Obecnie zdecydowana większość firm stosuje Agile (metodyki zwinne), w tym również w zdecydowanej większości Scrum. Przyjrzyjmy się zatem temu zagadnieniu bliżej - po przeczytaniu niniejszego wpisu dowiesz się, jak sprawić, by spotkania były efektywne nawet bez Scrum Mastera. Odświeżysz sobie cele poszczególnych części Scruma i zobaczysz alternatywy do codziennego stand-upa, na którym najłatwiej jest stracić koncentrację.
Scrum - niby wygląda prosto, mamy zdefiniowane formy różnego rodzaju spotkań i jak powinny być przeprowadzane. Jednak w każdej firmie, a nawet 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ć, że sprint wystartuje, a naszego taska X jednak nie możemy zacząć, bo zapomnieliśmy, że 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 - jeżeli 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, że w każdym momencie może “wpaść” nagły bug o wysokim priorytecie, do naprawienia. Zatem jeżeli 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). Jeżeli 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, że 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, że 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śli jest to osoba techniczna, możemy sobie pozwolić na dokładny opis co zostało poczynione. Warto jednak mieć na uwadze, że 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 nawet 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, że 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 że również wartościowe, to według mojej opinii nie jest aż tak konieczne, zwłaszcza, jeżeli 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ę, że nie potrzeba nawet Scrum Mastera, a zespół potrafi być efektywny, cyklicznie dowozić pewną wartość, a programiści nie odczuwają nadmiaru niepotrzebnych spotkań.
