To pytanie gotowało się w mojej głowie przez pewien czas, więc chciałem zapytać tych, którzy przestrzegają praktyk zwinnych / scrumowych w swoich środowiskach programistycznych.
Moja firma w końcu odważyła się wdrożyć zwinne praktyki i zaczęła od zespołu 4 programistów w zwinnej grupie na zasadzie próbnej. Minęły 4 miesiące z 3 iteracjami i nadal to robią, nie pozostając w pełni zwinnym dla reszty z nas. Wynika to z faktu, że zaufanie kierownictwa do spełnienia wymagań biznesowych przy dość dużej liczbie zapytań typu ad hoc z góry.
Ostatnio rozmawiałem z programistami, którzy są częścią tej inicjatywy; mówią mi, że to nie jest zabawne. Nie mogą rozmawiać z innymi programistami przez swojego mistrza Scrum i nie mogą odbierać żadnych połączeń telefonicznych w obszarze roboczym (co może być do pewnego stopnia w porządku). Na przykład, jeśli chcę porozmawiać z moim przyjacielem o kopnięcia, który jest w zwinnej drużynie, nie wolno mi bez zgody mistrza Scrum; który siedzi tuż obok zwinnego zespołu.
Ideą tego wszystkiego lub zwinności jest zapewnienie pełnej próżni zwinnym programistom od wszelkich zakłóceń i zapewnienie im dobrych 6+ produktywnych godzin. Cóż, chłopaki, nie jestem zwinnym guru, ale to, co przeczytałem zwinny dokument dotyczący wdrażania Yahoo i podobne dla innych organizacji, daje mi wrażenie, że zwinność nie jest tania. Wymagają zasobów i budżetu, aby zaszczepić zwinne zespoły i rozwiązać problem po ich przybyciu, aby przywrócić je na właściwe tory.
Na początek wymaga szkolenia dla programistów i coachingu dla menedżerów itp. Itd. Obecny mistrz Scrum był menedżerem, który odbył kilka dni zwinnej klasy szkoleniowej opłaconej przez kierownictwo, która prowadzi teraz ten zwinny zespół. Słyszałem również na spotkaniu, że manifest zwinny nie dyktuje, że zwinny nie jest osadzony w kamieniach i jest dostosowywany inaczej dla każdej firmy. Cóż, wszystko brzmi dobrze i uzasadnione.
Podsumowując, zawsze myślałem, że zwinny powinien przynieść harmonię w zespołach programistycznych, co prowadzi do zadowolenia programistów. Jednak mam wrażenie zupełnie przeciwne, gdy rozmawiam z programistami w zwinnym zespole. Są niezadowoleni, że nie mogą rozmawiać tylko poza pracą, siedzą spokojnie przez cały dzień i pracują, i uważają, że to kolejny sposób zarządzania, aby zwiększyć ich pracę.
Powiedz mi proszę, czy jest to jeden z przykładów dobrych praktyk stosowanych w celu samolubnej przewagi za więcej dolarów? A może tylko my, programiści tacy jak ja, i ten zwinny zespół czuje, że nie lubią pracować w środowisku, w którym oddychają tylko dlatego, że są w pracy.
To firma z branży opieki zdrowotnej, która ma biura w całych Stanach Zjednoczonych. Zdecydowanie czuję się jak agresywny w stylu kowbojskim, co sprawia, że naprawdę nie chcę wcale być agile, szczególnie w mojej obecnej firmie.
Wszystko to ma związek z tym, że zarządzanie jest całkowicie tanie. Wycinanie drogiej kawy w celu uzyskania tańszej wersji, nacisk na oszczędność i produktywność przy zachowaniu jak najbardziej szczupłej sylwetki.
Mam wrażenie, że ktoś z kierownictwa za drzwiami odrzucił ten pomysł, że zwinność sprawia, że produkujesz więcej, abyśmy mogli pokazać naszym szefom, że produkujemy więcej przy tym samym zatrudnieniu. A może pozwoli nam to zmniejszyć liczbę pracowników, jeśli tak jest.
Codziennie odbywają 5-minutowe spotkanie. Ale nie wolno rozmawiać ani rozmawiać z kimś spoza zespołu. Koncentrujemy się na pracy.
źródło
Odpowiedzi:
Opisujesz dyktaturę kierowniczą, a nie zwinną. Zwinność polega na stopniowym rozwoju w dziedzinie zmieniających się wymagań, a nie na dyktowaniu ludziom indywidualnego podejścia do wykonywania pracy.
źródło
To naprawdę nie jest częścią zwinnych praktyk - i osobny problem.
Dużą motywacją metodologii Agile jest zwiększona komunikacja między programistami. Ograniczanie komunikacji programisty <-> z programistą jest kwestią niezależną od praktyk Agile. Nie twierdzę, że tak się nie dzieje - oczywiście tak jest i jest oznaczane jako część „zwinnego” wdrożenia w Twojej organizacji, ale tak naprawdę jest to kwestia odrębna od zwinności (i nieco wbrew duchowi zwinnego rozwoju, IMO).
źródło
To brzmi jak całkiem przewrotna implementacja zwinności. Zwinne, jeśli w ogóle, powinno zmniejszyć mikrozarządzanie, a nie je zwiększyć. Zespół zobowiązuje się, a częścią procesu jest to, że kierownictwo wierzy, że zespół go zrealizuje. Codzienny scrum jest sposobem dla programistów na komunikowanie się ze sobą i sposobem na informowanie o tym, co zrobili, a nie o tym, jak spędzili czas (co jest błędem, który widziałem w kilku miejscach). Nawet proces szacowania powinien usunąć jawne zachowanie czasu z oszacowań, ponieważ powinieneś szacować względną złożoność, a nie to, jak długo zajmie opowieść (kolejny powszechny błąd). Kontrolowanie czasu spędzanego przez programistów jest cechą mikrozarządzania, a usuwanie czasu z procesu jest jedną z podstawowych zasad zwinności.
źródło
Opisywane środowisko brzmi jak pseudo-zwinne bzdury odmiany ogrodowej .
Zaangażowałem się w Agile, zanim była to Agile. Około 2000 roku wypaliłem kodowanie, usłyszałem o Extreme Programming, wypróbowałem go i polubiłem. Jako programista dał mi kontekst, w którym najważniejsze było tworzenie solidnego oprogramowania, i dał mi narzędzia do zminimalizowania wielu bzdur, które doprowadzały mnie do szału. Kocham to.
Problem dzisiaj, który szczegółowo wyjaśniam gdzie indziej , polega na tym, że większość ludzi „adoptujących Agile” w tych dniach nie jest zainteresowana poprawą czegokolwiek, co sprawia, że czują się niekomfortowo. Dla nich „Agile” to po prostu nowy kij do pokonania programistów w ten sam stary sposób. W przeciwieństwie do, powiedzmy, sposobu radykalnego zwiększenia wydajności przy jednoczesnym usunięciu wszystkich bzdur, które spowalniają rozwój.
Teraz. Zaczynam firmę i będę używał dużo XP, a także wielu innych sztuczek, które oparłem w świecie Agile. Ale właśnie z powodu takich historii jak ja, wzdrygam się za każdym razem, gdy słyszę o adopcji Agile.
Aby odpowiedzieć bezpośrednio na twoje pytanie: zwinne nie powinno być nowym mikrozarządzaniem. Powinno to polegać na wzmocnieniu pozycji ludzi wykonujących rzeczywistą pracę, aby zrobić gówno. Ale w twoim przypadku Agile brzmi jak najnowsze kłamstwo, które ci mówią, podczas gdy oddają się swoim złym instynktom. Za co naprawdę mi przykro.
źródło
To nie jest zwinne.
Po pierwsze, Scrum nie jest zwinny . Scrum, szczerze mówiąc, to bzdury. Wychowałem się w domu programowania ekstremalnego (dosłownie - kazałem Kentowi Beckowi usiąść na kanapie mojego taty i porozmawiać ze mną o testowaniu) i mogę powiedzieć wprost, że Scrum to nie to. Scrum to narzędzie do zarządzania projektami - określony rytm projektu deweloperskiego. Ale nie ma nic do powiedzenia na temat samego rozwoju, a bardzo mało na temat wymagań, planowania i relacji z klientem. XP ma wiele do powiedzenia na ten temat; każda inna metodologia, która chce się nazywać zwinną, musi mieć coś do dodania do rozmowy. Zwolennicy Scruma opisali to nie jako proces, ale jako opakowanie procesu. Mądry człowiek zauważył kiedyś, że opakowanie jest rzeczą, którą usuwasz i odrzucasz, aby dostać się do dobrych rzeczy.
Okej, scrum się skończył!
Po drugie, podstawową zasadą XP, która moim zdaniem jest fundamentem każdego zwinnego procesu, jest to, że koncentruje się na deweloperze . Jest to sposób na zapewnienie programistom mocy do wykonywania pracy, o której wiedzą, że muszą ją wykonać i dlatego tak często ich nie ma. Zwinny zespół może mieć strukturę demokracji lub autokracji, ale liderzy są programistami. Istnieją role kierowników projektów i tak dalej - ważne role - ale nie jest to kierownictwo zespołu. Posiadanie menedżera - przepraszam, „mistrza scrum” - siedzenie tam i kierowanie ludźmi to pewny znak, że zespół nie robi zwinności.
Czuję, że powinna być trzecia. Nie ma
źródło
Scrum jest bękartem Agile. Jest to najbardziej wodospad ze wszystkich zwinnych metodologii i dlatego jest najpopularniejszy wśród menedżerów.
Wszystkie zwinne metody polegają na tworzeniu działającego kodu bez przeszkadzania. Przeczytaj to jeszcze raz. I znowu.
Wszystko, co przeszkadza w osiągnięciu tego celu, niezależnie od „zwinnych zasad”, jest złe. Jeśli reguły ci przeszkadzają, zmień reguły f * * ! To zwinny sposób, dzięki czemu jest odpowiedni i skuteczny.
Najlepszym przykładem tego jest przez Alistair Cockburna (jeden z inicjatorów agile manifestu)
Jeśli to działa na jakość twoich facetów, to wszystko, czego potrzebujesz. Nie potrzebujesz mistrza scrum ani żadnej „zwinnej” metodologii. Jeśli siedzi w codziennym scrum działa dla Ciebie, to f * * * to zrobić. Zmuszanie cię do wstania to po prostu żałosne zniesienie twojej zdolności do samodzielnego myślenia.
Jest reakcja na rodzaj zwinności, który robisz. To jest to. Wydrukuj i przypnij gdzieś, gdy nikogo nie ma w pobliżu, i pozwól im to odkryć.
źródło
To Twój problem. Kierownictwo chce trochę zwinności, tak naprawdę nie wiedzą, co to jest, i narzucają to zespołom. To właściwie co zrobić, jeśli chcesz znacznie zmniejszyć produktywność programistów;)
Nowa propozycja procesu powinna pochodzić od programistów. Lub przynajmniej przejrzeć je i zatwierdzić, jeśli jest to pomysł kierownictwa.
W każdym razie, jeśli deweloperzy odmówią, nie wdrażaj go ! Albo będzie to katastrofa, którą opisujesz.
źródło
„Zwinna” i każda inna „metodologia zarządzania” jest często nadużywana w celu wymuszenia mikrozarządzania na ludziach. OTOH jest czasem nadużywane w celu obrony złego wykonania.
„Jesteśmy zwinni” to najczęstsza wymówka, jaką słyszę z powodu braku planowania, braku myślenia o projekcie, funkcjach, jakości i cyklach wydawniczych. Zazwyczaj pochodzi to od deweloperów i niższego kierownictwa. Jest to również szalenie najczęściej używana wymówka, jaką słyszę od menedżerów średniego szczebla, architektów, sprzedawców itp. W odniesieniu do mikrozarządzania, zawsze zmieniających się terminów i list wyróżniających, wymuszających masowe nadgodziny na ludziach (ciągle zmieniające się terminy i listy funkcji zapewniają to oczywiście) itp. Itp. .
Oba oczywiście są często w bezpośredniej sprzeczności i mogą się zdarzyć w tym samym projekcie.
źródło
Aby odpowiedzieć na twoje pierwotne pytanie, czy Agile to nowe mikro zarządzanie, powiedziałbym, że nie.
Najpierw przeczytaj ten (manifest Agile), a zauważysz, że nie rozmawianie ze współtwórcami nie jest wymienione.
W rzeczywistości „Indywidualności i interakcje” jest dokładnie odwrotnością nie rozmawiania ze współtwórcami.
źródło
Zwinne powinno być nowe samozarządzanie. Jeśli zwinność jest praktykowana poprawnie, wiele decyzji jest podejmowanych przez klienta i programistę, pracując nad odpowiednio rozbudowaną historią użytkownika, która jest dodawana do zaległości wraz z identyfikacją zadań.
Codzienny scrum dotyczy komunikacji, a nie zarządzania. Będą dyskusje na temat równoważenia priorytetów i obciążenia, ale osoba zarządzana w scrumie jest, mam nadzieję, mistrzem scrum. Jako programista uczestniczę, mówię, co zrobiłem, co zamierzam zrobić i jakiej pomocy potrzebuję. Wtedy mistrz scrum powinien włączyć się do akcji, usuwając przeszkody dla moich postępów.
Zwinne zespoły nie mogą mieć poczucia, że codzienna praca jest zarządzana hierarchicznie. Jeśli decyzje podejmowane są z daleka przez kogoś na szczycie hierarchicznej organizacji, nadszedł czas na decentralizację procesu decyzyjnego! Dla niektórych osób i niektórych organizacji może to być pomost zbyt daleko. Jeśli poniższe informacje nie są zgodne z twoją organizacją:
Żyć Agile Manifesto
Unikaj „Poznaj nowego szefa, tak samo jak stary szef”. Pochodź zwinnie w zespole w jak największym stopniu. Czasami dzieje się tak, wybierając koalicję chętnych do wzięcia udziału w próbnym projekcie z wykorzystaniem Agile. Jeśli możesz utworzyć zespół Agile z wolontariuszy lub zaproszonych członków, którzy mają doświadczenie w dobrej pracy zespołowej, mogą to wypracować. Skorzystaj z małego zespołu przy krótkim projekcie, być może dla klienta wewnętrznego lub wysoce dostępnego.
Uwzględnij zmianę. Być może możesz przejść szkolenie, ale może twój budżet jest napięty i pieniędzy po prostu nie ma. Inne możliwości mogą również zapewnić poprawę. Poczytaj trochę, poproś członków zespołu, aby dowiedzieli się, co mogą na temat Agile i nauczali się nawzajem. Być może będziesz w stanie znaleźć nowych lub istniejących pracowników posiadających kwalifikacje do modelowania i kierowania w adaptacji Agile.
źródło
Zwinne drużyny są jak drużyny piłkarskie pracujące na rzecz powszechnie rozumianego celu. Od kilku lat jestem częścią zwinnych zespołów, a kluczem jest skuteczna i wydajna komunikacja między wszystkimi zainteresowanymi stronami. Menedżerowie / mistrzowie Scrum są jedynie pomocnikami zespołu, a tradycyjne zarządzanie / mikro zarządzanie zabije ducha zespołu.
W zespołach, w których pracowałem, zachęcamy do grania w gry zespołowe po godzinach pracy, aby poprawić koleżeństwo wśród członków. Zebrałem tutaj te myśli .
źródło
Aby odpowiedzieć na twoje pytanie: Nie. Agile nie jest formą mikrozarządzania. Ale jak każde narzędzie, ludzie mogą go używać nieprawidłowo. Zwinność jest cudowna, jeśli jest właściwie wdrażana i gdy ludzie są z nią zgodni.
Moje przemyślenia na temat „Deweloperzy nie rozmawiają z nikim oprócz mistrza scrum”:
Pracowałem wcześniej w miejscu, w którym była to reguła. JEDNAK zasada była bardziej związana z proszeniem ludzi o wykonanie zadań. Na przykład nie mogę losowo pójść do testera i poprosić go o wykonanie testów w ciągu kilku godzin. Muszę porozmawiać z mistrzem scrum, aby mogli omówić ze swoim członkiem zespołu, w jaki sposób ta praca będzie pasować do sprintu, jeśli jest to nagły wypadek (lub jeśli trzeba go zepchnąć do zaległości na przyszły sprint).
W takim przypadku zrozumiałem pojęcie „deweloperzy nie rozmawiają ze sobą”, ponieważ tak naprawdę przełożyło się to na wykonywanie zadań przez jeden punkt kontrolny, dzięki czemu dany programista nie jest przepracowany lub jest tak zajęty wykonywaniem zadań awaryjnych, że nie mogą zrealizować swojego planu robota skończona.
W przeciwnym razie deweloperzy POWINNI rozmawiać ze sobą. Zawsze. Pomaga szybciej pracować z problemami, zbliżyć się do zespołu i szybciej dostarczać.
Żeby zaoferować inną perspektywę: byłem także w środowisku, w którym ludzie myśleli, że deweloperzy „za dużo mówią”. Po przysiadu okazało się, że w rzeczywistości przetłumaczone na „deweloperzy nie są wystarczająco niezależni, aby wykonać własną pracę. Ponieważ wszystko jest tak rozdrobnione, deweloperzy muszą udać się do trzech innych osób, aby wykonać małe zadanie”.
Kiedy więc menedżerowie postanowili przejść na agile, spodziewali się, że pomogą to dostarczyć informacje we właściwe miejsca i powstrzymają fragmentację wewnątrz organizacji. Niektórzy byli rozczarowani, że po wdrożeniu Agile, deweloperzy wciąż biegali w tę iz powrotem. Ale nie zdawali sobie sprawy, że dzieje się to coraz mniej. Zajęło to jednak trochę czasu. Może dlatego, że tak dzieje się w Twojej organizacji, być może ludzie oczekują od firmy sprawnego rozwiązywania problemów z dnia na dzień. To po prostu nie tak działa.
źródło
Oryginalny autor Smith Janes mógł dać doświadczenie. Ale to typowe problemy, które znalazłem w projekcie Agile.
Nadużywaj tutaj ... albo niski udział firmy lub uczestnika nie posiadającego pełnej wiedzy, albo przedsiębiorca odpadający w trakcie sprintu.
Zwinność to zdecydowanie dobra metodologia. Chyba że twoja organizacja nie przestrzega całkowicie lub nie jest przeszkolona .... Jest nadużywana ... skutki uboczne 60+ godzin pracy / tydzień, obwinianie, niska moralność.
źródło
Agile to mikrozarządzanie w przebraniu. W Agile nie ma miejsca na inicjatywę ani kreatywność. Usunęło to zabawę z programowania, aby niekompetentni menedżerowie mogli zachować kontrolę nawet bez pojęcia z technicznego punktu widzenia.
źródło