Procesy, a marsze ku klęsce

czyli co robić kiedy już się pali

Agenda:

• Metoda “triage”

• Znaczenie zarządzania wymaganiami

• Procesy formalne, a nieformalne

• "Dosyć dobre" oprogramowanie

• Najlepsze i najgorsze praktyki

• Koncepcja “codziennego budowania”

• Zarządzanie ryzykiem

Podsumowanie

Metoda “triage”

1

Skąd pochodzi słowo i co oznacza

Metoda “triage”

Co daje jej stosowanie

zrobić koniecznie
należy zrobić
ewentualnie zrobić

Metoda “triage”

Podział ze względu na priorytet:

Kluczowe w marszach ku klęsce:

Metoda “triage”

• niektórych wymagań nie da się w ogóle zrealizować,

• obowiązuje znana zasada 80-20 - czyli można uzyskać 80% funkcjonalności systemu realizując 20% wymagań,

• użytkownik często zaczyna korzystać z systemu szybciej (zasada 80-20) i przestaje dalej interesować się postępami

• ważne, aby wiedzieć od których wymagań zacząć.

Metoda “triage”

Niezależnie od typu kierownika każdy z nich ostatecznie musi

renegocjowac ostateczny termin - często jest to niemożliwe ze względu na potrzeby banku na system,

renegocjowac wymagania stawiane systemowi - jest bardzo trudne ale przynosi najlepsze efekty

Znaczenie zarządzania wymaganiami

2

Trudności związane z zarządzaniem wymaganiami

- Konflikty dotyczące podziału ważności wymagań

- Zmiany w zespole

- Zmiany poza zespołem

- Chwila prawdy. Zmierzamy ku klęsce...

Natura Wymagań w czasie klęski

Wzajemne powiązania ze są wymagań

Wkradające się wymagania

Zapominanie o koszcie, ryzyku czy priorytecie

Zwięzła dokumentacja

procesy formalne, a nieformalne

3

procesy formalne, a nieformalne

Nie należy uczyć się nowych metod pracy przy projekcie zmierzającym ku klęsce

Nowe metody formalne powinny być wprowadzone jako element długoterminowej strategii firmy.

Konsekwencje wprowadzania skomplikowanych procesów formalnych...

“Dość dobre” oprogramowanie

4

"Dość dobre"... czyli jakie?

- Pomyślne zakończenie projektu nie jest jednoznaczne ze spełnieniem wszystkich wymagań.

- Bezwzględne dążenie do najlepszej jakości.

- Wymagania użytkowników vs aspiracje programistów

Dlaczego Nie wychodzi dostarczanie dobrego oprogramowania?

- Określamy jakość wyłącznie na podstawie wad.

- Przyjmujemy, że mniej wad to lepsza jakość.

- Często definiujemy jakość projektu tylko raz.

- Nie doceniamy nieliniowych zależności takich parametrów jak wielkość personelu, harmonogram, budżet

- Ignorujemy dynamikę procesów.

- Ignorujemy "czynniki miękkie"

Co można zrobić, żeby być bliżej "dość dobrego" oprogramowania?

Strategia użyteczności

Strategia ewolucji

Heroiczne zespoły

Dynamiczna infrastruktura

Najlepsze i najgorsze praktyki

5

• Wiedza zespołu ponad wiedzę konsultantów spoza organizacji

• Uzgodnienie łączy

• Dzielenie kamieni milowych na mniejsze,

• Oceniajmy się wzajemnie podczas pracy

• Dokumentacja, która pozwoli uczyć się na wcześniejszych błędach

• Dbanie o kod źródłowy i wczesne wyszukiwanie błędów

Podstawowe najlepsze praktyki:

• Nie ma podobnych projektów

• Ostrożnie z nowymi technologiami

• Blokowanie zespołu, przez czynniki niezależne

• "Magiczne narzędzia" narzucane przez dyrekcję

• Bezpośrednio kontroluj stan projektu

Najgorsze Praktyki praktyki:

• Nie myśl, że uda Ci się nadrobić opóźnienie bez zmniejszenia funkcjonalności

Czy macie aktualną, wiarygodną siatkę działań oraz szczegółowy podział prac?
Czy macie aktualny wiarygodny harmonogram i budżet?
Czy wiecie, za dostarczenie jakich programów odpowiadacie?
Czy możecie wymienić dziesięć największych zagrożeń projektu?
Czy wiecie, o ile procentowo skrócono Wasz harmonogram?
Jaka jest szacunkowa wielkość oprogramowania, które macie dostarczyć? Jak ją obliczono?
Czy wiecie, jaki procent zewnętrznych łączy jest poza Waszą kontrolą?
Czy Wasza załoga ma wystarczające wiadomości z dziedziny, której dotyczy projekt?
Czy wiecie, ile osób jest potrzebnych do wykonania poszczególnych zadań w zaplanowanym czasie?