Lean Requirements, hoe bedoelt u?

Gegevens

Publicatiedatum

Ook het vlak van requirements management ontkomt niet aan de Lean filosofie. Ook hier moeten zaken sneller en efficiënter worden georganiseerd, met zo min mogelijk ‘waste’. Waar vroeger requirements nog werden verzameld op een per project aanpak, zien we nu steeds meer gestandaardiseerde werkwijzen. Denk aan ontwikkelmethoden als RUP, Agile, Scrum en XP. Elk heeft zijn “eigen” manier van het vastleggen van requirements. Denk aan woorden als Use Case, Storyboard, Scenario etc. Een waterval aanpak kan tegenwoordig echt niet meer. In ieder geval is zo’n aanpak niet Lean, want er is geen sprake van flow, maar meer van een batch georiënteerde werkwijze.

Maar als je dan kiest voor een Lean werkwijze, wat is dan de beste manier, wat is het meest Lean? Moeten de eerder genoemde methoden tot op de letter worden toegepast of gaat het om het pragmatisch toepassen en een soort mix & match afhankelijk van de situatie? Kortom, een eenduidige manier van het Lean verzamelen van requirements is vooralsnog nog een flinke zoektocht.

Ivar Jacobson, bedenker van het begrip “use case” heeft zijn ervaringen sinds dat hij het begrip in de jaren tachtig introduceerde verder uitgebreid met diverse “agile” en Lean toevoegingen. Hij heeft recent een eBook uitgebracht met de naam Use-Case 2.0, wat gratis te verkrijgen is (na registratie) op zijn website. In dit boek beschrijft hij een zestal principes rondom zijn nieuwe Use-Case 2.0, die volgens hem “lightweight, scalable, versatile and easy to use” zijn. Ook beschrijft hij het “slicen” van Use Cases en maakt hij gebruik van Lean werkwijzen, zoals visuele voortgang overzichten. Al met al een interessante aanpak, maar wel één die een hoog gehalte “oude wijn in nieuwe zakken” heeft, want echt nieuwe concepten heb ik niet gevonden. Het lijkt erop dat Jacobson in dertig jaar veel ervaring heeft opgedaan met Lean en Agile concepten zoals product backlogs, stories en het werken met post-its en deze nu op een slimme manier heeft samengevoegd met zijn Use Case benadering.

Daarnaast is er het boek van Ken Pugh met de titel “Lean-Agile Acceptance Test-Driven Development”. Hij probeert zijn lezers ervan te overtuigen dat het vooraf definiëren van testgevallen “waste” helpt te voorkomen, aangezien er volgens Pugh dan minder iteraties nodig zijn om tot de gewenste functionaliteit te komen. Hij argumenteert dat het toepassen van Acceptance Test-Driven Development (ATDD) binnen de driehoek van klant-ontwikkelaar-tester “waste” voorkomt en tevens hoge kwaliteit van de output garandeert. Door vooraf acceptatie testcriteria te definiëren wordt het aantal loops tussen ontwikkelaar en tester gereduceerd. Simpel gezegd: hoe eerder feedback kan worden gegeven, hoe beter. Net als Jacobson maakt ook hij gebruik van User Stories en Scenarios. Uiteindelijk worden deze beschreven in Use Cases, dus daar is een duidelijke overlap. Waar echter bij Jacobson de nadruk ligt op de Use Case, legt Pugh (niet verwonderlijk) de nadruk op het testen en de testaanpak.

Tenslotte is er het boek van Dean Leffingwell met de titel “Agile Software Requirements”, met de veelzeggende ondertitel “Lean Requirements Practices for Teams, Programs, and the Enterprise”. Dit veelomvattende werk lijkt een soort integrale aanpak van Agile en Lean methoden en gaat veel verder dan alleen het terrein van Requirements, zoals de titel doet deken. In dit boek heeft ook ATDD een plaats gekregen, zij het met minder focus dan in het boek van Pugh. De nadruk ligt vooral op het toepassen van de filosofie op meerdere niveaus, zoals de titel al suggereert. Allereerst op teamniveau, waar bekende concepten als User Stories, Personas, Backlogs en Iterations worden gebruikt. Op programma niveau wordt er gekeken naar het werken volgens een Visie en een Roadmap, de rol van de Product Owner, Release Planning en (Non-Functional) Requirements. Ook wordt er (kort) aandacht besteed aan Use Cases. Uniek naar mijn mening is het gedeelte op organisatieniveau, waar architectuur wordt geïntroduceerd in combinatie met deze Agile aanpak en er zelfs een uitstapje gemaakt wordt naar Portfolio Management. Vooral dit laatste ontbreekt naar mijn mening in veel beschrijvingen van Lean en Agile aanpakken. Immers, de korte termijn initiatieven en verbeteringen moeten mijn inziens bij voorkeur wel leiden tot realisatie van een stip op de horizon en niet in een ondefinieerbaar einddoel stranden. Dit boek lijkt dan ook het meest compleet te zijn, alhoewel het dusdanig omvangrijk is dat het toepassen van alle zaken uit dit boek wel haast een “Greenfield” nodig heeft.

Kortom, op het gebied van Lean Requirements is er de nodige informatie voorhanden. Maar welke Best Practice nu de beste is of anders gezegd, wat wanneer toegepast moet worden, is allesbehalve duidelijk. Duidelijk is in ieder geval dat (dit onderdeel van) Lean IT nog een stuk onvolwassener is dan de toepassings van Lean in een manufacturing omgeving.