ISO, PRINCE2 są na poziomie który pozostawia bardzo dużą swobodę jeżeli chodzi o samo tworzenie oprogramowania. Ĺšle zrozumiane i używane mogą jedynie zaszkodzić, jak wszystko zresztą.

Przede wszystkim należy poruszyć sprawę co osiągać mamy przez dokumenty. Uważam że kod nie jest naturalnym sposobem przekazywania informacji. Kod powinien być zwięzły, minimalistyczny wręcz. A kod bez komentarzy nadaje się do wyrzucenia.
Zmierzam do tego że jeżeli designer nie potrafi napisać dokumentu opisującego to jak zabierze się do rozwiązania problemu, to prawdopodobnie problemu nie rozumie, nie jest w stanie oszacować czasu jaki jest potrzebny na realizację itd. I, moim zdaniem, podstawowe zagadnienia można wyrazić zdecydowanie szybciej w języku naturalnym.

A co do metodologii to natknąłem się ostatnio na Meeting Driven Development ;)

Co do jednego się nie zgodzę… dokumentów nie trzeba pisać, a przynajmniej nie takich, z którymi się do tej pory spotkałem, bo jak dla mnie były stratą czasu i ich jedyną funkcją było zasłonięcie stosem kartek braku dobrego podejścia do wytwarzania oprogramowania. Być może taki dokument należy nawet do artefaktów zalecanych przez RUP, PRINCE2 czy normy ISO, tylko co z tego, jeśli te metodyki pozostają jedynie hasłami na papierze. Osobiście nie zaryzykowałbym stwierdzenia, że dobrze wdrożony RUP jest gorszy od XP. Problem polega na tym, że w Polsce częściej jednak wybiera się nie wdrażanie niczego i udawanie profesjonalnego podejścia, a to już należy rozpatrywać w kategoriach patologii.

Twój komentarz natchnął mnie jedną myślą. Wspomniałeś o RUP jako o dorosłym procesie i posiadaniu np. certyfikatu jakości ISO. Faktycznie mam wrażenie, że tego typu metodyki są kojarzone z pewną dojrzałością, a Agile kojarzy się raczej z chaosem. Ciekawe jak wyglądałoby w Polsce zdobycie certyfikatu ISO:9001 na bazie procesu z rodziny agile. Wydaje się to dość ciekawe zagadnienie, na które na pewno zwrócę uwagę.

Jest jeszcze sprawa dokumentacji projektowej, czyli pomniejszych specyfikacji, których to klient może sobie zażyczyć “bo tak”, albo gdy część systemu ma być reużytkowalna, wystawiać interfejsy dla systemów dostarczanych przez innych dostawców.
Tak więc pisać i jeszcze raz pisać dokumenty trzeba. Bo to że klient życzy sobie nagle pełną transparentność co do dokumentacji nie powinno oznaczać że wywracamy cały proces do góry nogami. Sądzę że oparcie się na modelowaniu i odwlekanie rozpoczęcia kodowania jak najadalej ma duże zalety.
A konkret: w 6-miesięcznym projekcie kod (poza prototypikami) pojawił się po dwóch miesiącach i wcale uważam żebyśmy byli z tego powodu gorzej ustawieni, wręcz przeciwnie. Wcześniej rozmowy z klientem były oparte na sprawdzaniu scenariuszy, omawianiu interfejsów do zewnętrznych systemów.

Zaczynam głośno myśleć i przynudzać :) Wszystko oczywiście zależy od okoliczności. Akurat teraz moim zmartwieniem jest też jak polepszyć jakość produkowanej dokumentacji, bo jest niezbędnym składnikiem systemu.

Co do kwestii specyfikacji, to piętnuję tutaj coś co częściej nasi klienci nazywają specyfikacją, a co staje się załącznikiem do umowy. Ten dokument ma dla bardzo małą wartość bo zwykle ani nie zapewnia dostatecznie dużej dozy technicznej ścisłości, ani niej jest dostatecznie zrozumiały na klienta mimo, że paradoksalnie przy podpisywaniu umowy i firma IT i klient twierdzą zupełnie coś innego i zgodnie podpisują ten dokument jako “wspólny pogląd na system” :-) Co do specyfikacji w sensie projektowej jak najbardziej, chociaż uważam, że nie należy z tym zbyt mocno przesadzać. Sam jak już zacznę to czasem ciężko mi się powstrzymać a potem część jest do kosza.

Nie mogę się zgodzić z jednym.
Odnieść można wrażenie że sugerujesz pominięcie budowania (szczegółowej) specyfikacji i rozpoczęcie kodowania po (mniej niż) tygodniu od pierwszego spotkania z klientem. Jak dla mnie “iteracja zerowa” trwająca miesiąc to wcale nie jest dużo przy średnim projekcie (6 miesięcy, kilkunastu developerów).
Zwłaszcza że początkowo angażuje się tylko 2-4 osoby do rozkręcenia przedsięwzięcia.
Budowanie specyfikacji wcale nie musi polegać na zgadywaniu. Może opierać się na budowaniu scenariuszy działania systemu, przechodzeniu ich razem z klientem (artykuł zakłada że udaje się go przekonać do uczestnictwa), pokazywania prototypów interfejsu użytkownika - zdolny programista potrafi budować takie rzeczy w prawie równolegle do tego jak mu się je opisuje, można nawet zacząć od tablicy i mazaka.
Zresztą, po co mam się rozpisywać i zabierać czytelników np. “The Object Primer”.
Nawet jeżeli klient nie uczestniczy na bieżąco, to zbudowane w początkowej fazie modele pomagają wykryć mnóstwo nieścisłości, zadać odpowiednie pytania i potem usprawniają produkcję.

pozdrawiam,
Jacek