O dobrych praktykach stosowanych przez zespoły IT, a w tym trochę o agile i skalowaniu.
Niedawno kolega z pracy, zajmujący się jakością procesów i projektów, poprosił mnie o wskazanie paru dobrych praktyk, jakie stosujemy w IT (a konkretnie w tzw. “Pociągu”, czyli SAFe’owym Agile Release Train, czyli bardziej po ludzku, w programie “projektów” zwinnych… eh z tymi “projektami” w SAFe jest dość specyficznie, ale to temat na inny artykuł), a z których mogłyby skorzystać zespoły nie-IT w swojej codziennej pracy. Pisząc o dobrych praktykach myślał tym samym o standardach, pozytywnych inicjatywach, pożytecznych przyzwyczajeniach, słowem na zachowaniach, na które się umówiliśmy w naszych zespołach, które usprawniają pracę i których staramy się przestrzegać, a nawet te których przestrzegania bezwzględnie pilnujemy. Zależało mu przede wszystkich na praktykach na styku biznesu i IT, więc nad takimi w pierwszej chwili zacząłem się zastanawiać. Potem zrobiłem sobie listę wszystkich pozytywnych zachowań, które na szybko przyszły mi do głowy. Gdy zacząłem tą listę przeglądać, pomyślałem że chociaż wiele z nich dotyczy działań związanych z produkcją oprogramowania, to w wielu przypadkach nie stoi nic na przeszkodzie, żeby zacząć stosować je również w innych zespołach. Wierzę nawet, że wiele z nich już jest stosowanych, ba, nawet sam niektóre wdrażałem poza IT.
Dobre praktyki
Poniżej lista dobrych praktyk, które szczególnie zwróciły moją uwagę. Niektóre są być może dość powszechnie znane i stosowane, np. w produkcji, z których się wywodzą, a przez IT zostały w szczególny sposób zaadaptowane, inne być może mało kto spoza IT przymierzał do swojego obszaru. Mimo, że są to proste rzeczy, to jednak z jakichś względów nie upowszechniły się jeszcze poza produkcją i IT.
Daily Scrum
Rytuał wywodzi się Scruma (zwinnego framework’a do zarządzania rozwojem produktów), ale ja widzę jego wartość potencjalnie w każdym zespole. Polega on na tym, że członkowie zespołu pracujący razem na pewną inicjatywą (projekt, pakiet prac, zadanie itp.) spotykają się codziennie na max. 15 minut i synchronizują się. Każdy mówi krótko czym się zajmował od ostatniego spotkania, czym będzie się zajmował do kolejnego i co go blokuje. Dzięki takiej krótkiej i treściwej wymianie informacji wszyscy wiedzą, na jakim poziomie znajdują się powiązane prace i na jakich zagadnieniach powinni się skoncentrować. Spotkanie realizowane jest na stojąco, żeby zniechęcić uczestników do przedłużania swoich wypowiedzi. Z doświadczeń w pracy poza IT wiem, że często nawet osoby współpracujące ze sobą bezpośrednio, nawet te siedzące biurko w biurko nie zawsze są do końca świadome postępów swoich prac i napotykanych problemów.
Kanban
Genialne w swojej prostocie narzędzie do monitorowania przepływu prac, zwłaszcza jeśli się dobrze wizualizuje konkretne, sensownej wielkości zadania i ich przepływ. Nie będę go opisywał, bo jest bardzo powszechnie znane, a jeśli nie, to łatwe do wygooglania. Dorzuciłem je do listy, bo niestety poza obszarem produkcji i IT nie za bardzo funkcjonuje. W wersji minimum daje obraz tego, co się dzieje, w wersji rozszerzonej pozwala zarządzać np. limitem pracy w toku, priorytetami, płynnością, czy wąskimi gardłami. Niezależnie od tego, czy używamy Kanbana, jako prostej tablicy do wizualizacji, czy jako proces Kanban. Nieważne czy wieszamy tablicę na hali produkcyjnej, czy w biurze. Nie ma również aż tak wielkiego znaczenia, czy używamy wersji cyfrowej czy analogowej. Ważne natomiast jest to, że mamy przed oczyma listę realizowanych prac przez poszczególnych pracowników, możemy śledzić ich postępy i obserwować dysfunkcje w ich przepływie. Wdrażałem Kanbana również poza obszarem IT i produkcji przemysłowej i gwarantuje, że podnosi on znacznie efektywność pracy każdego zespołu.
Czego nie ma w “Jirze”, to nie istnieje*
Ta praktyka mogłaby równie dobrze brzmieć: Jeśli nie ma tego w Jirze/ Asanie/ Trello/ Redmine/ Target Process/ (tu wstaw właściwe Tobie narzędzie do zarządzania zadaniami)/, to nie istnieje. Pozytywów z używania narzędzia do rejestrowania zadań jest mnóstwo. Przede wszystkim konieczność zapisania czegoś i formalnego zaadresowania konkretnej osobie lub zespołowi, mobilizuje do przemyślenia zakresu zadania i oczekiwanego rezultatu. Dodatkowo minimalizuje nieporozumienia, pozwala na odnajdowanie cennych informacji ze statystyk o naszych zadaniach i konsumowanych przez nie zasobach, pozwala lepiej zarządzać priorytetami. Stanowi podstawę do obrazowania i usprawniania procesów. Wiąże się z pozornie dodatkową pracą poświęconą na obsługę narzędzia, ale ta inwestycja zwróci się wielokrotnie.
Definition of Ready
Termin wybitnie IT i odnosi się do kompletności oraz jakości przygotowania wymagań, które zamawiający przekazują zespołom deweloperskim. Można to jednak przetłumaczyć na, mniej więcej, taką oto regułę: Nie przyjmujemy do realizacji zlecenia, które nie jest opisane według ustalonego standardu. Dzięki temu, dostając od kogoś zadanie do wykonania, nie zaczynamy pracy od żmudnej rozkminki i dociekania wszelkimi sposobami i kanałami tego, co autor miał na myśli. Dodatkowo, kiedy zlecający musi się przyłożyć do precyzyjnego opisania zadania, to może dojść do ciekawych przemyśleń, może też dojść do wniosku, że nie jest gotowy na zlecenie tych prac do realizacji, bo na przykład sam nie wie czego oczekuje. Takie przykładowe elementy standardu opisu zleceń lub zadań, to np. szczególna forma opisu (np. konkretny formularz zamówienia), konieczność zamieszczenia rysunku, mapy, schematu, arkusza, makiety, modelu lub konieczność zdefiniowania celu za pomocą metody SMART/ER/EST.
Prace, które są opisane w sposób niezgodny z przyjętymi standardami mogę nie być przyjęte do realizacji, co może zaoszczędzić sporo czasu niedoszłemu wykonawcy.
Zapraszamy na szkolenie
Szkolenia SAFe
Decentralizacja podejmowania decyzji
Jest to dobra praktyka zapożyczona z między innymi z SAFe (Scaled Agile Framework) http://atscale.pl/o-skalowaniu/ (patrz tabela Pryncypia SAFe, ostatni punkt), w którym kładzie się na nią szczególny nacisk.
Naszą praktyką jest to, że zespoły posiadają pewną samodzielność zdefiniowaną w ramach ustalonych zakresów (np. architektura systemu, kamienie milowe, moduły i główne funkcjonalności, współdzielone komponenty, itd.) bądź przyjętych standardów (np. definicja kompletności, standardy tworzenia kodu). Określone decyzje są podejmowane samodzielnie przez zespoły funkcjonujące na poziomie operacyjnym, bo wiążą się koniecznością posiadania aktualnych i szczegółowych, często mocno specjalistycznych, informacji, a inne z kolei muszą być zatwierdzane z góry, bo wymagają znajomości szerszego kontekstu. Nie osiągniemy prawdziwej skali i efektywności działań, jeśli nie pozostawimy ludziom na poszczególnych poziomach zarządczych i operacyjnych swobody poruszania się w ustalonym zakresie. Nie tylko niweluje to wąskie gardła i poprawia jakość decyzji, ale zwiększa też motywację ludzi do pracy.
Raportowanie czasu poświęconego na zadania
Jest to zazwyczaj negatywnie kojarzone z nadmierną kontrolą. Służy jednak przede wszystkim budowaniu świadomości odnośnie pracochłonności poszczególnych prac dotyczących np. danej kategorii zleceń, rodzajów działań, czy rozwoju poszczególnych cech produktu.
Coś jeszcze?
To tylko część dobrych praktyk. To, co przyszło mi do głowy w pięć minut. A czy Ty dodałbyś coś do tej listy? Czego można nauczyć się od zespołów IT? Tylko proszę bez haseł w stylu: chodzić w kapciach ;]
Nie jesteś z IT, ale hasła które przeczytałeś zaintrygowały Cię? Podejdź do znajomego programisty, admina lub PMa i poproś o wyjaśnienie. Będzie wiedział o co chodzi.
*(@Leszek – „A w Jirze jest?” ;] )
