Author Archives: Cláudio Barizon

  • 2

Compartilhando um pouco da Minha Experiência com o Agile: Um Case Especial

Tags :

Category : Bússola Digital

Em 2013, comecei uma jornada nova para mim: saí do mundo corporativo para empreender. Certamente não foi uma decisão fácil, mas aconteceu naturalmente. O Juan Bernabó, mestre e referência na evangelização das práticas pragmáticas, e que foi o nosso consultor na adoção de metodologias ágeis na Infoglobo alguns anos antes, de onde eu vim, buscava um parceiro capaz de realizar as entregas (dos projetos e produtos) e trabalhar na transformação dos ambientes. Nesta ocasião, Jesuíno Lopes e eu embarcamos neste processo (posteriormente, o Fabrício Fujikawa se juntou a nós). Nosso objetivo, à época, foi fazer da Teamware, hoje ViaDigital, uma referência neste trabalho de transição para um modelo de gestão mais moderno, garantindo às empresas (clientes) usufruir dos benefícios das entregas ágeis e da geração de valor cada vez mais rapidamente.

E foi exatamente esta a nossa grande motivação: disseminar esta nossa experiência tão rica e tão transformadora. Na verdade, senti-me na obrigação de compartilhar esta vivência! Mostrar para outras empresas que é possível construir uma área de TI diferente, estratégica, pró-ativa e inovadora, capaz de trabalhar com as áreas de Negócio de forma muito integradas, com total transparência na comunicação e com um objetivo comum. Um verdadeiro trabalho colaborativo, onde a equipe possui mais autonomia e responsabilidade, gerando um profundo engajamento e enorme motivação. E onde busca-se o que é melhor para o produto e para empresa e não para um departamento ou outro: o valor para o negócio é colocado em primeiro lugar, permitindo, assim, que as entregas sejam mais rentáveis e enxutas e, consequentemente, mais rápidas e baratas.

Vamos usar o nosso blog para apresentar cases de como isso é possível e como isso acontece. No entanto, para melhor tangibilizar esta harmonia que contei acima, com o foco no objetivo comum, alegria do trabalho colaborativo e atingimento dos resultados num curto espaço de tempo, geramos um pequeno vídeo. Nele, contamos a experiência que tivemos na entrega de uma nova versão do Site do Globo, enquanto ainda estava na Infoglobo. Foi um momento incrível, com uma tremenda equipe e um super desafio para todos os envolvidos, pois, além do prazo “impossível”, este era um projeto muito importante dentro de um grande programa, onde muitas mudanças estavam acontecendo simultaneamente.


  • 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


  • 1
Exemplo de Quadro Scrum

Como é que de quadros e post-its vai sair um software bom para os clientes?

Tags :

Category : Bússola Digital

Olá,

Tudo bem? Para quem nunca usou Scrum (ou outra metodologia ágil na prática), é muito comum ter essa dúvida: como é que de um quadrinho com post-its coloridos sai um software decente e, ainda mais, que agrade aos clientes e usuários?

Quando comecei a adotar o Scrum na Infoglobo, em 2008, também tinha essa desconfiança… um certo preconceito até. E não me envergonho em admitir isso, porque sei que não é uma questão de certo ou errado… apenas eu vivia dentro de um paradigma de trabalho diferente, que era uma continuação do que tinha estudado na faculdade.

Ainda bem que consegui me dar a oportunidade de trabalhar com o Scrum e, hoje, muitos anos e projetos entregues com sucesso depois, consigo ver a realidade de outra forma. Tenho plena convicção de que o método funciona bem para qualquer tipo de software e processo de trabalho. Já usei inclusive para reformar meu apartamento!

Uma de suas ferramentas mais valiosas, talvez a mais percebida por todos (os que usam e os que não usam o método) e, por isso mesmo, talvez a mais controversa, é o quadro Scrum.

Compartilho com você neste vídeo minha visão de por que um quadro Scrum funciona e promove transformações tão profundas.

Lendo o livro “Scrum – Gestão Ágil para Projetos de Sucesso”, de Rafael Sabbagh, entendi a explicação científica por trás dessa minha percepção de transparência que o quadro Scrum proporciona:

“Esse tipo de quadro é classificado como ‘irradiador de informação’, ou seja, a informação chega aos olhos de quem é importante chegar sem haver um esforço significativo para buscá-la. É muito mais eficiente, por exemplo, do que um programa de computador, que necessita de ser acessado para mostrar a informação.”

Como disse no vídeo, o quadro básico de Scrum é muito simples, composto por uma lista ordenada de histórias e tarefas, com 3 colunas: a fazer (to do), fazendo (wip) e feito (done).

Exemplo de Quadro Scrum

Exemplo de Quadro Scrum

As histórias mais importantes, que devem ser concluídas primeiro, ficam em cima. As menos importantes, ficam em baixo. Embora as histórias sejam de autoria do Product Owner (pelo menos a autoria principal), as tarefas (os post-its menores) são de autoria do time de desenvolvimento.

Isto significa que é o time que decide o que será feito para entregar a história. O Fabrício, que já participou como membro de time e Scrum Master em vários projetos Scrum, tem um depoimento interessante sobre esta questão:

“O quadro Scrum dá uma sensação de empoderamento e autonomia incríveis ao time. É muito diferente você trabalhar em algo em que você teve a oportunidade de opinar e dizer que achava que era importante fazer aquilo, do que quando você faz porque te passaram a atividade, ou para seguir um processo ou uma norma corporativa, simplesmente por seguir.

Até mesmo as atividades de documentação, QA e testes, que normalmente são atividades menos prazerosas para os desenvolvedores, tornam-se mais agradáveis desta forma.

Lembro-me de que um diagrama que fizemos em praticamente todos os projetos é o diagrama de arquitetura explicitando os componentes da solução e os pontos de conexão das integrações. O time percebe que ele é necessário: ao invés de toda hora um ficar perguntando para o outro “Qual é mesmo o nome ou IP/porta do servidor de qualidade daquela API?”, o time sente que pode performar melhor se investir um pouco de esforço em criar um diagrama simples que possa ser consultado sempre que necessário.

O quadro Scrum também é uma expressão do modelo mental coletivo do trabalho. E a gente, como membro do time, percebe que esse modelo mental coletivo é maior do que o nosso modelo mental individual. A gente sente que a equipe consegue fazer coisas que eu, sozinho, não consigo. Mas eu faço parte da equipe, faço parte dela e contribuo com ela. Tem uma parte de meu valor aí. Só que o ponto é que o valor total é maior do que a soma dos valores individuais. A gente vê isso claramente com as histórias e tarefas no quadro.

Outra coisa que eu acho muito positivo é que com o quadro Scrum o time fica muito bem organizado. Eu podia sair mais cedo e no dia seguinte, quando eu chegasse, eu sabia exatamente no quê eu deveria trabalhar, sem correr o risco de retrabalho. Se eu ficasse até mais tarde, não precisava me preocupar em mandar um email avisando para o primeiro que chegasse no dia seguinte onde parei. Era simplesmente chegar, olhar o quadro, e puxar a próxima atividade.

Por último, o quadro Scrum tem um pouco de coisa lúdica… é como se fosse um tabuleiro de jogos, em que a gente tem que andar com os post-its para a direita. Pode parecer bobagem, mas o fato é que é de certa forma divertido fazer isso… a sensação de olhar para o quadro e ver os post-its todos à direita, na coluna ‘Feito’ é muito boa. Eu acho até que essa sensação positiva é compartilhada também pelo PO e pelos stakeholders.

Tudo isso motiva muito! E trabalhar motivado é simplesmente muito bom!”

Para fechar, um alerta: o quadro Scrum é simples, eficaz e excelente instrumento de trabalho para o seu time. Mas, ele não faz mágica. São os desenvolvedores que continuam criando o software. O quadro apenas ajuda o seu time a trabalhar melhor, nas coisas certas, e encontrar sua melhor performance.

Abraços,

Cláudio Barizon
Diretor de Produtos Digitais
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.