Scrum - niby wygląda prosto, mamy zdefiniowane formy różnego rodzaju spotkań i jak powinny być przeprowadzane. Jednak w każdej firmie, a choćby w każdym zespole, wygląda to trochę inaczej. Jedyne, co łączy te wszystkie formy implementacji Scruma to możliwe obniżenie morali programistów z uwagi na ilość wymaganych spotkań. Czy zatem wszystkie są konieczne?
### Planning
Zanim zaczniemy sprint, musimy go zaplanować, czyli zebrać zestaw zdefiniowanych
i wyestymowanych zadań, i wiedzieć co w ramach nich trzeba zrobić. Dobrze jest, gdy cały
zespół aktywnie uczestniczy w tym spotkaniu, mając z tyłu głowy priorytety. Zazwyczaj
zadania są wyestymowane, natomiast nie zawsze dobrze mają poustawiane zależności
pomiędzy sobą - może się okazać, iż sprint wystartuje, a naszego taska X jednak nie
możemy zacząć, bo zapomnieliśmy, iż najpierw trzeba zrobić task Y. Jak temu zaradzić? W
kolejnej części artykułu zostanie opisane Scrumowe spotkanie “grooming / refinement” -
podczas niego (ale nie tylko wtedy!) należy pamiętać o ustawianiu zależności pomiędzy
taskami.
Należy również kontrolować proporcję członków zespołu - o ile w danym projekcie
pracuje 2 frontend developerów oraz 5 backend developerów, wówczas nie byłoby dobrym
pomysłem, gdyby większość story pointów pochodziła z zadań frontowych. Również należy
pamiętać o tym, iż w każdym momencie może “wpaść” nagły bug o wysokim priorytecie, do
naprawienia. Zatem o ile dostępne mamy potencjalnie 100 story pointów (według obliczeń
przyjętych w danym zespole - każdy może mieć inną wersję), sensownym byłoby
pozostawienie marginesu 10-15 story pointów na “nieprzewidziane ewentualności”.
### Stand-up / daily
Stand-up, nazywany również daily, jest podstawowym spotkaniem, przeprowadzanym codziennie. Każdy z członków zespołu mówi:
- co zrobił wczoraj
- nad czym będzie pracował dzisiaj
- czy ma jakieś z tym utrudnienia.
Na pierwszy rzut oka wygląda fajnie - codziennie każdy ma szansę się “zsynchronizować” z
resztą zespołu odnośnie tego w jakim miejscu projektu jesteśmy i czy możemy komuś
pomóc z jego problemem. Jednak jak to wygląda w rzeczywistości? W praktyce większość
członków zespołu przygotowuje sobie w głowie co powiedzieć i czeka na swoją kolej,
ignorując wypowiedzi pozostałych (inaczej by mogli zapomnieć przygotowanej w głowie
wypowiedzi). o ile kolejność zabierania głosu jest losowa i członkowie wybierają następną
osobę, większość członków zespołu zwraca uwagę jedynie na to, kto już mówił a kto nie
(jeżeli wybierze się następną osobę co już mówiła, wyjdzie na jaw to, iż nie słuchaliśmy).
Jakie są więc możliwe alternatywy tego spotkania?
#### Stand-up story focused
Zamiast koncentrować się na **osobie**, w tym podejściu koncentrujemy się na **story**,
czyli na danym **tasku** w naszym sprincie. Podczas spotkania, uwaga się skupia na każdym
zadaniu po kolei i wówczas każdy z członków zespołu może się wypowiedzieć na jego temat
- czy pracował nad nim, czy zamierza pracować, czy zadanie jest zblokowane przez coś
innego, czy pojawiły się nieprzewidziane trudności itd. W takim ujęciu jest większa szansa
na to, iż zespół będzie miał po każdorazowym spotkaniu większe pojęcie na temat
kontekstu obecnego stanu prac.
#### Daily-bot np na Slacku
Można do tematu podejść w jeszcze inny sposób - zamiast w ogóle organizować
spotkania, można użyć botów na komunikatorach (w takich integracjach prym wiedzie
Slack). Wówczas taki bot codziennie o tej samej porze pyta członków zespołu o
standardowe 3 pytania, czyli co zrobili wczoraj, co zamierzają zrobić dzisiaj oraz czy mają
jakieś problemy. Jest kilka zalet tego podejścia:
- można na spokojnie zastanowić się jak opisać swój raport i nie trzeba ciągle go w
głowie sobie powtarzać
- W każdej chwili można zerknąć do statusu pozostałych członków zespołu, gdyż
zapisane raporty będą udostępnione na dedykowanym kanale
### Demo
Ideą Scruma jest to, żeby móc cyklicznie dostarczać pewien przyrost wartości dla
klienta. Po każdorazowym sprincie sensownym jest zaprezentowanie dostarczonej pracy
przez cały sprint. Łatwo jednak wpaść w pułapkę pokazywania jedynie zmian na UI, czyli
tego, co może zobaczyć docelowy użytkownik. Oczywiście jest to potrzebne, natomiast
warto również powiedzieć o wszelkich zmianach niewidocznych na pierwszy rzut oka - być
może jakieś zmiany technologiczne, spłaty długu technicznego, poprawa wydajności
aplikacji lub masa innych niefunkcjonalnych rzeczy. Wówczas prezentacja takich wartości
powinna być dostosowana do poziomu wiedzy klienta (lub jego reprezentanta, najczęściej
Product Ownera) - jeżeli jest to osoba techniczna, możemy sobie pozwolić na dokładny opis
co zostało poczynione. Warto jednak mieć na uwadze, iż głównym celem firm jest
zarabianie pieniędzy (a nie czynienie świata lepszym, jak to czasami mają na swojej
stronie), więc trafionym pomysłem będzie przełożenie efektów pracy technicznej na
konkretne, mierzalne metryki - np zamiast:
```Zrobiliśmy zaległy refaktoring, teraz jest czystszy kod.```
Lepsze będzie stwierdzenie:
```Dzięki poczynionemu refaktoringowi, kod stał się czytelniejszy i łatwiejszy do poczynania kolejnych zmian, dzięki czemu kolejne funkcjonalności będą możliwe do zaimplementowania w mniejszą liczbę “men days”.```
### Grooming / Refinement
Czasami (a choćby i często) taski wzięte do sprintu podczas planningu, wymagają
delikatnej modyfikacji bądź lepszego zrozumienia przez zespół. Być może trzeba wspólnie
przeanalizować i przedyskutować zadania na kolejne sprinty. Do tych celów zostało
przewidziane niniejsze spotkanie. Wówczas ważnym jest także ustalenie powiązań
pomiędzy taskami - a zwłaszcza informacja które zadanie jest zblokowane przez jakieś inne.
### Retro
Retro, czyli spotkanie na którym zespół omawia swoje przemyślenia na temat
ubiegłego sprintu, może przyjąć wiele różnych form, aczkolwiek najczęściej spotykana jest
taka, iż każdy stara się wypisać / powiedzieć **co poszło dobrze, a co poszło źle (i czy możemy to naprawić w przyszłości)**. Przedstawiłem to spotkanie jako ostatnie, gdyż,
pomimo iż również wartościowe, to według mojej opinii nie jest aż tak konieczne,
zwłaszcza, o ile sprint przeszedł dosyć “typowo”, i każdy z członków zespołu musiałby się
wysilać, żeby wymyślić jakąś opinię.
### Podsumowanie
W tym artykule przedstawiłem i opisałem poszczególne spotkania w Scrumie. Żeby
jednak przechodziły one sprawnie i efektywnie, wymaga się, żeby **każdy** członek zespołu
wiedział o co w nich chodzi i trzymał się przyjętej formy. Oczywiście szczegóły można (a
nawet powinno się) dostosowywać do konkretnego zespołu - tak jak zaproponowane przeze
mnie alternatywy do typowych stand-upów. Wówczas okazuje się, iż nie potrzeba nawet
Scrum Mastera, a zespół potrafi być efektywny, cyklicznie dowozić pewną wartość, a
programiści nie odczuwają nadmiaru niepotrzebnych spotkań.
