Modelo de Gestão de Projetos Kanban para Projetos de Ciência e Inovação

Kanban é uma estrutura popular usada para implementar o desenvolvimento de software ágil e outros tipos de projetos. Requer comunicação em tempo real e total transparência do trabalho. Os itens de trabalho são representados visualmente em um quadro kanban, permitindo que os membros da equipe vejam o estado de cada parte do trabalho a qualquer momento.

Revisões #

Versão	Data	Alterações / Comentários	Revisor(es)
1.0.0	12/12/2022	Criação do documento.	Bruno Souza
1.0.0	20/12/2022	Inclusão do ritual “Reunião de Planejamento”. Inclusão da seção “Time Kanban”. Inclusão da seção “Ferramenta de Gestão”. Revisão geral.	Bruno Souza
1.0.0	15/07/2024	Alteração do título do documento para “Modelo de Gestão de Projetos Kanban para Projetos de Ciência e Inovação”	Bruno Souza

O que é Kanban? #

O Kanban é um framework para gestão de projetos que utiliza a metodologia ágil. O vídeo a seguir apresenta uma visão geral do que é Kanban:

O objetivo desse documento é delinear as orientações gerais para aplicar o framework kanban em projetos de desenvolvimento de software do Instituto Modal.

Conceitos do Kanban e como são aplicados #

Backlog do produto #

É uma lista ordenada / priorizada de tudo que deve ser necessário no produto. O backlog é composto por itens de backlog do produto (PBIs – Product Backlog Items), que podem ser qualquer coisa – requisitos de mercado, casos de uso, especificações e histórias de usuários, por exemplo (ver História de Usuário).

• Na ferramenta Taiga serão utilizadas as histórias de usuário para criar os itens de backlog do produto
  • Para a necessidade de um usuário do sistema, os requisitos serão escritos em forma de Histórias de Usuário, com os devidos critérios de aceite.
  • Para outras especificações, na forma mais adequada à necessidade.

História de Usuário #

É uma qualificação do backlog do produto, solicitado pelo usuário, que descreva uma pequena parte do projeto que, ao ser concluída, apresente um aspecto do resultado do produto que seja funcional e útil para o cliente / usuário.

Uma história de usuário segue geralmente a seguinte estrutura:

1. Descrição da história seguindo o modelo:
   ”COMO <papel do usuário do sistema>, DESEJO / PRECISO / QUERO <ação a ser executada pelo sistema> PARA <objetivo a ser atingido pela ação>.”
   Exemplo:
   “COMO membro de uma equipe da unidade policial, DESEJO visualizar detalhes de um processo de forma cronológica PARA acompanhar o andamento processual no PJe.”
2. Critérios de Aceite, que são os requisitos necessários para o desenvolvimento e validação da história (ver Critérios de Aceite). Pode haver vários critérios de aceite para a mesma história.
3. Anexos, que podem ser protótipos de telas, regras de negócios, documentos ou outros artefatos que facilitem a execução da história.

Deve ser considerado o acrônico INVEST para a atividade de refinamento das histórias de usuário – Independente, Negociável, Valiosa, Estimável, Small (Pequena) e Testável.

• Independente: significa que a história não depende de outras histórias para ser executada, ou seja, poderá ser realizada em qualquer momento, independente da ordem cronológica.
• Negociável: trata da negociação entre a equipe de negócio e a equipe técnica para buscar apenas a essência do requisito e não o seu detalhamento, pois uma história poderá evoluir ao longo do projeto.
• Valiosa: é a capacidade da história em agregar valor ao cliente e ao produto.
• Estimável: refere-se à capacidade de estimar a dimensão de uma determinada história para poder ser priorizada com o objetivo final de permitir o planejamento do roadmap futuro.
• Small: histórias pequenas e capazes de serem estimadas, porém, não tão pequenas que não agreguem valor ao cliente. Uma história grande demais tira o foco do desenvolvimento, o que exige quebrá-la em duas ou mais histórias menores e que permitam a entrega do valor.
• Testável: a história deve ser passível de teste, ou seja, é necessário validar se os critérios de aceite foram atendidos de maneira satisfatória para poder ser verificada a sua conclusão.

Além das histórias de usuário, também pode existir itens de backlog (que, no sistema de gestão adotado pela NBTI, também se chamam histórias de usuário). Os itens de backlog seguem a mesma ideia geral das histórias, no entanto, possuem uma perspectiva mais técnica, voltada para construção de funcionalidades necessárias que não passam, necessariamente, pela necessidade da definição de um usuário. Alguns exemplos de itens de backlog seriam a preparação de um ambiente de trabalho / desenvolvimento / homologação / produção; o desenvolvimento de um serviço de backend a ser consumido; a elaboração de um documento de referência, relatório técnico ou similar etc.

Neste documento, para simplificar, será utilizada o termo “história de usuário” (ou simplesmente “história”) para designar tanto itens de backlog quanto histórias propriamente ditas, exceto quando necessário fazer uma diferenciação.

Critérios de Aceite #

Para a definição dos critérios de aceite de uma história de usuário, utiliza-se a técnica BDD (Behavior-Driven Development, ou Desenvolvimento Orientado por Comportamento). O BDD é técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando o comportamento do software. Isso significa que os testes orientam o desenvolvimento, ou seja, primeiro se escreve o teste e depois o código.

BDD ajuda a simplificar a comunicação usando cenários descritos pelo cliente ou PO. Cada cenário é dividido em três blocos definidos pelas palavras-chave:

• Given (DADO) – dado um contexto;
• When (QUANDO) – quando acontecer um evento;
• Then (ENTÃO) – então se espera que aconteça algo.

Exemplo:

”DADO que <tal ação seja executada pelo usuário>, ENTÃO <executar alguma ação>.”

“DADO que <tal evento aconteça>, ENTÃO <executar alguma ação>.”
Na prática:
“DADO que a aba de movimentações seja iniciada ENTÃO montar uma estrutura contendo o histórico de interações do processo.

1. A timeline será montada por ‘itens da lista de movimentação’
2. Um ‘Item da lista de movimentação’ será montado com as seguintes informações:
   1. Os eventos relacionados a entrega da petição, seja ela inicial, incidental ou avulsa
   2. Os dados de ‘Documentos’ e ‘Movimentações’ retornados do endpoint ‘Consultar processo’
   3. Os ‘itens da lista de movimentação’ devem ser, por padrão, organizados e apresentados do mais recente para o mais antigo.”

Tarefa #

Uma tarefa é a menor unidade de uma história de usuário que represente uma atividade concreta, finita e mensurável a ser executada. Uma história terá uma ou mais tarefas necessárias a sua finalização. Além disso, todas as tarefas necessárias para a conclusão da história devem estar listadas na própria história.

De maneira semelhante ao que acontece nas histórias, o time pode usar o acrônico SMART para quebrar as histórias em tarefas:

• Específica (Specific): toda tarefa deve ter uma responsabilidade única, ser coesa com seu objetivo e entregar apenas uma parte de uma história de usuário, e todas juntas contribuem para atingir os critérios de aceitação da história de usuário.
• Mensurável (Measurable): não importa a unidade de medida, embora o ágil encoraje muito mais o uso de pontos do que de horas. O importante é medir, seguindo os critérios técnicos do time, para garantir a entrega no timebox do projeto conforme as necessidades do cliente.
• Alcançável (Achievable): as tarefas devem ser alcançáveis pelos seus responsáveis, com as competências e recursos necessários para conseguir entregá-la.
• Relevante (Relevant): as tarefas devem agregar valor à história e tem que ser explicáveis e justificáveis. Elas são quebradas para auxiliar os desenvolvedores a organizarem seu trabalho. Se a tarefa não agrega valor, então ela é irrelevante para a história e, portanto, não deve ser feita.
• Temporal (Time-Boxed): as tarefas precisam ter um tempo definido para serem concluídas, delimitadas a um timebox específico. Não é necessário fazer uma estimativa formal em horas ou dias, mas deve haver uma expectativa de conclusão.

Épico #

Tecnicamente, um Épico é uma grande história de usuário, que inclui várias funcionalidades, requisitos, recursos etc. – tão grande que levaria um tempo demasiadamente longo para que se encaixe no acrônimo INVEST.

Para o presente modelo de implementação do framework Kanban, consideramos o Épico como um conjunto de histórias de usuário suficientes para justificar o lançamento de uma nova versão do produto ou para fazer uma entrega consistente de um grupo de funcionalidades ou resultados. Dessa forma, um Épico deverá incluir:

• todas as histórias de usuário necessárias para o lançamento da nova versão do produto ou de um grupo de resultados;
• um item de backlog específico para registrar as tarefas de deploy da nova versão ou de preparação da entrega dos resultados.

O Épico deve conter pelo menos as seguintes informações:

• Versão, para informar a versão da release, a tag a ser entregue
• Data da Entrega, para informar a data de entrega das histórias para o cliente

Após a entrega de um Épico é conveniente realizar uma reunião de retrospectiva para que o time Kanban possa avaliar em conjunto o andamento dos trabalhos, apontar boas práticas e propor melhorias para a execução do projeto.

Time Kanban #

Um time Kanban é tipicamente composto por profissionais de diferentes áreas que trabalham como uma equipe de alto desempenho. Usualmente, participam de um time Kanban:

• Gerente de Projeto: responsável por atuar como “guardião” do framework Kanban, por facilitar a comunicação entre a equipe e por retirar os impedimentos para o andamento do projeto
• Analista de Requisitos: responsável por fazer a “ponte” com o cliente e traduzir os requisitos em histórias de usuário; simultaneamente, atua como referência para o Time DEV em relação ao entendimento das necessidades e desejos do cliente.
• Time DEV: são os profissionais responsáveis pelo desenvolvimento técnico do projeto. Formalmente, não há distinção de funções dentro do Time DEV – todos devem se posicionar para contribuir para o sucesso do projeto com um todo. Em um projeto de desenvolvimento de software, o time DEV teria profissionais como desenvolvedor front / back / fullstack, administrador de banco de dados, arquiteto de software, designer, analista de testes etc.
• Outros colaboradores: conforme a necessidade de cada projeto, outros profissionais podem ser convidados a participar Time Kanban de maneira pontual, para executar tarefas específicas. No entanto, diferentemente do Gerente de Projeto, do Analista de Requisitos e do Time DEV, esses profissionais são temporários: uma vez concluídas suas tarefas, se afastam do projeto.

Rituais do Kanban #

Reunião de Planejamento #

As reuniões de planejamento devem ser realizadas sempre que necessário.

Seus objetivos incluem:

• fazer o refinamento das histórias com a equipe do projeto
• alinhar o entendimento das histórias de usuário com o Time DEV
• definir quais histórias comporão cada etapa do roadmap do produto
• pontuar as histórias em função do grau de complexidade, utilizando a ferramenta PlanIT Poker sempre que possível

Participam da reunião de planejamento:

• o gerente de projeto
• o analista de requisitos
• o Time DEV
• também podem ser convidados outros profissionais, conforme a necessidade do projeto

As reuniões de planejamento devem ser documentadas na forma de relatório, ata ou outro documento que registre, de maneira clara e objetiva, os resultados alcançados e as decisões tomadas. O relatório deve ser de fácil acesso para toda a equipe.

Reunião Diária #

Para o framework Kanban, as reuniões diárias são fortemente recomendadas. Sua duração é de aproximadamente 15 minutos, onde cada membro do time Kanban responde a três perguntas:

1. O que foi feito nas últimas 24 horas?
2. O que será feito nas próximas 24 horas?
3. Existe alguma coisa impedindo ou atrapalhando o desenvolvimento das atividades?

Participam das reuniões diárias:

• o gerente de projeto
• o analista de requisitos
• o Time DEV

Reunião de Retrospectiva #

Quando da entrega de um épico ou nova versão, é conveniente realizar uma reunião de retrospectiva para que o time Kanban possa avaliar em conjunto o andamento dos trabalhos, apontar boas práticas e propor melhorias para o método de trabalho.

O relatório da reunião de retrospectiva pode ser anexado ou no próprio Épico a que se refere ou em um item de backlog específico, conforme a conveniência do projeto.

Execução do Projeto #

Ferramenta de Gestão #

Foi escolhida a ferramenta Taiga para a gestão de projetos, que pode ser acessada pela URL https://scrum.modal.org.br/.

O Taiga trabalha tanto com o framework Scrum quanto o Kanban, sendo simples, de fácil aprendizado e apresentando todos os recursos e funcionalidades essenciais.

Deve ser concedido acesso ao Taiga para o cliente, com perfil que permita:

• ler e comentar histórias de usuários, tarefas e épicos
• criar problemas (issues)
• ler e comentar as páginas da Wiki do próprio Taiga
• outras permissões podem ser concedidas conforme as necessidades do projeto e o perfil do cliente

Ciclo de Desenvolvimento das Histórias de Usuário #

As colunas das histórias representam a situação de cada história, marcando a sua etapa no ciclo de execução do projeto.

Backlog (ou Novo) #

• Esta coluna tem somente a descrição da história de usuário.
• A responsabilidade em criar um item de backlog é de qualquer integrante do projeto, porém as histórias de usuário são do Analista de Requisitos.

Preparando #

• Nesta coluna é puxada a história para preparação.
• No caso de História de usuário:
  • A responsabilidade pela preparação é do Analista de Requisitos
  • O time DEV e o Cliente participa da preparação entendendo e direcionando os critérios para que a história de usuário seja clara, consistente e testável.
• A responsabilidade em mover um item de backlog para esta coluna é de qualquer integrante do projeto, porém as histórias de usuário são do Analista de Requisitos.

Preparado #

• Esta coluna representa que a história de usuário foi preparada e validada pelo cliente.
• No caso de história de usuário, representa que os Critérios de Aceite foram definidos, refinados e priorizados pelo Analista de Requisitos.
• A história é dividida em tarefas e pontuada pelo time DEV.
• A responsabilidade em mover um item de backlog para esta coluna é de qualquer integrante do projeto, porém as histórias de usuário são do Analista de Requisitos.

Desenvolvendo #

• Nesta coluna é puxada a história de usuário quando o seu desenvolvimento iniciado.
• O desenvolvedor pode criar tarefas, além daquelas já definidas na reunião de planejamento.
• A responsabilidade em mover a história para esta coluna é do primeiro desenvolvedor que iniciar o desenvolvimento.

Pronto para Teste #

• A história de usuário nesta coluna representa que o desenvolvimento foi concluído e que a história está pronta para ser testada pela equipe de testes.
• Nesta coluna, os testes internos e rotineiros podem ser executados antes da publicação no ambiente de homologação.
• A responsabilidade em mover a história de usuário para esta coluna é do desenvolvedor, o último a concluir o desenvolvimento.

Testando #

• Esta coluna abriga as histórias de usuários que se encontram em testes pela equipe interna para testes rotineiros.
• Poderão ser abertos problemas para que o(s) desenvolvedor(es) que implementou(ram) a história possa(m) corrigi-los.
• A responsabilidade em mover a história de usuário para essa coluna é do analista de testes que fará os testes rotineiros, ou, quando não houver analista de teste, pelo Analista de Requisitos.

Pronto para Homologação #

• A história de usuário que estiver nessa coluna está apta a ser homologada pelo cliente.
• A responsabilidade em mover a história de usuário para essa coluna é do Analista de Testes que concluiu os testes rotineiros ou, na sua ausência, do Analista de Requisitos.

Em Homologação #

• A história de usuário Em Homologação é aquela que está sendo validada pelo usuário / cliente.
• O cliente poderá abrir problemas para que o(s) desenvolvedor(es) que implementou(ram) a história possa(m) corrigi-los.
• A responsabilidade em mover a história de usuário para essa coluna é do Cliente / Usuário.

Homologado #

• Nesta coluna é puxada a história de usuário homologada pelo Cliente / Usuário.
• A responsabilidade em mover a história de usuário para esta coluna é do Cliente / Usuário.

Publicando #

• A história de usuário nesta coluna indica que ela está em processo de publicação no ambiente de produção, já tendo sido homologada pelo Cliente.
• O Gerente do Projeto pode criar um Épico para representar a entrega e anexar todas as histórias que farão parte dele. O Épico deve conter pelo menos as seguintes informações:
  • Data da Entrega, para informar a data de entrega das histórias para o cliente
  • Versão, para informar a versão da release, a tag a ser entregue
• Nos comentários, incluir quaisquer observações pertinentes para orientar a equipe de infraestrutura quanto à publicação.
• A responsabilidade em mover a história para essa coluna é do Gerente de Projeto.

Publicado #

• A história de usuário nesta coluna está finalizada e disponível no ambiente de produção do cliente.
• A responsabilidade em mover a história de usuário para esta coluna é do responsável pela publicação no ambiente de produção ou, em sua ausência, do Gerente do Projeto.

Arquivado #

• Nesta coluna é puxada a história de usuário que se tornou obsoleta ou que, uma vez concluída, não impacta no lançamento de uma versão do produto.
• Alguns exemplos de histórias de usuário que podem ser arquivadas são:
  • Preparar ambiente de desenvolvimento / homologação / produção
  • Criar repositório
  • Pesquisar soluções de software existentes
  • etc.
• A responsabilidade em mover a história de usuário para esta coluna é do Gerente do Projeto.

Fluxo do ciclo de desenvolvimento da História #

Gestão das Tarefas #

As tarefas, incluídas em cada história de usuário ou item de backlog, determinam o que deve ser de fato executado para que a história se concretize. Toda história de usuário deverá possuir, obrigatoriamente, uma ou mais tarefas – quantas forem necessárias para que a história seja desenvolvida em sua totalidade.

As tarefas podem ser criadas a qualquer momento pelo time DEV, em especial pelo Desenvolvedor que inicia o desenvolvimento da história de usuário.

Usualmente, durante uma reunião técnica para entendimento da história, o time DEV incluirá as tarefas necessárias para a conclusão da história. No entanto, a qualquer momento novas tarefas podem ser incluídas pelo time DEV ou pelo Desenvolvedor que inicia o desenvolvimento da história de usuário – afinal, o projeto é um organismo vivo e que se constrói à medida que as histórias vão sendo desenvolvidas.

As tarefas de uma história de usuário possuem os seguintes status:

Novo #

• A execução da tarefa ainda não foi iniciada.

Em Andamento #

• A tarefa está sendo realizada.
• O DEV que iniciar o trabalho da tarefa é o responsável por definir esse status.

Fechado #

• A execução da tarefa foi concluída.
• O DEV que iniciar o trabalho da tarefa é o responsável por definir esse status.

Precisa de Informação #

• Existe algum impedimento para a continuidade da execução da tarefa.
• Cabe ao DEV que iniciar o trabalho da tarefa e perceber que não é possível avançar por falta de alguma informação é o responsável por definir esse status.

Fluxo do ciclo de vida de tarefas #

Problemas #

Um “problema”, no contexto da gestão de projetos, é uma funcionalidade, recurso ou outro aspecto de uma história que não cumpre um ou mais critérios de aceite.

Caso um problema seja identificado durante o desenvolvimento de uma tarefa, ele deve ser tratado e resolvido diretamente pelo desenvolvedor da tarefa, de maneira imediata.

No entanto, problemas também são identificados:

1. Durante os testes rotineiros (coluna Testando), antes de liberar a história para homologação do cliente;
2. Enquanto estiver sendo homologada pelo cliente (coluna Em Homologação).

Três tipos de problemas devem ser relatados assim que identificados durante a fase de testes internos e/ou pelo cliente, durante a homologação:

1. Erro (Bug) – inconsistência, erro, não aderência ao escopo da história.
2. Pergunta – utilizada pelo Desenvolvedor quando um problema está sem evidência ou não está claro o entendimento.
3. Melhoria – um novo aspecto, classificado e entendido como uma evolução da história que pode provocar duas situações:
   • Faz parte do escopo, então será priorizado o desenvolvimento o mais rapidamente possível.
   • Não faz parte do escopo, então será levado para a gestão do contrato.

Diretrizes na abertura dos problemas: #

• Problemas abertos nos testes de homologação do cliente (coluna Em Homologação): Incluir tag “homologação”
• Problemas abertos nos testes rotineiros (coluna Testando): incluir a tag “rotineiro”
• Incluir tag com o número da história com o símbolo #. Exemplo: #25
• Se o problema foi fechado, mas, por algum motivo, não foi resolvido, é preciso abrir outro.

Uma vez aberto um problema, idealmente o mesmo deve ser resolvido pelo desenvolvedor imediatamente – quanto mais tempo demorar o início da solução do problema, maior será a dificuldade para a sua solução!

Fluxo do ciclo de vida dos problemas do tipo BUG #

Fluxo do ciclo de vida dos problemas do tipo PERGUNTA #

Fluxo do ciclo de vida dos problemas do tipo MELHORIA #

Considerações finais #

O framework Kanban traz muitos benefícios para a execução de projetos de diversos tipos, sendo mais comumente usado no desenvolvimento de softwares.

Sua aplicação pode (e deve) ser ponderada com a realidade do projeto e a cultura do cliente, sendo possível adaptar alguns de seus aspectos para melhorar o andamento dos trabalhos.

Deve-se evitar que uma mesma equipe participe de mais de um projeto simultaneamente!