The document discusses the challenges of traditional project management and introduces an agile approach called project inception. It outlines the goals of project inception, which are to define the project goal, create an initial project plan, and assess feasibility. It also discusses establishing product vision, customer needs, and technical goals during inception. The document provides guidance on splitting projects into problem and solution domains, creating a product backlog, and planning releases and iterations using an agile approach to help projects get started in a more effective manner.
2. Who am I He Mian( 何勉 ), A agile SW development Practitioner Beneficiary Embracer Evangelist Explorer works in Alcatel-Lucent Shanghai Bell [email_address] [email_address]
3. Agenda Challenge of Status Quo Project Inception Inception target Project goal Project planning Architecture and Non-functional requirement Concerns Try it all together
5. Status-Quo On time On budget Within Scope Struggling with Quality and always almost get it done
6. But ... Unhappy Customer Unhappy Developer Unhappy Boss Suffered Project Manager
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. Lean Thinking System Thinking Theory of constraint Scrum XP Kanban LSD Mary Bas Daniel Lv Yi TWers Light in the Dark
9. Let's start Compose Cross Functional team Feed them with Two Pizzas Bring the Business people in
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”
18. Scope Time Cost Start from Product Backlog Creation Time and cost as constraint
19. Split in Problem Domain Solution Domain Problem Domain Traditional Way Agile Way Splitting at Solution Domain Splitting at Problem Domain
20. Why Split in Problem Domain Quick Feedback Enable Iteration Development Model Customer Centric Consideration Global Thinking for development team Team collaboration, meaningful discussion Mandatory for Scrum/XP Adoption
21. If I had 20 days to solve a problem , I would take 19 days to define it
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. What Makes good Product Backlog D etailed appropriately E mergent E stimated P rioritized
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. Release Planning Can be Epic based Delivery planning or sprint planning Business priority as the primary consideration With consideration of dependency and integrity Compose meaningful goal for each delivery/sprint
35. What’s architecture 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. -- IEEE-Std-1471-2000
36. What’s architecture What’s the primary determination factors of architecture? -- Non functional requirement What’s decision can be deferred and what can not be? -- Driven by risk and cost of change A Conceptual Flow of the ATAM From: http://www.sei.cmu.edu/architecture/tools/atam/
37. Thinnest Slice and Steel Thread Tech Risk focused Just enough work to prove the concept Mock is allowed or even encouraged Code generated is not supposed to directly reused
38. Spikes On Architecture decision validation On Development Tech. On Performance On Algorithm On User Experience On Business Process On Domain Knowledge
39. Tips Facts Architecture is an ongoing job instead of an one time activity What ever he does, in reality every SW developer is an Architect Try Run design workshop regularly with Engage stakeholders Prove with real code (spike), don’t be “astronaut architect” Build thinnest vertical slices to drive the Architecture Skelton out Do customer-centric features with major architectural impact first Defer the decision to the last responsive minutes
40. Performance Concerns -- discussion What determines the Performance What determines the theory limitation What is the actual bottleneck Why ? How?
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