Software engineering MODULE3__Agile.pptx

Software system engineering and project management

1. MODULE 3 AGILE DEVELOPMENT Dr. Dayanand J HOD AIML Dept.

2. Chapter 3 2 Agile Development Software Engineering: A Practitionerʼs Approach, 7/e by Roger S. Pressman

3. The Manifesto for Agile Software Development 3

4. 3.1 What is “Agility”? 4 Effective (rapid and adaptive) response to change Effective communication among all stakeholders Drawing the customer onto the team Organizing a team so that it is in control of the work performed Yielding … Rapid, incremental delivery of software

5. 3.2 Agility and the Cost of Change 5

6. 3.3 What is An Agile Process 6 key assumptions [Fow02] about the majority of software projects: It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds So it i s driven by customer descriptions of what is required (scenarios) For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created.

7. Recognizes that plans are short-lived Develops software iteratively with a heavy emphasis on construction activities Delivers multiple ʻ software increments ʼ Adapts as changes occur

8. Agility Principles - I 8 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. 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.

9. Agility Principles - II 9 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. 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.

10. Human Factors 10 the process molds to the needs of the people and team, not the other way around key traits must exist among the people on an agile team and the team itself: Competence. Common focus. Collaboration. Decision-making ability. Fuzzy problem-solving ability. Mutual trust and respect. Self-organization.

11. Extreme Programming (XP) 11 The most widely used agile process, originally proposed by Kent Beck XP Planning Begins with the creation of “ user stories ” Agile team assesses each story and assigns a cost Stories are grouped to for a deliverable increment A commitment is made on delivery date After the first increment “ project velocity ” is used to help define subsequent delivery dates for other increments

12. Extreme Programming (XP) 12 XP Design Follows the KIS principle Encourage the use of CRC cards (see Chapter 8) For difficult design problems, suggests the creation of “ spike solutions ”—a design prototype Encourages “ refactoring ”—an iterative refinement of the internal program design XP Coding Recommends the construction of a unit test for a store before coding commences Encourages “ pair programming ” XP Testing All unit tests are executed daily “Acceptance tests” are defined by the customer and excuted to assess customer visible functionality

13. Extreme Programming (XP) unit test continuous integration 13 acceptance testing user stories values acc e ptance t e s t cr i t e r i a iteration plan simple design C RC cards spike solutions p r otot y pe s refactoring pair pr o g r a mm i n g Release software increment proje c t v e l oc i t y c omp u t ed

14. Industrial XP “ IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-centric, test-driven spirit. IXP differs most from the original XP in its greater inclusion of management, its expanded role for customers, and its upgraded technical practices.” IXP incorporates six new practices that are designed to help ensure that an XP project works successfully for significant projects within a large organization 1. Readiness assessment . Prior to the initiation of an IXP project, the organization should conduct a readiness assessment. 2. project community . Classic XP suggests that the right people be used to populate the agile team to ensure success. a large organization, the concept of the “team” should morph into that of a community. A community may have a technologist and customers who are central to the success of a project as well as many other stakeholders (e.g., legal staff, quality auditors, manufacturing or sales types)

15. 3. Project chartering. The IXP team assesses the project itself to determine whether an appropriate business justification for the project exists and whether the project will further the overall goals and objectives of the organization. 4. Test-driven management. An IXP project requires measurable criteria for assessing the state of the project and the progress that has been made to date. 5. Retrospectives . An IXP team conducts a specialized technical review after a software increment is delivered. Called a retrospective, the review examines “issues, events, and lessons-learned” across a software increment and/or the entire software release. 6. Continuous learning . Because learning is a vital part of continuous process improvement, members of the XP team are encouraged (and possibly, incented) to learn new methods and techniques that can lead to a higher quality product.

16. 3.5 Other Agile Process Models The most widely used of all agile process models is Extreme Programming (XP). But many other agile process models have been proposed and are in use across the industry. Among the most common are: Adaptive Software Development (ASD) Scrum Dynamic Systems Development Method (DSDM) Crystal Feature Drive Development (FDD) Lean Software Development (LSD) Agile Modeling (AM) Agile Unified Process (AUP)

17. Adaptive Software Development 17 Originally proposed by Jim Highsmith ASD — distinguishing features Mission-driven planning Component-based focus Uses “ time-boxing ” (See Chapter 24) Explicit consideration of risks Emphasizes collaboration for requirements gathering Emphasizes “ learning ” throughout the process It incorporates three phases, speculation, collaboration, and learning

18. Adaptive Software Development adaptive cycl e planning u s e s m i ssi on s t a t e m e n t p roje c t c on s t r a i n t s b as i c r e q u i re m e n t s t i m e - b ox ed re l e a s e p l a n R e q u i re m e n t s g a t h er i n g JAD mini-specs c omp on e n t s i mp l e m e n t ed / t e s t ed f oc u s g r ou p s f or f eed b a c k f or ma l t e c hn i c a l re v i e w s postmortems a d j u s t m e n t s f or s u b s eq u e n t c y c l e s Release s of t w a r e i n c r e m e n t 18

19. During speculation, the project is initiated and adaptive cycle planning is conducted. Adaptive cycle planning uses project initiation information—the customer’s mission statement, project constraints (e.g., delivery dates or user descriptions), and basic requirements—to define the set of release cycles (software increments) that will be required for the project. Motivated people use collaboration in a way that multiplies their talent and creative output beyond their absolute numbers. This approach is a recurring theme in all agile methods. As members of an ASD team begin to develop the components that are part of an adaptive cycle, the emphasis is on “learning” as much as it is on progress toward a completed cycle. learning will help them to improve their level of real understanding. ASD teams learn in three ways: focus groups, technical reviews and project postmortems

20. Scrum (the name is derived from an activity that occurs during a rugby match) is an agile software development method that was conceived by Jeff Sutherland and his development team in the early 1990s. It incorporates the following framework activities: requirements, analysis, design, evolution, and delivery. Within each framework activity, work tasks occur within a process pattern called a sprint. The work conducted within a sprint is adapted to the problem at hand and is defined and often modified in real time by the Scrum team. The overall flow of the Scrum process is illustrated in Figure 3.4 Scrum

21. Scrum Process Flow (used with permission) 21

22. Scrum emphasizes the use of a set of software process patterns that have proven effective for projects with tight timelines, changing requirements, and business criticality. Each of these process patterns defines a set of development actions: Backlog —a prioritized list of project requirements or features that provide business value for the customer. The product manager assesses the backlog and updates priorities as required Sprints —consist of work units that are required to achieve a requirement defined in the backlog that must be fit into a predefined time-box (typically 30 days) Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum team. Three key questions are asked and answered by all team members • What did you do since the last team meeting? • What obstacles are you encountering? • What do you plan to accomplish by the next team meeting?

23. 23 Scrum—distinguishing features Development work is partitioned into “ packets ” Testing and documentation are on-going as the product is constructed Work occurs in “ sprints ” and is derived from a “ backlog ” of existing requirements Meetings are very short and sometimes conducted without chairs “ demos ” are delivered to the customer with the time- box allocated

24. Dynamic Systems Development Method Promoted by the DSDM Consortium ( www.dsdm.org ) DSDM—distinguishing features Similar in most respects to XP and/or ASD Nine guiding principles Active user involvement is imperative. DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of deliverables. Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible. Requirements are baselined at a high level Testing is integrated throughout the life-cycle. 24

25. DSDM life cycle that defines three different iterative cycles, preceded by two additional life cycle activities Feasibility study —establishes the basic business requirements and constraints associated with the application Business study —establishes the functional and information requirements that will allow the application to provide business value Functional model iteration—produces a set of incremental prototypes that demonstrate functionality for the customer. Design and build iteration —revisits prototypes built during functional model iteration to ensure that each has been engineered in a manner that will enable it to provide operational business value for end users I mplementation —places the latest software increment (an “ operationalized ” prototype) into the operational environmet

26. Dynamic Systems Development Method DSDM Life Cycle (with permission of the DSDM consortium) 26

27. Crys t a l 27 Proposed by Cockburn and Highsmith Crystal—distinguishing features Actually a family of process models that allow “ maneuverability ” based on problem characteristics Face-to-face communication is emphasized Suggests the use of “ reflection workshops ” to review the work habits of the team

28. Feature Driven Development 28 Originally proposed by Peter Coad et al FDD—distinguishing features Emphasis is on defining “features” a feature “is a client-valued function that can be implemented in two weeks or less.” Uses a feature template <action> the <result> <by | for | of | to> a(n) <object> A features list is created and “ plan by feature ” is conducted Design and construction merge in FDD

29. Feature Driven Development 29

30. Agile Modeling 30 Originally proposed by Scott Ambler Suggests a set of agile modeling principles Model with a purpose Use multiple models Travel light Content is more important than representation Know the models and the tools you use to create them Adapt locally