Scrum e Estratégia
Se Scrum é completamente sobre curto prazo, como os caras da estratégia trabalhariam neste ecossistema?
Rastreando mudança e inovação na comunidade de desenvolvimento de software corporativo.
Postado por Vikas Hazrati , traduzido por Marcelo Andrade em 14 Ago 2009 09:01 AM
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.
Se Scrum é completamente sobre curto prazo, como os caras da estratégia trabalhariam neste ecossistema?
Este artigo explica o porquê a adoção de Agile falha em algumas organizações.
Esse artigo apresenta o seguinte autoquestionamento: Eu seria liderado por mim mesmo? Essa é uma pergunta direta, porém,respondê-la é enormemente complicado.
ORMs estão na moda nos dias de hoje por uma boa razão: eles podem fazer o desenvolvimento de aplicações baseadas em banco de dados rápido e sem dor.
Os novos conhecimentos em neurociência (neurociência social, psicologia positiva e técnicas de imagem) nos dão ferramentas para entender e ampliar a habilidade de homens e mulheres trabalharem juntos.
Esse texto almeja gerar uma reflexão na forma como os times estão tratando os impedimentos que aparecem em seu cotidiano.
Este artigo aborda os desafios para adoção de métodos ágeis dentro da empresa e as estratégias para enfrentá-los.
Gerenciar a produtividade e o cronograma em um projeto é sempre um desafio devido à complexidade na tomada de decisões. Neste artigo, tentamos usar o gráfico burndown para endereçar este problema.
Nenhum comentário
Acompanhar Discussão Responder