Nie jestem zwolennikiem klasycznego, kaskadowego procesu projektowania i wytwarzania oprogramowania. Preferuje proces podobny do kaskadowego, z prototypami odrzucanymi, jednak prototypem jest u model (projekt) a nie żywy kod. Proces taki opisuje np. metodyka MDA (więcej na stronie OMG, przyjdzie pora i na niego tu). Jednak propaganda mówi, że jak “powszechnie wiadomo”…
…model kaskadowy skazuje klienta na długi czas oczekiwania na efekt końcowy. Bardzo dużo czasu pochłaniają analizy przedwdrożeniowe i szczegółowe projekty, a ich wynik jest widoczny wyłącznie ?na papierze?. (za Scrum eliminuje słabości tradycyjnych metod wytwarzania IT).
I od razu do rzeczy. Powyższe nie jest prawdą. Badania projektów pokazują coś zupełnie odwrotnego:
Jak widać, poprawna (o takiej tu mowa) analiza wymagań, skraca czas implementacji (projektowanie i wykonanie) o ponad połowę. Po drugie owe zwinne iteracje to nic innego jak odkrywanie wymagań metodą prób i błędów, co jest czasochłonne i kosztowne, co widać na powyższym diagramie (pokazuje on statystyki ukończonych projektów).
A co jest prawdą?
To, że ów czas trwania projektu jest długi, to najczęściej efekt zbyt dużego zakresu tego projektu a nie tej czy innej metodyki. Po prostu system mający 200 planowanych cech funkcjonalnych będzie budowany długo nie dlatego, że wybrano “kaskadową metodykę” tylko dlatego, że “jest duży”.
Cytowany artykuł (zachwalający metodykę SCRUM) wskazuje na kilka “wad” analizy i projektowania, zobaczmy co tu jest wadą…
Ryzyko uzyskania nieadekwatnego rozwiązania ? model kaskadowy skazuje klienta na długi czas oczekiwania na efekt końcowy. Bardzo dużo czasu pochłaniają analizy przedwdrożeniowe i szczegółowe projekty, a ich wynik jest widoczny wyłącznie ?na papierze?.
- Z punktu widzenia klienta, analizy to bardzo istotny koszt, który długo się zwraca ? klient płaci za doradztwo, często nie widząc żadnego realnego rezultatu poza dokumentami. Skomplikowane i złożone projekty to dla organizacji wielka odpowiedzialność, tymczasem w podejściu kaskadowym im bardziej złożone projekty, tym mocniej rośnie ryzyko związane z rezultatem końcowym.
- Przy zastosowaniu Scrum takie ryzyko praktycznie nie istnieje. Obie strony wiedzą, że w okresie współpracy mogą wypracować rozwiązanie, którego nie można było przewidzieć na początku projektu. Przy tym zwinnym podejściu coś takiego jak ostateczna definicja finalnej wersji produktu na początku projektu nie istnieje.
I to jest ten moment, gdy ja pytam: na co zawarto umowę i z czego jest rozliczany dostawca? Tak więc dostawca jest praktycznie bezkarny, bo może dostarczyć cokolwiek… jak nazwać to ryzyko? Po drugie krytyka procesu analizy jako zbędnego pożeracza czasu i środków wymagań nijak się ma do praktyki, co pokazuje przytoczony na początku wynik badań.
I dalej:
Opóźniony rezultat ? celem IT bardziej niż kiedykolwiek wcześniej jest dziś wspieranie biznesu w jego codziennych działaniach i szybkie reagowanie na dynamiczne zmiany w otoczeniu biznesowym. W modelu kaskadowym na rezultat projektu czeka się długo, ponieważ określa go pełna, finalna wersja produktu.
Dobry projekt ma wizję i etapy. Każdy etap to ograniczona liczba funkcjonalności, możliwych do dostarczenia w czasie wymaganym przez biznes. Nie widzę powodów, by działające podsystemy dostarczać np. kwartalnie, i tak się dzieje.
Bardzo mała elastyczność podczas projektu ? biznes ulega ciągłym zmianom, co w oczywisty sposób pociąga za sobą zmiany oczekiwań dotyczących funkcjonalności zamawianego oprogramowania. Model kaskadowy kontraktuje projekt na etapie analiz (lub nawet wcześniej), po czym obu stronom trudno jest bez ryzyka wnosić istotne zmiany do zaplanowanych prac.
Po pierwsze nie wiem skąd autor wziął tezę o tym, że “Model kaskadowy kontraktuje projekt na etapie analiz (lub nawet wcześniej”. Model kaskadowy nie ma tu nic do rzeczy. Dobra umowa zawiera zakres projektu, a projekt ma cel biznesowy, i nie powinno nim być zatrudnienie programistów na kwartał po jakiejś stawce, a wytworzenie czegoś konkretnego i nazwanego w konkretnym czasie.
System, w którym implementację poprzedza analiza i projektowanie dzieli się na etapy jak każdy inny. Po drugie nie prawdą jest, że kontraktuje się od razu całość. Dobry projekt ma oddzielony etap projektowania od wykonania, kluczem jest raczej to na jaki zakres “rzuca się”, zamawiający.
Potencjalnie większe koszty ? w projektach IT liczy się nie tylko zwrot z inwestycji (ROI), ale też czas, w jakim poniesione inwestycje zaczynają się zwracać.
Tu odnoszę wrażenie, że autor nie rozumie co napisał albo jest to błąd redakcyjny… zwrot z inwestycji to zysk w czasie, więc nie ma znaczenia nic poza całkowitym kosztem i czasem w jakim go liczymy.
Biznes jest dziś tak dynamiczny, że dużą korzyścią jest dla niego względnie szybki dostęp do dostatecznie dobrych rozwiązań. W podejściu kaskadowym czas oczekiwania na finalny produkt jest bardzo długi.
Kolejna nieprawda, czas oczekiwania jest dokładnie taki jaki zaplanowano… można planować podział dużego projektu na podsystemy (jak wyżej).
Duże ryzyko złych relacji ? model kaskadowy z założenia dzieli obie strony kontraktu na dwa obozy: dostawcy i odbiorcy rozwiązania.
To ciekawostka, nie wiem skąd autor wysnuł taki wniosek….
Marnotrawstwo czasu i pieniędzy przez biurokrację ? praca oparta na częstych iteracjach i powtarzalnym procesie (sprintach) pozwala bardzo szybko identyfikować niedoskonałości specyfikacji i luki w pierwotnej koncepcji. Strony mogą szybko zorientować się, że na etapie przygotowawczym np. nie wzięto pod uwagę istotnych komponentów lub interfejsów. W modelu wodospadowym wnoszenie zmian wiąże się najczęściej z pisaniem aneksów i renegocjowaniem kontraktu.
Kolejna nieprawda. częste iteracje to częste poprawki projektu w poszukiwaniu “właściwego rozwiązania”. Takie same iteracje robi analityk na etapie analizy i projektowania, tworząc projekt “na papierze”, rzecz w tym, że analityk na papierze robi to sam w ciągu pojedynczych godzin a zespół programistów robi to kilka dni kosztem kilkunastu “osobodniówek” tego zespołu. Koszty i czas łatwo sobie porównać…
W Scrum wszystkie niedopatrzenia można natychmiast uwzględnić na każdym etapie realizacji projektu, bez konieczności uruchamiania niewygodnej dla obu stron, i często burzącej relacje biznesowe, procedury obsługi zmian (Change Requests). Jeśli podejście służy projektowi, a tak jest w przypadku Scrum, dostawca i odbiorca elastycznie dopasowują się do siebie niezależnie od tego, jak dalece zmieniają się oczekiwania i potrzeby biznesowe.
Jeżeli autor uważa, że wprowadzanie ad-hoc nieformalnych zmian w zakresie projektu czyni projekt lepszym, to pozostawiam go z tym przeświadczeniem.
Scrum polega na wspólnym widzeniu celu, jakim jest rozwiązanie konkretnego problemu biznesowego. Jest to często dalekie odejście od sztywnej interpretacji zapisów kontraktowej specyfikacji wymagań, które same w sobie narzucają zespołom projektowym ograniczenia realizacyjne (techniczne) niezależnie od problemu jaki jest rzeczywiście do rozwiązania. Zaletą Scrum jest przejrzystość i wysoka elastyczność projektu.
Tu przytoczę słowa mojego kolegi prawnika:
Największym problemem sporów przed sądem, w sporach z firmami programistycznymi jest to, że wiele tych firm niczego nie dokumentuje i tak na prawdę nie wiadomo o co toczy się spór. Większość takich spraw zakładają pokrzywdzone firmy, nabywcy usług programistycznych. W zasadzie większość tych spraw, te firmy właśnie przegrywają, bo nie wiadomo co miało powstać a wiadomo ile miało kosztować. Tu sądy są bezsilne… wygrywają programiści, mając pieniądze mimo, że nie osiągnięto celu zamawiając. Ale winni są sobie wyłącznie zamawiający, godzący się na taką treść tych umów…
A co mówią statystyki?
Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com).
Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). I niech nikt mi nie mówi, że 29% to same SCRUM’y a pozostałe 71% to “kaskadowe” projekty bo to nieprawda.
Na zakończenie
Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych… Państwo sami muszą wybrać… Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających “kastomizacji” bo to (nowe funkcjonalności systemu) także projekt dedykowany.
Z większością Pana komentarzy nie zgadzam się, ale 🙂 też cytowany artykuł nie jest do końca trafny.
Zgadzam się całkowicie z tym : “71 percent of software projects that fail do so because of poor requirements management, ..” i uważam, że problem leży po stronie klienta – który często nie wie czego chce – i dostawcy – który prawie zawsze nie potrafi pomóc klientowi. I nie pomogą stwierdzenia : “Dobry projekt ma oddzielony etap projektowania od wykonania, kluczem jest raczej to na jaki zakres ?rzuca się?, zamawiający” jeśli obie strony rozumieją “inaczej”. Jedynie co pomaga to prototypowanie, a w projektach prowadzonych zwinnie prototypowanie dziej się ciągle 🙂
Przy pewnym “konflikcie” interesów między dostawcą (chce zrobić to na co się umówił) i zamawiającego (chce produkt, który będzie działał) model kaskadowy służy jedynie temu pierwszemu, ponieważ porusza się w znanej sobie terminologii i technologii, a dla zamawiającego to często coś prawie jak magia 🙂 – jak to bodajże A.Clark napisał: “Każda dostatecznie zaawansowana technologia niczym szczególnym nie różni się od magii”. Zamawiający zaś może w łatwy sposób zweryfikować czy prototyp odpowiada jego wyobrażeniom i potrzebom. Znaczna większość klientów nie chce projektu, nawet nie chce analizy oni oczekują działającego produktu.
Parafrazując ostatnie zdanie: znaczna większość pacjentów nie chce chodzić do lekarza i badać się, chcą od razu właściwe pigułki i być zdrowi …
Ponawiam pytanie: co jest przedmiotem umowy na wykonanie oprogramowania? “Na co się umówił dostawca”?
Moim zdaniem porównanie do lekarza nie jest trafne – chyba, że rzeczywiście klient “upadł na głowę” i chce kupić co jest mu nie potrzebne :). Mimo to postaram się na tym porównaniu wyjaśnić. Znacznej większości pacjentów nie chodzi o robienie badań (mówię tu o zdrowych na umyśle :)) i odwiedzaniu szpitali, nawet nie chcą właściwej pigułki, ale chcą być zdrowi. Nauczyliśmy się, że pewien trud trzeba wykonać (badania), aby lekarz mógł wykonać swoją pracę dobrze, ale kiedyś wierzyliśmy, że upuszczanie krwi jest konieczne :). Ja twierdzę, że podejście z “twardą” umową, kaskadowe, czy też z rozbudowaną dokumentacją są “upuszczaniem krwi”.
Jeszcze inaczej – jako, że znam blisko kilku lekarzy to jestem na bieżąco 🙂 – pewna ilość pacjentów koniecznie prosi o wykonanie pewnych badań, bo tak sobie wymyśliła, albo im ktoś powiedział, że trzeba je zrobić – lubią ten trud (tworzenia dokumentacji). Dobry lekarz odmawia, tłumaczy, edukuje, czy też wręcz opierdala za głupotę :), zły kasuję kasę z uśmiechem na ustach :).
Ad.?Na co się umówił dostawca??
Jak się umówił na zrobienie papiera to niech robi i klient ma problem bo celem jest papier, a nie działający system i tyle. Jak obie strony chcą się umówić na działający system to spisują funkcje, założenia, opis efektu końcowego i jedziemy. Po co generować tony dokumentacji? Nie lepiej weryfikować prototypem? Mitem jest, że każda zmiana oprogramowania jest kosztowna. Najbardziej kosztowna zmiana wynika z niezrozumienia przy opisie funkcji, założeń, czy efektu końcowego w umowie. Dlatego robi się prototypy i piloty. Dokumentacja w niczym nie pomoże, ponieważ trzeba ją zrozumieć. A nawet jeśli zamawiający włoży ten wysiłek i przeczyta ją, i niezależnie od tego ile wysiłku włoży to i tak zrozumie inaczej niż my 🙂
Koszt zmiany zależy od kompetencji dostawcy i jakości wykonania oprogramowania. Czym bardziej doświadczony wykonawca tym lepiej i wcześniej przewidzi problemy. Czym lepszy kod tym bardziej elastyczny. Czym wyższy poziom kultury technicznej tym sprawniej idzie projekt. I barokowa dokumentacja nic tu nie pomoże, a wręcz będzie przeszkadzać i opóźniać.
Podsumowując: Uważam dokumentację za niezbędną, ale w stopniu koniecznym do zaplanowania i wykonania oprogramowania oraz z ograniczeniem narzuconym na czas i objętość. 🙂 Czyli jak wychodzi za duża to coś jest źle. Wolę jeden dobrze przemyślany (ale bez wszystkich szczególików) diagram, niż 200 stronicowy szczegółowy opis. A słabość w tradycyjnych metodach wytwarzania w IT widzę właśnie w niezwracanie uwagi ma ludzi, który w tym procesie uczestniczą. Nie brane są pod uwagę jakie możliwości percepcji mają tworzących dokumenty i czytających dokumenty, jak pojmują pewne sprawy ludzie po stronie biznesu i po stronie IT (np. programiści).
Te wszystkie elementy są uwzględniane w metodykach zwinnych – nietradycyjnych 🙂
Co do lekarza, badania są nie po to by je wykonać a po to by lekarz zyskał wiedzę o tym “z czym walczy” (wywiad z pacjentem nie zastąpi badania krwi…). Ale do rzeczy: skoro jednak należy opisać “funkcje, założenia, opis efektu końcowego” to jednak dokument wymagań powstaje, pytanie brzmi: jak powstaje ten dokument? Wracając do polegania tylko na ludziach: co powstanie i jak przeżyje to firma jeżeli np. nowy system wynagrodzeń powstanie na bazie wywiadów i życzeń pracowników? Związki zawodowe tu to pikuś…
Ad.”jak powstaje ten dokument?”
A czy to ma znaczenie? Ważne jest, aby obie strony tak samo go rozumiały i podpisały.
Ad.”Wracając do polegania tylko na ludziach”
Nie “tylko”, ale głównie – to różnica.
“co powstanie i jak przeżyje to firma jeżeli np. nowy system wynagrodzeń powstanie na bazie wywiadów i życzeń pracowników?”
Pyta się zamawiającego (sponsora, inwestora), a nie pracownika 🙂
Odnosząc się do przykładu powtórzę jeszcze raz: jeśli zamawiający chce byśmy sami znali przepisy, popytali pracowników i przygotowali papier – no to robimy to i tyle. Jeśli zamawiający mówi zróbcie system naliczający płace i załóżmy, że ma być to tak jak teraz. No to prosimy o dokumentację tego “teraz” i/lub eksperta od klienta, który zezna jak jest teraz i co jest istotne. Mamy notatkę ze spotkania (lub spotkań) i to jest wkład do umowy.
Jest bardzo ważne “jak powstał ten dokument” bo sposób jego wytworzenia świadczy o jego wiarygodności… Widzę światełko w tunelu: “Pyta się zamawiającego (sponsora, inwestora), a nie pracownika”. Kolejne pytanie: który plan miasta będzie wiarygodniejszy: ten na bazie wywiadów z jego mieszkańcami (nawet jeśli jednym z nich będzie Burmistrz, sponsor projektu) czy ten ba bazie pomiarów i zdjęć lotniczych?
Pytanie dodatkowe: sponsor zamówił “korbę”. Co jest lepszym załącznikiem do umowy na jej wykonanie: rysunek korby czy jej słowny opis (proponuję w ramach ćwiczenia wykonać słowny opis korby bez użycia słowa KORBA).
“który plan miasta będzie wiarygodniejszy: ten na bazie wywiadów z jego mieszkańcami”
Nie rozumiem związku ,ale oczywiście ten ostatni 🙂
“Co jest lepszym załącznikiem do umowy na jej wykonanie: rysunek korby czy jej słowny opis”
Nie wiem czy dobrze zrozumiałem przytoczone przykłady:
Czyżby się Pan zaczynał ze mną zgadzać?
W rewanżu proszę zrobić zdjęcie korby od strony rączki i sprawdzenie na ile jest warte 🙂 Podpowiem: widać będzie kółko i drążek.
Przykład z korbą, ćwiczyłem wiele lat temu i moim zdaniem w kontekście dyskusji niczego nie dowodzi. No cóż dla mnie truizm: obraz więcej znaczy niż opis i … działanie znacznie więcej znaczy niż opis działania 😛
Dochodzę do wniosku, że zgadzamy się co do tego, że jednak coś jest planowane, że jednak rysunek lepszy od prozy. Problem chyba tu jest taki, że jeżeli ktoś (być może Pan) miał do czynienia z opisami wymagań w postaci steku niespójnej prozy pisanej rękami zamawiającego lub będącego zapisem (dyktafon?) wywiadów to można takie analizy znienawidzić. Jeżeli miał Pan do czynienia ze stertami bezsensownych diagramów to także można można je znienawidzić. Co do korby, owszem dlatego każdy projekt robi się z kilku perspektyw (przekroje) i wtedy jest OK. Co do zaś “działanie znacznie więcej znaczy niż opis działania” to ja jednak wyznaję zasadę: “najpierw pomyśl potem rób”… Być może się nawet zgadzamy…. proponuje spojrzeć na to https://it-consulting.pl/2020/12/11/analiza-biznesowa-od-zlecenia-do-kompletnego-projektu-technicznego-z-uzyciem-narzedzia-case/ to mała namiastka czegoś co moim zdaniem jest jednak lepsze od “działania zamiast pisania”….
Ad.”…postaci steku niespójnej prozy pisanej rękami zamawiającego…” “… ze stertami bezsensownych diagramów…”
Miałem do czynienia, (nie dziwiłem się :)) nie chodziło mi o tego rodzaju dokumentację. Chodziło mi np. o dokumentacje, której przygotowanie trwało kilka-kilkanaście miesięcy, wielostronicową, do której dostaję dopisek, “ale to już się u nas zmieniło” 🙂 Albo dokumentację, wg której aplikację klient skwitował stwierdzeniem: “no tak podpisałem papier, ale ja to sobie wyobrażałem inaczej, czytając ten papier”.Zaglądamy w papier i rzeczywiście można to też zrozumieć w sposób w jaki zrozumiał klient 🙂
Ad.http://modelowaniebiznesowe.biz.pl/CaseStudy%20Biblioteka.pdf ta dokumentacja nie wydaje mi się mocno nadmiarowa (na etapie już uruchomionego projektu), ale -z mojego doświadczenia – niestrawna dla większości zamawiających. Ale widzę jej zastosowanie w komunikacji w zespole.
Aby powiedzieć, czy jest ona ok. brakuje tu elementu czasu, tzn. ile czasu zajęło przygotowanie tego rodzaju dokumentu. Czas jest bardzo ważnym elementem w metodach zwinnych, ponieważ decyduje często o przyjętej strategii.
No to widzę nic porozumienia :). Po pierwsze zgadzam się, że jeśli dokumentacja powstaje dłużej niż kwartał jest z zasady bezużyteczna. Zgadzam się, że jeżeli jej koszt dorównuje kosztowi systemu nie warta jest wykonania. Tu mogę powołać się na słowa trenera jednego ze szkoleń: dobrze opracowany system jest oddawany jako pierwsza iteracja, jego implementacja (lub jeden użyteczny komponent) powinna mieścić się w kwartale, opracowanie projektu zaś powinno trwać nie dłużej niż kwartał i kosztować nie więcej niż 20% całości (nie mówię tu o kosztach uzyskania wydajności czy niezawodności). Co do dokumentu Biblioteka to mam minimalne oczekiwania od zespołu implementującego: znajomość i rozumienie obiektowych narzędzi, znajomość UML, znajomość wzorców projektowych, ktoś musi być tam dobrym architektem. Czas opracowania dokumentu takiego (objętość) jak owa Biblioteka dla mnie jednego to jeden dzień na wywiady i jedne na opracowanie. Po drodze ma miejsce prezentacja dla klienta (ten nie zna ani UML ani innych rzeczy) wiec ja recytują a klient słucha, zgłasza uwagi lub akceptuje.
Kluczowe jest: “oczekiwania od zespołu implementującego” i “dla klienta (ten nie zna ani UML ani innych rzeczy)”
Przykład jest trywialny :), dlatego sztuką jest robić w takich ramach czasowych projekty nietrywialne. A to umożliwia podejście zwinne – nietradycyjne. Przy podejściu tradycyjnym, trzeba udawać, że dzielimy projekt na podprojekty lub etapy itp.
rozumiem, że 100 przypadków użycia SCRUM załatwia w dwa dni?
“rozumiem, że 100 przypadków użycia SCRUM załatwia w dwa dni?”
To jest przesadne uproszczenie wręcz złośliwe spłycenie :). Odpowiem krótko: nie 🙂
To próba testowania tezy na skrajnych danych…
Taki dziwny test. Tak jakby Pan chciał testować odporność zegarka na wstrząsy podkładają pod pracę o nacisku 1T/cm2 i zdziwił się, że nie wytrzymał 🙂 Ani to nie wstrząs, ani nie adekwatne obciążenie do rzeczywistość.
Ani SCRUM (czy inna metodyka) niczego nie załatwia, ani też nie adekwatne jest to rzeczywistości projektowe. Jak dla mnie czysta złośliwość 😛
ten test to co innego: jeżeli testuje system to w ramach scenariuszy testowych podrzucam także dane nielogiczne, sprzeczne itp. który system powinien odrzucić bez “zawieszania się”, jeśli tego nie zrobi to nie przeszedł testów… tak więc prośba wystawienia faktury VAT (lub przelewu w banku) w systemie na kwotę 3 mld. powinna wygenerować co najmniej kilka dodatkowych pytań… to nie złośliwość tylko testowanie hipotez (dobra teoria powinna definiować sytuacje, które ją obalają jeśli wystąpią, polecam Karl Popper i falsyfikację).
“który system powinien odrzucić bez ?zawieszania się?, ”
Metodyka to nie system.
BTW: W tradycyjnych metodykach nie ma scenariuszy.
są w tych, które ja stosuję…
“są w tych, które ja stosuję?”
Niestety nie znam takiej. Czy mógłby się Pan podzielić o jakiej metodyce Pan mówi?
proponuję sprawdzać terminy szkoleń i konferencji na jakich mam referaty.. tu niestety nie widzę miejsca na szkolenie a i czas nie pozwala…
Mhh, jeśli jest to niestandardowa metodyka, to w takim razie to nie jest żaden argument:?są w tych, które ja stosuję?? 🙂
Ponieważ przy takim podejściu, można sobie wyobrazić dowolną kombinację elementów z dowolnej puli metodyk i w ten sposób udowodnić dowolną teorię przemawiającą za lub przeciw tradycyjnych czy też nietradycyjnych metodyk.
W tym przypadku zastosował Pan elementy (scenariusze) metodyk nietradycyjnych to Pana metodyka na pewno nie jest tradycyjna 🙂 Dowolność stosowania lub nie stosowania różnych elementów metodyk jest właściwa metodykom nietradycyjnym (zwinnym) 😛
to nie jest nic niestandardowego… proponuję http://www.omg.rog/mda oraz literaturę na temat prototypownia z pomocą modeli …
MDA nie jest metodyką i nie ma scenariuszy. Opierając się w dużej części na UML, posiada Use Case, ale to coś innego niż scenariusz. Nie jest moją intencją popychanie dyskusji w kierunku “spierania się o wyższość świąt …”. Właściwie to nie wiem jaki jest cel tej dyskusji 🙂 Ja twierdzę, że tradycyjne metodyki są niedobre (głównie z powodu kaskadowego rozłożenia w czasie ), a Pan też wypowiada się o nich niepochlebnie w pierwszych słowach artykułu 🙂 Mylące jest tylko to, że MDA nie jest metodyką. MDA najbardziej brakuje metod zarządzania procesem (w czasie) i zespołem.
moim zdaniem kaskadowość czy agilność to nie problem, jak się to robi, problem w tym czy robi się to w sposób sformalizowany czy nieformalmalny-swobodny… metody nieformalne są nieweryfikowalne, skutki znamy dopiero widzą produkt, w metodach sformalizowanych potencjalne skutki widać na modelach, czyli szybciej i taniej….
Dziwne ostatni mój post nie pojawił się 🙂
Krótko: MDA to nie metodyka i tu jest pies pogrzebany 🙂 Brakuje w niej zarządzania procesem (w czasie) i zespołem.
Metodyka to zbiór metod, MDA jest metodą… zarządzanie procesem a proces… gdzie granica? Proponuje zapoznać się z “procesem analizy systemowej”. Proces ten zawiera etap budowania i testowania modeli, a model w analizie systemowej jest hipotezą “takie rozwiązanie spełni wymagania”, budujemy scenariusze testowe i badamy model. Model (tu np. stosowne diagramy UML), który przejdzie testy staje się projektem oprogramowania, które ma powstać. Więcej o tym napisałem w jednym z poprzednich postów.
“Metodyka to zbiór metod, MDA jest metodą? zarządzanie procesem a proces? gdzie granica? Proponuje zapoznać się z ?procesem analizy systemowej?.”
Proszę nie uciekać w teoretyzowanie 🙂
Odwołuje się Pan do “kaskadowego procesu projektowania i wytwarzania oprogramowania”, a nie można mówić o MDA w tym kontekście, ponieważ ten sposób projektowania aplikacji nie posiada w sobie opisów zarządzania procesami wytwarzania jak i samego procesu wytwarzania.
Nie mam nic przeciwko MDA – śledziłem i kibicowałem jej powstaniu 🙂 – nawet zrobiłem jeden, czy dwa projekty stosując MDA. Ale to całkowicie coś innego niż np. Price, PMBok, Scrum, Kanban.
Proszę spojrzeć na trójkąt projektowy zakres+budżet+czas. MDA wspiera częściowo “zakres” i “budżet”. Częściowo “zakres” ponieważ nie wspiera dystrybucji zakresu w zespole. Oczywiście można się jakoś umawiać kto co robi, ale tego nie ma w tych “metodach”. “budżet” wspiera ponieważ jest on w dużej części pochodną “zakresu”.
proces zarządzania projektem to proces, proces analizy systemowej to także proces… nie sprowadzał bym wszystkiego do procesu zarządzania i “świętego trójkąta”. Czego nie ma w ‘tych metodach” a powinno? Po drugie dzielenie wszystkiego na “zarządzanie projektem” i “jakieś inne mało ważne rzeczy” prowadzi na manowce, najlepszy kierownik projektu i proces zarządzania nim nie stworzy ani projektu ani oprogramowania, bo robią to analitycy, projektanci, architekci i programiści. Kierownik projektu i “project management” są ważni ale oni są dla projektu a nie odwrotnie. Jeżeli jest możliwe by programista napisał program bez PM’a, tak w drugą stronę to nie działa. Po drugie, całym szacunkiem ale MDA ma się PMI czy Prince2 jak pięść do nosa…
“proces zarządzania projektem to proces, proces analizy systemowej to także proces? nie sprowadzał bym wszystkiego do procesu zarządzania i ?świętego trójkąta?”
Nie sprowadzam. Jedynie staram się Panu pokazać, że proces analizy to tylko jeden z elementów metodyki prowadzenia projektów. Nie można porównywać zielonych samochodów z ogórkami 🙂 – narzędzi do analizy (np.MDA) i metodyk zarządzania/prowadzenia projektów (metodyki zwinne, kaskadowe).
“Po drugie dzielenie wszystkiego na ?zarządzanie projektem? i ?jakieś inne mało ważne rzeczy?”
Nigdzie tego nie dzielę – rozróżniam.
“Kierownik projektu i ?project management? są ważni ale oni są dla projektu a nie odwrotnie.”
Nie mieszajmy jeszcze PMów 🙂 to inna bajka.
“Po drugie, całym szacunkiem ale MDA ma się PMI czy Prince2 jak pięść do nosa?”
I tu się z Panem zgadzam – o to mi chodziło. Dodam, że podobnie MDA ma się do metodyk Agile (np.SCRUM, Kanban, MSF for Agile) 😛 I jeśli nie ma Pan nic przeciwko, to możemy tym podsumowaniem skończyć dyskusję 🙂
“proces analizy to tylko jeden z elementów metodyki prowadzenia projektów” Nie, analiza to, jak każde inne eksperckie działanie, jakaś praca, nie raz proces ciągły. Może być elementem projektu (w rozumieniu zakresu, terminu i budżetu) ale nie musi. W szczególności analizy prowadzone na zasadzie czas i materiał (np. w działach R&D), nie mają terminu i zakresu (czasami mają termin). Większość analiz to badanie “do skutku” a nie projekty. O projekcie można mówić jak posiadamy jego zakres (co należy dostarczyć), budżet i termin. Analiza i projektowanie to proces, którego produktem jest zakres dla projektu. Mam wrażenie, że mylone tu jest zarządzanie projektami, które to jest czynnością menedżerską, z analizą i projektowaniem co jest czynnością bliższą nauce. MDA nie ma nic wspólnego z zarządzaniem projektami. Podobnie jak proces zalewania fundamentów betonem nie jest projektem, projektem jest zadanie wylania konkretnego fundamentu w konkretnym czasie i budżecie. Stąd moje zdziwienie z porównania MDA z zarządzaniem projektami i cały ten spór (wymiana zdań ;)) i to faktycznie może spokojnie zakończyć ten dialog 🙂
Dzień dobry. Na wstępie pragnę szepnąć dobre słowo o tym blogu, uważam, że miło czyta się zamieszczane tu artykuły. Nieduża liczba ludzi piszących w podobnym temacie umie pisać językiem, który potrafi przyciągnąć mnie do rzucenia okiem i skomentowania artykułu. “SĹ?aboĹ?ci tradycyjnych metod wytwarzania IT – czy na pewno sĹ?aboĹ?ci? | Analiza biznesowa i projektowanie – JarosĹ?aw Ĺ?eliĹ?ski – blog” – ten napis już widnieje wśród moich zakładek :). Jestem pewna, że jeszcze tu wrócę. Akurat chcę postawić własnego bloga i zbieram wszystkie wskazówki, które mogą mi to ułatwić. Największym moim problemem jest część techniczna i optymalizacja bloga, która ma pomóc w tym, żeby mój blog został uznany w oczach Google.
Pozdrawiam serdecznie – Zosia Tomaszewska
P.S. Podoba mi się ta skórka bloga, skąd mogę ją ściągnąć?
http://themes.bavotasan.com/
Witam,
Dziękuję za artykuł. Szkoda, że nie trafiłem na niego, kiedy moja firma postanowiła zaaplikować sobie scruma, być może, przynajmniej do pewnego stopnia, udałoby się ograniczyć liczbę błędów oraz koszty tej metody. Korzystając zatem z popularności Pana bloga pozwalam sobie za pomocą tego krótkiego komentarza przestrzec wszystkich przed tą metodyczną katastrofą ;-).
Z perspektywy moich wieloletnich doświadczeń, scrum, to nic innego jak marketingowo opakowany “garaż” – tak na początku naszego wieku określano w pełni spontaniczny sposób tworzenia oprogramowania (w scurmie nazywa się to samoorganizacją), gdzie programiści na bazie spotkań z klientami, dostarczonych materiałów w bardzo przypadkowy sposób, próbowali przygotować rozwiązanie. Mieli o tyle trudniej w stosunku do dzisiejszych agilowców, że budżet był określony z góry, więc klient miewał dość silne narzędzie wywierania wpływu, które bywało często nadużywane – odbiór systemów potrafił trwać miesiącami. Nie było sprintów, ale były fazy projektów, które później zaczęto rozbijając na iteracje. W tym sensie tzw. feedback nie pojawiał się po dwóch tygodniach, ale jeśli ktoś prześledziłby scrumowe review, to szybko zorientowałby się, że uwagi, które się na nim pojawiają są często trywialne ? ten przycisk powinien nazywać się inaczej, a ta etykieta jest nie w tym miejscu. Z perspektywy metody a?la RUP to po prostu drastyczny regres.
Co wynika z mojej tzw. “obserwacji uczestniczącej”?
1. Scrum jest mocno zideologizowany. Ludzie nie chcą widzieć ograniczeń tej metody. Każdego, który zwraca uwagę na choćby potrzebę definiowania wymagań, modelowania itp. natychmiast wrzuca się do worka “wodospadowiec” i kończy dyskusję. W tym sensie jest to metoda niepodatna na myślenie krytyczne i istotne korekty. Teoretycznie są retrospektywy, które powinny korygować proces, jednak w praktyce rama scrumowa jest bardzo sztywna (typy spotkań są określone, ich przebieg oraz możliwy output również), a dodatkowo zabezpieczają ją tzw. scrum “but’y” – czyli nieakceptowalne odejścia od scruma (trudno oprzeć się wrażeniu, że takie zabiegi mają podłoże bardzie retoryczne niż merytoryczne).
2. Scruma i cały agile “sprzedaje się” jako developerski raj. Developerzy, czy lepiej powiedzieć “zespół” są w centrum uwagi, kreują, osiągają cele, są w pełni zmotywowani i w dużym stopniu autonomiczni – innymi słowy “za cudze pieniądze” robią startup. Niestety duża firma, to nie jest zbiór startupów. Spośród wszystkich developerów, myślę, że jakieś 5-10% faktycznie żyje tym, co robi, reszta po 7 godzinach w pracy mocno spogląda na zegarki i chce jak najszybciej wrócić do domu. Być może dla kogoś, to mało istotny argument, ale chcę w ten sposób pokazać jak nieadekwatne są założenia agile w stosunku do rzeczywistości. Utrzymanie motywacji, to stara i złożona kwestia – niestety w scrumie sprowadza się ją często do “wymuszonego” entuzjazmu, czy sposobu stania na stand-up’ach – uwaga! najlepsza jest postawa zasadnicza.
3. Odkrywanie modeli metodą prób i błędów, to niemal zasada w scrumie. Do tego celu stosuje się groomingi. Przez 1,5 godziny spotyka się 7-8 osób i w trybie burzo-mózgowym “rozkminiają” jakiś złożony temat. Oczywiście wcześniej nikt się do nich specjalnie nie przygotowuje – przygotowanie oznaczałoby wodospad ;-). Jak to z burzami mózgów bywa – aktywne są 2-3 osoby o specyficznych cechach charakteru (nie zawsze są to osoby najbardziej przenikliwe ;-)), reszta siedzi i się nudzi. Po zakończeniu spotkania poza jakimś szkicem rozwiązania nikt już za bardzo się nad nim nie pochyla do czasu implementacji. Powstały pomysł nie jest w żaden sposób testowany. To, co zespół ma w głowach wystarcza, by zrealizować cały temat. Jeśli są zależności z innymi zespołami, to zaprasza się ludzi z innych zespołów i tłumaczy w 5 min. co chcemy zrobić i na zasadzie “wielkiej improwizacji” powstaje rozwiązanie. Nikomu nie przychodzi do głowy, że w ten sposób można tylko zbudować przysłowiową budę dla psa. Istnieje oczywiście zawsze świetna wymówka – biznes nie interesują dobrze zaprojektowane rozwiązania, liczy się tylko to, by dana funkcjonalność działała. W praktyce, po kilku miesiącach działania scruma można spodziewać się niezłego ?bajzlu? w systemie. W czystym scrumie nie ma oczywiście roli architekta ? to wodospadowy relikt. Jeśli cały system rozwijany jest przez jeden niewielki zespół, to półbiedy, jeśli jednak zespołów jest kilka to pojawia się efekt rozproszonej wizji rozwiązania ? tj. nikt tak naprawdę nie wie jak na końcu coś powinno być zrealizowane. Jeśli mamy ?czystego? scruma, to jedno jest dla mnie pewne, o Domain Driven Design możemy zapomnieć.
Warto dodać, że to co doświadczonemu analitykowi może zająć 2 tygodnie pracy, zespoły mogą odkrywać przez 2-3 sprinty. Różnica jest taka, że 10 osobodni przekształca się w 7*10 osobodni. Pomijam efekt jakości. Niestety z moich obserwacji wynika, że programiści, to na ogół bardzo słabi analitycy. Interesują ich najczęściej tylko ścieżki pozytywne albo przeciwnie mają predylekcję do komplikowania świata.
4. Na koniec kilka uwag na temat uber-kompetencji, które zakłada się w scrumie. W scrumie wyróżnia się 3 role: product-ownera, scrum-mastera i developerów. Product owner to tzw. rola nie możliwa 😉 ? skrzyżowanie: eksperta dziedzinowego, research?era, specjalisty od użyteczności, do pewnego stopnia analityka. W praktyce bardzo trudno znaleźć takie osoby więc product ownerów rekrutuje się spośród analityków, pm?ów, biznesowców. Niestety rzadko tego typu osoby czują w jakim kierunku ich ?kawałek? systemu powinien się rozwijać nawet na poziomie funkcjonalnym. Często nawet nie czują potrzeby, żeby wyobrazić sobie rozwiązanie w dłuższej perspektywie (uwaga! znowu wkrada się wodospad). Ostatecznie zatem system staje się ?zlepkiem? features. Niestety PO rzadko mają wiedzę na temat budowy systemów by być partnerem dla zespołu. W zdyscyplinowanych metodykach rozróżnia się wiele ról, które mają dobrze zdefiniowane kompetencje i dopiero z ich zbioru tworzy się zespół projektowy. Jeśli kogoś brakuje w zespole np. architekta, to łatwo zidentyfikować takie ryzyko. Z drugiej strony czasami ktoś może łączyć wiele ról, ale wiadomo, że jest to dla projektu problem, bo trzeba znać się często na bardzo różnych obszarach i dodatkowo taka osoba bywa na ogół przeciążona. W scrumie nie dostrzega się tego – wierzy się w nieograniczone możliwości kolektywu.
O scrum masterach niestety nic dobrego nie mogę powiedzieć. Głównie zajmują się rezerwacją salek i wypowiadaniem jednego słowa ?timeboxing?. Choć muszę przyznać, że jeśli jest konflikt w zespole, to starają się pomóc. Pytanie tylko, czy dla czynności, które zajmują 15 min. dziennie potrzebny jest etat ;-).
Z rolą developer jest podobny problem jak z PO. Każdy, bez względu na doświadczenie, musi być w określonych przypadkach architektem, projektantem, programistą i testerem. Jeśli ktoś jest od wszystkiego, to, wiadomo jak to się kończy. Poza tym, liczy się na samoorganizację w obszarze różnych decyzji projektowych. Jeśli nie ma consensusu, to oczywiście debaty na dany temat mogą trwać tygodniami. PO oczywiście nie ma prawa się mieszać, poza pytanie, ile coś będzie trwało jest nie na miejscu.
Kończąc, od razu wyjaśnię, że powyższe uwagi dotyczą scruma w postaci opisanej w scrum-guide ? niestety tę ?metodyczną zabawkę? próbuje się wdrażać tu i tam ;-). W praktyce prędzej, czy później (zwłaszcza jak jesteśmy po ścianą, bo małe tematy realizuje się miesiącami) po cichu zaczyna się uzbrajać tę metodę w różne dodatki, które niestety do niej nie pasują np. architektów, specyfikowanie wymagań przez przykład, czy DDD. Efekty tych hybryd są niestety dość mizerne, bo nie są one ?zabezpieczone? procesowo ? wszystkim steruje samoorganizacja (to taki patent pochodzący od mrówek ;-)) + święty cykl spotkań: planning (definiowanie karteczek), review (oglądanie ekranów), retro (jak lepiej testować, albo króciej się spotykać) i grooming (burze mózgów, których efektywność została zakwestionowana już w tylu badaniach, że aż nie wypada tego powtarzać).
Na koniec link pokazujący, że nawet entuzjaści z czasem tracą zapał 😉
http://lostechies.com/jimmybogard/2012/09/12/why-im-done-with-scrum/
Mogę tylko dodać, że tam gdzie trafiło mi się rozpoczynać jeszcze raz po tym, jak zwinne metody poległy, oprogramowanie było dostarczane znacznie taniej i szybciej.
I podobne jest moje spojrzenie na scruma, które opisałbym jednym zdaniem: “Próba ‘wodospadowego’ podejścia do agile” 😛 Z definicji nie ma prawa się udać.
Mam wątpliwości co do “niekompatybilności” scruma z DDD, czy ze “specyfikowaniem wymagań przez przykład” (właściwie to jest zalecana metoda spec. wymagań w agile). W posiadaniu architekta też nie widzę nic złego. Ten scrum-guide musi być naprawdę “dziwny” 🙂
Niestety, to co zostało opisane przez Jutrzenkę, to punkt po punkcie wskazane przykłady niewłaściwego podejścia do wykorzystywania zwinnego zarządzania projektami. Przede wszystkim, opisana sytuacja pokazuje, że ktoś skupił się na metodach, zupełnie odcinając kwestie kultury organizacyjnej i pryncypiów Agile, od których powinno się rozpocząć jakiekolwiek działania ze zwinnością. Nie “doing agile”, a “being agile”. Zdarzają się osoby, które mocno trzymają się metod waterfallowych, a które są agile, ale często zdarza się też sytuacja odwrotna.
W opisanym przykładzie nie zadbano o właściwe zbudowanie zespołu, o dobranie ludzi właściwych do ról scrum-owych. Nikt nie mówi, że jest to łatwe – wręcz przeciwnie, sam Scrum mówi o tym, że jest to łatwe do zrozumienia, ale bardzo trudne do zastosowania. Kolejny raz wychodzi to, że ludzie podchodzą do wszelakich metodyk jako do kompletnego algorytmu postępowania. W praktyce to tylko wskazówki dla świadomych osób, które mają ułatwić, bądź wskazać co jeszcze warto zrobić, aby doprowadzić projekt do sukcesu. Nie bardzo rozumiem jak praktycy analizy, czy zarządzania projektami, potrafią tak spierać się na temat szczegółowych zwrotów użytych w opisie metodyk, zupełnie zapominając o najważniejszym czynniku: kompetencjach ludzi, którzy proces wykonują. Bez tego nie da się, lub jest to prawie niemożliwe, osiągnąć wyznaczonych celów (chyba, że przypadkowo, ale wtedy to bardziej opłaca się zagrać w totka). To osoby biorące udział w realizacji skomplikowanych procesów, jakim jest na przykład dostarczenie rozwiązania informatycznego, są najważniejszym źródłem decyzji, nie zaś sam algorytm postępowania, czy metodyka. Jeśli ktoś podąża ślepo za wytycznymi metodyki, podejmując decyzje stojące w sprzeczności z zastaną sytuacją (bo przecież tak każe metodyka), to zachowanie takie ma swoją nazwę – głupota.
I tak jest z każdym podejściem, czy zwinnym, czy nie. Opisana tutaj sytuacja jest przykładem niewłaściwego podejścia do tematu organizacji w ogóle, a nie przykładem na słabość agile, czy Scruma (choć nie są one pozbawione wad, podobnie zresztą jak waterfall, z tym nie zamierzam dyskutować).
Jest jednak równie wiele, jeśli nie więcej, przykładów na organizacje, które z sukcesem działają zwinnie, a zatem można. Wystarczy podejść do tematu z otwartym umysłem i we właściwej kolejności.
Jeżeli uznamy, że metoda pracy to zbiór reguł oraz, że “istnieje wiele sytuacji, w których reguł tych nie należy restrykcyjnie stosować” to wniosek jest jeden: metoda jest do kitu (reguł się albo przestrzega albo się je zmienia).
Druga rzecz: “Nie bardzo rozumiem jak praktycy analizy, czy zarządzania projektami, potrafią tak spierać się na temat szczegółowych zwrotów użytych w opisie metodyk”, w moich oczach słownik pojęć to nic innego jak precyzyjne ustalenie znaczenia “pojęcia”, to jedyny sposób na jednoznaczność przekazu (komunikacji), bez tego “każdy mówi to samo czyli co innego”. Kompetencje ludzi są jak najbardziej ważne ale one nie mogą być narzędziem “łamania reguł”, bo dojdziemy do wniosku, że na drodze publicznej wszyscy muszą przestrzegać reguł Kodeksu Drogowego za wyjątkiem medalistów w wyścigach samochodowych, co jest bzdurą (rolą stanowienia reguł jest także uzyskanie przewidywalności zachowań). Uznanie jakiejś drogi za publiczną, obliguje do jednakowych zachowań wszystkich, drogi niepubliczne pozwalają na nieprzestrzeganie tych zasad ale ryzyko ponosi kierowca. W zarządzaniu projektami mamy to samo: albo projekt jest “typowy” (czyli zakres, termin i budżet, kierownik projektu, ustalone reguły itp…) albo są to “badania i rozwój” (lub sturt-up) i wtedy świadomie łamiemy zasady i rozumiemy ryzyka.
W moich, i nie tylko, oczach “agile/scrum” to traktowanie wszystkich projektów jak “badania i rozwój” (na koszt sponsora – bardzo wygodne dla wykownawcy). Co do przykładów i pojęć: problemem Agile jest to, że tego pojęcia nikt do tej pory nie zdefiniował a “wszyscy go używają” (słownikowe “zwinny” oznacza wyłącznie “wykonujący szybkie, zręczne ruchy”), w efekcie udowodnić można każdą tezę o Agile bo to słowo tak na prawdę nic, ponad słownik, nie znaczy. Nie jestem “wrogiem” Agile, po prostu od każdego wykonawcy oczekuję poprzedzania każdej pracy deklaracją co zrobi (i nie mam na myśli deklaracji: “popracuje jeszcze kilka dni”) albo zaliczam projekt do “prac badawczych”.
Jutrzenka opisał to co spotykam w większości przypadków. Co do straszenia metodami “waterfall” to jest to jakiś bzdurny mit o trwających latami analizach o zamrożonych wynikach, tak zwany “wodospad” to wyłącznie utrzymanie prostej kolejności: analiza i projekt (deklaracja), wykonanie (w tym test), zarządzanie zakresem, odbiór. Problemem jest raczej zbyt duży zakres na jeden taki “cykl” (projekt) a nie sam cykl jako taki. To dlatego powstały metody komponentowe w IT i zarządzanie zakresem (WBS) w metodykach zarządzania projektami i programami. Co ciekawe, źródłem “wielkich i całościowych analiz” jest, nie wodospad jako metoda, a nadal stosowane metody strukturalne, wymagające rozpoczęcia projektu od analizy i opracowanie pełnego relacyjnego modelu bazy danych, co ciekawe, tak zaczyna prawie każdy programista, Ci zwinni także. Z własnej obserwacji mogę potwierdzić doświadczenie Jutrzenki: projekty zwinne zawsze produkują kosztowny kod zwany “kupa błota” (chyba, że pojawi się w projekcie architekt ale to jest passe). Metody obiektowe (owszem trudne) powstały między innymi po to, by wielkie projekty dzielić na hermetyzowane małe (a nie jak twierdzi większość programistów jakich spotykam: po to by reużywać kod).
Witam,
Nie spodziewałem się aż takiego rezonansu na mój wpis. Dziękuję Panu Jarosławowi za redystrybucję mojego komentarza oraz bardzo trafną opinię, z którą w pełni się zgadzam. W szczególności zgadzam się, że agile jako pojęcie jest niezwykle mgliste. Oczywiście takie pojęcia funkcjonują w języku naturalnym i kiedy rozmawiamy o wrażeniach estetycznych, literaturze możemy obejść się bez jednoznaczności. Jednak w IT ? dyscyplinie mimo wszystko dość ścisłej ? można byłoby się spodziewać czegoś dobrze określonego i zdefiniowanego. Rozumiem, że metodyki projektowania funkcjonują na styku IT i nauk społecznych, ale to co ludzie podstawiają pod hasło agile jest wyjątkowo mętne i nieprecyzyjne. Najczęściej kiedy pada hasło agile, to pojawia się nawiązanie do manifestu ? czyli zbioru wartości podzielanych przez ?wspólnotę? ;-). Gdyby na chłodno przyjrzeć się zapisom manifestu, to można powiedzieć, że jest to zbiór banałów, jednak wśród zwolenników te kilka zdań funkcjonuje niemal jak tekst autorów natchnionych.
Wpis jackav2 jest dla mnie bardzo symptomatyczny – scrum to ?wodospadowe? podejście do agile. Jak rozumiem wodospad jest jak wirus, który niepostrzeżenie atakuje zespoły scrumowe, pomimo tego, że otacza je kordon scrummasterów, scrum-coachów, a nawet bezkrytycznie wspierających to podejście top-managerów. Nie pomaga nawet przeszkolenie wszystkich osób w organizacji, dostosowanie struktury organizacyjnej, ciągłe przypominanie zasad z manifestu, masowy udział w konferencjach, wypowiadanie jak mantra ? ?jaką wartość biznesową prezentuje to, co zostało zrealizowane w ostatnim sprincie? itd. Czyżby do dyspozycji pozostawało już tylko pranie mózgu ;-).
Oczywiście nie można zaprzeczyć, że są zespoły, w których scrum lub inna metodyka zwinna ?nie przeszkadza?. Wydaje mi się jednak, że mamy w takich przypadkach z typowym efektem przypadkowej korelacji. Ponieważ zespół jest silny ? składa się z osób z dużym doświadczeniem wiedzących, co należy zrobić w danym przypadku, dysponujący szeregiem technik pracy, które należy w danym kontekście zastosować, to efekt jest taki, że scrum działa. Sam widziałem taki zespół, który na wejściu otrzymywał dobrze określone wymagania (realizowana była klasyczna analiza), dobrze określoną architekturę, a tylko implementacja i testy odbywały się w scrumie ? w efekcie zespół dowoził bardzo wysokiej jakości rozwiązania co do dnia w projekcie 3-4 miesięcznym (wiem, wiem ? to nie agile, tylko przeklęty wodospad ;-), ale to po prostu działało i mimo wszystko było w części nazywane scrumem. Dla kogoś ze świata agile to dowód, że scrum działa, a dla mnie to przypadkowa korelacja. Ten sam zespół mógłby działać bez wszystkich ceremonii scrumowych i nadbudowy agilowej i byłby prawdopodobnie równie sprawny. Kiedy jednak weźmiemy pod uwagę zespól osób bez dużego doświadczenia, bez szczególnej motywacji i samodyscypliny natychmiast wyjdą opisane przeze mnie scrum-efekty np. odkrywanie wszystkiego bojem, słabe modele, niska jakość, ciągnięcie prostych tematów miesiącami. Zdaję sobie sprawę, że agile mocno podkreśla ważność osób (ludzie ważniejsi od procesów), w praktyce jednak niewiele z tego wynika, bo krzywa Gaussa jest nieubłagana ;-). Inaczej jest w metodykach zdyscyplinowanych, gdzie mówi się wprost: na tym etapie projektu musisz przygotować to, to i to. Oczywiście zawsze można traktować to mechanicznie i w efekcie robić rzeczy niepotrzebne, ale tu przynajmniej mamy jakąś podpowiedź, ktoś bazując na doświadczeniach z setek projektów proponuje nam by się nad tym przynajmniej zastanowić i podjąć decyzję, czy jest nam to potrzebne, czy nie. W agile istnieje przekonanie, że zespół zawsze wie co w danej sytuacji należy zrobić ? żadne podpowiedzi metodyczne nie są mu potrzebne. Jeśli jednak przyjrzeć się pomysłom Scotta Amblera, cenionego przeze mnie agileowca, to można byłoby je spokojnie porównać do uproszczonego RUP?a w wersji dla małych projektów. Startujemy od opracowania najważniejszych przypadków użycia, tworzymy kilku szkiców architektonicznych i szybko przechodzimy do implementacji oraz testów. Wodospad jak w pysk strzelił ;-). Tam, gdzie choćby najluźniejsze skojarzenie z wodospadem i fazami projektu jest zakazane, tam pojawia się przekonanie, że można być mistrzem szachowym myśląc jedne ruch do przodu. Uważam, że największym grzechem scruma jest jego wręcz metodyczne blokowanie myślenia w dłuższym horyzoncie – stąd mój sceptycyzm wobec łączenia DDD i scruma. DDD wymaga zastosowania dogłębnej analizy dziedziny – niemal zżycia się z problemem – patrz efekt break -through opisany przez Evansa. Naprawdę trudno mi to sobie wyobrazić kiedy tematy groomowane są przez 2-3 godziny przez cały zespół z PO, a nie ekspertami dziedzinowymi. Takie skracanie horyzontu, to dla mnie zaprzeczanie złożoności. Obawiam się, że wszyscy, którzy próbują iść tą drogą będą musieli wydatkować znacznie więcej energii niż Ci, dla których etykiety metodyczne są mniej istotne, a ważniejsze jest by dobrze zrozumieć problem, precyzyjnie ustalić wymagania, przygotować dobrą architekturę i projekt i wreszcie zaimplementować to co zostało wymyślone ? jak pokazuje RUP aktywności te realizowane są niemal w całym cyklu życia projektu, niemal w każdej iteracji, a nie tak jak chcieliby agileowcy tylko sekwencyjnie.
Na koniec polecam lekturę artykułu ? wygląda to trochę na luźną asocjację, ale pokazuje jak nasze przekonania wpływają na postrzeganie świata.
Pozdrawiam.
P.S. Dziękuję uczestnikom za spokojną debatę.