• 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ąć.

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

- Zmiany w zespole

- Zmiany poza zespołem

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

Wzajemne powiązania ze są wymagań

Wkradające się wymagania

Zapominanie o koszcie, ryzyku czy priorytecie

Zwięzła dokumentacja

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.

- 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

- 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"

Strategia użyteczności

Strategia ewolucji

Heroiczne zespoły

Dynamiczna infrastruktura

• 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

• 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

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

Gotowość

Przejrzystość

Automatyzacja

Testowalność