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