1 the new (agile) methodology martin fowler chief scientist, thoughtworks
TRANSCRIPT
1
The New (Agile) Methodology
Martin FowlerChief Scientist, ThoughtWorks
www.martinfowler.com/articles/newMethodology.html
2
Code and Fix
» Still the most popular approach» Development builds features
– Little control over schedule– Frequent changes of requirements
» Painful test and integration– Hard to say when it ends
3
Methodology
» Bringing Engineering Discipline to software– Break projects down into stages– Control changes to requirements– Documentation
4
Is Methodology Considered Harmful?
» Bureaucracy– Lots of “pretty pictures”, but nothing that
works– Harder to change documentation
» Rigidity– Cannot change when need to– Deliver what customer asked for, but not
what customer needs.– Difficult to tune for specific project – even
with tailoring
5
Agile Methodologies
» New breed of methodologies that have discipline without bureaucracy
» E.g.: – XP (Extreme Programming)– Crystal / Highsmith ASD– Feature Driven Development– SCRUM– DSDM
6
A Meeting at Snowbird
» Alistair Cockburn» Jim Highsmith
» Kent Beck» Ward Cunningham» James Grenning» Ron Jeffries» Robert Martin
» Jon Kern
» Mike Beedle» Ken Schwaber» Jeff Sutherland
» Arie van Bennekum
» Andrew Hunt» Dave Thomas» Brian Marick» Steve Mellor» Martin Fowler
7
Agile Manifesto
Individuals and Interactions
over Process and Tools
Working Software
over Comprehensive Documents
Customer Collaboration
over Contract Negotiation
Responding to Change
over Following a Plan
We Value:
www.agileAlliance.org
8
Warning
» Agile methods are not for all projects– Still very new– Boundaries are not yet understood
» There’s a lot of zealotry about– Both positive and negative
9
What makes “light” right?
» Most people focus on “light”– i.e.: lack of documents and the processes
that create them» We think the priorities are
– Adaptivity– vs. predictivity
– People orientation– vs. process-orientation
10
The Engineering Metaphor
» Figure out what you need– Understand, stabilize, and sign off
requirements» Produced a detailed design
– UML or similar» Hand off to Construction
– Programming
11
Requirements Engineering
Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when you client starts using your product, is so expensive and so inefficient, that we will assume that no right-thinking person would do it, and will not mention it again.
Robertson and Robertson, Mastering the Requirements Process
12
Adaptivity
» Requirements aren’t stable– “Welcome changing requirements, even late
in development. Agile processes harness change for the customer's competitive advantage.”
13
Controlling Adaptivity: Iterations
AnalysisAnalysis DesignDesign CodingCoding TestingTesting
DD
AA CC
TT
DD
AA CC
TT
DD
AA CC
TT
14
Agile Iterations
» Delivering software is a key feedback mechanism– “Working software is the primary measure of
progress”» Short iterations and frequent delivery
– “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”
» Long term plans are fluid– “Welcome changing requirements, even late in
development. Agile processes harness change for the customer's competitive advantage”
15
The Agile Customer
» Agile development does not fit well with fixed-price / fixed scope– “Business people and developers must work
together daily throughout the project”» Customer needs to steer project
– Must be closely involved– Responsible for success or failure
16
People First
» Software is built by people: not by Plug Compatible Programming Units
» The methodology must fit your people, not vice-versa
» The people doing the work figure out how to do it best– “Build projects around motivated
individuals. Give them the environment and support they need, and trust them to get the job done”
17
Self-Adaptive Process
» The process you start with shouldn’t be the one you finish with
» Review process regularly» Everyone is involved in evolution
18
Principles (1)
» Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
» Working software is the primary measure of progress
» Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
19
Principles (2)
» Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
» Business people and developers must work together daily throughout the project.
» The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
20
Principles (3)
» Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
» Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
» The best architectures, requirements, and designs emerge from self-organizing teams.
21
Principles (4)
» Continuous attention to technical excellence and good design enhances agility.
» Simplicity--the art of maximizing the amount of work not done--is essential.
» At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
22
XP (Extreme Programming)
» Developed by Kent Beck– Based on Smalltalk projects in the 90’s– Collaboration with Ward Cunningham
» First “done” on C3– Smalltalk Payroll system for Chrysler
» Now an informal community– Ron Jeffries, Robert Martin, Chet
Hendrickson, Jim Newkirk, Don Wells, Ken Auer, Bill Wake…
23
XP Practices
Metaphor
CollectiveOwnership
CodingStandard
40 HourWeek
ContinuousIntegration
On-SiteCustomer
Planning Game
Acceptance Tests
SimpleDesign
PairProgramming
Test-First Design
Refactoring
Small Releases
The Jeffries Model
24
XP Values
» Communication– Rich informal networks of communication
» Feedback– Build in a rich set of feedback loops so we
know where we are» Simplicity
– Try the simplest things that could possibly work
» Courage– Play to win
25
Balance of PowerCustomer» Itemize “stories”
(features) of useful function
» Decide on business value of stories
» Prioritizes stories » Defines acceptance
tests for stories» Can change plan at
any time
Programmers» Provides estimates for
stories» Builds the function » Maintains high quality
at all times» Sustainable pace
Business people make business decisionsTechnical people make technical decisions
26
Boundary Conditions
» Size– Up to 20 developers
» Location– Co-located team
» Requirements– Volatile or not well understood
» Acceptance– All involved must want to use it
27
SCRUM
» Developed by several people in the patterns community– Mike Beedle, Martine Devos, Yonat Sharon,
Ken Schwaber, Jeff Sutherland» Planning process based around short
agile iterations– Scrummers often use XP’s
design/development practices
28
SCRUM’s Sprints
» Scrum iterations are called sprints– Usually around 30 days
» During sprint requirements are fixed for that sprint
» Produces working software with Demo at end
» Team chooses appropriate process for sprint
29
SCRUM: Backlog
» Prioritized list of work items» Backlog may change continuously» Only one person controls backlog» Sprint team selects items from backlog to
do in next sprint– Sprint team chooses what it thinks it can
achieve in collaboration with backlog manager
» Multiple sprint teams may work off one backlog
30
SCRUM meetings
» Short Daily Meeting– ~15 minutes
» Whole sprint team attends, plus outsiders– Pigs and Chickens
» Topics– What did you do since last scrum?– What are your blocks?– What will you be doing in next 24 hours?
31
Highsmith / Cockburn
» Recent union of two methodologists» Alistair Cockburn
– Crystal Family» Jim Highsmith
– Adaptive Software Development
32
Crystal Family
People
Comfort
Essentialmoney
Life
1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000
C6 C20 C40 C100 C200 C500 C1000
D6 D20 D40 D100 D200 D50 D1000
E6 E20 E40 E100 E200 E500 E1000
L6 L20 L40 L100 L200 L500 L1000
Discretionarymoney
Cri
ticality
Family of Methodologies tuned to team size and criticality
33
The Tolerant Crystal
» Observing Methodology Use– The people on the projects were not interested in
learning our system. – They were successfully able to ignore us, and were
still delivering software, anyway» Strong People Orientation
– People are communicating beings, doing best face-to-face.
– People have trouble acting consistently over time. – People are highly variable.– People generally want to be good citizens.
What is the sloppiest methodology that could work?
34
Shrink to Fit
» At project start team chooses its own methodology following Crystal guidelines– Talk to people about previous projects, and
company culture» Review process at end of every iteration
– What’s working?– What can we do better?– What puzzles us?– Also review mid way if more than 3 weeks
35
Highsmith’s ASD
» ASD = Adaptive Software Development» Primarily a philosophy underpinning agile
development approaches» Adaptive Cycle
– Speculate– Collaborate– Learn
36
Feature Driven Development
» Developed by Peter Coad and Jeff de Luca at TogetherSoft
37
FDD: Five Processes
» Initial Processes– Develop an Overall Model – Build a Features List – Plan by Feature
» Iterative Processes– Design by Feature – Build by Feature
38
FDD: Team Organization
» Multiple Teams– Features assigned to chief programmer
» Chief Programmer– Responsible for overall design of feature– Gathers class owners to work on feature– Coordinates and mentors class owners
» Class Owners– Work on particular classes
39
DSDM
» Dynamic Systems Development Method» Originated in the UK
– Consortium of end user and IT development organizations
– Spreading across Europe and into the US» Many ‘serious’ methodology trappings
– Detailed manuals– Accreditation and training
40
DSDM: Basic processes
» Feasibility and Business Study» Functional Model Iteration
– Modeling and prototyping» Design and Build Iteration
– Evolutionary build with integrated testing» Implementation
– Handover from development to operations» Each process is one or more iteration
– Up to six weeks in length– Carry out in any order
41
RUP ?
» Rational Unified Process– Developed by Rational Software led by
Philippe Kruchten– Really a process framework
» Large Process– Many artifacts and roles– Process and tool oriented
» Needs a lot of trimming to be agile– Robert Martin: dX– Craig Larman: Agile UP
42
Final Thoughts
» New Breed of Methodology» Suited for some kinds of software
development– Volatile environments
» Early days– Boundary conditions not well understood
» More in common than differences– Lots of inter-method borrowing