Manifest Agile czy może Manifest Oprogramowania zwinnego?
Aby lepiej zadbać o własny profesjonalizm warto zacząć od środowiska w jakim ma się on budować. Od dłuższego czasu standardem w dostarczaniu rozwiązań IT jest podejście zwinne i to właśnie od niego zaczniemy.
My robimy Agile po swojemu.
Wiadomo, pracujemy zwinnie, ale to taka nasza wariacja.
Nie da się robić Agile zgodnie z założeniami, wprowadziliśmy swoje zmiany.
Nie, Agile nie pomógł nam dostarczyć rozwiązania na czas.
Czy często słyszysz takie opinie? A może też masz takie doświadczenia i wyrobione zdanie w temacie „metodyk zwinnych”? Czy zauważamy, że część „implementacji” manifestu bardzo mocno zależą od kontekstu w jakim działają? Czy mogą one być szkodliwe i bardziej przeszkadzać niż wspierać nas w projektach? I dlaczego tak mało w nich nacisku na działania techniczne?
Czy zdajesz sobie sprawę, że implementacje manifestu oprogramowania zwinnego przez 20 lat stały się przyczyną niezadowolenia i to nawet samych autorów? Dla przykładu warto przytoczyć cytat z najnowszej książki z cyklu „czystych” autorstwa R.C.Martina – jednego z twórców manifestu oprogramowania zwinnego.
„Głównym celem korzystania z metody Agile jest właśnie to, by utracić nadzieję. Stosujemy tę metodę, aby ostatecznie zniszczyć nadzieję, zanim ona zdoła zniszczyć projekt”
Martin R.C., Czysty Agile, (2020)
Prawda, że nie brzmi to zachęcająco? Ja wręcz dreszczyk przerażenia poczułem. Porzućcie wszelką nadzieję, Ci którzy tu wchodzicie? 🙂
Skąd tak pesymistyczne nastawienie i dlaczego coraz rzadziej mówi się o „manifeście oprogramowania zwinnego” a zdecydowanie częściej o „manifeście agile” i metodykach zwinnych? Gdzie się podziało sformułowanie oprogramowania zwinnego? Czy komuś takie działanie było na rękę?
Spróbujmy więc na podstawie historii, statystyk oraz kilku mitów prześledzić co się w świecie projektów informatycznych zadziało i jakie ma to obecnie konsekwencje.
Początek!?
Manifest oprogramowania zwinnego został opracowany przez doświadczonych w inżynierii oprogramowania specjalistów i miał być odpowiedzią na bieżące potrzeby… Potrzeby realizacji projektów informatycznych nastawionych na dynamikę zmian biznesowych, jakość oraz ścisłą współprace zespołów z ekspertami dziedzinowymi.
Cofnijmy się do roku 2001, w którym to manifest powstał i przypomnijmy kilka faktów.
- Manifest stworzyło 17 ludzi na co dzień związanych z „żywym kodem”, inżynierią oprogramowania.
- Przed rokiem 2001 istniały już iteracyjne i inkrementacyjne sposoby pracy w projektach informatycznych z naciskiem na współpracę z klientem, jakość oraz potrzebę zmiany priorytetu realizacji. Autorzy kilku technik i ich popularyzacji brali udział w tworzeniu postulatów manifestu:
-
- Extreme programming XP (1996) – K.Beck
- Scrum (1995) / Scrum guide (2009) – J.Sutherland i K.Schwaber
- Pragmatyczny programista (1999) – D.Thomas i A.Hunt
-
- Głównymi problemami w ówczesnych projektach IT były brak możliwości wprowadzania zmian w rozpoczętych już przedsięwzięciach a także ilość dokumentacji wymagana do realizacji projektów. Wynikało to przede wszystkim z długo trwających i sekwencyjnych etapów metodyk kaskadowych, które nie dawały elastyczności w modyfikacji założeń.
- Zespoły deweloperskie realizowały projekt bez dostępu do ekspertów dziedzinowych w oparciu o dostarczoną dokumentacje powstającą tygodnie bądź miesiące przed rozpoczęciem implementacji.
- Klienci potrzebowali większej elastyczności a autorzy manifestu mieli częściowe rozwiązania. Brakowało tylko opisu wspólnej koncepcji. Meta opisu już istniejących rozwiązań oraz szeroko zakrojonej promocji ww. metod. Promocji u dużych graczy!
No i ruszyła maszyna!
O dziwo to właśnie wspomniana promocja i bardzo generyczne zasady opisane w manifeście dały ogromne pole do interpretacji a co za tym idzie niestety i frustracji autorów.
W powszechnym przekazie i komunikacji bardzo szybko zniknęło z nazwy manifestu słowo „oprogramowania”. Elastyczna interpretacja pozwalała sądzić, że oto powstał meta opis sposobu zarządzania projektami a nie zmiany w procesie dostarczania z naciskiem na sferę techniczną. To jak mocno rozwinęło się to „zarządzanie” widać na poniższym modelu nałożenia na siebie kilku metodyk „Agile” przygotowanym przez Deloitte.
Christopher Webb - LAST Conference 2016 Agile Landscape - https://www.slideshare.net/ChrisWebb6/last-conference-2016-agile-landscape-presentation-v1
Po głębszej analizie widać jak wiele jest technik ukierunkowanych na sam proces. Mamy tu olbrzymią liczbę wariantów pozyskiwania wymagań, inicjowania i odkrywania potrzeb biznesowych, podejścia do leadershipu i to co zaskakuje dość mocno – skalowania „Agile” w wielkich organizacjach. Dziwi to przede wszystkim ze względu na pierwotne założenia. Agile był i jest kierowany do małych i średnich zespołów.
Niewiele niestety jest praktyk ze sfery tylko technicznej a w szczególności niewiele nowych. Nowych to znaczy „świeższych” niż założenia opracowane w extreme programmingu. Pojawiają się one jedynie w obszarach deliver oraz release w stosunkowo niewielkiej ilości.
Przy tej skali praktyk z obszarów procesowych i technicznych nie dziwi więc określenie „My robimy Agile po swojemu.„. Chyba nie trudno wywnioskować jak wiele z ww. technik należy poznać, aby rzetelnie dobrać je do konkretnego projektu / zespołu.
Miało być łatwiej, szybciej, prościej! Miało być!
Jeżeli właściciele biznesowi mają do wyboru działające oprogramowanie oraz szybką odpowiedź na zmiany ponad kompleksową dokumentację i realizacje zapewne już nieaktualnego planu – to wybór jest oczywisty! Niekoniecznie skupiamy się nad tym, że teraz to będziemy musieli wchodzić w szersze interakcje z zespołami technicznymi. A to właśnie ta szersza interakcja miała być motorem napędowym sukcesu w kontekście Agile. Zamiast tego mamy rozbudowaną sieć praktyk! Niekoniecznie pomagających spełnić pierwotne założenia manifestu oprogramowania zwinnego.
Skoro więc pojawiły się nowe metody zarządzania to wystarczyło dostosować do nich zespół, wdrożyć odpowiednią ilość spotkań, rytuałów związanych z konkretną wariacją Agile i gotowe.
Jak dalekie jest od pierwotnych założeń, że ludzie są nad procesami i jeżeli należy je dostosować to zespół taką decyzje podejmuje.
Poza tym stare procesy zostały zastąpione nowymi bez większego zrozumienia jaki mają cel.
Czy przy takiej interpretacji i zastosowaniu tylko części założeń manifestu projekty nagle zaczęły osiągać zawrotne rezultaty?
No właśnie nie!
Agile sam w sobie stał się produktem do zarządzania z szeroką promocją w świecie.
Ruszyła maszyna! Ale czy w dobrą stronę?
Warto również wspomnieć, że już w latach trzydziestych 20 wieku w produkcji stosowano metody iteracyjne (nie inkrementacyjne) np. PDCA (plan–do–check–adjust), które to stały się podstawą do najbardziej popularnej dziś metodyki z rodziny „Agile” czyli Scrum. Poniżej kilka faktów z ostatnich 100 lat, które pomogły zbudować założenia obecnego „Agile”
Powyższa oś czasu jasno pokazuje, że długo przed definicja samego manifestu oprogramowania zwinnego podjęto pierwsze działania, które dzisiaj określane są jako „Agile”. Warto zwrócić uwagę, że nie zawsze wywodziłī się one ze świata projektów IT.
Czym więc manifest oprogramowania zwinnego różnił się od wcześniej zaproponowanych metod? Przede wszystkim nie definiował jasno praktyk jakie należy w projektach IT podejmować. Celem miało być pokazanie istoty projektów programistycznych i tego jak wiele zależy od praktyk technicznych i samych inżynierów oprogramowania. Czy to się udało? Wystarczy wrócić do wyżej zaprezentowanego Landscape Deloitte’a i odpowiedź sama ciśnie się na usta 🙁
Warto podkreślić raz jeszcze, że manifest był kierowany do zespołów programistycznych. Zastanawia więc fakt, że obecnie mówi się o „Agile’owej” organizacji pracy np. w marketingu, księgowości itp. Pytanie więc czy w tych obszarach możliwa jest realizacja postulatu „Działające oprogramowanie od szczegółowej dokumentacji” 🙂
Zamiennie stosuje się również określenie praca zwinna. Lepiej! Ale zwinność a bardziej iteracyjność czy inkrementacyjność to sposoby opracowane dużo wcześniej niż sam Agile.
A więc #coztymIT?!
Skoro projekty nie zaspokajają potrzeb klienta, są marne jakościowo, oraz nie mają możliwości dostarczania tak szybko jak tego potrzebujemy to dlaczego właściwie wybieramy różne wariacje „Agile”?
Spróbujmy na podstawie utartych przekonań rozwiać wątpliwości dotyczące zwinnego dostarczania oprogramowania.
MIT #1. „Agile” przyspiesza realizację projektów
Nie ma chyba nic bardziej mylnego niż przekonanie, że projekt będzie dostarczony szybciej!
Jednym z głównych punktów manifestu jest „Reagowanie na zmiany od realizacji założonego planu”.
Jeżeli kiedykolwiek wybierzesz, którąś z implementacji „Agile” aby przyspieszyć realizację projektu to wiedz, że właśnie wygenerowałeś sobie dość duży problem. Szybciej to jesteśmy w stanie reagować na zmiany i wyciągać wnioski aby metodą małych kroków i zwrotów dostarczać najważniejszą w tej chwili wartość.
„Agile” w swych założeniach jest nastawiony na wielką empatię kliencką. Na dostarczenie tego czego akurat teraz oczekuje biznes z jakim pracujemy i to niezależnie od kosztu. Jeżeli klient, z którym współpracujesz nie rozumie tego aspektu to nie metodyki zwinny są Ci potrzebne.
A skoro źle zrozumiany Agile prowadzi do problemów z zadeklarowanymi terminami to skąd jest brany czas, na dogonienie terminu czy zmianę zakresu? No nie uwierzysz! Właśnie z kawałka odpowiedzialnego za profesjonalizm, podnoszenie umiejętności oraz jakość. Z kawałka technicznego
Statystycznie od 55% do 70% (oczywiście zależy kto robi statystykę) projektów nie dostarcza wartości biznesowej w zakładanych ramach czasowych a to oznacza, że w pracy zespołu zwinnego coś nie działa. Ciekawym aspektem jest również szersze wskazanie przyczyn niepowodzenia projektów IT
https://financesonline.com/35-essential-project-management-statistics-analysis-of-trends-data-and-market-share/
A teraz spójrz na całość założeń manifestu oprogramowania zwinnego!
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.
Dlaczego akurat zmiany priorytetowych, celów, wizji jest wskazywane w powyższych statystykach jako problem skoro miało być „reagowanie na zmiany”.
Dlaczego tak wysoko statystycznie pojawia się słaba komunikacja i brak wsparcie inwestorów – skoro mieliśmy bliżej współpracować z klientem a dodatkowo ludzie i interakcje zostały wskazane jako priorytet?
Powyższe statystyki to zaprzeczenie zrozumienia zasad jakimi miały się rządzi projekty realizowane w duchu zwinnego wytwarzania oprogramowania.
Jeszcze ciekawsze jest to, że nie ma bezpośredniego wskazania problemów związanych z częścią techniczną – zespołem. Nie ma tu informacji np. o nieprawidłowym podejściu do procesów CI/CD, nieefektywnej metodzie dobrania kontroli jakości kodu np. code review wybrane zamiast pair programmingu, który nadawał by się lepiej do danego projektu itd.
Z perspektywy samego zespołu to super opcja – problemy pojawiają się w warstwie procesu a nie technicznej ale czy na pewno? Trzeba wiedzieć, że takich zestawień nie robią inżynierowie oprogramowania a osoby odpowiedzialne właśnie za te rozdmuchane procesy. Niestety nie można spodziewać się innych wyników. Ten stan rzeczy wpływa na nasze tytułowe zacieranie się oprogramowania w nazwie „manifest oprogramowania zwinnego”.
#coztymIT?! – przecież szybciej na pewno nie będzie!
W „zdrowym” projekcie klient dostanie to czego akurat teraz potrzebuje! Niezależnie, czy to coś było planowane wcześniej czy też nie. Aby szybka reakcja na zmiany była możliwa trzeba oczywiście ponieść koszty związane z dobrym jakościowo produktem. Koszt to znaczy czas!
MIT #2. W „Agile” jestem programistą
Kolejny krążącym mitem i źle zrozumianym aspektem jest nazwa roli. Przywykliśmy nazywać osoby potrafiące pisać kod programistami. Rynek, oferty pracy a nawet konferencje branżowe – wszędzie pojawia się nazwa programista java, programista php, programista C# itd.
Rzadziej spotykamy nazwę deweloper, która jest już bliższa założeniom Agile ale ponownie pojawia się tu developer czego.
A więc o jakich założeniach mówimy i co z tą nazwą jest nie tak?
Przede wszystkim rola o nazwie programista kojarzy się tylko i wyłącznie z programowaniem.
Agile w sposób niejawny redefiniuje oraz rozszerza tę rolę. Nie jest to już osoba „klepiąca” kod a z całą pewnością biorąca udział w działaniach, które do tej pory nie były standardem w pracy programisty. Dlaczego tak?
Bo zwinność projektu zaczyna się od zwinności jednostki!
Interakcje, współpraca z klientem, reagowanie na zmiany to elementy z samego manifestu a istnieje jeszcze 12 dodatkowych zasad, w których warto podkreślić:
- rozumienie konkurencyjności produktu jaki tworzymy,
- ścisła współpraca z biznesem,
- zrozumienie wartości motywacji i zaufania,
- praca nad rozwojem członków zespołu,
- działanie samoorganizujących się zespołów,
- udział w optymalizacji procesów
Nie były to elementy, na których profesjonalny programista musiał się skupiać w świecie waterfall. Inżynier oprogramowania, bo tak nazywałbym specjalistę pracującego w duchu Agile musi w swym warsztacie powyższe uwzględniać! Dostarczanie wartości nastawionych na zadowolenie klienta oraz odpowiedzialność to podstawa profesjonalizmu.
Taka postawa bardzo często wiąże się z szybką nauką nowych frameworków, języków programowania, koncepcji oraz postaw, które były wcześniej zbędne.
Jeżeli przywiążemy się do nazwy stanowiska np. programista java zamiast mentalnie zostać inżynierami oprogramowania to trudniej nam będzie zrozumieć jaką role pełnimy w Agile.
Słabo przepracowana i zdefiniowana rola w zespole bez jasno zaznaczonej odpowiedzialności na pewno nie przybliża nas do sukcesu projektów w jakich pracujemy.
Warto również zwrócić uwagę, że nie zawsze programistom to rozszerzenie odpowiedzialności jest na rękę. „Ja chce tylko programować” to określenie może się dość często pojawiać i niekoniecznie przybliżać nas do współczesnego podejścia w Agile. Jest to kolejny aspekt, który może zacierać nasze tytułowe „oprogramowania”
Nad profesjonalną postawą skupimy się szerzej podczas opisywania Software Craftsmanship.
#coztymIT?! Bądźmy więc inżynierami oprogramowania a nie tylko programistami!
MIT #3. „Agile” podnosi jakość oprogramowania
Niestety manifest oprogramowania zwinnego nie wskazuje jednoznacznie co jest ważne z perspektywy samej jakości. Nie uczy nas czym jakość oprogramowania jest.
Efektem pracy świadomego zespołu powinien być prosty i podatny modyfikacją produkt, który możemy wydawać bardzo często.
Niestety jest tu dość niewiele wskazówek dla samych inżynierów, a niektóre mogą być mylnie interpretowane.
Przyjrzyjmy się zatem trzem z 12 założeń manifestu oprogramowania zwinnego
„Dostarczaj funkcjonujące oprogramowanie często w kilkudniowych lub kilkumiesięcznych odstępach. Im częściej tym lepiej.”
„Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.”
„Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.”
Jak więc widzimy powyższe założenia nie odpowiadają na pytanie jak do samej jakości podejść. Nie ma tu narzędzi, technik ani innych gotowych rozwiązań, które z założenia podnoszą jakość.
Oczywiście brak jasnego wskazania praktyk może powodować wrażenie, że nie jest to istotne a co za tym idzie powoli słowo oprogramowania zaczyna znikać z określenia „Manifest oprogramowania zwinnego”.
Co tu poszło nie tak?
Zacznijmy więc od dążenia do doskonałości. Skupiając się na tym aspekcie możemy wpaść w pułapkę i przekonanie, że wszytko w projekcie musi być doskonałe a przecież to nie jest prawda! Nie musi! Zwinny zespół to przede wszystkim taki, który potrafi podejmować decyzje o jakości w konkretnych częściach systemu. Kluczem jest tu odpowiedź na pytanie „który obszar i z jaką częstotliwością może się zmieniać?”.
Im dynamika zmian większa tym jakość powinna być wyższa. Jest to bardzo prosta zasada, która pomoże nam w dobieraniu odpowiednich technik podnoszących zwinność naszych rozwiązań oraz zaoszczędzenie czasu i energii w miejscach o niskim potencjale zmian. Po co mielibyśmy robić arcydzieło w miejscu, do którego nigdy nikt nie zajrzy?
Nieważne czy tworzymy wewnętrzne narzędzie do wsparcia procesów organizacji czy może system rezerwacji lotów, zawsze znajdziemy obszary, które zmieniają się i będą zmieniać często. I to właśnie tam należy dbać o jakość aby osiągnąć większą zwinność
Skoro mamy obszary gdzie dynamika zmian jest wysoka to jakie działania należy w nich podjąć?
- Prosty i czytelny kod – To taki, który nawet osoba rozpoczynająca naukę programowania jest w stanie przeczytać i zrozumieć. Dobrze zdefiniowane domeny z odpowiednim zakresem odpowiedzialności i języka zrozumiałego dla całego zespołu jest kluczowe do szybkie analizy i modyfikacji. Wysoka abstrakcja i naszpikowanie kodu zależnościami i frameworkami niestety nie pomaga. Oczywiście istnieje szereg zasad wspomagających tworzenie kodu o założonej jakości KISS, SOLID, TDA, YAGNI, DRY, i oczywiście cały nurt DDD z narzędziami wspierającymi. Znaczenie tych zasad oraz błędy w ich interpretacji poruszymy w kolejnych wpisach.
- Odpowiednia ilość i rodzaj testów. Tam gdzie są one potrzebne i dają realną wartość. W miejscach, w których pojawia się złożoność biznesowa bądź infrastrukturalna. Na przekroju łączenia usług aby wdrożyć kontrakty i zapewnić niezawodność w komunikacji. Wszędzie tam gdzie wiemy, że ułatwi nam to w przyszłości modyfikację a w chwili realizacji zapewni niezawodność. Pamiętając przy tym, że im szersze testy (jednostkowe, integracyjne, e2e) tym czas modyfikacji większy.
- Dobrze zaprojektowany i utrzymywany proces ciągłej integracji oraz dostarczania CI/CD/CD’. Większość systemów oczywiście nie potrzebuje wdrożenia, po każdym commicie. Nie da się niestety osiągnąć dobrego poziomu zwinności bez porządnego zaprojektowania procesu począwszy od sposobu pracy z repozytorium a kończąc na automatyzacji dostarczania na produkcję. Ważne jest również to aby to narzędzia wspierały nas przy kontrolowaniu jakości poprzez wykonanie testów, informowanie o problemach, uruchamianie statycznej analizy kodu a w efekcie podejmowanie decyzji o propagowaniu zmian na docelowe środowiska. Dbałość o te procesy może nie tylko podnieść jakość ale w szczególności mocno przyspieszyć dostarczanie.
- Code Review i Pair Programming. Szybka informacja zwrotna to podstawa technik zwinnych. Im szybciej dowiemy się, że robimy coś co odstaje od przyjętych zasad tym wcześniej możemy zareagować i wprowadzać zmiany. Nie ma oczywiście szybszego i bardziej efektywnego udzielania informacji niż praca w trybie pair programmingu. Niestety bardzo często praca w parach kojarzy się z brakiem produktywności a dodatkowo technika jest dość mocno wymagająca skupienia i koncentracji. Dobrą alternatywą jest tu zbudowanie procesu przeglądu kodu (code review) najlepiej używając narzędzi wspierających ten proces.
- Oczywiście dążenie do doskonałości to również budowanie profesjonalizmu własnego jak i całego zespołu. Bez pracy nad propagowaniem wiedzy, dobrych praktyk i standardów ciężko będzie podejmować skuteczne decyzje pomagające osiągnąć zwinność.
To tylko część zagadnień na jakie w ramach osiągnięcia zwinności poprzez podnoszenia jakości warto zwrócić uwagę. Oczywiście nie są to wszystkie praktyki ale ich wdrożenie to dobry początek budowania skutecznego i zwinnego zespołu.
Na końcu warto zadać sobie pytanie czy w niektórych momentach to obniżenie jakości, bądź nawet zaciągnięcie długu technologicznego nie jest działaniem zwinnym. Przecież to może być dostosowanie się do potrzeb klienta. Pamiętajmy przy tym aby taka decyzja była również opatrzona odpowiednią komunikacja o potencjalnych problemach.
A więc #coztymIT?! skoro w branży krąży przekonanie, że Agile podnosi jakość oprogramowania!
Bardzo często wygodniej jest określić jakość całego projektu i trzymanie się go od początku do końca niż zmiana zasad podczas gry. To niestety może być jedną z głównych przyczyn niepowodzenia projektu. bo inwestujemy w miejsca, które tego nie wymagają.
Niezrozumienie roli ukierunkowania technicznego w Agile może bardzo często powodować kaca Agile’owy o czym w kolejnych postach.
MIT #4. „Agile” wspiera rozwój inżynierów
Manifest oprogramowania zwinnego został przygotowany przez bardzo doświadczone osoby i wydaje się, że aspekt rozwoju inżyniera nie do końca przebija się ponad inne potencjalne wartości. Niewiele też w tym temacie dowiemy się z opisów implementacji Agile takich jak np. Scrum. Skoro nie ma jasnego sposobu na radzenie sobie z ciągłym rozwojem to ten aspekt może zostać pominięty. Ta sytuacja oczywiście nie sprzyja jakości projektów a co za tym idzie zwinności.
Również w tym aspekcie doszukiwałbym się zacierania nazwy manifestu oprogramowania zwinnego na rzecz Manifest Agile. Nie przebija się dbałość o aktualizację wiedzy więc i profesjonalizm schodzi na dalszy plan.
Istotnym problemem pojawiającym się w tym obszarze jest traktowanie specjalistów jako reprezentujących ten sam poziom techniczny. Niestety nie jest to prawda. Dobre i indywidualne zaplanowanie działań rozwojowych jest niezbędne do utrzymania optymalnego poziomu zespołu. Poziomu, który pozwoli efektywnie reagować na potrzeby związane z rozwojem projektów.
Kwestie rozwojowe częściowo opisałem już tu – Nie bądź samotnym partyzantem w Software Developmencie. Więcej w temacie narzędzi jakimi możemy posłużyć się do efektywnego planowania i realizacji zadań rozwojowych będę opisywał w kolejnych wpisach.
MIT #5. „Agile” nadaje się do każdego projektu
Niestety NIE!
Nie wszyscy klienci są gotowi na tak szeroką współpracę jaką metodyki zwinnego wytwarzania definiują.
Jeżeli zespół nie ma wystarczającego dostępu do ekspertów dziedzinowych nie ma możliwości zbierania zwinnie / dynamicznie wymagań.
Kolejnym aspektem związanym z klientem może być sposób finansowania projektu, który nie pozwala na zmianę zakresu, terminu czy budżetu. Nie da się wtedy inkrementacyjnie sterować realizacją projektu.
Uwagę warto zwrócić również na to czy istnieje potencjał zmian tworzonego systemu. Jeżeli się ich nie spodziewamy to system może być zrealizowany również przy pomocy metod kaskadowych. Nie ma wtedy potrzeby wkładania energii w działania, które nie przyniosą korzyści.
#coztymIT?! w takim razie? Utarło się, że trzeba być „Agile” i w taki sposób pracować. Niestety po 20 latach nadal bardzo wiele firm, klientów, partnerów w realizacji projektów nie rozumie, że samo zastosowanie tej odpowiedniej metodyki jest już zwinnym podejściem.
MIT #6. „Agile” to metoda zarządzania projektem
Agile to swoista filozofia i framework działania, który jest implementowany na różne sposoby. Sam w sobie nie daje odpowiedzi jak zarządzać projektem. a dzięki mnogości implementacji możemy dobrać odpowiednie podejście do problemu jaki chcemy rozwiązać. Nie możemy przy tym oczywiście zapominać o meritum czyli o praktykach technicznych!
No i na koniec warto jeszcze zwrócić uwagę na to, że sami autorzy wypowiadają się bardzo zachowawczo pytani czym jest dla nich manifest oprogramowania zwinnego. Ta maszyna już się rozpędziła!
Jeżeli chcesz profesjonalnie zajmować się software developmentem staraj się o Sobie myśleć jako o inżynierze oprogramowania a nie programiście. Inżynier rozwiązuje problemy a nie tylko programuje.
Frameworki zwinne nie nadają się do każdego projektu. Już o tym wiemy więc jeżeli tylko zauważysz, że w Twoim projekcie nie przynosi efektu staraj się znaleść inne rozwiązanie.
Agile nie przyspieszają realizacji projektów, dają tylko elastyczność wprowadzania zmian zgodnie z bieżącymi potrzebami. Pamiętaj, że statystyki jasno pokazują – większość projektów nie dostarcza założonej wartości przy ścisłych ramach czasowych lub budżetowych.
Pamiętaj, że „Agile” sam w sobie nie podnosi jakości oprogramowania. To zestaw użytych praktyk w określonych kontekstach generuje jakość a zarazem zwinność.
Podnoś swoje umiejętności w sposób zwinny – tak działają profesjonaliści. Zaplanuj małe kroki nauki nowych rzeczy, zrealizuj, wyciągnij wnioski i powtarzaj.
Jako specjalista informuj tak szybko jak tylko się da, że widzisz zagrożenie. Jeżeli czegoś nie jesteś w stanie zrobić – odmawiaj, lecz nie zapominaj o przedstawieniu alternatyw. Czy chciałbyś aby chirurg, który widzi zagrożenia przeprowadzał operacje na Twoim organizmie?
Jeżeli dopiero zaczynasz prace w projektach zadbaj o wysoki poziom świadomości i zbuduj własną odpowiedzialność za podejmowane działania. Bez tego osiągnięcie sukcesu będzie bardzo trudne
Fundamentem „Agile” jest wielozadaniowość i możliwość dostosowania się do sytuacji. Jako inżynier oprogramowania powinieneś orientować się na cel i dostarczanie wartości. Pamiętaj jednak, aby to tego zagadnienia podejść mądrze bo przełączanie się między kontekstami może nawet o 40% obniżyć Twoją wydajność
Podejmuj świadome decyzje w jakich obszarach systemu jakość powinna być podniesiona. Nie daj zbudować w sobie przekonania, że cały system musi mieć takie same założenia.
Metoda małych kroków – wykorzystuj gdzie tylko się da. Nowe hobby czy rozwój umiejętności nie ważne! Małymi krokami możesz wiele spróbować i podjąć lepszą decyzję.
Jest kilka dodatkowych powodów, dla których nazw Manifestu oprogramowania zwinnego przybrała formę Manifest Agile. Niestety wiele z nich zależy od zbudowanego w koło tego pojęcia biznesu i mody.
Oczywistym jest, że każdy właściciel firmy, manager, człowiek odpowiedzialny za sukces przedsięwzięcia, bierze w ciemno nowe sposoby pracy, które tak dużo obiecują. Niewiele dokumentacji, samoorganizujące się i odpowiedzialne zespoły. Budowanie relacji i poczucie wpływu, na każdy aspekt projektu. Działające oprogramowanie!
Niestety, aby powyższe założenia były prawdziwe trzeba zwrócić uwagę na dodatkowe działania. Nie zapominajmy, że istnieją często powtarzane mity, które szkodzą sukcesowi projektu.
Nadal potrzebujemy przestrzeni na rozwój i budowanie profesjonalizmu. Nadal projekty są czasochłonne a Agile ich nie przyspieszy. Nadal w mocy jest ścisła współpraca zespołu z osobami odpowiedzialnymi za biznes.
Nie zapominajmy jednak, że Manifest stworzyli ludzie techniczni, którzy szukali możliwości usprawnienia nie tylko procesów ale również poprawy jakości pracy inżynierów.
Na koniec warto zwrócić uwagę, że popularność „Agile” pomogła stworzyć i spopularyzować nurt, który doskonale uzupełnia ww. braki. Mowa tu o Software Craftsmanship, o którym będę pisał.
Metodyki zwinnego dostarczania oprogramowania użyte świadomie mogą bardzo mocno pomóc zespołom osiągnąć sukces. Trzeba pamiętać tylko o kilku zasadach.
Niepodważalnie w nazwie manifestu jest słowo oprogramowania. Nie zapominajmy o tym!
Bibliografia:
- Martin C.Robert, Czysty Agile, Helion, 2020
- Mancuso S., Software Craftsman, Helion, 2015
- Thomas D., Agile is Dead, 2015, https://www.youtube.com/watch?v=a-BOSpxYJ9M
- Ribgy D., Sutherland J.,Takeuchi H., The Secret History of Agile Innovation, 2016, https://hbr.org/2016/04/the-secret-history-of-agile-innovation
- Kehrli J., The Agile Method Collection, https://www.niceideas.ch/the_agile_methods_collection.pdf
- Toikkanen T, Don’t draw diagrams of wrong practices, 2005, https://www.tarmo.fi/2005/09/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/
- Schissler T., Iterative is not Necessarily Incremental, 2020, https://www.scrum.org/resources/blog/iterative-not-necessarily-incremental
- Royce W. Managing The Development of Large Software Systems, 1970, http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
- https://agilemanifesto.org/iso/en/principles.html
Statystyki
- https://teamstage.io/project-management-statistics/
- https://financesonline.com/35-essential-project-management-statistics-analysis-of-trends-data-and-market-share/
Dla rozluźnienia
Pingback: #2 Rola wizualizacji w pracy inżyniera oprogramowania - #coztymIT?!
Pingback: Projekt #coztymIT?! startuje a ja zachęcam Cię do wzięcia w nim udziału! - #coztymIT?!