the crystal family of methodologies for software development
DESCRIPTION
The Crystal Family of Methodologies for Software Development. Alistair Cockburn http://alistair.cockburn.us. History 1991 - 2004. 1991: Alistair Cockburn (pronounced Co-burn) wanted to develop an effective software development methodology. - PowerPoint PPT PresentationTRANSCRIPT
©Alistair Cockburn 2003-2005 Slide 1
Alistair Cockburnhttp://alistair.cockburn.us
The Crystal FamilyThe Crystal Familyof Methodologiesof Methodologies
for for Software DevelopmentSoftware Development
©Alistair Cockburn 2003-2005 Slide 2
History 1991 - 2004
1991: Alistair Cockburn (pronounced Co-burn) wanted to develop an effective software development methodology.
He interviewed and studied project teams for 10 years.
He found that “people-centric methodologies” do better than “process-centric” methodologies.
He found that you must choose and tailor the methodology to the team and the assignment (cannot have 1 methodology design for all projects).
1994: “Orange” used on 45-person fixed-price project1997: “Orange” published in Surviving OO Projects1998: Family of methodologies the name “Crystal”2004: “Crystal Clear” published as book
©Alistair Cockburn 2003-2005 Slide 3
What were the most common characteristics of successful projects?
• People sit close together• They communicate frequently and with good will• The eliminate bureaucracy and let them design• They get a real user directly involved• They have good automated regression tests• THey produce shippable functionality early and often
A good methodology (family) must prioritize for these!
©Alistair Cockburn 2003-2005 Slide 4
‘Methodology’ is only the set of conventions people agree to follow -- it changes every few months!
As the people on the team change, the conventions of the team change, also.
As the project evolves from start to middle to end, the strategies and conventions change, also.
The methodology of the team needs to change along with the situation.
This is natural is we view the methodology only as the conventions the team uses, and nothing more!
(Most people try to use ‘methodology’ as required development technique and also project management -- this is too much burden to place on a methodology)
©Alistair Cockburn 2003-2005 Slide 5
Crystal is the lightest, least intrusive set of rules that puts a project in the safety zone.
Crystal’s purpose: Keep people from hurting each other, keeping each other informed
Crystal’s nature: A set of conventions that gets updated
Crystal’s Philosophy: People differ in working styles Projects differ in needs Software development is communication-intensive,
experiment-based, needing lots of feedback in all directions Less is generally better (for methodologies) Techniques / technologies change over time People learn in class or on the job, not from the
methodology
©Alistair Cockburn 2003-2005 Slide 6
Clear Yellow Orange Red
Crystal is a family of methodologies because every project is slightly different and needs its own.
Technologieschangetechniques.
Cultureschangenorms.
Distanceschangecommunication.
Number of people involved
C
riti
cali
ty(d
efec
ts c
ause
loss
of.
..)
Comfort(C)
Essentialmoney
(E)
Life(L)
1 - 6 - 20 - 40 - 100 - 200
C6 C20 C40 C100 C200
D6 D20 D40 D100 D200
E6 E20 E40 E100 E200
L6 L20 L40 L100 L200
Discretionarymoney
(D)
©Alistair Cockburn 2003-2005 Slide 7
Crystal is a family of methodologies with a common genetic code.
1 Cooperative Game Mindset: SD is a series of resource-limited cooperative games of communication and invention.
2 Methodology Design Priorities: Project safetyDevelopment efficiencyHabitability (tolerates humans!)
3 Methodology Design Principles: (7 of them, including: face-to-face work, concurrent development, & different rules for different circumstances)
4 Project Properties: Frequent delivery Close communication Reflective Improvement
5 Techniques: Discretionary but with a starter set.
6 Sample Methodology Designs: Crystal Clear Crystal Orange Crystal Orange-web
©Alistair Cockburn 2003-2005 Slide 8
1: Crystal’s 1: Crystal’s MindsetMindset
“Software development is a (resource-limited) finite, goal-seeking cooperative game
of invention and communication.”
©Alistair Cockburn 2003-2005 Slide 9
InfiniteOrganization Survival
Career Management
A finite, goal-directed (resource-limited!)cooperative game
Competitive Cooperative
Finite w/no fixed end
Jazz musicKing-of-the-hill
wrestling
Finite & goal-directed
Tennis
SoftwareDevelopmen
tChess
Rock-Climbing
Games
Poker
©Alistair Cockburn 2003-2005 Slide 10
The game has a primary and secondary goal: Two Games in One !
Primary Goal Deliver working software. (Mess up the first goal => no software.
Secondary Goal Set up for the next game. Mess up the secondary goal => disadvantaged next project
©Alistair Cockburn 2003-2005 Slide 11
Plan-drivensweet spot
Time and Effort Invested in Plans
Da
ma
ge
fro
m
ov
er/
un
de
rpla
nn
ing
The “correct” mix of planning vs. agility depends on the individual project’s risk exposure.
from “Get Ready for Agile Methods – With Care” (Barry Boehm, IEEE Computer, January 2001)
Agilesweet spot
©Alistair Cockburn 2003-2005 Slide 12
2: Crystal’s 2: Crystal’s Design PrioritiesDesign Priorities
•Project Safety•Development Efficiency
•Process Habitability
©Alistair Cockburn 2003-2005 Slide 13
Richness (“temperature”) of communication channel “cold” “hot”
Com
mun
icat
ion
Eff
ecti
vene
ss
2 people atwhiteboard
2 people on phone
2 peopleon email
Videotape
PaperAudiotape
(No Question-Answer)
(Questio
n-and-Answer)
3: Crystal’s 3: Crystal’s Design PrinciplesDesign Principles
©Alistair Cockburn 2003-2005 Slide 14
Seven principles for methodology design
1. Prefer face-to-face communication Interactive face-to-face communication is the cheapest and
fastest channel for exchanging information2. Methodology weight is costly3. Use heavier methodologies for larger / distributed teams4. Use More ceremony for more criticality5. Use more feedback & communications,
with fewer intermediate deliverables6. Discipline, skills, understanding counter
process, formality, documentation7. Efficiency is expendable at non-bottleneck activities.
©Alistair Cockburn 2003-2005 Slide 15
Agile processes are easy to describe understand as nested cycles of different durations.
Project
Episode
Integration
Day/Week
Iteration
Delivery
©Alistair Cockburn 2003-2005 Slide 16
To understand Crystal (or any agile process), describe each cycle independently.
Project
Delivery Delivery
IterationIteration
Iterations
Day/WeekIntegration Integration
Day/Week
Integrations
Days Days
Integrations
EpisodesEpisode Episode Episode Episode Episodes
Integrations
Episodes
©Alistair Cockburn 2003-2005 Slide 17
The activities of any one day may belong to different cycles
Project Iteration Day Integration EpisodeCharter
Plan Daily standup
Design & Check-inDesign & Check-in
Build and testDesign & Check-inDesign & Check-in
Build and test Daily standup
Design & Check-inDesign & Check-in
Build and testDesign & Check-inDesign & Check-in
Build and testDeliverReflect and celebratePlan(etc.)
Wrapup
©Alistair Cockburn 2003-2005 Slide 18
4: Crystal’s 4: Crystal’s Project PropertiesProject Properties
•Frequent Delivery•Osmotic Communication•Reflective Improvement•Personal Safety•Focus•Easy Access to Expert Users•Technical Environment with
- Frequent integration- Automated testing- Configuration management
©Alistair Cockburn 2003-2005 Slide 19
5: Crystal’s 5: Crystal’s StarterStarter Strategies & TechniquesStrategies & Techniques
•Methodology Shaping•Reflection Workshop•Blitz Planning•Delphi Estimation•Daily Stand-ups•Agile Interaction Design•Process Miniature•Side-by-Side Programming•Burn Charts
•Exploratory 360°•Early Victory
•Walking Skeleton •Incremental Rearchitecture
•Information Radiators
©Alistair Cockburn 2003-2005 Slide 20
Critical technique in Crystal:The reflection workshop each month or iteration.
Hang a 2-column flipchart
Fill in the chart (30 minutes)
Hang the chart in a public, visible, frequently seen place !
Try the ideas
Repeat each month or after each iteration
Keep these Try these
Problems
test lock-downquiet timedaily meetings
pair testingfines for interruptions
programmers help testers
too many interruptionsshipping buggy code
©Alistair Cockburn 2003-2005 Slide 21
6: Crystal 6: Crystal Sample Sample MethodologyDesignsMethodologyDesigns
Crystal Orange Crystal Orange/web Crystal Clear
©Alistair Cockburn 2003-2005 Slide 22
Crystal Orange : scopeFor D40 projects:
Up to 40 people, same buildingLoss of discretionary moneys (May extend to E50)
Not for very large projects (insufficient subteaming)
Not for life-critical projects(insufficient verification)
(Described in Surviving OO Projects, Cockburn, 1998, pp. 77-93)
AmberC6 C20 C40 C80
D6 D20 D40 D80
E6 E20 E40 E80
L6 L20 L40 L80
©Alistair Cockburn 2003-2005 Slide 23
Crystal Orange roles & teams for 45 people
Roles:
Sponsor, Business expert, Usage expert, Technical facilitator, Business analyst/designer, Project Manager, Architect, Lead designer/programmer, Designer/programmer, UI designer,Design Mentor, Reuse Point, Writer, Tester
Teams: System planning, Project monitoring, Architecture, Technology, Functions, Infrastructure, External test.
©Alistair Cockburn 2003-2005 Slide 24
C6 C10
D6 D10
E6 E10
Crystal Clear : scope
For D6 projects:3-6 people, close or in same roomLoss of discretionary moneys (may extend to: E8 project)
Not for large projects (insufficient group coordination)
Not for life-critical projects(insufficient verification)
(Described in Crystal Clear, Cockburn, 2004also in Agile Software Development, Cockburn 2002)
©Alistair Cockburn 2003-2005 Slide 25
Crystal Clear roles & teams for 3-8 people
Required Roles:
sponsor, senior designer, designer/programmer, user (part-time)
Combined Roles:
coordinator, business expert, requirements gatherer
Teams: single team of designer-programmers
Seating: single big room, or adjacent offices
©Alistair Cockburn 2003-2005 Slide 26
Getting started with Getting started with Crystal ClearCrystal Clear
©Alistair Cockburn 2003-2005 Slide 27
Select the frequency of delivery, the length of the iteration and integration cycles.
Project: any length
Delivery: every two months
Delivery
Iteration: two weeksIteration
Iterations
Week
Integration: daily
Week
Integrations
Days Days
Integrations
EpisodesEpisode Episode Episode Episode Episodes
Integrations
Episodes
©Alistair Cockburn 2003-2005 Slide 28
Must Do These !
1. Frequent Delivery : every month or two
2. Osmotic Communication : sit next to each other
3. Reflective Improvement : do reflection workshop monthly
Focus on the first 3 properties
©Alistair Cockburn 2003-2005 Slide 29
Add these as you can !
4. Personal Safety : speak freely without fear of punishment
5. Focus : Know what is most critical, have time to work on it
6. Easy Access to Expert Users
7. Technical Environment with
- Frequent integration : hourly, daily, 3 / week
- Automated testing : unit tests, acceptance tests
- Configuration management : check-in, versioning
Simply start work, and stay in good-humored communication with with your teammates !
©Alistair Cockburn 2003-2005 Slide 30
Hold a reflection workshop one day andeach month or iteration after that.
Keep these Try these
Problems
test lock-downquiet timedaily meetings
pair testingfines for interruptions
programmers help testers
too many interruptionsshipping buggy code
©Alistair Cockburn 2003-2005 Slide 31
• Crystal is a genetic code for shaping your working conventions to your projec, always agile, focused on frequent delivery, close communication, and reflection.
• Crystal Clear is the lightest of the Crystal family, for 3-8 people working at the same location.
http://Alistair.Cockburn.us
Crystal is the lightest, least intrusive, success-oriented methodology.