l22 architecture and agile
DESCRIPTION
Með tilkomu agile hugbúnaðargerðar er hætt á að forritarar fórni hlutum sem voru sjálfsagðir í aðferðum eins og Waterfall og RUP en eiga fullt erindi í agile þó svo með öðrum hætti. Má nefna skjölun, en margir misskildu agile á þann veg að ekkert þarf að skjala. Skjölun er nauðsynleg þótt hún sé með örðum hætti, en svo er einnig með architecture. Í agile er nauðsynlegt að huga vel að architecture en einnig að átta sig hvað það er sem við skilgreinum sem architecture og hvað ekki. Í þessum fyrirlestri er fjallað um architecture og agile og hvernig þessir hlutir geta fallið vel saman. Með aglie teymum flyst mikið af ábyrgð á architecture til teymanna, en samt þarf að vera einhver sameinlegur strúktúr og sýn.TRANSCRIPT
Lecture 22Architecture and Agile
Agenda Software Development Evolution Architecture in Agile environment– Conflicts– Boundaries for xDD
Moving from Big Up-front Design Quantifying Risk– Risk Storming– Mitigation Strategies
Just Enough Design Introducing Architecture
Reading Brown 62 - 67
Software Development
Waterfall
RAD RUP Agile
Sequential ProcessAll design front-upProcess heavy
70s, 80sRapid Application Development80s, 90s
Rational Unified Process90s, 00s 00s, 10s
Rapid PrototypingPrototype not planProcess Light
Framework for iterative developmentCan be process heavy
Iterative and incrementalCan be process light
Architecture in Agile Environment
Architecture is about structure and vision
Agile is about flexibility
Is this not a Conflict?
Conflict #1 – Team StructureTraditionally a Chief Software Architecture defines the architecture for all to follow – large design documents
Chief Software Architect in his Ivory Tower
Big UpfrontSpecifications
Conflict #1 – Team StructureIn Agile, teams are small, self-sufficient with minimum overhead
But we still Architecture, don’t we?
Conflict #1 – Team StructureIn Agile, teams are small, self-sufficient with minimum overhead
SoftwareArchitecture SA
SA
SA
SA
SA
Team members form an Architecture Group
Conflict #2 – Process and OutputAgile teams favor responding to change over following a plan – no upfront designBut we still need Architecture, don’t we?
Boundaries for xDD
Test-, Behavioral-, Domain, and Resume Driven Development are not substitutes for Architecture
The architecture is about putting boundaries in place
Boundaries for xDD
We must define Architecture and the architectural drivers:
Functional Requirements
Quality Attributes
Constraints
Principles
Requirements drive architectureUser stories, acceptance tests, etc
Non-functional RequirementsScalability, performance, security, etc
Real-world constraintsApproved technology, people, standards etc.
Principles – Rules for consistencyLayering strategy, separation of concerns, patterns etc
Moving from Big Up-front DesignArchitecture is about stuff that hard or costly to to change
Core technology choicesOverall High Level Structure
Architecture is about defining high-level structure and put a vision in placeAgile teams need a framework and boundaries – and should be trusted to do the rest
Quantifying Risk
Risk management is crucial in agileNot addressing Risk can kill projects
Risk can be managed by separating probability from impact
Probability: How likely is this to happen?Impact: What is the negative impact if this occurs?
Quantifying Risk
Prioritizing risk
Use scale 1-5 (5 high) for probability and impact, then multiply
Risk Storming
Process for identifying Risk
Step 1: Draw some architecture diagramsStep 2: Identify the risks individuallyStep 3: Converge risk on the diagramsStep 4: Prioritize the risk
Risk Storming
Example risks:Data formats from 3rd party system changeExternal components don’t workExternal systems are not available in timeTechnical specification is vaguePeople are not cooperatingPolitics in the workplace
Mitigation Strategies
What can we do to prevent this or how can we correct this
Example strategies:
EducationPrototypesReworkAlliances, people issues
Just Enough Design
We are agile, do we need design?
Just Enough Design
The solution is to identify the need for design and do just that – not to little, not too much
StructureRiskVision
Just Enough Design
The solution is to identify the need for design and do just that – not to little, not too much
Just Enough Design
1. Structure• What: understand the structural elements and how they
fit together• How: Design and decomposition down to containers and
components2. Risk
• What: Identify and mitigate the highest priorities• How: Risk storming and concrete experiments
3. Vision• What: Create and communicate a vision for the team to
work with• How: Context, Container and component diagrams
Introducing Software ArchitectureArchitecture is necessary in software development
It needs to be communicated and accessible
People have limited time and a usually interested in other things
Introducing Software ArchitecturePractical suggestions
1. Educate People2. Talk about Architecture in
retrospectives3. Definition of Done4. Allocate the architecture role to
someone5. Architecture katas
Summary Agile is important today– Architecture needs to fit the methodology– Conflicts– Boundaries for xDD
Moving from Big Up-front Design Quantifying Risk– Risk Storming– Mitigation Strategies
Just Enough Design Introducing Architecture