Série "De Brooks a Berkun" - 4ª Parte"O primeiro passo é aceitar as mudanças como um estilo de vida, e não como um desvio, uma exceção". Assim, de forma simples e direta, Fred Brooks começa a tratar o tema "Mudanças".Mudanças ocorrerão em um projeto não só porque o trabalho inicial (coleta e análise de requisitos e arquitetura da solução) não foi bem feito. Segundo Brooks, "a entidade Software está sempre sujeita a pressões por mudanças. Claro, como prédios, carros ... Leia +
Posts Tagged ‘Fred Brooks’
Série "De Brooks a Berkun" - Continuação da 3ª Parte.Scott Berkun dedica várias páginas de seu livro para tratar da tal 'Engenharia de Requisitos' (termo que ele não utiliza) e do 'Design' (termo que ele usa insistentemente) de uma solução. Capítulos como "How to figure out what to do", "Where Ideas come from" e "What to do with ideas once you have them" dão o merecido tratamento aos temas.Para Berkun, a Perspectiva do Cliente pode ser obtida de duas ... Leia +
Série "De Brooks a Berkun" - 3ª ParteEm 1986 Fred Brooks publicou o artigo "No Silver Bullet", que aparece como o capítulo 16 da edição que comemorou os 20 anos de "The Mythical Man-Month". Para Brooks, "ainda cometemos erros de sintaxe, com certeza, mas eles não são nada quando comparados aos erros conceituais da maioria dos sistemas". Scott Berkun cita Brooks na abertura do capítulo "How to figure out what to do", o terceiro de "The Art of Project Management":"A ... Leia +
Série "De Brooks a Berkun" - Continuação da 2ª Parte.Fred Brooks encerra "O Time Cirúrgico", terceiro capítulo de "The Mythical Man-Month", falando que um sistema deve ter total Integridade Conceitual, e que isso só seria possível através da dedicação integral de um Arquiteto (System Architect, no texto original). Logo depois, em "Por que a Torre de Babel falhou?", ele fala de dois líderes em um projeto: o Arquiteto (ou Diretor Técnico) e o Produtor. Mas o dito popular não ensina ... Leia +
Série "De Brooks a Berkun" - 2ª ParteA experiência prática de Fred Brooks, como citado anteriormente, foi com projetos mastodônticos: 1000 pessoas envolvidas ou mais. Mas ele lembra que desde aquela época os 'gerentes de programação' preferiam "pequenos e 'agudos' times formados por pessoas de 'primeira classe'". Brooks cita um estudo (de Sackman, Erikson e Grant) que mostra que um programador de 'primeira classe', que recebia US$20.000/ano, podia ser até 10 vezes mais produtivo que um programador de US$10.000/ano. Mas ... Leia +
Série "De Brooks a Berkun" - Continuação da 1ª ParteBerkun diz que o problema com nossos projetos não está nos cronogramas mas sim na forma como eles são elaborados e usados. O coordenador deve confiar nas estimativas apresentadas pelos programadores e demais membros do time. Se cada estimativa apresentada for bem justificada, não há porque desconfiar delas. Uma questão de validação: quão prováveis são os prazos fixados? "Se nenhuma probabilidade é oferecida e nenhuma pré-condição é colocada, então a realização ... Leia +
