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

11.
Evolution of Models
Product Items burnt
Backlog
Items burnt
updated story
V1 V2 V1
com.myapp.Models IDo IDo
C1 C1
com.myapp.Views
M1 M2 M1
com.myapp.Controllers
Initial Architecture Model1 Model 2
Sprint 0 Sprint 1 Sprint 2
11

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