Inleiding - Scrum

Scrum is een agile projectmanagementmethodologie voor software-ontwikkeling, vergelijkbaar met XP (Extreme Programming)

Tussentijdse wijzigingen: Net als voor XP, is het kenmerkend voor Scrum dat het overweg kan met tussentijdse wijzigingen van de requirements
Empirisch: Scrum is empirisch, in de zin dat het geijkt is op waarnemingen, en niet op normatieve zaken
Probleem beperkt inzichtelijk: Er wordt aangenomen dat het probleem van de klant niet uitputtend in kaart is gebracht voorafgaand aan het begin van de werkzaamheden, en dat dit ook niet zal lukken
Feedback-driven: Transparantie, inspectie & aanpassing (adaption)
Product backlog = Werkvoorraad, denk ik
Sprint = iteratie

Projectmanagement? Voor software-ontwikkeling?

Op één of andere manier, is het bouwen van een brug anders dan het bouwen van een stuk software. En dat lijkt ook te gelden voor Internet-gerelateerde projecten zoals webwinkels, marketing-campagnes en uploads naar een Amazon-site.

Daarnaast: Waarom heb je überhaupt zoiets als projectmanagement?

Zo efficiënt mogelijk van A naar B

De essentie van plannen en projectmanagement, is een economische: Hoe kun je met zo efficiënt mogelijk gebruik van hulpbronnen een bepaald doel bereiken? Bij hulpbronnen moet je vooral denken aan tijd en geld.

Voorbeeld: Auto-onderhoud:

Wanneer laat ik onderhoud aan m'n auto verrichten? Deze maand, bij m'n vertrouwde garage op de hoek, of tijdens de vakantie als ik met pech langs de weg sta in een land waar ik de taal niet spreek?

In het eerste geval is onderhoud veel economischer, zowel qua tijd (ik hoef de auto alleen te halen en te brengen) als qua geld. In het tweede geval kost het veel tijd (wachten op een sleepdienst, twee dagen wachten tot de auto klaar is, veel frustratie) en zal flink duurder zijn.

Samenwerking & afhankelijkheden

Onderdeel van projectmanagement, is dat het samenwerking tussen verschillende betrokken partijen inzichtelijk maakt (in zoverre dat relevant is om zo efficiënt mogelijk van A naar B te komen), omdat dit op een of andere manier op elkaar moet aansluiten.

In het bijzonder komt dit naar voren bij het kritieke pad: De reeks aan afhankelijkheden die de totale doorlooptijd van het project bepaalt.

Hier belanden we bij een opvallend verschil tussen software-engineering en het bouwen van bv. een brug. Zoals Fred Brooks in zijn klassieker The Mythical Man-Month beschreef: Mensen toevoegen aan een project dat al vertraagd is, zal dat project verder vertragen.

Al etende krijgt men honger: Omarm de onzekerheid

De mogelijkheden van software zijn breed en veranderen continue. Ook de context van een project verandert continue, evenals de inzichten van de klant gedurende het project. Dat is waarschijnlijk het meest fundamentele verschil tussen de bouw van een brug of een stuk software: De onzekerheid van het project. De risico die dat met zich meebrengt, en hoe belangrijk het is, om nog tijdens een project wijzigingen te kunnen incorporeren. Dit laatste punt is de aanleiding tot het ontstaan van zogenaamde agile methodologies in de jaren '90, omdat traditionele ontwikkelmethodologieën hier slecht mee overweg konden (plus nog andere nare issues).

Een aantal best practices die aansluiten bij deze onzekerheid en veranderingen:

Feesback & iteratief werken: Zo snel mogelijk 'iets' opleveren dat relevant is voor de klant, om aansluitend te bespreken hoe verder te gaan
Korte iteraties: Iteraties duren maximaal enkele weken. Als dit langer duurt, neemt de kans toe dat het resultaat niet meer aansluit bij wat de opdrachtgever in gedachten heeft. Als het veel korter wordt, neemt de overhead van het initiëren en beëindigen van een iteratie toe
One iteration at a time: Uiteraard is er een idee van het beoogde eindresultaat, maar dat hoeft aan het begin niet in detail te zijn vastgelegd. De actuele iteratie, is wél in detail bepaald. En daarop is de focus.

Rollen

Scrummaster

De Scrummaster heeft een faciliterende rol. Hij of zij staat buiten het team.

Producteigenaar

De Producteigenaar of Product Owner is de klant, opdrachtgever en/of belanghebbende, of iemand binnen het team die hem of haar representeert. Hij is de belanghebbende bij het op te leveren product en hij betaalt de rekening. Hij of zij is het equivalent van de Customer Representative in XP

Een team moet niet meer dan één Producteigenaar hebben
Een Producteigenaar kan niet tegelijkertijd Scrummaster zijn
De Producteigenaar is business-georiënteerd en niet inhoudelijk betrokken.

Zie [1] voor details.

Sprints

Een sprint of iteratie is de basiswerkeenheid in Scrum:

Sprints duren meestal van ca. een week tot een maand. Twee weken is het meest gebruikelijk
Sprints zijn timeboxed [2]: Vantevoren staat vast hoe lang een sprint duurt
Een sprint begint met een Sprint Planning Event: Het werk en het doel worden gedefineerd
Een sprint eindigt met een Sprint Review en een Sprint Retrospective
Sprints resultereren in opgeleverd werk. Bv. programmeercode die geïntegreerd, getest en gedocumenteerd is, en het liefst ook verscheept is. Doelen zijn dus tastbaar en bruikbaar.

Kaarten & PBI

Het werk dat gedaan moet worden, en de resultaten die je voor ogen hebt, moeten uiteraard gespecificeerd worden. Dat gebeurt op verschillende niveau's. De meest concrete en down-to-earth manier waarop dat gebeurt, is wellicht via de Product Backlog Items, oftewel Werkvoorraad-items. In Trello worden dit kaarten genoemd, en dat is vaak een prima benaming.

Wat voor dingen zet je op kaarten?

Een kaart kan basically elk soort werk of beoogd resultaat beschrijven. Er zijn geen nauwe definities, maar er zijn wel een paar practische richtlijnen. Om te beginnen [3]:

Product Backlog Items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain "user stories"; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.

Verder:

Begrijpelijk voor de Producteigenaar: De Producteigenaar bepaalt de prioriteiten van de verschillende kaarten. Daarom moeten de items voor hem of haar begrijpelijk zijn. Items die uitsluitend technisch-inhoudelijke zaken bespreken, zijn dat meestal niet
Wat niet hoe: Zoals het citaat hierboven zegt: Most items should focus on delivering value to customers: Beter om beoogde resultaten te benoemen dan het beoogde werk: Oftewel: Wat wil je bereiken, niet hoe

Scope?

Hoe breed of hoe smal defineer je een item? Kun je tijdens een groot project dat misschien een paar jaar duurt, een kaart aanmaken nieuwe website, die naar verwachting zes maanden werk vergt? Het is intuïteif dudidelijk dat dat niet handig is. Maar waarom precies? Waar liggen de grenzen?

Samenwerking is tussen kaarten

Eén van de essenties van projectmanagement, is om samenwerking te coördineren. Een kaart leent zich daar niet goed voor: Het is te zeer een 'monolitsch' geheel. Samenwerking geschiedt op een hoger abstractieniveau: Tussen kaarten en tussen iteraties. Een kaart heeft meestal een eigenaar en er is een goede kans dat meestal maar één of soms twee personen samen een kaart afwerken.

Oftewel: Als een bepaald doel samenwerking vereist, is één kaart te beperkt

XP vs. Scrum

Duur van iteraties

Scrum: Eén tot vier weken, typisch twee weken
XP: Eén of twee weken

Verandering binnen een sprint

Scrum: Geen veranderingen binnen een lopende sprint
XP: Verandering binnen een sprint is ok. Verandering binnen een kaart die al is begonnen, is nie tok

Prioritiet

XP: Werk wordt strict in de volgorde van prioriteit gedaan, zoals aangegeven door de Producteigenaar
Scrum: Team bepaalt zelf de volgorde

Ontwikkelwerkwijzes

XP schrijft tot op zekere hoogte voor hoe ontwikkelaars moeten werken (bv. team programming)
Scrum schrijft dit soort zaken niet voor, want vertrouwen speelt een belangrijke rol.

Inleiding - Scrum

Inhoud