Czy ustalenie dat dostawy elementów jest „zwinnym” sposobem pracy?

Mówi się nam, że będziemy pracować sprawnie nad nowym projektem przez kierownictwo wyższego szczebla. Stworzyli oni stand-upy, planowanie sprintu, retrospektywy itp. Jednak teraz opracowali plan wyszczególniający całą pracę, którą chcą, abyśmy wykonali z datami dla każdego elementu i ponownie pokazali daty z tym, co zostanie pokazane w każdym z nich jeden. Plan wchodzi w życie do drugiego kwartału 2017 r.

Dla mnie wydaje się to w najgorszym sensie Wodospad, opracowano plan bez wkładu zespołu technicznego, w którym pewne historie dotyczące planu są bardzo niejasne i żaden z nich nie oszacował.

Wiem jednak, że ich argumentem będzie „starsi interesariusze muszą mieć daty i musi istnieć plan, nie możemy po prostu pracować z zaległości”. Wydaje mi się, że starsi interesariusze nie kupili Agile, dlatego jesteśmy skazani na niepowodzenie we wdrażaniu go na niższym poziomie.

Czy to sprawiedliwy osąd, czy przesadzam z tym planem !?

Istnieje różnica między dotrzymaniem terminu a spełnieniem wszystkich wymagań. To jak stare powiedzenie „szybko, dobrze lub tanio, wybierz dwa”.

Tutaj masz ustalone daty dostawy - to dobrze, oznacza to, że masz określone ramy czasowe, ponieważ to, co dostarczysz na koniec ostatniego sprintu, będzie produktem końcowym. Pamiętasz, że zawsze musisz wypuszczać działające oprogramowanie na końcu każdego sprintu, prawda?

Może się zdarzyć, że w ostatecznym oprogramowaniu nie będzie niektórych funkcji. Dzieje się tak ze wszystkimi metodologiami rozwoju, w tym z wodospadem. Wszystko, co się stanie, to zadanie polegające na wyprodukowaniu łatki lub wersji 2. Zakłada się, że ostateczna dostawa jest wystarczająco dobra!

Tak więc ustalone daty nie są zwinnym sposobem pracy. Zwinność nie oznacza, że ​​masz nieograniczony budżet na grę z nowymi narzędziami do planowania. Oznacza to, że musisz skupić się na dostawie, co nigdy nie jest złe.

Nie. To jest dokładnie to, co zwykle robią firmy inne niż oprogramowanie. Istnieją plany, terminy i budżety. I nieuchronnie się nie powiedzie, ponieważ ludzie są do bani przewidywania przyszłości.

Przejrzyjmy tutaj różne punkty:

Mówi się nam, że będziemy pracować sprawnie nad nowym projektem przez kierownictwo wyższego szczebla.

Gdybyś był zwinny, to miałbyś samoorganizujące się zespoły, których kierownictwo nie powiedziałoby, jak pracować.

Jednak teraz wymyślili plan wyszczególniający całą pracę, którą chcą, abyśmy dostarczyli daty dla każdego elementu i ponownie zaprezentują daty z tym, co zostanie pokazane w każdym z nich.

Nie. Jest to w zasadzie przeciwieństwo iteracyjnego rozwoju. Coś się wydarzy (ktoś zachoruje, ktoś odejdzie, zapomniano o jakimś wymogu, wasze serwery umierają, cokolwiek), a potem stracicie jeden z tych celów. Teraz kierownictwo może albo przeliczyć cały plan, albo złamać bicz przy rozwoju.

żaden nie został oszacowany przez zespół deweloperów.

Skąd więc zarząd wie, że ten plan jest w ogóle wykonalny ? W Agile praca jest negocjacją. Biznes mówi: chcielibyśmy to. Inżynieria mówi: okej, przy założeniu XYZ, zajmie to 3 tygodnie. Nie ma współpracy z klientem w tym, co opisujesz. Brak osób i interakcji.

Wydaje mi się, że starsi interesariusze nie kupili Agile, dlatego jesteśmy skazani na niepowodzenie we wdrażaniu go na niższym poziomie.

Niekoniecznie jesteś skazany, ale jeśli nie, to tylko zbieg okoliczności. Kiedy wszystkie prace się pojawią, ponieważ kierownictwo nie widzi przyszłości, przegapisz swoje daty (lub produkujesz tandetny kod lub potrzebujesz więcej zasobów niż oczekiwano). To będzie twoja wina. Kierownictwo najprawdopodobniej będzie wtedy wywierać na ciebie presję, abyś pracował więcej godzin, aby dotrzymać terminu, lub może rzucić ludzi na problem.

Najlepszy przypadek , zarządzanie jest w rzeczywistości sprawne i wystarczająco inteligentne, aby ograniczyć zakres. To znaczy, że spędzili cały ten czas na tworzeniu dużego szczegółowego planu, który jest bezwartościowy.

Jeśli istnieje oczekiwanie, że określone zestawy funkcji zostaną dostarczone w określonych terminach, to nie, nie jest to sprawne zarządzanie projektami. Zwinne zarządzanie projektami ma charakter empiryczny. Prognozy nie są tworzone na podstawie życzeń kierownictwa, lecz na podstawie analizy wcześniejszych wyników.

Twój opis pasuje do tego, co uważam za zwinne pod względem kultowym. Koncentrujemy się na konkretnych procesach i ceremoniach, a nie na podstawowych koncepcjach zarządzania projektami opartymi na dowodach. Możesz mieć trochę szczęścia w zrozumieniu ludzi biznesu, jeśli odniesiesz to do Lean lub TPS . Prawdziwym problemem, który musisz rozwiązać tutaj, jest pokonanie przez kierownictwo lęku przed nieznanym. Prawidłowa odpowiedź dla kadry kierowniczej brzmi: „nie możemy teraz powiedzieć, kiedy coś się stanie, ale kiedy zaczniemy dostarczać wartość, możemy budować prognozy na podstawie naszego doświadczenia”. Deweloperzy zwykle mówią takie rzeczy, jak: „zrobione, gdy gotowe” i „Nie wiem, kiedy będzie gotowe”. Menedżerowie nie powiedzą takich rzeczy kierownictwu, to sprawia, że ​​brzmią jak nincompoops.

Najprawdopodobniej plan się nie powiedzie i należy go zmienić. Największe ryzyko dla zespołu polega na tym, że nastąpi duży nacisk na dotrzymanie terminów i ucierpi jakość. W pewnym momencie nie będziesz w stanie osiągnąć celu (najprawdopodobniej będzie to pierwszy termin) i będzie naciskać, aby trafić w tę datę. Nadgodziny będą oczekiwane i będzie presja, aby skracać rogi (pomiń test jednostkowy, recenzje kodu itp.) Jest to śliskie nachylenie, a kiedy zaczniesz tą ścieżkę, jest to trochę spirala w dół i wszystko stanie się brzydkie. Wydajność będzie się pogarszać w miarę kontynuowania projektu.

Jeśli uda Ci się skłonić zespół programistów do zaprezentowania jednolitego frontu, naprawdę powinieneś odepchnąć się i utrzymać linię jakości. Z mojego doświadczenia wynika, że ​​kierownicy projektów uważają, że dane wyjściowe oprogramowania są liniowe. Oznacza to, że każdy okres X da Y „procent ukończony”. Oznacza to, że jeśli nie osiągniesz „50% ukończenia” w połowie dozwolonego czasu, klaksony zaczną wybuchać. W rzeczywistości, jeśli robisz to dobrze, pierwsza funkcja zajmuje znacznie więcej czasu niż 50. funkcja (o podobnej wielkości). Jeśli możesz przejść przez ten początkowy okres zagrożenia („co się dzieje?”, „Nie rozumiem” t widzę, jak coś się robi! ”) prawdopodobnie będziesz w porządku.

Witamy w prawdziwym biznesie.

Istnieje starszy styl prowadzenia działalności, który szyderczo nazywam „tradycyjnym rozwojem”, a następnie nowy styl, „zwinny rozwój”. Jeśli spróbuję potraktować je jako przeciwstawne ideały, widzimy prosty podział na środek: plany i wymagania dotyczą tradycyjnej kolumny, odkrycie i ewolucja idą w zwinnej kolumnie. Jest schludnie, schludnie i źle.

W rzeczywistości biznes to poszukiwanie szczęśliwego medium między nimi. Łatwo jest wykazać, że każda skrajność faktycznie pada płasko na twarz. My, którzy kochamy Agile, chętnie demonstrujemy wszystkie kwestie czystego ideału tradycyjnego rozwoju, a jest wielu, którzy mogą pokazać, w jaki sposób czysty Agile się rozpada. Skuteczne firmy zwinne to te, które znajdują między nimi szczególną równowagę. Tradycyjne firmy odnoszące sukcesy to te, które znajdują między nimi szczególną równowagę. Nie możesz mieć jednego bez drugiego.

Nawet nasz błogosławiony proces SCRUM pokazuje równowagę między nimi. Chociaż istnieje wyraźna próba maksymalizacji zwinności, istnieje kilka kluczowych kompromisów. Na przykład właściciel produktu ma ogromną rolę w promowaniu wszystkich klientów. SCRUM celowo nie określa sposobu działania tej interakcji. Celowo zastanawia się nad tym, że wszyscy muszą otrzymać zapłatę na koniec dnia. Zadaniem właściciela produktu jest stworzenie iluzji, która nie ma znaczenia.

(Warto zauważyć, że czysta zwinność działa świetnie, dopóki nie otrzymasz zapłaty, dopóki nie wyprodukujesz produktu, i nie uzyskasz dostępu do zastrzeżonych informacji, dopóki nie otrzymasz uprawnień. Myślę, że jedyni inżynierowie oprogramowania, którzy są komfortowi z tą branżą są przedsiębiorcy)

Dlatego kierownictwo podyktowało, jakie funkcje będą tam dostępne i kiedy będą potrzebne. W porządku. Słyszałem zdanie: „klient wybiera, co i kiedy, producent wybiera, kto i jak”. Zostałeś zarejestrowany na „co” i „kiedy”. Nie powiedzieli nic o tym, kto i jak, oprócz zaoferowania ci możliwości użycia „Agile” jako twojego sposobu. Pozostało tylko pomóc kierownictwu zrozumieć, ilu ludzi będą musieli zatrudnić, aby zaspokoić swoje potrzeby.

W idealnym świecie Twoja firma jest zwinna z zewnątrz. W zwinny sposób współdziała z klientami, umożliwiając programistom sprawny rozwój. Jednak bardzo często firma musi wchodzić w interakcje z otoczeniem, rozwijając się sprawnie. Pomiędzy nimi jest zawsze złożony zestaw kompromisów, unikalny dla każdej firmy.

Osobiście traktuję tę sytuację jako przypadek testowy dla każdego, kto uważa, że ​​rozumie zwinny rozwój. W pewnym momencie w przyszłości będziesz musiał opracować produkt w określonym terminie, a ta para produkt / termin zostanie względnie ustalona. Jeśli ustalony produkt / termin zakłóca proces, czy naprawdę możesz powiedzieć, że byłeś zwinny?

Moja rada: nie myśl o tym jak o wodospadzie. Nadal kontrolujesz „jak”. Nadal możesz wykonywać szybkie i elastyczne prototypowanie, z którego Agile jest tak znana. Musisz tylko zdawać sobie sprawę, że guma styka się z drogą i musisz ją dostarczyć. To jest prawdziwy świat, a nie świat idealny. Czy lepiej byłoby, gdyby zapytali cię w pierwszej kolejności? Pewnie. To może nie być twój telefon. Może być tysiące powodów biznesowych, aby zrobić to po swojemu, czego po prostu nie rozumiesz. Zapraszam do odparcia ich, ale zrozum, że mogą mieć bardzo dobry powód tego, co zrobili.

Zwinne nie przeszkadza w planowaniu kamieni milowych (np. Wydamy V 1.0 za 3 miesiące), ale to, co trafi do każdego z kamieni milowych, nie może zostać naprawione.

Myślę, że to, jak powinieneś zareagować, zależy od charakteru projektu. Jeśli projekt ma wysłać człowieka na Księżyc do drugiego kwartału 2017 r., Wszyscy zgodziliby się, że jest skazany na niepowodzenie. Jeśli uważasz, że możesz dostarczyć MVP do końca drugiego kwartału 2017 r., Powinieneś popracować nad tym sprintem przez sprint.

Jeśli kierownictwo uważa, że ​​Twój zespół robi wszystko, co w jego mocy, i możesz wykazać postępy przy każdym sprincie, powinieneś być w stanie negocjować przez dłuższy czas.

KAŻDY projekt związany z biznesem ma ograniczenia:

• Czas
• Zasoby
• Oczekiwany minimalny zestaw funkcji

To nic więcej. Rozwijanie zwinności nie oznacza „ludzie płacą nam pieniądze, dzięki czemu możemy rozwijać, na co tylko chcemy, kiedy tylko będzie to gotowe” - zawsze będziesz miał pewien przedział czasowy. Zawsze będzie data z pewnymi minimalnymi wymaganiami, a jeśli nie zostaną one spełnione, projekt zostanie anulowany i zostanie nazwany niepowodzeniem. Czasami mogą być niejawne - tak więc menedżer wie „Jeśli nie mam działającego interfejsu użytkownika z tymi funkcjami po 4 tygodniach, ten projekt jest skazany na porażkę” - lub mogą istnieć akcjonariusze, którzy ustalą cel.

Istnieje wiele projektów wynikających z prawodawstwa. - Jeśli rząd zdecyduje, że musisz wdrożyć Funkcję X do 2017 r., Aby przestrzegać nowego prawa, otrzymasz niepodlegający negocjacji termin i zestaw funkcji, które muszą być gotowe. Jedyną zmienną jest ilość zasobów, którą kierownictwo może przydzielić do zadania. - A w tych projektach, w których termin jest decyzją zewnętrzną, będą musieli obserwować twoje postępy, usłyszeć twoje prognozy i obsadzić zespoły lub zlecić część pracy, aby osiągnąć swoje cele.

Wszystko to nie sprzeciwia się zwinnemu rozwojowi. Nadal będziesz miał swoje sprinty, rozwijasz swoje funkcje we własnym czasie. Zawsze otrzymujesz swoje priorytety funkcji od klienta - i dołożysz wszelkich starań, aby dostarczyć ich jak najwięcej do terminu.

Jeżeli termin rzeczywiście zostanie dotrzymany z dostępnymi zasobami, stanowi problem zarządzania. Możesz podać swoje prognozy oraz cotygodniowe / codzienne aktualizacje statusu, a oni mogą zdecydować, czy potrzebują więcej zasobów. W przeciwnym razie będziesz kontynuować pracę w sprintach i dostarczać runnable - tak samo jak każdy projekt.

Jak ktoś już zauważył, zanim manifest mówi:

Osoby i interakcje w procesie

Proponuję przyjrzeć się przedstawionemu planowi i zaproponować zmiany. Pamiętaj, że Manifest mówi, że zaległości nigdy nie są ostateczne, ciągle się rozwijają.

Możesz więc przekazać swoje sugestie zespołowi. Jeśli masz uzasadnienie i zespół się na to zgodzi, każdy właściciel produktu wart swojej soli weźmie je pod uwagę i usunie zaległości, aby odzwierciedlić opinię całego zespołu.

To jest punkt, w którym może pójść na dwa sposoby.

1. Właściciel produktu i firma zgadzają się z twoim uzasadnieniem i mogą zwiększyć zasoby, aby dotrzymać terminu, jeśli jest to opcja LUB mogą zrezygnować z niektórych funkcji, aby dotrzymać terminu.

2. Mogą nadal chcieć trzymać się własnej wersji wbrew zbiorowej opinii zespołu.

Jeśli wynikiem jest # 2, nie jest to zwinne.

Jeśli skończysz z numerem 1, powiedziałbym, że zespół jest na dobrej drodze, ponieważ Agile nie polega tylko na tym, że deweloperzy „Odpowiadają na zmiany”, ale także na tym, że firma może reagować na zmiany.

Wyobraź sobie, że poprosiłeś kogoś o pomalowanie ściany, domu, a następnie całej ulicy, ile czasu poświęciłbyś tej osobie na zrobienie tego?

Jakakolwiek jest twoja odpowiedź, będziesz w błędzie. Otóż ​​to.

Nie ma mowy, żeby mieli rację co do dat, gdyby nie pytali ludzi, którzy muszą wykonać pracę, co myślą.

Nawiasem mówiąc, jeśli ty (jako zespół) zaakceptować te daty, jesteś w tym złego.

Powinieneś poprosić o trochę czasu, aby wspólnie z interesariuszami popracować nad tym planowaniem, abyś mógł ustalić priorytety w zależności od tego, jak łatwo i szybko można to zrobić.

Na przykład, być może ostateczna praca zajmie dwa razy dłużej, niż myśleli, ale mogliby użyć wersji beta znacznie wcześniej, niż się spodziewali.

Podsumowując, nie możesz pozwolić ludziom myśleć, że będziesz w stanie wykonać X w Y, jeśli nie możesz lub mógłbyś być szybszy, to Twoim obowiązkiem jest wyjaśnienie, czego potrzebujesz, jeśli chodzi o szczegóły i czas.

To nie aglie planuje nie.

Ale jeśli udajesz, że nie znasz planu, po prostu pracuj sprintem po sprincie. To może działać.

Zawsze będą daty i budżety. Zawsze istnieje ryzyko, że zostaną pominięte lub przekroczone, a kiedy to nastąpi, zawsze będziesz musiał wrócić do planu B.

Jeśli pracujesz zwinnie, plan B jest, mam nadzieję, wersją demonstracyjną ostatniego sprintu