There is a balance between delivering use cases to the market and maintaining overall software quality in an Agile Software Development Project. It's extremely easy to get "trapped" into the "tunnel vision" of providing user facing features as fast as possible and quickly encounter architectural deficiencies and technical debt that impacts the overall quality and performance of the software.
Agile does not mean NO architectural design! Many teams just learning agile have difficulty understanding how design "fits" into the use case or user story methodology.
Here at ERDAS, we utilize planned 'spikes' and design sessions and plan them in iterations before implementation of the the user/system interaction to ensure that the resulting imlpementation soundly builds upon our architecture.
A SPIKE is a "technology" discovery process. It can be a research project into technologies or algorithms, an evaluation/benchmark or prototype of technologies to find a "best fit" or a discovery process of existing algorithms and archtecture to provide man day estimates or "Level of Effort" to get some use case completed. We effectively use SPIKES to address the "unknown" or "uncertain", dedicate time to make it known and to determine how long it will take to satisfy a use case and always report the results of every spike in the Iteration Review.
We also enforce a "time capped" rule on spikes. This rule essentially allocates a fixed amount of time that it will take to "discover" what we want to know. At run time if a blocking issue is encountered, we can always increase the duration of the spike, but we very seldomly do so. Time capping the spike really enables detailed planning, ensuring we avoid "creep" in a discovery process and stay on schedule.
Subscribe to:
Post Comments (Atom)
1 comment:
It was very interesting and useful helpful blog, i think this is about software development, programming thanks for shearing.
Post a Comment