Through the years I have seen a few different development life cycles stuff like really ad-hoc frameworks to strict SCRUMS to hybrid Waterfall techniques. Ive seen many good projects fail and some bad ones devolve into catastrophies, but some things are constant.
These are some of my observations about each part...
In the beginning everybody is really excited about a fresh new project. Using that motivation a ton of documentation will be made. There will be a clear roadmap, requirements docs etc. but only for 25% of the actual end product. Some of the documentation will be stored on a company knowledgebase, most will be in peoples 'My Documents' folder and the remainder will be in printed version only and seriously out of date within 2 weeks.
Once the documentation has been completely somewhat written engineers will casually start coding ignoring almost all of the documentation and making numerous exceptions to the accepted designed framework and just generally doing what they want.
When a workable version of the product is ready, QA will rip it to shreds belittling the developers. They will quickly drill through any eye-candy the developers have put in and expose the complete and utter lack of functionality.
At the "halfway" mark developers sometimes wake up and start actually wiring up the buttons they added in the first part. They wont stay past 5 but they may not take a full 2 hours for lunch.
This is where I come in. Usually I would start to develop a kit and actually install the product. Its at this point I realize no one knows anything about how the product actually works. The fact that it exists will usually baffle me and I will spend several days reverting virtual machines trying to find the exact balance of Windows components and 3rd party software to install to get the app working.
About 3/4s of the way we enter the bickering stage. QA and Development will fight constantly in this phase. Engineers will be annoyed that QA "isnt using the software correctly" and QA well be slighted because devs "cant repro" implying QA dropped acid that day.
About 2 weeks out from the release date people start feeling the urgency. At this point the build process will inexplicably break causing the entire process to shut down for at least a week. QA will have little confidence in the product. The CTO or Engineering lead will freak out and get the date bumped. This could repeat for a while...
Eventually enough concessions will be made and functionality deferred to a future versions that the current version will be "ready." This is important because everyone has been looking forward to this date and eagerly awaiting the new release. If by eagerly awaiting you mean won't look at for two weeks.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment