Ostatnio widziałem wiele postów mówiących, że jednym z głównych powodów używania Agile jest to, że klienci często zmieniają wymagania.
Powiedzmy jednak, że klienci często nie zmieniają wymagań . W rzeczywistości klienci mają ścisłe wymagania, choć mogą być nieco niejasne (ale nic nierozsądnie niejasne), ale i tak używam Agile.
Powodem, dla którego stosuję Agile, jest to, że oprogramowanie jest na tyle skomplikowane, że istnieją szczegóły, problemy, których nie rozpoznałbym, dopóki się z nimi nie zmierzę. Mógłbym zastosować pełne planowanie na dużą skalę, takie jak wodospad, ale wtedy zajęłoby kilka miesięcy, aby sfinalizować wszystkie projekty wysokiego poziomu i podpisy kodowania niskiego poziomu. Istnieje jednak bardzo konkretny, stały projekt architektoniczny systemu.
Moje pytanie brzmi: czy byłoby to uważane za złe, kodowanie kowboja, anty-wzór itp.? Czy musimy zastosować wodospad i zaplanować jak najwięcej szczegółów, zanim zaczniemy kodować, gdy wymagania są stabilne zamiast tej mentalności „zróbmy to” w Agile?
EDYCJA: Najważniejsze jest to, że: NIE MOŻEMY winić klientów za zmianę wymagań. Załóżmy, że klienci wskazali nam na bardzo konkretny problem, podaj nam listę życzeń w bardzo rozsądnych szczegółach i zostaw nas w spokoju (tzn. Klienci mają swoje własne produktywne rzeczy do zrobienia, nie rób im więcej błędów. Tylko demonstracje dla nich w pobliżu koniec, gdy masz minimalny działający prototyp). Czy stosowanie Agile w tym scenariuszu byłoby błędem?
źródło
Odpowiedzi:
Krótka odpowiedź: nie. Prawidłowe działanie „zwinnego” nie oznacza „braku planowania”, nie oznacza zbytniego analizowania rzeczy.
To oświadczenie upraszczające. „Zmiana wymagań” dotyczy także zmiany zrozumienia przez zespół wymagań. I chodzi o to, jak zmieniają się priorytety klienta dotyczące wymagań, gdy faktycznie widzi kilka wydań oprogramowania.
W rzeczywistości „zwinny” działa IMHO najlepiej dokładnie w opisywanej sytuacji - klient ma dobrą wiedzę na temat swoich ogólnych wymagań, możesz napisać z niego ogólny plan, wypełnić swoje zaległości wieloma „historiami użytkowników” i już wystarczająco dużo informacji, aby wybrać odpowiednią architekturę systemu. Krótkie iteracje zwinnej strategii rozwoju pomogą uszczegółowić „niejasne wymagania”, z dużą ilością informacji zwrotnych, jeśli nadal zmierzasz we właściwym kierunku. Zapewni również wczesną informację zwrotną na temat rzeczywistego wysiłku i kosztów (co jest czymś, co nadal może zawieść przy podejściu do wodospadu, nawet jeśli znasz każdy szczegół wymagań).
źródło
Korzystanie ze zwinności w tej sytuacji jest nadal bardzo dobrym pomysłem. Zwinność ma wiele zalet, z których tylko jedną jest regularna informacja zwrotna od klienta i umiejętność reagowania na zmieniające się wymagania, jak wspomniałeś.
Jednym z głównych powodów, dla których projekty wodospadu są znane z niepowodzenia, jest problem „prawie ukończony” - testowanie wyprodukowanych stosów błędów na końcu, pozostawiając produkt, którego nie można wydać i nie ma pojęcia, czy potrzeba kolejnych dwóch dni, czy dwóch lat, aby naprawić zaległe błędy. Zwinne całkowicie usuwa to ryzyko. Jeśli zwinny projekt jest nadmiarowy, nadal możesz dostarczyć działającą wersję, która:
A) Udostępnia klientowi, że jesteś prawie na miejscu dzięki demonstracjom („Wszystkie te historie są gotowe, możemy zrobić kilka ostatnich, jeśli chcesz”), a trochę więcej czasu dostanie dokładnie to, czego chcą.
B) Potencjalnie jest wystarczająco dobry, aby i tak byli szczęśliwi i wypuścili.
Dla mnie wyeliminowanie tego ryzyka całkowitej awarii jest wystarczającym powodem, aby firma przeszła na sprawny proces programistyczny. Możliwość zbudowania lepszego oprogramowania, niż początkowo planowano, jest wisienką na torcie. Jak wspomniano w innych odpowiedziach, te „konkretne” wymagania są często zaskakująco plastyczne.
źródło
Zwinność jest idealna, jeśli potrzebujesz częstej pętli sprzężenia zwrotnego z klientem. Może tak być, ponieważ wymagania często się zmieniają, ale może być również z innych powodów.
Z drugiej strony, Agile może działać równie dobrze, jeśli wymagania są w pełni stabilne, a klient oczekuje tylko pojedynczej dostawy Big Bang, ale być może trzeba będzie trochę dostosować do poziomu zaangażowania, jakiego oczekuje klient podczas projekt. Oznacza to, że rola właściciela produktu musi być wypełniona z Twojej organizacji i osoba ta musi mieć wystarczające uprawnienia od klienta do podejmowania decyzji.
źródło
Zawsze możesz podzielić duże wydanie na mniejsze wydania (sprinty) i poprosić klienta o opinię. W ten sposób masz pewność, że postępujesz właściwie, a klient może śledzić twoje postępy.
Jeśli coś jest nie tak, możesz zaoferować klientowi możliwość szybszej korekty, co jest bardzo dobre. Lepiej jak najszybciej poprawić swoje błędy, niż pokazać mu bzdury na końcu i spróbować to naprawić, gdy nawet nie wiesz od czego zacząć.
źródło