agile software development - making programming fun again

Slide 1

making programming fun again

Agile Software Development

How Projects Really Work

How the customer explained it

How the project leader understood it

How the analyst designed it

How the programmer wrote it

How the business consultant described it

How the project was documented

How much the project cost

What the customer really needed

CHAOS Report by Standish Group

Challenged Projects - Reasons

Lack of User Input

Incomplete Requirements & Specifications

Changing Requirements & Specifications

Lack of Executive Support

Technology Incompetence

Lack of Resources

Unrealistic Expectations

Unclear Objectives

Unrealistic Time Frames

New Technology

Failed Projects - Reasons

Incomplete Requirements

Lack of User Involvement

Lack of Resources

Unrealistic Expectations

Lack of Executive Support

Changing Requirements & Specifications

Lack of Planning

Didn't Need It Any Longer

Lack of IT Management

Technology Illiteracy

Successful Projects - Reasons

User involvement

Executive management support

Clear business objectives

Optimizing scope

Agile process

Project manager expertise

Financial management

Skilled resources

Formal methodology

Standard tools and methodology

What's wrong with Waterfall?

What's wrong with Waterfall?

Mistakes are hard to find in early stages

Expensive to fix mistakes in later stages

Customers don't know what they want from the beginning

Developers don't know how long a project will take from the beginning

Business needs change

Effects of Waterfall

Death March projects

Mis-estimated schedules lead to successive overtime

Delays in one stage cause delays in succeeding stages

Conflict between customers and developers

Customers don't get the software that they want

Developers don't get clear requirements

Process and tool obsession

People focus on creating artifacts but lose sight of the goal of working software

Processes replace natural communication

The Agile Manifesto

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

That is, while there is value in the items on the right, we value the items on the left more.

Selected Practices

Iterative Development

User Stories

Test-Driven Development

One Team

Self-Managed Teams

Sustainable Pace

Iterative Development

Software development as an evolutionary process

Iterative Development

All steps of SDLC are done at each iteration

Iterative Development

Working software produced at each iteration

No such thing as X% complete, only done and not done

Iterative Development

Benefits

Customers can evaluate what they want and adjust requirements

Developers get better estimates of future tasks

Better communication between customer and developers and among developers

Talk is about something concrete, not abstract

Just enough artifacts are created to produce working software

Less waste

User Stories

Traditional requirements: The system shall... the system shall...

User Stories

As a < user role >In order to < business goal >I want to < behavior >

Focus on business goals

- Requirements have context

Story-telling is the most natural way of communication

Test-Driven Development

Bugs are harder to find and fix when found later

Modifying code tends to introduce bugs

- Difficult to know if one has introduced bugs without tests

Manual tests are expensive to repeat and provide limited information

Test-Driven Development

Programmers should write automated tests as they code

- Write test before implementation

Provides immediate feedback if their code works

Builds suite of automated tests that can be run each time code is modified

Makes it safe to modify existing code

Frameworks: JUnit, NUnit, hundreds of others...

TDD Benefits

Code is safe to modify

Tests are excellent documentation

- Programmers hate writing documentation, but they like to code

Design improves

- Programmers think of their code's behavior before coding- Programmers see their code from a second-person's point-of-view

Is my code readable? Easy to use?

- Components become decoupled to facilitate testing

One Team

Everyone is considered part of one team, including the customer

Developers, testers, business analysts, project managers, web designers, etc, work in the same place, usually on the same table

One Team

Faster communication

Issues resolved faster

Natural communication

Face-to-face, ad hoc and continuous throughout the day

Less misunderstanding and antagonism between functional groups

Self-Managed Teams

When teams manage themselves...

Higher motivation

More creative solutions

Faster resolution of issues

Drive for continuous improvement

Self-Managed Teams

Practices/Tools

Daily Stand-Up Meetings

Retrospectives

Big Visible Charts, Whiteboards

Direct access to customers

Sustainable Pace

Overtime leads to lower productivity

Lowers morale

Sustainable Pace

Team should measure velocity at each iteration

Keep work load within velocity

If iteration load was underestimated, ask customer to decide which features to move to future iterations

Other Practices...

Planning

Tracking

Continuous Integration

Pair Programming

Refactoring

Planning Boards

Burn-Down Charts

Collective Code Ownership

Coding Standards

Many more...

Agile at Orange & Bronze

Been doing Agile since its foundation in 2005

Before it became mainstream

We've tried different methodologies and practices

XP, Scrum, Kanban

Not all practices work in all conditions

The first to offer training in Agile methodologies and practices

Scrum, TDD, Agile Business Analysis, Agile QA, etc

Trainers are seasoned practictioners

Open Workspaces

Project Automation

Collaborative Design

Agile Training

Software engineering done right.

Software engineering done right.

Software engineering done right.