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 Jonathan Allen , traduzido por Felipe Rodrigues em 11 Nov 2008
No PDC tivemos um painel de discussão sobre "O futuro do Teste Unitário". A maior parte da conversa focou em mocking. Foi um consenso geral frameworks de mock estão sendo super utilizados.
A teoria é a seguinte. Freqüentemente, implementar todas as interfaces necessárias é tedioso ou consome muito tempo. Então para tornar as coisas mais fáceis, as pessoas apelam para os frameworks de mocking. Isso apenas esconde o problema raiz, que é uma API muito complexa.
Um tema popular foi a diferença entre "teste de desenvolvedor" e teste que todo mundo faz. A idéia de que desenvolvedores escrevem somente testes unitários era freqüente na discussão. Testar de acordo com os requisitos, testes de aceitação, testes de integração e todas as outras formas de teste são problemas de alguém fora do desenvolvimento.
Isso ressalta uma incompreensão na comunidade de testes unitários. Especialmente, o pressuposto de que todos os desenvolvedores têm um time de QA para cuidar de todos os outros tipos de teste. Infelizmente, mesmo empresas multimilionárias freqüentemente não possuem um time de QA, deixando todo o teste para o desenvolvedor e o usuário final.
A principal desculpa para não suportar mais tipos de testes foi a velocidade. Testes unitários já são lentos e, portanto não há espaço para testes mais lentos que incluem comunicação via rede. Ainda pior é o fato de que nenhuma outra opção foi considerada.
Por exemplo, testes unitários podem ser inteligentes. É possível usar os resultado de cobertura de código para executar os testes somente para os códigos que mudaram. Mudar uma classe não deve exigir que você execute a suíte de teste inteira. O termo "teste unitário " implica que você pode testar somente um pequeno pedaço.
Outra possibilidade que não tem sido discutida é alavancar a programação distribuída. O código e os testes podem ser rapidamente carregados para diversos servidores e executados neles. Nós já temos toda a tecnologia necessária para execução de integração contínua.
No começo do painel, reconheceu-se que bancos de dados estão sendo negligenciados. A maioria dos desenvolvedores de banco de dados tem pouco ou nenhum conceito sobre testes unitários e há pouquíssimas ferramentas para suportá-los. Mais perturbador, nem foram questionados para vir à mesa do painel. Infelizmente isso foi tudo que foi dito sobre eles. Em nenhum momento o painel ofereceu opções reais para corrigir os problemas sociais.
Do lado positivo, houve alguma discussão sobre usar ferramentas de modelagem para tornar os testes unitários mais fáceis. Há muitas opções aqui como iniciar no nível de contratos. Os contratos poderiam então ser usados pelos geradores de código para escrever os testes. Obviamente isso não seria uma solução 100%, mas iria reduzir o esforço em cenários comuns.
Outra idéia promissora foi a de delta state management. A maioria das pessoas assume que um teste de contas começa com $100 e depois da transação só tem $80. A alternativa é primeiro ler o balanço atual e então checar para ver se houve a redução de $20. Desta forma um reconfiguração completa do ambiente de teste não necessária para cada execução.
O que seria "delta state management"? Acabo de procurar no google e encontro "Resultados 1 - 6 de 6 para "delta state management" (0,60 segundos)". Você inventou isto ou há alguma teoria por trás?
O que seria "delta state management"? Acabo de procurar no google e encontro "Resultados 1 - 6 de 6 para "delta state management" (0,60 segundos)". Você inventou isto ou há alguma teoria por trás?
Eu só traduzi e como não vi sentido em traduzir para gerenciamento de estado delta. Por isso, postei a mesma dúvida na versão em inglês, pro autor responder. =)
www.infoq.com/news/2008/10/Testing#view_35002
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.
2 comentários
Acompanhar Discussão Responder