I den här tredelade serien om Kanban för DevOps förklarar Dominica DeGrandis, chef för utbildning och coachning på Planview AgilePlace, tre viktiga skäl till varför IT-Ops-team och de som implementerar en DevOps värdekedja använder en lean flow-strategi för produktutveckling. Här är första delen.
Skäl #1: Arbetet är inte klart förrän det fungerar i produktionen.
Det finns ett skämt inom mjukvaruutveckling om att vara "klar" och "klar". Enkel utförd är en plattityd, dubbel utförd är en replik. Korken spricker, banners flyger, den nya funktionen är "klar" - men det återstår fortfarande mycket arbete. Arbete som kräver att någon från verksamheten stannar kvar för att få det "gjort".
Double-done innebär den verkliga mållinjen, när alla kan slappna av och göra sig glada - ofta ett bra tag efter det att koden kan levereras eller till och med levereras till produktion. När alla operativa uppgifter verkligen är gjorda är festen oftast slut och det finns ingen annan utväg än hem, för att sova några timmar innan man reser sig upp för att börja arbeta igen.
Lean flow - även känt som Kanban för kunskapsarbete - lyfter upp verksamheten ur den dubbelt utförda röran. Som ett systemtänkande uppmuntrar det utveckling och drift att kartlägga hela arbetsflödet och ta hänsyn till alla relevanta uppgifter, även de som vanligtvis förpassas till efterproduktion. Denna enhetliga arbetsström ökar oddsen för att alla ska kunna fira att de har passerat mållinjen tillsammans.
Varför det finns metoder för "dubbelt utfört" färdigställande
Innan vi undersöker varför driftsteam använder en lean flow-metod, ska vi titta närmare på de affärsmässiga skälen till vanliga "dubbelarbete": marknadsföring, underhåll och risk.
Marknadsföring
Generellt sett struntar kunderna i den enda gjorda fanfaren. De bryr sig inte om att koden är i ett skick som kan levereras. För kunderna är den nya funktionen inte riktigt färdig förrän koden har levererats till produktionen, stabiliserats och fungerar korrekt. När det gäller marknadsföring av funktioner är dock en enda gång en bra signal för att få återkoppling, för att öka marknadsintresset och för att föregripa den dubbla gången.
Underhåll
För att förbli konkurrenskraftiga behöver företag en viss nivå av förtroende för att se till att den nya funktionen är motståndskraftig - att den övervakas och underhålls. Modellen med dubbla åtgärder ger företagen ett fönster (vanligtvis ett för kort fönster) för att skaffa de nödvändiga elementen för motståndskraft, t.ex. tillräcklig hårdvarukapacitet, lagring och säkerhet, när användarmängden ökar.
Risk
För att undvika risken för misslyckade uppdateringar måste flera teammedlemmar lära sig att felsöka och åtgärda problem med den nya funktionen. För att underlätta framtida stödfunktioner behövs någon form av dokumentation. Med hjälp av dubbelarbete kan man kontrollera att stödsystemen är tillräckliga för att förutse och minska riskerna.
Även om dubbelarbete kan uppfylla vissa affärsbehov, kan en lean flow-metod hantera alla ovanstående och mer därtill, inom ett helt öppet arbetsflöde.
Kanban för DevOps: Att korsa mållinjen tillsammans
Kanban ger en genomgående synlighet för alla tillstånd som arbetet måste genomgå för att funktionen ska vara tillförlitlig för kunderna och säker för företagen.
Lean flow-metoder använder Kanban-tavlor för att skapa en synlig koppling mellan alla arbetstillstånd i systemet. Det blir uppenbart att blockerat arbete hindrar annat arbete från att slutföras. Beroenden mellan grupper eller med tredjepartsleverantörer framstår som obestridliga. Och eftersom alla de kompetenser som krävs för att slutföra en funktion har en röst i processen blir det dessutom en trevlig upplevelse för de anställda.
Slutsats
Med Kanbans slut-till-slut- och lean-flödesmetod kan "done-done" bli verkligt done. När vi kan visualisera och ta hänsyn till hela arbetsflödet kan flaskhalsar som tidigare varit osynliga åtgärdas, uppgifter som krävs efter att koden har distribuerats till produktionen kan bli vanliga och alla kan delta i festen vid mållinjen.
Ta reda på det andra skälet till varför IT Ops använder lean flow - läs del två i serien Kanban for DevOps.