1

Manifest Programowania Zwinnego


Zdaję sobie sprawę, że nie wszyscy z Was programują. Możliwe, że tytuł nie zaciekawi Was, a może nawet odstraszy. Proszę, nie uciekajcie. Manifest Programowania Zwinnego nie jest przeznaczony tylko dla programistów. Nie tyczy się on tylko świata IT. Moim zdaniem, można wykorzystać go w wielu innych obszarach, począwszy od własnego, prywatnego życia, a skończywszy na biznesie. Postaram się przekazać Wam przydatną wiedzę pochodzącą ze świata IT. Poniżej przedstawiam Manifest Programowania Zwinnego oraz jego dwanaście zasad. Zapraszam do lektury.

Manifest Programowania Zwinnego

W 2001 roku spotkało się siedemnaście osób ze świata IT reprezentujących niekaskadowe podejście do tworzenia oprogramowania, m.in. Scruma, Programowania Ekstremalnego, Adaptive Software Development, Crystal Clear, Pragmatic Programming, Dynamic Systems Development Method. Zebrali oni swoje doświadczenia z tworzenia programowania i napisali Manifest Agile. Zawarli w nim cztery tezy. Twórcy podkreślają, że elementy z lewej strony poniższych stwierdzeń są ważniejsze od tych z prawej (które również są istotne).

Twórcy manifestu zapisali w nim, że cenią bardziej:

  • 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.

Innymi słowy, to ludzie i relacje między nimi są najważniejsze. Czy to w biznesie, czy w domu, to właśnie oni są na pierwszym miejscu. W końcu nie współpracujemy z umową prawną, programem komputerowym czy misją organizacji, tylko żywymi ludźmi. Twoim głównym celem jest zaspokojenie potrzeb klientów. Działający produkt jest dla klienta najważniejszy, nie interesuje go dokumentacja i procedury, które masz narzucone. A w jaki sposób najlepiej jest poznać potrzeby klienta? Trzeba z nim dużo rozmawiać, pokazywać mu, w którą stronę zmierza projekt, uwzględniać zmiany w jego wymaganiach i współpracować. Jakie jest prawdopodobieństwo, że klient powie nam, że produkt, który dla niego zrobiliśmy, nie jest tym, czego oczekiwał, gdy często i regularnie pokazywaliśmy mu kolejne wersje produktu?

Dwanaście zasad Manifestu Programowania Zwinnego

Tamtego dnia powstała również lista zasad, którymi powinno się kierować podczas produkcji oprogramowania. Postaram się przełożyć ją na trochę ogólniejszą materię, aby mogła przydać się nie tylko programistom.

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

W swoich pracach skup się na tym, aby zadowolić swojego klienta. To jest najważniejsza rzecz. Możesz to osiągnąć przez regularne i częste dostarczanie mu wartościowych rzeczy.

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

Zastanawiałeś się po co w ogóle robisz konkretne zlecenie klienta? Jaki jest tego cel? Jeśli Twoją odpowiedzią jest, że robisz to po to, aby zadowolić klienta, to musisz sobie uświadomić, że zmiany będą chlebem powszednim. Czy to dobrze? Moim zdaniem bardzo dobrze. Klient oraz jego otoczenie cały czas się zmieniają. Tak samo powinien ewoluować projekt, aby Twój produkt był zawsze konkurencyjny.

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

Częste ocenianie przez klienta postępów w rozwoju pozwala na lepsze dopasowanie się do potrzeb klienta oraz zmniejszenie przypadków, gdy robimy coś niepotrzebnie lub w zły sposób. Staraj się zbierać możliwie jak najwięcej informacji zwrotnych od klienta oraz omawiaj każdą swoją wątpliwość. Pomoże Ci to zminimalizować nakłady pracy oraz lepiej spełnić jego oczekiwania.

Doświadczyłeś w swoim życiu remontu mieszkanie, w którym żyjesz? Ten właśnie przypadek, wykańczania mieszkania, pokazuje, jak bardzo ważne jest częste pokazywanie klientowi postępów w pracach. Równie ważne jest też częste omawianie i specyfikowanie wizji produktu. Późne spostrzeżenie przez klienta, że dostarczony produkt nie jest tym, czego oczekiwał, bywa bardzo kosztowne. W zależności od ustaleń, kosztami może zostać obarczona jedna bądź druga strona. Dużo lepiej jest jednak dokładnie precyzować wymagania i poddawać do oceny prototypy.

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

Wymagania klienta możesz poznać tylko w jeden sposób: komunikując się z nim. Im częściej będziesz to robił, tym lepiej. Pamiętaj, że nie liczy się tylko częstotliwość kontaktów, ale również ich jakość. Każdy z nas korzysta z trochę innego języka, ma różne doświadczenia i inaczej pojmuje świat. Poświęć trochę czasu i energii na zrozumienie swojego klienta, jego wizji i pragnień.

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

Zadbaj o środowisko pracy. Spraw, aby ludzie oraz Ty chcieli tworzyć dany produkt. Nie pozwól, aby większość energii była przeznaczana na rozwiązywanie nieistotnych problemów, jak np. zbyt niska temperatura w pomieszczeniu. Stwórz środowisko, w którym energia ukierunkowana będzie na dostarczenie produktu o wysokiej jakości.

Tę zasadę można znaleźć również w słowach Richarda Bransona:

,,Jeżeli zadbasz o swoich pracowników, oni zadbają o twoich klientów’’.

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

Spotkania twarzą twarz, niekoniecznie całego zespołu, to najlepszy sposób na przekazanie informacji. Takie spotkania pozwalają wzmocnić więzi, zwiększyć poczucie odpowiedzialności, spersonalizować swój przekaz, pokazać ludzką naturę. Można do tego skorzystać z narzędzi informatycznych. Nie można jednak przesadzić i spotykać się za każdym razem, aby porozmawiać o każdym detalu. Jak we wszystkim, w tym również należy znaleźć złoty środek.

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

Powiem krótko: klienta nie obchodzi, ile dokumentacji napisaliśmy, czy ile szkoleń przeszliśmy. Klienta obchodzi produkt, który przynosi mu korzyści.

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

Równe tempo pracy pozwala łatwiej przewidywać przyszłość związaną z produkcją. Daje również poczucie bezpieczeństwa pracownikom oraz poczucie stabilności użytkownikom. Praca podobna do jazdy na kolejce górskiej może być pasjonująca, ale na dłuższy okres nie jest zdrowa. Ciągła niepewność oraz duża ilość silnych emocji powodują stres, który negatywnie wpływa na nas samych, naszą pracę oraz nasze otoczenie.

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

Dobrze zaprojektowany program komputerowy jest z założenia przygotowany na modyfikacje. Prowadząc projekt zwracaj również uwagę na możliwość zmian. Staraj się przewidywać wymagania klientów. Nie rób jednak tego, aby je od razu wdrożyć w życie, lecz aby przygotować się do niespodzianek i działać proaktywnie, np. rozmawiając o swoich prognozach z klientem.

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

Klient zazwyczaj potrzebuje czegoś prostego, ale skutecznego. Fontanny i wodotryski są ładne, ale często są zbędne. Po co zatem robić coś, co jest niepotrzebne? Czy ktoś Ci za to zapłaci? Zapytaj i wybadaj najpierw, czy powinieneś coś robić. Nie staraj się robić czegoś na zapas, bo może komuś się to przyda. To podejście jest zbyt kosztowne.

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

Daj ludziom przestrzeń do pracy, przekaż im część obowiązków oraz pozwól im realnie wpływać na produkt. Zespoły, które mogą kierować same sobą, mające świadomych członków, tworzą bardzo dobre produkty. Nie ograniczaj siebie i swoich pracowników. Nie twórz barier, lecz likwiduj je.

12. 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.

Dwóch kucharzy chciało zmierzyć, który z nich pokroi więcej warzyw w przeciągu trzech ośmiogodzinnych dni pracy. Zaczęli o godzinie 8 rano i zawzięcie kroili warzywa przez kolejne cztery godziny. Po tym czasie jeden z kucharzy wyszedł z pomieszczenia mówiąc, że potrzebuje godzinnej przerwy. Drugi kucharz zdziwił się tym bardzo, ale nie przestał pracować. Po godzinie pierwszy kucharz wrócił i znowu zaczął kroić. O godzinie szesnastej zmęczeni kucharze poszli do domu, aby nabrać sił. Drugiego dnia historia powtórzyła się, tzn. pierwszy kucharz o godzinie dwunastej zrobił sobie godzinną przerwę. Dzień trzeci i ostatni wyglądał identycznie. Z tą różnicą, że o godzinie szesnastej zostały zważone warzywa obu kucharzy. Wygrał pierwszy kucharz, ten, który robił sobie przerwy. Zdziwiło to bardzo drugiego kucharza. Zapytał więc, jak to jest możliwe, że, pomimo iż tamten kroił o całe trzy godziny mniej, to jednak wygrał zawody. Co takiego zrobił ten kucharz w przerwie? Pierwszy kucharz zdradził swoją tajemnicę: w czasie przerwy ostrzył swoje noże. Pozwoliło mu to wydajniej pracować.

Zadbaj o to, abyś Ty oraz Twój zespół miał chwile refleksji nad sposobami wytwarzania. Dobre pomysły pozwalają zaoszczędzić duże ilości czasu i pieniędzy. Nie rezygnuj z tego.

Podsumowanie

Powyższy manifest oraz zasady zostały stworzone przez ludzi tworzących oprogramowanie. Wiele z nich jest jednak bardzo uniwersalnych i można je stosować w wielu gałęziach produkcji oraz usług. Ja sam dostrzegam zastosowanie powyższych informacji w moim życiu oraz w kierowaniu projektami. Sami musicie przyznać, że projekt aplikacji komputerowej jest tylko specyficznym projektem.

 

 

Źródła:

https://pl.wikipedia.org/wiki/Manifest_Agile
https://en.wikipedia.org/wiki/Agile_software_development#The_Agile_Manifesto
http://agilemanifesto.org/iso/pl/manifesto.html
http://agilemanifesto.org/iso/pl/principles.html
https://www.virgin.com/richard-branson/georgia-on-my-mind