Na minha empresa, trabalhamos com sucesso com práticas ágeis - mas sem usar iterações. O principal motivo é que não conseguimos encontrar uma maneira limpa de ajustar o controle de qualidade em um ciclo de iteração.
Entendemos o controle de qualidade como um pouco extra de verificação para uma determinada versão (candidato a lançamento) antes que essa versão seja implantada no cliente. O objetivo é evitar que um único commit malicioso danifique toda a versão. Como você nunca sabe qual é, o controle de qualidade precisa aguardar até que todos os recursos / confirmações para o lançamento estejam na compilação. (Nenhuma última palavra famosa "Foi apenas uma pequena alteração" permitida.)
Se o controle de qualidade encontrar erros em um candidato a lançamento, os desenvolvedores os corrigem no respectivo ramo de lançamento (e o mesclam no tronco). Quando todos os erros são corrigidos, uma nova compilação é implantada para que o controle de qualidade seja testado novamente. Somente quando nenhum bug é encontrado em um determinado candidato à liberação, ele é oferecido ao cliente para verificação.
Isso geralmente leva de dois a três candidatos, cerca de uma semana, por release. O tempo para escrever as correções geralmente é muito menor do que os esforços de teste. Portanto, para manter os desenvolvedores ocupados, eles trabalham no release N + 1, enquanto o QA trabalha no N.
Sem usar iterações, isso não é problema, pois podemos sobrepor o trabalho das versões N e N + 1. No entanto, pelo que entendi, isso não é compatível com abordagens baseadas em iteração como Scrum ou XP. Eles exigem que uma iteração seja liberável ao final, com todo o esforço de teste a ser incorporado na iteração.
Acho que isso leva necessariamente a um dos seguintes resultados indesejados:
(A) Os desenvolvedores estão ociosos no final de uma iteração porque o controle de qualidade precisa de tempo para verificar um candidato a lançamento e o trabalho de correção de bugs não está mantendo completamente os desenvolvedores ocupados.
(B) O controle de qualidade já começa a funcionar antes que o candidato à primeira liberação esteja pronto. É o que é mais recomendado no Stack Exchange. Mas não é o que minha empresa entende como controle de qualidade, porque não há nenhum candidato a release específico testado. E a "pequena mudança" que quebra tudo ainda pode ser introduzida despercebida.
(C) Os erros são transferidos para a próxima iteração. Isso também é recomendado no Stack Exchange. Não acho que seja uma solução. Basicamente, significa que nunca estamos obtendo uma compilação verificada, porque sempre que são feitas correções de bugs, novas confirmações não verificadas também são adicionadas à mesma ramificação.
Existe alguma maneira de sair desse dilema?
Respostas:
Não há nada inerentemente incompatível entre essa forma de controle de qualidade e metodologias baseadas em iteração como o Scrum.
No Scrum, a equipe entrega um produto em um ciclo semanal X para seu cliente. A parte importante aqui é que, se a equipe de desenvolvimento estiver executando o Scrum, o cliente será a equipe de controle de qualidade, não o usuário final do seu produto.
Como desenvolvedor, eu consideraria um produto que pode ser entregue ao controle de qualidade se tiver uma chance de ser aprovado em todos os testes. Isso provavelmente significa que alguns dos testes de controle de qualidade já foram executados nas compilações diárias, mas como isso afeta os testes de versão oficial da equipe de controle de qualidade depende da sua organização.
fonte
Para a maioria das situações da vida real, o ágil para na entrega ao QA / UAT ou como quer que seja chamado.
O esforço para passar do controle de qualidade para a produção em um ambiente da vida real é frequentemente subestimado. Em muitos casos, isso envolve usuários reais de negócios em testes, o gerenciamento sai da linha real de gerentes de negócios, agendando o lançamento com operações etc. etc. Isso não é trivial!
Em casos extremos, o software pode precisar de certificação por agências externas ou estar sujeito a testes de segurança rigorosos.
Nessas circunstâncias, é simplesmente impossível prever mais de uma versão por trimestre, exceto correções de bugs.
Fica pior para um produto de software sério. A documentação precisa ser revisada e publicada. As brochuras de marketing precisam ser alteradas. O pessoal de vendas precisa ser informado sobre o que está vendendo (não é tarefa fácil!) Etc. etc. Você realmente não deseja promover os negócios mais de uma vez por ano.
fonte
A solução a curto prazo é dar ao controle de qualidade um período extra após a iteração para finalizar o teste. ie Se você tiver uma iteração de duas semanas, não a liberte até a terceira semana. O controle de qualidade não terá nada para testar na próxima iteração, durante a primeira semana dela.
Mas vou avisá-lo com antecedência o que acontecerá (tendo visto isso em várias equipes): você terminará em uma situação em que uma iteração você realiza o trabalho de duas semanas, o controle de qualidade está sobrecarregado, eles estão procurando por você semana inteira do controle de qualidade e, na iteração a seguir, você realizará apenas o trabalho de uma semana. Essa iteração, o controle de qualidade não terá nada para fazer e você pensará que resolveu o problema. Mas, na próxima iteração, você iniciará o ciclo novamente.
Assim, assim que você adicionar essa semana, apenas para garantir que seu lançamento seja estável (porque uma coisa que aprendi é que, se você perder a fé nos negócios, o Agile fica exponencialmente mais difícil de implementar), siga em frente para o plano de longo prazo.
Compre uma cópia da Entrega Contínua de Jez Humble , leia-a, capa a capa, passe para a equipe. Inspire todos. Em seguida, implemente tudo o que puder dele.
Torne o processo de criação o mais liso possível. Implemente uma política de teste de unidade e faça com que as pessoas executem em todas as versões. Faça do processo de implantação a coisa mais esperta que você já viu. Três cliques? Não é liso o suficiente.
Depois de fazer tudo isso, não importará muito se o erro de regressão ocasional passar. Você sabe porque? Porque você poderá (opcionalmente) reverter, corrigi-lo e implantar novamente, antes que os negócios desmoronem. De fato, o zelador noturno poderá reverter para você, o processo será muito simples.
Sei o que você está pensando: não temos tempo para fazer tudo isso. Deixe-me dizer-lhe, você faz. Se você está sobrecarregando o controle de qualidade, está implantando demais por iteração. Então não. Se você ainda não está sobrecarregando, pergunte-lhes por que eles ainda não têm suítes de teste automatizadas. Você logo estará.
Faça tudo isso com total visibilidade para os negócios. Faça uma estimativa mais baixa e injete parte desse trabalho na iteração. Ou, melhor ainda, divida-o em histórias e faça com que eles o priorizem, junto com todo o resto.
Explique a eles que a) melhorará a estabilidade do lançamento eb) melhorará sua capacidade de responder a problemas para eles ec) comprará mais velocidade posteriormente. É uma empresa rara que não quer essas coisas. Certamente não é uma empresa ágil que não os deseja, portanto, se você tiver resistência, saberá que tem um problema diferente.
Depois de baixar a Entrega contínua, você pode começar a reduzir o tempo de controle de qualidade no final da iteração. É do interesse de todos trazer as iterações de volta em paralelo, o mais rápido possível. Talvez você tenha um dia no final da iteração, onde precisará preencher o tempo. Eu já respondi o que fazer sobre isso em outro lugar .
fonte
Parece haver um problema com a maneira como você decidiu o que exatamente constitui
work for release N.Por algum motivo estranho (só posso supor que haja algum mal-entendido sobre receitas específicas do Agile), você decidiu que a abordagem ágil exige que todos os esforços da equipe de controle de qualidade sejam incorporados na iteração.
Há um pouco mais de agilidade abaixo, mas primeiro, vamos resolver
work for release N...Olha, simplesmente não há motivo para a equipe de desenvolvimento definir o trabalho dessa maneira. Muito pelo contrário, a partir de sua descrição, é claro que, em vez de "unidade de trabalho" monolítica, existem várias dessas unidades, com marcos fáceis de sentir ...
Observe também que a maneira como você define
work for release Ntambém não é forçada pelo fluxo de trabalho do controle de qualidade. Pelo que você descreve, as coisas parecem ter um cronograma próprio (e bastante razoável).Dado acima, a maneira mais realista de definir as unidades de trabalho no seu caso pode ser a seguinte:
Release Candidate NRelease Candidate N patch 1Release Candidate N patch 2Acima estão suas unidades de trabalho, não importa se você faz o Agile ou o que quer.
Estes são naturais e convenientes para definir, seguir e acompanhar. Isso também combina bem com o cronograma de controle de qualidade, permitindo uma coordenação conveniente dos esforços de desenvolvimento e controle de qualidade.
Acima da compreensão da compatibilidade com o Agile parece fundamentalmente errado e aqui está o porquê ...
A suposição que você fez não tem nada a ver com o Agile, se considerarmos sua filosofia pelo valor nominal indicado pelo próprio nome, que é uma abordagem que favorece e pratica a agilidade .
Nessa perspectiva, manter um fluxo de trabalho "fixo" específico e ignorar se é conveniente ou não simplesmente contradiz o espírito do Agile. Seguir servilmente o "procedimento" leva a práticas denegridas de maneira tão eloquente no Manifesto Ágil Semi-Arsed "... temos processos e ferramentas obrigatórios para controlar como esses indivíduos (preferimos o termo 'recursos') interagem" .
Você pode encontrar mais informações sobre isso em uma resposta a outra pergunta , citada abaixo. Dê uma olhada na nota sobre "release entregável", parece que naquela época o OP havia sido confundido de maneira semelhante:
fonte