Quando a equipe discute os requisitos ao usar o Kanban?

Eu tenho lido um pouco sobre o Kanban e estou um pouco confuso sobre o tópico Requisitos.

No meu projeto atual, usamos Scrum. No início de uma Sprint, temos uma sessão em que o BA faz uma explicação passo a passo da história e a descreve da melhor maneira possível. Em seguida, pegamos a história, a revisamos, discutimos e preparamos uma pergunta para o BA para a próxima sessão de planejamento da Sprint. Na próxima sessão, o BA responde a todas as perguntas e a sessão termina conosco, tendo entendido os requisitos (na maioria das vezes).

O próximo passo é que produzamos um design técnico e desenvolvamos a solução / história.

Com o Kanban, tudo o que li sugere que não há Planejamento de Sprint no Kanban. Minha pergunta é em que momento (em Kanban) os técnicos e os empresários se sentam juntos para discutir o requisito da história? O gerente de produto ou a BA não fornece uma explicação da história em Kanban?

Com o Scrum, o BA geralmente está disponível em todo o Sprint para apoiar o desenvolvimento e presumo que seja o mesmo com o Kanban. Não está claro para mim, porém, como, com Kanban, os técnicos entendem a história se não houver um planejamento de sprint.

Você está certo que Kanban não tem o conceito de Sprints ou Sprint Planning como o Scrum. Isso porque é uma metodologia mais enxuta . Mais coisas são feitas na hora certa .

Cabe a você decidir como agendar as atividades de planejamento, mas eu recomendaria fazê-las o mais próximo possível do início do trabalho. Isso é mais eficaz quando há representantes de todas as principais partes interessadas incorporadas à equipe (o mesmo também torna o Scrum mais eficaz).

Penso que este diagrama, baseado em Discipline Agile Delivery , fornece uma boa representação pictórica de um processo de software lean:

Os eventos do Planejamento diário de pé e de sprint são capturados na reunião de coordenação e na sessão de modelagem de reabastecimento. A Reunião de Coordenação é mais como uma Standup Diária do Scrum e uma Sessão de Modelagem de Reabastecimento é mais como Refinamento de Backlog e Planejamento de Sprint. No entanto, não há problema em trazer algumas discussões de requisitos para a Reunião de Coordenação, se isso funcionar para sua equipe.

Como a maioria das coisas em um processo lean, isso acontece na hora certa. Não existem caixas de tempo e os eventos não acontecem em uma cadência específica, como acontece no Scrum. Você faz o trabalho quando agrega valor à equipe e às partes interessadas.

Que você pode comparar com uma representação pictórica de um processo baseado no Scrum modelado no contexto de Entrega ágil disciplinada:

Em vez de restringir-se a 2-4 semanas de Sprints com planejamento no início, stand-ups diários e uma revisão e retrospectiva no final, metodologias mais enxutas promovem suas demonstrações, coordenação e reuniões retrospectivas sempre que as partes interessadas acharem apropriado .

O Kanban fornecerá orientações para gerenciar sua lista de pendências de trabalho e trabalho em andamento (WIP). Você pode recorrer a outras técnicas e métodos para a implementação exata de outras atividades, já que o Kanban geralmente não fala sobre elas.

Você está deturpando / entendendo um pouco o que a reunião de Planejamento da Sprint faz no Scrum, o que eu acho que é a causa da sua confusão. Uma reunião de Planejamento da Sprint geralmente é o lugar errado para descobrir os detalhes das histórias. Além de alguns ajustes finais e uma rápida revisão para garantir que não haja preocupações pendentes que impactariam significativamente as estimativas, as histórias consideradas devem estar prontas para serem utilizadas. A partir daí, o Sprint Planning faz o que diz na lata: planeja o que será no próximo sprint. Se você não possui sprints, não há necessidade de planejar o sprint.

Então, quando os detalhes das histórias se realizam? Normalmente, por meio da preparação de lista de pendências ou em comunicações contínuas durante sprints anteriores. O objetivo aqui é obter clareza suficiente para que uma estimativa razoavelmente confiável possa ser fornecida. Isso não exige que todos os detalhes sejam resolvidos antes do tempo. Não importa o quanto você tente, sempre haverá perguntas que surgem durante a implementação. O objetivo no Scrum é que as perguntas que surgem durante a implementação sejam relativamente menores (essencialmente, pequenas o suficiente para não impactar qual seria a estimativa).

No Kanban, a estimativa é opcional. Se você estimar, é provável que faça algo semelhante ao Scrum, no sentido de que antes da história ser discutida, é discutida a elaboração de uma estimativa. Se você não faz uma estimativa, o comportamento real é semelhante, exceto que você não pode discutir uma história até que ela seja iniciada.

Na minha experiência, normalmente trabalhei em equipes que usavam uma abordagem semelhante ao Scrum para o desenvolvimento principal e depois mudaram para uma abordagem mais Kanban para a fase de manutenção. O trabalho na fase de manutenção tende a ser mais esporádico, e as histórias mais claramente definidas ab initio e em menor escala. Na fase principal de desenvolvimento, as histórias geralmente começam em alto nível e precisam ser refinadas e desmembradas para chegar a um ponto em que seriam aceitáveis ​​para um sprint. Iniciar essas histórias em um contexto Kanban faz pouco sentido e afundaria absolutamente suas métricas.

Não existe uma função oficial de "Analista de negócios" no Scrum ou no Kanban. É a equipe que analisa e estima histórias. Se o Sprint Planning é a primeira vez que a equipe de desenvolvimento está ouvindo os detalhes das histórias, algo está errado. Não estou dizendo que você não pode utilizar um bacharelado ou que todo desenvolvedor precisa estar em todas as reuniões de coleta de requisitos, mas algunsa representação dos desenvolvedores deve ocorrer em algum momento durante a coleta de requisitos antes do Sprint Planning. Um BA geralmente não tem conhecimento suficiente sobre os detalhes da implementação para saber o custo das coisas ou quais perguntas podem ter um impacto significativo no custo. Isso significa que existem detalhes que podem afetar drasticamente as estimativas que não serão reconhecidas até que a equipe de desenvolvimento as veja. Além disso, os desenvolvedores podem fornecer orientações para abordagens mais econômicas ou sugerir recursos que são relativamente fáceis de implementar, mas podem agregar muito valor ao usuário. O que eu suspeito que possa estar acontecendo no seu caso é que os desenvolvedores estão ajudando o BA, na medida em que o BA faz a coleta de requisitos (por exemplo, respondendo a perguntas do BA ou fornecendo estimativas de ordem de magnitude), e que isso está substituindo aproximadamente o Backlog Grooming. Como alternativa, você está realizando um trabalho (por exemplo, trabalho de manutenção) que chega naturalmente em pacotes relativamente pequenos; nesse caso, o Kanban pode ser um processo mais apropriado.

Estou editando minha resposta com base nos comentários que recebi para ajudar a entender como e quando você deve trabalhar no estágio Requisitos e Planejamento do Sprint do seu Sprint; como também na aplicação do Método Kanban aos seus processos atuais. Para os fins da minha resposta, estou usando os termos "Kanban" e "Método Kanban" de forma intercambiável, com os quais quero dizer as recomendações do Método Kanban. Eu espero que isso ajude.

Primeiro, você não deve alterar nada sobre o processo de desenvolvimento / elaboração de requisitos "para o Kanban" - porque o Kanban não faz nenhuma recomendação lá. Tudo o que Kanban recomenda é que você visualize seus processos atuais, incluindo gerenciamento de requisitos e planejamento de sprint, implemente limites de WIP e gerencie o fluxo. Posteriormente, faça as alterações em seu processo com base nos gargalos e nas oportunidades de melhoria observadas.

[Eu sugiro fortemente que, se você ainda não o fez, leia o livro - " Kanban: mudança evolutiva bem-sucedida para seus negócios de tecnologia ", de David Anderson, pioneiro do Método Kanban. (Exclusão de responsabilidade - sou co-fundador de uma empresa de produtos Kanban. Também sou treinador e instrutor Kanban certificado pela Universidade Lean Kanban.)

O Kanban em si não é uma metodologia de desenvolvimento de software / gerenciamento de projetos. Sem um processo existente, você não pode aplicar / implementar o Kanban. É um método para ajudá-lo a melhorar de maneira evolutiva (gradual, sem interrupções), quaisquer que sejam seus processos atuais. No seu caso, isso é Scrum. Portanto, você realmente deve aplicar o Kanban em seus processos Scrum para ajudar sua equipe a melhorar sua entrega de software. A combinação disso é conhecida popularmente como Scrumban.

Você começaria seguindo os três princípios básicos do Kanban -

1. Comece com o que você faz agora
2. Concorda em buscar mudanças evolutivas e incrementais
3. Respeitar os processos, funções, títulos e responsabilidades atuais

Utilizando-os como princípios orientadores, você implementa as práticas padrão do Método Kanban - que são -

1. Visualize seu processo atual (e o trabalho em andamento)
2. Limitar WIP (trabalho em andamento)
3. Gerenciar fluxo
4. Tornar explícitas as políticas de processo

Comece com essas 4 práticas. Existem 2 outras práticas definidas no Método Kanban que você pode ver depois de começar e ter uma noção. Estes são (5) implementar loops de feedback e (6) melhorar e evoluir de forma colaborativa, usando o método científico.

Este é um resumo rápido - o livro realmente ajudará você a entender melhor isso. Também há um abrangente Guia Kanban disponível em nosso site.]

O importante a se concentrar na sua situação é visualizar (em um quadro Kanban) o que você está fazendo hoje. Seu processo atual de requisitos deve ser seguido durante o processo de planejamento da sprint ou em algumas sub-etapas que você pode optar por visualizar. De fato, seu quadro Kanban deve refletir o planejamento da Sprint como um estágio específico do processo geral de desenvolvimento, seguido pelo design técnico, desenvolvimento e teste, conforme o caso.

Enquanto as histórias do usuário estão no estágio de planejamento do sprint, você deve seguir as etapas, como a BA fornecendo detalhes, desenvolvedores preparando perguntas e respondendo-as antes que a história avance para o estágio de design técnico e além.

(BTW, se o seu processo de Requisitos tiver algum aspecto upstream que possa ser considerado parte do planejamento do roadmap ou da preparação da lista de pendências, existe um tópico completo de "Upstream Kanban" que ajuda você a gerenciar melhor as atividades upstream com o máximo de detalhes possível Você ou seu BA / PO pode considerar usar um quadro Kanban upstream separado para gerenciar toda essa atividade.)

O fluxo do seu quadro Dev Kanban pode se parecer com o abaixo -

Lista de pendências -> Sprint Planning -> Design técnico -> Dev -> Teste -> Integrar -> Concluído

Cada um dos estágios pode ter suas próprias sub-colunas "Em andamento" e "Concluído" - embora se um único desenvolvedor passar por todos os estágios, talvez você não precise dessas sub-colunas em cada estágio. Se você achar que é importante, poderá dividir o Planejamento da Sprint em três sub-etapas - Detalhamento da história, Esclarecimentos e Concluído, para potencialmente poder estudar gargalos em cada aspecto do trabalho. Por exemplo, em nossa própria equipe de desenvolvimento, a revisão de código pode ser um gargalo com frequência!

No final do seu ciclo de sprint de 2 ou 3 semanas, todas as histórias de usuário concluídas podem ser coletadas - e você começa com o próximo conjunto de histórias do Backlog.

Durante um período de tempo, você pode decidir que alguns dos desafios de fazer o Scrum (vazamento de história, prazos perdidos de sprint etc.) podem ser resolvidos eliminando algumas das restrições / regras do Scrum - que podem parecer sacrílego para alguns. Nós mesmos fazemos lançamentos de 4 a 6 semanas - e não fazemos Sprints. Mas igualmente bem, você pode continuar trabalhando com Sprints e Releases. Em nossa experiência, é aqui que o Kanban ajuda você a decidir o que é certo para o seu negócio ou equipe e a adotar ou modificar seus processos que ajudam a entregar seu trabalho da melhor maneira possível, o que maximiza o fluxo, a taxa de transferência / velocidade e reduz os prazos de entrega ( tempo de colocação no mercado).

Se você decide acabar com o Sprints e apenas fazer lançamentos como e quando um número suficiente de recursos tiver sido construído (ou defeitos corrigidos ou uma combinação de ambos) - ou se você mantiver o Sprints - o Kanban deve ajudar sua equipe a trabalhar com mais tranqüilidade, eliminar gargalos e melhorar o desempenho do tempo de ciclo. Se isso ajuda você a fazer lançamentos mais frequentes, o que, por sua vez, ajuda a obter um feedback mais rápido do cliente, agora você está migrando para o que você poderia chamar de um estado de coisas "mais ágil", mas que pode não se encaixar necessariamente na definição clássica do método Scrum.

No entanto, se as metas de negócios estiverem sendo atendidas melhor, os clientes ficarão mais felizes e sua equipe poderá funcionar da melhor maneira possível, você teria alcançado seus objetivos de implementar o Kanban.

Espero que isto ajude. Se você tiver alguma dúvida, ficarei feliz em respondê-las.

Para aprimorar especificamente suas perguntas ...

em que ponto (em kanban) os técnicos e os empresários se sentam juntos para discutir o requisito da história? O gerente de produto ou a BA não fornece uma explicação da história no Kanban?

O Método Kanban , pioneiro em David Anderson, não contém uma prática ou recomendação específica sobre quando essas atividades acontecem. A resposta que qualquer profissional do Kanban forneceria é que, inicialmente, ao adotar o Método Kanban , você deve executar essa atividade da mesma maneira que antes de decidir evoluir a maneira como gerencia o trabalho. Se você executá-lo a cada 2 semanas, você deve continuar a executá-lo a cada 2 semanas.

Sua equipe descobrirá se há uma oportunidade e valor na alteração do cronograma. Lembre-se de que a programação de 1 mês é mais ágil que 1 ano, uma programação de 2 semanas é mais ágil que 1 mês, 1 semana é mais ágil que 2 semanas. Esse pensamento acaba nos levando a tempo como os mais ágeis . Ser o mais ágil não deve ser a condição de destino antes mesmo de começar.

Com o Scrum, o BA geralmente está disponível em todo o Sprint para apoiar o desenvolvimento e presumo que seja o mesmo com o Kanban. Não está claro para mim, porém, como, com Kanban, os técnicos entendem a história se não houver planejamento de sprint.

O Método Kanban, como uma mentalidade e um conjunto de práticas, não impõe condições ou restrições à existência de uma reunião da Sprint, do Sprint Planning ou de outras práticas. É completamente respeitoso para uma equipe Scrum e suas práticas. Se você tem uma reunião hoje em que os Técnicos discutem a história, você continuaria a ter essa reunião, usando o mesmo cronograma.

Eu não poderia, em sã consciência, dizer qual seria o cronograma / deveria / poderia ser sem entender sua equipe e a organização ao seu redor. Se você não realiza essas atividades hoje, existem muitas outras fontes de informações para ensiná-lo a fazer essas atividades. O Método Kanban pode fornecer orientação para ensinar você a descobrir se suas escolhas são boas.

Leia as postagens do blog nessas duas séries. Um de mim mesmo e outro de Steve Porter, membro da equipe no Scrum.org.

Nada no Kanban impede Scrum - Dave White - WesternDevs.com

Scrum e Kanban - juntos mais fortes - Steve Porter - Scrum.org

A maior parte do que Mahesh Singh diz no topo é do material de treinamento publicado da Lean Kanban Inc. Então, realmente ... não há nada a discutir aqui. Converse com qualquer AKT ou KCP e ele / ela dirá a mesma coisa.

Para a pergunta original sobre onde você poderia fazer esclarecimentos sobre os requisitos, existem várias opções:

1. Você poderia fazer o que faz hoje, mas visualizando e colocando essas etapas em um fluxo de valor, identifique seus impedimentos. Em seguida, faça uma alteração e veja como isso funciona. A comunidade Toyota Kata chama isso de experimentos de fator único.

2. Faça uma placa upstream para refinamento de requisitos, decomposição, design de UX / interação, etc. Em seguida, as histórias são priorizadas ao reunir todas as partes interessadas em uma reunião. O final desse fluxo de valor resulta em histórias refinadas e priorizadas. Isso constitui nosso atraso para a equipe de desenvolvimento. De fato, esse fluxo leva muito tempo de ciclo, principalmente porque leva tempo para passar de um requisito de nível Épico para quadros de estrutura de arame no Sketch ou no Zeppelin para a equipe de desenvolvimento.

3. Se você não tiver um fluxo de valor significativo ou tempo de ciclo para converter algo de requisito em histórias refinadas, poderá simplesmente ter um estágio no seu fluxo de valor de Desenvolvimento (como esclarecimento de requisitos). No entanto, o Scrum espera alto nível de clareza para estimativa e quebra de tarefas. Portanto, se você faz uma reunião antes da reunião de planejamento da Sprint ou faz uma reunião de planejamento prolongada da Sprint, isso dependerá da sua equipe e organização.

Se lembramos dos princípios e somos abertos às práticas definidas, o ciclo Inspecionar e Adaptar se torna muito mais fácil.