1. Simple Design
and
Development Strategy
for agile teams
Duong Trong Tan
tandt@fpt.edu.vn
2. Objectives
• Issues of Planned • Design for
Design Communication
• What is Simple • Design for
Design? Collaboration
• Simplicity • Refactoring
• Design for Code • Simple Design in
practice
2
3. Design is the key,
Planned Design is not …
• Takeuchi & Nonaka: overlapping is better than sequential
Not efficient:
• Time consuming
• No backward
• No “better idea” on the go
But how to do this kind of overlapping development?
3
4. What is Simple Design?
• Design grows as
implementation
– Complete design NOT
required. Just enough, GO!
• Part of programming
Evolve
processes
• Program evolves the
design changes
• Not “code and fix” tactics
4
5. Simplicity
Rationale behind Simple Design
• "Do the Simplest Thing that Could
Possibly Work“
• "You Aren't Going to Need It“
• Invest in patterns
• Simple system
1. Runs all the Tests
2. Reveals all the intention
3. No duplication
4. Fewest number of classes or
methods
5
6. Design for
Communication
• Draw design stuffs for discussion within your
team
– Just enough for clarifying solutions
• Only use diagrams that you can keep up to
date without noticeable pain
• Keep diagrams visible
– Post to wall or board
– Encourage people to edit
• Pay attention to whether people are using
them, if not throw them away.
6
7. Design for Construction
• “Working software is the primary
measure of progress”
• Your design will be realized into a working
item, so:
– Design should be code-able in team
• separation, interfacing, collaboration between
components
– Design should be testable
– “Architect must code!”
7
8. Refactoring
• For simpler design
• For maintenanceupgrade
later
• MustHave task in your
DoneDefinition checklist
Learn more: http://www.refactoring.com/
• Invest in patterns and best
practices
Image: http://www.testically.org
8
9. Development Flow
$ $
Collaboration:
PO DevTeam PO
UI Mocking Design Draft Code the
Refactoring
Steps: Requirement •Customer •Design skeleton to Coding in
and
Build the
Analysis discussion Discussion test the team increment
Refinement
design
Interface IDo{
//TODO …
A Interface IDo{ }
//TODO … Class A{
IDo } method1(){
As a super user,
Class A{ //Mr. A codes here
Artifacts:
I want to …
//TODO … }
}
B }
Class B:IDo{ Class B:IDo{
//TODO … method1(){
} //Mrs. B codes here
}
}
Note: 1. TDD|BDD|AMDD can be used or not Class C{
2. Images are for illustration only } 9
10. How about Architecture?
• PO works with DevTeam to specify
– Technologies used
– Frameworks used
– Initial Architecture
• Before Sprint 1
– @User Story Writing workshop
– @ Initial Requirement Envisioning and Initial
Architecture Envisioning
10
12. “Continuous” Architecting
Sprint #1: without layering
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
12
13. “Continuous” Architecting
Sprint #2: refactoring to layers
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
13
14. “Continuous” Architecting
Sprint #3: architecting “on the go”
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
14
15. Summary
• A good design is simple
• Keep It Simple, Stupid!
• Using incremental design for agile
development
• Design evolves during development
process
• Using refactoring to maintain simplicity
• There should be a vision for architecture
15
16. References
• Agile Alliance, Agile Manifesto
http://agilemanifesto.org
• H. Takeuchi & I. Nonaka, The new new
Product development game, Harvard
Business Review, 1986.
• M. Fowler, Is Design Dead?
http://martinfowler.com/articles/designDead.html
• http://www.refactoring.com/
16