O evento está sendo organizado por mim (Guilherme Chapiewski) em parceria com o meu amigo Henrique Bastos e a realização está sendo coordenada pelas nossas experientes amigas da Arteccom (e tê-las ao nosso lado já garante que este será um evento para marcar o circuito carioca).

Nossa programação conta com três palestrantes nacionais e três internacionais falando sobre Open Source, Java, Ruby on Rails, Django e desenvolvimento ágil de software:

“O molho secreto”: como as comunidades do Joomla! e Open Source estão melhorando o cenário de tecnologia… e mudando o mundo! Ryan Ozimek é atual membro do Steering Committee da Open Source Initiative, membro da diretoria da Open Source Matters e co-fundador e CEO da PICnet Inc. Com enfoque em tecnologias open source, Ozimek está constantemente a procura de formas em que a Internet possa servir melhor o “bem maior” e, mais especificamente, as entidades sem fins lucrativos.

O Java está morto? Guilherme Silveira é especialista em Java para a web e graduando em matemática computacional na USP, ministrou diversas palestras relacionadas ao tema em eventos e empresas pelo Brasil. Atualmente é commiter do CodeHaus pelos projetos XStream e Waffle, além de um dos responsáveis pelo desenvolvimento do VRaptor.

Nico Steppat é Engenheiro da Computação Aplicada na Fachhochschule Brandenburg na Alemanha, é instrutor, consultor e desenvolve há cinco anos com Java no Brasil e Alemanha, atuando agora na Caelum com enfoque especial em EJB. É o responsável técnico no Rio de janeiro. Escreve para a revista MundoJava e possui as certificações SCJP, SCWCD, SCBCD e SCEA.

Ecossistema Ruby on Rails Fabio Akita é Gerente de Produtos de Hospedagem na Locaweb e ajudou a implantar Ruby on Rails pela primeira vez num grande hosting no Brazil. Ano passado também organizou o Rails Summit Latin America, o primeiro grande evento de Rails na América do Sul. Trabalhou na consultoria americana Surgeworks LLC, prestando serviços relacionados a projetos Ruby on Rails, com o cargo de Brazil Rails Practice Manager.

Django: o framework web para perfeccionistas com prazos Jacob Kaplan-Moss é um dos líderes de desenvolvimento e co-criador do Django. Jacob é um desenvolvedor de software experiente com foco em desenvolvimento de aplicações web e arquitetura de gerenciadores de conteúdo. Em 2005, Jacob ingressou no Lawrence Journal-World, um jornal local em Lawrence, Kansas, e ajudou a desenvolver e tornar open source o projeto Django. É também co-autor do livro “The Definitive Guide to Django” (Apress, 2007).

Desenvolvimento ágil e iterativo de produtos Jeff Patton cria e desenvolve software nos últimos 15 anos desde sistemas de pedidos de peças de aeronaves até fichas médicas eletrônicas. Jeff se focou em metodologias ágeis desde que trabalhou com um time de Extreme Programming em 2000. Em particular, Jeff se especializou na aplicação de práticas de user experience design (UX) para melhorar requisitos ágeis, planejamentos e produtos. Desde 2007, Jeff tem aplicado Lean thinking e práticas de desenvolvimento com Kanban e Scrum para ajudar times a focarem na entrega de valor.

Para fechar com chave de ouro, no encerramento do evento faremos um bate-papo com os palestrantes, alguns membros das comunidades de desenvolvimento e a participação especial do meu amigo Vinicius Teles!

Como se isso tudo já não fosse suficiente, enquanto todas essas apresentações estão acontecendo teremos sessões de Coding Dojo rolando do lado de fora com participação especial dos nossos palestrantes (caso eles consigam ficar por lá)! Estamos planejando fazer um Dojo de Python, um de Ruby e um de Java!

Será simplesmente incrível, ninguém pode ficar de fora dessa!

As inscrições podem ser feitas no site do evento (http://www.devinrio.com.br) e custam apenas R$ 65,00. Todos os inscritos terão direito a participar de todas as sessões, incluindo o Dojo.

Nosso encontro será numa segunda-feira, ou seja, se você não for do Rio de Janeiro já tem uma ótima desculpa para passar o fim de semana aqui, assistir uma ótima conferência na segunda-feira e voltar para o trabalho cheio de idéias na terça!!! Ainda estamos tentando fechar uma parceria com algum hotel para oferecer desconto para participantes do evento. Fiquem ligados nas novidades por aqui ou pelo Twitter!

Gostaria de deixar registrados meus sinceros agradecimentos para os nossos patrocinadores Locaweb e Caelum, além de outras organizações que nos apoiaram de alguma forma: Associação Python Brasil, Fábrica Livre, Open Source Matters e Myfreecomm. E por último, meu mais sincero agradecimento para a Globo.com pois ela é a principal responsável por viabilizar essa idéia! Obrigado por mais uma vez acreditarem nesse louco aqui tarado por desenvolvimento de software! Não tenho palavras pra dizer o quanto é gratificante fazer parte dessa equipe!

Então nos vemos no Dev in Rio 2009! Faça agora sua inscrição no nosso site! Fique ligado também no Twitter do @devinrio para concorrer a inscrições gratuitas!

Ah, e uma última coisa. Por favor, nos ajudem a divulgar o evento! Falem com seus amigos, postem nos seus blogs, Twitters, coloquem nossos banners nos sites de vocês, enfim, por favor nos ajudem a divulgar esse evento! Vamos fazer barulho no Rio de Janeiro!

Inspirado no livro Scrum and XP from the Trenches do Henrik Kniberg, Robert Galen está escrevendo um novo livro entitulado Becoming a Great Scrum Product Owner, disponível para download em PDF no seu site. O livro ainda é um draft e sua cópia/impressão/distribuição ainda não são permitidos, porém pelo pouco que já li estou percebendo que é um excelente material e que deve preencher um espaço muito importante na literatura de Scrum. E o mais legal é que claramente várias das coisas que estão escritas são fruto da experiência prática do autor e não apenas um monte de teorias.

Recomendo muito muito fortemente a leitura, especialmente se você for um P.O., quiser ter um time de sucesso e quiser ser um profissional de sucesso!

Oi Guilherme, tudo bom?

Eu tenho uma curiosidade, como vcs aí da Globo fazem quando no Scrum um item que teve pontuação baixa na reunião de planning (algo como 3 ou 5) na realidade é um abacaxi de 40, 50?

De acordo com a mecânica do Scrum, no Sprint Planning o time e o P.O. definem juntos um objetivo para a próxima iteração, que é o Sprint Goal (um exemplo de goal seria “prover serviços para que um usuário possa despublicar seus vídeos do site”). Após a definição do Sprint Goal, é selecionada uma porção do Product Backlog para que esse objetivo seja atendido.

A partir daí você tem o Sprint Backlog, que é o conjunto de histórias que serão trabalhadas no próximo Sprint.

Se no meio de um Sprint você percebe que uma dessas histórias é um monstro 10 vezes maior do que parecia, você pode fazer uma das duas coisas:

1) Se essa história puder ser removida sem afetar o Sprint Goal, basta tirar a história do Sprint. É importante no entanto que se descubra as causas disso ter acontecido (pode ser na Sprint Retrospective) para que não aconteça novamente. As estimativas têm uma margem de erro implícita, mas quando alguma coisa multiplica tantas vezes assim de tamanho pode ser que o time não esteja conversando o suficiente sobre as funcionalidades antes de estimar. Muita gente fala inclusive que o principal produto de uma reunião de estimativas não são as estimativas em sí, mas o conhecimento que o time adquiriu discutindo sobre os problemas.

2) Se essa história for fundamental para atender ao Sprint Goal, o Sprint deve ser cancelado e um novo Sprint Planning deve ser feito. Se você não pode trabalhar na coisa que adiciona mais valor para o projeto, ou seja, uma história que atende diretamente ao goal definido junto com o P.O., é preciso fazer um novo planejamento para descobrir no que trabalhar. No Sprint planning pode-se decidir várias coisas, desde quebrar essa história em histórias menores até descobrir que dada a nova estimativa o custo-benefício da história não vale a pena e ela deve perder a prioridade no backlog.

Por isso é muito importante ter objetivos muito bem definidos. Um bom Sprint goal ajuda o time a se reorganizar em caso de problemas, além é claro de ajudar a focar no que é mais importante para o projeto no momento.

No mais, recomendo a leitura dos capítulos 3.5 e 3.6 do Agile Software Development with Scrum que falam sobre a definição do goal no Sprint Planning e a mecânica dos Sprints, incluindo uma parte sobre cancelamento de Sprints.

Depois, com o Scrum, acabamos criando um time um pouco maior (de aproximadamente 9 pessoas) e, pela força do hábito, várias vezes nos pegamos com vontade de trabalhar em dois ou três projetos ao mesmo tempo. Talvez dê vontade de fazer isso para ter a impressão de que as coisas estão acontecendo, mesmo que lentamente, e que os projetos estão andando… Mas será que isso vale a pena? Vejamos.

Um dos principais objetivos do Scrum é entregar o maior valor de negócio para o cliente no menor tempo possível. Quanto mais dinheiro o cliente puder ganhar e quanto mais rápido, melhor. Sendo assim, o P.O. sempre deve pensar na melhor forma de maximizar o ROI – retorno sobre o investimento.

Falando de forma simplificada, o retorno sobre o investimento é calculado da seguinte forma: se você investe R$ 100,00 em alguma coisa e no final de um período você ganhou R$ 50,00 por conta deste investimento, você teve 50% de ROI. Sendo mais prático, quando você paga alguém para desenvolver um sistema para você, se você gastar R$ 100.000,00 e ganhar R$ 10.000,00 por mês, você está tendo um ROI de 10% por mês. Neste cenário o sistema se pagará em 10 meses, e a partir daí você passa a ter lucro.

Dito isso, vamos pensar numa situação hipotética. Imagine que um time de Scrum está trabalhando em 3 projetos ao mesmo tempo. Constata-se que no fim de 3 meses o time consegue finalizar e colocar em produção todos os 3 projetos:

Para conseguir entregar esses 3 projetos, o time teve que trabalhar paralelamente em todos eles, usando sempre 1/3 do tempo de cada Sprint para cada um dos projetos. Desta forma só depois de 3 meses o cliente poderia começar a faturar com seus novos produtos.

A pergunta é: não seria muito melhor se o time tivesse trabalhado de forma serial, focando todo seu tempo e esforço em apenas um projeto e entregando uma coisa de cada vez?

Trabalhando dessa forma, no fim do primeiro mês o primeiro projeto já poderia entrar em produção, antecipando o faturamento, gerando dinheiro (ROI) para o cliente mais rápido e diminuindo o tempo necessário para recuperar seu investimento. Neste caso, a antecipação da entrega de um dos projetos faz com que o cliente comece a faturar 2 meses antes do que poderia – sem dúvidas o ROI foi maximizado.

Voltando ao ponto inicial, é preciso resistir à tentação de querer trabalhar em vários projetos ao mesmo tempo. O melhor é focar no mais importante deles (ou seja, o que vai gerar mais lucro para a empresa) e trabalhar nele até o fim, passando em seguida para o próximo projeto mais importante e assim por diante.

Nossa história no início foi bem parecida com as histórias tradicionais. Sabe aquelas empresas que gastam uma semi-fortuna com uma consultoria para desenhar um processo de desenvolvimento de software? Assim estávamos nós no início de 2007. Poucos projetos eram entregues nas datas acordadas e muitos deles falhavam ou não satisfaziam as necessidades dos clientes. Contratar uma grande consultoria de software parecia ser uma boa tentativa de arrumar as coisas, mas o resultado do trabalho foi um documento que descrevia um processo com algumas centenas de páginas que devia ser seguido á risca, isso sem contar as dúzias de documentos padrão para todos os tipos de requisição e comunicação que se possa imaginar. Dezenas de páginas descreviam quem deveria falar com quem e quem entrega qual documento em qual momento. O processo foi feito para lidar com todas as complexidades, burocracias e exigências que nós mesmos criamos dentro da empresa.

Resumindo a história, isso não funcionou na Globo.com e acho que existem poucas chances de algo tão complexo assim funcionar em algum lugar. E por incrível que pareça, no fim das contas ninguém havia pensado em nada para resolver o problema principal: como entregar o software que nossos clientes querem no menor tempo e com a maior qualidade possível?

Um pouco de história

Ao contrário do que acontece em muitas empresas, as metodologias ágeis na Globo.com vieram de baixo para cima. Tudo começou com um movimento tímido entre alguns desenvolvedores de aplicar práticas de desenvolvimento ágil do XP (Extreme Programming) nos projetos. A porta de entrada foi a oportunidade de melhorar a qualidade dos nossos sistemas, pois tinhamos uma incidência muito grande de bugs em produção e poucas aplicações eram testadas adequadamente.

Alguns desenvolvedores mais experientes começaram a desenvolver usando desenvolvimento guiado por testes (TDD), e com isso houve uma melhora nítida na qualidade do que era entregue. Aos poucos, enquanto isso acontecia, algumas seções de programação em par aconteciam de vez em quando para difundir o conhecimento e ensinar a técnica a outros programadores, mas ainda de forma muito tímida e sutil (afinal às vezes é difícil convencer que dois programadores fazendo apenas um código é uma coisa boa).

Em seguida foi a vez de organizar as demandas de clientes e os ciclos de desenvolvimento. Lembro-me de ter colocado nessa época o mesmo software em produção quatro vezes em duas semanas, e depois disso o mesmo software foi trabalhado durante dois meses para só depois poder ir novamente para produção. Para piorar, nossos clientes nos traziam todo tipo de demanda que se pode imaginar, sempre em lotes e com prioridade máxima. Por exemplo, acontecia frequentemente do mesmo cliente demandar cinco coisas e todas elas com máxima urgência. Resumindo, os ciclos de planejamento, desenvolvimento e entrega eram totalmente irregulares e afetavam o desempenho de toda a equipe. Explicando todas as dificuldades que tinhamos para nos organizar nesse caos, conseguimos acordar que fariamos entregas constantemente de duas em duas semanas, e que dentro desse período não haveria nenhuma mudança no planejamento, que seria feito no início de cada período. Antes de iniciar cada ciclo de desenvolvimento, os clientes tinham a oportunidade de escolher quais seriam as prioridades da equipe de desenvolvimento nas duas semanas seguintes. Sem perceber eles haviam aceitado a idéia de desenvolvimento iterativo e jogo do planejamento, e nós teriamos alguma organização e paz para fazer o trabalho.

Em meados de Julho de 2007 a empresa decidiu bancar um curso de Scrum com o Boris Gloger para alguns membros da nossa equipe e o resultado foi ótimo! Na semana seguinte mesmo já começou a mudança. Todos voltaram com um novo gás e dispostos a mudar a empresa. Me lembro de nessa época alguém ter falado a seguinte frase: “Agora eu acredito em desenvolvimento de software”.

Desse momento em diante passamos a aplicar Scrum no nosso time de desenvolvimento. O problema é que estávamos no meio de um projeto feito da forma “tradicional” (leia-se waterfall) e toda a fase de análise e especificação já tinha sido concluída. Tudo indicava que seria melhor esperar uma oportunidade melhor para começarmos a adoção, só que nós sabiamos que tinha que ser “naquela hora ou nunca” e então começamos a desenvolver nosso principal projeto usando práticas do Scrum.

Quase ninguém na equipe havia trabalhado com desenvolvimento ágil, então achamos que seria mais fácil não falar de Scrum, XP ou qualquer nome diferente. Simplesmente começamos a praticar e durante o desenvolvimento o time foi introduzido às práticas e à forma de trabalhar. As regras são muito simples e por isso foi muita fácil de adotá-las. Ao longo dos cinco Sprints o time foi amadurecendo, entendendo como trabalhar e também foram nascendo algumas adaptações necessárias ao funcionamento do projeto dentro da estrutura da empresa. Por exemplo, tivemos que resolver como seriam criadas as histórias e como isso seria integrado com o nosso sistema de tracking, como integrar com a equipe de QA, como colocar os projetos em produção e diversas outras questões. O Phillip falou bastante sobre essa fase introdutória no seu blog no ano passado.

Hoje, o Globo Vídeos 4.2, que é o tal projeto, está em produção. Para os padrões da empresa na época, ele foi um projeto surpreendente do ponto de vista de qualidade. Na versão anterior do Globo Vídeos (4.0) foi necessária uma janela de mais de 24 horas para colocá-lo no ar e ela aconteceu aos trancos e barrancos. Além disso a semana seguinte foi infernal, com muitos bugs para serem corrigidos e várias mudanças arriscadas durante o dia para corrigi-los. Já a versão 4.2 foi colocada em produção em pouco mais de uma hora e na primeira semana nem ouviamos falar do Globo Vídeos. Nem parecia que um dos sites de maior audiência da empresa havia sido quase totalmente substituído por um totalmente novo e com grandes mudanças arquiteturais!

Ao mesmo tempo que acontecia o Globo Vìdeos, o site de inscrições para o Big Brother Brasil 8 foi desenvolvido de cabo a rabo usando Scrum, da forma estrita, como está nos livros. O projeto simplesmente não teria sido feito considerando-se a complexidade e o tempo disponíveis. No final, ele foi um sucesso e além de ter sido entregue no prazo houve uma percepção de muita qualidade por todos – mais uma prova viva de que o Scrum era uma possível resposta para os nossos problemas. O Danilo inclusive fez uma apresentação sobre esse projeto na semana passada num evento do C.E.S.A.R. em Recife.

Esses dois projetos serviram de aprendizado e base para a estruturação de todos os projetos seguintes na empresa. O sucesso deles foi o grande responsável para ganharmos carta branca e começarmos a implementação de Scrum em massa na Globo.com.

Como estamos hoje

Após um ano de metodologias ágeis a empresa já está bem mais madura nas práticas e já temos mais de 10 times usando Scrum.

No fim do ano passado, após um treinamento para pessoas de todas as áreas da empresa, começamos todos a usar Scrum da forma estrita (obviamente houve uma curva de aprendizado até todos estarem mais seguros e praticando melhor). Hoje, alguns meses depois, já é possível perceber diferenças entre alguns times, que acabaram se adaptando de forma diferente por terem problemas e questões diferentes.

Sobre a duração dos Sprints, estamos trabalhando com duas semanas porque achamos que quatro semanas é muito tempo e poderiamos acabar nos tornando lentos na resposta às mudanças. Além do mais já vinhamos usando iterações de duas semanas desde que começamos a adotar desenvolvimento iterativo e continuar com este tamanho de ciclo seria mais fácil para nós.

Em virtude disso, como temos a metade do tempo de desenvolvimento recomendado pelo Scrum, decidimos que só precisamos da metade do tempo de planejamento. A recomendação é que o Sprint Planning tenha 8 horas para um Sprint de 4 semanas, e como nosso Sprint é de 2 semanas decidimos fazer um planning de 4 horas. As outras reuniões (Sprint Review, Retrospective, Daily Scrum, etc) permaneceram com a mesma duração, lembrando que essa duração não é obrigatória mas sim um limite para não ficarmos discutindo as coisas indefinidamente.

Nossos Sprint Plannings têm melhorado constantemente. No início sempre estouravamos o tempo da reunião discutindo um monte de coisas que não eram necessárias mas agora já estamos mais focados e a reunião tem funcionado bem melhor. As estimativas com planning poker também evoluiram um bocado e em várias ocasiões todos os desenvolvedores colocam o mesmo número sem combinar, o que indica que estamos evoluindo na sensação de esforço necessário para desenvolver as coisas.

A equipe, que antes era só de desenvolvedores, agora tem também um designer, um arquiteto de informação, um especialista em programação client-side (JavaScript/CSS/HTML), uma pessoa da equipe de testes e homologação e uma pessoa focada em negócios e ROI (que é o Product Owner). Todas essas pessoas sentam próximas umas das outras, e isso efetivamente aumentou muito a produtividade delas e o ritmo do projeto. Aos poucos todo o conhecimento específico está sendo difundido entre os membros da equipe. Infelizmente nem todas as equipes estão completas dessa forma por diferentes motivos (espaço físico, distância entre os prédios da empresa, etc), mas estamos trabalhando duro para resolver isso. Inclusive temos uma reunião chamada de Scrum Of Scrums, onde todos os Scrum Masters se reunem para se ajudarem a resolver esses tipos de problemas, que muitas vezes são comuns a várias equipes.

Já que o Scrum não fala nada sobre práticas de desenvolvimento de software, acabamos adotando muitas práticas do XP. Isso fica por conta de cada equipe e cada uma faz o que julga mais adequado para entregar o melhor software possível, mas muitas equipes usam desenvolvimento guiado por testes, integração contínua, programação em par, metáforas e várias outras práticas de Extreme Programming com muito sucesso. De fato a integração entre Scrum e XP funciona muito bem.

Definimos o nosso conceito de “done” (finalizado), que é a parte mais divergente entre as equipes. Na equipe de desenvolvimento de vídeos (minha equipe), uma história ou funcionalidade está pronta quando foi desenvolvida (incluindo testes unitários), integrada à base de código, testada novamente (fazemos testes de aceitação com critérios definidos no Sprint Planning ao criar as histórias) e homologada. Como nosso time tem uma pessoa da área de QA, podemos incluir a homologação da aplicação dentro do Sprint (nem todos os times fazem dessa forma).

Temos na empresa uma equipe que é especializada no ambiente de produção e por isso colocar os sistemas no ar fica fora do nosso Sprint. Quando nosso Sprint termina, entregamos um pacote fechado, testado, homologado e pronto para ser colocado em funcionamento, e então agendamos uma data e hora para que a subida seja feita acompanhada por um ou mais desenvolvedores do time. Todas as alterações de arquitetura e ambiente de deployment, quando necessárias, são feitas dentro do Sprint, somente as mudanças que envolvem risco de indisponibilidade nos sistemas que são feitas numa data que agendamos após o termino do Sprint, geralmente no meio da madrugada (as famosas “janelas”). Alguns times, por terem menos criticidade no seu ambiente de deployment, consideram que um Sprint está concluído quando o software está no ar, e o seu último dia do Sprint sempre é uma subida para produção. Como já havia falado anteriormente, cada time se adaptou para funcionar da melhor forma possível de acordo com suas peculiaridades.

E por último, nossas retrospectivas têm sido uma base forte para adaptações no processo e na forma de trabalhar. Para mim foi um aprendizado enorme quando o Boris Gloger veio na Globo.com e acompanhou uma retrospectiva inteira do nosso time – ele deu excelentes toques importantissimos. A última retrospectiva em especial, que aconteceu após uma grande entrega de um projeto interno, mostrou nitidamente a evolução do time e como estamos efetivamente conseguindo aos poucos achar e resolver todos os problemas. Estamos evoluindo devagar mas constantemente e já temos várias equipes com um bom nível de maturidade e evolução na empresa.

Concluindo…

Não só o Scrum como todos as metodologias ágeis dependem muito das pessoas. Na Globo.com não foi diferente e as pessoas certas fizeram toda a diferença. Também existe o outro lado da moeda: algumas pessoas simplesmente não se adaptam a essa forma de trabalhar. Desde o início da adoção nós já perdemos muitos desenvolvedores e acredito que ainda perderemos muito mais. Por conta disso nossos processos seletivos se tornaram mais exigentes e demorados, porque agora não só precisamos de pessoas que sejam ótimas tecnicamente mas também que tenham um perfil adequado para trabalhar no tipo de ambiente que criamos dentro da empresa.

Além disso é essencial que haja apoio da gerência e “carta branca” para que as equipes de desenvolvimento tenham a autonomia necessária para levar o projeto da forma correta. Como estes “processos” são muito diferentes dos tradicionais, algumas empresas acabam fazendo modificações antes do tempo por puro medo ou falta de conhecimento, que acabam atrapalhando ou até mesmo arruinando a adoção de uma metodologia ágil. Ainda em relação aos times de desenvolvimento, é essencial que os líderes de equipe (ou Scrum Masters no caso do Scrum) sejam muito bem capacitados e que conheçam profundamente as práticas/regras/princípios, não só para que tenham capacidade de argumentação com a empresa mas também para que não façam adaptações que violem os princípios básicos das metodologias ágeis.

Por fim, acho que ainda estamos muito longe do ideal e vejo muitas oportunidades de melhoria na nossa forma de trabalhar, mas o mais importante é que agora acreditamos que estamos no caminho certo.

Em primeiro, Roman Pichler escreveu um excelente artigo no InfoQ entitulado “Creating Product Owner Success” com vários insights sobre como ser um Product Owner de sucesso. Além disso ele também fala de alguns erros comuns cometidos nesse papel. Há uma lista de outros artigos sobre Scrum e P.O.s no site do Roman, vale a pena dar uma vasculhada.

O segundo artigo é do Rodrigo Yoshima entitulado “Product Owner: Um de$graçado ganancio$o”. O Rodrigo colocou um ponto interessante que eu também vejo acontecendo em alguns projetos: a falta de compromisso com o ROI. O Scrum é totalmente “ROI-oriented” e é absolutamente essencial que o P.O. entenda isso plenamente para o sucesso dos projetos.

E por último, o Danilo Bardusco escreveu sobre “Product Owner Técnicos”, argumentando porque o P.O. também deve ter bons conhecimentos técnicos e como isso é benéfico para que ele possa guiar bem o time e expressar melhor suas idéias.

Além disso, há uns meses escreví sobre esse mesmo assunto referenciando um artigo do Antonio Carlos Silveira sobre “O papel do Product Owner e priorização do Product Backlog”, que também vale a pena ler.

O Patrick Kua postou agora há pouco sobre o que ele acredita que sejam algumas das responsabilidades de um líder técnico e colocou um link para um “Tech Lead Manifesto” escrito por Sam Newman em 2006:

A Tech Lead Should…

• Ensure the creation of a clear and consistent technical vision for the project which can best result in a successful project
• Ensure all members of the team have a proper understanding of the technical vision
• Ensure that the technical vision updates to reflect new requirements
• Track and resolve issues where the code deviates from the technical vision
• Create an environment in which all members of the team can contribute towards the technical vision
• Understand and address skills gaps in the team which would result in difficulties implementing the technical vision

A Tech Lead Should Not…

• Tell everyone what to do
• Necessarily be the best at everything
• Write no code
• Write all the hard code

Esse manifesto resume muito bem algumas características altamente desejáveis para líderes de times de desenvolvimento de software e é totalmente aderente a todas as metodologias ágeis, incluindo o Scrum.

Fica como complemento para a discussão anterior.

Infelizmente os 40 minutos não foram suficientes para falar tudo que eu queria/deveria e a apresentação ficou meio corrida… Então, como prometí, estou disponibilizando os slides da apresentação sob a licensa Creative Commons 2.5 para quem quiser dar uma olhada com mais calma.

Além disso, seguem alguns ponteiros para quem quiser estudar mais sobre o assunto:

Livros recomendados

• Agile Software Development with SCRUM
• Agile and Iterative Development: A Manager’s Guide
• Agile Project Management with SCRUM
• The Enterprise and Scrum
• Extreme Programming Explained
• Lean Software Development
• Implementing Lean Software Development: From Concept to Cash
• Scrum and XP from the Trenches
• Agile Software Development, Principles, Patterns, and Practices
• Agile Retrospectives: Making Good Teams Great
• Agile Estimating and Planning
• User Stories Applied
• The Art of Agile Development

Blogs sobre “Agile”, Scrum e XP

• Agile & Business
• Agile Advice – Working With Agile Methods (Scrum, XP, Lean)
• Agile Development Thoughts
• Agile Executive Blog
• Agile Planet
• Agile Software Development
• Agile Thoughts
• Henrik Kniberg’s blog
• Implementing Scrum: the blog
• Lean Blog
• Mike Cohn’s Blog
• Net Objectives Blog

Links

• Scrum Alliance articles
• Agile & Business – Suggested Reading
• Improve It – Extreme Programming
• Improve It – Scrum
• Patrick Kua – The Essential Agile Reading List
• Patrick Kua – The Extended Agile Reading List

Lendo vários livros e artigos sobre o assunto, percebi que todos eles enfatizam várias características do Scrum Master. Ele deve ser influente dentro da empresa, corajoso, comprometido com o projeto, deve ajudar o time a entender as práticas do Scrum e assegurar que elas não sejam violadas, dentre outras coisas.

O Scrum Master não precisa ser técnico. Todas as tarefas principais exigidas pela função podem perfeitamente ser realizadas por uma pessoa sem nenhum conhecimento técnico. Porém isso não significa que é ruim quando ele tem conhecimento técnico e usa-o em favor do time ou do projeto. Mais do que isso, acredito fortemente que os melhores Scrum Masters necessariamente devem ter conhecimento técnico e do negócio, pois isso os ajuda a entender melhor os problemas do projeto e ajudar melhor o time.

Essa não é uma opinião só minha. Mike Cohn, um dos grandes nomes do mundo ágil, escreveu no ano passado um artigo sobre o que ele considera que sejam as seis principais características dos melhores Scrum Masters. Uma dessas características é:

Knowledgeable

The best Scrum Masters have the technical, market, or specific knowledge to help the team in pursuit of its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.” Lockhart, K. 2006. Responsibility Junkie. Harvard Business Review (October): 30.

A princípio o Scrum Master não deve estar comprometido com tarefas dentro do projeto e deve evitar se intrometer tecnicamente. Primeiro, porque impedirá que ele se concentre em resolver os impedimentos e problemas que estão no caminho do time, que no início da adoção são muitos e muito graves. Segundo, porque ele pode acabar tirando o compromisso do time. Ele pode acabar tomando decisões que nem todos concordam exatamente, mas farão porque alguém acima na hierarquia determinou e aí voltamos ao gerenciamento command-control onde as pessoas só fazem o que são mandadas. Para evitar esses problemas, no início da adoção é recomendável que o Scrum Master siga as recomendações e as práticas à risca e que se concentre em cuidar só disso.

Porém, vejo que depois de um certo tempo o time e o Scrum Master se adaptam tanto à empresa e a forma como ela trabalha (assim como a empresa se adapta às necessidades do time) que o time precisa cada vez menos do Scrum Master. Ele continuará sendo necessário na hora em que aparecerem problemas fora do alcance do time, mas penso que isso aconteça na menor parte do tempo e cada vez menos. O time e a empresa amadurecem sua relação e evoluem tanto que o time entra num ritmo de alta produtividade e sofre cada vez menos interferências.

E quando isso acontecer o Scrum Master deverá ficar sentado esperando o próximo problema/impedimento a ser resolvido? Certamente isso não seria bom para a empresa.

Todos os Scrum Masters ou líderes de projeto que conheço são pessoas excelentes tecnicamente. Muito modestamente e humildemente falando, eu me incluo neste grupo. Eu e todos esses líderes/Scrum Masters que conheço chegaram nesta posição por terem sido ótimos técnicos e se destacarem entre os demais. Como é que se pode ignorar este fato e pedir que eles simplesmente deixem de fazer o que mais sabem? Porque o Scrum Master não pode trabalhar com impedimentos técnicos? Ou programar? Desde que se concentre primariamente em exercer seu papel de Scrum Master, que não atrapalhe o time e que não atrapalhe o projeto, é totalmente aceitável que ele faça isso. Aliás, nenhum livro sobre Scrum fala o contrário.

Hoje, por exemplo, eu diria que uso metade do meu tempo exercendo ativamente o papel de Scrum Master. Na outra metade, eu não fico parado esperando o próximo problema acontecer.

No último Sprint do meu time, por exemplo, trabalhei para resolver um impedimento técnico gigantesco do próximo Sprint. Estamos no meio de um projeto importante para a empresa e a história que talvez seja a mais importante de todas acabou ficando de fora do Sprint. Já é certo que ela será a primeira história do próximo Sprint, porém, existe um grande impedimento técnico relacionado à forma como funciona uma API de busca interna da empresa, e eu trabalhei para contornar este problema e o time possa trabalhar tranquilamente na próxima semana. Outro exemplo, foi quando parei uns três dias para reconfigurar todo nosso ambiente de integração contínua e fazer um refactor agressivo no build. Ou então, para não desfocar o time do seu trabalho, eu resolvo silenciosamente vários bugzinhos chatos.

Muitas pessoas discordam dessa atitude simplesmente porque eu tive que codificar alguma coisa. Mas eu não estou facilitando o trabalho do time? Não estou resolvendo problemas e fazendo com que o time só precise se concentrar em entregar seu trabalho? O Scrum é um framework onde a cada período de desenvolvimento temos oportunidade de avaliar o que fizemos e nos adaptarmos às circuntâncias do projeto/time/empresa. Refletindo sobre o meu trabalho, percebi que se eu me adaptasse para trabalhar desta forma poderia contribuir muito mais com o time e a empresa do que simplesmente fazendo o feijão-com-arroz do Scrum.

Coincidentemente (ou não), o Phillip Calçado escreveu um post que vou usar como argumento para outro ponto importante. O manifesto ágil, base para todas as metodologias ágeis que conhecemos, coloca pessoas acima do processo. Ou seja, o processo importa menos do que as pessoas que participam dele. Parafraseando o Phillip, você não pode fazer que o processo –ágil ou não- vença à razão e você tenha um desenvolvedor (ou Scrum Master) completamente desestimulado e frustrado na equipe. Mais ainda, você não pode fazer com que o processo deixe de lado pessoas técnicas altamente capazes.

A verdade é que não existe uma regra. Você faz a regra, mas faça com consciência e sabedoria.

Estou falando mais especificamente de Scrum e eXtreme Programming (XP). O Scrum, particularmente, é um framework focado principalmente em planejamento e gerência. Já o XP é mais focado em práticas de desenvolvimento. Mesmo assim, várias práticas são coincidentes entre Scrum/XP como sprint/desenvolvimento iterativo, daily scrum/daily meeting, sprint planning/planning game, e por aí vai.

A principal diferença que vejo entre as duas é que Scrum não te diz nada sobre práticas de desenvolvimento de software ágil, até porque você pode usar Scrum não só para fazer sistemas, como também para fazer carros, aviões ou bolos.

Minha visão é que as práticas de XP complementam o Scrum. Certas práticas de desenvolvimento, que vejo como essenciais para o bom andamento de um projeto de software, não fazem parte do escopo do Scrum mas fazem parte do XP, como desenvolvimento guiado por testes, integração contínua, build de 10 minutos, design incremental, metáforas, código coletivo, programação em par, refatoração e por aí vai. Por isso, não só acho que é bom fazer essa combinação, como acho que é bastante recomendável.

Mas para fazer isso não seria melhor usar XP puro ou invés de Scrum? Não vejo dessa forma. Scrum tem algumas diferenças que acho interessantes, como a retrospectiva fazendo parte do processo, uma grande ênfase na gerência do backlog (e em quem é o “responsável” por cada backlog: o P.O. pelo backlog do produto e o time pelo Sprint backlog) e a forma de planejamento e acompanhamento dos Sprints.

Para quem está começando a praticar o Scrum, às vezes é um pouco complicado lembrar de todas as regras (apesar de serem poucas). Entretanto, é altamente recomendável seguir todas essas regras à risca, especialmente no início da adoção quando ainda não se tem muita experiência/conhecimento sobre o framework.

Por estes motivos as checklists são muito úteis! O objetivo delas é que você possa ter um micro guia de referência, para andar debaixo do braço e te ajudar a seguir e lembrar das regras.

Recomendo duas:

1) Checklist do Boris Gloger/SPRiNT-iT: essa foi a primeira que eu conhecí e a que mais usei. Quando fiz o curso de Scrum Master, o Boris deu uma versão impressa para os alunos, que é de excelente qualidade (tanto no conteúdo como no material). Ela é feita em papel duro e tem um espaço para anotações ao lado das páginas. Se você imprimir este PDF numa gráfica, deve ficar show de bola!

2) Checklist do Henrik Kniberg/Crisp: essa checklist é muito mais resumida, mas também tem várias informações legais. Neste caso não é um livreto, mas um mind map com vários tópicos importantes para se lembrar.

Combinando essas duas checklists você terá um excelente guia de bolso!

Nos projetos Scrum, o P.O. tem uma importância tão grande quanto o próprio time ou o Scrum Master. Eu pessoalmente considero sua importância de certa forma maior do que a de todos os outros, visto que o P.O. pode fazer um projeto falir ou “skyrocket”, dependendo das decisões que ele toma.

O Antonio Carlos escreveu um ótimo resumo sobre o papel do P.O. e sua importância dentro dos projetos Scrum. Leitura obrigatória.

Eu sei que já falei isso algumas vezes aqui e que todos estão carecas de saber, mas mesmo assim tenho que repetir: o Boris é sensacional! Se todos os outros encontros com ele já tinham sido excelentes, “sensacional” é a palavra mais adequada para descrever o encontro e os ensinamentos de hoje.

Esse treinamento que fizemos serve para habilitar os Scrum Masters a se tornarem Scrum Trainers, ou seja, treinadores capacitados a passar a mensagem do Scrum para outras pessoas. Na verdade não é um treinamento de apenas um dia que cria um trainer, o caminho é muito mais longo que isso. Segundo o Boris, quem pretende seguir como um trainer tem que escrever artigos, ser reconhecido na comunidade e depois escolher um mentor, para acompanhá-lo por vários treinamentos, até que esteja realmente apto a treinar (e quem julga se você está preparado ou não, é o mentor). Esse curso é apenas o começo da jornada.

Não pretendo me tornar um treinador oficial de Scrum no momento, mas com certeza esse treinamento constroi mais um degrau no meu conhecimento sobre Scrum, e vai me ajudar bastante a elaborar uma forma de transmitir a mensagem para minha equipe, já que nem todos tiveram a oportunidade de fazer o curso do Boris (infelizmente).

Foi muito legal entender as “internas” do treinamento e conhecer os segredos do Boris. O treinamento de Scrum Master é totalmente planejado, desde o primeiro minuto em que as pessoas entram na sala, até os horários e os motivos estratégicos para os coffee-breaks, passando pelo planejamento de exercícios e de cada minuto do dia. Tudo tem um motivo, tudo mesmo. Ele nos ensina a usar várias técnicas de psicologia, didática e revela toda sua forma de pensar, seus segredos e suas técnicas para lidar com situações difíceis ou inesperadas.

É tudo tão incrível que o Danilo, por exemplo, está absolutamente convencido que o Boris tem poderes sobrenaturais. Já o Evandro acha que ele é uma espécie de Jedi. Enfim, o fato é que seus vários poderes incluem a leitura da mente, desintegração de matéria, indução de amnésia e por fim, ele é a única pessoa além de Chuck Norris que sabe fazer o Roundhouse Kick. Hahaha, é claro que isso é brincadeira, mas realmente é impressionante como a conjunção das técnicas do Boris faz tudo parecer mágica.

O fim do treinamento foi especial. Quando fizemos a retrospectiva do dia, o Antonio falou emocionado sobre todo o caminho que percorremos até chegar onde estamos. É incrível perceber como um grupo pequeno de pessoas pode mudar a cabeça de uma empresa grande e tradicional como a Globo. Tenho orgulho de fazer parte das cabeças dessa revolução, e fico triste pelo nosso amigo cangurú-calçado, que foi peça fundamental nessa mudança, não estar mais aqui conosco…

Para mim o dia de hoje foi muito mais do que um dia de treinamento. Foi uma viagem pela mente e uma mudança de estado de espírito. O Scrum é totalmente sobre pessoas e como lidar com elas. As práticas funcionam porque o processo todo foi pensado nas características humanas e intelectuais que todos nós temos. O Scrum nos ajuda dando ferramentas para nos ajudar a lidarmos com nossas fraquezas e permite que nossas características individuais e criatividade aflorem, fazendo com que a produtividade vá a mil por hora!

Para quem tiver interesse, coloquei fotos do treinamento no meu Flickr.

Aproveitando que o Boris estava aqui pela Barra da Tijuca, o Antonio conseguiu que ele viesse nos visitar aqui na Globo.com!

Na primeira parte da sua visita, o Boris visitou o desenvolvimento das equipes de Portal e Aplicativos, e o Evandro tirou várias fotos e blogou tudo. Como a segunda foto denuncia, acompanhei tudo de perto! Ouvimos várias dicas e sugestões interessantes para melhorarmos nosso processo, além de termos feito vários bate-papos com alguns times. Fiquei sempre por perto para aproveitar o máximo possível (como chicken, obviamente), porque eu sabia que ele viria com uma dúzia de sacadas expertas e conclusões que são tão óbvias que acabam sendo imperceptíveis. E não deu outra.

Em seguida fomos para a base de WebMedia, onde o Boris acompanhou todo o nosso Sprint Review e Sprint Retrospective. Ele nos acompanhou durante três horas e deu várias dicas de como agir e o que fazer em determinadas situações específicas, além de ter tirado algumas dúvidas que sempre nos perturbam no dia-a-dia.

Depois, quando tudo acabou, ele disse que a retrospectiva foi muito boa, e mais uma vez deu várias dicas… A mais importante foi que eu tenho que ser um Scrum Master mais malvado (risada macabra), porque ele me achou bonzinho demais… Por ele o P.O. tinha sido expulso da sala duas vezes, mas eu confesso que ainda não sei fazer isso. Mas fiquei feliz de saber que estamos no caminho certo. Foi uma oportunidade única e inenarrável.

Se alguém quiser ver, tem mais algumas fotos no meu Flickr.

Nem preciso dizer que o curso foi sensacional – fora o fato de ter me tornado o mais novo Scrum Master do pedaço! O Boris têm uma didática excelente e tive a oportunidade de tirar várias dúvidas que vinham me perturbando há algum tempo. Apesar de já ter lido alguns livros sobre Scrum esse treinamento conectou vários conhecimentos na minha cabeça e eu me sinto agora com uma visão clara como cristal de como tudo funciona.

Para ter uma idéia melhor de como é o treinamento você pode ler dois posts do José Papo resumindo a agenda e dando suas opiniões em seguida.

O curso é cheio de surpresas e eu não vou contar nada aqui para não estragar a experiência. Mas o ponto é que através de exemplos extremamentre simples e didáticos a mensagem é transmitida. É impossível não sair da sala no fim do dia extremamente motivado a mudar!

WUFF!