Pryncypia w Agile C.D.N.

Część następna, części poprzedniej...

4 - Nigdy nie idź na kompromis w kwestii Jakości

Wymaga w kierunku  zespołu:

- Ciągłego testowania w możliwe wczesnej fazie;
- Ustalenia na początku oczekiwanego poziomu jakości;
- Odpowiedniego planowania, udokumentowania i właściwego testowania;
- Zapewnienia, że jakość nie stanie się wartością zmienną;
- Wbudowywania jakości przez przeglądy z odpowiednimi osobami, wykonywane w sposób ciągły.

To pryncypium jest wspierane przez:

- Periodyczne przeglądy w cyklu życia;
- Testowanie uzyskanych produktów;
- Wczesne i integracyjne testowanie;
- Kluczowe techniki to MoSCoW i Stosowanie Okienek Czasu

Jak wiecie - Gwarancja jest JAK...ości

Znaczy to nie mniej, nie więcej jak to, że Jakość powinna spędzać wam sen z powiek. tylko ona gwarantuje długoterminowe zadowolenie interesariuszy.

5 - Buduj "przyrostowo" na solidnych podstawach

Wymaga to od zespołu :

- Ciągłego potwierdzania, że budowane rozwiązanie jest poprawne;
- Dążenia do jak najwcześniejszego dostarczenia korzyści biznesowych tam, gdzie to jest
możliwe;
- Formalnego dokonywania ponownej oceny zasadności projektu i właściwych priorytetów, po każdym przyroście;

Wspierane jest przez :


- Cykl życia - stworzenie solidnej podstawy (Wykonalność i Podstawy) przed rozwojem przyrostowym (przez Inżynierię i Eksplorację)

6 - Rozwijaj w sposób iteracyjny

Rozwój Iteracyjny pozwala zespołowi w sposób ciągły zbliżać się do odpowiedniego rozwiązania

Wymaga to od zespołu :

- Zaakceptowania faktu, że większość szczegółów pojawi się później niż wcześniej;
- Wykonania tylko wystarczającego projektowania na początku (enough design up front EDUF), po to by stworzyć solidne podstawy;
- Ciągłej kreatywności, właściwego eksperymentowania, nauki oraz ewoluowania;
- Budowania produktów za pomocą podejścia iteracyjnego - przyrostowego;
- Wbudowania (feedbacku) informacji zwrotnej od klienta w każdą iterację;
- Wykorzystania zmian, dobre rozwiązanie nigdy nie będzie ewoluowało bez nich.


Zmiana jest nieuchronna, wykorzystaj jej skutki - jest to wspierane jest przez :

- Iterację i przeglądy - zapewniają, że ewoluujące rozwiązanie jest zgodne z rzeczywistymi

potrzebami biznesu.

7 - Komunikuj się ciągle i jasno

Wymaga to od zespołu:

- Przeprowadzania Codziennych Zbiórek (daily stand-up);
- Utrzymywania zwięzłej i aktualnej dokumentacji - nie chodzi tutaj o ilość papieru, lecz zwięzłość i aktualność zapisów;
- Wykorzystywania Warsztatów Facylitowanych;
- Wspierania nieformalnej komunikacji „twarzą w twarz” na wszystkich możliwych poziomach;
- Korzystania z modelowania, prototypowania;
- Przedstawiania przyrostów rozwijanego rozwiązania często i wcześnie;
- Ciągłego zarządzania oczekiwaniami interesariuszy.

Jest to wspierane przez:

- Upoważnianie użytkowników i ich zaangażowanie; 
- Codzienne Zbiórki i Warsztaty Facylitowane;
- Jasno zdefiniowane role;

- Modele i prototypy – w celu unaocznienia rozwiązania w początkowym stadium rozwoju.

8 - Demonstruj właściwą kontrolę

Wymaga aby zespół, a przede wszystkim Kierownik Projektu i Lider Zespołu:

- Zarządzali proaktywnie;
- Ciągle mierzyli postępy poprzez dostarczanie produktów;
- Używali odpowiedniego stopnia (nie zbyt dużego, ani zbyt małego) formalizmu dla śledzenia i raportowania;
- Zapewnili, że plany i informacje o postępach były widoczne dla wszystkich;  
- Ciągle oceniali, w oparciu o cele biznesowe, zasadność dla projektu .

Wspierane jest to przez:

- Kluczową technikę : Stosowanie Okienek Czasu;
- Produkty planowania;
- Ciągłe przeglądy;

- Plany Okienek Czasu oraz Podstawy Zarządzania.


 ...that's all folks !... i pamiętajcie :

Traktuj każde odejście od zasad jako ryzyko.

Złamanie którejkolwiek z zasad stanowić powinno poważne ryzyko dla sukcesu procesu zwinnego i sukcesu projektu

Na początku każdego projektu otwarcie przedyskutuj z zespołem projektowym Pryncypia. Upewnij się, że wszyscy są one jasne i akceptowalne dla wszystkich.

Procesy - o nie, znowu ? - Przygotowanie Projektu

Procesy to działania , mogą one być realizowane po sobie (dobrze widać to w ujęciu Kaskadowym) lub równolegle (wtedy uzyskujemy wartość Lean). 

Na co to komu, otóż jest to Proces "wejściowy" - występujący przed projektem, dzięki któremu możemy zaoszczędzić sporo środków, jeśli na jego etapie unikniemy jak najwięcej błędów. Zgodnie z filozofią "odchudzonego" zarządzania - błędy wykryte we wczesnej fazie kreują najmniej kosztów na końcu.

Dzięki takiemu procesowi, jak np. Przygotowanie Projektu w PRINCE2, powinniśmy uzyskać możliwość uniknięcia realizowania nieprzemyślanych projektów. Jest to wstępne sito, które pozwoli nam zracjonalizować początkowe idee. 

Tutaj też dowiemy się, czy opisany wstępnie projekt jest wart realizacji, także otrzymamy zapewnienie, że istnieje uzasadnienie biznesowe dla zainicjowania takiego projektu.

Co nam daje jeszcze proces Przygotowanie Projektu ? Między innymi informację, o tym że :

- zweryfikowano wszelakie , różne od siebie sposoby realizacji danego projektu (łącznie z tym, żeby go nie realizować...);

- opisano role i przypisano osoby, "nawet" te z Komitetu Sterującego danym projektem;

- nie stracimy czasu na realizację czegoś co ma błędne "wstępne" założenia, np. dotyczące czasu, terminów, ograniczeń etc.;

- będziemy przeglądać doświadczenia, jak również założymy dziennik doświadczeń - czyli Lessons Learned.

Całość "ubiera się" zgrabnie w produkt zarządczy zwany nie inaczej jak : Założenia Projektu


Na końcu tej "gry wstępnej" należy postarać się o to by zaplanować etap inicjowania. W tym miejscu kończy się więc etap przed projektem.

...i ja też kończę ;)

Zdefiniowane role i obowiązki / Roles Defined.

Zdefiniowane role i obowiązki pojawiają się w każdym projekcie, jako kolejne z koniecznych pryncypiów.

Jest koniecznym i standardowym podejściem w metodologii PRINCE2, ustanowienie jasnych zakresów obowiązków, choć dopuszcza się czasem przy założeniu, że projekt jest niewielki – łączenie ról. Standard zaleca jednak by role pozostały rozdzielone w taki sposób, aby umożliwić przepływ danych i rozdział kompetencji, dając tym samym pracującym ludziom wszystkie potrzebne narzędzia do wykonywania swoich obowiązków.

Istotnym jest zdefiniowanie interesariuszy – z punktu widzenia „koncepcji ruchu” – są to ludzie, których „zawsze coś rusza”, w odniesieniu do projektu. Czyli mają na projekt wpływ lub projekt na nich wpływa – w konsekwencji wywołując ruch.

Mówi się często o TRZECH stronach interesu w projekcie :

Korzystanie z doświadczeń / Lessons Learned.

Tak jest to jedno z siedmiu pryncypiów według PRINCE2, które jest koniecznym by projekt był realizowany w zgodzie z metodyką.  W języku angielskim używa się czasem pojęcia „Lessons”, ponieważ to właśnie doświadczenia, te Lekcje z „pola walki” są najistotniejszymi dla powodzenia realizacji projektu. Jeśli już raz udało nam się przetrzeć szlaki i wykarczować las niebezpieczeństw i terminów oraz zazębiających się zadań oraz ułożyć z tego spójną drogę przez proces prowadzenia projektu. Logicznym jest, że prawdopodobnie uda nam się za drugim i trzecim razem. 

Choć praktycy powtarzają, że każdy projekt jest inny, każdy ma inne uwarunkowania. Najistotniejsze jest jednak z punktu widzenia tego pryncypium to, że dzięki doświadczeniu unikamy popełniania tych małych błędów. Ponieważ nawet największa podróż zaczyna się od pierwszego kroku. Ważnym jest by nie skręcić kostki na samym początku i uniknąć stałych niebezpieczeństw, które towarzyszą każdemu przedsięwzięciu biznesowemu.

Jeśli realizujemy mały projekt w ramach małego przedsięwzięcia, zazwyczaj korzystamy z notatnika albo innej formy bazy danych, bardziej nieformalnej. Korporacyjne podejście jest bardziej usystematyzowane. To cała gałąź „ Lessons Learned” osnuta jest w ideologię, politykę i opasłe systemy informatyczne do przechowywania danych i doświadczeń, po to by wykorzystać je podczas kolejnej działalności, kolejnego „startu” projektu. Ma to swoją drugą stronę medalu taką, że często ilość danych przerasta czytelnika / odbiorcę, co w gruncie rzeczy prowadzić może do zniechęcenia i zaniechania korzystania z takiego źródła. 

Negatywne efekty - to popełnianie tych samych błędów przy każdym projekcie, brak motywacji do poprawiania działań. 

Ruch w przypadku procedury SCRUM, Agile PM, PRINCE2, Kaskada

Więc o co chodzi z tym ruchem w PM, chodzi o to żeby będąc członkiem choćby najmniejszego zespołu projektowego  - wiedzieć gdzie się ruszać i jak poruszać. Co prawda SCRUM i Agile mówią o tym że nie należy przekładać procedur ponad podejście zdroworozsądkowe i współpracę międzyludzką, powiedzmy sobie jednak szczerze - rzadko się to udaje. Minimalny, elementarny i rzekłbym nawet funkcjonalnie opisany szkielet procedury jest wymagany, by choćby najmniejszy projekt przeprowadzić osiągając sukces. Wiadomo, że inaczej będzie określony sukces dla Agile PM, a inaczej dla PRINCE2. W ujęciu kaskadowym o sukcesie moża natomiast mówić gdy wszystkie procedury zostaną wypełnione ale jest do drugi kraniec szali, o którym dziś mniej będzie.

Jakie zatem procedury wprawią w ruch nasze projekty - na pewno "nie opasłe", tzn. lekkie i zwinne i powiewne. Nie muszą być opasłymi tomiskami, najważniejsze by spełniały swoją rolę. Chcę was przestrzec przed tworzeniem "papierologii stosowanej" bo :

• dokumenty-procedury trzeba tworzyć;
• trzeba nią zarządzać, czasem jak w przypadku zarządzania konfiguracją, potrafi to być bardzo upiorne;
• papierologię trzeba przechowywać i przypominać wszystkim by ją czytali, a to przecież NVAA ;)

Podsumowując zgrabnie - ruch w procedurze ma sens gdy procedurę da się przesunąć, poruszyć jednym małym palcem... 

So, what is all about this movement in PM, it is just a hint for you , when you are a member of even the smallest project team - to know where to move or how to move. That is true SCRUM and Agile defines its attitude to procedures in short sentence, that you shouldn't take procedures too serious, clear thoughs and interpersonal communication is far more important, but let's be honest - it is so rare to give effective succes. Small, elementary and let me say functionally defined backbone of procedure is needed, to lead even not very big project with success. It is known, that success itself will be defined differently for Agile PM, PRINCE2 and success for Waterfall attitude we may say only when all procedures will be fulfilled , but this is the other end, I won't be describing that today.
So which procedures will make our project to move  - for sure lightweight, and agile, light as breeze. these do not have to be heavy volumes, the most important is fact that they must work. I want to warn you against creation of " documentation faculty", because:

• documents - procedures must be created;

• documents must be managed, sometimes in scope of configuration management this could be creepy

• documents must be saved, reminded to everyone and this of course creates NVAA

To sum it up - movement within procedure is wise whet prcedure can be moved with your little finger...