Adopting software project management and testing protocol from scratch

Question

I work in a small company (2-4 software developers) where software is "only" a part of the main product (specialized measurement instruments). So far the software has been built from start to end with no formal process at all, but as we're steadily growing in both in number of products and people involved, it's evident that we need to adopt some kind of methodology for the whole thing (designing, building, testing, maintaining) to avoid blowing into a mess

The problem is that none of us has much real-world experience on such processes. Wikipedia's software development methodology and software development process entries list lots of practices, and I'm aware of the modern buzzwords (agile, extreme, etc.), but we're still lost on how and from where to start all this.

What should we do to get started, given that currently we have no formal process, and the goal would be to have a light process that helps us keep things under control without slowing us down? Is there some:

• Essential de facto literature that we should read first?
• Essential tools? (We do have a SCM, but should we start using something like FogBugz?)
• Practical "do this and this" guidelines?

Any guidelines are welcome, as long as they're not 1000+ page books! I want to avoid both the religious hype and the dull academicity that seem to surround this field, and find out what to do in practice.

Answer 1

Highly recommended reading includes : The Agile Manifesto and The Pragmatic Programmer. Subsequently, you'll probably want to get familiar with Scrum software development, or Test-Driven Development. At the very least you should have:

• Source Control repository
• Bug tracking system
• Standard set of tools for communication (A wiki tends to be popular for documentation, these days),
• IDE
• Testing framework

A lot of things will depend on the skills of your team and the application domain that you're seeking to go into. Get yourselves familiar with some methodologies, then practice them. Have 15 minute standing meetings at the start of the day. Develop code incrementally with a write a failing test, make it pass, repeat mindset. Etc etc.

Answer 2

Subscribing rigidly to someone else's view of the development process isn't going to work for everyone. Start with the real basics

1. Get the basics of the development process right - see The Joel Test.
2. Track everything. Use a system like JIRA, FogBugz or so on to track all issues, features and bugs that are ever reported. Track how long you spend on each task; the information you have the better prepared you'll be.
3. Triage - Work with stakeholders to make sure what you are doing is actually important, rather than just what you think is important. In my experience, developers and customers often have wildly differing views!

Answer 3

I would suggest to try Scrum for start. As lightweight project management framework it should suite your small team needs.
To do that less painful I would also suggest temporary hiring someone familiar with scrum (certified scrum master maybe), after 3-4 months you should be able to keep it running by yourself. Really investing in few months of experienced team member should pay off. And I don't mean analytic, consultant or whatever you call person that comes, analyzes, makes presentation, takes money and goes while you stay with a problem. I mean Team member that will work with you but also introduce scrum to you via daily practice.
You could also just read some books instead, or send one or two team members to a training, but I think that having someone to incorporate Scrum into your daily work and start learning by examples is the best.

Good description detailed description (based on daily work) would be Scrum and XP from the Trenches (alternative source).

Answer 4

I'm a huge fan of the recent Lean literature by the forerunners of the movement, Mary and Tom Poppendieck:

• Lean Toolkit
• Implementing Lean Software Development: From Concept to Cash
• Leading Lean Software Development

These are very practical books that look at the whole business value chain from a software team's viewpoint, instead of being head-down in software land and ignoring business goals.