Engineering

Bernd Fischerbfischer@cs.sun.ac.za

RW344: Software Design▬ ▬ ▬

Agile Methods

Iterative Development

• The essence of iterative softwareprocesses is that specification andsoftware are developed together.

• This contrasts with approacheswhere requirements specificationsare part of the system developmentcontract.

• 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.

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.

Pros & Cons of iterative/incrementalAdvantages• 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.

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)

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

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.

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.

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

XP Practices

• Fine scale feedback• Continuous process• Shared understanding• Programmer welfare• Coding• Testing

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

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.

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.

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

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

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

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.

Scrum

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

Scrum framework

•Product owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts

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)

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)

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

Everyone answers 3 questions

• These are not status updates for the ScrumMaster– they are commitments in front of peers

What did you do yesterday?11

What will you do today?22

Is anything in your way?33

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

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

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

Burndown Chart

Hou

rs

40

30

20

100 Mon Tue Wed Thu Fri

TasksTasksCode the UICode the middle tierTest the middle tierWrite online help

MonMon8

168

12

TuesTuesWedWed ThurThurFriFri4

1216

711

81016 8

50

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