Scrum

Uit De Vliegende Brigade
(Doorverwezen vanaf Projectmanagement)
Ga naar: navigatie, zoeken

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.

Tools

  • Pivotal Tracker - Schijnt goed aan te sluiten bij Scrum
  • Todoist
  • Trello → Gekozen.

Bronnen