Simple design
16
description
This presentation shows some core ideas of simple design which helps agile teams collaborating in their development effort.
Transcript of Simple design
Objectives
• Issues of Planned
Design
• What is Simple
Design?
• Simplicity
• Design for Code
• Design for
Communication
• Design for
Collaboration
• Refactoring
• Simple Design in
practice
2
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
What is Simple Design?
• Design grows as implementation
– Complete design NOT required. Just enough, GO!
• Part of programming processes
• Program evolves the design changes
• Not “code and fix” tactics
Evo
lve
4
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
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
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
Refactoring • For simpler design
• For maintenance\upgrade
later
• MustHave task in your
DoneDefinition checklist
• Invest in patterns and best
practices
Learn more: http://www.refactoring.com/
Image: http://www.testically.org
8
Development Flow
Requirement Analysis
UI Mocking
•Customer discussion
Design Draft
•Design Discussion
Code the skeleton to
test the design
Coding in team
Refactoring and
Refinement
Build the increment
$
DevTeam PO
Collaboration:
Steps:
Artifacts: As a super user,
I want to …
A
B
IDo
Interface IDo{
//TODO …
}
Class A{
//TODO …
}
Class B:IDo{
//TODO …
}
Note: 1. TDD|BDD|AMDD can be used or not
2. Images are for illustration only
Interface IDo{
//TODO …
}
Class A{
method1(){
//Mr. A codes here
}
}
Class B:IDo{
method1(){
//Mrs. B codes here
}
}
Class C{
}
$
PO
9
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
Evolution of Models
11
com.myapp.Models
com.myapp.Views
com.myapp.Controllers
Sprint 0
updated story
V1
M1
IDo C1
V1
M1
IDo C1
V2
M2
Sprint 1 Sprint 2
Product
Backlog
Items burnt
Items burnt
Initial Architecture Model1 Model 2
“Continuous” Architecting Sprint #1: without layering
12
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
“Continuous” Architecting Sprint #2: refactoring to layers
13
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
“Continuous” Architecting Sprint #3: architecting “on the go”
14
Presentation Tier Application Layer Business Layer Data Access Layer Data Tier
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
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
