He mian agile project-inception


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Feedback Iteration User Centric, Global Thinking Team collaboration, meaning discussion Agile management
  • Adjusted with Knowledge gained Inspired by sprint review Development teams contributes ideas
  • Architecture Spike Development Tech. Spike Performance Spike Algorithm Spike User Experience Spike Business Process Spike
  • He mian agile project-inception

    1. 1. Agile Project Inception He Mian 2010-11-09
    2. 2. Who am I <ul><li>He Mian( 何勉 ), A agile SW development </li></ul><ul><ul><li>Practitioner </li></ul></ul><ul><ul><li>Beneficiary  </li></ul></ul><ul><ul><li>Embracer  </li></ul></ul><ul><ul><li>Evangelist </li></ul></ul><ul><ul><li>Explorer </li></ul></ul><ul><li>works in Alcatel-Lucent Shanghai Bell </li></ul><ul><li>[email_address] </li></ul><ul><li>[email_address] </li></ul>
    3. 3. Agenda <ul><li>Challenge of Status Quo </li></ul><ul><li>Project Inception </li></ul><ul><ul><li>Inception target </li></ul></ul><ul><ul><li>Project goal </li></ul></ul><ul><ul><li>Project planning </li></ul></ul><ul><ul><li>Architecture and Non-functional requirement Concerns </li></ul></ul><ul><li>Try it all together </li></ul>
    4. 4. Challenge of Status Quo
    5. 5. Status-Quo On time On budget Within Scope Struggling with Quality and always almost get it done
    6. 6. But ... Unhappy Customer Unhappy Developer Unhappy Boss Suffered Project Manager
    7. 7. Understand Reason of the Dilemma 1. Waterfall model and phase-based earned value management 2. Contract Game 3. Metrics organization, Functional teams 4. Go to the solution domain too soon 5. Defined process over Motivated People 6. Separate these who doing the work and who improving the work 7. No Gold plating Plan this Speech in Agile tour Qingdao. 7 sins of traditional Project Management & SW Engineering and Agile Way Out
    8. 8. Lean Thinking System Thinking Theory of constraint Scrum XP  Kanban LSD Mary Bas Daniel Lv Yi TWers Light in the Dark
    9. 9. Let's start Compose Cross Functional team Feed them with Two Pizzas Bring the Business people in
    10. 10. But, what's next … How to start
    11. 11. Target of Project Inception
    12. 12. Inception - Input <ul><ul><li>Tech. Evolution </li></ul></ul><ul><ul><li>Differentiation </li></ul></ul><ul><ul><li>Product Vision </li></ul></ul><ul><ul><li>Business Case (Return of Investments) </li></ul></ul><ul><ul><li>Customer Needs </li></ul></ul>Ideas Tech. Goals Constraints <ul><ul><li>Critical date </li></ul></ul><ul><ul><li>Budget Constraints </li></ul></ul><ul><ul><li>Tech. constraints </li></ul></ul>
    13. 13. Expectation from Inception Project Goal Project Plan Feasibility , Critical Decision , Risk, Dependencies
    14. 14. Project Goal
    15. 15. Project Goal For (target customer) Who (statement of the need or opportunity) The (product name) is a  (product category) That (statement of key benefit, that is, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation) Originated from the book “Cross the chasm”
    16. 16. Project Planning
    17. 17. Project Planning Cost Scope Time Scope Time Cost fixed variable
    18. 18.   Scope Time Cost Start from Product Backlog Creation Time and cost as constraint
    19. 19. Split in Problem Domain Solution Domain Problem Domain Traditional Way Agile Way Splitting at Solution Domain Splitting at Problem Domain
    20. 20. Why Split in Problem Domain <ul><li>Quick Feedback </li></ul><ul><li>Enable Iteration Development Model </li></ul><ul><li>Customer Centric Consideration </li></ul><ul><li>Global Thinking for development team </li></ul><ul><li>Team collaboration, meaningful discussion </li></ul><ul><li>Mandatory for Scrum/XP Adoption </li></ul>
    21. 21. If I had 20  days  to solve a  problem , I would take  19 days  to define it
    22. 22. Techniques for Splitting Data Boundaries Operation Boundaries Scenario based Non-Functional
    23. 23. Techniques for Splitting Nonfunctional Based Performance, Scalability … Make it work, make it better Scenario Based Meaningful Subset of steps Sunny day path, rainy day path Operation Boundaries Based C/R/U/D Connecting, Send the traffic, … Data Boundaries Based Subset of data Subset of supported protocol
    24. 24. What Makes good Product Backlog <ul><li>D etailed appropriately </li></ul><ul><li>E mergent </li></ul><ul><li>E stimated </li></ul><ul><li>P rioritized </li></ul>
    25. 25. Detailed Appropriately Fine grained Coarse grained Place holder Priority Done
    26. 26. Emergent <ul><ul><li>Originate from the project inception </li></ul></ul><ul><ul><li>Adapt with marketing changing </li></ul></ul><ul><ul><li>Emerge with the on-going of the product development </li></ul></ul>
    27. 27. Estimated 5 3 13 8 In Relative Size With Planning Poke
    28. 28. Prioritized <ul><ul><li>Financial Value </li></ul></ul><ul><ul><li>Cost of Development </li></ul></ul><ul><ul><li>Knowledge Gained </li></ul></ul><ul><ul><li>Risk Removal </li></ul></ul>adjust adjust adjust
    29. 29. Now We have Or
    30. 30. And … What else yet to be planned?
    31. 31. Planning Onion and Rolling wave Plan Product Vision Product Roadmap Release Planning Sprint Planning Daily Planning @ start of each release by PO and Team @ First day of each sprint by team @ Daily scrum meeting by team members
    32. 32. Release Planning <ul><li>Can be Epic based </li></ul><ul><li>Delivery planning or sprint planning </li></ul><ul><li>Business priority as the primary consideration </li></ul><ul><li>With consideration of dependency and integrity </li></ul><ul><li>Compose meaningful goal for each delivery/sprint </li></ul>
    33. 33. Risk Planning Possibility Impact Risk Item xxxxxxxx xxxxxx Mitigation Action : xxx Owner: xxx Low Mid High Low High Mid
    34. 34. Tips on Architecture and Non-Functional requirement Concerns
    35. 35. What’s architecture <ul><li>Architecture is the fundamental organization of a system embodied in its components , their relationships to each other and to the environment and the principles guiding its design and evolution. </li></ul>-- IEEE-Std-1471-2000
    36. 36. What’s architecture <ul><li>What’s the primary determination factors of architecture? -- Non functional requirement </li></ul><ul><li>What’s decision can be deferred and what can not be? -- Driven by risk and cost of change </li></ul>A Conceptual Flow of the ATAM From: http://www.sei.cmu.edu/architecture/tools/atam/
    37. 37. Thinnest Slice and Steel Thread <ul><li>Tech Risk focused </li></ul><ul><li>Just enough work to prove the concept </li></ul><ul><li>Mock is allowed or even encouraged </li></ul><ul><li>Code generated is not supposed to directly reused </li></ul>
    38. 38. Spikes <ul><li>On Architecture decision validation </li></ul><ul><li>On Development Tech. </li></ul><ul><li>On Performance </li></ul><ul><li>On Algorithm </li></ul><ul><li>On User Experience </li></ul><ul><li>On Business Process </li></ul><ul><li>On Domain Knowledge </li></ul>
    39. 39. Tips <ul><li>Facts </li></ul><ul><ul><li>Architecture is an ongoing job instead of an one time activity </li></ul></ul><ul><ul><li>What ever he does, in reality every SW developer is an Architect </li></ul></ul><ul><li>Try </li></ul><ul><ul><li>Run design workshop regularly with Engage stakeholders </li></ul></ul><ul><ul><li>Prove with real code (spike), don’t be “astronaut architect” </li></ul></ul><ul><ul><li>Build thinnest vertical slices to drive the Architecture Skelton out </li></ul></ul><ul><ul><li>Do customer-centric features with major architectural impact first </li></ul></ul><ul><ul><li>Defer the decision to the last responsive minutes </li></ul></ul>
    40. 40. Performance Concerns -- discussion <ul><li>What determines the Performance </li></ul><ul><li>What determines the theory limitation </li></ul><ul><li>What is the actual bottleneck </li></ul><ul><li>Why ? </li></ul><ul><li>How? </li></ul>
    41. 41. Try it all together
    42. 42. Risk Spike Critical arch Decision User stories Biz needs, Vision, ROI Collaboration Inception (Sprint 0) Velocity Sprint Plan Burn Down Daily Run Burn UP Iteration Del. Update Sprint 1~n Estimation Priority Release Plan Release Planning
    43. 43. Now, We are on the way!
    44. 44. Inspect and Adapt
    45. 45. Thank You!