Às vezes, as equipes de desenvolvimento jovens entram em confusão.
Isso acontece no momento em que eles ainda não entenderam completamente o que é uma vantagem; O projeto e o produto argumentam qual deles é quem e cada um realiza tarefas por conta própria. Ou todo mundo já sabe tudo, mas os sprints não podem ser planejados - as tarefas não são executadas, as demos e as retrô não são regulares.
Também tivemos uma história semelhante, mas encontramos o nosso caminho.
Esta é uma história da equipe de contas pessoais do Yandex.Kassa e uma instrução detalhada para quem deseja melhorar seu planejamento.
Como foi
A equipe de contas pessoais do Yandex.Kassa é responsável pela conveniência de conectar novos comerciantes ao Caixa e faz um serviço de cobrança. Pelos padrões da Yandex, a equipe é jovem - 4 em cada 6 desenvolvedores trabalham seis meses ou menos e eu, gerente de projeto, ingressou na equipe há 3 meses.
No primeiro dia do novo sprint, a equipe se reuniu com o proprietário do produto (doravante - PO) e planejou o sprint por cerca de duas horas. Essa abordagem tem desvantagens óbvias:
- Baixa elaboração de requisitos. O PO não teve tempo suficiente para responder a todas as perguntas. Nós levamos essas tarefas para o sprint ou pedimos aos analistas para avaliar a tarefa e adiamos sua implementação até o início do próximo sprint.
- Havia situações em que as partes interessadas eram lembradas quando o sprint estava em pleno andamento e precisávamos urgentemente de algumas melhorias ou soluções das equipes relacionadas.
- Falta de gerenciamento de riscos.
Com a consideração deles, surgiram os requisitos para um novo processo:
- Os requisitos para as tarefas devem ser elaborados pelo proprietário do produto e por todas as partes interessadas.
- Dod implementado (definição de concluído é um conjunto de critérios que permitem entender se qual foi o objetivo do desenvolvimento) para cada atividade. Eles começaram a identificar as partes interessadas para que, uma semana antes do início de um novo sprint, as informassem sobre o andamento do trabalho e coletassem feedback.
- Reuniões mínimas para focar no sprint atual. Limitado a duas reuniões em duas semanas por uma hora cada.
- Eles começaram a realizar treinamento interno regular do produto como uma equipe, pois hoje um dos principais riscos é a falta de conhecimento sobre o produto.
Novos conceitos
Introduzimos novos contêineres (listas) de comandos:
A prioridade das tarefas em todas as listas, exceto a primeira, é determinada pelo pedido.
Se as tarefas forem concluídas no sprint, um membro da equipe poderá levar as tarefas de Estimated para o trabalho e entenderá que elas estão completamente prontas para o trabalho - pegue e faça.
Primeira semana
Por clique - versão completa.
Segunda-feira
O proprietário do produto move as atividades do contêiner da Lista de Tarefas para o Grooming, prioriza e descreve a Definição de Concluído da forma mais clara possível.
O PM verifica a atividade no contêiner Grooming com a lista de verificação:
- Os layouts são necessários para novas atividades e, em caso afirmativo, são?
- Todas as atividades do projeto mais importante foram incluídas?
- Os links entre as tarefas são indicados?
Se algo estiver errado, o PM se comunica com o OP para esclarecer os detalhes e notifica a equipe que a lista de Higiene está atualizada.
Um exemplo:
- Execute a tarefa "As cartas sobre faturas emitidas à noite são enviadas com atraso". Foi adicionado pelo testador ao final da lista de Higiene.
- O PO levantou esta tarefa na lista.
- O PM verificou se a atividade de trabalhar com o contêiner por parte da OP foi realizada e notificou a equipe sobre isso.
Terça-feira
A equipe se familiariza com novas atividades e escreve comentários, perguntas e faz sugestões. O PO recebe automaticamente todos os novos comentários (usamos Jira, por isso é fácil de fazer), e ele tem tempo para preparar as respostas amanhã.
Um membro da equipe especificou se a tarefa é relevante. Descobriu-se que a tarefa é relevante, o testador encontrou a causa do problema e o relatou. No entanto, do ponto de vista da lógica de negócios, a questão permaneceu em aberto.
Quarta-feira
Temos uma reunião com o OP que responde às perguntas da equipe. O objetivo da reunião: corrigir o Departamento de Defesa. Após a reunião, parte das atividades irá para o contêiner “Definido” e parte - imediatamente para “Estimado”, se for imediatamente óbvio quanto tempo essa atividade levará. Definir dependências e partes interessadas.
Um diálogo entre PM e OP, após o qual ficou claro o que precisa ser feito. Normalmente, esse diálogo não é fixo, mas foi por causa dessa atividade que o pedido não estava disponível durante a reunião; portanto, a comunicação foi registrada por escrito.
Quinta-feira
O PM envia uma lista de atividades próximas da lista Estimada e Definida para as partes interessadas, com uma solicitação para ver e comentar.
Sexta-feira
O PM responde às perguntas das partes interessadas, envolvendo uma equipe ou OP, se necessário.
Nenhum comentário foi recebido sobre a tarefa, que mostramos como exemplo, mas em geral se parece com isso:
O feedback pode vir através do messenger.
O resultado da primeira semana é a atividade, segundo a qual fica claro o que precisa ser feito (o dod é determinado), levando em consideração os desejos das partes interessadas.
Segunda semana
Segunda-feira
A equipe avalia independentemente as atividades na lista "Definido" e a decomposição de atividades na lista "Estimado". O PO não está envolvido aqui, porque ele é responsável por estabelecer metas por parte dos negócios e não é sua responsabilidade avaliar como é feito o planejamento.
Terça-feira
Há uma segunda reunião com a OP, na qual a equipe pode esclarecer os detalhes e comunicar suas classificações. O PO pode informá-lo sobre novos eventos introdutórios que podem ter ocorrido durante a semana passada, além de esclarecer por que a atividade é exatamente essas estimativas, e não menos.
Quarta-feira
Há uma demonstração no sprint atual. Como resultado da demonstração, geralmente são formadas novas atividades, algumas das quais devem ser concluídas antes do final da semana e as demais no próximo sprint. O objetivo da demonstração é coletar feedback. A equipe apresenta o resultado de seu trabalho e recebe feedback antecipado sobre o trabalho da nova funcionalidade.
A demonstração é interna e externa .
A demonstração interna é para o PO, onde ele avalia se a equipe alcançou o resultado conforme o esperado ou se são necessárias melhorias. É realizado por um testador em um ambiente de teste.
A demonstração externa é destinada às partes interessadas. Ocorre após o cálculo da nova funcionalidade "para a batalha", leva PO.
Após a demonstração, novas atividades são adicionadas ao backlog e, dependendo de sua prioridade e classificação, podem ser adicionadas ao sprint atual. Realizamos uma demonstração especificamente no meio da segunda semana, a fim de ter tempo para melhorias até o final do sprint.
Quinta-feira
O PO prioriza as listas Definidas (se durante o sprint as atividades forem concluídas antes do prazo esperado, será possível incluir novas atividades no trabalho desta lista) e Estimado (as atividades desta lista serão transferidas para um novo sprint).
Sexta-feira
O planejamento da sprint é realizado, no qual a equipe de desenvolvimento de PM e OP participa.
Há um ponto em que discutimos como trabalhamos no sprint atual e se estávamos bem preparados para o próximo: trocar opiniões, se tudo está claro no próximo sprint, se ainda temos recursos suficientes no recurso para corrigir bugs inesperados.
Está ocorrendo uma reunião de gerenciamento de riscos. No momento, estamos dedicando esse tempo ao estudo do produto, pois seu excelente entendimento reduz significativamente os riscos. O PM junto com os testadores durante a semana aloca tempo para estudar o produto e compartilha o resultado com a equipe. Representantes das unidades são convidados para a reunião para complementar a imagem.
Toda segunda sexta-feira é o fim não apenas da semana de trabalho, mas também do sprint. Este é um dia de comunicação e feedback. Assim, a segunda-feira da nova semana de trabalho começa com tarefas claras e apreciadas, o que também é lógico e confortável para a equipe.
Conclusões e próximos passos
Com a ajuda desse processo, foi possível estabelecer uma interação de alta qualidade entre o OP e a equipe, conflitos e mal-entendidos existem no passado. O clima na equipe melhorou e surgiu um senso de trabalho rítmico harmonioso. Obviamente, ainda existem muitos problemas, mas há muito menos situações emergenciais e imprevistas nas quais a equipe ou o gerente de projetos teve que salvar o projeto.
Como todos os seres vivos, nosso processo de tempos em tempos requer atualização. Agora vemos que vale a pena finalizar nas seguintes áreas:
- Bugs. O trabalho com erros também precisa ser planejado. Não podemos executar os bugs emergentes no processo de planejamento do sprint, é necessário mais trabalho operacional aqui. Estamos pensando em como fazê-lo.
- Queremos fazer uma tabela de riscos típicos para levá-los em consideração e reduzir a probabilidade de erros na implementação do sprint.
- Ao planejar um sprint, queremos desenvolver o objetivo do sprint para manter o foco do trabalho. A equipe é jovem, então há dificuldades com isso.
Esperamos que nossa experiência ajude sua equipe. Estamos prontos para discutir nossa abordagem nos comentários, responder a perguntas ou dar conselhos.