Monthly Archives: janeiro 2016

  • 0

Por que o post-it funciona tão bem nas metodologias ágeis?

Tags :

Category : Bússola Digital

Olá,

Tudo bem? Já falei um pouco sobre minha experiência com post-its no texto do Barizon “Como é que de quadros e post-its vai sair um software bom para os clientes?“. Eu uso post-it no meu dia-a-dia e entendo que não é uma solução mágica, nem se adequa a todos os cenários. Mas, nas experiências que tive, ele funcionou bem, muito bem mesmo.

Entretanto, outro dia li um post no LinkedIn, chamado “A Incrível Fábrica de Post-Its“, que me chamou a atenção para este ponto: os quadros e post-its são realmente uma das coisas mais marcantes nas metodologias ágeis. Por isso mesmo, ainda hoje são uma das mais controversas.

Então, resolvi trazer outros fatos e me aprofundar um pouco mais nas experiências que eu vivi, para alimentarmos uma discussão saudável.

Post-it gera motivação

Como integrante de time scrum, escrevi junto com meus colegas vários post-its de tarefas, o me dava uma sensação de autonomia e empoderamento muito fortes: a gente decidia o que seria feito para entregar a história priorizada.

Isso me dava muita motivação. Eu sou um profissional que preciso acreditar que o que estou fazendo tem valor. Para mim, é muito difícil fazer as coisas simplesmente porque tem que ser feitas. Acredito que a maioria dos profissionais de TI, ou melhor, não só de TI, mas da era do conhecimento, são guiados por esse tipo de motivação também.

Post-it não substitui documentação técnica

Há um mito de que quem usa os post-its é contra a documentação técnica. É engano! Se o time decidir que um artefato de documentação é importante e tem valor, o time cria um post-it para ele.

Na maioria dos projetos em que trabalhei, a gente gerou, por exemplo, um post-it para criar o diagrama de arquitetura da solução, representando as integrações entre os diversos componentes, porque a gente entendia que esse diagrama tinha vários benefícios:

  • apoiar na análise dos impactos de novas implementações ou manutenções no código existente;
  • mapear cenários de testes;
  • explicar a solução técnica para novos colaboradores do time;
  • consultas diversas no dia-a-dia.

Esse mesmo diagrama de arquitetura também ganhava um post-it para ser atualizado quando necessário. Por exemplo, num projeto, quando mudamos a solução de pagamentos online, criamos um post-it para atualizar esse diagrama.

Quadros e post-its são fáceis e todo mundo entende

Quando usamos um quadro scrum básico, o entendimento do quadro é imediato: histórias e suas tarefas, com 3 status (a fazer, fazendo e feito), por quais andam os post-its. Eventualmente, um 4o. status indesejado (impedido).

Nos times em que usei Kanban, o quadro também era simples de ser entendido. Era só mostrar o quadro, explicar as etapas e como os post-its deveriam caminhar. Pronto, com 15 minutos de conversa qualquer pessoa entendia o quadro.

Mas o bacana disso tudo é que o quadro scrum ou quadro kanban é a representação visual de um processo de trabalho. Nesse sentido, eles estabelecem um modelo mental coletivo do trabalho. Em outras palavras, todo o time tem um mesmo entendimento sobre o trabalho a ser feito. Isto é muito poderoso, porque alinha os esforços na mesma direção!

1 post-it + 1 post-it = 3 post-its

Por mais clichê que isto pareça, quem trabalhou num time ágil, já deve ter tido esse momento em que olhou para o seu quadro e “caiu a ficha“: caramba, o que a gente entrega como time é muito mais do que eu faço sozinho e é muito mais do que a soma dos nossos post-its.

Isto também dá uma motivação e orgulho de pertencer ao time difíceis de explicar em palavras. Mas a gente sente e isso aparece nas retrospectivas do time.

Os post-its organizam o trabalho da equipe

Imagine você trabalhando com 3, 4, 5 pessoas num time, todas mexendo no mesmo código-fonte, em que elas chegam em horários diferentes para trabalhar e vão embora também em momentos diferentes. Quando você começa o dia seguinte, como saber por onde começar, ou em que ponto o colega parou no dia anterior?

Os post-its respondem isso de forma muito eficaz, rápida e simples: é só olhar para o quadro e seguir o fluxo dos post-its.

Tanto quando atuei como scrum master, como quando era gestor do time, esta característica também me ajudava bastante: era só olhar para o quadro para saber o que dependia de minha ação.

Outra situação é quando você trabalha numa equipe geograficamente distribuída. Teve um projeto em que a gente estava no Rio de Janeiro, o cliente em Sorocaba e um fornecedor técnico em Miami. Além da distância, neste caso também tinha uma diferença de fuso horário. O que usamos? Quadro e post-its digitais (ferramenta Trello).

Post-its são divertidos

Pode parecer bobagem, mas para mim faz muita diferença. Você prefere trabalhar aborrecido ou trabalhar feliz?

Pequenas diversões ajudam a construir um ambiente de trabalho mais feliz. Mexer com os post-its para lá e para cá é lúdico, é divertido. Parece um jogo, em que você tem que andar com as peças para ganhar o jogo.

Mas não é um jogo em que sou eu contra um colega de trabalho. É o time todo, junto, andando com as peças. Isso é gostoso de fazer; é muito melhor do que ficar mudando o status de uma tarefa numa planilha ou num sistema.

Uma vez fiz com minha família uma “retrospectiva do ano“. No final de 2015, a minha filha mais velha pediu para a gente lembrá-la sobre como era o “jogo” que a gente tinha feito daquela vez.

Nas palavras dela, explicando por que gostou dos post-its:

“De início essa ideia de usar post-its pareceu meio simples, ainda mais com toda a tecnologia que temos hoje em dia. Mas a verdade é que escrever à mão e mover os post-its pra lá e pra cá acabou sendo bem mais dinâmico e divertido do que ficar olhando para uma tela de computador.”

Post-it só para mim?

Talvez você notado que falei muito em equipe, time, no coletivo. Será que o post-it funciona para o trabalho individual? Eu acho que sim. Eu uso, principalmente, porque acho mais prazeroso. Talvez esteja influenciado pela ferramenta digital que adoto, que dá mobilidade, tem ótima usabilidade, etc. Mas acho que usaria mesmo se fosse com post-its de papel.

 

Voltando ao artigo original que me motivou a pensar neste assunto, acho importante fechar com dois tópicos:

Post-it não gera software de qualidade: não é porque você usa quadros e post-its que você vai gerar software de qualidade. Quem faz um software bem feito é uma boa equipe de desenvolvimento. A metodologia ágil, e os quadros e post-its como suas ferramentas, ajudam a entregar valor mais rapidamente e a organizar o fluxo de trabalho para uma boa performance do time.

Agora, se o valor entregue é de fato um valor, depende muito da competência do Product Owner. Já se o software entregue está bem feito, depende da competência técnica do time de desenvolvimento, não dos post-its.

Tarefas e compromissos com datas: para isto, eu recorro à velha e boa agenda. 🙂

 

Fontes de referência

 

O que você achou? Qual a sua experiência com os post-its? Deixe seus comentários.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0

5 exemplos de quadros kanban para TI

Tags :

Category : Bússola Digital

Olá,

Tudo bem? Uma das características principais do quadro kanban é a sua flexibilidade: ele pode ser adaptado a qualquer tipo de trabalho e processo de negócio.

Por isso, deve-se controlar a tentação de começar com um quadro perfeito, extremamente detalhado, e iniciar com um quadro bem simples, o mais simples possível, para que seja adaptado à medida que as necessidades surgirem.

Por outro lado, começar a partir de alguns exemplos pode ajudar a acelerar o início e também te dar boas inspirações sobre o que usar e o que deixar de lado.

Este post, baseado no artigo original “Managing IT projects: kanban board examples for IT operations“, reúne 5 exemplos de quadros kanban feitos para equipes de TI (Tecnologia da Informação), mas que podem ser adaptados para qualquer processo de negócio e tipo de trabalho.

5 exemplos de quadros Kanban para TI

Os exemplos de quadros kanban foram divididos em 5 categorias:

  • por tipo de demanda
  • por prioridades variáveis
  • por subtimes de conhecimentos específicos
  • para projetos e dia-a-dia
  • para processos específicos

Quadro kanban por tipo de demanda

Este quadro kanban é perfeito para equipes de operações e atende ao cenário em que existem demandas planejadas, rotinas de manutenção, incidentes em produção (não-planejados) e demandas ad hoc (aquelas que surgem “do nada”). As raias horizontais diferenciam os tipos de demanda.

Quadro kanban para TI: por tipo de demanda

Quadro kanban para TI: por tipo de demanda (clique para ampliar)

Quadro kanban por prioridades variáveis

Já este é o quadro kanban ideal para quando temos aquela situação em que “as prioridades mudam a todo instante”. Nas raias horizontais, ele mostra o que está em andamento, o que está em espera e o trabalho que foi despriorizado. Achei interessante porque o quadro deixa bem claro o quanto de esforço foi gasto em atividades que foram despriorizadas, o que pode levar a ótimas reflexões internas.

Quadro kanban para TI: por prioridades variáveis

Quadro kanban para TI: por prioridades variáveis (clique para ampliar)

Quadro kanban por subtimes de conhecimentos específicos

Nesta configuração, o quadro kanban mostra nas raias horizontais o trabalho de subtimes que tenham conhecimentos específicos. Uma coisa interessante na imagem é que a região marcada com linhas diagonais indica que o limite de capacidade daquela etapa foi atingido, impedindo que novas atividades sejam “puxadas” para ela. (Pode parecer contraintuitivo, mas limitar a capacidade de trabalho é uma das bases da agilidade do método Kanban. Falarei sobre este assunto num próximo texto.)

Quadro kanban para TI: por subtimes de conhecimentos específicos

Quadro kanban para TI: por subtimes de conhecimentos específicos (clique para ampliar)

Quadro kanban para projetos e dia-a-dia

Este acho que é o quadro kanban mais genérico de todos os exemplos. Trabalhar em um projeto específico e também em atividades do dia-a-dia é um cenário muito comum. Repare que na raia “Projetos em Andamento” (“Active Projects”), o quadro kanban reflete o processo de trabalho da equipe através de suas divisões verticais, da esquerda para a direita (Test Design, Code, Test, Deploy). Esta também é uma outra característica fascinante dos quadros kanban: facilitar o entendimento coletivo sobre o processo de trabalho. (Bem mais simples que os tradicionais fluxogramas, não?)

Quadro kanban para TI: para projetos e dia-a-dia

Quadro kanban para TI: para projetos e dia-a-dia (clique para ampliar)

Quadro kanban para processos específicos

Se o quadro kanban anterior era o mais genérico, acho que este é o que dá mais conexão com a sua realidade, porque é fácil de entender o mapeamento do processo de trabalho no quadro kanban e dá vontade de customizar logo o quadro para a sua realidade, para o seu processo de trabalho.

Quadro kanban para TI: para processos específicos

Quadro kanban para TI: para processos específicos (clique para ampliar)

 

Vale reforçar o conselho de sempre começar com o quadro mais simples possível, para sair logo da inércia, e adaptá-lo com o passar do tempo. É incrível como, se você usar o quadro kanban no dia-a-dia, as necessidades de adaptação se tornam evidentes rapidamente. E, ao fazer as adaptações, você e seu time sentem a melhoria no processo de trabalho e passam a internalizar cada vez mais o conceito de melhoria incremental e contínua, que é também uma das bases teóricas dos modelos ágeis de gestão.

Fontes de referência:

Este post foi baseado no artigo “Managing IT projects: kanban board examples for IT operations“, que também é a fonte original de todas as imagens.

 

Espero que tenha gostado! O que você achou? Deixe seus comentários abaixo.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0

A importância do foco no Scrum

Olá,

(Se você preferir, pode fazer o download deste artigo em MP3 e escutar no seu celular, tablet ou computador.)

Tudo bem? Uma dúvida muito comum para quem ainda não trabalhou com Scrum é: será que o time Scrum precisa mesmo ficar focado em apenas um projeto? Não dá para fazer pelo menos dois simultaneamente? Algo como “de manhã, um projeto A; de tarde, um projeto B”?

A resposta simples e pragmática é: dá, claro que dá sim, mas não funciona nada bem. Não é recomendável.

Focar em vários projetos dá a falsa impressão de que estamos usando melhor o tempo, porque afinal estamos atendendo várias demandas simultaneamente.

Mas, se analisarmos bem, na prática, num dado momento, estamos sempre trabalhando em um projeto só. Repare que no exemplo “de manhã, projeto A; de tarde, projeto B”, na verdade estamos dizendo que em cada período trabalhamos apenas num projeto. Não há mágica, pois nós não conseguimos trabalhar, de fato, em mais de uma coisa ao mesmo tempo.

Se fizermos uma análise simples de encadeamento das entregas, também chegamos à conclusão de que não há benefícios.

Vamos fazer algumas simulações com números, apenas para ilustrar: vamos supor que o projeto A demorasse 4 meses se trabalhássemos 100% de nosso tempo nele.

O projeto A leva 4 meses para ficar pronto com 100% de foco nele

O projeto A leva 4 meses para ficar pronto com 100% de foco nele

Para simplificar, vamos supor que o projeto B também levasse os mesmos 4 meses com foco integral.

O projeto B também leva 4 meses para ficar pronto com 100% de foco

O projeto B também leva 4 meses para ficar pronto com 100% de foco

Se focássemos primeiro no projeto A, e se tudo desse certo, ao final do 4o. mês, ele estaria pronto. Começaríamos o projeto B e, novamente tudo dando certo, ao final do 8o. mês, ele estaria concluído.

Foco em 1 projeto de cada vez, como prega o Scrum

Foco em 1 projeto de cada vez, como prega o Scrum

Já num cenário de focarmos 50% de nosso tempo para cada projeto, significa que duplicaremos o prazo de entrega: cada um deles levará 8 meses.

Trabalho em projetos paralelos (como não prega o Scrum)

Trabalho em projetos paralelos (como não prega o Scrum)

Nada muda para o projeto B, pois ele será concluído igualmente no 8o mês, junto com o projeto A. Na prática, porém, perdemos a oportunidade de lançar o projeto A com 4 meses de antecedência!

Percebe como não há ganho nenhum?

Isto se considerarmos que tudo correu bem em ambos os projetos, o que dificilmente acontece. A única coisa garantida neste cenário de trabalho em paralelismo é a de que deixaremos de entregar um dos projetos que poderia ter sido finalizado primeiro.

Além disso, perdemos um dos grandes benefícios do Scrum. Se focarmos em apenas um dos projetos de cada vez, graças às entregas incrementais do Scrum, sempre priorizadas por valor, pode acontecer do cliente ficar satisfeito antes mesmo do prazo inicialmente previsto.

Assim, é possível que os 4 meses originais sejam encurtados, porque, por exemplo, o cliente já ficou satisfeito com as entregas feitas até o 3o. mês.

Outro aspecto que quase sempre é ignorado é que trabalhar em modo multitarefa é desgastante e diminui, sim, a nossa performance, embora muita gente não queira reconhecer isto.

Jeff Sutherland, co-criador do método Scrum, em seu livro “Scrum – a arte de fazer o dobro de trabalho na metade do tempo“, sugere um exercício que “É simples, mas mostra o profundo impacto do foco e do fluxo. Mostra como multitarefas são árduas para o nosso cérebro, e como isso reduz o seu ritmo, mesmo que você acredite que está aumentando. Demonstra como essas atividades desperdiçam tempo e energia.

Capa do livro de Jeff Sutherland sobre Scrum

Capa do livro de Jeff Sutherland sobre Scrum

O exercício é o seguinte: escrever os números cardinais de 1 a 10, os números romanos de I a X e as letras de A a J, da seguinte forma:

Você deve fazer o exercício de duas formas: na primeira, escreva linha por linha, isto é, escreva a primeira linha:

1   I   A

Depois, escreva a segunda linha:

1   I   A
2   II   B

E assim por diante, até a décima linha. Cronometre quanto tempo você levou.

Agora, escreva coluna por coluna, isto é, escreva a primeira coluna:

1
2
3

10

Depois, a segunda coluna:

1   I
2   II
3   III

10   X

E, finalmente, a terceira coluna, a das letras. Novamente, marque quanto tempo levou.

Experimente fazer o exercício, de verdade! Eu fui 40% mais rápido quando escrevi coluna por coluna. É realmente incrível!

Sutherland relata no livro: “Simplesmente por fazer uma (coluna) de cada vez, em vez de ficar trocando um contexto pelo outro, eu cortei pela metade o tempo que levei para realizar a tarefa.

O autor prossegue mencionando o estudo de Gerald Weinberg, que quantifica a perda de produtividade em função de trocas de contexto de projetos.

Perda de produtividade por trabalhar em projetos simultâneos (por Gerald Weiberng)

Perda de produtividade por trabalhar em projetos simultâneos (por Gerald Weiberng)

A coluna “perda” significa puro desperdício!

O Fabrício foi desenvolvedor de software por muitos anos (e, para falar a verdade, ainda gosta de “meter a mão na massa”) e tem um depoimento sobre este assunto:

“Realmente, quando focamos em um projeto só no Scrum, a produtividade do time aumenta a cada ciclo. A gente vai adquirindo conhecimento sobre as regras daquele produto e vai ficando cada vez mais rápidos.

Quem já desenvolveu software moderno sabe que muitas vezes mexemos pela primeira vez com algumas APIs, componentes, classes, frameworks, durante um projeto. Cada projeto é um aprendizado novo. Ficar focado em apenas um projeto torna esse aprendizado muito mais rápido e produtivo.

Aliás, sobre essa questão do ‘aprendizado’, sempre me lembro de um treinamento em Engenharia Ágil de Software que fizemos com o Klaus Wuestefeld na Infoglobo.

Klaus Wuestefeld

Klaus Wuestefeld

Qualquer livro de engenharia de software traz uma definição sobre ‘o que é software’ parecida com esta da Wikipédia: ‘(…) é composto por uma sequência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um programa correto e funcional, essa sequência segue padrões específicos que resultam em um comportamento desejado‘.

Já o Klaus, no curso, deu uma definição completamente diferente, poética até. Algo como ‘software é a expressão do aprendizado da equipe sobre os problemas a serem resolvidos‘.

O que é software (adaptado de Klaus Wustefeld)

O que é software (adaptado de Klaus Wustefeld)

Sem querer entrar no mérito de qual é certa ou errada, o fato é que a definição do Klaus fez muito mais sentido para mim quando pensei nos projetos em que já trabalhei.

Por isso, acho que quando focamos 100% em um projeto de cada vez, conseguimos aprender a ‘resolver seus problemas’ mais rapidamente e de forma mais produtiva.”

Uma última informação: o autor Cal Newport lançou no início de 2016 o livro que ele classificou como “o livro que o Facebook não quer que você leia”, no qual trata sobre concentração e foco: “Deep Work: Rules for Focused Success in a Distracted World“.

Capa do livro Deep Work

Capa do livro Deep Work

Alguns dos feitos de Newport: publicou cerca de 50 artigos acadêmicos, com mais de 2500 citações, escreveu 5 livros com mais de 200 mil cópias vendidas e criou um blog que teve 300 mil páginas visualizadas em Dezembro/2015.

Tudo isto sem trabalhar até tarde da noite e raramente trabalhando nos finais de semana. Apenas usando o foco. 🙂

Abraços,

Cláudio Barizon
Diretor de Negócios Digitais
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 4
Agenda com tarefas do dia

Como fazer o seu dia render?

Olá,

Tudo bem? Desde que me tornei um (feliz) empreendedor adepto do home office, em Setembro/2015, comecei a procurar um método para organizar bem meu dia-a-dia.

Já tinha experimentado por um tempo o método GTD (Getting Things Done), de David Allen, quando fui coordenador de TI na Infoglobo. Li seu livro Produtividade Pessoal e, na época, me agradou.

Livro Produtividade Pessoal, de David Allen

Livro Produtividade Pessoal, de David Allen

Só que desta vez eu procurava algo um pouco diferente, para eu produzir de forma mais eficaz, mas também me fizesse sentir mais dono do meu tempo, já que eu realmente tinha mais autonomia sobre ele.

Eu já conhecia o autor Cal Newport, professor de ciências da computação na Universidade de Georgetown. Pesquisando sobre o assunto, encontrei em um de seus artigos a sua metodologia de planejamento diário.

O título do artigo logo me chamou a atenção: “The Importance of Planning Every Minute of Your Work Day” (numa tradução livre, “A importância de planejar cada minuto de seu dia de trabalho“).

Ora, de imediato, discordei! Afinal, onde já se viu querer planejar cada minuto do seu dia?! Lógico que não vai funcionar!

Porém, como já conhecia o autor, e tinha me identificado com ele, resolvi ler o artigo para conhecer o método. Basicamente, ele consiste em, diariamente, planejar as suas atividades, criando e bloqueando fatias de tempo específicas para cada atividade. Durante essas fatias de tempo, concentração e foco total na tarefa definida.

Gostei muito e coloquei em prática! Veja uma agenda diária minha (as partes hachuradas mencionavam nomes que preferi não expor):

Agenda com tarefas do dia 30/11/2015

Agenda com tarefas do dia 30/11/2015

Três preocupações comuns para quem acaba de conhecer o método (eu realmente tive as duas primeiras):

1) Vale a pena mesmo investir tempo nesse planejamento? Segundo o autor, uma semana de 40 horas de trabalho bem distribuído segundo esse método equivale a uma semana de 60 horas de trabalho adhoc. Não sei quantificar, mas minha percepção é de que funciona, mesmo. Quando chego na fatia de tempo de trabalho, simplesmente a executo e não me preocupo com as outras coisas. Ou melhor, digo “não” para as outras coisas. Email fechado, redes sociais fechadas, etc. Dependendo do nível de concentração que preciso, WhatsApp no silencioso também.

2) E aquelas atividades, não planejadas, que eu sei que vão aparecer (geralmente, no meu email)? Neste caso, o autor também recomenda uma solução simples: crie uma fatia de tempo para elas. Por exemplo, 1 ou 2 horas para checar o email e encaminhar as demandas. Ele, inclusive, sugere uma estratégia para a incerteza natural dessas fatias de tempo: “process client requests; if I have downtime during this block, work on project X”.

3) Será que funciona para trabalhos de natureza criativa? Segundo o autor, sim, porque garante uma dedicação consistente de foco e esforço às atividades criativas. Além disso, a tranquilidade por saber que sua agenda está organizada permite você se aprofundar nesses seus “blocos criativos” e gerar mais valor. Eu acrescentaria que você pode também escolher o seu melhor momento do dia para trabalhar nessas atividades. Por exemplo, eu gosto de escrever mais pela manhã e tenho feito assim. E, de fato, saber que eu tenho um bloco de tempo definido para isso, mas também para as minhas outras atividades, no meu caso, me dá muita tranquilidade e prazer para escrever.

Refletindo sobre o método de Cal Newport, vejo algumas práticas parecidas com o método Scrum: bloquear tempo, foco em uma coisa de cada vez, representar visualmente o trabalho, uma divisão clara entre planejar X executar e a flexibilidade para mudanças.

Aliás, falando em falando em planejar X executar, num outro artigo o autor fala sobre planejar o dia seguinte ao final do dia anterior. Isto eu fiz umas poucas vezes e gostei também, mas confesso que ainda não consegui incorporar como hábito.

Sua metodologia na verdade é bem mais abrangente e aborda também o planejamento semanal e a longo prazo. Se você achar interessante, podemos abordar num texto futuro. Espero que tenha gostado. Veja aqui o artigo original do autor sobre o planejamento diário e deixe seus comentários. 🙂

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


Receba nosso Boletim

Grátis, diretamente em seu email, artigos sobre métodos de startups aplicados a soluções empresariais.