An agile development process like eXtreme Programming is a complete antithesis to the practices of waterfall model. Downplaying the importance of following plans, processes and tools, documentation whilst demanding constant receptivness to customer-induced changes comes as a culture shock. To capture the essence of the eXtreme Programming methodology I look at the four key aspects of requirements, process, architecture and risk from its perspective.
Requirements - Customer written user stories, each around three sentences, substitute formal requirement document and are used for implementation estimate during release planning meeting (Wells,2006). The actual detailed requirement is captured face-to-face with the customer during story implementation but analysis documentation is deemed unnecessary (Bennett et al, 2006,p171). It facilitates dynamically changing requirements.
Process - The adaptive, collaborative, agile and lightweight process is antithesis of traditional lifecycle methodologies (Bennett et al, 2006,p61; Wells,2006). The process is user stories driven, customer-focused, iterative and incremental where feedback is continuous. Fixing a failing process is allowed and encouraged (Sorensen,2001). The teams are small and developers work 40-hours week. Test harness has to be created prior to any coding. The code is owned collectively and all team members can change it (Bennett et al,2006,p619), The developers have to adhere to standards, design simply, have the courage to discard solutions. Constant refactoring to simplify and remove redundancy is absolutely essential. A user is a full-time team member. No specialist roles exist. There is no emphasis on using modeling tools. The code itself is deemed design documentation. Pair programming is the norm.
Architecture - ‘you aren’t going to need it’ (YAGNI ) characterizes architecture too. Emphasis is on coding fast and relying on refactoring to fix design (Fowler,2004). The notion that we should keep things simple and not implement something till it is needed works against the idea of architecture. XP system metaphor is analogous to architecture (Herbsleb et al,2003 ). The metaphor, an evocative description, helps the team understand how the system hangs together (Herbsleb et al,2003). Simple design is emphasized and there is no upfront design (Stephens,2003). Architectural spikes or prototypes are used for testing design ideas (Sorensen,2002)
Risk - The paired programming, automated testing, continuous integration, accommodation of changing requirements, iterative development, customer involvement, improved communication, constant refactoring, coding standards, spike solutions etc are all geared towards minimizing risk (Brewer,2001;Wells,2006). The whole reason for subverting traditional practices is that XP significantly reduces risk in dynamically changing environment and these practices are at the heart of XP.
References
Bennett S., McRobb S. and Farmer R. (2006) Object-Oriented System Analysis And Design Using UML,
Brewer J (2001) Extreme Programming FAQ [online] Available from http://www.jera.com/techinfo/xpfaq.html
Wells, D. (2006) Extreme Programming: A gentle introduction [online] Available from http://www.extremeprogramming.org/rules/userstories.html
No comments:
Post a Comment