Introdução
A adoção do framework Scrum para gerenciamento e organização do trabalho em times de desenvolvimento de Software tem aumentado naturalmente, a medida que casos de sucesso são relatados. A importância da disseminação do conhecimento adquirido e do relato das experiências fazem com que os processos e as práticas propostas pelo Scrum sejam aperfeiçoadas. O Scrum, quando utilizado em conjunto com Extreme Programming (XP), pode representar um arma poderosa para o ganho de produtividade e qualidade nos projetos de Software. XP define uma série de princípios que devem ser seguidos: como a Simplicidade e o Feedback para os ativos de desenvolvimento, por exemplo, além de um processo de Comunicação efetiva.
O livro "O Mítico Homem-Mês", um clássico da Engenharia de Software, cita o projeto da Torre de Babel como um grande projeto de Engenharia que falhou por falta de comunicação. Ao desenvolvermos projetos de Software (como projetos de Engenharia), de qualquer porte e que envolva times de desenvolvimento, temos que ter uma grande preocupação com a qualidade da comunicação, devendo estar buscando sempre a excelência na forma como as informações são passadas entre as pessoas. Algumas medidas são extremamente importantes para que o processo de comunicação ocorra efetivamente como, por exemplo, a forma como os integrantes dos times são distribuídos no seu ambiente de trabalho e quais meios de comunicação devem ser adotados no projeto.
Em projetos Scrum a comunicação não é apenas importante entre o time de desenvolvimento. A mesma importância deve ser dada para a comunicação que ocorre entre o time (representado normalmente pelo Scrum Master) e o Product Owner. Essa comunicação deve envolver também habilidades de negociação, por ambos os lados, para o bom andamento dos projetos. Neste artigo, abordaremos algumas práticas que podem ser úteis para uma comunicação efetiva entre os membros de um time de desenvolvimento, bem como entre o time e o Product Owner.
O papel do Scrum Master
Começaremos esse tópico afirmando que a escolha do Scrum Master é uma decisão importante dentro do projeto. Até agora, parece uma coisa óbvia! Se isso é verdade e partindo do princípio que o Scrum Master deve liderar e representar um time heterogêneo de desenvolvedores, com variados níveis de conhecimento e experiência, é razoável acreditar na hipótese de que o Scrum Master deve ser o mais experiente, o de maior conhecimento, o mais comunicativo, o mais ..., o mais ...enfim. Essa hipótese pode ser sumariamente desacreditada uma vez que as principais atribuições do Scrum Master são, a grosso modo: ser um representante do time de desenvolvimento junto ao Product Owner, garantir e aplicar as boas práticas do Scrum e servir. Considerando esse cenário, um Arquiteto de Software com n certificações e "x" anos de experiência pode ser tão elegível quanto um simples desenvolvedor que preencha requisitos básicos como liderança reconhecida pelo time, boa capacidade de comunicação, organização e responsabilidade. Obviamente, se um profissional atende todos esses requisitos e possui também uma boa capacidade técnica, o seu valor para o time no papel de Scrum Master passa a ter grande importância.
O Scrum Master representa um papel de liderança dentro de um time de desenvolvimento, onde tal papel não deve diferenciá-lo em termos de regalias em relação aos outros membros do time. Como líder de um time Scrum, ele torna-se uma figura focal e, consequentemente, deve ter algum controle sobre todo tipo de informação que envolve o time de desenvolvimento. Como representante do time, deve ser o responsável por manter conversações entre o time e o Product Owner de um determinado projeto. No entanto, o Scrum Master deve ter em mente que há informações que necessariamente devem ser tratadas pela Gerência dos Projetos e que ele não deve se envolver, a menos que sua participação seja requerida. Na próxima seção, serão relatadas experiências e boas práticas que consideramos importantes para uma comunicação ágil em projetos Scrum.
Boas práticas para uma comunicação efetiva
Nessa seção, será abordada a comunicação em três cenários distintos: nas relações envolvendo o Product Owner, entre os membros do time de desenvolvimento e no momento das retrospectivas de Sprint. O conteúdo apresentado nessa seção é resultante de algumas experiências práticas da utilização do Scrum em alguns projetos profissionais.
Como não se tratam de conceitos mas de experiências, os cenários relatados podem ser adaptados para a realidade de cada projeto em particular.
Comunicação efetiva com o Product Owner
Com a popularização de altas velocidades de conexão nas organizações e da oferta por uma ampla gama de ferramentas de comunicação em rede é aceitável que as pessoas escolham soluções online para comunicação, à primeira vista. Em projetos de desenvolvimento de software precisamos tomar decisões, constantemente, e decisões que muitas vezes não podem esperar uma resposta por email com 12 dias de atraso. E se eu procurar as informações suficientes para a minha tomada de decisão através de algum messenger? É online, a minha resposta está do outro lado, a poucos segundos de mim! Talvez tenhamos que esperar que o informante termine seu papo descontraído sobre o Campeonato Brasileiro do outro lado! Bom, então eu posso falar com tal pessoa, que conhece tal pessoa, que pode fazer como que o Product Owner forneça a resposta mais rapidamente. Será que há uma rede de comprometimento eficaz entre essas pessoas? Será que a informação final chegará sem ruídos? Podemos imaginar muitas outras situações que podem acabar prejudicando a produtividade em um projeto.
O ideal é ter o Product Owner auxiliando o time de desenvolvimento sob o mesmo teto. Infelizmente, isso nem sempre é possível. Dessa forma, a interação entre pessoas através de comunicação oral é sempre o melhor caminho. Esclarecer dúvidas pessoalmente, nos momentos de disponibilidade do Product Owner, é um bom momento para pensar boas soluções. Use 100% desse momento, efetivamente. Nos momentos em que o ProductOwner não estiver disponível fisicamente, prefira a telefonia ou qualquer ferramenta para comunicação instantânea por voz. Essas formas de comunicação garantem que você saiba qual próximo passo deve ser executado, mesmo que o próximo passo passo, segundo o Product Owner, seja: "Não tenho a resposta para o seu problema. Passe pra outra funcionalidade, enquanto eu lhe respondo". Temos uma pendência, porém sabemos que devemos continuar, na pior das hipóteses.
Ok, mas talvez possamos esperar um dia por determinada resposta, então posso mandar um email? A resposta é não. Não podemos esperar um dia por uma informação previamente necessária. O Scrum Master deve tentar ao máximo ser proativo na sua comunicação com o cliente, visando evitar que atrasos diários possam resultar em sprints cada vez mais apertados ou finalizados sem cumprir com o objetivo especificado.
O Scrum Master também deve ter a preocupação de saber qual linguagem utilizar no processo de comunicação. Para comunicação envolvendo informações de negócio, o Scrum Master deve evitar utilizar termos técnicos ou pode ser auxiliado na tarefa de comunicação por algum analista de negócio habilitado. Por outro lado, para comunicações envolvendo informações técnicas, o Product Owner pode decidir entre participar exclusivamente da comunicação ou envolver alguma outra pessoa com habilidades técnicas na conversação. O importante é que o fluxo de informações seja realizado pelas pessoas corretas.
Comunicação efetiva com o Time
Em qualquer atividade que, necessariamente, deve ser desenvolvida através da interação entre pessoas é de suma importância entender que cada membro envolvido possui algumas particularidades. Saber respeitar essas diferenças é o primeiro grande passo para as coisas terminarem bem. Em times heterogêneos é comum encontrarmos componentes mais tímidos que outros, pessoas mais focadas em resultados que outras, alguns membros podem ser mais questionadores e assim, as diferenças vão aparecendo. Partindo desse princípio, o Scrum Master deve atuar como um mediador para essas diferenças, respeitando a individualidade de cada membro, desde que essas individualidades não entrem em conflito com o bom andamento dos projetos.
Contrariamente, querer que todos os membros sejam "iguais a você" pode ser uma experiência trágica e frustante. A grande arma que o Scrum Master tem em suas mãos para esse caso é o seu poder de persuasão.
Se algum membro está contribuíndo negativamente para o andamento do projeto, o Scrum Master não tem o poder de puní-lo. Uma boa prática é evidenciar os problemas ocorridos, convencer o membro que sua contribuição poderia ser melhor para o projeto e ser solícito para praticar as mudanças necessárias para uma melhoria na sua postura.
O daily meeting é definido pelo Scrum como o momento diário onde o time conversa sobre o que aconteceu no dia anterior, o que está acontecendo e quais os entraves para o andamento das atividades. É preciso entender que essa definição não pode ser encarada como os 15 minutos destinados à conversação em 8 horas de trabalho diário. O daily meeting não pode ser o único momento onde as pessoas conversam durante um dia de trabalho. Esse momento deve ser encarado como o momento onde toda equipe compartilha o estado atual de um determinado projeto.
Se os problemas forem detectados antes da hora marcada para o daily meeting, é fortemente aconselhável que eles sejam comunicados antes da reunião diária, para que medidas corretivas possam ser imediatamente tomadas. No momento da reunião diária esses problemas, previamente identificados, devem ser apenas tornados público para o restante do time e se já tiverem sido resolvidos, um breve relato da solução deve ser comentado. Uma boa prática que pode ser adotada pelo Scrum Master é, no ínicio de um dia de trabalho, conversar informalmente com cada membro do time na tentativa de identificar se há algum impedimento identificado. Problemas que são imediatamente identificados e tratados, não importando a sua complexidade, não comprometem o bom andamento dos sprints. Eles só passam a ser realmente problemas, quando há um retardo para sua comunicação após terem sido identificados.
No tocante a identificar e relatar problemas, o time deve estar confiante e com a segurança necessária para relatar problemas identificados. Novamente, o cenário-chave para isso é manter um ambiente propício para que essas coisas aconteçam naturalmente. Problemas são inerentes ao ciclo de vida de qualquer projeto de Software, por mais simples e pensado que ele tenha sido. Não há como fugir deles! O que deve haver é uma proatividade para relatar problemas e tratá-los desde o primeiro indício de sua ocorrência.
A prática de qualquer metodologia não pode ser imposta. Com o Scrum não pode ser diferente. É importante entender que temos ao nosso lado pessoas, com personalidades diferentes, com variados níveis de criticidade e cheias de opiniões próprias. Dessa forma, simplesmente aceitar a imposição de uma metodologia pode ser um passo não tão agradável para as pessoas à primeira vista, principalmente quando algum nível de processo já está definido. Scrum não deve ser visto como uma religião. Uma boa prática para a aceitação do Scrum é evidenciar e destacar a sua importância em um processo de desenvolvimento de Software quando os bons resultados começarem a aparecer. Isso faz com que o time adquira a confiança necessária para praticar Scrum. Um grande momento para que os erros e acertos ocorridos durante os Sprints sejam discutidos é a Retrospectiva, tema da próxima seção.
As Retrospectivas
Muita coisa pode acontecer dentro de um projeto de Software ocorrendo em sprints de 3 semanas, por exempo. Certamente, muitas decisões de projetos foram tomadas (técnicas ou não), algumas estratégias não planejadas foram formuladas e muita coisa do que foi planejado deve ter acontecido conforme o esperado. Durante esse tempo foram colecionados acertos e erros. No Scrum existe um momento especial para que os acertos sejam evidenciados e os erros sejam discutidos para que possamos tirar boas lições para o futuro. Esse momento é a Retrospectiva de Sprint. As retrospectivas inerentemente favorecem a Comunicação, proporcionando uma maior interação entre os membros do time.
Algumas premissas devem ser consideradas para que o processo de comunicação ocorra de forma natural durante esses momentos. A primeira premissa é que a retrospectiva não é um momento para eleger culpados por eventuais falhas ocorridas. Uma boa prática é evitar citar nomes durante esse momento, seja ao relatar casos de sucesso ou ao relatar problemas. Tudo que aconteceu durante o sprint deve ser responsabilidade do time como um todo, não importando as individualidades de cada integrante. A segunda premissa é proporcionar um ambiente informal onde as pessoas possam ser estimuladas a expor suas idéias e convicções. Apesar dessas premissas serem tão óbvias, é impressionante como elas podem interferir negativamente para o propósito principal das retrospectivas:
o aprendizado constante em busca da excelência dos processos de desenvolvimento e organização utilizados.
Se as duas premissas básicas (relatadas acima) não forem obedecidas, um clima negativo e de injustiça pode ser criado dentro do time, por responsabilizar uma ou mais pessoas pelo fracasso em algumas tarefas e muitas coisas que aconteceram durante os sprints ficarão guardadas na mente dos participantes porque eles não estavam confortáveis em relatar determinados acontecimentos naquele momento. Portanto, é preciso se preocupar em montar um cenário favorável para as retrospectivas de forma a conseguir extrair o máximo de informação e aprendizado.
Conclusões
O Scrum pode ser considerado um poderoso framework para a organização de times de desenvolvimento de Software. No entanto, é preciso tomar algumas precauções para maximizar esse poder. Uma das grandes preocupações que deve ser considerada é no que diz respeito à comunicação entre as pessoas envolvidas. A forma e o ambiente criado para que as informações possam circular entre as pessoas de um projeto é tão importante quanto os aspectos técnicos necessários para o seu bom andamento. Entretanto, não há um guia perfeito ou um conjunto de regras capaz de garantir que a comunicação seja tão ágil quanto esperamos. Pelo contrário, os aspectos psicológicos envolvendo o modo como cada pessoa se comunica com as outras nos deixa um amplo cenário para que novas experiências sejam postas em prática e posteriormente avaliadas.
Este artigo tenta relatar um guia de boas práticas e experiências que podem fornecer resultados efetivos para o processo de comunicação em projetos de desenvolvimento de Software usando Scrum. Mais importante do que aplicar definições e conceitos é ter em mãos frameworks, como o Scrum, que possibilitam customizar práticas e soluções para a realidade de cada time de desenvolvimento, devendo ser respeitados os seus fundamentos. Scrum diz o que devemos fazer mas deixa na mão dos seus usuários o melhor modo de implementá-lo.
A Comunicação é um dos pilares proposto pelo XP e deve merecer atenção especial em qualquer relação de trabalho envolvendo grupo de pessoas. Ao serem tomados pequenos cuidados, como as iniciativas propostas por esse artigo, entendemos que muito dos pequenos acontecimentos que causam impacto negativo para o bom andamento de projetos de Software podem ser evitados ou terem seus efeitos amenizados, evitando que cada projeto seja contabilizado como mais um fracasso da Engenharia.
Referências:
O Mítico Homêm-Mês - Ensaios sobre a Engenharia de Software
Frederick P. Brooks Jr, Editora Campus, 2009.
Programação Extrema Explicada: Acolha as Mudanças
Kent Beck, Editora Bookman, 2004.
Scrum e XP direto das Trincheiras: Como nós fazemos Scrum
Henrik Kniberg, Disponível livremente em: http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches
Sobre o autor:
Ronaldo Cisneiros Veras é graduado em Engenharia da Computação pela Escola Politécnica de Pernambuco (POLI-PE) e mestre em Ciências da Computação pelo Centro de Informática da Universidade Federal de Pernambuco (UFPE), na área de Reúso e Engenharia de Software. Atualmente atua como Líder Técnico e Scrum Master em projetos agéis de desenvolvimento de Software na Pitang (http://www.pitang.com). Possui também as Certificações Sun Certified Java Programer (SCJP 1.4) e Sun Certified Web Java Developer (SCWCD 1.5).