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.

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.

As metodologias ágeis tem tudo a ver com o TPS (Toyota Production System) e sempre que alguém fala de formas ágeis de desenvolvimento acaba citando a Toyota como uma das criadoras destes princípios. Na verdade o link entre estas duas coisas vem do fato de que a Toyota foi uma das grande empresas que começaram a empregar o Lean Thinking na década de 1970, nas palavras de Taichi Ohno um dos criadores do TPS, o foco da Toyota era “the absolute elimination of waste, where waste is anything that prevents the value-added flow of material from raw material to finished goods”.

Esse é o grande foco das metodologias ágeis em relação aos processos em cascata (waterfall), eles são focados no valor adicionado pelo desenvolvimento seguindo os principios constantes no Agile Manifesto.

Enfim, este paper do Boris é uma leitura simples, rápida e fácil e que ajuda a enriquecer um pouco mais nossa cultura sobre SCRUM e suas origens.

Aqui esta o link para o paper: Scrum Delivers or Scrum and the Toyota Way.

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.

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.

Em seguida, vim para Santa Clara para participar da SD West 2008, um evento com diversos tracks legais e super sintonizados com o momento de transição que estamos passando na Globo.com, particularmente estou assistindo a maioria das apresentações do track chamado People, Process and Methods, onde são discutidas práticas ágeis de gerenciamento do desenvolvimento do Software, como o SCRUM, Crystal Clear e XP entre outros assuntos. Hoje assisti várias palestras e aproveitei para tirar algumas dúvidas com uns dos maiores nomes do mundo Agile, como Mike Cohn, Alistair Cockburn, Paul Hodgetts entre outros.

Na primeira palestra que participei foi a “Agile Transitions“, que na verdade foi um round de discussão de como realizar a mudança para uma metodologia ágil, independente de qual vc estaria interessado. Foi muito bom ver que grande parte das perguntas feitas eu consegui responder corretamente, o que mostra que estamos avançando no quesito de conhecimento sobre práticas ágeis. Uma das perguntas que fiz foi a respeito de qualidade versus número de features, justamente perguntando se na situação onde o time vê a necessidade de melhorar a qualidade do software criando uma estória de refactoring , por exemplo, é correto dropar uma feature e escolher a qualidade?

A resposta foi em linha com o que pensava, todos foram categóricos com o fato de que com qualidade não se discute e que isso é uma decisão do Time juntamente com o PO, mas que o PO precisa entender o que esta em jogo e o que se ganha ao realizarmos um refactoring ou automatizar um teste que na maior parte das vezes é muito sutil, porque só se percebe o Technical Dept quando ele já esta muito alto e coloca o projeto todo em risco, é função do Time mostrar este valor para o PO.

Na segunda palestra Prioritizing Requirements, com Mike Cohn, foram apresentadas técnicas de priorização do Product Backlog, em resumo é possível dividir estas técnicas em dois grupos: Financeiras e as Não-Financeiras. Na parte de técnicas financeiras nenhuma grande novidade, ele falou bem superficialmente sobre NPV, FV, IRR, etc. Mas na parte de técnicas não-financeiras achei interessante o Método de Kano e tb o reforço no método do Beneficio Relativo. Para saber mais sobre este assunto leia o livro do Mike “Agile estimating and planning“.

A terceira palestra foi sobre o Crystal Clear, ministrada pelo Alistair Cockburn (Lê-se Co-burn), onde ele apresentou um overview sobre a metodologia Crystal, que em resumo tem os seguintes propriedades:

• Frequent Delivery
• Reflective Improvement
• Close Communications

Estes principios todos são muito comuns a diversas metodologias ágeis, mas este último tópico (Close Communications) foi muito interessante, onde ele discutiu e mostrou alguns papers como este aqui da Universidade de Michigan chamado Distance Matters, onde é provado que quanto mais proximos estão os membros de um time melhor é o rendimento e a qualidade e por consequencia o retorno sobre o investimento.

A última apresentaçao que fui, ministrada por um consultor da Net Objectives, não teve grandes novidades, mas foi muito interessante para ajudar a verificar como podemos estruturar o conteúdo sobre SCRUM para os nossos treinamentos internos para os Team Members.

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:

Neste ano continuamos este trabalho de formação dos profissionais da Globo.com, porém este novo round de treinamentos foi focado em um dos principais papéis dentro do SCRUM, o Product Owner (PO) e também na formação de Trainers, que realizarão os treinamentos internos para as equipes que passarão a usar SCRUM este ano.

The Scrum roles
© Copyright Conchango 2006

Apenas relembrando o papel do PO, ele é o responsável pelo Retorno do Investimento (ROI) do projeto, cabe a ele priorizar os itens no Product Backlog (PB) de forma a obter o maior retorno possível, entre as suas responsabilidades estão:

• Criar a visão
• Manter o PB estimado e priorizado
• Priorização do PB, com pelo menos 3 Sprints
• Criar as fronteiras (boundaries) que protegem o Time (Tempo, Orçamento, Visão, Padrões, etc)
• Criar um Release Plan do Produto
• Ser a interface de comunicação com os stakeholders, e outros clientes internos e externos
• Ajudar o ScrumMaster a proteger o Time
• Aceitar ou rejeitar uma funcionalidade no Sprint Review

O PO é quem deve criar a visão, mas esta deve ser compartilhada e refinada com o Time, pois é o time que deve se sentir motivado e desafiado por aquela visão. A visão deve ter algumas características básicas como: ser emocional (criar desejo), deve ser clara e concreta e deve ser difícil de alcançar.

O Product Backlog (PB) é responsabilidade do PO, mas quem deve escrever as user stories é o Time, pois este é que vai executar o Sprint Backlog e se comprometerá em entregar estas user stories, claro que o PO pode ajudar a escrevê-las, mas apenas se o time deixar. Antes deste treinamento eu achava que o PO é quem deveria escrever as user stories. É importante lembrar que o PB é formado por um misto de user stories detalhadas e estimadas e um conjunto de idéias mais amplas e sem muitos detalhes, que serão refinadas e devidamente transformadas em user stories no decorrer do processo. O Time é o responsável por estimar a complexidade das user stories, atribuindo pontos de dificuldade para cada uma delas, que chamamos de Story Points.

É importante ter pelo menos 3 Sprints priorizados e estimados, para que o time não fique “idle” na transição entre um Sprint e outro, recentemente passamos por uma situação assim na entrega de um dos releases do Globo Vídeos, por não ter um PB detalhado e priorizado o time teve de esperar alguns dias para iniciar o Sprint seguinte.

The ScrumFlow

No decorrer de cada Sprint é preciso iniciar os trabalhos de estimativa e planejamento do próximo Sprint, é uma boa prática alocar de 10% a 15% do tempo do Sprint corrente para planejar e detalhar o próximo Sprint. É responsabilidade do PO chamar as reuniões de planejamento e detalhamento dos Sprints (não confunda estas reuniões com o Sprint Planning 1 e 2) e de manter pelo menos 3 Sprints planejados e priorizados, se o PO não realizar estas reuniões o ScrumMaster deve chamar a atenção do PO e em casos extremos assumir esta responsabilidade temporariamente. Cada reunião de planejamento não deve durar mais do que 60 minutos (Timebox) e tem como objetivo manter todos no Time informados sobre possíveis mudanças nas user stories e ajustes de prioridades, além de aumentar a precisão das estimativas feitas anteriormente.

Abaixo segue uma proposta de planejamento para um backlog hipotético que entrega um release a cada 10 dias úteis, aqui vai uma dica do Boris, nunca fazer o Sprint Planning 1 e 2 em uma Segunda-Feira ou depois de um feriado, porque é preciso que todas as partes envolvidas estudem o backlog e se preparem com antecedência para estas reuniões e todos nós sabemos que é muito difícil alguém se planejar durante um final de semana ou feriado. Sendo assim a agenda ficaria assim:

• Segunda-Feira (tarde): Sprint Review e Sprint Retrospective
• Terça-Feira (manhã): Entrega do Release
• Terça-Feira (tarde): Sprint Planning 1 e Sprint Planning 2
• Quarta-Feira: Inicio do Próximo Sprint
• Mais ou menos dois dias depois do inicio do Sprint deve-se marcar uma reunião de planejamento e estimativa do próximo Sprint.
• Mais ou menos dois dias antes do final do Sprint deve-se marcar outra reunião de estimativa do próximo Sprint.

Uma vez escritas e estimadas as user stories o PO deve priorizar o PB, no treinamento aprendemos uma técnica interessante chamada de Relative Benefit. Ela funciona assim: para cada item do Backlog atribui-se um valor para o Beneficio de se ter aquela funcionalidade (variando de 0 a 10) e um valor para Penalidade de não se ter aquela funcionalidade entregue, depois somam-se estes valores e o resultado chamamos de Business Value (BV). Agora dividimos o BV pela Estimativa, que reflete a dificuldade/complexidade para se entregar aquela determinada funcionalidade, por fim o PO reordena o Backlog com base neste resultado, do maior para o menor valor.

Por exemplo, no Backlog acima temos a feature 1 que possui um beneficio baixo (1) , uma penalidade alta(9) e uma complexidade baixa(2), sendo assim o beneficio relativo desta funcionalidade é alto (5) quando comparado relativamente com os outros itens do Backlog. Esta técnica também ajuda a priorizar itens com o mesmo BV, como é o caso da feature 1 e 5, neste caso vemos que a feature 5 possui um Beneficio igual a 5, maior que o beneficio da feature 1. Seguindo este método PB acima ficaria priorizado da seguinte forma:

1. Feature 5
2. Feature 1
3. Feature 3
4. Feature 4
5. Feature 2

Esta é uma técnica muito simples que ajuda a dar uma base concreta para comparação entre as funcionalidades e assim, priorizar corretamente o PB, claro que cada caso é um caso e vão acontecer situações onde um diretor vai pedri prioridade de uma determinada funcionalidade, mas esperamos que esta seja uma exceção e não a regra.

Mas uma das mensagens mais importantes do treinamento foi com relação ao papel do PO de proteger e respeitar o Time, este é uma papel que geralmente o PO não assume e pior, como os PO’s geralmente tiveram uma experiência passada em áreas de marketing ou gerência de produtos , eles tendem a achar que a equipe de tecnologia é devagar e não tem compromisso com o produto e sempre tentam empurrar mais e mais funcionalidades pra cima do time. Isso é natural principalmente nos processos waterfall, mas em um ambiente de utiliza Scrum, esta postura do PO não pode ser aceita. Ele não deve pressionar o time para inserir mais coisas no sprint, o time é que escolhe do PB priorizado o que se compromete a entregar com qualidade até o fim do Sprint. Caso o PO entenda que o time pode entregar mais do que esta entregando, ele deve conversar com o ScrumMaster, pois a produtividade do time é um problema que o ScrumMaster deve resolver. Ao tentar empurrar mais do que o time pode entregar com qualidade, o PO começa a quebrar sua relação de confiança com o time, e o ScrumMaster deve intervir e lembrar o PO de que ele também deve proteger o time.