Identyfikowanie blokad to sposób na wspólne rozwiązywanie problemów
Historia spotkania „scrumowego” inżyniera oprogramowania jest dość standardowa: każdy programista sporządza listę swojej pracy z poprzedniego dnia, co będzie robił dzisiaj… i opisuje, czy napotkał jakieś blokady.
„Celem tego spotkania” jest umożliwienie członkom zespołu podzielenia się kontekstem. Metodologie zwinne chcą, aby programiści żyli w „stanie przepływu”: maksymalnej produktywności przy minimalnym rozproszeniu uwagi. Ale jak mogą to zrobić i nadal być częścią zespołu?
Jak programiści koordynują współpracę ze swoimi współpracownikami? W jaki sposób menedżerowie mogą śledzić, co się dzieje i organizować zasoby, aby rozwiązywać problemy? Jak właściciel produktu może wykryć ryzyko w swoim projekcie? Właśnie to powinno rozwiązać codzienne spotkanie scrumowe – i dlaczego istnieją blokery.
Jednak programistom często trudno jest powiedzieć, że są zablokowani. Dlaczego?
Zmniejszenie wpływu swojego ego
Programiści, których znam, są dumni ze swojej pracy i dbają o swoje osiągnięcia, a także o swoją reputację wśród innych programistów. Ich codzienną pracą jest zrozumienie problemu i przezwyciężenie go, więc co to znaczy być zablokowanym?
Niezależnie od tego, czy programista wdraża nową funkcję, próbuje zidentyfikować przyczynę błędu, czy integruje się z nowym systemem, codzienna praca programisty jest taka sama. Deweloper wystarczająco długo przygląda się problemowi, próbuje różnych rozwiązań i ostatecznie dochodzi do wniosku, który pozwala mu przejść do następnego zadania.
Dla niektórych programistów bycie zablokowanym jest równoznaczne z niemożnością pracy. Powiedzenie, że dana osoba nie potrafi rozwiązać problemu, może przypominać przyznanie się do porażki. Nie pomoże, jeśli menedżerowie i koledzy z drużyny marszczą brwi i jęczą za każdym razem, gdy ogłaszana jest osoba blokująca.
Musimy zmniejszyć piętno wokół identyfikacji osoby blokującej. Przeanalizujmy kilka sposobów rozwiązania tego problemu.
Rozpoznawanie blokerów w regularnych czynnościach
Pierwszym ważnym zadaniem jest zmiana skojarzenia mentalnego słowa „bloker”. Pomóż swojemu zespołowi zrozumieć, że każdego dnia mamy do czynienia z blokadami — nawet trywialne wyzwania należy uznać za blokady, ponieważ wpływają one na naszą produktywność.
- Zależności — gdy czekasz na zależność, jesteś blokowany, nawet jeśli wiesz dokładnie, jak rozwiązać historię użytkownika. Najpierw potrzebujesz zależności, aby wylądować.
- Harmonogramy — czasami menedżerowie mówią: „Wstrzymaj się ze zmianą kodu do wtorkowej publikacji”. Być może czekasz na spotkanie z partnerem, a może zespół zdecyduje się na dużą zmianę dopiero po zakończeniu wakacji. Nadal jesteś zablokowany, nawet jeśli kod jest gotowy.
- Zatwierdzenia – niektóre projekty wymagają podpisów od wewnętrznych członków zespołu, partnerów lub klientów zewnętrznych. Gdy tylko skończysz pracę, oznacz siebie jako zablokowanego, czekając, aż wszystko będzie jasne.
- Decyzje — projekt może czasami zostać zatrzymany, gdy wokół konkretnej decyzji toczy się zbyt wiele debat. Czy powinniśmy rozwiązać ten problem w warstwie danych, czy w warstwie biznesowej? Czy powinniśmy dodać nowe API, czy nie? Zostałeś zablokowany, ponieważ zespół musi dojść do porozumienia.
- Brakujące historie — Jednym z niefortunnych problemów jest sytuacja, gdy członek zespołu otrzymał polecenie pracy nad projektem, ale jego właściciel produktu, scrum master lub menedżer nie napisał jeszcze ani nie sfinalizował zgłoszeń. Tak! Trzeba złapać tego wcześniej. Czas programisty jest kosztowny i nie chcemy go marnować!
Gdy Twój zespół zobaczy, że bloker może oznaczać coś więcej niż tylko „Nie rozumiem dokumentacji i mój kod nie działa”, możesz pozwolić swojemu zespołowi na dalsze omówienie miejsca, w którym utknął, i zwrócenie się o pomoc.
Najważniejszą rzeczą do zapamiętania jest to, że zostajesz zablokowany, gdy nie możesz już samodzielnie wywrzeć wpływu. Zrobiłeś wszystko, co w Twojej mocy, a następnym krokiem jest wkroczenie Twojego menedżera lub kolegów z zespołu i pomoc w rozwiązaniu problemu.
Algorytmy planowania dla ludzi i procesorów
Kiedy nowoczesny procesor dociera do modułu blokującego — być może musi poczekać na powolnym dysku twardym, w sieci lub na wejściu z klawiatury — przełącza zadania. Kiedy to piszę, mój procesor ma 257 procesów i prawie trzy tysiące aktywnych wątków.
Z jednej strony możesz pomóc swojemu zespołowi wywierać wpływ, wyznaczając mu inne zadania. Jeśli członek zespołu jest zablokowany w jednym zadaniu, czy możesz otworzyć kolejne, w którym może wnieść swój wkład? Jeśli zespół potrzebuje jednej ostatecznej decyzji, aby móc rozpocząć projekt, może będzie mógł rozpocząć kolejny?
Jednak zbyt częste przełączanie zadań może być również oznaką, że zespół nie robi wystarczająco dużo, aby rozwiązać problemy blokujące. Członek zespołu, który ma trzy aktywne projekty, prawdopodobnie jest zablokowany w jednym z nich. Czy menadżer zwraca uwagę? Czy członkowie drużyny powodują problemy poprzez swoją niezdecydowanie? Co się dzieje z każdym z nich? Czy możemy skupić się na pierwotnych przyczynach blokerów i je rozwiązać?
Zwolnij roszczenia do zadań, które nie są aktywne
Częstym wyzwaniem jest obsługa interesów dewelopera w różnych obszarach. Utalentowany programista może zobaczyć nadchodzące zadanie, historię użytkownika lub błąd, który naprawdę chce naprawić. Może jest to technologia, którą uwielbiają lub funkcja, na której im zależy.
W każdym razie programista może zgłosić roszczenie o projekt, zgłoszenie lub zgłoszenie błędu z tygodniowym wyprzedzeniem — a to oznacza, że nikt inny nie może tego zrobić.
Twój menadżer lub scrum master powinien w jak największym stopniu pomóc zidentyfikować i złagodzić ten problem. Chcemy, aby nasi programiści podchodzili do swojej pracy z pasją i zachęcamy członków naszego zespołu do wybierania biletów, na których im zależy.
Ale gdy programista ma od pięciu do dziesięciu historii użytkowników w stanie „Aktywny”, być może próbuje zrobić za dużo. Poproś ich, aby skupili się na dwóch lub trzech zadaniach jednocześnie, a być może odblokujesz pracę innym członkom zespołu.
Używaj małych zatwierdzeń i regularnych żądań ściągnięcia
Jednym z przydatnych sposobów ograniczenia blokad biletów jest zachęcanie zespołu do regularnego dokonywania małych zmian w miarę upływu czasu. Każde małe żądanie ściągnięcia może być jedną częścią całego projektu. Stały napływ małych żądań ściągnięcia pokazuje, że członek zespołu nie jest zablokowany.
Kiedy konkretna historia użytkownika jest aktywna dla programisty, a ten programista nie przesłał żądania ściągnięcia w ciągu kilku dni, może to oznaczać, że bloker wkradł się niezauważony — lub może być tak, że historia użytkownika była zbyt duży i powinien zostać podzielony na mniejsze kawałki.
Jednym z podejść, jakie menedżerowie stosują przy zajmowaniu się ważnymi historiami, jest „rotacja odpowiedzialności” za zadanie – ale należy to stosować tylko w ostateczności. Odebranie zadania jednemu programiście i przypisanie go innemu może wydawać się karą i nie należy na to patrzeć w ten sposób.
Lepszym sposobem poradzenia sobie z tym jest podziękowanie programiście za dotychczasową pracę i powiedzenie: „Ten bilet jest zdecydowanie za duży. Podzielmy to na pół. Zamkniemy ten bilet i otworzymy dwa nowe. Możesz pracować nad biletem A, a ta osoba będzie pracować nad biletem B.”
Monitoruj swoją reakcję na blokery
Jeśli mogę zakończyć tę rozmowę jedną mocną radą, brzmi ona tak: Podziękuj swojemu zespołowi za zidentyfikowanie osób blokujących. Kiedy ktoś podnosi rękę i identyfikuje problem, pamiętaj, aby powiedzieć: „Och, dobry chwyt! Zobaczmy, co możemy zrobić.
Z biegiem czasu Twój zespół powinien docenić fakt, że w razie potrzeby może uzyskać pomoc, a blokady powinny przestać być czymś negatywnym, a zamiast tego stać się tym, czym zawsze powinny być: narzędziem skupiającym energię zespołu na rozwiązaniu złożonego problemu.
Ted Spence wykłada w „Bellevue College” i kieruje inżynierią w „Lockstep”. Jeśli interesuje Cię inżynieria oprogramowania i analiza biznesowa, chętnie usłyszę Twoją opinię na LinkedIn.
