Скачать презентацию The Crystal Family of Methodologies for Software Development Скачать презентацию The Crystal Family of Methodologies for Software Development

c883b1212a4e83e5fb6914b6b939c3ce.ppt

  • Количество слайдов: 31

The Crystal Family of Methodologies for Software Development Alistair Cockburn http: //alistair. cockburn. us The Crystal Family of Methodologies for Software Development Alistair Cockburn http: //alistair. cockburn. us ©Alistair Cockburn 2003 -2005 Slide 1

History 1991 - 2004 1991: Alistair Cockburn (pronounced Co-burn) wanted to develop an effective 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 project 1997: “Orange” published in Surviving OO Projects 1998: Family of methodologies the name “Crystal” 2004: “Crystal Clear” published as book ©Alistair Cockburn 2003 -2005 Slide 2

What were the most common characteristics of successful projects? • • • People sit 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 3

‘Methodology’ is only the set of conventions people agree to follow -- it changes ‘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 4

Crystal is the lightest, least intrusive set of rules that puts a project in 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 5

Criticality (defects cause loss of. . . ) Crystal is a family of methodologies Criticality (defects cause loss of. . . ) Crystal is a family of methodologies because every project is slightly different and needs its own. Life (L) L 6 L 20 L 40 L 100 L 200 Essential money (E) E 6 E 20 E 40 E 100 E 200 Discretionary money D 6 (D) D 20 D 40 D 100 D 200 Comfort (C) C 6 C 20 C 40 C 100 Clear Yellow Orange Red 1 -6 - 20 - 40 - 100 C 200 Cultures change norms. Distances change communication. - 200 Number of people involved ©Alistair Cockburn 2003 -2005 Technologies change techniques. Slide 6

Crystal is a family of methodologies with a common genetic code. 1 Cooperative Game 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. 4 Project Properties: Frequent delivery Close communication Reflective Improvement 2 Methodology Design Priorities: Project safety Development efficiency Habitability (tolerates humans!) 5 Techniques: Discretionary but with a starter set. 3 Methodology Design Principles: (7 of them, including: face-to-face work, concurrent development, & different rules for different circumstances) 6 Sample Methodology Designs: Crystal Clear Crystal Orange-web ©Alistair Cockburn 2003 -2005 Slide 7

1: Crystal’s Mindset “Software development is a (resource-limited) finite, goal-seeking cooperative game of invention 1: Crystal’s Mindset “Software development is a (resource-limited) finite, goal-seeking cooperative game of invention and communication. ” ©Alistair Cockburn 2003 -2005 Slide 8

A finite, goal-directed cooperative game Infinite (resource-limited!) Organization Survival Career Management Finite w/ no A finite, goal-directed cooperative game Infinite (resource-limited!) Organization Survival Career Management Finite w/ no fixed end Finite & goal-directed Games King-of-the-hill wrestling Poker Tennis Chess Competitive ©Alistair Cockburn 2003 -2005 Jazz music Rock-Climbing Software Developmen t Cooperative Slide 9

The game has a primary and secondary goal: Two Games in One ! Primary 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 10

Damage from over/underplanning The “correct” mix of planning vs. agility depends on the individual Damage from over/underplanning The “correct” mix of planning vs. agility depends on the individual project’s risk exposure. Plan-driven sweet spot Agile sweet spot Time and Effort Invested in Plans from “Get Ready for Agile Methods – With Care” (Barry Boehm, IEEE Computer, January 2001) ©Alistair Cockburn 2003 -2005 Slide 11

2: Crystal’s Design Priorities • Project Safety • Development Efficiency • Process Habitability ©Alistair 2: Crystal’s Design Priorities • Project Safety • Development Efficiency • Process Habitability ©Alistair Cockburn 2003 -2005 Slide 12

Communication Effectiveness 3: Crystal’s Design Principles 2 people at whiteboard 2 people on phone Communication Effectiveness 3: Crystal’s Design Principles 2 people at whiteboard 2 people on phone er) -an Videotape 2 people on email Audiotapen-Answer) Paper estio o Qu w ns -A d (Q on sti ue (N Richness (“temperature”) of communication channel “cold” ©Alistair Cockburn 2003 -2005 Slide 13 “hot”

Seven principles for methodology design 1. Prefer face-to-face communication Ø Interactive face-to-face communication is Seven principles for methodology design 1. Prefer face-to-face communication Ø Interactive face-to-face communication is the cheapest and fastest channel for exchanging information 2. Methodology weight is costly 3. Use heavier methodologies for larger / distributed teams 4. Use More ceremony for more criticality 5. Use more feedback & communications, with fewer intermediate deliverables 6. Discipline, skills, understanding counter process, formality, documentation 7. Efficiency is expendable at non-bottleneck activities. ©Alistair Cockburn 2003 -2005 Slide 14

Agile processes are easy to describe understand as nested cycles of different durations. Project Agile processes are easy to describe understand as nested cycles of different durations. Project Delivery Iteration Day/Week Integration Episode ©Alistair Cockburn 2003 -2005 Slide 15

To understand Crystal (or any agile process), describe each cycle independently. Project Delivery Iteration To understand Crystal (or any agile process), describe each cycle independently. Project Delivery Iteration Day/Week Integration Episode Integrations Episodes ©Alistair Cockburn 2003 -2005 Days Iterations Days Integrations Episodes Slide 16

The activities of any one day may belong to different cycles Project Charter Iteration The activities of any one day may belong to different cycles Project Charter Iteration Day Plan Integration Daily standup Build and test Wrapup Deliver Reflect and celebrate Plan (etc. ) Build and test ©Alistair Cockburn 2003 -2005 Episode Design & Check-in Design & Check-in Slide 17

4: Crystal’s Project Properties • Frequent Delivery • Osmotic Communication • Reflective Improvement • 4: Crystal’s Project 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 18

5: Crystal’s Starter Strategies & Techniques • Exploratory 360° • Early Victory • Walking 5: Crystal’s Starter Strategies & Techniques • Exploratory 360° • Early Victory • Walking Skeleton • Incremental Rearchitecture • Information Radiators • Methodology Shaping • Reflection Workshop • Blitz Planning • Delphi Estimation • Daily Stand-ups • Agile Interaction Design • Process Miniature • Side-by-Side Programming • Burn Charts ©Alistair Cockburn 2003 -2005 Slide 19

Critical technique in Crystal: The reflection workshop each month or iteration. Hang a 2 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 ©Alistair Cockburn 2003 -2005 Slide 20

6: Crystal Sample Methodology. Designs Crystal Orange/web ©Alistair Cockburn 2003 -2005 Crystal Clear Slide 6: Crystal Sample Methodology. Designs Crystal Orange/web ©Alistair Cockburn 2003 -2005 Crystal Clear Slide 21

Crystal Orange : scope For D 40 projects: Up to 40 people, same building Crystal Orange : scope For D 40 projects: Up to 40 people, same building Loss of discretionary moneys (May extend to E 50) L 6 L 20 L 40 L 80 E 6 E 20 E 40 E 80 D 6 D 20 D 40 D 80 C 6 Amber C 20 C 40 Not for very large projects (insufficient subteaming) Not for life-critical projects (insufficient verification) (Described in Surviving OO Projects, Cockburn, 1998, pp. 77 -93) ©Alistair Cockburn 2003 -2005 Slide 22 C 80

Crystal Orange roles & teams for 45 people Roles: Teams: Sponsor, Business expert, Usage Crystal Orange roles & teams for 45 people Roles: Teams: 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 System planning, Project monitoring, Architecture, Technology, Functions, Infrastructure, External test. ©Alistair Cockburn 2003 -2005 Slide 23

Crystal Clear : scope For D 6 projects: 3 -6 people, close or in Crystal Clear : scope For D 6 projects: 3 -6 people, close or in same room Loss of discretionary moneys (may extend to: E 8 project) E 6 E 10 D 6 D 10 C 6 C 10 Not for large projects (insufficient group coordination) Not for life-critical projects (insufficient verification) (Described in Crystal Clear, Cockburn, 2004 also in Agile Software Development, Cockburn 2002) ©Alistair Cockburn 2003 -2005 Slide 24

Crystal Clear roles & teams for 3 -8 people Required Roles: Teams: sponsor, senior Crystal Clear roles & teams for 3 -8 people Required Roles: Teams: sponsor, senior designer, designer/programmer, user (part-time) single team of designerprogrammers Seating: single big room, or adjacent offices Combined Roles: coordinator, business expert, requirements gatherer ©Alistair Cockburn 2003 -2005 Slide 25

Getting started with Crystal Clear ©Alistair Cockburn 2003 -2005 Slide 26 Getting started with Crystal Clear ©Alistair Cockburn 2003 -2005 Slide 26

Select the frequency of delivery, the length of the iteration and integration cycles. Project: Select the frequency of delivery, the length of the iteration and integration cycles. Project: any length Delivery: every two months Delivery Iteration: two weeks Week Integration: daily Episode Iteration Integrations Episodes ©Alistair Cockburn 2003 -2005 Days Iterations Days Integrations Episodes Slide 27

Focus on the first 3 properties Must Do These ! 1. Frequent Delivery : Focus on the first 3 properties 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 ©Alistair Cockburn 2003 -2005 Slide 28

Simply start work, and stay in good-humored communication with your teammates ! Add these Simply start work, and stay in good-humored communication with your teammates ! 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 ©Alistair Cockburn 2003 -2005 Slide 29

Hold a reflection workshop one day and each month or iteration after that. ©Alistair Hold a reflection workshop one day and each month or iteration after that. ©Alistair Cockburn 2003 -2005 Slide 30

Crystal is the lightest, least intrusive, success-oriented methodology. • Crystal is a genetic code Crystal is the lightest, least intrusive, success-oriented methodology. • 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 ©Alistair Cockburn 2003 -2005 Slide 31