Pragmatic Architecture for Agile Teams
-
Upload
janne-sinivirta -
Category
Software
-
view
349 -
download
4
description
Transcript of Pragmatic Architecture for Agile Teams
"All Hands on Deck"
PragmaticArchitecture
for Agile Teams / Janne Sinivirta @v3rtti
OutlineWhere are we now and why?How can we be better?
1. Balance2. "All Hands on Deck"3. Team vs Organization4. Documentation
Forgotten Architecture
Where are we now?
Conspiracy?
Bad Rapfor Architecture
How can we be better?
1. Balance
BDUF vs. YAGNIBig Design Up Front vs. You Aren't Gonna Need It
* see "Balancing Agility and Discipline" by Barry Boehm and Richard Turner
MVP and ArchitectureAgile is all about emergent designArchitecture gives the code a place to growDesigning architecture only for MVP is short-sighted
- Uncle Bob Martin
Architecture from tests only .. is horse shit!
The Dilemma ofLast Responsible
MomentRecognize hard problemsStart early and prototype
How can we be better?
2. All Handson Deck
In Hurry toWait
Team Decisions
Architecture is too important to be left for the architect.
Modern Architect
Kaizen
Optimizing the organization and the value stream.
Users and DomainExperts
Genchi Genbutsu (現地現物) Go and see for yourselves!Matching users mental model"Future proofing" with crazy ideas
How can we be better?
3. Team vs.Organizatio
n
Local and FastAllow local decisionsEnsure feedback both ways
Conway's Law
No organization
There's no organization. Just people. Get to know them!
How can we be better?4. Documentation
BasicsWho's the reader?Code as forward thinking documentationDocument relationships that are not visible from code
Must-have documentsDomain Dictionary
Aim for common language in teamReduce misunderstandingsDon't conquer all with single dictionaryCreate with stakeholdersAliases that combine multiple terms/concepts
Must-have documentsExternal integrations diagram
Created with PlantUML
Must-have documentsInternal component diagram
Created with PlantUML
Must-have documentsDomain Model as Code
https://github.com/NitorCreations/DomainReverseMapper
Must-have documentsDomain dictionaryInternal component diagramExternal integration diagramDomain model as codeDecision log
SummaryDesign enough, early enoughArchitecture is a team responsibility"See for yourself!" is essential in good designDocument things that are not visible from code