evolution of architecture in agile projects
DESCRIPTION
TRANSCRIPT
Evolution of Architecture(I obviously mean „in agile projects”)
Paweł Lipiński
pawel@agileee:/etc$whoami
• based in Warsaw / Poland
• then >10 years in Java
‣ SCJP, SCWCD, SCBCD, SCEA
• i did: development, consulting, trainings, audits, architecture
• software and system architect for the last 4 years
• worked with: cowboy, quasi-RUP, FDD, Scrum (CSP), XP
• currently:
‣ developer & owner @ Pragmatists, doing a merge of Scrum&XP
• professional interests: (A)OO, agile, software quality assurance, languages
What’s this gonna be about
• baseline - what’s architecture in general and how do I see it in agile projects
• some principles of agile architecture what I think is important what helps what not to do
• how we try to implement it
Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
The best architectures, requirements, and designs emerge from self-organising teams.
agile manifesto, principles #2 & #11
Architecture
„Architecture” is a term that lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change.
Martin Fowler, PoEAA
From the perspective of change, the role of architecture in agile development becomes quite clear: a good architecture is responsive and will support agility; a poor architecture will resist it and reduce it.
Kevlin Henney, The role of architecture in agile development
so how should the architecture be?
should encourage change - so it must be extensible and modifiable
should promote quality - care for / ensure testability, readability, feeling of safety
promote creating value - make adding functionality simple, enable regular demos / reviews of new features
enable research and verification - developers should always be able to check different approaches, verify their ideas
be self-documenting - architecture lies in the code, the more readable it is at a high level, the less one needs to describe (often just the package names are enough to give high level description of architecture)
(some) principles of Agile Architecture
influenced by Dean Leffingwell, scalingsoftwareagility.wordpress.com
a team which codes the system, designs the system
conscious decisions need data - which appears / emerges during development
decisions should be made by the team - it increases responsibility and engagement / commitment
making decisions by several people increases probability of making better ones
for the architecture to evolve, the architect (as a role) must be aware of costs and consequences of changes - and these are known to the team only
choose the simplest architecture that can possibly work
if we suppose that architecture can evolve together with the development of the system, we can also suppose that it’s enough that it supports only what’s necessary NOW and what we’re absolutely sure is required (vs. YAGNI)
the simpler the architecture, the easier it is to control and grasp by the team
the bigger the team, the more true it is
if unsure, check it with code
evolution of architecture, design, code means constant refactoring, permanent trials and tests leading to the right solution
sometimes you need to check several things up to empirically verify which one is better
that’s the best way to gain knowledge and architectural experience
the one to build is the one to test
performance and stability tests verify correctness of architecture (eligibility in respect to nonfunctional requirements)
in order to find these kinds of issues, tests must be performed often (CI)
tests can lead architecture similarly as they do with design
if you know it, don’t pretend you don’t
some things can be safely assumed / decided on very early, so that big changes are not needed later
some things lie in experience and there’s not much sense in verifying them
sometimes the last responsible moment is just the very beginning of a project
if a decision is to be made, and we have complete data do make it, there’s no sense to pretend we don’t know what to do
architecture is a collaborative work
sometimes it just means a work done commonly within the development team
for big systems, with big/many teams it’s a subset of people
team members can change - it’s good to have developers there as well - they’re the ones that need to commit!
Nokia Test - it’s not agile if any part of a project is done by a single person
how’s that done in practice?
initial conceptevaluation
and changes
software development
systems architect architecture team:architect + developers
development teams
the concept is just a vision, not a BAUF
Architecture as a part of each iteration
Analysis Architecture Design Coding Testing Integration
Inspect & AdaptPragmatistsPriority: _____Release: _____
Notes:
Estimate:Number:
13As a Manager I want to
see statistics of progressof my projects
A statistic should contain:- project name and description- budget in € and %-tage of overall budget- progress as %-tage
2 15
8
architecture is just one aspect of a project, and just like any other is governed by the same forces and principles
iterativeness, communication, feedback, balance between decisions and risk enhance reactiveness to change
Architecture is not a document or some prescriptions, but an effect of a long-lasting process, which starts with initial concept, and then, during system’s development reacts to new-coming data and adapts to them.
It’s a message about current system state, a shared team’s knowledge being under constant evolution.
Architecture as such is a waste. It’s of no value to a client, but is an element of lowering costs of creating the actual value.
One of the more insidious and persistent myths of agile development is that up-front architecture and design are bad; that you should never spend time up front making architectural decisions. That instead you should evolve your architecture and design from nothing, one test-case at a time.
Pardon me, but that’s Horse Shit.
(...)
Don’t feel that TDD is the only way to design. On the other hand, don’t let yourself get too vested in your designs. Allow TDD to change your plans if it leads you in a different direction.
Robert C. Martin, ObjectMentor blog, „The Scatalogy of Agile Architecture”, 25.04.2009
Thank You(Q&A)
http://www.pragmatists.pl