Scrum

Każda firma posiada różne podejście do zarządzania procesem tworzenia oprogramowania. Również wewnątrz jednej firmy może zdarzyć się tak, że dany zespół programistyczny w obrębie jednej firmy będzie miał inne podejście to tej sprawy. Może kłaść nacisk na inne aspekty procesu zarządzania członkami zespołu, lub np. pomijać całe sekcje 'domyślnego' postępowania. Obecnie jednak większość firm, zwłaszcza małych i średnich tworzy oprogramowanie przy użyciu metodyki Agile (zwinnej). Najpowszechniejszym rodzajem tego podejścia jest Scrum). Najkrócej rzecz ujmując, sprowadza się ona do rozbicia czasu produkcji oprogramowania na krótkie interwały (najczęściej jednotygodniowe). Członkowie zespołu określają swoje cele do zrealizowania na następny tydzień; dodatkowo codziennie powinien odbyć się tzw. scrum meeting (standup) - krótkie spotkania na początku dnia, gdzie członkowie informują innych o swoich postępach i zamiarach na bieżący dzień. Scrum pozwala na skupieniu się na mniejszym wycinku przyszłości. Dodatkowo, dzięki częstej aktualizacji wiedzy na temat postępów prac nad poszczególnymi funkcjonalnościami manager może zainterweniować wcześniej, np. przez dołączenie kolejnej osoby do zespołu. Dla klienta również jest to bardzo dobre rozwiązanie, ponieważ otrzymuje testu i recenzji kolejną, wersję strony/aplikacji co tydzień lub częściej.

Planowanie

Planowanie w Scrum jest to proces, w którym członkowi zespołu wybierane są zadania do wykonania na następny tydzień (kolejny sprint). Dodatkowo te zadania powinny być oszacowane. Planowanie zwykle odbywa się w konkretnym dniu, np. w poniedziałek rano. Członkowie zespołu siadają z managerem, lub inną osobą, która zarządza projektem. Korzystają oni z trackera zadań (PivotalTracker, Jira, Trello lub podobny), który zawiera listę funkcjonalności, błędów, rzeczy do zrobienia. Lista zadań w trackerze jest zwykle tworzona przez właściciela produktu (ang. product owner). Właściciel produktu jest przedstawicielem firmy, dla której jest wykonywany projekt. Dba on głównie o dostarczenie wartości biznesowej przez zespół programistów. Product owner oprócz stworzenia listy zadań powinien również posortować zadania według priorytetu - najważniejsze, najpilniejsze zadania muszą być umieszczone wyżej niż te mniej istotne.

Mając listę zadań w trackerze przystępujemy do szacowania zadań. Jest to po prostu orientacyjne określenie złożoności, trudności zadań. Inaczej mówiąc, szacujemy ilości czasu w jakiej programista spodziewa się ukończyć zadanie. Siłą rzeczy nie może być ona bardzo dokładna. Celem szacowania jest stwierdzenie jaką ilość zadań z trackera programista może wykonać w sprincie na bieżący tydzień. Metryki szacowania zadania są różne. Przykładowo, tracker może posługiwać się punktami. Jeden punkt to ok. 2-3h pracy. Zatem gdy myślimy, że zadanie jest stosunkowo proste, możemy go oszacować na 1 lub 2 punkty. Bardziej złożone ficzery wymagają większej ilości czasu, np. ok. 2 dni pracy, co odpowiada 5-6 punktom. Oszacowane zadania zostają przypisane do danej osoby, tzn. ta osoba będzie wykonywać to zadanie w sprincie. Szacujemy tyle zadań dla każdej osoby, aby suma ich punktów nie przekroczyła ilości punktów w tygodniu. Czyli zakładając 3 punkty na dzień (ok. 8h), dla 5 dni pracujących w tygodniu mamy 3 * 5 = 15 punktów, co oznacza że suma punktów poszczególnych zadań przypisanych dla nas nie może przekroczyć 15.

W jaki sposób oszacować zadanie? Jeśli nie masz dużego doświadczenia w programowaniu może to być dosyć trudne, zwł. na początku. Prawdopodobnie inni członkowie zespołu pomogą ci z tym zadaniem, ponieważ oszacują go na podstawie swojego doświadczenia, którego ty jeszcze nie posiadasz. Jeśli mimo to musisz oszacować zadanie przeczytaj uważnie co dany task zawiera. Czasem w trackerze zadania mają wyszczególnione podzadania. Wykonanie ich wszystkich może być czasochłonne. Zadania, które brzmią prosto, nie wiążą się np. z użyciem nieznanej biblioteki, można oszacować prawdopodobnie na 1 czy 2 punkty. Przykładowo, dodanie przycisku na interfejsie aplikacji, wraz z podpięciem do niego wykonania jakiejś akcji będzie można oszacować na taką ilość punktów. Z drugiej strony jednak zadnia rozbudowane, wymagające zrobienia researchu, tudzież zadania innego typu niż te, z jakimi mieliśmy wcześniej do czynienia będziemy szacować na większą ilość, np. 4 czy 6 punków. Przykładem takiego taska może być integracja z zewnętrznym serwisem, który jest mało popularny.

Biorąc pod uwagę twoje doświadczenie w programowaniu bezpieczniej jest zawyżyć nieco oszacowanie zadania (Hofstadter's law). Czyli w głowie myślimy, że dany ficzer może zająć nam 5 godzin, to dodajemy margines, i szacujemy zadnie na 3 punkty (1 cały dzień). Nie jest to w żadnym przypadku oszukiwanie - po prostu nie masz na tyle doświadczenia, żeby dobrze wykonać oszacowanie, a dodatkowo podczas programowania mogą wystąpić dodatkowe problemy i komplikacje które i tak zwiększą czas na uporanie się z taskiem. A jeśli nawet zbyt mocno nadszacujesz lub niedoszacujesz zdanie, to inne osoby z zespołu mogą natychmiast poprawić twój osąd. W trakcie pracy nad poszczególnymi zadaniami będziesz widział, czy twoje szacunki się sprawdziły, czy nie. Na przykład jeśli w większości przypadków czas poświęcony na zadanie mieścił się w wartości 'pomyślanej' przez ciebie, możesz w następnych planowaniach rezygnować z dodawania dodatkowych marginesów czasowych, bądź dodawać je w przypadku nietypowych tasków (gdzie istnieje duża szansa na to, że wystąpią komplikacje).

W przypadku, gdy jakieś zadanie nie zostaną wykonane w danym sprincie, będą one przesunięte do następnego. Bądą uwzględnione przy kolejnym planowaniu.

Standup

Jest to krótkie, poranne spotkanie wszystkich członków zespołu, gdzie każda z osób mówi co zrobiła w poprzednim dniu, i co zamierza wykonać w bieżącym dniu. Dzięki temu pozostali członkowie zespołu znają postęp innych, a opowiadająca osoba może lepiej zrozumieć nadchodzące zadania poprzez sam fakt wyartykułowania ich. Standup powinien trwać najwyżej 10 minut (15 w przypadku większych zespołów). Zwykle na stojąco - stąd nazwa.

Co i jak powiedzieć na standupie? Przede wszystkim nie można zbytnio rozwodzić się nas szczegółami tego co zrobiliśmy, lub tego, z czym mamy problem. Wystarczy zakomunikować problem, ale omawiać go należy już po spotkaniu, między developerami. Dzięki temu pozostali członkowie zespołu nie muszą stać, i tracić czas na wysłuchiwaniu szczegółów problemu (np. graficy wysłuchujący szczegółów problemu developerów Androida). Wypowiedź na standupie ma być krótka, kilkuzdaniowa. W żołnierskich słowach przekazane ma być to, co najistotniejsze. Warto w głowie ułożyć sobie plan wypowiedzi, przypomnieć sobie nad czym pracowaliśmy poprzedniego dnia, i taski na dziś. Przykładowa wypowiedź na scrum meetingu: 'Wczoraj zaimplementowałem sekcję widoku statystyk użytkowników dla admina, według mockupów przygotowanych przez Krzyśka. Dodatkowo zacząłem debugować problem ze znikającymi powiadomieniami dla użytkowników. W logach znalazłem bardzo dziwne wpisy, których nie umiałem zinterpretować, ale to przegadam z Maciejem po standupie. Na dziś mam zamiar uporać się tym bugiem, zmienić layout dla niezalogowanego użytkownika, a także - jak zastanie mi trochę czasu - myślę zacząć poszukiwania jakiejś dobrej biblioteki do konwersji plików graficznych, którą musimy wprowadzić do projektu.'.

Praca z trackerem

Istnieje sporo różnych aplikacji typu Bug Tracker, czyli przeznaczonych do śledzenia zadań. Czasem są one bardzo rozbudowane (jak Jira), albo uproszczone (jak Trello). Jednym z popularnych narzędzi tego typu jest PivotalTracker. Dana osoba - zwykle klient - dodaje w nim zadania (taski). Task zawiera tytuł, typ, opis, ewentualnie listę podzadań i załączniki (np. mockup w .jpg). Typem może być feature, bug, chore (zob. słowniczek). Taski pogrupowane są w obrębie kilku kategorii: zakończone, te nad którymi pracujesz teraz, zaplanowane do zrobienia w obecnym sprincie i przyszłe. W trakcie planowania product owner wybiera kilka przyszłych tasków, i przenosi je do grupy obecnego sprintu. Wraz z zespołem robisz szacowanie czasu ich wykonania. Dodatkowo właściciel produktu sortuje taski z bieżącego sprintu według priorytetu ich wykonania. Praca w sprincie nad taskami polega na szeregu czynności. Najpierw developer rozpoczyna task, co automatycznie przesuwa go do grupy zadań obecnie wykonywanych. Gdy task jest ukończony trzeba go zakończyć, czyli kliknąć przycisk 'Finish'. W tym momencie klient widzi, że nad tym taskiem już nie pracujesz, ale jeszcze nie ma możliwości zweryfikowania poprawności jego wykonania. Gdy wrzucimy zmiany związane z tym taskiem (lub taskami, jeśli nie chcemy za każdym razem uaktualniać stage'a) na serwer stagingowy ustawiamy status z 'Finished' (zakończony) na 'Delivered' (dostarczony). Teraz klient widzi, że ma możliwość weryfikacji zmian na stage'u. Po sprawdzeniu przez klienta czy wszystko jest w porządku są dwie możliwości. Opcja 1: klient ma pewne zastrzeżenia, coś zostało zrobione nie tak lub np. brakuje jakiejś części. Wtedy klika on na przycisk 'Reject' (odrzuć), pisze komentarz w tasku, lub komunikuje się z developerem w inny sposób. Zadania musi być ponownie być zrestartowane wtedy od początku. Drugą możliwością jest to, że task został wykonany poprawnie, klient nie ma żadnych zastrzeżeń. Wtedy klika na 'Accept' (zatwierdź), co automatycznie przenosi task do grupy zadań zakończonych. Oczywiście, w przypadku różnych trackerów cały powyższy proces może się różnić, jest to tylko przykład.

Inne aspekty SCRUM

Powyższy opis SCRUMa przedstawia tylko kilka najważniejszych elementów tej metodyki. Jak wspomniano na początku tej sekcji, każda firma, każdy zespół może bardziej lub mniej realizować założenia metodyki SCRUM. O innych składowych SCRUM, takich jak Scrum Master, prędkości (ang. velocity), przegląd (ang. sprint review) można przeczytać w wielu istniejących książkach czy na stronach internetowych na ten temat.