Application Lifecycle Management
Any worthwhile software is not just developed, it is also used and should have at least some level of governance. The application lifecycle involves all three of these areas, and they all need to be considered when managing the software. This post will mostly discuss processes rather than software.
There are a number of documented processes that can be used in software development such as Agile, Scrum, Kanban and Continuous Integration. We won’t go into these in any detail as they are documented elsewhere and most opensource development teams just build their own processes.
It is vital that the project’s scope and progress is well documented. It should be possible to track work items, look at task listings and get reports on time usage. This is the absolute basics that any open source project should have, more corporate development teams should spend more time on time tracking and produce burndown and velocity reports (which may also be possible for some open source teams). Shareholders shouldn’t have to ask a developer to find out the status of a project, it should all be documented.
If teams are physically working together, daily standup meetings can be a great idea. These should address just three issues, what did we do yesterday, what are we doing today, and what’s stopping us from doing that? These meetings aren’t always suitable for every development team’s style, but some variation of them should be considered for implementation.
The process for developing the code should be considered before any programming happens. This should include things like branching strategies and what is required before code is allowed into the software. Branching strategies are discussed on the codeplex website amongst other places, requirements for code acceptance aren’t often talked about and will vary. The most important thing is to not break the build, doing so will delay everybody, and so stopping people from commiting code which fails to compile (and other basic tests) is top priority. Doing smoketesting, ensuring checkins are commented and linking checkins to jobs are other good ideas. If people do want to checkin code which isn’t entirely working (for review or to keep safe) they should use personal repositories.