There are many complex facets of software development, and in many ways, I think the open source world has adopted them quicker and better than the corporate world. There are many reasons for this, but I think the main factor is that since open source projects have developers not confined to the same office (or office hours for that matter), there must be an organized development environment and communication structure.

There are many different development styles (XP, SCRUM, etc), and what I’m proposing here is a simple but effective summary of some of these practices. These guidelines target 3 groups of people directly involved in the process; clients, developers, and managers.

1. All 3 groups must communicate using a standardized platform. In general, this means using some form of issue tracking software (bugzilla, jira, scarab, xplanner, etc). All too often, corporations fall into this kind of trap: clients send requests to managers, managers communicate to developers, black hole and clients do not know how/when features/fixes are put in place. Issue tracking is frowned upon as a “waste of time”, but considering the benifets of having direct and fluid communication between clients and developers, it’s a must have.
2. Clients define the feature set. Managers work to break down features into workable pieces, but having the clients actually involved in this creates a great deal of “project ownership” for them.
3. Clients set the priority of features, thus defining the project roadmap and release schedule. If the client decides that feature A is a hot item even though it requires a great deal of side work and wasn’t scheduled until later in the project, TOUGH! Managers should be informing clients and developers on the ramifications of these changes (possibly swaying clients to wait until time permits), but the bottom line is that the clients know what they “need”.

This is a consise listing of what I would call Feature Driven Development. It doesn’t get bogged down with guidelines and rules like some other practices. I’m just a software developer, but I see the corporate environment needing a big kick in the pants to get some basic software development practices in place.