Sou gerente de controle de qualidade / teste em minha organização e até hoje verifiquei a qualidade do software (testes escritos e executados e bugs corrigidos). Quem verificará isso no Scrum? Como sei que a equipe escreveu e executou todos os testes certos? Por outro lado, receio que, se continuar a verificação, a equipe não se sentirá suficientemente empoderada. Mas preciso de algum processo de verificação que "Concluído" seja realmente "Concluído". O que você sugere?
Respostas:
Uma idéia importante no Scrum é que a equipe deve concordar com uma "definição de pronto". Idealmente, isso é algo como um conjunto de critérios objetivos que qualquer pessoa pode verificar através de uma lista de verificação.
Mas, para reduzir a chance de algo escapar, faz todo o sentido ter uma regra de que a verificação de "concluído" seja executada por alguém que não seja a pessoa que implementou um item - ou por um responsável designado pelo controle de qualidade como você (mas isso corre o risco de fazer você um gargalo).
Em caso de dúvida, discuta com a equipe e o Scrum Master e decida em conjunto.
Eu acho que há uma suposição implícita na questão. Há uma diferença entre "aceito", quando um Dono do Produto declara que um item da lista de pendências ou uma tarefa satisfez o Dono do Produto, e "concluído" significa que todo o trabalho associado ao item da lista de pendências está concluído.
No entanto, há regularmente uma tarefa além da visível para o Dono do produto, geralmente alguém semi-técnico na melhor das hipóteses, incluindo testes (automatizados e manuais), documentação e revisão. O Dono do Produto raramente está em posição de conhecer os aspectos técnicos, muito menos se eles foram concluídos.
Portanto, cabe à equipe determinar o que significa "feito". A organização pode ter padrões e diferentes partes interessadas terão seus próprios requisitos. O scrum master ou os gerentes relevantes geralmente são responsáveis por agrupar e aplicar a lista.
No seu exemplo, como gerente de controle de qualidade / teste, você é quem diz se os testes estão completos. No entanto, você pode não ser a melhor pessoa para dizer se o código foi revisado, se os requisitos de segurança foram atendidos, se o produto é internacionalizado, se a documentação está completa ou o que mais significa "pronto".
O único conceito de "pronto" é se uma história como um todo é ou não concluída. A equipe deveria ter criado uma definição de feito que diz quando eles sentem que uma história está terminada ou não. Isso normalmente inclui itens como "o código foi revisado", "os testes noturnos foram executados", "todos os critérios de aceitação foram atendidos" etc. etc. Quando essas coisas são realizadas, a equipe pode se sentir confiante de que fez tudo espera-se que eles terminem uma história.
Durante um sprint, se você estiver tentando determinar se um desses itens na definição de concluído foi realizado, basta perguntar. Scrum e ágil tem tudo a ver com comunicação aberta. Se você faz parte da equipe, pergunte a seus colegas de equipe se alguém escreveu os testes, ou executou-os, ou criou o trabalho noturno, etc. Se você é uma parte interessada, pergunte ao scrum master.
Se você se sentar fora da equipe, mas ainda precisar revisar os testes, peça à equipe que inclua "os testes devem ser revisados pelo usuário user3251930" como parte da definição de concluído. Se é isso que é necessário para uma história ser concluída, seja honesto e faça parte do processo. O objetivo da "definição de pronto" é para que a equipe saiba com certeza que fez o necessário para fornecer software de qualidade. Se parte disso é uma revisão externa, que assim seja.
Por fim, é o proprietário do produto que assina uma história em particular; portanto, no final do dia, ele ou ela tem a decisão final sobre se uma história como um todo é feita ou não.
Primeira pergunta, você deve se perguntar
Você é o Scrum Master ? se sim.
Os processos scrum são controlados e gerenciados pelo Scrum Master.
Como você faz isso:
Na fase de requisitos, você pode usar as histórias do usuário para cada um que exista um teste que precise ser verificado.
Em cada Sprint Os itens de trabalho são retirados da lista de pendências do produto e direcionados pelo proprietário do produto. Cada um deles também terá critérios de verificação.
Agora, no Scrum, os requisitos não mudam após o início do sprint. No final do Sprint, você pode analisar a verificação de acordo com os critérios para cada item realizado.
Se isso for feito, somente poderá ser encontrado pela resposta do proprietário do produto.
Lembre-se, no Agile, você "abraça a mudança" até tarde na fase de desenvolvimento
A equipe decide. Eu uso uma lista de verificação, para o que é considerado 'Concluído'. O que é 'Concluído' por história, por sprint, por versão.
Como outros já mencionaram, em última análise, a decisão cabe ao proprietário do produto.
Concorde que isso é algo que a equipe de desenvolvimento / teste precisa definir, dependendo de suas próprias práticas. Alguns projetos são tão ágeis que estão dispostos a arriscar a liberação de bugs no fluxo alfa; alguns consideram qualquer bug que fica fora do grupo de desenvolvimento uma falha no processo.
O projeto em que estou trabalhando exige uma revisão por pares das alterações de código e exige que quem escreveu o código forneça / atualize testes de regressão ou explique por que não é possível fazer isso. (Eles e seus revisores também precisam certificar que verificaram práticas ruins conhecidas. Em geral, somos muito mais felizes se eles conseguem mostrar que executaram a suíte de testes completa e obtiveram um resultado limpo (ou um módulo limpo conhecido) questões abertas, pelo menos) O código precisa sobreviver a testes intensivos automatizados de unidades e funcionais em várias plataformas para demonstrar que não causa nenhuma regressão em relação a elas e é verificado ainda mais quanto a padrões comuns por um sistema automatizado de análise de código. em seguida, aceitamos isso no fluxo principal de desenvolvimento e marcamos o item de trabalho como concluído.
Obviamente, isso não garante que ninguém encontre uma nova maneira de falhar, mas reduz o risco a um nível aceitável sem impedir muito a velocidade do desenvolvimento.
DoneeUndone