What is an agile methodology?
1.1 Rapid business change – the ultimate driver. 1.2 What must agile methodologies be able to do? 1.3 Agility – what is it and how do we achieve it? 1.4 Evolving software – obstacles and possibilities. 1.5 The quality agenda. 1.6 Do we really need all this mountain of documentation? 1.7 The human factor. 1.8 Some Agile Methodologies. 1.8.1 Dynamic Systems Development Method (DSDM). 1.8.2 Feature Driven Design (FDD). 1.8.3. Crystal. 1.8.4 Agile modeling. 1.8.5 SCRUM. 1.8.6 Summary table. 1.9 Review. Chapter 2: Extreme Programming Outlined. 2.1 Some guiding principles. 2.2 The five values. 2.3 The twelve basic practices of XP. 2.3.1 Test first programming. 2.3.2 Pair programming. 2.3.3 On-site customer. 2.3.4 The planning game. 2.3.5 System metaphor. 2.3.6 Small, frequent releases. 2.3.7 Always use the SIMPLEST solution that adds business value. 2.3.8 Continuous integration. 2.3.9 Coding standards. 2.3.10 Collective code ownership. 2.3.11 Refactoring. 2.3.12 Forty hour week. 2.4 Review.
• “Agile” is an umbrella term for software processes that use iterative development as a process control framework • Agile methodologies are focused on • Early and Continuous Delivery of Software • Iterative Development • Business User Involvement • Building Effective Teams • Welcoming Changing Requirements • Agile Example: Extreme Programming • Cost of Change • Based on the premise that changing software is not as expensive as we once thought Cost of Change Time Traditional Assumption XP Assumption • XP’s Big Picture • Little or no requirements gathering • No “Big Design Upfront” • String together several time-boxed iterations • Develop most important features first • Stop when the features’ benefits aren’t worth the cost of an iteration • Anatomy of an XP Iteration High-Discipline Development • Customer Selects “Stories” • Stories broken into tasks and estimated Planning Game • Customer Runs Acceptance Tests Iteration Review • High-Discipline Development Practices • Pair Programming
In the late 80’s, increasing dependence on the success of IT projects and their high failure rate spurred the re-evaluation of the development methodologies of the day. IT projects were beginning to be recognized as the complex, chaotic animals that they are. The very structured, well defined, and rigid prescriptions of traditional methodologies such as Waterfall, PSP, Unified Process, etc. failed to allow for the dynamics of change, and in many cases failed to deliver a product before customer needs had already evolved to make the project inappropriate. Development strategies that expected and embraced change, intensively involved the people who would ultimately use the product, and focused on building a business solution rather than an IT solution began to be formed by individuals, organizations, and consortiums. In the mid 90’s these evolving new ideas began to coalesce into branded methodologies (DSDM, Scrum, FDD, Extreme Programming, Crystal, and others) which collectively became
