11 Scrum

Välkommen till del 11 av avsnittet Processer och process modeller. I den här delen kommer vi att gå in och titta på den agila processen. Scrum och den är utformad och vad den adresserar. Vi har tidigare tittat på XP som en ganska stor process som talar om till exempel hur vi ska koda, hur vi ska testa Scrum. En betydligt mindre process som fokuserar mer på hur projekthantering ser ut. Och skam har som nyckelbegrepp. Pigs and chickens. Och. Det finns en del i det här som är en liten historia som adresserar hur man ser bakgrunden i att vara pigg eller en chicken, en gris eller kyckling i det här. Det är en lite ordvits, så den måste jag dra på engelska. Så det pekar rakt. What about what to do their lives? Är du att budet på duon inbjudit till ett avbrott från start och med stark röst från Together? Där befann sig som student en debatt där responsen var god. Save the look. Ni kanske vet hur jag röstar. IT must have nice Neymar restaurant something but what cool restaurants. En bar längs en hamn ägs. Because I will be coming back be in world. Så nyckeln i Scrum är att skilja på. Vem är communityt och vem är inte våld som en skillnad där committed är? Depeche Mode. Ham där grisen är den som står där och har kommit ut måste mer som en del i det hela. Men vi har å andra sidan har vi en deg som är inte mycket mer än våld, därför att det. Hörnan i det här fallet bidrar med är ägget inte sig själv. Grisen bidrar med sig själv hel och hållen, men hönan räcker bara fram någonting annat som inte är sig själv. Skillnaden mellan att vara komiker och att vara en wold är viktig att ta hänsyn till i Scrum och vem som har kontroll i Scrum. För att kunna återkomma till att man definierar roller i fram utifrån att vara committed eller icke våld. Så iskallt som man hände. Inte något som kom vid millennieskiftet. Det fanns tankar runt detta tidigare och om man tittar i olika papper så kan man gå tillbaka till 80 talet där man började tala om Scrum som en term och scrum som kommer från rugby där en Scrum är klungan som gemensamt pressar spelet framåt och detta dyker upp 86 som en flexibel utvecklingsmodell ungefär. Detta plockas upp lite senare i början på 90 talet som referenser till de första modellerna och under 90 talet så börjar Schwaber att utveckla det som blir mer formellt, Scrum. Han använder inte namnet från början, men i mitten på 90 talet så gör han ett paper tillsammans med Sauerland, som också är ett namn inom den mjukvaruutveckling biten där de beskriver det som kommer att vara Scrum som en del, och Scrum talar om hur man organiserar och planerar projekt. Den säger inte något om exakt hur man gör i utvecklingen eller hur man testar i tidigare del där vi talade om XP så talar om att Expert ska genomföra enhets tester. Vi ska testdriven utveckling, vi skapar programmera till exempel och andra sådana saker. Sådant säger Scrum ingenting om hur du gör under själva utvecklingen av själva testningen och så. Det är upp till dig att definiera. Det lägger sig inte Scrum i sig självt i. Och när man tittar på Scream så många bilder i dag hugger bort den första delen. Där är nämligen en del som ibland presenterar Scream som någonting som man bara jobbar på i det som kallas sprintar. Man har ingen plan man håller på hela tiden. Men det som faktiskt finns i originalbilden och i original för fram, det är den här delen. Som faktiskt talar om att det finns en vision. Där finns en planerad plan för releaser och milstolpar. Return David West var ute efter det här och att här är en del som handlar om att prioritera krav och det man talar om sin produkt back logg. Så glöm inte bort att den här biten finns inom fram. För en betydligt vanligare del som man ser. Den bild som illustrerar detta är den här bilden som visar att vi har klippt bort den första delen innan vi påbörjar hela vår stora Scrum process. Och här har vi vår produkt back up som är övergripande arbets paket funktionalitet. Vi vill göra till exempel de krav som finns. De är inte detaljerade, de är ganska övergripande olika former av använda funktionalitet som ska finnas eller större saker som behöver göras. Sedan jobbar man i sprintar som enligt Schwaber är 30 dagar, ingenting annat. Schwaber menar på att har man någonting annat än 30 dagars sprintar så är det inte Scrum. Men det finns en ganska stor variation i vad olika organisationer kallar Scrum. Man kan se sprintar från ett par veckor till ett par månader. Drar man det kortare så börjar man få svårt att se fram för det som vi kommer att se. Delar man har svårt att hinna med och man börjar ha sprintar som är bara en vecka eller så drar man ut på det mer så är det också svårt och säga att det här är Scrum och man börjar tala om ett halvår på sprintar för då går det för lång tid emellan. Man kan inte definiera arbetet för ett helt halvår i detalj, men det man gör inför varje sånt här 30 dagar är att man tar från sin back blogg. Hur många delar den tror att man hinner uppfylla och bli klar med under de här 30 dagar sprinten och då väljer man ut det här och bryter ner det som kallas för en sprint back. Så de här lite större arbets paketen bryter man ner i mindre delar och de här delarna de bryts ner i ska helst var någonting man kan göra på en arbetsdag, det vill säga något som en person kan göra på åtta timmar. Så man gör en ganska detaljerad plan. Men med kort framförhållning man gör den här detaljerade planen för 30 dagar så jobbar man i den här och då är det de här 24 timmars cykler för varje arbetsdag där man då ska hinna med en sådan här bit sprint back och en per person som minst. Och sedan efter 30 dagar så tar man en ny bit av sin produkt och bryter ner och planerar de små delarna och jobbar vidare med. Och helst ska varje sådan här sprint resultera i ett nytt instrument, en ny Willis av mjukvaran. I praktiken så vet vi att det där kanske inte alltid fungerar så det där instrumentet kanske en prototyp kanske är någonting som inte är helt färdigt, men någonting man kan testa och få information om i alla fall. Så det här är grymt. Processen för Scrum är det här har sin makt att bryta ner den till en mer detaljerad sprint och de delarna man tror man hinner med jobba med det i 30 dagar där varje arbetsdag är en liten cykel i sig själv, leverera någonting efter 30 dagar och tillbaka till sin produkt och plocka ut någonting nytt. Den bryta ner. Och så gör vi om en ny sprint. Och till detta så definierar Scream ett antal roller. Där talar man om picks eller chickens, det vill säga vem är kommit och vem är våld och picks? Är det som vi talar om, som Skumtimmen i framtiden är. Den som man talar om som produkt under produktion är en person som representerar beställare och användare och liknande. Alla de sakerna ska koncentreras till en person som representerar dem. Det är produktionens roll att kommunicera med alla de andra personerna som inte finns i Skumtimmen och att se var det önskemål som finns. Sedan har man en stram master och en Masters uppgift överlappar i många fall med en mer traditionell projektledare. Men det är inte riktigt samma sak. En projektledare som rapporterar om en ny organisation. En projektledare kanske inte alltid någon som är tekniskt involverad, men en stram master utan någon som är mer tekniskt involverad också. Och så har man sitt development team, sitt utvecklingsteam. De som sitter och jobbar med själva utvecklingen och kicken är alla andra intressenter, de som finns att säga bakom denna produkt on och även management i organisationen. Linje organisationen är en traditionell organisation med avdelningar och enheter och mellanchefer är de här och så vidare. Men när de inte är picks, de är chickens. De är inte de som ska fatta beslut om vad man gör, utan det ligger hos dem. Och Skumtimmen som vi kommer att se i detta sken. Och här knyter man sedan an till mer aktiviteter som är knutna till Scrum processen och de här rollerna. Och när en sprint börjar så har man ett och kan inuti och alla de här mötena är hårt team boxare med tanken att tar det längre tid att göra det här. Då är det för mycket arbete för en sprint. Då är det någonting som en målvakt behöver gå tillbaka till att bryta ner i ytterligare lite delar i samråd med alla de andra intressenterna och Sprint planning biten de första fyra timmarna. Där är produktionen och vår strama och del väldigt måna om hela det här. Alla våra pingis är mer här. Och då väljer man ut vad från Bachelor ska vi göra i den kommande sprinten? Vad är rimligt? Och produktionen kan prioritera sin produktutveckling och säga att det här är det som är viktigast för intressenterna att vi får gjort nu. Men det är. Teamet som säger hur mycket av det man hinner. Hur stor del hinner man göra när man under de första fyra timmarna har gjort ett åtaganden commitment till de här delarna i sin produkt. Och lov så är de följande fyra timmarna den tid som man lägger på att bryta ner detta och ta fram sin sprint raklång. Och eftersom vi redan har prioriterat en produkt, verkligen vad vi ska ta tag i, så behöver man inte ha produktionen med i de sista fyra timmarna. Produktionen behöver dock vara tillgänglig om det uppstår något man känner att man vill stämma av är oklart, men det är gruppen med Scrum och Development Team som tar fram sprint back bloggen. På de här fyra timmarna. Och sedan drar man i gång sin. Nya sprint och varje dag i den har man delvis fram. Mito är femton minuter. De är så kallade stand up meeting för att de inte ska ta längre tid. Då går man varvet runt och så får man. Vad gjorde du i går? Vad planerar du att göra idag och vad är det som hindrar dig? Och finns det då saker som hindrar det så är det samma uppgift att ta tag i de sakerna och lösa de problemen. Det kan handla om någonting vi inte riktigt förstår. Vi behöver stämma av med vårt unga för att förstå bättre vad som ska göras. Eller det här är någonting i det vi synkar med. En annan Timell motreaktion som är oklart som vi behöver lösa. Då är det strama jobb att ta tag i det där så att teamet kan jobba så smidigt som möjligt. Strama är någon som ska skydda teamet och låta teamet få arbetsro. Där gav man då laget som så här löper de 30 dagarna på är tanken. Sen har man ett spread meeting, då är man klara med sitt instrument. Man presenterar det och här är alla chickens välkomna. Här presenterar man. Vad har vi gjort? Hur fungerar det här nya instrumentet? Här öppnar man också sin back logg. Här kan det föras in nya saker som doktorn tar hand om att prioritera och så vidare. Så här är alla involverade med i detta. Så här har man då gjort klart något. I slutet av vår sprint och i slutet av sprinten så har man också 1 sprint retrospektiv meeting. Men där är vi också bara ute efter pingis som är här och här bygger man in just annat för att förbättra sin process i ett sprint retrospektiv så diskuterar utvecklingsteamet. Vad har fungerat bra? Den här sprinten hade vissa problem. Hur kan vi förändra hur vi jobbar i vårt arbete för att vara effektivare? För att undvika att upprepa problem eller misstag eller liknande, så IF Fram bygger man hela tiden in att förbättra och definiera hur man jobbar. Så Scrum säger att du behöver definiera saker om hur du utvecklar, hur du testar, men den säger inte hur du ska göra de här sakerna. Men den säger att det är viktigt att titta på hur du gör det och att hela tiden förbättra det här. Detta är i princip de regler som Scrum presenterar runt rollerna. Sprinten uppbyggnad med back och sprint back och de här aktiviteterna och vilka saker som gäller runt om. Den definierar den övergripande processen och projekthantering, men inte detaljerna i hur vi utvecklar kod eller hur vi samlar in krav hur produktionen jobbar med det. Men det finns vissa konsekvenser. Fördelar och nackdelar med Scrum och en i den här är att den flyttar makt nedåt i en hierarki. Det är inte en chef i en organisation som bestämmer vad man gör nästa år, utan det är Scrum, teamet och produktionen som prioriterar det här och hur mycket man hinner. Som makten i planeringen ligger i teamet. Det kan vara problematiskt ibland i en organisation som är van vid en traditionell linje och organisation där chefer styr vad man gör. Eftersom du själv är den som är smittad i det här. Som utvecklare kräver det väldigt disciplinerad utvecklare för att det är du som kontrollerar det själv, vad du har tagit dig och göra. Det är ingen chef som kommer av sig nu. Har sagt att du ska göra det här utan den här disciplinen går inåt så att det här är också någonting som ställer stora krav på utvecklarna att vara professionella, disciplinerade i sitt arbete. Det kräver att man har en produktägare som har tid för aktivt deltagande och att det är någon som kan diskutera och avsätta den här arbetstiden för de här sprint mötena på olika sätt. Att Sprint planning meeting att det är också någon som har tid och möjlighet att lösa konflikten som finns mellan alla andra intressenter och så vidare. Fördelen med detta är att här är något som har ett ganska lågt krav på dokumentation. Man dokumenterar och bryter ner saker inför varje sprint, men innan dess så är det ganska lite i det här. Det gör också att Scrum i sådan process stöttar det osäkra eller flyktiga och har väldigt väl därför att så länge någonting bara är back så är det ganska lätt att förändra och prioritera om det här. Och det skapar en stor synlighet för gruppen. Vem jobbar med vad? Men de här Dalí framstår kräver ju också att alla är på plats vid början av arbetsdagen. Lämnar inte så stor flexibilitet när vi börjar jobba till exempel. Och däremot vet man hela tiden vem har tag i vilken del? Vem jobbar på vad? Vem hade problem med vad och så vidare. Där man blir flexibla i att hjälpa varandra och att ingen åtar sig arbetsuppgifter som är längre än en dag heller. Några nackdelar med det är att det här är inte bara en ny processor utan det är ett nytt synsätt på hur man ser på hur man organiserar sig med makt och ansvar i en organisation. Det kan vara svårt att komma ifrån traditionellt sätt på en organisation ibland. Detta sätt att förhålla sig kan också vara svårt i vissa mer traditionella bedömningar. Modeller som tittar på om man talar om avbildning match modell. Man tar de olika standarder som finns på olika sätt och en del av de här modellerna är kanske något man från början tänker att spelar inte så stor roll, men i vissa sammanhang så är det väldigt viktigt för en organisation och ett företag att vara certifierad enligt vissa modeller och därför är det något som man faktiskt också måste förhålla sig till på många olika sätt. Och att då jobba med en traditionell prices fick Stuart kontraktet. Det här är en kravspecifikation som vi uppfyller och levererar till det här datumet för det här priset. Det är också ett något som är knepigt att jobba med med Scrum när man säger att vi definierar inte det här förrän senare. Men det är också på den andra sidan av myntet i flexibiliteten. Man kan vara väldigt snabb i mig. En fördel då? Just det här med osäkra krav. En intressant del som jag satt i det här var programvara för att stötta som vi gjorde med Region Skåne där man stöttade psykologer i deras arbete. Och när vi satt med detta så ville de ha ett bättre sätt att asynkron samtala med sina klienter. Man hade skickat en del mejl, men man ville ha mer ett forum. Men det var ju kanon på forum och när vi satt med detta så var IF kunden, ni och det här sättet att strukturera som vi idag tänker som som självklar princip där jag har en pratbubbla till ena sidan, en annan pratbubbla till andra sidan på det här viset där man lätt ser vem pratar. Den sätt att strukturera någonting var helt nytt och ett möte när vi satt med produktionen och talade om vad vill vi göra inför just Sprint Planning Meeting inför nästa sprint? Är det någon som plockar upp i en paus ni för då ska alla titta på den här och så ser man den här. Men vänta lite nu det här, det här så här kan vi visa detta och produktionen som är den här bloggen tycker att det här är ett brott så den här funktionen runt forumet bara talas om som hade legat rätt långt ner i prioriteringslistan för back lagen. Jag förstår att det här det här kändes rätt. Det här gör vi nästa sprint. Så istället för att som alla trodde att det var det här vi skulle ta tag i så att allt det där trycktes ner. Och det vi planerar är. Hur gör vi nu det här forumet? Och där var ju en styrka i att använda Scrum där. Det var lätt att säga okej, det här är er prioritering. Vi kör på det och så gör vi på det här viset då. Där fanns ju något som man med en traditionell process kanske inte hade kunnat göra, för det var redan definierat hur det här forumet skulle se ut om man skulle sitta och skriva om en kravspecifikation eller liknande. Men nu var det inga problem, men det var det här vi ska göra. Och så planerar vi ner det här och sedan kan vi skissa upp det här på snabba skisser och ta reda på hur vill vi att det här ska se ut mer i detalj? Vad kan vi göra? Vad är för och nackdelar med detta? Där man väldigt snabbt svängde processen till att göra någonting helt annat i nästa sprint än vad man trodde att man skulle göra. Men det kräver också att man då har en organisation där ingen står och säger att det här har vi inte tänkt. Har man uppskattat kostnaderna för detta det här? Vad händer när vi tryckt in det här med de andra delarna? Men det var öppet att svänga om och säga att bra har ni prioriterat här. Då gör vi det här. Så som alla förstår det så finns det fördelar, nackdelar och konsekvenser man behöver tänka på och Skram är idag ganska etablerad. Men i en trög stor organisation så kan man fortfarande vara saker man måste jämka med en traditionell linje och organisation, men det har sina fördelar.