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

47

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 !?

Sutty1000
źródło
28
To, co wymyśliło twoje kierownictwo, nie ma absolutnie nic wspólnego z Agile.
Euforii
13
„wygląda to jak Wodospad w najgorszym tego słowa znaczeniu” - zdecydowanie nie lubię Wodospadu, ale nie wynika z tego, że wszystko, czego nie lubisz, to Wodospad. Na przykład jeśli twój proces powoduje wczesny „skok”, to znaczy działającą implementację części systemu przed zaprojektowaniem innych części, prawdopodobnie nie robisz Waterfall, nawet jeśli nie robisz Agile (właściwie ) zarówno. Jeśli nie piszesz wielu dokumentów projektowych w odpowiedzi na wiele dokumentów wymagań, zdecydowanie nie robisz Waterfall, nawet jeśli nie robisz Agile.
Steve Jessop,
3
Jak tylko coś się wydarzy, co oznacza, że ​​ogromny plan jest nierealny (i prawdopodobnie się wydarzy), wyrzuć to wszystko. Kiedy kierownictwo narzeka, przypomnij im, że manifest Agile ceni wartości „odpowiadające na zmiany w stosunku do planu”. Albo powiedzą ci, żebyś trzymał się planu, a będziesz mógł z pewnością powiedzieć, że nie pracujesz zwinnie, albo zgodzą się i pozwolą ci się dostosować, i mam nadzieję, że nauczą się, że nie warto dalej planować z wyprzedzeniem, niż można śmiało przewidzieć, a następnym razem nie będą marnować czasu na tak szczegółowy (i skazany na zgubę) harmonogram.
anaximander
3
@ Kyralessa Przynajmniej z mojego doświadczenia, Scrum jest prawie zawsze sprzedawany jako zwinna metodologia.
T. Sar - Przywróć Monikę
3
@kyralessa z szybkich badań, które mogłem zrobić, wygląda na to, że jesteś jedyną osobą, która twierdzi, że SCRUM nie jest zwinny. Jeśli masz jakieś odniesienia do tego, chciałbym je przeczytać.
Newtopian

Odpowiedzi:

60

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.

gbjbaanb
źródło
5
To prawda, ale jeśli kierownictwo zdecyduje, że i tak chce mieć pełną funkcjonalność w dniu dostawy, to programiści trzymają torbę. Otrzymujesz moje poparcie, ponieważ, jak zauważyłeś, to, co opisuje OP, nie jest z natury przeciwne działaniu Agile.
Cronax
3
@Cronax Każdy menedżer warty imienia zrozumie czas, a funkcje przeciwstawiają się siłom. Ty wybierasz, który jest najważniejszy. Jeśli zdecydują, że muszą być kompletne i zabezpieczone czasowo, to ich wina, że ​​nie obsadzili zespołu odpowiednio. (Wiem, wiem ...)
gbjbaanb 18.07.16
3
@Cronax nie bądź zbyt trudny dla biednych menedżerów, często ich sprzedaż powoduje, że się w nich znajdują.
gbjbaanb
5
Czytając to, jak stwierdzono: „wszystkie prace, które chcą, abyśmy dostarczali z datami dla każdego elementu i ponownie prezentują daty z tym, co zostanie pokazane w każdym z nich”, nie wydaje się, że plan jest elastyczny w odniesieniu do tego, co jest dostarczane w danych datach.
JimmyJames
14
Ta odpowiedź ma sens, ale wydaje się, że ma zastosowanie tylko w innej sytuacji. Z pytania wynika, że ​​to, co zostanie dostarczone i kiedy zostanie dostarczone, jest podyktowane przez kierownictwo.
Ben Aaronson
37

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.

Telastyn
źródło
6
Pesymizm @Wildcard? Czy jest to realizm ?
RubberDuck,
7
@Wildcard I jak na ironię bardzo autorytatywny, przewidując przyszłość ;-)
Cort Ammon
1
Wildcard ma rację, jestem prawie pewien, że ustaliliśmy datę, kiedy słońce wybuchnie lub o ile bardziej katastrofalne staną się katastrofy naturalne ze względu na zmiany klimatu, że światowy pokój pozostanie żartem w przewidywalnej przyszłości itp. Zobacz Telastyn, jesteśmy świetni w przewidywaniu przyszłości, więc proszę ograniczyć swoje zbyt pesymistyczne wypowiedzi!
null
8
@wildcard - No plan survives contact with the enemy. I nie możesz mi powiedzieć, kto będzie największym zwycięzcą na NYSE w styczniu 2020 roku. To prawda. Mamy wiele tysiącleci danych, które pokazują, że to prawda. I wiedząc, czego nie robić / nie może wiedzieć o żywotnym przydatność podczas planowania oprogramowania konstruktu. Spójrz na sytuację PO - przeważająca większość ich planów opiera się na domysłach nie lepszych od przypadku . Myślę, że to okropny sposób na planowanie. Nawet jeśli uważasz, że to na mnie naiwne i fatalistyczne, wciąż nie jest w żaden sposób zwinne.
Telastyn
2
Całkowicie zgodził się, że nie jest zwinny, co opisano w pytaniu. A jednak cele mogą być osiągane każdego dnia. Prawdą jest, że cele taktyczne często wymagają korekty w celu osiągnięcia szerszego celu strategicznego , ale nie uniemożliwia to dotrzymania terminu lub uczynienia tego w ramach budżetu. Nawiasem mówiąc, myślę, że faktycznie możemy być bliżej niż się wydaje: zgadzam się, że ludzie nie są świetni w przewidywaniu przyszłości. Nie zgadzam się, że to wyklucza osiągnięcie zamierzonego celu.
Wildcard,
18

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.

JimmyJames
źródło
9

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.

Cort Ammon
źródło
4

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.

Chamindu
źródło
4

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.

Falco
źródło
3

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.

Pratik
źródło
2

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.

Steve Chamaillard
źródło
1
Tak naprawdę nie chodzi o zaakceptowanie terminu. Co robisz, jeśli rząd zdecyduje, że Twoja firma musi przestrzegać określonego prawa do 2017 r.? Nie możesz powiedzieć „nie akceptuję tego” - będziesz musiał pracować w sprintach, ustalać priorytety i próbować wdrożyć wymagane funkcje. Raportujesz swoje postępy w każdym sprincie, a kierownictwo może zdecydować o zdobyciu dodatkowych zasobów, jeśli liczba prezentowanych funkcji nie spełni ich oczekiwań.
Falco
-2

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

Ewan
źródło