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

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?

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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ę?

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

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

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

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.