Temat: Bądź zwinny, nie naiwny

Na wstępie przyznam, że ucieszyłem się, że i w GL znaleźć można grupę, która nawiązuje do metodyk Agile.

W tej chwili nie widzę by była to nadzwyczaj ruchliwa i popularna grupa, niemniej już teraz pozwolę sobie zadać pytania/zadania:

- trafiacie jako project manager do niedużej (10-20 osób) firmy z wieloletnim doświadczeniem; firma od paru lat stoi w miejscu, realizuje projekty za grosze, zespół jest niezadowolony a szef ma kompleks małej firmy - marzy mu się kolos z dokumentacjami inicjującymi projekt, zebraniami, analizami sensowności realizacji projektu, regulaminami, procedurami . Jako PM wiecie, że to nie tędy droga; pojawia się kwestia: jak przekonać szefa, który lubi dokumentacje, mimo, że jej nie czyta, do przejścia na zwinne metodyki prowadzenia projektów?

- jak przedstawiać mu raporty, by nie był jedyną osobą w firmie, która widzi ich sens istnienia

Temat: Bądź zwinny, nie naiwny

My w firmie stosujemy Agile i dzieki temu tworzyny oprogramowanie szybko, idealnie dostosowane do potrzeb, z minimalnym ryzykiem niepowodzenia projektu oraz w elastyczny sposob.

Proponuje abys dokladnie przestudiowal materialy:

http://jdd.proidea.org.pl/presentation/Agile.pdf

nastepnie znalazl osobe w firmie ktora to popiera i zrobil szefowi prezentacje zalet.

pzdr
BB

Temat: Bądź zwinny, nie naiwny

Witam,
Cieszę się, że spotkałem praktyka. Znam założenia technik lekkich od strony teoretycznej, przymierzam się do wdrożenia ich w swojej organizacji. Mam w związku z tym kilka pytań:

- W jaki praktyczny sposób określany jest budżet projektu, skoro przy tak krótkim harmonogramowniau na dobrą sprawę nie wiedomo, jaki jest zakres, czas wykonania a w konsekwencji koszt projektu?
- Czy macie sprawdzone sposoby nakłaniania klientów do ciągłej współpracy w ramach wykonywania projektu?

Dzięki za odpowiedź,

Pozdrawiam.

Temat: Bądź zwinny, nie naiwny

Bartosz B.:
My w firmie stosujemy Agile i dzieki temu tworzyny oprogramowanie szybko, idealnie dostosowane do potrzeb, z minimalnym ryzykiem niepowodzenia projektu oraz w elastyczny sposob.

Proponuje abys dokladnie przestudiowal materialy:

http://jdd.proidea.org.pl/presentation/Agile.pdf

nastepnie znalazl osobe w firmie ktora to popiera i zrobil szefowi prezentacje zalet.

pzdr
BB

Przepraszam, ze dopiero teraz, ale pozwole sobie skomentowac to w ten sposob:

blablabla, lorem ipsum dolor sit amet, something something something, przeczytaj w googlach.

Sory, ale agile zajmuję się już trochę czasu i wydaje mi się, że nie jest/nie była to odpowiedź na moje pytanie. Zresztą, wszyscy zawsze twierdzą, że projekty powstają szybko, na czas, mieszczą się w budżecie a ludzie chodzą szczęśliwi i wypoczęci do pracy. Tylko, że to z reguły kłamliwa statystyka, która nie sprawdza się nawet w 37signals czy Google.

- W jaki praktyczny sposób określany jest budżet projektu, skoro przy tak krótkim harmonogramowniau na dobrą sprawę nie wiedomo, jaki jest zakres, czas wykonania a w konsekwencji koszt projektu?

Przepraszam, w "takim krótkim" to znaczy w jak krótkim? Przecież projekt może zostać rozpisany np na rok, tylko będzie miał np 12 miesięcznych iteracji. A może też być krótszy, z krótszymi iteracjami. Z klientem przygotowujesz listę funkcjonalności których klient potrzebuje, rozbijasz to na kroki - iteracje, na podstawie tego widzisz, że pi razy oko wychodzi Ci x czasu. No i możesz też trafić na projekt o ustalonej cenie, wtedy już za wielkiego pola manewru nie masz :) No i zakres jest wiadomy.

Z nakłanianiem do współpracy raczej problemów nie ma, wystarczy.. zrobić prezentację zalet na początku (którą skrytykowałem wyżej) a później sami cenią sobie ten sposób współpracy, gdyż widzą co się dzieje z ich aplikacją na bieżąco. Owszem, klienta trzeba pilnować, gdyż ludzie mają tendencję do zgłaszania największej liczby poprawek do gotowego produktu, kiedy o poprawki do początkowych faz trudno, a wtedy trudno utrzymać z góry ustalony termin.

W sumie, to w tej chwili to właśnie przechodzę - klient w gotowym produkcie zwrócił uwagę na błąd użytkowy, który istniał od początku projektu. I poprawienie go teraz wiąże się z głębszą ingerencją w jądro systemu.Tomasz Staniak edytował(a) ten post dnia 15.04.07 o godzinie 01:34

Temat: Bądź zwinny, nie naiwny

- W jaki praktyczny sposób określany jest budżet projektu, skoro przy tak krótkim harmonogramowniau na dobrą sprawę nie wiedomo, jaki jest zakres, czas wykonania a w konsekwencji koszt projektu?

Przepraszam, w "takim krótkim" to znaczy w jak krótkim? Przecież projekt może zostać rozpisany np na rok, tylko będzie miał np 12 miesięcznych iteracji. A może też być krótszy, z krótszymi iteracjami. Z klientem przygotowujesz listę funkcjonalności których klient potrzebuje, rozbijasz to na kroki
- iteracje, na podstawie tego widzisz, że pi razy oko wychodzi Ci x czasu. No i możesz też trafić na projekt o ustalonej cenie,
wtedy już za wielkiego pola manewru nie masz :) No i zakres jest
wiadomy.

OK, to rozumiem. Jednak w Agile planujesz tylko na koleją iterację - iteracje są któtkie, więc planowania długofalowego nie ma. Z mojego punktu widzenia zakres nie jest określony - lista funkcjonalności to zdecydowanie nie jest zakres projektu.
Z reguły wykonujemy projekty, których realizacja jest rozstrzygana na drodze przetargu - zanim przystapimy do przetargu, musimy przygotować ofertę. Jedynym kryterium przy ocenie ofert jest cena, w związku z tym musimy bardzo dokładnie oszacować zakres i koszt projektu, żeby być konkurencyjnym a jednocześnie żeby do interesu nie dopłacać. W tym wypadku nie mogę sobie pozwolić na ocenę "na oko". Nadal uważam, że w Agile to niemożliwe, ze względu na brak dokładnej specyfikacji przed przystapieniem do realizacji projektu. W chwili obecnej, mając dobrze zrobioną specyfikację, jestem w stanie z około 10% precyzją oszacować czas i koszt projektu. Do tego dodaję rezerwę na ryzyko i zakładany zysk i mam cenę (to tak w dużym uproszceniu).
W tej chwili jakieś 40% czasu (więc w naszym przypadku kosztów projektu, bo zasobów materiałowych zużywamy w projektach niewiele) zabiera analiza funkcjonalna, efektem której jest Brief (na tym poziomie zazwyczaj powstaje oferta) a potem DIP (po wygranym przetargu). W tej fazie faktycznie bardzo mocno angażujemy klienta. Później wymagamy od niego aktywności na zakończenie każdej fazy zarządczej, w naszym przypadku najczęściej związanej z wdrożeniem kolejnych elementów systemu. Oczywiście klient ma prawo wprowadzać zmiany, zgodnie z procedurą zarządzania zmianami. O tym co, w jakim czasie i zakresie może w trakcie projektu zmieniać jest informowany przed przystąpieniem do realizacji, z tym większą uwagą podchodzi do wstępnego określenia wymagań. Zmiany w kluczowych elementach systemu wprowadzane na końcu projektu pociągają za sobą często konieczność renegocjacji kontraktu (np. w postaci dodatkowego zamówienia na wykonanie usługi), jednak klient jest tego świadomy.

Z nakłanianiem do współpracy raczej problemów nie ma, wystarczy.. zrobić prezentację zalet na początku (którą skrytykowałem wyżej) a później sami cenią sobie ten sposób współpracy, gdyż widzą co się dzieje z ich aplikacją na bieżąco.

I tu w mojej branży pojawia się problem. Projekty robimy głównie dla klientów zewnętrznych, dla których wdrożenie systemu nie jest celem strategicznym a kultura projaktowa jest bardzo niska. Radzimy sobie w różny sposób, ale moim zdaniem na tym polu moglibyśmy wiele jeszcze poprawić. Oczywiście robimy prezentacje, spiralny model implementacji, zarządzanie zmianą, rola właścieila uzasadnienia biznesowego itp, natomiast nie wyobrażam sobie, żeby dyrektor instytucji, z którą pracujemy oddelegował swoich kluczowych w tym wypadku pracowników do projektu na prawie 100% na dłuższy okres czasu.
Natomiast znajduję zastosowanie pewnych elementów XP w samym procesie produkcyjnym projektu (proces zarządczy pozostawiłbym jednak zgodnie z PRINCE-m. Podoba mi sie pomysł programowania w parach, warto też moim zdaniem, w stosunku do tego, co robimy teraz, skrócić (w ramach zdrowego rozsądku) iteracje. Znalazłem nawet ostatnio założenia metodyki XPRINCE, w której stara się połączyć XP z PRINCEM - mam do niej kilka zastrzeżeń, ale pomysł jest ciekawy.
Na potrzeby dokumentacji wewnętrznej do pewnego stopnia stanowi ją kod, natomiast nie rezygnowałbym z systemu kontroli błędów, spisywania know-how nawet w postaci prostych FAQ.
Reasumując - nie znajduję obszarów bezkrytycznego zastosowania Agile we wsystkich typach projektów IT - na pewno stanowi ciekawą propozycję dla projektów innowacyjnych, gdzie odkrywamy jakiś nowy obszar i nie wiadomo dokładnie dokąd zmierzamy. Nie umniejszając wszystkich zalet Agile, w pozostałych przypadkach zastosowanie XP jak dla mnie przynajmniej wiąże się ze zbyt dużym ryzykiem niedoszacowania projektu.

Temat: Bądź zwinny, nie naiwny

OK, to rozumiem. Jednak w Agile planujesz tylko na koleją iterację - iteracje są któtkie, więc planowania długofalowego nie ma. Z mojego punktu widzenia zakres nie jest określony - lista funkcjonalności to zdecydowanie nie jest zakres projektu.
Z reguły wykonujemy projekty, których realizacja jest rozstrzygana na drodze przetargu - zanim przystapimy do przetargu, musimy przygotować ofertę. Jedynym kryterium przy ocenie ofert jest cena, w związku z tym musimy bardzo dokładnie oszacować zakres i koszt projektu, żeby być konkurencyjnym a jednocześnie żeby do interesu nie dopłacać. W tym wypadku nie mogę sobie pozwolić na ocenę "na oko". Nadal uważam, że w Agile to niemożliwe, ze względu na brak dokładnej specyfikacji przed przystapieniem do realizacji projektu. W chwili obecnej, mając dobrze zrobioną specyfikację, jestem w stanie z około 10% precyzją oszacować czas i koszt projektu. Do tego dodaję rezerwę na ryzyko i zakładany zysk i mam cenę (to tak w dużym uproszceniu).

Witam,

Nie wydaje mi się do końca prawdą, że stosując Agile nie planujesz długoterminowo - ani w Agile Manifesto ani w wypowiedziach ludzi, którzy zajmują się Agile na poważnie nie znajdziesz takiej definicji Agile - metodyka ta jedynie tak na prawdę przedkłada pragmatykę ponad dokumentację. Chodzi bynajmniej o to by nie tworzyć stosów niepotrzebnej dokumentacji i nie ograniczać tym samym możliwości dokonywania nawet radykalnych zmian w projekcie - w firmie stosujemy wręcz religijnie Agile - i planujemy na kilka miesięcy do przodu.
W Agile nie chodzi o nie określanie zakresu funkcjonalności - chodzi o to by nie blokować możliwości zmian w nim - to, że oczekiwania klienta wraz z rozwojem projektu co do tegoż funkcjonalności się zmienią jest praktycznie pewne - sęk w tym aby łatwo takie zmiany wprowadzać - ale co oczywiste - za takie zmiany klient musi zapłacić.
Dawno już minął czas, kiedy wielkie korporacje kupowały każdy nowy software w ciemno - co powoli wymusza zmiany w mentalności - między innymi w dostosowywaniu kontraktów - przynajmniej w moim doświadczeniu, łatwiej udawało się przekonać klienta do wdrożenia mniejszej wersji pilotażowej - i rozwoju tejże - w miarę zapotrzebowania ze strony samego klienta - który moźe ograniczyć tym samym ryzyko wykonania projektu.

Temat: Bądź zwinny, nie naiwny

Jednym z kluczowych elementów zarządzania projektem jest zarządzanie zmianą. Tradycyjne metodyki na etapie planowania projektu określają, w jaki sposóbtą zmianą będzie się zarządzać. Żadna z tradycyjnych metodyk nie blokuje zmian w projekcie. Ilośc dokumentacji projektowej również tworzy się w zależności od skali projektu, choć tu metodyka określa, jakie dokumenty zarządcze powinny powstać.
Nie widzę powodu, da któego nie można by wdrażać wersji pilotażowej programu stosując tradycyjne ZP i na tej podstawie budowac dalszy software. Z punktu widzenia tradycyjnego ZP można takie podejście albo wpasować w model fazowy albo potraktować jako program projektów uzasadniając biznesowo i określając budżet i zakres dla każdego z nich. Ja osobiście skłaniałbym się do technik adaptacyjnych, gdzie łączę tradycyjne zarządzanie projektem na poziomie zarządzcym z technikami lekkimi na poziomie wykonawczym - w przypadku software bardzo fajnie to działa.
Jeśli przygotowujecie plan bazowy projektu (oczywiście na odpowiednio niskim poziomie szczegółowości), to czego w Agile, w porównaniu na przykład do PMBoK-a nie robicie (poza pisaniem dokumentacji ;-) )? Czyli, czy:

- opracowujecie ogólny harmonogram projektu
- określacie cele projektu wraz z kryteriami ich akceptacji
- określacie budżet projektu
- określacie zakres projektu (np. na poziomie celów produktowych)
- analizujecie udziałowców projektu
- tworzycie listę ryzyka i opracowujecie plany reakcji na ryzyko
- określacie w jaki sposób będziecie wymieniać informację
- określacie, kto w projekcie decyduje, co będzie a co nie będzie zrobione (struktura zespołu zarządzania projektem)
- określacie, w jaki sposób bedą wprowadzane zmiany i kto je zatwierdza bądź odrzuca

Paweł

Temat: Bądź zwinny, nie naiwny

Tomasz S.:
Na wstępie przyznam, że ucieszyłem się, że i w GL znaleźć można grupę, która nawiązuje do metodyk Agile.

W tej chwili nie widzę by była to nadzwyczaj ruchliwa i popularna grupa, niemniej już teraz pozwolę sobie zadać pytania/zadania:

- trafiacie jako project manager do niedużej (10-20 osób) firmy z wieloletnim doświadczeniem; firma od paru lat stoi w miejscu, realizuje projekty za grosze, zespół jest niezadowolony a szef ma kompleks małej firmy - marzy mu się kolos z dokumentacjami inicjującymi projekt, zebraniami, analizami sensowności realizacji projektu, regulaminami, procedurami . Jako PM wiecie, że to nie tędy droga; pojawia się kwestia: jak przekonać szefa, który lubi dokumentacje, mimo, że jej nie czyta, do przejścia na zwinne metodyki prowadzenia projektów?

- jak przedstawiać mu raporty, by nie był jedyną osobą w firmie, która widzi ich sens istnienia

To chyba nie jest łatwe pzrekonać formalistę. Ja namawiajac jednego z moich opornych klentów na swoją metodyke poprosiłem o liste dokumentów projektowych jakie sobie on życzy oraz cel każdego z nich i planowaną treść (to był straszny formalista), oszacowaliśmy pracochłonośc na kazdy dokument i wyszło na moje: powstały tylko te dokumenty, które do czegokolwiek służyły a nie wszystkie z listy Prince2. Spotkania lub weryfikacje produktów projektu było codziennie.

Dla mnie Agile to połączenie rozsądku z pragmatyką, nie robię rzeczy których celowość jest wątpliwa, nie robie tego czego nie można przewidzieć wiec na np. na początku projektu nie określam setek funkcjonalności tylko liste celów i czynności jakie należy wesprzeć systemem, do każdej pisze ogólne scenarisuze przypadków użycia i planowane postacie GUI itp. Codziennie przekazuje aktualną wersje dokuemntacji wskazując co w danym dniu napisałem i czekam na uwagi, na które reaguje natychmiast.

Tu niestety wazne jest by druga strona akcpetowała taki styl pracy.