![AllTopics](https://it-consulting.pl//wp-content/gallery/topics/thumbs/thumbs_AllTopics.gif)
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ą.
Dokumentacja jest wartościowa tylko wtedy gdy ktoś potem z niej korzysta, a nie jest sztuką dla sztuki 😉
Innego przypadku nie biorę pod uwagę, jednak dostawca podpisujący umowę na wykonanie (dostarczenie) oprogramowania nie może z niej nieskorzystać :).