Agile is not working in BIG project? TaoWen & LiuFan
Jan 15, 2015
Agile is not working in BIG project?
TaoWen & LiuFan
Once upon a time
there was a BIG project
“Agile” in Reality
• Small team
• Client start from big plan
• Big scope
• Complex business logic
• Tight schedule
• Big team
• Quick feedback
• Collective ownership
• Simple design
• Continuous refactoring
Do you feel the pain?
• Code organization in BIG project
Same code again and again
Big Mess
Layered Code Design
• View => Controller => Model => Service => ORM => Table => Stored Procedure
• “OOP Leads to Big Objects”: blindly put logic inside models do not help us. Enforcing putting logic into models, is enforcing layering.
• Layering is important, but not enough to control total complexity
• Over-layering is pain in the butt
“ Big Ball of Mud, Still the Most Popular Software Design
”http://www.infoq.com/news/2010/09/big-ball-of-mud
Is there a better way?
% cat inFile | grep pattern | sort > outFile
Pipeline Architecture
Unix styleEclipsePlugin architecture
Besides Code,What else is painful?
• Team in BIG project
Long process
Bottleneck
Layered Team Design
• Client => Michael => BA s + UI => DEV s + UI => QA s =>Deployers => Client=> Users
• Roles == Layers
Is there a better way?
• Separate team by features
– Feature Owner (Developer/Business analyzer)– QA/Business analyzer– DevOps
Conway’s Law
“ organizations which design systems ... Are constrained to produce designs which are copies of the communication structures of these organizations
”
Vertical <=> Horizontal
Big problem
CodeTeam
That is so coolWhy not do it?
• Capbility• Simple Design• Tight Schedule• Integration Cost• Reuse• Organization Structure
Vendor side
• User perceive it as single system• Customer want a total solution
• Vendor lack of business insight• Customer lack of IT perspective
Customer side
Should we just doBIG up front design?
• Do features in parallel from beginning• => Validate concept very late• => Harder to change direction, re-prioritize
• Big project, but think first=> Separate the important from unimportant=> Do the most important part first
=> Earlier to validate the concept=> Easier to change direction
• Eric Evan call it “Strategic Design”
Why we need to plan strategically?
Q & A