Scrum nie działa

2
LukeJL napisał(a):

Rozwój produktu to maraton, tymczasem jest tak, że dzieli się rozwój produktu na jakieś "sprinty", które wręcz promują krótkowzroczność. Bo masz się skupić na zrobieniu taska na sprint i nic cię nie interesuje. Tzn. sprinty w teorii to bardzo fajny pomysł, ale w praktyce właśnie nie do końca, takie mam wrażenie.

5

ja tam lubie korpo scruma, bo wprowadza jeszcze mniejsza przejrzystosc tego co sie tak naprawde dzieje.
oczywistym minusem sa planningi, standupy itp ale mialam szczescie ze wystarczylo dac telefon na mute i robic swoje zanim sie reszta przestanie jakac.
przy odpowiedniej znajomosci projektu bylam zawsze w stanie dostarczyc duzo story pointow, czasem wiecej niz reszta teamu, zajmujac sie glownie tym co mi sie podoba (i 80% moich jir zalozona przeze mnie, biznes happy ze takich zaangazowanych programistow ma ;))

3

No dobra popłakaliśmy, to spójrzmy na alternatywy - waterfall? Już zapomnieliście projekty co po kilku latach pełnego sukcesu rozwoju produktu dostarczały coś co nie działa? A może wręcz przeciwnie - żadna tam metodyka, czyste nap....e kodu - debeściaki nie planują? Projekt za 10 baniek w twardej walucie do przepalenia i przez 2-3 lata na wszelkie pytania góry odpowiadamy w zależności od okoliczności:
"będzie pan zadowolony",
"będzie jak napiszemy, nie da się oszacować",
"my wiemy lepiej czego potrzeba w elektrowni atomowej, nie miejcie nas za idiotów, każdy miał fizykę w liceum",
"mój kod trzymam u mnie na dysku, bo jak ktoś czyta, to później tylko marudzi, albo jeszcze coś zmieni i zepsuje".

2

@piotrpo:

Odpowiedź jest prosta - codzienna harówka ze wszystkich stron, bez korpobullshitu.

  1. Daily meetingi na których ludzie się deklarują, co zamierzają robić i ile im to zajmie.
  2. Analitycy odpowiedzialni za wymagania.
  3. Programiści odpowiedzialni za swoją pracę.
  4. PM odpowiedzialny za pracę całego zespołu.
  5. Im większy projekt tym większa faza zerowa - projektowanie i spisywanie wymagań.
  6. Dostarczanie jakiegoś kawałka co wyznaczony czas jest ok. Przy czym głupoty typu retro można olać.
  7. Zespół wycenia wymagania na bieżąco, w razie problemów wie że może zadzwonić do analityka lub nawet klienta żeby dopytać ocb.
  8. I przede wszystkim - jasno wyznaczamy odpowiedzialnych za zadania. Nie ma "my, zespół", jest "programista nie dowiózł", ewentualnie "analityk późno dostarczył wymagania", a nawet "klient wysłał je o dwa dni za późno".
  9. Tzw. transparency przede wszystkim, kiedy ktoś coś zawalił to mówi się o tym głośno. Kiedy coś nie pasuje - mówi się o tym głośno.
  10. Założyłem że zespół składa się z osób dojrzałych. Osoby zachowujące się jak dzieci położą każdy projekt, niezależnie od metodyki.

Jest to w jakimś sposób zwinne, ale nie jest to Scrum.

2

Ja wiem, że to znowu post w stylu scrum tak, wypaczenia nie itp, ale patrzę na to z perspektywy takiego Prince II (moda sprzed 15 lat), że o jakichś tam RUP tylko wspomnę. Ilość pracy wkładana w samo liczenie metryk i wypełnianie dokumentacji, której nikt nie czytał spokojnie wystarczyła by na zamknięcie niewielkiego projektu. Oznacza to, że dla mnie Scrum jest gigantycznym skokiem w stosunku do poprzednich podejść. Jeżeli nie da się jak ktoś tu twierdził oszacować zadania w perspektywie 2 tygodniowego sprintu, to spróbujcie oszacować je w perspektywie 2 letniego projektu, a tego przecież oczekiwano od PMa. W tej chwili scrum, czy agile generalnie wchodzi w fazę w której staje się obiektem memów i dobrze, za kilka lat przyjdzie moda na nową, odważną metodykę będącą odpowiedzią na problemy Scruma i wprowadzającą swoje własne.

0

Już zapomnieliście projekty co po kilku latach pełnego sukcesu rozwoju produktu dostarczały coś co nie działa?

Można wcielić metody lean i rozwój produktu potraktować jako pole do eksperymentów - np. robisz jakiś proof of concept czy MVP (minimum viable product) i potem patrzysz, czy jest to, czego potrzebujesz, wypuszczasz, patrzysz jak użytkownicy reagują. I produkt ewoluuje, nabywa kolejnych użytkowników itp. Masz cały czas działający produkt i nie masz wtedy sytuacji, w których budujesz przez kilka lat coś, a potem to nie działa.

Zamiast wymyślonych "punktów historii" licytowanych w planning pokerze czy w innej karciance, to można liczyć bardziej realne metryki, np. liczbę ściągnięć aplikacji czy przepływ hajsu (co też rodzi potem różne patologie, że ludzie się skupiają na jakichś mikrooptymalizacjach w stylu przesunęliśmy o 10 pikseli banner na stronie i nasze przychody z reklam wzrosły o 0.001% Idziemy do przodu! , ale to juz inny temat).

Zamiast planowania backloga na 1000 zadań do przodu, jak to się robi w waterfall Scrumie, można powoli rozwijać produkt i "reagować na zmiany".

Większym problemem wydaje się być biznes/klienci, którzy nie umieją schować swoich ambicji i zamiast zamówić prosty MVP, który potem wypuszczą i który będzie się potem rozwijać, to każą wypuścić od razu dopracowaną na tip-top aplikację z mnóstwem ficzerów. A takie aplikacje robi się przez kilka, kilkanaście miesięcy, zanim ujrzą światło dzienne.

To jest jeden z powodów, dla których pozorny "agile" zamienia się w "ukryty waterfall" :/

Oznacza to, że dla mnie Scrum jest gigantycznym skokiem w stosunku do poprzednich podejść.

Przed Scrumem był jeszcze ruch Agile, który gdzieś się zatarł i nikt już o nim nie pamięta (Scrum to dla mnie trochę takie przeciwieństwo Agile'a, bo zasady Scruma przeczą kilku punktom manifestu Agile). Poza tym też kiedyś był XP (Extreme Programming), który jak dla mnie ma zasady o wiele bardziej sensowne niż Scrum (może dlatego, że XP to zasady programistyczne, a Scrum to po prostu kolejna korpo polityka). Poza tym ruch Lean Startup też próbuje odpowiedzieć na bolączki poprzednich podejść...

13

SCRUM i żadna inna, (nowa) metodyka nie będą (uniwersalną) odpowiedzią na problemy. Projekty są różne.
Metodyki wytwarzania powinny być dostosowane do

  • projektu,
  • zespołu i jego doświadczenia,
  • kultury firmy
  • klienta
  • narzędzi
    I jeszcze paru innych rzeczy.

SCRUM jest CIEŻKĄ metodyką, która ma jakiś sens przy mało doświadczonym/zgranym zespole, w projekcie gdzie można manipulować scopem i przy średniej wielkości firmie. Klient musi też być wystarczająco sensowny, żeby nie popadł w samozachwyt nad swoją zwinnością.

Bardziej doświadczone zespoły powinny iść w kierunku programming motherfucker i upraszczać proces .
Małe sturtupy i januszsofty w zasadzie skazane są na: metodykę BIN. To mniej więcej to samo co programming motherfucker tylko robione przez amatorów. Po prostu muszą liczyć na szczęście i zapał komandosów.... Żadna metodyka nie zastąpi doświadczenia, a wprowadzanie przez niedoświadczonych ludzi zabawy w agile skutkują tylko dodatkowym nakładem pracy i defokusacją.

Projekty typu "maintenance" powinny raczej z metodyk typu kanban coś brać.

Projekt fixed price jest w zasadzie skazany na jakiś waterfall - i tak nie jesteście agile i cała zabawa tylko stratą czasu. Serio. Można zrobić ten waterfall ludzkim. Ciekawostka: chociaż słyszałem o legendarnych projektach waterfall - to jednak taki waterfall z agilowego obrazka: 2 lata robimy ficzery i na koniec kompilujemy i prezentujemy przed klientem istnieje głównie w wyobraźni klaunów. W praktyce już od lat 90-tych zeszłego wieku były promowane wszelkiego rodzaju procesy iteracyjne/sprialne Co kilka tygodni była normalna prezentaja wynków /postępu prac. Korpa, które się tego nauczyły zmieniły tylko w dokumentach szyld RUP na SCRUM, iteracja zmieniła się w sprint i zostało po staremu)

Duże korpa niestety są zawsze skazane na klęskę - jakby genialny proces nie wymyśleć to zeżre go management we własnych zabawach.

Takie rzeczy jak review, dod, sprawna komunikacja w zespole, kontakt z klientem przydają się zasadniczo w każdego rodzaju projekcie (nawet w fixed price).

Polecam też jedną rzecz eksperymentować. NIe znajdziecie swojej dobrej metodyki jak nie przeprowadzicie kilku eskperymentów i będziecie się trzymać książki.
Sprinty jednodniowe, brak sprintów, standupy co godzinę - dały mi całkiem ciekawe efekty.

I na koniec ważny fakt. Jak zespół jest dobry i zgrany to mu nawet SCRUM nie przeszkodzi.
Często nowe metodyki sa testowane przez doświadczone , zgrane zespoły, na projektach, które nie są obciążone politycznie, i nie są krytyczne dla klienta.
Prawie zawsze z tego wychodzi sukces story, które można prezentować na konferencjach. Niestety, Ty w swoim korpo raczej tego nie powtórzysz.

0

Przed Scrumem był jeszcze ruch Agile

A przed ruchem Agile przez duże A był jeszcze agile software development, tutaj fajne omówienie jak przez niezrozumienie idei (albo celowe działanie) powstała z tego gałąź biznesu i kult cargo:

Tutaj inny wykład tego gościa, omawiający temat z pozoru inny, ale mocno obrazujący bezsensowność jednolitych procesów:

https://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas

2
piotrpo napisał(a):

No dobra popłakaliśmy, to spójrzmy na alternatywy - waterfall? Już zapomnieliście projekty co po kilku latach pełnego sukcesu rozwoju produktu dostarczały coś co nie działa? A może wręcz przeciwnie - żadna tam metodyka, czyste nap....e kodu - debeściaki nie planują?

No tak, jeśli ktoś nie jest za PiS, to jest za PO.
Ale można też nie popadać w skrajności i stosować pragmatyzm oraz zdrowy rozsądek. I nie szukać na siłę nazw na wszystko.

piotrpo napisał(a):

za kilka lat przyjdzie moda na nową, odważną metodykę będącą odpowiedzią na problemy Scruma i wprowadzającą swoje własne.

Obym tylko nie musiał się dostosowywać do żadnych mód i dalej pracować normalnie.

0

Skupcie się na czytaniu kodu ze zrozumieniem. Działa poprawnie napisany kod. Proces nie napisze kodu sam. Myślenie że słabi programiści pracujący w super procesie stworzą coś dobrego to mit. Te procesy to bzdury.
Linux kernel jaki ma proces ? Jaki proces używają naukowcy jak piszą algorytmy?

2

Linux kernel jaki ma proces ?

To co widać na listach dyskusyjnych to code review, pull requesty, poprawki i tak w kółko. Co się dzieje w firmach, które zatrudniają programistów Linuksa to nie widać wprost.

Jaki proces używają naukowcy jak piszą algorytmy?

Ale konkretnie co? Większość prac naukowych zawiera krótkie programy pisane przez jedną lub dwie osoby. Algorytm wrzucany do pracy naukowej to zupełnie inna skala niż projekt pisany przez wiele lat przez wiele osób, które muszą się zgrać.

2
Krolik napisał(a):

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".

Tutaj ciekawe spojrzenie na temat estymacji:

5

Tylko, że estymacja ma działanie przede wszystkim psychologiczne. Ma uspokoić klienta/przełożonego, który w przeciwieństwie do programisty nie umie tolerować chaosu/ryzyka/niepewności, więc konkretna cyferka daje mu złudzenie kontroli i orientacji.

To tak jak z paskami postępu czy różnymi ETA. Zobaczenie, że pasek postępu jakoś idzie do przodu, albo że plik ściągnie się za 37 minut (nawet jeśli ściągnie się naprawdę za 2 godziny) jakoś uspokaja, wiemy, że nic się nie zepsuło.

Tak samo powiedzenie, że ficzer będzie zrobiony za 2 tygodnie, jakoś uspokaja klienta/przełożonego, nawet jeśli wiadomo, że to bujda i że po 2 tygodniach trzeba będzie mu powiedzieć, że jeszcze za kolejny tydzień, albo powiedzieć mu prawdę, że za 2 miesiące. Estymacja to takie jakby "kupowanie czasu", żeby stakeholder nie dowiedział się prawdy na początku i żeby się nie wściekł.

Tak samo Scrum. Patrząc od strony praktycznej, tylko spowalnia pracę, jednak z drugiej strony daje jednak pewne poczucie dyscypliny, misji, gry - innymi słowy podnosi morale w zespole, pokazuje, że to nie jest tylko programowanie, ale że radość, interakcja z innymi, wspólne pokonywanie przeszkód, wspólne dzielenie się trudnościami i sukcesami w czasie standupów itp. Czyli Scrum to takie team building, jak te wszystkie firmowe gry integracyjne.

Więc od strony technicznej wiadomo, że estymacje to głupota, a Scrum nie ma sensu - ale nigdy nie chodziło o stronę techniczną ani o sens, tylko o działanie psychologiczne.

0

Akurat estymacja, moim zdaniem, ma sens i fajnie jest estymować dobrze, tylko, że to kosztuje czas zespołu. Ja niestety zazwyczaj niedoszacowuję - miało być na 15 stycznia, jest na 14 lutego. Cały czas nad tym pracuję.
Jeżeli nie podaję estymat to tzw. biznes jest zaniepokojony i myśli, że brak estymaty = nieskończoność :-). Ma to działanie motywujące i mobilizujące, żeby nie odkładać zadań w nieskończoność.

3

@goJavaGo
Nie wiem czy wiesz, ale w kilku zdaniach streściłeś w zasadzie wszystko, co jest złego z estymacją.

Akurat estymacja, moim zdaniem, ma sens i fajnie jest estymować dobrze

Czyli: wiele ludzi ma "zdanie" (tj. przyjmuje na wiarę) że estymacja "ma sens" i marzy sobie o tym, że "fajnie jest estymować dobrze". Czyli wishful thinking.

Mimo, że estymacja:

kosztuje czas zespołu

Oraz programiści "zazwyczaj niedoszacowują":

miało być na 15 stycznia, jest na 14 lutego.

Jednak mimo ciągłych porażek, to jeśli spytasz programistę o dokładność estymacji to ci powie:

Cały czas nad tym pracuję.

I ciągle się łudzi, że następnym razem lepiej oszacuje (czyli "szaleństwem jest robić wciąż to samo i oczekiwać różnych rezultatów").

Niestety programiści są nękani przez Januszy biznesu:

biznes jest zaniepokojony

stąd ciągła potrzeba kłamania biznesowi, Januszom, którzy koniecznie wymagają tych estymatów, bo są niedojrzali
emocjonalnie i nie umieją poruszać się w obszarze ryzyka, wolą słodkie kłamstwa typu "Titanic nigdy nie zatonie".

No i na deser:

Ma to działanie motywujące i mobilizujące, żeby nie odkładać zadań w nieskończoność.

Prawo Parkinsona - "praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie". Co akurat bywa optymistyczne. Bo czasem okazuje się, że ludzie mogliby być bardziej wydajni, gdyby dać krótsze deadline'y, bo czasem estymacja bywa również zawyżona, ale przeszacowana estymacja okazuje się tak samo zła jak niedoszacowana.

Bo jeśli niedoszacowujesz:

miało być na 15 stycznia, jest na 14 lutego

to jesteś w dupie, przekroczyłeś deadline.

Jednak jeśli coś się da zrobić w 5 dni, ale jakiś matoł zestymował 2 tygodnie, to będzie to robione i tak dwa tygodnie, po prostu wolniej będziecie pracować. Więc i tak jesteś w dupie, bo przez złą estymację tracisz czas.

Czyli no estimation = no problem?

Chociaż z drugiej strony deadline'y są przydatne. Widzę to po studiach. Gdyby nie deadline to nigdy bym niczego nie zaliczył, a jeśli wiem, że np. egzamin jest w poniedziałek, to w niedzielę zaczynam się uczyć i jakoś zaliczam na 3.

0
LukeJL napisał(a):

przeszacowana estymacja okazuje się tak samo zła jak niedoszacowana.

Z tym się nie zgodzę, bo nawet uwzględniając prawo Parkinsona konsekwencje są zgoła inne, tutaj masz wykres z "Software Estimation: Demystifying the Black Art" McConnella:

estimates

0

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. :)

  1. 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ć.

  1. 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.

  1. 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ć.

  1. 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ć.

  1. 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.

  1. 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ąć.

  1. 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?

  1. 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 :).

1

@Michał Drzewiecki:

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.

Podejmowanie decyzji biznesowych na podstawie zgadywanek (bo inaczej tego nie można nazwać) programistów nie brzmi jak dobry plan.

estimates

Jeśli w trakcie estymowania pojawią się dwie zupełnie skrajne wartości, to ponownie jest to sygnał mobilizujący do dyskusji.

A co jeśli wszyscy dadzą takie same wartości - czy to oznacza, że szacunek jest prawidłowy?

korzystanie ze sprintów, które trwają od 1 do 4 tygodni pozwala biznesowi sprawdzić, czy produkt rozwija się w dobrym kierunku.

Sprinty nie są tu jedynym sposobem na osiągnięcie tego - imo jednym z gorszych w pracy twórczej -> https://en.wikipedia.org/wiki/Candle_problem
Brak Scruma !== waterfall

0

Podejmowanie decyzji biznesowych na podstawie zgadywanek (bo inaczej tego nie można nazwać) programistów nie brzmi jak dobry plan.

Kto lepiej Twoim zdaniem oszacuje pracę?

Jeśli w trakcie estymowania pojawią się dwie zupełnie skrajne wartości, to ponownie jest to sygnał mobilizujący do dyskusji.

A co jeśli wszyscy dadzą takie same wartości - czy to oznacza, że szacunek jest prawidłowy?

To może znaczyć, że podobnie postrzegają poziom skomplikowania zadania lub jego pracochłonność. Estymacja nie jest wynikiem, które ma 100% prawdopodobieństwo. https://en.wikipedia.org/wiki/Estimation
Im bardziej zespół jest zgrany i ma większe doświadczenie, tym celniejsza jest estymata.

korzystanie ze sprintów, które trwają od 1 do 4 tygodni pozwala biznesowi sprawdzić, czy produkt rozwija się w dobrym kierunku.

Sprinty nie są tu jedynym sposobem na osiągnięcie tego - imo jednym z gorszych w pracy twórczej -> https://en.wikipedia.org/wiki/Candle_problem
Brak Scruma !== waterfall

Celna uwaga :). Co Twoim zdaniem sprawdza się lepiej w warunkach dla których został utworzony Scrum?

0

@Michał Drzewiecki:

Kto lepiej Twoim zdaniem oszacuje pracę?
Co Twoim zdaniem sprawdza się lepiej w warunkach dla których został utworzony Scrum?

Nie szacować (nie zgadywać) - mierzyć i prognozować imho -> Scrum nie działa

To może znaczyć, że podobnie postrzegają poziom skomplikowania zadania lub jego pracochłonność.

A dyskutujecie podczas planningu o US które mają zgodne szacunki? Zgodność może oznaczać milion rzeczy.

Estymacja nie jest wynikiem, które ma 100% prawdopodobieństwo.

Nie musisz mi tego mówić, skoro nazwałem szacowanie "zdagywankami" ;)

Im bardziej zespół jest zgrany i ma większe doświadczenie, tym celniejsza jest estymata.

Im bardziej zgrany zespół tym zgodniejsze estymaty, ale czy bardziej trafne to bym polemizował :)

1

Jeśli w trakcie estymowania pojawią się dwie zupełnie skrajne wartości, to ponownie jest to sygnał mobilizujący do dyskusji.

Z jednej strony racja, z tych wszystkich estymacji jedyne dobre, co płynie, to że ludzie mogą podyskutować na temat szczegółów implementacji danego zadania. Problem jednak, że i tak potem wygra najbardziej głośny/wygadany programista. To mnie właśnie wkurzało w tym całym planning pokerze i estymacjach grupowych, że koniec końców i tak większość przegaduje jednostkę. Jeśli się nie zgadzasz z estymacją, to musisz głośno krzyczeć i argumentować, żeby inni zmienili swoje zdanie, albo po prostu spasować i przyjąć estymację grupową, nawet jeśli widzisz, że jest mocno zaniżona.

Największą głupotą jest, że nawet jak dany ficzer implementuje jeden programista, to estymuje cała grupa* (mimo, że w zasadzie trudność implementacji zależy od tego kto robi, a nie od obiektywnej trudności czegoś).

* przynajmniej tam, gdzie ja pracowałem, estymowała cała grupa. Chociaż też zależy gdzie. Czasem też menedżer odgórnie estymował, albo estymował senior - w każdym razie i tak patologia pozostaje patologią - jeśli estymuje osoba, która nie będzie tego implementować.

0

@Maciej Cąderek:

Nie szacować (nie zgadywać) - mierzyć i prognozować imho -> Scrum nie działa

Kwestia estymat lub jej braku jest bardzo ciekawa i mogłaby nawet zasługiwać na osobny temat :). Dziękuję również za ten wykład Allena - trafnie uderza w wiele dysfunkcji.
Jeśli chodzi o estymacje w kontekście Scruma, to nie mówi on nic o sposobie estymowanie takim jak czas idealny, story pointy, koszulki, owoce, NFC'ki czy też TFB'ki ( https://twitter.com/pawelbrodzinski/status/555028771645194242 ). Scrum nie nakłania też do wiążących kontraktów, czy też dotrzymywanie terminów.

Estymacje mogą być bardzo przydatne biznesowi do podejmowania decyzji, czy w ogóle coś robić bądź nie. Przykładowo biznes chciał zrobić historyjkę A, którą uważał za malutką, a w praktyce była bardzo problematyczna. Gdy okazało się jak jest bardzo złożona "pod spodem", to padała decyzja, że niestety leci na "Won't do" i zamiast tego zostaną zrobione dwie inne historie, które łącznie dają większą wartość biznesową. Polecam sobie tutaj wyobrazić dwuwymiarowy układ na którego w jednej osi mamy priorytet, a na drugiej złożoność.

Korzystanie z estymacji nie przeszkadza w tym, żeby dokonywać pomiarów i prognoz. Przykładem może być sprawdzanie jak sobie radzimy w obecnym releasie przy użyciu Version Report'u, który możemy podejrzeć w Jirze. Na podstawie naszego velocity predykcja pokazywała, że nawet w optymistycznym wariancie zabraknie nam 2 tygodni do zrobienia wszystkiego co zakładaliśmy, więc biznes podjął decyzję, że mamy nie rozpoczynać pracy nad pewną funkcjonalnością.

Podsumowując, moim zdaniem oszacowania złożoności w połączeniu z ich ich mierzeniem i prognozami przydają się biznesowi w podejmowaniu decyzji, czy to w krótkim okresie (sprintu), czy też w dłuższym okresie.

A dyskutujecie podczas planningu o US które mają zgodne szacunki? Zgodność może oznaczać milion rzeczy.

Najpierw rozmawiamy o historyjce, a dopiero potem estymujemy.

Im bardziej zgrany zespół tym zgodniejsze estymaty, ale czy bardziej trafne to bym polemizował :)

Czy mógłbyś się podzielić swoimi doświadczeniami?

@LukeJL:

Z jednej strony racja, z tych wszystkich estymacji jedyne dobre, co płynie, to że ludzie mogą podyskutować na temat szczegółów implementacji danego zadania. Problem jednak, że i tak potem wygra najbardziej głośny/wygadany programista. To mnie właśnie wkurzało w tym całym planning pokerze i estymacjach grupowych, że koniec końców i tak większość przegaduje jednostkę. Jeśli się nie zgadzasz z estymacją, to musisz głośno krzyczeć i argumentować, żeby inni zmienili swoje zdanie, albo po prostu spasować i przyjąć estymację grupową, nawet jeśli widzisz, że jest mocno zaniżona.

Czy w trakcie planningów macie osobę odpowiedzialną za facylitację? To, że ktokolwiek musi krzyczeć, żeby przekazać swój widzenia jest sporą dysfunkcją i retrospektywa jest dobrym miejscem w którym mógłbyś to poruszyć. Gdybyś chciał to mogę dać Ci kilka wskazówek, jak byś mógł do tego podejść.

Największą głupotą jest, że nawet jak dany ficzer implementuje jeden programista, to estymuje cała grupa* (mimo, że w zasadzie trudność implementacji zależy od tego kto robi, a nie od obiektywnej trudności czegoś).

Complexity != effort ( https://www.clearvision-cm.com/blog/why-story-points-are-a-measure-of-complexity-not-effort/ ) . Jeśli wspólnie ustalicie, że złożoność wynosi 3UP (Unicorn Pointy :) ), a jeden członek zespołu zrobi to w 1 dzień, a inny zrobiłby to w 3, to wszystko jest nadal w porządku. Ważne jest to ile wspólnie jesteście w stanie dostarczyć.

* przynajmniej tam, gdzie ja pracowałem, estymowała cała grupa. Chociaż też zależy gdzie. Czasem też menedżer odgórnie estymował, albo estymował senior - w każdym razie i tak patologia pozostaje patologią - jeśli estymuje osoba, która nie będzie tego implementować.

W Scrumie za estymacje odpowiedzialny jest cały Zespół Deweloperski. Nie menadżer, nie senior, nie właściciel produktu, ani nie scrum master :).

2

mam PSM 1 i jakieś 7 lat doświadczenia w pracy ze skramem jako deweloper, jednoznacznie mogę stwierdzić ze skram służy głównie menago żeby pochwalić się jak idą słupki i żeby dowalić roboty jak team wyrobi się z taskami szybciej. code-review i refaktoring, po co to komu, dla większości menago nie ma to żadnej wartości.

jak masz ułożony team dobrych devow to poradzą sobie świetnie bez tego.
jeżeli nikt nie ma pracy dla ciebie to stwórz sobie sam stanowisko i powiedz innym, ze jesteś im potrzebny

4
Michał Drzewiecki napisał(a):

Oszacowanie wielkości zadania przez Zespół Developerski daje istotną [itd. bla bla bla z książeczki]

Tutaj dzielimy się doświadczeniami, które wskazują, że nie dają. I zespołowi i biznesowi wystarczają do planowania (krótko i długofaloweg) zgrubne estymaty - godzina, dzień , tydzień , miesiąc. Natomiast SCRUmowe zespoły rypią tymi planning pokerami i innymi itracą czas na kłótnie: czy 5 czy 8. SCRUmy za dużo czasu poświęcają na numerki.

  1. 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.

to korzystanie ze sprintów, które trwają od 1 do 4 tygodni pozwala biznesowi sprawdzić, czy produkt rozwija się w dobrym kierunku.

Sprinty 4 tygodniowe to jakiś niezły żart. Jedyne miejsce gdzie wg mnie się sprawdzają to kładzenie regipsów. W normalnym biznesie i projekcie sytuacja jest na tyle dynamiczna, że jesli w drugim tygodniu sprintu zespół robi to co zaplanował w pierwszym to znaczy, że cały biznes jest na urlopie. 4 tygodnie to jest właśnie waterfall - tylko na małą skalę.

  1. 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ć.

To chyba zdanie najbardziej pokazuje do czego prowadzi SCRUM i trzymanie się świętych ksiąg. Otóż w normalnym procesie, w odniesieniu od SCRUMa bardzo ważne jest realizowanie tego co dla biznesu jest najważniejsze w danym momencie. Realizowanie Celu Sprintu to dobry przyklad jak to się może rozjechać. Co, jeśli już 32 minuty po planowaniu biznes odkryje, że wpadły o wiele wążniejsze zadania do zrobienia? albo zadania ze sprintu właśnie straciły sens? Mamy przez nastepne 2 tygodnie robić Cel sprintu, żeby ładne numerki wyszły i podnieść morale ?

Btw. w jednej firmie, której udało się wleźć w taki postSCRUM biznes potrafił zmienić zdanie 3 razy w ciągu tygodnia i zasypywaliśmy dopiero co wykopane rowy. Czy nam to bardzo kładło morale? Nie, bo zadania były ciekawe i widać było, że firma walczy o utrzymanie pozycji lidera na rynku i wyprzedzenie konkurenci o lata świetlne, dlatego było dużo eksperymentów, w tym oczywiście część nieudanych.

Najgorsze jednak w dążeniu do realizacji Celu sprintu jest promowanie kiepskiej jakości czyli dylematy - albo pokażę to na demo czwartek, ale muszę zrobić chamskiego copy paste, albo zrobię kod porządnie, ale będzie dopiero w poniedziałek (i drama bo numerki źle wyjdą...). To co się stało z kodem jednego systemu po 2 latach SCRUma to miazga niestety (ale dało się stopniowo wyczyscić).

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.

Chyba, że masz normalny zespół, w którym ludzie wiedzą na bieżąco co kto robi, bo ze sobą rozmawiają. W praktyce trwa to o wiele więcej niż 15 minut, ale za to rozmawiają w dogodnym momencie i kontekście. Da się o wiele większą ilością informacji podzielić.
Do standupów mam mieszane uczuci a- w końcu wypracowaliśmy zasadę, że są nieobowązkowe - jak ktoś chce czymś się podzielić, albo ma wrażenie,że nie wiemy gdzie jestesmy - to mówi i robimy ad hoc standup.

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

Jak miałeś SIWZ czyli efektywnie fixed price i założony scope to robienie SCRUMa i dyskutowanie z klientem co ma być zrobione to niegospodarność. Chyba, że nie interesuje was otrzymanie kasy za projekt. No bo jak, jeśli nie zrobicie dokładnie tego co w zamówieniu...). Btw. już dwa razy byłem świadkiem takiego numeru. Raz, moim zdaniem, świadomie rozegrał to klient widząć, że team to SCRUmowe naiwniaki. Bardzo zwinnie zamawiał punkty, których nie było w konktrakcie (większym - więć była ładna kaka).

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.

Tylko, że członkowie zespołu nie są tacy sami, chodzą na urlopy, maja choroby. Zawsze mi się podobała drama Scrum Masterów, jak nie wiedzieli co zrobić z tzw. velocity skoro połowy teamu nie bedzie przez 2 następne sprinty. Może zabronić chodzić na urlopy? Czy jak nie ma 2 z 5ciu ludzi to mamy 60% wydajności rly? Btw. moja poprzednia firma w erze post scrumowej odkryła zajebistą sprawę - mieszanie ludzi między zespołami. Wczesniej za SCRUMa była naturalna tendencja do trzymania stałych zespołów (które dają takie łądne, przewidywalne velocity), z tego się zrodziła niezła patologia, bo ustała wymiana myśli technicznej...

0

@jarekr000000: Równie dobrze mógłbyś napisać (zgodnie z prawdą zresztą), że jakikolwiek nacisk na tempo, terminy, implementację rzeczy potrzebnych i na czas, to grzebanie jakości, bo zniechęca do code review, pokrywania kodu testami, refaktorowania kodu i generalnie zmusza do olewania wszystkiego co wykracza poza horyzont najbliższego deadline'u.

Wiadomo, że kompetentny, zmotywowany i dojrzały zespół zrobi więcej niż zbieranina patałachów, nawet jeżeli będą robić sobie dwa SM dziennie. Tylko oni sobie już wypracowali sposoby na komunikację, szacowanie czasu wykonania zadania, raportowanie wykonanej pracy i planowanie kolejnych zadań. Problem w tym, że takie zespoły to rzadkość, a wciąż trzeba robotę zaplanować, rozdzielić wymienić się informacjami o problemach, zagrożeniach i jednym ze sposobów poradzenia sobie z brakiem wypracowanych mechanizmów jest przyjęcie i dostosowanie już istniejących rozwiązań, takich jak Scrum. To co nazywasz postScrum, to wg. mnie stan oczekiwany i docelowy. Gorzej, jeżeli korpo nie pozwala na dojście do takiego stanu bo scrum meeting musi być codziennie, velocity jak się zmieni o 20% to tragedia i kilka tygodni dyskusji na temat powodów takiej katastrofy.

Problemem nie jest chyba sam Scrum, tylko podejście do niego w niektórych firmach, gdzie robi się z ~prostej metodyki coś na kształt religii z własnymi kapłanami, wyznawcami, a wszelkie pomysły by zmienić sposób robienia czegokolwiek traktowane są jak herezja.

1

@piotrpo

Problemem nie jest chyba sam Scrum, tylko podejście do niego w niektórych firmach, gdzie robi się z ~prostej metodyki coś na kształt religii z własnymi kapłanami, wyznawcami, a wszelkie pomysły by zmienić sposób robienia czegokolwiek traktowane są jak herezja.

Ale to o czym piszesz to nieodłączna cecha Scruma, ze Scrum Guide:

Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

Scrum z definicji jest niezmienny (ramy Scruma) i jest religiopodobny ;)

1

Też mam kilka uwag do Scruma, co prawda jako dev a nie jako PO, SM czy Bóg raczy wiedzieć kto tam jeszcze jest z jakimś "foxxy" określeniem w nazwie pełnionej funkcji - już samo to wprowadza zamieszanie.
Uważam, że Scrum się nie nadaje do projektowania/prowadzenia projektów. Wiem za to do czego się nadaje: do robienia reklamy dla dużych klientów, na zasadzie: "bo my to pracujemy w Scrumie, jesteśmy Agile i w ogóle to jesteśmy tacy fajni".

Jakie są dobre założenia Scruma:

  • wykorzystuje Sprinty, choć 3-4 tygodnie Sprintu to jakieś nieporozumienie, po takim okresie czasu zapomniałbym o czym jest projekt. Sprint powinien jak dla mnie trwać tydzień.
  • to tyle, więcej nie ma :P

Jakie są złe założenia Scruma:

  • podział ról na Scrum mastera, PO i resztę czyt. zespoły,
  • rozmycie odpowiedzialności, bo ani PO ani SM nie biorą odpowiedzialności, zespół często gęsto też nie bierze odpowiedzialności - odpowiedzialności ni ma, więc produkt wygląda tak jak wygląda,
  • Retro - kto to wymyślił? dla mnie to jest strata czasu, chcesz mieć realny feedback - idź do lekarza, masażystki, mechanika, kominiarza - ale nie zawracaj głowy innym "abo mi to się nie podobało, bo jak coś zrobiłem i to działało, ale przestało i mnie hejtujo" - tak, są to problemy Pierwszego Świata,
  • rozbicie planowania na planning i review, jak dla mnie to to samo, w projektowaniu trochę czasu spędziłem i tylko jedno jest pewne: to że Słoneczko wstaje i zachodzi, reszta to jest planowanie,
  • wycenianie zadania vel. Scrum Poker - z większym absurdem się nie spotkałem w życiu. Albo coś trzeba zrobić, albo nie - i tyle. Dobrze, że te wyceny nie są robione przy pomocy kostki k20, choć można tak zrobić przecież "te punkty nie mają żadnego znaczenia".

To tak z grubsza biorąc.

2

Jakie są dobre założenia Scruma:

  • wykorzystuje Sprinty, choć 3-4 tygodnie Sprintu to jakieś nieporozumienie, po takim okresie czasu zapomniałbym o czym jest projekt. Sprint powinien jak dla mnie trwać tydzień.

Mam wrażenie, że w wielu projektóach nie powinno być sprintów tylko stałe reagowanie i feedback. Standupy, (sync) co godzinę.(gdzie jesteśmy co robmy)
Lista zadań trochę jak w kontroli lotów, ściągamy z góry i jedziemy, wrzucamy na bieżąco do tej listy. PO - dostępny na zawołanie.
NIestety pracowałem tak, tylko na krótkich przykładach (kilka dni) więc możliwe, że nie działa na dłużej.
Bo o ile efekty takiej pracy były wręcz niesamowite -to

  1. robiłem to z doświadczonymi ludźmi (takimi, którym nawet by SCRUm nie zaszkodził)
  2. zmeczenie po 6ściu !!! godzinach takiej pracy jest duże, możliwe że jestem za stary, ale chyba bym nie dał rady tak dłużej pracować.
  3. Kluczowe jest w zasadzie posiadanie PO - na zawołanie. Nie zawsze sie da.
2
jarekr000000 napisał(a):

Mam wrażenie, że w wielu projektóach nie powinno być sprintów tylko stałe reagowanie i feedback. Standupy, (sync) co godzinę.(gdzie jesteśmy co robmy)
Lista zadań trochę jak w kontroli lotów, ściągamy z góry i jedziemy, wrzucamy na bieżąco do tej listy. PO - dostępny na zawołanie.
NIestety pracowałem tak, tylko na krótkich przykładach (kilka dni) więc możliwe, że nie działa na dłużej.
Bo o ile efekty takiej pracy były wręcz niesamowite -to

  1. robiłem to z doświadczonymi ludźmi (takimi, którym nawet by SCRUm nie zaszkodził)
  2. zmeczenie po 6ściu !!! godzinach takiej pracy jest duże, możliwe że jestem za stary, ale chyba bym nie dał rady tak dłużej pracować.
  3. Kluczowe jest w zasadzie posiadanie PO - na zawołanie. Nie zawsze sie da.

No ja nie jestem wielkim fanem sprintów, z przynajmniej trzech powodów (króre już tu się pojawiły):

  1. Cel sprintu i jego ramy czasowe stanowią zewnętrzna motywację, destrukcyjną przy pracy twórczej, przy rozwiązywaniu nieoczywistych problemów - stąd słaba jakość kodu, skróty, nieoptymalne rozwiązania, gromadzenie się długu technicznego.
  2. Mała elastyczność w obrębie sprintu.
  3. W przypadku przeszacowania - prawo Parkinsona

Ciekawą wariacją pokazanego przez Ciebie modelu wydaje się mob programming - z relacji innych (sam niestyty nie miałem okazji jeszcze wypróbować) daje bardzo dobre rezultaty.

Używał ktoś z Was takiego podejścia?

Jakby ktoś nie wiedział o co chodzi:

0

Przykładowo biznes chciał zrobić historyjkę A, którą uważał za malutką,
a w praktyce była bardzo problematyczna.
Gdy okazało się jak jest bardzo złożona "pod spodem

Taka idea: może ten cały "biznes" należałoby wypieprzyć na zbity ryj i ograniczyć jego rolę jedynie do roli inwestora? (czyli - dajcie nam hajs, zbudujemy wam aplikację, a potem będziecie mieć udział w zyskach). Wydaje się, że ta cała kultura startupowa w Sillicon Valley tak właśnie działa, że hakerzy piszą apki, a biznes inwestuje, i jakoś się to kręci.

Biznes złożony z ludzi, którzy chcą decydować (choćby o ficzerach, jakie mają się znaleźć w produkcie), a nie mają zielonego pojęcia o tworzeniu oprogramowania, to patologia systemowa (w sensie, że to nie kwestia estymacji czy ich braków, tylko raczej samego faktu, że biznes miesza się do tworzenia oprogramowania).

W Scrumie za estymacje odpowiedzialny jest cały Zespół Deweloperski.
Nie menadżer, nie senior, nie właściciel produktu, ani nie scrum master :).

Różnie to było. Jak pracowałem w takim typowym scrumowym zespole, to faktycznie cały zespół estymował. Ale to właśnie było na zasadzie "estymacja musi być jednogłośna, więc albo dajemy tę samą estymację, albo estymujemy do czasu, aż większość przekona mniejszość do swojej estymacji, ew. jak ktoś, kto się nie zgadza po prostu spasuje i dla świętego spokoju zgodzi się na błędną estymację". Ja miałem wrażenie, że ten cały Scrum Poker to po prostu taki Eksperyment Ascha powtarzany co tydzień https://pl.wikipedia.org/wiki/Eksperyment_Ascha

Jak na czymś takim można opierać planowanie działań? Czy to poważne? Mam taką hipotezę, że jeśli zamiast estymacji rzucałoby się kostką i na tej podstawie ustawiłoby się estymację - to na to samo by wyszło. Może nawet lepsze byłyby rezultaty.

To, że ktokolwiek musi krzyczeć, żeby przekazać swój widzenia jest sporą dysfunkcją
i retrospektywa jest dobrym miejscem w którym mógłbyś to poruszyć.
Gdybyś chciał to mogę dać Ci kilka wskazówek, jak byś mógł do tego podejść.

Ja miałem największą trudność z tym, że byłem nowy w zespole i nawet jak wysuwałem argumenty, że coś jest trudne, to ktoś wysuwał kontrargumenty, których nie umiałem skontrować (ponieważ za słabo znałem projekt), więc przystawałem dla świętego spokoju. W trakcie implementacji okazało się jednak, że wynikały niespodziewane trudności i zadanie było niedoszacowane (to kolejna patologia - że estymacje są sztywne - a w rzeczywistość jest taka, że robiąc coś dopiero odkrywamy wszystkie potencjalne trudności. Czasem już po 2-3 godzinach robienia - tj. fizycznego siedzenia w kodzie - okazywało się, że coś jest źle zestymowane, bo inaczej estymuje się przy konferencyjnym stole, a inaczej jak się widzi kod i próbuje zaimplementować).

1 użytkowników online, w tym zalogowanych: 0, gości: 1