Jest jedna rzecz, którą zawsze zastanawiałem się, czytając o tych wszystkich „zwinnych pracach programistycznych” tutaj na SE i innych stronach:
W „tradycyjnej” inżynierii oprogramowania
- zbierać wymagania użytkownika,
- napisz specyfikację na podstawie tych wymagań,
- dać klientowi i wystawić rachunek za dotychczas wykonaną pracę,
- wykonać (przybliżony) projekt techniczny, aby można było oszacować koszt wdrożenia,
- podać użytkownikowi ofertę cenową za wdrożenie,
- poczekaj, aż klient podpisze specyfikację i zaakceptuje ofertę,
- zaprojektować, wdrożyć, przetestować,
- rachunek.
Jeśli podczas procesu zmieniają się wymagania, wysyłasz ofertę (z ceną) żądanych zmian (lub robisz to za darmo, jeśli zmiana jest niewielka, podoba ci się klient, a klient nie robi tego zbyt często) .
Jak to działa (finansowo) w zwinnym projekcie, w którym częste zmiany wymagań są częścią tego procesu?
- Czy piszesz ofertę na każdą zmianę projektu? (Czy to nie byłby niezły bałagan?)
- A może negocjujesz stałą cenę i masz nadzieję, że klient nie zmieni zbyt często wymagań? (Może to być ryzykowne, znam klientów, którzy skorzystaliby z tej okazji, aby poprosić o nowe funkcje przez lata, zanim zaakceptują ukończenie projektu).
- A może po prostu rozliczasz klienta za całkowity wymagany czas? (Może to być ryzykowne dla klienta, który nie zna z góry kosztów).
Odpowiedzi:
W idealnym świecie zwinnym uzgadniasz z góry cenę i liczbę godzin, ale nie zakres. Klient decyduje o tym, jaki jest minimalny użyteczny produkt, a nie produkt, którego naprawdę chce, a to powinno oszacować znacznie poniżej uzgodnionej liczby godzin.
Następnie dostarczasz im iteracyjnie, a oni zmieniają zdanie, ile chcą, ale nigdy nie przekraczasz ustalonej liczby godzin. Teoretycznie i często w praktyce kończą się produktem, którego naprawdę potrzebują, a nie produktem, którego naprawdę chcą.
A jeśli chcą nadal płacić za dodatkowe godziny po pierwotnie uzgodnionej wartości, to też jest w porządku. Jeśli wykonasz wystarczająco dobrą robotę, aby uczynić postęp widocznym, za pomocą kart opowieści, Greenhoppera itp., Możesz bardzo wyraźnie uświadomić klientowi, które funkcje tracą (lub przynajmniej depriatyzują) za każdym razem, gdy dodają coś nowego, co w dużej mierze stawia zatrzymanie frywolnych zmian.
Warto tu zwrócić uwagę na dwa rodzaje ryzyka. Po pierwsze, klient może się wystraszyć, jeśli nie zrozumie z góry Agility. Wygląda na to, że podejmuje całe ryzyko. Jedynie doświadczenie pokazuje, że tak naprawdę nie jest.
Po drugie, muszą być zaangażowani przez cały proces, inaczej wszyscy stracą. Wielu klientów nie rozumie, jak muszą być zaangażowani, dopóki nie będzie za późno.
Ale jeśli jako firma wyjaśnisz to wystarczająco dobrze, wszyscy są zwycięzcami.
źródło
Niektórzy ludzie próbowali aby dać rozwiązania używać Agility w projektach Cena ustalona w przeszłości. Osobiście uważam, że generalnie nie jest to możliwe.
Scrum szczególnie nadaje się dla firm produkujących oprogramowanie i jest mniej wykorzystywany w firmach usługowych.
Możesz wykorzystać pewną zwinność w swoich projektach, takich jak iteracje, codzienne stand-upy, burndorn itp., Ale zapewniam cię, że jeśli zaoferujesz określoną ilość rzeczy za określoną cenę i dostarczysz mniej niż to, co było w umowie, będziesz mieć problem.
Proszę nie podawać Agility à toutes les sosy . Musimy zastosować odpowiednie rozwiązanie danego problemu.
źródło
Nie jest to tak naprawdę związane z programowaniem Agile lub jakimkolwiek modelem, którego używasz. Pracując jako freelancer, używam kombinacji Waterfall i V-model, ale nadal mam ten sam problem: co, jeśli klient chce coś zmienić podczas szczegółowego projektu? Co jeśli wprowadzi zmiany podczas wdrażania?
Podejście, które musisz zastosować, zależy od klienta i twoich relacji.
Jeśli kontakt jest niezbędny we wszystkim, co robisz dla tego klienta, ponieważ wiesz, że on stara się nie płacić, kiedy może, lub spróbuje Cię pozwać w miarę możliwości, to tak, musisz napisać ofertę dla każdego drobna zmiana wymagań. To nie jest bałagan: jeśli jesteś dobrze zorganizowany, dostosowanie się do nowych wymagań podczas rozwoju może nie być trudne. Ale na pewno jest to strata czasu i pieniędzy i raczej dziwne jest podpisanie oferty zmiany, której wdrożenie zajmie dwie godziny.
W przypadku innych klientów dobrze działające podejście jest następujące:
Podpisując pierwszą ofertę, określ szacunkowy koszt i maksymalny koszt. Szacowany koszt nic nie znaczy z prawnego punktu widzenia: to tylko szacunek. Maksymalny koszt ma wartość prawną: jeśli powiesz, że produkt będzie kosztował 3 000 USD dla klienta, a ostatecznie będzie kosztował 3 157,24 USD, klient nadal będzie musiał zapłacić 3 000 USD. W praktyce w większości przypadków rzeczywisty koszt będzie niższy od podanego maksimum i bliższy oszacowaniu.
Gdy klient prosi o zmianę wymagania, oszacuj jego koszt i porównaj go z faktycznym kosztem i stanem. Jeśli prawie ukończyłeś produkt, a rzeczywisty koszt to 2 108,36 USD, a koszt zmiany szacowany jest na 150 USD, po prostu zrób to. Jeśli z drugiej strony istnieje ryzyko, że osiągniesz maksimum, powiedz swojemu klientowi, że musisz wspólnie oszacować całkowity koszt.
źródło
Zwinne i „Napisz ofertę” wydaje się antytezą :) - to nie jest produktywna inżynieria oprogramowania: D
Okej, teraz, gdy żart został usunięty z powrotem - wracamy do rzeczy.
„Jak to działa w Agile ?” - umowa komplikuje sprawy, ale mam nadzieję, że to wyjaśnię. Agile opiera się na zasadzie „zaufania” i „współpracy”, co oznacza, że klient może zmieniać cokolwiek, kiedykolwiek i rozumie, że może to kosztować nieco więcej lub jeśli nie jest nachalne, być może bez dodatkowych kosztów.
Co to znaczy? Oznacza to, że umowa określa, że my (klient) ustalamy wstępny szacunek kosztów i wariancję +/-%, którą możemy obsłużyć, np. 100 000 USD, ale jestem skłonny podnieść się do 120 000 USD (to NIE MOŻE część umowy, ale w myślach klienta).
Teraz, gdy pojawi się zmiana projektu, zwinnie podejmij oszacowanie i zaplanuj - zbierz swój zespół i zapytaj go, czy „punkt fabularny” oszacuje złożoność faktoryzacji zmian. Dzięki niektórym oszacowaniom prędkości możesz je pomnożyć i podać oszacowanie harmonogramu. Wyznaczenie kosztu za punkt historii powinno być stosunkowo łatwe, jeśli znasz zespół i jego względne pensje (proszę nie uśredniać całej pensji KAŻDEGO, ulegniesz błędowi średnich).
Czy musisz wrócić do klienta z finansami? NIE. Niekoniecznie. Poproś klienta o nadanie im priorytetu i wstawienie ich we właściwe miejsce w rejestrze. Teraz, gdy znasz rozmiar zaległości (powinieneś, jeśli jeszcze tego nie wiesz) i w oparciu o finanse (koszt na punkt fabuły) wiesz, które wymagania o niskim priorytecie mogą nie być wykonalne przy danym budżecie. POKAŻ im ponownie zalegalizowane zaległości z oszacowaniem możliwych do wykonania funkcji zgodnie z umową $$. Następnie pozwól im zdecydować, czy są gotowi zapłacić więcej, aby uzyskać więcej, jeśli / kiedy ty / ona tam dotrzesz. Jeśli będą chcieli za darmo ... zajmij stanowisko i powiedz im, że będzie to kosztować więcej.
Powinno to pomóc bez ciągłego wracania do finansów, jeśli możesz mieć ten wykres gdzieś, aby klient mógł go zobaczyć.
Mam nadzieję że to pomoże!
źródło
Doświadczenia innych ludzi prawdopodobnie będą się różnić, ale jednym ze sposobów, w jaki to widziałem, jest w dużej mierze takie samo, jak twoje „tradycyjne”, z kilkoma rzeczami do zapamiętania:
Często też zwinne projekty zaczynają się jako „rdzeń” i przechodzą stamtąd modułowo w miarę potrzeb (widziałem, że dzieje się to dość często w projektach, w które się zaangażowałem). Zaczynasz od podstawowego produktu, powiedzmy, że jest to aplikacja do mapowania. Pierwsza implementacja to tylko mapa, która koncentruje się na twojej bieżącej lokalizacji (co początkowo zamówił klient).
Następnie klient decyduje, że chce mieć wokół Ciebie upuszczone atrakcje. Ok, to dość duży kawałek (mówiąc stosunkowo), więc wystawiasz rachunek jako nowy „moduł” lub zamówienie. Zmiany w rzeczach takich jak kolor lub wygląd tych szpilek są wbudowane w koszt tego zamówienia. Instrukcje i nakładki są kolejnym zamówieniem, ponieważ nie były wymagane aż do momentu realizacji innego zamówienia, i tak dalej.
źródło