Czy tworzenie oprogramowania Agile może być wykorzystywane w projektach określonych w umowie?

14

Niedawno rozmawiałem z innym programistą na temat Agile Software Development. Chociaż rozumiem tę zasadę, wydaje się, że ciągle zmieniające się wymagania stwarzają potencjał do kontynuacji projektu. Ale przynajmniej tam, gdzie pracuję, projekty muszą zostać zakończone, ponieważ jest to umowa.

Oznacza to, że pierwsza iteracja może zająć miesiące, ponieważ w przypadku niektórych projektów klient nie może użyć niekompletnej aplikacji. Myślę, że w przypadku niektórych projektów musisz najpierw zdefiniować ukończone, a następnie możesz podzielić je na iteracje i dopracować swoją definicję po każdej iteracji. Ale zawsze musisz mieć tę definicję.

Jeśli programowanie zwinne obejmuje zmieniające się wymagania, skąd wiesz, gdzie się kończy? Jak możesz budżetować projekt, gdy wynik końcowy zawsze się zmienia?

Czy programowanie zwinne to bardziej zwinny proces niż zwinny produkt?

Verax
źródło
kończy się, gdy trzeba rzeczywiście dostarczyć coś, co działa, zamiast majstrować. W tym momencie musisz zacząć narzucać strukturę, planowanie, ustalać wymagania i terminy, i zacząć pracować zamiast wygłupiać się.
jwenting 14.07.11
Każda zwinna iteracja daje działający, dostarczalny produkt, z którego klient może korzystać i dowiedzieć się więcej. Dzieje się tak, dopóki nie są zadowoleni, co często zdarza się wcześniej niż pierwotnie planowano. Gwarantuje to, że produkt zawsze działa i bierze pod uwagę fakt, że oprogramowanie nigdy nie jest gotowe, ale ewoluuje na zawsze lub umiera. Wystarczy wybrać moment, w którym uważasz, że produkt jest wystarczająco dobry i na tym poprzestać (na razie).
Martin Wickman
@Martin Wickman: Rozumiem to, ale problemem jest „produkt dostarczalny, z którego może skorzystać klient”. W takim przypadku pierwsza iteracja może potrwać miesiące, ponieważ w przypadku niektórych projektów klient nie może użyć niekompletnej aplikacji. Myślę, że w przypadku niektórych projektów musisz najpierw zdefiniować ukończone, a następnie możesz podzielić je na iteracje i dopracować swoją definicję po każdej iteracji. Ale MUSISZ ZAWSZE mieć tę definicję.
Verax,
@ Verax: Zwinny manifest został stworzony w celu zarządzania zmianami. Jeśli twój projekt nie ma żadnych zmian, zwinny nie jest dla ciebie. Koniec opowieści.
Martin Wickman
2
@ Verax: Powinieneś wyjaśnić swoje pytanie i dodać do niego więcej kontekstu. Twoje komentarze pokazują, że pytanie zawiera więcej. Jest to również oczywiste z głosowania, że ​​liczy się na odpowiedź i że zaakceptowana odpowiedź nie ma związku z rzeczywistym tekstem pytania (a nawet mówi „z komentarzy PO…”).
Martin Wickman,

Odpowiedzi:

7

Z komentarzy OP wynika, że ​​on tak jak ja pracuje w sklepie konsultingowym, w którym świadczymy usługi programistyczne dla naszych klientów ... Myślę, że z tego powodu, który powoduje jego / jej zamieszanie ... Więc zamierzam podać dobrze znany, ale nigdy nie podany fakt.

Zwinne jest niezgodne z tworzeniem oprogramowania zdefiniowanym w umowie.

  • Kontrakty muszą być trudne, płacisz X my robimy Y. Chcesz X + M płacisz nam Y + (M * N)
  • Umowy MUSZĄ być zadowalające (tzn. Nie są otwarte na koniec), w przeciwnym razie nie są to kontakty prawne. (W przypadku kontaktu należy przejść ścisły proces kontroli zmian).

Wiele sklepów konsultingowych twierdzi, że Agile, kłamią. Mówią to tylko dlatego, że Agile osiągnęło status słowa Buzz.

Zwinność sprawdza się najlepiej w programowaniu wewnętrznym, w którym programiści pracują na pełny etat, a budżetów niewiele mówi się. Tylko ramy czasowe i funkcje.

Kretynowie
źródło
Gdy dowiaduję się o tym więcej, dochodzę do tego samego wniosku. Twoje ostatnie zdanie wydaje się całkowicie poprawne. Kiedyś pracowałem dla rządu, a moim klientem była agencja, dla której pracowałem, a programy musiały być utrzymywane przez lata, o ile korzystali z nich pracownicy. Widzę zwinnego pracującego tam. Teraz rozwijam systemy wbudowane. Projekt kończy się, gdy maszyna działa (wszystko lub nic). Jeśli maszyna częściowo działa, nie można jej sprzedać - projekt nie powiódł się.
Verax,
2
Właściwie w sklepie konsultingowym, nad którym pracowałem kilka lat temu, rzeczywiście był artykuł napisany przez zwinnego zwolennika opisujący, jak zwinny można dopasować do modelu usługi o stałej cenie.
mcottle,
2
Muszę się nie zgodzić z tą odpowiedzią. Powodem jest to, że jeśli masz umowę, która nie jest zawarta na czas nieokreślony, oznacza to, że nie chcesz zarządzać pełzaniem zakresu (co prawie zawsze się dzieje). Umowy, które zwykle widzę, zaczynają się od: Płacisz X, my robimy Y. Następnie mają klauzulę, która mówi, że każda zmiana zakresu wiąże się z dodatkową ceną. Tak długo, jak jesteś bardzo wcześnie na powiadamianie o zmianie zakresu (co wymaga dodatkowych zasobów i czasu), wcześniejsi klienci mogą reagować na zmiany (uzyskiwanie zatwierdzeń i budżetu od wyższej kadry zarządzającej itp.). Wtedy sam proces zarządzania staje się sprawny.
Spoike,
Nie jest to niezgodne, jeśli umowa dotyczy usługi (pisanie kodu) w przeciwieństwie do produktu (gotowe oprogramowanie). Zwinne pozwala oszacować, co zostanie zrobione w ramach jakiego budżetu, jeśli zmieni się wymóg, budżet również musi się zmienić. Chcesz kolejną funkcję? Musisz wynosić kolejne 500 roboczogodzin. Pełzanie funkcji to także pełzanie cen, całkowicie satysfakcjonujące deweloperów, a jeśli klient jest skłonny zapłacić, kogo mamy to kwestionować?
SF.
2
Istnieją zwinne kontrakty , więc oczywiście odpowiedź ta jest z definicji błędna.
Martin Wickman
20

Jeśli skupiasz się na robieniu tego, co uważasz za najważniejsze, projekt zostanie zakończony, gdy:

  • Wydałeś pieniądze z budżetu.
  • Upłynął już czas w budżecie.
  • Nie chcesz już niczego dodawać ani zmieniać.
  • Następna partia zmian o najwyższym priorytecie nie jest warta tego, co będzie kosztować.
Dale Emery
źródło
5
1. Nigdy więcej pieniędzy - Klient wydał wszystkie swoje pieniądze na niekompletny, bezużyteczny produkt. 2. Nigdy więcej czasu - Klient nadal ma niekompletny, bezużyteczny produkt. 3. Nic do dodania - Tak, jasne! 4. Nie warto - klient po prostu zrezygnował z projektu. --- Czego mi brakuje? To nie ma dla mnie sensu.
Verax,
7
Dla 1 i 2: Jeśli najpierw wykonasz najważniejsze rzeczy, a następnie, gdy zabraknie Ci pieniędzy, otrzymasz najważniejsze rzeczy, które możesz zdobyć za te pieniądze. Podobnie jak czas. Przyznaję, że 3 jest rzadkie. Po 4: Zatrzymanie niekoniecznie oznacza, że ​​klient się poddał. Może to oznaczać, że mają najważniejsze rzeczy, których chcieli od tego, a teraz wolą robić inne rzeczy za swoje pieniądze. Jak decydujesz, kiedy zakończyć inne projekty? Niezależnie od kryteriów, które teraz stosujesz, nadal są dostępne w zwinnych projektach.
Dale Emery
1
Dale, dziękuję za twoje przemyślenia. Myślę, że to działa tylko wtedy, gdy klient płaci za każdą iterację indywidualnie i ceni każdą iterację jako sam produkt. Nie rozumiem, jak mogłoby to działać dobrze w przypadku produktów o stałym koszcie lub produktów, które wymagają wszystkiego albo niczego.
Verax,
5
@ Verax: Nie ma czegoś takiego jak produkt, który wymaga „wszystko albo nic”. Zawsze są funkcje, które są po prostu „miło mieć” i błędy, które są bardziej kosmetyczne niż funkcjonalne. Projekt o stałych kosztach jest sukcesem, jeśli to wszystko, co pozostało po wyczerpaniu pieniędzy. Zwinne metody próbują zmaksymalizować prawdopodobieństwo tego.
Michael Borgwardt
1
Oczywiście zmiana wymagań wiąże się z pewnym kosztem. Jeśli zbudujesz coś w jednej iteracji, a następnie zmienisz wymagania dla tych rzeczy w następnej, to będzie za to koszt. Zwinny obniża koszty. Nie eliminuje tego. Jeśli masz budżet, pamiętaj o nim, podejmując decyzję o dodaniu nowej funkcji lub zmianie istniejącej, wiedząc, że zawsze handlujesz jedną z nich. Uczysz się ustalania priorytetów i zmiany priorytetów oraz konsekwencji.
Dale Emery
14

Zatrzymujesz się, gdy firma zdecyduje, że nie chce już wykonywać iteracji. Miałbyś nadzieję, że dzieje się to po dostarczeniu znacznej wartości, ale zanim przejdziesz zbyt daleko w sferę malejących zysków.

Zawsze powinien być napędzany przez „biznes”, cokolwiek to oznacza w danych okolicznościach. Może to być kierownictwo wyższego szczebla sklepu programistycznego lub faktyczni sponsorzy biznesowi w wewnętrznym środowisku programistycznym. Zdecydują, kiedy koszt następnej iteracji przewyższy korzyści z funkcji, które będą dostępne w następnej iteracji.

Mcottle
źródło
5

Nigdy, i to jest jego piękno.

Projekt nigdy się nie kończy . Osiągnąłeś kolejne wydanie, kolejny kamień milowy, ale dopóki pieniądze płyną, zawsze jest jeszcze jedna funkcja do dodania, jeszcze jedna poprawka, jeszcze jeden błąd do naprawienia. Projekt umrze, gdy nie będzie już potrzebny, ale nigdy nie zostanie ukończony. W przeciwieństwie do modelu Waterfall z wymaganiami-> projekt-> produkt-> koniec, jest to pętla, która może kręcić się na zawsze - dopóki zarabiasz pieniądze.

Czyż nie jest to często wymieniana funkcja biznesowa tej technologii?

SF.
źródło
2
Projekty wodospadów też nigdy nie są całkowicie ukończone, istnieje większe prawdopodobieństwo, że zostaną dostarczone „zabierz lub zostaw”, a brakuje ważnych funkcji, co sprawia, że ​​konieczny jest nowy, drogi projekt.
Michael Borgwardt
4

Istnieje nieporozumienie: zwinny nie zachęca do zmiany wymagań projektu. Zamiast tego pozwala na zmiany bez marnowania pracy lub poświęcania ważnych obszarów rozwoju.

Istnieją cztery podstawowe ograniczenia dla każdego projektu inżynierskiego; zakres, koszt, czas i jakość. Wodospad zakłada, że ​​będą one statyczne. To błędne założenie; co najmniej jeden z tych ZAWSZE się zmienia. Zakres pełzania, cięcia budżetów i inne „nieznane niewiadome” ZAWSZE zakłócają projekt, zmieniając ograniczenia. Wodospad nie przewiduje tego, więc kiedy to nastąpi, projekt zmienia się w niepożądany sposób; ważne funkcje, które nie zostały jeszcze dodane, znikają, są szybko wykonywane lub wydanie musi zostać wypchnięte, lub kosztować balony, ponieważ PM rzuca pieniądze na nowych programistów, aby pomóc i zrobić to dobrze.

Zwrotna natomiast pozwala na zmianę ograniczeń i faktycznie tego oczekuje. Robi to, wykonując pracę w małych, użytecznych porcjach, zgodnie z priorytetami właściciela, a zatem porcje są idealnie natychmiast przydatne dla właściciela projektu. W ten sposób zmniejsza się narażenie na nieznane, nie robiąc wielkich planów w czasie, w którym nieznane są duże. Jeśli oś czasu ulegnie zmianie, zespoły mogą zostać dodane, a mniej ważne funkcje „zmniejszone”, a system, który zespół już zbudował, pozostaje nienaruszony.

Zapewnia również lepsze szacunki czasu i kosztów wymaganych do wytworzenia danego zakresu o wymaganej jakości. Ludzie notorycznie źle oceniają duże prace; aby zrobić to poprawnie, potrzeba dużo doświadczenia i dużo więcej wstępnych obliczeń. Dla kontrastu, ludzie są ogólnie dobrzy w ocenie tego, co mogą zrobić w ciągu dnia, tygodnia lub dwóch. To szybko tworzy stan ustalony, w którym można ekstrapolować czas i koszt pozostałej pracy do wykonania w oparciu o historyczne tempo, z dużą dokładnością.

Jeśli chodzi o definiowanie punktów końcowych, masz rację; zwinny projekt MOŻE trwać wiecznie. Podobnie może się stać w przypadku tradycyjnego SLDC; klient często wraca z większą ilością pieniędzy i listą ulepszeń. Różnica polega na tym, że nie ma wyraźnej granicy między „analizą”, „projektowaniem”, „rozwojem” i „utrzymaniem”, gdy patrzymy na projekt jako całość; wszystko dzieje się cegła po cegle, sprint po sprincie. Jeśli w dowolnym momencie właściciel chce nazwać projekt „wykonanym”, może to zrobić i będzie miał sumę „cegieł”, za które zapłacili, w solidnej „ścianie”; może nie być tak wysoki lub rozciągać się tak daleko, jak pierwotnie planowano, ale jest mocno osadzony, wykonuje pracę i można go dodać w późniejszym terminie, przy minimalnym zużyciu.

KeithS
źródło
Przepraszam, ale „To zamiast tego pozwala na zmianę bez marnowania pracy”, jest humanoidalnym błędem, którego używa się, by przekonać zarząd, jak wspaniale jest. Czy refaktoryzacja i / lub przeprojektowanie systemu w celu uwzględnienia nieoczekiwanych zmian nie jest uważane za marnowanie pracy? W obozie nad wodospadem tak, najwyraźniej nie w zwinnym obozie. Ponadto, jeśli klient chciał tylko pracy, której wykonanie zajmuje 2 tygodnie, nie ma znaczenia, jaką metodologię zastosuje, ludzie mogą podać dobre oszacowania. Tym, czego tak naprawdę chce klient, jest to, jak długo będę miał pełny produkt, w którym zwinność nie jest lepsza niż inne metody szacowania.
Dunk
1
Ponadto sprawia, że ​​brzmi to jak dobra rzecz, którą właściciel może nazwać zrobioną w dowolnym momencie, a to, co ukończyłeś, jest tym, co dostaje. IME, ogólnie rzecz biorąc, klient chce wiedzieć, że jego X dolarów zapewni pewien zestaw funkcji, zanim zacznie wypłacać gotówkę. Nie widzę w tym korzyści, że klient wydał stos gotówki i otrzymał tylko połowę oczekiwanych funkcji. Uważam, że jest to porażka ze strony rozwijających się firm, nawet jeśli dostarczyły coś, co nazywają działającym ....
Dunk
2
Co się stanie, jeśli klient zakontraktował dom, ale pieniądze się skończyły przed założeniem dachu? Zwinny obóz nadal nazwałby to sukcesem. Nikt inny by tego nie zrobił; w szczególności klient.
Dunk
1
Jeśli chodzi o szacowanie, zespół ocenia, co mogą zrobić w sprincie, i jest to ekstrapolowane, aby utworzyć oś czasu dla całego projektu. Ponownie pomaga chronić zarówno programistów, jak i klienta. Możesz umieścić w umowie wszystko, co chcesz, w tym kwotę i datę „nie przekraczać”. Jest do negocjacji. Zwinny nadal pomaga, pokazując obu stronom bardzo szybko, czy ograniczenia są wykonalne. Dwa tygodnie później, jeśli nie wygląda na to, że uda się to zrobić na czas, można dodać zespoły, usunąć funkcje lub przedłużyć harmonogram.
KeithS,
1
Co jeśli zrobiłby to samo w wodospadzie SLDC? Albo rozwój zostanie zatrzymany, a klient może otrzymać bazę kodu z poważnymi dziurami funkcjonalnymi lub przewidując brak pieniędzy / czasu, pozostały harmonogram zostanie zatłoczony w pozostałym czasie. ZAWSZE poświęca się jakość, a pod koniec takiego projektu zespół programistów jest usmażony. Ponadto zdarza się wiele przekroczeń kosztów, ponieważ tradycyjny wodospad nie wytwarza produktu do czasu zakończenia rozwoju; co ogranicza zdolność klienta do powiedzenia „nie tego chciałem”.
KeithS,
1

Kończy się, gdy wszystkie funkcje zostaną zaimplementowane, a wszystkie błędy zostaną naprawione.

Jeżeli termin jest ustalony, a wymagania również ustalone. To nie będzie problem. Ale jeśli termin jest ustalony, ale wymagania się zmieniają, jest coś, co powinieneś zrobić, aby pomyślnie kontynuować projekt.

Naprawiono cenę część 1, co jest tak złego?

Naprawiono cenę część 2, napraw ją zwinnie!

CharithJ
źródło
Trudno wiedzieć, kiedy wszystkie błędy zostały naprawione.
Martin Wickman
Może „kiedy naprawione zostaną wszystkie znane błędy, które warto naprawić”?
Dan Ray
@CharithJ, twoje linki są zepsute. Czy są jeszcze gdzieś dostępne? Dzięki.
TwainJ
1

Wielkim założeniem zwinnego rozwoju jest to, że wymagania ciągle się zmieniają, bez względu na zastosowaną metodologię. Teraz, oczywiście, możesz zbudować dokument wymagań, zbudować na nim plan wykonania i dostarczyć na końcu, i może się wydawać, że twoje wymagania się nie zmieniły. Być może nie zmieniły się one w twoim planie, ale wraz ze zmianami rynku i lepszym zrozumieniem produktu przez ciebie i twojego klienta, wymagania dotyczące tego, czego chce klient, zmienią się. Wchodzi Agile i sugeruje proces, który nie ukrywa tych zmian w ustalonym harmonogramie, ale zamiast tego buduje reakcję na nieuniknione zmiany w procesie.

Kiedy skończysz, teraz przechodzisz od zakończenia ustalonego harmonogramu do momentu, gdy produkt znajduje się w miejscu, w którym możesz zapewnić wystarczającą wartość biznesową, w której klient może wysłać i sprzedać oprogramowanie w jego obecnym stanie. Realizacja wiąże się znacznie bardziej z tym, ile wartości dostarczasz, niż z przestrzeganiem harmonogramu.

Brian Geihsler
źródło
1
Zwinni zwolennicy błędnie zakładają, że w świecie wodospadów programiści znikają po podpisaniu umowy i nigdy więcej nie są słyszani, dopóki produkt nie wyskoczy za drzwi. To, jak działa w prawdziwym życiu, polega na tym, że istnieje spora liczba punktów kontrolnych i wiele recenzji, z którymi klient może być tak zaangażowany, jak tylko chce. Jeśli nie podoba im się kierunek ani decyzje, mogą poprosić o zmiany. Do czasu dostarczenia produktu powinno być to, czego chciał klient, w zakresie, w jakim zdecydował się wziąć udział. Agile nie poprawia tego w wielu projektach.
Dunk