Falando em Agile 2008

Esta semana vou fazer uma palestra no Falando em Agile 2008, evento organizado pela Caelum do Paulo Silveira e do Alexandre Magno. Esta é a primeira edição deste evento com foco em agilidade e processos de desenvolvimento de software, um assunto cada vez mais recorrente no nosso dia a dia e tema constante em todos os eventos relacionados a tecnologia que participo e leio a respeito.

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á!

Distância ainda é importante

Eu não sou muito a favor do uso de ferramentas eletrônicas no gerenciamento de projetos tocados por equipes ágeis, no entanto, até o momento não tivemos que lidar com grandes distância entre membros de um mesmo time ou entre times na Globo.com. Existem diversas ferramentas digitais que se propõem a ajudar os times que estão distantes, a estruturar melhor a informação, gerar relatórios gerenciais e por ai vai. Algumas destas ferramentas são por exemplo o Mingle da Thoughtworks, o VersionOne, o Jira com Greenhopper entre outros, vc pode ver uma lista mais extensa dessas ferramentas no blog do Wayne Allen.

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.

O perigo do mini-waterfall em times ágeis

Hoje estou finalmente tirando o atraso do meu Google Reader e lendo alguns artigos e posts sobre Scrum e Agile development, me deparei com uma excelente iniciativa do Mark Levison chamada Agile/Scrum Smells (baseada em um projeto do Mike Cohn) com o objetivo de catalogar os principais problemas encontrados durante a implantação e dia-a-dia de práticas ágeis, em especial práticas ligadas ao SCRUM.

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.

O ScrumMaster e seu papel

O Guilherme Chapiewski escreveu um post esta semana bem polêmico e a discussão esta correndo solta no Blog. O ponto é, até onde vai o papel do ScrumMaster quando este pode ajudar o time resolvendo, quando possível, impedimentos técnicos ou discutindo uma dada solução técnica.

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.

Agile na SD West 2008

Como alguns de vcs sabem estou nos Estados Unidos nesta semana, tivemos algumas reuniões em San Francisco com a ADOBE, onde vimos algumas das novidades que vão acontecer durante 2008 e inicio de 2009 nas plataformas da empresa.

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.