Manifest Zwinnego Wytwarzania Oprogramowania — wyjaśnienie i zastosowanie

Czym jest Manifest Agile?

Manifest Agile to pisemna deklaracja zawierająca cztery wartości i 12 zasad, których celem jest usprawnienie sposobów pracy przy tworzeniu oprogramowania.

Manifest, który ma bardziej filozoficzny niż nakazowy charakter, miał być możliwy do dostosowania do różnych rozmiarów zespołów, celów i warunków.

4 wartości Manifestu Agile

Oficjalny Manifest Agile składa się z tych 4 wartości:

1. Ludzie i interakcje ponad procesy i narzędzia
2. Działające oprogramowanie ponad wyczerpującą dokumentację
3. Współpraca z klientem ponad negocjowanie umów
4. Reagowanie na zmiany ponad realizację planu

Warto zauważyć, że autorzy opatrzyli te wartości następującym wyjaśnieniem: "Oznacza to, że choć doceniamy wartości zawarte po prawej stronie, to jednak bardziej cenimy te po lewej stronie."

Podkreśla to ideę, że Manifest Agile nie polega na przestrzeganiu określonego procesu ani na korzystaniu z konkretnego zwinnego narzędzia. Chodzi o przyjęcie określonego sposobu myślenia.

12 zasad Manifestu Agile

Oprócz czterech wartości Manifest Agile zawiera 12 wspierających je zasad, które wyjaśniają, jak interpretować i stosować te wartości w projektach zwinnych.

1. Stawiaj klienta na pierwszym miejscu

Najwyższym priorytetem jest zadowolenie klienta dzięki wczesnemu i ciągłemu dostarczaniu wartościowego oprogramowania.

2. Przyjmuj zmiany

Akceptuj zmieniające się wymagania, nawet na późnym etapie tworzenia oprogramowania. Zwinne procesy wykorzystują zmiany dla uzyskania przewagi konkurencyjnej przez klienta.

3. Dostarczaj często

Dostarczaj działające oprogramowanie często — od kilku tygodni do kilku miesięcy, preferując krótsze przedziały czasowe.

4. Współpracuj między zespołami

Przedstawiciele biznesu i deweloperzy muszą codziennie współpracować przez cały czas trwania projektu.

5. Rozwijaj talenty

Buduj projekty wokół zmotywowanych ludzi. Zapewnij im środowisko i wsparcie, których potrzebują, oraz zaufaj im, że wykonają swoją pracę.

6. Rozmawiaj

Najbardziej wydajną i skuteczną metodą przekazywania informacji zespołowi programistycznemu i w jego obrębie jest rozmowa twarzą w twarz.

7. Mierz to, co ma znaczenie

Działające oprogramowanie jest podstawową miarą postępów.

8. Ustalaj tempo pracy, aby uniknąć wypalenia

Zwinne procesy wspierają zrównoważony rozwój. Sponsorzy, deweloperzy i użytkownicy powinni być w stanie utrzymywać stałe tempo pracy w nieskończoność.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

9. Skup się na jakości, a praca będzie przebiegać szybciej

Ciągła dbałość o doskonałość techniczną i dobry projekt zwiększa zwinność.

10. Stawiaj na prostotę

Prostota — sztuka maksymalizowania ilości pracy, której nie trzeba wykonywać — jest kluczowa.

11. Nie stosuj mikrozarządzania

Najlepsze architektury, wymagania i projekty powstają w samoorganizujących się zespołach.

12. Refleksja i dostosowanie

W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć swoją skuteczność, a następnie odpowiednio dostosowuje i modyfikuje swoje działania.

Historia, autorzy i geneza Manifestu Agile

W świecie technologii o Manifeście Agile mówi się z taką samą czcią i brakiem czci jak o każdym świętym tekście przekazywanym przez lata.

W lutym 2001 roku 17 specjalistów z branży oprogramowania, którzy nazwali siebie „The Agile Alliance”, spotkało się w amerykańskim stanie Utah, aby opracować dokument, który nazwali „Manifestem zwinnego wytwarzania oprogramowania”. Dokument ten, podkreślający cztery wartości i 12 zasad, jest obecnie znany jako Manifest Agile.

Autorzy Manifestu Agile są często określani jako The Agile Alliance, a wśród nich znaleźli się przedstawiciele różnych procesów wytwarzania oprogramowania, w tym programowania ekstremalnego, Scrum i Crystal. 

Szybki rzut oka na oficjalną stronę internetową manifestu ukazuje autorów w scenerii, która może przywodzić na myśl tajne stowarzyszenie lub spotkanie ojców założycieli. Było jasne, że ich zamiarem było stworzenie czegoś, co wywrze trwały wpływ na branżę. I rzeczywiście tak się stało.

Chociaż osoby, które spotkały się w Utah, nie były pionierami zasad zwinności jako takich, ugruntowały wartości, które od pewnego czasu kształtowały się w tle świata wytwarzania oprogramowania.

Dziś metodyka zwinna przeniknęła niemal każdą branżę.

Autorami byli:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

Dlaczego Manifest Agile jest (wciąż) ważny

Manifest Agile pozostaje aktualny ze względu na koncentrację na sposobach pracy skoncentrowanych na ludziach oraz możliwość elastycznego działania.

Szybkim zmianom technologicznym często towarzyszą zmieniające się wymagania projektowe. Manifest Agile pozwala kierownikom projektów priorytetowo traktować zdolność adaptacji i współpracę poprzez tworzenie responsywnego i odpornego środowiska projektowego, które może jednocześnie dostarczać rezultaty, wprowadzać innowacje i zmieniać kierunek w razie potrzeby.

Promuje również podejście skoncentrowane na kliencie, nadając większą wartość działającym rozwiązaniom niż wyczerpującej dokumentacji. Dzięki temu kierownicy projektów mogą wcześnie zbierać informacje zwrotne i stale udoskonalać swoją pracę, zapewniając ścisłe dopasowanie projektu do potrzeb użytkowników. To iteracyjne i napędzane potrzebami klienta podejście zwiększa prawdopodobieństwo sukcesu projektu oraz poziom satysfakcji.

Jak stosować Manifest Agile

Przyjrzyjmy się nieco dokładniej każdej z czterech wartości manifestu zwinnego wytwarzania oprogramowania. Analizując podstawowe wartości, omówimy również 12 zasad, które rozwijają każdą z nich.

Wartość nr 1: Ludzie i interakcje ponad procesy i narzędzia

Podstawą zwinności są ludzie. Podejście zwinne zakłada, że zespół pracuje razem, ściśle współpracuje i samodzielnie podejmuje decyzje. Zwinność nie polega na mówieniu zespołowi, co ma robić ani co ma zbudować. 

W projektach zwinnych komunikacja musi być swobodna i ciągła, a nie zdefiniowana i zaplanowana. Praca w odizolowanych silosach nie jest zgodna z podejściem zwinnym.

Oceń komunikację w zespole

Zadaj sobie pytanie: czy Ty i Twój zespół prowadzicie rozmowy twarzą w twarz? Czy może polegacie na wiadomościach e-mail, dokumentach i pewnych bardzo lubianych narzędziach do komunikacji (nie będziemy wymieniać nazw)? 

Nawet jeśli pracujecie zdalnie, rozmowa twarzą w twarz może przyspieszyć realizację różnych działań. Jest to szczególnie ważne, gdy zespół dopiero się formuje — synchroniczna komunikacja sprzyja zaufaniu i otwartości oraz pomaga budować relacje.

Nie kontroluj wszystkiego

Wszyscy od czasu do czasu byliśmy winni takiego zachowania. Jednak zaufanie jest integralną częścią podejścia zwinnego. Szukasz czegoś, co możesz wdrożyć od razu? NIE ZARZĄDZAJ MIKROMANAGERSKO (tak, celowo to wykrzykuję).

Może kusić, aby szczegółowo rozplanować zadania, przydzielić je zespołowi, a następnie śledzić ich realizację aż do wyznaczonego terminu (lub jego przekroczenia), tak aby mieć kontrolę nad wszystkim. Aby jednak naprawdę wzmacniać sprawczość zespołu, musisz nieco się wycofać i pozwolić jego członkom przejąć odpowiedzialność za swoją pracę!

Wspieraj samoorganizujący się zespół

Nie chodzi o zarządzanie — chodzi o przewodzenie i ułatwianie pracy. Samoorganizujący się zespół to zespół, który sam wybiera najlepszy sposób realizacji swojej pracy. To on powinien decydować, jak przekształcić rejestr prac w kod gotowy do wydania. Nie popadaj jednak w skrajność i nie pozostawiaj zespołu bez żadnej pomocy ani wskazówek — nadal potrzebuje on wizji, motywacji oraz wsparcia w usuwaniu blokad.

Jak więc odejść od przydzielania zadań i zamiast tego określić, w jaki sposób możesz ułatwiać pracę?

Nie przejmuj się procesem ani narzędziem

Wiem, wiem — w świecie zwinnego zarządzania projektami nieustannie mówi się o narzędziach do zarządzania projektami i oprogramowaniu do zwinnego zarządzania projektami.

Rzecz w tym, że Twojego klienta nie obchodzi Twój wewnętrzny proces zwinnego przepływu pracy. I nie powinno go to obchodzić.

Zwinność polega na przyjęciu podejścia, w którym klient jest na pierwszym miejscu, oraz umożliwieniu zespołowi dostarczania lepszej i bardziej wartościowej pracy. Więcej o podejściu stawiającym klienta na pierwszym miejscu — w dalszej części!

Usuń silosy

Silosy utrudniają współpracę, a tym samym osłabiają wartości zwinności. 

Aby odejść od silosów, rozważ następujące wskazówki:

• Umieść zespół we wspólnej lokalizacji: Tak, znowu o tym mowa. To świetnie, jeśli projektanci mogą siedzieć blisko siebie i rozmawiać o kwestiach związanych z projektowaniem, ale czy nie byłoby lepiej, gdyby rozmawiali z programistami o tworzeniu tego świetnego produktu? Wiem, że wdrożenie tego rozwiązania w większej organizacji lub środowisku zdalnym może być trudne, ale nawet spotkania na wspólnym kanale Slacka lub zaplanowane sesje wspólnej pracy, podczas których ludzie mogą jednocześnie i zdalnie wykonywać pracę wymagającą głębokiego skupienia, pomogą utrzymać większą spójność zespołu.
• Zniechęcaj do przekazywania pracy między działami: Bardziej formalne, kaskadowe podejście, w którym każdy dział pracuje etapami (UX, następnie projektowanie, programowanie, a potem QA), często prowadzi do zakłóceń w komunikacji i zwiększa marnotrawstwo w projekcie. Zamiast przekazywać pracę wzdłuż całego łańcucha, zachęcaj zespół do wspólnej pracy nad funkcjami. Nawet jeśli pracujesz w sprintach, ale poprzedzasz je sprintem projektowym, zaangażuj programistów w sprint projektowy — w końcu to oni będą tworzyć ten produkt!

Wartość nr 2: Działające oprogramowanie zamiast wyczerpującej dokumentacji

Pamiętaj, że manifest nie mówi o całkowitym porzuceniu dokumentacji — po prostu przypisuje elementom po lewej większą wartość niż tym po prawej. Oznacza to, że dokumentacja nadal istnieje. Na przykład Scrum wykorzystuje historyjki użytkownika, aby wskazać programiście, jak rozpocząć tworzenie rozwiązania.

Co możesz jednak zrobić, aby odejść od obszernej, czasochłonnej dokumentacji i szybko przejść do czegoś namacalnego?

Uprość wykorzystywaną dokumentację

Zidentyfikuj wszelkie problemy i blokady w swoim procesie. Czy tworzysz zbyt dużo dokumentacji? Czy poświęcasz wieczność na przygotowanie idealnego dokumentu wymagań, spędzasz mnóstwo czasu nad zakresem funkcjonalnym, a następnie nie masz już czasu na stworzenie produktu? Ogranicz zbędną dokumentację, wykonując następujące działania:

• Skup się na zadaniach związanych z projektowaniem i programowaniem, które bezpośrednio przyczynią się do powstania produktu, zamiast na dokumencie tekstowym, który ostatecznie nie zostanie wykorzystany
• Organizuj warsztaty na początku, aby określić wymagania i kolejne kroki, zamiast tworzyć obszerne dokumenty. Dokumentuj i udostępniaj rezultaty za pomocą zdjęć i krótkich notatek.

Szybko przejdź do tworzenia

Tworzenie obszernych dokumentów wymagań to jeden ze sposobów na opisanie potrzeb firmy, klienta i użytkownika. Jednak ostatecznie znacznie bardziej przydatne jest zobaczenie czegoś działającego, reagującego i zachowującego się w określony sposób.

Rozważ niektóre z poniższych sposobów na szybkie posunięcie projektu do przodu:

• Skróć wstępne rozpoznanie lub definiowanie do krótszego okresu: Ograniczenie czasu poświęcanego na definiowanie i ustalanie szczegółów oznacza, że szybciej dojdziesz do etapu, którym projektanci i programiści będą mogli się zająć. Możesz przyspieszyć ten proces, korzystając z tych pytań na sesję rozpoznawczą.
• Organizuj warsztaty: Warsztaty zespołowe gromadzą interesariuszy, aby szybciej podejmować decyzje.
• Zmień swój plan projektu: Czy zaplanowałeś kolejno definiowanie, projektowanie, a następnie programowanie? Rozważ wcześniejsze rozpoczęcie programowania i zaangażowanie projektantów oraz programistów we wspólne tworzenie czegoś na wcześniejszym etapie.

Stosuj metody prototypowania zamiast płaskich projektów

Zamiast postrzegać postęp jako dokument definicyjny lub płaski projekt, który jest jedynie polem wyboru do zatwierdzenia przez klienta, pokaż mu coś, co stanie się częścią ukończonego produktu.

Wykorzystaj szybkie prototypowanie, aby stworzyć coś działającego i użytecznego, a co ważniejsze — coś, co możesz testować z klientami. Zbieranie opinii na temat prototypu staje się użytecznym sposobem śledzenia postępów, zamiast polegania na elemencie dostarczanym, który nie ma tej zalety, że jest częścią finalnego produktu.

Możesz tworzyć prototypy o różnym poziomie wierności:

• Niska wierność: Projekty z możliwością klikania. Stosuje się je, gdy trzeba szybko przygotować makietę do przetestowania z klientami — jest to raczej test wyglądu i odczuć oraz prostych interakcji.
• Średnia wierność: Wykorzystanie pewnego ruchu lub animacji.
• Wysoka wierność: Działający kod HTML. Stosuje się go w przypadku złożonych interakcji, ale można go rozwijać i przekształcić w kod gotowy do wydania.

Prototypy o wysokiej wierności są bliższe „działającemu oprogramowaniu” niż pozostałe typy, ale ich przygotowanie może wymagać więcej czasu. Prototypy o niskiej lub średniej wierności zapewniają deweloperom lepsze wskazówki niż płaskie projekty.

Szybko dostarczaj coś użytkownikowi końcowemu lub klientowi

To ważna kwestia.

Dzięki częstym wydaniom działającego oprogramowania klient może korzystać z każdej nowej udostępnionej funkcji. Zamiast czekać z wielkim uruchomieniem do końca projektu, wcześniejsze dostarczanie wartości klientowi ma kluczowe znaczenie dla stworzenia lepszego produktu.

Jak możesz osiągnąć częstsze dostarczanie w swojej organizacji?

• Przeanalizuj plan projektu lub mapę drogową projektu: Czy zaplanowano ukończenie prac programistycznych, a następnie uruchomienie projektu na jego końcu? Zamiast tego współpracuj z zespołem, aby podzielić pracę na funkcje lub fragmenty, które można niezależnie wydawać w trakcie realizacji.
• Skup się na blokadach: Ważną częścią Twojej roli jest pomoc w usuwaniu przeszkód, gdy pojawiają się problemy. Jak możesz pomóc zespołowi pracować wydajniej? Czy istnieją sposoby pracy, które spowalniają wydawanie kolejnych wersji? Przeprowadzenie z zespołem retrospektywy sprintu może ujawnić możliwości usprawnienia procesu.
• Automatyzuj: Jeśli Twoja organizacja poświęca ogromny wysiłek na wydawanie kolejnych wersji, w miarę możliwości automatyzuj procesy. Na przykład automatyczne testowanie i wdrażanie może ograniczyć pracę ręczną oraz zmniejszyć nakład pracy potrzebny do wydania wersji. Porozmawiaj ze swoim zwinnym zespołem programistycznym o stosowanych przez niego procesach i możliwościach automatyzacji.

Wartość nr 3: Współpraca z klientem zamiast negocjowania umowy

Zamiast tworzyć na początku projektu niezwykle szczegółową umowę, określającą dokładne elementy dostarczane, zakres, budżet i harmonogram, utrzymuj swoją umowę zwinną na możliwie wysokim poziomie ogólności. Podejmuj decyzje w trakcie projektu, ściśle współpracując z klientami i interesariuszami.

Zwinność nie polega na poświęcaniu ogromnej ilości czasu na definiowanie wymagań z wyprzedzeniem. Chodzi o rozpoczęcie projektu i uczenie się w jego trakcie na podstawie testów z klientami oraz opinii zebranych na temat działającego oprogramowania.

Stosuj podejście, w którym klient jest najważniejszy

Uwielbiam ten cytat z artykułu Neila Killicka:

„Osoba myśląca zwinnie nieustannie pyta: „Jaki jest najprostszy/najszybszy sposób dostarczenia wartości klientowi?”. Czy zadajesz sobie to pytanie codziennie? Jeśli nie, oto Twój pierwszy krok.”

Nie tylko projektanci i deweloperzy powinni o tym myśleć — kierownicy projektów również. To także my odpowiadamy za dostarczenie klientowi najlepszego możliwego produktu lub usługi. Klient, użytkownik Twojego produktu lub usługi, powinien znajdować się w centrum wszystkiego, co robisz.

Umieść klienta końcowego w centrum planu

Zamiast planować działania wokół elementów dostarczanych i szacunków, planuj je wokół wartościowych rezultatów dla klienta. Co chcemy, aby zrobił klient i dlaczego? Jak zmierzymy, czy to działa?

Przeformułuj rozmowę tak, aby skupić się na tym, jaką wartość dostarczyliśmy klientowi, a nie na liczbie zrealizowanych elementów pracy.

Zaangażuj ściśle swojego klienta

Zamiast organizować cotygodniowe spotkanie statusowe, a następnie dostarczać rozwiązanie klientowi i interesariuszom po upływie określonego czasu, staraj się angażować klienta w projekt codziennie.

Jeśli stosujesz w większym stopniu proces Scrum, wyznacz klienta na właściciela produktu. Właściciel produktu odpowiada za zebranie wymagań biznesowych, technicznych i klienta. Wczesne i częste uzyskiwanie akceptacji klienta oraz współpraca z nim mają kluczowe znaczenie dla uniknięcia opóźnień. Ostatecznie prowadzi to do powstania lepszego produktu lub usługi dla klienta końcowego.

Zaangażuj klienta, który jest mało dostępny

Jeśli klient nie ma czasu na udział w projekcie lub z innego powodu nie jest zaangażowany, upewnij się, że ktoś z zespołu reprezentuje klienta. Kluczowe jest, aby ktoś brał pod uwagę potrzeby klienta i biznesu.

Nawet jeśli klient nie jest zaangażowany na co dzień, komunikuj się z nim regularnie i co najmniej angażuj go we wszelkie dyskusje dotyczące planowania zwinnego oraz ustalania priorytetów. Współpracuj z nim, aby pokazać korzyści płynące z jego zaangażowania.

Wdróż mapę drogową produktu

Rozważ wykorzystanie mapy drogowej produktu do przedstawienia jego kierunku rozwoju. Mapa drogowa produktu przedstawia plan dotyczący produktu i wizualizuje funkcje zaplanowane do wdrożenia. Mapa drogowa nie jest ustalana raz na zawsze na początku projektu — z czasem ewoluuje, odzwierciedlając zmiany priorytetów.

Rozmawiaj z użytkownikami końcowymi lub klientami

Nie mogę tego wystarczająco podkreślić — musisz starać się testować produkt z użytkownikami końcowymi i klientami na wczesnym etapie oraz często. 

Testowanie przynosi wiele korzyści:

• Możesz upewnić się, że produkt spełnia potrzeby klientów, czyli sprawdzić, czy jest dla nich wartościowy, a tym samym wartościowy dla firmy. Pomaga to ocenić dopasowanie produktu do rynku.
• Możesz uwzględnić opinie klientów w procesie projektowania i tworzenia, co prowadzi do powstania lepszego produktu końcowego.
• Możesz zdobyć wiedzę, która zasili przyszłe prace.

• Często wskazywanym problemem związanym z testowaniem z udziałem klientów jest budżet — takie testy mogą być kosztowne. Oto kilka sposobów testowania niezależnie od budżetu projektu:

Testowanie partyzanckie: Uwielbiam tę metodę, ponieważ jest tania i łatwa. Zaproponuj, że kupisz komuś prawdziwą lub wirtualną kawę w zamian za odpowiedzi na kilka pytań dotyczących projektów lub prototypu. Trudniej jest określić, kto odpowie na pytania, ale szybka informacja zwrotna może być pomocna podczas testowania wyglądu i sposobu działania lub prostych interakcji.

Ankiety: Aby zebrać dane ilościowe od większej grupy osób, możesz utworzyć ankietę w celu oceny projektu lub dokładniejszego zbadania zachowań klientów.

Witryny takie jak usertesting.com: Możesz przesłać swoje projekty do jednej z takich witryn i za jej pośrednictwem zrekrutować osoby, stosując w razie potrzeby określone kryteria. Następnie osoby te przejdą przez projekty, nagrają swoje przemyślenia i odpowiedzą na pytania.

Testowanie bezpośrednie: Tak, może to być droższa opcja, ponieważ prawdopodobnie trzeba będzie zrekrutować osoby i wypłacić im wynagrodzenie za udział. Może się jednak okazać nieocenione w przypadku testowania złożonych interakcji lub funkcji wysokiego ryzyka.

Wartość nr 4: Reagowanie na zmiany zamiast trzymania się planu

Projekty zwinne i kaskadowe nie mogłyby się bardziej różnić pod tym względem. W tradycyjnych projektach tworzenia oprogramowania wymagania, koszty i terminy ustala się z góry, podczas gdy podejście zwinne dopuszcza zmiany i wychodzi im naprzeciw.

Zmiana jest dobra! Nie jest złem! Ile planów projektów sprawdziło się dokładnie tak, jak zostały utworzone na początku? Niewiele, jak sądzę (pracowałem przy projektach, w których plan projektu miał dziesiątki iteracji).

Plany są najlepszym przypuszczeniem w danym momencie, które można doprecyzować w miarę postępów — nie uwzględniają jednak zwykle zmian. Co się stanie, jeśli zmienią się potrzeby klienta? Jeśli firma zmieni kierunek? Jeśli klient zmieni priorytety? Jeśli określona funkcja okaże się trudniejsza do zbudowania, niż zakładałeś?

Zwinne sposoby pracy uwzględniają niepewność poprzez adaptacyjne podejście do planowania, takie jak poker planistyczny. Na przykład wartości Scrum zakładają, że zespół planuje pracę sprint po sprincie. Przed rozpoczęciem ograniczonego czasowo okresu pracy zespoły zwinne wybierają elementy z rejestru prac i ustalają ich priorytety na potrzeby tworzenia.

Choć często dąży się do dokładnego określenia kosztów, harmonogramu i zakresu na początku projektu, bardziej realistyczne podejście do napotykanych niepewności często prowadzi do powstania znacznie lepszego produktu końcowego. Ostatecznie właśnie tego powinni oczekiwać: Ty, klient i interesariusze. 

Oto kilka sposobów na rozpoczęcie uwzględniania zmian w projektach i zachęcanie do większej elastyczności:

Utwórz „lekki” plan, aby zaspokoić potrzeby interesariuszy

„Ale potrzebujemy planu!” — wołają interesariusze. Zamiast wywoływać u nich panikę słowami: „Niespodzianka, nie ma planu!”, utwórz uproszczony plan wydań, aby zapewnić im poczucie bezpieczeństwa przy nieco mniej formalnym podejściu.

Jeśli stosujesz zwinne zarządzanie projektami z procesami Scrum, w swoim backlogu będziesz mieć listę uporządkowanych według priorytetów i oszacowanych historyjek użytkownika. Współpracuj z właścicielem produktu, aby pogrupować je w przybliżone wydania, a następnie odwzoruj je na mapie drogowej produktu.

Staraj się nie planować wszystkiego, niwecząc tym samym korzyści płynące ze stosowania metodyki Scrum. Pokaż interesariuszom, co planujesz w ramach pierwszych dwóch lub trzech wydań, a następnie wyjaśnij im, że ponowne planowanie jest podstawą zwinnego sposobu pracy oraz że w miarę postępów będziesz przekazywać im aktualizacje i informacje o kolejnych wydaniach. Miejmy nadzieję, że zapewni im to potrzebną pewność!

Stopniowo wprowadzaj zespół w podejście oparte na sprintach

Mike Cohn w swoim artykule „Wprowadzanie zwinnego procesu w organizacji” sugeruje, aby pomóc zespołom stopniowo wdrożyć Scrum poprzez zdefiniowanie zestawu typów sprintów, na przykład:

• Prototypowanie
• Zbieranie wymagań
• Analiza i projektowanie
• Wdrażanie
• Stabilizacja

Oto, jak opisuje on korzyści z takiego podejścia:

„Następnie współpracujemy z zespołami, aby zdefiniować artefakty, które powstaną w ramach każdego typu sprintu. Wprowadzenie typów sprintów zapewnia wystarczający poziom formalizacji, aby zespoły mogły wyraźniej dostrzec kolejne etapy projektu. W miarę jak zespoły coraz lepiej radzą sobie z nieformalnością zwinnego procesu, stopniowo rezygnują z koncepcji typów sprintów.”

To kolejny sposób na ukształtowanie planu wydań. Jeśli przypiszesz „typ” do każdego sprintu, interesariusze będą mogli zobaczyć, jak powstaje plan, a Ty nie będziesz musieć gwarantować konkretnych funkcji. Twój zespół również lepiej zrozumie, nad czym będzie pracować.

Odejście od sztywnych terminów

Wyznaczenie zespołowi terminu lub przekazanie klientowi konkretnej daty to strategie, które są skazane na niepowodzenie albo przynajmniej powodują stres po drodze. Budowanie zaufania między Tobą a zespołem oraz między Tobą a klientem lub interesariuszem jest niezbędne, aby udowodnić, że dostarczysz rozwiązanie i wartość dla klienta końcowego.

Pamiętaj, że próbujesz ograniczyć potrzebę przeprowadzania wielu punktów kontrolnych i uzyskiwania licznych zatwierdzeń. Wprowadzanie terminów do projektu nie pomoże Ci osiągnąć tego celu. Nie jest też dobrym rozwiązaniem ciągłe wywieranie presji na zespół i ponaglanie go w sprawie pracy, której „obiecał” dostarczyć.

Jak wspomniałem powyżej, mapy drogowe i plany wydań mogą być dobrym mechanizmem odejścia od podejścia opartego na stałej dacie. Przekazanie interesariuszom informacji o tym, co zostanie wydane w najbliższej przyszłości, może uspokoić ich, że istnieje plan.

Zastosuj zakres oparty na czasie i materiałach

Jeśli masz zakres o stałej cenie i stałych elementach do dostarczenia, trudno będzie realizować projekt w bardziej zwinny sposób. Zdecydowanie możesz zastosować niektóre z omówionych już technik, takie jak umożliwienie bardziej zespołowej współpracy. Będziesz jednak mieć ograniczone możliwości reagowania na zmiany i dostosowywania się do nich, pozwalania zespołowi na określanie, nad czym pracuje, czy stosowania podejścia bardziej skoncentrowanego na kliencie.

Wspólnie z zespołem wewnętrznym i klientem ustal zakres oparty na czasie i materiałach — tzn. klient płaci za zespół, a nie za stałe elementy do dostarczenia. Na początku klienci mogą się denerwować, jeśli nie będą dokładnie wiedzieć, co otrzymają.

Aby złagodzić te obawy, możesz uwzględnić w zakresie backlog działań lub zadań, które można rozważyć do uruchomienia. Określ w umowie, że w miarę postępów projektu zespół będzie ponownie planować i ustalać priorytety backlogu z uwzględnieniem opinii klienta (chociaż nie wszystkie elementy muszą zostać zrealizowane).

Aby pomóc w zarządzaniu zmieniającymi się priorytetami i elementami do dostarczenia, zespoły mogą korzystać z oprogramowania do zwinnego zarządzania, aby stale zmieniać priorytety backlogu, oraz z narzędzi do współpracy przy tworzeniu oprogramowania, aby koordynować współpracę międzyfunkcyjną.

W ten sposób nie zobowiązujesz się do realizacji stałego zakresu, ale klient ma mniej obaw dotyczących wyglądu produktu końcowego.

Nie przestawaj śledzić postępów

Śledzenie i wizualizowanie postępów nie znika tylko dlatego, że nie ma formalnego planu projektu. Utrzymywanie widoczności postępów dla zespołu i interesariuszy nie tylko gwarantuje, że nie stracisz z oczu potencjalnych przeszkód i wąskich gardeł, lecz także pozwala interesariuszom być na bieżąco. 

Korzystanie z tablicy WIP w stylu Kanban lub zwinnych pulpitów nawigacyjnych dobrze sprawdza się w projektach zwinnych. Po zwizualizowaniu procesu możesz zacząć rozplanowywać zadania i działania wspierające. Pomaga to dostrzec wąskie gardła, które można usunąć, aby ułatwić szybsze dostarczanie rozwiązań klientom.

Krytyka Manifestu zwinnego tworzenia oprogramowania

Podobnie jak każda inna metodyka zarządzania projektami, podejście zwinne nie jest idealne. Krytycy wskazują, że autorzy Manifestu Zwinnego Wytwarzania Oprogramowania byli jednorodną grupą, która mogła nie wziąć pod uwagę alternatywnych sposobów pracy, takich jak korzyści z pracy zdalnej czy zastosowanie podejścia zwinnego poza obszarem tworzenia oprogramowania.

Posunięte zbyt daleko podejście zwinne może oznaczać podejmowanie decyzji przez komitet, spowalniając tempo pracy. Brak dokumentacji może ostatecznie zaszkodzić realizacji projektu, szczególnie w środowisku zdalnym, w którym komunikacja asynchroniczna ma kluczowe znaczenie.

Jeśli zdecydujesz się stosować podejście zwinne w swoich projektach, koniecznie zapoznaj się z wartościami i zasadami zwinnego podejścia. Są one pomocnym przewodnikiem, który pozwala ograniczać najgorsze tendencje tego podejścia.

Przeczytaj więcej o debacie na temat tego, czy podejście zwinne jest metodyką, czy sposobem myślenia.

Zwinność, nie podejście zwinne

Ostatnia myśl: pamiętaj o retrospektywie! Jak stwierdza Manifest:

W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć swoją skuteczność, a następnie odpowiednio dostosowuje i koryguje swoje działania.

Niezależnie od rodzaju stosowanego procesu retrospektywa to skuteczny sposób analizowania tego, jak pracujesz, i optymalizowania działań pod kątem sukcesu. Pamiętaj, aby regularnie uwzględniać retrospektywy projektu w wybranym procesie — oraz zadbaj o mechanizm uwzględniania zdobytych wniosków! PS: Ważne jest, aby zachęcić mniej rozmownych członków zespołu do zabierania głosu podczas retrospektyw — oto jak to zrobić.

Co dalej?

Aby dowiedzieć się więcej o wdrażaniu zwinnych sposobów pracy i czerpać wiedzę od najlepszych kierowników projektów w branży, zapoznaj się z naszymi opcjami członkostwa DPM.