Manifest Agile: 4 podstawowe wartości i 12 zasad wyjaśnionych

Obrazek poniżej pochodzi z strony internetowej Manifestu Agile i pokazuje cztery stwierdzenia wartości Agile.

Agile Manifesto and the 4 Agile Values answer what agility is

Jak widać w przesłowiu do wartości, autorzy stwierdzają, że odkrywali lepsze sposoby tworzenia oprogramowania i pomagania innym. Wszystkie wartości są ważne, ale te po lewej stronie mają priorytet przed tymi po prawej.

Ludzie i interakcje powyżej procesów i narzędzi

Jak już wspomniano, gdy został opublikowany Manifest Agile, wyzwał on metodyki ciężkie. Model dojrzałości kompetencji (CMM) i ITIL były popularnym trendem w kierunku podejść skupionych na procesach w tamtym czasie.

Dlatego było zaskakujące, że ci liderzy myślenia zdecydowali się zacząć od ludzi. Uważali, że znalezienie odpowiednich osób (osób) w zespole i pomaganie im skutecznie współpracować (interakcji) jest znacznie ważniejsze niż ślepe przestrzeganie konkretnego procesu i/lub używanie określonych narzędzi. Dlatego postawili nacisk po lewej stronie: ludzie i interakcje.

Działające oprogramowanie powyżej kompleksowej dokumentacji

W tradycyjnej lub kaskadowej metodologii tworzenia oprogramowania zespoły poświęcały znaczny czas na zbieranie wymagań i tworzenie projektów oraz specyfikacji, budując coś rzeczywistego dopiero na końcu cyklu życia. Autorzy manifestu uważali, że posiadanie działającego rozwiązania jest bardziej wartościowe niż posiadanie dużej ilości dokumentów opisujących, jak działa rozwiązanie.

Współpraca z klientem powyżej negocjacji umowy

Trzecią wartością jest współpraca z klientem powyżej negocjacji umowy — gdzie negocjacje umowy oznaczają spory o to, co zawarte jest w zakresie. Na przykład możesz usłyszeć zdania typu „To nie było w Twoim dokumencie wymagań”. Ci liderzy myślenia uważali, że współpraca z klientami w celu dostarczenia rozwiązania, które naprawdę potrzebują, jest znacznie ważniejsza.

Reagowanie na zmiany powyżej ślepego przestrzegania planu

Czwartą i ostatnią wartością Agile jest reagowanie na zmiany powyżej ślepego przestrzegania planu. Autorzy zgadzają się, że planowanie jest ważne — w rzeczywistości zespoły Agile dużo planują. Ale ci liderzy myślenia uważali, że zdolność do reagowania na nieuniknione zmiany jest ważniejsza niż trzymanie się planu stworzonego na początku projektu, gdy informacje są jeszcze ograniczone.

Wszystkie te wartości w manifestzie są ważne, ale te po lewej stronie mają wyższy priorytet niż te po prawej.

12 zasad Agile

Oprócz tych 4 wartości Agile, autorzy Manifestu Agile zgodzili się na zestaw 12 zasad Agile, które stanowią fundament podejść Agile. Choć mniej znane niż 4 wartości Agile, uważam, że 12 zasad Agile jest bardziej praktycznych i oferuje jasniejsze wskazówki dla praktyk Agile.

12 Agile Principles behind the Agile Manifesto

Zgodnie z wygodą, ponumerowałem 12 zasad, choć na oficjalnej stronie internetowej.

  1. Pierwszą zasadą jest najwyższy priorytetto zaspokojenie klienta poprzez wczesne i ciągłe dostarczanie wartościowego oprogramowania. Słowo „wartościowe oprogramowanie” może być mylące. Pamiętaj, że w 2001 roku, gdy ci liderzy wprowadzili wartości i zasady Agile, skupiali się wyłącznie na tworzeniu oprogramowania. Od tego czasu Agile został przyjęty w prawie każdej branży — architekturze, produkcji samochodów, nawet produkcji samolotów bojowych. Jeśli to dla Ciebie bardziej sensowne, zastąp „wartościowe oprogramowanie” słowem „wartościowe rozwiązanie”.
  2. Drugą zasadą jest witamy zmieniające się wymagania, nawet na późnym etapie rozwoju. Choć większość ludzi dziś skupia się na kontroli zmian lub zarządzaniu „rozrostem zakresu”, rzeczywistość mówi, że zmiany są nieuniknione. Procesy agilne odkładają decyzje, skracają cykle rozwoju i wspierają szybką analizę żądań. Pozwala to zespołom agilnym szybko się dostosować i to z niskim kosztem. Daje to przewagę konkurencyjną i jest jednym z kluczowych filarów pracy agilnej.
  3. Trzecim zasadą jest często dostarczać gotowe oprogramowanie, od kilku tygodni do kilku miesięcy, najlepiej z krótszymi okresami. Jednym z głównych korzyści częstego dostarczania jest uzyskanie opinii, aby upewnić się, że idziesz w dobrym kierunku i naprawdę budujesz to, czego potrzebuje klient.
  4. Czwartą zasadą agilną jest działanie razem ludzi biznesowych i programistów każdego dnia przez cały projekt. Dzisiaj przedstawiciele interesów biznesowych często tworzą dokumenty wymagań i „rzucają je przez mur” do programistów. Miesiące lub nawet lata później programiści dostarczają rozwiązanie zleceniodawcy do ostatecznego testowania — by odkryć, że rozwiązanie zostało źle zrozumiane, błędnie zbudowane lub już nie jest potrzebne. Nacisk tej zasady leży na współpracy między tymi, którzy budują rozwiązanie, a tymi, którzy go używają, aby uniknąć takich wyników.
  5. Piątą zasadą agilną jest budować projekty wokół motywowanych osób, zapewniając im środowisko i wsparcie, które potrzebują, i uznając ich za zdolnych do wykonania zadania. Jest to zasadniczo podejście trzykrotnie złożone: uwalnianie ludzi, nadawanie im autonomii i uznawanie ich za zdolnych do działania.
  6. Szóstą zasadą agilną jest utrzymywalny rozwój. Sponsory, programiści i użytkownicy powinni móc utrzymywać stały temp o nieustannie. Kiedy pierwszy raz pracowałem nad projektami technologicznymi, trwały one często 6 miesięcy, 12 miesięcy lub dłużej. Było powszechne, że w pierwszych tygodniach lub miesiącach osiągano niewiele. Niezbyt zaskakujące, że to prowadziło do ogromnych okresów „przyśpieszenia” na końcu, kiedy trzeba było ukończyć ogromne obciążenia. Członkowie zespołu oczekiwano, że będą pracować wieczorami lub w weekendy, by spełnić ustalone terminy i zakresy. To nazywane jest projektem „marszu śmierci”. Agile nie mówi, że nigdy nie będziesz pracował wieczorami lub w weekendy — ale podkreśla, że każdy powinien pracować w utrzymywalnym tempie.
  7. Zasada siódma mówi, że gotowe oprogramowanie jest podstawowym wskaźnikiem postępu. Tradycyjnie do śledzenia postępu projektu używano procentu ukończenia. Procent ukończenia jest bardzo niepewny, ponieważ trudno go ocenić, zwłaszcza gdy osiąga 80% lub 90%. Ukończenie na 90% często oznacza, że pozostało tylko 10% wysiłku lub czasu. Zespoły agilne unikają procentu ukończenia, dzieląc pracę na funkcje lub możliwości, dzieląc je na małe fragmenty i śledząc, czy te fragmenty zostały ukończone. To podejście unika mylących metryk postępu.
  8. Ósmą zasadą jest to, że najskuteczniejszym i najefektywniejszym sposobem przekazywania informacji do zespołu programistów i w obrębie zespołu jest rozmowa twarzą w twarz. Dzisiaj najpopularniejszym narzędziem komunikacji może być e-mail. Jest on wydajny dla nadawcy — przecież może wysłać wiadomości setkom lub tysiącom osób naraz. Ale to nie jest prawdziwa komunikacja. Badania pokazują, że czytanie tekstu kogoś innego pozostawia znaczne pole do nieporozumień. Przywódcy agilni nauczyli się, że prawdziwe zrozumienie wspólne wymaga zjednoczenia ludzi. Jeśli rozmowa twarzą w twarz nie jest możliwa, należy użyć najbardziej przepustowego środka komunikacji — może to być rozmowa wideo lub telefoniczna. To znacznie lepsze niż publikowanie dokumentów na SharePoint! Wnioskiem jest korzystanie z najbardziej przepustowego kanału komunikacji. Jednym z efektów ubocznych uprawiania rozmów twarzą w twarz jest sensowność skupienia członków zespołu agilnego w jednym miejscu. Dzisiaj wiele organizacji ignoruje to wydawać się oczywiste.
  9. Zasada dziewiąta to ciągłe skupienie się na doskonałości technicznej i dobrym projektowaniu w celu zwiększenia elastyczności. Nacisk kładzie się na unikanie skrótów lub zadłużenia technicznego. Nie robić tego, co w krótkim okresie przyspiesza, ale kosztuje więcej w dłuższej perspektywie. Jeśli będziecie ciągle gromadzić zadłużenie techniczne, stracicie elastyczność. Jest to powszechne w projektach wodospadowych z ustalonymi terminami. Aby spełnić obietnice terminów, skracane są procedury. Cykle testowania mogą być skrócone lub całkowicie usunięte, by zaoszczędzić czas, co prowadzi do większych problemów w produkcji po uruchomieniu. Wynikiem jest walka z awariami i kod, który trudno utrzymywać.
  10. Zasada dziesiąta dotyczy uproszczenia rzeczy i eliminacji niepotrzebnej pracy. Prostota — sztuka maksymalizacji ilości niezrobionej pracy — jest kluczowa.To znaczy, powinniśmy przeanalizować nasze procesy i usunąć wszystko, co nie przynosi wartości klientowi, tym samym maksymalizując ilość niezakończonej pracy, jednocześnie dostarczając to, co jest potrzebne.
  11. Zasada dziesiąta dotyczy również zespołów samodzielnie organizujących się. Najlepsze architektury, wymagania i projekty pochodzą z zespołów samodzielnie organizujących się. Powinniśmy pozwolić tym, którzy są najbliżej pracy, na decyzję, jak najlepiej ją wykonać — to jest esencja tej zasady.
  12. Ostatnią zasadą, numer 12, jest retrospektywa. Zespoły regularnie analizują, jak stać się bardziej skutecznymi i potem dostosuj i przystosuj ich zachowanie odpowiednio.

Wartości i zasady Agile mogą dziś nie wydawać się rewolucyjne, ale gdy zostały ogłoszone w 2001 roku, były naprawdę rewolucyjne. Dlatego właśnie termin „Manifest”. Wskazały sposób pracy, który całkowicie różnił się od tego, jak organizacje działały w poprzednim stuleciu. Przedtem rozwój oprogramowania głównie odzwierciedlał praktyki pracy z eras przemysłowej. Zrozumienie tego kontekstu historycznego jest kluczowe, jak zostanie omówione poniżej.

 

 

Leave a Reply