1. 1 Review  Software life cycle  Software process  Various software process models Have advantages and disadvantages  A unified model Iterations Many ways of tailoring it for specific project

2. 2 A Process Management Challenge  Process complexity Many interacting processes Different processes may follow different process models  The challenge To ensure the effectiveness and the efficiency of the processes involved in software projects To increase the predictability of the outcome for each process

3. 3 Answer #1  Keep it simple (KIS)  Rapid feedback

4. 4 Agile Software Processes Slides adapted from a tutorial presented by Pekka Abrahamsson from VTT Eletronics

5. 5 Key Questions  What is agility?  Where is agility needed?  What are agile software development methods?

6. 6 What is agility  Agile (Webster’s 1913) Having the faculty of quick motion in the limbs Apt or ready to move  Agility for a software development organization The ability to adapt and react expeditiously and appropriately to changes in its environment and demands imposed by the environment The ability to both create and respond to change in order to profit in a turbulence business environment Agility at organization, project, and individual levels

7. 7 Where agility is needed?  Complex problems characterized by Change Turbulence  Situations where accelerated development is required To meet tight delivery schedule To reduce the significant risk and uncertainty  Changes imposed by rapidly evolving technology, business, and product needs

8. 8 Agile Thinking Explained Need to respond To constant changes The fundamental reason For a new paradigm Values Defines the set of beliefs About what is the most important Principles Defines a set of ways To meet the values Practices Defines in detail how this Is implemented in practice

9. 9 Need to respond to constant change  Software development can be affected by many changes Changes in development environment and technology Organizational changes Personnel changes Product requirement changes …  Software development should embrace change rather than avoid it

10. 10 Manifesto for Agile Software Development 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. Source: www.agilemanifesto.org

11. 11 The 12 Principles  Flexible and simple planning 1. Satisfy customer’s need through early and frequent delivery 2. Keep delivery short (e.g., every couple of weeks) 3. Working software is the primary measure of progress 4. Welcome changing requirements even late in the project

12. 12 The 12 Principles (cont’d)  Building and maintaining a good team 5. Business people and developers work together daily throughout the project 6. Build projects around motivated individuals 7. Place emphasis on face-to-face communication 8. The best results emerge from self-organizing teams

13. 13 12 Principles (cont’d)  Simple and good design 9. Continuous attention to technical excellence and good design 10. Promote sustainable development pace 11. Simplicity is essential 12. Team reflects regularly where and how to improve

14. 14 Agile Philosophy  The importance of self-organizing teams  Communication and collaboration between team members  Recognition that changes represent opportunities  An emphasis on rapid delivery that satisfies the customer

15. 15 How agility can change your organization  Interaction and communication Much more interaction between developers, management, and customers Level of informal communication increases  Visibility Related stakeholders know the exact status of the project  Much shorter development cycle The pace of development can become very high  Less effort spent up front

16. 16 Agile Software Development Methods (Processes)  Share the following characteristics Incremental Small releases, rapid cycles Cooperative Customers and developers working constantly together with close communication Straightforward The method is light, simple, well documented, easy to modify Adaptive The method is able to take into account last moment changes

17. 17 Extreme Programming (XP)

18. 18 Introduction  Developed by Kent Beck in 1999  Address the basic risks in software development  Method is formed around common sense principles and simple to understand practices No process fits every project, rather, simple practices should be tailored to suit an individual project

19. 19

20. 20 Some XP Key Words  Client as a team member  User stories Short description of a desired functionality Fit on a 3”x5” note card Stories can evolve  The planning game  Pair Programming  Test-first software development  Refactoring and continuous design improvement

21. 21

22. 22 XP Management Practices  Small/short releases  Planning game Release planning Iteration planning  40 hour weeks?

23. 23 XP Implementation  Coding standards  Pair programming  Metaphor  Simple designs  Refactoring  Test-driven

24. 24 Coding Standards Recommendations for the programmer with regards to  how to lay out the code, e.g. tabbing, braces, comments  where source code files should be located in the file system  which settings should be used for the compiler and linker  which naming conventions should be followed for files, classes, methods, attributes, parameters, and local variables.

25. 25 Pair Programming TWO programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software.

26. 26 Metaphor  Explaining the project in terms understandable to the audience  Different Metaphors for different audiences Patterns when explaining to other developers Plain English for the ccient company’s CEO

27. 27 Refactoring  Early coding is kept simple to facilitate rapid early progress  Subsequent iterations bring in complexity, including application of patterns

28. 28 Other Practices  XP SCM Collective code ownership Continuous integration  XP V&V Continuous testing On-Site customer test

29. 29 How XP solve some SE problems ProblemSolution Slipped scheduleShort development cycles Cancelled projectIntensive customer presence Cost of changesExtensive, ongoing testing, system always running Defect ratesUnit tests, customer tests Misunderstand the business Customer part of the team Business changesChanges are welcome Staff turnoverIntensive teamwork

30. 30 Known Limitations  Limitation XP is aimed at small to medium-sized teams Requires the development team to be located in one place Cannot solve the problems in projects that are not XP-able.

31. 31 Scrum

32. 32 Introduction  Developed by Schwaber in 1995 Based on experiences from adaptive, self- organizing product development in Japan  Focuses on managing systems development in a changing environment Strictly management only The choice of the software development methods are up to the project

33. 33

34. 34 Key Concepts  Backlog A dynamic set of product features  Sprints A set of backlog items that can be done in a predefined timebox (30 days)  Scrum daily meetings 15 minute status report What did you do since the last meeting? What obstacles are you encountering? What do you plan to accomplish by the next team meeting?

35. 35

36. 36 Key Concepts  Effort estimation  Product backlog  Sprint  Sprint planning meeting  Sprint backlog  Daily scrum meeting (15 minutes)  Sprint review meeting (4 hours)

37. 37 Sprint  a short burst of work lasting approximately 30 days during which an executable and other deliverables are built by an engineering team, as indicated by the assigned backlog.  A sprint is undertaken by a cross functional team consisting of no more than 9 members.  Every sprint has a specific goal, expressed as the backlog. the list of tasks that the Scrum team is committing that they will complete in the current sprint  An executable demonstrating the goal will be completed by the team during the sprint.  The sprint team has final say in estimating and determining what they can accomplish during the sprint.  Once the sprint is underway, new backlog cannot be added to the sprint except that, if the scrum master determines that a new backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint’s executable, and can be completed within the sprint’s time frame, the backlog item can be added. Examples are building a demonstration of the executable for a specific purpose, such as a trade show or prospect.  If external forces determine that the sprint is working on the wrong thing, a sprint can be halted and restarted with new backlog and purpose.

38. 38 Mix-and-Match  The practices in different agile methods can be extracted and combined  Examples Pair programming and its variation Daily scrum meeting Test-driven development approach  The key Understand the problems the practice is addressing Understand the essence of the practice

39. 39 Agile method in one slide  Is suitable for a volatile development environment Product requirements and business environment change often Tight schedule are required  Places emphasis on individuals, interactions, and delivering working software  Is both light and sufficient  Are incremental, cooperative, straightforward, and adaptive in nature