Arch factory - Agile Design: Best Practices
4 likes1,033 views
This document provides guidance on agile architecture and design principles. It emphasizes that agile design is about responding quickly to change for customers and teams through transparency, lightweight processes, and continuous learning. Key principles discussed include designing incrementally without large upfront design; getting early and continuous feedback; delaying commitment and complexity; and maximizing evolutionary design through reversibility and packaging. The document also covers topics like testing, distributed teams, and delivering frequently.
Arch factory - Agile Design: Best Practices
- 1. Track: Architecture Leadership Agile Design Best practices We know that it is possible. Igor Moochnick Principal IgorShare Consulting igor@igorshare.com Blog: www.igorshare.com/blog 1
- 2. Wireless Access 1. Connect to the “Cambridge” network 2. Open a Browser 3. In Logon page use the code: af609 2
- 3. A/agile? L/lean? It’s not about: • Methodology • Tools • Games • Protocols • Rituals • Manifests • Etc… It’s about • doing the “right” thing for your customers and your team • Transparency
- 4. Am I agile? Agile means the ability to respond quickly to any change • Follow new business opportunities • Reflect rapid market changes or challenges Lightweight It has nothing to do with the software development, but it really helps to rapidly exploit business potential You have to have Agile company to really succeed • If your software team is agile and produces a ton of features but the sales and the marketing teams are not performing – it’ll not help you to grow your revenue as quickly as you’d like
- 5. Assumptions 1. Life is unpredictable 2. Doesn’t matter what you do, the statement #1 still holds true 3. Customers are unpredictable – deduction from #1 4. Our goal is to make it safely to the delivery while reacting to the consequences from statement #1
- 6. Agile design is here to address … How to move forward without having all the requirements flushed out How to isolate the “unknowns” and capitalize on “known” How to create the boundaries between the “stable” and “unstable” How to make your systems resilient to change How to make your systems accommodate constant and continuous changes
- 7. Agile design helps you to … Move forward without knowing the final destination – no design upfront Accommodate “continuous design” Capitalize on learning Socialize and Distribute the design – important for distributed teams Get early and continuous feedback Achieve flexible delivery options Provide sustainable development
- 8. Requirements Prioritized backlog • Allows you to make decisions on what and when should be done Track progress (lifecycle of a requirement) Ownership
- 9. Redesign – self-fulfilling prophecy Increased complexity of the code reduces productivity which leads to a “ahh… screw it and let’s redesign everything” mentality Reduced productivity leads to adding developers which increase the complexity faster “Clean Code” NDC 2010 – “Uncle” Bob Martin
- 10. Backlog management Priority/Order “Initial estimates are off by factor of 4.” – from 1980 popularized by Steve Assignments McConnell Estimates “Software Engineering Economics” – Barry Bohem (1981)
- 11. Transparency - Feedback Customer Done, Done, Not Started In Progress Testing Review Done Story #1 Story #2 Story #3 Story #4 Story #5 Story #6 Story #7 Story #8 Story #9 Story #10
- 12. Kanban Board TechEd 2011 “Yes We Kanban”
- 13. Design No large design upfront • Not everything is known ahead of the time and will be discovered later • Design continuously – design hat is always on KISS/YAGNI/DRY Delay commitment and complexity Simplicity is hard Avoid “Architect Hubris” • If we just build the framework upfront, coding will be easy… Harvest Abstraction • Make any abstraction earn its existence
- 14. Basic Agile Mindset • Never get blocked • Decouple yourself from the others • Abstract the dependencies • Mock or Stub the unknowns • Feed your assumptions into evolving design • Incremental improvements • “First make it work, then make it right, then make it fast”
- 15. Development Orthogonal Code • Separation of Concerns • Cohesion • Coupling Don’t Repeat Yourself Principle (DRY) Don’t build frameworks Design for Testability
- 16. Composite Application Loosely coupled but cohesive Inversion of Control • Don’t call me, I’ll call you • Seamlessly swap one implementation with another Dependency Injection • “new()” is a form of tight coupling with inherent knowledge • Constructor Injection • Properties Injections
- 17. SOLID Development Principles (classes)
- 23. Coding Katas Effortful study means constantly tackling problems at the very edge of your ability. Stuff you may have a high probability of failing at. Unless you're failing some of the time, you're probably not growing professionally. You have to seek out those challenges and push yourself beyond your comfort limit. – Coding Horror (Jeff Atwood)
- 24. Refactor Relentlessly Design reflectively The quality of a design is largely the accumulative sum of many small decisions “Clean the dishes after cooking” • Bad names • Duplication • Big classes • Long methods Software entropy is the enemy!
- 25. “Boy scout” Rule “…Commit your code in a better shape than the one it was when you started working on it. “ – “Uncle” Bob Martin
- 26. The Last Responsible Moment “…delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. “ – Mary Poppendieck
- 27. Decide when to Decide Make decisions at the right time Utilize continuous learning Think ahead, yes! Act ahead, no! • Don’t act on speculative design • Keep a queue of design ideas and possible refactorings Don’t go past the Last Responsible Moment • Be cognizant of outstanding design decisions • Some decisions have to be made earlier than others
- 28. Reversibility “If you can easily change your decisions, this means it's less important to get them right - which makes your life much simpler. ” - Martin Fowler
- 29. Where Reversibility breaks • Dependencies on external teams or external experts • Publicly published interfaces • Too late – other components may force your hand • It’s important to decide when to decide!
- 30. Design Feedback • SMELL test • Mockups for customers • Any Design is theory until proven • If you don’t know what to do next, Spike It! • Don’t keep bad design • Don’t be afraid of modeling but stop it as soon as you stop learning
- 31. Maximizing Evolutionary Design If possible, only divide teams by feature • Externally facing API’s are NOT reversible Be Cautious when building Frameworks Persistence Ignorant Domain Models Delay the Database Model Presentation / Behavior Separation in the User Interface
- 32. Package Cohesion Principles The Release Reuse The granule of reuse is the REP Equivalency Principle granule of release. The Common Closure Classes that change together are CCP Principle packaged together. The Common Reuse Classes that are used together CRP Principle are packaged together.
- 33. Package Coupling Principles The Acyclic Dependencies The dependency graph of packages ADP Principle must have no cycles. The Stable Dependencies SDP Depend in the direction of stability. Principle The Stable Abstractions Abstractness increases with SAP Principle stability.
- 34. Development feedback? • Continuous integration • Continuous deployment • Unit tests • Code coverage • Test automation
- 35. Testing • When do we start testing? • Do we really need it? • Do we test the right thing? • What does the test testing? • Do we know what code is tested? Coverage? Really? • If the test fails – what does this mean? • Do we know what failed?
- 36. Make your code easy to test “I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes, it’s not as good as you think it is, and whether you know it or not, you're paying a price for it.” – Michael Feathers
- 37. Tests are all about confidence
- 38. Improve the Testability of the code Easy to test the classes in the system except for the edge Isolate the Ugly stuff (the hard to test things) Some things are hard to test User interface is hard to test – use MVP, MVC, MVVM, etc… Data Storage is hard to test – use ORMs Use Mock frameworks – nMock, Moq, etc… Dependency Inversion Principle • Code to the interface, not the implementation
- 39. Distributed Design Socialize the design Know the why Collectively challenge the design every day Talk about the design Keep the team abreast of changing design strategies The “This is the way we do it” moment
- 40. Distributed development Separation of concerns Hide responsibility Abstract external dependencies Decoupling teams Self-sustained and self-sufficient teams If possible, only divide teams by feature • Externally facing API’s are NOT reversible Transparency on interfaces and contracts – demos and unit tests
- 41. Work Vertically by Feature Design vertical slices of deliverable functionality All design work should be traceable to immediate business need • Includes architectural infrastructure • “Pull” Design versus “Push” Design Minimize rework by integrating early • Test early • User feedback early • Deployment feedback early • Shorten the time between doing and verifying “Code Leaders and Beautiful Teams” – Roy Osherove
- 42. Delivery • Instant deployment • Constant deployment
- 43. About design of APIs • Convention over Configuration • “5 minutes out-of-the-box experience” • "design away" common problems rather than documenting workarounds • Read more on Developer’s Experience (http://blog.oshineye.com/2011/05/what-is-devexp.html) • Programmers are People too (http://www.natpryce.com/articles/000732.html) • Affordances and Design (http://www.jnd.org/dn.mss/affordances_and_design.html)
- 44. Thanks for ideas Martin Fowler – Is Design Dead “Uncle” Bob Martin – Principles of Agile Design Jeremy D Miller – How Design Gets Done on an Agile Project Roy Osherov Others …
- 46. Thank You Sponsors ! {CodeRight}
- 47. http://ArchitectFactory.com/Survey.aspx Help make a better event - Complete a Survey!