De wereld van Practices – Wat is een Practice?

De wereld van Practices   Wat is een Practice?Bij IJI staan we een practice-gedreven aanpak voor. Zoals met veel concepten en principes geldt ook hier dat een goed begrip van wat ermee wordt bedoeld essentieel is om er echt de vruchten van te plukken. Een manier om daar invulling aan te geven is om te kijken naar criteria waaraan je een goede practice kunt herkennen. Maar voor we dat doen, is het goed om eerst te kijken naar de definitie en kenmerken van een practice en een practice-gedreven aanpak.

Onder een practice-gedreven aanpak verstaan we onder meer “het samenstellen van een effectieve manier van werken op basis van relevante procescomponenten”. In plaats van moeizaam te proberen een procesraamwerk toe te snijden op een specifiek project draaien we het om; we selecteren alleen relevante procescomponenten en assembleren die tot een consistent proces. En zo’n procescomponent noemen we dan een practice. Use Cases, User Stories en Iteratief ontwikkelen zijn enkele voorbeelden van practices. Andere voorbeelden zijn Operationaliseren Systeem en Datamigratie. In deze context is het ultieme doel van een practice-gedreven aanpak “betere resultaten boeken met softwareontwikkeling”. Hierbij kun je dan denken aan betere software, goedkoper, sneller en een prettigere manier van werken.

 

Een practice-gedreven aanpak vraagt om met een andere bril naar de totstandkoming en het gebruik van ontwikkelprocessen te kijken zodat tal van problemen worden opgelost die ons er vaak van weerhouden om echt succesvol te kunnen zijn. Deze problemen en de uitweg zijn goed beschreven in het artikel Enough Proces, Let's do Practices. Het komt er kortweg op neer dat organisaties en projectteams daadwerkelijk en van dag tot dag baat moeten hebben bij een ontwikkelproces. Het komt namelijk nog vaak voor dat een ontwikkelproces niet wordt gevolgt of dat het eerder een blok aan het been is. Ook kan het zijn dat de implementatie van een procesraamwerk als geheel gewoon te veel vraagt van een organisatie of te weinig oplevert.

Anders kijken naar het verzamelen en delen van kennis is een deel van de oplossing. Stel je eens voor dat je:

  • Op een elegante manier de kennis van duizenden ervaringsdeskundigen kunt ontdekken, verzamelen en vastleggen.
  • Kennis supertoegankelijk kunt maken.
  • Zeer snel toegang krijgt tot de kennis die je nodig hebt, alleen die kennis, wanneer je het nodig hebt en niet eerder.
  • Teams in staat stelt om met behoud van controle hun eigen innovatieve manier van werken samen te stellen, helemaal toegesneden op de behoefte.
  • Stapsgewijs procesverbetering mogelijk maakt zodat risico’s worden geminimaliseerd.
  • Nieuwe werkwijzen zeer eenvoudig kunt verweven met bestaande zodat je het goede kunt behouden en het nieuwe eerst op kleine schaal in de praktijk kunt beproeven.

Een practice-gedreven aanpak maakt dit allemaal mogelijk.

Volgens de definitie is een practice een manier om op systematische en verifieerbare wijze een specifiek aspect van een probleem op te lossen. Enkele kermerken van een goede practice zijn:

  • Een duidelijke focus op een specifiek aspect van softwareontwikkeling
  • Een aanpak om een probleem te duiden en de strategie om het probleem op te lossen
  • Instructies om te verifieren dat het probleem daadwerkelijk is opgelost en,  indien relevant, een beschrijving van welk ondersteunend bewijs hiervoor benodigd is
  • Een beschrijving van hoe de te volgen strategie in de dagelijke praktijk moet worden uitgevoerd.

Hierbij is het verder belangrijk om te weten dat een practice:

  • Niet beoogt om een probleem in zijn geheel op te lossen.
  • Daadwerkelijk door iemand in de praktijk kan worden uitgevoerd.
  • Een helder begin en eind heeft.
  • Een element van verificatie in zich heeft en zonder eigenlijk niet compleet is.

Simplistisch voorgesteld beschrijft een practice: wat moet worden geproduceerd, hoe je dat moet doen en welke bekwaamheden je daarvoor nodig hebt. En zou je in EssWork naar bijvoorbeeld de Use Case Essentials practice kijken, dan zul je zien dat een practice meer informatie kan bevatten zoals een workflow, hints en tips, veel gemaakte fouten, beschrijvingen van concepten en compleetheidscriteria.

Het simpelweg verzamelen van essentiële informatie maakt een practice echter nog geen goede practice. Met name de focus op een specifiek aspect van softwareontwikkeling (of teamwork) is zeer relevant. Deze focus kunnen we concreet maken door goed te letten op het onderwerp van een practice en het aandachtgebied waarbinnen een practice zich begeeft.

Binnen softwareontwikkeling kan een practice zich richten op drie aandachtsgebieden, de klant (customer), de oplossing (solution) en de inspanning (endeavour).

Customer – Ieder software project heeft een klant en ieder process dient het perspectief van die klant mee te nemen om ervoor te zorgen dat de juiste oplossing wordt ontwikkeld.

Solution – Ieder software project dient werkende software op te leveren en ieder process dient te een team een set van werkwijzen te bieden die het team helpt om op productieve en constructieve wijze goede kwaliteit software te ontwikkelen.

Endeavor – Softwareontwikkeling is een serieuze aangelegenheid die normaliter vele weken in beslag neemt, vele verschillende belanghebbenden raakt en meestal een team van specialisten vereist. Ieder practisch process dient een set werkwijzen te bieden voor het effectief plannen, leiden en bewaken van de benodige inzet van het team.

De onderstaande figuur geeft een overzicht van onder andere de werkproducten en activiteiten van de Use Case Essentials practice.

De wereld van Practices   Wat is een Practice?

Use Case Essentials Overview

Wat bij nadere bestudering opvalt is dat alle activiteiten en werkproducten geel van kleur zijn. Dit betekent dat ze allemaal binnen het aandachtsgebied Solution vallen. Waren ze groen geweest, dan zouden ze binnen het aandachtsgebied Customer zijn gevallen of het aandachtsgebied Endeavour wanneer ze blauw zouden zijn geweest.

Samengevat geldt dat bij een goede practice alle werkproducten en activiteiten ultiem binnen één aandachtsgebied vallen. Uitzonderingen zijn mogelijk of soms noodzakelijk om de practice te kunnen laten werken. Zo kent de Architecture Essentials practice een Coach Team activiteit (Endeavour) om ervoor te zorgen dat een team zich een software architectuur goed eigen kan maken.

Behalve een eenduidig aandachtsgebied is er nog een manier om een practice een goede focus te geven en dat is het onderwerp van de practice. Een goede practice heeft ultiem één en soms een beperkt aantal onderwerpen. Een heel specifiek onderwerp van de Use Case Essentials practice is de Use Case Module, zie ook de onderstaande figuur.

De wereld van Practices   Wat is een Practice?

Use Case Module Practice Card

In het kort is een Use Case Module een set van flows of delen van een use case die gezamenlijk door het ontwikkelproces gaan. Aan de linkerkant van de bovenstaande practice card staat een state machine of toestandsdiagram die de levenscyclus van een Use Case Module gedefinieerd. De figuur laat zien dat een Use Case Module vijf toestanden kent.

Op Scoped moet duidelijk zijn welke use-case flows, special en supplementary requirements de use case module omvat.  Op Specification Agreed moet er overeenstemming zijn over de inhoud van de Use Case Module. Op Realized moet duidelijk zijn welke componenten op welke manier gaan samenwerken om tot een executeerbaar systeem te komen. Op Implemented moet de Use Case Module executeerbaar zijn. Tot slot moet op Verified de executeerbare Use Case Module voldoen aan de specificatie.

De mogelijke toestanden van de Use Case Module maken inzichtelijk in welke volgorde de Use Case Module door het ontwikkelproces gaat. Of anders gezegd, op welke manier stapgewijs voortgang kan worden geboekt. Een onderwerp van een practice noemen we ook wel een Alpha. Alpha’s zijn die dingen die een softwareproject altijd heeft, ongeacht het type project of de aanpak. Verder zijn Alpha's ook niet tastbaar en zijn werkproducten nodig om er iets over te kunnen zeggen. Practices geven als het ware invulling aan Alpha’s. Alpha hebben ook verband naar planning en beheersing; ze geven inzicht in waar je bent en welke activiteiten je moet uitvoeren om van de ene toestand naar de volgende toestand te komen. De status van werkproducten vormen hierbij dan de bewijslast waarmee kan worden aangetoond dat een bepaalde status is behaald.

Samengevat geldt dat een goede practice ultiem één Alpha heeft waar alle werkproducten en activiteiten betrekking op hebben. In de praktijk kunnen we hier iets losser mee omgaan om een practice goed te kunnen laten werken.

De eerder getoonde overzichtskaart van de Use Case Essentials practice laat bijvoorbeeld meer Alpha’s zien dan alleen de Use Case Module: Opportunity, Requirements, Change, System, Defect, Test, Project, Risk en Task. Bijna al deze Alpha’s zijn afkomstig uit het model dat onder EssWork zit. Dit practice onafhankelijke model of Kernel maakt het mogelijk om meerdere practices samen te smelten tot een consistent geheel. Met practices kun je dan op relevante plekken Alpha’s aanvullen met relevante informatie, in dit geval use case specifieke zaken. Zo is Change geïntroduceerd om grip te krijgen op wijzigingen. En is System aangevuld met essentiële content in de vorm van mogelijke Changes en één of meerdere Use Case Modules en het inzicht dat deze worden beschreven middels een use case model en supplementary requirements.

Op dit punt aangekomen hebben we de definities en de essentie van practices en een practice-gedreven aanpak en enkele kenmerken van goede practices in het kort behandeld. Uiteraard valt er nog veel meer over te zeggen. Wanneer je meer wilt weten, bekijk dan bijvoorbeeld de video over Practice Execution of stuur me een email: [email protected]

<!--[endif]--><!--[if gte mso 9]> <![endif]--><!--[if gte mso 9]> Normal 0 false 21 false false false NL X-NONE X-NONE <![endif]--><!--[if gte mso 9]> <![endif]--> <!--[endif]-->

De onderstaande figuur geeft een overzicht van onder andere de werkproducten, activiteiten van de Use Case Essentials practice.

  

Wat bij nadere bestudering opvalt is dat alle activiteiten en werkproducten geel van kleur zijn. Dit betekent dat ze allemaal binnen het Solution aandachtsgebied vallen. Waren ze groen geweest, dan zouden ze binnen het Customer aandachtsgebied zijn gevallen of het Endeavour aandachtsgebied wanneer ze blauw zouden zijn geweest.

In het kort is een Use Case Module een set van flows of delen van een use case die gezamenlijk door het ontwikkelproces gaan. Aan de linkerkant van de bovenstaande practice card staat een state machine of toestandsdiagram die de levenscyclus van een Use Case Module gedefinieerd. De figuur laat zien dat een Use Case Module vijf toestanden kent.
Op Scoped moet duidelijk zijn welke use-case flows, special en supplementary requirements de use case module omvat.  Op Specification Agreed moet er overeenstemming zijn over de inhoud van de Use Case Module. Op Realized moet duidelijk zijn welke componenten op welke manier gaan samenwerken om tot een executeerbaar systeem te komen. Op Implemented moet de Use Case Module executeerbaar zijn. Tot slot moet op Verified de executeerbare Use Case Module voldoen aan de specificatie.
De mogelijke toestanden van de Use Case Module maken inzichtelijk in welke volgorde de Use Case Module door het ontwikkelproces gaat. Of anders gezegd, op welke manier stapgewijs voortgang kan worden geboekt. Een onderwerp van een practice noemen we ook wel een Alpha. Alpha’s zijn die dingen die een softwareproject altijd heeft, ongeacht het type project of de aanpak. Practices geven als het ware invulling aan Alpha’s. Alpha hebben altijd verband naar planning en beheersing.Ze geven inzicht in waar je bent en welke activiteiten je moet uitvoeren om van de ene toestand naar de volgende toestand te komen. De status van werkproducten vormen hierbij dan de bewijslast waarmee kan worden aangetoond dat een bepaalde status is behaald.
Samengevat geldt dat een goede practice ultiem één Alpha heeft waar alle werkproducten en activiteiten betrekking op hebben. Net zoals bij de aandachtsgebieden moet hier niet te rigide mee worden omgesprongen om een practice goed te kunenn laten werken.
De bovenstaande overzichtskaart van de Use Case Essentials practice laat bijvoorbeeld meer Alpha’s zien dan alleen de Use Case Module Alpha. Er zijn er behalve de Use Case Module inderdaad nog een aantal: Opportunity, Requirements, Change, System, Defect, Test, Project, Risk en Task. Bijna al deze Alpa’s zijn afkomstig uit het model dat onder EssWork zit. Dit practice onafhankelijke model, of Kernel maakt het mogelijk om meerdere practices samen te smelten tot een consistent geheel. De Alpha’s zijn dus enerzijds toegevoegd om samenwerking met andere practices mogelijk te maken. Anderzijds kunnen practices op belangrijke plekken Alpha’s aanvullen met relevante informatie, in dit geval use case specifieke zaken. Zo is Change geïntroduceerd om grip te krijgen op wijzigingen. En is System aangevuld met essentiële content in de vorm van mogelijke Changes en één of meerdere Use Case Modules en het inzicht dat deze worden beschreven middels een use case model en supplementary requirements.
Op dit punt aangekomen zijn de definities en de essentie van practices en een practice-gedreven aanpak en enkele kenmerken van goede practices besproken. Uiteraard valt er nog veel meer over te zeggen. Wanneer je meer wilt weten, bekijk dan bijvoorbeeld de video over Practice Execution of neem contact op via [email protected]