1. Engineering Bernd Fischer bfischer@cs.sun.ac.za RW344: Software Design ▬ ▬ ▬▬ ▬ ▬

2. Agile Methods

3. Iterative Development The essence of iterative software processes is that specification and software are developed together. This contrasts with approaches where requirements specifications are part of the system development contract. Each iteration is a self-contained mini-project that repeats some or all of the software activities. This is basically the waterfall method with a feedback loop back to the first step. The goal of each iteration is a release, a partially complete system that is stable, integrated, and tested. All software across all teams is integrated into a release at the end of each iteration. Releases are sometimes internal, and not released to the users.

4. Incremental Development Incremental development is a kind of iterative development where users are exposed to releases. Rather than deliver the system as a single package, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and those with the highest priority are included in early releases. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

5. Pros & Cons of iterative/incremental Advantages Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Greater user involvement during development. The highest priority system services tend to receive most testing. Lower risk of overall project failure. Disadvantages Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done. The normal contract may include a specification; without a specification, different forms of contract have to be used. Without a specification, what is the system being tested against? Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements.

6. Agile Software Development Dissatisfaction with the overheads involved in design methods led to the creation of agile methods that: focus on the code rather than the design are based on an iterative development approach are intended to deliver working software quickly and evolve this quickly to meet changing requirements Examples Scrum (1995) Crystal Clear (2004) Extreme Programming (1996) Adaptive Software Development (2000) Feature Driven Development (1997) Dynamic Systems Development Method (1995)

7. Agile Software Development Agile software development is based on the philosophy that modern business requirements change quickly and frequently and the software process must adapt. Agile Manifesto: 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.” 7

8. Agile Principles Customer involvement: The customer should be closely involved throughout the development process. They provide and prioritise new system requirements and evaluate the iterations of the system. Incremental delivery: The software is developed in increments with the customer specifying the requirements to be included in each increment. People not process: The skills of the development team should be recognised and exploited. The team should be left to develop their own ways of working without prescriptive processes.

9. Agile Principles (2) Embrace change: Expect the system requirements to change and design the system so that it can accommodate these changes. Maintain simplicity: Focus on simplicity in both the software being developed and in the development process used. Wherever possible, actively work to eliminate complexity from the system.

10. Extreme Programming (XP) Created by Kent Beck during his work at Chrysler. –Book: Extreme Programming Explained, 1999. Basic idea: take some “best practices” from software development, push them to the extreme, ignore (almost) everything else. –Some of these best practices date back to the 60’s. XP values: Communication Simplicity Feedback Courage Respect

11. XP Practices Fine scale feedback Continuous process Shared understanding Programmer welfare Coding Testing

12. XP Practices - Fine scale feedback Pair programming –Developers work in pairs, checking each others work and providing the support to always do a good job. Planning game –Requirements 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. Test-driven development

13. XP Practices - Continuous process Continuous integration –As soon as 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. Refactoring or design improvement –All developers should refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable. Small releases –The 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.

14. XP Practices - Shared understanding Coding standards Collective code ownership –The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything. Simple design –Enough design is carried out to meet the current requirements and no more.

15. XP Practices - Programmer welfare Sustainable pace, No Overtime –Large amounts of over-time are not considered acceptable as the net effect is often to reduce code quality and medium term productivity

16. XP Practices – Coding The customer is always available –A representative of the end-user of the system should be available full time for the use of the XP team. Code the unit test first –An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Only one pair integrates code at a time Leave Optimization till last

17. XP Practices – Testing All code must have unit tests All code must pass all unit tests before it can be released. When a bug is found tests are created before the bug is addressed –a bug is not an error in logic, it is a test you forgot to write Acceptance tests are run often and the results are published

18. Scrum Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). The business sets the priorities. Teams self- organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

19. Scrum

20. Sprints Scrum projects make progress in a series of sprints –analogous to XP iterations Typical duration is 2-4 weeks –maximal calendar month A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint No changes during a sprint –Plan sprint durations around how long you can commit to keeping change out of the sprint

21. Scrum framework Product owner ScrumMaster Team Roles Sprint planning Sprint review Sprint retrospective Daily scrum meeting Ceremonies Product backlog Sprint backlog Burndown charts Artifacts

22. People Product Owner Define the features of the product Decide on release date and content Be responsible for the profitability of the product Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results Scrum Master Represents management to the project Responsible for enacting Scrum values and practices Removes impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences Team ( typically 5-9 people) Cross-functional: Programmers, testers, user experience designers, etc. Members should be full-time (exceptions for e.g., database administrator)

23. Sprint planning Team selects items from the product backlog they can commit to completing Sprint backlog is created –tasks identified and effort estimated (1-16 hours) –collaboratively, not done alone by the ScrumMaster High-level design is considered As a vacation planner, I want to see photos of the hotels. Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)

24. The daily scrum Parameters –daily –15-minutes –stand-up Not for problem solving –whole world is invited –only team members, ScrumMaster, product owner, can talk Helps avoid other unnecessary meetings

25. Everyone answers 3 questions These are not status updates for the ScrumMaster –they are commitments in front of peers What did you do yesterday? 1 1 What will you do today? 2 2 Is anything in your way? 3 3

26. Sprint review Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal –2-hour prep time rule –No slides Whole team participates Invite the world

27. Sprint retrospective Take a look at what is and is not working Typically 15–30 minutes Done after every sprint Whole team participates –ScrumMaster –Product owner –Team –Possibly customers and others

28. Managing the sprint backlog Individuals sign up for work of their own choosing –Work is never assigned Estimated work remaining is updated daily Any team member can add, delete or change the sprint backlog Work for the sprint emerges If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Update work remaining as more becomes known

29. Burndown Chart Hours 40 30 20 10 0 MonTueWedThuFri Tasks Code the UI Code the middle tier Test the middle tier Write online help Mon 8 16 8 12 Tues Wed Thur Fri 4 12 16 7 11 8 10 168 50

30. The Real Value of Agile Iterations with predictions as to required effort, allows one to better predict future effort Iterations allow more fine-grained profiling of the process and therefore one can more quickly see whether something is going wrong Most organizations find a workable implementation of Scrum for them –Even though the evangelists would say all or nothing