Odpowiedź.

Wybór metodologii realizacji zależy od wielu parametrów: dojrzałości klienta, stopnia określenia wymagań, możliwości zespołu, krytyczności terminów i budżetu.

• Waterfall stosuje się, gdy wymagania są jasne i stabilne od samego początku, projekt jest ściśle regulowany (np. przetargi rządowe, duże rozwiązania integracyjne dla klientów korporacyjnych).

• Agile wybiera się, jeśli możliwe są znaczące zmiany w trakcie realizacji, klient jest gotowy na iteracyjne dostarczanie wartości i ciągłe poprawki.

Analityk ocenia:

• Sztywność terminów i budżetu.
• Doświadczenie i elastyczność zespołu.
• Wyrazistość końcowego celu i kompletność wymagań.
• Wymagania dotyczące przejrzystości toku pracy dla klienta.

Kluczowe cechy:

• Metodologia wpływa na sposoby zbierania, szczegółowego określania i zarządzania wymaganiami.
• Przy Waterfall wymagana jest szczegółowa SRS na początku.
• W Agile analityk prowadzi Product Backlog i wspiera iteracyjną pracę z wymaganiami.

Pytania podchwytliwe.

Czy analityk może całkowicie zmienić metodologię w połowie projektu?

Nie, przejście wymaga reengineeringu modelu roboczego, co jest kosztowne i ryzykowne. Częściej łączy się elementy obu podejść.

Czy Agile zawsze jest szybszy niż Waterfall?

Nie, Agile nie gwarantuje szybkiego wyniku, jeśli klient nie jest zaangażowany w proces i nie ma kultury zmian.

Czy wszystkie projekty są idealnymi kandydatami do Agile?

Nie, dla projektów z ustalonymi wymaganiami i wysokim ryzykiem sankcji regulacyjnych Agile nie zawsze jest odpowiedni.

Typowe błędy i antywzorce

• Ślepe kopiowanie Agile bez uwzględnienia dojrzałości klienta i zespołu.
• Niekompletna dokumentacja wymagań przy pracy w Waterfall.
• Brak elastyczności w obliczu zmian.
• Przeciążenie dokumentacją przy realizacji Agile.

Przykład z życia

Negatywny przypadek: W projekcie korporacyjnym próbowano wdrożyć Scrum bez doświadczenia i zaangażowania klienta, wymagania zmieniały się chaotycznie, ostateczny termin został przesunięty.

• Plusy: są elementy elastyczności, szybkie podejmowanie małych decyzji.
• Minusy: ciągłe przeróbki, przekroczenie budżetu i terminów.

Pozytywny przypadek: W projekcie dla startupu wdrożono Kanban, klient brał udział w priorytetyzacji zadań, wymagania zmieniały się przez Product Backlog, odbywały się stałe wydania użytecznych aktualizacji.

• Plusy: elastyczność, wysokie zadowolenie klienta, szybki czas wprowadzenia na rynek.
• Minusy: wymaga czasu na szkolenie roli Product Owner i zaangażowanie klienta w procesy zespołu.