he mian agile project-inception
DESCRIPTION
TRANSCRIPT
Agile Project Inception
He Mian2010-11-09
Who am I
He Mian(何勉 ), A agile SW development Practitioner
Beneficiary
Embracer
Evangelist
Explorer
works in Alcatel-Lucent Shanghai Bell
Agenda
Challenge of Status Quo
Project Inception Inception targetProject goalProject planningArchitecture and Non-functional requirement Concerns
Try it all together
Challenge of Status Quo
Status-Quo
On timeOn budget
Within Scope
Struggling with Quality and always almost get it done
But ...
Unhappy CustomerUnhappy Developer
Unhappy Boss
Suffered Project Manager
Understand Reason of the Dilemma
1. Waterfall model and phase-based earned value management2. Contract Game3. Metrics organization, Functional teams 4. Go to the solution domain too soon5. Defined process over Motivated People6. Separate these who doing the work and who improving the work7. No Gold plating
Plan this Speech in Agile tour Qingdao. 7 sins of traditional Project Management & SW Engineering and Agile Way Out
Lean ThinkingSystem Thinking
Theory of constraint
ScrumXP
KanbanLSD
MaryBas
DanielLv Yi
TWers
Light in the Dark
Let's start
Compose Cross Functional team
Feed them with Two Pizzas
Bring the Business people in
But, what's next …How to start
Target of Project Inception
Inception - Input
Tech. EvolutionDifferentiation
Product VisionBusiness Case (Return of Investments)Customer Needs
Ideas
Tech. Goals
Constraints
Critical dateBudget ConstraintsTech. constraints
Expectation from Inception
Project Goal
Project Plan
Feasibility ， Critical Decision , Risk, Dependencies
Project Goal
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)
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”
Project Planning
Project Planning
Cost
Scope
TimeScope
Time Cost
fixed
variable
Scope
Time Cost
Start from Product Backlog Creation
Time and cost as constraint
Split in Problem DomainSolution DomainProblem Domain
Traditional Way
Agile Way
Splitting at Solution Domain
Splitting at Problem Domain
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
If I had 20 days to solve a problem, I would take 19 days to define it
Data Boundaries
Techniques for Splitting
Operation Boundaries
Scenario based
Non-Functional
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
Techniques for Splitting
What Makes good Product Backlog
Detailed appropriately
Emergent
Estimated
Prioritized
Detailed Appropriately
Fine grained
Coarse grained
Place holder
Priority
Done
Emergent
Originate from the project inception
Adapt with marketing changing
Emerge with the on-going of the product development
Estimated
5
3
13 8
In Relative Size
With Planning Poke
Prioritized
Financial Value
Cost of Development
Knowledge GainedRisk Removal
adjust
adjust
adjust
Now We haveOr
And …What else yet to be planned?
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
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
Risk PlanningPossibility
Impact
Risk ItemxxxxxxxxxxxxxxMitigation Action ： xxx
Owner: xxxLow Mid High
Low
High
Mid
Tips on Architecture and Non-Functional requirement Concerns
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
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/
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
Spikes
• On Architecture decision validation
• On Development Tech.
• On Performance
• On Algorithm
• On User Experience
• On Business Process• On Domain Knowledge
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
Performance Concerns -- discussion
What determines the Performance
What determines the theory limitation
What is the actual bottleneck
Why？How?
Try it all together
RiskSpike
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
Now, We are on the way!
Inspect and Adapt
Thank You!