Analysis and Design in Agile
Analysis and Design in Agile
Join the DZone community and get the full member experience.Join For Free
Within a year of that first contact, I was an outspoken advocate of using XP. I successfully convinced a manager to try it out and it worked wonderfully for that group. I started talking to more and more people, and in doing so started to encounter the first myths and misconceptions about what XP did and did not do. That was 2001, and in 2011 I still hear many of the same things. So, let's deal with a few of those myths now.
Let me go back to what I read in XP Installed, XP Explained, the C2 Wiki and on the XP Yahoo group in those days. The 'genesis' of XP started when Kent Beck was faced with leading a restart of the Chrysler Comprehensive Compensation project in 1996. As I understand it, Kent was a reluctant leader and knew that he had to do something different. He reflected on everything and anything in his career that had 'worked', and reasoned that if a practice worked you should amplify it, i.e. take it to the extreme. To wit:
- Planning is good, so do it all the time (Planning Game)
- Analysis is good, so do it all the time (Planning Game)
- Design is good, so do it all the time (Planning Game, Test-Driven Development, Pair Programming)
- Testing is good, so do it all the time and automate it (Test-Driven Development, Customer Tests)
- Keeping the design clean is good, so do it all the time (Refactoring)
- Integrating completed code is good, so do it all the time (Continuous Integration)
- Feedback is good,, so do it all the time (Short Iterative Development)
- Releases to production are good, so do them all the time (Small Releases)
- Contact with the people for whom you're building the software is good, so do it all the time (Whole Team)
- Collaboration between team members is good, so do it all the time (Whole Team)
- Code inspections and reviews are good, so do them all the time (Pair Programming)
- Avoiding silos of knowledge is good, so do it all the time (Whole Team, Collective Ownership)
The key word there is "enough", which is very context dependent. A smallish web application may not require much analysis, design and planning beyond a few iterations or outside of the current release. The anti-lock brake management system for a car would likely need more. A constant very-high-volume system like Twitter would have different parameters for "enough" than an eCommerce application handling a few dozen paying customers per day. One lost tweet is no big deal, but a customer losing their cart on that eCommerce site could be lost business for that small company. Conversely, the eCommerce site need only handle a few concurrent users whereas Twitter must handle thousands. In the end, you always must be mindful of what constitutes "enough" in your domain.
Activities such as analysis and design happen in increments ranging from a couple of minutes to possibly as large as a couple of weeks:
- A pair of people may spend a few minutes at a whiteboard sketching out the work they're about to do to implement a story.
- A pair of people will use tests to guide their work and the design of the code while using Test-Driven Development.
- A team will spend a few hours to a few days doing Release Planning to map out work for the next few weeks to months. This will include an overall view of the design vision of the system.
- A team will spend a couple of hours doing Iteration Planning to map out work for the next week or so. This will include breaking the work into much more detailed tasks, and further refining the design.
- A large group of people may spend multiple weeks working through the business problem, usage scenarios, personae, use cases, and overall high-level design for a large enterprise system.
- A small startup may iterate on multiple small experiments per week in order to quickly get validated feedback on their business direction.
- A team of any size on any project in any domain may hold ad hoc sessions to discuss and refine the design as required based on any new learnings or refined understanding of the business problem.
Published at DZone with permission of Dave Rooney , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.