agile software development - making programming fun again
TRANSCRIPT
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.