I’ve just been planning some work for fellow developers, and thought I’d throw some thoughts up on what I feel creates a good approach for working as a team.
Know the “critical path”
Before you get started, try and identity what problems you will encounter (easier said that done), but be sure to have a clear understanding of how you are going to approach the development and what things need to be done in what order (i.e. what will cause a delay if its not done in time!).
Keep work segments small
Try and ensure that any given task can easily be completed in a day – that includes researching it, building it and ultimately testing it. If its going to take longer, then break it down further. Keeping tasks small like this helps people stay motivated, as they feel that the project is progressing a little bit further every day – and its measurable.
If you find that you are stuck on something, or it’s taking longer than you expected, look at it again – sometimes even scrapping it and starting again totally, although annoying, is the best thing to do.
Make use of people’s strengths
Development is a very broad term, and there are many subtle facets to it. For example, some developers are better at GUI work, others better at service or back office code. Others might be more skilled at doing Silverlight, ASP.NET or maybe Win Forms. Don’t always assign tasks purely based on strengths though – we all like a bit of variety, and it’s important to not find things get too routine.
Use source control
Now this one I really can not stress enough. I don’t care if you use SVN, VCS, Team Foundation Server, GIT, or whatever.
No matter how small your team, you MUST run source control. Personally I have every project I work on (yes, even if I’m the only developer) source controlled. Why? It means I know what I’ve done, what’s remaining to do (Trac or TFS are great for this) and it gives me the all important backups. However, for source control to be really useful, its important to have some rules. Some simple ones that I tend to mandate are:
- Code is checked in at the end of every day. If its not finished (you did read the above though right?), then shelve it (again, TFS, very good), but locks must be cleared and code must go in.
- Run code analysis automatically
- Run gated check-ins. If you break the build, sorry, you are the one that has to fix it.
- Comments rule. Checkin comments should NOT be optional.
- Assign any tickets. If you are using TFS or Trac, or similar, then the work item tickets should be assigned to the checkin. Simple really.