IT

Garść wniosków z obserwacji SCRUMa w praktyce - no, może nie odnośnie całego frameworka, a jedynie dwóch jego aspektów - estymacji i planowania. Zacznę od krótkiego SCRUMowego przypomnienia - otóż, jak wszyscy doskonale wiemy, jednym z artefaktów SCRUMa jest Backlog (lista zaległości produktu) - to lista zmian, które mają zostać wprowadzone w produkcie przez pracujący nad nim zespół deweloperski (bądź zespoły). Widniejące na takiej liście zmiany (zadania) zespół deweloperski omawia w trakcie spotkań nazywanych "refinmentem" (doskonaleniem), czyli w trakcie spotkań porządkowania listy zalogłości produktu (choć należy zauważyć, iż "refinement" przez Scrum Guide jest opisywany jako "proces ciągly", więc podejście do "porządkowania" może wyglądać różnie w różnych zespołach; w zespołach, w których ja miałem okazję pracować przyjęta była akurat zasada organizowania raz w tygodniu spotkania w celu omawiania zadań z backloga). Tak więc, w trakcie "refinementu" zespół stara się oszacować (wyestymować) ilość pracy potrzebną na realizację zadań (usuwanie zaległości) spisanych w backlogu. Szacunki dotyczą oczywiście poszczególnych zadań, a nie całości backloga, który może być oszacowany jedynie bardzo... ogólnie (przynajmniej w teorii). I tutaj pojawia się pierwszy problem: jak szacować ilość pracy potrzebą na realizację określonego zadania?

Jeżeli Twoje środowisko dockerowe składa się z więcej niż jednego kontenera to zapoznanie się z docker-compose znacznie ułatwi Ci życie. Zresztą nawet przy jednym, no dobrze – dwóch kontenerach, okazuje się on być bardzo pomocnym narzędziem. To, co przy korzystaniu z „gołego” dockera może sprawiać pewną trudność, czyli mnogość opcji i parametrów podawanych przy uruchamianiu kontenerów w bardziej zaawansowanych (niż „hello world”) implementacjach, jest w dość przejrzysty i wygodny sposób znacząco uproszczone przez właśnie docker-compose. Dzięki temu narzędziu możemy zarządzać naszym środowiskiem za pomocą zdefiniowanych nazw/aliasów bez konieczności pamiętania (i ciągłego wpisywania) wszystkich szczegółów implementacji. Oczywiście nie jest to nic czego nie moglibyśmy dokonać również za pomocą sprytnych skryptów powłoki, jednak yaml (ten format pliku konfiguracyjnego wykorzystywany jest przez docker-compose) wydaje się być bardziej… elegancki, a elegancja – ważna rzecz.