Gustavo Muñoz - justavo, kanchenjungo, zipi

I am not going to say anything new (I hope) to people who work in IT, this post is for all those friends who want to know a little bit more of my daily activities regarding software. Of course, I would need to add other items like strategic planning, human resources activities, support for versions that are already in the market, etc. Here I just focus on the typical steps for a release.
It could be equally a partial release, a sole milestone that will be available for external consumers or a big, final one. Management typically is Product Management. Testers belong to Product Management while Programmers are part of Engineering.

1. Management states high-level requirements.
2. Programmers formalize the requirements in detail.
3. Management approves detailed requirements.
4. Programmers identify testing resources.
5. Management approves testing resources.
6. Programmers estimate duration of design phase.
7. Testers estimate duration of test plan creation.
8. Management approves design and test plan efforts.
9. Programmers perform design phase.
10. Testers begin development of test plan.
11. Programmers estimate duration of estimation phase.
12. Management approves estimation phase.
13. Programmers perform task partitioning.
14. Programmers perform detailed estimate in hours.
15. Management may allocate additional programming resources.
16. Programmers define timeline with incremental milestones.
17. Management approves the timeline.
18. Programmers begin implementation.
19. Testing begins when software deliverables are available.
20. Programmers complete implementation.
21. Testers perform full regression testing.
22. Programmers define integration procedures.
23. Programmers implement installation program.
24. Testers perform full regression testing including installation and integration.
25. Testers approve beta release.
26. Beta testing begins.
27. Testers perform free play testing in parallel with beta.
28. Beta testing complete.
29. Testers perform full regression testing including installation and integration.
30. Testers along with Management approve product release.
31. Management or marketing begin distribution.
32. Programmers collapse in corner and sleep for three days.

Of course each step requires a lot of negotiation, back and forth decisions, redesign, rework, etc. Not only that, finalizing requirement details typically don’t happen as early as the 2nd. or 3rd. step. So you need to think on these steps not exactly as a linear procedure, but as a revolving one. Even when date changes with some changes included on the way, it on what to include in the release and what don’t. Typical question is isn’t it possible to squeeze these few requirements also? Then you need to say if we include these then we must take out those…
Now, the most important thing for my friends. Risks for your free time to get reduced to ashes include:

1. Errors you make while discussing the scope of the delivery and timeline.
2. Negative externalities which force Management to force adding some features Engineering is refusing to include because there is not enough time to create them.
3. Errors in the timeline you give for the implementation (this is the most typical one when you are doing something that you have never done before).
4. Errors in the design that force you to redesign and rework when you are in the implementation phase.
5. Poor implementation from part of your team, so you need to rescue that module
6. Poor communication from within your team when some problem arises and it is communicated too late, so you enter in a tough situation because you don’t have enough time to manage

Note: Steps were mainly taken from Duncan’s The career programmer (BTW, a must for any programmer that wants to understand the environment where she works daily).