AllTopics

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

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Scrum Master

    Dokumentacja jest wartościowa tylko wtedy gdy ktoś potem z niej korzysta, a nie jest sztuką dla sztuki 😉

    1. Jarosław Żeliński

      Innego przypadku nie biorę pod uwagę, jednak dostawca podpisujący umowę na wykonanie (dostarczenie) oprogramowania nie może z niej nieskorzystać :).

Możliwość dodawania komentarzy nie jest dostępna.