As equipes Agile devem fornecer novos recursos diariamente?

Minha empresa está no meio de uma transição do desenvolvimento em estilo cascata para o Agile / Scrum. Entre outras coisas, somos informados de que a expectativa é que tenhamos novos recursos funcionais e testáveis (pelo controle de qualidade) no final de cada dia.

A maioria dos nossos desenvolvedores perde cerca de 2 horas por dia em reuniões e outras despesas corporativas. Isso significa que, em qualquer período de 6 horas (no máximo), temos que projetar, escrever, testar unitariamente, criar e implantar (com notas de versão) código suficiente para produzir um recurso completo para o controle de qualidade. Entendo que as notas de compilação / implantação / versão podem ser automatizadas com uma configuração de IC adequada, mas ainda não estamos lá.

Também temos um grande contingente offshore escrevendo nosso código do servidor, e a diferença horária de 12 horas torna isso ainda mais difícil.

Tentamos organizar as histórias em fatias verticais estreitas e profundas para concluir os recursos de ponta a ponta o mais rápido possível, mas a maioria dos dias parece um tanto frenética e geralmente vejo pessoas usando atalhos estúpidos e frágeis para garantir o controle de qualidade. Esse problema é agravado após um sprint em andamento por alguns dias, quando os defeitos inevitáveis ​​começam a aparecer e precisam se encaixar na mesma janela de 6 horas.

Esse é um ritmo normal para as equipes ágeis? Mesmo que consigamos implementar uma configuração de IC, não vejo como conseguiremos manter esse ritmo e ainda criar software de qualidade.

Edit: Existem várias boas respostas aqui. Isso me fez perceber que o que realmente estava perguntando é: as equipes Agile devem fornecer novos recursos diariamente. Eu atualizei o título de acordo.

Os crimes cometidos em nome do Agile hoje em dia me deixam triste. Muitas pessoas estão tendo dificuldades para fazer essa transição.

Manifesto ágil: "Valorizamos as pessoas e as interações sobre processos e ferramentas". Quando as pessoas estão claramente sofrendo, o processo está errado. Não quero lhe dizer como fazê-lo, mas vou compartilhar como faço.

Nas minhas equipes, a parte importante é evitar comprometer-se com um código de repo compartilhado que é quebrado de maneiras que desperdiçam o resto do tempo da equipe. Apenas nesse sentido, eu me esforço para 'entregar código de trabalho todos os dias'. Não interrompa o controle de qualidade. Não bloqueie outros desenvolvedores. Idealmente, nunca verifiquei erros. (ha ha).

A implicação não é que você precise comprometer algo todos os dias. A implicação é que você deve apenas cometer coisas boas, para que todos os dias você possa criar todas as coisas boas que alguém cometeu. Dessa forma, a equipe continua disparando em todos os cilindros.

Nas minhas equipes, o controle de qualidade é constante. Como construo produtos comerciais, o projeto nunca termina até que o produto esteja obsoleto. Os engenheiros de controle de qualidade testam os recursos disponíveis para teste. Os engenheiros de controle de qualidade sempre têm uma lista de pendências. Nunca há tempo de controle de qualidade suficiente para testar ou automatizar tudo o que idealmente queremos.

Se os desenvolvedores precisarem de vários dias antes de mesclar as alterações de um recurso ou correção, tudo bem, incentivado se isso os ajudar a acertar o código antes de arriscar nosso tempo. Os desenvolvedores podem confirmar o código em seu repositório ou filial particular sem afetar a equipe ou o controle de qualidade. Os desenvolvedores podem executar testes de unidade ou automação de regressão no código criado a partir de um repositório de desenvolvedores ou filial particular. Em casos particularmente arriscados, um engenheiro de controle de qualidade trabalhará com o desenvolvedor para testar antes da fusão, para proteger a equipe de atrasos.

Nesse sentido, pratico o que seus gerentes querem. Quase todos os dias, nos últimos 12 anos, minhas equipes de desenvolvimento têm código que funciona no repositório compartilhado. Estamos sempre quase prontos para enviar. Ocasionalmente, não conseguimos isso, mas não nos preocupamos muito com isso. Às vezes é intencional acomodar mudanças importantes nas ferramentas ou fusões difíceis.

O Manifesto Ágil, para mim, resume o melhor do novo pensamento sobre o processo de desenvolvimento que surgiu nos anos 90. Acredito bastante nesses princípios, mas os detalhes do processo podem variar. A meu ver, o objetivo do Agile é adaptar seu processo às necessidades de seus produtos e clientes, para não ser um escravo do processo.

Se você tinha software trabalhando ontem, por que não estaria funcionando hoje? Se você não concluiu nenhuma tarefa hoje, a compilação de hoje será a mesma de ontem. Construções diárias e o ritmo do desenvolvimento são coisas separadas. Só porque você tem compilações diárias, isso não significa que você tem novos recursos em cada compilação.

Quando, finalmente, algum recurso é concluído e efetuado o check-in na filial principal, você deve ter um processo automatizado que construa o software e execute testes. Se houver um problema com a criação ou execução de testes, a equipe é notificada e eles concentram seus esforços para fazê-lo funcionar novamente. É assim que o CI funciona e como ele ajuda a lançar o software em funcionamento o tempo todo.

Resposta curta: Não . Simplesmente não pode ser realizado diariamente.

No entanto, a equipe ágil deveria fornecer peças de software ou histórias de usuários em cada sprint . Geralmente, a reunião de status é realizada diariamente para ver o progresso e os impedimentos.

No que diz respeito ao software de qualidade , os processos de integração contínua (IC) em vigor garantirão que o controle de qualidade seja aplicado a pequenos esforços (check-ins) e realizado com a frequência configurada. Também visa melhorar quality of softwaree reduzir o tempo necessário para entregá-lo, substituindo a prática tradicional de aplicar o controle de qualidade após a conclusão de todo o desenvolvimento.

Não, não deve haver expectativa de entrega de novos recursos todos os dias. Nem todos os recursos podem ser divididos em um tamanho tão pequeno que permita que um desenvolvedor termine o recurso em ~ 6 horas de tempo de desenvolvimento.

Se você estiver fazendo scrum, deve fazer no mínimo duas semanas de sprints, com recursos dimensionados para levar de 0 a 8 dias para serem concluídos. A promessa ao proprietário do produto é fornecer um novo código de trabalho correto, testado e verificado, que possa ser colocado em produção no final do sprint. (OBSERVAÇÃO: você não precisa colocá-lo em produção, mas o objetivo é que poderia ser se você quisesse)

Uma boa metodologia sugeriu que você configurasse um servidor de CI (Continous Integration) no qual automatizou a criação de pelo menos uma compilação diária de software de trabalho. A ideia é que você faça o check-in do seu código assim que terminar o recurso, para que ele possa estar no próximo ciclo de criação e depois nas mãos do controle de qualidade para teste.

Lembre-se de que o objetivo é ter os recursos prontos e testados até o final do sprint! Você não precisa fazer com que o controle de qualidade aguarde até o último dia do sprint para que você faça a compilação e faça com que testem todos os recursos. Eles não terão tempo para testar tudo e você não terá tempo para corrigir quaisquer erros ...

Se você não pode configurar um servidor de IC, a prática deve ser a criação manual de uma nova compilação para o controle de qualidade sempre que um desenvolvedor verificar seu código finalizado e afirmar que ele terminou um recurso e está pronto para entregá-lo ao controle de qualidade.

Na verdade, depende do tamanho do projeto; se o projeto for grande, não há maneira viável de conseguir isso.

Construções diárias (ou mais frequentemente) que resultam de ferramentas de integração contínua, não significa software funcionando; mal significa código compilável.

Existem muitos projetos por aí que fornecem versões diárias, que graças à integração contínua, estão funcionando com software. Pelo menos em teoria.

Isso significa que não está necessariamente contendo novos recursos. Talvez algumas pequenas correções de bugs, ou nada.

Em teoria, se você não conseguir fornecer mais trabalho ao seu controle de qualidade diariamente, deverá aumentar o número de desenvolvedores ou reduzir o número de testadores. Terrível ideia!

Seu trabalho é fazer as coisas.

Diga ao controle de qualidade que eles terão algo para testar quando terminar. Você precisa explicar a eles o porquê.

Eu acho que você está confuso sobre a ideia de "IC". Você pode visitar este excelente artigo de Martin Fowler sobre como o IC funciona na prática . Isso deve responder sua pergunta corretamente.