Mitt blogginlägg i mars, om att ta för sig lagom från modell-smörgåsbordet, berörde även kravkommunikation. I en vinglig färd genom åren har ungefär lika många kört i båda diken: det ena med underförstådda krav (ibland med dyra missförstånd, ibland med dyra glädjekalkyler), det andra med en byråkratiserad fabrik och överdådig notation i många ritningar som få läser (ibland osammanhängande, ibland ur fas med programkod). En rimlig väg är att noga pröva ut ett fåtal diagram i praktisk användning för konkreta syften, med feedback löpande från olika roller och vid regelbundna ”iteration retrospectives”. Tanken bakom standarderna UML och BPMN var ju aldrig att alla projekt ska svälja all notation.
När man kommunicerar krav i agila projekt behöver man hela tiden ha syftet klart för sig och dosera/förpacka efter vilka roller och bakgrunder vi vänder oss till, i vilka situationer de har nytta av kravinformationen (i ledning, design, programmering, test, vidareutveckling/underhåll, personalutbildning, osv), och vilka eventuella detaljer de har störst nytta av för att förebygga missförstånd. Diagrammen på kravstadiet brukar använda mer verksamhetsanknuten/”framtung” notation än de i designen: t ex processflöden med processhierarkier alternativt verksamhetsanvändningsfall, eller domänindelning. Vissa företag har ibland använt två skilda ritverktyg, medan standarden Model Driven Architecture använder separata modellnivåer (datoriseringsoberoende, plattformsoberoende, och plattformsspecifik nivå – en och annan bloggbesökare lär nog känna igen strukturen från kursen Agile modellering med UML2).
Lika klokt är att även undvika överlappningar inomresp modell, eftersom de leder till dubbelarbete vid ändringar. Arkitekten strävar efter symmetri med ”restricted vocabulary”, dvs systemen ska utföra en typ av uppgifter på ett enhetligt sätt överallt. Något liknande gäller kraven: krav av samma typ bör man uttrycka på ett koncist snarlikt sätt överallt, med samma medel så långt möjligt.
Behov av precision medför mer modellering i kravkommunikation, men också risk för överlappning och dubbelarbete. Lagom är bäst – för eller senare inträffar en brytpunkt där marginalinsatsen överstiger marginalnyttan och fokus på dokument tränger ut det som dokumenteras.
I en granskande eller ledande roll bör man inte heller mekaniskt räkna antalet diagram och dokument (med tiden kan f.ö. antal bli omvänt proportionerlig till aktualitet). Kvalitet slår kvantitet i längden, medan dubbelarbete och dubbelunderhåll hämmar användningen av modeller i längden.
Till citatet ”you can still build significantly complex systems using only three diagrams” i mitt blogginlägg i mars kan man alltså lägga till: ”eftersom det minskar överlappning, underlättar uppdateringar, styr rätt information i rätt diagramtyp – och eftersom fler kommer att läsa dem”. Hellre än att frossa i notation har Informators modelleringskurser eftersträvat valuta för modelleringspengarna: ett smalt urval av diagram som hänger ihop och kompletterar varandra (även i övningar).
Konsult, Kiseldalen.com
UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)
Huvudförfattare UML Xtra Light – How to Specify Your SW Requirements
Samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys och design. Håller kurser i Arkitektur, i modellering (T2715, T2716), och i våras även Informators fullsatta frukostseminarium om användningsfall.