AVALIAÇÃO DO IMPACTO DO SCRUM NO DESENVOLVIMENTO DE SOFTWARE UTILIZANDO A ANÁLISE SWOT

Transcrição

1 XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO Maturidade e desafios da Engenharia de Produção: competitividade das empresas, condições de trabalho, meio ambiente. São Carlos, SP, Brasil, 12 a15 de outubro de AVALIAÇÃO DO IMPACTO DO SCRUM NO DESENVOLVIMENTO DE SOFTWARE UTILIZANDO A ANÁLISE SWOT Mariana de Azevedo Santos (DCC/UFLA) marianaazsantos@yahoo.com.br Juliana Galvani Greghi (DCC/UFLA) juliana@dcc.ufla.br Paulo Henrique de Souza Bermejo (DCC/UFLA) bermejo@stela.ufsc.br Esse artigo relata um estudo de caso de caráter exploratório e qualitativo, sobre a adoção da metodologia de desenvolvimento ágil de software Scrum em um laboratório de pesquisa e desenvolvimento de software para o setor florestal. O objetiivo da pesquisa é avaliar o impacto que a adoção do Scrum traz para a organização, utilizando como método de análise qualitativa, o framework de análise de gestão e posicionamento estratégico SWOT. O resultado é exibido em uma matriz, denominada matriz SWOT, que contempla os pontos fracos e fortes da adoção do Scrum, bem como as oportunidades a serem aproveitadas no mercado de software e as ameaças enfrentadas. Palavras-chaves: Scrum, SWOT, metodologias ágeis, desenvolvimento de software, gestão de projetos

2 1 Introdução O desenvolvimento de software é um processo complexo (SCHWABER, 2004). Neste contexto, a importância das metodologias ágeis de desenvolvimento de software tem sido destacada nos estudos de (DYBÅ & DINGSØYR, 2008), (MANN & MAURER, 2005), (ERICKSSON et al., 2005), (ABRAHAMSSON et al., 2002), (WILLIAMS & COCKBURN, 2003), pois elas detêm um paradigma, uma conceituação mais simples e objetiva que a abordagem tradicional, buscando focar em menos documentação, resposta rápida a mudanças de requisitos, uma ativa colaboração do cliente, além de permitir a minimização de riscos de desenvolvimento (AGILE MANIFESTO, 2009). Uma dessas metodologias ágeis de desenvolvimento de software, em particular, o Scrum, vem tornando-se popular entre as empresas nos últimos anos por atender dois fatores: satisfação do cliente e rapidez nas entregas em relação às metodologias tradicionais (MANN & MAURER, 2005). A grande motivação do estudo é insuficiência de uma revisão detalhada das capacidades e limitações que podem ser usados como base para identificar áreas de melhoria nas metodologias ágeis (SHAHIR et. al, 2008) e principalmente, uma revisão detalhada das capacidades e limitações do Scrum. A segunda seção descreve a metodologia de análise. A terceira seção apresenta uma pesquisa da metodologia Scrum e a quarta, uma pesquisa sobre análise SWOT. A quinta seção descreve o estudo de caso realizado e a última seção apresenta e discute o resultado do estudo, resumindo as propostas futuras à concepção da pesquisa. 2 Metodologia O presente estudo é de caráter exploratório, de abordagem qualitativa. O meio de obtenção de dados foi o uso de entrevistas com os membros da equipe de TI do laboratório em pesquisa. Para chegar aos resultados foi utilizada a ferramenta de análise estratégica SWOT (também conhecida como análise FOFA). O objetivo da aplicação do SWOT no estudo é conseguir entender o impacto que a aderência da metodologia Scrum traz à organização e, a partir da análise, definir quais aspectos culturais da organização em estudo, que produz softwares na área de engenharia florestal, podem ser mudados ao aplicar o Scrum, trazendo para a organização um melhor aproveitamento e aprendizado em desenvolvimento de software utilizando tal metodologia. 3 Scrum Scrum é uma metodologia ágil e também definida como um framework interativo e incremental de desenvolvimento de projetos de software. A princípio, ela foi idealizada como um modelo de gerenciamento de projetos em indústrias automobilísticas e de produtos de consumo (TAKEUCHI & NONAKA, 1986). O nome Scrum deriva-se de uma estratégia usada no rúgbi para o reinício do jogo, com características similares ao método de desenvolvimento proposto. Em 1993, a metodologia foi 2

3 concebida e implementada por Jeff Sutherland, John Scumniotales e Jeff McKenna, sendo formalmente definida e documentada em 1995 por Ken Schwaber e Jeff Sutherland. Segundo Schwaber e Beedle (2002), o Scrum tem como objetivo gerenciar e controlar processos de desenvolvimento de software, focado em pessoas e que seja indicado para ambientes com frequente mudança de requisitos. De acordo com Beedle et al. (2000), todo o funcionamento do Scrum é estruturado em ciclos chamados Sprints, que são iterações de trabalho que duram de duas a quatro semanas. A metodologia estabelece também um conjunto de práticas e regras que devem ser cumpridas pela equipe, em seus respectivos papéis, para que o projeto seja bem sucedido. Schwaber e Beedle (2002) definem que o Scrum possui três papéis: o Product Owner representa o cliente no projeto. Define funcionalidades de acordo com o valor de mercado, planeja e faz a lista de prioridades, conhecido Product Backlog, que deverão ser cumpridas no projeto dependendo da duração do mesmo; o Scrum Master, moderador entre os interesses do time de desenvolvimento e do cliente. Sua responsabilidade é manter a equipe funcional e produtiva, resolver qualquer tipo de impedimento entre o Team e garantir que o processo esteja no andamento adequado, incluindo a abertura das cerimônias, também chamadas de práticas Scrum: o Daily Meeting (reunião diária do projeto), Sprint Review (reunião de balanço ao final de cada Sprint) e dos Sprint Planning Meetings (reunião onde define as atividades que deverão ser cumpridas no projeto por completo); e o Team, que é o time responsável pelo desenvolvimento do projeto. Ele é multidisciplinar e é composto por um grupo de cinco a nove integrantes. É delegada a ele qualquer função dentro do Sprint desde que cumpra o prazo limite. Deve mostrar os resultados do projeto em andamento para o Product Owner durante as formalidades. O trabalho dentro do Sprint é monitorado pelo Burndown Chart, que é um gráfico que estima o tempo gasto no andamento do trabalho dentro do Sprint. Um termo que vem se tornando comum dentro das organizações que adotam a metodologia é o Scrumbut. Segundo Schwaber e Aguanno (2009), Scrumbut é quando a organização adota o Scrum, mas o modifica, usando a lógica Nós usamos Scrum, mas tivemos que mudá-lo porque na nossa empresa.... E essas customizações inapropriadas podem causar riscos para a organização. Na Figura 1, pode-se visualizar o funcionamento geral do método. Em primeiro lugar, o Product Owner e o cliente definem o backlog. A partir dele, são determinados quais são os requisitos que devem ser priorizados no Sprint. Durante os Sprints são realizados os Daily Meetings, reuniões diárias onde o time compartilha uns com os outros o andamento do projeto. Ao final do Sprint, o Scrum Team entrega um incremento funcional do projeto ao cliente que junto ao Product Owner, redefine os requisitos, a priori, de acordo com os seus interesses. 3

4 4 SWOT Figura 1 Visão geral da metodologia Scrum (adaptado de MARÇAL et al., 2008) A análise SWOT é uma ferramenta de análise de cenário ou análise de ambiente utilizado para definir o posicionamento estratégico de uma empresa (ARMSTRONG, 1996). Geralmente, é utilizada no marketing e no planejamento estratégico, mas pode ser utilizada para analisar qualquer tipo de cenário empresarial (SHAHIR et. al, 2008). O termo SWOT tem origem no inglês e é uma sigla de strengths, wakeness, opportunities e threats (Shahir et. al, 2008), que em português significam forças, fraquezas, oportunidades e ameaças, respectivamente. A origem e concepção da técnica é datada nos anos 60 (LEARNED et al., 1965). Porém, Tarapanoff (2001, p. 209) afirma que SWOT já era utilizada há mais de três mil anos pelo estrategista militar chinês Sun Tzu, na epígrafe: Concentre-se nos pontos fortes, reconheça as fraquezas, agarre as oportunidades e proteja-se contra as ameaças. O termo SWOT estuda o ambiente e a competitividade de uma organização, baseada nos seguintes aspectos (OLIVEIRA, 2001): Ponto forte: é a diferenciação conseguida pela empresa (variável controlável) que lhe proporciona uma vantagem operacional no ambiente empresarial. Ponto fraco: é a situação inadequada da empresa (variável controlável) que lhe proporciona uma desvantagem operacional no ambiente empresarial. Oportunidade: é a força ambiental incontrolável pela empresa, que pode favorecer a sua ação estratégica, desde que conhecida e aproveitada satisfatoriamente enquanto perdura. 4

5 Ameaça: é a força ambiental incontrolável pela empresa, que cria obstáculo à sua ação estratégica, mas que poderá ou não ser evitada, desde que conhecida em tempo hábil. O resultado da análise é disposto em uma matriz chamada Matriz SWOT. Ela fundamental na análise de uma situação e o desenvolvimento de estratégias e táticas, de acordo com o cenário identificado. 5 Estudo de Caso Como objetivo de coletar informações relevantes sobre o assunto estudado, foi realizado um estudo de caso de caráter exploratório em um laboratório de pesquisa localizado em Lavras, Minas Gerais. O objetivo da pesquisa é analisar o impacto que a adoção da metodologia Scrum trouxe para o laboratório, através de dados qualitativos obtidos em entrevistas com a equipe de TI do laboratório em pesquisa. A organização estudada é um laboratório de pesquisa e desenvolvimento de software no setor florestal. Inicialmente, adotava-se a metodologia de desenvolvimento em cascata, que é uma abordagem clássica, sistemática e sequencial, que se inicia na especificação dos requisitos pelo cliente, planejamento do projeto, modelagem, desenvolvimento e implantação do software e culminando na manutenção progressiva do software (Sommerville, 2006), usando como suporte algumas noções de gerência de projetos do PMBOK (2008), que é um guia de referência contendo um conjunto de boas práticas a serem seguidas ao gerenciar projetos. A proposta de adoção do Scrum surgiu no início de 2009, período em que o laboratório enviou seus funcionários para treinamento, prática adotada anualmente. Apresentados à metodologia, o chefe de TI, acompanhado de um funcionário fizeram os treinamentos oficias da SCRUM ALLIANCE de Scrum Master e Product Owner, respectivamente. Após o treinamento, o conhecimento adquirido foi repassado para os demais membros do laboratório através de palestras. O cliente, que é uma empresa pública, também foi treinado e capacitado em Scrum. Houve resistência na aceitação do método pela falsa impressão de que metodologias ágeis são desorganizadas. Entretanto, vencida a resistência, a adoção foi positiva. Outro ponto importante que o chefe de TI levantou foi a dificuldade de cobrar dos funcionários os deveres diários do Scrum e viu a necessidade de formar Scrum Masters dentro do laboratório, pois ele viaja com bastante freqüência, o que torna difícil o monitoramento das práticas do Scrum pela equipe. Ainda segundo o chefe de TI, o Scrum melhorou o desempenho do laboratório no desenvolvimento de projetos. Além de conquistarem a confiança do cliente, começaram a receber mais propostas em relação ao concorrente que ainda adota o modelo cascata. Outros aspectos do Scrum no laboratório foram abordados através das entrevistas concedidas pelos membros das equipes dos projetos da empresa. Os membros foram divididos em duas equipes A e B, que trabalham nos projetos que serão chamados de projeto A, projeto B e projeto C. Porém, deve ser esclarecido que o laboratório trabalha com multi-equipes, ou seja, os integrantes estão escalados em uma ou mais equipes, trabalhando em um ou vários projetos. A equipe A ficou encarregada dos projetos A e B e a equipe B ficou encarregada do projeto C. 5

6 5.1 Projeto A O projeto A foi um software sobre inventário de resíduos industriais. Esse projeto possui uma peculiaridade. A princípio não foi utilizado nada específico como metodologia, mas de acordo com o Scrum Master 1, aplicou-se Scrum ao final do projeto. O Scrum Master 1 relatou que neste projeto inicialmente a equipe não utilizou nenhuma metodologia de desenvolvimento. Percebeu-se que o projeto estava 60% concluído e nem todos os requisitos prometidos cumpridos. Essa necessidade do laboratório coincidiu com a volta dos funcionários do treinamento oficial. Então, o projeto foi finalizado com o uma adaptação do Scrum nos moldes do laboratório, já que a equipe ainda não havia sido treinada. Nessa fase de implantação, segundo o Product Owner do projeto, os Sprints não eram bem sucedidos, sempre ultrapassavam o tempo estimado nas tarefas. Um ponto importante a ser levantado nesse projeto, é que a partir das mudanças ocasionadas nesse projeto, o laboratório passou a adotar Scrum como metodologia de desenvolvimento de software e gestão de projetos, alguns projetos seguindo as recomendações, outros com várias adaptações. Mesmo adaptado, o Scrum denotou uma melhora em relação ao processo de produção do software e a equipe insiste que não deixa essas diversas adaptações transformarem o Scrum em Scrumbut. 5.2 Projeto B O projeto B, sobre gases do efeito estufa, foi planejado e implementado utilizando Scrum. Os Sprints começaram a sofrer variações no tempo estimado para cumprir tarefas. Essas variações podem ser explicadas pela falta de experiência da equipe, já que o projeto B foi um dos primeiros projetos com Scrum. Os problemas enfrentados foram relacionados a este primeiro contato dos membros da equipe com a metodologia e a dificuldade dos mesmos de abandonar velhos conceitos. O Scrum Master 1 relatou a dificuldade de cumprir vários papéis dentro do Scrum e que mesmo possuindo horários bem delimitados para alternar-se nas funções, a mudança acaba afetando sua produtividade. Apesar dos problemas enfrentados, foram observados benefícios. O resultado do Scrum, que é o software, o produto final, é mais rápido, o que garante uma melhor transparência frente ao cliente. O Scrum melhora a comunicação entre os membros do time, faz com que a rotina de trabalho seja mais organizada e esteja mais atenta aos prazos, obrigações e expectativas dos clientes. Desenvolver em fatias e alterá-las é muito mais prático e eficiente que desenvolver o sistema por completo e tentar encaixar as várias alterações no produto final. O Scrum ocasionou uma melhora significativa no desempenho do laboratório. 5.3 Projeto C O projeto C é um sistema de controle de qualidade de água. O Scrum Master do projeto, identificado como Scrum Master 2, não possui certificação em Scrum. Ele comentou que ao planejar os Sprints houve muitos problemas em relação à comunicação, o que afetava gradativamente na estimativa de tempo para cumprir os requisitos. Mas depois, a equipe conseguiu alcançar as metas à medida que entendia melhor o funcionamento do Scrum. O Scrum Master 2 relatou que a adoção de Scrum pelo laboratório foi interessante, porque a organização começou com poucas pessoas na parte de TI, o que fortaleceu a cultura 6

7 Ameaças Ambiente Externo Oportunidades organizacional no processo de desenvolvimento. Muitos dos grandes projetos que o laboratório desenvolveu, ou seja, projetos legados são considerados carros-chefes e deve-se dar continuidade. A questão é que, uma vez que há a necessidade de prestar serviços ligados a esses softwares, as atividades que envolvem Scrum param por completo. Apesar desses problemas, o Scrum Master 2, que não é adepto às práticas de Engenharia de Software, relatou que o Scrum é flexível, o que facilita a sua adequação ao método de trabalho. Houve um progresso na melhoria dos processos em relação aos projetos A e B, as práticas do Scrum, principalmente as reuniões em que o Team participa, começaram a ser cumpridas mais formalmente. O chefe de TI e o Product Owner 2 levantaram a possibilidade de adotar alguma outra metodologia ou modelo de melhoria na qualidade de processos, como CMMI e MPS-BR, juntamente com o Scrum. O objetivo seria organizar melhor os processos, trazendo maior robustez ao laboratório e uma documentação mais consistente. 6 Resultados e discussão A partir das entrevistas foram identificados alguns pontos a serem analisados. Organizando os fatores na Matriz SWOT, pode-se obter o seguinte resultado: Matriz SWOT Pontos Fortes Ambiente Interno Pontos Fracos A satisfação dos clientes; Scrum traz rapidez nos processos, então a demanda com o cliente aumentou; Scrum melhorou o canal de comunicação do Team; Os desenvolvedores possuem maior controle de suas tarefas; Por ser incremental, o progresso dos projetos fica mais visível para os clientes; Falta de maturidade no processo; O laboratório se capacitar em CMMI ou MPS-BR para atingir o nível de maturidade, mínimo necessário; Investimento na capacitação dos funcionários com competências sociais notáveis, nos treinamentos oficiais de Scrum Master e Product Owner; Scrum foi uma tentativa por parte do laboratório de deixar uma metodologia informal e de baixa maturidade; Mesmo com o treinamento em Scrum, o laboratório ainda possui o vício em velhas práticas, apoiadas pela forte cultura organizacional; Uso excessivo de Scrumbut; Se o concorrente adotar alguma metodologia ágil e já tiver maturidade nos processos, pode conquistar o mercado e o laboratório perder; 7

8 Tabela 1 - Matriz SWOT O resultado esperado pelo estudo era a avaliação do impacto da adoção do Scrum, sendo ele positivo ou negativo. Diante da análise apresentada na matriz SWOT, percebe-se que a adoção trouxe como benefícios (pontos fortes) ao laboratório em pesquisa: Transparência das atividades do projeto perante o cliente; Maior rapidez em seus processos; Melhoria na comunicação entre os membros da equipe. Aumento da produtividade; Entretanto, o laboratório falha nas perspectivas internas, ao utilizar em excesso o Scrumbut e não o Scrum em sua essência. Schwaber (2008) afirma que o Scrum expõe as disfunções do produto e das práticas de desenvolvimento para que estas possam ser corrigidas. A postura do laboratório é oposta. Assim, pode-se concluir que o impacto gerado pela adoção do Scrum foi positivo quanto aos fatores gestão de pessoas, produtividade e dinâmica nas atividades do projeto. Porém, a imaturidade e ineficiência em seus processos de planejamento e desenvolvimento de software sugerem dificuldade em atingir a excelência e robustez dos processos do laboratório, ameaçando a qualidade do produto final. Pode-se avaliar como impacto negativo o uso do Scrumbut, postura que deriva de uma forte cultura organizacional, onde o laboratório impõe seus valores às práticas do Scrum e, alguns deles, não produtivos. A flexibilidade na adaptação do Scrum deve ser coerente e com limites. Adotar um modelo de referência ou melhoria na qualidade de processos como CMMI ou MPS-BR, juntamente com o Scrum, pode ser uma oportunidade viável para alcançar maturidade e eficiência em seus processos. Porém, esta análise pode ser feita em estudos futuros. 7 Conclusão Os resultados obtidos do estudo de caso e da análise SWOT confirmam a proposta inicial da pesquisa, ao mostrar avaliação dos impactos tanto positivos e quanto negativos da adoção do Scrum como metodologia de desenvolvimento de software no laboratório em estudo. Em síntese, o presente estudo de caso contribuiu para área de Engenharia de Software identificando o impacto da adoção da metodologia Scrum no desenvolvimento de produtos de software e os benefícios alcançados para a organização, se esta aplicar a metodologia adequadamente. Para a área de Engenharia da Produção os resultados do estudo contribuíram para a análise do desempenho de um produto de software e quais impactos sofrem o produto final, se não há um comprometimento com a metodologia Scrum. Essencialmente, para a área de Gestão de Projetos, o estudo contribuiu mostrando que a adoção de Scrum pode proporcionar um gerenciamento mais dinâmico e transparente de projetos de software. Entretanto, para que a pesquisa e os resultados desse estudo de caso comprovem um valor de uso da metodologia Scrum, propõe-se a elaboração de uma análise mais aprofundada, utilizando uma combinação de métodos qualitativos e quantitativos, aplicados a uma 8

9 amostragem de organizações nacionais e internacionais que utilizam a Scrum como metodologia de desenvolvimento de produtos de software. 8 Referências ABRAHAMSSON, P.; SALO, O.;RONKAINEN, J.; WARSTA, J.; Agile software development methods: review and analysis, VTT Technical report, AGILE MANIFESTO. disponível em 10/10/09. ARMSTRONG, M., Management Processes and Functions, CIPD, London, BEEDLE, M., DEVOS, M., SHARON, Y., SCHWABER, K., SUTHERLAND, J., SCRUM: An extension pattern language for hyperproductive software development, Pattern Languages of Software Design 4, DYBA, T.; DINGSØYR, T. Empirical studies of agile software development: A systematic review. AGILE 08. Volume 50, Issue 9-10, Aug Page(s): AGILE Conference, ERICKSON, J.; LYYTINEN, K.; SIAU, K. Agile Modeling, Agile software development, and extreme programming: the state of research, Journal of Database Management 16 (4) (2005) JAKOBSEN, C.R.; SUTHERLAND, J. Scrum and CMMI Going from Good to Great. AGILE 09. Volume, Issue 24-28, Aug Page(s): Agile Conference, LEARNED, E.P., CHRISTENSEN, C.R., ANDREWS, K.E., GUTH, W.D. Business Policy: Text and Cases. Irwin, Homewood, II, MANN, C., MAURER, F. A case study on the impact of scrum on overtime and customer satisfaction. Agile Development Conference, p IEEE Computer Society MARÇAL, A.S.C.; DE FREITAS, B.C.C.; FURTADO SOARES, F.S.; MACIEL, T.M.; BELCHIOR, A.D. Blending Scrum practices and CMMI project management process areas. Innovations Syst Softw Eng (2008) 4: MOUNTAIN GOAT SOFTWARE. - disponível em 24/09/09. OLIVEIRA, D.P.R. Planejamento estratégico Conceitos, metodologia e práticas. Editora Atlas, 15ª edição, PMBOK Guide. Project Management Body of Knowledge (PMBOK Guide). 4ª Edition, SCHWABER,K. Agile Project Management with Scrum. Microsoft Press, 2004; SCHWABER, K., BEEDLE, M. Agile Software Development with Scrum. Prentice Hall, SCHWABER,K. Interview with Ken Schwaber: depoimento [19 de fevereiro de 2008]. AGILECOLLAB: - disponível em 03/11/09. Entrevista concedida a AGILECOLLAB. SCHAWABER,K., AGUANNO, K. ScrumButs: The Dangers of Customizing Scrum. Audio CD, 60 min SCRUM ALLIANCE. What is Scrum? - disponível em 24/09/09. SHAHIR, H. Y.; DANESHPAJOUH, S.; RAMSIN, R.: Improvement Strategies or Agile Processes: A SWOT Analysis Approach, Proc. of the SERA Conference 2008, pp SOMMERVILLE, I. Engenharia de Software. Pearson, 8ª edição, TAKEUCHI, H.; NONAKA, I. The New New Product Development Game, Harvard Business Review, TARAPANOFF, K. Inteligência organizacional e competitiva. Brasília: Editora Universidade de Brasília, 2001; TURNER, R.; JAIN, A. Agile Meets CMMI: Culture clash or common cause. P XP/Agile Universe WILLIAMS, L. ; COCKBURN, A. Agile software development: it s about feedback and change, IEEE Computer 36 (6) (2003)