Czy ustalony zakres + ustalony termin + umowa o stałej cenie może kiedykolwiek zostać dostosowana do „zwinnej”?

Niektóre projekty, które realizujemy wewnętrznie, to Scrum, a jednocześnie „wszystko naprawia” dla klienta. Z naszej strony mamy mieszany sukces (klientowi podoba się widoczność wykresu wypalenia). Czy typy projektów, które pracujemy, mogą być z powodzeniem realizowane przy użyciu zwinnych metod?

Cóż, pracowałem głównie w „zwinnych” środowiskach (chociaż nie używamy żargonu) i robiłem rzeczy o stałych kosztach. Ogólnie rzecz biorąc, oznacza to koszty plus, ponieważ żadna firma nie może sobie pozwolić na zrobienie wszystkiego za darmo, a wymagania zmieniają się i ewoluują, gdy klient bardziej precyzyjnie określa, czego chce.

Wstępne wymagania dotyczące części kosztów stałych muszą być wykonane znacznie ostrożniej niż w typowym środowisku iteracyjnym, co czyni proces nieco mniej iteracyjnym. „Dodatkowa” część umowy może być bardziej iteracyjna, pod warunkiem, że część kosztów stałych zrealizowaliśmy mniej lub bardziej zadowalająco dla klienta.

Chciałbym zadać pytanie przeciwne:

Czy ustalony zakres + ustalony termin + stała umowa mogą kiedykolwiek zostać wprowadzone w życie, okres ?

Powiedzenie „dobry / szybki / tani - wybierz dwa” to nie tylko głupi żart z inżynierii. Każdy kierownik projektu wart swojej soli wie o trójkącie zarządzania projektami :

Mówisz nam, że koszty, zakres i harmonogram są stałe. To nie pozostawia miejsca na zwrotność lub błąd. Żaden . Możesz wybrać wyświetlanie „Jakości” jako atrybutu, ale nie jest to atrybut „rzeczywisty”, bardziej przypomina meta-atrybut pochodzący z innych atrybutów (koszt / zakres / harmonogram).

Problem polega na tym, że tak naprawdę nigdy tak się nie dzieje, dopóki twój projekt jest planowany i realizowany przez ludzi.

• Wymagania i specyfikacje nigdy nie obejmują każdego przypadku na krawędzi, chyba że zostały opracowane bardzo szczegółowo przez wykwalifikowanych architektów i projektantów, w którym to przypadku projekt jest już w połowie ukończony; i nawet wtedy istnieje możliwość błędu.

• Pojawią się nieoczekiwane koszty prowadzące do przekroczenia budżetu. Subskrypcja wygasła. Producent przestał obsługiwać produkt, którego używasz, i musisz znaleźć nowy. Godzinny kontrahent podniósł stawkę pod groźbą odejścia. Twój cały zespół właśnie rozpoczął strajk, żądając podwyżki o 10% i dodatkowego tygodnia wakacji.

• Plany poślizgu. Pojawiają się nieprzewidziane problemy; ten składnik wykresów, z którego korzystasz przez 5 lat, nie jest zgodny z systemem Windows 95, z którego nadal korzysta Twój klient. Niejasny błąd w 64-bitowym systemie Windows powoduje poważne usterki interfejsu użytkownika, a Ty spędzasz prawie tydzień na jego śledzeniu i opracowywaniu obejścia (tak się naprawdę stało). Twój starszy programista został potrącony przez autobus i musisz rekrutować i szkolić nowego. Szacowana data dostawy jest zawsze nieprawidłowa. Zawsze.

  Zobacz prawo Hofstadtera :

  Prawo Hofstadtera: zawsze trwa dłużej, niż się spodziewasz, nawet jeśli weźmiesz pod uwagę prawo Hofstadtera.

Metody zwinne polegają na żonglowaniu kosztami, harmonogramem i zakresem. Przez większość czasu chodzi przede wszystkim o żonglerkę wokół zakresu, a czasem harmonogramu , dlatego zaczynasz od mglistych historii użytkowników i planujesz zmiany zamiast pełnych wersji. Różne metodologie wykorzystują inną terminologię, ale jest to ta sama podstawowa przesłanka: częste wersje i ponowne równoważenie harmonogramu i zakresu z każdą wersją.

Nie ma to sensu w przypadku projektu, który ma (lub twierdzi, że jest) albo stały zakres, albo stały harmonogram.

Gdyby jeden atrybut projektu (koszt / zakres / harmonogram) został naprawiony, powiedziałbym, że może nie być dobrze dopasowany do zwinnych metodologii.

Jeśli dwa atrybuty projektu są ustalone, Twój projekt zdecydowanie nie pasuje do zwinnych metodologii.

Jeśli wszystkie trzy atrybuty zostaną naprawione, prawdopodobnie projekt zawiedzie. Jeśli faktycznie zostanie wysłany, to albo pierwotny harmonogram został masowo przerobiony, albo klientowi udało się oszukać, że rzeczywiście dostarczyłeś to, co obiecano.

Jeśli ta umowa nadal obowiązuje, wzywam do jej odrzucenia. A jeśli już to zaakceptowałeś, niech Bóg zlituje się nad twoją duszą.

Uwielbiam ten cytat:

„Scrum doskonale nadaje się do zmiennej daty o ustalonej dacie lub„ stałej o zasięgu ”(która zawsze rośnie) o zmiennej dacie. Jeśli pracujesz w określonym terminie, polecam wodospad lub RUP, który kupi ci kilka miesięcy na znalezienie nowej pracy. ”~ Michael James

Jasne, o ile pasek jakości jest utrzymywany na wyjątkowo niskim poziomie. Wierzę w stary żelazny trójkąt „czas dostawy / jakość / cena”, w którym można wybrać dwa, ale potem drugi płynie. Wygląda na to, że ustaliłeś czas dostawy i cenę (a także funkcje), więc naprawdę jedyną rzeczą, która może dać, jest jakość.

To powiedziawszy, jeśli używasz wykresu wypalenia i masz pierwszeństwo wykonania rzeczy w pierwszej kolejności, może być do przyjęcia garść najważniejszych rzeczy wykonanych w określonych ramach czasowych dla określonej kwoty pieniężnej. Przynajmniej twój klient zobaczy, że w pewnym stopniu kontrolujesz proces, z rezultatem na końcu każdej iteracji i będzie mógł powiedzieć, co jest najważniejsze.

W przeciwnym razie uważam, że poświęcenie się ustalonemu czasowi, zestawowi funkcji i cenie jest nierozsądne i doprowadzi do heroicznych wysiłków, których rezultatem będzie niższa jakość i mniejszy w utrzymaniu kod. Zwinny to nie magiczny czarodziejski pył.

Stałą cenę / ustalony termin / ustalony zakres można wykonać co najmniej tak zwinnie, jak w wodospadzie.

W wodospadzie szacunki czasu są niedokładne, a szczegóły są wdrażane inaczej niż w oryginalnych specyfikacjach. Innymi słowy, nie można dokładnie ustalić terminu / zakresu.

W zwinnym możesz wykonać sprint zero, aby wygenerować zaległe historie użytkowników i dokonać pewnych oszacowań. Następnie uzgodnij, że spełnisz wartościowe historie za ustaloną cenę, w ustalonym terminie. Zakres jest ustalony pod względem historycznych wartości, które zamierzasz spełnić, i nie składa się żadnych obietnic dotyczących historii użytkowników.

Innymi słowy, obiecujesz dostarczyć to, co ważne, i unikać obietnic dotyczących konkretnych decyzji projektowych niezwiązanych z przychodami / oszczędnościami itp. który projekt ma dostarczyć.

W pewnym stopniu zgadzam się z Brucem. Chociaż nie znam się zbyt dobrze na wodospadzie lub RUP i dlatego nie mogę tego komentować.

To, co ostatnio czytałem i uważałem za bardzo dobrze powiedziane, to to, że nawet w Agile zaniedbujemy planowanie. Dokładna sesja planowania, gdy iteracja jest świetna - nie, jest niezbędna - ale podobnie planuje się PRZEZ iterację.

Pracuję w branży rozrywkowej, w której ciągle się zmieniają. Zespół potrzebuje pewnej łagodności / elastyczności, która pozwoli mu na „ponowne zaplanowanie” historii w trakcie sprintu, aby dostosować się do nowych lub zmienionych celów.

Podoba mi się pomysł ciągłego planowania, ponieważ zbyt często programiści każą właścicielowi produktu odejść, gdy pracują nad historiami w trakcie sprintu. Jest to doskonałe, jeśli Twój zespół pracuje nad historiami, które są nadal aktualne, a właściciel produktu jest po prostu uciążliwy. Ale w niektórych przypadkach historie stają się zbędne PODCZAS sprintu, a właściciel produktu musi to zauważyć, a zespół musi ponownie dostosować się do zmienionych celów / historii - czy nie o to chodzi w zwinności?