Skuteczne sposoby wprowadzenia Agile w miejscu pracy?

Z twojego doświadczenia (anegdotycznego lub innego), jakie są skuteczne sposoby wprowadzenia Agile do organizacji lub firmy innej niż Agile?

ZAKTUALIZOWANO: Czy ktoś może rozmawiać w sprawach, w których próbowałeś przedstawić Agile, ale zostałeś „zestrzelony”? Czy masz teraz retrospektywne zrozumienie, dlaczego zostałeś „zestrzelony”?

TO TWARDE, ALE NIEMOŻLIWE. Chyba że mieszkasz w raju. W przypadku konkretnych kroków, które możesz podjąć, z całego serca polecam wziąć kopię Fearless Change

• Najpierw uzyskaj wsparcie zarządzania . Jeśli tego nie zrobisz, nic innego nie nadrobi tego. Jeśli na wyższym poziomie jest wszystko „Ostateczny termin jest wczoraj…”, „Weekendy robocze przez następne 3 miesiące”, „Dlaczego piszesz testy, kiedy powinieneś być kodowanie? .. możemy przetestować później. Dodo po prostu nie będzie latał.
• Sprawdź, czy kultura Twojej organizacji jest odpowiednia dla sprawnych. To było coś, za czym tęskniłem. Pożyczenie wiersza z książki. Proces będzie łatwiejszy i szybszy, jeśli kultura będzie wspierać i pielęgnować nowe pomysły, da ludziom czas na naukę i robienie nowych rzeczy, jest wystarczająco cierpliwy, aby wspierać innowacje dzięki świadczenia długoterminowe i nie uznaje niepowodzenia za wyrok śmierci
• Ludzie : Zidentyfikuj innowatorów: wczesnych użytkowników: wczesna większość: późna większość: opóźniony stosunek. Pierwsze 3 to twoi odbiorcy docelowi początkowo .. powinien wynosić około 30-40% .. co daje ci masę krytyczną, aby zacząć. Problem polega na tym, że Agile zwraca uwagę na słonie w pokoju .. braki i problemy stają się łatwo widoczne .. jeśli mieszkasz w miejscu, w którym wybuchła „bozo eksplozja” (by zacytować termin Guya Kawasakiego) , zmiana byłaby naprawdę powolny i bolesny ... jeśli w ogóle. Mamy tendencję do zakładania, że ​​jeśli pomysł jest dobry, zostanie zaakceptowany. Nie prawda. Wiele powodów socjologicznych podnosi głowy.
• Następnie nie próbuj zbyt wielu rzeczy na raz. Pośpiesz się ... spokojnie . Sztuką jest zastosowanie podejścia przypominającego kod refaktoryzujący starszy. Znajdź tu i tam małe rany i załóż je zwinnym bandażem. Upewnij się, że ludzie rozumieją praktykę i korzyści oraz że powinni je przyjąć z czasem. Nie wszystko będzie się trzymać, ale wkrótce będzie lepiej. To, jak szybko zależy od wielu zmiennych, z których niektóre są poza twoją kontrolą.
• To ogromna osobista inwestycja, aby tak się stało . Ponownie sprawdź, czy jesteś gotów podjąć to zobowiązanie i przejść przez wzloty i upadki, jakie on przynosi. Być może będziesz musiał przekazać pałeczkę komuś innemu lub wyżej. Bądź przygotowany na rezygnację ze zmiany własności dla większego dobra. Nie popadaj w syndrom „To moje dziecko”.
• Zwinność jest inna dla każdego zespołu, dla każdej organizacji . Nie wszystko, co przeczytasz / zaproponujesz, zadziała. Niech akceptacja poprowadzi cię do rzeczy, które będą działać w twoim scenariuszu. Znajdź inne sposoby, które rekompensują praktyki, które się nie zakorzeniły.

Mam nadzieję, że to miało sens .. jak się domyślacie, jestem w tym od jakiegoś czasu :)

Słuchaj zespołu, kierownictwa, interesariuszy i słuchaj wskazówek. Prawdopodobnie odczuwają ból w wielu obszarach, które Agile bezpośrednio rozwiązuje.

Trzymaj się sugestii, które mogą bezpośrednio złagodzić te bóle. „Nie możesz uleczyć tego, czego nie czujesz” - że tak powiem.

To zajmuje dużo czasu, ale budowanie zaufania ma ogromne znaczenie. Dzięki przeszłym sukcesom i zaufaniu zarówno Twojego zespołu, jak i menedżera, będą patrzeć na Ciebie, gdy przyjdzie czas na podjęcie decyzji.

Widziałem to na własne oczy, po latach frustracji w próbach nakłonienia ludzi do zmiany sposobu dostarczania oprogramowania. I chociaż mam teraz sukcesy, nie jestem prawie tak blisko. Istnieje mnóstwo obszarów do poprawy, a obecnie odnoszę największe sukcesy, wprowadzając niewielkie zmiany, które bezpośrednio rozwiązują pewien rodzaj odczuwanego bólu.

Na koniec chciałbym powiedzieć, że bądźcie bardzo empatyczni. Popełniłem błąd, odrzucając większość pomysłów, zanim naprawdę je przejrzałem, ponieważ nie czytałem o tym w „zwinnej książce XYZ”. Wysłuchanie zespołu i próba wdrożenia niektórych jego sugestii zajmie długą drogę.

Powodzenia!

Pomijając kwestię techniczną, odkryliśmy, że kluczowe było znalezienie grupy w organizacji, która mogłaby kupić metodyki Agile i zapewnić „stanowisko testowe”. W naszej firmie było wielu ludzi, którzy nie rozumieli odmiennej terminologii Agile, byli zdezorientowani terminami i procesami oraz panował ogólny lęk.

Moja grupa badawcza była bardzo zainteresowana próbą uruchomienia Scruma (wraz z kilkoma innymi metodologiami typu Agile). Nasze zainteresowanie pozwoliło nam stworzyć w firmie łóżko testowe do wypróbowania różnych elementów. Najpierw dużo nauczaliśmy - rozmawialiśmy na korytarzu z ludźmi, prezentacje dla dyrektorów firm itp. Nie pchaliśmy się mocno - wykształciliśmy się. Następnie poprosiliśmy o pozwolenie, aby wypróbować to z naszą grupą.

Będzie wiele odpowiedzi na temat empirycznego pokazania, jak rzeczy takie jak programowanie w parach, programowanie oparte na testach, Scrum itp. Mogą oszczędzić czas, ale pod koniec dnia czuję, że dowód musi pochodzić z Twojej firmy. Znajdź grupę, której możesz użyć jako łóżko testowe i spraw, by faktycznie to zrobili. Nic nie rozwiąże strachu lepiej niż pokazanie, że twoja grupa to sprawia, że ​​tak się dzieje.

Wepchnij to w ich gardło, ale bez ich zauważenia;)

Przez ostatnie 6 miesięcy powoli próbowałem wdrożyć zasady zwinności (głównie scrum) w moim miejscu pracy. Najpierw wprowadziłem codzienne stójki, do których wszyscy się przyzwyczaili, ale działa całkiem nieźle. Ponieważ wszyscy pracujemy nad różnymi programami, które są częścią jednego systemu, trochę trudno jest śledzić scrum z definicji. Kolejnym krokiem jest rozpoczęcie spotkań sprinterskich, aby śledzić każdą z naszych wydań. Już trwamy miesiąc, więc długość sprintu nie stanowi problemu. Planuję również w pełni przestrzegać zasad scrum podczas naszego następnego dużego projektu. Jestem jednym z dwóch programistów w zespole projektu, a on jest cały czas do ciągłego doskonalenia. Mam nadzieję, że zarząd zobaczy korzyści z tego, co próbuję osiągnąć.

Myślę, że kluczem jest spowolnienie. Ludzie, którzy od lat znajdują się w tej samej pozycji, generalnie są przeciwni inwazyjnym zmianom, ale jeśli potrafisz to przekraść kawałek po kawałku, nie powinni tego zauważyć. Najpierw zacznij od małych częstych spotkań. Mówiąc krótko, kierownictwo nie powinno postrzegać tego jako marnowania czasu.

Rozwój oparty na testach. Demonstracja, w jaki sposób testy jednostkowe mogą przyspieszyć twojego dewelopera. czas przy jednoczesnym zwiększeniu stabilności kodu jest doskonałym pierwszym krokiem do wypicia zwinnej Kool-Aid.

Najpierw popraw się. Naprawdę. Przykład jest silnym sposobem mówienia o zwinności. Co więcej, jak ktoś już powiedział, unikaj definicji technicznych i po prostu używaj terminów zrozumiałych dla menedżerów i osób zarządzających. Zamiast tego dwa tygodnie Sprint; Zamiast tego Planuj Sprint Planowanie lub Gra Planistyczna; Menedżer produktu zamiast właściciela produktu i tak dalej. Michele Sliger zrobił niesamowitą prezentację na temat Agile w Waterfall Enterprise . Naprawdę trzeba zobaczyć wideo. Mogą Cię również zainteresować inne filmy na temat sprawnego wdrażania .

Tam, gdzie pracuję, dowiaduję się, że Scrum to dobry sposób na zwinne podejście, ponieważ kierownictwo szybko to rozumie. Jest prosty i ma ładne imię. Później, robiąc Retrospektywy, możesz zasugerować praktyki XP jako ulepszenia i będzie to całkiem łatwe, że ludzie zaakceptują przynajmniej wypróbowanie ich.

Z poważaniem

Wprowadziliśmy go do naszych zadań „Konserwacja” (błędy, zmiany o niewielkim wpływie itp.) Jako 2-tygodniowy sprint. Tak więc programiści, którzy pracowali nad długoterminowymi projektami, pozostali bez zmian, ale mieliśmy rotacyjny sprint konserwacji. Więc wszyscy mieli ochotę korzystać z wypalonych wykresów i szacunków pokera, nie zakłócając jednak dużych projektów.

Po zakończeniu każdego dużego projektu rozpoczęliśmy kolejny, stosując zwinne 2-tygodniowe sprinty. Cały proces trwał kilka miesięcy, zanim wszyscy byli na sprintach, ale oznaczało to, że było mniej zakłóceń i każdy mógł „złagodzić” ten proces

W zespole programistów wprowadzenie Agile to coś więcej, nad czym masz pewien poziom kontroli.

Widzę jednak, że głównym problemem jest wymóg, który Agile wymaga ciągłej informacji zwrotnej od „klienta” lub przedstawiciela klienta.

Dlatego naprawdę musisz skupić się na stronie edukacyjnej rzeczy spoza twojego zespołu bezpośredniego rozwoju, ponieważ prawdopodobnie będą musieli w jakiś sposób zmienić sposób, w jaki działają (tj. Znacznie większy kontakt z zespołem programistycznym).

Najlepszym sposobem, jaki powiedziałbym, jest skoncentrowanie się na korzyściach płynących z podjęcia zwinnego procesu i przekazanie ich w jasny sposób klientowi. Oczywiście, jeśli masz dział sprzedaży / rachunków w swojej firmie, to samo dotyczy tam.

Krok 1: Upewnij się, że Twój projekt ma mocne zaległości i upewnij się, że ma on priorytet

Krok 2: wprowadzenie praktyk SCRUM (możliwe do zarządzania iteracje, codzienne stand-upy, scrum-master, właściciel produktu, wykresy wypalenia)

Krok 3: każda iteracja przedstawia wyniki zespołu wraz z wypaleniem

następnie ...
zaimplementuj TDD / BDD, sparuj programowanie, recenzje kodu (wszystko bardzo delikatnie), a jeśli masz wystarczająco dobry zespół, umieść wszystkich w jednym miejscu (jeśli to możliwe, pokój zespołowy).

Przede wszystkim zrozumcie, że pojawi się opór (WOLI), więc bądźcie gotowi poradzić sobie z tym.

Inną rzeczą do zapamiętania jest to, że jeśli jesteś częścią organizacji (dużej lub małej), która jako całość nie będzie przestrzegać tych najlepszych praktyk, może minąć trochę czasu (jeśli w ogóle), aby poczuć, że robisz postępy.

Ludzie są zawsze odporni na zmiany, a przejście do scrum jest dość duże. Kluczowa jest motywacja i kierunek.

Pierwszym krokiem jest zmotywowanie ludzi do zapewnienia scrumowi szansy. Odkryłem, że Google Tech Talk Kena Schwabera był bardzo przydatny w zachęcaniu ludzi do rozpoznania korzyści płynących z scrum, zapewniając jednocześnie dobre wprowadzenie. Zacznij od osób, które Twoim zdaniem będą wrażliwe na zmianę, niezależnie od tego, czy są programistami, czy menedżerami, abyś mógł nabrać rozpędu. Posiadanie menedżerów po twojej stronie będzie w pewnym momencie koniecznością, ale to, jak sobie z tym poradzisz, zależy od twojego środowiska.

Następnie wszyscy muszą zostać przeszkoleni, bez względu na to, czy chodzi o czytanie książki, czy prowadzenie serii wykładów. Jeśli ludzie nie wiedzą, jak działa Scrum, nie możesz rozpocząć próby wdrożenia tego procesu.

Kiedy ludzie są zmotywowani i mają pojęcie o tym, co powinni zrobić, musisz mieć swoje pierwsze spotkanie planistyczne i skonfigurować niezbędne części scrum (scummaster, codzienne spotkania itp.).

Spodziewałbym się, że pierwsze spotkanie planistyczne nie odbędzie się płynnie i będzie dla wszystkich doświadczeniem edukacyjnym. Również kilka pierwszych sprintów będzie bardzo kamienistych i prawdopodobnie opóźnionych. Kluczową częścią jest teraz dyscyplina i wytrwałość. Nie pozwól, aby codzienne spotkania trwały zbyt długo, utrzymuj spotkania planowania na zadaniu i upewnij się, że wszyscy poprawnie wypełniają swoje role.

Myślę, że najbardziej odporni są ludzie, którzy od dawna zajmują się tworzeniem oprogramowania lub ludzie, którzy czują, że przechodząc do scrum, przyznają, że wcześniej robili coś złego. Jest to trudna przeszkoda do pokonania, ale myślę, że pokazując im korzyści, które możesz powoli przekonać. To zajmuje tylko czas. Z mojego doświadczenia wynika, że ​​menedżerowie produktu są naprawdę odporni, ponieważ zmusza ich to do większej jasności na temat swoich wymagań i tego, czego chcą. Ale kiedy zobaczą, jak zwinny proces przynosi im korzyści i ułatwia im życie, dość szybko wchodzą na pokład.

Powodzenia!

• Zademonstruj sukces - patrz odpowiedź Marka
• Zwróć szczególną uwagę na zasady / techniki, które wywrą największy wpływ na firmę
• Pamiętaj, że chodzi o zwinne zasady, a nie listę kontrolną procesu

Zanim pomyślisz o wprowadzeniu zwinnego programowania, najpierw sprawdź, które najlepiej pasuje do Twojej organizacji / projektu. Jeśli na przykład patrzysz na scrum, zastanów się, czy użyjesz go ściśle, czy może bardziej luźna forma scrum, lub nawet inna metoda może lepiej pasować. Moja odpowiedź brzmi więc na scrum jako twojej zwinnej metodzie.

Scrum doskonale nadaje się do projektów wymagających innowacji, w których niewiele wiadomo i gdzie potrzebne są eksperymenty. Nie nadaje się najlepiej do wykonywania takich czynności, jak konserwacja istniejących produktów lub wykonywanie okresowych prac konserwacyjnych. Na szczęście scrum jest luźną strukturą i można go używać w najlepszy możliwy sposób.

Do prac konserwacyjnych Kanban może być dla Ciebie lepszy lub możesz wypróbować tylko kilka elementów Scrum do zarządzania sprintem i robienia rzeczy takich jak codzienne awarie. Nazywam to „scrum-but”, „tak, robimy scrum w naszej firmie, ale ...”. W porządku, nie przejmuj się tym.

Aby wprowadzić scrum w swojej organizacji, potrzebujesz zaangażowania właściciela produktu i interesariusza. Jeśli jesteś małą firmą, tym facetem może być jedna osoba, szef, aw większej kierownik produktu i szef / szef działu. Sugerowałbym dwie drogi wprowadzenia scrum:

1) możesz zacząć używać scrum w nieco luźniejszej formie do natychmiastowego zarządzania istniejącymi kolejkami roboczymi. Ale spójrz też na Kanban.

2) zacznij używać scrum w bardziej rygorystycznej formie w nowym projekcie, który będzie wymagał innowacji, wczesnej informacji zwrotnej i gdzie wiele jest nieznanych. Możesz zasugerować szefowi / właścicielowi produktu, że scrum byłby idealny dla tego nowego projektu.

Ale pamiętaj! nie chodzi tylko o kod, właściciel produktu ma kluczową rolę i musi zrozumieć i spełniać swoją rolę. Oznacza to na przykład, że nie piszemy z góry wszystkich specyfikacji, a zaczynamy od minimum, szybko iterujemy, otrzymujemy informacje zwrotne, uczymy się i karmimy to z powrotem i tak dalej. Spróbuj współpracować z menedżerem produktu, który byłby tak chętny do wprowadzenia scrum jak ty, ale od strony właściciela produktu, a idealnie powinien być wystarczająco twardy, aby odeprzeć żądania kierownictwa i chronić sprint.

Wprowadzenie scrum zajmie wiele wysiłków od rozwoju i zarządzania produktem.

Przy takim nowym projekcie spróbuj przenieść nowy zespół do osobnego pokoju i użyj notatek pocztowych, aby wizualizować pracę w różnych stanach, takich jak zaległości, w toku itp. Na tym etapie nie daj się wciągnąć narzędziom elektronicznym , utrzymuj rzeczy tak proste, jak to możliwe. Nie czuj się głupio, planując poker z kartami, kiedy zaczynasz, kiedy twój zespół będzie gotowy do gry, prawdopodobnie nie użyjesz ich po prostu podając liczby.

Z mojego doświadczenia wynika, że ​​łatwiej jest najpierw wprowadzić scrum w czystej formie, a następnie ułatwić mu kolejkowanie prac związanych z konserwacją. Na odwrót jest trudniej.

Moim ostatnim komentarzem jest, aby uważać, że scrum jest jakimś panaceum rozwojowym, nie jest. Scrum jest użyteczną i prostą platformą do innowacji produktów, ale eksploruj inne metody łączenia, gdy wymaga tego Twoja firma i nie przejmuj się tym.

Kilka lat temu byłem konsultantem w bardzo dużej firmie (prawie 20 000 pracowników), która prowadziła wiele dużych projektów oprogramowania dla przedsiębiorstw. Byłem na jednym z nich. Całkiem krytyczny.

Napotkaliśmy wiele problemów, a zespół programistów mocno nacisnął na nas. Problemy były po prostu wspólne dla branży oprogramowania, ale zarząd miał doświadczenie bardziej zorientowane na infrastrukturę i bardzo mało doświadczenia zorientowanego na oprogramowanie. Więc wszystko było skoncentrowane na nas. Pomyślałem, że dobrym pomysłem byłoby poinformowanie kierownictwa o Scrumie.

Stawiłem czoła silnej niechęci, więc na jakiś czas porzuciłem ten pomysł. Ale problemy nadal się sumowały, więc wraz ze sponsorem lidera zespołu, ostatecznie zdecydowaliśmy się na Scrum, by ourselve.

Każdy, w tym ja, miał jakiekolwiek doświadczenie ze Scrumem. Więc odkryliśmy ramy, wykonując ...

Obecnie Scrum jest uogólniony na całe przedsiębiorstwo poprzez program zarządzany przez certyfikowanego trenera. Nie wiem, czy nasza inicjatywa była przyczyną. To powiedziawszy, wiem, że to była prawdziwa rewolucja w dość sztywnym towarzystwie.

Myślę, że aby wprowadzić coś takiego w takim przedsiębiorstwie, musisz przestrzegać następujących zasad:

• To musi się zmienić jest konieczne . Jeśli nie ma przekonującego powodu, że zmiana musi zostać wykonana, nie ma żadnego powodu, dla którego zespoły zarządzające miałyby podejmować ryzyko.

• Musimy skupić się na problemach zarządzania i nie wspominając o problemach programistów, chyba że są one częścią problemów związanych z zarządzaniem. Innymi słowy, musisz znaleźć rozwiązanie dla nich, a nie dla siebie. Postaw się w sytuacji zarządczej. Jakie są ich obawy?

• Nie powinieneś proponować zmiany całej organizacji na raz . Musisz zaproponować projekt pilotażowy, na którym wziąłbyś odpowiedzialność. Radzę podać realistyczne cele, takie jak znaczący wzrost widoczności tego, co się dzieje w projekcie. Jest to, według IMHO, główny wkład Scrum w zarządzanie oprogramowaniem. Pozwala ludzkiemu rozsądkowi działać, a tym samym iść do przodu.

• Wreszcie należy koniecznie upewnić się, że doświadczeni ludzie kontrolują to wprowadzenie. Nie czytaj tylko jednej lub dwóch książek. Musisz iść na szkolenie i powiedziałbym, że konieczne jest skorzystanie z doświadczonego trenera. Oczywiście da się to zrobić bez, ale będzie bolało :)

Jeśli będziesz przestrzegał zasad i przedstawiał fakty, to zadziała. O faktach znajdziesz wiele w książce Software in 30 Days: Jak sprawni menedżerowie pokonują szanse, zachwycają klientów i zostawiają konkurentów w pyle . To najnowsza książka twórców Scruma, Kena Schwabera i Jeffa Sutherlanda .

W poście na blogu Kena o książce możesz przeczytać:

Jeff Sutherland i ja to zrobiliśmy. Razem napisaliśmy książkę, nasze pierwsze wspólne pisanie od czasu pierwszej publikacji Scruma w 1995 roku. Co nas skłoniło? Pytanie, które często zadajemy:

Jak sprzedajemy Scrum naszemu kierownictwu?

Zawsze zastanawiało mnie to pytanie. Dlaczego miałbyś sprzedawać więcej przewidywalności, wydajności, jakości, wartości, kontroli ryzyka, zadowolonych klientów, zaangażowanych pracowników i mniej marnotrawstwa komukolwiek w zarządzaniu? Jednak rozmawiałem z Jeffem i stwierdziliśmy, że tam, gdzie jest dym, musi być ogień.

Ostatnią połowę 2011 roku spędziliśmy na pisaniu książki. Każdy menedżer, od góry do dołu, może łatwo podnieść i przeczytać tę książkę.

[...]

Cały czas to widzimy. (pełne ujawnienie: opracowuję aplikację do zarządzania projektami). Problem polega na tym, że zwinne metodyki wprowadzają nieodłączne napięcie w tradycyjnie zarządzanych organizacjach. Zazwyczaj kierownictwo wyższego szczebla chce mieć możliwość planowania z wyprzedzeniem. Chcą planów trzyletnich; chcą właściwie oszacowanych projektów; chcą mieć możliwość budżetowania na zatrudnianie nowych ludzi; chcą być w stanie zaangażować się w ważne etapy, jeśli chodzi o partnerów / klientów.

Ale potem dział R&D decyduje, że stanie się zwinny. Nie chodzi już o planowanie z wyprzedzeniem przez dwa miesiące przed napisaniem kodu. Sprinty będą krótkie, a poza sprintami otrzymasz oszacowania w bardzo niskiej rozdzielczości dla rzeczy, które są w zaległościach / mapie drogowej. Dział badań i rozwoju zdaje sobie sprawę, że wymagania zmieniają się zbyt często, aby klasyczny wodospad był skuteczny, ale menedżerowie produktu chcą jasnej, przemyślanej i dobrze budżetowanej wizji tego, jak będzie wyglądał produkt za 12 miesięcy.

Problemem jest więc pogodzenie tych dwóch. Jak powiedziałem, cały czas dzieje się to z naszymi klientami. Dlatego naszym rozwiązaniem jest ujednolicenie narzędzi używanych zarówno do sprintu, jak i planowania długoterminowego. Dobra, teraz nadchodzi część bezwstydnej wtyczki, więc śmiało weź ją z odrobiną soli. Jedną z naszych unikalnych cech jest to, że do zarządzania zadaniami używamy interfejsu użytkownika z możliwością powiększania. Oznacza to, że bardzo łatwo jest zagłębić się w historię użytkownika / zadanie i rozwinąć je. (możesz zobaczyć, jak to wygląda tutaj ). W rzeczywistości w naszym systemie nie ma żadnej koncepcji „projektu”. To wszystkie zadania zawierające inne zadania, łączące się z innymi zadaniami (naprawdę fraktalne). To tworzy przyjemne rozmycie między historiami użytkowników, zadaniami, projektami, eposami itp.

W praktyce wielu naszych użytkowników praktykujących zwinne metodyki tworzy plan teleskopowy, który łączy długoterminową mapę drogową (lub zaległości) z zarządzaniem krótkoterminowymi sprintami (lub iteracjami). Menedżerowie nadal widzą ładną, szacunkową mapę głównych funkcji czekających na dodanie, a programiści po prostu głębiej powiększają i radzą sobie z rzeczywistymi zadaniami roboczymi. Zaletą tego jest to, że zmniejsza ilość „targowania się”, które ma miejsce, gdy menedżerowie przeglądają plan pracy. Zamiast zespołu programistów, który podaje tylko bardzo przybliżone dane szacunkowe (tj. „4-6 tygodni!”), Mają szansę na powiększenie każdej historii użytkownika i podzielenie jej na mniejsze części. Kiedy to zrobisz, nagle będzie mniej miejsca na targowanie się. Spędzasz 10 minut na dzieleniu 5-tygodniowej historii użytkownika na części o wielkości około 1 dnia, i nagle ten argument nie brzmi „nie, możesz to zrobić szybciej. nie, nie możemy. tak, możesz”. ale „oto co wkłada się w ten wysiłek, w tym całą ukrytą pracę, której początkowe oszacowanie nie wzięło pod uwagę. Co sugerujesz, abyśmy wyeliminowali? Zapewnienie jakości? Testowanie? Szkolenie nowego faceta? Konfigurowanie środowiska kompilacji?”.

To podejście działa, dopóki używasz narzędzia, które pozwala zmieniać plany tak szybko, jak je wstępnie szkicujesz. To jest prawdziwy powód, dla którego ludzie obecnie nie znoszą wodospadu. Większość systemów sprawia, że ​​niezwykle trudno jest całkowicie przerobić istniejące plany, a ludzie bardzo racjonalnie odmawiają marnowania czasu na tę działalność.

Okej, wydaje mi się, że to zmienia się w ofertę sprzedaży, więc przestanę. :)