Agile och CMMI , hur fungerar de tillsammans?

Agile och CMMI är inte samma sak

Lättrörlig utveckling är en filosofi och ett antal principer om vad som är viktigt inom mjukvaruutveckling. De olika utvecklingsprocesserna, Scrum, XP, FDD, DSDM, Lean development pch så vidare, omsätter sedan dessa i processbeskrivningar med roller, aktiviteter och artefakter.

CMMI är en mognadsmodell som definierar ett antal områden inom vilka man bör ha ett definierat arbetssätt. Det är inte en processbeskrivning utan ett sätt att bedöma processer. Denna bedömning görs antingen för att få en klassning (CMMI-nivå) eller, vilket är betydligt vanligare, att identifiera förbättringsområden i sina processer.

Så det finns ingen konceptuell motsägelse mellan agile och CMMI – de är olika saker.

Var kommer motsättningen ifrån?

CMMI innehåller, förutom de beskrivningar på processområden att förbättra, ett antal exempel på vad som kan göras för att få ett definierat arbetssätt inom de olika områdena. Dessa exempel (”best practises”) är hämtade ur ett stort material från verkliga projekt i organisationer som har lyckats bra. Det tar dock ett antal år från att processer definieras, används i verkliga projekt, identifieras som framgångsrika, generaliseras och infogas i CMMI. De exempel som finns är hämtade från traditionell plandriven utveckling. Just nu pågår arbete med version 1.3 av CMMI och ett av delmålen är att få tydligare kopplingar till lättrörlig utveckling.

Agile, å andra sidan, har en tendens att fokusera på delar av utvecklingsprocessen och förutsätta att andra finns på plats. Scrum fokuserar på projektledning och XP på det tekniska arbetet och ingen av dem berättar så mycket om hur t ex intressenthantering sköts. Det förutsätts bara att det finns en kundrepresentant eller produktägare som gör det.

Hur CMMI är uppbyggt

CMMI definierar ett antal processområden som anses viktiga för att få en stabil, skalbar och effektiv systemutvecklande organisation. Inom varje processområde definieras ett antal mål som måste vara uppfyllda. Dessa mål står inte i konflikt med lättrörlig utveckling. Eftersom CMMI riktar sig mot en utvecklande organisation och Scrum, XP etc.  riktar sig mot ett utvecklande projekt så finns det flera mål i CMMI som inte berörs i Scrum, XP etc., men som i hög grad berör utvecklande projekt. CMMI har ett större scope än de flesta lättrörliga processer.

För varje mål finns det ett antal tillvägagångssätt (”Practices”). Dessa är inte obligatoriska utan ”förväntade”. Det vill säga om dessa inte kan utförs så skall man kunna visa hur syftet fås på annat sätt. Ett vanligt misstag är att dessa tillvägagångssätt ses som aktiviteter i en process vilket leder till en väldigt administrativt tung process. Det man istället vill är att få till få processaktiviteter som täcker in många olika tillvägagångssätt från flera olika mål. Det lyckas lättrörliga processer bra med. Det finns dock ett antal tillvägagångssätt i CMMI som är svårförenliga med lättrörliga processer.

Inom varje tillvägagångssätt finns det underliggande tillvägagångssätt (”Subpractices”) och exempel på dokument (”Typical Work Products”). Dessa är varken obligatoriska eller förväntade utan ges bara som information för att lättare förstå tillvägagångssätt och mål. Dessa är ofta beskrivna på ett sätt som inte är förenligt med lättrörliga processer. Termer som ”Establish…”, ” Records of…” och ” Identify and document…” är vanliga. Inom agile finns alltid en strävan att minimera mellanresultat och istället arbeta direkt på leverablerna.

Så även om det inte finns någon konflikt mellan CMMI och lättrörliga processer så är det lätt att förstå att det vänder sig i magen för en förespråkare för agile när han eller hon läser den underliggande dokumentationen. Du kan läsa mer specifika exempel på hur CMMI bör tolkas i förhållande till Agile nedan.

CMMI missförstås alltför ofta och läses som om det vore en processbeskrivning. Det är det inte – det är ett ramverk för att identifiera och hantera förbättringar.

Vad är Agile?

Lättrörlig utveckling är en filosofi kring mjukvaruutveckling som är centrerad kring förändringsbenägenhet, samarbete och enkelhet. Grundläggande är att vi skall ha ett arbetssätt där förändring inte innebär merarbete. Ett exempel på detta som återkommer i alla de olika metoderna är att utveckla i korta iterationer och att lämna varje iteration med en uppdaterad produkt som håller leveranskvalitet. Kärnan i Agile beskrivs bra i ”Manifesto for Agile Software Development”.

I sin strävan efter enkelhet så väljer de olika lättrörliga metoderna att fokusera sina beskrivningar på delar av utvecklingsarbetet. Detta är bra för att fokusera nödvändiga förändringar för att skapa ett mer lättrörligt arbete, men det ska inte tolkas som att andra delar av utvecklingsarbetet är onödigt. Scrum säger, t ex, att i de delar som Scrum inte beskriver skall sunt förnuft och goda erfarenheter användas för att komplettera. Ett annat sätt att uttrycka detta är att Scrum, XP, FDD etc. alla är implementationer av CMMI som mer eller mindre täcker det scope som CMMI spänner upp.

Agile och CMMI – kompletterar varandra

Lättrörlig utveckling ger ett bra ramverk för effektiv utveckling med enkla och intuitiva processer. Oavsett vilken eller vilka metoder, Scrum, XP, FDD etc. ni väljer att använda i er implementering av agile, så fyller det inte hela ert behov av allt som ingår i utvecklingsverksamheten. Det behövs komplettering och anpassning till befintliga metoder för att få ett arbetssätt som passar era behov. Det är också viktigt att skapa utrymme för kontinuerlig förbättring för att hantera nya behov och optimering av kostnad, kvalitet, ledtid, flexibilitet mm. Här är CMMI väldig användbart verktyg för att guida er till rätt kompletteringar och de bästa anpassningarna för full effekt av agile. CMMI ger er även förutsättningarna för att få på plats en strukturerad kontinuerlig förbättring.

------------------------------------------------------------------------------------------------

Exempel på område: Projektuppföljning

CMMI definierar följande mål inom området projektuppföljning (PMC):

• Actual performance and progress of the project are monitored against the project plan.
• Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.

Här finns ingen konflikt med t.ex. Scrum. Där har vi en projektplan i form av definierade iterationer, planerad funktionalitet, aktiviteter och möten för pågående iteration. Uppföljning sker med t.ex. med en burn down chart. Åtgärder görs vanligtvis genom att ta bort lågt prioriterad funktionalitet men kan även vara förenkling av implementation, ändring av metafor eller i mer extrema fall avbruten iteration med påföljande omplanering.

För det första målet ovan är de förväntade tillvägagångssätten:

• Monitor the actual values of the project planning parameters against the project plan.
• Monitor commitments against those identified in the project plan.
• Monitor risks against those identified in the project plan.
• Monitor the management of project data against the project plan.
• Monitor stakeholder involvement against the project plan.
• Periodically review the project's progress, performance, and issues.
• Review the accomplishments and results of the project at selected project milestones.

Läser man dessa som separata aktiviteter så kan de vara svåra att hitta men inte heller här har vi någon konflikt med Scrum. ”Monitor”-punkterna ovan hanteras under Daily Scrum där problem och avvikelser från plan identifieras. Den näst sista hanteras både av Daily Scrum och av demonstrationen i slutet av iterationen viken också fungerar som milstolpsgranskning.

Lite svårare blir det när man går ner i texten med exempel under varje tillvägagångssätt som vanligtvis inte beskriver en typisk lättrörlig process. Syftet är ofta att inget skall missas men vitsen med listor över t.ex. avvikelser från plan minskar snabbt om man istället snarast åtgärdar planen då avvikelser inträffar.

Exempel på område: Kravhantering

CMMI definierar följande mål inom området Kravhantering (RM):

• Requirements are managed and inconsistencies with project plans and work products are identified.

På målnivå finns här heller ingen konflikt. Vi vill hålla reda på krav, t ex med hjälp av en product backlog och en sprint backlog. Om krav är i konflikt med iterationsplan eller annat som t ex testkod så vill vi identifiera och åtgärda detta.

Det ovanstående målet har följande förväntade tillvägagångssätt:

• Develop an understanding with the requirements providers on the meaning of the requirements.
• Obtain commitment to the requirements from the project participants.
• Manage changes to the requirements as they evolve during the project.
• Maintain bidirectional traceability among the requirements and work products.
• Identify inconsistencies between the project plans and work products and the requirements.

Det första av dessa hanteras i stor utsträckning av att ha en kundrepresentatnt på plats eller att produktägaren löser detta. Den andra hanteras vanligtvis i planeringssessionen inför respektive iteration. Den tredje, förändrade krav, hanteras vanligtvis i lättrörliga processer på samma sätt som nya krav. Den sista är heller inte så konstig, om krav är i konflikt med sprint backlog eller annat som t ex testkod så vill vi identifiera och åtgärda detta. Men den näst sista, om dubbelriktad spårbarhet, är sällan uppfylld i lättrörliga processer.