Agilidade para o desenvolvedor

Você é programador e sofre com horas extras, prazos atrasados, mudanças constantes de prioridades nos projetos?

O proposta deste blog é compartilhar iniciativas que colaborem para aumentar a agilidade nos projetos e empresas. E a proposta do Henrique Bastos compartilha o mesmo mindset que sigo aqui. 

Além disso, ele traz a mensagem que agilidade também é qualidade de vida para o programador. E as estratégias certas podem nos levar para este objetivo de desenvolver software de forma ágil e com qualidade de vida.

O Henrique tem uma história fantástica sobre estes assuntos e ninguém melhor que ele para te contar. 

Clique aqui e veja a história dele!

Clique para ser avisado por e-mail sobre um novo artigo. Fique tranquilo, também odeio Spams!

Imagem: Free Pick

4 evoluções no processo de desenvolvimento com Kanban

Em 21 e 22 de setembro de 2015, apresentei no CBSoft o que fizemos no TST de janeiro a maio de deste ano. A apresentação é um resumo e uma comparação com o mesmo período de 2014.

Você verá quatro das principais evoluções ocorridas no início de 2015. Entre elas, alteração da estrutura da equipe, a redução do WIP e o tratamento de um estoque de cerca de 200 defeitos.

Segue a apresentação.

Quer ser avisado por e-mail sobre um novo artigo? CLIQUE AQUI e se inscreva. Fique tranquilo, também odeio Spams!

Gostou? Curta, compartilhe e deixe seu comentário! Assim você me ajuda a continuar escrevendo.

Times Estáveis

Olá,

recentemente, passamos aqui no TST por uma pequena mudança que eu espero que dê altos ganhos num futuro próximo. 

A mudança foi deixar as equipes fixas. Pois é, até agosto de 2015 os nossos times de desenvolvimento de software fazia revezamentos após cada projeto. Funcionava assim: um projeto acabava e todos iam para o time de manutenção; quando o novo projeto fosse começar, montávamos um novo time a partir do time de manutenção. Estávamos supondo que muitos desenvolvedores não gostavam de fazer manutenções o tempo todo. Então, colocamos esta regra para garantir o revezamento neste time. A ideia era manter a motivação deste time em alta. Mas, percebemos que isso estava impedindo que cada time alcançasse todo o seu potencial. Além disso, alguns desenvolvedores gostam de manutenções.

Por coincidência, passei por este artigo de 2014 do Jeff Sutherland, Neil Harrison e Joel Riddle que descreve 9 padrões de times Scrum altamente produtivos e o primeiro dos padrões é Times Estáveis.

Segue o link para o artigo: Teams that Finish Early Accelerate Faster: A Pattern Language for HighPerforming Scrum Teams.


Gostou do artigo? Curta, compartilhe e deixe seu comentário! Assim você me ajuda a continuar escrevendo.

Se quiser ser avisado por e-mail sobre um novo artigo, se inscreva aí do lado. No Spams!

Quem gosta de pontos de função?

Não sei se concordam comigo, mas acho que a maioria dos fiscais de contratos de desenvolvimento de sistemas na administração pública não gosta de contar pontos de função (PF). Acho que nem as empresas que trabalham com o governo gostam...

Veja o artigo completo no Governo Ágil

Gostou? Curta, compartilhe e deixe seu comentário! Não Gostou? Deixe seu comentário também.

Se quiser ser avisado por e-mail sobre um novo artigo, se inscreva aí do lado. No Spams!

"To do or not to do"

Você já passou por este tipo de problema? Demandas são priorizadas para o time de desenvolvimento, mas nunca são iniciadas? Ou levam semanas para serem iniciadas? 

No meu caso, em um time responsável pela manutenção de vários sistemas, mesmo respeitando um limite de demandas priorizadas em um quadro kanban isso continuava acontecer. Sempre apareciam demandas que estavam paradas a muito tempo nesta fila. 

O problema é que, assim que uma demanda é priorizada, ela começa a gerar expectativas no demandante e nos usuários. Eles esperam que o problema deles seja resolvido em breve. E estar frustrando constantemente expectativas causa desconfiança no time de desenvolvimento: um custo caro a se pagar.

Então, como era a priorização neste time? Qualquer analista de requisitos pode priorizar uma demanda a qualquer hora. Seja a partir da chegada de um defeito por um sistema específico, seja pelo recebimento de um e-mail relatando um problema ou mesmo por telefone. Este analista decidia sozinho qual a prioridade deste item em relação aos demais da fila.

Então, começamos a priorizar semanalmente. Escolhemos um dia para todo o time se reunir e priorizar o que será feito na próxima semana. Não limitamos os itens a um número de demandas ou a um número de pontos (como é feito no Scrum), mas ao que o time acha que dá conta de fazer em uma semana. O time leva em conta o trabalho que está em progresso e o trabalho priorizado na semana anterior mas ainda não iniciado. Além disso, o time considerada também as férias e licenças dos seus integrantes.

Esta estratégia é chamada de estabelecer uma cadência de entrada e tem todo um capítulo dedicada a ela no livro Kanban: Successful Evolutionay Change for Your Technology Business de David J. Anderson. 

As vantagens que notamos ao utilizar esta técnica neste time foram:

1. Adequação da demanda à capacidade da equipe, pois a equipe só puxa o que conseguirá fazer na semana; 
2. Possibilidade de agrupar demandas similares ou correlacionadas para melhorar a produtividade, por exemplo, priorizar várias correções em um mesmo sistema, ou seja, a ordem que as demandas chegam não é a melhor ordem para trabalharmos; 
3. Criação de uma oportunidade para toda a equipe discutir cada demanda, entender e revisar os seus critérios de aceite.

Vale ressaltar que estabelecemos uma cadência de entrada, mas não de saída. Muitas demandas ou grupo de demandas levam mais do que uma semana para estarem prontas e continuam a serem testadas, homologadas e colocadas em produção no seus ritmos.

Um receio que tínhamos antes de iniciar era se o custo de reunir todo o time em uma reunião semanal seria alto demais. Mas isto não se confirmou. No início, gastamos mais de duas horas em uma reunião e no final já estávamos gastando pouco mais de uma hora. 

Um ponto que me surpreendeu é que nos pareceu fácil saber o que dava para fazer em uma semana. Se estivéssemos priorizando para duas semanas receio que os erros - priorizar demais ou de menos - seriam maiores. Mas, pode ser também que depois de um tempo, acabaríamos aprendendo. Fica como mais uma oportunidade de experimentação...

A conclusão é que desde então o time está mais consciente do trabalho a ser feito e poucas demandas passam de uma semana para a outra sem estarem terminadas ou pelo menos iniciadas.

PS1: Se quiser ser avisado por e-mail sobre um novo artigo, se inscreva aí do lado (nada de spams).

Contratos e Agilidade

Olá, este artigo que escrevi sobre agilidade em contratos públicos de desenvolvimento de software no Governo Ágil pode te interessar.

... em determinado momento deste seminário surgiu a discussão sobre pagar ou não pagar pela alteração de funcionalidade já desenvolvida em iteração anterior. Sendo que funcionalidade aqui deve ser encarada do ponto de vista da Análise de Pontos de Função. No guia do SISP, ficou a orientação por não se pagar por essas alterações...

Veja o artigo completo em http://governoagil.com.br/2015/07/11/contratos-e-alteracoes-no-software-pagar-ou-nao-pagar/ .

Quadro kanban com dois níveis

Olá! Este artigo conta como chegamos ao quadro kanban em dois níveis mostrado na figura abaixo.

Inicialmente, os nossos quadros kanban tinham um nível. Cada demanda fluía livremente pelo quadro independentemente das demais. Raras vezes, fazíamos uma demanda esperar por outra para ser implantada ou para ser testada. O artigo Tangibilizando os Resultados mostra uma versão deste quadro com um nível.

Então, alguns eventos aconteceram: 

Evento 1: Uma janela de mudanças foi definida, permitindo a implantação em produção somente em um dia da semana. Isto nos levou a agrupar as demandas para a implantação. 

Evento 2: Notamos que alguns erros em produção decorriam da falta de testes integrados das demandas de um mesmo sistema. Ou seja, as demandas eram testadas isoladamente, mas quando agrupadas apresentavam erros. Então, passamos a testar em conjunto as demandas de um mesmo sistema que seriam implantadas em um release.

No quadro kanban, a solução inicial para agrupar as demandas foi anotar, em vermelho, um mesmo número no post-it de cada uma para indicar que deveriam ser testadas, homologadas e implantadas em conjunto. Ou seja, anotando o número 2 em 3 post-its indicava que os 3 formavam um release e deveriam seguir juntos do teste até a implantação. Este processo de relacionar as demandas por números nos post-its deve ter de 1 a 2 meses. Até que...

Até que aconteceu o Evento 3: os limites de WIP do Desenvolvimento não estavam sendo respeitados pelo próprio time, causando um acúmulo de demandas na coluna Desenvolvimento Pronto. Outro problema que notamos foi que a utilização dos números dificultava bastante a visualização do relacionamento das demandas, principalmente, quando eram vários releases em desenvolvimento.

Então, criamos as raias que vão do Para Fazer até o Desenvolvimento Pronto como mostrado pela figura acima. Agora, a facilitação visual não deixa dúvidas sobre o relacionamentos entre as demandas! Cada raia representa um release e, quando uma demanda é priorizada, deve ter um post-it azul na primeira coluna do Para Fazer, representando um release. Quando todas as demandas de um release estão prontas, este post-it azul anda também para o pronto, ocupando a última coluna do Desenvolvimento. Mas isso não quer dizer que esta raia esteja liberada para a priorização de um novo release. A liberação só ocorre quando são iniciados os testes/homologação. Nessa hora, o post-it azul é movido com todas as demandas do release dependuradas nele. Assim, se o time não iniciar os testes/homologação, de forma a manter as demandas fluindo pelo quadro, logo não poderão puxar mais trabalho para o desenvolvimento.

Uma vantagem desta abordagem é deixar bem claro que há um limite de releases simultâneos no Desenvolvimento, já que a restrição é física: 6 raias = 6 releases.

Comunicação

Olá! Hoje vou escrever sobre um problema que temos no TST e acredito que seja comum a diversas outras organizações. O problema que estamos tentando resolver é a falta de comunicação com desenvolvedores, gestores e toda a comunidade envolvida no desenvolvimento de software.

Percebemos a falha na comunicação por questionamentos dos desenvolvedores como "Qual o próximo projeto?", "Quando vai começar?" ou "Será um produto novo em Java ou manutenções no legado?". Também por questionamentos dos gestores sobre quais projetos estamos envolvidos. Muitas vezes os gestores tinham uma percepção de que estávamos envolvidos somente em um projeto, mas na verdade existiam inúmeros outros pequenos projetos em paralelo, além de uma fila de defeitos esperando para serem corrigidos.

Então, criamos um painel que foi colado ao lado do quadro kanban da equipe. A Figura abaixo mostra este painel, que tem as seguintes informações: 1) projetos aguardando na fila; 2) projetos em andamento; 3) projetos concluídos recentemente; 4) estoque de chamados e defeitos; 5) taxa de entrega mensal; 6) taxa de entrega dividida por tipo de demanda; 7) lead time; 8) resumo de defeitos em fila, em correção e concluídos no mês; e 9) CFD.

Além disso, as cores dos cartões diferenciam os projetos grandes em azul (com duração de meses), os projetos pequenos em laranja (com duração de semanas) e o resumo de defeitos em vermelho. Cada cartão de projeto possui as seguintes informações, de cima para baixo: nome do projeto, demandante, percentual de conclusão, estado atual (i.e., em desenvolvimento, em homologação, em implantação, entregue em data, etc.) e o prazo. Estas informações servem como um resumo da situação de cada projeto e dos defeitos para os gestores.

Este painel foi desenvolvido em um planilha e impresso em um A3 para ser colado ao lado do quadro kanban. Hoje, atualizo a planilha diariamente, mas só colo uma nova versão na parede semanalmente.

Toda esta estratégia de comunicação ainda está sendo testada. Inicialmente somente a equipe de desenvolvimento visualizava este painel. Em seguida, começamos a enviar para os gestores da informática. Talvez um dia ele chegue a todo o Tribunal. Afinal seria uma forma de ampliar a transparência do desenvolvimento de sistemas.

Tangibilizando os resultados

O Problema

Uma das responsabilidades do nosso time de desenvolvimento é a sustentação a diversos sistemas. Entre as atividades de sustentação estão correção de defeitos, tirar dúvidas de usuários que os dois níveis anteriores de suporte não resolveram, extração de dados de produção para os quais não há relatório nos sistemas, entre outros. 

Então, no início de março de 2015, o estoque de chamados não resolvidos chegou a cerca de 200, sendo que alguns deles já estavam fazendo aniversário.

A estratégia

Recentemente fiz o curso Software Zen com o Alisson Vale e uma das estratégias que ele ensina é "Tangibilizar os resultados". Geralmente, no desenvolvimento de software, os produtos e as métricas são intangíveis, ficam escondidas dentro de computadores e sistemas. Os objetivos desta estratégia incluem:

1. Criar informação para suportar a tomada de decisão;
2. Gerar confiança em todas as interações do sistema; e
3. Motivar as pessoas.

Então, no início de março, incluímos um gráfico de chamados não resolvidos abaixo do quadro kanban, como mostrado na Figura 1.

Figura 1 - Quadro kanban

Este gráfico é atualizado diariamente e foi feito da forma mais simples possível: uma papel A3, caneta esferográfica e canetinha vermelha e preta, como mostrado na Figura 2. A propósito, a linha vermelha no gráfico é a fila de chamados não resolvidos e a linha verde, incluída após uma reunião de retrospectiva, evidencia o número de defeitos não resolvidos.

Figura 2 - Chamados não resolvidos

Este gráfico evidencia para este time se o objetivo de reduzir os chamados não resolvidos está sendo atingido ou não. Ao mesmo tempo, o gráfico é um motivador para a equipe quando mostra o quanto o time já avançou para atingir este objetivo.

Conclusão

Antes de tudo, a diminuição no número de chamados não resolvidos, como mostrado no gráfico, não se deveu somente a esta estratégia. A queda já era esperada, já que janeiro e fevereiro tinham sido meses atípicos, onde houve uma acumulação de cerca de 100 chamados. Entretanto, alguns fatos nos levam a crer que a estratégia de tangibilizar os resultados teve um impacto e que a queda talvez fosse menor sem ela.

Primeiro, o gráfico deixou evidente qual deveria ser a preocupação da equipe a todo momento. Antes dele, estes dados ficavam guardados dentro de um sistema que nem todos do time acessavam constantemente. Agora, mesmo sem querer, todos vêem o s números. Em diversos momentos, quando o número não diminuiu de um dia para outro, ouvia-se de alguém do time: "Pô, não diminuiu!" ou "Aumentou!";

Segundo, houve um esforço para procurar chamados que não precisavam mais ser feitos e fecha-los. Alguns deles deixaram de fazer sentido porque se referiam a partes dos sistemas que já tinham sido desligados, outros porque um outro chamado já tinha resolvido o problema.

Por fim, nos últimos dias, quando a linha vermelha diminuiu a velocidade de queda e até tendendo para a estabilização, pudemos cruzar os dados com as férias de 3 integrantes deste time, o que já nos deu uma hipótese sobre a diminuição do ritmo e, consequentemente, reduziu a ansiedade dos gestores para tomar alguma medida imediata, já que 2 destes integrantes já estavam por voltar das férias.

Os efeitos da redução do WIP

Introdução

A Figura 1 é uma fotografia do quadro kanban do desenvolvimento de software judicial no TST de dezembro de 2014. Cada post-it é um defeito ou uma história de usuário. Os post-its verdes são quase todos de correção de defeitos. Cada uma das outras cores representam um projeto diferente.

Esta figura mostra dois problemas principais: muito trabalho em progresso (WIP) e lotes grandes. Muito trabalho em progresso é um problema pois dificulta a coordenação dos trabalhos e é uma grande fonte de interrupções nas demandas que ainda estão em desenvolvimento. O que faz com que estas últimas demorem mais para serem terminadas. Lotes grandes, como o ilustrado pelo círculo na Figura 1, são um problema quando entram em produção. Normalmente, uma entrega grande em produção é seguida de uma sequência de defeitos reportados.

Figura 1 - kanban de dezembro de 2014

O que fizemos?

Então, a partir do início do ano, mas com mais intensidade a partir de fevereiro, começamos a tomar ações para reduzir o WIP do sistema de trabalho. Abaixo listo uma sequência de ações executadas e fatos que se sucederam:

1. O projeto em azul (Figura 1) foi implantado no início janeiro;
2. Os limites de WIP foram retirados do quadro kanban. Isto parece contraditório, mas pela Figura 1 podemos ver que os limites, mesmo altos, não eram respeitados pela equipe. Então retiramos os limites, para recolocá-los quando o WIP já estivesse mais baixo.
3. Em fevereiro começaram a aparecer os defeitos da implantação do projeto em azul. A equipe de desenvolvimento trabalhou quase que exclusivamente todo o mês para corrigi-los de forma imediata.
4. Para favorecer a correção destes defeitos e não permitir o aumento do WIP, não foi priorizado nenhum item que não fosse imediato até o início de março (círculo na Figura 2);
5. Com o WIP mais baixo, no início de março foram recolocados os limites de WIP. Por exemplo, o limite do desenvolvimento que antes estava em 28 itens passou para 6, o limite do teste e homologação que antes era 30 passou para 6.
6. Então, no final de março, com os limites já sendo respeitados voltamos a priorizar itens não emergenciais para serem desenvolvidos.

Figura 2 - kanban do início de março de 2015

E onde isto nos levou?

O Lead Time, que é o tempo desde que uma história de usuário entrou em desenvolvimento até o momento em que ela foi colocada em produção, tem caído para a maior parte destas histórias. A Tabela 1 mostra a média e a mediana para quatro períodos. Apesar da média não ter caído tanto, pois algumas histórias antigas ainda puxam a média para cima, a mediana mostra que para 50% das histórias a tendência é de queda no tempo de entrada em produção. 

Tabela 1 - Lead Time

A taxa de entrega mensal (throughput) de março só não foi superior aos meses de agosto de 2014 e de janeiro de 2015, considerando os últimos 12 meses (Gráfico 1). Por outro lado, nestes dois meses existiram entregas grandes em produção que haviam ficado acumuladas, como aquela da Figura 1. Assim, isto nos indica que esta taxa de entrega mais alta veio das ações descritas anteriormente.

Gráfico 1 - Taxa de entrega mensal

Conclusão

A redução do WIP teve impacto não só na redução do Lead Time e no aumento da taxa de entrega (que ainda precisamos confirmar se irá se manter nos próximos meses), mas também facilitou a coordenação do trabalho da equipe no dia a dia.