GAP analyse: Agile projectmanagement en de PMBok aanpak voor kennisgebieden Project Integration, Scope en Time Management Karel Nijs, Ing.,
[email protected]
ABSTRACT
INLEIDING
Deze white paper gaat de kennisgebieden Integration
Project Management,
Project Scope Management en Project Time Management uit de PMBok vergelijken met de Agile manier van werken. Eerst
wordt
Agile
A
gile, ook “lenig” of “behendig”, beschrijft een conceptueel raamwerk voor softwareontwikkeling dat afwijkt van de standaard, meer rigide, manier van werken.
agility - A skill-related component of physical fitness that relates to the ability to rapidly change the position of the entire body in space with speed and
kort
uitgelegd en vervolgens kijken
accuracy.
we naar de oorsprong van Agile. Op één van deze gaan we dieper in: Lean Principles. Verder
worden
de
Het lijkt alsof Agile er nog maar een tiental jaren is, maar wanneer we de wortels gaan opzoeken, kunnen we tot in de jaren ’60 terug gaan. Vertrekkend van Iterative and Incremental Development (IID), via Evolutionary project
verschillende ontwikkelingsmodellen vergeleken en
de link met
Unified Process gemaakt. Voor we de kennisgebieden
management (evo) en de (reactie op de) watervalmethode komen we bij Lean development terecht.
gaan vergelijken, bekijken we
In
ook twee implementaties van
methodologieën: Scrum (1986), Crystal Clear, eXtreme Programming (XP;
Agile:
1996), Adaptive Software Development, Feature Driven Development (FDD),
Scrum
en
eXtreme
Programming.
de
jaren
’90
is
er
wildgroei
ontstaan
van
verschillende
Agile
en Dynamic Systems Development Method (DSDM; 1995).
KEYWORDS:
project
management; PMBok; Agile; Lean; iterative;
waterfall;
incremental;
eXtreme
Programming;
De eXtreme Programming methodologie wordt gezien als de grote katalysator in de verspreiding van Agile omwille van zijn grote adoptie.
Scrum;
Unified Process; knowledge area; Project Integration Management;
In 2001 wordt het woord “Agile” in gebruik genomen als overkoepelende naam
Management;
voor al deze methodologieën en wordt ook het “Agile Manifesto” geschreven.
Project Time Mangement; deming
In 2005 wordt dit manifest uitgebreid met de “PM Declaration of
wheel; value-driven; plan-driven;
Interdependence”, die even later weer bekend wordt als “The declaration of
Project
Scope
© 2010 Karel Nijs In samenwerking met Xios Hogeschool. Mentor: Francis Moeris, PMP
interdependence for modern management“.
Op moment van schrijven is Agile nog steeds niet aanvaard als de nieuwe werkwijze voor softwareontwikkeling. Er zijn al talloze discussies geweest en nieuwe discussies starten elke dag over de nood aan en het nut van deze nieuwe manier van werken. Vooral voor management lijkt de drempel nog iets te hoog. Omdat Agile zo een brede term is, kan het ook verschillende betekenissen hebben: een projectmanagement aanpak, lean development om verspilling te vermijden en het werken in een veranderende omgeving. Al deze betekenissen komen terug in deze tekst. Een belangrijke verandering in manier van denken is de shift in stijl van werkgeven en werknemen: daar waar vroeger alle beslissingen bij management lagen, probeert Agile de beslissingen en verantwoordelijkheid te leggen bij de mensen die het werk werkelijk uitvoeren. De teams worden toegewezen, multifunctioneel en zelf organiserend van aard, met als bedoeling de productiviteit te verhogen.
INHOUDSOPGAVE 1
Lean Principles ....................................................................................................................3
2
Het Agile Manifesto..............................................................................................................6
3
Vergelijking van ontwikkelingsmodellen ...............................................................................7
4
Implementaties ..................................................................................................................12
5
PMBok vs. Agile - algemeen ..............................................................................................16
6
Kennisgebied Project Integration Management..................................................................18
7
Kennisgebied Project Scope Management ........................................................................25
8
Kennisgebied Project Time Management...........................................................................31
9
Eindconclusie.....................................................................................................................37
10
Literatuurlijst...................................................................................................................38
3 van 39
1 Lean Principles Als voorbeeld hebben we één van de methodologieën genomen die geleid hebben tot het huidige Agile raamwerk.
1.1 Wat is Lean? You're a lean, mean, fighting machine! - Bill Murray in de film “Stripes” (1981) Lean, ofwel “mager”, is ontstaan in de jaren ’80 in de productie-industrie, meerbepaald de autoproductie-industrie bij Toyota. De
auto-industrie
in
Japan
kon
moeilijk
concurreren
tegen
de
Amerikaanse
massaproductie en moest een nieuwe manier van werken bedenken. Het nieuwe productiesysteem van Toyota werd opgestart met een fundamenteel Lean principe: Eleminate Waste. Hoofdprincipe van Eleminate Waste: “Beschouw alles wat geen waarde creëert voor de klant als verspilling en pas je processen zo aan dat deze verspilling vermeden wordt”. Wanneer een ontwikkelingsproject opgestart wordt, is het de bedoeling om dit vlug te beëindigen, want al het werk dat in het ontwikkelen gestoken wordt, levert geen waarde totdat de eerste auto van de band rolt. Ondertussen is de Lean manier van werken al stevig ingeburgerd in de productie-industrie en zoekt het langzaam zijn weg naar de software-industrie. Ondanks het succes in de productie-industrie is er geen gelijkaardige maat van succes bij softwareontwikkeling. De reden hiervoor kan de nodige verandering in cultuur en organisatie zijn die niet elk bedrijf aan kan. Ook kunnen niet zomaar alle Lean principes uit de productie-industrie overgenomen worden door de software-industrie. Enkele door Lean gebruikte methodes zijn Kaizen, Pull productie en Just In Time.
1.2 Achterliggende principes Er zijn zeven achterliggende principes van de Lean manier van werken: 1. Eleminate waste Schakel alles uit wat geen waarde oplevert voor de klant.
Karel Nijs, Ing.
4 van 39
Zaken die geen waarde opleveren, kunnen gaan van documentatie schrijven en overdrachten van taken tot het implementeren van onnodige features. 2. Amplify leaning Door middel van korte, herhalende cyclussen het product maken en al doende je kennis uitbreiden. Belangrijk is dat je van de “Do it right at the first time” denkwijze afstapt. 3. Decide as late as possible Probeer beslissingen uit te stellen tot “the last possible moment”. Hierdoor kan je betere beslissingen nemen omdat deze op feiten gebaseerd zijn in plaats van veronderstellingen. Deze strategie wordt best gevolgd in een complexe en sterk veranderende omgeving, zoals bijvoorbeeld softwareontwikkeling. 4. Deliver as fast as possible Door sneller en met kleinere iteraties op te leveren kan je vlugger waarde creëren en heeft de klant mogelijkheid om feedback te geven. Sneller opleveren maak het ook mogelijk dat de klant zijn beslissing zo lang mogelijk kan uitstellen en zou minder defects opleveren in slechts gedeeltelijk afgeleverd werk. 5. Empower the team Geef het team de mogelijkheid om de details van de technische beslissingen te bepalen: zij voeren het werk uit en kunnen de technische beslissingen beter nemen dan wanneer iemand anders die voor hen zou maken. Wanneer het team deze beslissingen kan maken, moet er ook niet telkens via een centraal orgaan gegaan worden. Dit versnelt de werking. 6. Build integrity in Zorg dat het gehele systeem goed in elkaar zit en een goed geheel vormt (conceptuele integriteit). De door de klant waargenomen integriteit (uitgedrukt in marktwaarde) zal dan toenemen. 7. See the whole Het geheel zien betekent dat de focus ligt op het totale product en de verschillende partijen ook zo denken en werken. Er zal niet gesuboptimaliseerd worden, maar er wordt aan de performantie van het totale product gewerkt.
Karel Nijs, Ing.
5 van 39
1.3 Hoe vult Agile deze principes in? Wanneer we opzoeken hoe de Lean principes zich vertaald hebben naar Agile principes, komen we bij een lange lijst uit. In de scope van deze tekst kunnen we er slechts maar gedeeltelijk naar verwijzen: -
Vermijd gedeeltelijk afgewerkt werk: dit blijft immers liggen en introduceert een onzekerheid.
-
Onnodige, extra features worden niet geïmplementeerd, maar de focus wordt gelegd op de features waar de klant waarde aan geeft.
-
Vermijd project volg- en controlesystemen want dit levert geen waarde op.
-
Werk intensief met feedback loops; vermijd strikt volgen van het watervalmodel.
-
Werk met iteraties die lang genoeg zijn om iets te kunnen ontwikkelen, maar kort genoeg zijn om frequent feedback te krijgen van de klant.
-
Klanten weten vaak niet precies wat ze willen: werk met een onderhandelbare scope.
-
Hoe later in het traject er wijzigingen of problemen voorkomen, hoe meer ze kosten: probeer deze vroeger op te vangen door niet sequentieel, maar concurrent te werken.
-
Laat de mensen zelf beslissen in plaats van beslissingsprocessen op te leggen of hun langs een centraal orgaan te laten passeren.
-
Rigide projectschema’s zijn niet geschikt in een veranderlijke omgeving.
-
…
Sommige van de Agile methodologieën zijn tegelijk of na Lean ontstaan, dus kunnen we hier invloeden van in terug vinden. In sommige gevallen nemen deze implementaties het wel zeer letterlijk op: het praktische eXtreme Programming gaat bijvoorbeeld strikt de werktijden gaan opvolgen omdat één van de achterliggende principes (Empower the team; tool Leadership) dicteert dat men op moet letten met (de negatieve gevolgen van) voortdurend overwerken. In de Agile literatuur vind je ook regelmatig terug dat het projectteam op de hoogte moet zijn van de business value van het project. [02] gaat hier wel zeer ver in door voor te stellen dat de ontwikkelaars zelf de waarde inschatten door hun het economische model te geven. Algemeen kunnen we besluiten dat Lean zeker aan de grondvesten van Agile ligt. Het belangrijkste wat we moeten onthouden van Lean is dat alles wat we momenteel als normaal
aanvaard
hebben,
Karel Nijs, Ing.
in
vraag
wordt
gesteld:
documentatieprincipes,
6 van 39
beslissingsorganen,
planning,
processen,
omgaan
met
wijzigingen,
refactoring,
contracten, enz. Men wil de huidige werkwijze zo efficiënt maken dat het minste wat onnodig is/lijkt, overboord wordt gegooid.
2 Het Agile Manifesto Manifesto - A manifesto is a public declaration of intentions, objectives, opinions or motives. Op de website [14] kan je het Agile Manifesto terugvinden. Dit manifest bevat richtlijnen om te evalueren of een proces als Agile beschouwd mag worden en is in 2001 opgesteld door een aantal volgelingen van de Agile methodologie. Ondertussen is het manifest (digitaal) ondertekend door duizenden volgelingen, verspreid over de hele wereld. Het manifest bestaat uit een algemeen deel met vier waardes, vergezeld door twaalf Agile principes: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. Op het Internet en in de vakliteratuur wordt dit manifest vaak besproken, en de meningen verschillen sterk. Het manifest schippert tussen te vage statements zoals “promote sustainable development” en “simplicity is essential” en te specifieke statements zoals “working software is primary measure of progress”. Ook zitten er principes in die geldig zijn voor eender welke manier van werken, zoals: -
“Build projects around motivated individuals”
-
“Business people and developers must work together daily throughout the project”
Karel Nijs, Ing.
7 van 39
-
“Continuous attention to technical excellence and good design enhances agility”
Niet alle richtlijnen zijn altijd toepasbaar, bijvoorbeeld “the most efficient and effective method
of
conveying information […] is face-to-face conversation”. Het belangrijkste wat we van het manifest moeten onthouden, is dat dit richtlijnen zijn en niet letterlijk overgenomen moet worden. De aanduiding “while there is value in the items on the right, we value the items on the left more” duidt hier ook op. In de literatuur komen we soms te letterlijke implementaties tegen van de vier waardes, wat kan leiden tot de typische Agile discussies en weigering van management om deze nieuwe werkwijze toe te laten. In 2005 is er een uitbreiding genaamd “PM Declaration of Interdependence” [15] geformuleerd voor Agile projectmanagers. Deze wordt later, wanneer duidelijk werd dat de principes ook voor andere managementprincipes bruikbaar waren, hernoemd naar “The declaration of interdependence for modern management“
3 Vergelijking van ontwikkelingsmodellen 3.1 Watervalmodel Het watervalmodel is een sequentieel software ontwikkelingsproces dat bestaat uit verschillende fases die sequentieel doorlopen worden. Je mag pas aan de volgende fase beginnen als de vorige fase voltooid is. Ondanks dat het watervalmodel in de jaren ’70 door Royce voorgesteld werd als een nietwerkend model, werd het toch globaal geadopteerd binnen de software-industrie. Het watervalmodel is risicovol en uitnodigend voor problemen omdat de testen uitgesteld worden tot het einde. Wanneer er fouten in de design fase gemaakt worden, kunnen deze pas gedetecteerd worden bij het testen. Men spreekt dan van een aha-erlebnis die de klant en het projectteam ervaren.
Karel Nijs, Ing.
8 van 39
Figuur 1 Watervalmodel [10]
Fouten corrigeren in de test fase van het project is echter een dure aangelegenheid (omwille van het vele rework) en moet vermeden worden. Zie ook de grafiek “2.2 Impact of Variable Base on Project Time” in de PMBok. Bij gebruik van het watervalmodel gaan we de planning opmaken aan de hand van een takenlijst en een volgorde vastleggen. De scope van het project gaan we bewaken en het plan wordt vastgelegd en aangehouden. De praktijk leert ons echter dat het vooraf maken van een sluitende planning niet altijd mogelijk is en er gegarandeerd wijzigingen gaan optreden. Door de scope van te leggen kan je beslag leggen op de creativiteit van de oplossing en door het aanhouden van het plan kan je minder vlug reageren op nieuwe marktontwikkelingen. Na het watervalmodel zijn er enkele verbeteringen geïntroduceerd zoals het V-model, het Dual Vee Model, het Big Design Up Front model, …
3.2 Incrementele model Het incrementele model voor software-ontwikkeling is ontstaan als reactie op de zwakke punten van het watervalmodel. Het incrementele model pakt het probleem aan van de te lange doorlooptijd van het watervalmodel en doet dit door verschillende fases te laten overlappen en functionaliteiten vroeger af te leveren. Verder is het incrementele model ook handig als bij de start van het project nog niet alle requirements bekend zijn.
Karel Nijs, Ing.
9 van 39
Figuur 2 Incrementele model [10]
3.3 Iteratieve en incrementele model Ook het iteratieve en incrementele model is ontstaan als reactie op de zwakke punten van het watervalmodel. Dit model start met een Initial Planning fase en eindigt, na het cyclische deel, met een Deployment fase. Het iteratieve en incrementele model is de basis voor het Agile raamwerk voor softwareontwikkeling.
Figuur 3 Iteratieve en incrementele model [10]
Bij iteratieve en incrementele ontwikkeling wordt de business value van het software eindproduct via iteraties opgeleverd. Bij het watervalmodel werd deze pas opgeleverd bij de laatste stap. De verschillende iteraties laten de klant toe om tijdig bij te sturen wanneer nodig.
Karel Nijs, Ing.
10 van 39
Het detailniveau van analyse, design en documentatie die afgeleverd moeten worden per iteratie is in te vullen door het raamwerk voor softwareontwikkeling dat van dit model gebruik wilt maken.
3.4 Unified Process Unified Process is een iteratief en incrementeel raamwerk voor softwareontwikkeling en is ook ontstaan als reactie op het watervalmodel. Unified Process is zelf geen proces, maar een raamwerk dat nog geïmplementeerd moet worden. Een bekende implementatie is Rational Unified Process. Er zijn vier fases in Unified Process: Inception, Elaboration, Construction en Transition.
Figuur 4 Unified Process [10]
Tijdens de Inception fase ligt de focus op het opstellen van de business case, het vastleggen van de project scope en requirements, identificeren van risico’s, enz Tijdens de Elaboration fase ligt de focus op vergaren van requirements, adresseren van risico’s en vastleggen van de systeemarchitectuur. De Construction fase is de grootste in het raamwerk en gaat verder op de basis gelegd tijdens de Elaboration fase. Tijdens de laatste fase, de Transition fase, worden software, documentatie en opleidingen overgedragen naar de klant.
Karel Nijs, Ing.
11 van 39
3.5 Agile model De Agile methodologieën maken gebruik van het iteratieve en incrementele software ontwikkelingsmodel, maar gaan een kortere iteratietijd gebruiken. De doorlooptijd van een iteratie bij de Agile implementatie loopt van één week tot één maand. Een Agile release bestaat uit meerdere iteraties en een Agile project bestaat uit meerdere releases (zie rechts). De planning gaat slechts per deelniveau gebeuren. Deze manier van plannen staat ook bekend als rolling wave planning, en wordt eveneens beschreven en gebruikt in de PMBok.
Figuur 5 Agile Project Life Cycle [04]
Verder heeft Agile nog maar weinig gemeen met het watervalmodel. Eventueel kan er binnen een iteratie wel nog met het watervalmodel gewerkt worden.
Agile vs. Unified Process Unified Process werkt net zoals Agile iteratief, maar volgt de verschillende fases min of meer lineair. Bij Agile wordt elke activiteit (verzamelen requirements, design, implementatie, demonstratie, …) herhaald tijdens elke iteratie. Verder is Unified Process een raamwerk dat specifiek aangepast moet worden voor het uit te voeren project en hierdoor een extra complexiteit introduceert. Agile implementaties kunnen echter meer kant-en-klaar gebruikt worden. Unified Process wordt ook verweten meer via documentatie te werken in plaats van met de klant.
Karel Nijs, Ing.
12 van 39
Er zijn ook enkele Agile verfijningen van Unified Process bekend zoals Agile Unified Process en OpenUP. Ook hebben Agile methodologieën het aantal Unified Process disciplines en artefacten vereenvoudigd.
4 Implementaties Deze tekst zal slechts twee courante implementaties van Agile bespreken: Scrum en eXtreme Programming.
4.1 Scrum Scrum is een iteratief en incrementeel raamwerk voor projectmanagement en Agile softwareontwikkeling. Scrum voorziet een raamwerk voor het beheren van het werk dat een lijst van uit te voeren taken (backlog) bijhoudt en aan de hand van prioriteiten bepaald welke taken het dringendste zijn. De werkuitvoering is iteratief en incrementeel door het gebruik van sprints. De backlog wordt verwerkt in verschillende sprints en via burndown charts wordt de voortgang weergegeven. Na elke sprint is er een nieuwe, werkende versie van het eindproduct waarvan de functionaliteit incrementeel toeneemt. De gebruikte planning lijkt op rolling wave planning en op het deming wheel.
Meetings Scrum maakt gebruik van verschillende types van meetings: 1. Sprint Planning Meeting Tijdens deze meeting wordt aan de hand van de backlog de planning opgesteld voor de volgende sprint. 2. Daily Stand-up Meeting met beperkte tijd waarin besproken wordt waar het team mee bezig is en wat de vorderingen zijn. 3. Sprint Review Deze meeting wordt uitgevoerd na het voltooien van een sprint en bespreekt de voorbije sprint. Ook wordt er een demonstratie gegeven aan de belanghebbenden.
Karel Nijs, Ing.
13 van 39
In bepaalde literatuur maakt men ook vermelding van dagelijkse “Scrum of scrums” en “Sprint Retrospective” meetings.
Rollen Scrum verdeelt de “wat” en “hoe” over verschillende rollen en definieert hiervoor drie rollen: 1. Product Owner. De Product Owner vertegenwoordigt de klant en bepaald wat er ontwikkeld wordt met behulp van de backlog en prioriteiten. De Product Owner is officieel verantwoordelijk voor het project en gaat om met echte projectmanagement taken zoals tijd-scope-budget, projectschema, projectobjectieven, rapportering… De Product Owner zet ook iteratiedoelen, maar wijst zelf geen taken toe aan de ontwikkelaars. 2. Scrum Master De rol van Scrum Master is een rol die we nergens anders kunnen terug vinden. De Scrum Master heeft geen autoriteit en is geen manager. Hij wijst geen taken toe en volgt ze ook niet op. Het team rapporteert niet aan de Scrum Master. De rol van Scrum Master wordt niet ingenomen door de projectleider; ook de taken uit de PMBok mappen niet op deze van de Scrum Master. De hoofdtaken van de Scrum Master zijn eerder facilitair van aard: hij ziet er op toe dat de Scrum regels gerespecteerd worden, hij verbetert de bestaande (Scrum) processen en hij zorgt er voor dat het team en de Product Owner kunnen samenwerken. 3. Team Member(s) Het Scrum team heeft meer autoriteit dan bij de traditionele manier van projectmatig werken. Het team is self-organizing en self-managed: zij zijn zelf verantwoordelijk hoe de ontwikkeling uitgevoerd wordt en bepalen hun taken zelf. Het team beheert de scope (omdat ze de implementatie zelf mogen kiezen), maar ook de tijd (tijdens iteraties), de kwaliteit, human resources, communicatie en risico’s. Scrum teams zijn kleine teams met crossfunctionele rollen. Alle rollen zijn aanwezig om bij elke sprint een werkend product af te leveren. Karel Nijs, Ing.
14 van 39
De Scrum teams krijgen een vrijgeleide om alles te doen (binnen de marges van het project) zodat het sprint doel gehaald wordt. Na elke sprint wordt het eindproduct gedemonstreerd aan de Product Owner.
4.2 eXtreme Programming eXtreme Programming is a humanistic discipline of software development, based on principles of simplicity, communication, feedback, and courage. eXtreme
Programming
(XP)
beschrijft
een
aantal
engineering
praktijken
voor
softwareontwikkeling en is een extreem praktische toepassing van een aantal principes die focussen op engineering kwaliteit zoals Test Driven Development, automatisatie, pair programming, … Dit praktische uit zich ook in de bijhorende literatuur: deze legt een zeer strikte werkwijze op en gaat bijvoorbeeld tot in detail vloerschema’s uitwerken. De kracht van XP ligt in het volledig toepassen van de methodologie. In de praktijk blijkt dit echter niet altijd haalbaar omwille van de strenge vereisten. XP werkt met (korte) iteraties en volgt een proces gelijkaardig aan het deming wheel.
4.3 Wanneer toepassen? Zoals hierboven beschreven, heeft Agile vele verschillende oorsprongen en zijn er vele implementaties beschikbaar. Omdat het moeilijk te bepalen is welke methodologie nu de meest geschikte is voor de specifieke situatie van elk projectteam, werd de Cockburn Scale opgesteld. Deze schaal beschrijft de mate waarin een softwareproject formele processen nodig heeft. Op de Y-as wordt de kriticiteit uitgezet, op de X-as wordt de teamgrootte uitgezet. Hoe dichter men zich bij de oorsprong bevindt, hoe meer formele processen het project nodig heeft.
Karel Nijs, Ing.
15 van 39
Figuur 6 Cockburn Scale [11]
Zo zien we bijvoorbeeld dat de rigide manier van werken van eXtreme Programming meer geschikt is voor kleinere teams, terwijl Scrum en Lean algemeen toepasbaar zijn. De vereenvoudiging van het complexere Unified Process raamwerk, Agile Unified Process, is meer geschikt voor Essential en Discretionary Money projecten.
Karel Nijs, Ing.
16 van 39
5 PMBok vs. Agile - algemeen De PMBok is opgedeeld in negen kennisgebieden en vijf procesgroepen. De drie kennisgebieden die in de volgende tekst behandeld worden zijn: -
Project Integration Management,
-
Project Scope Management,
-
Project Time Management. Project Management Process Groups
Knowledge
Initiating
Planning
Executing
Monitoring &
Closing Process
Areas
Process
Process Group
Process
Controlling Process
Group
Group
Group
Group Project
- Develop project
- Develop project
- Direct and
- Monitor and Control Project
- Close Project or
Integration
charter
management plan
Manage
Work
Phase
Project
- Perfom Integrated Change
Execution
Control
Management Project
- Collect Requirements
- Verify Scope
Scope
- Define Scope
- Control Scope
Management
- Create WBS
Project
- Define Activities
Time
- Sequence Activities
Management
- Estimate Activity Resources - Estimate Activity Durations - Develop Schedule
Voor we de drie kennisgebieden gaan bespreken, bekijken we kort de high level verschillen tussen de PMBok en Agile. A smart agile project manager does a lot of things the PMBOK talks about without calling it PMBOK, and a smart PMBOK project manager does a lot of agile things without calling it agile. - Dave West De PMBok een gids en ze dicteert geen methodologie: ze raden aan dat de lezer zelf bepaald wat de meest ideale processen zijn voor zijn bepaalde situatie. De PMBok kan dus gebruikt worden met de verschillende ontwikkelingsmodellen, inclusief Agile
Karel Nijs, Ing.
17 van 39
De PMBok kan gedetailleerd zijn op gebied van te gebruiken methodes, maar Agile implementaties leggen dan weer zeer specifieke richtlijnen op en geven minder vrijheidsgraden. Verder is de PMBok is ook een raamwerk: er is ruimte voor interpretatie, maar het doel blijft klantentevredenheid. Elke organisatie moet zijn implementatie van de PMBok uitwerken. Vaak kan dit ook een combinatie zijn met een andere methodologie, bijvoorbeeld Prince2. Beide werkwijzen, PMBok en Agile, hebben gedragsrichlijnen; bij de ene heet dit “code of ethics”, bij de andere “Agile Manifesto”. De aanpak verschilt wel sterk. Bij de PMBok is deze plan-driven: de requirements zijn vast, de resources en tijdsduur worden geschat. Bij Agile is de aanpak value-driven: de resources en de tijdsduur liggen vast, maar de features (of de business value) varieert. De afgeleverde business value kan veranderen tijdens het project op aanvraag van de klant.
Figuur 7 Bron [04]
Ook een belangrijk verschil is de wijze van controle. De PMBok wordt verweten een command
&
control
methodologie
te
zijn:
de
projectleider
draagt
uiteindelijke
verantwoordelijkheid, de projectleider wijst taken toe en plant deze, de projectleider verspreidt de status via rapporten, enz. Bij Agile zijn de teams self-managed en self-directed, het team kiest zelf zijn eigen taken en de status is transparant.
Karel Nijs, Ing.
18 van 39
Enkele algemene bezwaren van Agile tegen de PMBok zijn: weerstand tegen scope veranderingen, te zeer gefocusseerd op het projectplan, planning op basis van taken, een projectleider die opgelegd wordt en te uitgebreide documentatie noden.
6 Kennisgebied Project Integration Management Project Integration Management includes the process and activities need to identify, define, combine, unify, and coordinate the various process and project management activities within the Project Management Groups. Het Project Integration Management kennisgebied bevat enkele processen en output die tijdens het verdere verloop van het project opnieuw bekeken en aangepast kunnen worden. Bijvoorbeeld de risicomitigatie strategie die aangepast kan worden wanneer er nieuwe risico’s ontdekt worden. De PMBok schrijft voor om de verschillende processen minstens te adresseren om zo het implementatieniveau te bepalen. Wanneer een project uit verschillende fases bestaat, wordt er aangeraden om dezelfde werkwijze toe te passen in alle fases. Dit kennisgebied bestaat uit volgende processen: 1. Develop Project Charter 2. Develop Project Management Plan 3. Direct and Manage Project Execution 4. Monitor and Control Work 5. Perform Integrated Change Control 6. Close Project or Phase
6.1 Develop Project Charter Develop Project Charter is the process of developing a document that formally authorizes a project or a phase and documenting initial requirements that satisfy the stakeholder’s needs and expectations. Bij het Develop Project Charter proces gaat de project sponsor een document opstellen dat de toelating geeft om het project uit te voeren en de initiële vereisten vastlegt. In praktijk kan de projectleider de rol van project sponsor ook opnemen om de projectopdracht op te stellen.
Karel Nijs, Ing.
19 van 39
Bij Agile kunnen er twee verschillende werkwijzen gevolgd worden: ofwel wordt er met standaard papierwerk gewerkt (een Agile projectopdracht), ofwel is de budgettering al goedgekeurd en gaat men in een visie meeting de nodige documentatie uitwerken. In dit laatste geval gaat men trachten om enkel de essentiële informatie/design/analyse op voorhand uit te voeren zodat goedkeuring verkregen kan worden. In de visie meeting wordt er via oefeningen met het project team de projectvisie en een product box ontworpen. De hoofdreden hiervan is betrokkenheid creëren van het projectteam met het uiteindelijke product. Een input voor het Develop Project Charter proces is de business case. Hierin wordt er de business nood van het project beschreven op vlakken van vraag en aanbod, organisatorisch vereisten, aanvragen door klanten enz. Bij Agile wordt slechts eventueel een business case opgesteld. Een business case opstellen kan hier moeilijker zijn omwille van het onvoorspelbare element dat deze projecten met zich meebrengen. Ondanks dat de PMBok in dit kennisgebied vereist dat een projectopdracht wordt opgesteld, vinden we in de PMBok bij de inputs van het Define Scope proces (zie verder) terug dat de afwezigheid van een projectopdracht geen probleem is en men zich moet behelpen met de beschikbare informatie. Voor het Develop Project Charter proces kunnen we besluiten dat de PMBok met meer strengheid de verschillende documenten vast wil leggen, doch kunnen deze nog steeds aangepast worden in de loop van het project. Bij Agile ligt de focus meer op het motiveren van het team en dit door de als onaangename en verplichte ervaren zaken aangenamer te maken.
6.2 Develop Project Management Plan Develop Project Management Plan is the process of documenting the actions necessary to define, prepare, integrate, and coordinate all subsidiary plans. Voor de PMBok is dit plan een belangrijke deliverable en wordt opgesteld door de projectleider. Het Project Management Plan is geen schema (schedule): het kan wel een schedule baseline omvatten, maar het bevat meer informatie en kan zelfs onderverdeeld worden in verschillende subplannen. Karel Nijs, Ing.
20 van 39
Ook het Project Management Plan kan tijdens de uitvoering van het project geüpdatet worden. Terwijl bij de PMBok het projectplan op voorhand opgesteld wordt (en al gaande eventueel aangepast), gaat Agile slechts met een beperkte tijdshorizon werken. Agile tracht zo veel als mogelijk onnodige documentatie te vermijden en legt de plannen slechts vast voor korte termijn. Het hele projectteam wordt betrokken in dit proces. Ondanks dat Agile officiële documentatie, procedures en processen schuwt, zien we echter dat Agile de gebruikte methodes even zeer vast gaat leggen en reguleren. Bij de PMBok ligt de focus op de resultaten van deze processen (het change management plan, het communicatieplan, …), terwijl bij Agile de focus ligt op de manier waarop je deze processen uitvoert en resultaten bereikt. Door het bedrijf al vastgelegde procedures worden beschouwd als slecht en overlast, maar Agile gaat net méér nadruk leggen op processen, maar dan op de eigen processen zoals visie meetings, stand-up meetings, strikt (gelimiteerd) gebruik van flip-overs en whiteboards, … De meeste vrijheid heb je echter wanneer je als team zélf kan kiezen welke methoden, processen en procedures je gaat volgen. De PMBok laat deze vrijheid toe en niet-puriteinse opvolging van Agile ook. Vanuit historisch oogpunt kunnen we echter besluiten dat deze methoden, processen en procedures net ontstaan zijn om wildgroei en inconsistente resultaten te voorkomen. Een andere belangrijke output van het Develop Project Management Plan proces is het change management plan. Hierin wordt er vastgelegd hoe wijzigingen worden opgevolgd en gecontroleerd. Zoals eerder vermeld staat Agile open voor wijzigingen, maar dit betekent niet dat er geen change management plan is: dit plan ligt namelijk vastgelegd in de gebruikte Agile methodologie. Het change management plan van Agile bevat onder andere volgende denkwijzen: alle veranderingen zijn welkom, samen met de klant worden de nood en prioriteit van de wijzigingen bekeken, wijzigingen zo vroeg mogelijk identificeren, enz. Het change management plan is dus wel degelijk gedefinieerd, maar op niveau van methodologie in plaats van project of organisatie zoals in de PMBok. Karel Nijs, Ing.
21 van 39
Qua release plan is er een duidelijk verschil tussen de PMBok en Agile. Bij de PMBok wordt er op voorhand een grote inspanning geleverd en de details van het project uitgeklaard. Er wordt enkel bijgestuurd bij scope wijzigingen, change requests, … maar dit is eerder een uitzonderingssituatie. Bij Agile heeft het projectteam inspraak bij het opstellen van het release plan en worden er afspraken gemaakt in verband met het indelen van het werk in timeboxes. De belangrijkste features worden eerst gereleased zodat wanneer de planning niet gehaald wordt, de earned value het grootst is. Features worden niet toegewezen door de projectleider, maar de teamleden kiezen deze zelf en maken zelf een committment voor de komende iteratie.
6.3 Direct and Manage Project Execution Direct and Manage Project Execution is the process of performing the work defined in the project management plan to achieve the project’s objectives. Het Direct and Manage Project Execution bevat een grote lijst van mogelijke activiteiten, gaande van training tot verzamelen van lessons learned. Dit proces wordt uitgevoerd door de projectmanager samen met het projectteam. Hoewel bij eerdere versies van de PMBok een meer dirigerende aanpak gebruikt wordt, is er nu een aanpak die, net zoals bij Agile, meer het projectteam betrekt. Binnen Agile worden bepaalde rollen gecreëerd die door verschillende projectleden opgenomen worden; bijvoorbeeld Product Owner, Scrum Master, projectleider, … De Scrum Master zal zich bezighouden met het Agile gedeelte van het project, terwijl de projectleider meer een ondersteunende, facilitaire rol gaat opnemen. De projectleider heeft de verantwoordelijkheid dat de projectleden hun job kunnen uitvoeren en voorziet hiervoor de nodige software en materiaal, en neemt eventuele hindernissen weg. Dit is echter niet uitgevonden door Agile: deze trend doet zich algemeen voor in de sector van projectmatig werken en is ook bekend als servant-leadership. Zowel bij de PMBok als Agile wordt de voortgang opgevolgd, doch op een andere manier. De PMBok gaat onder andere de status van deliverables, voortgang op schema en gemaakte kosten
opvolgen.
Agile ontwikkeling gebeurt in iteraties en per iteratie worden een aantal features gepland. Het Karel Nijs, Ing.
22 van 39
inschatten van de werklast van de features en het mogelijke aantal features per iteratie wordt door de projectleden zelf gedaan. Dit komt overeen met bottom-up schatten van deliverables bij de PMBok. Het aantal features dat nog geïmplementeerd moet worden, wordt bijgehouden in een backlog. De klant bepaalt de prioriteit van de features en de projectleden kiezen hieruit zelf welke ze gaan implementeren. Naar het aantal features dat gepresteerd kan worden binnen één iteratie wordt verwezen als de burnrate. Deze kan bijgesteld worden tijdens het project wanneer er gemerkt wordt dat het aantal features niet haalbaar is of net te weinig is. Bij de PMBok worden change requests officieel aangevraagd en behandeld; bij Agile gebeurt dit meer officieus en worden de wensen van de (vertegenwoordiger van de) klant gevolgd. Normaal worden iteraties niet onderbroken, tenzij dat de change request zo ingrijpend is dat het voltooien van de iteratie totaal geen meerwaarde zou hebben. Wanneer de klant voortdurend wijzigingen zou aanvragen, kan het eindproduct onder druk te komen staan. Met een vast aantal resources en een vast schema is het aantal features dat geïmplementeerd kunnen worden beperkt. Als de klant change requests aanvraagt, kan/zal dit ten nadeel van andere (minder belangrijke) features zijn.
6.4 Monitor and Control Project Work Monitor and Control Project Work is the process of tracking, reviewing, and regulating the progress to meet the performance objectives defined in the project management plan. Monitoring includes status reporting, progress measurement, and forecasting. Eén van de inputs van dit PMBok proces zijn de performance reports waarin status, voorspellingen, struikelblokken, enz gecommuniceerd worden. Agile adresseert dit op verschillende manieren: dagelijkse stand-up meetings, demonstraties na elke iteratie en informatieradiatoren. Op de dagelijkse stand-up meetings wordt de huidige status besproken. De projectleden zeggen kort waarmee ze bezig zijn en mogelijke problemen die ze ervaren. De problemen worden pas na de meeting meer diepgaand besproken. Karel Nijs, Ing.
23 van 39
Op deze meetings is het hele projectteam aanwezig en eventueel ook vertegenwoordigers van Business. Ook hier zien we de strikte regelneverij daar deze vertegenwoordigers geen recht tot spreken hebben tijdens deze meetings. Het voordeel van deze dagelijkse meetings is dat het hele team up-to-date en betrokken is met de ontwikkelingen van de collega’s, een noodzaak bij parallelle ontwikkeling. Agile werkt ook met zogenaamde informatieradiatoren: dit zijn duidelijk zichtbaar opgestelde bronnen van informatie. In de literatuur vind je voorbeelden terug van whiteboards, flip-overs enz. De informatieradiatoren bevatten projectvoortgang informatie, huidige problemen, technische ontwerpen, … en hun hoofdfunctie is om in één oogopslag de passant een indruk te geven van het project. Door dit gegeven in combinatie met Management By Walking Around (MBWA) te gebruiken, kan management zich snel en eenvoudig op de hoogte brengen van de huidige ontwikkelingen binnen het project. Verder wordt er na elke iteratie een demonstratie gegeven aan het projectteam en de (vertegenwoordiger van de) klant. Deze demonstratie heeft verschillende voordelen: de software wordt voortdurend getest tijdens de gehele ontwikkeling, de klant kan tijdig ingrijpen als nodig en de aha-erlebnis op het einde van het project wordt vermeden. Daar dit vroeger misschien ad hoc gebeurde, is dit nu door Agile expliciet opgenomen in de methodologie en worden de demonstraties met grote regelmaat uitgevoerd. De praktijk leert ons dat geen van deze processen uitgevonden is door Agile. Het enige verschil is dat Agile ze expliciet opneemt in de beschrijving van de methodologie, terwijl andere methodes hier meer ruimte voor eigen invulling laten. De focus bij Agile ligt evenzeer op de werkwijze als op het gewenste resultaat. De officiële procedures op papier voorgesteld door de PMBok worden in een meer officieus kleedje gestoken, maar strikte opvolging blijft een vereiste. Verder vinden we als gelijkenis bij PMBok en Agile het gebruik van collaboratie-tools zoals SharePoint, Wikis, RSS, enz. Vooral bij geografisch verspreide teams wordt er systematisch van deze middelen gebruik gemaakt.
Karel Nijs, Ing.
24 van 39
6.5 Perform Integrated Change Control Perform Integrated Change Control is the process of reviewing all change requests, approving changes, and managing changes to the deliverables, organizational process assets, project documents, and the project management plan. Volgens de PMBok worden in dit proces worden niet alleen de wijzigingen zelf behandeld, maar ook het voorkomen van en reageren op mogelijke wijzigingen. Alle wijzigingen moeten via een officieel document aangevraagd en goedgekeurd worden. Iedereen kan wijzigingen indienen. Goedkeuren kan enkel door bevoegde personen. Vaak is dit de projectleider, maar eventueel wordt er een Change Control Board opgericht die over deze wijzigingen beslist. Beslissingen worden gemaakt op de Change Control Meeting en worden via een officiële weg naar alle betrokken gecommuniceerd. Goedgekeurde change requests kunnen impact hebben op het projectmanagementplan en projectdocumenten, maar ook op de projectscope. Wanneer de wijziging een zekere invloed heeft, wordt er een scope uitbreiding aangevraagd en zal er een nieuwe baseline gecreëerd worden. Bij Agile wordt er gestreefd naar een minimale overhead van documenten, processen en procedures. De klanten kunnen eenvoudig hun wijzigingen doorgeven. De aanvragen worden bijgehouden in de backlog, en ingedeeld en uitgevoerd naargelang prioriteit. In de dagelijkse stand-up meetings worden deze prioriteiten gecommuniceerd en er is constante interactie tussen klant en projectteam, zowel tijdens de iteratie als de demonstratie. De Change Control Board besproken in de PMBok is te vergelijken met een officiële versie van de klant-projectteam interactie die we vinden bij Agile.
6.6 Close Project or Phase Close Project or Phase is the process of finalizing all activities across all of the management Process Groups to formally complete the project or phase. Bij de PMBok is de belangrijkste input het project management plan waarin de scope beschreven werd. Als output heb je het finale product en eventuele aanpassingen aan documentatie en toevoegingen aan de database van historische informatie en geleerde lessen.
Karel Nijs, Ing.
25 van 39
Bij Agile worden voor het afsluiten van het project nog enkele iteraties uitgevoerd om het product productieklaar te maken en de nodige documentatie te schrijven. Onder de naam project retrospective wordt dezelfde historische informatie en geleerde lessen verzameld, net zoals de learned lessons van de PMBok. De resultaten van de project retrospective worden verder gebruikt om aanpassingen aan de organisatie en gebruikte Agile methodologie door te voeren, maar ook dit is niet nieuw aan Agile.
6.7 Conclusie We noteren enkele verschillen tussen de PMBok en Agile perspectieven, maar ook vinden we vaak overlappende delen. Er is een sterke afwijking bij de manier van het bepalen van de projectvisie en de business case, en het laten goedkeuren van de projectcharter op basis van minimale documentatie. Agile maakt zich enkele werkwijzen eigen die voorvloeien uit de door de industrie geleerde lessen van projectmatig werken. We denken dan aan MBWA, team empowerment, servant leadership, retrospectives (lessons learned), enz. Deze werkwijzen zijn echter niet nieuw, noch specifiek voor Agile. Vaak komen we deze werkwijzen al tegen in aangepaste implementaties van de PMBok en andere raamwerken voor projectmatig werken. Ondanks dat Agile zich hard maakt om af te stappen van het standaard beheer van documentatie en wijzigingen, worden deze in praktijk op een andere manier ingevuld en evenzeer opgelegd.
7 Kennisgebied Project Scope Management Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project. Ook het Project Scope Management kennisgebied bevat enkele processen en output die tijdens het verdere verloop van het project opnieuw bekeken en aangepast kunnen worden. Karel Nijs, Ing.
26 van 39
Dit kennisgebied bestaat uit volgende processen: 1. Collect Requirements 2. Define Scope 3. Create WBS 4. Verify Scope 5. Control Scope Elk proces uit dit kennisgebied wordt minstens éénmaal uitgevoerd: ofwel in het project, ofwel in elke fase van het project. Verder wordt er een onderscheid gemaakt tussen product en project scope.
7.1 Collect Requirements Collect Requirements is the process of defining and documenting stakeholders’ needs to meet the project objectives. The project’s success is directly influenced by the care taken in capturing and managing project and product requirements. Het verzamelen van de requirements is essentieel voor de volgende processen in dit kennisgebied. Daarom is het belangrijk dat deze requirements duidelijk en ondubbelzinnig gedocumenteerd worden. Ook moeten de requirements getraceerd kunnen worden naar de verantwoordelijke belanghebbende. De
requirements
kunnen
op
verschillende
manieren
van
de
geïdentificeerde
belanghebbenden verkregen worden: interviews, focus groepen, workshops, prototypes, enz. De PMBok beschrijft uitgebreid dat de requirements vastgelegd, beheerd en getraceerd moeten worden, maar ook dat de mate waarin dit gebeurt door de projectleider bepaald moeten worden. The urge to write requirements documentation should be transformed into an urge to instead collaborate closely with your stakeholders and then create working software based on what they tell you. – Scott W. Ambler Karel Nijs, Ing.
27 van 39
Bij Agile worden de requirements via een soortgelijke samenwerking tussen de belanghebbenden en het projectteam vergaard. Deze requirements gaan echter niet officieel gedocumenteerd worden, maar de notities, whiteboards en flip-overs worden bijgehouden en eventueel gefotografeerd. De filosofie waar men hier van uitgaat, is dat de requirements kunnen wijzigingen tijdens het project en alle tijd en moeite die in het documenteren en officieel vastleggen gestoken wordt, tevergeefs kan zijn. Bij de PMBok wordt de manier van omgaan met requirements vastgelegd in het Requirements Management Plan. Omdat de beschrijving hiervan de projectleider toelaat om de werkwijze te bepalen, is dit perfect combineerbaar met de Agile manier van werken. De in de PMBok beschreven Requirements Traceability Matrix legt de oorsprong van de requirements vast en volgt deze op gedurende het project. Het voordeel van deze matrix is dat je bij wijzigen van requirements de impact kan bestuderen. Het nadeel is dat deze matrix gedurende het hele project onderhouden moet worden. In de Agile literatuur vinden we hier geen eenduidige strategie voor. Er wordt vaak verwezen naar het gebruik van je “gezond verstand”, bij andere methodologieën zou het gebruik dan weer niet mogelijk zijn omdat de requirements meteen opgesplitst worden in verschillende work requests.
7.2 Define Scope Define Scope is the process of developing a detailed description of the project and product. De PMBok beschrijft dit proces als kritisch voor het slagen van het project en dat de gebruikte informatie uit de projectinitiatie fase afkomstig is. Een input voor het Define Scope proces is de projectopdracht. Bij Agile wordt deze niet altijd in dezelfde mate opgesteld als bij de PMBok. Dit zou echter geen probleem zijn voor de PMBok daar we de scope kunnen opstellen met de informatie die voor handen is. De belangrijkste output voor het Define Scope proces is de project scope statement. Hierin wordt gedetailleerd vastgelegd wat er afgeleverd moet worden en hoe dit zal gebeuren. Er kunnen expliciete zaken binnen of buiten scope gezet worden en de scope statement Karel Nijs, Ing.
28 van 39
wordt verder gebruikt als baseline om wijzigingen tijdens het project te controleren. De scope statement wordt gebruikt om alle belanghebbenden op dezelfde lijn te krijgen. Omdat Agile open staat voor wijzigingen, is het moeilijker om de scope vast te leggen voordat het project begonnen is. Om dit op te vangen voorziet Agile een raamwerk voor scope management. Dit raamwerk omvat de eerder beschreven backlog van features en de prioritering van de features door de (vertegenwoordiger van de) klant. Agile gaat uit van een negotiable scope. Meestal weet de klant bij aanvang van het project niet precies wat hij en hoe hij het allemaal wilt. Hierdoor kan er de neiging zijn om te veel functionaliteit aan te vragen die later nooit gebruikt zal worden. Een onderhandelbare scope laat de klant via het systeem van features, prioriteiten, backlog en het “deliver as fast as possible” principe, kiezen wat eerst geïmplementeerd wordt.
7.3 Create WBS Create WBS is the process of subdividing project deliverables and project work into smaller, more manageable components. De Work Breakdown Structure is een deliverable georiënteerde, hiërarchische voorstelling van het werk dat uitgevoerd moet worden. Het laagste niveau in de hiërarchie bevat de werkpakketten die gebruikt worden om te plannen, inschatten, opvolgen en controleren. Het is belangrijk dat de hiërarchie de juiste diepte heeft zodat er accurate schattingen gemaakt kunnen worden voor de uit te voeren werkpakketten, en zodat het werk beheersbaar blijft. De WBS kan je op verschillende manieren opstellen, bijvoorbeeld uit een opdeling van het product. Bij Agile wordt er wel een product breakdown gemaakt, maar deze wordt niet altijd in een WBS gegoten. De reden hiervoor is weer het sterk wijzigbare karakter van Agile projecten. Voortdurend updaten van de WBS zou een verspilling van tijd zijn. Eventueel wordt er een wel (tijdelijke) WBS gemaakt op een whiteboard, flip-over, … en vastgelegd op foto. Wanneer het niet mogelijk is om de deliverables al op te delen in werkpakketten, kan dit uitgesteld worden tot de details bekend zijn. Dit principe staat bekend als rolling wave planning. Karel Nijs, Ing.
29 van 39
Agile werkt ook op deze manier en er wordt dan gedurende het hele project per iteratie de scope vastgelegd.
7.4 Verify Scope Verify Scope is the process of formalizing acceptance of the completed project deliverables. Het Verify Scope proces dient om de afgewerkte deliverables formeel goed te laten keuren door klant. Als input worden verschillende eerder gemaakte stukken documentatie zoals het project management plan, de WBS, de requirements documentatie, … gebruikt. De afgewerkte deliverables die formeel aanvaard worden door de klant worden als afgewerkt en goedgekeurd gedocumenteerd. Deliverables die niet aanvaard worden, worden gedocumenteerd met de reden en eventueel kan er een change request ingediend worden. Bij Agile zien we hier een soortgelijk proces, maar weer minder officieel en formeel. Na elke iteratie krijgt de klant een demonstratie van het eindproduct. Hierin worden de features gedemonstreerd die in de iteratie geïmplementeerd werden. De klant controleert samen met het projectteam of deze afgewerkt zijn en kan op een eenvoudige manier change requests aanvragen. Door het systeem van voortdurend implementeren, builden, testen en demonstraties heeft de klant een beter zicht op de ontwikkeling van het product dan bijvoorbeeld bij het watervalmodel. Eerder goedgekeurde features kunnen later weer gewijzigd worden. Het gevolg is dat na iedere iteratie de scope kan wijzigen, maar de klant heeft hier zelf de controle over.
7.5 Control Scope Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. Het Control Scope proces gaat er over waken dat er geen wijzigingen aan de scope gemaakt worden zonder de officiële weg van change requests te gebruiken.
Karel Nijs, Ing.
30 van 39
De PMBok is er bewust van dat wijzigingen niet te vermijden zijn, maar laat deze door een vooraf gedefinieerd proces van change control gaan. Bij Agile wordt er ook aan scope bewaking gedaan, maar enkel voor de tijdelijke of lokale scope per iteratie. Tijdens het uitvoeren van de iteratie mogen er geen wijzigingen gemaakt worden aan de features. De klant heeft pas terug inspraak op het einde van de iteratie. Dit vormt geen probleem omdat de iteraties van redelijke korte duur zijn. Wanneer er echt onnodig werk gedaan zou worden tijdens de iteratie (omwille van een nieuw geïdentificeerd element), heeft de klant wel de mogelijkheid om in te grijpen en de iteratie te onderbreken. Ook de backlog met nog te implementeren features mag niet gewijzigd worden tijdens een iteratie. Als inputs voor het Control Scope proces hebben we de scope baseline (welke gebruikt wordt om afwijkingen te identificeren), verschillende managementplannen voor scope, change requests, requirements enz., en voortgangsinformatie. Bij Agile kunnen deze managementplannen in beperkte vorm beschikbaar zijn. Er wordt er een onderscheid gemaakt tussen de grootte van de scope: project, release, iteratie en dagelijks werk. Als voortgangsinformatie kunnen velocity en burn charts gebruikt worden om de scope onder controle te houden en eventueel aan te passen.
7.6 Conclusie Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. De PMBok en Agile gaan anders met de scope om op bijna alle vlakken. Het voornaamste om te onthouden is dat de PMBok de scope tracht vast te leggen, terwijl Agile dit net bewust niet doet. De PMBok beschrijft wel de mogelijkheid om eerst high level te plannen en verder progressief uitwerken door telkens de nieuwe context in rekening te brengen. De PMBok staat ook open voor wijzigingen, maar deze resulteren in scope uitbreidingen. Karel Nijs, Ing.
31 van 39
Zowel bij de PMBok als bij Agile gaan de wijzigingen door een bepaald proces. Dit verloopt bij de eerste wat meer rigide dan bij de andere.
8 Kennisgebied Project Time Management Project Time Management includes the processes required to manage timely completion of the project. Dit kennisgebied bestaat uit volgende processen: 1. Define Activities 2. Sequence Activities 3. Estimate Activity Resources 4. Estimate Activity Durations 5. Develop Schedule 6. Control Schedule Elk proces uit dit kennisgebied wordt minstens éénmaal uitgevoerd: ofwel in het project, ofwel in elke fase van het project. Voor kleinere projecten kunnen de processen in dit kennisgebied in één enkel proces afgehandeld worden. Voor de processen in dit kennisgebied wordt het Develop Project Management Plan proces (dat in kennisgebied Project Integratiebeheer besproken is) uitgevoerd en worden enkele belangrijke planningseigenschappen en -methodes vastgelegd.
8.1 Define Activities Define Activities is the process of identifying the specific actions to be performed to produce the project deliverables. Define Activities kan vertrekken van de WBS en maakt van elk werkpakket via decompositie een aantal activiteiten. Aan deze activiteiten worden verschillende eigenschappen gekoppeld (ID, naam, omschrijving, …) en later worden ze gebruikt om een volgorde mee op te bouwen. Agile werkt niet op exact dezelfde manier omdat er niet altijd een WBS aangemaakt wordt, maar deelt het eindproduct wel op in user stories.
Karel Nijs, Ing.
32 van 39
Een user story beschrijft een specifieke software requirement en is geformuleerd in elke zinnen, uitgedrukt in de normale “business taal”. De user stories zijn kort en passen op één index kaart. Bijvoorbeeld: “als niet-geregistreerde klant kan ik enkel de catalogus zien, maar geen voorwerpen kopen”. De klant stelt de user stories op en geeft de prioriteit aan, zodat de ontwikkelaars deze correct kunnen inplannen en uitvoeren. Verschillende user stories samen vormen een feature. De PMBok laat ook rolling wave planning toe om het nabije werk progressief te plannen, wanneer er meer details bekend zijn, en het toekomstige werk slechts high level te plannen. Hierdoor kan Agile perfect aansluiten met zijn iteratieve planning. Een belangrijke output van het Define Activities proces is de milestone list. Deze bevat alle belangrijke punten in de tijd gedurende het project. Agile werkt met minimijlpalen aan het einde van elke iteratie, maar over het algemene gebruik van mijlpalen is er nog discussie [13].
8.2 Sequence Activities Sequence Activities is the process of identifying and documenting relationships among the project activities. Activities are sequenced using logical relationships. Every activity and milestone except the first and last are connected to at least one predecessor and one successor. Over de vergelijking van het Sequence Activities proces met Agile kunnen we kort zijn: Agile legt niet meteen een volgorde op voorhand vast. Eventueel kunnen aan de verschillende user stories wel een volgorde gegeven worden, maar deze kan veranderen wanneer de klant de prioriteiten verandert. Tijdens de iteratieplanning kan de volgorde van de te-implementeren user stories binnen een iteratie wel vastgelegd worden.
8.3 Estimate Activity Resources Estimate Activity Resources is the process of estimating the type and quantities of material, people, equipment, or supplies required to perform each activity. Karel Nijs, Ing.
33 van 39
Wat betreft human resources kan het zowel bij de PMBok als bij Agile zijn dat je een team toegewezen krijgt. Een logische eerste stap is dan controleren of je de nodige vaardigheden beschikbaar hebt. Agile teams zijn typisch crossfunctioneel, maar toch kunnen er specifieke vereisten op voorhand gedefinieerd worden. Tijdens de uitvoering van het project kan eventueel nog opnieuw geëvalueerd worden of de nodige rollen voldoende aanwezig zijn. Een verschil tussen de PMBok en Agile aanpak is de betrokkenheid en inschakeling van de klant en belanghebbenden. Daar er bij Agile voortdurend input nodig is (beheren backlog, bepalen prioriteiten, afstemmingen, dagelijkse stand-ups, …) zullen deze rollen een vast deel uitmaken van het team. Voor de nodige uitrusting wordt bij Agile het principe “decide as late as possible” gehandhaafd. Zo zal bijvoorbeeld de aankoop van een specifiek databasesysteem uitgesteld worden tot men echt niet meer anders kan. Op deze manier tracht men het risico van een foute aankoop te vermijden.
8.4 Estimate Activity Durations Estimate Activity Durations is the process of approximating the number of work periods needed to complete individual activities with estimated resources. Bij de PMBok wordt de duur van de verschillende activiteiten op verschillende manieren geschat, zoals analoge, parametrische en driepunts schattingen. Agile gaat de verschillende features en stories ook bottom-up laten inschatten door de ontwikkelaars. Wanneer blijkt dat een feature te groot is om in één iteratie te implementeren, wordt deze opgedeeld in verschillende aparte features. Hoewel in sommige literatuur beweerd wordt dat Agile de duurtijd van features niet bijhoudt, wordt deze toch uitgedrukt in het aantal iteraties. Zowel in de PMBok als in de Agile literatuur wordt er gesproken over het progressief aanpassen van de geschatte duurtijden telkens wanneer er meer informatie beschikbaar komt. Karel Nijs, Ing.
34 van 39
8.5 Develop Schedule Develop Schedule is the process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule. Entering the activities, durations, and resources into the scheduling tool generates a schedule with planned dates for completing project activities. Bij het Develop Schedule proces wordt de projectplanning opgemaakt die meestal in de vorm van milestone charts, bar charts of netwerkdiagrammen voorgesteld wordt. Agile gaat ook werken met een projectplanning, maar gebruikt als input de backlog. De features worden niet in een vaste planning gegoten en er wordt geen netwerkdiagram noch kritisch pad opgesteld. Een vast schema is immers niet bestand tegen de vele mogelijke veranderingen. Agile gebruikt time boxing: hierin kiezen de ontwikkelaars features om te implementeren per vaste tijdspanne (box). De klant geeft de prioriteit van de features in de backlog aan. Door eerst de belangrijkste features te implementeren wordt de slack nul en wordt elke iteratie kritisch. Zoals eerder beschreven worden de features zo klein mogelijk opgesplitst en kunnen zo eventueel over meerdere boxen geïmplementeerd worden. Een iteratie time box moet groot genoeg zijn om een betekenisvolle design-build-test cyclus uit te voeren en kort genoeg om frequente feedback te geven aan klanten dat het project op schema zit. Tijdens een iteratie wordt er enkel gewerkt aan de geplande wijzigingen. Het design gebeurt niet op voorhand in één keer, maar wordt telkens aangepast bij elke feature. Dit principe komt uit de Lean werkwijze [02]:
Karel Nijs, Ing.
35 van 39
In Japan, the tool and die suppliers start working on a die at the same time the car design is started. Die cutters are expected to know what a die for a part will involve, and they are in constant communication with the designer. Suppose that a body engineer wants a change made. The body engineer goes directly to the die cutting shop, discusses the proposed change with the die engineers, checks production feasibility, and together they decide what to do. The die shop makes the changes in the milling machine and keeps on cutting the die. Paperwork and approvals follow later.
8.6 Control Schedule Control Schedule is the process of monitoring the status of the project to update project progress and manage changes to the schedule baseline. The key to project success is to apply knowledge, experience, and intuition to a project plan, and then attempt to execute according to the plan. – [09] Het Control Schedule proces wordt door de PMBok als de hoofdactiviteit binnen het Project Time Management kennisgebied beschouwd. Hoe doel van dit proces is het opvolgen van de voortgang en het ondernemen van acties als er afgeweken wordt. De acties gaan van het identificeren van de problemen tot het indienen van change requests. Als tools gebruikt de PMBok onder andere performance reviews, variance analysis en projectmanagementsoftware. Working software is the primary measure of progress. – Agile Manifesto Bij Agile wordt op een soortgelijke manier de performantie opgevolgd. De velocity wordt voorgesteld in zogenaamde burn charts. Grafieken die het aantal acceptatietesten per iteratie uitdrukken, kunnen ook gebruikt worden om de voortgang op te volgen. Wanneer aan de velocity gemerkt wordt dat het aantal features te groot is om in één iteratie af te werken, worden er voor de volgende iteraties minder features ingepland. Een ander hulpmiddel is de input vergaard tijdens de dagelijkse stand-up meetings.
Karel Nijs, Ing.
36 van 39
Bij outputs van het Controle Schedule proces bij de PMBok vind je change requests en updates van het schema en netwerkdiagram terug. Bij Agile wordt na elke iteratie de voortgang aan de hand van het aantal succesvol geïmplementeerde features geëvalueerd. Dit kan resulteren in aanpassingen in de backlog, de prioriteit van de features, het iteratieplan en het releaseplan.
8.7 Conclusie Zoals verwacht bevat het Project Time Management kennisgebied enkele essentiële verschillen tussen de PMBok en Agile die net typisch zijn voor de Agile manier van werken. Agile planning gebeurt op basis van release en iteraties in plaats van op project. De projectteamleden maken de schattingen zelf door eerst high level in te schatten en per iteratie wordt deze uitgewerkt door detailinschattingen te maken. De betekenis van het kritisch pad zoals we het kennen binnen projectmatig werken is ook niet meer dezelfde. Net zoals bij de PMBok, wil ook Agile de voortgang van het project opvolgen. Planning blijft dus een belangrijke component, maar er worden andere methodes van meten gebruikt, zoals time boxes, burnrate, velocity, rework percentage, enz.
Karel Nijs, Ing.
37 van 39
9 Eindconclusie Er
bestaat
een
algemene
aversie
tussen
de
uitvoerders
van
de
verschillende
methodologieën. De PMBok probeert vaak (onterecht?) te bewijzen dat ze al Agile werken; Agile probeert te bewijzen dat ze net niet volgens de PMBok werken. De waarheid is dat Agile in de PMBok past (of minstens complementair is), maar zich ontdaan heeft van verschillende onnodige of te strikte praktijken. Daarentegen promoot Agile dan weer niet cowboy coding door alles toe te laten, maar gaat zelf nieuwe en soms striktere praktijken opleggen. Verder voert Agile ook de verschillende PMBok activiteiten iteratief uit, maar ook dit kunnen we in de PMBok zelf terugvinden. The organization and/or project management team is responsible for determining what is appropriate for any given project. - PMBok Het is het best om uit de verschillende methodologieën de goede dingen uit te pikken en je eigen methodologie te maken in plaats van de one-size-fits-all aanpak. We merken hier ook een valkuil op: zowel bij de PMBok als bij Agile nemen sommige bedrijven deze frameworks te letterlijk over en laten geen ruimte voor interpretatie toe. Terwijl de PMBok er op staat om alles officieel vast te leggen, lijkt de focus bij Agile op het officieuze te liggen. Het nut van documentatie en planning wordt erkend, maar er wordt geen tijd in gestoken om deze in dezelfde mate af te werken. Vaak maakt men ook een planning of een breakdown, maar in plaats van deze in te voeren in de projectmanagementsoftware die vandaag ter beschikking is, wordt het ontwerp verder gebruikt of gewoon vastgelegd op foto. Vaak wordt onterecht gedacht dat Agile niets van documentatie weten wil. In de literatuur vinden we deze component wel nog steeds terug, maar deze wordt vaak anders aangepakt. Er worden bijvoorbeeld wel tests, high level designs en documentatie voor de eindgebruiker opgesteld.
Karel Nijs, Ing.
38 van 39
10 Literatuurlijst [01] A Guide To The Project Management Body Of Knowledge, PMI, 2008 [02] Lean Software Development: An Agile Toolkit, M. Poppendieck, T. Poppendieck, 2003 [03] The Art of Agile Development, Warden, J. Shore, 2008 [04] The Software Project Manager's Bridge to Agility, Michele Sliger; Stacia Broderick, 2008 [05] Project Management: The Managerial Process, C. Gray, E. Larson, 2008 [06] Business Driven PMO Setup, M. Perry, 2009 [07] Human Resources Skills for the Project Manager, V. Verma, 1996 [08] PMP Exam Study Guide 5th Edition, Kim Heldman, 2009 [09] Practice Standard for Scheduling, PMI, 2007 [10] Wikipedia, http://www.wikipedia.com [11] Alistar Cockburn Scale, http://www.kusmin.eu/wiki/index.php/Project_Classification_Scale [12] Agile Requirements Best Practices, http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm [13] Milestones are useless for agile development, http://blogs.msdn.com/progressive_development/archive/2008/06/24/motley-says-milestonesare-useless-for-agile-development.aspx [14] Agile Manifesto, http://agilemanifesto.org [15] PM Declaration of Interdependence, http://pmdoi.org/ [16] A Comparison of Software Development Methodologies, http://www.stsc.hill.af.mil/crosstalk/1995/01/comparis.asp [17] Unified Process vs Agile Processes, http://ccollins.wordpress.com/2008/06/11/unifiedprocess-vs-agile-processes/ [18] The Agile PMP: Teaching An Old Dog New Tricks, http://www.slideshare.net/mcottmeyer/the-agile-pmp-teaching-an-old-dog-new-trickspresentation [19] Basics of Rolling Wave Planning, http://www.brighthub.com/office/projectmanagement/articles/48953.aspx [20] An Exclusive Webinar Series for Software Organizations - The Road To Agile, http://www.rallydev.com/thankyou_webinar_series.jsp?c=webinarseries [21] Agile Alliance, What Does the Agile Manifesto Mean, http://www.niwotridge.com/Essays/AAPrinciples.htm
Karel Nijs, Ing.
39 van 39
[22] Agile Project Management and "Normative" Paradigms, http://www.niwotridge.com/Essays/Editorials/PMEditorial.htm [23] Agile Project Management Is Not Enough!, http://www.agile-softwaredevelopment.com/2008/05/agile-project-management.html [24] Can traditional project management and agile development coexist?, http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1348177,00.html [25] An Agile PM Isn’t What You Think, Agile Journal, November 17, 2009 [26] Go Agile, Don’t Fear the PMBOK, http://rg-agile.blogspot.com/2007/08/go-agile-dontfear-pmbok.html [27] PMBOK 4 going Agile?, http://www.gantthead.com/discussions/discussionsTopicContainer.cfm?ID=10552 [28] PMBOK and Agile Article, http://herdingcats.typepad.com/my_weblog/2007/08/pmbokand-agile.html [29] PMBOK and agile development, http://www.fucinaweb.com/en/pmbok-and-agiledevelopment/ [30] Agile Project Management: PMBOK vs. Agile, Agile Project Leadership Network, August 2, 2007 [31] Relating PMBOK Practices to Agile Practices, http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=103 65&tth=DYN&tt=siteemail&iDyn=2 [32] The Rules of Lean Project management, Claude Emond/Qualiscope, 2009 [33] Using Agile Alongside the PMBok, Mike Griffiths, 2004 [34] Features vs. User Stories, http://www.symphonious.net/2006/05/18/features-vs-stories/ [35] Principles of Lean Thinking, Mary Poppendieck, 2002 [36] Why Most IT Projects Fail. And How Agile Principles Help, http://www.agile-softwaredevelopment.com/2007/08/why-most-it-projects-fail-and-how-agile.html [37] How Does a ScrumMaster Compare to a Project Manager?, http://www.pmi.org/eNews/Post/2010_03-26/ScrumMaster-Compare-To-PM.html [38] Certified Scrum Master, Mitch Lacey, 2007 [39] Metrics for Agile Projects, http://www.slideshare.net/mittaldeepak01/metrics-for-agileprojects-349218
Karel Nijs, Ing.
