Zwinny projekt – zwinne życie

Agile czyli zwinne wytwarzanie w projektach i poza nimi.

Tematem tego wpisu będzie manifest agile, jego najważniejsze elementy i możliwe zastosowania (także dla własnego życia). Możliwe, że część z Was pracuje przy projektach, w których wykorzystywane są jakieś techniki zwinnego wytwarzania oprogramowania. Możliwe też, że Wasz team stale pracuje w oparciu o scrum. Pytanie tylko czy metodyki postępowania, których skuteczność jest potwierdzona na przykład dla wytwarzania oprogramowania, można zastosować w codziennym życiu?

Na te pytania postaram się odpowiedzieć.

Większość idei związanych ze zwinną produkcją powstała przy opracowywaniu metod zarządzania i prowadzenia produkcji aut. Często przywołuje się w tym kontekście przykład Toyoty. Kiichirō Toyoda, zainspirowany rozwiązaniami, jakie wprowadził Henry Ford w swoim amerykańskim koncernie (a największą rewolucją w Fordzie było uruchomienie ruchomej taśmy produkcyjnej i podział pracy na najmniejsze możliwe części), podjął decyzję o rozpoczęciu produkcji samochodów w firmie, którą założył jego ojciec. Przykład Forda i Toyoty potwierdził, że określona metodyka pracy daje wymierne efekty w dziedzinie efektywności.

Wróćmy do współczesności. W 2001 spotkali się reprezentanci różnych metodyk produkcji (tym razem produkcji czyli tworzenia oprogramowania) i wspólnie ogłosiło tak zwany manifest agile. Oto tezy, jakie znalazły się w deklaracji:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się:

• Ludzie i interakcje ponad procesy i narzędzia
• Działające oprogramowanie ponad obszerną dokumentację
• Współpracę z klientem ponad formalne ustalenia
• Reagowanie na zmiany ponad podążanie za planem

Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.

Brzmi pięknie, czyż nie? Jak widać, manifest stworzono w kontekście oprogramowania ale jak zaraz pokażę, nie musimy jego znaczenia zamykać tylko w takiej sferze.

Zobacz też: Programowanie – nie lękajcie się

Warto pamiętać, że agile nie jest jedyną metodyką tworzenia oprogramowania. Istnieje też lean, w którym mówi się o szczupłym zarządzaniu lub szczupłej produkcji. W kilku punktach opisują to poniższe zasady:

• określenie wartości dla klienta,
• zidentyfikowanie strumienia wartości i wszystkich czynności w strumieniu wartości,
• ciągły przepływ,
• system ssący,
• dążenie do doskonałości.Warto tu podkreślić, że w metodyce lean bardzo ważne jest pojęcie marnotrawstwa, z którym związane są takie zjawiska jak:
• nadprodukcja,
• zbędny ruch,
• oczekiwanie,
• zbędny transport,
• nadmierne zapasy,
• wady,
• nadmierne przetwarzanie.Zanim przejdę do objaśnienia pojęć ważnych dla metodyki lean na przykładach, wyjaśnię czym jest tablica kanabanowa, która znalazła w tej metodyce zastosowanie.
  

  

  Bardzo prosta wersja tablicy kanban w trello

  Z wyglądu przypomina trochę klasyczne „to do list”, na której mamy wpisane jakieś zadania, ale w istocie tablica kanabanowa jest nieco bardziej skomplikowana, a dzięki temu bardziej użyteczna

  Na tej tablicy poszczególne zadania są pogrupowane w kolumnach:

• Backlog – kolumna pomysłów i założeń. To, co pojawia się w tej sekcji musi przejść przez tak zwane „wstępne sito” dzięki czemu w kolumnie tej znajduje się to, co musi, powinno, może być zawarte w danym projekcie.
• To do – lista rzeczy do zrobienia, w której znajdują się zadania, którymi zajmiemy się jak tylko zwolni się zasób czasu.
• In progress – lista zadań, którymi się obecnie zajmujemy.
• Done – tu znajduje się lista zadań, które zostały wykonane. Sekcja ta pozwala na obserwowanie postępów.Oczywiście kolumn może być więcej, w zależności od potrzeb i kreatywności, np.
• Testy – kolumna, w której znajdują się elementy wykonane, w fazie testów przed ich wpisaniem do kolumny „Done”
• Rejected – lista elementów odrzuconych na poziomie planowania.
• Możemy też podzielić kolumnę „To do” na bardziej i mniej pilne zadania.

To, jakie będą kolumny zawszę powinno być dopasowane do konkretnego projektu i modyfikowane w oparciu o obserwację, na ile usprawnia pracę.

Zobacz też: Projekt a testy

Każda kolumna (prócz kolumny „Done”) ma w nawiasach [ ] zapisaną cyfrę. Tam wpisujemy, ile zadań może maksymalnie „leżeć” w danej kolumnie. Dla mnie, osoby, która lubi robić dużo i ma tendencje do brania na siebie kolejnych projektów, czy tendencję do zaczynania i odkładania w czasie kończenia, to świetna sprawa. Obsługa tej tablicy polega zatem na przerzucaniu kolejnych zadań z lewej do prawej, no chyba że mamy kolumnę test i po negatywnym wyniku jakieś zadanie wraca do kolumny „to do”, do poprawki. Dzięki ograniczeniom ilościowym i omówionemu wyżej ruchowi zadań między kolumnami, możemy zajmować się tylko ograniczoną ilością tematów i bez ich skończenia nie zabieramy się za kolejne.

Każde zadanie możemy sobie jeszcze uszczegóławiać i komentować

Czasem możemy też ograniczyć ilość zadań w kolumnie „Done”. Mam tu na myśli ograniczenia pozwalające na określenie, na jakim etapie projekt będzie uznany za zakończony. Jest to przydatne zwłaszcza dla osób, które mają skłonność do dodawania kolejnych elementów, tak że z projektu robi się „Never ending story”.

Dodatkowo warto pamiętać czym jest systemie iteracyjny oraz o wizualizacji przebiegu projektu (jak na przykład na tablicy kanban). Są to cechy wspólne w prawie każdej formie agile.

Teraz nareszcie przejdźmy do sytuacji, w której chcemy użyć powyższych metod w projekcie lub poza nim. Metodyka opisana w sposób teoretyczny brzmi jakby jej zastosowanie było dziecinnie łatwe, jednak często okazuje się, że takie podejście jest mylne. Warto pamiętać, że z zespołach pracujących w oparciu o scrum, będący formą agile, jest osoba, która zajmuje się wyłącznie tym, aby wszystko działo się w zgodzie z założeniami przyjętej formy projektu (scrum master).

Chaotyczną „to do list” łatwo można wpędzić się w przytłoczenie

Czym może być ten projekt? Może to być program który chcemy napisać, praca inżynierska, urządzenie, które naprawiamy lub tworzymy, jakiś event który organizujemy, zarządzanie pracami jakimi zajmujemy się w naszym warsztacie, lub zdobywanie wiedzy.

Wiadomo, że inaczej działamy, jeśli realizujemy zadanie dla własnych potrzeb, a inaczej, kiedy organizujemy pracę całego zespołu. Ważny jest tu też podział ról. Co zrobić w sytuacji, w której jesteśmy sami, a przed nami piętrzą się różne role: projektanta, osoby pracującej nad projektem, project ownera, testera, a nawet klienta? Naszym zadaniem jest wówczas wcielanie się w poszczególne role na różnych etapach projektu. Jako klient oczekujemy od siebie że skończymy coś, co sobie zaplanowaliśmy, że spełni to nasze oczekiwania i zabierze jak najmniej czasu.

W lean, jak pisałem, ważny jest brak marnotrawstwa. Ta cecha skupia się wokół materiału i tego, co z tym materiałem się dzieje. Powiedzmy zatem czym może być materiał. Jeżeli ktoś zajmuje się elektroniką to mogą to być części elektroniczne, jeśli ktoś jest stolarzem to deski, kleje śrubki. W większości przypadków za materiał możemy uznać nasze umiejętności. Zgodnie z systemem ssącym, nie zdobywamy tych materiały „na przyszłość” („niech jest i leży” – to podejście jest najgorsze). Zdarzyło wam się czegoś uczyć i nie skorzystać z tej wiedzy, a nawet ją zapomnieć? Prawda, że marnotrawstwo? Materiały zajmują miejsce, są pieniędzmi i czasem zamrożonym, czasem może się okazać że się nie przydadzą i pójdą do kosza.

Prawie wszystko możemy zapisać w tablicy kanban. Mój system jest prosty, mam kilka tablic kanbanowych, do pracy, do nauki, do bloga – każdy inny projekt ma tablicę. Do tego używam kalendarza i bez zbędnego rozpisywania się wrzucam do niego dwugodzinne bloki pod hasłami „blog”, „praca”. Hasła te odnoszą się do mojej tablicy, w której szczegółowo opisałem swoje zadania.

Metodyki pracy mogą być wdrażane do realizacji określonych zadań przy użyciu konkretnych narzędzi (bo jak wspomniałem wcześniej, proces wymaga wizualizacji). Narzędzia powinny być proste i niezawodne, abyśmy nie musieli się przejmować skomplikowaną obsługą i awariami. Naszymi narzędziami mogą tu być zwykłe przylepne karteczki, kawałek tablicy oraz teczka wyposażona w dodatkowe zakładki. Można tez korzystać z nowocześniejszych narzędzi, takich jak Trello, które pokazałem na samym początku, jakieś repozytorium jak np. Bitbucket czy Github. Istnieją też całe „kombajny” do prowadzenia projektu jak na przykład Jira. Warto też pamiętać o podstawach agile i treści manifestu. Jeśli zarządzamy pracą zespołu, musimy pamiętać o tym, że ponad wspomnianymi narzędziami cenimy umiejętny kontakt z ludźmi. Bez tego te narzędzia nie mają sensu. Jeśli chodzi o kontakt w teamie możemy się wspomóc takimi aplikacjami jak Hipchat albo Slack.

Tablice kanban można zrobić z kartki A4 i śliskiej koszulki, do tego wystarczą karteczki i gotowe

Tak naprawdę opisałem tu tylko z grubsza podstawy związane z agile, bo cała gałąź wiedzy związana z metodyką jest olbrzymia i można tu długo, długo opowiadać. Mam jednak nadzieję, że może ktoś z Was skorzysta z omówionych przeze mnie rozwiązań, może poszerzy swoją wiedzę związaną z agile czytając inne strony na ten temat np. Trzeciakawa, Poddrzewem, Agile247.

A może już korzystacie w swoim życiu z jakiś elementów agile? Zapraszam do pisania komentarzy z takimi pomysłami (;

Jeśli artykuł w jakiś sposób Tobie pomógł , możesz wpierać blog, aby nowych materiałów przybywało więcej. Zapraszam TUTAJ.