Przeskocz do treści

Agile i jego manifest

Rozpocząłem prace nad projektem kończącym mój kurs w Coderslab, chcę aby pod każdym względem był jak najlepszy pokazując, że nie tylko kodowanie trochę ogarniam 😀 ale też orientuję się w środowisku dookoła kodowania. Może o samym projekcie w innych wpisach teraz skąd i po co Agile? Jednym z problemów a może jednym z wyzwań jest dokumentacja i rozpisanie założeń. Podczas kreatywnych rozmów pojawiło się zagadnienie metodologii jaką jest Agile i tutaj chciałem sobie wypisać te zasady aby szybko do nich wrócić i z nimi pracować.

Manifest (Agile) Zwinnego Programowania

Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić:

Ludzi i interakcje od procesów i narzędzi

Działające oprogramowanie od szczegółowej dokumentacji

Współpracę z klientem od negocjacji umów

Reagowanie na zmiany od realizacji założonego planu.

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

 

 

Założenia Manifestu Programowania Zwinnego

Wyznajemy następujące zasady:

Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.

Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.

Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.

Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.

Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.

Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.

Działające oprogramowanie jest podstawową miarą postępu.

Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.

Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.

Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.

Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.

W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

 

Z zasad zaznaczyłem sobie te, które bardziej dotyczą bezpośrednio mojego projektu ponieważ jedynym zespołem na razie jestem ja sam. Jak to ma się przełożyć na wykonanie projektu? Po pierwsze praca w krótkich iteracjach czasu (ogólnie zespół powinien w tym samym czasie wykonywać wszystkie czynności - projektowanie, kodowanie, testowanie), które mają się zakończyć nawet jak funkcjonalność ma być skasowana.

Planowanie - a dokładnie "cebula planowania" jak to cebula ma kilka warstw, zespół zainteresowany jest tylko trzema wewnętrznymi - Wydanie -> Iteracja - Dzień. W planowaniu wydania są historyjki użytkownika (user story) lub motywy.  Podczas planowania iteracji mówimy o zadaniach, które będą wymagane do tego, aby przekształcić żądanie funkcjonalności w działające i przetestowane oprogramowanie. Planowanie dnia ma zawęzić planowanie zadań do realizacji do następnego dnia.

Wnioski:

  • pracuję w określonych odstępach czasu,
  • funkcje programu realizuję stosując historyjek użytkownika,
  • po każdej iteracji mam gotowy program,
  • weryfikuję każdą funkcjonalność, wymaganą jako priorytetową na tym etapie,
  • jestem elastyczny co do zmian.

Dalszy etap to przyjrzenie się Scrumowi.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.