Agile / Scrum - początek

somekind napisał(a):

Chyba nie Uncle Bob... Z jego postów wynika, że on w ogóle nie zdaje sobie sprawy z tego, jak "agile" wygląda w praktyce i broni go jak zakonnica dziewictwa.

Ano. Poziom wpisów godny moderatora.

No dobra, ta dyskusja chyba mi wyjaśniła wszelkie zawiłości. Wystarczy po prostu tworzyć oprogramowanie i starać się to robić jak najlepiej ;)

Zwykle powtarzam, że: jeśli zespół dobry to i agile/scrum mu nie przeszkodzi.
Jakkolwiek:
w firmie gdzie obecnie pracuje całkiem ten SCRUM całkiem działa ( o zgrozo - bo nie zgadza się to z moimi uprzedzeniami i poprzednimi doświadczeniami:-) ).
Zastanawiałem się dlaczego i możliwe, że przez:

• lekkie olewanie velocity, burndown chartów i innego badziewia (to znaczy nawet czasem widzimy te wykresy, ale nikt nimi nikogo nie straszy),
• samo velocity jest co prawda używane do prognozowania.. ale uśrednione z 3 ostatnich sprintów, bo czasem mamy taki super sprint, że wyjdzie 0 (nikt nie płacze) :-),
• PO jest ludzki i jak mu mówimy, że trzeba zrefaktorować to po prostu przyjmuje do wiadomości,
• jak się nie da skończyć story dobrze z testowaniem i review - to przerzucamy na następny sprint - bez bólu,
• każdy mówi w swoim dialekcie (taki kraj) - nikt nikogo nie rozumie, więc i tak długie Stand-d**y nie mają sensu,
• robimy eksperymenty i czasem coś w procesie zmieniamy (nakaz pair programmijng, zakaz pair programming :-), itp...),
• no i my raczej utrzymanie i rozwój robimy - czasem wchodzi dużo nowych ficzerów - ale ogólnie jest technologicznie stabilnie (sąsiednie Teamy stosują kanban - co zdecydowanie bardziej pasuje do tego co robimy - u nas jakoś wygrali maniacy SCRUM (i nie moge tego ubić, a od jakiegoś czasu już mi się nie chce -skoro działa)).

Tak, że jak widać bajki się zdarzają - tym niemniej normalnie nie ryzykowałbym - nie każdy team wylosuje rozsądnego PO i managerów bez spinki.

neves napisał(a):

Scrum natomiast jest jedynie szczegółem implantacyjnym Agilu w odniesieniu do zarządzania procesem wytwarzania oprogramowania. I, tak, głównie, dotyczy mangmentu, ale proces wytwarzania oprogramowania to gra zespołowa, w której bierze udział znacznie więcej osób niż tylko programiści.

Jak Scrum ma się do Agile Manifesto, który mówi "interakcje pomiędzy ludźmi ponad procesy" (Individuals and interactions over processes and tools)?
Czy to nie znaczy przypadkiem, że Scrum to żaden agile, a jego zaprzeczenie?

somekind napisał(a):

Nie tworzy się całego systemu na raz, tylko dzieli na zadania, a tych w miesiąc już można trochę napisać. Przynajmniej tyle, by jakąś pierwszą wersję jakiegoś ekranu pokazać użytkownikowi.

Tak i w ten właśnie sposób powstaje beznadziejna architektura spaghetti.

wartek01 napisał(a):

Samo słowo Agile oznacza metodyki lekkie, tj. takie które kładą nacisk na iteracyjność procesu wytwórczego i minimalizację okładu na komunikację. Co samo w sobie jest całkiem OK.

To też ciekawe, szczególnie że jak zrobisz jakiegoś user story i widać, że czegoś zabrakło to kolejną szansę na pracę nad tym brakującym elementem możesz mieć za rok jak PO nada temu niski priorytet :) Gdzie tu więc iteracyjność procesu wytwórczego, jeżeli za rok tego taska podniesie ktoś zupełnie inny? :D

Ostatnio u Mariusza Gila ukazał się kolejny odcinek podcastu właśnie w tym temacie - pozostaje tylko odesłać: https://bettersoftwaredesign.pl/episodes/54

snakeomeister napisał(a):

Tak i w ten właśnie sposób powstaje beznadziejna architektura spaghetti.

Not even wrong.
Spaghetti wyklucza architekturę.
A to, jaki kod powstanie wynika z podejścia i umiejętności jego twórców, a nie z tego, czy tworzą cały produkt na raz, czy ficzer po ficzerze.

snakeomeister napisał(a):

Jak Scrum ma się do Agile Manifesto, który mówi "interakcje pomiędzy ludźmi ponad procesy" (Individuals and interactions over processes and tools)?
Czy to nie znaczy przypadkiem, że Scrum to żaden agile, a jego zaprzeczenie?

Oczywiście, że jest to zaprzeczenie, chociaż zwykle mało szkodliwe. Są gorsze choroby.

somekind napisał(a):

Tak i w ten właśnie sposób powstaje beznadziejna architektura spaghetti.

To akurat bzdura. Od strony technicznej dość dobrze znane są (w każdym razie w literaturze...) wzorce pozwalające uniknąć pułapek wynikających z ciągłej zmiany.

wartek01 napisał(a):

To też ciekawe, szczególnie że jak zrobisz jakiegoś user story i widać, że czegoś zabrakło to kolejną szansę na pracę nad tym brakującym elementem możesz mieć za rok jak PO nada temu niski priorytet :) Gdzie tu więc iteracyjność procesu wytwórczego, jeżeli za rok tego taska podniesie ktoś zupełnie inny? :D

Ale to nie jest wina podejścia zwinnego, że zatrudnili ci idiotę na POsa. Szczególnie, że jeżeli jest to coś potrzebnego, to powinno zostać zrobione w ramach DoD dla taska. Problem z agile jest taki, że zakłada zaangażowanie i dojrzałość wszystkich członków zespołu. A często jest tak, że połowa technicznych ma wywalone, druga połowa to miękkie faje, do tego nikt w zespole nie jest w stanie powiedzieć w ludzkich słowach dlaczego np. trzeba poprawić testy. Kończy się tym, że rolę lidera technicznego faktycznie pełni gość po jakiejś politologii.

piotrpo napisał(a):

To akurat bzdura. Od strony technicznej dość dobrze znane są (w każdym razie w literaturze...) wzorce pozwalające uniknąć pułapek wynikających z ciągłej zmiany.

Jakie to są wzorce, jeżeli można spytać?

Całe DDD, separacja warstw, wzorce projektowe dla programowania obiektowego. Do tego TTD + ciągły refaktoring.

piotrpo napisał(a):

Kończy się tym, że rolę lidera technicznego faktycznie pełni gość po jakiejś politologii.

Niech będzie nawet po wyższej szkole robienia hałasu - Tak długo jak ma wiedze i ma coś sensownego do powiedzenia.

Najgorszy jest TL, który nie ma wiedzy, nie ma nic sensownego do powiedzenia, ale za to żyję w odwrotnym przekonaniu + jest pato agile oszołomem. Miałem takiego (Dodatkowo zrobił certyfikat na Scrum Mastera :D) i nikomu nie życzę takiego "lidera". Mgr-Inż informatyki na PW.

@snakeomeister:

druga połowa to miękkie faje łatwo tak powiedzieć, chyba masz małe doświadczenie w korpoświecie. Już nie raz widziałem jak ktoś zaczynał rzeczywiście mówić szczerze i konstruktywnie, w ten sposób komuś podpadał i za chwile nie było go już na projekcie :

Projekty software'owe to:

• zrozumienie problemu klienta (zdefiniowanie wymagań)
• rozwiązanie problemu klienta (implementacja)
• sprawdzenie czy problem klienta został rozwiązany (testy)

Nic ponad te 3 punkty nie jest konieczne. Jeżeli jakieś dodatkowe zadanie wspiera którąś z tych części to powinno zostać. Jeżeli nie wspiera bezpośrednio, lub pośrednio tych zadań, to jest marnowaniem czasu i pieniędzy, powinno wylecieć.

Wszystkie te punkty, to zadania czysto techniczne. Oczywiście są jakieś tam role projektowe i taki PO będzie bardziej skoncentrowany na rozmowie z klientem, a programista bardziej na implementacji / testach, ale to nie znaczy, że PO nie ma mieć żadnej wiedzy o implementacji/testach, a programista ma nie wiedzieć po co pisze kod.

I teraz moje doświadczenie, skoro już je przywołałeś:

• januszsoft
• polskie korpo
• polskie wannabe korpo
• polskie postkomunistyczne korpo
• januszex, który się rozrósł i zaczął udawać korpo, ale janusze wciąż tam zostały
• francuski software-hauso-korpo
• startup (miły wyjątek)
• w uj wielkie korpo

Właściwie w każdej z tych firm, niezależnie od metodyki pracy (początki były w niby-waterfall, później nadszedł niby-agile), software development siedział w kącie i chlipał, bo był zaszczuty przez ludzi, którzy w życiu nie napisali porządnego user story, linijki kodu, nie uczestniczyli w testach oprogramowania. Jednocześnie nie wiedzieli po co to oprogramowanie piszą, co przekładało się na brak sensownych argumentów na poparcie rzeczy, które chcieli by zrobić.

Taka historia rozmowy z biznesem, której byłem świadkiem, chodziło po pozbycie się pewnego komponentu i argumentacja ze strony programistów "chcemy przepisać serwis X, bo on jest w starej technologii, a my chcemy używać nowej technologii". Robota niezbyt duża, ale te 100-200 tysięcy by kosztowała, więc biznes słysząc takie fanaberie kazał im spadać na drzewo. Pomysł wrócił z nieco szerszym kontekstem:
"Ten komponent jest oparty na zewnętrznych bibliotekach, których już nikt nie wspiera. Możemy zostawić jak jest, ale to oznacza, że w dowolnym momencie ktoś może znaleźć lukę w tych przestarzałych kawałkach i będziemy musieli zamknąć biznes na 3-6 miesięcy". Priorytet taska skoczył o +100 punktów.

A podsumowując, da się zmienić projekt, którego jesteś częścią, chociaż nie jest to łatwe. Nie da się tego zrobić siedząc w piwnicy i powtarzając sobie "mój kod taki piękny".

Odpowiedź na komentarze z postu wyżej w formie wertykalnej:

Dobra, narzekanie na scruma zmieszało się z narzekaniem na agile w ogólności i co moim zdaniem kompletnie bez sensu ze zwinnym podejściem do programowania.
Nie chce mi się pisać o Scrum, bo raczej wszyscy się zgadzamy, że podejście stosowane w większości firm nie ma sensu i nie ma co kopać leżącego. Cały ten cyrk to sekta, która werbuje nowych "ewangelistów" a jej wyłącznym celem jest sprzedaż certyfikatów, treningów, konsultacji i całego temu podobnego g...a. Jeżeli jakiś SM uważa, że jest inaczej, to jest frajerem, który odwala za darmo marketing dla góry tej scrum mafii.

Agile, to w moim rozumieniu podejście, w którym zespół wie co ma zrobić (jaki jest ogólny cel), sam sobie dobiera narzędzia, sposób organizacji pracy. Do tego potrzeba ogarniętych ludzi (albo takich, co się potrafią ogarnąć), natomiast zdecydowanie nie potrzeba SM. Jeżeli stanowisko SM jest zbędne przy kafelkowaniu kibli, to dlaczego niby ma być niezbędne przy pisaniu oprogramowania? W jaki sposób, ktoś bez rzeczywistego doświadczenia i z wiedzą ograniczającą się do 3 dniowego kursu dla opornych, ma powiedzieć kilku ludziom z rzeczywistym doświadczeniem, jak dobrze wykonywać pracę?
Podsumowując, to co ja rozumiem jako agile i z co całym sobą popieram, to paru gości, którzy wiedzą co mają zrobić, rozmawiają ze sobą jak inteligentni ludzie, koncentrują się na jak najszybszym dostarczeniu ważnych rzeczy i kompletnie olewają rzeczy nieważne. To co widzę w Agile Manifesto to praktycznie 1:1 to co widzę w Programming Motherfucker.
Praktycznie trzeba wiedzieć co jest do zrobienia, co z tej listy jest ważne, jak coś jest ważne, to robić to w pierwszej kolejności. Jak porządek tej listy się zmienia, albo wpadają tam nowe, ważniejsze rzeczy, to też ok. Jak przy kafelkowaniu kibla pęknie rura, to też priorytety się zmieniają, kafelki będą tak szybko jak to możliwe, ale najpierw trzeba się zająć pękniętą rurą.

Ponieważ klient nie ma pojęcia czego chce (taki prawdziwy klient, a nie tzw. "biznes"), to wymagania się zmieniają. Jak chce mieć sklep internetowy, to wyobrażenie tego jak ten sklep ma wyglądać, działać zmienia mu się każdego dnia i to dobrze, bo klient też widzi co dostaje, co ma konkurencja, uczy się rynku. Zespół też się uczy tego co klient, bo całe to customer collaboration oznacza, że zespół (a nie tzw. biznes), z tym klientem rozmawia i uczy się coraz więcej o problemie, który wspólnie z tym klientem chce rozwiązać. Uwaga poboczna, nie płacą nam za pisanie kodu. Płacą nam za to, że za pomocą tego kodu rozwiążemy problem klienta. Tym problemem może być np. to, że ma sklep z kibelkami, ale traci rynek, bo konkurencja ma sklep internetowy. Więc rozwiązujemy ten problem dostarczając lepszy (definicja później) sklep internetowy, niż ma konkurencja, żeby klient mógł ten utracony kawałek rynku odzyskać. Ta lepszość oznacza oczywiście wiele rzeczy, funkcjonalność, UX, integrację z systemem magazynowym (bo klient widzi kiedy będzie, a klient oszczędza na automatyzacji sprzedaży), niezawodność, możliwość szybkiego dostarczania nowych funkcjonalności (bo konkurencja nie śpi).

Wreszcie, nie da się być agile, jak dopuszczamy do powstania długu technologicznego, który uniemożliwia szybkie wdrożenie nowych ludzi do zespołu, zmiany funkcjonalne systemu, albo wymusza poświęcanie 90% czasu zespołu na trytytkowanie i silwertejpowanie systemu, bo co chwilę pada.

Większość tych modnych terminów typu CI/CD, TDD, SOLID, YAGNI, to zasady, które mają na celu umożliwienie tego co opisałem wyżej, czyli szybkiego dostarczania wartości, w sposób iteracyjny (dzisiaj funkcja koszyka, jutro kodów rabatowych) w zmiennych warunkach (bo jak wyżej - klient się uczy i mu się wymagania zmieniają).
Skoro wymagania się zmieniają, to zmienia się też system i ulega zmianie architektura systemu. Żeby nie utonąć we własnym syfie, architektura musi być podatna na zmiany. Żeby utrzymać tempo rozwoju musimy refaktoryzować "na bieżąco" kod, czyli po zaimplementowaniu jakiejś funkcji, która pasuje do poprzednich jak pięść do nosa, zmieniamy to co było, tak, żeby równocześnie z oddaniem mieć 0 długu technologicznego (teoria oczywiście).
@snakeomeister: Tak, jeden ogarnięty programista dostarczy więcej niż 10 nieogarniętych, ale nadal programowanie to zajęcie zespołowe, bo 3 ogarniętych powinno dostarczyć więcej niż 1. I ok, może jesteś geniuszem, który raz pomyśli, przez 2 tygodnie klepie w klawiaturę i wychodzi system bez błędów. Tylko twój geniusz nie będzie miał wartości, jak w trakcie tych 2 tygodni zmienią się wymagania.

Do oburzających się na moje słowa o pierdołowatości programistów przykład z życia. Zatrudnili nam SM, nie wiem po co, ale zatrudnili. Pech chciał, że trafił na raczej ogarniętą grupę, która wiedziała co i dlaczego robi. Pierwszego dnia zwołał zebranie w celu "uzgodnienia kontraktu". Dostał zjebki za marnowanie czasu i delikatną sugestię, żeby zajął się czymś pożytecznym. Nie zrozumiał i ostatnio jeden z zespołów w projekcie wyprosił go z daily. Na jakimś tam refinemencie (tak, uzgadniamy co jest do zrobienia i jaki jest tego sens) w odpowiedzi na motywacyjne gadki i "commitment zespołu" poleciała sugestia, że jak zajmie się sensowną robotą, to pewnie da się zrobić więcej. Cała różnica pomiędzy tymi zespołami, a typowym korpo projektem jest taka, że nie ma w nich żadnego programisty z łapanki, każdy z ludzi wie co pisze, dlaczego, jaki problem klienta rozwiązuje, dlaczego pilne rzeczy są pilne.

Scrum jest jaki jest, a mimo to warto zaznaczyć, że karawana jedzie dalej. Gdyby to było niepotrzebne/szkodzące interesom firmy to ktoś wymyśliłby coś mniej porażającego.

Obstawiam, że scrum dominuje, bo firmom nie chodzi o potencjał jednostki, czy zespół marzeń, czy nawet o samo IT, ale o proces, który jakkolwiek, ale ciągle jedzie i robi wyniki.

W ten sposób zarządzający nie musi się na wszystkim znać, może w dowolnym momencie zrobić sobie wolne bądź przełączyć się na temat, który najbardziej w danej chwili leży. Bez konieczności rozpraszania uwagi z powodu N projektów każdego dnia.

Pracując w scrumie warto robić 3 rzeczy:

1. nic nie zmieniać jeśli nas o to nie proszą, bo nieproszeni szkodzimy
2. zachować średnio-wolne tempo, bo większa produktywność to również większa presja i oczekiwania (niekoniecznie większy hajs)
3. pracuj tak, aby było wszystkim wygodnie

znowutosamo napisał(a):

Obstawiam, że scrum dominuje, bo firmom nie chodzi o potencjał jednostki, czy zespół marzeń, czy nawet o samo IT, ale o proces, który jakkolwiek, ale ciągle jedzie i robi wyniki.

Czyli podsumowałeś tym zdaniem po prostu http://programming-motherfucker.com - tabelka our values - they claim to value vs they really value.

@znowutosamo: Meh... Firmy stosują SCRUM, bo nie mają zielonego pojęcia o produkcji oprogramowania, z wyjątkiem naprawdę nielicznych. Zorientowali się, że podejście waterfall, które całkiem nieźle się sprawdza w przypadku np. budowy mostu, wcale się nie sprawdza w przypadku tworzenia oprogramowania. Jak przyszedł ktoś, z magiczną pigułką, powiedział "waterfall się nie sprawdza, ale nasz agile tak", łyknęli to jak foczka świeżego śledzia, bo zdanie jest przynajmniej w połowie prawdziwe. Tymczasem prawda jest taka, że nie wiemy jak robić oprogramowanie. Inżynieria lądowa i zarządzanie budową mostów ewoluowało przez tysiące lat, wciąż zdarzają się drobne problemy, bo ktoś coś źle policzył, ale większość projektów budowlanych kończy się sukcesem, a większość projektów SD klęską.
W inżynierii lądowej firmy mogą sobie zatrudniać przeciętnych pracowników (ale wymagania formalne i tak są większe niż w SD) i chciałby stosować takie podejście w SD, zatrudnić stażystów za lizaki, zamiast ogarniaczy za pieniądze. Albo chociaż zatrudnić roboli od kodu i "doświadczonego, technicznego scrum mastera", kazać im pracować wg. sprawdzonego procesu i wypuszczać kolejne projekty w przewidywalnej jakości, czasie, budżecie.
Tylko jako inżynieria oprogramowania jesteśmy w bardzo wczesnym stadium rozwoju i nie byliśmy do tej pory zdefiniować tego skutecznego procesu, więc podobnie jak budowniczowie (masoneria hehe..) średniowiecznych katedr, musimy się opierać na doświadczonych i sprytnych ludziach, oraz ich indywidualnych predyspozycjach. Jeżeli jakaś firma tego nie rozumie, to nie ma tych doświadczonych i sprytnych ludzi (bo spryt poprowadził ich do innych firm, zamiast tracić czas na kopanie się z koniem). Jak ich nie ma, albo ich pomija, to nie ma szans na dostarczenie tej wartości o której firmie chodzi.

Mam inne pytanie do ekspertów agile.

1. Kiedy powinniśmy robić refinement?
2. Czego powinien dotyczyć refinement?
   2.1. Czy powinien on dotyczyć user stories zaplanowanych na aktualny sprint?
   2.1.1. Jeżeli user stories zaplanowanych na aktualny sprint, to jak w ogóle mogliśmy je na aktualny sprint zaplanować wcześniej bez refinementu?
   2.2. Czy może powinien on dotyczyć user stories zaplanowanych na kolejne sprinty?
   2.2.1. Jeżeli user stories zaplanowane na kolejne sprinty, to czy to nie jest anty-agile, że w aktualnym sprincie pracujemy nad rzeczami na kolejny sprint?

NIe mam żadnego certyfikatu SM, jedynie jakiś tam drobny kursik, ale się wypowiem:

1. Kiedy wam wygodniej. Im wcześniej tym lepiej. Zdecydowanie nie powinno to być robione w trakcie planowania, dzień przed planowaniem. Musi być przegadane wcześniej, żeby nie znaleźć się w sytuacji, że nie wiadomo o co chodzi, ale trzeba zaplanować.
2. User stories, które nie są "zaplanowane", ale istnieje prawdopodobieństwo, że wejdą na warsztat w ciągu kilku najbliższych tygodni.

Anty-agile to jest robienie głupich rzeczy, bo w jakimś pdf'ie tak napisali.

Odpowiem tutaj, bo w kometarzach się to bardzo rozrasta
@snakeomeister:

dla biznesu informacja co będzie zrobione w konkretnym jednym sprincie ma wartość bliską zeru jeżeli biznesu to nic nie obchodzi to po co są w ogóle sprinty? Sprints are the heartbeat of Scrum, where ideas are turned into value. (Scrum Guide) The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.(Scrum Guide) Co to znaczy why the Sprint is valuable to stakeholders? Czyli próbujecie powiedzieć, że nie jest valuable?

Sprinty w Scrum mają teoretycznie nadać powtarzalność "procesu". Wprowadzić rutynę w trakcie której wykonujemy parę czynności, które dają pozytywny rezultat. Za te sprinty ktoś płaci, albo jest to tzw. biznes, albo rzeczywisty klient. Cel sprintu ma zakomunikować tym bytom, że na jego koniec dostaną coś wartościowego, czyli zgodnego z ich potrzebami. Tylko to jest teoria, bo w praktyce, głównym powodem istnienia sprintu jest manipulacja zespołem i kontrola. Dlatego Scrum mówi o tych głupotach w stylu "sprint commitment", bo wychodzi z założenia, że jak się zespołu nie pilnuje, to będą grać w piłkarzyki i się opierdalać. Czyli w guidzie masz na początku wspomniane "values" (, a później całą resztę, która jest zaprzeczeniem tych pryncypiów.

O ile nawet zgadzam się, że pewien rytm w projekcie powinien być, to nie widzę sensu utrzymywania sprintów, w którym mamy cały ten scrum cyrk z planingami (po co planować, skoro wiadomo co trzeba zrobić i co jest pilne?), estymowaniem (po co to robić, skoro nikt tej wiedzy nie potrzebuje dla 2 tygodniowego okresu, a estymowanie samo w sobie jest kosztowne), pieprzeniem o "commitmencie" (bo jak przyciśniesz ludzi to owszem, dowiozą, ale coś co nie będzie działać, albo oleją poważny błąd w aplikacji, bo najpierw trzeba dowieźć plan) i nie przepalasz bez sensu czasu na bezsensowne spotkania z których nie można zrezygnować, bo przecież tak mówi scrum guid, do tego jak zrezygnujesz i zrobisz w tym czasie jakąś sensowną pracę, to "zaburzysz velocity".

Natomiast w praktyce Scrum jest szkodliwy, bo jest nie tylko marnowaniem czasu, ale dodatkowo:

• Izoluje developerów od klienta jego problemu.
• Obniża wydajność zespołu
• Wydłuża czas reakcji na zmiany środowiska zewnętrznego
• Sprawia, że zespół uważa, że jego zadaniem jest dostarczenie sprint objective, story pointów, burndown chartów i całej reszty bzdurnych artefaktów z których jest rozliczany, zamiast dostarczenia działającego i odpowiadającego potrzebom klienta oprogramowania, bo z tego akurat nikt ich nie rozlicza.
• Działa demotywująco na ludzi, bo ciężko o motywację, kiedy nie wiesz co, po co, dla kogo i w jakim celu robisz. Do tego jesteś traktowany jak idiota, który potrzebuje dokładnej, ale złej instrukcji jak zrobić coś, co doskonale wiesz jak zrobić. Instrukcję dla odmiany napisał ktoś, kto o twojej robocie nie ma pojęcia, ale naćpał się Scruma na kilkudniowym szkoleniu.
• udaje, że jest odpowiedzią na wszystkie pytania, ale na pytania ważne, takie jak "kiedy będzie ukończony system i ile to będzie kosztowało" nawet nie próbuje udzielić odpowiedzi.

I żeby nie pominąć zalet, napiszę jedynie, ze zaletą Scrum jest to, że jednak są nie zerowe szanse na zrobienie czegoś. W takim SAFe, stosowanym by the book, na pracę już nie ma kompletnie miejsca.

Mi brakuje czegos innego w rozwazanich o Scrumie/Sprintach: byl ahistoryjka jak to zespol sie zorganizowal, pocisnal i cos dowiozl i tak powstal Scrum.

ALE takie cos moze zadzialac jesli sie to robi sporadycznie. Majac odpowiednia marchewke i dobry zespol mozna w ciagu tych dwoch tygodni dostarczyc o wiele wiecej niz zazwyczaj ALE to jest mozliwe na krotka mete. Wiem ile potrafilismy zrobic ze znajomymi na Compo gdzie w 8h bylismy w stanie zrobic grywalny prototyp gry. Tylko po cyzms takim trzeba odpoczac. Tak samo ze sprintem. Oczekuje sie ze ludzie bede dawac z siebie caly czas 100% -> stad te wszystkie burdown charty. Dajemy z siebie wszystko w dwoch pierwszych iteracjach, ustawiamy wysokie velocity i krecimy na siebie bicz I stad pozniej wszelkie quiet quittingi.. Sami pomyslcie czy majac perspektywe, ze musicie w aktualnym sprincie dowiezc 3-4x tyle co zwykle, ale dostaniecie za to okragla sumke, albo dwa tygodnie na regenracje, dalibyscie rade ?

@WhiteLightning: Dlatego ta "motywacyjna" część scrum'a jest o kant d.. potłuc. Jeżeli nie masz zmotywowanego zespołu, to nie dostarczysz niczego sensownego. Jeżeli masz zmotywowany zespól, to masz szansę, ale przecież motywacja nie spowoduje, że ludzie zaczną 4 razy szybciej myśleć, więc wydajności trzeba szukać w innych miejscach. I teraz jakie są możliwości:

• Skupienie się na robocie. Można sobie odpuścić partyjkę fify, ale na dłuższą metę jakieś chwile relaksu są potrzebne.
• Możesz usunąć z projektu systemowe marnowanie czasu, np. jakieś retrospektywy o dupie Maryni, które w przeciwieństwie do szybkiej partyjki na PS nie mają żadnej wartości
• Możesz identyfikować i rozwiązywać problemy, które się pojawiają i utrudniają pracę. Np. trzeba jakiegoś narzędzia, albo wprowadzić pair programming, zrobić wewnętrzne szkolenie dla juniora, zainwestować w spłatę długu technologicznego, zbudować pipelinę....
• Możesz pracować dłużej, ale o ile nie jest to wynik realnej potrzeby (coś rzeczywiście jest pilne) i o ile nie masz odpowiedniej marchewki, to nie zadziała
• Możesz pominąć testy
• Można zamiast aplikacji zrobić prezentację...

Czyli systematyzując można:

• pracować mądrzej
• pracować dłużej (i czuć się jak frajer)
• udawać, że się pracuje
  Punkt pierwszy ma sens, reszta nie ma sensu. Problem w tym, ze pierwszy punkt coś kosztuje - czas pracy zespołu, ego scrum mastera itd. Więc wiadomo jak jest...

Czasem myślę, że scrum jest po to, aby rozluźnić napięcie. Wiecie wspólny wróg, wspólny ból - a to łączy, co z resztą i tutaj widać.

znowutosamo napisał(a):

Czasem myślę, że scrum jest po to, aby rozluźnić napięcie. Wiecie wspólny wróg, wspólny ból - a to łączy, co z resztą i tutaj widać.

Nie ma żadnego wroga, żadnego wspólnego bólu. Jedyne co jest to ebanie sprintów aż się projekt skończy, potem kto zostanie ten zostanie, kto nie ten se poszuka nowej pracy. Dopóki nie zobaczę przypadku gdzie skram monter wypierala managera projektu dyscyplinarnie na zbity ryj to nie uwierzę, że skram to coś innego niż metoda zaganiania devów do pracy w akordzie.

Fistandantilus napisał(a):

Dopóki nie zobaczę przypadku gdzie skram monter wypier*ala managera projektu dyscyplinarnie na zbity ryj to nie uwierzę, że skram to coś innego niż metoda zaganiania devów do pracy w akordzie.

Tyle, że w scrumie nie ma managerów projektów, więc nie bardzo jest jak ich zwolnić.
SM też nikogo nie zatrudnia, żeby miał kogokolwiek zwalniać.

W Scrum nawet nie ma się do czego odnieść, bo Scrum Guide to bzdety i to rozmyte, każdy sobie w tym widzi co chce.
Jedyne poprawne zastosowania Scrum jakie widziałem to te gdzie SM=PM albo jakaś część PM czyli stanowisko kierownicze. Wszelkie wdrożenia gdzie skramikami są różowe paski bez rozumu, ale z cyckami pomijam bo to jakby wizytówka firmy że tam się odstawia teatrzyk a nie pracuje na poważnie.

Fistandantilus napisał(a):

W Scrum nawet nie ma się do czego odnieść, bo Scrum Guide to bzdety i to rozmyte, każdy sobie w tym widzi co chce.
Jedyne poprawne zastosowania Scrum jakie widziałem to te gdzie SM=PM albo jakaś część PM czyli stanowisko kierownicze

A czy w tych Świętych Księgach Scama nie ma że SM ma byc dowolna osoba w zespole tylko nie kierownik? Więc jeśli SM = PM = PO to jest to coś innego a nie Scam, i może dlatego właśnie działa :P

BTW też pracowałem w zespole w UPC gdzie SM = PM = PO i wszystko działało, ale ze Scama miało to tylko nazwę, i nikt nie narzekał. Poza głównym testerem, ale on zawsze narzekał :D (mimo to dobrze wspominam z nim współpracę)