segunda-feira, 9 de novembro de 2015

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

quinta-feira, 24 de setembro de 2015

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.

terça-feira, 15 de setembro de 2015

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!

segunda-feira, 10 de agosto de 2015

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!


terça-feira, 4 de agosto de 2015

"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).

domingo, 12 de julho de 2015

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/ .

segunda-feira, 22 de junho de 2015

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.