• Save
Planning Agile Projects
Upcoming SlideShare
Loading in...5
×
 

Planning Agile Projects

on

  • 534 views

Book Review of Planning eXtreme Programming (XP)

Book Review of Planning eXtreme Programming (XP)

Statistics

Views

Total Views
534
Views on SlideShare
534
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Planning XP 1/22/2002 H.Briley

Planning Agile Projects Planning Agile Projects Presentation Transcript

  • Planning e X treme P rogramming (XP)
    • How little can we do
    • … and still build great software?
            • A book review by Harry Briley, January 22, 2002
    • ICS Group Leader, Lawrence Livermore National Lab
  • By Kent Beck and Martin Fowler, 140 pages
    • (the GREEN book)
    • These slides have only a few highlights
    • Copyright law : Buy a copy of the book
  • PLAN? “I have always found plans … useless, but planning … indispensable” – Eisenhower
    • What really matters today is building software fast
        • But often introduced to projects when they are mostly dead
    • Agile/XP Keys:
        • Break large jobs into 3-week self-contained mini-projects
        • Enable developers to work without a formal process
    • Most Plans are huge time sinks, dragging down people who’d rather be productive
  • FEAR “Unacknowledged fear is the source of all project failures.” - Kent Beck
    • Customers fear: They won’t ever see meaningful plan
        • The right to an overall plan : what, when, and at what cost.
        • The right to cancel and get a useful system reflecting investment.
    • Developers fear: They won’t have time to succeed
        • The right to ask for and receive help
        • The right to accept responsibilities instead of being assigned them
  • BALANCE and ITERATIONS Frequently assess where project going: “Ready…Fire…Aim… Aim… Aim…”
    • Estimating is a technical decision
    • Choosing between features is a business decision.
    • Shrink development life cycle to microscopic size
        • A quarter ly turn of ‘business crank’ is a release
        • A three week development cycle is an iteration .
        • An iteration is a fully-tested production-ready system
    • Estimates: Assume you’ll accomplish as much in this iteration as you did in the last iteration.
  • TOO MUCH TO DO “Not only do I have a full plate, I now have a complete dining set.” – a Lab 285
    • COSTS : Adding more people makes a late project later
        • Faster desktops, bigger monitors ( flat panels? ) are motivators
        • Motivated developer in 7 hours outperforms a tired one at 10 hours.
        • Long hours to do -> fatigue -> mistakes -> Long hours to fix
    • QUALITY : Trade tolerable defects for valuable functions
        • Trade-offs are always the Customer’s decision
    • TIME and SCOPE : Planning makes time visible
        • Since hopelessness breeds mistakes, burnout, and failure ...
        • End the project every few weeks
        • By planning so often, nobody pays for plans , they pay for results
  • SCOPING A PROJECT “You can’t put 10 pounds of manure in a 5 pound bag.” – Anyone that tried
    • A typical 24 month project using Agile/XP:
        • Begins with shouting and negotiations
        • Break problem into pieces
        • Estimate each piece
        • Defer less valuable pieces
    • A manager once said, “I know it’s going to be a challenge, but if anyone can do it, you can.”
        • The result was that developers found something else to work on most of the time
  • RELEASES and STORIES Release often ... with enough new functionality to merit a press release
    • Whoops! Infrastructure before delivering functions
        • Common feature of dead and dying projects
        • You spend a lot of time not delivering things
    • Project Tools for repetitive projects useless for XP
        • Dependencies between XP tasks do not figure strongly
        • False Dependencies: Building GUI data entry screens first
    • Customer has responsibility to supply stories
        • Writing stories iterative , few at a time, clear enough to estimate
        • Value: Customer is happier if we do valuable things first
        • Risk: If developers are nervous , everyone should listen.
          • New technology, Task too big, Inflexible design
        • Creep: Let requirements crawl around to find customer’s needs .
  • ITERATION PLANNING Understanding a story is simplest if customer gives short talk about story
    • Regularly Scheduled Planning Meeting:
        • Customer reads out stories for the given iteration
        • Together, White-board the tasks for each story
        • Developers sign up and estimate tasks … up to their velocity
    • With motivated and capabable developers
        • “ Ideal Weeks” are if programmer could dedicate 100% time
        • Velocity = Number of stories completed in an iteration
    • Programmer chooses amount completed last cycle
        • When programmer says, ” I’ll get that done in a day” ... check.
        • Learn to accurately predict than reach for arbitrary measure .
        • Records as weapons? You’ll never get an honest estimate again.
  • TRACKING The only thing you know about a plan … is that things won’t go according to it
    • A key question: “ How many days are left? ”
        • Every dark corner you haven’t tested … is full of bugs
        • “ I’m done coding, but haven’t tested yet”, is meaningless.
        • Customers sadly log developer ‘doneness’ as bugs .
    • Work iteration to iteration, but plan one or two ahead.
        • A danger is never having a ‘ formal release ’
        • Keep long term in mind . We can easily lose strategic vision .
    • Iterations synchronized to rhythms of programming
        • Never slip dates . Set regular cycle . Defer functionality.
        • Rule: No one allowed overtime two weeks in a row.
        • Overtime will rapidly takes its ‘pay’ in some other form .
  • Planning e X treme P rogramming (XP) The GREEN Book - Planning XP The WHITE Book - XP Explained