Kiedy Agile idzie źle [zamknięte]

Piszę kurs Agile dla niektórych nowych facetów, do których ostatnio dołączamy, i chcę dodać ostrzeżenie, aby zrozumieli, że Agile nie jest przeznaczony dla wszystkich projektów.

Mój problem polega na tym, że ze względu na naturę projektów, w których pracuję z Agile, jak na razie działa całkiem dobrze, nie mogę uczciwie wskazać, co może pójść nie tak i dlaczego, gdy używasz go w niewłaściwym projekcie.

Na co zwrócić uwagę, gdy projekt Agile się nie powiedzie?

Największa porażka w zespołach „Agile” wynika z tak zwanego Cargo Culting . Zasadniczo zespoły chcą efektów skutecznych zwinnych zespołów, aby naśladowały widoczne działania

• Codzienne awarie (trwające około godziny)
• Rozbijanie pracy na sprinty
• Historie użytkowników (zwykle są to niewiele więcej niż zdanie, ale można się spodziewać ich oszacowania)

To są trzy, które zobaczysz konsekwentnie „stosowane” w tych środowiskach, ale bardzo mało zaangażowania w faktyczną zwinność. W rzeczywistości usłyszysz, jak kierownictwo mówi, że „działamy sprawnie”. (Uciekaj od tych dwóch słów, to zły znak.)

Dowiesz się też dużo o długu technicznym, ale ich definicja długu technicznego brzmi: „zrób to szybko i brudno, a może uda nam się później poprawić”. (Tłumaczenie: sprawimy, że zabrzmi to tak, jakbyśmy martwili się o łatwość konserwacji, ale w rzeczywistości zachowamy tę samą mentalność kotłowni, ponieważ to działało dla nas w przeszłości).

Inne kluczowe frazy: „Wiem, że te historie nie są w pełni zdefiniowane, ale pracujemy sprawnie, abyśmy mogli je naprawić w miarę upływu czasu”.

„Robimy sprawny rozwój, więc powinieneś być w stanie zaspokoić to, czego potrzebuję w sprincie, gdy go zidentyfikuję”.

„Nie jesteśmy w stanie zablokować naszych zaangażowanych historii na początku sprintu, ponieważ trzeba zmieniać się w połowie sprintu”.

Kluczowym wskaźnikiem tego, czy projekt Agile odniesie sukces, jest to, czy kierownik projektu (scrum master lub jakakolwiek inna rola) przeszedł doświadczenie lub formalne szkolenie na temat prowadzenia zwinnego projektu. Zbyt często widziałem, jak ludzie czytają o Agile w książce lub biorą udział w dwudniowym kursie bycia mistrzem scrum i myślą, że mają możliwości, aby go z powodzeniem wdrożyć. Przepraszam, to się nie dzieje kapitanie.

Osoby, które nie rozumiały, na czym polega zwinność (była?) I stosują ją do:

• klienci, którzy nie mogą komentować do upływu terminu
  ... i później grożą podjęciem kroków prawnych ;

• menedżerowie, którzy trzymają programistów z dala od klienta (prawdopodobnie dlatego, że są nieco niedopłacani i mogą skakać statkami, idąc do pracy dla tego klienta) i grają w „ zepsuty telefon ” w desperackiej (choć często udanej) próbie patrzeć na zajęty i użyteczny,

  Zobacz także: zarządzanie grzybami , czyli „ukryte, karmione obornikiem” i spiczastymi włosami szefów . :)

• zespoły, które są zbyt duże, aby jechać gdziekolwiek;

• firmy, które utrzymują na liście płac niegdyś znani projektanci architektury systemu, którzy desperacko odwracają uwagę od faktu, że całkowicie stracili z oczu rzeczywiste rzemiosło kodujące, poprzez przeprojektowanie wspaniałych, niepraktycznych, trudnych do zrealizowania, familias sagrada UML .

Agile nie nadaje się do umów na czas określony lub umów o stałej cenie. Po zapisaniu się na taką bestię musisz dostarczyć. Zwinny jest bardzo dobry w ciągłym rozwoju na zawsze, ponieważ klienci zmieniają zdanie i „wyjaśniają” swoje wymagania. To nie pomoże ci w dniu wyczerpania pieniędzy, ale nadal musisz zakończyć pracę.

Zwinność jest bardzo dobra w fazie postprojektowej, gdy wykonujesz przyrostowe aktualizacje i poprawki błędów.

Drugi aspekt, w którym Agile kończy się niepowodzeniem, nie jest winą Agile, ale winą ludzi, którzy nalegają na wszystkie stare rzeczy, takie jak pełna dokumentacja projektu, projekty wstępne i słaba komunikacja. (W połowie zwinny manifest zwinny ).

Oto kilka pytań, które mogą być przydatne w poszukiwaniu odpowiedzi w zakresie znalezienia przykładu, w którym próba Agile może pójść źle:

• Czy Agile jest nowym mikrozarządzaniem?
• Proces zwinny: jak i co należy udokumentować?
• Właściwe połączenie planowania i programowania nowego projektu

Czy słyszałeś kiedyś o „pseudo Agile”? Oto kilka wpisów na ten temat na blogu:

• Od Pseudo-Agile do Waterfall - Ścieżka małej i nowej firmy produkującej oprogramowanie
• Pseudo Agile!

Jest coś do powiedzenia dla firm, które mogą mieć własne zdanie na temat tego, co jest zwinne i rozbijać to na coś innego.

Pracowałem w bardzo udanym zespole Agile, a także w kilku, którzy próbowali Agile, ale nie udało mi się go uruchomić.

Ten udany miał następujące elementy:

• Naprawdę „zwinne” wymagania. Były historie użytkowników, a my je zakodowaliśmy.
• Dostępny właściciel produktu. Jeśli historia użytkownika, z której kodowałem, była niekompletna, mógłbym łatwo przejść do właściciela produktu, zapytać go, co powinno tam być, dodać go i uzupełnić kod.
• Zaangażowanie w proces i uświadomienie sobie, że była to krzywa uczenia się.
• Zespół skoncentrowany.
• Menedżerowie, którzy znali i rozumieli zwinny sposób robienia rzeczy, którzy byli zaangażowani w to, aby działało.

Zespół, który odniósł sukces, zrobił Agile i zrobił to naprawdę dobrze. Sądzę, że jeśli nie masz żadnego z powyższych punktów, możesz łatwo zawieść. Pierwsza i druga rzecz idą w parze, a jeśli tego nie masz, Agile nie będzie działać.

Zespół, w którym pracowałem, który nie radził sobie dobrze z Agile, również miał kilka elementów:

• Brak zaangażowania ze strony kierownictwa. Kierownictwo nie wierzyło w tę filozofię i dlatego wahało się to zrobić.
• Wymagania udokumentowane w innych miejscach niż historie użytkowników. Zobacz wyżej o zaangażowaniu kierownictwa. Mieliśmy też wysoko płatnych analityków wymagań i duże drogie narzędzia wymagań, których ktoś potrzebował, aby uzasadnić użycie.

Dodam do świetnych odpowiedzi, które już napisałem, że z mojego doświadczenia, zwinny, a konkretnie Scrum będzie działał tylko wtedy, gdy kierownictwo ORAZ zespół chętnie dadzą dużą widoczność tego, co się dzieje.

Oznacza to, że w spółkach publicznych (na przykład rządach) bardzo trudno będzie sprawnie działać.

Nie wiem tego z własnego doświadczenia, ale hipotetycznie istnieje wiele okoliczności, w których zwinność nie jest najlepszą opcją.

• Projekty, których produkt ma krytyczne znaczenie dla życia lub własności - Na przykład nie chcesz używać zwinnego do tworzenia oprogramowania, które uruchamia rozrusznik serca. Czemu? Ponieważ masz prawie zerową tolerancję na błędy. Rozważ klasyczny przykład błędu programowania w medycynie w odniesieniu do Therac 25 . To prawda, że ​​nie został zbudowany zręcznie, ale chodzi o to, że rozwój życia lub własności krytycznej nie ma miejsca na powiedzenie: „posprzątamy to podczas następnego sprintu” lub „nie potrzebujemy wielkiego, po prostu dobrego wystarczająco."

• Projekty ze zbyt dużą liczbą młodszych programistów - Agile oczekuje pewnej autonomii w grupie uczestniczącej. Jeśli zespół nie ma wystarczającego doświadczenia, ta autonomia może działać przeciwko tobie.

• Projekty wymagające wyższego stopnia kontroli lub planowania niż to, co jest tradycyjnie oferowane w Agile.

Zakładam, że albo ktoś inny wskoczy i pomoże w lepszych przykładach, albo głosuję za ten kawałek flaczki, który napisałem ;-).

Pamiętaj tylko, że gdy jedynym narzędziem, które masz, jest młotek, każdy problem wygląda jak gwóźdź. Nie wszystkie projekty to paznokcie.

Zwinne moim zdaniem polega na kulturze zespołu, który ćwiczy. Jeśli kultura jest do bani, członkowie zespołu nie dogadują się, a ludzie nie współpracują, aby spełnić zobowiązania do sprintu, to kultura lub zespół są niewystarczające.

Niekoniecznie powiedziałbym jednak, że Wodospad musi koniecznie działać w takim środowisku, nie jest to sytuacja czarno-biała, bardzo mało jest naprawdę czarno-białe.

Dobry zespół Agile jest wspólny. Mają plemiennego ducha wspólnoty, w której wszyscy członkowie dążą do tych samych celów. Zespół odnosi sukcesy lub porażki razem. Pracują razem nad rozwiązywaniem problemów. Członek zespołu przerwie to, co robi ze swoimi zadaniami, aby pomóc walczącemu członkowi zespołu. Wszystko jest zlewem lub pływaniem.

Gdy tak nie jest, szybko staje się jasne, co jest nie tak. Jeśli członkowie zespołu siedzą, piszą na laptopie, piszą SMS-y lub dzielą strefę podczas codziennego pojedynku, to nie masz dobrego zespołu Agile. Jeśli Twoi kierownicy projektów egzekwują wszystkie procedury, definicje i terminologie Scrum, ale wszyscy tylko zachowują rytm i wypowiadają się, to jest to raczej rażąca farsa tego, czym naprawdę jest Agile, a to na wiele sposobów prowadzi do dysfunkcji zespołu, nieefektywności , przekroczone terminy i nieudane projekty.

Niepowodzenie Agile jest pod wieloma względami gorsze niż średnio udany zespół Waterfall i prawdopodobnie ma niższe wskaźniki powodzenia projektu.