Ciesze się, gdy pojawiają się polemiki z moimi artykułami, to znaczy, że ktoś je czyta i budzą one emocje. Czytamy na pewnym blogu (który gorąco polecam jako całość):
Zacznę od drobnej złośliwości. W maju, jako że sięgnąłem też do starszych wpisów, autor napisał: ?[…] ja już wyrosłem ze społecznych źródeł wiedzy jakim jest Wikipedia i przytoczę definicję z książek mających konkretnego autora […]?. A dzisiaj czytam, jak autor krytykuje praktyki Agile ? czerpiąc wiedzę na ich temat z tego społecznego źródła wiedzy. Kończąc złośliwość dodam adresując to do autora, że Wiki i Wikipedia to nie to samo i mają się do siebie tak ja klasa do obiektu. (źr. Zwinna analiza ? TouK).
Cóż, problem w tym, że Agile jest głównie na społecznych stronach definiowane więc nie miałem wielkiego wyboru: społeczna metodyka to i społeczna wiedza o niej…. (wiem czym jest i wiki i wikipedia, nie sądzę by tu tkwił problem).
Po drugie nie jestem wrogiem zwinności (agile a małej litery) bo sam dostosowuję metody pracy do projektu. Jednak jak by nie było manifest Agile mówi:
Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych doświadczeń zaczęliśmy przedkładać:
- Ludzi i ich wzajemne interakcje(współdziałanie) ponad procedury i narzędzia.
- Działające oprogramowanie nad wyczerpującą dokumentację.
- Współpracę z klientem nad negocjację umów.
- Reagowanie na zmiany nad realizowanie planu.
Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak bardziej cenimy to co wymieniono po lewej.
Ciekaw jestem np. pracy bez dobrze wynegocjowanej umowy (świat jest dla niektórych idealny… zazdrościć) i tego jak możńa coś większego zbudować bez planu (dokumentacji). Kolejny argument – IBM i czytamy:
według firmy IBM wydłużanie jej czasu przed fazą implementacji, tylko stosowanie zwinnych (agile) metodyk i choćby w takim kierunku zmierza sztandarowy zestaw produktów tej firmy wspierających proces tworzenia oprogramowania ? IBM Rational
Popatrzyłem w opisy i cóż: Scott Ambler pisze, że trzeba próbować bo kluczowa faza pętli “szukania rozwiązania” to “Produce a potentially consumable solution” czyli tworzenie czegoś potencjalnie przydatnego… (potencjalnie). Idąc dalej, autor polemiki cytuje:
Scott Ambler (chief methodologist for Agile at IBM Rational) napisał kiedyś, że ?analiza jest tak ważna dla praktyków Agile, że robimy ją każdego dnia?
Po pierwsze metodyk od Agile w IBM (czyżby moda na Agile? Jak by nie było piewcy ciężkiego [[RUP]]’a będącego nadal podstawą w IBM)). Powyższe to tak jak bym napisał, że “dla chirurgów plan operacji jest tak ważny, że planują co będą robić stale, nawet podczas trwania operacji”…
Agile w literaturze ma wiele znaczeń, jedno to adaptacyjność stosowanej metodyki pracy, inne to np. odkrywanie rozwiązania poprzez jego tworzenie. Jeżeli w tym pierwszym rozumieniu jestem Agile, to jednak mam zasadę: najpierw projekt potem implementacja. Jakoś nie widzę się w projekcie, w którym drugie piętro jest dopiero planowane po wybudowaniu fundamentów, te zaś powstały bez wiedzy ile pięter powstanie. Owszem, na pewno projekt lepiej uszczegóławiać dopiero gdy są potrzebne szczegóły, ale praca bez zbudowania szkieletu… to nie ja.
Na koniec zapytam: dlaczego zespoły “Agile” bardzo często rękami i nogami bronią się przed kontraktami “fixed price” czyli klasyczny trójkąt: czas, budżet, zakres, gdzie jest to z góry określone. Agile: zakres (to co powstanie) rodzi się podczas pracy? Czyli nie wiemy co powstanie … dopóki nie skończymy…
Cytat z komentarza:
Merry Poppendieck idzie w swoich rozważaniach dalej. Po co w ogóle robić analizę, produkować dokumenty i diagramy? Ich efektem będzie zamieszanie. Lepiej wyznaczyć cele i napisać działający kod.
Tak sobie pomyslałem: co bym miał gdybym tak właśnie podszedł do budowy domu… chociaż podobno tak się właśnie buduje na wsiach: bez planów budowlanych, budujemy i projektujemy w trakcie … a powodzie uczą pokory…
Nie jestem wrogiem Agile, jestem zwolennikiem innego autorytetu: Yourdona, który napisał w swojej książce o modelowaniu UML:
bez planów na pewno można z marszu zbić z desek np. budę dla psa bo jest mało skomplikowana i ogarnia ją wyobraźnia przeciętnego człowieka, ale dlaczego tak wielu ludzi próbuje tą metodą budować wielkie biurowce…
![Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]](https://it-consulting.pl/wp-content/uploads/2022/05/image-14-590x397.png)
1.”Ciekaw jestem np. pracy bez dobrze wynegocjowanej umowy” – negocjowanie umów nie jest częścią projektu – na pewno w części związanej z budżetem. Jak dla mnie to sprzedaż. Wydaje mi się dobrą praktyką oddzielić MD od stawki za MD.
2.”najpierw projekt potem implementacja” – w agile nie chodzi o to, że implementujemy bez projektu, tylko zatrzymujemy się z projektowaniem w “odpowiednim” momencie 🙂
3.”dlaczego zespoły ?Agile? bardzo często rękami i nogami bronią się przed kontraktami ?fixed price? czyli klasyczny trójkąt: czas, budżet, zakres, gdzie jest to z góry określone.”
W moim przypadku to proste. Z uwagi na dobro klienta. Projekt jest przeważnie tańszy i szybciej dostarczany.
1. Umowa to także zakres projektu, a czym jest zakres jak nie specyfikacją tego co ma powstać?
2. W jakim momencie się zatrzymujemy? Oprogramowanie to dzieło w rozumieniu prawa autorskiego, jest ono przedmiotem umowy (ma zostać dostarczone) skoro jeszcze nie wiadomo co ma powstanie to czego dotyczy umowa na Agile?
3. Jak znam projekty IT to praktyka, nie tylko moja, przeczy w 100% tej tezie, większość projektów zatrzymanych z powodu wyczerpania czasu lub budżetu to były projektu, których zakres to była jedna strona umowy. Dlaczego mimo kilku tysięcy lat budownictwo nie zaadaptowało tej “lepszej dla klienta” metodyki?
Ad.1.Chodzi o budżet. Nawiązałem do postu. Zakres jest tylko początkiem. Nie oszukujmy się chodzi pieniądze. Jak jest budżet to i zakres jest gumowy 🙂
Ad.2.Wiadomo co powstanie – przecież to zakres. Projekt w tradycyjnym rozumieniu i tak powstaje po podpisaniu umowy.
Ad.3.I teraz pytanie : dlaczego tradycyjne projekty tak często padają? A może zabrakło elastyczności, a było za dużo formalizmów? Papierologia bardzo często powoduje przedłużenie czasu projektu, a biznes nie czeka zmienia się, co powoduje późniejsze zmiany w zakresie. I mamy błędne koło.
Budownictwo i IT to dwie całkowicie różne dziedziny.To że używamy często w nomenklaturze IT słownictwa z budownictwa nie znaczy, że te dwie dziedziny są takie same.
To już każdy sam oceni…
masz racje sami ocenia
Na razie krótko. Kiedyś może pokuszę się o dłuższy tekst
1. Co do chirurgów, to są sytuacje, że “otwiera się” pacjenta w celu zobaczenia, co jest w środku. W trakcie takiej operacji podejmuje się decyzje (planuje się), co zrobić z pacjentem a i zdarza się, że zaszywa się go bez żadnych zmian. Zdarza się to zarówno w przypadkach nagłych jak wypadki, gdzie ofiara trafia na stół bez dłuższego planowania, jak i w chorobach przewlełych. Nie mogę w tym momencie napisać, że to większość, albo spora część, bo bazuję tylko na przypadach, z którymi ja sam miałem styczność – i w nich jest akurat 100% agile.
2. Nie jest tak, że wszystie zespoły Agile bronią się przed kontraktami fixed price. Kolega z TouK, Piotr Burdyło będzie o tym mówił na konferencji AgileByExample.
3. Eda Yourdona sobie bardzo cenię. Szczególnie za książkę “Death March”. Jednak znowu powołuje się Pan na autorytet, który rozwija swoją wiedzę.
Można też znaleźć jego pozytywne zdanie na temat burzy mózgów, czy JAD (to chyba nawet jest właśnie w Death March). 🙂
Nie chciał bym być, źle zrozumiany: Yourdon czy Fowler to “klasycy analizy i projektowania”. Faktem jest, że biorą udział w ruchach Agile ale ja stale podkreślam, że zanim wypowiemy słowo Agile warto przytoczyć jakąkolwiek jego definicję. Bez niej mamy jedno słowo i wiele znaczeń. Ja mam nawyk “nie wymyślania” koła od nowa i posługuję się słowem Agile mając na myśli wspomniany Manifest Agile. Z drugiej strony, jeżeli rozumiemy Agile jako odejście od tak zwanych ciężkich metodyk (RUP i podobne) na rzecz metodyk adaptacyjnych (ale jednak nie pomija się w nich analizy, projektowania i jakiejś określonej formy dokumentowania projektu co podkreśla i Yourdon i Fowler – z którym nawet wymieniłem kilka maili) to jak najbardziej jestem za i tak pojmuję zwinność w projektach (świadomie omijam słowo Agile ;)).
Podsumowując: ze swojej strony jak najbardziej jestem za zwinnymi metodykami w rozumieniu dobierania metod i narzędzi (planowania etapów projektu) na bazie tego jakie są cele i ryzyka w projekcie. Nie wyobrażam sobie jednak dobrego projektu bez udokumentowanej jego wizji, koncepcji rozwiązania i udokumentowania co najmniej architektury, kluczowych elementów (komponentów) systemu i prototypów (realizacji) nietrywialnych przypadków użycia.
Tak więc należy się zgodzić z tym, że są przypadki gdy chirurdzy otwierają pacjenta ale to jest metoda na totalny brak wiedzy gdy inne metody zawiodły, nie jest to standardowa procedura dla każdej operacji. Zgadzam się z tezą, że JAD bywa przydatne ale najczęściej wtedy gdy nie istnieją już żadne inne źródła wiedzy poza tym co mają w głowie klienci. Tu pragnę zwrócić uwagę, że (moim zdaniem) 90% zależności i reguł biznesowych siedzi w prawie, zarządzeniach i procedurach a nie w głowach użytkowników (oni pracują na bazie zakresu obowiązków, instrukcji, procedur, poleceń Zarządu itp.), Pozostałe 10% swobody to “wolność” z racji kompetencji i uprawnień ale to wymaga po porostu dostarczenia narzędzia dającego im pewną swobodę.
Nie widzę tu sporu między nami, mam wrażenie, że piszemy (i bronimy go) o “innym Agile” niż to z Manifestu.