Simple design


Published on

This presentation shows some core ideas of simple design which helps agile teams collaborating in their development effort.

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Simple design

  1. 1. Simple Design andDevelopment Strategy for agile teams Duong Trong Tan
  2. 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. 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. 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. 5. Simplicity Rationale behind Simple Design• "Do the Simplest Thing that Could Possibly Work“• "You Arent 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. 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. 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. 8. Refactoring• For simpler design• For maintenanceupgrade later• MustHave task in your DoneDefinition checklist Learn more:• Invest in patterns and best practices Image: 8
  9. 9. Development Flow $ $Collaboration: PO DevTeam PO UI Mocking Design Draft Code the RefactoringSteps: 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 hereArtifacts: 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. 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. 11. Evolution of ModelsProduct Items burntBacklog Items burnt updated story V1 V2 V1com.myapp.Models IDo IDo C1 C1 com.myapp.Views M1 M2 M1 com.myapp.ControllersInitial Architecture Model1 Model 2 Sprint 0 Sprint 1 Sprint 2 11
  12. 12. “Continuous” Architecting Sprint #1: without layeringPresentation Tier Application Layer Business Layer Data Access Layer Data Tier 12
  13. 13. “Continuous” Architecting Sprint #2: refactoring to layersPresentation Tier Application Layer Business Layer Data Access Layer Data Tier 13
  14. 14. “Continuous” Architecting Sprint #3: architecting “on the go”Presentation Tier Application Layer Business Layer Data Access Layer Data Tier 14
  15. 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. 16. References• Agile Alliance, Agile Manifesto• H. Takeuchi & I. Nonaka, The new new Product development game, Harvard Business Review, 1986.• M. Fowler, Is Design Dead?• 16