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

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?

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.

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

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.

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?

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.

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!

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.