Spory pomiędzy zwolennikami metod zwinnych i sformalizowanych zapewne się nigdy nie skończą. Jak każdy, kto zajmuje się jakimkolwiek wspieraniem firm w sferze ich organizacji, zarządzania, wdrażania zmian, w tym oprogramowania, mam sukcesy większe i mniejsze a czasem żadne. Nie ja jeden stale podnoszę jakość swoich projektów, ucząc się nie tylko na efektach dotychczasowych projektów, ale także na studiowaniu tego co osiągnęli inni. Szukanie, w moim przypadku, to jednak nie tylko bierne szukanie gotowej, lepszej recepty, to głęboka własna analiza każdego przypadku.
Ostatnie lata, czyli nie jeden a kilka projektów, skłaniają mnie do postawienia tezy mówiącej, że jest silny związek pomiędzy metodami zwinnymi i sformalizowanymi. Jaki?
Zauważyłem pewną prawidłowość: narzędzie pracy powinno być ściśle dopasowane do stylu pracy jej wykonawcy. Prosty przykład: kierowcy i ich umiejętności, samochody jakimi się poruszają oraz środowisko w jakim się poruszają. Zwróćmy uwagę, że zbyt dobry kierowca w kiepskim samochodzie, dobry kierowca w dobrym samochodzie w mieście o słabej organizacji ruchu, słaby kierowca w bardzo dobrym samochodzie w bardzo dobrze zorganizowanym mieście, (i inne niedopasowane warianty), to wszystko przykłady tego, że „nie uda się” osiągnąć tego co można (co planowane, co możliwe do osiągnięcia). W zasadzie te trzy elementy: kierowca, samochód oraz miasto i jego organizacja ruchu, albo są na tym samym „poziomie rozwoju” albo będą kłopoty. W zasadzie o wszystkim decyduje poziom organizacji ruchu w mieście, to miasto narzuca wymagania na umiejętności kierowców, ci narzucają wymagania na swoje samochody. Jeżeli miasto jest kiepsko zorganizowane to najlepszy kierowca w super samochodzie nic nie poradzi. Jak się poruszać po mieście o słabej organizacji? Niestety na żywioł i siłowymi metodami z bardzo dużym ryzykiem stłuczki, straty czasu i nerwów (polecam filmy na youtube o kierowcach w Rosji).
Do czego zmierzam?
Od pewnego czasu zajmuję się pojęciem dojrzałości procesowej firm. Ogólnie jest to miara ich wewnętrznego uporządkowania i przewidywalności zachowań. Po co się to robi? Otóż im dana organizacja jest mniej przewidywalna w swoich zachowaniach tym większe ryzyko wprowadza do swojego otoczenia (np. dla partnera). Badanie [[poziomu dojrzałości procesowej]] zostało dość dobrze opisane w literaturze, jest już całkiem dojrzałą dyscyplina wiedzy.
Poniżej jeden z wielu dostępnych w sieci diagramów obrazujących owe poziomym, jest ich pięć:
(źr. Carnegie Mellon Contracted for Software R&D).
Na stronie PTI, mamy ciekawy artykuł na ten temat, zacytuję opis skali ocen jako pierwszy komentarz do powyższego diagramu:
Poziom 1 – Początkowy Procesy są nieprzewidywalne i niekontrolowalne.
Poziom 2 – Zarządzany Ustalone zostały procedury dla każdego projektu osobno.
Poziom 3 – Zdefiniowany Ustalone zostały procedury na poziomie organizacji.
Poziom 4 – Zarządzany ilościowo Organizacja ustaliła listę celów jakościowych i ilościowych i posiada narzędzia pozwalające na kontrolę ich wykonania.
Poziom 5 – Optymalizowany Procesy są w usprawniane w sposób ciągły.
(CMMI czyli jak kontrolować rozwój oprogramowania, polecam cały artykuł).
Pobieżne tylko poszukiwania w sieci wskazują na to, że większość firm w Polsce nie przekroczyło poziomu drugiego (!). Jaki z tego wniosek? Wracając do metafory z kierowcami w miastach: nie ma sensu podejmowanie prób zarządzania projektem metodą lepszą, na wyższym poziomie, niż poziom firmy będącej beneficjentem tego projektu, bo i tak firma ta nie będzie w stanie skonsumować korzyści jakie niosą z sobą wyższe poziomy CMMI. Jeżeli nawet w umowie zapiszemy nasz, dojrzalszy sposób postępowania, napotkamy duży „opór niedopasowania”. Wprowadzając „siłowo” lepszą organizacje pracy po stronie klienta, w najlepszym wypadku obszar naszego projektu „wzniesiemy” na poziom pierwszy, ale i tak tylko na czas trwania projektu (to akurat ma sens) z dużym prawdopodobieństwem, że po zakończeniu projektu nasz klient szybko wróci do „swojego poziomu”.
Ćwiczenie myślowe dla czytelników ;): biorąc pod uwagę znane Wam lub dostępne w sieci opisy metod pracy Agile, innych mniej lub bardziej sformalizowanych, „przyłóżcie” je do powyższego opisu poziomów. Czy nie macie wrażenia, że metody zwinne to jedyny sposób pracy w firmach na pierwszym poziomie? Czy nie macie wrażenia, że inne metody pracy niż czas i materiał, nie mają żadnego sensu w firmach na pierwszym poziomie dojrzałości? Jakie to ryzyko i straty (diagram powyżej)?
Jaki ma sens poukładane zarządzanie projektem (planowanie, dokumentowanie decyzji i ich zmian, zarządzanie ryzykiem itp.) w firmach, które tego nie robią same dla siebie? Co mi z tego, że ja będę planował, zarządzał zakresem, dokumentował istotne kroki (bo faktycznie nie ma sensu zapisywanie wszystkiego), wersjonował dokumentacje itp. skoro klient nie jest w stanie, nie tylko skonsumować korzyści z tego, nie jest w stanie nawet nawiązać realnej współpracy, bo moja prośba o pisemne uwagi do dokumentu w określonym terminie napotyka na próżnię: „my tu wszystko załatwiamy na spotkaniach i piszemy notatki”. Od siebie dodam, że w tych notatkach nie ma nic poza datą, lista obecności i zadaniami do następnego spotkania.
Dobrze zorganizowana organizacja organizuje spotkania, ale nie po to by coś opracowywać – to jest praca, spotkania są wyłącznie po to by coś wyjaśnić i ustalić (przed nimi należy wymienić się dokumentami i zapoznać się z nimi). Większość dokumentów projektowych jakie dostaję w firmach do wglądu, to nieniosące żadnych informacji notatki ze spotkań. A gdzie opis przedmiotu projektu???? Po co ten projekt? Jaki ma cel?
Tak więc wydaje mi się, że stosowanie metod zwinnych w wielu projektach ma jak najbardziej sens… ale stosowanie ich to raczej oznaka niedojrzałości nabywcy oprogramowania.
Dlaczego zwinne metody nie mogą wejść na poziom chociażby drugi? Wymagania dla tego poziomu nie wydają się nieosiągalne.
Odpowiedź na diagramie powyżej (kolumna capability): zarządzalność – jeżeli (znowu wracamy do „braku” ścisłej definicji metody zwinnej czyli nie wiadomo o czym teraz piszemy ::))) – polega na planowaniu i mierzeniu stopnia osiągnięcia planu:celu. Metody zwinne jednak nie operują pojęciem zakresu projektu, maja jedynie cel, zaś cel projektu a zakres to nie to samo. Z jakim dokumentem, co zawiera, startuje „projekt zwinny”?
W Scrumie na przykład możemy zarządzać wymaganiami na Product Backlogu i na Sprint Backlogu. Można też opisy rozszerzyć na jakieś narzędzie wspomagające albo dokumentację. O ile zakres projektu nie jest znany na początku, w ramach sprintów mamy plan realizacji i możliwe jest śledzenie postępów. Możemy mierzyć i analizować sprint na burn down charcie. Za jako taki proces odpowiada Scrum Master, jakość produktu też może być zapewniana i sprawdzana przez zespół czy jakiegoś szczególnie wykwalifikowanego testera. Zarządzaniu konfiguracji nic nie stoi na przeszkodzie 🙂
Jak rozumieć to: „zakres projektu nie jest znany na początku, w ramach sprintów mamy plan realizacji i możliwe jest śledzenie postępów”. To jest to czego nie rozumiem: jak śledzić postępy realizacji coś czego nie ma? Moim zdaniem problem z metodami zwinnymi polega na tym, że to tylko „praca czas i materiał”. Nie ma w takiej pracy nic złego, to po protu dostarczanie usługi (zasobów), jednak pojawia się konflikt pojęciowy (i biznesowy) przy próbie połączenia tego z „produktem” jakiego ktoś oczekuje. Jak bezpośrednio połączyć „zamówienie dzieła (produktu)” z kontraktem „czas i materiał”? To sytuacja gdy w klasycznym trójkącie „zakres, termin, budżet” czegoś brakuje (albo nad czymś nie panujemy). Jeżeli jednak ktoś chce (a biznes chce) zawrzeć umowę „fixed price”, to w zasadzie jedynym lekarstwem, przy braku zakresu, jest „wyciąganie” ile się da terminu i budżetu.
„jakość produktu” – jak tu definiujemy produkt: „coś co do tej pory udało się wytworzyć” czy „coś co zostało zamówione”?
Nie wiedząc, co ma powstać w projekcie, faktycznie trudno nim zarządzać. Jeśli jednak spojrzymy na sprinty jak na podprojekty, wtedy mamy dokładnie określony zakres – wiemy, jakie funkcje mają zostać zaimplementowane w następnych np. 2 tygodniach. Wtedy czym różni się to od zwykłego projektu? Możemy planować dokładnie, monitorować, itd. Z racji krótkiego czasu, te czynności będą uproszczone, ale mogą występować i są zalecane. Martwi mnie tylko w kolejnym sprincie analiza wpływu nowych funkcji i zmian na dotychczasowy produkt, bo zazwyczaj nikt się nad tym bardzo nie pochyla. Nie jest to jednak niemożliwe i zdaje się, że bardzo wykwalifikowani członkowie zespołów zwinnych mogą coś takiego wykonywać, choć wymaga to pewnie samozaparcia i no i znajomości metod, co nie leży w typowym warsztacie programisty.
„Jeśli spojrzymy na sprinty jak na podprojekty, wtedy mamy dokładnie określony zakres ? wiemy”, ale czy to nie wygląda jak budowa domu metodą polegającą na projektowaniu i stawianiu kolejnych pieter dopiero po zakończeniu kondygnacji poniżej? kto by w tym nie bał się mieszkać? Po drugie taki sprint jako „podprojekt” nie działa, mówiąc wprost: „sprint” nie spełnia definicji projektu (bo ten tworzy samodzielny, przydatny dla klienta produkt). Tak więc nie możemy spojrzeć na sprinty jak na podprojekty.
W założeniach dla tworzenia sprint backlogu (czyli listy funkcji, które będą realizowane w kolejnym sprincie) jest powiedziane, że powinny dostarczać działający produkt realizujący funkcje posiadające wartość dla klienta, umożliwiające wykonanie jednej lub kilku ważnych z jego punktu widzenia, dla jego biznesu czynności. Co do strachu to pewnie i strach, szczególnie, jeśli to dom do codziennego mieszkania całej rodziny 🙂
I tu widzę „chwyt”: „produkt realizujący funkcje posiadające wartość dla klienta”. Pojedyncza funkcja rzadko oznacza wartość dla klienta jako „ważna dla jego „biznesu”. Bo tu funkcja to przypadek użycia, ten ma wartość jako usługa systemu (wsparcie czynności w procesie biznesowym) ale już nie jako „sama w sobie”. System (oprogramowanie biznesowe) to zestaw funkcji (przypadków użycia). Pojedyncza funkcja, pozbawiona pozostałych (poza być może nielicznymi wyjątkami), nie ma sensu biznesowego. System wsparcia sprzedaży to nie tylko „funkcja” tworzenia faktur. Do sprzedaży, będącej pewnym procesem, wymagane jest jeszcze kilka funkcji: np. zarządzanie kontrahentami, magazynem, płatnościami itp. To jako całość dopiero ma sens. Czy ma sens rozpoczęcie pracy nad funkcją fakturowania bez wiedzy (nie było jeszcze tych sprintów) o tym, że (czy) będzie potrzebny także magazyn i rejestr kontrahentów? Bez wiedzy o tym jaka logika łączy te elementy? Nawet jeżeli było by to możliwe, czy ten projekt ma sens bez wiedzy czy starczy czasu i środków na brakujący np. raport sprzedaży?
Pewnie często trudno jest w jednym sprincie wykonać cały proces. Czy jednak zastąpienie pewnych czynności już nie jest samo w sobie usprawnieniem procesu? Nie musi być, bo np. wymaga podwójnego wykonywania czynności – na papierze i w komputerze, jednak już zobaczenie jak to będzie wyglądało pomaga klientowi to sobie lepiej wyobrazić w ostatecznej wersji, zrozumieć i podejmować dalsze decyzje. Może być też ważny dla przyszłych użytkowników i poznania ich opinii. Co prawda ukończony cały proces może wyglądać inaczej i mieć nieco inne znaczenie, ale już łatwiej jego go przybliżać, kiedy gdzieś powstał, nie tylko w modelu. Tę rolę może spełniać (i spełnia często) prototyp, jednak wielu klientów ma trudności ze zrozumieniem (albo wykonawcy z jasnym wytłumaczeniem) granic funkcjonalności prototypu (co tu ma działać i być widać, a co jeszcze nie). Funkcje można oddzielać, np. najpierw wystawiać fakturę z polami do ręcznego uzupełnienia (co już da dobry pogląd na wiele aspektów), stopniowo dodawać słowniki, magazyny, itd. Czy ktoś jest w stanie dokonać rzetelnej analizy podczas wprowadzania tych dodatków w kolejnych sprintach? Pewnie da się. Nie mniej pewna jestem, że prawie nikt tego nie robi, niestety. I tu moim zdaniem słabość stosowalności agile, że kojarzy się z dowolnością (choć tak naprawdę wymaga dyscypliny) i wielu chętnie wykorzystuje to skojarzenie, robiąc za mało, zbyt chaotycznie, a nazywając swoje działanie zwinnym.
„czy ten projekt ma sens bez wiedzy czy starczy czasu i środków na brakujący np. raport sprzedaży?” – jeśli nie starcza czasu, zazwyczaj jest uzasadnienie w spożytkowaniu czasu na inne elementy oceniane przez klienta jako bardzo ważne. Wtedy można łatwiej osiągać porozumienie – zrezygnowaliśmy z raportów na rzecz elementów ocenianych jako ważniejsze lub dodajemy je jako kolejne zamówienie. Umowy można przecież aneksować. Pytanie jak z otwartością klienta. Jego elastyczność jest jednym z ograniczeń stosowania zwinnych metod.
„jeśli nie starcza czasu, zazwyczaj jest uzasadnienie w spożytkowaniu czasu na inne elementy oceniane przez klienta jako bardzo ważne” – a jakim cudem „inne ważne elementy” pojawiły się dopiero w np. w połowie projektu? W kwestii rezygnacji „z czegoś na korzyść czegoś” – co ma zrobić klient, gdy już zainwestował dużo w projekt (trwa długo) i nagle dowiaduje się, że „z uwagi na termin i budżet dostanie samochód albo bez kół albo bez silnika”, po prostu dostanie nieprzydatny produkt. To są rzeczy, które należy rozstrzygać na etapie planowani zakresu a nie w trakcie trwania projektu…
Planowanie, jak najbardziej powinno być, na początku, czego Agile nie wyklucza. Po to analityk w projekcie, by uświadamiać klienta i czuwać nad tym, żeby nie dostał samochodu bez silnika, co najwyżej bez klimatyzacji na jesień 🙂
Czy to nie jest tak, że im bardziej jednak planujemy, projektujemy, dokumentujemy itp. tym bardziej jest to „zwykły projekt” a nie „agile” (nadal szukam definicji „metodyki zwinnej”)???? 😉
Dla mnie np. SCRUM to metoda zarządzania realizacją projektu, jednak „ktoś” powinien jednak na początku zdefiniować zakres tego projektu.
Ja bym porównał metodyki zwinne do drukarek 3D, zaś metodyki sformalizowane do wtryskiwarek opartych na formie 🙂
dlaczego?
Zarówno przeciwnicy jak i zwolennicy metod zwinnych powielają schematy. Wygląda mi też na to, że działają w działkach, które nie pokrywają się.
Skąd pomysł, że przyjęcie podejścia polegającego na rytmicznym dostarczaniu czegoś co klient może „dotknąć” i skomentować, automatycznie wyłącza nam możliwość planowania i przewidywania konsekwencji naszych działań?
Jeżeli robię projekty, w których nie ma pewności czy się da osiągnąć technologicznie i organizacyjnie cel, to moje problemy nie będą łatwo zrozumiałe dla kogoś, kto z góry może podać dokładną cenę pracy.
Metody zwinne to nie są przepisy kucharskie. Zupa z „robimy bez pomysłu”, „nie mamy wspólnego modelu”, „przestaliśmy być amatorami, bo teraz używamy Scorm” jest zupełnie niezjadliwa. Agie to jest głównie ideologia. To jest trochę jak z demokracją. Kwitnie w pewnych warunkach, w innych może przegrać wojnę z dyktaturą. Co nie znaczy, że dyktatura jest zawsze lepsza. Jeżeli interesuję nas tylko wynik bieżacego projektu, ludzi można łatwo wymienić, to nie zawracajmy sobie głowę agile, przynajmniej nikt się nie będzie nabijał z nadużyć semantycznych.
Ludzie nie rozumiejący celu swojej pracy i nie otrzymujący szybkiej informacji zwrotnej pracują poniżej swoich możliwości. W zadaniach nietypowych większy potencjał ma zróżnicowana grupa ludzi o średnim doświadczeniu niż jeden człowiek z ogromnym. Każdy przypadek trzeba traktować indywidualnie. Jeżeli nie analizujemy ryzyka i nie planujemy, to jesteśmy dla siebie niebezpieczni. Organizacje używające metod zwinnych mogą celować w CMMI na poziomie 5, ale nie dla każdego projektu i nie na podstawie recenzji „Scrum for dummies”.
Model CMMI ładnie wygląda, gdy mam na celu robienie sterowników do hamulców w samochodach. Jest nawet za mało szczegółowy. Bardziej pełny obraz w takim przypadku daje model SPICE. Procesy agile, w rodzaju Scrum, pozwalają na praktyczne osiągnięcie celów poziomu 5 CMMI. Nie zapewniają jednak one samodzielnie obsługi nawet poziomu 2, tak jak śrubokręt nie pozwala na to samo co młotek. Ale tłumaczenie, że z powodów ideologicznych, nie można używać równolegle młotka i śrubokrętu odsyłam na zajęcia praktyczno-techniczne.
Moim problemem w projektach jest właśnie to, że Agile to TYLKO ideologia. Osobiście nie tyle jestem „wrogiem” tej ideologii, co jestem wrogiem uznawania, że nie trzeba odpowiadać na pytanie „co zrobimy” a wystarczy odpowiedź na pytanie „co będziemy robili”. Nie ja jeden uważam, że „trójkąt”: zakres, budżet, termin, ma bardzo głęboki sens biznesowy: planowanie. Nadal nie wiem czym, poza ideologią, jest Agile (poza manifestem nie znalazłem żadnej definicji), ale mam przekonanie, że projekt bez zdefiniowanego pojęcia „zakres” nie jest projektem. Co do dokumentacji w projekcie to uważam, że wyjaśniają problem słowa pewnego prawnika na jednej z konferencji (nie pamiętam kora ;)), treść umowy w formie pisemnej ma jeden cel: korzystamy z niej w przypadku jakichkolwiek wątpliwości co do tego co, kiedy i kto miał zrobić. Praktyka pokazuje, że ideały nie istnieją, dokumentacja w projekcie jest potrzebna. Bardzo często wrogowie tworzenia dokumentacji posługują się przykładem złej dokumentacji: 1000 stron kosztownego bełkotu mi tez przeszkadza. Ale brak dokumentu na temat tego kto i co ustalił dwa miesiące temu w przypadku gdy coś nie przeszło testu, szkodzi. Brak opisu logiki biznesowej oczekiwanej przez klienta i zdanie się na wyobraźnię programisty jest już bardzo złe i kosztowne.
Kolejna rzecz z perspektywy biznesu (zamawiający): to co developerzy nazywają Agile jest bardzo wygodne dla nich, bo w zasadzie nie podejmują żadnego ryzyka, jest loterią dla kupującego bo do samego końca nie wie co naprawdę otrzyma.
CMMI ma pewną zaletę: pozwala porównać firmy, zaś osiągnięcie np. poziomu 3 czyni projekty powtarzalnymi i bardziej przewidywalnymi. Nie twierdzę, że każdy kto nie ma najwyższego poziomu to kiepściuch, ale jeżeli czyjaś praca nie jest powtarzalna to ma biznesowy problem choćby z wycena oferty fixed price.
„Organizacje używające metod zwinnych mogą celować w CMMI na poziomie 5, ale nie dla każdego projektu i nie na podstawie recenzji ?Scrum for dummies?. – jeśli nie dla wszystkich projektów, to nie może być na poziomie 5. Zdaje się, że już 3 zakłada, że musi być stosowanie konsekwentnie dla wszystkich. Wydaje mi się, że Scruma można podciągać wyżej w CMMI, wymaga to jednak spełniania szeregu wymagań, które pewnie obciążyłyby zwinność realizacji i pytanie czy komuś zależałoby równie silnie na dwóch tych aspektach jednocześnie.
Zacytuję jednego z moich klientów (firma usługowa): „jeżeli Twoje projektu są prowadzone niepowtarzalnymi metodami pracy to znaczy, że nie masz żadnych podstaw by je wyceniać wcześniej niż po ich zakończeniu, więc jak składasz oferty?”
Ideologia powstała na podstawie wielu doświadczeń, które zaowocowały postulatami wychodzenia poza ograniczenia pierwszego pomysłu na sposób działnia organizacji: „są ludzie od myślenia i są ludzie od wykonywania”. Odrzuca podejście „tailorowskie” stwierdzające, że pracownik musi być dokładnie kontrolowany. W lapidarny sposób ujęte są tu doświadczenia psychologii pracy i zarządzania. To nie jest tak, że w 2001 dokonał się przełom. Wtedy pełzająca ewolucja zyskała formę pozwalającą na przeprowadzenie ogólnoświatowej rewolucji w rozprzestrzenianiu się wiedzy.
I jak to bywa z rewolucjami, lokalne kultury wpływają na osiągany kształt.
Traktowanie agile jako metodyki jest niebezpieczne, gdy polega na „zaoraniu” tego co działało wcześniej, albo na postawieniu sobie niskich celów. Otóż wyzwanie jest większe, bo:
– dopuszczamy robienie projektów, które w „klasycznym” podejściu mają niewielką szansę powodzenia – takie zachowanie wymusza rosnąca konkurencyjność
– uwzględniamy psychikę ludzi którzy wykonują projekt
– akceptujemy, że nie jesteśmy w stanie zdefiniować z góry wszystkich aktywności w projekcie; poza tym okazuje się to niepotrzebne – wystarczy wiedza, że wykonamy prawidłowe działania gdy zajdzie potrzeba
– zamiast gonić króliczka zakresu, pracujemy nad zaufaniem z klientem, który płaci za uzyskiwaną wartość biznesową; nie zawsze musi być to kontrakt time and material; kontrakt fixed price staje się w pewnym sensie „zakładem”, że osiągniemy sukces w danych ograniczeniach – sprawa trudna, ale wykonalna.
Sprawę dokumentacji rozwiązuje jedno proste stwierdzenie: dokumentacja też jest produktem projektu. System nieudokumentowany jest mało użyteczny. Ale też zakres i szczegółowość dokumentacji dobieramy do konkretnego zapotrzebowania, w tym planowanego czasu życia systemu.
Agile jest odzaływującą siłą, jak grawitacja. Wnioski wpływają na to w jaki sposób budowana jest komunikacja z klientem oraz wewnątrz zespołu projektowego, w jaki sposób dostajemy informację zwrotną. Wpływają na zdefiniowanie ról w projekcie, np. kierownika projektu. Świetnie systematyzuje współpracę analityka z zespołem.
Ale nie jest sprawą trywialną, „niższym poziomem”, wytłumaczeniem niedojrzałości organizacji.
Moim zdaniem wiara w to: „wykonamy prawidłowe działania gdy zajdzie potrzeba” rozłożyło już niejeden projekt bo potrzeby zachodziły a prawidłowości nie wyszły. Zwracam uwagę, że nie mówimy o start-upach i projektach typu R&D (te są niejako „zwinne” z zasady).
„Agile jest odziaływującą siłą, jak grawitacja”: co to znaczy z perspektywy zarządzania projektem?
Wiele projektów cierpi z powodu dużych kosztów zmian wymagań, wymagań osieroconych i wymagań odkrywanych dość późno w trakcie projektu; cierpi bo nie można się powołać na dokonane wcześniej ustalenia w sytuacji nieporozumień, złej woli (niestety świat nie jest idealny) czy zwykłej rotacji uczestników projektu (nie można tego wykluczyć). Jak sobie z tym radzą metody zwinne? Co się dzieje gdy klient zmieni developera?
” jeśli nie dla wszystkich projektów, to nie może być na poziomie 5. Zdaje się, że już 3 zakłada, że musi być stosowanie konsekwentnie dla wszystkich”
Może nie mogą się certyfikować. Jeżeli robię obok siebie projekt safety critical i infotaiment, to nie ma sensu stosować w nich tych samych standardów. Oczywiście szanuję podejście „Kliencie, nie zrobimy Ci tego projektu, bo wymagałby zastosowania metod, które nie są zgodne ze spisanymi w naszej organizacji”.
Nie musimy aż tak ironizować, rzecz w tym, że metodyki to przede wszystkim „listy kontrolne”, prosty projekt jednak nie musi oznaczać pomijania etapów (rezygnacji z metodyki). Owszem można powiedzieć, że usługi o wartości mniejszej niż 1 tys. PLN robimy bez pisemnej umowy na gębę ale każdy wie, że to podnosi ryzyko takiej współpracy. Ja np. zawsze wymagam zawarcia umowy na moje usługi w tym napisania „jak stwierdzimy, że umowę zrealizowano”. Owszem bywa, że zamiast umowy godzę się na email lub proste pisemne zlecenie, jednak nie godzę już się na prace na gębę, z uwagi na ryzyko choćby nieporozumień albo tego, że po stronie klienta zmieni się pracownik, który nadzoruje moją pracę (a bywało tak). Ta moja „dojrzałość” polega tu na tym, że ZAWSZE stosują swoją procedurę przyjmowania zleceń, ma ona jednak warianty. Co do zasady, jeżeli ktoś unika podpisania ze mną jakiegokolwiek zobowiązania, ja rezygnuję ze współpracy z uwagi na ryzyko. Podejście to sprawdza się bardzo dobrze i ja jestem widziany tak samo niezależnie od tego kto i kiedy pyta. Nie posądzam nikogo o złą wolę, ale jak ktoś mi nie znany ma opór przed zapisaniem czynionych razem ustaleń, to milcząco zakładam (analiza ryzyka), że potencjalnie ma zamiar nie wywiązać się z tych ustaleń, uczciwemu człowiekowi pospisywanie się pod obietnicą nie przeszkadza.
Bardzo ciekawy temat zaufania. Czyli jeżeli robimy projekt krytyczny dla firmy, to dokładnie specyfikujemy, a jeżeli możemy zaryzykować ewentualną stratę, to wystarczy wyznaczenie celów przy założeniu że wykonanie spełni oczekiwania obu stron?
no to zbliżamy się do wzajemnego zrozumienia 🙂 – ryzyko projektu decyduje o podejściu :).
Odpowiadając na pytanie: dlaczego? Agile to drukarka 3D: ponieważ nie wymagają dużego i drogiego rozbiegu oraz szybko weryfikuję koncepcję rozwiązania technologią i kompetencje wykonawcy.
Czyli maszyna do prototypów, problem w tym, że „wydruki 3D” to pozbawione jakiejkolwiek logiki działania atrapy, np. telewizor z takiej drukarki jak najbardziej pozwoli mi poznać zdolności estetyczne jego projektanta ale absolutnie nie upewni mnie ze cokolwiek na nim obejrzę 😉 i z ta metafora się całkowicie zgadzam.
Jest Pan w błędzie. Drukarki 3D produkują końcowe produkty stosowane np. w medycynie (protezy, zastawki serca), a za chwilę w armii USA jako przenośnie „magazyny” części do mi. broni. Obecnie technologia 3D jest w fazie optymalizacji kosztów.
Drukarki 3D pomału stają się widziane w przemyśle jako nowsza generacja obrabiarek numerycznych.
Są też próby drukowania elektroniki, ale chyba na razie telewizora Pan nie zobaczy 🙂
Ja uważam, że nie jestem w błędzie ;), drukarki 3D są stosowane do tworzenia elementów, których złożoność nie przekracza określonego progu złożoności. Osobiście drukarki 3D przyrównał bym do widoków CRUD – mogą być pracochłonne i wyrafinowane ale nie zawierają niemalże żadnej logiki. Drukarka 3D zapewne zrobi nam wyrafinowaną obudową telewizora czy komputera ale nie zrobi płyty głównej (którą i tak najpierw należy zaprojektować, jak wyglądała by zwinna metoda zaprojektowania i wytworzenia wnętrza komputera?)… Ja stale podkreślam, że nie wszystkie, ale jest wiele rzeczy (nie tylko oprogramowanie) gdzie „diabeł tkwi w środku”. Najlepszy nawet prototyp GUI nie zastąpi np. logiki motora systemu skoringowego… Podkreślam: najczęściej widuję porażki projektów „zwinnych” tam, gdzie „pod maską” była (oczekiwana) złożona logika biznesowa, tego nie da się udokumentować historyjkami użytkowników, bo to jak próba przekazania wiedzy o kodeksie drogowym metodą nakręcenia kilku filmów z przejazdu samochodem z domu do pracy i spowrotem. Wydaje mi się, że często agile cierpi z powodu wiary w to, że logika wynika z procesu a jest dokładnie odwrotnie: proces jest wynikiem (skutkiem) logiki i ograniczeń (reguły gry w szachy są jednej, partii nieskończenie wiele i możemy zapisać tylko ich mała ich część), dokładnie tak jak kodeksie drogowym: to jak jedziemy zależy od przepisów. I teraz CMMI: jeżeli spotykają się dostawca i odbiorca o dwóch różnych kulturach podejścia do prowadzenia projektu będą tarcia. Niestety w większych projektach, czyli takich w których złożoność logiki systemu jest duża, żadne historyjki ani prototypy nie przekażą wiedzy o tej logice, metody bazujące na spotkaniach i burzach mózgów się po protu tu nie sprawdzają.
Mętne określenie „określonego progu złożoności”.
Tak jak napisałem są pierwsze próby drukowania elektroniki – mi. komputerowych płyt głównych. Drukarki 3D nadają się świetnie do budowania złożonych produktów, których obecnie łatwo nie możemy zbudować – np. struktury zawierające w sobie inne struktury.
A wracając do IT:
Pan utożsamia Agile z „historyjkami użytkowników” to tak samo jakbym napisał, że UML to tylko Use Case.
„Wydaje mi się, że często agile cierpi z powodu wiary w to ..”
Agile jest konsekwencją tego, że 70 – 99% każdej aplikacji to interakcja z człowiekiem: GUI, mail, oczekiwanie na akcje, alarmowanie.
Oczywiście, że prototyp GUI nie zastąpi np. diagramu BPMN. Twórcy Agile zauważyli, że zamiast tworzyć diagramy i opisy słowne, aby przekazać, że dokument, czy raport będzie zawierał 5 – 6 konkretnych pól, lepiej zrobić prototyp. Jest to szybsze i lepiej zrozumiałe dla klienta.
A czymże jest sławetna „logika biznesowa”? To naprawdę nic magicznego, ale często, bardzo trudno ekstraktowalnego z organizacji klienta. I na tą trudność odpowiada Agile poprzez prototypy, które ułatwiają komunikację z klientem – często uświadamiają jego własne procesy. 1 obraz jest wart 1000 słów, a 1 prototyp 1000 diagramów 🙂
Reasumując: budowanie jakiejkolwiek aplikacji to proces z wbudowaną dynamiką interakcji z klientem. Prototypowanie (Agile) ułatwia komunikację i znacząco skraca czas i koszty projektu.
Można też zaryzykować stwierdzenie, że Agile jest bardziej wymagający od wykonawcy (komunikacja, znajomość dziedziny, odpowiedzialność) niż tradycyjne metodyki. Konieczne jest te zastosowanie innych narzędzi programistycznych.
„Określony próg złożoności” nie jest mętne, to ten moment, gdy liczba szczegółów przekracza możliwości ich zapamiętania. UML to kilkanaście typów diagramów, pomijając to czym są, służą do „zapamiętywania” i „odczytywania” ale to dopiero obrazki. Jeżeli uznamy ich formalizm, stają się dodatkowo narzędziem modelowania systemu, weryfikacji spójności i kompletności.
Różnica pomiędzy modelami UML a prototypami wykonanymi przez programistę jest taka jak pomiędzy rysunkiem technicznym a „domem postawionym na próbę”…
„[logika biznesowa] nic magicznego, ale często, bardzo trudno ekstraktowalnego z organizacji klienta”, być może nawet 90% to interakcja człowieka z systemem (podobno logina biznesowa to maks. 3% kodu), nie zmienia to faktu, że bez tych poprawnych 10% „sławetnej logiki biznesowej” całe GUI jest tak przydatne jak piękny panel kompuera bez płyty głównej w środku.
„Można też zaryzykować stwierdzenie, że Agile jest bardziej wymagający od wykonawcy (komunikacja, znajomość dziedziny, odpowiedzialność) niż tradycyjne metodyki. Konieczne jest te zastosowanie innych narzędzi programistycznych.” Jakich innych narzędzi programistycznych? Komunikacja to proces wymagany w każdej metodzie pracy, odpowiedzialność to także rzecz konieczna, mitem jest wymagana znajomość dziedziny, bo system sprzedaży zaprojektuję na bazie analizy dokumentów i stosownych ustaw, zaś tylko na bazie „komunikacji z userem i prototypów” powstają kosztowne buble, które metodą prób i błędów, wymagają kilkunastu podejść by nadawały się do czegokolwiek o ile w ogóle tą metodą powstaną.
Proponuję zakończyć dyskusję w tym miejscu… bo jeszcze wyda się, że mam dużo pracy właśnie dzięki temu, że przede mną ktoś próbował np. napisać system zarządzania warunkami złożonych umów outsourcingowych metodą „prototypowania”… i nie dane mu było skończyć bo biznes oczekuje deklaracji „terminu i budżetu” a nie obietnicy, że „dołożymy wszelkich starań”…
Pojawiały się już tu zdania o tym, żeby stosować odpowiednie metody do sytuacji. Jeżeli biznes musi mieć plan, który będzie „toćka w toćkę” realizowany, trzeba zastosować inne metody niż dla zdobywania nowego rynku. Znaczy to też, że metody lekkie i klasyczne mają się uzupełniać, a nie ze sobą konkurować. Są tylko metody złe i dobre w danym kontekście. To ludzie stosują je w sposób nieprzemyślany, kierując się modą, pogłoskami albo chęcią zabezpieczenia swoich pleców – nawet kosztem klienta.
Dziękuję za okazję do przemyśleń. Drukarki 3d najlepiej nadają się do wywoływania myślenia nieszablonwego 😉
Niewątpliwie należy się zgodzić z tym, że „Są tylko metody złe i dobre w danym kontekście.”. Niewątpliwie zabezpieczanie pleców jako cel, jest czynnikiem szkodliwym. Co ciekawe – nikt tu o tym nie wspomniał, że w procesie projektowym na początku ważne jest określenie wymagań, ale nie na rozwiązanie – to potem, a na metodę zarządzania projektem, bo zgadzam się, że metod jedynie-słusznych nie ma.
Kolejny często popełniany błąd polega moim zdaniem na pomijaniu tego, czy „nowe oprogramowanie” jest nowym narzędziem pracy czy zupełnie nowym produktem na rynek! Nowe produkty to nic innego jak R&D, tu już nie raz zostało powiedziane, że metody zwinne mają jak najbardziej sens. Jednak jeżeli celem projektu jest wytworzenie narzędzia dla biznesu, to nie ma tu mowy o R&D tylko jest analiza, wymagania i projektowanie a potem realizacja (jest ogromna różnica pomiędzy np. napisaniem nowej gry komputerowej a napisaniem programu wspierającego jej przemyślaną sprzedaż).
Ja także dziękuję za zwracanie mi uwagi na te elementy, które pomijam „z nawyku”. Co do szablonowości myślenia zaś, to nie wiem czy mowa o samej drukarce czy tym co ona „drukuje”, bo to drugie ktoś musi najpierw dobrze zaprojektować :).