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 Vikas Hazrati , traduzido por Marcelo Andrade em 14 Ago 2009
O Manifesto Ágil recomenda ter-se “Software funcionando mais que documentação abrangente". Isto tem levado muitas equipes a acreditar que não existe necessidade de documentação em projetos ágeis. Os críticos apontam a limitada documentação como uma das fraquezas das metodologias ágeis. Ron Jeffries destacou que as metodologias ágeis não recomendam que não haja nenhuma (nem pouca) documentação, mas sim que enfatizam fortemente que haja a documentação certa. Ele menciona,
Um dos argumentos contrários à XP sequer é verdadeiro. As pessoas acham que dissemos que documentação é uma má ideia. O XP é focado no diálogo direto como meio para máxima efetividade. Nossas recomendações sobre documentação seguem este simples fato.
Com outras palavras, Eelco Gravendeel acrescenta que há apenas dois tipos de documentação em metodologias ágeis,
Eelco sugere que muitos documentos, que são criados para apoiar a criação do produto, demandam uma atenção bem próxima, uma vez que tais documentos perdem-se tão logo o projeto esteja concluído. Segundo ele,
Tão logo você aceite que os documentos que são escrito apenas para apoiar o processo de criação do produto devem ser perdidos assim que o projeto esteja terminado e o produto entregue, há a esperança de que você também possa resistir à vontade de deixar qualquer documento totalmente pronto e 100% correto! Isto é exatamente a razão que faz da escrita de documentos uma tarefa que consome tanto tempo (e portanto, uma tarefa tão custosa!). Uma vez que você aceite que você só precisa de fato escrever apenas o suficiente para transmitir sua mensagem ou para evitar de esquecer coisas importantes, você vai compreender que papel & caneta, fotos de desenhos em quadros brancos, rabiscos no verso de diagramas, cartões de histórias, etc., são o bastante para estes propósitos!
Documentação a ser entregue junto com o produto final. - Estes são os documentos que fazem parte do produto entregue e que são acordados em conjunto com o cliente. Exemplos típicos incluem
Mesmo no caso destes documentos, Eelco sugere,
Quando você acordar sobre as documentações que serão entregues junto com o produto, você ainda pode ser criativo quanto ao formato da documentação. Você pode escrever extensos manuais de usuário, ou você pode usar técnicas modernas como manuais em vídeo gravados com screencast. Esta segunda opção costuma ser mais barata (estatisticamente, cerca de 10 vezes mais barata!) e com muito mais possibilidade de ser utilizada de fato.
Assim, tem-se que há dois tipos de documentos, um que auxilia à equipe e outros que precisam ser entregues junto com o produto final. Se uma equipe ágil estiver preparando documentos que não se encaixem numa dessas categorias, então tais documentos vão demandar um cuidado especial. Em muitos casos, a equipe deveria ser capaz de evitar ter de criar tais documentos.
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.
Nenhum comentário
Acompanhar Discussão Responder