Agile, czyli co?

Dzisiejszy wpis będzie trochę nawiązywał do wcześniejszego. Omówiłam w nim model Waterfall, więc dzisiaj część o.. zwinności!

Zapraszam 🙂

Charaktersytyka Agile

To czym w takim razie jest to zwinne podejście?

Podejście zwinne definiowane jest właściwie przez cztery punkty, zwane Manifestem Agile. Jest to podstawa oceny, czy konkretna metoda jest zwinna. Agile to po prostu sposób pracy w zgodzie z wartościami wymienionymi poniżej.

Bardzo często jest to niestety przyswajane przez organizacje, jako „to-do-list”. Czyli robimy rzeczy po lewej stronie, a te po prawej odrzucamy. Nie wiem czy zauważyliście, ale ostatnie zdanie jasno mówi, że sygnatariusze nadal cenią wartości po prawej stronie. Tylko nie są one dla nich priorytetem.

To tak jak ze sprzątaniem – nie jest Waszym ulubionym zajęciem i przynoszącym największą wartość, ale trzeba to robić. W przeciwnym wypadku będzie

Wracając do Agile. To, że Panowie napisali, że przedkładają „działające oprogramowanie ponad wyczerpującą dokumentację” nie oznacza, że specyfikacja techniczna czy jakiekolwiek notatki mają zniknąć. Wiecie jak to jest, np. podczas spotkań z klientem. To co nie zostanie zapisane, często.. nie istnieje.

Za czterema wartościami wymienionymi w Agile Manifesto zostało jeszcze stworzonych 12 zasad będących swego rodzaju „wskazówkami” jak powinna działać zwinna organizacja. Brzmią one następująco:

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

Czyli.. „Nasz klient, nasz Pan”. Oczywiście przesadzam, ale chodzi o to, że to klient ma być zadowolony, a nie zarząd czy Twój menedżer.

A jak to zadowolenie osiągnąć? Przez tworzenie i regularne dostarczanie produktu, który przynosi klientowi wartość. Przez utrzymywanie kontaktu z klientem i konsultowanie w jakim kierunku ten produkt ma się rozwijać. Przez wczesne wdrażanie go.

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

Tu oczywiście mowa o tych słynnych zmianach. Których, tak bardzo szczerze, nikt nie lubi. Łatwiej jest podążać za wcześniej zdefiniowanymi, jasnymi oczekiwaniami. Zgodnie z jakimś planem.

Ale to tak jak w życiu 🙂 Jeśli chcemy, żeby nasze życie było „pełne” i dążymy do osiągnięcia NASZEGO sukcesu, to musimy się dostosowywać do okoliczności i zmieniać. Obserwować co działa, a co nie. Wprowadzać korekty. Ewoluować.

Nie mówię tu o rewolucjach, jak np. umówiliśmy się z klientem na zbudowanie hulajnogi, a on nagle przychodzi i mówi, że chce łódź podwodną. Oczywiście tą łódź możemy mu zbudować, ale będzie musiał liczyć się z kosztami i utratą zasobów, przede wszystkim czasowych, poświęconych na budowę hulajnogi.

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

Najprościej rzecz ujmując, tu jest mowa o pracy w krótkich, powtarzalnych odcinkach czasu oraz o podejściu iteracyjnym.

Podejście iteracyjne, czyli praca w powtarzalnych, zamkniętych cyklach wytwórczych, których rezultatem jest działająca wersja produktu. Na zasadzie: „od ogółu do szczegółu”.

Po więcej odsyłam do artykułu Jacka Wieczorka z Agile247.

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

Czyli zlikwidowanie przepaści komunikacyjnej między biznesem a zespołami deweloperskimi. W dobie pracy zdalnej na pewno trudniej o pracę biznesu i deweloperów w jednym pomieszczeniu. Ale, jak to mówią: „dla chcącego nic trudnego”. Chodzi o to, żeby chcieć się porozumieć, chcieć usłyszeć zdanie tej drugiej strony.

To nic innego, jak komunikacja np. w relacjach damsko-męskich. Stereotypowo, mężczyźni mówią o „faktach”, a kobiety są bardziej emocjonalne. Kluczem jest chęć poznania perspektywy tej drugiej strony. Bez tego nie będzie udanej komunikacji. Ani udanej relacji. Bez tego nie będzie najlepszych efektów.

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

Kontrola i brak zaufania, czyli tzw. „mikromanagement” zabijają motywację. To jest w ogóle temat na osobny wpis.

Ale, omawiając ten punkt bardzo krótko. Agile buduje kulturę zaufania do osób które pracę wykonują. Bo w końcu kto najlepiej wie ile czasu zajmie mu dane zadanie czy jak je wykonać? No właśnie. Osoba, która faktycznie tą pracę wykonuje.

Więc zadaniem takiego np. kierownika projektów, czy innej osoby „biznesowej” nie powinno być kontrolowanie ludzi, ale ich wspieranie. Rozumienie potrzeb, rozumienie zachowań, które powodują np. spadki motywacji czy jakieś opóźnienia. I rozwiązywanie ich. Wartość dostarczają ludzie. To właśnie od ich nastawienia i przekonań będzie zależeć jakość produktów jakie dostarczą.

Nie wiem czy Wy też tak macie, ale ja – kiedy robię się wobec siebie zbyt wymagająca i krytyczna – to się blokuję. Na całego. Totalnie. Im więcej chcę z siebie wycisnąć, tym gorzej mi to idzie.

Kiedy zaczynam być wobec siebie łagodniejsza, pozwalam sobie na chwilę relaksu – moja motywacja i energia „kreatywna” powraca.

Odpuszczenie kontroli, zaufanie sobie i innym, zapewnienie wsparcia – te czynniki budują relacje. A relacje ułatwiają nam wspólne osiąganie wyników i tworzenie wartości.

Ale to moja opinia. Możecie się z nią nie zgodzić 🙂

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

Ojj, w tych czasach to raczej o to ciężko. Większość z nas pracuje jednak z domów, więc rozmowa „face to face” możliwa jest wyłącznie w formie wideokonferencji.

Ale myślę, że sam tu chodzi o sam fakt „przegadania” problemu. Nie wypisujesz maili, z 10 osobami w CC. Dzwonisz do danej osoby i pytasz. Otrzymujesz natychmiastową odpowiedź, możesz wyjaśnić nieścisłości. A jeśli masz możliwość zobaczenia danej osoby, to również otrzymujesz komunikaty niewerbalne, związane z mową ciała.

Więc otrzymujecie komunikaty na 3 poziomach: mowy ciała, brzmienia głosu oraz słów. Łatwiej jest ocenić, czy faktycznie się rozumiemy. A o to właśnie chodzi w komunikacji – nie tylko o przekazanie informacji, ale też o jej poprawne zrozumienie. I udzielenie odpowiedzi.

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

Najprostszą metoda oceny czy robimy coś dobrze i czy w ogóle coś robimy są efekty naszych działań. Tyle.

Papier, prezentacja w PowerPoincie czy wyszukany Excel wszystko przyjmie. Jednak najprostszym i najskuteczniejszym narzędziem jest produkt (lub jego przyrost), który stworzyliśmy.

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

I tutaj możemy się pokusić o rozważania na temat zrównoważonego rozwoju i równego tempa pracy.

Definicję „zrównoważonego rozwoju” słyszałam nie raz, nie dwa podczas moich studiów. Z definicji „zrównoważony rozwój to taki rozwój, w którym potrzeby obecnego pokolenia mogą być zaspokojone bez umniejszania szans przyszłych pokoleń na ich zaspokojenie”.

Odnosząc to do zespołów zwinnych i tworzenia oprogramowania – czas i energia włożona w pracę, powinna być równoważona przez odpowiednią ilość odpoczynku. Zdaję sobie sprawę, że pisanie o odpoczynku jest totalnie nie na czasie. Ale pomyślmy, ile błędów popełniamy tylko ze względu na to, że jesteśmy przemęczeni i zestresowani? Ile więcej czasu zajmuje nam dane zadanie, tylko dlatego, że za mało spaliśmy, a za dużo czasu spędzamy w pracy?

I ja nie mówię tutaj, że trzeba tylko odpoczywać! Trzeba zdefiniować swoje granice. Nauczyć się siebie i tego w jaki sposób się regenerujemy. Kiedy czujemy, że nasz limit się wyczerpuje.

Ja trochę nie ufam mojej motywacji 🙂 Bardziej polegam na wypracowanych nawykach. A ostatnio nawet łagodności. Testuję na sobie różne rzeczy i sprawdzam jak na mnie działają. I chyba dzięki temu ciągle się rozwijam.

Ale wracając do tematu – eksploatując zespół dziś, zastanów się co się z nim stanie za rok? A może nawet wcześniej. Duża rotacja w zespole negatywnie wpływa na jego produktywność. Bo nowa osoba potrzebuje czasu, aby się wdrożyć. Dodatkowo ktoś musi się tym wprowadzeniem jej zająć.

Utrzymując stałe, harmonijne tempo, jesteśmy w stanie dłużej wykonywać daną czynność. Bez wypalenia i załamań nerwowych 🙂

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

Nawiązując do poprzedniej zasady – pośpiech nie sprzyja wysokiej jakości. W żadnej dziedzinie.

Nie jestem deweloperem – nie będę się wypowiadać na temat przejrzystości czy jakości kodu.

Mogę się tylko odwołać do wpływu jaki jakość, albo jej brak, ma na późniejsze koszty utrzymania systemu w przyszłości. Niedoskonałości, prędzej czy później, trzeba będzie poprawić. A to naraża klientów na dodatkowe obciążenia finansowe.

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

Tu nasuwa się ten przykład z pralką.

Ile programów ma Twoja pralka? Strzelam, że z 10.

A ilu z nich używasz? Bo ja chyba 3.

Każda z tych funkcji to dodatkowy koszt. Agile zachęca do tworzenia systemów, które mają podstawowe funkcje. A następnie dodawanie kolejnych, jeśli zaistnieje taka konieczność. Czyli stosowanie modelu przyrostowego. Ponownie odsyłam do artykułu Jacka Wieczorka a Agile247.

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

Każdy z członków zespołu chce się rozwijać. A samoorganizacja pozwala na wybór narzędzi, metod czy architektury, dzięki którym praca nad produktem będzie im to umożliwiać. Dla niektórych będzie wyzwaniem, dla innym doskonaleniem swoich umiejętności w znanej im już technologii.

Nasuwa mi się tu taki przykład ze specjalistą, którego zatrudniamy, żeby np. położył płytki w łazience.

Czy mówimy mu jak ma to robić? Nie. On sam wybiera sposób.

My, jako właściciele, definiujemy co chcemy osiągnąć. Sposób osiągnięcia tego zależy jednak od zatrudnionego specjalisty.

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.

No tak – wyciąganie wniosków na końcu projektu, w postaci lessons learned jest.. użyteczne. Ale większość z nich będzie raczej mglistym wspomnieniem, niż rzetelnym opisem co możemy poprawić. Dodatkowo po omówieniu ich, zwykle nie zostają one zaimplementowane. Bo jak to zrobić, skoro projekt już się zakończył?

Zatrzymanie się i zastanowienie, w trakcie trwania projektu, co działa czy co można poprawić, sprawia, że możemy wprowadzić zmiany już dziś. Nie przy następnym projekcie, ale właśnie dzisiaj.

Sama próbuję, co mniej więcej 2 tygodnie, spokojnie usiąść i przeanalizować moją obecną pracę. Co dzięki temu osiągam? Na pewno łatwiej mi odnieść się do tego co udało mi się zrobić, co chcę poprawić i jakie cele mogę sobie wyznaczyć na kolejny okres. Zastanawiam się również nad wpływem pracy na moje samopoczucie. I staram się robić nie tylko nowe plany, ale też odpuszczać pewne działania. Takie, które ewidentnie mi nie służą.

Dlaczego to takie ważne?

Powyższe zasady jak i Manifest Agile zostały opisane jest z punktu widzenia deweloperów. Dlaczego je opisałam? Bo chciałam je dobrze zrozumieć. Zrozumieć punkt widzenia deweloperów. Oczywiście możecie się z moimi przemyśleniami nie zgodzić 🙂

Ale.. Management też się zreflektował i 4 lata później stworzył „Deklarację współzależności”. Jej treść znajdziecie poniżej.

Jakie są bariery i wyzwania związane z wprowadzaniem Agile?

Odsyłam Was do podcastu i artykułu na blogu Deloitte.

A na zakończenie, tylko przypomnę, że..

..Agile to nie tylko Scrum!

Scrum to nie synonim Agile. Scrum to tylko najpopularniejszy framework zwinny, ale istnieje więcej metod. Jakich?

  • Lean Software Development,
  • Kanban,
  • Programowanie Ekstremalne (XP),
  • Feature-driven development (FDD),
  • Dynamic systems development method (DSDM),
  • Crystal..
  • ..i dużo innych.

A na koniec jak zwykle.. Cieszę się, że jesteśmy Bliżej Projektów 🙂

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *