Here’s a brief list of some of the most obvious, and important, team-level best practices I know for software development:
- Do use some form of repeatable agile process for building software applications. Almost any repeatable process is better than none at all. (If you need one I recommend Scrum.)
- Do use a source code control system (git, svn, or commercial products).
- Do use a formal bug-tracking system (bugzilla or commercial products).
- Do have some form of source code peer review.
- Do have coding standards, preferably a consistent set of standards across all applications.
- Do have a repeatable automated build system for your applications (such as ant for Java projects).
- Do have some mix of experienced developers (who are good and experts in these practices) and relatively new developers.
- Always keep the application in a running, demonstrable state.
If I came in to review an organization’s software development ability, and they didn’t have at least these things going I wouldn’t talk to them about anything else. My comments would “get these things going, then give me a call.”
There are a ton of other things I recommend, but at a second tier I’d start looking at these practices:
- Do write unit tests, and lots of them.
- Do ask developers to estimate their tasks. That’s the only way they’ll get better at estimating, and managers need this information. Look at things like Function Point Analysis to help estimate project size and cost.
- Especially on larger projects, do have your entire team close to each other, preferably in the same large room, definitely as close as possible in the same building. (If I’m next to you I’ll talk to you; if I’m a block away I’ll call you; if I’m a mile away I’ll forget about you.)
- Don’t ever say you’re “75% done” or “90% done.” Talk like that makes me want to puke. You’re only done when acceptance testing is complete and you have some acceptable level of open bugs. (Preferably zero known bugs, but on a large system that’s not always going to happen.)