Ostateczne wprowadzenie do zwinnego zarządzania projektami

Krótkie

Odpowiadasz za dostarczenie najnowszej i największej inicjatywy swojej firmy, która na zawsze zmieni oblicze „Widgets International”. Jest to projekt oprogramowania, który zainteresuje i zafascynuje Twoich klientów, ułatwi życie współpracownikom i przyniesie firmie milionowe przychody. Jest dużo oczekiwania, zapału, podekscytowania i oczekiwania. Musisz to zrobić tak szybko, jak to możliwe, aby Twoja firma mogła zacząć czerpać korzyści. Przyszły sukces firmy zależy od Ciebie. Wszystkie oczy skierowane są na ciebie. Nie możesz zawieść.

Na początku myślisz sobie: „Świetnie, jestem gotowy na wyzwanie. Zróbmy to!” Zatrzymujesz się na chwilę, robisz krok w tył i myślisz sobie „OK, więc jak to zrobimy?” Zaczynasz rozmawiać z kolegami i rówieśnikami. Spędzasz czas na poszukiwaniu najlepszych praktyk w zakresie tworzenia oprogramowania i technik zarządzania projektami, ale opcje i podejścia są niezliczone. Jest mnóstwo akronimów i metodologii. Znani wspinają się na szczyt. Wkradają się wątpliwości. Którego użyć? Jak mogę zagwarantować sukces? A jeśli podejmę złe decyzje?

Jeśli chodzi o zarządzanie projektami oprogramowania, istnieje mocna mieszanka opcji poparta niezliczonymi opiniami. Głosy z kątów pokoju szepczą: „Spróbuj to zrobić w ten sposób”; inni krzyczą: „To jedyny sposób, aby to zrobić”; a reszta tylko skomle: „W ogóle nie radzę sobie z tym, po prostu zajmij się tym”. W rzeczywistości wszystkie te głosy mówią trochę prawdy. Ale ważne jest, aby ustalić, co jest odpowiednie dla Twoich potrzeb, Twojego zespołu, Twojej firmy i Twoich klientów.

Ustawiać scenę

Był czas, kiedy zarządzanie projektami oprogramowania siedziało prosto w jednym z trzech obozów. Istniały ciężkie ramy, które pozwalają podejmować decyzje dotyczące sposobu wykonywania i dostarczania, oferując jednocześnie strukturę do utrzymania kontroli i zarządzania. Istniały nakazowe metodologie sekwencyjne, takie jak kaskada, które zmuszały Cię do planowania długich projektów, zrozumienia i zobowiązania się do spełnienia wszystkich Twoich wymagań, projektowania i zatwierdzania złożonych systemów, pisania dużej ilości kodu, a następnie testowania (wszystko to, zanim klient zobaczy to po raz pierwszy czas). I wreszcie, mniej nakazowe, ale iteracyjne cykle życia oprogramowania (SDLC), które zachęcają do szybkiego prototypowania lub większych systemów, które należy projektować, budować i dostarczać w krokach przyrostowych, każdy budowany jeden nad drugim.

Zwinne tworzenie oprogramowania i zwinne zarządzanie projektami zrodziły się z niedoskonałości wodospadu i korzyści z iteracyjnych podejść do dostarczania oprogramowania. Ich korzenie sięgają lat 50., przywództwa myślowego w latach 70., dojrzałości w latach 90. i adopcji w latach 00. W 2001 roku grupa praktyków i ekspertów stworzyła Manifest Agile, którego celem jest zdefiniowanie 4 wartości i 12 zasad przewodnich, które mają na celu ucieleśnienie ducha tworzenia oprogramowania Agile i zachęcenie do jego ewolucji. I zdecydowanie ewoluowało.

Teraz samo nazwanie czegoś Agile nie jest szczególnie pomocne. Słowo, nawet w kontekście oprogramowania, oznacza różne rzeczy dla różnych osób lub organizacji. Istnieje wiele aspektów, definicji, implementacji i interpretacji. Każde ciało, które obejmuje Agile, stara się nadać mu własną definicję.

Wystarczy powiedzieć, że zwinne tworzenie oprogramowania i zarządzanie projektami to grupa powiązanych zachowań, struktur, technik i koncepcji, które zasadniczo faworyzują dostarczanie odpowiedniego działającego oprogramowania tak wcześnie i tak często, jak to realnie możliwe.

Wspomniałem wcześniej, że Agile, w zastosowaniu do tworzenia oprogramowania lub zarządzania projektami, może być różnymi rzeczami. W skrócie, Agile Software Development zajmuje się tworzeniem świetnego oprogramowania w zwykłym biznesie (BAU) lub kontekście projektu. Z drugiej strony, zwinne zarządzanie projektami zapewnia zarządzanie i kontrolę wymaganą do dostarczania złożonych projektów, w tym między innymi oprogramowania.

Dostępnych jest wiele metod tworzenia oprogramowania Agile, takich jak Scrum, Kanban, XP i Lean Software Development. Ale tak jak gra w rugby to coś więcej niż scrum, tak samo jest z Agile. W odosobnieniu, te paradygmaty Agile nie odnoszą się do pełnego cyklu życia zarządzania projektami wymaganego w złożonych projektach, takich jak zarządzanie, zasoby, finanse, zarządzanie jawnym ryzykiem i wiele innych ważnych koncepcji zarządzania projektami. W tym przypadku możesz rozważyć PMI Agile lub PRINCE2 Agile — pomyśl o tym jako o „zwinności rządzonej”.

Dlaczego musimy być zwinni?

Dawno temu wędrowaliśmy po ziemi, aby zbierać żywność i schronienie, aby przeżyć. Były to proste potrzeby, ale dość zwinne. Jakiś czas później kraje i gospodarki rosły i prosperowały dzięki rewolucji przemysłowej. To były narodziny zarządzania i kontroli oraz utrata zwinności. Teraz jesteśmy w epoce informacyjnej lub rewolucji, w której firmy zatrudniają pracowników wiedzy. Pracownicy wiedzy to Ty, Twoi partnerzy, Twoi koledzy i koledzy, którzy starają się tworzyć doskonałe rozwiązania problemów klientów, biznesu, problemów społecznych, ekonomicznych i światowych. Pracownicy wiedzy stosują analizę, wiedzę, rozumowanie, zrozumienie, wiedzę fachową i umiejętności do często luźno zdefiniowanych i zmieniających się potrzeb. Te przedsiębiorstwa i pracownicy potrzebują metod i technik, którym nie mogą sprostać procesy i procedury ze starej epoki industrialnej. Agile wspiera interakcje.

Praktycznie żaden projekt oprogramowania nie może śmiało zacząć od początku i wiedzieć wszystkiego, czego potrzebuje, aby dostarczać wartościowe, działające oprogramowanie bez zmian. Zmiana stwarza zarówno szanse, jak i zagrożenia dla powodzenia projektu. Niezarządzane możliwości mogą oznaczać różnicę między świetną firmą a niesamowitą firmą. Niekontrolowane ryzyko oznacza katastrofę i ruinę. Agile zarządza zmianami.

Przyjęcie Agile umożliwia reagowanie na zmieniające się lub nowe wymagania. Umożliwia zespołom programistów bycie ekspertami i podejmowanie decyzji wspieranych przez zaangażowaną, ufną i poinformowaną firmę. Umożliwia dostarczanie klientom tego, czego naprawdę chcą. Ostatecznie daje to Tobie i Twojej organizacji kontrolę nad dostarczaniem wysokiej jakości, wartościowego oprogramowania, które spełnia potrzeby i oczekiwania klientów, przy jednoczesnym jak najszybszym uzyskiwaniu zwrotu z inwestycji. Agile tworzy wartość.

Przyjęcie Agile wiąże się z pewnymi kosztami. Nie przychodzi za darmo. Przejście na podejście Agile w zakresie dostarczania oprogramowania może być trudną ścieżką do naśladowania. Jeśli jednak zinternalizujesz filozofię Agile, będziesz stąpać ostrożnie, zaangażujesz właściwy zespół z odpowiednim nastawieniem, rozbijesz rzeczy, sprawisz, że będzie to osiągalne i realistyczne oraz zareagujesz na informacje zwrotne, zbierzesz korzyści. Agile kładzie nacisk na współpracę.

Poniżej wymieniono niektóre korzyści, których możesz się spodziewać:

• Szybkość wprowadzania na rynek
• Wcześniejsze generowanie przychodów
• Regularna dostawa realnej wartości
• Ochrona Twojej inwestycji
• Dane, dane, dane
• Lepsza jakość produktu
• Zarządzanie oczekiwaniami
• Większa satysfakcja klienta
• Zespoły osiągające lepsze wyniki
• Lepsza widoczność postępów
• Przewidywalność, przejrzystość i pewność
• Ryzyko do opanowania

Sukces nie jest ostateczny, porażka nie jest zgubna: liczy się odwaga, by kontynuować.

Winston Churchill może nigdy tego nie powiedział, ale myślę, że to całkiem dobre podsumowanie Agile. Wiemy, że Agile jest najlepszym krokiem naprzód dla większości projektów. Zachęca Cię do dążenia do sukcesu, ale zawsze iterujemy i budujemy na nim. Agile zachęci Cię do porażki, ale poniesiesz porażkę wcześnie i pójdziesz dalej. Odwaga, by kontynuować i budować właściwe rozwiązanie w oparciu o wiedzę poinformowaną przez klienta, przynosi nagrodę.

Należy pamiętać, że możesz dostosować Agile do swoich potrzeb. Użyj metody i zarządzania, które są odpowiednie dla Twojej firmy. Gdziekolwiek zaczniesz, bądź wierny treści, kontekstowi i duchowi metody, której używasz — zachowaj to, co waniliowe. Jeśli dopiero zaczynasz, naucz się . Jeśli robisz to od jakiegoś czasu, zrozum . Jeśli robisz się super, aplikuj . Wreszcie, jeśli Twoja firma i projekty są złożone i współzależne, zarządzaj . Z biegiem czasu Ty i Twoje zespoły odkryjecie, co najlepiej sprawdza się w Twojej firmie.

Wykonalność

Więc teraz myślisz: „Ok, rozumiem. Jak zacząć? Gdzie zaczynam?" Cóż, ze wszystkimi dobrymi rzeczami zaczynamy od początku. A w przypadku Agile wystarczy zadać sobie pytanie „Jaką wartość biznesową chcę zapewnić?” W końcu dlatego podejmujemy się projektów, aby generować wartość biznesową. Aby ustalić, czy warto podjąć się projektu, aby uzyskać wartość biznesową, musisz zrozumieć, czy jest to wykonalne.

Wizja

Czy Twój projekt ma na celu zwiększenie przychodów, wejście na nowy rynek, pozyskanie większej liczby klientów, poprawę postrzegania klientów lub ułatwienie życia w przypadku zidentyfikowanego problemu? Mając to na uwadze, możesz przedstawić swoją „wizję”.

• Twoja wizja może pochodzić z różnych źródeł — od Twojego własnego, odważnego start-upu do rozwiązania wspólnego problemu, strategii zarządzania firmą, ulubionego projektu Twojego CEO, konkretnego zespołu produktowego, a nawet potrzeb Twojego klienta.
• Spróbuj cofnąć się o krok od własnych butów i „zobaczyć” jak wygląda przyszłość z nowym produktem lub usługą w rękach Twoich klientów.
• Zaangażuj swoich interesariuszy — dyrektora generalnego, kierownika ds. produktu i klientów. Ćwicz to, nie próbuj tego w odosobnieniu. Zmierz się z założeniami i zweryfikuj argumenty.
• Zapisz to, zachowaj krótkie. Skoncentruj się na wartości biznesowej.
• Ulepsz go, aż wszyscy się zgodzą, że wizja będzie rezonować ze wszystkimi i spotka się z powszechną interpretacją, która określa, dokąd zmierzasz.
• Twoja wizja, jeśli jest ważna, rzadko się zmienia. Jak się tam dostaniesz, z pewnością tak będzie.

Ludzie nie kupują tego, co robisz i jak to robisz. Kupują „dlaczego” to robisz. To właśnie tworzy emocjonalną więź między Twoją firmą a klientami. Wizja pomoże to zilustrować.

Czy to możliwe?

Wykonalność ma co najmniej kilka odcieni. Zazwyczaj będziesz chciał zrozumieć, czy Twoja wizja lepszej przyszłości dla Twojej firmy i klientów jest zarówno technicznie wykonalna, jak i wykonalna dla Twojej firmy.

• Jeśli Twoim celem jest podróż do dowolnego miejsca na świecie w niecałą godzinę, możesz mieć problem z wykonalnością techniczną. Ponieważ nauka, fizyka i technologia nie do końca jeszcze doścignęły tego marzenia, twoje rozwiązanie techniczne może nie być opłacalne w niczym innym niż teoria. Ponadto, gdyby Twoje rozwiązanie było nowe, wykraczałoby to daleko poza ideę minimalnego opłacalnego produktu (MVP).

• Aby przetestować techniczną wykonalność swojego produktu, rozważ dalsze zbadanie go w prototypowym projekcie Discovery lub uruchomienie skoku na wczesnych etapach projektu. Będziesz wiedział, którą metodę zastosować, myśląc o skali lub złożoności rozwiązania, które masz na myśli.

  „Najlepsza wiedza, jaką moje zespoły zdobyły w zrozumieniu technicznej wykonalności, pochodzi z wykonania skoku. I często jest to najprostsze rozwiązanie, które wygrywa!”

• Drugim odcieniem wykonalności do rozważenia jest to, czy Ty, Twój zespół lub Twoja firma macie umiejętności i motywację, aby to zadziałało. Na przykład, jeśli jesteś świetny w pieczeniu ciast w domu na urodziny swoich dzieci, to jest słodkie. Ale jeśli chcesz przekształcić to w firmę sprzedającą najlepsze ciasta na świecie, musisz zrozumieć, czy potrafisz ją zwiększyć, obsługiwać zarówno biznes, jak i produkcję, zarządzać dystrybucją i realizacją oraz dbać o obsługę klienta.
• Ten rodzaj wizji może być osiągalny na dłuższą metę. Ale na razie może nie. Więc zmniejsz to, myśl na małą skalę, weź mały fragment, który wygląda realistycznie i skoncentruj się na zapewnieniu jak najlepszej, mniejszej aspiracji. Jeśli to zdoła zaangażować i zachwycić klientów, spraw, by wracali po więcej i opowiadali znajomym, a następnie zwiększ skalę, korzystając z opinii klientów jako przewodnika i kompasu.
• Musisz także wiedzieć, czy Twój projekt jest wykonalny pod względem budżetu i ram czasowych. Czy Twoja firma może sobie pozwolić na realizację tego projektu? Czy ramy czasowe są osiągalne? Czas i pieniądze to dwa z trzech ograniczeń w projekcie zwinnym, które są naprawione. Staramy się dostarczać w określonym czasie iw ramach ustalonego budżetu.
• Jakość produktu odnosi się do produktu końcowego, z którego korzystają Twoi klienci, oraz praktyk inżynieryjnych stosowanych przez Twój zespół w celu dostarczania doskonałego, solidnego i niezawodnego oprogramowania. Jakość to także coś, czego nie brakuje nam do zmiany. Z drugiej strony mogą ulec zmianie kryteria jakości. Jeśli nie planujesz budowy Ferrari, produkt może nie być postrzegany jako wysokiej jakości. Jeśli nie budujesz rakiet kosmicznych, tolerancje osiągane w warunkach produkcyjnych mogą być znacznie wyższe. Wcześnie ustaw odpowiedni ton i oczekiwania.

Więc teraz potwierdziłeś, że twoje marzenie to coś więcej niż czekoladowa fantazja, zajmij się testowaniem swoich założeń i udowadnianiem ludziom, że warto zainwestować w to przedsięwzięcie.

Uzasadnienie

Teraz, w zależności od okoliczności, usprawiedliwienie przyjmie różne formy. Ale zasadniczo chcesz udowodnić, że ten projekt spełni kryteria sukcesu klienta, ma szanse powodzenia, przyniesie wartość i jest przystępny cenowo.

• Określ swoje założenia w oparciu o potrzeby klienta, a następnie zweryfikuj je. Lean Startup daje świetne wskazówki dotyczące identyfikacji i udowodnienia, że ​​Twój produkt jest potrzebny Twoim klientom i tworzy wartość.

• Napisz, przetestuj i zweryfikuj swój biznesplan. Teraz nie wygląda to tak, jak ten, który kazał ci produkować twój bank lub główny biznes i finanse. Nie używaj ich — będą nieaktualne, zanim atrament wyschnie. Zamiast tego sprawdź kanwę modelu biznesowego. Jest to zasadniczo krótki biznesplan, który pozwala skupić się na propozycji wartości, klientach, przychodach i kosztach. Użyj go, aby sprawdzić, czy masz firmę, która będzie działać.

  „Raz zignorowałem tę radę i spędziłem dużo czasu na pisaniu długiego, tradycyjnego 50-stronicowego biznesplanu. Nigdzie mnie to nie zaprowadziło. Wszystkie założenia, które poczyniłem, były bezpodstawne, a wszystkie prognozy, które poczyniłem, nie mogły zostać potwierdzone. To było bolesne i kosztowne doświadczenie, które nauczyło mnie, że nigdy więcej tego nie zrobię”.

• Jeśli prowadzisz dojrzałą firmę, w której portfele projektów są dostarczane w złożonym środowisku, konieczne może być modelowanie finansowe. Jeśli musisz, zrób to dopiero po udowodnieniu powyższego.
• Po zbudowaniu MVP może zaistnieć potrzeba stworzenia bardziej tradycyjnego biznesplanu — na przykład, jeśli musisz wybrać finansowanie lub wybór z portfolio konkurencyjnych projektów i zasobów firmy. Ale będzie to biznesplan oparty na narzędziach użytych powyżej i oparty na nich. Będzie też lżejszy.
• W każdym razie używaj tych narzędzi jako żywych, oddychających artefaktów. Użyj ich jako przewodnika i perednicy. Nigdy nie są statyczne. Odwołaj się do nich i popraw je w miarę rozwoju projektu lub firmy.

Gdy masz swoje uzasadnienie i wszyscy interesariusze są na pokładzie, będziesz w ogniu.

Faza wykonalności jest zwykle przeprowadzana raz w życiu projektu. Może się okazać, że ponownie przyjrzysz się wizji i wykonalności projektu, zwłaszcza jeśli wskazują na to Twoje dane, klienci, rynek lub biznes. Przynajmniej będą twoimi światłami przewodnimi przez cały czas.

Inicjacja

Świetny. Decyzja podjęta, projekt ma zielone światło i jesteś gotowy do budowy. No, prawie. Wiem, że myślisz: „No już, naprawdę? Jeśli nie zrobimy tego teraz, nigdy tego nie zrobimy. Zabierzmy ten program w trasę!” Ale pomyśl o tym — Agile to nic innego, jak dostarczanie wartości wcześnie i często, jednocześnie zachwycając klientów po drodze. Poświęcenie trochę czasu na znalezienie najlepszego sposobu realizacji projektu jest najlepszym fundamentem sukcesu.

Drużyna

W sporcie, myśląc o swojej ulubionej grze zespołowej, będziesz w stanie rozpoznać kluczowe role, które umożliwiają zespołowi wykonywanie tego, co robią. Tradycyjnie znajdziesz menedżera, kapitana i resztę składu. Poza tym znajdziesz trenerów, fizjoterapeutów, dietetyków i cały personel pomocniczy. Ale jeśli spojrzymy na grę w rugby, w zespole jest drużyna: gracze, którzy tworzą scrum. Ta paczka składa się z wyznaczonych graczy, których zadaniem jest odzyskanie piłki i kontynuowanie gry. Kiedy w grze jest scrum, zawodnicy z każdej strony pracują, bez lidera, jako jedna jednostka, współpracując, komunikatywnie i wydajnie, aby odzyskać piłkę w posiadaniu. To właśnie gra w rugby zainspirowała Jeffa Sutherlanda do nazwania swojej metodologii tworzenia oprogramowania „Scrum”.

• Scrum nie jest jedyną metodą tworzenia oprogramowania w podręczniku Agile. Ale to ten, który najlepiej opisuje koncepcję Agile i zachowania związane z pracą w zespole, motywowaniem jednostek, tworzeniem relacji opartych na zaufaniu, samoorganizacją, przywództwem sługą, komunikacją, przejrzystością i współpracą.
• Twój zespół będzie uformowany w dużej mierze przez okoliczności, w jakich się znajdziesz. Możesz mieć do dyspozycji programistów. Niektórzy, żaden lub wszyscy mogą być zaznajomieni z Agile w różnym stopniu. Możesz zatrudnić nowy zespół lub partnera z osobą trzecią.
• Inne role również będą wymagane, ale omówimy je później.
• Mówi się, że jeśli tworzysz zespół programistów, to wybrałeś swoją technologię. W zależności od tego, skąd zbierzesz swój zespół, otrzymają oni określone umiejętności. Zastanów się więc dokładnie, w jaki sposób tworzysz swój zespół programistów i czy musisz przeprowadzić ocenę techniczną, zanim dojdziesz do tego punktu swojej podróży.
• To prowadzi nas do zespołów wielofunkcyjnych. Zespoły działają najlepiej, gdy pracują razem, gdy jednostki angażują się, aby wykonać zadanie, niezależnie od ich tytułu. Postaraj się zbudować samowystarczalny zespół i jednostki, które pełnią więcej niż jedną rolę.
• Zbuduj środowisko, kulturę i centrum relacji — miejsce, w którym zespół może działać bez ograniczeń i ograniczeń. Daj zespołowi narzędzia, ludzi, zasoby i przestrzeń, aby był skuteczny i wydajny.
• Utrzymuj wielkość zespołu nie większą niż siedem lub osiem. Jeśli potrzebujesz więcej programistów, podziel zespół na kilka nowych zespołów. Każdy zespół może wtedy odpowiadać za dany obszar funkcjonalny. Jeśli masz wiele zespołów w wielu lokalizacjach, rozważ przeprowadzenie Scrum of Scrums. A tam, gdzie jest ich wiele w złożonych środowiskach, użyj zarządzania projektami Agile.
• Upewnij się, że zespół, biznes, interesariusze, a nawet klienci mają do siebie wzajemny dostęp. Upewnij się, że komunikują się i współpracują, i usuwaj wszystko, co przeszkadza w postępie. Codzienna komunikacja to najlepsze lekarstwo na dolegliwości projektowe. Kiedy ludzie mówią, załatwiają sprawy.

Istnieje wiele sposobów na stworzenie zespołu w celu dostarczania oprogramowania.

Krótki opis projektu

Na etapie studium wykonalności odkryłeś „dlaczego” swój projekt i albo zbudowałeś pewność siebie, aby iść naprzód ze swoim startupem, albo uzyskałeś wsparcie, aby kontynuować. Krótki opis projektu to żywy dokument, który łączy „dlaczego” z „co”, „kiedy” i „kto”. To „życie”, ponieważ wraz z postępami twoja wiedza, zrozumienie i ścieżka mogą się zmieniać. Opuszczenie tego dokumentu po jego napisaniu i nigdy do niego nie wracanie po prostu przenosi twoje myśli do punktu w czasie. W świecie Agile Twoje odniesienie do punktu w czasie może zmieniać się co tydzień, a nawet codziennie na początku, dlatego ważne jest, aby zachować to świeżość.

• Świetnym narzędziem do uchwycenia i utrzymywania krótkiego opisu projektu jest coś, co Jonathan Rasmusson nazywa „talią inicjującą” w swojej książce The Agile Samurai . Tutaj znajdziesz świetne porady, jak upewnić się, że wszyscy zainteresowani, dotknięci lub zaangażowani w Twój projekt są na tej samej stronie.
• Największym wrogiem realizacji projektów jest niejasne, niespójne lub po prostu inne rozumienie tego, czym jest projekt i jakie „wymagania” mają zostać spełnione. Jeśli nawet jeden ważny interesariusz ma inne rozumienie lub pogląd na to, co robisz, konsekwencje mogą być poważne.
• Dobry brief projektowy komunikuje:
  1. Wspólne i uzgodnione oczekiwanie interesariuszy i członków zespołu.
  2. Zrozumienie projektu, z takim samym zrozumieniem przez wszystkie strony.
  3. Cel, wizja, cel, zakres i kontekst projektu.
• Będziesz mieć dużo dobrych informacji do briefu zebranego z wykonalności. Brief projektowy pomoże Ci zdefiniować i znaleźć odpowiedzi na poszukiwane pytania. Zgromadzi interesariuszy, rację bytu , zakres wysokiego poziomu, ryzyko, rozwiązanie docelowe, budżet, harmonogram, oczekiwania i priorytety.

Kolega zatrzymał mnie kiedyś na korytarzu i zapytał, skąd może wziąć brief do projektu. Zażartowałem: „Nie potrzebujemy briefu, jesteśmy Agile”. Wyglądał na zdezorientowanego, jakby kwestionował moje zdrowie psychiczne lub autorytet. Miał rację, robiąc to.

Zanim przejdziesz dalej, upewnij się, że wszyscy są na tej samej stronie, przećwicz to, zadaj trudne pytania i umieść to w miejscu, gdzie ludzie mogą się zatrzymać, przeczytać, skomentować i pomóc poprawić.

Kultura i sposoby pracy

Znasz sposób, w jaki działa Twoja firma i jej kulturę, sposób, w jaki lubi robić różne rzeczy. Agile ze swej natury może rzucić wyzwanie niektórym z tych sposobów pracy, które Twoja firma kultywowała przez lata. Nie oczekuj, że Agile zostanie wdrożone i że wszyscy z miłością przyjmą go od samego początku. Niektórzy ludzie mogą uznać to za mylące i postrzegać je tylko ze strachem i strachem. Niektórzy ludzie mogą otwarcie odmówić zaangażowania się w to. To są wyzwania i spostrzeżenia, które musisz przezwyciężyć. Ale na początku nie chodź wymachiwać kijem Agile, bijąc każdego, kto nie chce go słuchać. To nie zbuduje zaufania, adopcji ani zaangażowania.

Byłem kiedyś fanem wymachiwania dużymi przysłowiowymi kijami i przysporzyło mi to wielu negatywnych opinii. Odwróciłem to, ale najpierw doznałem znacznego bólu.

Wyruszając na ścieżkę adopcji, postępuj ostrożnie, z szacunkiem i empatią. Jeśli prowadzisz trzeszczącą, starą, tradycyjną firmę, być może nie będzie to najlepsze podejście do dostosowania całego biznesu. Zacznij od małych rzeczy i stopniowo zdobywaj szacunek i uznanie. Zacznij tylko od swojego zespołu. Gdy zaczniesz dostarczać szybsze oprogramowanie o lepszej jakości niż kiedykolwiek wcześniej, ludzie zaczną to zauważać i zechcą zagrać w Twoją grę. Kiedy to zrobią, zaoferuj im piłkę, zabierz ich na kawę i wprowadź ich do nowego świata. Pomóc im.

Wraz ze swoim zespołem, teraz, gdy już wiedzą, czego dotyczy projekt i uzgodniono Twoje plany dotyczące adopcji Agile, pozwól zespołowi zdecydować, jak chcą się zachowywać i działać jako zespół.

• Poprowadź swój zespół, aby zidentyfikować koncepcje, techniki, zachowania i ramy Agile, które Twoim zdaniem odpowiadają Twoim wspólnym potrzebom.
• Przyjmij prośby od członków zespołu, jakie mają wymagania, aby pomóc im działać najlepiej, jak potrafią. Niektóre z tych próśb będzie można rozwiązać natychmiast. Inni mogą potrzebować pomocy budżetowej lub zewnętrznej. Zrób, co możesz, aby tak się stało.
• To są twoje pierwsze kroki do zostania prawdziwym przywódcą-sługą.
• Zastanów się nad zorganizowaniem odpowiedniego szkolenia w zakresie koncepcji i technik, które Twój zespół zdecyduje się zastosować. Jest to najlepszy sposób, aby upewnić się, że wszyscy członkowie zespołu, nawet interesariusze, znajdują się na tej samej stronie i otrzymują ten sam komunikat. Współpracuj z organizacją dostawców, która może dostosować swoją ofertę do Twoich potrzeb.
• Bądź ostrożny. Nikt nie będzie Agile ninja po kilku dniach na warsztatach uczących, jak stać się Agile. Twoja droga będzie długa. Słowo „stać się” jest dość definiujące. Tylko wtedy, gdy naprawdę zaakceptujesz Agile, zobaczysz jego wartość. Powinno cię ekscytować. Jeśli cię to ekscytuje, podniecaj także innych.
• Teraz, gdy Twój zespół uzgodnił koncepcje i techniki, spełnił jego życzenia i przeszedł szkolenie Agile, zwróć uwagę zespołu na siebie i na to, czego oczekują od Ciebie, firmy i siebie nawzajem.
• Zdefiniowanie niektórych sposobów pracy (WoW) w zespole i przez zespół pomaga budować zaufanie, relacje i oczekiwania. WoW to nie wojna i pokój . Powinna być krótka i rzeczowa, zawierać od siedmiu do dziesięciu wypunktowanych zdań. Zdania te jasno określają, jak ludzie zachowują się, komunikują, współpracują, wspierają, dostarczają i wykonują razem. Powinna również określać, czego zespół oczekuje od firmy.

• Agile to zarówno sposób myślenia, jak i przewodnie zasady i koncepcje. Pomaga rozwijać się w sposób, w jaki zachowujesz się, myślisz, negocjujesz, wchodzisz w interakcje, komunikujesz się, wykonujesz i poprawiasz. Opiera się na zmotywowanych jednostkach wspierających się nawzajem, aby wspólnie osiągnąć wspólny cel. Jest takie afrykańskie przysłowie:

Do tej pory Twój zespół powinien być bardzo podekscytowany, pełen energii i zmotywowany. Teraz zaangażuj ich bardziej w swoje zaległe historie użytkowników.

Zaległości

Nie miej wątpliwości, że w twoim projekcie jest niepewność. Prawdopodobnie nie możesz dokładnie wiedzieć, czego potrzeba, aby zbudować odpowiedni produkt dla swoich klientów na tak wczesnym etapie jego życia. Nie można patrzeć tęsknie w kryształową kulę i przepowiadać przyszłość.

„Backlog” lub „backlog” to miejsce, w którym żyją Twoje wymagania. Agile preferuje pisanie krótkich, zwięzłych stwierdzeń, które oddają istotę „wymagania”. Backlog to po prostu długa lista wpisów, z których każdy definiuje pojedynczy, dyskretny „wymaganie” jako historyjkę użytkownika. Od teraz będziemy używać słowa historyjka użytkownika, a nie „wymaganie”. Prawdopodobnie pytasz „dlaczego?” To dobre pytanie. Ponieważ wydaje się, że trwa wieczność, określenie funkcji lub aspektów potrzebnych w projekcie oprogramowania przez klienta zawsze było określane jako wymaganie. To słowo ma interpretację, która nie ma wartości w Agile. Słownik oksfordzki definiuje to jako:

Rzecz, która jest potrzebna lub pożądana. Lub rzecz, która jest obowiązkowa; warunek konieczny.

I niestety, jeśli zaczniemy określać, jakie powinno być nasze rozwiązanie, stwierdzając, że rzeczy są „obowiązkowe”, wpadniemy w kłopoty. Zbyt łatwo powiedzieć, że wszystkie te historyjki użytkowników są obowiązkowe. Jeśli przyjmiemy taki pogląd, ryzykujemy przekroczenie harmonogramu i budżetu, próbując dostarczyć cały dany zakres. Nie jest problemem stwierdzenie, że w przypadku tego produktu te historie są potrzebne, aby rozwiązanie było opłacalne, po prostu chcemy uniknąć interpretacji tego konkretnego słowa.

• Zawsze pisz historie z perspektywy osoby. Persona reprezentuje użytkownika lub interesariusza rozwiązania. Dobrym pomysłem jest rozwinięcie tych person, zanim zaczniesz robić zaległości.
• Na tym etapie pisz tylko krótkie, proste stwierdzenia, które zasadniczo sugerują przypomnienie o głębszej rozmowie na temat historii użytkownika, gdy nadejdzie odpowiedni czas.
• Prawdziwi ludzie myślą w kategoriach zadań, które muszą wykonać, aby osiągnąć cel. Pisz swoje historie z perspektywy osoby i pod kątem tego, co muszą zrobić.
• Nie musisz pisać pełnych zaległości — po prostu napisz tyle, ile możesz sobie wyobrazić, że Twoi klienci będą potrzebować, aby Twój produkt był opłacalny.
• Później, w trakcie użytkowania produktu, odkryjesz, że historyjki użytkowników ulegną zmianie, staną się mniej lub bardziej ważne lub można je całkowicie usunąć. Częste wypuszczanie, otrzymywanie informacji zwrotnych i ocenianie, co jest priorytetem, poinformuje o tym zachowaniu.
• Nie pisz opowiadań w odosobnieniu. Zaangażuj swój zespół, interesariuszy, a nawet klientów. Historie można aktualizować w dowolnym momencie życia projektu, ale należy unikać ich wprowadzania po rozpoczęciu prac rozwojowych.
• Niektóre z twoich historii mogą zostać uznane za „eposy”. Są to duże historie, które obejmują dużo i zostaną podzielone bliżej czasu dostawy na mniejsze historie.
• Rozważ użycie modelu INVEST, czyli listy kontrolnej służącej do sprawdzania jakości dobrej historyjki użytkownika.
• Każdy może dodać historię do zaległości. Powinien być umieszczony na dole lub na specjalnie stworzonym „parkingu”. Ta dodana historia służy jako zachęta do dyskusji z zespołem i firmą. Jeśli firma i zespół to wspierają, można to oszacować i uszeregować według priorytetów
• Możesz również rozważyć te części systemu, które są najbardziej ryzykowne. Jeśli masz historię użytkownika lub funkcję, która jest złożona, nowa lub technicznie nieznana, umieść je na szczycie listy zaległości. W ten sposób nie będziesz próbował dostarczać trudnych i krytycznych części swojego produktu na kilka tygodni przed pierwszym wydaniem.

Gdy masz zaległości, które spełniają Twoje potrzeby, możesz oszacować zawarte w nim historie, uszeregować je według priorytetów i zbudować plan wydania.

Szacowanie wysokiego poziomu i ustalanie priorytetów

Szacowanie wysokiego poziomu to proces określania wielkości zaległości. Jak „duży” jest projekt i jaką wartość dostarcza? Priorytetyzacja to proces decydowania, które historie są dla Ciebie najważniejsze, opłacalność produktu i zainteresowania Twoich klientów. Chcemy dostarczać produkty o najwyższej wartości jak najwcześniej, aby zapewnić jak największą wartość dla firmy, uzyskać informacje zwrotne od klienta i nie przejmować się drobiazgami. Wynikiem będzie uporządkowane zaległości, które są uszeregowane według priorytetu i odpowiednio zwymiarowane.

• Historie na górze są uważane za najcenniejsze. Chcemy jak najwcześniej dostarczać najcenniejsze przedmioty.
• Istnieje wiele technik określania rozmiaru i szacowania, ale w tym momencie chcesz tylko dobrze poznać rozmiar historii.
  • Użyj rozmiarów koszulek, rozmiarów względnych, idealnych dni lub punktów historii.
• W tym momencie również nie będziesz mieć wszystkich dostępnych informacji i to jest w porządku. Po prostu biegnij z tym.
• Zaangażuj interesariuszy biznesowych lub menedżera produktu, jeśli go masz, oraz zespół, który będzie wykonywał pracę.
• Chcemy, aby ci, którzy będą projektowali, rozwijali i testowali pracę, aby ją zwymiarowali, ponieważ najlepszymi ludźmi do oszacowania są eksperci.
• Zespół może zacząć dzielić historie na mniejsze części. Jeśli tak się stanie, napisz historie, które są bardziej szczegółowe, ale dyskretne.
• Zespół może również zacząć oceniać niektóre historie, ponieważ oczywiście niektóre rzeczy muszą zostać dostarczone przed innymi, aby wesprzeć technologię lub daną podróż użytkownika.
• Między tobą a zespołem możesz również zacząć znajdować dziury w zaległościach, które należy wypełnić. Po prostu wypełnij te dziury nowymi historiami i odpowiednio oszacuj i ustal priorytety.
• Priorytetyzacja jest najłatwiejsza przy użyciu analizy MoSCoW. MoSCoW to prosta technika, która pomaga zdecydować, które historie są „must have”, aby Twój produkt odniósł sukces.
• Możesz przeprowadzić nadawanie priorytetów przed rozpoczęciem szacowania. Jednak wielkość niektórych elementów może również decydować o priorytecie i rzeczywistej wartości biznesowej. Więc graj w szacowanie i ustalanie priorytetów, ale nie sprzeczaj się o to!
• Żadne dwie historie nie mogą być tak ważne jak druga. Historia na 1 miejscu jest ważniejsza lub bardziej wartościowa niż historia na 2 miejscu.
• Świetnym sposobem na zademonstrowanie wagi lub wartości historii jest dodanie do niej wartości pieniężnej. Jeśli na przykład uważa się, że historia A przyniesie dodatkowe 5000 USD, a historia B może przyciągnąć 100 USD, to historia A jest bardziej wartościowa. Podobnie, jeśli historia C ratuje firmę bardziej niż historia D, historia C jest bardziej wartościowa.
• Po ustaleniu rozmiaru zaległości pozostanie numer. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Praca w małych przyrostach daje ogromne korzyści. Oznacza to, że koncentrujesz się tylko na najbliższej przyszłości dostarczania, a dzięki nowym wkładom, informacjom zwrotnym i nauce możesz reagować na zmiany w krótkim, powtarzalnym cyklu.
• Na początku wydania wykonaj sprint 0. Pozwala to zespołowi, firmie i wydaniu projektu przygotować się i ustawić sposób myślenia na pomyślną dostawę. Narysuj podstawowe ramy techniczne i architekturę, które będą wspierać podstawę wydania. Skonfiguruj środowiska, konta i narzędzia. Wykonuj skoki, aby zrozumieć trudne lub nieznane problemy. Opracuj swoje historyjki użytkowników w gotowości do sprintu 1. Sprint 0 polega na przygotowaniu się.
• Podczas wydania dopracuj zaległości. Gdy zrozumiesz więcej lub nauczysz się czegoś nowego, Twoje priorytety mogą się zmienić, nowe wymagania mogą się rozwinąć, a to, co wcześniej uważałeś za świetną funkcję, może zostać całkowicie usunięte.
• Nie rozpoczynaj pracy, która nie ma szans na ukończenie w sprincie. Jeśli nie, podziel go na mniejsze kawałki. I nie rozpoczynaj nowej pracy, gdy poprzednio rozpoczęta praca nie została zakończona. Nie tworzysz żadnej wartości, rozpoczynając wiele rzeczy, których nie można uznać za kompletne. Ponadto unikaj przełączania kontekstu. Jest to czynność polegająca na rozpoczynaniu jednego zadania, przeszkadzaniu, rozpoczynaniu innego i, co jest najbardziej problematyczne, nie dokończeniu żadnego.
• Ogranicz ilość pracy wykonywanej przez zespół w dowolnym momencie. Na przykład, jeśli masz trzech programistów i jednego testera, możesz nałożyć limit WIP na programistów i testera.
• Nigdy nie dokładaj więcej pracy do sprintu po jego zaplanowaniu. Nigdy nie przerywaj sprintu w połowie. Wyjątkami od tego są:
  • Jeśli wykonałeś zadanie szybciej niż oczekiwano, rozważ wzięcie kolejnej historii z góry listy zaległości, o ile jest ona odpowiednio przygotowana.
  • Jeśli sprint wypada tak źle, że nie zostanie ukończony. Zwykle dzieje się tak tylko wtedy, gdy doszło do jakiejś katastrofy.
  • Jeśli cel sprintu nie może być dłużej wspierany ze względu na natychmiastowe zmieniające się potrzeby firmy.
• Jeśli anulujesz sprint, zrób to z wdziękiem, poświęć trochę czasu na ponowne skupienie się i rozpocznij nowy sprint tak, jak robiłbyś każdy inny.
• Pod koniec wydania rozważ sprint do ostatecznego wydania. Nie są pisane żadne nowe funkcje, niektóre błędy można usunąć i można poczynić przygotowania do faktycznego udostępnienia klientom nowej wersji produktu. Nie oznacza to, że w międzyczasie nie można wprowadzać przyrostowych wersji klientów — po prostu jest to kontrolowany, mierzony i zrównoważony mechanizm zwalniania.
• Pod koniec wydania możesz rozważyć tygodniowy sprint. W tym sprincie możesz współpracować z zespołem, aby przeanalizować kilka nowych pomysłów lub wymyślić nową technologię. Są to świetne narzędzia, które przynoszą korzyści firmie i dają zespołowi trochę miejsca na odprawę do myślenia i kreatywności. Nie służy do wygłupów i nadal będzie tworzyć wartość. Tak samo każdy potrzebuje przerwy. Wakacje w tym czasie pomagają utrzymać rytm i prędkość w dobrej formie, gdy jesteś w połowie zwolnienia.

Definiowanie Gotowe

Bardzo ważne jest zdefiniowanie, co naprawdę oznacza „zrobione”. W życiu projektu istnieje wiele wersji „ukończenia” — co to znaczy być „ukończonym” z historią, wydaniem lub całym projektem. Wszystko sprowadza się do tego, co Ty, Twój zespół i firma uznacie za kompletne, o odpowiednim poziomie jakości, aby zaspokoić gotowość do wysyłki.

Dla Twojego zespołu definicja „ukończonej” historii będzie przypominała ukończenie całego kodu, sprawdzenie przez innych, spełnienie zdefiniowanych kryteriów akceptacji, przetestowanie jednostkowe, poddanie UAT i przekazanie do repozytorium kodu. Aby umożliwić przekazanie historii od projektanta przez programistę do testera, definicje „ukończenia” będą musiały zostać zaakceptowane przez kolejną osobę w łańcuchu. Twój właściciel produktu będzie miał oczekiwania, co to dla niego oznacza, aby udostępnić przyrost produktu swoim klientom. W każdym razie każdy musi być świadomy tego, co oznacza „zrobione” i być stroną odpowiedzialną za spełnienie tego znaczenia. Zdefiniuj swoją definicję „zrobione”, przekaż ją, uzgodnij i rozwijaj. Gotowe gotowe.

Pomiar ciągły

Jeśli nie możesz tego zmierzyć, nie możesz tym zarządzać. To samo dotyczy ulepszeń. Potrzeba zebrania danych empirycznych w projekcie Agile jest prawie tak samo ważna, jak krążenie krwi w twoich żyłach! Skąd wiesz, co wymaga zarządzania, poprawiania lub ulepszania, jeśli nie ma danych? Mówiąc prościej, będziesz polegać na intuicji i bezpodstawnych domysłach, które dość szybko rozpadają się pod kontrolą. I w zależności od tego, kto przeprowadza analizę, może to być raczej niewygodne miejsce. Dlatego od samego początku projektu upewnij się, że wiesz, w jaki sposób zamierzasz zademonstrować postęp i jakimi miarami inni będą postrzegać Twój sukces.

Na szczęście Agile zawiera wiele przydatnych narzędzi i technik. Pierwszą rzeczą do zrobienia jest powrót do Manifestu Agile, wpisanie następujących słów do ulubionego edytora tekstu, powiększenie ich do 96 punktów, wydrukowanie i przyklejenie do ściany, aby wszyscy mogli je zobaczyć:

Twoją największą mocą do udowodnienia w dostarczaniu oprogramowania jest pokazanie go ludziom pracującym, robiącym to, co powinno. To nie tylko sprawi, że Twoi klienci będą szczęśliwi, ale także zdobędzie wielki szacunek dla Twojego zespołu i nasmaruje koła, aby uzyskać większą popularność w biznesie.

Oto kilka innych narzędzi:

• Codzienny standup: Istnieje kilka odmian tej ceremonii, ale istotą jest, aby wszyscy członkowie zespołu rozmawiali ze sobą twarzą w twarz: Niech będzie krótki, skupiony i lekki. Jeśli coś wymaga długiej dyskusji, zaparkuj to na dłuższą rozmowę między osobami potrzebnymi po stójce. Jeśli pojawiają się przeszkody, napisz je jak historię, dodaj je do swoich zaległości i zajmij się nimi jak najszybciej. Wszystko, co przeszkadza Twojemu zespołowi, spowalnia jego postępy i będzie można je zademonstrować przy zmniejszonej prędkości i oprogramowaniu, które nie spełnia oczekiwań.
• Velocity: jest narzędziem historycznym. To trochę jak te ostrzeżenia finansowe, które mówią, że wyniki w przeszłości nie są gwarancją przyszłych wyników. Ale w przypadku Agile mamy nadzieję osiągnąć prędkość zespołu, która będzie w dużej mierze płynna. To szybkość pozwala nam projektować przyszłe wyniki i wierzyć w nasze plany. Mogą istnieć wpływy poza twoją kontrolą, które mogą obniżyć liczbę punktów historii w danym sprintie. Jeśli tak się stanie, prawdopodobnie będziesz w stanie wyzdrowieć. Nigdy nie używaj prędkości jako kija do pokonania swojej drużyny; nie przyniesie ci żadnej łaski. Jedno jest pewne: prędkość będzie niestabilna przez pierwsze 2–4 sprinty. Jednak gdzieś w tym przedziale czasowym powinieneś zacząć dostrzegać spójność i stabilność. Jeśli twoja prędkość waha się od jednej skrajności do drugiej, masz problem, który musisz rozwiązać ze swoim zespołem.
• Wykres wypalania: Teraz ta miara postępu jest drażliwa. Z tego powodu nie podałem linku, aby dowiedzieć się więcej — będziesz musiał przeprowadzić własne badania i zgodzić się jako zespół i firma, która pracuje dla Ciebie. Powód, dla którego jest ciernisty? Cóż, żaden zasób nie opowiada tej samej historii! Jedno uzgodniono, że pokaże, w trakcie sprintu lub zwolnienia, jak radzisz sobie z czasem. Jeśli jest aktualizowany codziennie, pokaże, czy jesteś na dobrej drodze, czy zbaczasz. Niektóre zespoły używają go do przedstawienia, ile wartości pozostało do wytworzenia, częściej niż nie, inne używają go do pokazania, ile pracy pozostało do wykonania. Pierwszy to święto sukcesu i tworzenia wartości, drugi jest mniej inspirujący i motywujący.
• Wykres wypalenia: Jeśli musisz pokazać wskaźniki ukończenia pracy, użyj do tego wykresu wypalenia. Ale użycie wykresu wypalenia pozwala pokazać, jaka wartość została stworzona i o ile większą wartość planujesz stworzyć do końca sprintu. O wiele bardziej motywujące narzędzie dla zespołu, aby zarówno zademonstrować firmie, co zostało zrobione (lub niewiele, jeśli sprawy nie idą tak dobrze…), jak i co wciąż mają przed sobą. W każdym razie użyj wykresów, aby zauważyć, gdzie postęp nie jest śledzony zgodnie z oczekiwaniami, poszukaj wzorców lub odchyleń i przejdź do nich, aby jak najszybciej naprawić podstawowy problem. Aktualizuj je codziennie dla sprintów i raz na koniec sprintu, aby zobaczyć wykresy wersji wydawniczych.
• Tablice zadań: są to świetne promienniki wizualne do pokazania tworzonej wartości. Gdy są aktualizowane codziennie lub w dowolnym momencie dnia, natychmiast pokazują postęp. W połączeniu z Kanbanem są również świetnymi narzędziami do wizualizacji przepływu i blokad w systemie. Jeśli widzisz, że wiele prac programistycznych zostało ukończonych, ale testowanie nie jest tak produktywne, możesz zobaczyć, jak pojawia się problem i odpowiednio i szybko zareagować.

Inne narzędzia do rozważenia to wypracowana wartość Agile, czas cyklu i skumulowane diagramy przepływu (CFD).

Utrzymuj te miary, wykresy i inne narzędzia widoczne, najlepiej głośno i dumnie na ścianie, aby wszyscy mogli je zobaczyć. Zespół, interesariusze i inne zainteresowane strony mogą natychmiast zobaczyć status projektu. Jest przejrzysty i służy jako cenne narzędzie komunikacji. Jeśli nie możesz umieścić tych artefaktów na ścianie, użyj narzędzi, które można udostępniać i współpracować, i upewnij się, że mają je osoby, które chcą uzyskać dostęp.

Ciągłe doskonalenie

Przez całe życie Agile staraj się identyfikować i uczyć się, gdzie można wprowadzić ulepszenia. Lekcje nie są przechwytywane i wyciągane na koniec projektu. To jak zdanie egzaminu na prawo jazdy i wstępne odbycie pierwszej jazdy bez instruktora. Będziesz wiedział, co działa i co masz robić, ale z czasem dostosujesz swoje umiejętności i możliwości jazdy, ucząc się nowych technik. Nabierzesz nawet złych nawyków. Poszukaj ich, zrozum je i znajdź sposoby na poprawę.

Istnieje wiele możliwości zidentyfikowania tego, co nie działa i zastosowania środków zaradczych. Wbudowane podejście do tego w Agile to retrospektywa. Jest to podstawowe narzędzie do refleksji i dostosowania. Pod koniec każdego sprintu poświęć czas z zespołem na poprawę sposobu wykonywania pracy, dostarczania jakości, maksymalizacji wydajności, minimalizowania odpadów i zwiększania wydajności. Kiedy określisz środki do poprawy, nie ulegaj pokusie, aby od razu naprawić wszystkie swoje problemy. Zidentyfikuj te, które będą miały największy wpływ i które można wdrożyć w następnym sprincie. Mierz i obserwuj. Jeśli przyniosło to pożądany efekt, zamknij to, zapisz to w swoich sposobach pracy i definicjach ukończenia. Jeśli to nie zadziała, pomyśl jeszcze raz. Wszelkie wyciągnięte wnioski, które nie zostaną wprowadzone do nadchodzącego sprintu, można zaparkować i nadać im priorytet w następnym sprincie.

Dostosuj proces. Usuń wszystko, co nie działa. Usuń przeszkody. Twoja dojrzałość jako zespołu Agile nie będzie miała granic, jeśli na to pozwolisz.

Poza zwinnym zarządzaniem projektami

Ważne jest, aby wiedzieć, co dzieje się po dostarczeniu projektu. Wsparcie i konserwacja są kluczem do zapewnienia, że ​​projekt, który znajdzie się w rękach klientów, pozostanie wydajny; opinie klientów można uwzględnić w przyszłych wydaniach; a problemy klientów są odpowiednio rozwiązywane. Projekt to wyjątkowe, ograniczone czasowo przedsięwzięcie. Produkt, który dostarcza, żyje po rozwiązaniu zespołu projektowego. Upewnij się, że jesteś w stanie obsługiwać produkt po jego uruchomieniu.

Projekty zwinne współistnieją z bardziej tradycyjnymi podejściami. Równoważenie wymagań dotyczących kontroli budżetowej i widoczności interesariuszy z celami Agile, jakimi są elastyczność i responsywność.

Struktura zarządzania lub model zarządzania Agile jest używany w połączeniu ze standardowymi procesami Agile, takimi jak Scrum. Działają na dwa specyficzne sposoby:

• Zapewniają opakowanie dla projektu Agile, wyjaśniając procesy, które występują poza iteracjami programistycznymi (sprintami). Obejmuje to zapewnienie jasnych kryteriów pomyślnego zakończenia inicjacji projektu i właściwej walidacji decyzji i planu.
• Przenoszą nacisk na określone części standardowego procesu Agile i podkreślają konkretne zasady i techniki, które wymagają zarządzania lub wspierają zarządzanie.

W dzisiejszym, ciągle zmieniającym się świecie, organizacje i firmy chętnie przyjmują bardziej elastyczne podejście do realizacji projektów i chcą stać się bardziej zwinne. Jednak dla organizacji realizujących projekty i programy oraz tam, gdzie istnieją już formalne procesy zarządzania projektami, nieformalność wielu podejść Agile jest zniechęcająca i czasami postrzegana jako zbyt ryzykowna. Te skoncentrowane na projektach organizacje potrzebują dojrzałego podejścia zwinnego — zwinności w ramach koncepcji realizacji projektu — zwinnego zarządzania projektami .

Ucz się i rozwijaj dzięki zastosowaniu Agile. Zawsze rób tylko to, z czym Twój zespół czuje się komfortowo, upewnij się, że jego głos jest słyszany i postępuj zgodnie z jego prośbami. Zachęć swój zespół do przyjęcia nowych i bardziej wartościowych technik we właściwym czasie. Negocjuj z biznesem i zachęć ich do zrozumienia, co to znaczy być organizacją zwinną.

Miłej podróży.