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

S

Chapter 3 – Agile Software

Development

Chapter 3 Agile software development1

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


Agile methods

Agile – general approach Reduce overhead of software process Respond quickly to change Leverage knowledge of customer


Examples

Implementations Extreme Programming (XP) SCRUM 1995 Adaptive Software Development Feature Driven Software Development Dynamic Systems Development 1995 Crystal Clear 1996


The Agile Manifesto

Agile methods -1990s

Agile Manifesto 2001 Group of developers

AgileManifesto.org


The Agile ManifestoIntroduction

“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”


The principles of agile methods


Principle Description

Customer involvement Customers 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 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 recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and so design the system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.

12 Principles

Our highest priority is to satisfy the customerthrough early and continuous deliveryof 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.


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.


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.


Applicability

Product development - small or medium-sized product.

Custom development commitment from the customer

Scaling up difficult Focus is on small, tightly-integrated teams.


Issues With Agile Methods

Customer expertise

Customer time

Team member qualities

Prioritization - multiple stakeholders.

Refactoring

Contracts


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


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


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


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


The extreme programming release cycle


Extreme programming practices (a)


Principle or practice Description

Incremental planning 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’. See Figures 3.5 and 3.6.

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.

Simple design Enough design is carried out to meet the current requirements and no more.

Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.

Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.

Extreme programming practices (b)


Pair programming Developers work in pairs, checking each other’s work and providing the support to always do a good job.

Collective ownership The 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 pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity

On-site customer A 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.

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


A ‘prescribing medication’ story


Examples of task cards for prescribing medication


XP and change

Conventional wisdom: design for change.

XP: Changes cannot be reliably anticipated. Refactor for changes.


Refactoring

Refactoring – changing code to Maintain the same functionality Improve readability Improve efficiency Improve generality/reuse


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


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.


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.


Customer involvement

Develop acceptance tests

Always part of team

Getting their time commitment can be a challenge.


XP testing difficulties

Complete testing can be lengthy

Covering all cases

Interaction with the screens


Test case description for dose checking


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


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


The Scrum process


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.


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


Scrum benefits

Project broken into manageable chunks

Entire team is well informed

History of delivery to customer becomes the basis of trust.


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


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.


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.


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


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 Development Chapter 3 Agile software development1.

Documents

Transcript of Chapter 3 – Agile Software Development Chapter 3 Agile software development1.