The Agile Movement


Published on

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Agile Movement

  1. 1. The Agile Movement Modelos de Procesos y Metodologías de Ingeniería de software Mayo de 2014 Universidad de Caldas Facultad de Ingenierías Maestría en Ingeniería Computacional
  2. 2. ¡Welcome!
  3. 3. Content Agile Methologies The Agile Manifesto Concrete agiles examples CMMI & Agile
  4. 4. Sources • Gerard O’Regan, Introduction to Software Process Improvement, Springer 2011. ISBN 978-0-85729-171-4 • Kenneth S. Rubin. Essential Scrum : a practical guide to the most popular agile process. Copyright 2013 Pearson Education, Inc. ISBN 978-0-13- 704329-3 • Scott Ambler and Mark Lines. Disciplined Agile Delivery. A Practitioner’s Guide to Agile Software Delivery in the Enterprise. Copyright 2012, IBM Press. ISBN 978-0-13-281013-5. • Joachim Rossberg and Mathias Olausson. Pro Application Lifecycle Management with Visual Studio 2012. Apress, 2012. ISBN 978-1118314081 • Alan Shalloway et al. Essential Skills for the Agile Developer - A Guide to Better Programming and Design. Copyright © 2012 Pearson Education, Inc. ISBN 978-0-321-54373-8. • Paul E. McMahon. Integrating CMMI® and Agile Development. 2011 Pearson Education, Inc. ISBN 978-0-321-71410-7.
  5. 5. Agile Introduction (I) The Agile methodology / Agile development is a software development methodology that claims to be more responsive to customer needs than traditional methods.
  6. 6. Agile Introduction (II) Agile has a strong collaborative style of working and its approach includes the following: – Aim is to achieve a narrow fast-flowing value stream – Feedback and adaptation employed in decision-making – User stories and sprints are employed – Stories are either done or not done – Iterative and incremental development is employed – A project is divided into iterations – An iteration has a fixed length (i.e. Timeboxing is employed) – Entire software development life cycle is employed for the implementation of each story – Change is accepted as a normal part of life in the Agile world
  7. 7. Agile Introduction (III) – Delivery is made as early as possible – Maintenance is seen as part of the development process – Refactoring and evolutionary design employed – Continuous integration is employed – Short cycle times – Emphasis on quality – Stand-up meetings – Plan regularly – Direct interaction preferred over documentation – Rapid conversion of requirements into working functionality – Demonstrate value early – Early decision-making
  8. 8. A tale about Agile (I) In 2001 a group of people met at a Utah ski resort to talk, ski, relax, and try to find common ground for software development. This is the result: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.”
  9. 9. A tale about Agile (II) That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
  10. 10. (I) “On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground and of course, to eat. What emerged was the Agile Software Development Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.”
  11. 11. (II) the Agile Manifesto lays down the following principles: • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project.
  12. 12. (III) • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face- to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility.
  13. 13. (IV) • Simplicity—the art of maximizing the amount of work not done—is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. More about Agile history in:
  14. 14. • SEMAT Deal ( • The new deal for software development ( But, be careful with “Deals”
  15. 15. • Ongoing changes to requirements are considered to be normal in the Agile world, and it is believed to be more realistic to change requirements regularly throughout the project rather than attempting to define all of the requirements at the start of the project. • The methodology includes controls to manage changes to the requirements, and good communication and early regular feedback are an essential part of the process. Agile features - changes
  16. 16. • A story may be a new feature or a modification to an existing feature. It is reduced to the minimum scope that can deliver business value, and a feature may give rise to several stories. • Stories often build upon other stories and the entire software development life cycle is employed for the implementation of each story. Stories are either done or not done, i.e. there is no such thing as a story being 80% done. The story is complete only when it passes its acceptance tests. • Stories are prioritized based on a number of factors including – Business value of story – Mitigation of risk – Dependencies on other stories Agile features – user stories
  17. 17. • Sprint planning is performed before the start of an iteration. The goal is to assign stories to the iteration to fill the available time. The estimates for each story and their priority are determined, and the prioritized stories are assigned to the iteration. • A short morning stand-up meeting is held daily during the iteration and attended by the project manager and the project team. It discusses the progress made the previous day, problem reporting and tracking, and the work planned for the day ahead. A separate meeting is conducted for issues that require more detailed discussion. Agile features – planning
  18. 18. • Once the iteration is complete the latest product increment is demonstrated to an audience including the product owner. • This is to receive feedback as well as identifying new requirements. • The team also conducts a retrospective meeting to identify what went well and what went poorly during the iteration. This is to identify improvement actions for future iterations. Agile features – delivery
  19. 19. • Agile employs pair programming and a collaborative style of working with the philosophy that two heads are better than one. • This allows multiple perspectives in decision-making and a broader understanding of the issues. Agile features – pair programming
  20. 20. • Software testing is very important and Agile generally employs automated testing for unit, acceptance, performance, and integration testing. • Tests are run often and aim to catch programming errors early. They are generally run on a separate build server to ensure all dependencies are checked. • Tests are re-run before making a release. • Agile employs test driven development with tests written before the code. The developers write code to make a test pass with ideally developers only coding against failing tests. • This approach forces the developer to write testable code. Agile features – testing
  21. 21. • Refactoring is employed in Agile as a design and coding practice. • The objective is to change how the software is written without changing what it does. • Refactoring is a tool for evolutionary design where the design is regularly evaluated and improvements implemented as they are identified. • The automated test suite is essential in showing that the integrity of the software is maintained following refactoring. Agile features – refactoring
  22. 22. • Continuous integration allows the system to be built with every change. • Early and regular integration allows early feedback to be provided. • It also allows all of the automated tests to be run, thereby identifying problems earlier. Agile features – integration
  23. 23. • AMDD • Agile Modelling - Scott Ambler • • TDD • Refactoring • Unit Testing • Continuous Integration • Pair development • User stories • Releasing Most representative contributions
  24. 24. • • • Extreme Programming (XP) is a deliberate and disciplined approach to software development. It stresses customer satisfaction, an important part of the Agile Manifesto. The methodology is designed to deliver the software the customer needs, when it is needed. XP focuses on responding to changing customer requirements, even late in the life cycle, so that customer satisfaction (business value) is assured eXtreme Programming (I)
  25. 25. • All code to be included in a production release is created by two people working together at a single computer. This should increase software quality without impacting time to delivery. • The software should be delivered to the customers as early as possible and a goal is to implement changes as suggested. XP stresses that the developers should be able to courageously respond to changing requirements and technology based on this foundation. • XP have user stories. These serve the same purpose as use cases, but are not the same. They are used to create time estimates for the project and also replace bulky requirements documentation. The customer is responsible for writing the user stories and they should be about things that the system needs to do for them. Each user story is about three sentences of text written by the customer in the customer’s own terminology without any technical software jargon that a developer might use. eXtreme Programming (II)
  26. 26. • XP also emphasizes teamwork. Managers, customers, and developers are all part of a team dedicated to delivering high- quality software. XP implements a simple and effective way to handle team work. • There are four ways XP improves software team work; communication, simplicity, feedback, and courage. • It is essential that XP programmers communicate with their customers and fellow programmers. The design should be simple and clean. Feedback is supplied by testing the software from the first day of development. • Testing is done by writing the unit tests before even writing the code. This is called TDD and has started to become a very well used practice in many projects, not only agile ones. • Another important issue is that XP stresses the importance of delivering working software in increments so that the customer can give feedback as early as possible. By expecting that this will happen, developers are ready for implementing changes. eXtreme Programming (III)
  27. 27. SCRUM Source: Source:SCRUM México  “the rugby approach” (1986) - Harvard Business Review Takeuchi and Nonacha argued that small cross-functional teams produced the best results from a historical viewpoint. 20Product%20Development%20Game.pdf
  28. 28. SCRUM (II) Source:
  29. 29. SCRUM (III) Source: Disciplined Agile Delivery The Scrum lifecycle
  30. 30. • Product backlog (work item list) • Value-driven lifecycle • Daily Scrum (coordination meeting). • Sprint review and demonstration • Sprint retrospective • User story driven development (usage-driven development). See: SCRUM (IV)
  31. 31. • Release planning: it suggests abstracting the project plan to a higher level that describes higher level milestones such as delivery of small increments of demonstrable functionality. These higher level plan items can then be allocated to a set of sprints (iterations) over the life of the project. • Sprint planning (iteration planning): At the beginning of the sprint/iteration the team plans in detail what they will deliver and how they will do the work. This involves taking a set of highest priority requirements off the backlog and then decomposing these requirements into detailed tasks. The team estimates this work and commits to the product owner that they will deliver the work according to the plan that they have created themselves. SCRUM (V)
  32. 32. You must know the Disciplined Agile Delivery of Scott Ambler, in order to understand the value of EPF process and libraries. Key Issue
  33. 33. • Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. • At a more detailed level AM is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and lightweight manner. • AM was purposely architected to be a source of strategies that can be tailored into other base processes. Agile Modelling (I)
  34. 34. • With an Agile Model Driven Development (AMDD) approach you typically do just enough high-level modeling at the beginning of a project to understand the scope and potential architecture of the system. • During construction iterations you do modeling as part of your iteration planning activities and then take a just-in-time (JIT) model storming approach where you model for several minutes as a precursor to several hours of coding. • AMDD recommends that practitioners take a test- driven approach to development although does not insist on it Agile Modelling (II)
  35. 35. Agile Modelling (III) Source: Disciplined Agile Delivery
  36. 36. Agile Modelling (IV) Source: Disciplined Agile Delivery and
  37. 37. Agile Modelling Features •Active stakeholder participation •Architecture envisioning •Document continuously •Document late •Executable specifications •Iteration modeling •Just barely good enough artifacts (sufficient artifacts) •Look-ahead modeling •Model storming •Multiple models •Prioritized requirements (work item list) •Requirements envisioning •Single source information •Test-driven development (TDD)
  38. 38. Other agile methodologies • Lean Development • Kanban • DSDM • ASD • Crystal
  39. 39. Comparison from DAD S. Ambler
  40. 40. Comparison from DAD S. Ambler
  41. 41. CMMI & Agile (I) The CMMI model is not a set of dictated practices. It is a model that is intended to be used to “reason” about our processes to help us ask the right questions leading to an understanding of our weaknesses and areas of needed improvement.
  42. 42. CMMI & Agile (II) Source: Integrating CMMI and Agile Development
  43. 43. CMMI & Agile (III) Source: Integrating CMMI and Agile Development
  44. 44. How CMMI and Agile Help Each Other (I) Source: Integrating CMMI and Agile Development
  45. 45. Source: Integrating CMMI and Agile Development How CMMI and Agile Help Each Other (II)
  46. 46. How CMMI and Agile Help Each Other (III) Source: Integrating CMMI and Agile Development
  47. 47. Questions? Thanks