Bottom-Up Project Planning
Let’s go back now to my recent project. Several days were spent creating a detailed plan that embodied our approach, describing the tasks involved along with some concept of the resources necessary. That plan was then passed on to the project manager. The technical team now felt comfortable about the scope of the project, and we felt more prepared for our second meeting with management. We now believed we had a defensible position that was substantiated by a realistic plan.
About halfway through the design phase, however, a project manager came on board and recommended that we use the Agile methodology. Forgive a digression, but it appears to me that the main reason Agile is compelling to management is its stark simplicity. Essentially, it uses only a handful of operative words: iteration, scrum, dynamic method adaptation, and a few others, and it is now being extolled as being analogous to the way software was written in the past. As an object-oriented technologist, I have no interest in returning to the languages of the past, such as Assembler or FORTRAN, so I don’t really identify with this statement.
Basically, we created scrums and iterations from the existing project plan. (Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices.) Since some of the designs were complete, we then initiated full lifecycle iterations: that is, design to code complete. The early iterations went fairly well, which seemed to corroborate the success and usefulness of the methodology. I was assured early on during the effort that for subsequent iterations we would complete the design first; however, that never happened. We ended up completing the design the old-fashioned way, by having ad hoc whiteboard discussions of the object interaction and workflow behavior.
I also found that the concept of moving back and forth between design and coding is somewhat awkward. Design time is when you get away from computers, to a degree, and conceptually create the proposed system. In fact, being encumbered by the immediate implementation (e.g. Java, C++, etc.) can destroy creative forward engineering. Additionally, not having an end-to-end complete design can result in inconsistent applications; the design “model” needs to be completed as a single body of work, not something that can be incrementally carved up into iterations. In reality, some organizations mistake activity, in particular coding, for progress; time spent actually designing is simply not appreciated.
Implications
Today’s technologists are more interested in learning implementation than in learning design. I further submit that with the advent of anti-methodologies, such as Agile, the design ineptness of software development organizations has been further exacerbated—not remedied. Although I truly believe that the best designers understand implementation as well as design, it is their ability to negotiate the feedback loop between design and implementation that results in the most effective approach to software development.
As my statistics professor cautioned at the university, a little bit of statistics is a dangerous thing. The same can be said about methodology.
0 komentar:
Post a Comment