Um dos aspectos mais interessantes dos métodos ágeis é sua estruturação conceitual.
Oficialmente
são quatro declarações de valor que nos inspiram, um pequeno conjunto de princípios que nos guiam e
uma grande quantidade de métodos que nos ajudam a estabelecer "como" as
coisas devem ser feitas. Cada método estabelece seu próprio conjunto de
pressupostos e práticas. E é comum equipes de projeto adotarem práticas
de diferentes métodos enquanto os adaptam às suas realidades.
Depois
de quase cinco anos trabalhando com desenvolvimento ágil, nosso
dia-a-dia de trabalho nos levou além das fronteiras estabelecidas pelos
diversos métodos. Algumas práticas se consolidaram e hoje estão imersas
no nosso cotidiano de tal maneira que sem elas, tudo pára. Outras foram
vencidas pelo nosso processo de adaptação e acabaram em desuso.
Em
janeiro desse ano, nosso processo adaptativo cruzou o caminho de uma
nova abordagem hoje especialmente defendida e divulgada por David
Anderson e Corey Ladas. Essa abordagem usa um kanban como elemento
central para fazer fluir todo o trabalho necessário para tirar uma demanda da lista de desejos do cliente, transformando-o em software funcional. O foco do modelo é a
entrega de software just-in-time. Isso significa essencialmente
entregar o software certo na hora certa e fazer isso repetidamente com
o objetivo de diminuir ao máximo o tempo entre a demanda e a entrega,
por meio da detecção e eliminação das perdas que ocorrem nesse
intervalo. Na prática, essa abordagem abre todas as portas para uma boa
implementação Lean e pode ser uma boa opção em determinados tipos de
projetos.
O
kanban é o instrumento utilizado para amortecer as demandas e permitir
o estabelecimento do "fluxo"
e do "pull system" tão necessários em ambientes que querem se
beneficiar do modelo de produção enxuta (Lean). Até aqui não há nada
novo. Projetos ágeis de modo geral já se beneficiam do uso de kanbans
já a bastante tempo. No entanto, esse modelo extrapola o tradicional
quadro de 3 colunas (Pendente, Em andamento e concluído) para um
sistema que sinaliza e restringe o trabalho de tal maneira que qualquer "hands-off" é amortecido pelo kanban e "puxado" (ao invés de alocado). O objetivo é estabelecer o fluxo unitário, um fluxo de valor que começa na demanda e finaliza
com a entrega efetiva para o cliente.
Assim, o desenvolvedor puxa do backlog
de demandas, quem inspeciona puxa do backlog de inspeção, quem faz
deploy puxa do quadro de itens resolvidos e por aí vai. O trabalho é
primeiro sinalizado e só depois é puxado por quem irá executá-lo, e este só
puxa depois que sinaliza o trabalho que acabou de fazer de forma que a próxima
etapa do processo possa puxá-lo novamente até que ela chegue ao cliente. Ou seja, quem termina sempre sinaliza o item n e então puxa o n+1.
Nesse
modelo, não há iterações. Há um fluxo contínuo de entregas e a
previsibilidade dessas entregas se dá com base no SLA (Service Level Agreement) conquistado pela
equipe. Para chegar nesse ponto, a equipe precisa medir e controlar seu
Lead Time e esse será o principal parâmetro de controle da sua
produção. Como não há iterações, o backlog pode ser alterado o tempo
todo, cartões podem ser removidos, inseridos ou reordenados a qualquer
momento.
Já o esquema de priorização se adapta bem a um cenário onde há competição pelo
recurso, ou seja, um determinado número de clientes compete
pelos mesmos recursos do projeto. Nesse cenário, a tarefa de priorizar não
pode ser dos clientes, mas de um elemento intermediador capaz de
utilizar diferentes critérios para o estabelecimento da ordem pela qual
as entregas devem sair. A priorização será o resultado de uma análise
que leva em
conta uma série de aspectos circunstanciais que envolvem questões
técnicas, comerciais e de negócio, mas o aspecto mais relevante é o
chamado Cost of
Delay, ou o custo decorrente de se fazer ou não uma entrega hoje,
amanhã ou na próxima segunda-feira.
No que diz respeito a estimativas, a orientação é não estimar.
As demandas são categorizadas para composição do SLA, não estimadas. E
essa categorização é feita com base no feeling e na experiência da
equipe. As expectativas dos clientes devem ser adaptadas à
capacidade de produção da equipe.
Hoje tenho visto a utilização dos termos Kanban
Development ou Sustaining Enginnering para identificar esse modelo. Mas
independentemente do modo como ele é chamado, aqui na empresa ele tem
sido uma grande fonte de inspiração para avançarmos na organização
do nosso modelo de trabalho.
No meu entendimento, essa abordagem não deve substituir os métodos ágeis mais utilizados atualmente, mas é uma boa alternativa para projetos que não conseguem atender a alguns de seus pressupostos. Ele se adaptará bem a projetos que:
1) Já mantém o(s) seu(s) produtos em uso em ambiente de produção;
2) Demandam re-organização constante do backlog;
3) Há forte competição pelo recurso (o tempo investido nas features atende a diferentes interessados)
4)
É viável a utilização de SLA (Service Level Agreement) como instrumento
de negociação, planejamento e prestação de contas junto aos clientes;
A seguir eu descrevo um pouco da nossa implementação dessa abordagem.
O
elemento centralizador desse modelo é o quadro kanban de acompanhamento do
trabalho. Ele identifica a parte mais relevante do backlog e também o chamado Work in Process. Nosso
quadro Kanban foi evoluindo na parede até chegar ao modelo apresentado
na Figura 1.
Figura 1: Modelo kanban utilizado na parede.
O
kanban era composto por cartões semelhantes ao apresentado na Figura 2.
Mandamos confeccionar esses cartões de forma a apresentarem informações
relevantes que não só nos dessem um mapa visual do trabalho que
precisava ou que estava sendo executado, mas também que permitisse o
registro de dados que tínhamos a intenção de monitorar (como o tempo
que o cartão passava em cada estágio do nosso fluxo de trabalho).
Figura 2: Modelo de cartão utilizado no kanban
Criamos três categorias de cartões utilizando como critério o benefício que aquele tipo de trabalho gerava para a equipe:
-
Cartões Verdes (Investimento): Agregam valor ao produto (novas features)
-
Cartões
Vermelhos (Custo): Implementação necessária para manter o produto ou o
cliente em pleno funcionamento operacional (defeitos, extração de dados,
análises de cenários complexos, infra-estrutura, etc). Normalmente
cartões vermelhos representam o que eu costumo chamar de
aqueles-originados-devido-a-débito-técnico-aparente ou
coisas-que-nos-distraem-de-agregar-valor-ao-produto, por isso essa cor
gritante.
-
Cartões Amarelos (Improvement): Agregam valor ao modelo de execução ou ao ambiente de trabalho (Auto-improvement);
Cada
cartão recebe uma sinalização que indica a sua expectativa de tamanho,
o que é conhecido como T-Shirt Sizing. No nosso caso cada cor
representa um dos 3 tamanhos possíveis (Small, Medium ou Large) ou
simplesmente P,M e G.
Nosso objetivo é
então medir quanto tempo cada tipo de cartão leva para percorrer todo o
fluxo de trabalho, saindo do backlog até o status de entrega. Essa
métrica é bastante conhecida no modelo Lean como "Lead Time" e é um dos
principais elementos para monitoramento da eficiência do sistema de
trabalho, além de ser útil para a obtenção de estimativas de datas para
entrega junto aos clientes.
Na nossa
implementação, o backlog do kanban é dividido em duas áreas na parte
esquerda inferior do quadro. A primeira contém os 7 cartões de mais
alta prioridade e contém aquelas entregas que atingiram o estágio que
chamamos de LRM (Last Responsible Moment). Ou seja, cartões nesse
estado requerem a atenção imediata da equipe, não por uma questão de
urgência, mas porque ao compor o momento atual com o Lead Time da
equipe, percebe-se que estamos no momento certo para implementá-los. A segunda área contém os
cartões que "provavelmente" serão trabalhados nos próximos trinta dias. Os outros cartões do backlog ficam guardados para não poluir o quadro.
Quando um desenvolvedor fica
disponível ele simplesmente "puxa" o cartão que está no topo da área
LRM (cartão circulado em vermelho no topo dessa área) para a área
associada ao seu nome. A implementação envolve análise, documentação,
codificação e testes e está associada a prática de "Done Definition".
Ao finalizar essa fase de implementação, o cartão é colocado na área de
inspeção para que um outro membro da equipe possa "puxar" o cartão para
realização da inspeção.
Após essa
inspeção, o cartão deixa o kanban da equipe de desenvolvimento e segue
para um novo kanban, dessa vez da equipe de atendimento ao cliente.
Essa equipe puxa novamente o cartão para fazer o processo de deploy da demanda, explicando,
notificando, instalando, tirando dúvidas ou executando qualquer operação que precise ser
realizada no ambiente do cliente. Veja Figura 3:
Figura 3: Kanban na área de atendimento
Alguns pontos que achamos interessantes nessa abordagem:
- O
foco é completamente desviado para o controle e a otimização da
eficiência do sistema de trabalho por meio do monitoramento do seu
rendimento (Throughput);
- Métricas simples (como Lead
Time) mantém a equipe focada no objetivo global (rendimento do sistema);
- Controle do WIP (Work In Process). O Kanban
limita o trabalho em execução, impedindo a sobrecarga do sistema e
forçando-o a trabalhar com sua capacidade real; Um novo cartão só entra em WIP se um outro sair primeiro;
- A demanda deve se ajustar
à
capacidade de produção do sistema (e não o contrário). Se a demanda não pode
se adaptar ao fluxo, deve haver investimento no sistema para que ele
aumente o seu rendimento.
-
Exposição imediata dos problemas: Os problemas são revelados e
resolvidos no momento em que eles surgem. Isso acontece porque o modelo
depende do fluxo. Se um problema interrompe o fluxo, o trabalho de
todos é afetado, o que faz com que ele seja resolvido mais rapidamente;
- O esforço para estimar é progressivamente reduzido até um nível mínimo;
-
Estimula o uso de práticas ágeis de engenharia e
acompanhamento (controle visual, daily meetings, pair programming, tdd,
refactor, CI, etc) na medida em que a qualidade não pode mais depender
de inspeções que só iriam acontecer muito tempo depois do
desenvolvimento;
-
Todo o trabalho da equipe é convertido e mapeado em itens entregáveis
que tem valor real ou para o nosso produto (cartões verdes) ou para
nossos clientes (cartões vermelhos);
- Todo o trabalho da equipe está fisicamente visível, nada fica oculto;
- Todos os entregáveis passam um-a-um pelos mesmos estágios permitindo a implementação do fluxo unitário adotado no modelo Lean;
- Algumas ferramentas Lean são mais facilmente aplicáveis. Veja Figura 4.
Figura 4: Value Stream Map (Clique para expandir)
Quando você consegue trabalhar em termos de fluxo, uma coisa realmente interessante acontece: você começa a perceber as
perdas.
A redução de perdas é um dos elementos mais importantes da abordagem
enxuta e é realmente difícil enxergá-las sem um fluxo estabelecido.
Depois de meses trabalhando dessa forma, as perdas apareciam para nós
como painéis de neon piscando na nossa frente.
O
que mais nos incomodou por muito tempo foi a redundância do controle
visual que tínhamos no nosso quadro na parede, com o necessário
controle eletrônico que mantínhamos por meio de um sistema de tickets
(o Mantis) e pela necessidade de registrar os tempos para mudança de
estágio nos cartões para medição do Lead Time em planilhas eletrônicas.
O quadro ficava desatualizado com mais freqüencia que gostaríamos e a
movimentação dos cartões dependia da presença física das pessoas no
escritório. Em tempos de internet banda larga e remote desktop, o
recurso de trabalhar em casa era cada vez mais usado. Resumindo,
qualquer cartão fora de posição nos incomodava demais.
A
solução veio por meio de um esforço conjunto da própria equipe, onde
alguns membros trabalharam voluntariamente fora do seu horário de
trabalho para passar o kanban para o meio eletrônico. Em menos de uma
semana, conseguimos aposentar o quadro da parede e começar a usar o que
chamamos de kanban eletrônico. Ele apenas lia os dados do sistema de
tickets e os apresentava exatamente da mesma forma que estávamos
acostumados a ver no quadro da parede. Veja Figura 5 (Clique para expandir).
Figura 5: O kanban em sua forma eletrônica (Clique para expandir)
No
modelo eletrônico, a área "Entregue" só é descarregada quando vira o
mês. Essa abordagem ficou bem melhor do que no quadro físico, onde os
cartões entregues não permaneciam nem um dia sequer, pois eram
imediatamente retirados para alimentação da planilha eletrônica para
cálculo do Lead Time. O acúmulo de cartões na área de entregas dá uma sensação de produtividade para a equipe, já que ela consegue visualizar o resultado de todo o seu trabalho no mês.
Com o tempo, o kanban
começou a nos mostrar também as métricas calculadas instantaneamente
(eu precisava de várias horas só para calcular manualmente o nosso lead
time e só ficávamos sabendo do número no fim do mês). Hoje utilizamos
duas métricas principais:
a) Lead Time por categoria: revela o tempo médio necessário para fazermos nossas entregas por categoria;
b) Nível de Investimento no Produto: revela nossos níveis de "débito-técnico-aparente";
Figura 6: Nível de investimento no produto
O
kanban também passou a agregar ferramentas de colaboração, como a
exibição de posts publicados pela equipe no nosso blog interno. A idéia
é extrapolarmos também para outras fontes rss como o nosso wiki de
documentação, os e-mails da nossa lista interna de discussão e
futuramente do twitter da equipe.
Figura 7: Team blog exibido no kanban
Por
fim, ao passar o kanban da parede para a tela do computador, há o
grande problema em se perder o benefício do controle visual que o
kanban oferece. Mas nada que uma boa TV não possa resolver...
Para saber mais sobre Kanban Development:
Lista de discussão no Yahoo Groups
Agile Management - David Anderson
Corey Ladas