Czy Scrum zamienia aktywnych programistów w pasywnych programistów?

103

Jestem programistą pracującym w zespole złożonym z trzech programistów i jednego projektanta. Teraz około pięciu miesięcy wdrożyliśmy metodologię tworzenia zwinnego oprogramowania scrum. Ale mam dziwne przeczucie, że po prostu chciałem się tym podzielić.

Jednym z ważnych czynników w życiu człowieka jest proces decyzyjny. Istnieje jednak duża różnica w podejmowanych decyzjach. Niektóre decyzje są jedynie wynikiem siły wewnętrznej lub zewnętrznej, podczas gdy inne są całkowicie oparte na twojej wolnej woli, a niektóre są po prostu czymś pośrednim. Im więcej masz swobody w podejmowaniu decyzji, tym bardziej samodzielna staje się twoja praca. To wydaje się być regułą. Ponieważ sami dążymy do kształtowania naszego życia.

Istnieje wielka różnica między tym, że decydujesz, co robić , a tym, co ci powiedziano .

Przed scrum miałem większą swobodę w podejmowaniu decyzji związanych z rozwojem, analizą, priorytetem implementacji itp. Miałem więcej poczucia , że decyduję o tym, co robię .

Jednak ze względu na metodologię scrum wiele decyzji po prostu należy do właściciela produktu. Priorytetowo traktuje PBI , analizuje, jak powinno działać oprogramowanie, a czasem nawet sposób implementacji interfejsu użytkownika i funkcjonalności. Wiem, że jest to część metodologii scrum i wiem również, że może to skutkować lepszą sprzedażą produktu w przyszłości. Jednak teraz czuję , że zawsze każe mi się coś robić, zamiast decydować się na coś . Ten syndrom uczynił mnie bardziej pasywnym w stosunku do pracy.

  1. Zwykle szukam mniej, aby znaleźć lepsze rozwiązanie, podejście lub technikę
  2. Nie budzę się rano, oczekując przyjemnej pracy. Czuję się raczej zmuszony do pracy, aby żyć
  3. Po pracy mam głód do pracy nad własnymi projektami hobbystycznymi
  4. Nie będę już naciskać na zespół, aby osiągnął wyższy poziom technologiczny
  5. Spędzam teraz więcej czasu na obiedzie lub herbacie i mam mniej entuzjazmu, aby wrócić do pracy
  6. Jestem teraz gotów więcej, aby prace zakończyły się wcześniej, aby móc wrócić do domu

Dużym problemem jest to, że widzę i diagnozuję to zachowanie również u moich kolegów. Czy to wynik scrum? Czy scrum naprawdę sprawia, że ​​zespół programistów ma wrażenie, że nie bierze udziału w tworzeniu całego oprogramowania, co czyni go pasywnym w stosunku do projektu? Jak mogę przezwyciężyć to uczucie?

Saeed Neamati
źródło
4
Czy jesteś pewien, że wcześniej nie popełniłeś zbyt dużo dysfunkcji?
Donal Fellows,
27
Niezły post na blogu.
Robert S.
20
to, co
4
@Chad. To, co tu omówiłem, nie jest skargą na moją sytuację w pracy. Zastanawiam się tylko, czy ten nastrój jest wynikiem scrum? I czy inni programiści również doświadczają tego samego, czy nie?
Saeed Neamati,
5
@ Saeed - Przepraszam, że jestem tępy, ale twój nastrój jest wynikiem decyzji o postępowaniu ze środowiskiem pracy. Mogą mieć na to wpływ także inne opinie i postawy, ale możesz również wybrać tę metodę. Zwalnia cię z konieczności bycia odpowiedzialnym za decyzje projektowe i pozwala ci po prostu rozwiązać konkretne problemy. Nie pochłania całej energii i pozwala pracować nad większą liczbą projektów domowych. Masz więcej czasu na rozwój. To nie są złe rzeczy. Uszczęśliwienie cię nie jest zadaniem twojego pracodawcy. Możesz znaleźć inną pracę lub możesz to zaakceptować.
SoylentGray,

Odpowiedzi:

51

Jednak teraz czuję, że zawsze każe mi się coś robić, zamiast decydować się na coś.

Jest to poważny wskaźnik, że coś zjechało z torów. Zwinny projekt nie powinien się tak czuć. Ta retoryka „ludzie ponad procesem” powinna obejmować „nie zmuszamy naszych ludzi do robienia rzeczy, które są do bani”. Oto kilka pomysłów:

Czy robisz „scrum but”? Oznacza to, po części scrum, po części coś innego. (tzn .: „Robimy scrum, ale wszystkie nasze historie muszą pochodzić od naszego PMO, a nie właściciela produktu”). Wiele szalonych bzdur nazywa się Scrum.

Czy osobiście nie jesteś zaangażowany w proces, w którym powinieneś być? Wiem, że wiele osób jest zdenerwowanych treściami opowiadań i okazuje się, że angażują się tylko wtedy, gdy historia jest zaległa w sprincie. Porozmawiaj z właścicielem produktu na wczesnym etapie tworzenia historii i uzyskaj swoją opinię. (Jako PO mają oni ostatnie słowo, ale to nie znaczy, że muszą to zrobić sami).

W Scrumie zespół powinien być właścicielem procesu i oczekuje się, że proces ten z czasem ulegnie zmianie w zależności od potrzeb zespołu. Podnieś swoje obawy z perspektywy czasu. Jeśli możesz zaproponować drobiazgową modyfikację, która może sugerować, ułatwi to sprzedaż niektórym zespołom.

Sean McMillan
źródło
10
+1 Scrum (jak wszystkie metodyki zwinne) jest cięższy w rozmowie niż w kierunku. Organizacja producentów powinna opisywać, jaki efekt końcowy musi być w stanie osiągnąć, a następnie angażować projektantów i programistów w sposoby na osiągnięcie tego celu.
StevenV
5
„ludzie ponad proces”: Zabawne, dlaczego więc narzucać proces SCRUM zamiast pozwalać ludziom na korzystanie z własnych? I dlaczego wszystkie te środki (programowanie par, częste przeglądy postępów), które w imię przejrzystości pozwalają znacznie dokładniej monitorować pracę programistów?
Giorgio
3
@Giorgio: Ponieważ ustrukturyzowany rozwój umożliwia zespołom współpracę bez ciągłego stąpania po sobie. Po prostu jeszcze nie wymyśliliśmy, jak to zrobić idealnie.
Phoshi
2
@ Giogio, jest to ogólnie problem ze sprawnością. Chociaż celem jest sprawienie, by ludzie prześcigali się w procesie, w rzeczywistości Agile jest religijnie przestrzegana - co ponownie stawia proces nad ludźmi. Osobiście uważam, że lean lepiej sobie z tym radzi niż zwinny, choć nie próbuje narzucać ściśle horyzontalnej struktury zespołu - pozwala programistom lepiej wybierać zadania. Zakładając, że Twój zespół się nie zmieni, tablica Kanban oprócz tego, co robisz teraz, może uszczęśliwić kierownictwo i ciebie również, dając ci swobodę wyboru swoich historii / zadań.
jQwierdy
62

Twoim problemem nie jest Scrum (a jak wspominał Jarrod Roberson w komentarzach, nie jest to Scrum, który opisujesz) - to mikrozarządzanie Właściciela Produktu i brak (a) zespołu asertywności .

„Jednak ze względu na metodologię scrum wiele decyzji jest po prostu podejmowanych przez właściciela produktu. Priorytetem jest PBI, analizuje on, jak powinno działać oprogramowanie, a czasem także interfejs użytkownika i funkcje. Wiem, że jest to część metodologii scrum”.

Jesteś błędny. Już po krótkim spojrzeniu na stronę Wikipedii dla Scruma widać, że: „Zespół, grupa interdyscyplinarna, która dokonuje rzeczywistej analizy, projektu, wdrożenia, testowania itp.” Widzieć? Właściciel produktu powie ci, co robić, ale to Ty decydujesz, jak to zrobić.

Jesteś osobą odpowiedzialną za wdrożenie, więc powinieneś zdecydować, w jaki sposób aplikacja będzie wdrażana. Posłuchaj opinii właściciela produktu, ale ostateczna decyzja należy do ciebie (lub zespołu).

BTW mikrozarządzanie nie skręcić aktywnych deweloperów do programistów pasywnych.

Lukas Stejskal
źródło
38
Amen do ostatniej linii
Wivani,
6
„Właściciel produktu powie ci, co masz robić, ale to Ty decydujesz, jak to zrobić”. Właśnie to może stanowić problem dla motywacji deweloperów: brak innowacji. Przez większość czasu klient będzie chciał szybszych koni, a nie samochodów. Ale absolutnie zgadzam się z mikrozarządzaniem.
MAR
1
+1 @Lukas, ze względu na rozróżnienie między tym, co i jak . Dzięki stary.
Saeed Neamati,
5
„Właściciel produktu mówi, co robić” - nie do końca się z tym zgadzam. Powinni ci powiedzieć, czego potrzebują . Niewielka, ale ważna różnica. Innymi słowy: opisują problem / problem, podajesz rozwiązanie.
DanMan
2
@MaR Dlatego deweloperzy nie rozmawiają z klientami. Klienci rozmawiają z właścicielem produktu i proszą o szybsze konie, PO jest tym, który widzi wszystkie problemy klientów, łączy je i
nadaje
29

To, co opisujesz, to NIE SCRUM

Twój właściciel produktu przekracza swoje granice, jeśli mówi ci, jak wykonać swoją pracę technicznie, nie o to w ogóle chodzi w SCRUM.

SCRUM ma na celu uwolnienie programistów od skoncentrowania się na kwestiach programistycznych i umożliwienie im podjęcia decyzji o tym, ile czasu zajmuje i jak je wykonać.

SCRUM dotyczy współpracy, po to właśnie są spotkania planowania Sprint, aby promować współpracę między wszystkimi zainteresowanymi stronami; właściciel produktu, programiści i testowanie.

Tak, właściciel produktu powinien nadać priorytet funkcjom, które należy dostarczyć najpierw zgodnie z potrzebami klientów, ale programiści powinni zajmować się inżynierią i projektowaniem, a nie właścicielem produktu.

Nie zgadzam się z tym, że programiści powinni projektować GUI i przepływy pracy, chyba że zostaną specjalnie wyznaczeni i przeszkoleni do pracy z klientami i nie udostępnią funkcji bezpośrednio klientom. Programista zbudował GUI w próżni, rzadko zaspokajając potrzeby klientów.

SCRUM polega na umieszczeniu lekkiego procesu, który może być przewidywalny i powtarzalny w stosunku do zwinnego manifestu.

Smutno mi słyszeć historie, że bardzo dobre rzeczy są tak wypaczane.

user7519
źródło
3
Ludzka natura zawsze znajdzie sposób na wyrwanie klęski ze szczęki zwycięstwa.
Warren P
2
Jest takie, jakie powinno być SCRUM , i takie jest , przynajmniej w większości firm. SCRUM sam w sobie nie jest złem, ale jest narzędziem, które bardzo łatwo jest wykorzystać do zła przez kierownictwo.
AresAvatar,
11

Zgaduję, że przed Scrumem wszyscy zrobili tylko to, czego chcieli: yippee ki-yay mf'er . Twoi użytkownicy są twoimi dobroczyńcami, którzy kierują historią i płacą rachunki. Właściciel produktu upewnia się, że historia się zakończy. W pewien sposób, twoja grupa doszła do wniosku, że właściciel produktu powinien powiedzieć ci, jak programować.

Chcesz pisać kod lub tworzyć fajne małe aplikacje, które Twoim zdaniem są fajne? „Chcę najpierw uruchomić funkcję A, a nie B, aby zachować swobodę wyboru”. Znajdź innego dobroczyńcę, a nie nową metodologię rozwoju.

Zostałeś uwięziony w tytule właściciela projektu lub coś takiego. Jeśli masz uzasadniony powód, by nie zgodzić się z historią, powiedz coś, spieraj się. Nie zawsze możesz wygrać. Ich zadaniem jest powrót do użytkowników i poinformowanie ich, że istnieje ważny problem z ich żądaniem. Spójrzmy prawdzie w oczy, jeśli historia wymaga losowego upuszczenia bazy danych w ciągu dnia, bez kopii zapasowej, bez utraty danych lub przestojów, masz problem i obowiązek uporządkowania historii.

JeffO
źródło
10

Wygląda na to, że twoje przygody w Agile zostały zepsute przez Scruma. Uważam, że ze wszystkich zwinnych metodologii Scrum jest najmniej zwinny. To bardziej jak miniaturowe wodospady i dodatkowe zarządzanie projektami. To oczywiście sprawia, że ​​jest to najbardziej lubiane przez zarząd, który uważa, że ​​przejmują kontrolę od tych nieznośnych programistów, ale oczywiście widzisz rzeczywistość sytuacji.

Zwinność nie polega na podążaniu wyznaczoną ścieżką, ma na celu zwiększenie produktywności i motywacji. Ludzie, którzy nie przetwarzają, mówią manifest (sparafrazowany), który zagubił się w używanym systemie.

Więc zmień to. Przywołaj to do kierownictwa i powiedz, że jest to krok wstecz, że twoja produktywność jest mniejsza niż kiedyś i wszyscy jesteś niezadowolony z tego, jak to działa. Pokaż Manifest Agile (i jego złego bliźniaka ) i zademonstruj, że nie tylko nauczyłeś się lekcji z tego eksperymentu, ale chcesz przekształcić z niego dobre części w lepszy system (taki jak kiedyś, który wydaje się działać dobrze dla Was).

gbjbaanb
źródło
6
mnie? tak - kiedyś pracowaliśmy dobrze, a następnie zarząd zdecydował, że Agile jest przyszłością, i nałożył scrum, co ogromnie nas ograniczyło. To, co zwykliśmy robić, bez wysiłku pogrążyło się w procesie i biurokracji. Raz wziąłem 3 karty z tablicy Scrum !! Światła rozbłysły, a syreny zawodziły za naruszenie „drogi młyńskiej”, a raz zabrałem kartę z powrotem na biurko . Przyszli po mnie gliniarze z zarządzania projektami. I zwykłem siadać w codziennych młynach, które też nie szły dobrze. Wszystkie trywialności IMHO, ale zostały zrobione w góry.
gbjbaanb
2
Czy nie uważasz, że w twoim przypadku jest to zła, odgórna implementacja Scrum, która spowodowała spadek wydajności? Mówisz, że „ugrzęzłeś w procesie i biurokracji”, co jest dziwne, ponieważ Scrum jest najprostszą najmniej biurokratyczną metodologią na świecie ... Właściwie cała struktura Scruma mieści się w jednym arkuszu lub w 2. Btw, co nazywasz „tablicą scrum” nie jest częścią ram. W przypadku Saeeda uważam jednak, że problemem jest luka między typem organizacji, w której pracował (z dużą swobodą i mocą decyzji dla programistów), a typem organizacji, do której stosuje się Scrum.
guillaume31
3
@ ian31: tak, ten projekt był szczególnie zły, ale Scrum odwołuje się do tego rodzaju menedżerów. Nigdy nie widzisz, że wybierają Kanban lub Crystal. Scrum zbyt łatwo zmienia się w „scrum, ale”, kiedy ci faceci go opanują. szkoda.
gbjbaanb
1
Myślę, że to zabawne, że każda firma zamieni Scruma w ceremonię religijną. Hej! Stań podczas tej ceremonii, w której udajemy zwinność! Hej! Uśmiechaj się, podczas gdy my udajemy, że cię słuchamy, a następnie wesoło kontynuuj robienie tego, co chcieliśmy zrobić!
Warren P
2
Całkowicie nie zgadzam się z sednem tej odpowiedzi. Myślę, że jakiś „mini-wodospad” może być bardzo korzystny, szczególnie dla niedoświadczonych, ale sprytnych programistów, którzy mogą robić 5 różnych rzeczy naraz i nie kończyć żadnej z nich. W rzeczywistości osoba, która przeszkoliła mnie w Scrumie, powiedziała, że ​​nadal możesz robić „mini-wodospady” w Scrumie, jeśli chcesz, ale najlepiej, że powinno to trwać kilka dni, a nawet godzin . Myślałem, że godziny są za krótkie. Nie zawsze możesz zaprojektować-> wdrożyć-> przetestować historię w ciągu kilku godzin. Dzielenie historii tak, abyś mógł nie zawsze być optymalne.
Robin Green
8

Myślę, że po prostu jesteście przyzwyczajeni do posiadania większego prawa własności - i wszyscy, jak sądzę, wolą tę ludzką naturę.

Niestety, myślę, że dużo oprogramowania to mniej niż mogłoby być, ponieważ często części są pisane dla deweloperów, a nie dla klientów. Twoje nowe podejście powinno to zmniejszyć, ale kosztem poczucia własności.

Nie mam pojęcia, jak zasugerować, aby uczynić rzeczy lepszymi lub bardziej zabawnymi, ale to świetne pytanie i bardzo dobry wgląd.

Jonno
źródło
100% się zgadza. Jesteś teraz bardziej zjednoczony z właścicielem produktu, ale to oznacza, że ​​masz mniej swobody w robieniu tego, co uważasz za słuszne. Też tego doświadczyłem, a to wciągnęło i sprawiło, że moja praca stała się mniej przyjemna. Oznaczało to jednak, że byłem znacznie lepiej dostosowany do celów biznesowych i menedżera produktu. Firma płaci rachunki - w tym moją pensję - więc tak, mogą powiedzieć to, czego chcą na poziomie szczegółowym. Nie sądzę, że faktycznie mówią ci, jak kodować. Gdyby wiedzieli, jak sami mogliby to zrobić.
Michael Durrant
Firma nie płaci programistom za robienie tego, co chcą. Płacą programistom za zwiększenie wydajności zapewniane przez dobre środowisko oprogramowania. Jeśli pozwolisz, aby firma powiedziała ci, co robić „na poziomie szczegółowości”, czy naprawdę uważasz, że otrzymają dobre środowisko programowe, którego szukają?
Andomar,
@Andomar - To równowaga. Każda strona ma swoje ideały, założenia i wady. Zignorowanie któregokolwiek z nich prowadzi do niebezpieczeństwa.
Jonno,
5

Czy dostajesz historie użytkowników w postaci „Jako --role-- chcę - cel / pożądanie - tak, aby - czerpać korzyści”? Wygląda na to, że właściciel produktu chce wykonać prace projektowe i może nie być najlepszą osobą do tego. Użycie wzorca historii użytkownika może pomóc upewnić się, że właściciel produktu trzyma się interesu biznesowego, a twórcy oprogramowania zajmują się tworzeniem oprogramowania.

Michael Munsey
źródło
4
Jako programista nie chcę już nigdy więcej widzieć tego rodzaju historii użytkownika, więc nigdy nie będę musiał jęczeć wewnętrznie z powodu jej bezmyślności.
Warren P
@WarrenP Tak, płyta kotłowa może być uciążliwa, niezależnie od tego, czy występuje w postaci kodu płyty kotłowej, czy wymagań dotyczących płyty kotłowej. Myślę, że kluczową kwestią jest to, że wszystkie te 3 elementy powinny zostać stwierdzone lub zrozumiane, ale co ważniejsze, dla wszystkich powinno być jasne, czego naprawdę pragną, a wymagania oparte na szablonie mogą w rzeczywistości temu przeszkodzić. Zwłaszcza jeśli programiści zaczną myśleć, że wypełnienie kilku krótkich słów w tym szablonie jest zawsze wystarczające.
Robin Green
4

W Scrumie jest dużo miejsca dla programistów, którzy mogą wnieść swój wkład w udzielanie porad i wskazówek na temat nowych funkcji, interfejsu użytkownika, użyteczności ... W Scrumie wymagana jest współpraca i rozmowa między biznesmenami i programistami, co pozwala na to. Jednak ostatecznie właściciel produktu zawsze będzie miał ostateczny głos, ponieważ to on jest odpowiedzialny za maksymalizację wartości biznesowej przyrostów oprogramowania wytwarzanych sprint po sprincie (innymi słowy, ROI).

Z Manifestu Agile:

Naszym najwyższym priorytetem jest zadowolenie klienta poprzez wczesne i ciągłe dostarczanie cennego oprogramowania.

Właściciel produktu informujący o sposobie implementacji interfejsu użytkownika i funkcjonalności jest jednak nie do przyjęcia. W takim razie ty powinien mieć ostatnie słowo, ponieważ ty jesteś odpowiedzialny za wewnętrzną jakości oprogramowania, które tworzysz.

Być może pracujesz w firmie stworzonej przez programistów, w której programiści mieli swobodę wdrażania dowolnych funkcji. Jednak większość metodologii zwinnych wyraźnie rozdziela osoby z domeny biznesowej i zespół odpowiedzialny za tworzenie oprogramowania (programiści, testerzy ...), co jest najczęstszym działem pracy w większości miejsc. Jeśli moje założenia są słuszne, rozumiem twoje odczucie, że nie jesteś już w stanie „mieć wpływu na szerszy obraz”, ale wraz z rozwojem firmy wydaje mi się, że tak by było, Scrum czy nie.

Jeśli chodzi o analizy, projektowanie i inne wspomniane przez ciebie działania związane z meta-rozwojem (których właściciel nie powinien ponownie wykonywać), zespoły zwinne powinny być funkcjonalne i wolne od silosów. Nikt nie powinien posiadać całej wiedzy związanej z jednym konkretnym działaniem programistycznym, więc być może istnieje możliwość dywersyfikacji w porównaniu do „małpowania kodu”.

guillaume31
źródło
3

Przeciwnie, odkryłem, że posiadanie przez właściciela produktu decyzji dotyczących funkcjonalności pozwala mi poświęcić więcej czasu na tworzenie kodu jakości. Ponadto, jeśli istnieją uzasadnione obawy, zawsze mogę kwestionować decyzje właścicieli produktów, co zwykle prowadzi do owocnych dyskusji.

Misko
źródło
3

Tutaj ćwiczymy Scrum. Mamy dwa tygodnie planuje spotkanie, na którym karmimy w obecnych priorytetów biznesowych oraz sukcesów i porażek z poprzedniego sprincie i zdecydujemy, jako zespół , co chcemy rozwiązania dla następnego sprintu.

Jednym ze sposobów, w jaki to robimy, jest sortowanie zaległości na tablicy według złożoności w pionie, a priorytetów biznesowych w poziomie. Następnie właściciel produktu miał swój wkład, więc to do zespołu należy wybór tego, co chcemy zrobić. Oczywiście odrzucenie zadania o wysokim stopniu złożoności i niskim priorytecie jest niezadowolone, ale decydujemy o tym jako zespół. Wydłuża sesje planowania, ale warto i stanowi kluczową część procesu Agile.

Czasami mamy mikro-zarządzanie, ale to inny problem.

Tim
źródło
3

Prawdziwy problem, który opisujesz, to powszechna patologia, gdy zespoły przyjmują Metodologię: wyłączają mózgi. Jest to tak samo prawdziwe w przypadku nowego, zwinnego systemu zwinnego, jak w przypadku old-schoolowych systemów wagi ciężkiej.

P: Metodologia nakazuje x, ale x nie działa dobrze. Co powinniśmy zrobić?

Odp .: Udoskonal swoją implementację x. Może przestań to robić całkowicie. Metodologia nie jest twoim szefem!

W tym konkretnym przypadku wydaje się, że właściciel produktu może robić zbyt wiele. Czy możesz swobodnie z nim o tym rozmawiać? Czy czulibyście się swobodnie podczas tej rozmowy, gdybyście nie „robili scrum?” Jeśli właściciel produktu nie jest wrażliwy na konstruktywne opinie, nie jest to problem metodologiczny, to problem z właścicielem produktu.

Ian Olsen
źródło
2

Naprawdę nie jestem w zgodzie z całym tym scrumem, ponieważ od jakiegoś czasu jest więcej wodospadów.

Ale szczerze mówiąc, brzmi to bardziej jak kwestia personelu zarządzającego niż kwestia techniki zarządzania projektami. Tak jak w przypadku większej liczby osób opartych na technice.

kuszenie
źródło
Nie @temptar, nasz związek jest naprawdę dobry. Bez obrazy, bez nienawiści, w ogóle nic. Wszystko jest w porządku, wszystko oprócz tego, jak czujemy się do pracy.
Saeed Neamati,
2

Rola liderów w samoorganizującym się zespole byłaby postem na blogu o czymś, czego brakuje w twoim poście. Gdzie zespół decyduje, jaka praca zostanie wykonana w sprincie? Gdzie zespół ma prawo własności do procesu i pracy? Czy masz kogoś, kto zna Scruma na tyle, że go używasz, a nie jakąś jego wypaczoną wersję?

JB King
źródło
2

Miałem takie same doświadczenia ze Scrumem i lubię to nazywać „tyranią historii”.

Z mojego doświadczenia wynika, że ​​programiści bardziej po stronie kreatywnej / projektowej / frontendowej cierpią bardziej niż ludzie zaangażowani w pracę backendową.

Jedynym wyjściem, jakie do tej pory znalazłem, było albo porzucenie Scruma - często nie jest to możliwe i / lub odpowiednie, ponieważ w końcu ma to swoje zalety - lub wprowadzenie czegoś w rodzaju 20% czasu Google'a, aby dać programistom kreatywne ujście poza „ty” masz swobodę wyboru sposobu implementacji strony logowania ”, ponieważ w rzeczywistości nie jesteś, ponieważ implementacja jest ograniczona istniejącym kodem i architekturą systemu - to znaczy, o ile nie bierze się pod uwagę swobody wyboru między„ a for a a loop ”a wolność.

Alexander Battisti
źródło
1

Istnieje wielka różnica między tym, że decydujesz, co robić , a tym, co ci powiedziano .

Z mojego doświadczenia, nie ma po prostu dość długa droga z nich mówi, co zrobić , aby zdecydować, co robić.

Pod koniec tej drogi zwykle okazuje się, że pouczono nas nie dlatego, że lubią moc, a nie dlatego , że nie mają nic lepszego do roboty. Wręcz przeciwnie, na końcu tej drogi - kiedy oni uzyskać wystarczającą pewność w naszym zespole - wydają się być zwolniony i szczęśliwie przekazać nam jak najwięcej kontroli, jak możemy obsłużyć (i jeśli ich zaufanie jest naprawdę mocny, że nawet próby przekazania więcej niż to)

Aha, z mojego doświadczenia wynika, że ​​nie ma to w zasadzie nic wspólnego ze Scrumem / Agile Zdarzyło się ze scrum, iteracyjnym, wodospadem, cokolwiek. Wydaje się, że kwestia zaufania jest agnostyczna

komara
źródło
1

W naszym zespole właściciel produktu mówi nam, co mamy robić, a my decydujemy, jak to zrobić. To bardzo ważne, aby mieć tę separację, w przeciwnym razie znajdziesz się w sytuacji, którą opisałeś.

thegreendroid
źródło
1

Z mojego doświadczenia wynika, że ​​Scrum powinien uważnie obserwować, co robisz. Po prostu siedzi na ramieniu i obserwuje, co robisz. Chociaż ma to swoją przewagę, nie znoszę metodologii scrum. Oczekuje liczby, a nie jakości. Jakość pogarsza się dzięki metodologii scrum.

Anto
źródło
„Jakość pogarsza się dzięki metodologii scrum.”: Być może stwierdzenie, że jakość ulega pogorszeniu, jest nieco ekstremalne, ale tak, sterowalność projektu ma wyższy priorytet niż jakość.
Giorgio
Zadziwiające, jak niewiele osób wie o scrumie lub zwinności, a jednak jak publikują jak autorytety. Odnosi się wrażenie, że osoba pracowała przez kilka tygodni w dysfunkcyjnej grupie, w której powiedziała, że ​​„robi scrum” i doszła do wniosku, że tak właśnie powinien być scrum. W tym przypadku jest to całkowicie anonimowy facet, który ma tylko jeden post lub komentarz w ciągu 4 lat i nie ma dowodów na wiedzę specjalistyczną na ten temat. Dlatego nie możemy poważnie traktować wielu z tych komentarzy.
Curtis Reed,