{"id":533,"date":"2008-03-19T23:31:19","date_gmt":"2008-03-19T23:31:19","guid":{"rendered":"http:\/\/osmeusapontamentos.com\/?p=533"},"modified":"2008-03-19T23:31:19","modified_gmt":"2008-03-19T23:31:19","slug":"the-mythical-man-month","status":"publish","type":"post","link":"https:\/\/osmeusapontamentos.com\/index.php\/2008\/03\/19\/the-mythical-man-month\/","title":{"rendered":"The Mythical Man-Month"},"content":{"rendered":"

\"\"
\nPode parecer estranho mas acabei de ler um livro sobre tecnologia, melhor sobre desenvolvimento de software, que foi escrito h\u00e1 33 anos.
\nPara al\u00e9m da eventual afinidade que poderia ter por ler um livro que tem exactamente a minha idade, a verdade \u00e9 que o que me levou a ler o ‘The Mythical Man-Month’ foi o reconhecimento que muitas pessoas ainda hoje revelam sobre o livro.
\n‘The Mythical Man-Month’ \u00e9 um conjunto de artigos escritos como resultado do desenvolvimento do sistema OS\/360 e do reconhecimento do que correu menos bem ou mesmo mal e tentativa de explica\u00e7\u00e3o desses erros.
\nE a verdade \u00e9 que, com muita pena minha, consegui rever uma grande parte da minha vida profissional a\u00ed reflectida… \u00e9 triste saber que estou a repetir erros que foram identificados h\u00e1 33 anos…
\n
\nMas este livro serve-me tamb\u00e9m de enquadramento mental a alguns aspectos da minha profiss\u00e3o. Seja numa perspectiva hist\u00f3rica, onde podemos ver alguns fundamentos de metodologias modernas como extremme programming, seja na vertente da comunica\u00e7\u00e3o do projecto ou, na pr\u00e1tica do pair-programming<\/p>\n

“Notice in particular the differences between a team of two programmers conventionaly organized and the surgeon-copilot team. First, in the conventional team the partners divide the work, and each is responsible for design and implementation of part of the work. In the surgical team, the surgeon and copilot are each cognizant of all the design and all of the code.”<\/p><\/blockquote>\n

seja na defini\u00e7\u00e3o do \u00e2mbito da nossa profiss\u00e3o, da mat\u00e9ria com a qual trabalhamos e do que nos leva a gosta de trabalhar nela.<\/p>\n

“capitulo 2 – The Mythical Man Month pag. 15
\nThe programmer builds from pure thought-stuff: concepts and very flexible representation thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified.”<\/p><\/blockquote>\n

\u00c9 dificil sintetizar todo o livro numa palavra, mas sendo um livro mais ou menos de gest\u00e3o de projectos, \u00e9 tamb\u00e9m um livro de gest\u00e3o de rela\u00e7\u00f5es humanas e de constata\u00e7\u00e3o que o desenvolvimento de software mais do que um fim (o produto final) \u00e9 um processo – “grow, not build, software”.
\nApesar de estarmos cada vez mais acima nas camadas de abstrac\u00e7\u00e3o que nos levam do hardware (porque todo o software ainda corre num hardware) at\u00e9 ao dom\u00ednio de neg\u00f3cio que queremos “softwarizar” continua a ser verdade que:<\/p>\n

\u201cThe hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other sofware systems. No other part of the work so cripples the resulting system if done wrong. No other part is so more difficult to rectify later.
\nTherefore the most important function that software builders do for their clients is ther iteractive extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified. Even the simple answer – \u201cMake the new software system work like our old manual information-processing system\u201d – is in fact too simple. Clients never want exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteraction between the client and the designer as part of the system definition.
\nI would go a step further and assert that it is really impossible for clients, event those working with software engineers, to specifiy completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.\u201d<\/p><\/blockquote>\n

Torna-se por isso para mim cada vez mais claro que um projecto de desenvolvimento de software \u00e9 um projecto onde n\u00e3o se consegue especificar concretamente o que vai ser feito e logo quanto tempo vai demorar a fazer e portanto quanto \u00e9 que deve custar.<\/p>\n

“The programmer delivers satisfaction of a user need rather than any tangible product” (pag.241)<\/p><\/blockquote>\n

E com uma defini\u00e7\u00e3o t\u00e3o abstracta para algo que no fim vai ser muito concreto (n linhas de c\u00f3digo) percebemos que um projecto que tem que assentar na confian\u00e7a entre todos os participantes do projecto.
\nNote-se no entanto que esta confian\u00e7a n\u00e3o tem a ver com a ideia de f\u00e9 ou cren\u00e7a mas sim de confian\u00e7a porque todos os dados disponiveis apontam para que as solu\u00e7\u00f5es optadas s\u00e3o as mais apropriadas. Certamente que haver\u00e1 erros durante o processo mas estando todos os envolvidos no projecto a par das decis\u00f5es e dos objectivos, esses erros n\u00e3o ter\u00e3o mais relev\u00e2ncia do que a necess\u00e1ria para evitar que se repitam.<\/p>\n

Para al\u00e9m da ideia de desenvolvimento incremental e da ideia clara que “the clients do not know what they want”, outro ponto importante que \u00e9 referido tem a ver com o papel do gestor de projecto e a sua rela\u00e7\u00e3o com as pessoas que est\u00e1 a coordenar.
\nComo acontece provavelmente em rela\u00e7\u00e3o a todas as profiss\u00f5es, tamb\u00e9m no desenvolvimento de software, a defini\u00e7\u00e3o de prazos e datas \u00e9 uma esp\u00e9cie de luta entre quem define o tempo que as tarefas demoram (programador) e quem quer gerir os deadlines (gestor de projecto) como se o facto de se querer algo mais r\u00e1pido fosse sin\u00f3nimo de ser possivel ter algo mais r\u00e1pido…<\/p>\n

“The project manager has to keep his fingers off the estimated dates, and put the emphasis on getting accurate, unbiased estimates rather than palatable optimistic estimates of self-protective conservative ones.”<\/p><\/blockquote>\n

Ou seja, em vez de n\u00fameros e datas \u00e0 partida irrealistas mas com potencial “psicol\u00f3gico” para o nivel hierarquicamente superior e\/ou clientes, \u00e9 preferivel batalhar para ter datas fi\u00e1veis e por isso cada vez mais confi\u00e1veis.<\/p>\n

Todos estes pontos parecem \u00e0s vezes banalidades e\/ou generalidades com que todos podemos concordar, mas como disse no inicio n\u00e3o \u00e9 pelo facto de eu os conhecer que n\u00e3o sofri at\u00e9 agora na pele o efeito de cada um desses pontos…<\/p>\n

\n

outros artigos relacionados:<\/p>\n