Olá pessoal, meu nome é Alexei Fedorov, sou líder da equipe financeira do Citimobil. Neste artigo, quero compartilhar como funciona o processo de desenvolvimento ágil em nossa equipe.
O CityMobil é o segundo maior agregador de táxi da Rússia. Ao longo do ano, crescemos cerca de 10 vezes e não vamos desacelerar. Um crescimento tão rápido impõe algumas limitações: precisamos de um tempo de colocação no mercado (TTM) muito curto, o tempo entre a idéia e o uso por clientes reais deve ser o menor possível. Devido ao fato de minimizarmos o TTM, não coletamos a liberação, mas rolamos cada tarefa / recurso separadamente. Além disso, essa abordagem tem uma vantagem importante - em caso de problemas no produto, fica imediatamente claro por que eles surgiram. Isso permite reverter a tarefa, não a versão inteira.
Por que não Scrum
Há vários anos, a metodologia Agile e sua variedade Scrum (a seguir denominada Scrum) são populares no setor de TI. Scrum tentando implementar de alguma forma em cada empresa. E cada um tem sua própria experiência de implementação, mas, como regra, raramente é positiva. Mais frequentemente, vem a desilusão e uma reversão aos processos anteriores.
Na minha opinião, os principais problemas do scrum são:
- Sprints fixos.
Raramente termina o sprint a tempo, para que tudo seja feito. Por via de regra, ainda há alguma insignificância insuficiente ou não verificada. As melhorias são transferidas para outro sprint e, para chegar a tempo, a equipe realiza menos tarefas. Equilibrar o sprint de tarefas para que todos tenham um emprego é difícil. As tarefas de RnD geralmente não se encaixam em uma estrutura fixa. E o mais importante, os sprints fixos raramente são solicitados pela própria empresa. - Uma variedade de comícios.
O Scrum tem muitas atividades: comícios diários, planejamento e uma retrospectiva de cada sprint. Muitas vezes, essas reuniões são realizadas para exibição e são mais cansativas do que benéficas.
Em geral, o scrum me lembra um certo culto à carga, que está sendo introduzido como na esperança de que se torne bom. Nossa abordagem é usar as técnicas e processos que ajudam a alcançar o resultado e abandonar o que interfere.
A equipe
O papel chave na formação do processo é desempenhado pela equipe e sua estrutura. Nossa equipe inclui desenvolvedores e líder de equipe. PM opcional, controle de qualidade, analistas, designers. A equipe deve ser percebida como uma única unidade de combate. Esta é uma caixa cinza, na entrada da qual existem requisitos e na saída - o produto. A organização interna está completamente à mercê da equipe e, em si mesma, pode trabalhar em qualquer processo que lhe convenha.
Como conosco
Nossa equipe escolheu um processo muito semelhante ao Kanban. Temos muitas fontes de tarefas: encontradas pelo serviço de suporte a bugs, novos recursos de produtos, dívidas técnicas, recursos de uma equipe adjacente etc. Não importa de onde a tarefa veio, ela deve ser enquadrada no rastreador de tarefas, de preferência pelo próprio autor. Qualquer tarefa recebida passa por vários status obrigatórios: “Novo”, “Trabalhar”, “Em andamento”, “Testado”, “Pronto para implantação”.
As tarefas são movidas da esquerda para a direita no quadro, raramente retornando. A prioridade se estende de cima para baixo e da direita para a esquerda. Por exemplo, implementar uma tarefa na produção é mais importante que testar, e testar é mais importante que o novo desenvolvimento. A coluna "To Work" forma essencialmente o backlog da equipe - uma lista linear priorizada de tarefas com algumas semanas de antecedência. Assim que o desenvolvedor entende sua tarefa atual, ele pega a próxima coluna do topo.
As tarefas não são fixadas antecipadamente para um desenvolvedor específico; essa abordagem permite equilibrar a execução de tarefas, aumenta o conhecimento geral do código por todos os desenvolvedores, aumenta o fator de barramento. Tentamos lidar com uma estreita especialização dentro da equipe. Cada membro da equipe deve ser capaz de executar qualquer tarefa do backlog. Se o desenvolvedor assumiu a tarefa por si mesmo, ele controla completamente seu movimento no quadro até que ele apareça no prod. Ele também verifica como a tarefa se comporta em condições reais.
Das reuniões que realizamos comícios diários, discutimos não apenas planos, problemas e tarefas concluídas, mas também abordagens para solucionar problemas, propostas e, em geral, tudo o que preocupa os membros da equipe. A reunião raramente leva mais de 30 minutos para 4 pessoas. Todo mês, realizamos uma retrospectiva em uma amostra de scram: o que foi bom / ruim, o que podemos fazer com isso, um plano para aumentar a eficiência no próximo mês. Não temos planejamento dedicado, organizamos o planejamento, se necessário, se começarmos a desenvolver uma grande tarefa.
Tentamos registrar o tempo de cada tarefa, pelo menos 75% do tempo de trabalho. Com isso, alcançamos dois objetivos:
- Buscamos e eliminamos demolidores: tarefas demoradas, mas que não traziam os benefícios esperados.
- Avaliamos as tarefas com base no já realizado, aumentando assim a precisão da avaliação.
Também temos turnos semanais: um dos desenvolvedores responde a perguntas da segunda linha de suporte, procura novos problemas nos logs / monitoramento, resolve tarefas urgentes e faz o que não se encaixa no backlog planejado. Isso permite que outros desenvolvedores se concentrem mais em suas tarefas sem se distrair com mensageiros, etc.
Sumário
O processo descrito, com pequenas variações, apliquei em várias equipes e empresas. Ele se estabeleceu como o mais flexível e transparente para todos.
Não descansamos em nossos louros, a cada nova retrospectiva tornamos nosso processo de trabalho melhor e mais eficiente. Cada vez que revisamos as práticas usadas. Não temos "vacas sagradas" - o que funcionou antes pode parar de funcionar, e muitas boas idéias em teoria não se mostram na prática da melhor maneira. Nós os abandonamos sem arrependimentos.
O processo de melhoria contínua é a base da nossa equipe.