Metodyki tworzenia oprogramowania, a problem komunikacji

Szukam źródeł, ale też informacji z "drugiej ręki". Problem jest następujący:

"Jak dane metodyki radzą (albo nie radzą) sobie z problemem komunikacji międzyludzkiej?"

Dla przykładu:
UML - zakłada, że język naturalny można sfromalizować (diagramy + sfromalizowany ich opis). Oczywiście traci się bogactwo na rzecz jednoznaczności.
Agile - zakłada, że 100% zrozumienie między ludźmi jest niemożliwe, więc zamiast tworzenia sformalizowanego opisu oprogramowania sugeruje tworzenie samego oprogramowania (prototypów).

Dla ścisłości - UML jest językiem modelowania, nie metodyką. Raczej tam powinien być RUP, ale UML jest lepiej kojarzony i niejako kształt metodologii determinuje(?)

Niestety na tych przykładach moja wiedza się kończy. Nie chcę gotowej rozprawki. Byłbym wdzięczny za podpowiedź: metodyka, książka (rozdział), link. Lub coś co wiecie (nawet zasłyszane - i tak będzie musiał znaleźć źródło);

Potrzebuję po prostu sposobu, żeby ugryźć temat. Takiego stołka, żeby zacząć się wspinać na moją "learning curve" ;)

Extreme Programming

To to jest chyba najpopularniejsze wśród studentów na wieczór przez zaliczeniem ;)

Wiem, somekind, dlaczego tak myślisz... sam często dogryzam przy okazji podobnych postów. Prawda - jestem studentem, ale już po sesji i na obecnych studiach ani nie miałem ani nie będę miał przedmiotu, który o tym traktuje.

Prawda jest taka, że przygotowuję materiały do pracy magisterskiej. Wiem, że mógłbym być mniej leniwy, pójść do biblioteki i poprosić o każdą książkę, która w tytule ma "Metodyka", ale raczej ich wszystkich nie przeczytam ;)
Dlatego wystarcza mi informacja w styku "Było coś w książce, którą czytałem, w tytule było coś z zarządzaniem projektami, a autor Framkowski, Franciszewski, albo coś innego z franek" - to jest dla mnie trop ;)

@EgonOlsen: Dzięki: mam jednak pytanie, jeśli w tej dziedzinie się orientujesz: z tego co doczytałem to XP należy do metodyk Agile. I tak naprawdę wszystkie Agile (XP, Xprince, Scrum itdd) to de facto "podejście iteracyjne" zakładające częsty kontakt z klientem i ścisłą współpracę zespołu projektowego (w odróżnieniu od "wodospadu" czy "spirali"). Mam rację?

@poniżej: Ok, widać nie pojąłem sensu Twojego postu. [soczek]

@id02009 - wcale nie miałem zamiaru Ci niczym dogryzać, mój post dotyczył postu Egona. Chodziło mi o to, jak szybko i w jaki sposób nieraz na studiach wykonywało się projekty na wieczór przed zaliczeniem - stąd emotka.

A co do Twojego problemu, to Cię rozumiem, ale nie bardzo pomogę. Nie znam żadnych metodyk poza tymi dwoma/trzema, o których już tu była mowa.

id02009 napisał(a)

@EgonOlsen: Dzięki: mam jednak pytanie, jeśli w tej dziedzinie się orientujesz: z tego co doczytałem to XP należy do metodyk Agile. I tak naprawdę wszystkie Agile (XP, Xprince, Scrum itdd) to de facto "podejście iteracyjne" zakładające częsty kontakt z klientem i ścisłą współpracę zespołu projektowego (w odróżnieniu od "wodospadu" czy "spirali"). Mam rację?

Tez ale glownie chodzi o to ze projektowany program ma byc bardzo elastyczny w danym zakresie. XP uzywa sie glownie wtedy kiedy nikt tak do konca nie wie co program ma docelowo robic (prototypy). Te czeste kontakty z klientem maja na celu okreslenie ostatecznych zadan ktore ma wykonywac dany program. W praktyce wyglada to tak ze krok po kroku dodaje sie rozne funkcjonalnosci z zachowaniem pelnej modulowosci. Tzn. tak to powinno wygladac ;)