6 www.mundoj.com.br

c o l u n a

Rodrigo Yoshima

(twitter: @rodrigoy): Técnico em Processamento de Dados,

bacharel em Administração de Empresas e autor, escreveu

artigos com renomados autores nacionais e internacionais

como Scott Ambler, Jon Kern e James Shore. Trabalha com

projetos de software há 16 anos, tendo treinado mais de 100

equipes em práticas ágeis no Brasil nas mais variadas empresas

e setores. Atua como instrutor/Coach Agile na Aspercom e

escreve no blog Débito Técnico (http://blog.aspercom.com.br).

Neste artigo inaugural da coluna

MundoAgile muitas questões que você (e seu

gerente) podem ter sobre Auto-organização

serão explicadas. Desenvolvimento ágil tem

muitos mitos gerenciais sobre como a equipe

funciona. Por que Scrum não tem gerente

de projeto? Uma equipe Agile faz o que ela

quer? Eu preciso de uma equipe sênior? O

modelo de gestão moderno dá liberdade

para a equipe explorar o máximo da sua

produtividade. Para isso, a confiança e a

autonomia são fundamentais.

e o escopo da Auto-organização

A nova coluna MundoAgile!

MundoAgile

Desde 2006 escrevo na Mundoj a coluna MundoOO. Durante esses qua-se 4 anos a coluna foi bastante variada, pregando sobre fundamentos arquiteturais, bons princípios da orientação a objetos e também práticas ágeis de desenvolvimento de software. Tivemos participações ilustres de gurus de software nacionais e internacionais como Scott Ambler, Jon Kern, James Shore, Phillip Calçado, entre outros. Agora em 2010 inauguramos a coluna MundoAgile trazendo informações sobre práticas de gerenciamento e engenharia ágil. Vamos trazer artigos, entrevistas, cobertura de eventos e muitas experiências do mercado vindas do meu trabalho como consultor em implantações Agile.

O maior motivo dessa coluna existir é o crescimento vigoroso (e talvez descontrolado) dos métodos ágeis no Brasil. Não há dúvidas que Scrum e Extreme Programming estão “tomando a cena” em várias empresas de diversos setores. Os relatos de experiências de grandes empresas, principal-mente na área de internet, destacando a Globo.com, chamaram a atenção de muitos gestores. Atualmente até grandes consultorias tradicionais cascateiras possuem suas iniciativas de adoção de processos ágeis, de-monstrando como é forte essa tendência. É bem empolgante ver o mercado mudando e empresas repensando a maneira como desenvolve seus proje-tos de software, porém, infelizmente há muitas adoções Agile às avessas

O Scrum

7

Os estigmas do passado atrapalham muito a vida dos evangelistas ágeis. Aqui no Brasil Agile ainda é confundido com falta de controle, bagunça, imprevisibilidade, retrabalho, documentação zero e muitas outras ideias erradas. Muitos definem auto-organização como “a equipe decide tudo o que deve ser feito”. Essa talvez seja a maneira mais idiota de explicar a auto-organização e leva muitos gestores de empresas grandes a achar que Agile é dar poderes ilimitados àquele bando de programadores irri-tados que ele tem.

Para tornar o conceito claro, vamos resumir o Scrum em um único pará-grafo. O primeiro passo para implantar o Scrum é organizar a empresa separando-a em pequenas equipes multifuncionais capazes de entregar software funcionando, criando valor de negócio. Para direcionar cada equipe, uma lista de funcionalidades potencialmente implantáveis chamada Product Backlog deverá ser criada e priorizada pelo cliente. Vou usar o termo “cliente” aqui como sendo a área usuária da solução, não importando se ele é interno ou externo. Essa demanda do cliente é definida e controlada por uma pessoa: o Product Owner (um papel do Scrum). Quanto mais o cliente se envolver no projeto, melhor. Quanto mais transparente for o relacionamento entre o cliente e a equipe, melhor. O Scrum roda dentro de Sprints (iterações) com período fixo de tempo: num prazo curto (uma a quatro semanas) os itens mais prioritários do backlog devem ser implementados pela equipe. O backlog geralmente é manifestado através de histórias do usuário (uma prática do Extreme Programming, ver referências). A cada ciclo iterativo há um planejamen-to, reuniões diárias, uma revisão dos resultados obtidos com a iteração e uma retrospectiva focada em melhoria do processo. A transparência permite a inspeção e a adaptação contínua.

Esse rápido resumo deixa claro que “a equipe faz o que quiser” é um mito. A auto-organização da equipe não tem alçada na priorização do

No Agile, a equipe faz o que ela quer (se ela quiser)

No Agile não tem “pressão”

backlog do projeto. A equipe não faz aquilo que ela quer, mas sim as funcionalidades criadas pelo Product Owner. A equipe não faz as coisas na ordem que ela quiser, mas sim obedece à priorização do backlog. Há decisões importantes a serem tomadas num projeto Scrum que a equipe técnica não tem a palavra final. Isso nos mostra a importância de um bom Product Owner no Scrum, e também deixa claro uma primeira premissa importante: a auto-organização requer objetivos claros de negócio. O Product Backlog é um artefato sob responsabilidade do Product Owner. Ele toma as decisões sobre quais itens entram, quais itens saem, quais itens já foram implementados etc.

O escopo da auto-organização é o trabalho técnico a ser feito para im-plementar um item do Product Backlog. Quando alguém da equipe (ou um par, caso esteja usando Pair Programming) “puxa” uma história do backlog para desenvolver a auto-organização emerge. É a equipe que vai decidir quais serão as técnicas, práticas e ferramentas utilizadas para transformar aquele item em um pedaço de software bem arquitetado e que funciona. Resumindo: o Product Owner decide “o que” e “quando” será feito, a equipe se auto-organiza para decidir o “como”.

Neste trabalho é bastante comum algumas perguntas “pairar na cabeça” do desenvolvedor: “Como vou implementar isso? Como vou testar e automatizar os testes? Como vou especificar e documentar?”. Para cada funcionalidade do backlog pode existir uma maneira mais eficiente de resolvê-la. Uma discussão rápida dentro do grupo pode ocorrer quando surge algum problema ou dúvida técnica. Isso é a equipe continuamente aprendendo, melhorando o processo, evoluindo a arquitetura e o seu arse-nal de engenharia. Tudo isso é fruto da auto-organização. Essa é uma das razões dos métodos ágeis pregarem tanto a importância dos membros da equipe estarem na mesma sala sempre que possível. A comunicação franca e aberta deve ser valorizada.

Um esquema auto-organizado inicia com a alta administração da empre-sa depositando muita confiança na capacidade da equipe, dando-lhe total autonomia, e isso faz todo sentido do mundo, afinal são os gestores que contratam e treinam as pessoas. A autonomia dá liberdade para a equipe buscar constantemente o próximo limite, rompendo paradigmas, achando atalhos, inovando e desafiando continuamente o status quo.

e até violando valores do Manifesto Ágil. Agile não é simplesmente trocar artefatos de gerenciamento de projetos por post-its num quadro na parede.

Adoção de métodos ágeis é sinônimo de mudança cultural. Essa mudança é impulsionada principalmente porque as empresas estão reconhecendo que desenvolvem seus projetos de TI de maneira pouco eficiente. Isso tem atrapalhado seus objetivos de negócio e muitas organizações têm adotado o Scrum para iniciar a melhoria dos seus processos. Se um dia você estiver no elevador com o CEO da sua empresa “tradicional” e quiser explicar o Scrum para ele em menos de 1 minuto as palavras-chave são: transparên-cia, autoorganização, inspeção e adaptação. Se ele não concordar com es-ses princípios será bem difícil implantar o Scrum, pois sem esses conceitos o método não funciona. Ter um Product Owner, um Product Backlog, uma equipe dedicada, um ScrumMaster certificado e um lindo quadro de post-its na parede faz seu processo ser bem parecido com Scrum, mas se você viola um desses princípios fundamentais citados, você não está aplicando Scrum. É muito comum navegantes de primeira viagem confundirem Scrum com um simples processo iterativo. É importante ressaltar que o Scrum não impõe só iteratividade, e se você analisar com cuidado, os princípios do Scrum chegam a dar medo nos gestores. Transparência é um dos funda-mentos mais violados no Scrum, mas isso será abordado em outro artigo. Aqui vamos explicar mais sobre auto-organização, um assunto polêmico no mercado e também bastante enigmático para muitos gestores.

Outra questão que deixa gerentes e coordenadores perplexos sobre

a auto-organização é o fato de não existir um papel hierarquicamente

superior acompanhando a execução das tarefas do dia-a-dia e cobrando

resultados. Essa é uma das diferenças mais acentuadas entre os métodos

ágeis e as metodologias "tradicionais". "No Scrum não tem gerente de

projetos" – é um discurso muito comum dentro da comunidade ágil. Re-

almente dentro dos papéis do Scrum você tem o Product Owner, a Equipe

e o ScrumMaster, não deixando espaço para um gerente de projeto,

principalmente aqueles que gostam de exercer pressão sobre a equipe.

É um mito achar que uma pressão externa exercida por um papel hie-

rarquicamente superior é eficiente. Também é um mito achar que não

há pressão sobre a equipe em métodos ágeis. A diferença é quem está

pressionando, mas pode ter certeza que equipes ágeis também se sentem

pressionadas! Takeuchi e Nonaka, em seu célebre artigo “The new new

product development game” definem que o desconforto é um elemento

fundamental para a auto-organização. Sem desconforto, não há inovação.

O Scrum e o escopo da Auto-organização

8 www.mundoj.com.br

O primeiro agente de desconforto que exerce pressão sobre a equipe é o próprio compromisso que ela assumiu no planejamento da iteração (Sprint). No Scrum, é a própria equipe que define os objetivos a serem cumpridos na iteração. Se a equipe deliberadamente define suas metas de curto prazo, ela se esforçará ao máximo para cumpri-las. Com isso, outro agente de desconforto surge: a própria equipe! É bem impressionante nas implantações Scrum como a pressão do próprio grupo é eficiente. Re-centemente em um dos meus clientes um gerente de um projeto crítico (e membro do PMO) reconheceu: “Com o Scrum, a equipe está se sentindo duramente pressionada, mesmo sem nenhum gerente estar no pé deles”.

Por último, a própria necessidade de se auto-organizar exerce pressão sobre a equipe: na auto-organização, a maior responsabilidade pela entrega é do próprio time. Não tem nenhum chefe cobrando a execução das tarefas, e isso inicialmente apavora os desenvolvedores, mas, passada essa fase, os benefícios são incontáveis. Potencializar a equipe traz uma grande responsabilidade para ela e isso eleva sua maturidade. A dinâmica que muitas vezes eu vejo numa equipe Scrum é a mesma de um time de futebol. Pense na “pelada” que você joga nos sábados de manhã: quando você faz uma “burrada” alguém te cobra; quando você vê uma burrada você também cobra alguém. Essas reações são naturais num ambiente altamente colaborativo, no qual pessoas diretamente envolvidas na exe-cução do trabalho estão no mesmo barco, sem hierarquias burocráticas, sem papéis rígidos e sem perder tempo procurando culpados. O time é responsabilizado pelos resultados.

A pressão interna da equipe até precisa ser controlada no início da im-plantação Agile. As equipes podem se empolgar com a liberdade e com isso tomarem compromissos muito ousados para si na primeira Sprint, às vezes, até para mostrar para a gestão resultados espetaculares. Eu costumo dizer para as equipes serem conservadoras nas primeiras Sprints. O projeto piloto da implantação Agile costuma ser estressante no início: a mentalidade das pessoas está se adaptando, há pressões organizacionais por todos os lados e a expectativa é inflada. Manter a equipe num ritmo sustentável é saudável para a qualidade do projeto e também importante para aumentar a confiança da implantação. Usamos "passos de bebê" (um conceito também do Extreme Programming) até para as mudanças organizacionais.

Agile só funciona com equipe experiente

Conclusão

Neste momento é provável que você esteja se questionando se auto-organiza-ção seria possível na sua empresa devido à maturidade dos desenvolvedores. Auto-organização tem uma premissa importante: a equipe deve ser formada por adultos responsáveis. Uma equipe ágil é formada por pessoas de boa índole, que querem entregar o projeto com qualidade técnica e eficiência. Não funciona colocar pessoas irresponsáveis ou imaturas para se auto-organizar. E isso não tem relação só com conhecimento técnico, mas sim com a postura do profissional. Talvez a vontade de aprender e de colaborar sejam qualidades mais importantes para avaliar a maturidade do desenvolvedor do que ele saber configurar o cache de segundo nível do Hibernate.

Muitas pessoas no primeiro contato com desenvolvimento ágil dizem: “Isso só funciona com equipe experiente”. Sim, tentar auto-organizar pessoas imaturas não funciona, mas é um exagero achar que só funciona com equipes seniores. É lógico que trabalhar com equipe sênior é muito mais fácil e produtivo. Muitas empresas de primeira linha têm adotado a prática de só contratar os “feras”, e isso é uma estratégia acertada para os objetivos de negócio dessas empresas.

Para se ter auto-organização você precisa de liderança técnica: com uma equipe de sete pessoas são necessárias três ou quatro pessoas mais experientes que dêem o norte técnico e fomentem a auto-organização dos novatos. Outro benefício é que os novatos da equipe ganham experiência muito rápido dentro deste ambiente colaborativo. Pair programming colabora muito neste processo. A responsabilidade compartilhada estimula a maturidade.

O objetivo do artigo é tirar certos mitos comuns sobre auto-organização. Para concluir é importante alertar que auto-organização não é para qualquer pessoa. Em muitas implantações observei que há um grande grupo de pessoas que adoraram auto-organização e logo nas primeiras Sprints já se habituaram com essa nova forma de gestão. Há um segundo grupo menor de pessoas que têm mais dificuldade, e que demoram alguns meses para se auto-organizar. Por último, há o grupo das exceções: pessoas que não se auto-organizam, não que-rem colaborar e começam a atrapalhar, torcendo contra, espalhando fofocas na equipe e minando a iniciativa. Infelizmente, este último caso é motivo para demissão. Em toda implantação Agile alguns “ovos precisam ser quebrados”.

Desenvolvimento Ágil são práticas leves e muitas decisões sobre a parte técnica são tomadas pela própria equipe em tempo de execução. Detalhes são resolvi-dos em tempo oportuno. Não há dúvidas que auto-organização é uma fronteira “dura de ser cruzada”; é uma ruptura de paradigma; é um desafio grande para uma empresa acostumada com microgerenciamento. De qualquer forma, é esperado que desenvolvedores de software, trabalhadores do conhecimento, adultos responsáveis, saibam organizar seu próprio trabalho com autonomia em prol da inovação. A produtividade e a eficiência não rolam com um gerente de projetos dizendo para a equipe passo-a-passo o que ela tem que fazer.

Referências

O Scrum e o escopo da Auto-organização

Evento Agile Brazil

A Agile Brazil 2010 – Conferência brasileira sobre Métodos Ágeis de Desenvolvimento de Software – é uma conferência nacional sem fins lucrativos organizada por representantes das principais comu-nidades ágeis brasileiras. O evento tem como propósito promover a comunicação e a colaboração entre seus integrantes visando à disseminação coordenada da cultura Ágil por todo o País.

A Agile Brazil 2010 acontecerá no campus central da PUCRS, em Por-to Alegre, de 22 a 25 de junho, contando com cursos, apresentação de trabalhos e relatos de experiência provenientes de várias regiões do País, além da participação de convidados reconhecidos inter-nacionalmente. Martin Fowler, cientista-chefe da ThoughtWorks, e Philippe Kruchten, professor da UBC em Vancouver (Canadá) e conhecido também por ter liderado a equipe do RUP na Rational Software, são alguns dos nomes já confirmados para o evento. Mais informações em http://www.agilebrazil.com.