W jaki sposób obciążasz klienta swoim projektem za pomocą elastycznej metodologii?Jak ładować/budżetować w zwinnych projektach programistycznych?
Co godzinę? W takim razie przed projektem trzeba było dużo zaufania.
Za iterację? Będzie wiele decyzji budżetowych, które mogą zająć trochę czasu.
Na projekt? Jak możesz to zrobić, gdy nie znasz zasięgu? Istotą zwinności jest nie pisać dużego projektu/specyfikacji.
Klient jest obciążany na podstawie warunków określonych w umowie, które będą nieznacznie różnić się od tradycyjnej umowy o stałej ofercie. Nazwijmy to zwinnym kontraktem.
Niektóre opcje omawia Alistair Cockburn w Agile contracts.
Kolejny wielki zasób to 10 Contracts for your next Agile Software Project autorstwa Petera Stevensa.
Mary Poppendieck ma również świetny materiał na ten temat. Zobacz agilecontracts, agilecontractsworkshop, Contracts Excerpt From Lean Software Development, Lean Contracts. Więcej here.
Jeśli twój klient kupił już w ramach metodyki zwinnej, masz rozsądne ramy do negocjowania ceny za iterację. Na przykład:
To o wiele więcej dowodów, na podstawie których można opierać decyzje dotyczące cen, niż jest to możliwe w przypadku większości umów o stałej cenie.
Jeśli zwinne metodyki jest czysto wewnętrzny proces rozwoju, który nie wiąże się z klientem, to jest mało prawdopodobne, aby mieć większego wpływu na negocjacje cenowe pomiędzy dostawcą a klientem. Istnieje argument, który mówi, że proces, który nie angażuje klienta w ustalanie zakresu i oczekiwań co najmniej raz na iterację, nie jest wcale sprawny.
Jeśli chodzi o komentarz Marka, istnieje bardzo powszechny model ustalania cen oparty na umowach o stałej cenie z luźno określonymi zakresami i optymistycznymi harmonogramami. Powszechnym rezultatem jest to, że zarówno dostawca, jak i klient odkrywają, że ich początkowy optymizm był niewłaściwie wprowadzony. Obie kończą negocjacje ze słabych pozycji nad rzeczami, które naprawdę są dla nich ważne i oboje kończą się nieszczęśliwi.
Niektóre z technik, które dobrze sprawdzają się w zarządzaniu tego typu umowami, są bardzo podobne do tych stosowanych w zarządzaniu kontraktami zwinnymi (częste dostawy, handel końmi w zakresie, priorytety: & cena, komunikacja frankfurcka, ...) Różnica polega na tym, że nie są one wbudowane w pierwotną umowę, a umowa może nie być wystarczająco elastyczna, aby pomieścić wszystkie z nich.
Jeśli masz klienta, który wyrazi na to zgodę, zrozumiesz proces rozwoju, a nawet, że byłby świetny, i spodziewam się, że może niektóre części aplikacji będą poniżej budżetu. Z naszego doświadczenia i być może natury rynku, w którym się znajdujemy, nasi klienci chcą tylko jednej ceny i chcą ją dostarczyć wczoraj. –
Moja 2c jako non-agile lekarza ... w dążeniu do poznania więcej ...
Jeśli robisz konkretnego projektu dla klienta, trzeba znać zakres projektu do podać koszt i skalę czasową. Koszt wytworzenia tego zakresu pracy jest częściej niż częścią odkrycia projektu, możesz albo trafić na to, aby uzyskać pracę lub opłatę za to (jawnie lub domyślnie) W tym przypadku koszt projektu może być opracowane i uzgodnione. W tym przypadku projekt zazwyczaj dzieli się na różne etapy.
Chociaż zwinny może być powtarzalny i nie wymaga pełnej specyfikacji; cel, przynajmniej na pewno jest wymagany. Musi istnieć jakaś forma podstawowej specyfikacji/wymagania. Możliwe, że trzeba podzielić projekt na mniejsze cele i odpowiednio obniżyć koszty.
Podejrzewam, że iteracje są bardziej związane z metodologią rozwoju, tj. Do osiągnięcia celów?
Jeśli nie ma wystarczającej specyfikacji, aby uzyskać ostateczny koszt, powiedziałbym, że należy podać "szacunek", ale praca powinna być naliczana według stawki godzinowej, ponieważ zakładam, że będą większe zmiany w decyzjach wykonane na projekcie w każdej iteracji.
Krótka odpowiedź brzmi, nie zrobisz tego. Kilka firm usługowych robi postępy, ale jest to trudna droga. Twoja zdolność do sprzedawania metodologii i przekonania klienta, który możesz dostarczyć, będzie wysoka.
Klienci nie chcą ryzykować płacenia za rozwiązanie, które nigdy nie zostanie dostarczone.
Typowe podejście do tego problemu polega na umieszczeniu kosztów "nie przekraczających". Jednakże, jeśli nie możesz kontrolować zakresu, to ty bierzesz całe ryzyko.
Podsumowując, poszukujesz klientów, którzy zarejestrowaliby się na T & M (czas i materiały), zanim Agile stanie się najnowszą modą (jestem częścią tej mody, ale to tylko jedna od dłuższego czasu) linia procesów rozwojowych, jej aspekty będą nadal rosły, a niektóre permutacje będą miały inną nazwę w ciągu kilku lat).
Ja to widać dobrze, gdy zbliżył się w 2 etapach:
faza 1) Incepcja (timeboxed)
A timeboxed okresie początkowym z klientem zakresie projektu. (Miesięczne intensywne rozpoczęcie projektu szacowanego na rok może być słuszne.) Dane wyjściowe do tej fazy to pełne zaległości dotyczące wielkości opowieści użytkowników, szacunkowe natężenie przepływu na parę deweloperów oraz parametry umożliwiające oszacowanie kosztów projektu na podstawie liczba programistów i koszty ogólne posiadania większych zespołów.
Początek dostarcza użytecznego szacunku budżetu, który można śledzić w fazie 2, jasnej wspólnej wizji zarówno dla klienta, jak i dostawcy, a także opcji dla każdej ze stron, aby odejść. To nie jest projekt z góry, historie mają wystarczająco dużo szczegółów, aby główny programista/tester przypisał względne rozmiary.
Phase 2) Dostawa (czas i materiały)
umową dostawy na podstawie czasu i materiałów, z preliminarza budżetowego na podstawie wyjść z fazy wstępnego. Zaufanie zbudowane w fazie 1 jest niezbędne do wykonania tej pracy.Ponieważ faza 1 zapewniała względne określanie wielkości całego portfela, poprzez regularne mierzenie rzeczywistego przepływu możliwe jest łatwe i częste raportowanie prognozowanego natężenia przepływu dla pozostałej części zaległości wraz z coraz dokładniejszymi szacunkami budżetu i daty dostawy. Dostawca powinien być zobowiązany do zgłaszania tych statystyk co najmniej co 2 tygodnie, z opcją dla klienta, aby odszedł w dowolnym momencie.
Płacąc za czas i materiały, klient może zmienić zakres i zaległość zaległości, a tym samym kontroluje budżet. Są one szyfrowane w celu priorytetowego potraktowania ich historii o najwyższym priorytecie/najwyższego ryzyka w pierwszej kolejności, a pozwalając im odejść, ilekroć chcą, powinny przez cały czas odczuwać dodatni zwrot z inwestycji.
zależy od metodologii, z której korzystasz. – fearofawhackplanet
Mam na myśli ogólne. czy masz bardziej szczegółowy przykład? –
To pytanie wydaje się być nie na temat, ponieważ chodzi o zarządzanie projektami, które wykracza poza bieżący zakres Stack Overflow. –