Planning Agile Projects

474 views

Published on

Book Review of Planning eXtreme Programming (XP)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
474
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Planning XP 1/22/2002 H.Briley
  • Planning Agile Projects

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

    ×