Att arbeta Agilt kan vara svårt att greppa och det är ett område som kan vara svårt att navigera i. Hur arbetar vi agilt i våra utvecklingsprocesser, vilka rutiner och lärdomar har vi?
Vilka rutiner har vi? Hur hanterar vi problemspårning, kunddemos, etc. Jag kände mig som om jag höll på att hoppa över mycket viktig information som jag skar ner saker men, så jag har bestämt mig för att göra detta till en serie blogginlägg som jag ska spruta mellan mina kollegors inlägg här och där.
Varför skriver jag detta?
"Agilt" är ett av de områden som är svåra att navigera i. Medan det finns många bra idéer och rutiner finns det också många inneord och dåliga metoder. För varje bra sätt att genomföra ett smidigt sätt att arbeta, finns det nog tio dåliga sätt att göra det på. För några år sen tillbaka, trodde jag att nyckeln till att lyckas med ett smidigt arbete var att veta varför du gjorde en viss sak.
Låt oss anta att du ska använda Scrum i ett projekt. Du har läst den officiella Scrumguiden, kanske deltagit i en kurs och fått en eller flera av certifieringarna. Vilket är bra, det innebär att du förhoppningsvis vet varför du ska göra en retrospektiv, och varför du borde ha en daglig genomgång och så vidare. Däremot är det svårt och du har kanske inte någon aning om hur man faktiskt arbetar Agilt på ett smidigt sätt, dag-till-dag.
Jag tycker personligen att ett av de mer uppenbara sätten för att se till att du misslyckas är att genomföra en ram som följer den i boken utan att förstå varför en viss typ av möte eller tidsplan finns. Det kommer att bli mycket svårt att svara på frågan om detta ger dig något värde eller inte. Och det är kärnan i det, eller hur? Att ha svaret är "ja" på frågan "Ger detta oss något värde?", Och undvik att göra saker som inte gör det. Jag ville egentligen inte diskutera Scrum i denna bloggpost (eller någon annan ram för den delen). Jag ville helt enkelt prata om ett konkret sätt att genomföra ett smidigt arbetsflöde. Dessutom ville jag prata om att nå den punkten. Jag tvivlar mycket på att någon bara säger "Hej, låt oss göra X för smidigt arbete" och bara ha allt som fungerar precis som det är tänkt. Jag tror att du måste fortsätta arbeta, förbättra, skölja och upprepa tills du får det rätt. Och även då kanske du måste ändra saker runt när ditt lag ändras. Jag kunde argumentera för att vi har "misslyckats" vid smidig före Edument, för vi har definitivt haft tillfällen när sakerna gick mindre smidigt än vad du skulle hoppas på. I själva verket var det vad vi gjorde samla data om vad som fungerade och vad som inte gjorde det.
Teamet
Jag var arkitekt / tech ledare på ett projekt som vi nyligen arbetat med, och jag kände att vi äntligen fick mycket detaljer rätt och lyckades nå den punkten där vår smidiga process bara låg i bakgrunden som något annat verktyg. Precis som vi använder Git för versionskontroll, eller använder Jira för bug / feature tracking, så borde det bara vara en del av din dagliga rutin, och du borde inte behöva tänka för hårt om det.
Ett problem med att försöka genomföra en ram exakt är att du kanske hamnar i mindre än idealiska situationer. Vad gör du när någon påpekar att "Hej, vi har inte en Scrum-mästare", till exempel? Det enkla svaret (ett som du sannolikt kommer att höra) är att du gör fel och borde hitta dig själv en Scrum-mästare. Det här säger inte riktigt hur man hanterar situationen praktiskt taget. Ur en pragmatisk synpunkt skulle jag personligen kalla detta svar fullständigt värdelöst.
Så, så långt jag kan säga, finns det några olika sätt att hantera detta. Antar vi någon ny för att fylla denna roll? Kan vara riskabelt, eftersom det förmodligen kommer att vara någon du inte har arbetat med tidigare och som har ingen kunskap om projektet. Detta kommer alltid att vara en investering i tid (och givetvis också en monetär).
Verkligheten för oss var väldigt mycket att vi inte kunde göra det här. Det här var aldrig ett alternativ, och det vi hade var en liten grupp programmerare (3 utvecklare heltid, 1-2 utvecklare som kom in / ut ur projektet när det var tillåtet), sporadisk åtkomst till en UX-designer, plus en produktägare från kundens sida, belägen i Tyskland.
Senare i projektet fick vi också ett andra lag från vårt kontor i Prag. Detta var ytterligare 3 utvecklare som arbetar med vårt team i Sverige. Detta betyder också att vi nu hade ett lag spridda över tre länder.
Av Eric Lavesson