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.


05
Mar 09

Apresentação sobre Test Driven Development – TDD

Uma das coisas que eu costumo repetir e re-repetir novamente nas conversas sobre métodos ágeis é que não dá para ser ágil sem adotar práticas de engenharia ágeis.

Eu não me canso de repetir: não é possível adotar uma técnica de gestão ágil de projetos, como o Scrum, sem abraçar os princípios do manifesto ágil e adotar práticas de engenharia consistentes, tais como Integração Contínua, Testes, Pair programming, Testes, Code Review, Testes, entre outros.

O Marcos Pereira fez uma excelente apresentação sobre TDD (aliás, deixo uma dica para um excelente artigo que o Marcos escreveu há um tempo atrás, falando do porque os desenvolvedores odeiam testar), que na minha opinião é uma prática importantíssima, e que num mundo ideal, seria uma disciplina básica em qualquer universidade – confiram:


20
Oct 08

O iceberg do Product Backlog

Encontrei esta imagem, originalmente em inglês, no blog do Boris Gloger. Achei bastante interessante e inteligente, uma maneira muito legal de representar a emergência de um Product Backlog. Não somente o tamanho das estórias aumenta à medida que nos afastamos da Sprint Atual, a prioridade também diminui.

Veja o post original do Boris aqui.

E o site do autor original da imagem aqui.

Agradecimentos à ambos, por terem disponibilizado o source da imagem para a tradução! Obrigado!


13
Oct 08

Porque as pessoas resistem à mudanças?

Um dos maiores problemas que nós encontramos quando falamos em Agile é a resistência à mudanças. É incrível como as pessoas tendem à resistir à mudanças, sejam elas quais forem.

Na minha experiência implementando Scrum encontrei resistência à mudanças em várias situações. Inclusive, encontrei resistência em lugares onde não imaginava que iriam existir, como no time, e em lugares onde eu já esperava ter alguma resistência, como na área de gerência e diretoria.

Dando uma sacada no blog do Boris Gloger, encontrei esse set de slides muito interessante:

5 Reasons Why People Resist Change

Vale à pena dar uma olhada!


30
Sep 08

O que eu faço com os under-performers?

Vi esse post no Blog do Boris Gloger, e achei muito bom. Extremamente interessante, este tema foi discutido em uma thread bem recente da lista scrum-brasil. Lá na lista, a discussão foi longa, e várias respostas agregando muito valor foram postadas, mas quando vi esse post no Blog do Boris fiquei meio sem chão. Na minha resposta, falei em colaborar com o funcionário (o under-performer em questão), em dar feedback, técnicas para dar feedback, enfim… E o autor original do post respondeu que já tinha tentado de tudo, mas o cara não melhorava.

Continue reading →