O ciclo de 6 semanas: uma alternativa muito necessária para Scrum e Kanban

Muitas empresas adotaram uma mentalidade ágil. Dentro dessa mentalidade ágil, Scrum ou Kanban formam a estrutura tática. Mas como você fornece algo com mais substância, mas menos intensidade do que sprints do scrum? Neste artigo, compartilho minha busca e resultado – o ciclo de 6 semanas – com você.

Eu trabalhei com Scrum, mas durante a maior parte da minha carreira fui uma rocha sólida na equipe Kanban. O gerenciamento de projetos, portanto, era assim: mapeei um roteiro de produto por 12 meses e a equipe de tecnologia escolheu os projetos para começar a trabalhar.

“Inferno do desenvolvimento”

Quando uma ideia de produto parecia importante, eu geralmente a colocava no topo da nossa lista de tarefas. E isso foi descoberto no dia seguinte por um desenvolvedor.

Esta, pensei, é a ideia por trás ágil. Você permanece flexível e enxuto a todo custo. Como equipe, você deseja poder mudar seu foco para o que agrega mais valor à sua organização naquele momento.

E isso funcionou com novos produtos. Continuamos lançando novos recursos e o produto ficou melhor a cada semana. Ideias espontâneas podiam ser lançadas na lista de tarefas do quadro kanban e escolhidas pelo desenvolvedor que chegasse lá mais rápido.

Mas em um ponto essa abordagem mostrou suas limitações. Desenvolvimento de recursos de repente parecia não ter fim. Os desenvolvedores desenvolveram sintomas de esgotamento. E o produto quase não melhorou.

Procurando por uma nova estrutura

Para resolver isso, comecei a busca por uma nova estrutura de gerenciamento de projetos. Precisávamos de uma estrutura com certas limitações que levasse a mais criatividade. Ao mesmo tempo, essa estrutura precisava ser ágil o suficiente para continuar funcionando rapidamente. E esse processo precisava ser repetido ao longo do ano e caber em nossas ferramentas de negócios.

Eu estava procurando por algo com mais substância, mas menos intensidade do que sprints do scrum. As estimativas detalhadas das histórias e a duração do sprint scrum apertado de duas semanas não são práticas devido à sobrecarga que envolvem. E como os sprints do scrum são muito curtos para desenvolver algo significativo, você ainda tem projetos para arrastar por um período indefinido de tempo. Embora agora em prazos de duas semanas.

A solução: um ciclo de 6 semanas (o ciclo de seis semanas)

O que acabou sendo a solução para minha empresa foi usar um ciclo de 6 semanas, com base em Ciclo-filosofia de seis semanas do Basecamp.

A ideia por trás disso é a seguinte. A cada seis semanas você inicia um novo ciclo de projetos que você divide em duas categorias:

  • Grande lote: esses projetos são grandes projetos ou recursos que geralmente levam 6 semanas para serem concluídos.
  • Lote pequeno: esses projetos são pequenas correções de bugs ou melhorias que podem levar de um dia a duas semanas.

Para lhe dar uma imagem mais concreta disso: este é um memorando em que anunciei nosso primeiro ciclo de produto.

Depois de completar um ciclo de seis semanas, é hora de um período de resfriamento de duas semanas. Os desenvolvedores podem escolher projetos de forma independente, implementar melhorias ou pesquisar novas tecnologias durante esse tempo, sem estar vinculado a um cronograma apertado. Isso estimula a criatividade e mantém os níveis de energia elevados. Você também usa este período para planejar projetos para o próximo ciclo.

Gostaria de enfatizar aqui que um ciclo não é a mesma coisa que um sprint. Os sprints são acompanhados de estresse e exaustão, o que leva às pessoas a ficarem exaustos e, assim, a iniciar o novo sprint de forma ineficiente. Um ciclo proporciona calma.

Planejando um ciclo

Quando um novo ciclo começa, você trabalha em paralelo em novas idéias de produtos para o próximo ciclo.

Logo após a conclusão do ciclo, é hora de uma reunião para discutir os argumentos de venda para o próximo ciclo. Pitches são recursos desenvolvidos pela equipe de produto durante o ciclo anterior. Para propostas que são recursos de novos produtos, o design UX e o design gráfico devem estar pelo menos 80-90% concluídos.

Essa reunião pode levar até duas horas. Com a gente, os membros da equipe que participaram foram o CTO, um número seleto de desenvolvedores sênior e eu. Todos estudaram cuidadosamente os argumentos de venda submetidos antes da reunião, e o objetivo da reunião é determinar quais argumentos serão desenvolvidos durante o próximo ciclo.

Fique dentro de 6 semanas

Após anos de desenvolvimento de software, acredito que uma excelente ‘versão de seis semanas’ pode ser desenvolvida a partir de quase qualquer projeto. Isso só é possível se você realmente ousar olhar criticamente para um projeto: o que deve ser, em vez do que pode ser? Isso significa que antes de começar a desenvolver um recurso, você já começa a cortar. Você se concentra na essência e abandona tudo o que não contribui substancialmente para isso.

Portanto, quando você iniciar o projeto, terá poucas ou nenhuma surpresa. Dessa forma, as 6 semanas do ciclo são sobre implementação e execução – não planejamento.

Proteja seus desenvolvedores

Para garantir que você não ultrapasse seis semanas, você precisa proteger sua equipe de tecnologia.

Você faz isso dizendo não às solicitações ‘rápidas’ de, por exemplo, um gerente de conta. Se uma pessoa não técnica pensa “isso não pode ser mais do que 5 minutos de trabalho, certo?” Freqüentemente, você vê que a duração real está mais perto de 3 horas.

E então você ainda fica com os custos que vêm com Troca de tarefas estão envolvidos. Se um desenvolvedor de repente tiver que escolher outro projeto, isso interromperá seu fluxo. Os desenvolvedores não fragmentam seus dias em pequenos pedaços como um profissional de marketing ou gerente de vendas faz: eles precisam de longos meios dias consecutivos de concentração total.

Moral da história: sempre proteja o tempo de seus desenvolvedores.

O que fazer com os bugs no ciclo de 6 semanas?

Muitas vezes as pessoas pensam que um bug é um bom motivo para encerrar projetos e não continuar até que o bug seja corrigido. Mas todo software tem bugs. Não há nada de especial nisso.

Às vezes, descobríamos um bug que estava lá há meses. A tendência era jogar esse bug no topo da nossa lista de tarefas e corrigi-lo o mais rápido possível – especialmente se fosse um investidor que o apontasse para nós.

Uma abordagem melhor é esta: se um bug for relatado, crie um tíquete para ele. Posteriormente, um desenvolvedor pode pegá-lo durante o resfriamento. Este bug não foi detectado por um desenvolvedor? Então, ele sempre pode ser lançado para o próximo ciclo. Mas o bug não será adicionado ao acaso ao ciclo atual.

A exceção aqui é se o bug matar o produto. Por exemplo, ele bloqueia um aplicativo em um tipo de telefone popular. Neste caso, você deve, obviamente, encerrar todo o trabalho e corrigir o bug o mais rápido possível.

Aprofundar o assunto

Claro, este tópico pode ser discutido com muito mais detalhes. Se você estiver interessado nisso, você pode reservar o livro gratuito do Basecamp Shape Up leitura. Basecamp explica sua metodologia em detalhes extremos.

Eu consideraria o livro deles um buffet. Escolha o que se aplica à sua organização e ignore o resto. Se você não gosta de sushi, não coma sushi.

Em última análise, o ciclo de 6 semanas trouxe os seguintes benefícios para nós:

  • Os desenvolvedores ficaram mais felizes
  • A qualidade do produto melhorou
  • E os projetos não se arrastavam mais indefinidamente

Você tem perguntas ou comentários sobre o ciclo de 6 semanas ou acha que sua equipe tem uma abordagem que funciona melhor? Então deixe uma mensagem abaixo.


Source: Frankwatching by feedproxy.google.com.

*The article has been translated based on the content of Frankwatching by feedproxy.google.com. If there is any problem regarding the content, copyright, please leave a report below the article. We will try to process as quickly as possible to protect the rights of the author. Thank you very much!

*We just want readers to access information more quickly and easily with other multilingual content, instead of information only available in a certain language.

*We always respect the copyright of the content of the author and always include the original link of the source article.If the author disagrees, just leave the report below the article, the article will be edited or deleted at the request of the author. Thanks very much! Best regards!