Cockburn:%20Agile%20Software%20Development - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Cockburn:%20Agile%20Software%20Development

Description:

Information radiators. information must change. easy to view the display. 11. SoberIT ... use of a shared, persistent information radiator ... – PowerPoint PPT presentation

Number of Views:15
Avg rating:3.0/5.0
Slides: 31
Provided by: JariVa9
Learn more at: http://www.soberit.hut.fi
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Cockburn:%20Agile%20Software%20Development


1
Cockburn Agile Software Development
  • T-76.650
  • 28.1.2002
  • Jari Vanhanen

2
Goal of the book
  • to undestand that it is impossible to name one
    best and correct way to develop software
  • to lead to constructive ideas to deal with the
    above situation
  • to build a vocabulary for software development
    that helps noticing things and talking about them

3
Software and games
  • Considering software development as a game is a
    better metaphor than engineering or model
    building
  • Software development is a group game, which is
  • goal seeking
  • finite
  • cooperative
  • Game of innovation and communication
  • contains peoples ideas and communicating the
    ideas to colleagues and computer

4
Software and games
  • Programmers and communication
  • a stereotype of a programmer is noncommunicative
  • programming has been work of individuals
  • agile methodologies emphasize communication
  • programmers like communicating about techical
    things
  • surprisingly high acceptance of pair programming
  • Gaming faster
  • programming is limited by the ability to think
    through the problem and the solution
  • like writing novels or writing laws
  • Other games
  • personal careers
  • growth of the company
  • may be in conflict with the project-game

5
Intermediate work products
  • Shared experices to refer to
  • reminds of an earlier thought or decision
  • Support structures for new ideas
  • incite new thoughts
  • For the primary goal (delivering software) they
    have value only as they help the team move on
  • measured for sufficiency, not for completeness or
    perfection
  • reaching perfect communication is an impossible
    goal
  • Preparing for the next game
  • transfer enough knowledge to the next team
  • when to produce?
  • constantly (lot of rework)
  • at the end (will they be created?)

6
Individuals
  • Purely people factors predict project
    trajectories quite well, overriding choice of
    process or technology
  • a well-functioning team of adequate people
    succeed almost regardless of the process or
    technology they are required to use
  • Hard to design a system composed of humans
  • humans are contradictory, depending on work,
    time, other people, etc.
  • people differ in their ways to solve problems
  • Diversity presents communication difficulty and
    personal friction but also allows for efficiency
  • mixed teams often outperform homogeneous teams

7
Human failure modes
  • People make mistakes
  • reason for iterative (rework) and incremental
    (develop pieces) development
  • Preferring to fail conservatively rather than to
    risk succeeding differently
  • risk-averse if you might lose something you have
  • risk-accepting if you are losing something and
    might regain it
  • inventing rather than researching
  • educational background
  • being incosistent creatures of habit
  • resist learning new habits, but tend towards
    inconsistency

8
How methodologies deal with human weaknesses
  • Discipline
  • create mechanisms that hold strict behavioral
    standards in place
  • high-discipline methodologies are fragile
  • Cleanroom
  • PSP
  • XP
  • strict adherence to ineffective practices leads
    to ineffective team
  • Tolerance
  • design the methodology to be tolerant of
    individual variations
  • team members form consensus of the minimum
    compliance needed
  • works if people care about citizenship issues and
    generally take pride in their work
  • tolerant methodologies
  • ASD
  • Crystal family

9
Working better in some ways than others
  • Concrete
  • Tangible
  • paper prototypes
  • CRC cards
  • Something to alter
  • examples or work products
  • Watching and listening
  • arrange the room setup for learning
  • Supporting concentration AND communication
  • flow
  • Personality-matched work assignments
  • Talent
  • skills can be improved, but talent can not
  • Rewards that preserve joy
  • rewards reduce the intrinsic joy and quality of
    otherwise fun activity
  • pride-in-work
  • pride-in-accomplishment
  • order of tasks in project
  • pride-in-contribution
  • Clear and frequent feedback

10
Communication
  • Discovering that someone knows something useful
  • Transferring the knowledge
  • Delays and lost-opportunity costs
  • proximity
  • knowing that someone is present
  • seeing what others are doing
  • Osmotic communication
  • useful background sounds and drafts
  • Information radiators
  • information must change
  • easy to view the display

11
Modalities in communication
  • physical proximity
  • three-dimensionality
  • smell
  • kinesthetics
  • touch
  • sound
  • visuals
  • cross-modality timing
  • low latency
  • trust and learning
  • use of a shared, persistent information radiator
  • remove almost everything and the result is a
    paper
  • you arent close to the writer
  • you cant see the writer
  • you cant hear the writer
  • you can ask question from the writer
  • ...
  • videotaped documentation

12
Elements of a methodology
reviews publications declarations
13
Scope of a methodology
  • Often two seemingly incompatible methodologies
    target different parts of the lifecycle or
    different roles
  • XP vs. GUI design

14
Conceptual terms
  • Methodology
  • size
  • number of control elements
  • ceremony
  • precision and tolerance in the methodology
  • weight
  • sizeceremony
  • visibility
  • how easily outsiders see if the methodology is
    followed
  • Problem size
  • number of elements and their cross-complexity
  • Project size
  • number of people
  • System criticality
  • damage from undetected defects
  • Work products
  • Precision
  • How much to say about a topic?
  • Accuracy
  • How correct you are?
  • Relevance
  • Whether or not to speak about a topic?
  • Tolerance
  • How much variation is permitted?
  • Scale
  • rolling items together
  • Stability
  • How likely is it to change?

15
Publishing a methodology
  • Pictorial view
  • e.g. Role-Deliverable-Milestone view
  • birth, review, death
  • most people only want to see the part that
    affects them
  • misses practices, standards, and other forms of
    collaboration

16
Publishing a methodology
  • Textual view
  • describes techniques, activities, meetings, ...
  • large
  • e.g. XP 200-gt1000 pages
  • documentation vs. understanding
  • real methodology is tacit knowledge
  • understanding does not presuppose having
    documentation
  • impractical to keep up-to-date with the needs of
    the teams
  • methodology needs to change constantly
  • practices needed to transfer good habits to other
    teams
  • Reducing size of the text
  • provide examples of work products
  • replace technique guides with pointers to books
    and courses
  • organize the text by role
  • use process miniature
  • play-act a release of a project in a very short
    period of time
  • replay from time to time

17
Methodology design principles
  • Common errors
  • One size for all projects
  • corporations common methodology ...
  • Intolerant
  • a methodology is a straight-jacket
  • should not be any tighter than absolutely needed
  • e.g. many techniques work quite well and
    different ones suit different people at different
    times
  • Heavy
  • heavier is safer for managers?
  • when to trust people
  • what constraints add more burden than safety
  • Embellished
  • unnecessary rules, practices, and ideas
  • have directly affected people review the proposal
  • Untried
  • Used once
  • generalization?

18
Principles for designing methodologies
  • Interactive, face-to-face communication is the
    cheapest and fastest channel for exchanging
    information.
  • prefer using warmer communication channels in
    software evelopment
  • e.g. videotaped design documentation
  • more difficult as the project size increases
  • emphasize small groups and personal contact if
    productivity and cost are key issues

19
Principles for designing methodologies
  • Excess methodology weight is costly.
  • intermediate work products might add unnecessary
    costs to a small team
  • a small team can succeed with a larger problem by
    using a lighter methodology
  • of course you cant remove everything
  • a team operating from peoples strenghts -
    communication and citizenship - can do with a lot
    less methodology than most managers expect

20
Principles for designing methodologies
  • Larger teams need heavier methodologies.

Small team
Large team
21
Principles for designing methodologies
  • Greater ceremony is appropriate for projects with
    greater criticality.
  • cost of leaving a fault in a system
  • criticality categories in Crystal family
  • loss of comfort
  • loss of discretionary monies
  • loss of essential monies
  • loss of life

22
Principles for designing methodologies
  • Increasing feedback and communication reduces the
    need for intermediate deliverables.
  • an intermediate deliverable is one that is passed
    across decision boundaries within the team
  • deliver a working piece of the system quickly
  • feedback
  • reduce the team size and put people close
    together
  • facilitate face-to-face communication

23
Principles for designing methodologies
  • Discipline, skills, and understanding counter
    process, formality, and documentation
  • discipline involves a person choosing to work in
    a way that requires consistency
  • process involves a person following instructions
  • discipline is more powerful
  • knowledge that becomes documentation is only a
    small part of what there is to know
  • transfer the heads that hold the information
  • no degree of formality replaces skill
  • exploratory vs. optimizing projects
  • finding vs. pumping oil wells

24
Principles for designing methodologies
  • Efficiency is expendable in nonbottleneck
    activities.
  • minimize rework in bottleneck activity
  • you can add inefficiency to preceeding activities
    in order to get their outputs more complete and
    stable

25
Consequences of the principles
  • Adding people to a project is costly
  • Team size increases in large jumps
  • Teams should be improved, not enlarged
  • Different methodologies for different projects
  • number of people, system criticality, project
    priorities
  • Lighter methodologies are better until they run
    out of steam
  • Methodologies should be stretched to fit

26
Why methodology at all
  • Introducing new people to the process
  • Delineating responsibilities
  • Impressing the sponsors
  • Demonstrating visible process
  • Curriculum for education

27
Light but sufficient
  • Primary goal is to deliver software
  • Secondary goal is to set up for the second game
  • How to allocate resources to each goal?
  • How much of the knowledge to document?
  • Recommendations for documentation
  • just enough required to communicate with the
    readers
  • replace typing with faster communications media
  • visits in person
  • video clips
  • remember, there will be new persons requiring
    more documentation
  • run documentation as a parallel, resource
    competing thread of the project

28
Sweet spots of software development
  • 2-8 people in one room
  • information moves fastest
  • Onsite usage expert
  • minimized feedback time of the solution
  • One-month increments
  • feedback of the product and the process
  • Fully automated regression tests
  • confidence to changing and improving the system

29
Agile software development manifesto
  • Signed by authors of ASD, XP, Scrum, Crystal,
    FDD, DSDM, and pragmatic programming
  • Agree at the first level
  • need to respond to change
  • Agree at the second level
  • individuals and interactions over processes and
    tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiation
  • responding to change over following a plan
  • Agree at the third level
  • 12 more detailed statements
  • Dont agree at the fourth level
  • detailed project tactics

30
References
  • Cockburn. Agile Software Development. Addison
    Wesley 2001.
  • Glass. Agile versus Traditional. In Cutter
    ITJournal December 2001.
  • http//www.cutter.com/itjournal/itj0112.pdf
  • Boehm. Get Ready for Agile Methods, with Care.
    IEEE Computer January 2002.
  • http//ieeexplore.ieee.org
About PowerShow.com