blog.testowka.pl

Agile dla „dużych projektów” nie działa

opublikowany przez 19, Wrz, 2013, w kategoriach Agile, Kanban, Scrum, Testowanie, XP, Zarządzanie

5665717830_dfe3ea51c2_o

Po raz kolejny ktoś próbował mi udowodnić, że Agile dla „dużych projektów” się nie sprawdzi. I… Generalnie zgadzam się z tym stwierdzeniem. Zgadzam się, tak! Agile dla „dużych projektów” nie działa!

Agile z pewnością nie zadziała jeśli za miarę wielkości „dużego projektu” przyjmiemy ilość ludzi nad tym projektem pracujących. Jeśli duże projekty dla Was to takie nad którymi pracuje 200 lub więcej osób to macie znacznie większe problemy niż, to czy Agile zadziała, czy nie.

„Duże projekty” to dysfunkcja sama w sobie.

Programowanie jest rozwiązywaniem problemów – nie potrafię sobie wyobrazić problemu, który potrzebował by więcej niż kilkadziesiąt osób do jego rozwiązania. Owszem, niektóre problemy są bardziej złożone od innych – w takim przypadku jedyne rozsądne rozwiązanie to rozbicie ich na mniejsze – być może mniej złożone problemy i stworzenie mniejszych zespołów rozwiązujących je.

Waterfall powstał właśnie po to, by radzić sobie z „dużymi projektami”. Waterfall jest cool. Waterfall działa… dopóki nie zaczniesz się nad tym zastanawiać…

Cała pseudonauka o tym w jaki sposób powinniśmy testować (oczywiście manualnie) skomplikowane projekty, zarządzać milionami przypadków testowych, poprawnie zgłaszać miliony bugów, następnie zarządzać tymi zgłoszeniami, mierzyć ilość tych zgłoszeń i co gorsza tworzyć z tego metryki mające na celu określenie jakości pracy testerów [BLAH!], to wszystko powstało w odpowiedzi na realne problemy. Problemy, które sami sobie stworzyliśmy budując niewłaściwe oprogramowanie w niewłaściwy sposób.

Skalowanie Agile to kolejny urojony problem.

Coraz więcej na około słyszy się o nowych, pięknych i kompleksowych metodach skalowania Agile. Niektóre z nich nawet zapewne działają. Ba, nawet widziałem je w działaniu. Niestety nadal są to narzędzia służące do rozwiązywania problemów, które ktoś, gdzieś sam sobie stworzył.

Agile nie trzeba skalować, jeśli jesteśmy w stanie przeskalować nasz produkt. Tak jak na przykład zrobili to w Spotify. Kluczem do sukcesu nie jest stworzenie squad’ów, tribe’ów, chapter’ów czy guild’ów… To wszystko powstało tylko po to by wokół wielu, względnie niezależnych komponentów produktu, rozwijanych przez interdyscyplinarne i kros-funkcjonalne zespoły stworzyć platformę służącą do synchronizacji pracy i wymiany wiedzy. Agile jest gdzieś indziej – w każdym zespole z osobna. Nie ma tutaj żadnego skalowania.

Więc tak, Agile nie działa w „dużych projektach”! Duże projekty są problemem samym w sobie. Nie chcę tutaj rozwodzić się nad potencjalnymi i faktycznymi przyczynami tego dlaczego nadal mamy do czynienia z tak wieloma „dużymi projektami”. To nie jest czas na to – niech ten post będzie dla Was przestrogą, by Wasze małe jeszcze projekty nigdy nie stały się „dużymi projektami”.


7 Comments for this entry

  • Radek

    Dzięki za wspomnienie naszej publikacji.
    Warto dodać, że sam wspomniałeś, że środowisko Agile i małe projekty to środowisko „normalne”. Nie odpowiadasz na podstawowe pytanie.
    Co ma zrobić tester / kierownik testów, kiedy pracuje w „nienormalnym” (w twojej opinii) środowisku, a jego wpływ na metody wytwarzania oprogramowania, technologie, wielkość produktu jest żaden? Ma zmienić pracę i pójść do organizacji z wdrożonym Agile?
    Czy instytucja bankowa, która kupuje całościowy system wsparcia działania ma uruchamiać drobne funkcjonalności? Jakby w takmi wypadku wyglądał i ile by trwał start AliorBanku?
    Jak wyobrażasz sobie, że osoba z 40 letnim doświadczeniem biznesowym, Pani Halina z księgowości (bez świadomości modeli wytwarzania oprogramowania) usiądzie z programistą w jednym zespole i razem coś zbudują? A co jeśli takich osób trzeba zaangażować 40?

  • streser

    Pozwolisz, że odpowiem na Twoje pytania w kolejnej notce? Są bardzo trafne, więc zasługują na coś więcej niż komentarze 🙂

  • walec51

    Osobiście uważam artykuł za nietrafiony. Sprawa oczywista że wydajność zespołu nie rośnie liniowo wraz z liczbą jego członków.

    Nie ma jednaj złotej metodyki. Każda ma swój obszar zastosowań. Na wybór ma zazwyczaj wpływ: klarowność celu, wiedza jak go osiągnąć, otoczenie.

    Przykład: Robisz kustomizację system WMS dla nowo powstającego magazynu przeładunkowego, którego funkcjonowanie musi być z góry zaplanowane przed budową. Masz tu stałe terminy, stały budżet i musisz z góry zaprojektować całą funkcjonalność razem z konsultantem z logistiki. Tylko kaskadówkę da się tu zastosować. Agile tutaj było by czystą fikcją. Musisz jechać równo z planem budowy, a procesy logistyczne wspierane przez system muszą być zaprojektowane jeszcze zanim budowa ruszy. PS. Taka kustomizacja WMS’a do projekt w skali 500’000 – 1’500’000 zł.

  • streser

    @walec51:
    Tak, w takim przypadku Waterfall sprawdzi się lepiej. Pozostaje tylko kilka pytań:

    Jeśli robisz WMS dla magazynu to czym ten system będzie się różnił od setek innych WMSów, które są na rynku?

    Jeśli robisz go tylko raz to powstaje pytanie czy to w ogóle ma sens i czy się opłaca?

    Jeśli myślisz perspektywicznie to na bazie potrzeb wspomnianego magazynu stworzysz produkt, który będzie spełniał wymagania tego magazynu, ale będziesz mógł go też później łatwo rozszerzyć i zmienić, by sprzedać kolejną wersję do innego magazynu.

    Właśnie problemem jest to, że twórcy tych wszystkich WMSów wcześniej myśleli podobnie do tego co opisałeś. Ci, którzy myśleli trochę bardziej perspektywicznie sprzedają teraz gotowe rozwiązania WMS – dostosowywane do klientów, albo wręcz uniwersalne.

    Ale takich uniwersalnych systemów nie da się już dobrze zrobić w sposób kaskadowy – tutaj już przewidywalność się kończy. W takim przypadku trzeba właśnie zmienić podejście z projektowego na produktowy. To co opisałeś jest typowym projektem – w niektórych przypadkach, to w zupełności wystarczy. Natomiast jeśli chcesz czegoś więcej to trzeba zacząć o tym myśleć jako o produkcie.

    PS: W następnej notce napisałem, że Waterfall jest cool i że działa. I to wcale nie był sarkazm – Waterfall do niektórych rozwiązań sprawdza się dobrze – sam kilka razy takie rozwiązania radziłem klientom.

  • streser

    @walec51
    A jeśli o samą kustomizację chodzi to tym bardziej posadził bym tego konsultanta logistyki razem z developerami. Wtedy miał bym ciągłe testy akceptacyjne.

    Jeśli magazyn jest w trakcie budowy i na przykład oddawane są jakieś jego działające części/hale/czy co tam jest, to można by pokusić się o wdrażanie takiego systemu od razu do działania w realnych warunkach.

    Nigdy nie robiłem akurat WMSa, ale jak się nad tym zastanawiam to chciałbym właśnie tak do tego podejść. Dzięki temu miałbym pewność, że to co robię faktyczni jest tym co jest w tym magazynie potrzebne. Dodatkowo plany budowy, czy zarządzania takim magazynem/logistyką też mogą się zmienić w trakcie…

    Może, nie do końca zrozumiałem kontekst. Ale tak jak pisałem – nigdzie nie twierdzę, że Waterfall jest inherentnie zły.

    Tylko, że jak się nad tym zastanawiam to inne podejścia w większości przypadków brzmią da mnie bardziej sensownie.

  • walec51

    Widzę że lubisz prawić kazania na tematy o których nie masz pojęcia.

    Nie ma czegoś takiego jak pudełkowy system WMS, który bierzesz z półki i instalujesz. Byłem w zespole, który kustomizował pod wdrożenia jeden z najlepszych tego typu systemów na Europejskim rynku. Baza była ciągle rozwijana nieustanie od 20 lat ale każdy magazyn jest inny i nie ma tutaj miejsca na jakieś generyczne kompromisy. Zawsze trzeba dopracować ekrany operatorskie oraz procesy logistyczne aby 100% odzwierciedlały organizację na magazynie. Nie jesteś wstanie zrobić tego konfiguracją nawet przy zastosowaniu BPML.

    Tego typu systemy to nie proste zabawki typu magazyn w OpenBravo lub Subiekcie. One sterują CAŁĄ pracą wszystkich przenośników, podajników, sortowników oraz pracowników, który są niewolnikami swoich terminali. Ma to masę odpowiedzialność od optymalizacji rozlokowania towarów po planowanie w przód wszystkich operacji transportowych, przeładunkowych, sortowniczych, itp.

    Budowa może ulec zmianie ? Człowieku czy ty zdajesz sobie sprawę jakie opóźnienia by to powołało. Wiesz ile czasy zajmuje korekta projektu oraz warunków zabudowy przy większej hali ? Czy ty myślisz że budowlańcy robią tak jak większość firm IT – wdrażają nieprzemyślany projekt, a potem burzą ściany i wrzucają setki hot-fixów ?

  • streser

    Nie prawie kazań, tylko piszę o tym jak ja bym podszedł do problemu.

    Ty patrzysz na taki produkt i widzisz wielki, skomplikowany problem do rozwiązania. Ja patrzę na niego i widzę, wiele stosunkowo prostych i małych problemów.

    Przez zmiany w planach budowy miałem na myśli na przykład błędy, które często są popełniane. Nie zawsze budynki są dokładnie takie jak planowano. Często też nie bierze się pod uwagę niektórych czynników podczas planowania, które później okazują się kluczowe. Na przykład ktoś postawi jakiś filar w miejscu, gdzie miała stać jakaś maszyna.

    A co do stosowania Agile przy WMS widzę, że są już tacy, którzy w ten sposób to robią:
    http://aquarelles.wordpress.com/tag/agile-project-management/
    http://www.forte-industries.com/warehouse-control-system-software.aspx

1 Trackback or Pingback for this entry

Skomentuj