O que queria provar é que é possível desenvolver um produto de forma incremental, feature a feature, aplicando um processo 100% ágil e entregando resultado rápidamente, contando com a participação de usuários reais e não baseado em achismos. Este produto hoje se chama Yahoo! Meme e vou compartilhar aqui pouco de como foi esta experiência.

Assim que cheguei no Yahoo! tive de montar a equipe, neste quesito eu já tinha certeza dos papéis que precisava:

• um Designer que escrevesse código e fosse responsável pela implementação 100% da Interface
• Desenvolvedores que gostassem de TDD e que topassem fazer qualquer coisa: frontend, backend, costurar, cozinhar, etc
• um Product Owner (PO) que tivesse conhecimento técnico e entendesse de Internet.

Enquanto o processo de entrevistas e seleção da equipe rolava, eu já havia encontrado o nosso PO (Pedro Valente) e começamos a montar alguns processos de Ideation e Filtragem de ideias, começamos a fazer vários brainstorms e o resultado foi um “framework” (ou um arcabouço como diriam alguns teóricos brasileiros ) para selecionar e filtrar ideias de uma forma mais ou menos científica e menos baseada em achismos e sentimentos.

Alguns pontos deste framework:

• Definir um público alvo: nosso caso Jovens 16-32 anos;
• Encontrar problemas reais e de grande impacto que ainda não tenham sido totalmente resolvidos;
• Encontrados os problemas, existem Players no mercado que solucionam este problema? Podemos resolver de uma forma melhor? Podemos simplificar a solução?
• Com as possíveis soluções, começamos a esboçar em que produtos aplicaríamos as mesmas.
• Legal, tínhamos encontrado alguns problemas que poderíamos resolver e suas possíveis soluções, neste momento aplicamos alguns filtros para selecionar qual seria o produto que começaríamos a “prototipar”. Este filtros não passam de umas 8 perguntas com respostas binárias (sim e não) que aplicávamos a todas as ideias, depois ordenamos as idéias pelas que tinham mais respostas “sim”

OBS: quando eu falo prototipar estou me referindo a desenvolver as features principais do produto. A entrega do protótipo é software funcionando e não telinhas e flashizinhos ou PPTs

Em paralelo a equipe foi sendo selecionada e já estávamos completos para começar a montar nosso ambiente de desenvolvimento e a escrever as principais User Stories do nosso primeiro protótipo. Este é um dos momentos onde o fato de termos um Product Owner com conhecimento técnico é vital, pois grande parte das primeiras User Stories seriam de infraestrutura básica do produto, o desenvolvimento das provas de conceito para confirmarmos a viabilidade do produto.

A entrega deste Sprint Zero, em Dezembro de 2008, seria algo muito mais técnico e menos visual e ainda teríamos que entregar os ambientes de Desenvolvimento, Continuous Integration, Staging, etc. O PO precisa ter sensibilidade para entender o que é importante ser priorizado e que algumas vezes as entregas serão mais técnicas (mas sempre sem perder o foco no usuário final).

Com as peças em seus devidos lugares, iniciamos o desenvolvimento do nosso primeiro produto e quando participei do primeiro Sprint Review, sabia que tínhamos algo na mão que pudesse dar um bom resultado. O projeto nesse momento tinha o codename de “GoodStuff”, pois queríamos permitir que os usuários tivessem um lugar onde eles pudessem propagar coisas legais (good stuff) que eles encontrassem pela Internet de forma fácil e rápida

E assim começamos a desenvolver User Story a User Story, funcionalidade por funcionalidade e em Fevereiro de 2009 fizemos nosso primeiro release interno dentro da rede do Yahoo!, apenas alguns poucos Yahoos poderiam usar o produto e nos dar feedback. O interessante é que o produto em si, possuía apenas algumas poucas funcionalidades, o que definimos como os maiores diferenciais e precisamos saber se estávamos realmente no caminho certo, para isso nada melhor do que ouvir usuários de verdade.

Para se ter uma ideia de como o produto estava no básico do básico o thumbnail/avatar de todos os usuários era fixo (usavamos uma imagem do Vitor Fasano), que depois virou uma User Story: “Eu como usuário não quero mais ter o thumbnail do Vitor Fasano”.

Assim caminhamos por mais alguns Sprints, repriorizamos as Stories baseadas no feedback dos usuários, mas sem perder o foco no objetivo que traçamos para o Produto, sobre este assunto eu sempre gosto de citar uma frase de Henry Ford na ocasião do lançamento do Ford T.

“Se eu perguntasse para meus clientes o que eles gostariam, eles me responderiam: Cavalos mais rápidos”

É muito importante ter a visão de onde você quer chegar e depois ir adaptando o caminho que você toma com base no que seus usuários dizem e em como o mercado evolui.

Fomos aumentando o número de Yahoos com acesso ao produto, coletando mais feedback e em Abril deste ano chegamos ao ponto onde tínhamos o que classificamos como “good enough” e fizemos um lançamento que chamamos de “Friends and Family“, foi a primeira vez que o produto foi aberto para usuários externos ao Yahoo!, foi neste momento que escolhemos o nome Meme. A equipe convidou alguns familiares e amigos e cada um destes tinha o direito a convidar outros 3 amigos e assim por diante, chamamos esta fase de Private Alpha.

Agora com mais e mais usuários chegando pudemos coletar mais feedback, e assim os usuários passaram a fazer parte do desenvolvimento do produto, nos dando dicas do que eles achavam importante e como podíamos melhorar. Com estes dados repriorizamos coisas que julgávamos como não prioridade. Por exemplo, um dos maiores pedidos era a possibilidade de buscar por outros usuários, então desenvolvemos uma busca de pessoas super simples, e depois comentários, e assim por diante. Internamente o produto fez tanto sucesso que nos foi pedido para fazermos uma versão em Espanhol, que lançamos em meados de Julho e depois uma versão em Inglês que lançamos no final de Agosto. Hoje o Yahoo! Meme esta em Private Alpha em 4 países: Brasil, México, Argentina e Philippines, e quem sabe o que virá mais a frente.

Em Setembro abrimos nossa API, baseada no Yahoo Query Language (YQL), que permite desenvolvedores usarem uma sintaxe similar ao SQL para recuperar dados do Meme. Sem fugir muito do tópico mas já fugindo, este aqui é um exemplo de query YQL que devolve todas as infomações sobre o meu meme.

SELECT * FROM meme.info WHERE name=’acarlos1000′;
Clique aqui para ver o resultado no Console do YQL

Aqui tem um um outro exemplo que mostra 100 dos meus seguidores ordenados por número de seguidores;

SELECT * FROM meme.followers(100) WHERE owner_guid IN (SELECT guid FROM meme.info WHERE name=’acarlos1000′) | sort(field=”followers”) | reverse();
Clique aqui para ver o resultado no Console do YQL

Finalmente, a lição que aprendi neste último ano é que, sim possível desenvolver produtos de forma incremental e que tenham alcance mundial se o problema que você esta resolvendo for grande o suficiente e a sua solução simples o suficiente, de forma a que o produto faça sentido em diversas partes do mundo.

Por último agora em Setembro, nosso time foi eleito um dos 10 melhores times de todo o Yahoo! entre mais de 14.000 funcionários, ganhando um prêmio interno chamado de Yahoo! Super Star Award. Mais uma prova de que se você tiver foco, entregar valor consistentemente e executar com qualidade o reconhecimento sempre virá.

Yahoo Super Star Award, assinado pela CEO do Yahoo! Carol Bartz

Abs e confiram o meu Meme: http://meme.yahoo.com/acarlos1000, se precisarem de convites para entrar, escrevam um comentário com seu e-mail que eu envio mais tarde.

Adicionando um pouco de contexto, o foco deste post é conversar sobre duas formas de trabalhar em ambientes que envolvam UX no desenvolvimento de projetos Web:

Quando pensamos com mais calma sobre estas comparações, acho que a conclusão fica meio óbvia, principalmente se o objetivo é ter a melhor qualidade possível como “saída” do nosso trabalho. Explicando: ao desenvolvermos um projeto novo o que é mais fácil? Fazer pequenas partes muito bem, com foco total e com o decorrer do tempo ir desenvolvendo as outras partes enquanto se ve o software funcionando, OU fazer um grande projeto com milhões de partes de uma só vez, para depois de um tempo razoável entregar todas as telas e suas variações para a próxima área responsável? É importante lembrar que em times ágeis o que é definido como entrega é software funcionando e não um monte de telas, especificações, casos de uso ou documentações.

Fazendo um paralelo com o nosso dia a dia (pelo menos eu sou assim), quando tentamos fazer muitas coisas ao mesmo tempo, geralmente não fazemos nada com profundidade e no final acaba tudo ficando “meia boca”. Ao ir desenvolvendo novas funcionalidades ou melhorias a cada 15 dias (citando um exemplo da duração de um Sprint aqui no Yahoo!), podemos pensar bem a respeito do funcionamento de cada item e, mais importante, temos a chance de envolver todos no time nas decisões: desenvolvedores, designers, Produto, QA, etc. Com isso eu sinceramente acredito que a qualidade geral do produto e das decisões tomadas aumentam exponencialmente e ficam cada vez mais consistentes com o tempo.

Sempre que vi um projeto sendo feito da forma tradicional, existia um batalhão de Designers que faziam “milhões” de telas, para que todas as variações possíveis fossem mapeadas antes de serem entregues para a equipe de desenvolvimento, muitas vezes chamavamos estas pessoas de “replicadores de telas”. É óbvio que quando se faz um trabalho em massa, como se fosse uma fábrica, nem tudo terá a melhor solução e alguns parafusos deverão ser apertados mais tarde, algumas partes vão precisar de alguns remendos para encaixarem e com certeza várias das telas criadas nunca serão implementadas representando total perda de tempo e dinheiro. O mesmo acontece com as fábricas de software, elas fazem com que os desenvolvedores trabalhem em paralelo como se cada um fosse uma máquina (os famosos Code monkeys). Os designers “Replicadores de telas”, nada mais são do que uma versão da fábrica de software aplicada ao UX.

Estes são conceitos bem básicos sobre desenvolvimento ágil e que podem ser melhor visualizados através das duas figuras abaixo:

Figura 1: Sprints com entregas constantes

Na Figura 1, temos o modelo ágil onde ao final de cada Sprint sempre haverá uma entrega de software funcionando, ou seja, com entrega de valor para o cliente, valor perceptível e paupável, pois estes poderão ver seu produto funcionando e se tornando real de forma evolutiva. Uma situação interessante é que se o orçamento acabar no Sprint 3, pelo menos o produto terá 3 Sprints completos de funcionalidades entregues e funcionando em produção.

Figura 2: Metodologia Waterfall

Na Figura 2, temos o método tradicional, onde vemos que o produto só vai funcionar ao final de quase todas as etapas, o que pode levar a tomadas de decisão preciptadas. Aplicando a mesma situação, se o orçamento acabar na fase 2 (Arq. da Informação e Design) o que podemos entregar para o cliente é uma série de documentos e PSDs, nada de software funcionando.

Em todos os eventos relacionados a desenvolvimento de software sempre tem uma pergunta da platéia sobre que ferramentas são usadas para gerenciar as equipes que usam métodos ágeis. Algumas estão aqui:

- Como gerar relatórios e ver como estão as coisas?
- Como ter certeza de que um release será entregue? Eu consigo ver isso quando uso o M$ Project!
- Como podemos controlar as pessoas que são alocadas parcialmente em diversos projetos sem uma ferramenta?

Ai quando penso nas respostas vejo que o título deste post não esta sendo verdadeiro, na verdade não é que eu não goste de ferramentas de gerenciamento, eu não gosto de ferramentas de uma forma geral. Isso é tão verdade que tenho uma resistência muito grande para aceitar tools nas minhas equipes, isso aconteceu recentemente quando minha equipe no Yahoo! sugeriu usarmos o Campfire para registrar os bate papos da galera e os links que são trocados, assim todos podem ter um log do que aconteceu durante o dia. Tenho uma grande preocupação de que uma ferramenta vá efetivamente adicionar valor ao trabalho das pessoas e não apenas gerar mais um passo no dia a dia delas que não seria necessário se não fosse o relatório para o gerente ou diretor, que na maioria das vezes nem lê estes relatórios.

O que mais me chateia neste tipo de pergunta é que existe um fato que muitas vezes não admitimos,  as pessoas preferem acreditar muito mais no que uma ferramenta mostra do que se um “humano” apresentasse a mesma informação. As pessoas preferem conversar por um chat ou IM do que levantar e ir conversar cara a cara ou no pior dos casos por telefone. Com o decorrer dos tempos e a popularização de diversas tecnologias passamos a nos apoiar nessas ferramentas de forma desmedida, em detrimento do relacionamento e do trabalho em equipe. Neste ponto acho importante fazer uma mea culpa, eu sou viciado em tecnologia e uso meu iPhone o dia todo, o tempo todo, twittando, mandando SMSs e navegando, mas isso não me tira o dever de interagir com meus colegas e amigos entre uma twitada e outra

Quando falamos em desenvolvimento ágil estamos falando de pessoas (vejam o vídeo do Danilo Bardusco),  nestas equipes preferimos usar a comunicação verbal do que documentos com happy paths e paths alternativos e preferimos desenvolver o que sabemos com clareza do que tentar prever o futuro por seis meses, acredito muito na premissa que li em uma entrevista do J Allard (head de games da Microsoft e responsável pelo projeto do Xbox) “if it’s a possibility that you may fail, then fail fast and learn“.

Voltando a questão de gerenciamento por ferramentas, é importante dizer que nunca trabalhei com equipes espacialmente distribuídas, já vi várias aqui no Yahoo!, mas eu nunca gerenciei uma delas. Então toda a minha experiencia vem de trabalhar com equipes alocadas no projeto, fora quando eu trabalhava com empresas terceiras de três letrinhas, onde experimentei na própria pele o pesadelo das malditas fábricas de software.

Sendo assim, quando desenvolvemos algumas coisas, eu basicamente uso o Quadro branco com post-its ou cartões (como prefere o Phillip Calçado). Mas em alguma situações admito que é preciso gerar algum tipo de report para áreas gerenciais. Na minha opinião não existe nada melhor do que ver o quadro, nada é mais claro para ver como as coisas estão andando do que o quadro com as Histórias, tarefas e o burndown chart.

Atualmente estou usando um Twiki que gera os principais gráficos de acompanhamento do sprint, é exatamente da mesma forma que usava quando trabalhei na Globo.com, lembro que na época existia uma vontade ensandesida de comprar alguma ferramenta para que as equipes pudessem atualizar suas tarefas e assim gerar relatórios fantásticos de custos e performance, bugs por pessoa, por linha de código ou por piscada de olho do desenvolvedor.

O problema na verdade não esta no relatório ou na ferramenta, o problema real é que as pessoas não confiam umas nas outras, e elas se apóiam em tecnologias e ferramentas para se blindar e muitas vezes se armar e poder desmascarar uns aos outros. Agora como é que se pode trabalhar em um ambiente em que não existe confiança, onde as pessoas ficam falando pelas costas umas das outras. Este é O PROBLEMA, e as ferramentas de gerenciamento não resolvem isso, só agravam. Não é pagando US$566.40 dólares por usuário/ano em uma ferramenta que se resolve esse isso, porque nenhuma ferramenta pode arrumar isso, só uma conversa clara, limpa e verdadeira é que pode ajudar a resolver essa situação.

Havendo transparência e confiança, pode-se trabalhar para arrumar os nossos defeitos e outros problemas, afinal de contas somos humanos e não máquinas.

Muitos podem não concordar comigo, não tem problema, acho que todos temos as nossas opiniões e acho legal que tenhamos divergências, mas eu já sofri muito e tentei muito usar ferramentas na minha vida. Mas cansei, elas nunca funcionaram comigo, e olha que já trabalhei com diversas empresas CMM5 e com três letrinhas que são super premiadas internacionalmente e não adiantou, os M$ Projects nunca diziam a verdade e tínhamos sempre que “gambiarrar” o projeto, onde geralmente o que era cortado de cara era a qualidade e as pessoas eram tratadas como utensílios. “Ah este recurso aqui esta alocado 13% em requisitos deste projeto, mas ele atua como tester 35% neste outro projeto aqui” QUEM é que em sã consciência acredita que um humano consegue se controlar desse jeito (13% para um lado, 35% para outro, 26,5% para tal coisa) isso é muito idiota.

Por ter errado muito na minha vida e ter caído no conto da carochinha muitas vezes, pensando que selos e certificados significavam alguma coisa, eu aprendi a ter aversão a ferramentas e processos burocráticos, pesados e principalmente mentirosos. Tem uma frase que uso muito e que ouvi pela primeira vez de um diretor de uma grande empresa de comunicação: “Cachorro mordido por cobra, tem medo de salsicha!“.

Hoje em dia o que mais vale pra mim é estar bem com o que estou fazendo, discutir de forma construtiva com minha equipe e outras pessoas e poder trabalhar com coisas legais, mesmo sabendo que nem sempre fazemos coisas legais 100% do tempo. #prontofalei.

Apesar de ser a primeira edição do evento, a Caelum trás na bagagem a experiência de realizar o Falando em Java, evento já bem conhecido dos desenvolvedores e muitos anos de participação na comunidade de desenvolvedores no Brasil.

Como não poderia deixar de ser, a agenda esta excelente. Vou poder reencontrar alguns velhos amigos e trocar idéias com pessoas que estão buscando se aprimorar e conhecer mais sobre processos ágeis de desenvolvimento, entre os palestrantes estão Phillip Calçado, Guilherme Chapiewski, Danilo Bardusco e o David Anderson, um dos criadores do FDD (Feature Driven Development). Aqui esta a agenda completa.

Eu vou falar sobre o Product Owner e seu papel dentro de um time ágil, e discutir alguns pontos que sempre surgem quando se fala sobre a sua atuação: o Product Owner pode ser técnico? O PO é parte do Time ou deve ficar de fora do Time? Como se planejar para entregar um release em uma data específica?

Vejo vcs lá!

Ainda acho que tudo se resolve com um bom e velho whiteboard, lembrando um dos princípios do Agile Manifesto “Individuals and interactions over processes and tools“. Se for necessário gerar um report do andamento do projeto (ou do sprint) tire uma foto do whiteboard todos os dias e envie para quem precisa deste report. Não tem nada mais claro para verificar problemas e andamento de um time do que o whiteboard.

Hoje em dia a Globo.com esta recoberta de Whiteboards e os burndown charts podem ser vistos por toda a empresa, o que mostra como as coisas estão mudando por aqui. Mas isso não tira mérito das pessoas que tentam encontrar formas de melhorar o trabalho quando times precisam atuar em um mesmo projeto e estão separados geograficamente.

Nas minhas leituras esporádicas de RSS encontrei um post sobre um projeto interessante do Henrik Kniberg chamado Whiteboard Wiki (http://www.whiteboardwiki.org), que se propõe a recriar online, de uma forma simples e direta, o ambiente de um whiteboard.

De qq forma ainda acho que se vc tiver uma opção de manter o time co-locado, nem pense em outra alternativa, “Take It“. Em linha com isso esta um paper do Gary e Judith Olson chamado Distance Matters, onde eles apresentam um estudo sobre o uso de tecnologia como forma de diminuir os problemas da distância. Abaixo segue a conclusão deste Paper:

Collaborative work at a distance will be difficult to do for a long time, if not forever.There will likely always be certain kinds of advantages to being together. However, as a wide range of collaborative tools emerges, we will find useful ways to use them to accomplish our goals. If at some point in the past we had written a similar article about telegraphy, the telephone, radio, television, or fax machines, we would have had tables that catalog their shortcomings. However, in their own ways, all of them have turned out to have been useful for a variety of purposes, and they worked their ways into social and organizational life in enduring fashion. Indeed, some of the most profound changes in social and organizational behavior in this century can be traced to these tools. The rich repertoire of present and future collaborative technologies will have a similar fate. We will find uses for them, and descriptions of collaborative work in the future will enumerate the emergent social practices that have put these technologies to useful ends. But it is our belief that in these future descriptions distance will continue to matter.

A lista esta sucinta, mas já constam diversos problemas muito comuns no dia a dia de equipes ágeis. Um dos problemas que me chamaram a atenção e é um problema que temos que evitar a todo custo é a formação do que venho chamando de mini-waterfalls. As pessoas com o tempo, mesmo quando estão dentro de times ágeis, tendem a voltar a fazer as coisas como sempre fizeram, principalmente quando aparecem problemas, Ken Schwaber descreve esta reação no seu livro The Enterprise and Scrum, e a chama de “Muscle Memory”:

Expect muscle memory to exert itself. When a project is going well, everyone is happy with Scrum. However, when stress, a problem, or an unexpected failure occurs, everyone tends to throw away Scrum and revert to their muscle memory. Teams don’t want to self-manage. They want to be told what to do. Managers don’t want to let teams self-manage. They want to command the teams in all matters, down to the minutest detail. Teamwork is dumped for individual heroics. Quality is abandoned. Everyone draws on what they think has worked best in the past. (SCHWABER, The Enterprise and Scrum, Chapter 4).

Bem, detalhamento um pouco mais, entre as caracteristicas de um time ágil temos que ter um número pequeno de profissionais, com todas as habilidades necessárias para que se atinja o goal/visão definida pelo Product Owner e entregando o maior valor de negócio possível no menor tempo possí­vel, aplicando sempre o princí­pio de implementar “The simplest thing that could possible work“.

É neste ponto onde começam os problemas que vão gerar o mini-waterfall, geralmente as pessoas trabalharam toda a sua vida em empresas que empregam o princípio do Big Design Up Front (BDUF), ou seja, primeiro as pessoas querem planejar todas as possí­veis variações do projeto, em todas as telas, todas as mensagens de sistema, todos os fluxos, todas as queries, todo o modelo de dados antes mesmo de começarmos a “meter a mão na massa” no projeto. Isso leva a departamentalização e ao faseamento do desenvolvimento em steps especializados: Levantamento de requisitos, análise, arquitetura da informação, design, provas de conceito, desenvolvimento, testes, produção. Com isso criamos um processo em cascata que incentiva o veneno deste tipo de abordagem: falta de compromisso com o todo, com o Goal e com a Visão, cada um faz a sua parte, e que o próximo na fila no processo dá o seu jeito para entregar para o próximo e assim por diante, as pessoas passam a ser responsáveis pelas suas especialidades e não pelo produto, pela entrega final. É triste ver um time, antes ágil, começando a criar hábitos cascateados e viciados.

O que fazer? Este exemplo usado pelo Mark Levison mostra como seria uma postura ágil:

A successful Scrum team does not need to be comprised entirely of generalists. However, for a team of specialists to be successful each specialist must accept general responsibility for the system as a whole. I may not know how to solve our project’s most intricate Oracle problems but I am going to do whatever I can to help, which may simply include taking on some of our database specialist’s other responsibilities to free her to solve the complex problems.

Enfim, temos que nos policiar contantemente e observar se não estamos voltando aos nossos velhos hábitos, e lembrar que é muito difícil mudar a cultura das pessoas e da organização, e que isso é um trabalho de paciência e perseverança.

Obviamente, em uma empresa que projeta reatores e usinas nucleares a inovação e experimentação não eram vistos com bons olhos, na verdade era inibida sempre que possível. Em 2006 a Toshiba (WTF?) comprou a Westinghouse Electric por US$ 5.4bi e começou uma nova fase na empresa, iniciou-se um processo incentivo a inovação em toda a empresa, sem comprometer a integridade dos sistemas e produtos atuais.

Obviamente este é um processo que esta bem longe de terminar, o foco da inovação no contexto da Westinghouse esta bem localizado na criaçao de novos serviços que podem ser prestados para os atuais clientes e tb em novos serviços para clientes que possuem produtos da concorrência. O processo começou escolhendo os melhores gerentes e alocando eles como “Growth Leaders” com a atribuição exclusiva de buscar novas oportunidades e tecnologias, eles tem a liberdade de conversar com todas as áreas da empresa em busca de novas idéias que separadas nao valem muito mas juntas podem formar um serviço novo e diferenciado.

Na verdade o que mais me chamou a atenção na matéria foi a seguinte frase:

If you only do what you know and do it very, very well, changes are that you won’t fail. You’ll just stagnate, and your work will get less and less interesting, and that’s failure by erosion. True failure is a mark of accomplishment in the sense that something new and different was tried.

Isso tem tudo a ver com a nossa industria e nós já sabemos isso de cor, a construção de software passa sempre por falhar, aprender com os erros e melhorar (PDCA), mas nunca tinha lido nada do gênero com uma industria tão peculiar quanto a de energia nuclear. O que reforça mais uma vez que ter a atitude de tentar coisas novas é uma caracteristica cada vez mais importante em qualquer profissional em qualquer ramo de trabalho.

Nas últimas semanas, venho conversando muito com o Guilherme e com a Patricia Fontes (nossa Product Owner nos projetos de vídeos da Globo.com) sobre estas questões de relacionamento entre Time, ScrumMaster e PO, até onde vai o papel de cada um. Nas nossas conversas geralmente temos pontos de vistas diferentes e as vezes opostos, mas o resultado destas conversas tem sido muito enriquecedor, pelo menos para mim. No final de cada conversa sinto que estamos mais unidos e concientes de onde queremos chegar e sempre que discutimos tentamos manter como nossa referência o que é a melhor solução/decisão/atitude para os produtos que estamos construindo.

O Phillip Calçado também fez um post onde coloca o seu ponto de vista sobre ter um SM que também é um líder técnico. Neste post dele gosto muito da frase:

Quem assume que isso é uma verdade absoluta está buscando respostas fáceis ao invés de tentar resolver o problema. Isso não é diferente em nada do cidadão que usa todos os templates, artefatos e papéis do RUP no seu projeto, ou daquele que acredita que um selo como CMMI ou MPS.BR traz qualidade.

E replicando meu comentário no blog do Phillip, para mim não existem verdades absolutas, e sim evolução e aprendizado contínuo, aprendizado quer dizer que erramos e acertamos em ciclos infinitos, e se estivermos no caminho certo, mais acertamos do que erramos, e estes erros que cometemos não deveriam se repetir.

“There are two different types of programmers. Some like to code for months or even years, and hope they will have built the perfect product. That’s castle building. Apple is great at it. Others prefer to have something working at the end of the day, something to refine and improve the next day. That’s what we do. The hardest part about indoctrinating people into our culture is when engineers show me a prototype and I’m like, ‘Great, let’s go!’ They’ll say, ‘Oh, no, it’s not ready.’ I tell them, ‘The Googly thing is to launch it early on Google Labs and then to iterate, learning what the market wants–and making it great.’

Some companies think of design as an art. We think of design as a science. It doesn’t matter who is the favorite or how much you like this aesthetic versus that aesthetic. It all comes down to data.”

Eu definitivamente penso em desenvolvimento de produtos com esta filosofia, (apesar de recentemente começar a gostar muito dos produtos Apple:-) acredito muito na premissa que li em uma entrevista do J Allard (head de games da Microsoft e responsável pelo projeto do Xbox) “if it’s a possibility that you may fail, then fail fast and learn“. Desenvolver produtos rapidamente e colocar estes na rua para que possamos pegar o feedback dos usuários o quanto antes e se for necessário fazer ajustes e incrementar mais features ou retirar features que não atendem as demandas dos usuários, é neste metodo mais “Googly” que eu acredito, desenvolvimento continuo e iterativo, com melhoria contínua e constante.

Ficar sentado em cima de um problema pensando anos como resolvê-lo da forma perfeita definitivamente não faz o meu tipo.

Para finalizar mais uma frase Googleneska da matéria, agora de um dos diretores de engenharia David Glazer, responsável pelo desenvolvimento do OpenSocial:

“…When in doubt, do something. If you have two paths and you’re not sure which is right, take the fastest path. What’s true in physics about objects in motion is true when you’re creating a product. It’s easier to keep moving and change course than when you’re sitting and thinking and thinking.”

A próxima meta é escalar o SCRUM para toda a empresa, enquanto estava lendo sobre o assunto acabei me desviando e cai em alguns artigos muito interessantes que discutiam um tema que afeta todo e qualquer projeto de desenvolvimento de software: como estimar com precisão o tempo total para se entregar um software em produção?

Acabei caindo na teoria do Cone da Incerteza, que explica o fenômeno onde nós da indístria de software quando iniciamos um novo projeto não fazemos a menor idéia de quando vamos terminá-lo. Quanto mais o tempo passa e mais perto do fim melhor e mais preciso são as nossas estimativas, ou seja, isso culmina na conclusão de que você só tem 100% de certeza de que terminará o projeto apenas um dia antes de efetivamente terminá-lo.

Esta figura é facilmente associada ao desenvolvimento de um software, ou seja, se começa um projeto sem ter a menor idéia do tamanho dele ai vai se detalhando, escreve-se montanhas de papel com requisitos, desenha-se milhões de telas no Photoshop para fechar o design do projeto, ai finalmente depois de alguns meses é que se começa a escrever software efetivamente. Nestes casos existe uma luta constante para afunilar o cone o mais rápido possível. O grande erro das empresas é fazer um “commitment” com um projeto quando ele esta nas suas etapas iniciais, ao fazer isso elas estão aceitando uma margem de erro de 2x ou 4x nas estimativas, e é neste momento que o projeto começa a ruir.

O que é interessante em metodologias ágeis, como o SCRUM por exemplo, é que podemos observar este fenômeno invertido, explicando melhor, se vc perguntar a um desenvolvedor que já esta envolvido em um projeto o que ele consegue entregar nas próximas duas semanas a estimativa com certeza será bem precisa, mas se perguntarmos o que ele consegue entregar daqui a 6 meses, não fará a menor idéia e vai chutar uma estimativa qualquer pois não há como ter certeza do que irá acontecer. A única certeza que podemos ter em qualquer projeto de software é de que as coisas vão mudar, os requisitos, o design, as funcionalidades e o grande trunfo dos métodos ágeis é de entregar software funcionando em ciclos constantes e curtos e com isso se adaptar as constantes mudanças.

Então em um ambiente ágil temos sempre mais certeza sobre as estórias que estão priorizadas para o próximo sprint ou estamos trabalhando neste momento e vamos melhorando nossas estimativas e aumentando a precisão delas conforme o Product Backlog vai sendo entregue, mas sempre com uma visão muito clara do curto prazo e menos clara para o que esta no fim do Product Backlog. Lembrando que as estórias que estão sendo desenvolvidas no Sprint são as de maior ROI para o projeto.

Sendo assim o Cone de Incerteza aplicado a uma equipe que utiliza SCRUM teria este formato: