W kwe­stii Alistair’a Cockburn’a: jest to piew­ca pro­jek­to­wa­nia poprzez przy­pad­ki uży­cia, któ­rej to teo­rii jakoś nie wyzna­ję. Uważam, że pro­jekt udo­ku­men­to­wa­ny wyłącz­nie przy­pad­ka­mi uży­cia jest bar­dzo ryzy­kow­ny bo prak­tycz­nie nie zawie­ra w ogó­le kon­tek­stu, nie licząc warun­ków począt­ko­wych i koń­co­wych każ­de­go przy­pad­ku użycia.

Zmiany w pro­jek­cie. Uważam, że na świe­cie są trzy pew­ne rze­czy: śmierć, podat­ki i zmia­na wyma­gań ale – czym innym jest zmia­na celu pro­jek­tu a czym innym zmia­na jego zakre­su. Jeżeli nor­mą jest zmia­na zakre­su w pro­ce­sie zarzą­dza­nia zmia­ną w pro­jek­cie, tak nie dopusz­czam zmia­ny biz­ne­so­we­go celu pro­jek­tu w trak­cie jego trwa­nia, chy­ba że nazwie­my to nowym projektem.

Tak więc jeśli sys­tem ma zarzą­dzać księ­gar­nią to pro­jekt sys­te­mu jaki należ­ny zro­bić, będzie zawie­rał model biz­ne­so­wy i pro­ce­sy biz­ne­so­we (ale już nie bez­sen­sow­ne szcze­gó­ły pro­ce­dur, któ­re zmie­nia­ją się jak w kalej­do­sko­pie), pro­duk­ty poszcze­gól­nych pro­ce­sów – doku­men­ty, oraz wspo­ma­ga­ją­ce pro­ce­sy, któ­re dostar­cza­ją zaso­by i two­rzą (sta­no­wią) ogra­ni­cze­nia. Wtedy dia­gra­mów pro­ce­sów jest naj­wy­żej kil­ka­na­ście a nie kil­ka­set (to chore).

Tak więc np. dla wspo­mnia­nej księ­gar­ni, po mode­lu biz­ne­so­wym i pro­ce­so­wym powsta­nie model dzie­dzi­ny, model przy­pad­ków uży­cia i ich sce­na­riu­sze. W kwe­stii zmian: Co tu się może zmie­nić? Cel powsta­nia fak­tu­ry? Może obiekt książ­ka? Nie! Można zmie­nić zakres pro­jek­tu usu­wa­jąc bądź doda­jąc przy­pad­ki uży­cia z puli zawar­tej w ana­li­zie ale dobrze wyko­na­ny model dzie­dzi­ny jest na to nie­czu­ły, więc nie ma tu nic do zmia­ny w doku­men­ta­cji ana­li­tycz­nej i pro­jek­cie, tyl­ko w zakre­sie pro­jek­tu implementacji.

Dlatego war­to mieć jed­nak ​„wodo­spa­do­wo” zamknię­tą ana­li­zę i pro­jekt (HLD), by łatwo było zarzą­dzać zmia­ną w pro­ce­sie imple­men­ta­cji. Warto spoj­rzeć na to tak­że z innej stro­ny, któ­ra moim zda­niem lepiej tłu­ma­czy potrze­bę doku­men­to­wa­nia i to stan­dar­do­wy­mi (wspól­ny język) meto­da­mi: doku­men­ta­cja to zarzą­dza­nie ryzykiem!

Idealny pro­ces wytwórczy:

1. klient dobrze opi­sał swo­je ocze­ki­wa­nia i podał wszyst­kie istot­ne informacje

2. dewe­lo­per dobrze wszyst­ko zro­zu­miał i okre­ślił budżet, ter­min i zakres projektu

3. deve­lo­per od razu z gło­wy bez pro­jek­tu napi­sał dobry kod – dobre oprogramowanie

Ale jak wiemy:

1. jeże­li jest ryzy­ko, że klient w spo­sób nie­kom­plet­ny opi­sze swo­je ocze­ki­wa­nia nale­ży wyko­nać ana­li­zę biz­ne­so­wą i ją udo­ku­men­to­wać (powsta­je model fir­my klien­ta, któ­ry on zatwierdza)

2. jeże­li jest ryzy­ko, że deve­lo­per nie zro­zu­mie biz­ne­su nale­ży prze­two­rzyć model biz­ne­so­wy i cele biz­ne­so­we klien­ta na wyma­ga­nia na opro­gra­mo­wa­nie w posta­ci przy­pad­ków uży­cia z ograniczeniami

3. jeże­li jest ryzy­ko, że deve­lo­per nie napi­sze od razu dobre­go opro­gra­mo­wa­nia nale­ży stwo­rzyć model archi­tek­tu­ry, model dzie­dzi­ny, kom­po­nen­ty i sce­na­riu­sze jak kom­po­nen­ty oraz obiek­ty dzie­dzi­ny, reali­zu­ją przy­pad­ki uży­cia, jak obiek­ty mode­lu dzie­dzi­ny i zre­ali­zu­ją inter­fej­sy komponentów.

Powyższe zawsze moż­na zro­bić na żywioł bez kom­plet­ne­go i udo­ku­men­to­wa­ne­go pro­jek­tu jeśli nie ist­nie­je ryzy­ko, że coś się nie uda. Dokumentacja sta­no­wi tak­że ele­ment zarzą­dza­nia wie­dzą. Gdy nie ma doku­men­ta­cji nowy czło­wiek w zespo­le zaj­mu­je czas kole­gów, któ­rzy muszą mu ​„opo­wie­dzieć” o pro­jek­cie, jak jest doku­men­ta­cja, czy­ta ją sam nie obni­ża­jąc efek­tyw­ność pra­cy kolegów.

Tak więc dla jasno­ści: nie negu­ję typo­wej dla SCRUM czy XP wer­sji postę­po­wa­nia, a tyl­ko wska­zu­je na sytu­acje gdy pre­fe­ro­wa­ne są inne. Co do Agile pod­su­mu­ję moje podej­ście: PMI czy Prince2 to dla mnie raczej for­mal­ny spis tre­ści ​„pro­jek­tu” ale dla każ­de­go rze­czy­wi­ste­go pro­jek­tu sam dobie­ram te ele­men­ty tego spi­su, któ­re mi pomo­gą i tak poj­mu­ję zwin­ność projektową.