Upload
sharprazor
View
86
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Agile development way works good for small projects and also works good for big project in the beginning. But most of time, the big projects face the same situation as projects not using Agile way. Adapt process and practice in system module design wise, team structure wise, project plan wise help big projects live better.
Citation preview
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