Przez całe dziesięciolecia kształcono nowe pokolenia informatyków nauczając twardych metodyk wytwarzania oprogramowania, co parafrazując obrazek wiszący nad gabinetem byłego Prezydenta Clintona można określić jako "Po pierwsze dokumentacja, durniu!". Rasowy informatyk da bardzo proste rozwiązanie problemu wskazanego w poprzedniej notce - "trzeba było lepiej zdefiniować wymagania - napisać więcej dokumentacji".
No tak, budując samochód, powinniśmy już na samym początku doskonale wiedzieć, czego chcem, bo późniejsze zmiany mogą być bardzo kosztowne, poprzez ciągłe wracanie do fundamentów i wchodzenie po schodkach metodyki twardej. No to przewidujemy:
Jak widać powyżej, informatycy "kochają" (w cudzysłowie) dokumentację, która jest rzekomym remedium na wszelkie problemy z tworzonym systemem (samochodem). Gdy coś nie działa, zawsze można zwalić na "złą" lub "niepełną" dokumentację, na podstawie której powstawał. Ośmielę się więc zapytać, czy taka "pełna" (w cudzysłowie) dokumentacja jest w stanie odzwierciedlić wszystkie elementy systemu? Czy przy takiej "pełnej" dokumentacji informatyk, a już tym bardziej klient jest w stanie zapamiętać wszystkie jej aspekty aby dyskutować ją?
Spójrzmy na system jeszcze z innego punktu widzenia. Otóż tworząc go, będziemy zmuszeni podejmować szereg różnego rodzaju decyzji - dla uproszczenia bardzo prostych - TAK/NIE. Przykładowo: czy samochód z aluminium czy metalu?
Na obrazku powyżej widzimy drzewko decyzyjne złożone z 5 pytań, co stanowi 2^5 = 32 różne ścieżki rozwoju systemu. Przy 100 pytaniach powstają 2^100 = 1.267.650.600.228.230.000.000.000.000.000 możliwe drogi. Czy można te drogi przewidzieć już na etapie definiowania wymagań, aby wybrać najlepszą z nich?
Nawet "ciężcy" informatycy zauważyli, że dokumentacja nie spełnia dobrze swojej roli, gdy jest jej za dużo. Powstały systemy CASE, powstały pomysły na diagramy UML. Generalnie pojawiły się idee, aby mniej pisać (bo tego i tak nikt nie przeczyta), a więcej rysować, bo ponoć obraz pokaże więcej niż tysiąc słów.
Jednakże z obrazami jest trochę tak jak z artystycznymi tekstami Wiedźmy Margo - każdy może znaleźć tam coś dla siebie, przeczytać i zrozumieć po swojemu. Jedni zobaczą na obrazku powyżej młodą, a inni starszą panią.
No dobrze. Wyobraźmy sobie genialnych programistów i genialnych klientów, którzy się świetnie rozumieją... a do tego wyibraźmy sobie genialną dokumentację, która odzwierciedla cały system*
Trzeba jeszcze do tego uwzględnić warunki biznesowe, w których działa klient, a te warunki się zmieniają, np. w trakcie tworzenia oprogramowania mogą się zmienić przepisy podatkowe, firma klienta może się przebranżowić lub po prostu rozrosnąć i utworzyć nowe oddziały czy oddzielny departament logistyki, co powinno być uwzględnione. Co wtedy? Ano wtedy wracamy do etapu pierwszego i zmieniamy wymagania (tworząc dokumentację), następnie zmieniamy projekt (tworząc dokumentację), po czym zmieniamy kod programu (dokumentując go oraz jego zmiany na każdym kroku), na końcu testujemy (tworząc nową dokumentację do nowych, innych testów). Czy widać już, że taki proces jest pracochłonny i kosztowny? Ano jest.
Czy taki proces jest jedynym możliwym procesem zapewniającym jakość tworzonego systemu? Ano niezupełnie. W 2001 roku znamienite postacie świata informatyki ogłosiły Manifest Zwinności: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, który spowodował odwrót z kierunku metodyk twardych w kierunku metodyk miękkich. Mówiąc obrazowo, zamiast fundament na fundamencie budować ogromne budowle, niczym indianie stawiamy szybkie do złożenia namioty, a jak trzeba to zwijamy i stawiamy w innym miejscu lub zmieniamy jego formę - a wszystko to zgodnie z życzeniami klienta.
W kolejnej notce opiszę na podstawie przykładów z życia, jak Agile Manifesto może wpłynąć na proces wytwarzania oprogramowania. A poniżej jego treść:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
*) to taka mała sprzeczność - dokumentacja nie może odzwierciedlać całego systemu, bo nigdy nie będzie pełnym systemem. Tylko system jest realny i sam siebie odzwierciedla w 100%. Model systemu tylko w pewnym stopniu przybliża ten system. Nie istnieje więc model idealny.
Komentarze
Pokaż komentarze (2)