Ostatnio coraz więcej czasu spędzam na zarządzaniu pracą zespołu programistów. Cieszę się z tego niezmiernie, ponieważ zawsze lubiłem analizować, planować i przede wszystkim rozwiązywać różnego rodzaju problemy związane z zasobami (i nie tylko!).
Pracujemy zgodnie z metodyką SCRUM, jednakże nie 1 do 1 – dostosowaną do naszych potrzeb. Jako, iż każdy z programistów pracuje w kilku projektach naraz, największy problem pojawia się podczas planowania ich pracy w kolejnym, 10 dniowym sprincie.
Plany, planami.
Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of “emergency” is that it is unexpected, therefore it is not going to happen the way you are planning. – Dwight D. Eisenhower
Na 3 dni przed zakończeniem sprintu, spotykam się z project managerami na tzw. preplanning. Na takim spotkaniu omawiamy możliwości wykonania konkretnych etapów projektów w następnym sprincie. Przez kilka miesięcy planowałem pracę na 1 sprint do przodu. Można powiedzieć, iż w miarę się to sprawdzało. No właśnie – w miarę.
Nagle, podczas kolejnego spotkania z project managerami okazywało się, iż jeden myślał, iż jego projekt będzie miał teraz najwyższy priorytet, drugi, iż jego, a trzeci, iż jego. Robił się bałagan, brakowało pomiędzy nimi komunikacji. Terminy poumawiane z klientami, zero elastyczności.
Musiałem jak najszybciej znaleźć inne podejście. Stwierdziłem, iż będę planował pracę zespołu, a adekwatnie wykonywał prognozę na pół roku do przodu. Sprint po sprincie. Oczywiście potrzebne są do tego dane, tj.:
- ilość zasobów ludzkich na poszczególne sprinty – można to mniej więcej określić, do swojej analizy potrzebuję wyłącznie informacji o potencjalnych, dłuższych urlopach
- liczba godzin sprzedanych klientowi w poszczególnych projektach
- wliczone ryzyko – choroby, odejście z pracy itp. – w swoich kalkulacjach, przy 6 programistach, obniżam capacity o +/- 15% -> 6 programistów * 15% = 90% (+ 10% rozłożonych po całym zespole). Analogicznie, przy 10 programistach byłoby to 10%.
Następnie z project managerami ustalamy priorytety projektów – w idealnym świecie, podczas wprowadzania nowych zasad, wszystkie projekty byłyby dopiero przed fazą oferty, ale w prawdziwym niektóre są już w trakcie, niektóre opóźnione, a niektóre w fazie prognozy. Priorytety można ustalać na swój sposób, np.:
- deadline – o ile jest już ustalony, po fazie oferty
- klient – czy jest to stały lub nowy klient, duży czy mały
- wkład finansowy w projekt – wysoki, średni, niski
Następnie mając wszystkie powyższe dane, można rozłożyć projekty w okresie pół roku, widząc, czy teoretycznie jest to możliwe do wykonania, czy też nie. istotną informacją jest też to, iż nigdy nie planuję pełnej ilości zasobów ludzkich (pomijając opisane wyżej ryzyko). Jest to spowodowane czasem potrzebnym również na bug fixing, maintenance istniejących aplikacji u obecnych klientów itp. Istnieje również potrzeba elastyczności – o ile trzeba będzie zrobić coś dodatkowego, lub szybciej. Jak to więc u mnie wygląda?
Brak długich urlopów:
Capacity:
- 6 programistów * 60h (6h developmentu na dzień, 10 dniowy sprint) = 360h
- 360h * 0.85 (15% ryzyka) = 306h
- 306h – 6 programistów * 6h (1 dzień) = 270h
Zaplanowana praca (rozłożenie projektów):
270/360h
Elastyczność godzin:
360h – 270h = 90h => bug fixing, maintenance, przyspieszenie pracy nad konkretnym projektem
Długi urlop:
Przypadek dla 1 programisty, niedostępnego przez cały sprint – dla innych przypadków analogicznie.
Capacity:
- 5 programistów * 60h (6h developmentu na dzień, 10 dniowy sprint) = 300h
- 300h * 0.85 (15% ryzyka) = 255h
- 255h – 5 programistów * 6h (1 dzień) = 225h
Zaplanowana praca (rozłożenie projektów):
225/300h
Elastyczność godzin:
300h – 225h = 75h => bug fixing, maintenance, przyspieszenie pracy nad konkretnym projektem
Powyższy sposób praktykuję od kilku miesięcy i co ważne, widzę całkiem sporą poprawę:
- czas potrzebny na preplanning skrócił się mniej więcej o połowę
- większość projektów idzie zgodnie z planem
- nie ma przestojów w projektach – np. w sprincie 1 i 3 jest wykonywany projekt dla klienta A, ale w sprincie 2 nie. Jest ciągłość w sprintach 1-3.
Oczywiście jest to stworzony na bazie własnych doświadczeń sposób (u mnie działa!) – zero teorii – na radzenie sobie z tego rodzaju problemami, więc nie namawiam – sugeruję. o ile chcesz dowiedzieć się na ten temat więcej, masz pytania – zapraszam do kontaktu w komentarzach, dzięki formularza kontaktowego, czy FB/Twittera.
Udanego czwartku!
