W kwestii Alistair’a Cockburn’a: jest to piewca projektowania poprzez przypadki użycia, której to teorii jakoś nie wyznaję. Uważam, że projekt udokumentowany wyłącznie przypadkami użycia jest bardzo ryzykowny bo praktycznie nie zawiera w ogóle kontekstu, nie licząc warunków początkowych i końcowych każdego przypadku użycia.

Zmiany w projekcie. Uważam, że na świecie są trzy pewne rzeczy: śmierć, podatki i zmiana wymagań ale – czym innym jest zmiana celu projektu a czym innym zmiana jego zakresu. Jeżeli normą jest zmiana zakresu w procesie zarządzania zmianą w projekcie, tak nie dopuszczam zmiany biznesowego celu projektu w trakcie jego trwania, chyba że nazwiemy to nowym projektem.

Tak więc jeśli system ma zarządzać księgarnią to projekt systemu jaki należny zrobić, będzie zawierał model biznesowy i procesy biznesowe (ale już nie bezsensowne szczegóły procedur, które zmieniają się jak w kalejdoskopie), produkty poszczególnych procesów – dokumenty, oraz wspomagające procesy, które dostarczają zasoby i tworzą (stanowią) ograniczenia. Wtedy diagramów procesów jest najwyżej kilkanaście a nie kilkaset (to chore).

Tak więc np. dla wspomnianej księgarni, po modelu biznesowym i procesowym powstanie model dziedziny, model przypadków użycia i ich scenariusze. W kwestii zmian: Co tu się może zmienić? Cel powstania faktury? Może obiekt książka? Nie! Można zmienić zakres projektu usuwając bądź dodając przypadki użycia z puli zawartej w analizie ale dobrze wykonany model dziedziny jest na to nieczuły, więc nie ma tu nic do zmiany w dokumentacji analitycznej i projekcie, tylko w zakresie projektu implementacji.

Dlatego warto mieć jednak „wodospadowo” zamkniętą analizę i projekt (HLD), by łatwo było zarządzać zmianą w procesie implementacji. Warto spojrzeć na to także z innej strony, która moim zdaniem lepiej tłumaczy potrzebę dokumentowania i to standardowymi (wspólny język) metodami: dokumentacja to zarządzanie ryzykiem!

Idealny proces wytwórczy:

1. klient dobrze opisał swoje oczekiwania i podał wszystkie istotne informacje

2. deweloper dobrze wszystko zrozumiał i określił budżet, termin i zakres projektu

3. developer od razu z głowy bez projektu napisał dobry kod – dobre oprogramowanie

Ale jak wiemy:

1. jeżeli jest ryzyko, że klient w sposób niekompletny opisze swoje oczekiwania należy wykonać analizę biznesową i ją udokumentować (powstaje model firmy klienta, który on zatwierdza)

2. jeżeli jest ryzyko, że developer nie zrozumie biznesu należy przetworzyć model biznesowy i cele biznesowe klienta na wymagania na oprogramowanie w postaci przypadków użycia z ograniczeniami

3. jeżeli jest ryzyko, że developer nie napisze od razu dobrego oprogramowania należy stworzyć model architektury, model dziedziny, komponenty i scenariusze jak komponenty oraz obiekty dziedziny, realizują przypadki użycia, jak obiekty modelu dziedziny i zrealizują interfejsy komponentów.

Powyższe zawsze można zrobić na żywioł bez kompletnego i udokumentowanego projektu jeśli nie istnieje ryzyko, że coś się nie uda. Dokumentacja stanowi także element zarządzania wiedzą. Gdy nie ma dokumentacji nowy człowiek w zespole zajmuje czas kolegów, którzy muszą mu „opowiedzieć” o projekcie, jak jest dokumentacja, czyta ją sam nie obniżając efektywność pracy kolegów.

Tak więc dla jasności: nie neguję typowej dla SCRUM czy XP wersji postępowania, a tylko wskazuje na sytuacje gdy preferowane są inne. Co do Agile podsumuję moje podejście: PMI czy Prince2 to dla mnie raczej formalny spis treści „projektu” ale dla każdego rzeczywistego projektu sam dobieram te elementy tego spisu, które mi pomogą i tak pojmuję zwinność projektową.