Pragmatic Architecture for Agile Teams
1 like484 views
The document discusses an 'all hands on deck' approach to architecture for agile teams, emphasizing collaboration and the importance of balancing design strategies. It suggests that architecture should be a collective responsibility and highlights the need for effective documentation to reduce misunderstandings. Key themes include emergent design, making local decisions, and engaging with users and domain experts.
Pragmatic Architecture for Agile Teams
- 1. "All Hands on Deck" Pragmatic Architecture for Agile Teams /Janne Sinivirta @v3rtti
- 2. Outline Where are we now and why? How can we be better? 1. Balance 2. "All Hands on Deck" 3. Team vs Organization 4. Documentation
- 4. Where are we now?
- 5. Conspiracy?
- 7. How can we be better? 1. Balance
- 8. BDUF vs. YAGNBig Design Up Front vs. You Aren't Gonna Need It * see "Balancing Agility and Discipline" by Barry Boehm and Richard Turner
- 9. MVP and Architecture Agile is all about emergent design Architecture gives the code a place to grow Designing architecture only for MVP is short-sighted - Uncle Bob Martin Architecture from tests only .. is horse shit!
- 10. The Dilemma of Last Responsible Moment Recognize hard problems Start early and prototype
- 11. How can we be better? 2. All Hands on Deck
- 12. In Hurry to Wait
- 13. Team Decisions Architecture is too important to be left for the architect.
- 14. Modern Architect
- 15. Kaizen Optimizing the organization and the value stream.
- 16. Users and Domain Experts Genchi Genbutsu (現地現物) Go and see for yourselves! Matching users mental model "Future proofing" with crazy ideas
- 17. How can we be better? 3. Team vs. Organizatio n
- 18. Local and Fast Allow local decisions Ensure feedback both ways
- 19. Conway's Law
- 20. No organization There's no organization. Just people. Get to know them!
- 21. How can we be better? 4. Documentation
- 22. Basics Who's the reader? Code as forward thinking documentation Document relationships that are not visible from code
- 23. Must-have documents Domain Dictionary Aim for common language in team Reduce misunderstandings Don't conquer all with single dictionary Create with stakeholders Aliases that combine multiple terms/concepts
- 24. Must-have documents External integrations diagram Created with PlantUML
- 25. Must-have documents Internal component diagram Created with PlantUML
- 26. Must-have documents Domain Model as Code https://github.com/NitorCreations/DomainReverseMapper
- 27. Must-have documents Domain dictionary Internal component diagram External integration diagram Domain model as code Decision log
- 28. SummaryDesign enough, early enough Architecture is a team responsibility "See for yourself!" is essential in good design Document things that are not visible from code
- 29. Thank you! Questions? Janne Sinivirta / @v3rtti