Scrum em sistemas heterogêneos e equipes distribuídas

Agilidade Nesta seção você encontra artigos voltados para as práticas e métodos ágeis. Scrum em sistemas heterogêneos e equipes distribuídas Utilizando Scrum em um projeto com sistemas heterogêneos e equipes distribuídas: Paulo Henrique dos Santos phscuritiba@gmail.com Graduado em Sistemas de Informação pela PUCPR, Pós Graduado em Banco de Dados Oracle pela FESPPR, Mestrando em Computação Aplicada na UTFPR, trabalha com consultoria em administração e desenvolvimento em SGBDs Oracle e SQL Server, administração de sistemas CRM Siebel 5, 7.8 e 8.0. Roberto Cesar Betini rcbetini@terra.com.br Possui graduação em Engenharia Industrial Elétrica pela Universidade Tecnológica Federal do Paraná (1984) e doutorado em Engenharia - The University Of Electro Communications (1994) em Tóquio. Trabalhou na NEC Security Systems em Toquio como engenheiro de sistemas, no desenvolvimento e implementação de sistemas de reconhecimento automático de impressões digitais desde 1992 até 1994. Adolfo Gustavo Serra Seca Neto adolfo@utfpr.edu.br Bacharel, Mestre e Doutor em Ciência da Computação. Atualmente é professor adjunto da Universidade Tecnológica Federal do Paraná (UTFPR). Suas principais publicações podem ser encontradas em http://lattes.cnpq.br /0071119715272492#ArtigosCompletos. É também desenvolvedor de software livre. O código-fonte de seu demonstrador de teoremas, o KEMS, está inteiramente disponível em http://github.com/adolfont/kems. Cresce rapidamente o interesse nos métodos ágeis dentro das corporações, seja para tentar otimizar o tempo de projeto e entrega do produto final, como também melhorar a interação das equipes quebrando paradigmas de métodos tradicionais. Este artigo descreve uma experiência de desenvolvimento de um projeto, envolvendo não só uma equipe com muitos profissionais alocados em lugares diferentes, mas também uma gama de sistemas completamente heterogêneos. Este artigo descreve uma experiência com a aplicação do método ágil Scrum em um projeto com equipes distribuídas e sistemas heterogêneos. Para tanto, foi necessário identificar os pontos do método que precisaram ser trabalhados de forma adaptada, caso contrário podiam comprometer sua aplicabilidade no desenvolvimento do projeto. Em que situação o tema é útil: É útil para entendermos como utilizar o Scrum na prática, identificando também pontos que talvez precisem ser adaptados na metodologia para possibilitar sua aplicação em projetos de desenvolvimento de software. Em particular, veremos como deu sua aplicação em um projeto com sistemas heterogêneos e equipes distribuídas. M uitas são as preocupações em projetos de desenvolvimento de software: recursos (pessoas), planejamento, organização, gerenciamento e acompanhamento. Mas isso é só a ponta do iceberg. Existem outras dificuldades na implementação de um projeto, por exemplo: alocação de equipes em locais diferentes e sistemas heterogêneos. Quando isso ocorre, o gerenciamento, a interação, o acompanhamento, podem ficar comprometidos uma vez que outros cenários podem surgir dentro do mesmo contexto. Este artigo tem por objetivo descrever uma experiência com a aplicação do método ágil Scrum em um projeto com equipes distribuídas e sistemas heterogêneos. Foi necessário identificar os pontos do método que precisaram ser trabalhados de forma adaptada, caso contrário, podiam comprometer sua aplicabilidade no desenvolvimento do projeto. Serão apresentados os pontos fortes e fracos na aplicação do Scrum, lições aprendidas, como foram adaptados e resolvidos os pontos que não atendiam de forma integral a alguns cenários do projeto. Edição 55 - Engenharia de Software Magazine 5

Scrum e Gerenciamento de Projetos O termo Scrum, para a área de projetos, surgiu a partir de um artigo publicado no início de 1986 por Hirotaka Takeuchi e Ikujiro Nonaka com o seguinte título: The New new product development game. Neste artigo, seus autores descreveram uma abordagem holística, onde as equipes de projetos são compostas por grupos multifuncionais trabalhando rumo a um objetivo comum. Eles comparam esta formação a uma formação do Rugby (esporte coletivo originário da Inglaterra). Neste modelo, a equipe trabalha em constante interação do início ao fim do projeto. Takeuchi e Nonaka também fizeram várias entrevistas com diversos profissionais de organizações líderes de mercado e elencaram seis características comuns no gerenciamento de processos de desenvolvimento de novos produtos: 1. Criação em instabilidade; 2. Auto-organização de equipes de projeto; 3. Fases de desenvolvimento de sobreposição; 4. Multiconhecimento; 5. Controle sutil; 6. Transferência de aprendizagem organizacional. Estas características são como peças de um quebra-cabeça. Cada uma delas por si só não traz a velocidade e flexibilidade desejada, mas a junção destas características produz um novo conjunto de dinâmicas que fazem a diferença no desenvolvimento de projeto. Em 1993, Jeff Sutherland estava trabalhando na construção de uma ferramenta de Análise e Projeto Orientado a Objetos, quando percebeu que sua equipe precisaria aprimorar o método ágil que estavam utilizando. Ele queria um processo em que, ao final das iterações, fosse possível a apresentação de código funcional no lugar de gráficos em papel. Então, utilizaram pela primeira vez o método Scrum para equipes de desenvolvimento de software. Mais ou menos no mesmo período, Ken Schwaber pesquisava sobre como poderia ajudar sua empresa a melhorar seu processo de software com o objetivo de aumentar a produtividade das equipes. Após análise de como outras empresas de software construíam seus softwares, Schwaber percebeu que o processo de desenvolvimento de todas era semelhante, todas usavam processos empíricos que exigiam inspeção e adaptação constantes. A Object Management Group solicitou, em 1995, que Sutherland e Schwaber trabalhassem juntos em um resumo para descrever o que haviam aprendido ao longo dos anos. Com isso, foi desenvolvido um novo método que foi chamado de Scrum, descrito em um artigo de Schwaber com o seguinte título: Scrum and The Perfect Storm. A Figura 1 mostra uma estrutura básica de projeto Scrum, ilustrando equipes, backlogs de produto, release e sprint. Pode-se perceber na ilustração que a equipe de Scrum deve ser uma equipe multifuncional e é composta de um Scrum Master, de um Product Owner e da equipe de desenvolvimento. Mesmo nas situações mais favoráveis, quando a equipe de Scrum é completamente multifuncional, não significa que todos os membros do projeto, em termos organizacional e hierárquico, façam parte da estrutura permanente da equipe de Scrum. A menos que na empresa seja adotado por completo o método ágil Scrum, para desenvolvimento de projetos, as equipes de Scrum serão compostas por profissionais emprestados de outras áreas como: Qualidade, Arquitetura, Suporte, DBAs e talvez outros profissionais conforme a necessidade. Figura 1. Estrutura básica de Scrum com Equipes e Backlog de Produto, Release, Sprint. O Gerenciamento é a parte fundamental de um projeto de desenvolvimento de software. A gestão organizada e estruturada acompanha cada fase do projeto, dando suporte, eliminando barreiras, identificando problemas e direcionando o curso do projeto, possibilitando que o projeto consuma somente os recursos orçados, cada fase seja entregue no prazo determinado, os problemas sejam identificados e corrigidos de forma ágil e que possa atender todos os requisitos de forma completa. Tutorial Estudo de Caso: Escalando Scrum em projeto com sistemas heterogênios e equipes distribuídas O projeto (o qual não será identificado por razões de privacidade), que resultara em um novo produto para um novo 6 Engenharia de Software Magazine - Scrum em sistemas heterogêneos e equipes distribuídas

AgiLidAdE segmento da empresa, surgiu para atender a demanda de um novo produto: TV por assinatura, com canais HD em todos os pacotes, recursos Smart, onde ao mesmo tempo em que se assiste um canal de TV, permite acessar a previsão do tempo, redes sociais e etc. dentro de uma empresa de Telecom de grande porte com uma área voltada para TI, que não será identificada por razões de privacidade, que conta com equipes de funcionários especializados. Como se tratava de um produto novo foram envolvidos vários sistemas em tecnologias diferentes da empresa e consequentemente a mobilização de vários profissionais com conhecimento em cada sistema, para atender as demandas durante todo o processo de análise de requisitos, desenvolvimento, teste de software, até a entrada em produção. A empresa decidiu pela utilização do Scrum porque buscava trabalhar um novo método no processo de desenvolvimento de projetos, por o método anterior (baseado em uma abordagem dirigida por documentação) não atender a necessidade de negócio, onde se trabalha com escopo definido. O método utilizado anteriormente funcionava da seguinte forma: o cliente gerava um documento chamado Product Description que trazia as necessidades do negócio, isso era orçado e se dava andamento ao projeto, destacando que isso funciona quando o escopo é conhecido e validado por todos os envolvidos no projeto. O Scrum se encaixa melhor quando o projeto tem definições que virão ao longo das etapas ou onde os clientes ainda não estão seguros mesmo da parte que já definiram. Assim, a cada validação de sprint, os clientes podem ir moldando e administrando o escopo junto à equipe de TI (Tecnologia de Informação). Além destes pontos, era necessário otimizar ao máximo o prazo de entrega. O projeto envolveu várias áreas da empresa, como, CRM (customer relationship management), Engenharia, Financeira e outros. Cada área desenvolveu mecanismos necessários para interagir com o novo produto. módulo do projeto se reúnam para discutir o andamento do projeto e planejar os próximos passos), para coordenar o trabalho das equipes. Utilizamos isso nas reuniões semanais dos Product Owners, que aconteciam para o follow-up do projeto como um todo. Para que o ambiente ficasse de acordo, permitindo a interação dos profissionais e a gestão adequada, a alocação física das equipes envolvidas foi aproximada. Foram montadas pequenas equipes de cada sistema em dois andares diferentes, mas próximos e em cada andar ficaram as equipes dos sistemas que tinham maior interação. Desta forma, as reuniões e comunicação entre os recursos do projeto se tornaram mais ágeis e assertivas. Ferramentas O Project da Microsoft foi a ferramenta utilizada para acompanhamento gerencial do projeto através da equipe de PMO (Project Management Office - equipe ou departamento dentro de uma empresa), que define e mantém o acompanhamento de padrões para gerenciamento de projetos. O Jira da Atlassian foi utilizado para abertura, acompanhamento e fechamento de chamados entre as equipes e o SVN (subversion) da Apache Software Foundation foi utilizado para o controle de versões e migração de códigos entre os ambientes. Gerenciamento do Projeto Para o apoio no gerenciamento do projeto, foi contratada uma consultoria especializada em Scrum, para treinar os profissionais envolvidos e acompanhar a aplicação do método, além de dois arquitetos de sistemas que já faziam parte da equipe responsável por este projeto na empresa e que possuem forte conhecimento do método Scrum. As equipes foram divididas conforme a definição do método. Foram criados os papéis de Stakeholders, Product Owner, Scrum Master e Equipe de Desenvolvimento. Como este projeto possuía características específicas já mencionadas, utilizamos o Scrum of Scrums, técnica que permite o escalonamento do Scrum em projetos com grande número de profissionais envolvidos. No Scrum of Scrums cada equipe trabalha normalmente, mas em cada equipe tem uma pessoa que deverá frequentar a Scrum of Scrums Meeting (técnica que torna possível utilizar o Scrum para grandes projetos de software; ela permite que as diferentes partes da equipe responsáveis por aplicar o Scrum em cada Edição 55 - Engenharia de Software Magazine 7

Análise Projeto Codificação / Teste Unitário Teste Integrado Figura 2. Testes dentro do processo de software tradicional em cascata Teste Aceitação Usuário Implantação Teste Teste Teste Teste Teste Teste Figura 3. Iterações/Sprints. Nova definição para os testes dentro da estrutura de método Agil/Scrum Desafios Com o grande número de recursos e sistemas envolvidos e com a distribuição das equipes, alguns desafios foram enfrentados neste projeto, como: A documentação com sua abrangência minimizada implica no baixo detalhamento dos processos e implementações, sendo necessária atenção dos times para identificar processos que mereçam uma documentação para uso futuro. Com a formação distribuída das equipes envolvidas, fica difícil a interação de forma efetiva entre os profissionais, uma vez que eles podem estar alocados fisicamente em lugares distantes. Algumas definições podem ficar comprometidas pelo não entendimento correto do escopo ou de parte de algum processo por uma equipe ou por um de seus integrantes. Pelo fato do Scrum propor uma estrutura de gestão de desenvolvimento de software baseada em auto-organização, a responsabilidade de delegar aos membros das equipes o que cada um deve fazer fica a cargo da própria equipe. A comunicação começa a ficar comprometida à medida que as equipes vão se distanciando, devido ao espaço físico ser insuficiente para comportar uma equipe com grande número de pessoas. Diferentemente do ciclo de vida em cascata, onde o teste de aceitação do usuário é realizado ao final do ciclo de vida, no Scrum, os testes são realizados ao longo das diferentes iterações e sprints. As Figuras 2 e 3 mostram estas iterações nos dois modelos. Na Figura 2, que representa o ciclo de desenvolvimento em cascata, podese perceber que o teste de aceitação é efetuado no fim do ciclo de vida do desenvolvimento, após as fases de análise, projeto, codificação/ teste unitário e teste integrado. Na Figura 3, que representa o modelo Scrum, os testes ocorrem a cada iteração. Os testes, apresentados na Figura 3, são incorporados ao longo das iterações e sprints. Adequações A seguir são apresentadas as adequações no método Scrum que foram realizadas pela organização para atender o contexto do projeto. Escopo de Documentação Na maior parte do projeto as próprias estórias serviram de documentação. Fica a cargo dos arquitetos da empresa e do time de desenvolvimento, indicar os casos em que uma documentação mais formal fosse necessária, o que aconteceu para itens mais complexos ou que precisariam ser repassados a outros times da empresa, por outros projetos estarem em implementação ou sendo iniciados. Com o escopo bem definido, outros projetos recebiam as informações necessárias para que não fossem impactados. Trabalho com as equipes As equipes procuraram seguir os princípios básicos do Scrum listados abaixo: Reuniões diárias de 15 minutos todas as manhãs em cada time; Reunião de planejamento para obter a macroestimativa para pontuação das estórias no meio da semana, o que é importante para o planejamento da semana seguinte; Reunião nas sextas-feiras para review da semana, em que todo o time comentava o que havia acontecido de bom, de ruim, fatos significativos e pontos a melhorar para as próximas sprints; Reunião semanal de Product Owners para alinhamento das sprints e analisar dependências de requisitos; Os releases e sprints eram planejados e alinhados semanalmente com os clientes, para ir adaptando o escopo ao prazo, mas sempre seguindo um planejamento geral para todo o projeto; Cada equipe tinha suas reuniões em separado semanalmente. E os Scrum Masters se reuniam com a gestão (gerente e coordenador) para repasse geral do andamento do projeto; O Gráfico de burndown (utilizado para monitorar o progresso de um time ágil representando a quantidade de trabalho que falta ser feito e o tempo necessário) recebeu uma adaptação devido a forma de controle exigida no projeto, mas manteve basicamente as mesmas informações do método original; A equipe de Finanças não pode usar totalmente o Scrum, porque eles tinham características de trabalho diferenciadas, como alguns calendários próprios de atividades que geravam dependências dentro do projeto e estas atividades não podiam ser migradas para este método apenas por causa deste projeto. 8 Engenharia de Software Magazine - Scrum em sistemas heterogêneos e equipes distribuídas

AgiLidAdE Gestão do Projeto Foi seguido em quase todos os times o método Scrum, com exceção da equipe de Finanças que não pode aderir 100% ao Scrum. Esta equipe, porém, adotou outro método ágil, Kanban (tem como principal objetivo transformar o trabalho em andamento visível para toda equipe, criando um sinal visual que indica que o novo trabalho pode ou não ser iniciado e se o limite acordado para cada fase está sendo respeitado), para o desenvolvimento e integração ao projeto. Comunicação Efetiva Enquanto não foi possível juntar as equipes no mesmo espaço e todos se adaptavam ao método, houve algumas falhas de comunicação. Nesses momentos foi usada a experiência da consultoria em Scrum para orientar na forma adequada de tratar os pontos de conflito. Assim, foi possível aos times maior interação e todos passaram a entender o método. Alguns times como o de Finanças e QA (garantia da qualidade) - programa de acompanhamento sistemático e avaliação dos diferentes aspectos de um projeto, serviço ou facilidade para garantir que os padrões de qualidade estão sendo cumpridos - tiveram de ficar afastados por questões físicas, mas por estarem alinhados com as demais áreas não houve maiores problemas. Arquitetura dos Ambientes Como o método sugere um ambiente de testes diferenciado, onde os testes ocorrem a cada iteração e sprint, foi criado um novo ambiente de testes e adaptado ao Scrum, para que o projeto não sofresse impacto ao ser testado em um ambiente preparado para o método integrado tradicional. Pontos Fortes e Fracos Listamos abaixo os pontos fortes e fracos identificados na adoção do Scrum neste projeto. Pontos Fortes: - Troca de informações constante entre as equipes, pois as reuniões diárias e a aproximação do espaço físico das equipes permite maior interação; - Oportunidade para analistas mais novos, pois ao estruturar as equipes com analistas de nível de conhecimento diversificado e com a interação constante entre estes profissionais, as pessoas com menos experiência conseguem enriquecer o conhecimento interagindo com analistas mais experientes; - Possibilidade de negociação de escopo de entrega com o cliente. Em vários momentos do projeto os clientes descobriram e solicitaram novos itens prioritários do ponto de vista do negócio, mas esses itens não cabiam no prazo de entrega do projeto. Com o Scrum é fácil rastrear itens de menor prioridade, informar o custo e propor trocas ou alterar a data de entrega do projeto. Essas negociações também podiam levar a determinar fases de entregas diferentes (entrega em releases diferentes), por exemplo, fase 1 para itens principais e que serviriam para um teste piloto, fase 2 para itens desejáveis, mas não impeditivos para início da operação, fase 3 para itens de menor prioridade, que agregam valor ao processo; - Permite saber o que entregar em cada sprint. Nos processos tradicionais, o gerente de projeto geralmente organiza reuniões semanais para acompanhar o estado do projeto, no Scrum, uma equipe se reúne diariamente para inspecionar o progresso rumo ao objetivo da sprint; - Visibilidade de cada etapa do projeto a partir de gráficos. Um exemplo importante para manter o registro do progresso da equipe é o Gráfico de Burndown, que mostra quanto de trabalho ainda resta até que a equipe tenha terminado a sprint; - Motivação do pessoal com a visão do que está acontecendo no projeto. As equipes interagem constantemente em reuniões diárias, assim ficam informadas de todas as ocorrências dentro do projeto; - Alguns vícios de trabalho de analistas se perdem com a mudança da forma de acompanhamento. O modelo de equipe trabalhado neste método é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade, não existindo espaço para comodidade; - Contribui para o gerenciamento de risco com seu ciclo frequente de inspeção e adaptação, fazendo um uso mais eficiente do tempo produtivo. Pontos Fracos: - Documentação com pouca abrangência, o que implica em baixo detalhamento. Uma vez que os métodos ágeis focam na comunicação constante, produzindo pouca documentação em relação aos métodos tradicionais, sendo considerada somente a documentação realmente necessária. - Algumas barreiras para trabalhar com grande número de pessoas de forma distribuída. O Scrum sugere uma equipe multifuncional com cerca de oito pessoas para a análise de requisitos, implementação, testes e etc. Mas como trabalhar com uma equipe reduzida em um projeto envolvendo mais de 20 sistemas e uma equipe com mais de 100 pessoas? Neste caso, foi usado o conceito Scrum of Scrums, conforme mencionado neste artigo. Lições Aprendidas Algumas lições aprendidas durante o uso e adaptação do Scrum neste projeto foram: Como o método tradicional ainda é forte na cabeça das pessoas que fazem parte da área de projetos na empresa, é importante ter alguém ou alguma estrutura garantindo que o Scrum não perca sua essência durante o desenvolvimento; O método Scrum permite uma interação funcional constante ao longo do projeto, superior a métodos tradicionais; O método pode assustar os clientes no início, porque esperam um documento formal com o que vai ser construído e como não recebem a documentação desta forma, deve-se mostrar como será o trabalho com as estórias e sprints e habituá-los apresentando claramente como serão feitas as estórias, sua avaliação, construção e pré-uats (Teste de aceitação pelo cliente (UAT - User Acceptance Testing), termo usado para apresentação Edição 55 - Engenharia de Software Magazine 9

10 Zanoni, R. (2002). Modelo de Gerência de Projeto Baseado no PMI para ambientes de Desenvolvimento de Software Fisicamente Distribuído. Dissertação de Mestrado, PUC/RS, Porto Alegre, RS, Brasil. Takeuchi, H.; Nonaka I. (1986). The New New Product Development Game. Havard Business Review, Boston, MA, USA. Costa C.; Rocha R.; Brito R.; Silva F. Q. B.; Prikladnicki R.; Meira S. (2010). Gerenciando um Projeto Distribuído: Lições Aprendidas. PUC/RS, Porto Alegre, RS, Brasil. Sutherland, Jeff. Agile Development: Lessons learned from the first Scrum, 2004. http://www.scrumalliance.org/resources/35 Schwaber, Ken. Scrum and The Perfect Storm, 2003. http://www.controlchaos.com/my-articles/ PHAM, Andrew; PHAM, Phuong-Van. Scrum em Ação. São Paulo: Novatec Editora Ltda, 2012. Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback Engenharia de Software Magazine - Scrum em sistemas heterogêneos e equipes distribuídas Feedback eu sobre e s O método Scrum é um mecanismo que contribui para a redução de riscos em projetos, é um processo de software enxuto, seu processo de gestão é adaptável nos diferentes cenários de desenvolvimento de sistemas, trabalha no modelo de autoorganização e isso motiva a equipe que está trabalhando, por tirar a figura de gerente de projeto e colocar a do Scrum Master que atua com foco em garantir que o Scrum seja aplicado e eliminar possíveis obstáculos para o bom andamento do projeto. Como o Scrum não pode ser utilizado em todos os contextos sem que seja necessário um tipo de adaptação, é importante se aprofundar na metodologia de desenvolvimento ágil, para entender melhor como adaptar o Scrum ao cenário de projeto em questão. Com a atuação neste projeto, todos os profissionais envolvidos puderam entender melhor como o método Scrum funciona e como sua aplicação correta pode beneficiar, agilizando e organizando o desenvolvimento de softwares complexos como foi este caso. Binder, J. C. (2007). Global Project Management: Communication, Collaboration and Management Across Borders. Gower Publishing. Dê s Conclusão Referências edição ta do software ou parte dele para o cliente, onde são testadas e avaliadas as funcionalidades pelo cliente para aceitação) de cada sprint. Deve-se mostrar desde o início as vantagens do método e garantir que os clientes estejam cientes que está acontecendo, gerando assim segurança, e evitando desgastes desnecessários. O cliente deve sentir que, no método Scrum, ele tem mais flexibilidade, podendo mudar o escopo acordado com a gestão do projeto.