05
Jul 10

Artigo: Falhe cedo, aprenda rápido

Recentemente, precisei escrever um artigo acadêmico sobre o uso de métodos ágeis, com foco em empreendedorismo e aprendizado. A experiência foi ótima, principalmente porque precisei revisitar vários temas que há tempos não estudava – e também aproveitei para ler um artigo célebre, do nosso amigo Edsger Dijkstra – “The Humble Programmer” (se você ainda não leu, recomendo – o artigo é muito bom!).

Fiquei feliz com o resultado, e resolvi divulga-lo aqui no blog, liberando o mesmo sob a licença creative commons.

Sem mais delongas, estou disponibilizando o trabalho aqui.


06
Mar 09

Como a Microsoft está controlando o desenvolvimento do Windows 7

Esta manhã, estava dando uma olhada nas notícias no Google News, quando uma chamada me atraiu: uma notícia do site InformationWeek, que fala sobre como a Microsoft está controlando o desenvolvimento do Windows 7. Supreendentemente, ao ler o artigo, encontrei sinal de vários dos princípios e valores do manifesto ágil, além de sinal algumas práticas ágeis também. É tudo especulativo, mas vamos aos trechos do artigo onde detectei essas congruências; posso esta delirando (por favor comentem!), mas:

Gerência de escopo e os princípios do manifesto ágil

“With Windows Vista, even before we wrote the code, people were talking about features,” Gavriella Schuster, Microsoft’s senior director of Windows client product management for enterprise customers, said in an interview. Leaks were rampant, uncontrolled, and unsubstantiated. Features would be discussed and never heard from again. Not this time, Schuster insisted.

Ou em Português:

“Com o Windows Vista, mesmo antes de que o código fosse escrito, as pessoas já estavam falando sobre as suas funcionalidades”, diz Gavriella Schuster, gerente de produtos para clientes corporativos. Os vazamentos eram repentinos, descontrolados, e insubstantiados. Funcionalidades eram discutidas e nunca mais ouvia-se falar delas novamente. Não dessa vez, insiste Schuster.

Aqui, dois comentários: O primeiro, sobre gestão de escopo. Ao que me parece, a Microsoft decidiu ser muito mais cuidadosa com as informações liberadas para os seus clientes, de forma a evitar que expectativas sejam desapontadas em relação ao que entrará e o que não entrará no produto final. Esses fatos me lembram alguns dos princípios do Manifesto ágil:

  • Working software is the primary measure of progress/Software funcionando é a medida primária de progresso – ou seja, não se fala sobre funcionalidades enquanto ainda não temos uma idéia consistente de como elas serão, e medimos o nosso progresso através do que já foi entregue.
  • Business people and developers must work together daily throughout the project. /Homens de negócios e Desenvolvedores devem trabalhar juntos durante todo o projeto – dessa forma, gerando uma comunicação mais consistente com seus clientes.

O segundo comentário é a respeito do papel do Product Owner, que mostra que tem vontade de entregar o que se foi prometido, e que só passará informações consistentes para o cliente. Sou só eu, ou vocês também enxergam isso?

Release planning, timeboxing e Product Backlog

It also created a firm release timeframe — about three years after the Vista release — and decided to stick with it so that unlike Vista, Windows 7 wouldn’t come five years after the previous Windows edition.

Ou em Português:

Também foi criado uma rígida linha do tempo — cerca de três anos após a release do Vista — e decidiu-se garantir que, ao contrário do Vista, o Windows 7 não seria entrege cinco anos depois da release anterior do Windows.

Se você está achando que isso se parece muito com o conceito de Timeboxing, utilizando em diversas metodologias ágeis, eu acredito acho que você não está enganado. O que também me leva a acreditar que há uma forte estratégia de release planning funcionando, ou seja: gestão de escopo baseada no tamanho e prioridade das funcionalidades. Product Backlog, alguém aí?

Colaboração com o cliente mais do que negociação de contratos e mais um princípio ágil

Even the development of features has taken on a new look with Windows 7, as Microsoft has engaged customers and partners more deeply than in previous releases, looking at more data than it ever has before. […] That included extensive qualitative and quantitative research.

The qualitative research Microsoft performed before Windows 7 has been even broader than the quantitative research. Key business customers — 27 of them, to be exact — were brought into the development process as early as the planning phase […]. During these meetings, Microsoft required that the people who attended were always the same people […]

Ou, em Português

Até o desenvolvimento de funcionalidades tomou uma nova face com o Windows 7, desde que a Microsoft incluiu seus parceiros e clientes mais profundamente do que em releases anteriores, e olhando para mais informações do que nunca […] Isso incluiu extensivas pesquisas qualitativas e quantitativas.

As pesquisas qualitativas que a Microsoft fez antes do Windows 7 foram ainda maiores do que as quantitativas. Clientes corporativos chave — 27 deles, para ser exato — foram incluídos no processo de desenvolvimento tão cedo quanto na fase de planejamento. […] Durante essas reuniões, a Microsoft exigiu que essas pessoas fossem sempre as mesmas pessoas […]

Um dos aspectos mais interessantes que encontrei neste artigo foram os indícios de que a Microsoft está trabalhando com um forte esquema de contato constante com o cliente, e acima temos vários indícios do valor “Colaboração com o cliente mais do que negociação de contratos” e também do princípio ágil “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation“, ou “A maneira mais efetiva e mais eficiente de convergir informações para dentro de um time de desenvolvimento é comunicação face-a-face“.

Entregas sempre, entregas cedo

Some software companies had early access to development toolkits and to a lab set up running early test versions of Windows 7 and Windows Server 2008 R2. Already, Microsoft said, more than 50 companies are testing out Windows 7 […]

Ou, em Português

Algumas empresas de software tiveram acesso muito cedo à toolkits de desenvolvimento, e a um setup de laboratório rodando versões preliminares de testes do Windows 7 e Windows Server 2008 R2. Até agora, a Microsoft diz, mais de 50 empresas estão testando o Windows 7 […]

Aqui, dá para ver claramente o primeiro princípio do manifesto ágil: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” ou “Nossa maior prioridade é satisfazer os clientes através de rápidas e contínuas entregas de software com valor agregado“.

Práticas de engenharia ágeis: teste, teste, teste, teste!

Uma das principais reclamações que escutei do Vista no início e ainda escuto até hoje são os problemas relacionados à performance. O boot é lento, o logon é lento, o shutdown é lento, antes do SP1 copiar qualquer arquivo também era uma tarefa que exigia muita paciência. E isso trazia um alto nível de frustração para o usuário: minha máquina novíssima, com o sistema operacional novíssimo da Microsoft, é infernalmente lenta! Mas a Microsoft ouviu e aprendeu:

Testing also has changed significantly. […] Microsoft also has added many instances of Windows 7 to its automated performance testing. So far, Microsoft has done more than 1 million hours of automated performance testing, generating more than 200 TB of “performance tracers” along the way to analyze and work on performance in Windows 7.

Ou, em Português

Os testes também mudaram significativamente. […] A Microsoft também adicionou muitas instâncias do Windows 7 à sua estrutura de testes de performance automatizados. Até hoje, a Microsoft já fez mais de 1 milhão de horas de testes de performance automatizados, gerando mais de 200TB de “traços de performance”, em conjunto com uma forma de analisar e trabalhar sobre a performance no Windows 7.

E, para finalizar, um último comentário:

While the overhauled development process seems to have worked so far — many early reviews of Windows 7 are positive — the true test won’t come for another several months when Microsoft finally releases the latest version of its flagship operating system.

Ou, em Português

Enquanto o processo de desenvolvimento melhorado parece ter funcionado até agora — muitas das primeiras reviews do Windows 7 são positivas — o teste real não vai vir até que, daqui há vários meses, quando a Microsoft finalmente lançar a versão final do seu sistema operacional carro-chefe.

Eu realmente acredito que a Microsoft aprendeu uma grande lição com as terríveis falhas no processo de desenvolvimento do Windows Vista. A filosofia de “Vai estar pronto quando estiver” é praticamente inexistente, e o feedback constante entre os clientes e a Microsoft estão criando uma onda de otimismo como jamais visto — todos estão falando e muito bem do Windows 7.

Afinal, a Microsoft finalmente enxergou que pode fazer um excelente trabalho apoiada em cima de valores, princípios e práticas ágeis. A minha pergunta final é: porquê você não pode também?

Por favor comentem — preciso saber se isso é um delírio, se estou enxergando chifre em cavalos, ou se realmente estou certo.


04
Mar 09

Agile Weekend 2009

Nos dias 25 e 26 de Abril, acontecerá em Porto Alegre/RS um importante evento organizado pelo grupo de usuários de métodos ágeis do RS: O Agile Weekend 2009.

O evento, que acontecerá daqui a mais ou menos 2 meses, já está com site, com uma programação preliminar e inscrição, e chamada para trabalhos disponíveis em seu site.

Confiram o site do evento aqui.


03
Mar 09

Scrum é efetivo, e não eficiente

Li há um tempo atrás um post do Dan Rawsthorne (CSM, CSP, CST) no blog da Danube Technologies, falando sobre como ele se sentia desconfortável com algumas afirmações ou concepções incorretas a respeito do que é efetividade (effective) e o que é eficiência (efficient). Como o post foi na época de festas, terminei perdendo o timing e não consegui traduzir nem fazer nenhum tipo de comentário no blog, mas tinha deixado o post gravado aqui para depois escrever sobre ele. Fiz uma tradução abaixo (para ver o texto na íntegra, em inglês, clique aqui):

Eu gostaria de falar um pouco sobre uma situação recorrente que encontro nos times que faço coaching e nas classes que ensino. Quando falo com as pessoas sobre Scrum (e agilidade em geral), eu invariavelmente escuto coisas como “Eu gostaria que os meus times fossem mais eficientes”, ou “Estamos usando Scrum então poderemos ser mais eficientes”, e, é claro “nós seremos mais eficientes com esse processo e economizaremos algum dinheiro, certo?”

A resposta é “não”, ou “não imediatamente”, e isso normalmente nos leva a uma conversa sobre efetividade versus eficiência. Por definição, efetividade é “produzir um forte efeito”, que em software siginifica que nós entregaremos algo usável para o negócio. Eficiência, por outro lado, é “produzir resultados com pouco desperdício de esforço”, o que é uma coisa completamente diferente, e é um conceito totalmente não-agile.

Agora, vamos olhar para o que as empresas normalmente fazem (lembre-se que você é o que você realmente faz, e não o que você diz que faz). Em minha experiência, muitas empresas estão no negócio de “deixar as pessoas ocupadas” ao invés de estar no negócio de “produzir um produto”. Isto é, gerentes entram em mais apuros por suas pessoas “desperdiçarem tempo” do que por sua organização não produzir o produto correto. Isso é uma vergonha.

Agilidade é sobre ciclos de “verificação e adaptação”, ou seja, feedback. Quanto mais feedback você recebe, mais efetivo você será, mas mais esforço será também gasto. Isso é inerentemente ineficiente — estamos sacrificando efetividade de propósito. Para poder ser eficiente com agile, você precisaria de loops de feedback que te fornecessem as respostas que você precisa o mais rápido possível, e ter o quanto mais loops de feedback como possível. E nós não sabemos como fazer isso, sabemos?

Aqui é quando aparecem frases como “falhe rápido, falhe cedo”, que é uma forma de dizer que nós gostamos de ser eficientemente ágeis, aprendendo nossas lições o mais rápido possível. Okay, e não me importaria em ser eficientemente ágil, preferiria ao invés disso ser efetivo do que eficiente. E, na minha visão, não traz nenhum bem tentar ser eficiente até que você já saiba como ser efetivo. Isto é, se você pnão consegue produzir o produto certo todas as vezes (ou virtualmente todas as vezes) então não tente adicionar eficiências ao seu processo.

Para colocar de maneira bem simples, “Waterfall é eficiente — agilidade é efetiva”, e quando nós tentamos ser eficientemente ágeis, nós terminamos por introduzir uma falsa previsibilidade no nosso processo, que no final, termina nos ferindo.

É isso por agora, meus dois centavos, Dan.


02
Mar 09

Review de ferramentas para gerir projetos ágeis

Há algum tempo, o Mike Cohn (autor de Agile Estimating and Planning e User stories applied) postou na lista Scrum Development do Yahoo! Groups uma mensagem falando que ele estava criando um site com o objetivo de centralizar reviews de ferramentas para métodos ágeis. Ele entrou em contato com diversos fabricantes, para que pudessem listar seus produtos no site, e os usuários poderiam então fazer o review das ferramentas, relatando suas experências e ajudando a comunidade como um todo a separar o joio do trigo.

O site está no ar desde Outubro/2008, e já possui algumas reviews de usuários e uma lista consideravel de ferramentas (mais ou menos 50 ferramentas). Estão lá listadas desde as ferramentas mais conhecidas, a brasileiríssima FireScrum, desenvolvida pelo pessoal do C.E.S.A.R.EDU e algumas ferramentas também que eu jamais havia ouvido falar.

Particularmente não gosto de ferramentas on-line para gerir projetos ágeis – na minha opinião, nenhuma dessas ferramentas chega aos pés do bom e velho taskboard – mas, se for necessário usar uma ferramenta dessas, esse site nos dá uma oportunidade de ouvir a comunidade e utilizar algo de bom. Confiram:

http://www.userstories.com/