Agile Development Processes - Informationsteknik

Links

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�

Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer�s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity �the art of maximizing the amount of work not done �is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, it tunes and adjusts its behavior accordingly.

Agile Methods

Scrum
eXtreme Programming (XP)
Crystal Methods
Agile Modeling
Adaptive Software Development (ASD)
Dynamic Solutions Delivery Model (DSDM)
Feature-Driven Development (FDD)
Lean Development
Agile Unified process (AUP)
Microsoft Solutions Framework (MSF4ASD)
Pragmatic Programming

0 - Introduction

[Big slides]

1 - Agile Software Development

[Big slides] [Slides with comments]

2 - eXtreme Programming

[Big slides] [Slides with comments]

Iteration duration: 1 to 3 weeks.

Typical release interval: 3 months.

Values

� Communication

� Feedback

� Simplicity

� Courage

� Respect

Principles

� Humanity

� Economics

� Mutual Benefit

� Self-Similarity

� Improvement

� Diversity

� Reflection

� Flow

� Opportunity

� Redundancy

� Failure

� Quality

� Baby steps

� Accepted Responsibility

Practices

Whole Team (Customer Team Member, on-site customer)

Everybody involved in the project works together as ONE team.
Everybody on the team works in the same room. (Open Workspace)
One member of this team is the customer, or the customer representative.

Small releases (Short cycles)

The software is frequently released and deployed to the customer.
The time for each release is planned ahead and are never allowed to slip. The functionality delivered with the release can however be changed right up to the end.
A typical XP project has a new release every 3 months.
Each release is then divided into 1-2 week iterations.

Continuous Integration

Daily build
- A working new version of the complete software is released internally every night.
Continuous build
- A new version of the complete software is build as soon as some functionality is added, removed or modified.

Test-Driven development (Testing)

No single line of code is ever written, without first writing a test that tests it.
All tests are written in a test framework like JUnit so they become fully automated.

Customer tests (Acceptance Tests, Testing)

The customer (or the one representing the customer) writes tests that verifies that the program fulfills his/her needs

Pair Programming

All program code is written by two programmers working together; a programming pair.
Working in this manner has a number of positive effects:
- Better code quality
- Fun way of working
- Information spreading
- Skills spreading
- Implicit code review

Collective Code Ownership

All programmers are responsible for all code.
You can change any code you like, and the minute you check in your code somebody else can change it.
You should not take pride in and responsibility for the quality of the code you written yourself but rather for the complete program.

Coding standards

In order to have a code base that is readable and understandable by everybody the team should use the same coding style.

Sustainable Pace (40-hour week)

Work pace should be constant throughout the project and at such a level that people do not drain their energy reserves.
Overtime is not allowed two weeks in a row.

The Planning Game

Simple Design

Never have a more complex design than is needed for the current state of the implementation.
Make design decisions when you have to, not up front.

Design Improvement (Refactoring)

Always try to find ways of improving the design
Since design is not made up front it needs constant attention in order to not end up with a program looking like a snake pit.
Strive for minimal, simple, comprehensive code.

Metaphor

Try to find one or a few metaphors for your program.
The metaphors should aid in communicating design decisions and intends.
The most well known software metaphor is the desktop metaphor.

3 - Vivace

[No slides]

4 - The Planning Game

[Big slides] [Slides with comments]

Planning is done in order to determine what to do, when to do it, and by whom.

The planning game gives a list of tasks that is to be done in the coming iteration.

1. Meeting with the customer

Help the customer formulate what he wants the program to do.
Typically the customer and one or two developers

2. Prioritizing user stories

Have the client order the user stories roughly in order of importance.
Assign to e.g. three categorize:
- �essential, to be done first�
- �needed, but not top priority�
- �only if there is time�

3. Iteration Planning meeting

The customer or the customers representative presents and explains the (top priority) user stories.
Discuss the user stories and resolve uncertainties.
- If the customer is not present take notes on uncertainties and categorize them on whether they affect planning or implementation.

4. Estimating user stories work effort

Estimate relative work effort of user stories.
Estimate each story�s work effort in IT (ideal time).
Use 1 IT = 1 hour.
Never assume an order of implementation. Estimate the time for each story in isolation.

5. Determine available time

Determine available units of time in iteration
Use yesterdays weather
- Assume you will implement as many IT:s worth of user stories as you did last week.
Count only finished stories.
Take known differences to last week into account.

6. Choose stories for current iteration

Given the estimated user stories and the available time, the customer choose the stories for the current iteration.

7. Break stories into tasks

Break the chosen User stories into Programming Tasks
A Programming Task is a task that needs to be done in order to implement a story. A task does not need to be understandable to the customer but is there to help the programmers in planning their work. E.g:
- Update database
- Construct GUI
- Extend the Engine package with needed functionality
Avoid making unnecessary design decisions when formulating tasks.

8. Assign tasks to programmers

All programmers that are interested in doing a task estimate how long it will take them.
The one with the lowest estimate �wins the bid� and gets to do the task.
No programmer can sign up for more time than his velocity.
Update the estimated time for each US with the sum of its tasks.
If not all tasks fit in the iteration or if there is extra time have the customer remove or add user stories.

Programmer velocity

The amount of ideal time that each programmer can commit to work.
Equals the amount of time used on finished tasks last iteration (yesterdays weather).
- Modify if circumstances differs.
Should be prepared by tracker prior to meeting.

Technical tasks

On all projects there are purely technical tasks that the customer don�t care about that needs to done.

A Technical task can be:

Upgrading development tools
Large Refactorings
Evaluating frameworks

Use a story card for documenting tasks that need to be done.

5 - Test Driven Development

[Big slides] [Slides with comments]

Unit testing

By developers for developers
white box testing. You have the code and you know how to break it.
Small pieces of code are tested separately

Acceptance tests

For the customer, in order to show that you built what your customer asked you to build.
Black box testing. You are testing the system without knowledge of the code. The way a user would test and use it.
Acceptance tests test the overall design of the system.

How - 7 steps to happiness

1. Baby steps! Think of the next little thing you wish to do. Small steps provide a good opportunity to figure out what you want to solve for the moment.

2. How will you test that the little thing above really works? � Representative testing: Some values that should work and some values that shouldn�t. Add to that some special values, such as division with zero, border values and such. You don�t need to test more than one or two of each.

3. Write the test code, it won�t compile (if it does, you�re doing something wrong since the methods you are about to test do not exist yet.)

4. Write enough code to make the test compile but not pass the test. Remember � baby steps!

5. The test fails (if it doesn�t you�re doing something wrong)

6. Write just enough code to pass the test. Don�t think of future iterations, or what might be fun for you or the customer.

7. What is the next little thing to do? Back to 1.

When the code gets too ugly, refactor. The best time for this is after all test have been run.

Final advice

Test just enough. Don�t test more than you have to.

Do not do more at any step than you need. Don�t plan for possible customer whishes in the upcoming iterations since you don't know what your customer thinks is important.

The tests should not be more complicated than the code. If the test demands 6 LOC and the method is only 2 LOC, leave it alone.

Keep it simple! Simple tests are easier to write correctly.

Test Coverage

Different types of tests

Unit test
Integration test
Regression test
Function test
Full scale test
Stress test
Negativ test
Ergonomic test
User manual test
Acceptance test

6 - Agile Processes

[Big slides] [Slides with comments]

XP for small projects, hard to communicate otherwise. XP cannot be used when building saftey critical systems.

6.1 - Crystal Methods

Different methods depending on project size. People are different and need different ways of working effective. Divide the methods into groups depending on number of team members. More team members need more control over the project. Important feautres: frequent delivery, reflective improvement and close communication.

Ju n�rmare �vre h�gra h�rnet i ett [Cockburn-diagram] ett projekt klassificeras, desto mer formell process kr�vs. G�llande Crystal-metoderna inneb�r ordet formell bl.a.:

� Mer dokumentation

� Mer specialiserade roller

� Mer koordination

� Mer gruppindelning

� Mer kvalitetss�kring (QA)

S� man kan nog resonera som s� att ju mer �t Crystal-red-h�llet, desto mer av ovanst�ende punkter inneh�ller processen :-)

6.1.1 - Crystal Clear (2-6)

Less productive than XP, however easier to follow than XP. More individuallity within the team which though might lead to less productivity. Easier to adopt by team members, however XP produces better result if it can be followed correctly. Team can "upgrade" from Crystal Clear to XP. A failing team in XP can fall back on Crystal Clear.

6.1.2 - Crystal Yellow (6-20)

6.1.3 - Crystal Orange (20-40)

More specialized roles in different teams. Developers are split into small groups containing needed specialists. More work around the product, more documentation though still relies on face-to-face communication.

6.1.4 - Crystal Red (/ Magneta / Blue / ...)

Not defined yet, however should include more QA and team coordination activities/roles.

6.2 - Dynamic Solutions Delivery Model

Independent method _framework_, can be used with other methods (e.g. XP/RUP). Manager view point. Skeleton on how project should be handled on superior level, less technical details (such as XP). E.g. DSDM is for managers/project leaders, XP is for developers. XP/RUP may be used to describe the details of the model. Earlier work steps may be revisited, only have to complete a step enough to move on (requirements may change anyway so one must not complete each step fully).

Active user involvement is imperative
DSDM teams must be empowered to make decisions
The focus is on frequent delivery of products
Fitness for business purpose is the essential criterion for *acceptance of deliverables
Iterative and incremental development is necessary to converge on *an accurate business solution
All changes during development are reversible
Requirements are base lined at a high level
Testing is integrated throughout the lifecycle
A collaborative and co-operative approach between all stakeholders is essential

Time boxing

The mechanism for handling flexibility of requirements in DSDM is the time box. In any project, there is a fixed completion date, which provides an overall time box for the work to be carried out. DSDM refines the concept of time boxing by nesting shorter time boxes of two to six weeks within the overall time frame. Time boxes can overlap in time and be carried out by different teams.

Each time box will typically pass through three phases.

Investigation - a quick pass to see whether the team is taking the right direction
Refinement - to build on the comments resulting from the review at the end of investigation
Consolidation - the final part of the time box to tie up any loose ends

MoSCoW? rulez!

Must Haves; fundamental to the projects success
o
Should Haves; important but the projects success does not rely on these
Could Haves; can easily be left out without impacting on the project
o
Won't Have this time round; can be left out this time and done at a later date

6.3 - Adaptive Software Development

ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. The process is supported by a host of techniques but none are mandatory.

Being able to adapt is considered more crucial than being able to optimize.
The ideas behind ASD are build on the Complex Adaptive Systems (CAS) theory.

Two strategies:

Less focus on process, more on product. Managers must apply rigor to the results of the process rather than prescribing the process.
Fostering self organization across virtual teams. Virtual teams are teams that are distributed around the world. Only needed if ASD is applied to large-scale software development.

Iterative Development with three phases:

Speculation: on the product means the discussion and subsequent definition of what is to be achieved in an iteration.
Collaboration: Phase in which team members collaborate towards a product that incorporates the features as suggested from the speculation phase and from the on-going external input.
Learning: Final phase of an iteration, the result is reviewed in light of the speculation and the next iteration is being prepared.

6.4 - Feautre Driven Development

6.4.1 - None Agile Feautres

Model driven
Distinct project phases
Individual code ownership
Progress tracking
Inspections

6.4.2 - Agile Feautres

Strong focus on customer needs
Short iterations
People-centric
Reduced documentation
Dynamically formed teams

6.4.3 - Project Phases

1. Develop an overall model (domain model)

2. Build a feature list (small use cases (<action> <result> <object>))

3. Plan by feature - Divide features into different sets and assign to chief programmers.

4. Design by feature - Chief programmer selects group of features to design/implement. Perform design inspection until design is complete and accepted.

5. Build by feature - Implement. Done when unit tests and code inspections pass.

Agile Modeling

AM is an agile approach to modeling
- It consists of a number of principles and practices stating how design should be produced and documented in an agile environment.
AM works well with XP giving guidance on when and how to design, while still not stating that the whiteboard is no good as a document.
It can also be applied to processes with rigor documentation, adding agility by allowing the documents to be produced only when needed, and just in time.

AM Principles

Model with a purpose
Maximize stakeholder return of investment
Travel light
Multiple Models
Rapid Feedback
Assume Simplicity
Embrace Change
Incremental Change
Quality Work
Software is your primary goal
Enabling the next effort is your secondary goal

AM Practises

Active Stakeholder participation
Model with others
Apply the right artifact(s)
Iterate to another artifact
Prove it with code
Use the simplest tool
Model in small increments
Single source information
Collective ownership
Create several models in parallel
Create simple content
Depict models simply
Display models publicly

7 - Scrum

[Big slides] [Slides with comments]

Scrum Master: Glue between project team and management. Fixes obstacles. Enforces Scrum practices. Team is self driven. Manager makes sure project is on track.

Product owner: Scrum has a product owner that is a single person who is the only one that decides what should be on the backlog and how it should be prioritized. A stakeholder that wants to have a feature must convince the product owner that it is needed instead of bothering the development team.

Back Log: List of everything interesting in the project; feautres, funcitons, technologies, enhancements and bug fixes. Prioritized. Dynamic document. Document owner decides what to do from the document. Includes time estimations.

Teams: Picks work items from back log each iteration. Self organizing, has free hands. About 7 members, experts in different fields, more does not usually work efficiently. Team members are title-less, it is the responsibility of all members to make the project progress.

Meetings: Daily meetings � 15 min. Used to report status. If discussions are needed, follow-up meeting is scheduled. Only team members allowed to talk.

Sprint: An iteration in Scrum, usually 30 days. Not allowed to change the features to implement during a sprint, if customer changes his mind, the changes can take effect at next sprint. Sill close cooperation with customer, though not allowed to change user stories as in XP. Sprint goal defined to convert back log into deliverable.

Sprint planning meeting: The sprint is planned during two meetings. At the first meeting, the team meets with the product owner, management, and users to figure out what functionality to build during the next Sprint. At the second meeting, the team works by itself to figure out how it is going to build this functionality into a product increment during the Sprint. Items from the product backlog is chosen and a sprint goal is defined. The tasks needed to complete the chosen items are listed in a sprint backlog.

Sprint Review Meeting: 4h review at the end of each sprint. Present what has been done to customers, managers and product owner. Actual result is comparison of back log and sprint goal.