Radzenie sobie z nieudanymi sprintami i terminami

80

Wiele książek i artykułów Scruma mówi, że nieudany sprint (gdy zespół nie ukończy niektórych funkcji z rejestru Sprint) nie jest taki zły, zdarza się od czasu do czasu i może być naprawdę przydatny, jeśli zespół uczy się na swoich błędach i poprawia coś w następujących sprintach. Zespół nie powinien być karany za niedokończenie pracy, do której się zobowiązali.

Wygląda to świetnie z punktu widzenia dewelopera, powiedzmy jednak, że mamy firmę programistyczną „ Scrum-Addicts LLC ”, która opracowuje coś dla poważnych klientów („ Money-Bags Corporation ”):

  1. Menedżerowie Scrum-Addicts sugerują stworzenie oprogramowania dla Money-Bagów
  2. Uzgadniają listę funkcji, a Money-Bag prosi o podanie daty wysyłki
  3. Menedżerowie Scrum-Addicts konsultują się ze swoim zespołem scrumowym, a zespół twierdzi, że ukończenie wszystkich funkcji zajmie 3 tygodniowe sprinty
  4. Menedżer Scrum-Addicts dodaje 1 tydzień, aby być bezpiecznym, obiecuje wysłać oprogramowanie w ciągu 1 miesiąca i podpisuje umowę z Money-Bag
  5. Po 4 sprintach (termin wysyłki) zespół Scrum może dostarczyć tylko 80% funkcji (z powodu braku doświadczenia w nowym systemie, konieczności naprawy krytycznych błędów w poprzednich funkcjach w środowisku produkcyjnym itp.)
  6. Jak sugeruje Scrum, w tym momencie produkt jest potencjalnie wysyłany, ale Money-Bag potrzebuje 100% funkcji, jak wspomniano w umowie. Więc łamią umowę i nic nie płacą.
  7. Scrum-Addicts znajduje się na skraju bankructwa, ponieważ nie otrzymali pieniędzy od Money-Bagów, a inwestorzy byli rozczarowani wynikami i nie chcą już dłużej pomagać firmie.

Oczywiście żadna firma programistyczna nie chce być w butach Scrum-Addicts. To, czego nie rozumiem w Agile i Scrum, to to, jak sugerują zespołom radzenie sobie z planowaniem i terminami, aby uniknąć sytuacji opisanej powyżej. Podsumowując, mam 2 pytania:

Kogo winić?

  1. Menedżerowie, ponieważ ich zadaniem jest właściwe planowanie
  2. Zespół, ponieważ zobowiązali się do wykonania większej pracy, niż mogli
  3. Ktoś inny

Co należy zrobić?

  1. Menedżerowie powinni przesunąć termin 2x (lub 3x) razy później niż szacuje zespół pierwotny.
  2. Członkowie zespołu powinni być zachęcani do wykonywania wszystkich prac, do których się zobowiązali bez względu na wszystko (poprzez nakładanie kar za nieudane sprinty)
  3. Zespół powinien porzucić Scruma, ponieważ nie jest to zgodne z obowiązującymi w firmie zasadami dotyczącymi terminów
  4. Wszyscy powinniśmy porzucić rozwój oprogramowania i dołączyć do klasztoru
  5. ???
Andre Borges
źródło
31
Punkt 3 w sekcji „Do zrobienia” zakłada, że ​​nieużywanie Scruma zmieniłoby wszystko, mając tylko 80% funkcji gotowych w ciągu jednego miesiąca. To jest absurdalne.
Doc Brown
7
@DocBrown, nie mogę się zgodzić, że to śmieszne. Porzucenie niektórych działań Scruma, takich jak spotkania retrospektywne i demonstracyjne, może przyspieszyć rozwój. A w przypadku solidnej umowy może to pomóc w osiągnięciu ostatecznego celu: dostarczenia określonej liczby funkcji na koniec terminu.
Andre Borges,
26
@AndreBorges Twoja sugestia wycofania się z retrospekcji i demonstracji jest taka sama, jak sugestia dotycząca usunięcia hamulców z samochodu. Jasne, hamulce tylko cię spowalniają. Ale to pozwala ci iść naprawdę szybko.
Euforia
13
ten sam problem pozostaje w każdym systemie - pamiętaj, że możesz praktycznie zastąpić Scrum równorzędnym wodospadem, a firma wciąż się psuje
jk.
6
Być może gdyby menedżerowie Scrum-Addicts zwracali większą uwagę podczas tych nieznośnych „retrospektywnych” spotkań, mieliby szansę zahamować w 1. lub 2. tygodniu, zamiast oglądać, jak projekt kieruje się w stronę klifu i nacisnął pedał gazu .
Dorus

Odpowiedzi:

134

W twoim przykładzie widzę kilka podstawowych problemów związanych z zarządzaniem:

  • jeśli menedżer Scrum-Addicts podpisze umowę „na czas”, ale dodaje tylko margines bezpieczeństwa w wysokości 33% w sytuacji, gdy „dotyczy to nowego systemu”, jest to dość lekkomyślne.

  • dostępność dostarczenia co najmniej x% funkcji po upływie jednego miesiąca mogła zostać wykorzystana do negocjacji umowy, w której klienci płacą pieniądze co najmniej częściowo, gdy otrzyma tylko 80% funkcji w terminie. Umowa typu „wszystko albo nic” nie jest korzyścią ani dla dostawcy oprogramowania, ani dla klienta - oznacza to nie tylko 0 pieniędzy dla dostawcy, ale także 0 funkcji dla klienta. A metodologia rozwoju typu „wszystko albo nic”, taka jak „Wodospad”, pozwala tylko na pisanie takich umów, a zwinne podejście oferuje dodatkowe możliwości.

  • spojrzenie na wyniki pierwszego lub dwóch sprintu powinno było uświadomić menedżerowi, że drużyna nie może dotrzymać terminu. Powinien był więc podjąć wcześniejsze działania i ponownie ustalić priorytety dla pozostałych zadań i funkcji lub spróbować ponownie negocjować z klientem wcześniej. Na przykład menedżer mógł spróbować zmniejszyć zakres niektórych pozostałych funkcji, więc zespół mógł dostarczyć wszystkie funkcje wymienione w umowie, ale każda z nich w ograniczonym zakresie.

Jeśli zadanie okaże się trwać dłużej, niż się spodziewałeś, żadna metodologia programowania cię przed tym nie uratuje. Jednak zwinne podejście, takie jak Scrum, daje zarządowi więcej możliwości kontrolowania tego, co dzieje się w tej sytuacji. Jeśli nie wykorzystają tych możliwości, to z pewnością jest to ich wina, nie wina zespołu, nie wina „Scrum”, a nie wina klienta, ponieważ „nie akceptuje zwinności”.

Doktor Brown
źródło
47
+1 za „Umowa typu wszystko albo nic” nie jest czymś, z czego ani dostawca oprogramowania, ani klient nie skorzysta ” . Jest to kluczowe w zwinnym kontraktowaniu.
guillaume31
5
I z pewnością jest tak, że 80% nie jest dobre dla niektórych rodzajów projektów (ostatecznie jest możliwe , choć mało prawdopodobne, że zwinność jest zbyt ograniczająca, aby zapewnić rezerwę na te projekty). Na przykład nie ma sensu mieć 80% funkcji satelity podczas jego uruchamiania, dlatego nie zadzierasz z przypadkowością na te projekty. Jeśli nie dostarczysz, to misja klienta nie powiedzie się (lub zostanie opóźniona), nic nie możesz zrobić w umowie, aby to zmienić.
Steve Jessop,
6
@SteveJessop: Jestem prawie pewien, że nawet jeśli zbudujesz tak skomplikowaną rzecz, jak oprogramowanie dla satelity, istnieją różne priorytety dla różnych funkcji i będzie wiele funkcji, w których zakres może się do pewnego stopnia różnić. Termin może być oczywiście ustalony dla takiej sytuacji, ponieważ gdy nie dostaniesz rakiety w kosmos do grudnia przyszłego roku, możesz nie dostać drugiej szansy.
Doc Brown
6
Ale w tym konkretnym przykładzie ... oczywiście nikt nie wysłałby nowych horyzontów, gdyby nie udało mu się ukończyć hardwarredriver kamer. Ale nawet w przypadku projektów na taką skalę, założę się, że nie ma miejsca w kosmosie z każdą funkcją, jaką sobie wyobrażali.
Zaibis,
6
być może opcją może być również płatność za kamień milowy lub funkcjonalność.
Bram
68

Jednym z oświadczeń o wartości „ Manifestu dla sprawnego tworzenia oprogramowania ” jest:

Współpraca z klientami w zakresie negocjacji umów

Fakt, że Scrum-Addicts LLC wynegocjował umowę zamiast nawiązania współpracy z klientem, sprawia, że ​​wątpię w ich zwinność.

Jedno jest jasne: KAŻDY musi zaakceptować zwinność. Zwinność jest nie tylko dla programistów. Menedżerowie i klienci muszą również zaakceptować wartości Agile Manifesto. Jeśli klienci nie akceptują zwinności i nadal wymagają sztywnych umów i minimalnej współpracy, nie używaj zwinności lub znajdź lepszych klientów.

To wina klienta, że ​​są uwięzieni w bańce kontraktowej dzięki rozwojowi opartemu na terminach.

Euforyk
źródło
9
@RubberDuck Nie opracowano jeszcze metodologii zarządzania projektami oprogramowania, która umożliwia określenie funkcji z góry, ustalenie terminu i nie była strasznie droga. Zakres, czas, pieniądze; Wybierz dwa.
Euforia
8
@RubberDuck: Projekt nie jest już zwinny, ponieważ wymagania są określone w kamieniu. Szacuje się, że to tylko trzy tygodnie. Nie ma nic magicznie złego w wodospadzie, który sprawia, że ​​zawsze jest późno, po prostu nie może poradzić sobie z niejasnymi wymaganiami i zmianami. Tak, w tym przypadku użyłbym „wodospadu”, a ściślej „zdecyduj, co należy zrobić i zrób to”.
RemcoGerlich,
3
@RemcoGerlich jak na ironię: „zdecydujmy, co należy zrobić i zróbmy to”, jest niezwykle zwinny :-)
gbjbaanb
2
@RemcoGerlich ah, myślę, że źle zrozumiałeś mój punkt widzenia: w tym zwinnym nie chodzi tak naprawdę o metody deweloperskie, ale o umiejętność radzenia sobie z pracą przy użyciu dowolnych środków. W końcu chodzi o postęp, a nie procedury. (np. zespół, który robi tylko Scrum, nie jest zwinny, zespół, który tylko dostosowuje styl wodospadu, ale dostosowuje go do okoliczności, jest)
gbjbaanb
2
Zgadzam się z Doc Brown tutaj. Możesz absolutnie mieć „limit czasu”, nie mówiąc dokładnie „za co”. Na przykład całkowicie rozsądne jest powiedzenie: „Nasz termin to <jakaś data>. W tym dniu wyślemy to, co zrobiliśmy”. Zakres dostawy nie musi być ustalony w momencie wyznaczenia terminu. Zwinne opracowywanie polega na zarządzaniu zakresem i komunikowaniu postępów w ramach przedziałów czasowych, które w rzeczywistości są własnymi mini-terminami.
Eric King,
15

Kogo winić?

Kierownicy, dział prawny, księgowi - wybierz coś ...

Wiem, że przykład jest nieco wymyślony, ale fakt, że firma mogłaby odejść, nie płacąc ani grosza, gdyby nie byli w 100% usatysfakcjonowani, powinien zadzwonić natychmiastowym dzwonkiem alarmowym, podobnie jak połączenie wodospadu i zwinnego myślenia.

Klienci chcą zjeść ciasto i zjeść je - chętnie przyjmują wodospad, mini-wodospad, zwinny, la-la-land, o ile dostaną produkt X za Y $ według daty Z.

Zwinne programowanie absolutnie wymaga, aby zespół programistów i klient byli na tej samej stronie z metodologicznego punktu widzenia. Myślenie o różnicach kulturowych pojawi się po prostu w modzie jest myśleniem życzeniowym.

Robbie Dee
źródło
12

Projekty informatyczne dotyczą nieznanych ; niektóre z tych niewiadomych są nawet nieznanymi . Co to znaczy?

Weźmy na przykład mostek z zabawkami dla swojej modelki kolejowej. Istnieją wszystkie znane Ci parametry:

  • Wiesz, jak duża jest dolina

  • Znasz materiał gór, ich wysokość, stabilność itp.

  • Wiesz, ile potrzebujesz materiału

  • Wiesz z wcześniejszych „projektów”, ile czasu zajęło ci zbudowanie podobnych rzeczy

Istnieje wiele zmiennych, które wpływają na twoje obliczenia dotyczące inwestowania wolnego czasu i pieniędzy. Ale można bez zastanowienia powiedzieć, czy zakończy się w następny weekend.

Zrób krok dalej:

  • Załóżmy, że nie budujesz mostu dla własnej linii kolejowej, zamiast tego budujesz go dla zupełnie nieznajomego: Twoim zadaniem jest zbudowanie mostu kolejowego między dwiema górami

  • Powiedz, że nie masz prawie żadnych informacji przed modelowym krajobrazem

  • Informacja o krajobrazie jest taka, że ​​ma dwie góry, które wydają się niezbyt duże

  • Konsystencja góry jest między skałą a galaretą

  • Całkowity koszt wynosi maksymalnie 10 $

  • Miejsce pracy jest całkowicie ciemne i nie ma szans na światło: masz tylko pudełko z 8 zapałkami

  • Termin wynosi 3 godziny

To byłaby analogia do projektu informatycznego. Masz doświadczenie w budowaniu mostów i łatwo chodzić po znanym terenie. To, co utrudnia, to ciemność . Jest wiele rzeczy, których trudno przewidzieć: Miary gór są znane dopiero po pewnym czasie w ciemności. Podobnie jest z konsystencją gór. Na tej podstawie możesz oszacować, ile czasu to zajmie i ile to będzie kosztować. Tutaj nieznane są rzeczy, których nie znasz na początku projektu, takie jak konkretny teren itp. Ale są rzeczy, których nie możesz przewidzieć, nawet przy największym doświadczeniu i najbardziej konserwatywnych szacunkach. Te rzeczy to nieznane niewiadome, które niosą ze sobą trochę chaosu.

Każda firma IT powinna to wiedzieć. Muszą poradzić sobie z ryzykiem projektu.

1) Istnieje kilka sposobów zminimalizowania ryzyka (finansowego): umowa może obejmować to, że klient płaci za każdy przyrost roboczy. Po dostarczeniu przyrostu 1 należy uiścić stawkę częściową. Dopóki Scrum-Addicts LLC zapewnia, ryzyko finansowe jest minimalne. Im więcej precyzyjnych celów sprintu jest planowanych, tym mniejsze jest całkowite ryzyko każdego sprintu. Oznacza to, że jeśli firma Money-Bags Corporation otrzyma 80% kontraktu, powinna zapłacić co najmniej 80% wartości kontraktu. Jeśli odmówili zapłaty po nieudanym sprincie, ryzyko nie jest tak wysokie, jak odmowa zapłaty 100%.

2) Scrum-Addicts LLC ma problem ze swoimi programistami

Menedżerowie Scrum-Addicts konsultują się ze swoim zespołem scrum, a zespół twierdzi, że ukończenie wszystkich funkcji zajmie 3 tygodniowe sprinty Menedżer Scrum-Addicts doda 1 tydzień, aby być bezpiecznym, obiecuje wysłać oprogramowanie w ciągu 1 miesiąca i podpisuje umowę z workami pieniędzy

To sugeruje, że a) programiści nie mają doświadczenia ze scrumem lub b) źle wykonują scrum Im dłużej zespoły pracują ze scrumem, tym lepsze są ich oceny. Jeśli zespoły dokonują oszacowań, a menedżer dodaje „bufor” jako „bezpieczeństwo”, wydaje się , że menedżer wie lepiej niż zespół, co jest złym znakiem . Jeśli masz doświadczony zespół, nie ma potrzeby stosowania „bufora menedżera”, zespół uwzględnił to już w oszacowaniu. Chodzi o to, że im więcej sprintów zespół pracował razem, tym bardziej zespół zna swoje mocne i słabe strony i ma pewne wskaźniki pozwalające na realistyczne oszacowania. Oczywiście są - jak już wspomniano - nieznane niewiadomektóre utrudniają oszacowanie; lub przynajmniej nieprecyzyjne. Ale na dłuższą metę szacunki powinny być coraz lepsze.

Kogo winić?

1) Zarządzanie

Jak powiedziano powyżej: ewidentnie występuje błąd w zarządzaniu ryzykiem. Jeśli firma znajduje się na skraju bankructwa, zasługuje na to. Jeśli pracujesz w takiej firmie: wyjdź!

2) Zespół

Nawet jeśli zarządzanie jest całkowicie głupie, zespół powinien był wypowiedzieć się przeciwko takiemu projektowi. Dobry kierownik powinien znać ryzyko; ale dobry programista powinien zwracać uwagę na ryzyko. A przede wszystkim: zespół powinien zgłosić się wcześnie, jeśli coś zawiedzie.

Co należy zrobić?

Teraz: zabierz worki z pieniędzmi do sądu

Na przyszłość: nie zawieraj takich umów

Scrum nie ponosi winy za niepowodzenie w zarządzaniu. Scrum został opracowany na podstawie doświadczeń wielu projektów informatycznych, które zawiodły. Nie może zapobiec niepowodzeniom ani wyleczyć niekompetencji zespołów lub kierownictwa. Podstawową ideą jest:

  • ustrukturyzować sposoby komunikacji (kto z kim rozmawia, o czym)

  • aby zachęcić programistów do wczesnego zgłaszania awarii

  • do dzielenia problemów w zadaniach i podzadaniach

  • ustrukturyzować czas i zdolności (kto pracuje, kiedy na czym)

  • aby rozdzielić zadania między przedziały czasowe

  • uczynić nieprzewidywalnym nieco bardziej przewidywalnym (planowanie pokera)

lub ogólnie: w celu zminimalizowania ryzyka.

Scrum to narzędzie jak młot. To, czy jest to dobre narzędzie, zależy od Twojej wiedzy, jak go używać. Ale czasami śrubokręt pasuje lepiej. To zależy od Ciebie.

Thomas Junk
źródło
1
Jest jeszcze jeden aspekt Scrum, który jest niezwykle ważny dla zrozumienia, dlaczego ten projekt się nie powiódł: scrum obejmuje porażkę . Oczekuje się, że pierwsza para sprintu nowego zespołu lub projektu zawiedzie. Dzięki procesowi mijania retrospekcji zespół poprawi się i na dłuższą metę stanie się dokładny w swoich szacunkach, ale tylko o ile pozostanie tym samym zespołem pracującym nad tym samym projektem. Kiedy którakolwiek z tych zmian się zmieni, należy ponownie spodziewać się niepowodzenia, ponieważ zmienne leżące u ich podstaw zmieniają się.
Cronax
9

Po pierwsze: „Kto jest winien?” to złe pytanie, które należy zadać. Przypisywanie winy jest fajne i prawdopodobnie sprawi, że wszyscy oprócz osoby obwinianej poczują ulgę (w sensie „hej, to nie moja wina, szef tak powiedział!”), Ale nie jest to produktywne wykorzystanie twojego czasu i może faktycznie przynieść efekt przeciwny do zamierzonego i spowodować spadek morale pracowników.

Lepszym sposobem na to jest „Co spowodowało opóźnienie?”. Czy był to brak doświadczenia w technologii? Krytyczne błędy, które nie zostały wykryte podczas testowania / kontroli jakości? Brak testowania / kontroli jakości? Zbyt optymistycznie w ocenie? Nie biorąc pod uwagę niezbyt optymistycznych szacunków zespołu? Ktoś został potrącony przez autobus? Bez względu na przyczynę, następne pytanie brzmi: „Jak upewnić się, że to się więcej nie powtórzy?”. W niektórych (miejmy nadzieję rzadkich) przypadkach odpowiedzią na to może być „pozbyć się takiego a takiego”, ale jeśli zaczniesz od „Muszę ukarać tego, kto jest odpowiedzialny”, prawdopodobnie nie zobaczysz większości przypadków gdzie nie jest to właściwe rozwiązanie.

W ramach projektu jesteś już zatopiony. Termin nadszedł i minął, ostrzegłeś klienta, gdy tylko stało się oczywiste, że się poślizgnie (bo zrobiłeś to, prawda? Jeśli nie, to część problemu), a teraz trzeba sobie z tym poradzić, bez względu na to, jak to napisano w umowie (tak naprawdę jest to określone w umowie, prawda?). Ogólnie rzecz biorąc, powinno to obejmować negocjacje z klientem, w jaki sposób zamierzasz dostarczyć to, czego brakuje. Wiele osób lubi myśleć o umowie jako o czymś, czego nie można zmienić, ale musi zmierzyć się z: a) zerwaniem umowy i nie posiadaniem tego, co kupiłeś, b) pozwaniem firmy za naruszenie umowy i wydawaniem dużych pieniędzy w sądzie, oraz c) negocjując, w jaki sposób uzyskać produkt przy jak najmniejszym możliwym problemie, większość firm wybiera c.

Patrząc w przyszłość, przed podaniem klientowi ceny / terminu należy przeanalizować ryzyko związane z przesuniętym terminem lub przekroczeniem kosztów (jakie są możliwe przyczyny? Jakie przyczyny można w jakiś sposób złagodzić, a których nie można i po prostu trzeba zaplanować) i wykorzystać te informacje, aby pomóc zdecydować, co zamierzasz obiecać. Jeśli jest to przypadek, w którym jest to 100% lub nic, oczywiście podasz wyższe ceny i dłuższe terminy, ponieważ ryzyko jest wyższe.

Zauważysz, że nie mówiłem o Agile w tej całej odpowiedzi. To dlatego, że (zamierzam na chwilę zapomnieć o zaangażowaniu klienta w Scrum, chociaż jest to bardzo, bardzo ważne) w tym momencie tak naprawdę nie ma to znaczenia. Ten problem napotkasz w Agile, Waterfall lub dowolnym innym procesie rozwoju. Tak, Agile ma pomóc ci lepiej zarządzać ryzykiem, pozwalając ci zobaczyć, czy wcześniej stały się rzeczywistymi problemami, i angażować klienta w sam proces, aby zawsze był informowany, ale to nie jest panaceum.

Iker
źródło
3
-1 Zwrotność polega na tym, że wielu zagrożeń po prostu nie można przewidzieć. Na przykład dodali bufor tygodniowy na wypadek, gdyby sytuacja się potknęła. Zawsze możesz potroić potrzebny czas, ale przegrywasz z konkurencją, która tego nie robi. Zwinny powinien przyjąć mentalność „Wykonano, gdy się zakończy”. Co jest po prostu niezgodne z opisanymi umowami i terminami.
Euforyczny
3
@Euphoric Nie mogę się całkowicie zgodzić. Tak, chodzi o to, że zwinne jest to, że nie można przewidzieć wielu zagrożeń, i do tego właśnie służy bufor, dam ci to. Nie oznacza to jednak, że wszystkie ryzyka są nieprzewidywalne, ani nie oznacza, że ​​powinieneś wejść w projekt w ciemno, nie biorąc pod uwagę ryzyk, które możesz przewidzieć.
Iker
2
@Iker Ten jeden nie wyklucza drugiego, ale prawdziwą zwinnością w procesie programowania jest to, że zarówno klient, jak i zespół mają mentalność „Zrobione, gdy jest zrobione”. Jasne, zawsze istnieje pewne ryzyko, które możesz przewidzieć, ale nigdy nie możesz z powodzeniem przewidzieć wszystkich możliwych zagrożeń i dokładnie, jaki będą one miały wpływ na twoje postępy. Chyba że jakoś zobaczysz przyszłość. Właśnie dlatego zwinna praca wymaga konkretnych umów, w których zgadzasz się, że „będziemy kontynuować pracę, dopóki pieniądze się nie wyczerpią, albo żadna ze stron nie będzie już chętna lub nie będzie w stanie tego zrobić, lub wszystkie potrzeby klientów zostaną spełnione”
Cronax
ok, głosowałem za natychmiastowym odrzuceniem winy jako koncepcji. Zgadzam się, że wina jest nieproduktywnym elementem odwracającym uwagę od sukcesu. Zmieńmy pytanie. Może moglibyśmy sprawić, że „jak moglibyśmy sobie z tym poradzić”? „jak możemy uczynić z tego sukces?” „jakie zmiany od każdej ze stron mogły przynieść pozytywne rezultaty?” Mogę być w stanie zmienić „winę” na „odpowiedzialną”, ale ponieważ każdy projekt z dostawcą i klientem jest interakcją w zespole, czy i tak cały globalny „zespół” nie jest odpowiedzialny? pytanie, kto jest winny, staje się następnie retoryczne.
Joshua K
4

Po pierwsze, jest to problem związany z każdą metodologią programowania. Przynajmniej z iteracyjnym systemem programistycznym masz coś do pokazania klientowi pod koniec terminu, co może być wystarczające, aby uzyskać rozszerzenie w celu ukończenia produktu (nawet jeśli klient nie płaci więcej!).

Są jednak przypadki, w których termin jest ostateczny, wyobraź sobie, że piszesz grę i absolutnie musi ona zostać wydana na czas świąt Bożego Narodzenia. Zrozumienie tego doprowadziło wiele firm do bankructwa!

W przypadku metod zwinnych, które muszą ukończyć określoną liczbę funkcji do określonej daty, scrum prawdopodobnie nie jest najlepszą metodą do użycia (jak zawsze zauważyłem, że scrum spowalnia programowanie i nie pozwala na wystarczającą zwinność, aby zmienić proces, gdy potrzebne.

Niezależnie od metodologii potrzebne jest skonfigurowanie zaległości wymaganych funkcji, aby zapewnić widoczność postępu. Postępy na zasadzie sprintu nie są wystarczająco dobre, nie będziesz wiedział, czy osiągasz ostateczny cel. Tak więc lepsza byłaby metodologia w stylu Kanban: ustaw wszystkie funkcje po lewej stronie i przeprowadź je przez system, aby pokazać postępy do końca.

To skupia ludzkie myśli na tym, co wciąż musi być zrobione w sposób, którego Scrum nie obsługuje, i pozwala osobom innym niż zespół deweloperów zobaczyć, co pozostało i czy prawdopodobnie uda ci się osiągnąć cel (a tym samym wcześnie zarządzać oczekiwaniami klienta lub zorganizuj te premie za nadgodziny, zanim będą potrzebne).

Scrum to system, który działa na zawsze, nieustannie definiując i udoskonalając coś. Po prostu nie nadaje się do tego rodzaju rozwoju. Inni mogą zarządzać tym systemem i nadal utrzymywać iteracyjną koncepcję rozwoju, Kanban jest taki, a Crystal inny. Ale najważniejsze jest, aby zrozumieć, że jeśli podążasz religijnie za Scrumem, nie jesteś zwinny. Każdy prawdziwy system Agile powinien być w stanie zmienić się, aby poradzić sobie z tymi konkretnymi problemami, dlatego nazywa się go zwinnym, chodzi o to, aby zrobić to, co należy zrobić, a jeśli określony termin jest częścią tego, powinieneś uwzględnij to w swoim sposobie pracy.

gbjbaanb
źródło
6
„Gra gotowa na święta” może być plakatem dla Scruma. Wyślij 80%, które ukończyłeś, resztę sprzedaj jako DLC. Nie taka hipotetyczna sytuacja tutaj omówiona, w której termin ustalono zarówno czas, jak i zakres, ze 100% karą za częściową dostawę.
MSalters
2
@MSalters zakładasz, że gra w ogóle działa, że ​​80% może nie brakować funkcji, które można dodać później, ale zepsuje funkcjonalność lub powoduje awarie. To nie musi być gra, może to być dowolne oprogramowanie, które musi zostać dostarczone na czas określony i niezmienny (ponieważ nawet Apple nie może odłożyć Świąt Bożego Narodzenia!)
gbjbaanb
6
To podstawowa przesłanka Scrum! Uszkodzona funkcjonalność się nie liczy. Jeśli pochodzisz z Wodospadu, przekonasz się, że Scrum ma pierwszeństwo przed naprawą błędów przed dodaniem nowych funkcji. „
Wykonano
1
@gbjbaanb Zgodnie z tym rozumowaniem coś można zrobić w 99,9%, ale nadal nie działa, ponieważ ulega awarii natychmiast po uruchomieniu.
immibis
@immibis, ale to prawda. Rzeczy takie jak gry nie wykluczają funkcji do końca, większość części gry musi być zaimplementowana, aby całość działała - chociaż możesz wyjąć niektóre funkcje (i wiem, że gry, które to zrobiły) nie dodają funkcje przyrostowe. Zatem brakujący boss byłby zepsutą grą. Wybrałem tylko gry jako przykład, ponieważ mają one tendencję (szczególnie przed dostawą przez Internet) jako przykłady trudnych terminów.
gbjbaanb
4

Paradygmat programowania nie jest zsynchronizowany z paradygmatem kontraktów. Najlepiej byłoby, gdyby sposób pisania umów zmieniłby się, ale jest to mało prawdopodobne. Jednak nawet jeśli zrzucisz scrum, nadal będziesz mieć niespodzianki i spóźnione terminy (tylko prawdopodobnie będziesz znacznie później, ponieważ zrobiłeś cały ten projekt z góry i wszystko było źle!).

Ze zmianą sposobu pisania umów lub bez niej, wysyłasz to, co już pracujesz . Następnie wypełnij umowę, jedząc cykl prac rozwojowych, aby dokończyć funkcje, których nie wykonałeś.

Czy to dobrze, że nie dotrzymałeś wszystkiego, co obiecałeś w dniu, który obiecałeś? Nie, ale twój klient będzie znacznie szczęśliwszy, jeśli możesz dostarczyć coś, co działa na czas, a następnie dostarczyć resztę szybko po tym, niż jeśli spóźnisz się i nie będziesz miał nic do zaoferowania.

Gumowa kaczuszka
źródło
3
Tak, czasami klient jest szczęśliwszy, jeśli zespół zapewnia przynajmniej część funkcji roboczych, ale nie zawsze tak jest. Mówię o przypadkach, w których (1) produkt jest bezużyteczny dla użytkowników końcowych, chyba że wdrożono 100% funkcji (na przykład wymaga drogiej certyfikacji, którą należy wykonać dopiero po zakończeniu wszystkiego) lub (2) klienta to oldschoolowa firma z podejściem „wszystko albo nic”: jeśli produkt nie jest w 100% gotowy, uważamy, że to nie powiodło się, zerwanie umowy i zwolnienie wszystkich odpowiedzialnych.
Andre Borges,
2
Klient zawsze będzie szczęśliwszy, widząc postępy w działającym oprogramowaniu. Drogie certyfikaty mogą poczekać, aż produkt spełni ich oczekiwania. Wydanie go klientowi nie oznacza, że ​​musi go udostępnić publicznie. W przypadku 2 tak naprawdę nie ma innej opcji, jak tylko pozwolić swoim zespołom prawnym / sprzedaży pisać lepsze umowy. Szczerze mówiąc, twoje problemy byłyby takie same, jeśli nie gorsze, z wodospadem.
RubberDuck,
2
@AndreBorges Z pewnością klient będzie szczęśliwszy widząc 80% funkcji niż 0% funkcji? Przynajmniej w ten sposób klient wie, że produkt jest w większości gotowy.
immibis
@immibis, jeśli tak mówisz, oznacza to, że byłeś wystarczająco szczęśliwy, aby uniknąć niektórych „osobliwych” klientów w swojej pracy. Istnieją wielkie, nieporadne korporacje rządowe, które egzekwują niezbyt rozsądne warunki umowne, ale jeśli zainwestujesz wszystkie swoje zasoby w swoje zadanie i odniesiesz sukces, płacą poważne pieniądze, które mogą podnieść Twoją małą firmę na wyżyny. Jeśli jednak ci się nie uda, możesz znaleźć nową pracę. Istnieje ryzyko, że niektórzy ludzie są skłonni podjąć.
Andre Borges
2
Dokładnie! Ze względu na wewnętrzną biurokrację i brak doświadczonej kadry kierowniczej czasami dużej firmie łatwiej jest uznać nieudany termin za „nieudany eksperyment” i całkowicie porzucić projekt, niż włożyć wysiłek w komunikację i renegocjację zakresu. Smutne, ale prawdziwe :(
Andre Borges
1

Wiele książek i artykułów Scruma mówi, że nieudany sprint (gdy zespół nie ukończy niektórych funkcji z rejestru Sprint) nie jest taki zły, zdarza się od czasu do czasu i może być naprawdę przydatny, jeśli zespół uczy się na swoich błędach i poprawia coś w następujących sprintach. Zespół nie powinien być karany za niedokończenie pracy, do której się zobowiązali.

Sposób „karania” tego rodzaju zachowań polega na ograniczeniu ilości pracy, którą ci, którzy nie ukończyli, mogą podjąć kolejny sprint. Szanse na pracę nad fajnymi rzeczami znikają. Nagrodą za dobrą pracę jest więcej pracy.

Wygląda to świetnie z punktu widzenia dewelopera, powiedzmy jednak, że mamy firmę programistyczną „Scrum-Addicts LLC”, która opracowuje coś dla poważnych klientów („Money-Bags Corporation”):

Menedżerowie Scrum-Addicts sugerują stworzenie oprogramowania dla Money-Bagów. Uzgodnili listę funkcji, a Money-Bags prosi o podanie terminu wysyłki. Menedżerowie Scrum-Addicts konsultują się ze swoim zespołem scrumowym, a zespół twierdzi, że zajmie to 3 tygodnie -długie sprinty, aby ukończyć wszystkie funkcje Menedżer Scrum-Addicts dodaje 1 tydzień dla bezpieczeństwa, obiecuje wysłać oprogramowanie w ciągu 1 miesiąca i podpisuje umowę z Money-Bagiem Po 4 sprintach (termin wysyłki) Zespół Scrum może dostarczyć tylko 80% funkcji (z powodu braku doświadczenia w nowym systemie, konieczności naprawy krytycznych błędów w poprzednich funkcjach w środowisku produkcyjnym itp.) Jak sugeruje Scrum, w tym momencie produkt jest potencjalnie dostępny do wysyłki, ale Money-Bag potrzebuje 100% funkcji, jak wspomniano w umowie. Więc łamią umowę i nic nie płacą.

Scrum-Addicts znajduje się na skraju bankructwa, ponieważ nie otrzymali pieniędzy od Money-Bagów, a inwestorzy byli rozczarowani wynikami i nie chcą już dłużej pomagać firmie.

Jeśli w poniedziałek założę się o 100 $, że w czwartek będzie padać i nie pada aż do piątku, to będziesz miał prawo wziąć moje pieniądze. Jeśli zamiast szansy na hazard, potrzebujesz prognozy pogody, potrzebujemy umowy, która pozwoli mi przedstawić ci zaktualizowaną prognozę we wtorek.

Oczywiście żadna firma programistyczna nie chce być w butach Scrum-Addicts. To, czego nie rozumiem w Agile i Scrum, to to, jak sugerują zespołom radzenie sobie z planowaniem i terminami, aby uniknąć sytuacji opisanej powyżej.

Zastanów się, DLACZEGO MB chce wziąć piłkę i wrócić do domu. MB na początku nie wymagało pracy w miesiąc. SA obiecała 100% najważniejszych funkcji w ciągu jednego miesiąca i nie dostarczyła. SA wyznaczyła termin nie MB. SA nawet arbitralnie dodał tydzień do terminu. Dlaczego to termin?

Czasami, gdy konkurują o oprogramowanie, firmy ulegają pokusie popisania się i obiecania księżycowi. Specjaliści ostrożnie ustalają, czy księżyc jest w ogóle potrzebny. Jakie jest najbardziej krytyczne zapotrzebowanie na MoneyBags? 100% funkcji lub działającego produktu w ciągu miesiąca? Czy w ogóle wiedzą, co jest naprawdę ważne? Czy jakieś nadchodzące wydarzenie wyznacza trudny termin?

Gdybym był uzależnionym od Scrum-a negocjującym tę umowę, chciałbym dowiedzieć się znacznie więcej o potrzebach biznesowych Money-Bagów i nadać jej strukturę, aby zapewnić tyle elastyczności, na ile Money-Bags czuje się swobodnie. Nauczę ich, jak działa zwinny proces, aby wiedzieli, czego się od nas spodziewać.

W ten sposób, zamiast oczekiwać, że wszystko nagle zadziała idealnie w ciągu miesiąca, oczekują, że ocenią pierwszą dostawę za 1-2 tygodnie.

Podsumowując, mam 2 pytania:

Kogo winić? Menedżerowie, ponieważ ich zadaniem jest właściwe planowanie
Zespół, ponieważ zobowiązali się do wykonania większej ilości pracy niż mogliby
Ktoś inny

Każdy mógł zatrzymać tę parodię, zanim miniemy miesiąc.

Mogłem posunąć się nawet do obwiniania Money-Bags Corp za zatrudnienie zespołu, który najwyraźniej oszukańczo przedstawiał proces wodospadu jako zwinny. Sama umowa wyjaśnia, że ​​nie jest zwinny. Planowanie do wykonania za miesiąc nie czyni go zwinnym.

Jeśli upierasz się, że jest zwinny, jest zwinny z jednym sprintem trwającym miesiąc. Którego tak, nie poleciłbym, bo to znowu to samo, co wodospad.

Co należy zrobić?

Co powiesz na zwinny? Dostarczać coś każdego sprintu? Uzyskaj informację zwrotną przed upływem terminu? Tygodniowe sprinty? Co powiesz na renegocjację smokowskiego kontraktu w chwili, gdy podejrzewasz, że termin jest w niebezpieczeństwie, zamiast ukrywać się i modlić? Przynajmniej możesz przestać marnować czas na skazany na porażkę projekt i znaleźć bardziej rozsądnego klienta.

Menedżerowie powinni przesunąć termin 2x (lub 3x) razy później niż szacuje zespół pierwotny.

Mnożniki terminów są tak samo przydatne, jak ustawienie zegarka 15 minut wcześniej, więc nigdy się nie spóźnisz. Możesz oszukać się tak długo, zanim zdasz sobie sprawę z tego, co zamierzasz.

Wczesne szacunki są błędne. Spróbuj uchwycić, jak źle. 5 tygodni, daj lub weź kilka tygodni to proste wyrażenie, które pozwala wyrazić, jak niepewna jest naprawdę data ukończenia. Zamiast próbować odgadnąć dokładnie, zgadujesz, jak dzikie są twoje przypuszczenia. Wykonaj prawdziwą pracę i uzyskaj prawdziwe dane. Następnie możesz rozpocząć szacowanie z węższym zakresem. Jeden do dwóch tygodni to dużo czasu, aby to zrobić.

Członkowie zespołu powinni być zachęcani do wykonywania wszystkich prac, do których się zobowiązali bez względu na wszystko (poprzez nakładanie kar za nieudane sprinty)

Członkowie zespołu powinni być zachęcani. Niepowodzenie, popełnienie lub w inny sposób. Zamiast budować jakiekolwiek sztuczne konsekwencje, takie jak kary, a nawet premie (marchewki i kijki), badania wykazały, że ludzie wykonujący twórczą pracę, taką jak programowanie, reagują najlepiej, jeśli zapewniają trzy rzeczy: autonomię, mistrzostwo i cel.

Daniel Pink ma na ten temat wykład TED . Dyskusja dotyczy motywacji, która nie jest zwinna, ale łatwo zrozumiałem, jak zmapować te punkty do zwinnych:

Autonomia - chcę kierować własnym życiem - pozwól mi wybrać pracę z zaległości.
Mistrzostwo - chcę być lepszy w czymś, co ważne - opinie klientów.
Cel - chcę być częścią czegoś większego niż ja - zespół współpracujący.

Zespół powinien upuścić Scruma, ponieważ nie pasuje to do polityki terminów firmy Scrum może trafić w termin dokładniej niż wodospad. Podany termin scrum może go dotrzymać. Może on spełniać tylko 1 z 47 funkcji w zależności od czasu, funkcji i umiejętności, ale może go spełnić.

Zwinny projekt może być tak zaprojektowany, że każdej nocy, gdy zespół wraca do domu, jest gotowy do wysyłki. Wydaje się to głupie, chyba że myślisz o wysyłce jako proszeniu klienta o przetestowanie i przekazanie opinii. Im szybciej to nastąpi, tym szybciej można wprowadzić zmiany. To dotyka każdego możliwego terminu. Po prostu nie każda funkcja. Ale kieruje Cię do funkcji, które mają znaczenie.

Wszyscy powinniśmy porzucić rozwój oprogramowania i dołączyć do klasztoru

Tak, jak zamknięcie mnie w pokoju z dala od prawdziwego życia sprawi, że napiszę MNIEJ kodu.

Zredagowałem tę odpowiedź do rozmiarów. Jeśli jesteś ciekawy, przeczytaj historię edycji.

candied_orange
źródło
Chciałbym tylko założyć, że miałeś na myśli sprint, a nie zaległości - miałem na myśli dokładnie to, co napisałem w pytaniu: zaległość sprintu
Andre Borges
ludzie wykonujący pracę twórczą, taką jak programowanie, reagują najlepiej, jeśli podają trzy rzeczy: autonomię, mistrzostwo i cel - może to być sam w sobie ogromny temat do spekulacji, ale faktem jest, że niestety wiele pracy programistycznej staje się mniej kreatywne i bardziej rutyna (nudne zadania, ustalone stosy technologii i zestawy fetyszy, ścisłe umowy). Dlatego w wielu przypadkach marchew i kij działają dobrze.
Andre Borges
@AndreBorges Masz rację, myślałem o zaległościach produktu. Ostatnio pracuję z narzędziem, które nazywa rejestr zaległości sprintu, a zaległości produktu. Przyłapałeś mnie na przegranej walce o to, by moje słownictwo nie stało się prawnie zastrzeżone.
candied_orange
Programowanie @AndreBorges nigdy nie będzie upychaniem kopert. To zdecydowanie problem świecy. Powodem jest to, że każdy powtarzający się problem można rozwiązać za pomocą tego samego kodu, który rozwiązał pierwszy problem. Pomimo tego kierownictwo może wpaść w sposób myślenia, w którym uważają, że kreatywność jest problemem, który należy wyeliminować. Pracowałem dla kilku takich sklepów i biegałem z nimi. Nie zatrzymują dobrych ludzi. Nie produkują dobrego oprogramowania. Deweloperzy to rzemieślnicy. Próba przekształcenia ich w pracowników linii montażowej tylko boli twoją sprawę. Moim zadaniem nie jest przewracanie jaj. Ma to na celu odwrócenie jaj.
candied_orange
0

Wszyscy muszą być zwinni. Cokolwiek zdecydujesz, będzie wyglądać, kto robi co, jak, kiedy, gdzie i dlaczego przez wszystkie strony. Zwinni klienci, zarządcy i programiści.

Nie możesz podać daty wysyłki zbyt daleko w przyszłości. Dajesz szacunek.

Ktoś musiał zarządzać oczekiwaniami klienta. Powodem, dla którego nie martwisz się zbytnio kilkoma sprintami, jest dostosowanie się, aby zapobiec opóźnieniu całego projektu. Jeśli po sprincie dojdzie do wniosku, że nie skończysz, dotrzymaj „terminu wysyłki”, wtedy powiesz klientowi.

Co teraz chcesz zrobić? Pozbądź się niepotrzebnych funkcji lub przenieś datę. Gdybyś mógł dostarczyć na czas, zrobiłbyś to. Nie wahaj się przynieść złych wieści.

Kto wie, przy niektórych projektach możesz wysłać wcześniej.

Nie możesz być zwinny, jeśli klient tego nie chce.

JeffO
źródło
0

Cel

Uważam, że następujące dwie „wskaźniki” powinny stanowić podstawę każdej decyzji biznesowej:

  • czy praca jest opłacalna (dla klienta)
  • czy pracujemy tak wydajnie, jak to możliwe

Są to dość uniwersalne. Oczywiście bardzo szybko się komplikuje, na przykład opłacalność pracy polega na tym, że produkt robi coś dobrego, użytkownik może korzystać z produktu, produkt jest sprzedawany poprawnie itp. - dla wielu z tych „ uzależnionych od ScrumaLLC ”nie ponosi odpowiedzialności.

Kwestia

Umowa nie koncentruje się na celach opisanych powyżej. Istnieje klauzula „wszystko albo nic” - załatw wszystko i zarabiaj, lub nie rób nic i nie zarabiaj. Nie dotyczy to jednak bezpośrednio tworzonej wartości. Kolejny minus, który następuje: teraz musimy poświęcić czas i pieniądze, aby zapewnić i sprawdzić, czy umowa jest przestrzegana. Dlaczego, u licha, chcielibyśmy wydawać te pieniądze? W jaki sposób upewnienie się, że umowa jest spełniona, pomaga w międzyczasie, gdy wymagania ulegną zmianie i dowiedzieliśmy się, że zamówione oprogramowanie nie tworzy żadnej wartości? Po prostu marnuje się więcej pieniędzy! Oczywiście istnieje powód takiego zachowania:

  • Kulturowo jesteśmy przyzwyczajeni do robienia takich rzeczy. Oczekujemy, że kupimy oprogramowanie tak, jak zrobilibyśmy samochód: wybierz konfigurację, otrzymaj cenę i termin i bądź bardzo niezadowolony, jeśli nie zostaną spełnione.
  • chcemy odciążyć ryzyko i odpowiedzialność
  • chcemy stabilności, pomaga w planowaniu i poprawia samopoczucie (a także naszego klienta, co jest ważnym aspektem!)

Pod koniec dnia będziemy musieli wybrać kompromis, który pozwoli nam osiągnąć nasze cele tak dobrze, jak to możliwe.

Tak to powinno działać

  • mieć umowę na usługi i pracę zamiast na produkt
    • musi zostać rozwiązane w stosunkowo krótkim czasie
  • ściśle współpracują ze sobą, aby zapewnić optymalną wydajność
  • angażują wszystkie niezbędne strony, zarówno z „ Scrum-Addits LLC ”, jak i „ Money-Bags Corporation ” - „pojedynczego punktu kontaktowego” tunelującego wszystkie informacje tutaj nie zadziałają

cóż, po prostu powiedziałem „bądź zwinny”. Oto dlaczego:

  • Proces i umowa są zoptymalizowane, aby wydać tyle pieniędzy na cel , jak to możliwe
  • musisz zaufać kontrahentowi, że wykona swoją pracę, i nie będziesz musiał inwestować dużo pieniędzy, aby sprawdzić, czy jest gotowy do pracy.
  • możliwość pozwania kontrahenta, jeśli twoje oczekiwania / umowa nie są spełnione, zwykle nie pomaga, ponieważ zrobienie tego będzie kosztować więcej niż samo porzucenie. Niektóre z głównych obaw dotyczą czasu wprowadzenia na rynek. Najprawdopodobniej stracisz znacznie więcej pieniędzy / biznesu, idąc do sądu, niż dostaniesz.
    • pod koniec dnia będziesz musiał sam ponieść pewne ryzyko.
BatteryBackupUnit
źródło