Agile and Lean, Scrum, Kanban, XP @ Business

Zuzi's blog header image 2

Scrum v extrémních podmínkách

01. 02. 2009 · 1 Comment

Scrum

Vraťme se k otázce pro jak velký tým a v jakých podmínkách lze Scrum proces použít. Ráda bych se podělila o svou poslední zkušenost se zaváděním Scrum procesu v té nejminimálnější představitelné podobě. Jak si poradit s krátkými projekty v řádu několika dní a týmu o velikosti jednoho člověka? První intuitivní odpověď je, že na Scrum můžete zapomenout. Všechny projekty by vlastně byly hotovy v rámci jednoho Sprintu, a tedy by to asi nemělo moc smysl. Jak ale zařídit abychom vždy přesně věděli, kde jsme a mohli rychle reagovat na třeba i drobné zpoždění a problémy? Zvlášť když zpoždění jeden den už může být pro úspěch projektu kritické.

Řešení je nasnadě. Nic nám vlastně nebrání Scrum proces použít, jen se musí vhodně upravit délka Sprintu. Prvním úkolem bylo vytvoření Backlogu. Jednotlivé úlohy, ohodnoceny body, byly rozděleny na celky v řádu pár hodin. Délku Sprintu jsme nastavili na půl dne. V takto krátce nastaveném Sprint cyklu už se nic neschová. Žádný delší oběd, ranní káva, ani problém se špatným ohodnocením úloh. Nic. Ale na druhou stranu, alespoň máte informace o tom, že projekt zítra nebude, již dnes v poledne. A tedy můžete zareagovat. Vyžádat si pomoc kolegy, zavolat zákazníkovi a domluvit si pozdější dodání. Pořád lepší než volat zpětně že jste to zase nestihli.

Takže jak to vypadá v praxi. Každý pátek se udělá plán na následující týden. V kalendáři rezervace času na jednotlivé projekty. Pro všechny týmy (i když tým o jednom člověku moc týmem není). Každý půlden se potom updatují Burndowny jednotlivých projektů, a případně kalendář, abychom věděli, proč se plán změnil. Docela hodně drsné. Ale hlavně, funguje to naprosto skvěle. Vzhledem k rychlosti výroby produktu, je to ale asi jediná možnost. Scrum meeting asi stačí jednou denně, na prodiskutování progresu a plánu na následující den.

Ještě jedna věc. Přesunuli jsme Burndowny na GoogleDocs, na změnu máme nastavené automatické emaily a tak stačí jen sledovat na mailu co se děje.

 


Zuzana Šochová - The Great ScrumMaster:#ScrumMasterWayNaučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay nebo Agilní Metody Řízení Projektů.


 

Tags: ···

1 response so far ↓

  • 1 Petr // Jun 8, 2009 at 1:59 pm

    Nadšený souhlas s tím, že “jedinou smysluplnou” časovou jednotkou je půlden. Řekl bych bez ohledu na velikost projektu.

    Domnívám se, že to, co je zde uvedeno, velice přesně potvrzuje můj názor na to, že vývoj software je nutno řídit … a nikoli nechat na dobré vůli (a “sebeorganizaci”) vývojářů. Což je něco, o čem jsem se celkem bezúspěšně dohaduji, když pro vývojáře vedu kurzy procesního modelování (jako příklad uvádím “proces vývoje software”, kterýžto celkem přesně odpovídá tomu, co je tady popsáno).

    A ještě bych poslední odstavec nahradil několikastránkovým pojednáním na téma “workflow” … ;-)