Bardzo ciekawa dyskusja. Jako, że poza byciem programistą pełnię również Klauna zwanego też Scrum Masterem, pomyślałem, że dołączę do dyskusji. :)
- Estymacja wielkości zadań była bezużyteczną stratą czasu. Nigdy estymaty się nie zgadzały z rzeczywistością, niezależnie od stopnia zaawansowania osoby estymującej. Jedyne, co działało, to podział zadań na "łatwe, znam rozwiązanie", "wiem jak to zrobić, ale to duże zadanie" i "nie mam pojęcia jak to zrobić / poprawić, zajmie od 5 minut do 5 miesięcy".
Oszacowanie wielkości zadania przez Zespół Developerski daje istotną informację Właścicielowi Produktu, dzięki której może podjąć decyzję o tym czy i w jakim zakresie realizować dany element backlogu. Jest wstępem do rozmowy i negocjacji z której mogą narodzić się różne wnioski. Przykładowo może, się okazać, że da się zmniejszyć lekko (z punktu widzenia biznesu) zakres historii, co wpłynie znacząco na zmniejszenie jej estymacji. Innym przykładem, kiedy estymacja mogą sprzyjać komunikacji jest ich ustalanie w zespole. Jeśli w trakcie estymowania pojawią się dwie zupełnie skrajne wartości, to ponownie jest to sygnał mobilizujący do dyskusji. Może się okazać, że ktoś miał za małą wiedzę w danym temacie i nadarzy się fajna okazja do rozpropagowania wiedzy z użyciem programowania w parze. Innym razem może się okazać, że ktoś/zespół, podchodząc do estymacji optymistycznie nie zdawali sobie sprawy z dużej trudności o której wiedział bardziej doświadczony kolega. Może się także okazać, że zakres o którym była mowa został inaczej zrozumiany i trzeba będzie go doprecyzować.
- W praktyce nie jest możliwe sensowne zaplanowanie rozwoju złożonego produktu planując w sprintach po dwa tygodnie. Taki system planowania ma tendencję do skupienia się na celach krótkoterminowych i gubienia całościowego obrazu budowanego systemu.
Celne zaplanowanie złożonego projektu ma bardzo małe szanse powodzenia, niezależnie, czy stosuje się agile'a, czy waterfalla (http://blog.mavenlink.com/21-shocking-project-management-statistics-that-explain-why-projects-continue-to-fail). Scrum nie został stworzony do pracy nad projektami, lecz nad produktami ( trochę o różnicy można poczytać tutaj https://www.scrum.org/resources/blog/project-mindset-or-product-mindset ). Jeśli chodzi o drugą część Twojej wypowiedzi, to korzystanie ze sprintów, które trwają od 1 do 4 tygodni pozwala biznesowi sprawdzić, czy produkt rozwija się w dobrym kierunku.
- Każde zadanie niby da się podzielić na N małych zadań. Gorzej jak się nie da. Przymus dzielenia zadań na małe zadania powoduje, że duże zadania których nie da się łatwo podzielić, wymagające np. zmian w architekturze / projekcie nigdy nie wychodzą poza backlog. Premiowane są taski trywialne, które dają efekty szybko i zrobią dobre wrażenie w trakcie retrospekcji.
W "Świętej Księdze" ( :) ) jaką jest Scrum Guide nie ma słowa o tym, że zadania należy dzielić na mniejsze, ale rzeczywiście jest to uznawane za dobrą praktykę, ponieważ zwiększa szansa na to, że będzie można skończony inkrement pokazać udziałowcom.
Jeśli na chwilę obecną trudno jest podzielić zadanie na mniejsze, to może warto zrobić Spike'a, żeby więcej dowiedzieć się na dany temat? Zdaję sobie sprawę, że dzielenie historyjek bywa momentami piekielnie trudne. Czy mógłbyś podać przykład czegoś, czego nie da się podzielić? Może wspólnie uda nam się zastanowić nad tym co można by było zrobić.
- Agile manifesto zakłada, że interakcje są ważniejsze niż proces. Tymczasem w wielu implementacjach Scrum widziałem coś zupełnie odwrotnego. Proces ważniejszy niż ludzie, do poziomu religijnego wręcz - "nie możesz robić tego zadania, bo nie było zaplanowane na ten sprint!" wtf?
W Scrumie bardzo istotny jest Cel Sprintu. Chodzi o to, żeby dostarczyć biznesowi, to co jest dla niego najważniejsze. Backlog Sprintu można modyfikować wraz z tym jak dowiadujemy się więcej o tym co zostało do zrobienia aby ten cel wykonać.
- Standupy - marnowanie czasu zespołu. Bo niby jak programista nie opowie co robi, to będzie cały dzień oglądał koty w internecie?
Stand-up nie jest batem to pracy :). Jest to moment w którym zespół wspólnie planuje najbliższe 24h pracy w kontekście tego co należy zrobić aby osiągnąć cel sprintu. Nawet w niesamowicie zgranych zespołach, w których wszyscy pracowali obok siebie, w tej samej strefie czasowej można zauważyć, że nie wszyscy wiedzą o wszystkim co może być istotne dla powodzenia Sprintu. W zależności od tego jak wielki mamy zespół, drastycznie rośnie liczba kanałów komunikacyjnych. ( https://www.izenbridge.com/blog/how-to-calculate-communication-channels/ ) Stand-up jest mechanizmem, który kosztem maksymalnie 15 minut (w praktyce nic nie stoi na przeszkodzie, żeby potrwał zdecydowanie mniej) może pomóc sformułować sensowny plan na najbliższą dobę z uwzględnieniem tego jak poradzić sobie z problemami, które ktoś napotkał i oszczędzając znacznie więcej czyjegoś czasu.
- Zbyt duży wpływ klienta na planowanie, zbyt mało swobody dla programistów / architektów / analityków. Klient często g*** wie. Jakby Ford słuchał klientów, to musiałby im dać "szybsze konie". Nie twierdzę, że klienta nie należy słuchać, ale mam wrażenie, że Scrum jest oparty na błędnym założeniu że programista nie jest w stanie pojąć, czego chce biznes.
Product Owner odpowiada za to, żeby zdecydować co ma zostać zrobione, za to Zespół Deweloperski decyduje się na to jak to ma zostać wykonane. Scrum daje to, że klient zobaczy to o co prosił po 1-4 tygodniach, a nie po dłuższym okresie. Parę lat temu pracowałem w projekcie waterfallowym (chociaż był on nazywany Scrumem, bo były Planningi i Scrumy ). Paruset stronicowy SIWZ, armia analityków biznesowych zadbała o to, żeby stworzony projekt był zgodny ze specyfikacją. No i było zgodne mimo, że wiele rzeczy nie miało sensu na co klient zwrócił uwagę jak tylko przyszło do odbioru projektu. Gdyby działał tam Scrum, to jestem przekonany, że tego nieporozumienia udało by się uniknąć.
- Zbytni nacisk na implementację i deprecjonowanie wagi procesu wstępnego projektowania i roli indywidualnych talentów. Wiele genialnych systemów powstało jako projekt jednego człowieka lub małej grupy ludzi. Klasyczny przykład: TeX. O ile pisać kod można wspólnie, to nigdy nie widziałem, aby wspólne projektowanie się udało. Projektowanie wymaga czasu i nie zawsze daje się je zmienić w kawałku sprintu.
Scrum nie zabrania robienia projektów. Nie zmusza też do tego, żeby wszystko robić wspólnie, chociaż niejednokrotnie widywałem jak programiście zbierali się wspólnie przy tablicy i rysowali projekt rozwiazania.
Czy TeX był projektowany przez dłużej niż miesiąc zanim powstał jego pierwszy działający fragment? Przyznam, że nie znam jego historii.
Może w Twoim przypadku pomogłoby stworzenie prototypu lub wydłużenie sprintu?
- Brak własności kodu i rozmywanie odpowiedzialności. Założenie, że każdy może grać na każdej pozycji jak piłkarze reprezentacji Niemiec w piłce nożnej nie działa w IT. Owszem, mogę usiąść do każdego kawałka naszego kodu i coś w nim poprawić, ale zajmie mi to 5X tyle czasu niż w kodzie, który sam pisałem / projektowałem. Założenie takie jest nieefektywne.
Podsumowując: Scrum szkodzi. Leczenie waterfalla scrumem to jak leczenie dżumy cholerą.
Oczekuję konstruktywnej polemiki. Może u Was Scrum / agile działa?
Jeśli nie Ty pisałeś dany fragment kodu to może się zdarzyć, że praca nad nim pójdzie Ci wolniej. To jest zupełnie normalne. Następnym razem jeśli przyjdzie Ci pracować w tym obszarze pójdzie Ci już jednak lepiej. Możesz też poprosić kolegę o wprowadzenie do tematu, albo programowanie w parze, aby poszło Ci sprawniej. Zmniejsza się wtedy ilość tzw. silosów wiedzy w zespołach, które mogą być sporym zagrożeniem dla projektów. W Scrumie nie jest najważniejsze to ile zrobią w nich poszczególni członkowie zespołu, ale to jaki będzie łączny przepływ pracy. Przyszła mi do głowy pewna metafora, która być może choć trochę to zobrazuje. Nie jest ważne ile jedna osoba dotnie desek, a ile druga wbije gwoździ, lecz to, żeby na koniec sprintu powstała z tego użyteczna szafka :).