Zapomnij na chwilę Agile, zastanów się, co należy rozumieć przez „wodospad”.
Istnieje faza wymagań, w której każdy próbuje dowiedzieć się, JAKIE problemy musi rozwiązać produkt końcowy. Ludzie kłócą się o to przez chwilę, a potem podpisują się zgodnie z szeregiem wymagań. W tym momencie Twój zakres jest zdefiniowany, umowy są podpisywane, a klient może odejść i poczekać, aż pojawi się produkt, który spełni te zdefiniowane wymagania.
Następnie jest jedna (a może dwie) fazy projektowania. Projektanci (którzy mogą, ale nie muszą być programistami), spierają się o to, JAK system musi iść w parze, aby spełnić podpisane wymagania. Problemy mogą wystąpić, jeśli nie do końca rozumieją wymagania, co może oznaczać, że muszą wrócić do klienta, potencjalnie ponownie otworzyć fazę wymagań (i uzyskać kolejną rundę podpisania się) lub przynajmniej uruchomić zarządzanie zmianami w działaniu . Często projektanci po prostu starają się zgadnąć. Mogą wymyślić logiczny model danych i mnóstwo UML-a opisującego nowy system i sposób jego działania. Następnie podpisują się.
Teraz programiści mogą zacząć kodować na podstawie podpisanego projektu. Problemy mogą wystąpić, jeśli nie do końca rozumieją projekt, co może oznaczać, że muszą wrócić do projektanta, potencjalnie ponownie otworzyć fazę projektu (i uzyskać kolejną rundę podpisów) lub przynajmniej uruchomić zarządzanie zmianami w działaniu . Projektanci mogą z kolei zdać sobie sprawę z tego, że zamieszanie naprawdę wraca do wymagań, co oznacza, że muszą ponownie otworzyć dyskusje na temat wymagań, podpisania się i dalszego zarządzania zmianami. Często programiści (mający zbliżający się termin) po prostu zgadują. Robią, co mogą, aby stworzyć funkcjonalny kod. Następnie udostępniają go do testowania.
Teraz rozpoczyna się faza testowania systemu. Testerzy testują na podstawie ich zrozumienia wymagań i projektu oraz rejestrują to, co postrzegają jako wady, w systemie śledzenia błędów / zarządzania zmianami, co powoduje, że programiści zaczynają programować od nowa, chyba że widzą problem jako wada projektowa, która odsyła ją z powrotem do projektu itp. W końcu testy systemowe przechodzą pomyślnie i zostają podpisane.
Wreszcie klient wraca i przeprowadza testy akceptacji użytkownika w nowym systemie. Tutaj decydują, czy rozwiązanie, które testowali testerzy, opracowali programiści, a projektanci zaprojektowali, jest tym, czego chcą. Jeśli tak nie jest, potencjalnie musisz wrócić do fazy projektowania lub nawet ponownie sprawdzić wymagania.
Idea stojąca za wodospadem polega na tym, że trudno jest (i bardzo niepożądane) cofnąć się po zakończeniu fazy. Różne osoby są zwykle zaangażowane w różne fazy, więc istnieje wiele przekazań - z których każda wiąże się z dużym ryzykiem błędnej interpretacji i utraty informacji. Istnieje również znaczna luka między momentem, w którym klienci mówią, co chcą, a momentem, w którym zobaczą, co zostało zbudowane, a kiedy rzeczywiste wymagania mogą się bardzo zmienić.
Metodyki zwinne koncentrują się na silnej komunikacji i współpracy między wszystkimi zainteresowanymi stronami. Zasada „Współpraca z klientem podczas negocjacji umowy” oznacza, że nie powinieneś przechodzić przez szereg podpisów i przekazów, ale zamiast tego powinieneś po prostu współpracować z klientem, a każda iteracja określa wymagania dla danego elementu układanki i natychmiastowe tworzenie testów, projektu i działającego kodu - przy czym wszyscy gracze komunikują się tak bezpośrednio, jak to możliwe (eliminując koszty i ryzyko związane z przekazaniem). Działający kod jest szybko testowany przez klienta, co eliminuje ryzyko opóźnienia czasowego. Wszystkie działania odbywają się we współpracy, a nie w dół.
Aby uzyskać doskonały przegląd metodologii zwinnych, gorąco polecam program Agile Software Development: The Cooperative Game firmy Allistair Cockburn .