I den lilla världen kan ett ensamt team leverera färdiga funktioner med bara några veckors (en sprints) mellanrum. Eftersom en funktion kan beskrivas i en sk "User Story" har man kallat de saker som ett team levererar under en sprint för just en "user story". Flera funktioner som hör ihop brukar kallas för en "epic".
Backloggverktyget Jira låter därför scrumteam hantera krav i ärenden av typen "Jira User Story", och flera sådana hanteras av den samlande ärendetypen "Jira Epic". I ärendetypen "Jira Epic" kan man följa upp hur varje ingående "Jira User Story" färdigställs.
Men om man måste skala upp det här? Om man inte kan leverera en funktion under en sprint utan behöver flera sprintar? Om det är mer än ett team som ska jobba med samma funktion? Alltså om arbetet med samma funktion måste delas upp mellan flera team och/eller delas upp över tid?
I Dean Leffingwells fyrdelade modell för en systemutvecklingsbacklogg (från Agile Software Requirements 2008, som senare blev ramverket SAFe) inför han därför en ärendetyp mellan user story och epic: en sk "feature". Tanken är att man på en övergripande nivå kommer fram till vilka funktioner man vill leverera, fångar var och en i en feature, och sedan bryts varje feature upp i mindre skivor av ett eller flera team och hamnar på deras respektive team-backloggar. På så sätt kan teamen följa upp hur de levererar en hel funktion även om de måste dela upp arbetet i delmål.
De sprintbara delmålen som hamnar på varje utvecklingsteams backlogg heter även i Leffingwells modell "user story". Så förhållandet i Leffingwells modell mellan "SAFe User Story" och "SAFe Feature" är precis densamma som i Jiras modell mellan "Jira User Story" och "Jira Epic". En "Jira Epic" delas upp i flera "Jira User Stories" på samma sätt som en "SAFe Feature" delas upp i flera "SAFe User Stories".
Samtidigt innehåller som sagt Leffingwells modell fortfarande begreppet "epic" ("SAFe Business Epic" samt "SAFe Architectural Epic"), och detta skapar förvirring när folk vill använda Jira för att hantera SAFe:s modell av backloggen. En "epic" i Leffingwells modell består av flera "SAFe Features" som i sin tyr består av flera "SAFe User Stories". En "epic" i Jiras värld består av flera "Jira User Stories" och det är allt.
Hur gör man? Tänker man uppifrån och ner så är det frestande att att beskriva "SAFe Business Epic" och "SAFe Architectural Epic" med hjälp av "Jira Epic". Det blir då på samma sätt frestande att använda en "Jira User Story" för att beskriva en "SAFe Feature". Men då orsakar man en massa svårigheter för alla andra i samarbetet.
En "SAFe Feature" ska inte ligga på ett enskilt utvecklingsteams backlogg utan på en sk "Program Backlog" för att hanteras på en överordnad nivå. En "Jira User Story" ska däremot handhas av ett team.
En "SAFe Feature" ska inte vara bunden till en viss sprint. I Jiras sprintplaneringsverktyg ska "Jira User Stories" bindas till en viss sprint.
En "SAFe Feature" ska kunna delas in (av teamen) i flera "SAFe User Stories", och varje "SAFe User Story" ska kunna estimeras och planeras och utvecklas av ett team för sig. Men om vi använt "Jira User Story" för att beskriva en "SAFe Feature", vad ska teamen använda för att kunna hantera sina "SAFe User Stories"? Hur ska de kunna göra sitt jobb om vi tagit verktyget från dem och använt det till annat?
Dessutom är det så att Jiras styrka är möjligheten att bringa ordning i en mängd arbetspaket och hur de förhåller sig till varandra. Det finns altid många fler "SAFe User Stories" än "SAFe Features", och många fler "SAFe Features" än "SAFe Epics". Det verkar vara dumt att slösa ärendetyper i Jira på att hantera ett fåtal saker som dessutom sällan förändras. Effektmålen och förutsättningarna för varje epic tenderar att vara stabila, det är informationen om hur epicen ska implementeras (vilket fångas i features och user stories) som förändras ofta och kräver verktygsstöd.
Så det rimliga är såvitt jag har sett att använda "Jira User Story" för att fånga en "SAFe User Story", och använda "Jira Epic" för att fånga en "SAFe Feature". Jag har sett konsekvenserna både av att använda Jira Epic för epic och för feature, och det blir oerhört trassligt för teamen att kunna koordinera sitt arbete om de inte får använda Jira User Stories för sina teambackloggar.
Vad ska man använda för att fånga sina "SAFe Epics" då? Man kan använda "Jira Epics" och länka till andra "Jira Epics" som fångar features. Man kan använda ett annat verktyg. Jag har goda erfarenheter av antingen en mapp i ett filarkiv (under versionskontroll), eller en wikisida per epic (kanske i Confluence, Jiras syskon som är en wiki). Låt sedan de "SAFe Features" som tillhör denna epic peka ut länken eller sökvägen dit. Sätt en "label" på din "Jira Epic" (="SAFe Feature") som beskriver vilken epic det rör sig om. Ha ett prefix i namnet på varje "SAFe Feature" som pekar ut vilken epic det rör sig om.
Det enda argumentet som jag tycker håller emot tanken att använda "Jira Epic" för att hantera en "SAFe Feature" är att man tyvärr inte kan ordna sina "Jira Epics" i en sträng ordning. Man kan alltså inte prioritera sina "SAFe Features", sin "Program Backlog", på samma sätt som andra backloggar. Men i praktiken har jag sett att det inte är något problem. På epicnivå handlar det inte så mycket om att prioritera "SAFe Features" löpande, utan om att bestämma vilka som ingår i en viss epic och vilka som inte gör det. Behovet av att dra-och-släpp-sortera sin programbacklogg är långt mindre än behovet av att dra-och-släpp-sortera teambackloggarna. Det är teamen som har det största behovet av "Jira User Stories", så låt dem använda dem till sina "SAFe User Stories".
När man skapar ett smidigt lean/agilt flöde börjar man från flaskhalsarna och arbetar sig bakåt. Eftersom utvecklingsteamen är den trånga sektorn behöver vi uppfylla deras behov av smidigt verktygsstöd först. Fungerar inte golvet smidigt kommer ingenting att fungera smidigt.
Inga kommentarer:
Skicka en kommentar