Projetos simultâneos de Ajile (sob prisão) e Cachoeira

Existem muitas estruturas testadas e prontas para organizar o fluxo de trabalho, nas quais métodos e princípios são bem descritos. Se montarmos um carro, use o Kanban, prepare uma torta - Lean, desenvolva um site personalizado - PMBoK. É importante considerar que cada projeto é único e precisa de adaptação de abordagens, mas, em geral, para o seu caso, provavelmente já existem soluções úteis suficientes. Construindo processos para mim, tirei um pouco de tudo.

isso foi


Ele trabalhou em uma startup. Um produto, uma equipe pequena, não há limites de tempo estritos. Usava Scrum e Kanban em sua forma mais pura, por assim dizer. Escrevemos as tarefas no Trello e as arrastamos em 4 quadros: idéias, precisamos fazê-lo, no trabalho, está pronto. Para discutir o andamento do trabalho, eles telefonavam todos os dias e, uma vez por semana, planejavam tarefas para o próximo sprint. Tudo é como as pessoas têm.

Se tornou


Depois de mudar um pouco o curso do desenvolvimento, fui para uma nova experiência em um estúdio na web. Lá, primeiro, ele ficou surpreso com a flexibilidade de trabalhar com clientes e, se não houver sarcasmo, com a falta de qualquer sistema.

Para mostrar o quadro geral, darei um exemplo muito simplificado.
Cliente A: Preciso desenvolver uma página de destino para um evento dessa e daquela data.
Gerente de projeto (MP): ok, faremos isso até uma certa data.
Cliente B: faça com urgência as seguintes alterações no site.
MP: OK, adicione o mais rápido possível.

Em seguida, o MP concorda com a estimativa do cliente A, grava as tarefas no rastreador, criando projetos separados e placas desconectadas. Diz à equipe o que fazer. Os desenvolvedores começam a cortar e, após a conclusão, o gerente mostra o resultado para os clientes.

As entradas no sistema são assim:
imagem

Problemas


A abordagem da manutenção é bastante lógica, mas surgem os seguintes problemas:

  • Falta de conexão visível entre as
    tarefas do cliente e da equipe As tarefas de negócios geralmente são encontradas na tabela e descompiladas no Jira. Quando um desenvolvedor escreve outro método de API, para entender quem o usará, você precisa ir ao gerente e esclarecer novamente.
  • Priorização incorreta O
    Designer relata a conclusão prematura do layout (sim, isso também acontece). Ele pergunta: o que fazer a seguir? O MP define a tarefa do quarto projeto, o primeiro da lista. No final do dia, ele percebe que a quarta tarefa do primeiro projeto era mais importante.
  • Não há representação visual do escopo do trabalho,
    tarefas em diferentes projetos. Ninguém quer mantê-los na cabeça ou pesquisar nos catálogos. Quando terminei, é mais fácil perguntar: o que fazer a seguir?
  • Distribuição desigual de carga por tempo e pelos funcionários
    Está claro o que Vasya e Petya estão fazendo no momento, é mais difícil dizer quem estará ocupado após duas semanas e se suas tarefas serão equivalentes.
  • Ao planejar o tempo de conclusão, as tarefas de outros projetos não são levadas em consideração, fomos
    solicitados a alterar o link no site. Ah, é fácil, vamos fazer hoje. Em seguida, o gerente lembra que existem erros super críticos em outro site. Como resultado, a mudança no link, segundo o cliente, se estendeu por uma semana.

Talvez neste exemplo, com as edições e a página de destino, não pareça assustador, pois tudo isso é fácil de lembrar, mas, na prática, pode haver 5 projetos ao mesmo tempo com 40 tarefas em cada. Muitos projetos vieram de outros gerentes. Placas, tipos de tarefas, metodologias neles foram escolhidas de acordo com o seu humor.

Conversão Melão


Para criar um sistema, foi necessário primeiro trazer os dados para um único formato. Transformando a massa de entidades transferidas à minha disposição, consegui chegar ao seguinte conceito:

imagem

acho que tudo está claro a partir da imagem, mas há pequenas nuances associadas à implementação em Jira. Vamos analisar cada entidade usando exemplos.

Com o conceito de projeto, tudo é inequívoco, tanto na mente da comunidade como na Atlassian. Esta é uma sequência de ações destinadas a obter resultados em um tempo limitado. Por exemplo: desenvolver um site, apoiar o aplicativo por todo o tempo de vida, criar uma empresa de publicidade.

Épico (lançamento)- grandes partes isoladas do projeto: conta pessoal, cesta, catálogo de produtos. Aqui as divergências já estão começando. Jira tem uma entidade épica, mas ainda assim usei o release.

O fato é que, para implementar a estrutura correta, é necessário ter três níveis de aninhamento, Jira no momento da redação do artigo tem 2 + 1 (histórico e tarefa estão localizados no mesmo nível). O +1 é uma subtarefa, não o levo em consideração, pois carrega a função de complemento em vez de aninhamento devido à falta de flexibilidade e forte vínculo com o pai.

Em vez da liberação, você poderia usar componente ou sprint, mas para meus propósitos, eles pareciam menos bem-sucedidos. Pelo mesmo motivo, épico é usado para gravar histórias.

A história (épica) nessa estrutura é a tarefa do negócio (o desejo do cliente). Tarefa- ações compreensíveis para resolver problemas de negócios.

Além disso, alguns contadores e campos foram adicionados às entidades. O mais importante deles é uma escala para avaliar a complexidade de uma tarefa de 1 a 10 em unidades arbitrárias (story story).

Criação do sistema


Como existem dados, você precisa decidir de que forma e como exibi-los. Criei um projeto comum para a equipe e escrevi uma consulta JQL para extrair tarefas de todos os nossos projetos (a consulta é fácil de gerar na seção de problemas). Foram adicionados quadros e status Kanban correspondentes ao nosso processo técnico: Lista de pendências → Tarefas → Execução → Revisão → Teste → Correspondência → Concluído.

A imagem a seguir foi mostrada:

imagem

Agora, todas as tarefas passam por um único ciclo de produção, que é bastante universal (você não pode testar o design, mas transferi-lo imediatamente para acordo). Em caso de falha de qualquer estágio, um comentário é adicionado à tarefa e enviado de volta à Tarefa. Cada tarefa possui links visíveis para o projeto, histórico do cliente (épico) e épico (release).

Usando a mesma consulta JQL com o plug-in BigGantt (ou qualquer outro) para Jira, as tarefas podem ser exibidas na forma de um gráfico de Gantt. Altere o lead time, os prazos, registre as dependências, veja a carga nos artistas. Recolher tarefas na história, história em épicos, ou seja, visualize um roteiro ou plano de trabalho detalhado.

Parte administrativa


Das metodologias, Lean é usado (uma sequência de ações é determinada, enquanto a possibilidade de execução paralela de tarefas permanece), Kanban (tarefas passam de especialista para especialista, um gargalo é facilmente identificado). A Scrum realizou reuniões diárias para manter uma compreensão de quem está fazendo o quê. Eles também avaliaram a complexidade de novas tarefas nos pontos da história. Eu queria, mas não podia usar sprints, porque o cliente às vezes alterava a prioridade das tarefas e não é mais possível regular a quantidade de trabalho após o início do sprint.

Após a reunião, as tarefas são priorizadas em uma lista não processada, um executor é designado e transferido para A fazer. O desenvolvedor cria uma ramificação no BitBucket; a tarefa salta automaticamente para Doing. Após a conclusão, o "desenvolvedor" é transferido para Revisão, o artista muda para outro desenvolvedor. Se estiver tudo bem, o "revisor" faz uma mesclagem e o código está no servidor de teste. Jira envia a tarefa para o testador. Após a verificação, o controle de qualidade transfere para o gerente. Isso mostra ao cliente. O cliente está satisfeito - o código é enviado ao servidor de batalha sob a supervisão cuidadosa de testes automáticos diários.

Obrigado por essa automação, graças aos nossos engenheiros de devops. Acabei de configurar a alteração de status e executores para eventos do git. Isso é feito nas configurações dos processos de negócios, se você trabalhar no ecossistema da Atlasian. E ao usar o GitLab, o Bitrix, o Redmine terá que mexer.

Soluções


Vamos ver o que conseguimos alcançar:

  • A falta de uma conexão visível entre as tarefas do cliente e a equipe.
    As tarefas de negócios são registradas no Jira como histórias (épicas), podem ser visualizadas com uma porcentagem de conclusão e um gráfico de Gantt. O desenvolvedor, executando a tarefa, vê a qual história pertence, pode ir e ler a descrição.
  • Priorização incorreta O
    designer, após concluir a tarefa anteriormente, pega uma nova no topo da lista de tarefas, onde é priorizada pela proporção entre o ponto da história e o custo (tarefas de negócios em rublos).
  • Não há representação visual do escopo do trabalho,
    tarefas em um projeto. Cada membro da equipe vê como eles se movem ao longo do quadro Kanban, o curso geral do trabalho. O que foi feito e o que resta a ser feito.
  • A distribuição desigual de carga por tempo e por
    gráficos de Gantt de funcionários permite planejar o trabalho em um longo horizonte (com atualizações constantes). Há uma projeção nos artistas. Pode ser visto quando o executor tem 2 tarefas ao mesmo tempo, enquanto alguém não as possui.
  • Ao planejar o tempo de conclusão, as tarefas de outros projetos não são levadas em consideração.
    Adicionando uma nova tarefa a qualquer projeto, ela pode ser vista no backlog geral. A prioridade em relação a outras tarefas é definida para ela em uma única métrica.

Planos


Alguns processos foram reduzidos ou automatizados, mas muito mais permaneceu nos planos:

Geração de estimativas para tempo e material dos projetos


Executando cada tarefa, o funcionário anota o tempo nela. Conhecendo as taxas por hora de cada pessoa, sua posição, fator de correção (por quanto multiplicar para contabilizar os custos da empresa), você pode gerar uma tabela com uma lista de empregos e custos.

Pagamentos automáticos entre gerentes


Se eu tiver tarefas, mas não houver recursos suficientes para concluí-las, solicito a outro gerente o contratado. Quando chega a hora dos relatórios, trago como despesas as horas gastas em dinheiro do funcionário para o meu plano e como receita para o plano de outro gerente.

Todo mês eu tinha que aumentar todo o trabalho, verificar com os gerentes, multiplicar e subtrair sem nenhum criativo. Se todos os funcionários mudassem para um único formato de dados (a maneira de conduzir projetos em Jira), todos os cálculos seriam possíveis de serem realizados sem intervenção humana.

All Articles