Scrum nie działa

0

Zrobiliśmy sobie spotkania sync z innyi zespołami i tam chodziliśmy (jak ktoś miał potrzebę!).

Ooo, dobry pomysł. W sumie jakby się zastanowić, to sama idea spotkań w zakresie jednego zespołu nie ma wiele sensu (bo zespół i tak się widzi i może komunikować codziennie), natomiast z ludźmi, którzy są poza zespołem (ale którzy jakoś współpracują, np. grafik) często kontakt jest ograniczony albo łatwo po prostu traci się tę synchronizację. Więc jeśli robić spotkania to niech faktycznie będą na tych spotkaniach ludzie, z którymi nie ma na codzień tak silnego kontaktu, jak z kolegą z biurka obok.

0
GutekSan napisał(a):

Jarku, ale wiesz co ma najniższą jakość?
Coś czego w ogóle nie ma.
Kluczem jest tu słowo wystarczająco, które oznacza, że coś spełnia ustalone standardy jakości. A te standardy też zostały określone w procesie planowania przy tworzeniu Definition of Done dla danego User Story. I tak rozumiem określenie wystarczający, a nie jako posiadający pozory bycia skończonym. Tymczasem przedłużanie pracy w celu maksymalizowania jakości prowadzi do tego, że albo dostajemy doskonały produkt, którego nikt już nie potrzebuje, albo w ogóle nie dostajemy nic, bo niczego nie udało się skończyć.

Programiści czasem zapominają, że nie są artystami, i nie tworzą dzieła sztuki, tylko produkt biznesowy.

Akurat artysta ma prościej, bo jego praca polega na tworzeniu setek małych greenfieldów, z których większość jest g*wniana, ale to nie szkodzi, bo g*wniane zostaną zapomniane, a porządne zostaną dobrze sprzedane. Programista pracuje nad jednym dużym projektem, więc musi się mocniej zastanowić zanim wyprodukuje kupę. Inaczej będzie ciągła rzeźba w brązie i biadolenie na forum.

Nie spotkałem się jeszcze z definition of done, które zahaczałoby o standardy jakości kodu czy ogólnie o dług techniczny. U nas teraz DoD = jest na prodzie, klient może używać funkcjonalności. Na szczęście odpadło nam szacowanie historyjek i mierzenie velocity. Widocznie komuś już przestał stawać na widok słupków. Zamiast tego to programiści decydują ile czasu trzeba poświęcić na zrobienie funcjonalności porządnie, a analityk biznesowy nakreśla jakie funkcjonalności są potrzebne. Do tego oczywiście trzeba najpierw udowodnić, że jest się profesjonalistami, czyli że czas poświęcony na dopracowanie funkcjonalności skutkuje zmniejszoną ilością problemów na produkcji.

Ja bym powiedział, że w wielu przypadkach coś co źle działa oznacza gorszą jakość całego systemu niż brak danej funkcjonalności. Nie tylko w danym momencie (bo klienci są beta-testerami którzy marnują swój czas na kopanie się z niedoróbkami) ale też w przyszłości, bo programiści zostali z długiem technicznym który zmniejsza ich efektywność. Nie ma prostej metody by powiedzieć kiedy należy skończyć pracować nad zadaniem. Od tego jest doświadczenie programisty (senior developer itd), by ten sam był w stanie osiągnąć pożądany kompromis między jakością kodu, a szybkością dowożenia funkcjonalności.

0

Definition of Done to patologia, bo działa odwrotnie niż się wydaje, że działa.

Teoretycznie wydaje się, że DoD dookreśla to, czy coś jest zrobione czy nie. No bo "definicja". Patrzcie jacy jesteśmy zorganizowani, nie ma niejasności, wszystko jest określone.

Tylko, że w praktyce to czasem działa sposób, że DoD swoją drogą, tylko, że biznes i tak się nie stosuje do tego. Pracowałem w zespole, gdzie np. PO potrafił cofnąć taska z kolumny Done do In Progress, bo tak (pomimo, że task spełniał DoD). Bo DoD swoją drogą, ale i tak biznes ma ostateczne zdanie.

I potem, żeby tego zapobiegać zespół myśli nad bardziej sprawną Definition of Done, żeby było naprawdę dookreślone wszystko...

W rezultacie Definition of Done jest ruchomym celem. I staje się z biegiem czasu coraz bardziej restrykcyjnie, aż do przesady. Gdzie rosną kolejne patologie typu "wymóg code review" jako jeden z warunków DoD (i przez to potem kilka gotowych tasków leży i nie może być zmerdżowanych bo czekają kilka tygodni na code review. A przecież DoD to "świętość", czyli "task, mimo, że został wykonany, to nie jest wcale uznany za zrobiony, bo tak mówi jakaś głupia regułka DoD").

Z Definition of Done jest jeszcze inny problem. A mianowicie pytanie o to, czy w ogóle większe projekty software'owe w dzisiejszych czasach mogą być kiedykolwiek "done"?

Duży software to ciągły rozwój i pomijając rzeczy binarne (np. fixowanie buga - jest bug=>nie ma buga) to ciężko stwierdzić, że jakakolwiek duża aplikacja została "zrobiona", albo czy jakikolwiek ficzer w aplikacji został "zrobiony", tak definitywnie do końca.

2

Dla odmiany, w projekcie gdzie nie ma DoD ostatnio oddawany kod w praktyce nie musi się nawet kompilować. Niestety autentyk.

0

Są różne patologie XD

2

DOD powinno być proste.

Widziałem już DOD , gdzie bylo narypane reguł, że pokrycie testami, że sprawdzone przez użytkownika. Potem sie okazuje, że mamy taska - zmień reguły firewalla, dopisz skrypt migrujący dane - jak tu pokryć testami (czasem się da... ale często nie warto), jak tu dostać akcept od użytkownika? Potem mamy 4 różne DOD (naprawdę), w zależności od rodzaju taska. Albo taski, które ze względów technicznych nie mogą spełnić DOD, bo np. nie można ich uruchomić na preprodukcji.., choć są zrobione.

Wszelkie koncepcje, typu musi być uruchomiony na serwerze testowym, gdzie deploymenty są tylko w piątek to zabójcy efektywnej pracy. Jak reguły DOD są takie, że zespół nie może przysiąść i zrobić i zamknąć w dowolnie wygodnym dla siebie momencie - to potem mamy 20 otwartych tasków, przy których nikt nie pracuje...

W praktyce reguła typu - musi być review zrobione i zadanie zaakceptowane przez kogoś z zespołu to już całkiem dużo - w wielu projektach wystarcza.
Dorzucanie coraz większej ilości kruczków, punktów itp. to jest zwykle ładny objaw choroby i próba zaklinania rzeczywistości.Dopisywanie reguł nie pomoże, jak zespół juz zaczął olewać to co tworzy... bo jest przytłoczony.

3

Tylko, że przynajmniej w teorii, to zespół scrum'owy określa co wg. niego oznacza "done". Problem w tym, że na początku często znajdzie się ktoś, co to naczyta się jakiś tam pierdół, był na 3 konferencjach o metodykach zwinnych a jego ambicje jeszcze się nie roztrzaskały o fiaska 5 projektów i wpada na jakieś dziwaczne pomysły typu wymogi, że kod składający się z rzeczy nietestowalnych jednostkowo ma być pokryty jak Sasha Grey u schyłku kariery. Albo jakiś manager chce być "lepszy" niż kolega z pokoju obok i wymyśla dziwactwa. Tylko to wszystko jest raczej wynikiem niekompetencji niż tego, że stosuje się taką czy inną metodykę pracy. Scrum, kanban i co tam jeszcze jest jak by nie patrzeć nie każe mieć bzdurnej DoD.

3

A czy osoba, która nie potrafi sensownie zorganizować zespołowi pracy w scrumie, albo zespół, który wymyśla sam sobie absurdalne regułki, będą w stanie efektywnie organizować sobie pracę i realizować projekt w jakiejś innej metodyce?

Jak ktoś ma fiziu miziu na punkcie tego, że do wszystkiego muszą być akurat 4, 8, 16 lub 32 unit testy, bo go rajcują potęgi dwójki, i potem wszyscy się z tym męczą, to chyba nie jest wina scruma?

Jak teamowi brakuje samodyscypliny i nie pisze testów, a potem trzeba wymyślać jakieś zasady dodatkowe, żeby jednak testy były napisane, to problem nie leży w scrumie.

Jak ktoś stwierdził, że buildy tylko w piątek, bo tak i koniec i potem wszyscy czekają jak na zbawienie to nie jest problem scruma.

Jak ktoś robi tygodniowy sprint, który zaczyna się w czwartek i potem w poniedziałek wszyscy gapią się w monitory i zastanawiają, na czym skończyli robiąc taski w piątek, to nie jest wina scruma.

Jak ktoś rozrzuca story pointy po taskach z precyzją rozrzutnika do gnoju, to też nie ma co winić scruma. U nas story pointy rozkładane są tak, że bierzemy taska, dyskutujemy nad nim, ile może zająć, czego wymaga, co jest wiadome, a co nie i jak się ma do tego, co już wyestymowaliśmy, a potem głosujemy czy task jest XS, S, M, L czy XL. Liczba punktów jest mniej istotna. Jak głosy są podzielone, to prawie zawsze na dwie sąsiednie kategorie, więc po prostu wybieramy ostatecznie jedną. Póki co to się sprawdza.

Jak ktoś nie dopuszcza do siebie myśli, że można wrzucić do backlogu refaktoring i jeszcze go przepchnąć powyżej ficzerów, a na domiar złego dorzucić do kolejnego sprintu, to chyba nie jest wina scruma tylko ludzi. Trzeba też umieć powiedzieć:

Słuchajcie, możemy rzeźbić od razu kolejny XYZ*, a potem kolejny i mieć to w dupie. Ale teraz wyrzeźbienie XYZ zajmuje 2-3 o-dni** co najmniej, a jak poświęcimy 2-3 o-tygodnie na taki a taki refaktor, to będziemy mogli dostarczać nowy XYZ w góra 1 o-dzień, plus dostajemy za darmo to, to i to i już nie trzeba będzie do tego wracać w nowych XYZach ani utrzymywać w wielu miejscach w starych.

Jak ktoś ma olej w głowie, to nawet jeśli się z tym nie zgodzi, to przemyśli sprawę i będzie miał jakieś w miarę sensowne uzasadnienie. A jak nie, to ponownie nie jest to winą scruma.

* - moduł, ficzer, cokolwiek
** o-X -> osobo-X -> X pracy jednej osoby

0

Jak ktoś rozrzuca story pointy po taskach z precyzją rozrzutnika do gnoju, to też nie ma co winić scruma. U nas story pointy rozkładane są tak, że bierzemy taska, dyskutujemy nad nim, ile może zająć, czego wymaga, co jest wiadome, a co nie i jak się ma do tego, co już wyestymowaliśmy, a potem głosujemy czy task jest XS, S, M, L czy XL. Liczba punktów jest mniej istotna. Jak głosy są podzielone, to prawie zawsze na dwie sąsiednie kategorie, więc po prostu wybieramy ostatecznie jedną. Póki co to się sprawdza.

Ależ story pointy, velocity i tym podobne pierdoły są narzucane przez Scruma. U nas oszacowania nie stawały się coraz lepsze, a zabawy w usprawiedliwianie własnego oszacowania są czasochłonne. Z tego powodu olaliśmy szacowanie prawie całkowicie (w sensie jest tylko zgrubne szacowanie ile komu wrzucić tasków na sprinta podczas planningu, ale wtedy każdy szacuje własną pracę, a nie cudzą). Lepszym rozwiązaniem jest po prostu dzielenie zadań na mniejsze.

0
Wibowit napisał(a):

Ależ story pointy, velocity i tym podobne pierdoły są narzucane przez Scruma.

Ale przywiązujesz do nich wagę na tyle, na ile potrzebujesz, czyż nie? Jak ktoś chce próbować na siłę patrzeć na świat przez pryzmat punkcików w JIRA i nie widzieć nic poza tym, wolna wola.

U nas oszacowania nie stawały się coraz lepsze, a zabawy w usprawiedliwianie własnego oszacowania są czasochłonne.

Stąd proces odwrotny, najpierw dyskutujemy o zadaniu, a dopiero potem je szacujemy i nie ma potrzeby spowiadania się - jak ktoś chciał dorzucić swoje trzy grosze, dorzucił w trakcie dyskusji. Nie ma tak, że jeden oszacuje zadanie na duże i tłumaczy swoje widzimisię, drugi oszacuje na małe i tłumaczy swoje, a potem próbują znaleźć porozumienie.

Lepszym rozwiązaniem jest po prostu dzielenie zadań na mniejsze.

A to się wyklucza z szacowaniem zadań?

0

Scrumowy planning poker czy inne metody szacowania polegają na tym, że każdy programista szacuje każde zadanie, a nie tylko własne.

Generalnie szacowanie zostało u nas zredukowane do pytania: czy uda ci się zrobić jeszcze to jedno zadanie w sprincie? Zadania dodajemy programiście, aż odpowie na pytanie przecząco. W ten sposób planowanie się nie przeciąga godzinami, cały sprint jest zaplanowany, a planowanie odbywa się standardowo raz na sprint.

1
Wibowit napisał(a):

Ależ story pointy, velocity i tym podobne pierdoły są narzucane przez Scruma.

Nie do końca - Scrum jako taki nic nie mówi o story, czy pointach. Wszystko co musisz, to wziąć na siebie tyle pracy, żeby ją wykonać w planowanym czasie i żeby wszyscy mieli co robić. Ktoś gdzieś wpadł na pomysł planning pokera (może nawet sensowny w tym konkretnym zespole / projekcie), ktoś inny uznał, że jemu się też przyda a reszta świata naśladuje to bez większego sensu, często kompletnie wypaczając pierwotne pomysły do postaci jakichś lokalnych frankensztajnów - np. u nas MUSIMY estymować wszystko w SP, które są przeliczane 1:1 (takie ustalenia na poziomie korpo) na dni pracy (1SP = 1MD) a później liczymy sobie velocity w MD / MD co według naszych agile gurus jest absolutely halal. Proces planowania w praktyce wygląda tak, że bawimy się w pokera, ale głównym zajęciem w tym czasie jest rozkmina o co właściwie biega w tych user stories, później patrzymy co można faktycznie zrobić przez 2 tygodnie w rozpisaniu na ludzi a na koniec przeklepujemy część estymat na takie, o dadzą właściwą sumę końcową.
Czyli w skrócie, ponownie: jak masz ogarnięty zespół, któremu nikt nie wcisnął jakiegoś dogmatycznego kapłana od scruma to sobie siądzie na chwilę oszacuje kto co może zrobić i pójdzie pracować. Jak masz zespół koncentrujący się na scrumie (w ich własnym rozumieniu) a nie na pracy to zaczynają się patologie a na wyjściu masz słupki a nie produkt, ale przynajmniej dano d**y zgodnie z procedurą.

3

Pracuję w niewielkiej firmie tworzącej dość skomplikowany i wymagający produkt (technicznie/technologicznie).

Są u nas dwa działy od oprogramowania:

  1. oprogramowanie systemowe, embedded
  2. soft webowy, przetwarzanie danych pod klienta itp.

Dział nr 1 działa w metodologii Programming Motherf*cker, w procesie planowania i tworzenia architektury liczy się praktycznie tylko merit, kto ma lepszy pomysł, czyj działa lepiej. Słabsze jednostki albo same odpadają i się zwalniają albo jeśli są do czegoś przydatne to w sposób naturalny przejmują taski, które są w stanie ogarnąć.
Zespół w zasadzie olewa wszystkich nietechnicznych managerów z ich durnymi pomysłami, wszystko za zgodą zarządu firmy gdyż z efektem pracy zespołu nie da się dyskutować.

Jeśli chodzi o dział nr 2 to jest to typowy, młody, dynamiczny zespół pełen pasji i barwnej różnorodności ;-). Przez ponad rok, zespołem większym niż nr 1, nie potrafili zrobić nic co sprawiałoby choćby cień wrażenia działającego. Nie jestem pewien jakich konkretnie metodologii używali ponieważ jest to zbiór ludzi z różnych korp i metodologie w podzespołach były inne jednak wszystkie były edżajl (co podkreślano przy okazji spotkań ogólnofirmowych). W końcu, jako że efektów brak to szef działu (swoją drogą kapłon referencyjny) stwierdził, że dość tego lawirowania i wszyscy przechodzą na scruma! Od tamtej pory trwa nieprzerwane spotkanie, a to w salkach, a to na kanapach, a to jadą gdzieś na "biwak". Przychodzę kiedyś do pracy a tam wszystkie ściany oblepione kolorowymi karteczkami z takimi banialukami, że szkoda było w ogóle produkować ten papier. Oczywiście źJira, pokery, ruletki, retro-wagary i inne zabawy są nieodłącznym elementem pracy.
Efektów nadal brak choć zespół rośnie średnio jedną osobę na dwa miesiące. Zgaduję, że to dlatego, że nie zaimplementowali metodologii w sposób poprawny ;-).

4
Złoty Kot napisał(a):

Efektów nadal brak choć zespół rośnie średnio jedną osobę na dwa miesiące. Zgaduję, że to dlatego, że nie zaimplementowali metodologii w sposób poprawny ;-).

Raczej po prostu nie mają certyfikatów SM, PO.

7

To chyba tutaj pasuje ;)

title

0

oczywiście że nie działa, tak samo jak demokracja nie działa; ale tak samo jak dla demokracji nie mamy niczego lepszego tak dla edżajla tyż ni

1
marian pazdzioch napisał(a):

oczywiście że nie działa, tak samo jak demokracja nie działa; ale tak samo jak dla demokracji nie mamy niczego lepszego tak dla edżajla tyż ni

A skąd jesteście? Bo cały świat ma, tylko Wy nie macie, to to chyba musi być jakaś inna planeta...

2

bo scruma się źle rozumie... ja w jednym zespole standupy miałem na slucku a w innym w ogóle ich nie miałem (był mały zespół). Scrum master winien być raczej rodadcą a niżeli mówić jak powinno się pracować. Ja np teraz planowania robię w ciągu 10 min przy komputerze z kolegą.

You need to find good people who work together at a human level, in the human sense that they can collaborate effectively. The choice what tools they use or what process they should follow is a secondary issue - Martin Fowler

I sformułowanie, które mi osobiście się spodobało: czasami żeby być agile, to trzeba zrezygnować ze scruma. Każdy zespół ma różne potrzeby w i każdej firmie pracują różni ludzie. Ten "wzorcowy" scrum jest jedynie sugestią - można go zmieniać/usuwać/dodawać nowe rzeczy dowoli pod warunkiem, że osiąga się zamierzony cel - biznes jest zadowolony.

3

@no_solution_found: to chyba Ty nie rozumiesz jak działa świat. W scrumie nie chodzi o to, żeby programistom pracowało się lepiej, tylko o to, aby ileś firm szkoleniowych zarobiło masę kasy na szkoleniach i certyfikatach dla korporacji.

3

I sformułowanie, które mi osobiście się spodobało: czasami żeby być agile, to trzeba zrezygnować ze scruma.

Ogólnie Scrum słabo idzie w parze z podejściem zwinnym, przynajmniej takim jak w manifeście

z manifestu Agile:

Individuals and interactions over processes and tools
...
Responding to change over following a plan

a w Scrumie ważne są procesy i narzędzia, oraz podążanie za planem.

8

Może czas skończyć to pitolenie i zabrać się za kodowanie:
programming_mofo.png

Więcej na http://programming-motherfucker.com/

0

Dzięki za ten wątek nie wiedziałam że bycie programistą zawodowo to takie bagno jakieś scrumy, standupy, wywalanie ludzi za byle błąd, uff już nie będę mieć żalu że nikt mnie dotąd nie chciał, powinnam dziękować Bogu że nie wlazłam w to szambo :) Płaca to nie wszystko, zresztą umówmy się te płace i tak specjalnie wysokie nie są jak na wasze obowiązki... sorry taki fullstack robi za 2 osoby albo i więcej a ile średnio zarabia 6000 tys czy coś koło tego.

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