Klasyczna sytuacja: projekt wystartował z jasnym zakresem i terminem. Po kilku tygodniach jest "prawie gotowy" od trzech tygodni. Zakres urósł, termin minął, relacja z klientem zaczyna skrzypieć. Nie ma jednej przyczyny takich sytuacji, ale są praktyki, które wyraźnie redukują ryzyko.
Zakres w formie listy, nie zdania
Projekt opisany jako "system do obsługi zamówień" jest niemierzalny. Projekt opisany jako lista konkretnych funkcji z kryteriami akceptacji jest mierzalny. Gdy coś "jest zrobione" - sprawdzasz listę. Gdy klient chce dorzucić funkcję - widzisz co to zmienia w zakresie. Rozmyta definicja zakresu to najczęstsza przyczyna rozrostu projektu.
Krótkie iteracje
Iteracja trwająca dwa tygodnie kończy się demonstracją działającego oprogramowania klientowi. Nie raportem, nie prezentacją - działającym kodem. Klient widzi postęp i może komentować zanim projekt pójdzie w złym kierunku. Problemy odkryte po dwóch tygodniach kosztują dużo mniej niż odkryte po trzech miesiącach.
Jeden kanał komunikacji
Ustalenia przez e-mail, decyzje przez Slack, zmiany wymagań przez telefon - i nikt nie wie co jest aktualne. Jeden kanał komunikacji (Jira, Linear, GitHub Issues, cokolwiek) gdzie decyzje są zapisywane sprawia, że historia projektu jest czytelna i łatwa do odtworzenia.
Zmiana zakresu = zmiana terminu lub budżetu
Każda dodatkowa funkcja ma koszt: czas dewelopera, testowanie, dokumentacja. Zmiana zakresu bez zmiany terminu lub budżetu to magiczne myślenie. Dobry projekt ma jasno opisany proces zmiany zakresu: kto może go inicjować, kto akceptuje i co to oznacza dla harmonogramu.
Regularne statusy zamiast raportów ad hoc
Cotygodniowy status w stałym formacie: co zostało zrobione, co jest w toku, co blokuje, co jest planowane na następny tydzień. Krótki, przewidywalny, bez zaskoczeń. Klient, który jest na bieżąco, rzadziej panikuje i rzadziej naciska na zmiany wynikające z niepewności co się dzieje w projekcie.
Definition of Done
Co znaczy że funkcja jest "gotowa"? Kod napisany? Przetestowany? Zaakceptowany przez klienta? Wdrożony na produkcji? Bez wspólnego rozumienia definicji gotowości, każdy ma inną i konflikty są nieuniknione. Ustal to na początku projektu, nie przy próbie zamknięcia pierwszego sprintu.