Witajcie ponownie — dzisiaj poruszymy z pozoru zbędny temat. Wydaje się, że tworzenie dużych projektów jest dość proste. Wystarczy podzielić całość na zadania i zatrudnić pracowników, którzy sami będą sobie przydzielali te zadania. Otóż sprawa jest nieco bardziej skomplikowana, bo prędzej czy później natrafimy na kilka problemów. W dzisiejszym odcinku porozmawiamy sobie o tym, w jaki sposób organizować pracę w zespole, tak aby wszystko poszło gładko i sprawnie.
Po co nam w ogóle metodyki organizacji pracy?
We wstępie wspomniałem już, że nie można po prostu rzucić programistom zadań i projekt w końcu będzie skończony. Taki dowolny przydział zadań mógłby prowadzić do wielu niepożądanych zdarzeń. Na przykład programista B mógłby sobie przypisać zadanie, które najpierw wymaga ukończenia zadania, tworzonego aktualnie przez programistę A. To spowoduje jego czasowe zablokowanie. Mogłoby to prowadzić również do sytuacji, w której przez większość czasu produkt nie nadawałby się do uruchomienia, bo zadania związane z interfejsem użytkownika zostaną wykonane dopiero na końcu.
Tak więc widzimy, że musimy organizować pracę w taki sposób, aby każdy z programistów mógł pracować w pełni samodzielnie oraz na każdym etapie projektu klient mógł zobaczyć jakąś realnie działającą cząstkę systemu.
Kanban
Pierwszą omawianą dziś metodyką będzie Kanban. Jego cel jest dość prosty, chodzi o maksymalne zwiększenie efektywności pracy. Nie jest to metodyka ściśle związana z programowaniem, ponieważ powstała już w roku 1947 i początkowo była stosowana w fabryce Toyoty. Dopiero w późniejszych czasach zaadaptowano ją do zespołów tworzących oprogramowanie.
Głównym elementem Kanbana jest tablica obrazująca aktualny stan projektu. Możemy tam zobaczyć wszystkie zadania znajdujące się w różnych stanach. W większości firm mamy podział co najmniej na zadania: oczekujące, w toku, w fazie testów i gotowe. Początkowo tablice były fizyczne, obecnie używa się do tego specjalnego oprogramowania.
W Kanbanie bardzo ważne jest określenie maksymalnej liczby zadań, nad którymi można pracować w jednym momencie. Ma to na celu usprawnienia pracy, dodatkowo łatwo można sprawdzać wydajność zespołu. Kanban jest systemem ewolucyjnym, zakłada więc wykonywanie ciągłych pomiarów wydajności i wprowadzania koniecznych zmian.
Programowanie ekstremalne
W tym podejściu nazwa jest nieco myląca, bynajmniej nie chodzi o to, aby programować w trakcie skoku ze spadochronem. Nie jest to typowa metodyka zarządzania zespołem, ponieważ skupia się ona głównie na podejściu do samego pisania kodu. W programowaniu ekstremalnym mamy 6 głównych zasad, które stosowane razem pomagają nam dowieźć w pełni działający projekt. Te zasady to:
- Brak planowania z góry — nie ustalamy na sztywno żadnej konkretnej architektury systemu. Oczywiście przed rozpoczęciem planu definiujemy jakieś wzorce, jednak przyjmujemy do wiadomości, że architektura ulegnie zmianie w ramach rozwijania projektu.
- Ciągła modyfikacja architektury — ten punkt jest związany z poprzednim. Chodzi o to, aby, nie bać się ruszać architektury, jeśli ma to nam pomóc w dalszym rozwoju projektu. Trzeba pisać też kod w taki sposób, aby takie modyfikacje nie ciągnęły za sobą zmian w większości klas projektu.
- TDD (programowanie napędzane testami) — testy jednostkowe (pisałem o nich w odcinku o testowaniu) powinny być pisane jeszcze zanim powstanie kod, który mają testować. Dopiero później piszemy kod, który musi zaliczyć wszystkie te testy. Takie podejście sprawia, że pokrycie kodu testami jest bardzo duże, a dodatkowo wymusza na nas pisania kodu, do którego da się łatwo napisać testy.
- Programowanie parami — programiści powinni siedzieć parami. Jeden zajmuje się pisaniem kodu, drugi z nich analizuje cały czas kod oraz zgłasza jakieś poprawki. Co kilkadziesiąt następuje zamiana rolami. Ten punkt jest dość kontrowersyjny. Z jednej strony takie podejście zwiększa czytelność kodu i minimalizuje ryzyko pomyłki. Z drugiej strony potrzebujemy znacznie więcej programistów.
- Iteracyjność — pracujemy w cyklach o określonej przez nas długości. Na początku zakładamy, co uda nam się zrobić w danym cyklu. Po upłynięciu czasu wysyłamy klientowi aktualną wersję aplikacji oraz planujemy, co zrobimy w kolejnym cyklu.
- Kontakt z klientem — nie da się ustalić wszystkich szczegółów przed rozpoczęciem projektu. Dlatego ważne jest, aby wszelkie wątpliwości rozwiewać poprzez bezpośredni kontakt z klientem.
Metodyki zwinne
Być może spotkaliście się ze słowem Agile, które z angielskiego oznacza zwinny. Jest to też nazwa jednej z popularniejszej metodyki prowadzenia projektu. O jej popularności może świadczyć fakt, że teraz każda firma reklamuje się pracowaniem według zasad agile.
Cała idea polega na samo organizujących się zespołach. Oznacza to, że przykładowo zespół mobilny sam dobiera sobie odpowiednie narzędzia i wybiera architekturę odpowiednią dla danego projektu. Podobnie jak w programowaniu ekstremalnym, miarą postępów projektu jest działająca wersja aplikacji. Osiągamy to poprzez regularne wydawanie kolejnych wersji programu do klienta.
Bardzo ważną kwestią jest także ciągła poprawa. Zespoły powinny aranżować spotkania, na których poddadzą analizie ostatnio wykonane postępy. Na podstawie wyciągniętych wniosków, wszyscy powinni wspólnie pomyśleć, co można by poprawić na przyszłość. W metodyce Agile bardzo ważna jest odpowiednia komunikacja. Najlepiej, jeśli odbywa się ona twarzą w twarz, chociaż zdarzają się też zespoły, w których każdy z pracowników pracuje z własnego domu.
Scrum
Scrum zawiera w sobie cechy metodyk zwinnych. Jest to najbardziej znane podejście do tworzenia oprogramowania i na pewno prędzej czy później się z nim spotkacie.
W scrumie mamy podział na 3 główne role:
- Scrum Master — osoba czuwająca nad tym, żeby były przestrzegane wszystkie zasady Scruma. Do jej obowiązków należy również pomoc w rozwiązywaniu problemów organizacyjnych.
- Product Owner — osoba reprezentująca klienta i dbająca o całokształt projektu. Bardzo często jest ona członkiem zespołu i jest pośrednikiem pomiędzy zespołem deweloperskim a klientem.
- Zespół deweloperski — zespół odpowiedzialny za implementacje aplikacji. Przeważnie nie wyróżniamy tutaj żadnego lidera, a więc struktura zespołu jest płaska.
Nie chcę was zanudzać dokładnym opisem Scruma, dlatego skupimy się tylko na tym, jak w Scrumie przebiega praca z perspektywy programisty. Jednym z ważniejszych wydarzeń są codzienne, krótkie spotkania zespołu deweloperskiego. Podczas takiego spotkania każdy z programistów mówi, co zrobił od wczoraj, jaki ma cel na dziś oraz wymienia jakieś ewentualne problemy. Dzięki takiemu podejściu każdy z członków zespołu jest świadomy, nad czym pracują inni, dodatkowo w razie jakichś problemów reszta zespołu może udzielić cennych wskazówek. Aby zapobiec przedłużaniu się spotkania, przeważnie odbywa się ono w pozycji stojącej, tak aby zmęczenie fizyczne motywowało do jego szybkiego zakończenia.
W Scrumie działamy w tak zwanych sprintach — jest to jakiś okres (nie dłuższy niż 1 miesiąc), po którym wydajemy aktualną wersję aplikacji. Po każdym sprincie następują dwa bardzo istotne wydarzenia. Pierwszym z nich jest retrospektywa — tutaj zespół omawia miniony sprint i zgłasza swoje uwagi oraz problemy. Na końcu formułowane są zalecenia, które mają na celu usprawnienie pracy w kolejnym sprincie. Kolejnym ważnym spotkaniem jest planning, w którego trakcie trwania zespół szacuje, jakie zadania uda się wykonać w nadchodzącym sprincie oraz oficjalnie otwiera kolejny sprint.
Bardzo często na zakończenie sprintu organizowana jest prezentacja, na której członkowie zespołu deweloperskiego pokazują klientowi funkcjonalności zaimplementowane w minionym sprincie. Po zakończeniu takiego spotkania aktualna wersja aplikacji zostaje dostarczona klientowi, tak aby mógł on przetestować ją we własnym zakresie.
To już koniec na dziś. Zdaję sobie sprawę, że mogłem pozostawić pewien niedosyt, ponieważ bez wątpienia nie opisałem wszystkich sposobów organizacji projektu. Skupiłem się jedynie na tych najpopularniejszych. Jeśli macie wrażenia, że pominąłem coś istotnego, to zapraszam do komentowania. Widzimy się już za tydzień, gdzie opiszę wam zmiany w Androidzie Q z perspektywy programisty.
Zapraszam również na największe w Polsce forum dla programistów Android. Jeśli macie pytania odnośnie do kariery programisty — zapraszam do działu Kariera programowanie. Zachęcam również do przejrzenia działu Praca oraz zlecenia dla programistów — być może to właśnie tam znajdziesz swoją pierwszą pracę.
Pozostałe odcinki serii o programowaniu.