Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Disseminando conhecimento e inovação em desenvolvimento de software corporativo
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Postado por Lucas Souza em 15 Mar 2010
Estimar segundo o dicionário é :
...Determinar o valor de uma coisa, avaliar, calcular...
Se uma pessoa precisa determinar, por exemplo, o preço de um determinado produto que ela nunca viu, certamente a chance dela errar será grande. Trazendo para o mundo de desenvolvimento de software, seria como se fosse pedido para um desenvolvedor determinar o tempo de uma tarefa que ele nunca viu na vida.
Se ele já conhece sobre o assunto, esta tarefa fica mais fácil de ser estimada, afinal ele está acostumado a lidar com aquilo. O artista da história, ou seja, a pessoa que colocará a mão na massa será o desenvolvedor, nada mais justo do que ele dizer quanto tempo ele demorará para executar tal função. Como dito neste tópico do GUJ, sobre uma matéria da Exame que dizia que trabalho de desenvolvedor é como de operário, desenvolvedores não são definitivamente operários.
O fato é que quanto mais longe as estimativas estão do desenvolvedor, mais fácil de criar-se "tempos" que não condizem com a realidade. O Carlos Brando em um post recente fala um pouco sobre como estimar tarefas de uma maneira precisa ou imprecisa também. Ele diz que programadores que sabem estimar tempos mais precisos, podem ser avaliados como bons:
O que muita gente não se dá conta é que a precisão com que um programador prevê a entrega de tarefas e projetos é um poderoso indicador do quão bom ele é.
Para informar de forma precisa o tempo necessário para a realização de algo em desenvolvimento de software é necessário que o programador possua uma certa experiência no assunto, tenha um bom domínio do negócio, seja rápido e produtivo.
Embora muitos de nós não apreciem essa difícil tarefa, estimar prazos é parte do nosso trabalho. Fazer isso bem pode ser a diferença entre um programador profissional e um amador.
Ele diz que o segredo está não no tempo, mas na precisão que sua estimativa alcança:
O segredo não está no tempo, mas em quão precisa deve ser a sua estimativa. Se seu chefe pergunta que horas você entregará o relatório amanhã, ele quer ter uma ideia se será antes ou depois do almoço. Se ele lhe pergunta quanto tempo será necessário para resolver um bug crítico e colocar o sistema de volta em produção ele precisa de uma precisão maior.
Ele fala sobre escala de tempo como fator importante também, dizer para seu gerente que você demorará 25 dias é bem diferente de dizer que demorará 5 semanas.
Embora ambas as frases indiquem o mesmo tempo, o efeito sob cada uma delas pode ser diferente. Ao dar a primeira resposta, seu cliente provavelmente anotará na agenda dele o dia exato em que você entregará o projeto. Por outro lado, a segunda resposta fará com que ele lhe procure a qualquer momento daqui a 4 ou 6 semanas.
A vantagem aqui é ser mais preciso em suas estimativas, porque quanto maior for o tempo, mais difícil é a previsão. Mas e o que é necessário quando precisamos estimar algo que nunca trabalhamos antes. Carlos diz que é melhor não estimar neste caso:
Mas, o que fazer quando é necessário estimar algo que você nunca fez ou que não conhece? A resposta é simples: “não estime”. É melhor pedir para que alguém que já tenha feito algo semelhante lhe dê uma ideia do tempo necessário.
Talvez neste caso o melhor seja "pensar" antes de dar alguma estimativa, como foi dito pelo Carlos em seu post. E você leitor? Como foram/são suas experiências com estimativas?
Com relação a última frase do Carlos, sobre não estimar se você não tem conhecimento, concordo que o correto seria não estimar, mas muitas vezes somos pressionados a fazer uma estimativa sem o conhecimento necessário. Postei sobre isso:
atitudereflexiva.wordpress.com/2009/07/15/estim...
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.
Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.
Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.
O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.
Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.
Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.
Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.
1 comentário
Acompanhar Discussão Responder