Czy używanie Agile jest niewłaściwe, gdy wymagania klientów w ogóle się nie zmieniają?

12

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?

agile development-process

— Poinformowano
źródło

2

@randomA: właściwie, IMHO nigdy nie powinieneś próbować czystego wodospadu tylko wtedy, gdy chcesz stworzyć działający produkt, który wymaga więcej niż tygodnia wysiłku.

— Doc Brown

10

Daj mi swoich klientów

— razethestray

7

Dam swoim klientom 2x więcej niż @razethestray

— Euphoric

2

Jeśli Twój klient nie chce „codziennie przeszkadzać”, dowiedz się, jak skutecznie z nim komunikować. Na przykład, zamiast przyjmować (prawdopodobnie błędne) założenia dotyczące niejasnych punktów, zbieraj pytania na liście i wysyłaj klientowi listę w regularnych odstępach czasu. Jeszcze lepiej: umów się na spotkanie w celu omówienia punktów. Jeśli wymagania są tak jasne, że lista pozostaje pusta: brak spotkania (ale chyba nie będzie). Jeśli zaczniesz wdrażać błędne założenia w swoim oprogramowaniu, będziesz mieć dużo więcej wysiłku, aby to zmienić później.

— Doc Brown

3

@randomA: możesz przez pewien czas utrzymywać zadowolenie klienta, nie pytając o nic, a następnie, gdy dostarczysz ostatnią rzecz, spraw, aby był bardzo niezadowolony, ponieważ okazało się, że tak bardzo spóźniłeś się z wymaganiami, że możesz odrzucić swój program i rozpocząć od samego początku (za co klient nie będzie skłonny zapłacić). Lub sprawisz, że będzie trochę, ale niezadowolony, prosząc go wystarczająco, aby zbudował odpowiedni program, ale bardzo szczęśliwy na końcu, gdy program rzeczywiście zrobi to, czego chce, a dostanie to, za co zapłacił. Wybierz swój wybór.

— Doc Brown

16

Czy byłoby to uważane za złe, kodowanie kowboja, anty-wzór.

Krótka odpowiedź: nie. Prawidłowe działanie „zwinnego” nie oznacza „braku planowania”, nie oznacza zbytniego analizowania rzeczy.

Jednym z głównych powodów używania Agile jest fakt, że klienci często zmieniają wymagania.

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ń).

— Doktor Brown
źródło

3

Prawidłowe wykonywanie „wodospadu” nie oznacza „planowania wszystkiego”, nie oznacza niedanalizowania rzeczy.

— Giorgio

1

@Giorgio: prawidłowe wykonanie „wodospadu” oznacza, że nie należy go stosować, gdy wymagania są „nieco niejasne”, a „oprogramowanie jest na tyle złożone, że istnieją szczegóły, problemy, których nie rozpoznałbym, dopóki ich nie napotkam” (cytowanie z oryginalne pytanie).

— Doc Brown

6

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.

— SpoonerNZ
źródło

Nie rozumiem, w jaki sposób A) rozwiązuje problem, o którym wspomniałeś na początku swojej odpowiedzi: skąd wiesz, czy kilka ostatnich opowiadań zajmie kilka dni, czy dwa lata? Wiesz tylko, kiedy to robisz, prawda?

— Giorgio

1

Masz rację, ale różnica polega na tym, że w obecnym stanie masz produkt, który można wypuścić, zamiast 90% zrobionego błędnego oprogramowania, którego nie można wydać. Masz również empiryczne dowody na to, jak długo zajęło Ci dostarczenie funkcji, które można wydać, oraz swoje szacunki dotyczące pozostałej pracy, które prawdopodobnie zapewnią więcej pewności, niż żaden dowód, że cokolwiek zrobiłeś, faktycznie działa.

— SpoonerNZ

Zależy: jeśli wszystkie planowane funkcje są niezbędne, to produkt z 90% funkcjami jest bezużyteczny / nie można go uwolnić: można go użyć tylko w celu pokazania tego, co już istnieje. Z mojego doświadczenia wynika, że zwinność nie jest lepsza we wszystkich sytuacjach: istnieją projekty, dla których zwinność jest bardziej odpowiednia (zmieniające się wymagania, małe, niezależne i niezależne funkcje) oraz projekty, dla których nie jest ona (stabilne wymagania, złożone i / lub krytyczne dla misji funkcje).

— Giorgio

Zgadzam się - niedostarczenie nie jest dobre w żadnym przypadku, ale jako interesariusz chciałbyś zaufać zespołowi, który produkuje w pełni działającą wersję twojego oprogramowania do zabawy, w którym wszystko działa, ale brakuje niektórych funkcji, lub zespołowi, który daje ci błąd zagadkowy stos kodu źródłowego, który teoretycznie ma wszystkie twoje funkcje, ale powoduje awarie i ma wiele nieoczekiwanych zachowań? Wiem, komu bardziej ufałbym.

— SpoonerNZ

Oczywiście zaufałbym pierwszemu zespołowi, ale nie zgadzam się z tym, że przy użyciu metody nie zwinnej zawsze kończy się to „błędnym stosem kodu źródłowego, który teoretycznie ma wszystkie funkcje, ale powoduje awarie i ma wiele nieoczekiwanych zachowań” . Przynajmniej nie było to do tej pory moje doświadczenie.

— Giorgio

3

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.

— Bart van Ingen Schenau
źródło

1

Często zastanawiam się, czy klienci, którzy nie chcą się zbytnio angażować, mają prawdziwą potrzebę biznesową. Często widziałem to w projektach, w których istniejąca aplikacja jest „tłumaczona” na nową technologię. Możesz sprawdzić kod, jeśli masz pytania, które ci mówią. Nikt nie czeka na remake.

— user99561,

@ user99561: masz rację, ale w takich sytuacjach wymagania w większości nie są niejasne, są krystalicznie czyste - o ile nowy program będzie zachowywał się dokładnie tak , jak stary. W takiej sytuacji podejście zwinne nie jest rzeczywiście konieczne. Rzeczywiście wystarczy iteracyjne podejście oparte na kamieniu milowym (bez dużej interakcji z klientem).

— Doc Brown

Krystalicznie czyste? Powodzenia w ustaleniu, jakie jest dokładne zachowanie i jakie są wyjątki. Przez większość czasu nawet ludzie biznesu nie rozumieją, co dzieje się w aplikacji. Moja rada: uciekaj jak najszybciej od tych projektów. Ponieważ wiesz, kiedy rozpoczyna się projekt, ale nie wiesz, kiedy ostatni opublikowany błąd, ponieważ aplikacje zachowują się inaczej, zostaną naprawione.

— user99561

0

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

— Silviu Burcea
źródło

Właśnie dodałem edycję w celu wyjaśnienia. Klienci pokazali problem z wystarczającą liczbą szczegółów i jasną listą życzeń i nie chcą się więcej martwić. Załóżmy więc, że nie ma opinii klientów aż do końca, kiedy można zaprezentować działający prototyp.

— Poinformowano