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.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
O Manifesto do Pronto
Postado por Shane Hastie , traduzido por Felipe Torres em 23 Mar 2010
Alixx Skevington postou um Manifesto do Pronto como o começo de uma discussão, falando sobre os compromissos que os membros do time tem sobre os outros em relação à qualidade do seu trabalho e claramente expressando suas obrigações para entregar valor de negócio através do código.
Sua lista dos critérios de Pronto contém:
- Eu terei certeza de que meu código é usável. Meu código é para uso e interação com outras pessoas, e tudo que eu escrevo deve fazer disso uma experiência prazerosa, e reduzir a carga de trabalho ao invés de aumentá-la.
- Eu escreverei código que esteja de acordo com o estilo adotado pelo time. Outras pessoas, além de mim, deverão ser capazes de manter e alterar meu código. Então eu devo ser flexível para projetar e utilizar qualquer tecnologia para criar minha solução. Optando pelo padrão, eu escrevo código que permite que outros mantenham-no.
- Eu concordo em manter meus métodos em um tamanho razoável. Métodos muito grandes tornam dificeis a navegação e debug. Sempre que possível eu manterei meus métodos num tamanho razoável para diminuir essa complexidade.
- Eu comentarei todo código. Sempre que eu criar um código novo ou alterar algum já existente, eu farei comentários curtos e sucintos para explicar o que eu fiz. Então assim que outros virem esse código depois de mim entenderão o que eu fiz e qual o seu objetivo.
- Eu concordo em testar unitariamente meu código. Eu concordo em fazer esses testes reutilizáveis e não frágeis. Eu farei o teste explicar o que se está testando e qual o motivo. Então além dos outros poderem rodar meus testes quando meu código for refatorado ou corrigido, poderão também ver o que o meu código tenta fazer.
- Eu concordo em manter os testes unitários para o código. Quando eu alterar ou adicionar novas features ao código, terei certeza de que todos os testes passam e que haverá novos, para toda feature.
- Eu concordo em tentar manter a cobertura do meu código em, ao menos, 80%. Verificando a cobertura do meu código, estarei certo de que tudo o que eu escrevi tem valor. Que náo haverá surpresas no meu código que poderiam causar problemas futuramente.
- Eu concordo em verificar que meu código se integra corretamente. Quando eu terminar de escrever meu código, trabalharei com os outros desenvolvedores para ter certeza de que meu código funciona bem com todas as outras partes e que desempenha corretamente a função desejada.
O post gerou um número de comentários no LinkedIn com sugestões para outros itens serem adicionados à lista, como:
Eu adicionaria um "eu rodarei novamente os testes unitários antes do check-in". O motivo pelo qual eu sugeri isso é aparentemente independentemente do código de um lugar poder quebrar testes e/ou código em outro lugar. Isso aconteceu várias vezes no meu último trabalho. (David Kramer)
Re: de fato eu alteraria para "eu escreverei testes unitários antes de escrever o código", porque eu sou um grande entusiasta do TDD. Outra coisa a dizer sobre testes: eles são código de produção, trate-os como tal. (Scott Ames)
Scott Mcphee discorda do item sobre comentário de código:
sobre o comentário de código, eu não posso dizer que discordo mais. Comentários frequentemente mentem, ou apenas mostram coisas óbvias (ex: /* atribui y a x */ x=y), e sempre adiciona bagagem extra que será mantida na linha com o código atual. Um código bem escrito e bem projetado não precisa de "comentários sucintos para explicar o que foi feito" - é óbvio, ao se ler o código, o que ele faz; e o os commits e controle de versão apenas iluminam o "porquê" algo foi feito. Documentação da API é algo diferente, mas isso geralmente é dirigido aos usuários dos métodos públicos, não aos leitores de código, e faz parte dos artefatos lançados.
Jay Packlick adicionou um ponto considerado o mais crucial:
A definição mais importante de feito está implícita, mas merece uma atenção explícita e eu a colocarei no topo da lista: * "Todos os critérios de aceitação definem 'feito' para uma função são expressos em testes e passar."
E você leitor, quais mudanças você faria nessa lista?
Nenhum comentário
Acompanhar Discussão Responder