Temat: Jak sobie radzicie z puchnięciem projektu

Chciałem Was zapytać odnoście Agile. Zgodnie z tą metodologią robimy wszystko co klient chce (oczywiście niewybiegający poza ogólne ramy projektu). Chciałem się zapytać jak sobie radzicie z taką sytuacją, że klient strasznie wymyśla coraz to nowe pomysły na dziełanie, filtry itp.

Czy gdzies notujecie to co robicie dodatkowo poza ustalony zakres?

Jak być jednocześnie "Agile" i nie dać "się zabić" klientowi?

Temat: Jak sobie radzicie z puchnięciem projektu

Jest to w technikach lekkich faktyczny problem. Właśnie przed chwilą natknąłem się na ciekawy artykuł o wymaganiach i Agile, pozwoliłem sobie nawet go skomentować:
http://cio.cxo.pl/artykuly/52963.html

Nie udało mi się dotąd znaleźć odpowiedzi na Twoje pytanie. Z mojego punktu widzenia Agile ma sens w projektach:
- innowacyjnych o proporcjonalnie dużym w stosunku do oczekiwanego wyniku budżecie
- wewnętrznych
- w takich, gdzie odbiorca zgadza się na zapewnienie ciągłości finansowania bez określenia ostatecznego kosztu (zna ktoś taki projekt ?)
- non-profit (open source ?)

W praktyce można stosować elementy Agile w procesie produkcyjnym projektu prowadzonym zgodnie z wybraną metodyką (np. skrócić iteracje, programować w parach, angażować o ile to możliwe klienta), jednak moim zdaniem ciężko uciec od ogólnej nawet specyfikacji funkcjonalnej wykonanej przed rozpoczęciem projektu. W moim przypadku stosuję typowy model fazowy projektu z PZP i DIP-em, gdzie klient wie, w którym miejscu projektu, jakie zmiany może wprowadzać - przy dobrej technologii i rozsądnej dekompozycji projektu można osiągnać całkiem niezły kompromis pomiędzy określeniem zakresu a elastycznością funkcjonalną oprogramowania. Chciałbym natomiast wdrożyć elementy Agile w samym procesie produkcyjnym oprogramowania.

Temat: Jak sobie radzicie z puchnięciem projektu

Bartosz B.:
Chciałem Was zapytać odnoście Agile. Zgodnie z tą metodologią robimy wszystko co klient chce (oczywiście niewybiegający poza ogólne ramy projektu). Chciałem się zapytać jak sobie radzicie z taką sytuacją, że klient strasznie wymyśla coraz to nowe pomysły na dziełanie, filtry itp.

Czy gdzies notujecie to co robicie dodatkowo poza ustalony zakres?

Jak być jednocześnie "Agile" i nie dać "się zabić" klientowi?

Generalnie nie jest to problem przy prawidłowym stosowaniu metodyk Agile jakie znam (XP, SCRUM, SPM). Już w Twoim pytaniu kryje się lekka sprzeczność. Mniemam, że podchodzisz do tego jak do zwykłej metodyki, z tym, że wybierasz to co Ci się podoba z metodyk Agile (iteracje?).

W tego typu metodykach, w zasadzie, nie ma takiego problemu. Każda iteracja kończy się *działającym* artefaktem (produktem) projektu. Nie ma mowy o "puchnięciu". Z definicji klient wie co mu jest potrzebne, i wie to najlepiej. Z jednej strony "zakres puchnie", z drugiej strony oddajesz coś co działa i w każdej chwili klient może powiedzieć, że "to wystarczy", kończymy projekt. Z mojej praktyki (IT) często jest tak, że klient w trakcie tworzenia systemu uświadamia sobie co mu jest potrzebne a co wcale nie...

Artur

Temat: Jak sobie radzicie z puchnięciem projektu

Artur K.:

Bartosz B.:
Chciałem Was zapytać odnoście Agile. Zgodnie z tą metodologią robimy wszystko co klient chce (oczywiście niewybiegający poza ogólne ramy projektu). Chciałem się zapytać jak sobie radzicie z taką sytuacją, że klient strasznie wymyśla coraz to nowe pomysły na dziełanie, filtry itp.

Czy gdzies notujecie to co robicie dodatkowo poza ustalony zakres?

Jak być jednocześnie "Agile" i nie dać "się zabić" klientowi?

Generalnie nie jest to problem przy prawidłowym stosowaniu metodyk Agile jakie znam (XP, SCRUM, SPM). Już w Twoim pytaniu kryje się lekka sprzeczność. Mniemam, że podchodzisz do tego jak do zwykłej metodyki, z tym, że wybierasz to co Ci się podoba z metodyk Agile (iteracje?).

W tego typu metodykach, w zasadzie, nie ma takiego problemu. Każda iteracja kończy się *działającym* artefaktem (produktem) projektu. Nie ma mowy o "puchnięciu". Z definicji klient wie co mu jest potrzebne, i wie to najlepiej. Z jednej strony "zakres puchnie", z drugiej strony oddajesz coś co działa i w każdej chwili klient może powiedzieć, że "to wystarczy", kończymy projekt. Z mojej praktyki (IT) często jest tak, że klient w trakcie tworzenia systemu uświadamia sobie co mu jest potrzebne a co wcale nie...

Artur

I wtedy dodajesz iteracje albo ja przerywasz na odpowiedzialnosc klienta.

Jeszcze jedno: nie robimy wszystkiego co klient chce, bo tak jak zauwazyl Artur: klient na starcie projektu nie wie co naprawde chce i dopiero w trakcie rozwoju zaczyna to do niego docierac. Naszym zadaniem jest natomiast wydobyc z klienta do czego bedzie danego rozwiazania uzywal i jakich efektow oczekuje. Na podstawie tego mozemy (a nawet musimy) czesc pomyslow odrzucic, inne rozdzielic na etapy i moze uzupelnic o wlasne.

Temat: Jak sobie radzicie z puchnięciem projektu

Artur K.:
Każda iteracja kończy się *działającym* artefaktem (produktem) projektu. Nie ma mowy o "puchnięciu". Z definicji klient wie co mu jest potrzebne, i wie to najlepiej. Z jednej strony "zakres puchnie", z drugiej strony oddajesz coś co działa i w każdej chwili klient może powiedzieć, że "to wystarczy", kończymy projekt.

To jest jasne i bardzo mi się w Agile podoba. Jednak mam właśnie okazję obserwować z zzewnątrz na szczęście projekt, w którym klienta nie ma zamiaru powiedzieć "dosyć". Projekt (swoją drogą bardzo ciekawy) już dawno przekroczył czas i budżet i zaczyna zarzynać organizację. Wiem, że to jest błąd na poziomie planowania strategicznego - należało się zastanowić nad finansowaniem takiego projektu, jednak w przypadku Agile niestety istnieje takie niebezpieczeństwo.
Ja dodatkowo cały czas mam problem z podaniem ceny przed przystąpieniem do realizacj (przetarg) a to bez dokładnego zakresu bardzo trudne.
Nie zgadzam się też z tezą, że klient na początku projektu nie wie, czego chce. Oczywiście, że to wie, tylko najprawdopodobniej nie potrafi tego wyrazić i opisać. Na szczęście jest cała masa narzędzi - chociażby model procesów, które ma automatyzować oprogramowanie, żeby z dobrym pzrybliżeniem tę wiedzę od niego wyciągnąć. A to razem z makietami i prototypami można zrobić przed uruchomieniem projektu a później te działania wkalkulowac w jego koszt.Paweł S. edytował(a) ten post dnia 02.05.07 o godzinie 20:46

Temat: Jak sobie radzicie z puchnięciem projektu

Ale macie zdefiniowane jakieś User Stories, Product Backlog czy coś podobnego? Jeśli tak, to nie powinno być problemu.

Temat: Jak sobie radzicie z puchnięciem projektu

Artur K.:

Generalnie nie jest to problem przy prawidłowym stosowaniu metodyk Agile jakie znam (XP, SCRUM, SPM). Już w Twoim pytaniu kryje się lekka sprzeczność. Mniemam, że podchodzisz do tego jak do zwykłej metodyki, z tym, że wybierasz to co Ci się podoba z metodyk Agile (iteracje?).

Hmm, ciekawe spostrzeżenie, zawsze staram się "iterować" projekty ale szukam sposubu na walkę z puchnięciem projektu (co się wiąże z podejściem Agile)

W tego typu metodykach, w zasadzie, nie ma takiego problemu. Każda iteracja kończy się *działającym* artefaktem (produktem) projektu. Nie ma mowy o "puchnięciu". Z definicji klient wie co mu jest potrzebne, i wie to najlepiej. Z jednej strony "zakres puchnie", z drugiej strony oddajesz coś co działa i w każdej chwili klient może powiedzieć, że "to wystarczy", kończymy projekt. Z mojej praktyki (IT) często jest tak, że klient w trakcie tworzenia systemu uświadamia sobie co mu jest

Dokładnie tak. Zazwyczaj w I iteracji klientowi uświadamiamy dopiero tak naprawde co może od nas dostac i kolejne iteracje puchą niemiłosiernie. Ważne jest jeszcze to że zaczynając projekt stosunkowo dokładnie opisuję 1 iterację a kolejne jedynie ogólnie uzgadniam z klientem - wycenę oczywiście przedstawiam za całość projektu i rozbijam go na transe płatności po każej iteracji. Szukam sposobu na uniknięcie tego puchnięcia kolejnych iteracji - wiem, że to może być cieżkie.

Temat: Jak sobie radzicie z puchnięciem projektu

Jak zwykle odpowiedź staje się łatwa, gdy do równania z zakresem doda się czas i pieniądze. Do tego kluczowe jest również, by klient jak najszybciej zaczął produkcyjnie wykorzystywać wytwarzany system (bo dopiero wtedy zaczyna w 100% rozumieć co i na kiedy jest dla niego ważne).

Zalecałbym podejście takie, w którym:
1) początkowo określamy minimalny zakres funkcjonalny niezbędny do wdrożenia
2) przed osiągnięciem zakresu z p. 1 grzecznie rejestrujemy nowe / zmienione wymagania, ale realizujemy je tylko wtedy, gdy:
- ich brak w początkowym zestawie był błędem i uniemożliwi wdrożenie
- mają niedodatni koszt (czyli są do zrobienia praktycznie za darmo, albo wręcz obniżają koszty / skracają czas)
3) od momentu wdrożenia klient wskazuje kolejność wdrażania wszelkich pozostałych i nowych wymagań, zaś wykonawca mówi na kiedy i za ile je dostarczy.

P. 3 jest iteracyjny i jest pierwszą skuteczną pętlą sprzężenia zwrotnego (uczenia), w której klient ujawnia swoje rzeczywiste i stopniowo coraz lepiej przemyślane priorytety, zaś wykonawca ujawnia koszt & czas wykonania jednostki funkcjonalności.

O ile klient ponosi jakieś koszty funkcjonowania projektu (choćby koszt zaangażowania własnego personelu) i współdecyduje o czasie, w którym będą mu dostarczone poszczególne funkcjonalności, to nie ma zagrożenia, że projekt nigdy nie skończy.

Temat: Jak sobie radzicie z puchnięciem projektu

Bartosz B.:

Artur Karazniewicz:
Generalnie nie jest to problem przy prawidłowym stosowaniu metodyk Agile jakie znam (XP, SCRUM, SPM). Już w Twoim pytaniu kryje się lekka sprzeczność. Mniemam, że podchodzisz do tego jak do zwykłej metodyki, z tym, że wybierasz to co Ci się podoba z metodyk Agile (iteracje?).

Hmm, ciekawe spostrzeżenie, zawsze staram się "iterować" projekty ale szukam sposubu na walkę z puchnięciem projektu (co się wiąże z podejściem Agile)

Czyli za duży zakres :-) Myślę, że musisz klienta zmusić do lepszego nadawania priorytetów. Polecam metodę MoSCoW, czyli:

Must be done
Should be done
Could be done
Will not be doneŁukasz Stilger edytował(a) ten post dnia 18.11.07 o godzinie 20:58

Temat: Jak sobie radzicie z puchnięciem projektu

Świetne :)

Temat: Jak sobie radzicie z puchnięciem projektu

Bartosz B.:
Chciałem Was zapytać odnoście Agile. Zgodnie z tą metodologią robimy wszystko co klient chce (oczywiście niewybiegający poza ogólne ramy projektu).

Otóż chyba nie. Dokładnie opisujemy wymagania a sposób ich wykonania moze ulegać zmianie. Lista życzeń, np. "system ma wystawiać faktury" nie ulega u mnie zmianie, zmianie może ulec sposób realziacji, no i nie robie dokumentow nie wykorzytywanych.

Chciałem się zapytać jak sobie radzicie z taką sytuacją, że klient strasznie wymyśla coraz to nowe pomysły na dziełanie, filtry itp.

To efekt złej analizy i zbyt ogólnych wymagan...

Czy gdzies notujecie to co robicie dodatkowo poza ustalony zakres?

Jak definiujesz zakres?

Jak być jednocześnie "Agile" i nie dać "się zabić" klientowi?

Ja robie tak:
- Analiza biznesowa, analiza i lista wymagań, architektura systemu: tu Agile Modeling
- Mając wymagania następuje impelementacja to już Agile Project Management

Moim zdaniem nalezy ściśle rozdzielić etap opisu tego co nalezy wykonac od etapy implementacji tego wtedy klient niczego już nie wymyśla.

Temat: Jak sobie radzicie z puchnięciem projektu

Dobrym pomyslem jest stworzenie nie tylko listy wymagan, ale tez listy, ze tak powiem, rzeczy ktorych program nie ma robic.
Z jednej strony zmusza to klienta do rzeczywistego zastanowienia sie nad swoimi wymaganiami/potrzebami, z drugiej strony pozwala lepiej zaplanowac architekturę systemu.

Temat: Jak sobie radzicie z puchnięciem projektu

Krzysztof Koźmic:
Dobrym pomyslem jest stworzenie nie tylko listy wymagan, ale tez listy, ze tak powiem, rzeczy ktorych program nie ma robic.
Z jednej strony zmusza to klienta do rzeczywistego zastanowienia sie nad swoimi wymaganiami/potrzebami, z drugiej strony pozwala lepiej zaplanowac architekturę systemu.

Bardzo słuszna uwaga, ja np. radzę sobie z tym tak, że na bazie mapy procesów opisuje wątki, które system mam obsługiwac i zaznaczam, że "żadnego nowego pomysłu z poza listy wątków nie implementujemy w tej wersji systemu".