Czy Agile jest nowym mikrozarządzaniem?


80

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.


71
Widziałem więcej nadużyć w imię zwinności, niż chciałbym komentować. Wiele razy „robimy sprawnie” oznacza „odrzucamy pozory procesu i robimy to, co chcemy, Yeehaw!” (dla oczywistego odniesienia do kowboja). Cichej okolicy na pewno pomaga, ale trzeba mieć , aby umożliwić programistom ze sobą rozmawiać i młotkowych rzeczy - bez scrum dyktatora zatwierdzenia.
Berin Loritsch,

28
Cóż, nie robisz zwinnego ...
CaffGeek

13
To naprawdę mowa. Bez pytania
JohnFx,

8
2 dni na certyfikowanym kursie scrum master nie czyni menedżera mistrzem scrum, podobnie jak 24 godziny nauczysz się c ++ w ciągu 24 godzin nie czyni cię zdolnym programistą c ++. Po prostu robią to źle.
Mat.

9
wymagana lektura: Manifest zwinności na wpół arseowany „Słyszeliśmy o nowych sposobach tworzenia oprogramowania, płacąc konsultantom i czytając raporty Gartnera ...”
gnat,

Odpowiedzi:


89

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.


7
Jedyną rzeczą, którą mogłem znaleźć, był post „Joel on Software” na 12 najważniejszych tematach, które każda firma powinna zapewnić swoim programistom. Jeden z 12 był cichym miejscem do pracy. Wątpię jednak, czy Joel Spolsky miał na myśli to.
Berin Loritsch,

5
Ciche miejsce pracy to takie, w którym jeśli nie rozmawiasz, ogólnie rzecz biorąc jest cicho i gdzie możesz rozmawiać bez przeszkadzania innym. Oznacza to brak kultury przywoływania ludzi przez domofon i stosowanie generatorów białego szumu lub innych metod minimalizacji pozornego poziomu dźwięku w obszarach, w których pracuje wiele osób. Zasada zakazu mówienia nie czyni spokojnego miejsca pracy.
Kevin Cathcart

5
@Kevin Cathcart, zgadzamy się w tej sprawie. Teraz byłem w firmie, gdzie było odwrotnie. Mieliśmy ~ 40 osób w kojcu z otwartymi stołami i bez kostek. Jedyny zespół, który mógł cokolwiek zrobić, to ten, który spowodował większość hałasu. To jest rodzaj środowiska, przed którym chcesz chronić.
Berin Loritsch,

8
@Kevin - Mój dział rozwoju to otwarta farma, obok trzech dzwonów z napisem „Wyprzedaż”, „Wielka wyprzedaż” i „Wielka wyprzedaż”. Kilka razy dziennie sprzedawcy dzwonią do nich i krzyczą „wooooo!”. : - \
Dan Ray

2
@ Dan Miałem kilka wywiadów kilka lat temu, podczas których trzy startupy powiedziały mi, że muszą odsunąć sprzedawców od deweloperów, ponieważ oni też byli! @ # $ Głośno.
Erik Reppen

46

Nie mogą rozmawiać z innymi programistami przez swojego mistrza Scrum i nie mogą odbierać połączeń telefonicznych w obszarze roboczym

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


29
Jest to absolutnie sprzeczne z pierwszą zasadą Agile Manifesto: „Osoby i interakcje między procesami i narzędziami”. Aby uzyskać więcej informacji, zobacz agilemanifesto.org .
Berin Loritsch,

„Jest to absolutnie sprzeczne z pierwszą zasadą Manifestu <XXX>”; zamień wszystko na XXX, a będziesz miał swój kultowy wybór. ;-) Poważnie, czy to cię nie zastanawia?
CesarGon,

5
@CesarGon, w tym przypadku mówimy o zasadach sprawnego działania. Jeśli nie możesz przypisać podstawowych zasad zwinności, być może nie chcesz zwinności. Dość proste. Nie mówię „nawróć się na wiarę”, mówię „rób to, co mówisz, w co wierzysz”. Poważnie, czy to cię nie zastanawia?
Berin Loritsch,

1
@CesarGon, opisywane OP dotyczy polarnego przeciwieństwa intencji tej wytycznej, jak to tylko możliwe. W którym momencie uważasz, że ton środkowy jest wystarczająco blisko? Wygląda na to, że 95% różnica między tonami jest wystarczająco bliska. No chodź. I daj mi trochę uznania. Od dłuższego czasu pracuję w świecie rzeczywistym i definiuję procesy w korporacjach. Rozumiem dość dobrze, co jest wystarczająco blisko - a to, co opisał PO, nie jest tym.
Berin Loritsch,

2
@Berin Loritsch: Daję ci kredyt; nie miałem zamiaru wyglądać inaczej. Moja początkowa uwaga na temat kultów próbowała brzmieć częściowo żartując. Chodzi mi o to, że nie potrzebujemy kilku linijek manifestu, aby bronić czegoś, co jest rażąco przeciw zdrowemu rozsądkowi. OP opisuje sytuację, w której wszystkie alarmy dzwonią. Mam nadzieję, że dobrze to odbierasz; przepraszam, gdybym był zbyt surowy. :-)
CesarGon

31

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.


24

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.


4
+1. Zwinne / scrum / xp lub cokolwiek innego to po prostu „mumbo jumbo” dla sklepów IT, które nie są rzeczywistymi firmami produkującymi oprogramowanie. Jak powiedziałeś, nikt nie wprowadzi radykalnych zmian, chowając głowę w piasku za pomocą tych praktyk. Wystarczy przeczytać ten wspaniały Lean Software Development: zwinny zestaw narzędzi i pozostawić za sobą wszystkie BS. Takie wnioski nie są dla sklepów IT, to mój wniosek.
Smith James

23

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


-1, nie zgadzam się. Zwinne programowanie oznacza również, że oczyszczasz i usprawniasz procesy, a także zdolność dostosowywania się do zmian. Dokładnie o to chodzi w Scrumie. Scrum dotyczy również wymagań i planowania, po prostu inaczej.
Falcon

6
No dalej, to jest 2012. Cytuj publiczne pisanie Kent Becka lub zostaw to. Nie ma znaczenia, czy wzdrygnął się na twojej kanapie.
nes1983,

6
@ nes1983: Napisałem to w 2011 roku. Wtedy było inaczej.
Tom Anderson,

3
Nigdy nie słyszałem terminu „dług techniczny”, dopóki na moim radarze nie pojawił się szum. Byłem na szkoleniu. Łatwo sprzedawany olej wężowy przeznaczony do odwołania się do kierownictwa kosztem długoterminowych względów dotyczących jakości produktu. 100% bzdury. Chociaż całkowicie przełknęłbym to, gdyby Scrum Masters nieśli miecz w stylu Conana, aby zabić ludzi, którzy zagrozili integralności procesu.
Erik Reppen

2
+1 za rant Scruma. Myślę o Scrumie jako o metodologii „Agile” dla osób, które tak lubią wodospad, że chcą to robić co dwa tygodnie.
Kyralessa

16

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)

„Umieść 4-6 osób w pokoju ze stacjami roboczymi i tablicami i dostępem do użytkowników. Niech dostarczą działające, przetestowane oprogramowanie użytkownikom co miesiąc lub co dwa miesiące, a w przeciwnym razie zostaw je w spokoju. ”

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


Masz na myśli, że dostarczają działające, przetestowane oprogramowanie użytkownikom co 2/3 tygodnie?
user272671,

2
@ user272671 NIE. Niech regularnie dostarczają działające, przetestowane oprogramowanie do użytkownika. Nie według głupio arbitralnego harmonogramu, jak 2 lub 3 tygodnie. Jeśli użytkownicy lub złożoność oprogramowania jest taka, że ​​cykl 6-tygodniowy działa, wykonaj 6 tygodni. Jeśli można to zrobić „po zakończeniu”, zrób to. Nie poddawaj się sztucznym ograniczeniom. To nie jest zwinne.
gbjbaanb

11

Obecny mistrz Scrum był menedżerem, który odbył kilkudniowe szkolenie zwinne opłacane przez kierownictwo, teraz prowadzi ten zwinny zespół.

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.


9

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


Z mojego doświadczenia ... Słyszałem tylko, że zwinny (zawsze scrum) wprowadzony w celu wyjaśnienia mikrozarządzania. Nie zaprzeczę, że jest to inny i unikalny styl mikrozarządzania. Nigdy nie słyszałem, żeby deweloper powiedział, że są zwinni, i wytłumaczył, że nadejdzie. Jakiego rodzaju scrum wymuszonego zarządzania napotkałeś?
JM Becker,

1
ilekroć natknąłem się na scrum, wprowadzano go, ponieważ kierownik (zwykle wyższy od kierownika projektu) słyszał o nim jako o „rzeczy”.
jwenting

7

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.


Cóż, „Osoby i interakcje” robią teraz w swoim zespole. Jak to działa przeciwko zwinnemu manifestowi, jeśli spojrzysz z głównego punktu widzenia Scrum? Problem polega na tym, że nie mogą oni wchodzić w interakcje z innymi zespołami, aby utrzymać swoją wydajność, co jest powodem narzekania zwinnej grupy.
Smith James

Nie wchodzą w interakcje. To jest problem. Upewnij się, że programista może godzinami nadużywać przywilejów i mówić o bezsensownych rzeczach. Jednak większość dobrych programistów chce dostarczyć projekt wysokiej jakości. To kwestia dumy. Wszystko, co robi mistrz scrum, podważa to, a zamiast tego czyni to kwestią represji. Nie o to chodzi w agile. Mistrz Scrum powinien umożliwić zespołowi produktywność, a nie złamać bata i powiedzieć mu, żeby był produktywny. Oni już chcą być produktywni.
Berin Loritsch,

2

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

„Odkrywamy lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym”.

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.


1

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 .


1
Rozwijaj relacje zawodowe po pracy. Powinniśmy rozwijać często zaniedbywane relacje rodzinne i przyjacielskie po pracy. Biorąc pod uwagę Współpracowników rzadko są przyjaciółmi i wykorzystują większość okazji, aby pomóc sobie kosztem innych. Ludzie tak, kumple i narzędzia po prostu nie zdają sobie z tego sprawy, ponieważ możliwości są rzadkie. XP może mieć jakąś wartość, nie mam doświadczenia, by powiedzieć inaczej. Scrum stał się inną wersją mikrozarządzania, przynajmniej w 3 znanych mi firmach. .... Wiesz co, nienawidzę korporacyjnej Ameryki o wiele za bardzo, by być choćby odrobinę obiektywnym.
JM Becker,

0

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.


-1

Oryginalny autor Smith Janes mógł dać doświadczenie. Ale to typowe problemy, które znalazłem w projekcie Agile.

  1. Większość organizacji, programiści powinni pracować w wielu projektach, w Agile / scrum. Sprinty nigdy nie są uważane za ten fakt. twój Scrum Master zakłada, że ​​powinieneś skończyć z twoimi historiami pod koniec sprintu. Twój Scrum Master może być poświęcony tylko jednemu projektowi, ale nie deweloperom. TO JEST ZAKŁÓCENIE - nie musisz po prostu odbierać telefonu lub zezwalanie na połączenie telefoniczne.
  2. Widziałem projekty Agile, w których planowany jest Sprint, Historie zawarte w Sprint, bez skulenia się .. w połowie lub w połowie sprintu .. Programiści stwierdzający, że zależności nie zostały rozwiązane, wymagania lub historia nie są ukończone opowiadane ... jest jednym z nadużyć w większości zwinnych projektów.
  3. Testowanie: TTD .. tak, jest bardzo dobre .. ale widziałem większość projektów Agile całkowicie polegających na TTD ... brak zakresu lub czasu na testy funkcjonalne lub testy na ludziach. Kolejne nadużycie ... Wiele Scrum Masters również nie znasz ani nie rozumiesz znaczenia testów funkcjonalnych. Twój fragment kodu może działać idealnie, jeśli nie spełnia potrzeb biznesowych .. jest bezużyteczny .. Dzieje się tak, gdy biznes nie uczestniczy z dużym wyprzedzeniem ... lub uczestnictwo jest ... ale nie odzwierciedla podejmowania decyzji biznesowych .. Na koniec obwiniamy deweloperów, nie dostarczyłeś funkcjonalności .. albo skończy się to zmianą w ostatniej chwili ... bardzo długie godziny, ponieważ twój Scrum master nie chce ponosić winy za niedokończoną historię.

Nadużywaj tutaj ... albo niski udział firmy lub uczestnika nie posiadającego pełnej wiedzy, albo przedsiębiorca odpadający w trakcie sprintu.

  1. Nie wszystkie projekty są odpowiednie dla Agile ... Większość menadżerów lub mistrzów scrum nie wie o tym ... Projekty konserwacyjne. Początkowo można założyć, że usterka może zostać wykonana w ciągu 8 godzin, zaakceptowanych w sprincie. Po spędzeniu 4 godzin okazało się, że jest to Java / inny produkt ... (Niedawno miałem do czynienia z defektem związanym z Quartz Scheduler ... wewnątrz naszego projektu) i ta wada może doprowadzić do uaktualnienia produktu / paczki. Sprzedaż z biurokracją, zatwierdzeniem, finansowanie, nowa wersja lub aktualizacja powinny zostać zatwierdzone przez Internal Engineering itp., 5. Kontrola: ten krok wykonuje tylko garść projektów Agile. Jeśli w ogóle zostanie zrobiony .. Zarządzanie, Scrum Master nigdy nie wziął odpowiedzialności za nieudane historie.
  2. Parowanie ... Wielu programistów traktuje parowanie jako miejsce nadużyć współpracowników .. krytykuje inne projekty, praktyki kodowania .. rater traktuje jako pracę zespołową., Uczy się od siebie nawzajem ... Kolejny sposób nadużywania Agile / Scrum.

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


zobacz ten link .. dlaczego projekty Agile kończą się niepowodzeniem .. brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda

Zgadzam się również z informacjami przedstawionymi w tym artykule. Rozumiem, że są tacy, którzy myślą, że Agile jest nieomylny, ale w rzeczywistości Agile pozostawia niewiele lub nie ma miejsca na wprowadzanie nowych i bardziej skutecznych pomysłów. is..brighthubpm.com / agile / 55778-dlaczego-do-agile-projects-fail
user272671

-3

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.


2
Nie możesz się bardziej mylić. W zwinnym zespole powinny mieć bardzo dużą kreatywną kontrolę. Zwinny wymaga ogromnej inicjatywy, ponieważ to zespół decyduje o tym, jak zaimplementować każdą historię. Zarządzanie faktycznie ma bardzo niewielką kontrolę nad zwinnym procesem. Osobiście trzy różne zwinne zespoły, w których byłem częścią, były bardzo fajne. Wygląda na to, że doświadczyłeś poważnej niekompetencji, która utożsamiła się ze zwinnością, nie będąc blisko niej.
Bryan Oakley

dodaj jakieś uzasadnienie na poparcie twojego twierdzenia (co ma dla mnie pewien sens, ale to nie ma znaczenia), a ja usunę głos negatywny
komara

1
Zgadzam się z @Geo. Do tej pory mam wrażenie, czym jest „Agile” w prawdziwym świecie. Kiedy masz takie ustawienie na hali produkcyjnej - jest to po prostu forma mikrozarządzania. Teraz Manifest próbuje nam powiedzieć, że tak nie jest. Ale projekt po projekcie doprowadził mnie do jeszcze większego przekonania, że ​​jest to po prostu inna nazwa „Micromanagement”. I zabija kreatywność.
user272671
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.