1. No category

Tema
Agiludvikling
Verden i dag er i konstant forandring, og kompleksiteten
i virksomhederne er stigende. Årsagen er i høj grad
teknologien, som på få år har forandret den måde, vi
kommunikerer og arbejder på i virksomheder, såvel som
i fritiden. Fleksibilitet er fremtidens nøgleord, og for at
udvikle it-systemer til denne fremtid skal man bruge en
fleksibel fremgangsmåde. Derfor arbejder vi agilt.
Introduktion til
agil udvikling
I maj 2014 udtalte David Mitchell Smith, Vice President og Gartner Fellow, ved en Gartner-konference, at
fleksibilitet og agilitet var de væsentligste kvaliteter ved fremtidens it-systemer – ikke sikkerhed,
stabilitet eller pålidelighed, som ellers før har været i centrum. Årsagen er, at uden fleksibilitet og agilitet bliver
gevinsterne ved de øvrige karakteristiska slet ikke realiseret til fulde. Så sikkert, stabilt
og pålideligt, ja, men på en fleksibel og agil måde.
At udvikle agile systemer kræver agile udviklingsmetoder, hvoraf den nok mest kendte er Scrum. I d60 arbejder vi også agilt, men efter vores egen metode, som vi kalder Bedrock. Bedrock baserer sig også i nogen grad
på Scrum, men går videre i forhold til projekthåndteringen og sikring af samarbejde med eksterne organisationer.
I dette tema ser vi på agil udvikling fra forskellige vinkler og nogle af de ændringer, det medfører i arbejdsformen og indstillingen. Agil udvikling er grundlæggende anderledes, men på mange måder mere et mindset,
man skal indstille sig på, end en metode. Det handler om at give slip på den langsigtede datailplanlægning og acceptere at have lange planer, men spille på den korte bane.
Agile it-løsninger
Agil udvikling dækker over en række forskellige projektmetoder. Kernen i den agile tilgang er korte
udviklingssprints og løbende leveringer, hvilket står i skarp modsætning til de vandfaldsmodeller, man
ellers i mange år har anvendt til it-udvikling.
Den væsentligste årsag til at udvikle software efter agile metoder er ganske enkelt, at det er nemmere
at sikre, at det er den rette løsning, vi leverer, og at løsningen virker – både sammen med de øvrige
systemer og for de brugere, der skal anvende den. De hurtige leverancer betyder, at man hurtigt får syn
for sagen så at sige og dermed også hurtigt kan høste værdien af
løsningen.
Den rette løsning
Engang var computeren en rettelaksfri skrivemaskine på arbejdspladsen. I dag er den en integreret del
af vores processer og arbejdsliv. Det gør det væsentligt mere kompliceret at designe software, idet
resultatet skal indgå i et komplekst netværk af mennesker, systemer og processer og kunne tilpasses
løbende, når verden forandrer sig.
At udvikle den rette løsning bliver af disse årsager en mere kompliceret opgave, og ikke en der på
forhånd kan designes i detaljer, fordi:
Det er sværere at forudse problemer og faldgruber, fx i integrationer til andre systemer,
brugere eller arbejdsgange
Løsningerne skal passe til den aktuelle situation, men samtidig også være tilpasselige og
fleksible, så de passer i morgen
Ændringsønsker vil altid opstå, men er sværere at implementere i færdige designs, fordi
de kræver omfattende tilretning
Dette, kombineret med det faktum at teknologien udvikler
sig i rivende hast, betyder, at ”den rette løsning” er en løsning,
som kan vokse, tilpasse sig og skaleres i takt med virksomhedens udvikling. Det er ikke en løsning, som er to år
undervejs og skræddersyet til virksomhedens virkelighed to
år tidligere.
følelse af tryghed. Det vigtigste er, at alle til enhver tid er
enige om målene.
Agil udvikling er brugerdrevet og sker i løbende samarbejde med brugerne og med regelmæssige leverancer, som
implementeres i virksomheden. Det betyder, at størrelsen på
hver levering er overskuelig, at leverancen testes i praksis
med det samme, og at løsningen implementeres løbende
som en naturlig udvikling i medarbejdernes hverdag. Og så
kan den også nemmere tilrettes, hvis teori viser sig at være
noget andet end praksis.
Planlægningshorisonter
I projektmetoder som Prince2 ser man på et projekts
omfang og risikoprofil for at fastslå længden af faser. Agil
udvikling er baseret på korte sprints af omkring 1-4 ugers
varighed. Pointen med de korte sprints er kun at arbejde i
den umiddelbare fremtid. Alle sprints afsluttes med evaluering, demonstration, videndeling og implementering.
Hermed bliver løsningens bæredygtighed jævnligt
afprøvet.
Agil udvikling er med korte planlægningshorisonter og
løbende leverancer langt bedre til at levere it-løsninger til
virksomhedernes vilkår end de traditionelle metoder er, og
samtidig give værdi kort efter hver release.
Forskelle mellem metoderne
Som Klaus Nielsen påpeger i artiklen ”Build the Right Product”, er agil udvikling ikke blot en metode, men også et
mindset. For mange projektledere, som for eksempel har
arbejdet med Prince2 i mange år, vil det være lidt et leap of
faith at kaste sig over agil udvikling. Det kan virke usikkert,
uplanlagt og tilfældigt, men det er faktisk det modsatte, der
er tilfældet. Når det kommer til softwareudvikling giver detaljerede kravsspecifikationer en falsk
Agile metoder indeholder samme skridt og planlægning, som de mere traditionelle metoder, men tilgangen er
bare lidt anderledes. Her er et par forskelle.
Beskrivelse er løsningen
Agile metoder arbejder med user stories frem for
kravsspecifikationer. En user story udvikles af – eller med brugeren/kunden og beskriver en særskilt funktionalitet
eller feature, systemet skal have. Alle user stories prioriteres
ud fra forretningsmæssig værdi holdt op i mod udviklingstiden. Hvilke user stories, der er vigtigst at gå i gang med,
bliver dermed en vurdering af omkostninger kontra gevinst.
En eller flere user stories bliver herefter udviklet i et sprint.
Fordelene ved user stories frem for faste kravsspecifikationer er:
Stor fleksibilitet når problemer eller muligheder
opstår, idet omprioritering og vurdering er en
naturlig del af processen
Høj grad af brugerinddragelse sikrer, at løsningen
passer til hverdagen og behovene
Kunden får nemmere ved at styre projektet, fordi
det ikke kræver viden om it, men alene viden om
processer og behov i virksomheden
Løbende implementering
Hele ideen ved agil udvikling er den løbende implementering og ibrugtagen. Den agile tankegang er funderet i, at
man ikke kan tænke sig til successen. Der skal hurtigst muligt
laves en prototype, så man kan afprøve ideerne i praksis og
sikre, at alle taler om det samme. De virkelige krav har det
først med at dukke op, når produktet går i noget, der ligner en
beta-version.
Løbende implementering sikrer:
at erfaringer hurtigt bliver gjort og opsamlet, så
alle bliver bedre
at medarbejdere gradvist introduceres til nye
processer og værktøjer, og overgangen dermed
bliver naturlig i virksomheden
at risikoen ved projektet minimeres, idet alle
teorier, antagelser og funktionaliteter løbende
bliver
afprøvet i praksis, ikke kun på tegnebrættet
Mindre risiko, større udbytte
Helt kort vil jeg hævde, at agil udvikling sikrer, at skalaen af
projekter/faser aldrig vokser sig uoverskueligt stor. Funktionaliteten testes og verificeres først i udviklingsfasen og
herefter i det kørende miljø, så risikoen for store fejl i
implementeringen er lille. Det betyder, at fokus er på
produktet lige nu. At systemets værdi og anvendelighed
testes lige nu. At ændringer og tilpasninger kan foretages
lige nu.
For et firma, der har arbejdet agilt i hele sit liv, er det svært
at forholde sig objektivt til emnet. Der er dog ikke meget
tvivl om, at agil udvikling er kommet for at blive. Metoden
giver bedre og billigere løsninger, minimerer risici og er
utvivlsomt den nemmeste måde at sikre et projekts
bæredygtighed løbende, idet man tager løsningen i brug
løbende og dermed undgår at spilde tid på at udvikle det
forkerte.
Med kortere planlægningshorisonter og løbende implementering bliver løsningerne afprøvet i praksis med det
samme. Viser det sig derfor, at forretningsværdien er mindre end forventet, og projektet derfor
stoppes, vil man stadig sidde tilbage med et udbytte i
form af allerede leverede funktionaliteter. Dermed er man
altid blevet mere end blot en erfaring rigere.
Build the Right Product
Dual MBA holder, Klaus Nielsen, is the author of the book “I Am Agile”, in which d60 is used as a
case example in agile development. In this article, he shares some of his findings on agile
development and the difference between doing agile and being agile.
When I was very young, the world of project management was ruled by plan-based methods,
and Royce's waterfall approach was considered the only valid best practice. When I was a bit
older, Bohem’s spiral development method saw the light of day and in the years to come an
array of so called agile methods arose to battle the plan-based methods. Some may argue that
Agile is just a new notion for reinvented old practices. This might be true to some extent, but
most Agile methodologies, tools and techniques include values, morals and principles that are
the key essence of being Agile.
Focus on the Product
Working plan-based or agile is very much about building the right product. Building the right
product too often comes down to applying practices, tools and techniques. In agile a recent
survey by Version One (2012) of agile techniques employed were retrospectives, value stream
mapping, velocity, iteration planning, release planning, planning poker, refactoring and such
among the top contenders.
A lesson learned from World War II on the Cargo Cult also highlights some of the
important key points from working agile, i.e. that scrum boards and practices alone do not
enable us to build the right product. Agile is a mindset; a diverse culture.
The Agile Manifest
Agile practices are based upon the four values found in the
sacred agile manifest developed on the slopes of Utah in
2001:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The manifest is found throughout the many different agile
practices. The agile manifest is then again explained in
greater details in the twelve principles of Agile software
(Link). In 2005, a group headed by Alistair Cockburn and Jim
Highsmith wrote an addendum of Project Management
principles, the Declaration of Interdependence to guide
software project management according to agile development methods.
Doing vs Being agile
Now we have established the practices, the manifest and
principles but still lack the mindset and culture to build the
right product. Some may apply agile as a process and practice
which means learning the practices and applying them
without knowing the mindset and principles to tailor them and how to select the best practices.
But with agile as a mindset and culture, we must inter- nalize
the right mindset, principles and culture which makes you
able to tailor and apply the right practices in different situa-
tions. So top-down approach with outset in practices is
doing agile while bottom up approach based upon the
mindset and culture is being agile.
Agile or Fixed Mindset
When it comes down to the mindset, Stanford professor
Carol S. Dweck is one of the world’s leading researchers in
the field. According to Dweck (2007) you can have a fixed
or a growth/agile mindset. Research shows that mindset
can influence how you determine goals, reactions to failure,
belief about effort and strategies and attitudes toward
others’ successes.
Fixed mindset approach involves using iterations where
discovery and learning is not the main intent. You tend to
avoid failure, focus on schedule, stick to what you know
and don't welcome change. Not changing requirements
but change how things are and work. You can still build the
right product with a fixed mindset. In my line of work, a
fixed mindset is often combined with practitioners doing
agile.
The growth or agile mindset approach to using iterations is
where discovery and learning is the main intent. This
implies emphasis on continuous learning, embracing challenges, not being afraid to fail and elicit feedback.
With an agile mindset, you can build the right product far
better than anyone else. Combine this with being agile and
you will see the benefits agile has to offer.
Responding
to change
Agile
We’re getting smarter
We are uncovering better ways of developing software by doing it and helping
others do it. Through this work I have come to value being agile over doing agile.
Through this work, I have come to value the agile mindset over the fixed mindset.
Whether we value one or the other, it is never too late to learn.
I started this journey in the 1970s and conclude here in 2014 with my 2 cents of
know-it-all in a world still controlled by the evil Royce but where the agile mindset
and culture more than ever can rock the boat with any software development
approach, so go out there and build the right product now!
About the author
Dual MBA holder Klaus Nielsen holds PMP, PMI-RMP and PMI-ACP credentials from
the Project Management Institute, Scrum master and ICAgile certified and is the
founding partner of Global Business Development in Denmark and associated
lecturer in Project and Program Management at the IT University of Copenhagen.
Klaus has over 10 years of project and program management experience in managing and delivering complex, high-visibility Information Systems projects and
programs. Recently Klaus has written the book "I am agile" and a number of
articles within project management. He can be reached at [email protected]
Customer
collaboration
Introduktion til Bedrock
I d60 arbejder vi agilt efter vores egen leverancemodel, som
vi kalder Bedrock. Bedrock er baseret på elementer fra
Scrum, kombineret med erfaringer omkring hvordan man
bedst håndterer it-udvikling, når to organisationer skal
arbejde sammen.
Bedrock sikrer, at de løsninger, vi udvikler, lever op til vores
kunders strategiske fokus og løbende implemente- res og
forankres hos de medarbejdere, der skal bruge dem. Leverancemodellen er baseret på agile principper og inspireret af
Scrum-metoden.
Med Bedrock har vi operationaliseret vores viden om projektstyring og leverancer, så vi kan sikre en effektiv leverance på
et højt niveau. Bedrock omfatter alt fra kommunikation,
rollefordeling og dokumentation til videndeling, test og de
rammer og normer, vi anvender, når vi udvikler vores
løsninger.
Vores kunder oplever:
At være helt tæt på udviklingsprocessen
At være i stand til at styre prioriteringen løbende
Hyppige leverancer af ny funktionalitet
Roller og ansvar i centrum
I Bedrock sammensætter vi teamet ud fra opgavens
indhold, kompleksitet og omfang, således at tid og ressourcer afsættes og anvendes optimalt under hele projektforløbet. Alle teamets medlemmer har klart definerede
roller og ansvarsområder, som er beskrevet i Bedrock.
En af de væsentligste årsager til at sikre en klar projektorganisation og proces er forventningsafstemningen. It-udvikling kræver, at både kunden og leverandøren investerer
en vis mængde tid i projektet – både før og under projektforløbet. Det er vigtigt at kunne afsætte denne tid fra
starten for at sikre fremdriften i projektet.
Når projektorganisationen er på plads, opdeles projektet i
sprints af 2-4 uger med løbende prioritering, leverancer og
review. I tæt samarbejde med kunden sikrer vi estimering
og værdiansættelse af de enkelte leverancer, så kunden kan
prioritere, hvilke opgaver vi skal løse først. Heri ligger
styrken ved agil udvikling. Det giver hurtige resultater og
sikrer maksimal mulighed for at styre projektets videre
udvikling.
Dynamiske behov
Agil udvikling er nyt for mange, men det er den
bedste måde at levere projekter på fordi:
Teknologiske muligheder ændrer sig
hastigt
Organisationer er dynamiske
Markeder og muligheder ændrer sig hele
tiden
Erfaring og brug af løsninger skaber
muligheder og ændringer i behov
undervejs
Daily
Follow up
Project
Cycle
Når behovene er i konstant forandring, skal
kravene til løsningen være det samme.
Sprint
Management
2-4 uger
Backlog Management
Product
Sprint
Backlog
Backlog
Initialisering
Indledningen af projektforløbet med
analyser, prioritering, fastsætning af
rammeforhold og praktisk opstart.
Udvikling
Udviklingssprints, estimering,
videndeling mv.
Handover
Dokumentation, release management,
support mv.
Interview:
Practicalities of a
Delivery Model
The d60 Delivery Model “Bedrock” is - as the name indicates - the foundation of all our projects. Bedrock
is developed by d60 and provides a guideline of best practices on how to start up, initiate, develop and
handover your projects. Bedrock is now fully introduced in d60 as our delivery model in all teams. A
Project Manager, Coordinator and BI
Consultant from d60 give their take on working with Bedrock.
Senior Project Manager, Stig Jæger Kronvold:
In developing Bedrock, we have focused on being fully compatible with e.g. Prince2, PMI standards or other stage/gate models. We have incorporated the best of models such as SCRUM and DSDM
into Bedrock taking into account the best of the classic project management
theories, and we constantly adapt according to the environment. In short, Bedrock is our way
of ensuring the success of the project.
We all know things change, and yet we have a need to plan and control aspects such as scope, schedule
and budget. In Bedrock, the aspect of constant change is built into the model without compromising
neither the controlling nor the management aspects of the project. We do this by working in short
sprints and focus on the foreseeable future.
For the past year, we have focused on implementing Bedrock
in all our teams. As useful or interesting as a delivery model
can be for a project manager, it also needs to be implemented –and adopted- by the project team. In this context, we
have decided to interview two sides that go hand in hand in
the process. On the one side, Camilla, project coordinator,
tasked with ensuring a proper implementation of the model.
On the other side, Olivier, Business Intelligence consultant
and primary target for the daily use of the model.
To start with, how have you experienced being involved in
establishing a new delivery model?
Olivier: A new delivery model brings change with itself, which
can easily disturb established procedures and habits. On the
other hand, it is also a priceless opportunity to rationalize
one’s processes, and maybe investigate how things can be
made to run more efficiently in daily operations. The opportunity to be part of a team trying out a new delivery model was
exciting, and very rich in learning. Change should not be
feared but embraced, and once one accepts that hiccups do
happen during the implementation, the end result is
very satisfying!
Camilla: Change is rarely associated with positivity – at least
not to start with. As a project coordinator, once you accept
this, you have come a long way in the process.
To embrace this you need to communicate. Transparency and
information mean everything and there can never be too
much communication. You need to foresee and be prepared
for every question there might be. When you finally think you
have all the answers, new ones will come. It is hard work,
but with change comes
opportunities!
How significant is it to focus on continuous
delivery?
Olivier: This is of course very dependent on the context a
team works within but, as a consulting company, it is in our
case highly relevant to provide the best stability and
flexibility to our customers. This means that we must be
able to understand their needs, work out a way to fulfill
these, and implement it. In an era where communication is
instantaneous and the world seems to change overnight,
every night, being able to adapt and evolve as quickly as
possible is not a luxury; it is a key component of one’s
competitive survival.
Camilla: It means everything. If we do not deliver within the
criteria set up by the customer, we do not succeed. We live
in a constantly changing world – a world where it is expected of us to predict the future in order to deliver sustainable
solutions. One way we do this, or at least try to, is by
estimation. Our goal is to overcome sudden change by
predicting a sprint. We do this by looking back on past
sprints to determine what we can expect in the current
sprint. When we know this, both our customers and
consultants focus on the same goal within the same frames
of flexibility.
One tool you use to grant this continuous delivery to the
customer is user stories, how does that work?
Olivier: User stories are quite self-explanatory. A user/customer comes to us with a “story”, which represents a need for a
new or modified feature. It is then translated into a main task,
describing the desired outcome and general work plan. This
is the end-result, the idea that needs to be concretized. This
user story then gets “children”, bite-sized tasks that can be
completed in around a day’s development. Each gets the user
story a step further toward completion. This way, one follows
the overall goal without missing sight of it, all the while
focusing on the more minute details of the implementation.
Camilla: During the sprint-planning meeting, every user story
is estimated and prioritized. This is necessary in order for the
customer and the consultants to keep an overview during
the whole sprint. The estimation gives an insight into how
big the story is. If the story is too big, it is broken down into
smaller tasks. We do this to make the tasks, and ultimately
the sprint, as transparent as possible for everyone involved. The prioritization
shows the customer how important a task is in order to
finish the sprint on time. The customer can always change
priority, but the team must have the final say in this,
because they are the ones that know the true complexity of
the task.
How does one avoid running wild (time used, feature creep)?
Olivier: Estimation. Experience. The whole task group participates in
investigating each user story and creating a work plan for it. Each story
is then split into tasks needed for completion. Each task gets investigated. What does it take to consider the task done successfully? What is
the preferred method? What are potential challenges? Once these
questions have an answer or qualified guess, it is much easier to answer
the main problematic: “How long will it take?” If the answer is still
unknown or too long, then the task probably can be split into still more
sub-components that are easier to ascertain. The idea is not to sign a
delivery contract. It is to understand the story enough as to limit
unexpected delays and accidents.
Camilla: It is important to make clear that we estimate. The consultants
commit to solving the user stories of highest priority with the knowledge that they have at that time. At the end of each sprint, we review
both the product and the estimations and make sure we identify
problems, if the estimations were incorrect. An estimation is a qualified
guess, and by reviewing sprints and sharing experiences we make sure,
that each new guess is even more qualified.
How does this model ensure both stability and flexibility for
the team?
Olivier: Our delivery model is based on weekly to monthly
sprints. This allows for great stability, all the while
enabling a short “idea to implementation” delay. Once such
an overview is built, it is also easier to work unexpected tasks
and challenges in. This mix allows our team to know what the
customer’s expectations are, while allowing the customer a
higher flexibility in task
prioritization and needs fulfillment.
Camilla: The consultants can model their sprint, taking into
consideration that a sprint always changes – in most cases,
time and prioritizing is an issue for both consultants and customers. Based on experiences from
previous sprints, the team has a clear idea of available
resources during the sprint.
As a conclusion, what would you say are the advantages and
challenges of this model?
Olivier: This model allows for a strong delivery process, where
changes are implemented quickly, effectively, and in accordance with the customer’s highest priorities. This means that,
while holding a great stability thanks to monthly planning,
the team is still free to focus on the best way to implement
a given story, as minute planning is allowed during the
daily operations. This however requires a strong cohesion
in the team, and pristine communication on all levels. This
means that the customer’s needs have to be correctly
understood, and that the tasks have to receive the attention they deserve in order to optimally evaluate them. Like
any other system, it only works if everyone is ready to do
his part!
Camilla: The biggest advantage is being able to deliver
quality to customers using the agile way, which means that
we are able to implement changes in a short time frame,
while satisfying the customer’s most acute needs. We
succeed when everyone involved in a project interacts and
moves in the same direction.
The challenge of course is that the agile way requires a fine
balance between transparency to the customer, and
flexibility to the team. One should not come at the price of
the other. Not every team benefits from the same process
in the same way. We sometimes need to adapt the model
to specific teams, and that is ok. As long as we deliver
quality.
Bedrock
og Prince2
Agil udvikling er det nye sort i it-branchen, hvor den traditionelle vandfaldsmodel gang på gang har vist sig at være
utilstrækkelig. Bedrock er d60’s egen agile leverancemodel;
Prince2 er ofte associeret med mere traditionelle projektmetoder. Men artiklen her postulerer dog ikke, at Prince2
arbejder med vandfaldsmodeller. Tværtimod betyder nyere
ændringer af Prince2, at modellen er fuldt kompatibel med
agile principper. Det er faktisk det, der er pointen.
I forhold til den mere praktiske tilgang til projekter
gennemgås forskelle mellem traditionelle metoder og agil
udvikling i artiklen ”Agile it-løsninger”. Her forholder jeg mig
mere til ligheder.
Prince2
Prince2 er udviklet af den britiske stat, oprindeligt til netop at
håndtere udvikling af it-systemer. I starten arbejdede man i
Prince2 med meget usmidige krav til aktiviteter, procedurer
og dokumentation, hvilket har givet modellen et lidt unfair
ry for at være en tung dinosaur. Den er dog løbende blevet
tilpasset og fremstår i dag i en form, som langt mere
anerkender problemerne ved vandfaldsmodeller og det
særegne i udviklingen af it-systemer, fx i det styrende
princip om tilpasning til projektmiljøet. Det betyder, at den
uden problemer kan kombineres med agile principper.
Projekt kontra leverance
Prince2 er en projektmodel og er dermed skabt til at tage
hånd om alle aspekter af et projekt. Bedrock er en leverancemodel, som skal håndtere vores arbejde som leverandører. Heri ligger også mange andre ting end den
enkelte leverance, men fokus i modellen ligger på leveringsniveauet af Prince2, idet agile modeller i særlig høj
grad fokuserer på leveringer – hele tiden.
Man kunne tegne det således, hvor de mørke kasser er Bedrock, og de lyse er Prince2:
Ledelse
Ledelse af et projekt
OPSTART
- Rammer og kontrakter
START AF ET PROJEKT
- Business Case
- Projektorganisation
- Erfaringsindsamling
Styring
Ledelse af faseovergang
OPSTART
- Observation og analyse
- Produktdesign
- Product Backlog
INITERING AF ET PROJEKT
- Styringsstrategier
- Projektplan
- Business Case
- Dokumentation
INITERING
- Prioritering af user stories
- Estimering
- Sprint Backlog
Levering
Projektafslutning
Styring af en fase
HANDOVER
- Dokumentation
- Release Management
- Overgang til support
Styring af produktleverancer
DEVELOPMENT
- User story breakdown
- Daily Scrum
- Test
- Evaluation
Præ-projekt
Initieringsfase
Leveringsfase
Som det ses, er der umiddelbart de samme faser i de to modeller, men hvor Prince2 følger en lineær projektfremgang, er
Bedrock baseret på kortere forløb, som gentages.
De tre kasser med initiering, development og handover i Bedrock kunne principielt alle lægges under punktet ”Styring af
produktleverancer” i Prince2, således at leverancerne blev leveret efter Scrum-principperne. Heri adskiller Bedrock sig dog fra
Scrum ved en bred tilgang til projekter og roller. Vi er ikke bare en kodefabrik, så for at få mest muligt ud af den viden, vores
konsulenter har om processer, data og forretning, har vi designet Bedrock til at sikre inddragelse og udnyttelse af denne viden.
Projektstyring
Et andet sted de to metoder kan forenes er i projektstyringen.
Bedrock gør faktisk Prince2-projektlederens rolle meget
nemmere.
Mange, som har arbejdet med Prince2, vil have hørt mottoet:
”Overvågning er godt, kontrol er bedre, razzia er bedst”, som
med halv alvor og halv ironi beskriver tilgang- en til dokumentation i Prince2.
I Bedrock har vi flyttet en stor del af fokus fra denne kontrol til
levering ved at automatisere dokumentationen. Funktionalitet/user stories nedbrydes til opgaver af omkring en dags
varighed, og tidsregistrering foretages dagligt på mindste
opgaveniveau. Det betyder, at kunden automatisk får ugentlige og månedlige rapporter med nøjagtig status og tidsforbrug på hver enkelt opgave.
Ved at nedbryde og registrere opgaver på mindste niveau
sikrer vi, at dokumentationen bliver en aktiv del af udviklingsprocessen, og at såvel projektleder som styregruppe til
enhver tid kan trække en opdateret statusrapport.
Håndtering af ændringer
I Prince2 er der ligeledes et større arbejde, der skal foretages,
når der opstår problemer eller ændringsønsker, som skal
bringes videre til styregruppen. Ikke blot er det meste dokumentation i denne forbindelse automatisk til rådighed, men
idet vi i Bedrock samtidig arbejder med korte
udviklingssprints efterfulgt af en funktionel leve- rance,
vokser problemerne (og konsekvenserne) sig sjældent så
store, at de ikke hurtigt kan beskrives og løses – uden på
anden vis at forsinke projektet.
Komplementære metoder
Prince2 og Bedrock repræsenterer to forskellige tilgange til
projekter, men kan sagtens sameksistere og samarbejde.
Man kunne endda argumentere for, at meget store projekter med fordel kunne køres som Prince2-projekter i de store
linjer, og faserne så kunne køres efter Bedrock.
Den væsentligste forskel er nok rollefordelingen. I Prince2
er projektlederen den dagligt ansvarlige, men i Bedrock
deles denne rolle af personer på begge sider af kunde/leverandør-forholdet. En Product Owner (PO) ved kunden har
ansvaret for at udvikle og prioritere user stories, mens
fremdriften hos leverandøren i højere grad er en teamindsats faciliteret af en projektkoordinator.
Så hænger man sig meget i titler, har vi et problem. Ser
man derimod blot på fordeling af ansvar og resultater, så er
Prince2 og Bedrock faktisk komplementære metoder.
Moduler
og løbende levering
Inden for Lean Manufacturing taler man om "flow" og "pull".
Det dækker over en produktions-pipeline, som initieres af
behov (pull) samt en uafbrudt, glidende proces (flow), som
sikrer, at der på ethvert givet tidspunkt er bevægelse i linjen,
og at der ikke ligger ting på lager.
Da vi som softwareudviklere er meget inspireret af Lean, er
det interessant at kigge på, hvilke ting vi kan gøre for at
understøtte softwareudviklingen for at sikre flow, hvor
parallellen til "noget på lager" er funktioner, som er udviklet,
men endnu ikke afleveret.
I denne artikel vil jeg gennemgå et par emner af teknisk
karakter, som kan bringe os tættere på en vaskeægte lean
proces med continuous delivery.
Continuous integration
Det har snart været alment kendt i to årtier, at man jævnligt
- måske adskillige gange om dagen - bør integrere sit
arbejde med "mainline" - altså den fælles linje som bør
være alle kodeændringers endelige destination. Dette
fænomen er kendt som "continuous integration", og det
kan ofte hjælpes på vej af en byggeserver, f.eks. TeamCity,
som er en maskine, der hele tiden sørger for at bygge og
køre tests på de forskellige branches, der måtte være.
Inden for de seneste år har vi som softwareudviklere
gennemgået en fantastisk udvikling, idet distribuerede
versionsstyringssystemer som f.eks. Git er blevet mainstream. Git (især kombineret med GitHub) tilbyder nogle
muligheder, som er særdeles velegnede til continuous
integration.
For det første så er det smertefrit at lave branches med Git,
hvilket medfører at det bliver naturligt at lave feature branches (det vender vi lige tilbage til...) - men derudover så er det
trivielt at gøre det, der i gamle dage hed "re-branching", altså
at merge mainline ud i den branch, man arbejder på. Dvs.
man kan som udvikler ganske nemt holde sin branch meget
tæt på mainline (eller "master", som det hedder med Git...).
For det andet så har TeamCity en funktion, som automatisk
kan "opdage" branches og bygge/teste dem på lige fod med
master. Derudover så kan GitHub auto-merge pull requests
og udstille resultatet som virtuelle branches, hvilket bringer
os ret tæt på en fuld automatiseret
continuous integration.
God test-disciplin
Generelt synes jeg, folk er blevet rigtig godt bevidste om,
hvor vigtigt det er at lave automatiserede tests af koden - jeg
oplever i hvert fald, at de fleste udviklere ganske naturligt
dækker udviklet funktionalitet godt af med unit tests. Min
egen erfaring er dog, at integrationstests, suppleret med
udvalgte unit tests giver et langt bedre fundament for at
udvikle software af høj kvalitet med et minimum af "klods om
benet"-effekt.
Her kan unit tests benyttes som verifikation af komplekse
beregninger, men jeg oplever alligevel ofte, at noget, der
startede som en unit test, udvikler sig til at være en integrationstest med visse afhængigheder erstattet af stubs, efterhånden som tiden går, og man erkender at units skal opdeles.
For at kunne lave løbende levering med korte intervaller er
det meget vigtigt, at man har gode tests på plads. De bliver
kørt af byggeserveren hele tiden, og det er dem, der skal
sikre, at man ikke skal bruge tid på alt for megen manuel
test i forbindelse med release.
Feature branch
I forbindelse med udviklingen af nye features er det en god
ide at lave feature branches, altså en branch til hver ny
story/task/bugfix, man tager fat på. Man bør lave en feature
branch, hver gang man forventer, at koden på et tidspunkt
mellem to commits IKKE vil være i stand til at blive released,
hvilket må antages at være ret ofte. Min egen hovedregel,
"better safe than sorry", kombineret med hvor nemt det er at
branche med Git, gør, at jeg anbefaler feature branches til alt.
Da man indimellem kan komme ud for, at det tager længere
tid end et sprint at færdiggøre en feature, så kan man evt.
drage nytte af feature toggle - altså en mekanisme i programmet, som kan bruges til at tænde/slukke for features vha.
konfiguration. Det giver sig selv, at det kræver lidt tilvænning
at implementere feature toggle, men hvis udgangspunktet er,
at der skal være mulighed for at konfigurere, hvorvidt den
pågældende feature er tilgængelig, og det ikke er en eftertanke, så er det i praksis ofte ganske nemt at
implementere.
Branch by abstraction
Til tider kan man få brug for at lave så store ændringer i
systemet, at det forekommer uoverskueligt at lave feature
branches og feature toggles til det - et eksempel kan være
en større refaktorering, som f.eks. ælter systemets arkitektur
rundt. Her kan man med fordel benytte sig af branch by
abstraction, som IKKE er branches, men som er en teknik,
hvor man først etablerer en abstraktion mellem den stabile
del af koden og den del, der skal rykkes rundt.
Når denne abstraktion er på plads, så kan man inkrementelt
migrere den del, der ligger bag abstraktionen. Jeg har f.eks.
selv været med at til at migrere et system fra at være en rig
klient med en direkte databaseforbindelse, til at have en HTTP-baseret klient-serverarkitektur ved i første omgang at indføre et request/response-lag i klienten, hvorefter request handlers kunne
flyttes til serveren en for en. Denne proces var tidskrævende
og forløb over en lang periode, men kompleksiteten var
overskuelig - grænsende til triviel - da arbejdet efter
etableringen af abstraktionen kunne udføres i takt med
andre opgaver i de forskellige områder af systemet.
Moduler
Der kan være mange grunde til at separere ting i selvstændige moduler - men hvor
det ofte forekommer naturligt at adskille ting, der teknologimæssigt eller funktionalitetsmæssigt tilhører forskellige områder, så kan det også
betale sig at adskille ting, der har brug for at bevæge sig i forskelligt tempo, da
løbende levering forudsætter, at man sætter kadencen efter det tempo, aftagerens
"pull" dikterer.
På den måde kan man undgå at forstyrre et stabilt område af systemet, som
sjældent har brug for tilføjelser eller ændringer, samtidig med at de mere dynamiske områder af systemet ikke bliver tynget af at være sammenflettet med noget
mindre dynamisk.
Helt overordnet så kan det efter min mening ofte betale sig at kigge på, hvordan
brugerne er organiseret - firmaer har separate afdelinger, fordi det giver mening at
organisere arbejdet med en vis grad af selvstændighed i hver afdeling, og denne
kendsgerning kan man ofte se afspejlet i systemers arkitektur med succes. Men ud
over de officielle afdelinger så kan der sagtens være nogle mindre udtalte
opdelinger i teams og subteams,
ansvarsområder osv., som med fordel kan gøres mere selvstændige i arkitekturen.
Append-only kode
Når man kommer helt ned i materien, så er der visse strategier, som kan vise sig at være meget fordelagtige at benytte for at gøre det nemmere at lave løbende levering. Personligt er jeg meget inspireret af de
principper, som Bob Martin beskriver med akronymet "SOLID". O'et i SOLID står for "Open/closed principle", som er den egenskab ved et kodedesign, at koden er "open for extension, but closed for modification".
Kort forklaret betyder det, at man kan tilføje funktionalitet til et system uden at modificere den eksisterende kode, dvs. uden risiko for at introducere fejl i den allerede afleverede funktionalitet.
Der er mange måder at realisere dette på, men helt generelt så kræver det, at man til en vis grad identificerer de akser, som systemet udvides i - hvis man f.eks. forudser, at der ofte skal implementeres nye søgefunktioner, så kan det måske betale sig at destillere frameworket omkring søgefunktionen og ophøje det til noget, der mere eller mindre dynamisk kan opsamle og aktivere sin funktionalitet - i simpel form måske blot via kode-refleksion, i mere ekstrem form som dynamisk indlæste plugins.
Jeg synes ofte, det kan betale sig at skelne mellem features og koncepter, hvor koncepter er ting, der
kræver ændringer til applikationens framework, og features er ting, der "hænges op" på frameworket. Her
vil det naturligvis være features, der kan implementeres efter append-only-modellen, såfremt konceptets
design tillader det, og features, der kan implementeres på denne måde, kan ofte leveres med meget fin
granularitet og dermed med kort ventetid fra ønske til idriftsættelse set fra aftagerens synsvinkel.
Aarhus
Søren Frichs Vej 34 A
8230 Åbyhøj
I d60 temaer sætter vores interne eksperter
fokus på udfordringer, løsninger og trends
indenfor it og forretning. Find flere temaer på
www.d60.dk/viden
København
Frode Jakobsens Plads 4, 2.
2720 Vanløse
Tlf. +45 32 11 66 60
[email protected]