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