Radzenie sobie z nieudanymi sprintami i terminami

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

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”.

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.

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.

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.

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.

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.

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.

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.

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.

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 Scruma ” LLC ”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.