Dwanaście zasad zwinnego wytwarzania oprogramowania to dopełnienie Agile Manifesto. Przedstawiają one dokładniej założenia, którymi kierował się zespół Agile Alliance podczas tworzenia manifestu. Agile Manifesto nie istnieje bez poniższych zasad. To one mają nam pomóc zrozumieć deklarację i podążać przy wytwarzaniu oprogramowania zgodnie z jej założeniami. Zasady Agile Manifesto zebrałam w mniejsze grupy, żeby podkreślić ich sens.
Zadowolony klient
Pracując w środowisku zwinnym musimy mieć na względzie dla kogo tworzymy produkt. Po drugiej stronie, oprócz użytkowników końcowych, zawsze jest klient. Bez znaczenia jest to czy pełni tę rolę wewnątrz organizacji, czy poza nią. Najważniejsze jest jego zadowolenie, i to czy produkt spełnia postawione przed nim oczekiwania i założenia. Warto pamiętać, że to klient jest pomysłodawcą, sponsorem i maksymalizatorem wartości wytwarzanego produktu. Zwykle jest też to osoba posiadająca szeroką wiedzę w branży, więc pewnie wie, co dla jego produktu będzie dobre.
Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
Zasada ta reprezentuje pierwszy i trzeci punkt Agile Manifesto: Ludzie i interakcje ponad procesy i narzędzia, oraz Współpraca z klientem ponad negocjacje umów.
Moim zdaniem nieodłącznym elementem stanowiącym o zadowoleniu klienta jest wsparcie go w tworzeniu konkurencyjnego produktu. Czasem wiąże się to ze zmianą priorytetów, a czasem tylko z drobnymi zmianami w wymaganiach. Pracując jednak w krótkich pętlach informacji zwrotnej jesteśmy w stanie uniknąć tworzenia zbędnych czy małowartościowych części produktu. Mam na myśli sytuację, w której pracujemy nad funkcjonalnością X, ale nagle okazuje się, że nie przewidzieliśmy pewnych scenariuszy. Być może jest zbyt dużo edge case’ów i tak naprawdę z biznesowego punktu widzenia dalsza implementacja tej funkcjonalności nie przyniesie nam oczekiwanej wartości. Warto wtedy zaufać Product Ownerowi, czy też klientowi, który decyduje się na podjęcie takiej decyzji. Jako eksperci powinniśmy umieć mu doradzić, w jaki sposób zatrzymać pracę, by nie utracić aktualnych postępów i być może w przyszłości móc wrócić do wdrażania zmian. O tym mówi kolejna zasada Agile Manifesto:
Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
Zasada ta reprezentuje czwarty punkt Agile Manifesto: Reagowanie na zmiany ponad realizację założonego planu.
Częstotliwość wdrożeń ma wpływ na jakość produktu
W tym akapicie znajdziecie kolejne dwie zasady Agile Manifesto. Mówią one o krótkich iteracjach, podczas których dostarczamy produkt potencjalnie gotowy do wydania lub wydajemy go, a także o stałości i równym tempie pracy.
Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
Dzięki takiemu podejściu możemy wyróżniać się na tle konkurencji, zaspokajając potrzeby użytkowników końcowych szybciej niż inni. Dostarczając zmiany w krótkich odstępach czasu jesteśmy w stanie stworzyć produkt wyższej jakości, bardziej dostosowany do potrzeb naszych odbiorców. Częściej pytając o feedback możemy szybciej reagować na zmiany i adaptować produkt do potrzeb. To co robi zespół pracujący zgodnie z zasadami Agile Manifesto, to w regularnych odstępach czasu analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków. Ta zasada świetnie wspiera drugi punkt Agile Manifesto: Działające oprogramowanie ponad szczegółową dokumentację.
Kolejnym, szalenie ważnym aspektem jest równe tempo pracy:
Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
Dzięki utrzymaniu podobnych, w idealnym świecie równych, pętli informacji zwrotnej jesteśmy w stanie jeszcze bardziej zmaksymalizować wartość dostarczanego produktu. Podążając znanym schematem, dostosowanym do naszych potrzeb jesteśmy w stanie zminimalizować ilość zależności, i ich wpływu na jakość produktu. Moim zdaniem ta zasada doskonale wspiera trzeci i czwarty punkt Agile Manifesto: Współpraca z klientem ponad negocjacje umów oraz Reagowanie na zmiany ponad realizację założonego planu. Równe pętle zwrotne pomagają nam usystematyzować działania, reagować i adaptować zaplanowaną pracę. Ważne by wspomniane ramy, w których się poruszamy były stosunkowo krótkie, dostosowana do wielkości projektu, ilości osób które nad nim pracują. Pozwala to na efektywniejszą komunikację, a co za tym idzie elastyczność względem pierwotnego planu pracy.
Współpraca i komunikacja
W tym rozdziale zebrałam aż cztery zasady. Wszystkie one kojarzą mi się z bardzo ważnym aspektem, nie tylko związanym z pracą, ale z tym co przysparza nam wiele wyzwań również w życiu prywatnym. Komunikacja, bo to o niej mowa, jest często kluczem do sukcesu wielu projektów i produktów. Bez dobrej komunikacji nie ma mowy o efektywnej współpracy. Wszystkie poniższe zasady odnoszą się do pierwszego i trzeciego punktu Agile Manifesto: Ludzie i interakcje ponad procesy i narzędzia oraz Współpraca z klientem ponad negocjacje umów.
Przyjrzyjmy się pierwszej zasadzie:
Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
Bez współpracy ubranej w konkretny scenariusz, bez umiejętnego planowania kolejnych kroków realizacji założonej wizji, ciężko jest osiągać oczekiwane efekty w określonych ramach czasowych. Dzięki częstej komunikacji i codziennej współpracy jesteśmy w stanie zminimalizować ryzyko dostarczenia funkcjonalności, która nie będzie spełniać przedstawionych wymagań. A te, mimo, że mogą być dostarczone developers w najbardziej przejrzysty sposób, mogą również potrzebować wyjaśnień, rozważenia dodatkowych scenariuszy implementacyjnych itp.
Efektywna współpraca
Idąc dalej z rozważaniami dotyczącymi komunikacji i współpracy natrafiamy na kolejną z dwunastu zasad Agile Manifesto. Zasadę, która mówi o tym w jaki sposób najefektywniej ze sobą współdziałać.
Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
Pracując w świecie wirtualnym, zdalnym można spotkać się ze stwierdzeniem, że nie ma tu miejsca na taki rodzaj komunikacji. Z czym z pełnym przekonaniem się nie zgadzam. Owszem, komunikacja twarzą w twarz może być utrudniona. Jednak dzięki szeregowi narzędzi, które nam ową pracę umożliwiają i usprawniają, jesteśmy w stanie wybierać bezpośrednią komunikację ponad tą pisaną. Zamiast wymieniać setki wiadomości na Slacku możemy zorganizować video rozmowę, która z reguły szybciej zbliża nas do rozwiązania danego wyzwania. Przewagą rozmów głosowych nad tymi pisanymi jest lepsza możliwość interpretacji emocji i uczuć drugiej osoby. Emotikony czy zdania, które powstają pod naszymi klawiaturami, czasem mogą być błędnie interpretowane przez drugą stronę. Zwłaszcza jeśli pracujemy w środowisku wielokulturowym. Przykładowo ikonka 🙂, która przez Polaków czy Amerykanów jest uważana za pokazanie, że jesteśmy z czegoś zadowoleni, często przez Japończyków jest rozumiana zupełnie inaczej, dla nich kojarzona jest z niskim poziomem inteligencji.
Motywacja do działania
Innym aspektem, jednak w moim odczuciu bardzo powiązanym z dwoma powyższymi, jest praca wśród ludzi, którzy są pełni motywacji i gotowości do pełnego zaangażowania się w projekt. Zasada Agile Manifesto o tym mówiąca brzmi następująco:
Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
Mamy tutaj mowę nie tylko o motywacji, ale również o zaufaniu. Jednej z kluczowych wartości jeżeli chodzi o efektywną współpracę i komunikację. Dzięki zaufaniu do ludzi, z którymi pracujemy budujemy zdrową atmosferę w zespole i ograniczamy stres. Gdy ufamy sobie nie musimy się zamartwiać „czy Antek na pewno wykona swoją pracę?”. Wierzymy wtedy, że skoro ktoś się zadeklarował to z pewnością wykona swoje zadanie. W przypadku potencjalnych problemów z pewnością da znać o tym reszcie zespołu. Zaufanie i opisane wyżej podejście świetnie przekłada się na kolejną zasadę:
Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
Zespoły samoorganizujące to takie, które wiedzą jak ułożyć swoją pracę by osiągnąć przedstawiony cel. Nie boją się podejmować wyzwań, stawiają na otwartą i transparentną komunikację i nie boją się powiedzieć “nie wiem”. Dzięki pracy w zwinnym i empirycznym środowisku próbujemy różnych rozwiązań zgadzając się na ich potencjalne niepowodzenie. Uwzględniając stosunkowo małe ryzyko strat, poprzez pracę w krótkich iteracjach, jesteśmy w stanie ponieść konsekwencje niepowodzeń.
Działający produkt
Kwintesencją pracy nad produktem jest … działający produkt :). Nic tak nie cieszy zespołu, klienta i użytkowników jak sprawny, funkcjonalny, spełniający ich oczekiwania wynik pracy. Pozwoliłam sobie zebrać trzy zasady Agile Manifesto o tym mówiące.
Działające oprogramowanie jest podstawową miarą postępu.
Czy ilość commitów, linijek kodu, napisanych test case’ów może być gwarantem sukcesu? Jak zmierzyć sukces produktu? Ciężko tego dokonać wypuszczenia produktu na świat. Gdy już go opublikujemy otwiera się przed nami szereg możliwości do sprawdzenia satysfakcji użytkowników.
Doskonałość
Oczywiście, aby produkt mógł odnieść sukces, z pewnością musi być konkurencyjny, być może również i innowacyjny. Niezależnie jednak od tego powinien być dobrze przemyślany, zaprojektowany. Zarówno pod względem architektonicznym, wizualnym jak i promocyjnym.
Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
Wyobraźmy sobie w sytuację, w której mamy zebrane wymagania od użytkowników, znamy więc ich potrzeby i teoretycznie wiemy co trzeba zrobić. Dlaczego teoretycznie? A no dlatego, że same wymaganie to jedno a umiejętne zaprojektowanie rozwiązań, które będą spełniać wspomniane oczekiwania to drugie. Użytkownicy czy interesariusze często opisując swoje trudności i bolączki, na które rozwiązaniem ma być nasz produkt. Niestety często robią to jednak tylko powierzchownie. Projektant, PO czy też cały zespół, który zadaje odpowiednie pytania pogłębiające jest w stanie nie tylko poznać problem, ale zrozumieć przyczyny jego powstawania. A następnie zaproponować i zaprojektować optymalne rozwiązanie. Poprzez fazę badawczą w projektach, tworzenie UI i klikalnych prototypów jesteśmy w stanie stworzyć produkt szyty na miarę potrzeb klienta, oszczędzając jednocześnie jego czas i pieniądze.
Bywa też, że świetny produkt może być niezauważony przez to, że marketing nie był uwzględniony w procesie wytwórczym. Moim zdaniem to duża strata. I można temu łatwo zapobiec, pamiętając, że odpowiednia promocja może spowodować, że nawet na pozór niechciany produkt stanie się nieodłączną aplikacją w naszym telefonie, czy elementem naszego domu.
Została nam ostatnia zasada, która w sumie odnosi się również to samego Agile Manifesto. Jest on, krótki, a treściwy. Nie znajdziemy w nim zbędnego lania wody. Tak samo powinniśmy działać w pracy, minimalizm, zasada “good enough” powinna kierować naszym procesem wytwórczym. Nie budujmy przez pół roku niepewnej funkcjonalności. Stwórzmy jej MVP, dajmy się pobawić użytkownikom, a dopiero później dopracujemy ją i usprawniajmy.
Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.
Zasady Agile Manifesto
Wszystkie opisane wyżej zasady stanowią podwaliny Agile Manifesto, są jego dopełnieniem. Pozwalają nam one jeszcze dogłębniej zrozumieć co autorzy mieli na myśli go tworząc. Powinny one stanowić nieodłączny element edukacji podczas stawiania pierwszych kroków w zwinnym świecie. Jak i nie opuszczać nas na całej drodze ku zwinności. Sposób w jaki je zebrałam jest moim własnym podziałem, który ma Wam jeszcze mocniej wskazać połączenie pomiędzy zasadami Agile Manifesto a samym Manifestem. Pamiętajcie, kluczem do pracy w zwinnym środowisku jest zrozumienia i opanowanie podstawowych działań oraz empiryzm. To on pozwala nam stać się mistrzami zwinności.
Sprawdź nasze ostatnie wpisy:
