Devemos parar de tentar fazer a agilidade se o controle de qualidade demorar 12 semanas?

24

Alguém da minha empresa propôs recentemente mudanças em nosso produto principal que nossos gerentes acham que devem acionar o que eu acho que minha empresa considera um ciclo completo de controle de qualidade (por exemplo, testar todo o conjunto de produtos desde o início). Aparentemente, nosso controle de qualidade leva 12 semanas para fazer um ciclo completo de controle de qualidade de nosso produto. Meu problema com isso é que estamos tentando fazer o desenvolvimento Agile (embora na maioria das vezes seja meio idiota). Faremos todo um conjunto de sprints e, em seguida, faremos um lançamento, que o controle de qualidade levará uma eternidade para concluir, eu acho. A questão é realmente: se nosso controle de qualidade demorar 12 semanas para fazer o trabalho deles, não deveríamos desistir de tentar fazer o Agile? Qual é o sentido de tentar fazer o Agile em uma situação como essa?

David Hosier
fonte
36
Atrevo-me a dizer que, se o controle de qualidade demorar 12 semanas, você não estará "agilizando".
SingleNegationElimination
9
Se a equipe não for responsável pela qualidade do código que produzem, eu também não chamaria isso de ágil ... #
merryprankster
11
@merryprankster Você poderia elaborar sua resposta? Você quer dizer que é inútil não fazer o controle de qualidade fazer parte da equipe e verificar a qualidade como parte do sprint? Ou você quer dizer que a equipe deve verificar a qualidade por conta própria até um ponto em que o controle de qualidade deve se tornar quase inútil? Ou talvez outro significado? Não sei as respostas corretas aqui. Só estou procurando algum conselho que possa dar para corrigir uma situação que sinto estar terrivelmente quebrada. Obrigado.
David Hosier 28/07
2
Quero dizer que a equipe deve possuir o processo de qualidade. Eles farão o que for necessário para garantir que a qualidade seja boa o suficiente. Isso mantém o ciclo de feedback o mais curto possível e o torna mais pessoal. Qualidade não é uma propriedade externa, é inerentemente parte do desenvolvimento.
28911 merryprankster
2
Isso se tornou um bate-papo, então esse será meu último comentário. Sim, eu concordo que no mundo real, você é limitado pelo seu ambiente. Além disso, você deve poder escolher suas maneiras de trabalhar. No entanto, acho que não é verdade que a agilidade do bate-papo é ser flexível em todos os aspectos, pelo contrário: a agilidade requer disciplina . Um aspecto importante do desenvolvimento ágil é manter os ciclos de feedback curtos. Se você tiver uma fase de controle de qualidade fora da iteração, o feedback está atrasado. Se a equipe não abordar o controle de qualidade como parte da iteração, eles não serão ágeis. A equipe pode decidir como eles fazem o controle de qualidade - isso é flexível -, mas a equipe deve fazê-lo.
28911 merryprankster

Respostas:

21

Bem, a resposta direta à sua pergunta seria Mu receio - não há detalhes suficientes para fazer um palpite informado se você deve ou não parar de tentar.

A única coisa de que estou bastante positivo é que o nível de agilidade deve ser impulsionado pelas necessidades do cliente / mercado (sobre as quais você não deu informações).

  • Por exemplo, como usuário do IDE, estou perfeitamente feliz em atualizar para a nova versão uma ou talvez duas vezes por ano e nunca tenho pressa em fazer isso. Ou seja, se o ciclo de lançamento for de 3 meses ( 12 semanas ), estou perfeitamente feliz com isso.
     
    Por outro lado, posso facilmente imaginar, digamos, que uma empresa de trading financeiro vá à falência se levar mais de um mês para que seu software se adapte às mudanças do mercado - o ciclo de teste de 12 semanas nesse caso seria um caminho para o inferno. Agora - quais são as necessidades do seu produto nesse sentido?

Outra coisa a considerar é que nível de qualidade é necessário para atender às necessidades de seus clientes / mercado?

  • Caso em questão - em uma empresa em que trabalhei, descobrimos que precisamos de algum novo recurso em um produto licenciado por algum fornecedor de software. Sem esse recurso, sofremos bastante, então sim, realmente queríamos que eles fossem ágeis e entregassem atualizações dentro de um mês.
     
    E sim, eles pareciam ser ágeis e lançaram essa atualização em um mês (se o ciclo de controle de qualidade for de 12 semanas, é provável que eles tenham pulado). E nosso recurso funcionou perfeitamente bem - acho que deveríamos ter sido perfeitamente felizes? não! descobrimos um bug de regressão de impedimento em algumas funcionalidades que funcionavam muito bem antes - então tivemos que ficar com a versão mais antiga.
     
    Outro mês se passou - eles lançaram outra nova versão: nosso recursoestava lá, mas o mesmo erro de regressão também estava lá: novamente, não atualizamos. E mais um mês e outro.
     
    No final, conseguimos atualizar apenas meio ano depois tanto pela agilidade deles.

Agora, vamos olhar um pouco mais de perto nessas 12 semanas que você mencionou.

Que opções você considerou para reduzir o ciclo do controle de qualidade? como você pode ver no exemplo acima, simplesmente ignorá-lo pode não dar o que você espera, então é melhor você ser bem ágil e considerar maneiras diferentes de resolvê-lo.

Por exemplo, você considerou maneiras de melhorar a testabilidade do seu produto?

Ou você considerou a solução de força bruta apenas contratar mais controle de qualidade? Por mais simples que pareça, em alguns casos, esse é realmente o caminho a percorrer. Vi o gerenciamento inexperiente tentando corrigir problemas de qualidade do produto contratando cegamente mais e mais desenvolvedores seniores, onde apenas um par de testadores profissionais médios seria suficiente. Muito patético.

O último, mas não o menos importante - acho que devemos ser ágeis quanto à aplicação de princípios ágeis. Quero dizer, se os requisitos do projeto não são ágeis (estáveis ​​ou mudam lentamente), por que se preocupar? Certa vez, observei a alta gerência forçando o Scrum em projetos que estavam indo perfeitamente bem sem. Que desperdício foi. Não apenas não houve melhorias na entrega, mas, pior ainda, desenvolvedores e testadores ficaram infelizes.


atualização com base nos esclarecimentos fornecidos nos comentários

Para mim, uma das partes mais importantes do Agile é ter um lançamento que pode ser entregue no final de cada sprint. Isso implica várias coisas. Primeiro, um nível de teste deve ser feito para garantir que nenhum erro seja exibido se você acha que pode liberar a compilação para um cliente ...

Liberação Shippable eu vejo. Hum. Hummm. Considere adicionar uma ou duas doses de Lean em seu cocktail Agile. Quero dizer, se essa não é uma necessidade do cliente / mercado, isso significaria apenas um desperdício de recursos (de teste).

Eu, por um lado, não vejo nada de criminoso ao tratar a liberação final da Sprint como apenas um ponto de verificação que satisfaz a equipe.

  • dev: sim, parece bom o suficiente para passar aos testadores; QA: Sim, parece bom o suficiente para o caso, se forem necessários mais testes entregáveis - coisas assim. A equipe (dev + QA) está satisfeita, é isso.

... O ponto mais importante que você fez foi no final de sua resposta em termos de não aplicar o ágil se os requisitos não forem ágeis. Eu acho que isso está certo. Quando começamos a agir com agilidade, tínhamos discado e as circunstâncias faziam sentido. Mas desde então, as coisas mudaram dramaticamente, e estamos nos apegando ao processo em que pode não fazer mais sentido.

Você acertou exatamente. Também pelo que você descreve, parece que você chegou ao estado (maturidade da equipe / gerenciamento e relacionamento com o cliente), permitindo o uso regular de desenvolvimento de modelo iterativo em vez do Scrum. Nesse caso, talvez você também esteja interessado em saber que, de acordo com minha experiência em casos como esse iterativo regular, pareceu mais produtivo que o Scrum. Muito mais produtivo - não era simplesmente tão muito menos sobrecarga, era simplesmente muito mais fácil de se concentrar no desenvolvimento (para QA, respectivamente, se concentrar em testes).

  • Eu costumo pensar nisso em termos de Ferrari (como iterativo regular) vs Landrover (como Scrum).
     
    Ao dirigir em uma rodovia (e seu projeto parece ter atingido essa rodovia ), a Ferrari vence a Landrover.
     
    É o off-road onde você precisa de jipe ​​e não de carro esportivo - quero dizer, se seus requisitos são irregulares e / ou se o trabalho em equipe e a experiência de gerenciamento não são tão bons, você terá que escolher o Scrum - simplesmente porque tentar ir com regularidade preso - como a Ferrari vai ficar fora de estrada.

Nosso produto completo é realmente composto de muitas peças menores que podem ser atualizadas independentemente. Acho que nossos clientes estão muito dispostos a atualizar esses componentes menores com muito mais frequência. Parece-me que talvez devêssemos focar na liberação e controle de qualidade desses componentes menores no final dos sprints ...

Acima parece um bom plano. Eu trabalhei nesse projeto uma vez. Enviamos lançamentos mensais com atualizações localizadas em pequenos componentes de baixo risco e a aprovação do controle de qualidade era a mais fácil possível.

  • Uma coisa a ter em mente para essa estratégia é ter uma verificação testável de que as alterações estão localizadas onde esperado. Mesmo que isso chegue à comparação de arquivos bit a bit de componentes que não foram alterados, escolha ou não os enviará. O problema é que o controle de qualidade é responsável pela qualidade do lançamento, não os desenvolvedores.
     
    É uma dor de cabeça do testador garantir que mudanças inesperadas não passem - porque, francamente, como desenvolvedor, tenho outras coisas suficientes para me preocupar, o que é mais importante para mim. E por isso eles (testadores) realmente precisam de provas sólidas de que as coisas estão sob controle com a liberação que testam para enviar.
mosquito
fonte
11
Penso que esta é provavelmente a melhor resposta à luz da nossa situação atual. Para mim, uma das partes mais importantes do Agile é ter um lançamento entregável no final de cada sprint. Isso implica várias coisas. Primeiro, um nível de teste deve ser feito para garantir que não ocorram erros, se você acha que pode liberar a construção para um cliente. Segundo, supondo que a primeira afirmação seja verdadeira, é possível que o controle de qualidade esteja duplicando muito trabalho que já deveria ter sido feito durante o desenvolvimento? Acho que provavelmente há algo a ser abordado lá, tanto em nosso controle de qualidade quanto em nossa equipe de desenvolvimento (sou desenvolvedor).
David Hosier 28/07
No entanto, não me lembro de termos lançado uma compilação para um cliente após um sprint. Além disso, do jeito que nossa base de clientes é, eles não querem um lançamento completo do produto com tanta frequência. Nossos clientes demoram a atualizar. O ponto mais importante que você fez foi no final de sua resposta em termos de não aplicar o ágil se os requisitos não forem ágeis. Eu acho que isso está certo. Quando começamos a agir com agilidade, tínhamos discado e as circunstâncias faziam sentido. Mas desde então, as coisas mudaram dramaticamente, e estamos nos apegando ao processo em que pode não fazer mais sentido.
David Hosier 28/07
3
Nosso produto completo é realmente composto de muitas peças menores que podem ser atualizadas independentemente. Acho que nossos clientes estão muito dispostos a atualizar esses componentes menores com muito mais frequência. Parece-me que talvez devêssemos focar na liberação e controle de qualidade desses componentes menores no final dos sprints. Poderíamos reduzir o ciclo de feedback devido a uma abordagem mais focada e agregar valor aos clientes mais rapidamente. Em seguida, poderíamos fazer um lançamento completo do produto em algum momento que agrupasse todos os bits menores. Então, o controle de qualidade tem menos a fazer, já que a maioria já foi validada em sprints anteriores.
David Hosier 28/07
11
+1 Gosto dos seus exemplos de diferentes necessidades do mercado. Pode-se fornecer exemplos mais extremos. Por exemplo, software de controlador para gerenciar lançamentos de foguetes espaciais. O cliente pode estar satisfeito com as atualizações a cada cinco anos (as leis da física não mudam muito), mas apenas um único erro de regressão pode custar centenas de milhões de dólares .
MarkJ
14

Oh, sinto sua dor. Há algumas mudanças sérias que você precisa fazer na equipe de controle de qualidade para que isso funcione.

Meu conselho é dividir a equipe em três equipes:

Teste de recursos - Rápida recuperação dos novos desenvolvimentos.

Teste de regressão - Teste totalmente o produto antes de sair pela porta. Isso não deve levar três meses, mesmo depois de reduzir o tamanho da equipe, porque a maioria dos erros será encontrada pela primeira equipe.

Teste automatizado - Escrevendo um conjunto completo de testes de regressão para acelerar o trabalho da equipe de testes de regressão.

A terceira equipe é um bônus, mas se você não pode ter as duas primeiras equipes, também pode ser uma cachoeira.

pdr
fonte
Teste automatizado +1 - Os testes de regressão são os principais candidatos.
Joshua Davis
Eu acho que essa é uma resposta muito boa. Eu realmente não estou ciente de como a equipe de controle de qualidade está organizada ou de como eles prosseguem com os testes. Nossa equipe de controle de qualidade está na Índia, o que eu acho que não é uma parte insignificante do problema. Pelo que entendi, seus planos de teste não são publicados para que qualquer pessoa possa revisá-los e validá-los. Além disso, devido à diferença de horário, o tempo de retorno entre os desenvolvedores e o controle de qualidade é atroz. O que deve levar uma hora de conversa na mesa de alguém se transforma em dias de e-mails ou comentários do JIRA.
David Hosier
13

A título ilustrativo:

insira a descrição da imagem aqui

Observe que sua equipe de controle de qualidade provavelmente está trabalhando fora do círculo (ATDD) e você está trabalhando dentro.

Eu acho que é bom trabalhar dessa maneira; se você puder provar em seus testes automatizados que está cumprindo os requisitos do cliente em cada sprint, poderá permitir que o controle de qualidade realize seus testes à vontade e encontrar defeitos, que poderão ser trabalhados no próximo sprint.

Robert Harvey
fonte
2
Um problema é que você está recebendo relatórios de defeitos do trabalho realizado há 4-6 sprints (assumindo 2-3 semanas de sprints). Dependendo das políticas e procedimentos de controle de qualidade da empresa, eles podem realmente precisar assinar um sprint antes de serem liberados para o cliente. Portanto, sim, você tem produtos potencialmente entregáveis ​​após cada sprint, mas menos de 25% deles atingem o controle de qualidade (supondo que, quando terminarem de testar um candidato, começarem a testar o candidato mais recente), para que você possa mostrar um produto a um cliente a cada algumas semanas, mas eles só podem receber um a cada 12 semanas e será mais antigo do que o que acabaram de ver.
Thomas Owens
Direita. Eu estava discutindo isso com um colega. Eu diria que nem sequer fizemos lançamentos adequados no final de cada sprint. Fazemos uma compilação no final de cada sprint, porque é isso que o Agile diz que você deve fazer, mas não temos a intenção de que alguém veja essa compilação. Não sei se o controle de qualidade recebe essas compilações ou não, mas posso garantir que nenhum cliente verá uma compilação no final do sprint. Apenas uma versão é potencialmente oficial, e é a do último sprint. Na minha opinião, isso não é totalmente ágil. Com esse fluxo de trabalho, o Agile é apenas uma maneira de organizar o trabalho.
David Hosier 28/07
Além disso, não me lembro de ter recebido feedback do controle de qualidade até depois da compilação do último sprint, como mencionei acima. Isso valida o seu ponto. Acho que isso pode levar a situações em que as decisões que são tomadas no sprint 1 acabam sendo decisões defeituosas, mas essa decisão defeituosa não é totalmente realizada até que todo o trabalho subsequente seja realizado além dessa decisão defeituosa. Obviamente, isso pode levar a uma enorme quantidade de retrabalho.
David Hosier 28/07
8

Parece que você tem um problema de "Definição de Concluído".

Como o seu grupo de controle de qualidade é externo e está envolvido apenas em lançamentos de clientes, você não pode confiar neles para obter feedback oportuno sobre os problemas. Isso significa que, se você quiser um feedback rápido, precisará trazer algum grau de teste "internamente" para a equipe.

Trate o grupo de controle de qualidade como se eles não existissem. A ação é se sua liberação no final do sprint será implantada no seu ambiente mais crítico no dia seguinte. O software não é feito até que esteja pronto para ir para os clientes.

O controle de qualidade não deve encontrar nada.

Isso será mais difícil de alcançar. Você provavelmente terá algumas coisas que esgueiram-se pelas primeiras vezes. Testes de aceitação automatizados e testes de "regressão" são seus melhores amigos aqui. O TDD ajudará você a construir grandes partes de tais suítes. Você deve saber - rapidamente - se quebrou alguma coisa.

Sean McMillan
fonte
3

Você tem um representante do cliente / proprietário do produto que pode ver um determinado release antes do controle de qualidade e fornecer um retorno autorizado sobre ele? Nesse caso, você pode fazer e ter a maior parte dos benefícios de métodos ágeis enquanto trata o controle de qualidade como uma fonte secundária e lenta de feedback. Uma versão estaria apenas "oficialmente pronta" após o controle de qualidade, mas você não precisaria esperar por ela antes de iniciar a próxima.

Mas se as regras da empresa disserem que o cliente não deve ver um release antes que o controle de qualidade seja concluído, você pode praticamente esquecer de ser ágil, até conseguir alterar essas regras.

Michael Borgwardt
fonte
3

O processo que você descreveu não é um processo ágil. As equipes que têm um alto grau de agilidade são capazes de fornecer versões confiáveis ​​e potencialmente liberáveis ​​a cada sprint. Na maioria das implementações ágeis, a função QA é criada dentro da equipe ágil, ajudando a alcançar esse objetivo.

Se você, seu líder de projeto, seu proprietário do produto e os desenvolvedores não estiverem trabalhando juntos e você não tiver um plano de melhoria (retrospectivas), nomeie seu processo de outra forma e siga em frente. Não parece que os problemas de sua equipe sejam culpa dos gerentes ou do controle de qualidade. Eles parecem estar reagindo a algum problema sistêmico que sai da organização de desenvolvimento. Nem tudo está perdido se a equipe estiver disposta a assumir responsabilidades e começar a trabalhar com as partes interessadas.

Você pode tentar três coisas. Primeiro, certifique-se de que cada parte interessada tenha funções definidas de forma concisa e que cada pessoa entenda sua responsabilidade. Segundo, estabilize a compilação e obtenha aprovação do controle de qualidade sem introduzir mais alterações. Três, instituir a automação de testes. A equipe de controle de qualidade amará você por isso.

GuyR
fonte
Você está 100% correto. Seus três itens são um bom conselho. Só posso afetar tantas mudanças como um único desenvolvedor, mas posso tentar dar o exemplo e ver se algumas pessoas de controle de qualidade querem ir junto. Minha maior frustração é que ninguém mais parece se importar, o que obviamente é uma enorme barreira para o retorno necessário. A maioria das pessoas da equipe fica feliz em continuar com o status quo; pelo menos essa é a minha impressão.
David Hosier
2

É uma pena que o feedback demore tanto, mas acho que não vale a pena parar com o Agile. No final de um sprint (ou dois), você libera um produto que tem certeza de que ele poderá ser colocado no mercado. Para sua equipe, o agile oferece a capacidade de focar no trabalho a ser realizado e manter o produto liberável. Quando o controle de qualidade encontra problemas, sugiro criar relatórios de erros para esses problemas e resolvê-los no próximo sprint (se eles tiverem prioridade alta o suficiente).

Nossos testes de campo de produto levam 8 semanas completas, além de dependermos de produtores externos. Ainda com agilidade, somos capazes de manter o foco no trabalho em questão e produzir uma nova versão muito rápida quando necessário.

O problema está (em seus olhos) no departamento de controle de qualidade. O problema pode ser resolvido lá? Você já discutiu isso?

refro
fonte
Sua resposta trouxe uma boa conversa entre um colega e eu. O ponto principal em sua resposta que me levou foi: "No final de um sprint (ou dois), você libera um produto que tem certeza de que ele poderá ser colocado no mercado". Eu nunca me lembro de lançar o produto no final de um sprint até depois de concluirmos uma série inteira de sprints, ele passou pelo controle de qualidade e tivemos várias rodadas de correção de erros de acompanhamento. A esse respeito, acho que estamos usando o Agile apenas como uma maneira de separar e organizar nossa carga de trabalho e nada mais. Na verdade, não estamos obtendo nenhum benefício do Agile.
David Hosier 28/07
@ David: Eu concordo com você.
Christopher Mahan
1

O prazo de 12 semanas é longo, mas esperamos que o controle de qualidade possa fornecer feedback e relatórios de erros durante esse período (e não após os três meses).

Depois, você ainda pode responder às questões mais importantes de maneira ágil e pode corrigir muitas, senão todas, antes mesmo de terminarem!

Hugo
fonte
-2

O que as pessoas do controle de qualidade estão fazendo enquanto você executa vários sprints? Parece que eles sentem a necessidade de testar tudo após cada alteração (e é por isso que eles esperam por várias alterações).

A equipe de desenvolvimento é ágil, mas o resto da empresa não é.

Quem está encarregado do controle de qualidade ou não sabe o que está fazendo ou executou um truque mental Jedi na gerência superior e pode dedicar seu tempo agradável. Como o controle de qualidade pode demorar mais que o desenvolvimento?

JeffO
fonte