- project is not a brand new one rather an enhancement or a maintenance of an existing system. What if there are not enough knowledgeable members left over, or not enough up-to-date documentation.
- You may want to consider the practice, in which high-level concepts and requirements are kept in documents while low-level details are explained in source code comments. This way, the documents won’t get out of date quickly, and developers don’t have to go to multiple places to keep things up to date.
- Consider Agile, if you can break a project into many easy-to-manage intermediate deliverables to take advantages of the benefits Agile offers such as iterative fine tuning, earlier usage of implemented functions (maximizing ROI). Still, I feel it will be more effective if certain best practices are followed to provide necessary check and balance, and further to avoid the traps mentioned above. If a project is too complex, you may want to consider something like waterfall model for a complete project plan before breaking it down to iterations. Without a "whole" picture, the likelihood of re-architect your software at the iteration level is high. It, of course, is highly undesirable.
- You may want to consider tools, which provide the flexibility for you to customize a process to best fit your situation and enforce your best practices. Productivity enhancement tools are also important, because small time saving become big one due to the repetitive and iterative nature of Agile.
- It will pay off if you mandate certain critical modules are reviewed. Not only more heads are better than one, but also more people are knowledgeable of critical pieces. It, too, is true that developers will do a better and more complete job, because they know others are looking over their shoulders.
In summary, there are no hard and fast rules but the best process for a project. What process to use depends on many factors such as the nature of the project (complexity, management’s and end users' expectations, etc.), the construct of the team (skill sets, communication means, commitment, etc.). As mentioned in the beginning, the intention of this article is to stir up more discussions, and, hopefully, via your participation we can all benefit from each other’s knowledge and experience.
|The Myth of Agile||47.51 KB|