Hur vi genomför Scrum-of-Scrums

Scrum-of-scrums är regelbundna möten, vars syfte är att diskutera olika frågor mellan Scrum Masters.

En gång arbetade vi med fyra produkter. Ett Scrum-team arbetade på tre av dem och 25 personer arbetade på det fjärde, som var uppdelat i flera Scrum-team. Det såg ut så här:

Vi hade två nivåer av Scrum-of-Scrums: en "produktnivå", som genomfördes med produkt D-team, och en "företagsnivå" för medlemmar i alla team.

Produktnivå Scrum-of-Scrums

Detta möte var mycket viktigt. Vi gjorde det minst en gång i veckan. Vi diskuterade integrationsfrågor, lagbalansering, förberedelser inför nästa sprintplanering m.m. Vi avsatte 30 minuter för detta, men ofta räckte de inte till för oss. Ett alternativ skulle vara att ha en daglig Scrum-of-Scrums, men vi kom aldrig att prova det.

Vår agenda var följande:

1. Alla berättade i sin tur vad deras lag gjorde förra veckan, vad de planerar att avsluta den här veckan och vilka svårigheter de stötte på.

2. Eventuella andra frågor relaterade till kompetensen hos flera team samtidigt som behöver diskuteras. Till exempel frågor om integration.

Faktum är att Scrum-of-Scrums agenda är inte så viktig – det är viktigare att detta möte hålls regelbundet.

Från boken Scrum och XP: anteckningar från frontlinjen författaren Kniberg Henrik

Från boken Lönsam blogg: Skapa, främja och tjäna författaren Litvin Evgeny

Från författarens bok

Från författarens bok

Från författarens bok

Hur vi demonstrerar Sprintdemon är en mycket viktig del av Scrum som många fortfarande underskattar. "Åh, måste vi göra en demo? Vi kommer inte att visa något intressant ändå!" "Vi har inte tid att förbereda olika &%$# ​​demos!" "Jag har mycket arbete att göra

Från författarens bok

Från författarens bok

Hur vi kör retrospektiv Även om grundformatet varierar lite gör vi i princip så här: Avsätter 1-3 timmar, beroende på hur lång diskussionen förväntas vara. Deltagare: produktägare, hela teamet och jag själv. Vi finns antingen i en separat

Från författarens bok

Hur vi kombinerar Scrum med XP Att Scrum och XP (eXtreme Programming) effektivt kan kombineras är utom tvivel. De flesta av resonemangen på Internet stöder detta antagande och jag vill inte slösa tid på ytterligare motivering, men en sak måste jag fortfarande

Från författarens bok

Förbättra kvaliteten genom att inkludera testare i Scrum-teamet Åh, jag kan redan höra dessa invändningar: ”Men det är uppenbart! Scrum-team ska vara tvärfunktionella!” ”Det ska inte finnas dedikerade roller i ett Scrum-team! Vi kan inte ha en person som bara testar!” Jag skulle genomföra onlineseminarier och utbildningar Denna typ av inkomst är lämplig för de mest ambitiösa och kompetenta bloggarna, proffsen, gurus, experter inom sitt område. Eller för de bloggare som omärkligt har blivit sådana.En bloggare kan tjäna pengar på

Förord ​​av Mike Cohn

Både Scrum och XP (extrem programmering) kräver att teamen slutför ett konkret arbete som kan levereras till användaren i slutet av varje iteration. Dessa iterationer är planerade att vara korta och fixerade i tid. Detta fokus på att släppa arbetskod på kort tid betyder bara en sak: det finns inget utrymme för teori i Scrum och XP. Agila metoder jagar inte vackra UML-modeller gjorda med specialverktyg, skapar detaljerade specifikationer eller skriver kod som passar alla tillfällen. Istället fokuserar Scrum- och XP-team på att få saker gjorda. Dessa team kan tolerera buggar när de arbetar, men de förstår att det bästa sättet att fånga dessa buggar är att sluta tänka på programvara på den teoretiska nivån av analys och design, och kavla upp ärmarna och fokusera helt på att bygga produkten.

Det är betoningen på handling snarare än teori som gör att den här boken sticker ut från resten. Att Henrik delar dessa synpunkter framgår redan från bokens första sidor. Det ger oss inte en lång beskrivning av vad Scrum är; istället länkar den helt enkelt till nödvändiga webbresurser. Henriks första steg är att beskriva hur hans team arbetar med sin produktstock. Den går sedan igenom alla delar och praxis i ett väl levererat agilt projekt. Ingen teoretisering. Inga referensdata. Inget av detta är nödvändigt: Henriks bok är inte en filosofisk förklaring till varför Scrum fungerar eller varför vi ska göra på det här sättet och inte på annat sätt. Detta är en beskrivning av hur ett framgångsrikt agilt team fungerar.

Henrik erbjuder ett urval av bästa praxis och levande exempel för att hjälpa oss förstå hur man använder Scrum och XP i frontlinjen.

Henrik Kniberg

Scrum och XP: anteckningar från frontlinjen

Tyvärr fick vi bara en sida för att tacka oss. Därför ska jag försöka presentera alla våra aktivister i fakta.

Maxim Kharchenko lyckades översätta även till sjöss. Tack Hyper. NETTO

Dima Danilchenko är regissör och deltid (och detta händer ☺) en av de mest aktiva översättarna i vårt projekt.

Om du under bokens gång verkligen gillade översättningen och du log, så översattes det här kapitlet troligen av Artyom Serdyuk.

Borya Lebeda automatiserade konverteringen av originalet från word- till wiki-format. Jag hade ingen aning om att det kunde göras så lätt.

Yaroslav Hnatiuk känner Henrik personligen.

Anton Maryukhnenko är den yngsta och mest lovande.

Sergey Petrov är den äldsta och mest erfarna.

Marina Kadochnikova är vår enda kvinnliga översättare.

Serezha Movchan, naturligtvis, jag har inte glömt bort dig ☺. Jag ville bara säga ett speciellt tack. Du var det andra loket, tack vare vilket vi lyckades nå det segerrika slutet. När allt kommer omkring, som de säger i ett japanskt ordspråk: "Att börja är lätt, att fortsätta är svårt."

Tack till Marina Zubritskaya och Lyosha Mamchiy för den sista korrekturläsningen och redigeringen. De lyckades hitta över hundra fel i den redan till synes polerade texten. Det finns ingen gräns för perfektion.

Vi kommer inte att glömma dem som hade en önskan, men som ofta händer fanns det ingen tid: Sergei Yevtushenko, Artyom Marchenko, Alexei Tigarev, Tim Evgrashin, Alexander Kulik.

Lyosha Solntsev,

initiativtagare och koordinator för det första ukrainska crowdsourcing-projektet, Certified Scrum Master

P.S. Du kan ladda ner originalboken på http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Förord ​​av Jeff Sutherland

Team måste känna till grunderna i Scrum. Hur skapar och utvärderar man en produktbacklog? Hur får man sprintbacklog från det? Hur man arbetar med ett burndown-diagram och beräknar prestandan (hastigheten) för ditt team? Henriks bok är en grundläggande nybörjarguide för att hjälpa team att gå från "vi försöker Scrum" till "vi gör Scrum framgångsrikt."

Bra Scrum-implementering blir allt viktigare för team som vill bli investerade. Jag fungerar som en agil coach för en grupp riskkapitalbolag och hjälper dem i deras strävan att investera i enbart riktiga agila företag. Chefen för investerargruppen kräver att företag som utgör en investeringsportfölj svarar på frågan om de känner till sina teams prestanda. Många människor är förbryllade över denna fråga. Framtida investeringar kräver att teamen känner till sin egen produktivitet inom mjukvaruutveckling.

Varför är det så viktigt? Om teamet inte känner till sin egen prestation kan produktägaren inte utveckla en strategisk produktutvecklingsplan med tillförlitliga releasedatum. Utan en sådan plan kan företaget misslyckas, vilket gör att investerare förlorar sina pengar.

Företag av alla slag står inför denna utmaning: stora och små, gamla och nya, med och utan finansiering. Under en diskussion nyligen om Googles implementering av Scrum vid en Londonkonferens bestämde jag mig för att fråga en publik på 135 personer som använder Scrum? Jag fick bara ett jakande svar från trettio personer. Sedan frågade jag om deras process följde Nokias standard iterativa utveckling Iterativ utveckling är en nyckelsats i Agile Manifest: "Försök att leverera versioner av fungerande programvara så ofta och så tidigt som möjligt." Som ett resultat av att ha genomfört retrospektiv med hundratals Scrum-team under flera år, har Nokia utvecklat några grundläggande krav för iterativ utveckling:

Iterationer måste vara av fast längd och inte överstiga sex veckor.

I slutet av varje iteration ska koden testas av kvalitetsavdelningen (QA) och fungera som den ska.

Av de trettio personer som sa att de arbetar enligt Scrum bekräftade bara hälften att deras team följer den första principen i Agile Manifest och följer Nokia-standarden.

Jag frågade dem sedan om de följde Nokias Scrum-standard:

Ett Scrum-team bör ha en produktägare och teamet bör veta vem det är.

Produktägaren måste ha en produktbacklog med berättelser och deras utvärderingar utförda av teamet.

Laget måste ha ett nedbränningsdiagram, och laget självt måste känna till sin prestation.

Under sprinten ska ingen störa lagets arbete.

Av de 30 team som implementerade Scrum hade bara tre en utvecklingsprocess som uppfyllde Nokias standarder. Jag tror att endast dessa tre team kommer att få ytterligare investeringar från riskkapitalister.

Det huvudsakliga värdet av Henriks bok är att om du följer hans råd, kommer du att få en produktbacklog, produktbacklogpoäng och ett burndown-diagram. Du kommer också att känna till ditt teams prestanda och kommer att kunna använda alla de viktigaste metoderna från högpresterande Scrum-team. Du kommer att klara Nokia Scrum-testet, för vilket investerare kommer att uppskatta dig. Om du är ett nystartat företag kanske du får sådana ekonomiska tillskott som är avgörande för ditt projekt. Kanske är du framtiden för mjukvaruutveckling, du är skaparen av en ny generation mjukvara som kommer att bli marknadsledare.

Förord ​​av Mike Cohn

Både Scrum och XP (extrem programmering) kräver att teamen slutför ett konkret arbete som kan levereras till användaren i slutet av varje iteration. Dessa iterationer är planerade att vara korta och fixerade i tid. Detta fokus på att släppa arbetskod på kort tid betyder bara en sak: det finns inget utrymme för teori i Scrum och XP. Agila metoder jagar inte vackra UML-modeller gjorda med specialverktyg, skapar detaljerade specifikationer eller skriver kod som passar alla tillfällen. Istället fokuserar Scrum- och XP-team på att få saker gjorda. Dessa team kan tolerera buggar medan de går, men de förstår att det bästa sättet att fånga dessa buggar är att sluta tänka på programvara på den teoretiska nivån av analys och design, och kavla upp ärmarna och fokusera på att bygga produkten.

Det är betoningen på handling snarare än teori som gör att den här boken sticker ut från resten. Att Henrik delar dessa synpunkter framgår redan från bokens första sidor. Det ger oss inte en lång beskrivning av vad Scrum är; istället länkar den helt enkelt till nödvändiga webbresurser. Först och främst börjar Henrik med att beskriva hur hans team arbetar med sin produktbacklog. Sedan går han igenom alla delar och praxis i ett välplacerat agilt projekt. Ingen teoretisering. Ingen bakgrundsdata. Inget av detta behövs: Henriks bok är inte filosofisk en förklaring till varför Scrum fungerar eller varför vi ska göra på det här sättet och inte på annat sätt. Detta är en beskrivning av hur ett framgångsrikt agilt team fungerar.

Henrik erbjuder ett urval av bästa praxis och levande exempel för att hjälpa oss förstå hur man använder Scrum och XP i frontlinjen.

Förord ​​- Hej! Och Scrum fungerar!

Scrum fungerar! Det passade oss åtminstone (jag menar projektet av min kund från Stockholm, vars namn jag inte skulle vilja nämna). Hoppas det passar dig också! Och kanske kommer den här boken att hjälpa dig på vägen mot att bemästra Scrum.

Det var första gången i mitt liv när jag såg hur metodiken (nåja, ja, Ken, - ramverket) fungerar "direkt ur lådan." Bara plug and play. Och samtidigt är alla nöjda: utvecklare, testare och chefer. Trots alla problem på marknaden och personalminskningen hjälpte Scrum oss att ta oss ur den svåraste situationen, tillät oss att fokusera på våra mål och inte tappa farten.

Jag vill inte säga att jag är förvånad, men... det är jag. Efter att ha skummat igenom ett par böcker i ämnet gjorde Scrum ett gott intryck på mig, för bra för att vara sant. Så det är ingen överraskning att jag var lite skeptisk. Men efter ett års användning av Scrum är jag så imponerad (och de flesta i mina team också) att jag med största sannolikhet kommer att använda Scrum på alla nya projekt, ja, om det inte finns en bra anledning att låta bli.