1.  Chapter 3 – Agile Software Development Chapter 3 Agile software development1

2. Agile Methods  Why?  Immediate business pressures  Requirements change  Reduce overhead of waterfall process  Incorporate user needs better  Rapid software development  Specification, design and implementation - inter-leaved  Development in versions  Stakeholders involved in each version Chapter 3 Agile software development2

3. Agile methods  Agile – general approach  Reduce overhead of software process  Respond quickly to change  Leverage knowledge of customer Chapter 3 Agile software development3

4. Examples  Implementations  Extreme Programming (XP)  SCRUM 1995  Adaptive Software Development  Feature Driven Software Development  Dynamic Systems Development 1995  Crystal Clear 1996 Chapter 3 Agile software development4

5. The Agile Manifesto  Agile methods -1990s  Agile Manifesto  2001  Group of developers  AgileManifesto.org Chapter 3 Agile software development5

6. The Agile Manifesto Introduction  “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” Chapter 3 Agile software development6

7. The principles of agile methods Chapter 3 Agile software development7 PrincipleDescription Customer involvementCustomers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental deliveryThe software is developed in increments with the customer specifying the requirements to be included in each increment. People not processThe skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace changeExpect the system requirements to change and so design the system to accommodate these changes. Maintain simplicityFocus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.

8. 12 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. Chapter 3 Agile software development8

9. 12 Principles (cont.)  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. Chapter 3 Agile software development9

10. 12 Principles (cont.)  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. Chapter 3 Agile software development10

11. Applicability  Product development - small or medium-sized product.  Custom development  commitment from the customer  Scaling up  difficult  Focus is on small, tightly-integrated teams. Chapter 3 Agile software development11

12. Issues With Agile Methods  Customer expertise  Customer time  Team member qualities  Prioritization - multiple stakeholders.  Refactoring  Contracts Chapter 3 Agile software development12

13. Issues  Most projects - combination of plan-driven and agile processes.  Formal spec required  Customer culture  Spec – detail needed?  Requirements  Design  Incremental delivery acceptable?  Team  Size  geographically dispersed Chapter 3 Agile software development13

14. Issues  Type of software  Real time systems – SCADA, embedded controllers  Incremental delivery may make no sense  Need for formal documentation  Many developers  Long term evolution  What technologies are available to support system development?  Agile methods rely on good tools to keep track of an evolving design Chapter 3 Agile software development14

15. Technical, human, organizational issues  Culture  Traditional engineering organizations.  How good are the designers and programmers in the development team?  Identifying requirements?  Identifying solutions?  Refactoring  External regulation?  Documentation needed.  FAA approval  Medical review Chapter 3 Agile software development15

16. Extreme programming  best-known, most widely used agile method  ‘extreme’ approach  New versions built several times per day;  Increments delivered every 2 weeks  All tests run on each build Chapter 3 Agile software development16

17. The extreme programming release cycle Chapter 3 Agile software development17

18. Extreme programming practices (a) Chapter 3 Agile software development18 Principle or practiceDescription Incremental planningRequirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’. See Figures 3.5 and 3.6. Small releasesThe minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple designEnough design is carried out to meet the current requirements and no more. Test-first developmentAn automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. RefactoringAll developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.

19. Extreme programming practices (b) Chapter 3 Agile software development19 Pair programmingDevelopers work in pairs, checking each other’s work and providing the support to always do a good job. Collective ownershipThe pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable paceLarge amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site customerA representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.

20. Requirements scenarios  In XP, a customer or user is part of the XP team and is responsible for making decisions on requirements.  User requirements  expressed as scenarios or user stories.  Stories broken down to tasks  Tasks are the basis of schedule and cost estimates.  customer chooses the stories  For each release  Their priorities Chapter 3 Agile software development20

21. A ‘prescribing medication’ story Chapter 3 Agile software development21

22. Examples of task cards for prescribing medication Chapter 3 Agile software development22

23. XP and change  Conventional wisdom:  design for change.  XP:  Changes cannot be reliably anticipated.  Refactor for changes. Chapter 3 Agile software development23

24. Refactoring  Refactoring – changing code to  Maintain the same functionality  Improve readability  Improve efficiency  Improve generality/reuse Chapter 3 Agile software development24

25. Refactoring Examples  Re-organization of a class hierarchy  remove duplicate code.  Consistent structure  Renaming attributes and methods  easier to understand.  Replacement of inline code with calls Chapter 3 Agile software development25

26. Testing in XP  Testing is  Essential  Done at every release  XP testing features:  Test-first development.  Incremental test development from scenarios.  User involvement in test development and validation.  Automated test harnesses  Run all component tests each time that a new release is built. Chapter 3 Agile software development26

27. Test-first development  Clarifies the requirements to be implemented.  Tests are written as programs  Automatic execution  Testing framework such as Junit.  Previous AND new tests are run  automatically  when new functionality is added,  Ensure that new functionality has not introduced errors. Chapter 3 Agile software development27

28. Customer involvement  Develop acceptance tests  Always part of team  Getting their time commitment can be a challenge. Chapter 3 Agile software development28

29. XP testing difficulties  Complete testing can be lengthy  Covering all cases  Interaction with the screens Chapter 3 Agile software development29

30. Test case description for dose checking Chapter 3 Agile software development30

31. Pair programming  Programmers work in pairs  Common ownership of code  Shared knowledge of code.  Informal code review.  Encourages refactoring  Results  Equal to two working separately  Maybe not for senior programmers Chapter 3 Agile software development31

32. Scrum  Agile approach  Focus on iterative process  Three phases  Outline general project objectives  Sprint cycles – developing part of the system  Closure  documentations  Help  Lessons learned Chapter 3 Agile software development32

33. The Scrum process Chapter 3 Agile software development33

34. The Sprint cycle  Fixed length, 2–4 weeks.  Product backlog - list of work to be done on the project.  The selection phase involves all of the project team who work with the customer to select the features and functionality to be developed during the sprint. Chapter 3 Agile software development34

35. Teamwork in Scrum  Scrum master - facilitator who  arranges daily meetings,  tracks the backlog of work to be done,  records decisions,  measures progress against the backlog  communicates with customers and management outside of the team.  Daily meetings  Whole team  Describe progress  Discuss issues  Discuss plans Chapter 3 Agile software development35

36. Scrum benefits  Project broken into manageable chunks  Entire team is well informed  History of delivery to customer becomes the basis of trust. Chapter 3 Agile software development36

37. Scaling agile methods  Suitable for small to medium sized projects  Suitable for co-located teams  Larger project broken into smaller teams  Possibly in separate locations Chapter 3 Agile software development37

38. Large systems development  Large systems  collections of separate, communicating systems,  separate teams develop each system.  teams are working in different places.  ‘brownfield systems’,  include and interact with a number of existing systems.  don’t really lend themselves to flexibility and incremental development. Chapter 3 Agile software development38

39. Large system development  Often constrained by external rules and regulations  limiting the way that they can be developed.  Long procurement and development time.  Difficult to maintain coherent teams who know about the system over long periods.  Diverse set of stakeholders.  Difficult to involve all of these different stakeholders in the development process. Chapter 3 Agile software development39

40. Scaling up to large systems  System wide refactoring can be a bigger issue.  Cross-team communication  phone and video conferences  short electronic meetings  Frequent integration  Daily is not feasible Chapter 3 Agile software development40

41. Scaling out to large companies  Challenge: Acceptance of a new approach.  Standards – quality and procedural  May conflict with agile development  Agile works best with high skill level  May not exist in large organization  Cultural resistance. Chapter 3 Agile software development41