MÉTODOS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE: UM CASO PRÁTICO DE APLICAÇÃO DO SCRUM

Transcrição

1 MÉTODOS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE: UM CASO PRÁTICO DE APLICAÇÃO DO SCRUM Carlos Eduardo Costa de Carvalho (UFRJ) Carolina Thome de Abrantes (UFRJ) Renato Flórido Cameira (UFRJ) Os ciclos de inovação tecnológica cada vez mais curtos têm exigido das empresas flexibilidade e agilidade na entrega de seus produtos. Na indústria de software, porém, os resultados entregues pelos projetos de desenvovimento de sistemas de informação estão aquém do valor esperado. Neste contexto, surgiram os métodos ágeis de desenvolvimento de software com a proposta de fornecer maior agilidade de resposta e flexibilidade de adaptação para as empresas que desejam ter a velocidade e qualidade de entrega como diferenciais competitivos. O Scrum, método ágil que tem se destacado nos últimos anos, tem suas bases em conceitos tradicionais da engenharia de produção como a filosofia enxuta e a teoria das restrições. Assim, o objetivo deste artigo é apresentar um estudo de caso sobre a utilização do Scrum em uma empresa do setor de software nacional embasado no referencial teórico sobre o tema. Será tratado o processo de análise e identificação de problemas da situação atual da empresa e a aplicação do método em questão. Ao final, serão apresentados os principais resultados obtidos, as limitações encontradas e conclusões que visam embasar novas iniciativas de aplicação do Scrum. Palavras-chaves: Desenvolvimento Ágil, Scrum, Empresa de Software, Teoria das Restrições, Produção Enxuta

2 1. Introdução O atual padrão de competitividade tem destacado organizações que tenham conseguido, através do lançamento de novos produtos e serviços, acompanhar ciclos de inovação cada vez mais acelerados no mercado. Segundo Senge (1990), a real vantagem competitiva das organizações é sua habilidade em aprender mais rapidamente que a concorrência, em gerar e compartilhar conhecimento e melhorar de forma contínua sua atuação. Neste contexto, os ciclos de inovação tecnológica se destacam nas últimas décadas. O tempo entre o lançamento de novos produtos e serviços de tecnologia tem diminuído e as empresas que se deparam com os desafios de aprendizado e lançamento de novidades no mercado. Porém, as tentativas de melhoria em relação aos resultados e ao tempo de entrega de projetos de software não têm gerado os resultados esperados. Uma pesquisa divulgada pelo The Standish Group (2009) demonstra que apenas 32% dos projetos de software obtiveram sucesso em Dos restantes, 44% foram entregues com problemas e 24% fracassaram. Em outra pesquisa divulgada pelo mesmo instituto em 2006, constata-se que 45% das funcionalidades entregues nunca foram utilizadas e apenas 7% são realmente utilizadas no dia-a-dia. Estes números revelam um cenário desfavorável relacionado à real entrega de valor proporcionada por projetos de desenvolvimento de software. Este cenário se torna ainda mais crítico frente à necessidade de constantes inovações para o alcance de posições de destaque no mercado, conforme colocado anteriormente. Assim, nos últimos 20 anos, novos métodos de desenvolvimento de sistemas de informação surgiram com a proposta de fornecer maior agilidade e flexibilidade para as empresas. Dentre estes métodos, destaca-se o Scrum, método ágil de desenvolvimento de software, criado na década de 1990 por Jeff Sutherland, com base em conceitos tradicionais da engenharia de produção como a filosofia enxuta e a teoria das restrições explorados por Takeuchi & Nonaka (1986) no artigo The new new product development game, no qual descrevem as vantagens da utilização de times multidisciplinares e autogerenciáveis no desenvolvimento de produtos. Este artigo tem o objetivo de apresentar um estudo de caso sobre a utilização do método ágil Scrum em uma empresa do setor de software nacional. Será tratado o processo de análise e identificação de problemas da situação atual da empresa e como o método em questão foi utilizado como referencial teórico para propor soluções de melhoria, orientando uma mudança organizacional. 2. Método Para a condução deste trabalho foi seguido um método que pode ser representado pela Figura 1. Esta pesquisa pode ser classificada como de natureza aplicada (GIL, 1999), isto é, trata-se de uma pesquisa que envolve conhecimentos que buscam resolver lacunas teórico-práticas. 2

3 Figura 1 Método de condução do trabalho Fonte: os autores Primeiramente foi realizada uma busca bibliográfica sobre os conceitos e definições de Metodologias de Desenvolvimento de Sistemas (MDS). Partiu-se, então, para o aprofundamento no método ágil de desenvolvimento de sistemas Scrum e os conceitos que são referenciados como base para a criação deste método. Foi então realizado um estudo de caso sobre a aplicação dos conceitos apresentados na implementação do Scrum em uma empresa do setor de produção e comercialização de software. A partir da análise do caso foram apresentados os principais resultados obtidos e as limitações encontradas. Por fim, são apresentadas conclusões que visam embasar novas iniciativas de aplicação do Scrum. 4. Referencial Teórico Este item se propõe a apresentar os conceitos, terminologias e definições necessárias para o entendimento do artigo. Serão apresentados conceitos da engenharia de software e das metodologias de desenvolvimento de sistemas, com foco no Scrum, apontando suas características e raízes na filosofia enxuta de produção A Engenharia de Software A engenharia de software, segundo Staa (1987) estabelece e usa sólidos princípios de engenharia para a obtenção econômica de softwares confiáveis e com funcionamento eficiente em máquinas reais. Maffeo (1992) corrobora com esta visão e acrescenta que é a área interdisciplinar que engloba as vertentes tecnológica e gerencial, visando abordar de modo sistemático os processos de construção, implantação e manutenção de produtos de software com qualidade assegurada, segundo cronogramas e custos previamente definidos. A partir dessas duas visões, tem-se a necessidade de estabelecer metodologias de desenvolvimento de software que cumpram os requisitos tecnológicos e gerencias para garantir a qualidade do produto entregue e a eficiência dos processos envolvidos. Cabe ressaltar ainda, segundo Maffeo (1992), os objetivos primários da engenharia de software que, dentre outros, abrangem o aprimoramento da qualidade dos produtos de software, o aumento da produtividade dos engenheiros de software e o atendimento aos requisitos com eficiência e eficácia. 3

4 4.2. Metodologias de Desenvolvimento de Software (MDS) O conceito de ciclo de vida do software surgiu devido à necessidade da especificação, em alto nível, do conjunto de tarefas que compõem o processo de desenvolvimento de software. (CARVALHO, 2009). As diferentes metodologias existentes para o desenvolvimento de software trazem abordagens distintas para o ciclo de vida de software. Entretanto, independentemente do modelo de ciclo de vida e de suas características particulares, em geral esses modelos compartilham as seguintes (macro) atividades (MAFFEO, 1992): Especificação de Necessidades, Especificação de Requisitos, Projeto de Software (Design), Implementação de Software, Implantação e Manutenção do Software. Carvalho (2009) define as possíveis tipologias para as metodologias de desenvolvimento de software que variam na forma com a qual dispõem os recursos (papéis, responsabilidades, tempo, etc.) para a construção do produto software e para a entrega ao cliente final O Modelo Cascata ou Clássico Nesta metodologia, o projeto de desenvolvimento de software é dividido em fases executadas sequenciamente com um conjunto detalhado de documentos específicos a cada macroatividade. São características desse modelo o grau elevado de documentação, o controle excessivo das atividades e a baixa participação do usuário final nos processos Prototipação Nesse modelo, o conjunto inicial de necessidades é detectado e implementado rapidamente, sendo posteriormente refinado de acordo com o aumento do conhecimento do sistema pelos envolvidos no processo de desenvolvimento (YORDON, 1990). A prototipação, porém, possui brechas para críticas, na medida em que a ausência de padrões e processos deixa a qualidade do produto final imprevisível e passível de oscilações. Nesta perspectiva, para ser um sistema real, aquele deveria seguir padrões de qualidade, segurança, desempenho, capacidade, robustez e facilidade de manutenção, mas, por ser um protótipo, padrões como os citados mostram-se insuficientes ou inexistem (ALVES; VANALLE, 2001) O Modelo Espiral As melhores características dos modelos cascata e prototipação podem ser encontradas no modelo espiral com o acréscimo de um elemento a análise dos riscos, inexistentes nos outros dois modelos (PRESSMAN, 2002). O modelo é composto por quatro quadrantes, quais sejam: Planejamento, Análise de Riscos, Engenharia e Avaliação O Modelo Iterativo e Incremental Este modelo apresenta uma ênfase na redução do lead time da produção do software. Sua ênfase é na liberação de versões que são atualizadas e melhoradas em ciclos de desenvolvimento consecutivos. Assim, de cada iteração (composta pelas fases de requisitos, análise e projeto, codificação e teste) resulta uma versão do software com um subconjunto de funcionalidades que crescem de forma incremental a cada iteração até conformar o produto final desejado. (CARVALHO, 2009) Técnicas da Quarta Geração 4

5 As técnicas de quarta geração, conhecidas pela sigla 4GT, trazem uma abordagem de especificação de software utilizando funções significativas que aproximam a linguagem de máquina à linguagem natural. Tecnologias modernas que utilizam a 4GT conseguem passar automaticamente das fases de especificação para a implementação, incluindo testes automatizados que garantem a conformidade com os requisitos levantados. As técnicas de quarta geração já se tornaram importantes para o desenvolvimento de aplicações de sistemas de informação (PRESSMAN, 2002) Metodologias Ágeis Um dos problemas relacionados às metodologias mais tradicionais de desenvolvimento de software está na identificação, registro e tratamento dos requisitos de negócio. No atual ambiente de desenvolvimento de software, os requisitos estão sujeitos a freqüentes modificações durante o ciclo de desenvolvimento do produto para atender as alterações da demanda (RISING; JANOFF, 2000). Frente às dificuldades de adaptação dos métodos tradicionais às necessidades de mudanças dos processos de desenvolvimento de software, surgiram, durante a década de 1990, os chamados métodos ágeis. Estes métodos foram influenciados pelos princípios da manufatura enxuta implementados pelas companhias Honda e Toyota e pelas estratégias de gestão do conhecimento de Takeuchi e Nonaka (2004) e Senge (1990). Tratam-se de metodologias de desenvolvimento adaptativas e flexíveis, e que são indicadas para cenários onde a mudança de requisitos é constante e os resultados precisam ser entregues ao cliente em curtos espaços de tempo. (CARVALHO; MELLO, 2009). No lugar da aderência e conformidade aos planos iniciais é preferível adaptar aos cenários atuais, levando em consideração o conhecimento adquirido durante o desenvolvimento (uma vez que o desenvolvimento é uma atividade de aprendizado baseado em tentativas e erros), aproveitando oportunidades emergentes e focando na entrega de valor real para os clientes. (FRANCO, 2006) Estas metodologias, portanto, focam nos indivíduos e na interação entre eles, no funcionamento do software, na colaboração com o cliente e na resposta rápida às mudanças. Isto é alcançado através de ciclos iterativos de desenvolvimento de sistemas com objetivos de curto prazo, tonando possível a adaptação dos requisitos até o momento em que entram em fase de desenvolvimento O Scrum Segundo Carvalho e Mello (2009), dentre os diferentes métodos ágeis, o que mais se destaca é o Scrum, uma abordagem enxuta de desenvolvimento de produtos. A primeira utilização deste termo surgiu em um estudo de Takeuchi & Nonaka (1986), no qual, os autores notaram que pequenos projetos que tinham equipes pequenas e multifuncionais obtinham os melhores resultados. Este estudo serviu como base para que, em 1993, Jeff Sutherland criasse o Scrum. O objetivo do Scrum é entregar a maior qualidade de software possível dentro de uma série de pequenos intervalos de tempo fixo, chamados Sprints, que tipicamente duram menos de um mês (SUTHERLAND et al., 2000). Ou seja, ao final de cada Sprint, espera-se que sejam entregues funcionalidades que possam ser utilizadas pelo usuário, gerando valor para seu negócio ou aumentando sua satisfação em relação ao produto entregue. O método tem início com uma reunião denominada Sprint Planning. Na primeira parte desta reunião, são eleitos os requisitos de sistema registrados no Product Backlog que serão 5

6 desenvolvidos ao longo do Sprint. Na segunda parte desta reunião, são discutidas e detalhadas as atividades envolvidas na execução de cada item selecionado. Após, dá-se início à fase de execução das atividades, o Sprint propriamente dito. Conforme Carvalho et al (2009) apud Abrahamsson (2002), no caso do desenvolvimento de software, o Sprint inclui as fases tradicionais do desenvolvimento de software: requisitos, análise, projeto e entrega. Durante o Sprint, são realizadas reuniões diárias conhecidas como Scrum Meetings ou Daily Scrum. As Scrum Meetings permitem que o time de desenvolvimento possa socializar o conhecimento de cada membro do Time e possui uma profunda transcendência cultural (SUTHERLAND et al., 2000). Ao final do tempo determinado para o Sprint, é realizada uma reunião de entrega do incremento do produto. Esta última reunião é chamada Sprint Review. A última reunião do Sprint é denominada Sprint Retrospective e serve para que os membros do Time possam discutir a respeito das melhorias no processo de desenvolvimento para o próximo ciclo de desenvolvimento. A figura abaixo retrata a dinâmica de processo do Scrum: Figura 2 Dinâmica de processo do Scrum Fonte: Mar e Schwaber (2001) O Scrum possui três papéis fundamentais. O Scrum Master deve trabalhar para que o processo Scrum aconteça e para que não existam impedimentos para que os membros da equipe realizem seu trabalho. Remover os obstáculos apontados no Daily Scrum é seu dever, de modo que os desenvolvedores se concentrem apenas nas questões técnicas (CARVALHO; MELLO, 2009). Outro papel importante no método é o do Product Owner. Este membro do time representa o cliente interno ou externo. Ele deve definir quais são os requisitos e qual é o grau de importância e prioridade de cada um deles (CARVALHO; MELLO, 2009). Por fim, o último papel destacado pelo Scrum é o próprio Time, que deve ser multidisciplinar, auto-gerenciável e todos devem estar em busca de um objetivo comum A Manufatura Enxuta (Lean Manufacturing) Como citado, o Scrum tem suas raízes nos princípios da manufatura enxuta japonesa. Filho e Fernandes (2004) propõem uma listagem com a síntese desses princípios, que são a base da manufatura enxuta. 6

7 Tabela 1- Princípios da Manufatura Enxuta Fonte: Filho e Fernandes (2004) Uma das etapas iniciais e foco da manufatura enxuta é o mapeamento do processo de construção do valor para o cliente (Value Stream Mapping). Através dessa ferramenta, são identificadas as atividades que agregam valor e as que não agregam valor passam a ser consideradas desperdícios e devem ser eliminadas. Womack e Jones (2006) evoluem nas atribuições chave da manufatura enxuta e prescrevem os passos para que uma organização utilize seus princípios para alavancar sua produção. Forneça o valor de fato desejado pelos clientes. Resista ao desejo de trabalhar adiante a partir da organização, dos ativos e do conhecimento existentes para convencer os clientes de que eles querem aquilo que é mais fácil de ser produzido pela empresa. Identifique o fluxo de valor para cada produto. Esta é a sequência de ações (o processo) necessárias para trazer um bem ou serviço do conceito até o lançamento (pelo processo de desenvolvimento) e de um pedido até as mãos do cliente (pelo processo de provisão). Questione cada etapa nesses processos, para ver se eles realmente criam valor para o cliente. Elimine as etapas que não criam. Organize as etapas estantes em um fluxo contínuo. Elimine esperas e estoques entre etapas, para reduzir os tempos de desenvolvimento e de resposta. Deixe o cliente puxar o valor da empresa. Reverta os métodos de empurrar, usados pelas empresas com tempos longos de resposta, as quais tentam convencer os clientes de que eles querem aquilo que a empresa já projetou ou produziu. Finalmente, uma vez estabelecidos o valor, o fluxo de valor e a puxada, comece novamente a partir do início, numa busca indefinível pela perfeição, a situação feliz de valor perfeito com desperdício zero A Teoria das Restrições Desenvolvida por Eliyahu M. Goldratt, na década de 1980, a Teoria das Restrições aponta que a meta de qualquer organização é maximizar o índice pelo qual cada empresa gera receita através de suas vendas líquidas (conceito que em inglês é apresentado como throughput) Segundo Goldratt e Cox (1990), a meta de qualquer organização é garantir dinheiro no presente, bem como garantir sua continuidade no futuro. Para tal, a teoria parte da identificação do gargalo produtivo. Entende-se gargalo como todo recurso que possui uma capacidade menor do que a sua demanda (GOLDRATT; COX, 1990). Para os autores, todas as organizações apresentam restrições, isto é, impedimentos que reduzem a eficiência dos sistemas produtivos. Nesse sentido, parte da teoria dita que o foco do 7

8 esforço gerencial deve ser na otimização dos gargalos e na redução das restrições que influenciam as etapas de agregação de valor. Dentre as máximas da Teoria das Restrições é dito que uma hora perdida na operação do posto gargalo é uma hora perdida para o sistema todo. Desta afirmação retirada da própria obra A Meta (GOLDRATT; COX, 1990), tem-se que a operação do gargalo dita o desempenho global da linha produtiva e do negócio. 5. O Caso O caso apresentado é baseado em um projeto de análise da situação atual e proposições de melhorias para a metodologia de desenvolvimento de sistemas de uma empresa do setor de software, que resultou na implementação do Scrum em seu processo produtivo A Organização e o Contexto do Projeto Este trabalho foi realizado em uma empresa brasileira com atuação internacional especializada em soluções relacionadas à Governança, Riscos e Compliance (GRC). A empresa atua nas áreas de desenvolvimento e comercialização de software para automatização de soluções de GRC, consultoria e educação nesta área. Seus clientes estão localizados no Brasil, América Latina, Estados Unidos e Europa. Para manter seu sistema atualizado frente às inovações do mercado de GRC e às necessidades de customização demandadas por seus clientes, a equipe técnica da empresa lida constantemente com uma série de mudanças e atualizações no sistema. O grande volume de novos requisitos a serem desenvolvidos exige dinamismo à equipe de desenvolvimento, que deve ser capaz de gerenciar a alta demanda e garantir qualidade e pontualidade de entrega de seu produto final. O crescimento das vendas da empresa durante 2010 aumentou ainda mais a demanda por atualizações no software, o que gerou uma pressão sobre a diretoria técnica a respeito da eficiência de sua equipe de desenvolvimento de sistema. Juntamente a este cenário, a alta gestão da empresa colocava em prática ações para a otimização de recursos. Assim, o diretor técnico, em parceria a um grupo externo, conduziu uma iniciativa para a avaliação da atual metodologia utilizada para o desenvolvimento do software, identificação de pontos críticos e proposição de melhorias A situação atual do processo de desenvolvimento de sistema da organização O estudo teve início com o mapeamento da situação atual dos processos de desenvolvimento de sistemas da empresa anteriormente à implementação do Scrum. Em primeiro lugar, era preciso entender como o processo de desenvolvimento estava organizado. Para tanto, foi construído um esquema que representava a situação atual do processo, desde a chegada de novas demandas até a entrega do software. 8

9 Figura 3 Macroatividades do processo de desenvolvimento de sistema Fonte: os autores A figura anterior representa o macroprocesso de desenvolvimento. Este tem início com o recebimento de novos requisitos para serem implementados no sistema ou modificações em requisitos já existentes. Estes requisitos são então priorizados e a equipe de especificação produz, para cada um, um documento detalhado sobre suas características, regras de negócio envolvidas e critérios de aceitação, chamado de Especificação do Requisito. Este documento é utilizado em todas as demais etapas do processo e serve como padronização para as informações que servirão de insumo para as atividades posteriores. Após a Especificação do Requisito, é realizado o desenvolvimento do código do sistema e de seu conteúdo (como questionários para avaliações de risco, por exemplo). O código passa então por alguns testes e, após os ajustes necessários, ocorre a implantação do sistema para os usuários internos à equipe técnica. Assim, seguem-se os testes de qualidade no software (Quality Assurance - QA), onde são simuladas situações cotidianas de utilização do sistema para a correção final de possíveis erros. Então, o software pode ser liberado para o cliente final e instalado nos ambientes de produção. É possível perceber que o processo de desenvolvimento da empresa estava organizado conforme o método cascata. Nesse modelo, o projeto passa por diversas etapas (análise, design, documentação, codificação e testes) antes de ser entregue ao cliente (ROSE e MELLO apud LOESER, 2010), diminuindo a flexibilidade do processo e prejudicando a obtenção de repostas rápidas às exigências de mercado por parte da empresa (ROSE; MELLO, 2010). Para entender detalhadamente de que forma estas características inerentes ao método cascata afetavam a produtividade da equipe de desenvolvimento da empresa, o macroprocesso identificado foi dividido em 45 atividades e os seus respectivos responsáveis foram entrevistados. Para tal, foi utilizado um questionário padrão com as seguintes perguntas: a) Qual o objetivo da atividade? b) Quais são os inputs necessários para a execução da atividade? Qual a qualidade destes inputs? Existe retrabalho para a atividade devido à má qualidade dos inputs? c) Quem e quantos são os envolvidos na execução da atividade? d) Quais são os recursos utilizados (documentos, sistemas etc.)? e) Quanto tempo, em média, demora a execução da atividade? f) Quais são os outputs gerados pela atividade? Qual a qualidade destes outputs? Existe retrabalho para a atividade devido à má qualidade dos outputs? 9

10 g) Quais críticas podem ser colocadas quanto à atividade, aos recursos necessários e à comunicação com as equipes responsáveis pelas demais atividades? Como resultado das informações obtidas através das entrevistas, foi possível a caracterização mais detalhada da situação atual da empresa. Alguns pontos críticos foram postos em evidência, demonstrando algumas dificuldades encontradas pela equipe técnica: Um ano antes deste estudo, houve uma reestruturação na metodologia de desenvolvimento da empresa devido à migração do software para uma versão mais avançada. Novas atividades foram criadas, dentre elas, a especificação dos requisitos. Esta atividade, apesar de ser considerada crítica para a garantia da qualidade do produto final, era realizada por uma equipe com pouca experiência na empresa e ainda não possuía papéis e responsabilidades bem definidos. Conforme mencionado, a equipe de especificação era responsável pela elaboração das Especificações dos Requisitos utilizadas como base por todas as demais etapas do processo de desenvolvimento. Devido à pouca experiência desta equipe, o aparente subdimensionamento e a falta de processos que orientassem a execução das atividades, pode-se identificar o seguinte cenário. Figura 4 Ponto crítico do processo produtivo: divergência de informações Fonte: os autores O processo de desenvolvimento de sistemas exige interpretação da Especificação do Requisito para sua tradução em códigos de programação. Porém, a baixa qualidade destes documentos levava os codificadores a implementar funcionalidades diferentes das descritas, sem o correto registro das mudanças realizadas no documento original (a Especificação do Requisito). Após a codificação, o software era repassado para as demais etapas. Uma vez que as equipes responsáveis por estas atividades posteriores utilizavam a Especificação do Requisito como o documento que detalhava o que deveria estar implementado no software, a divergência entre o documento e o que era encontrado no sistema gerava conflitos de informações e retrabalho para toda a equipe técnica dada a falta de registro das mudanças realizadas. De acordo com Womack e Jones (2006), uma das atividades relacionadas à filosofia enxuta de produção consiste em identificar o fluxo de valor para cada produto, do ponto de vista do cliente, questionar cada etapa desses processos sobre a real criação de valor e buscar eliminar as etapas que não criam o valor real. Nesta empresa, a correção da documentação e recodificação do sistema podem ser classificadas como atividades que não agregavam valor para o cliente. Estas eram resultado de erros cometidos pela equipe técnica. Sendo assim, de acordo com a filosofia enxuta, o retrabalho gerado pela baixa qualidade das especificações deveria ser eliminado. 10

11 Além disso, a capacidade de entrega da equipe de especificação ainda não havia atingido o nível de eficiência que as demais áreas já tinham adquirido devido a sua pouca experiência em lidar com as particularidades do sistema daquela empresa, comparada às demais equipes. Segundo Goldratt e Cox (1990), à luz da teoria das restrições, entende-se gargalo como todo recurso que possui uma capacidade menor do que a sua demanda. Assim, a etapa de especificação foi considerada como um gargalo para o processo de desenvolvimento do software da empresa. Ainda segundo esta teoria, toda a capacidade produtiva do sistema estava sendo limitada por esta etapa e o foco gerencial deveria ser na otimização deste gargalo Implementação da metodologia Scrum Como já mencionado, a metodologia de sistemas Scrum foi criada com base nos princípios enxutos de produção, visando eliminar os gargalos e balancear o fluxo de produção do método tradicional através da criação de times multidisciplinares, que deveriam trabalhar em conjunto, prezando pela comunicação entre seus membros e o foco em uma meta compartilhada. Sobre o fluxo de produção, Takeuchi e Nonaka (1986) colocam que o ritmo de cada indivíduo e o ritmo do grupo se tornam o mesmo, criando um pulso completamente novo. Este pulso serve como uma força motriz e move o time para frente. Um estudo realizado por Carvalho e Mello (2009) revelou que o benefício proporcionado pelo Scrum mais citado pelas publicações sobre o tema é a melhoria na comunicação e aumento da colaboração entre os envolvidos. Além disso, Sutherland (2004) relata que em um projeto de desenvolvimento realizado pela Microsoft onde foi utilizada a lógica do Scrum, foi obtida a maior produtividade por desenvolvedor já documentada. Assim, o Scrum se demonstrou a solução que melhor supria as necessidades da empresa estudada. Esta decisão significava o reprojeto do macroprocesso produtivo da empresa e o apoio da alta direção foi considerado fator crítico para o sucesso da implementação da metodologia. Uma particularidade da implantação do Scrum na empresa diz respeito à decisão de deixar os profissionais da área de Quality Assurance fora dos times multidisciplinares. Por questões de política interna à empresa, preferiu-se não envolver estes profissionais inicialmente e apostar em uma inclusão progressiva visando uma curva de aprendizagem. Conforme mostra a figura 2, apresentada anteriormente, que explicita a dinâmica do processo do Scrum, o resultado entregue ao final dos Sprints deve ser um incremento do produto. Porém, a figura abaixo demonstra que, para a empresa estudada, o resultado entregue pelos times Scrum não pode ser diretamente entregue ao cliente, visto que ainda resta a etapa de testes realizada pela equipe de QA (que não foi incluída nos times). Esta foi a solução encontrada para uma barreira política da empresa, que adaptou o método para o momento da mudança imediata. 11

12 Figura 5 Composição dos times Scrum Fonte: os autores Foi decidido por uma estratégia de mudança na qual todos os profissionais das áreas envolvidas no Scrum migrariam de uma só vez para os times multidisciplinares. Este processo demandou um trabalho intenso de conscientização e disseminação da cultura ágil por toda a equipe técnica. Para tanto, todos receberam um treinamento no método Scrum. Após a realização do treinamento, foram definidos os componentes dos times e houve a escolha dos Scrum Masters (que seriam trocados a cada três meses). Para a adaptação dos profissionais à nova metodologia, ao longo de janeiro de 2011 foram realizados dois Sprints experimentais, apenas para a resolução de bugs antigos do sistema. Este período de adaptação foi utilizado para observar possíveis pontos de melhoria no método implementado. Por fim, para o controle da evolução da nova metodologia, foram determinados alguns indicadores de desempenho como Eficácia do Trabalho, Índice de Trabalho Remanescente, Densidade de erros por linha de código, Tempo Médio de Resolução de Impedimentos e Avaliação da Satisfação do Product Owner. O processo de implantação do Scrum ocorreu durante 40 dias e foi finalizado na segunda semana de janeiro de Desde então, o progresso do método vem sendo acompanhado através de indicadores de desempenho e, de acordo com as necessidades impostas pela rotina e pelas particularidades da organização, são feitos ajustes nos processos. Com a formação de times multidisciplinares, os profissionais responsáveis pela especificação dos requisitos passaram a ter a oportunidade de adquirir experiência com outros profissionais da equipe técnica e o processo de comunicação constante ajuda a diminuir o retrabalho devido a inconsistências nos documentos gerados Conclusões Este estudo apontou a utilização de um método ágil de desenvolvimento de sistemas, o Scrum, como referencial para a transformação da estrutura de processos de uma empresa do setor de software. Foram apresentados os conceitos que suportam a discussão e, em seguida, o caso foi explicitado. Após a implantação da situação projetada, pode-se considerar que houve uma mudança significativa na organização, uma vez que esta iniciativa impactou o dimensionamento do 12

13 quadro de pessoal, a divisão de papéis e responsabilidades, os mecanismos de coordenação e os processos produtivos. Todavia, durante este estudo foram identificadas dificuldades práticas na execução dos conceitos previstos pelo Scrum, que devem servir de motivação para novos estudos que avancem no conhecimento sobre a aplicabilidade do método. Entre elas, pode-se citar a dificuldade de reprojetar a estrutura de cargos e salários para uma nova realidade em que novos papéis são propostos e as estruturas de poder são alteradas. Ainda, a multifuncionalidade total do time, isto é, a presença de profissionais com habilidades e conhecimentos que garantissem todas as etapas necessárias para a entrega do produto, não conseguiu ser implantada. Dentre os motivos para essa decisão aponta-se o conflito de interesses e o impacto para a divisão de poder da empresa, podendo ser um fator contra o objetivo de ganho de produtividade e melhoria na comunicação interna. Optou-se então por uma solução híbrida que manteve fora do time multifuncional uma área de qualidade (QA). Como fator positivo que merece destaque neste estudo foi o patrocínio da alta direção da empresa que orientou as mudanças internas no sentido da implantação da nova estrutura organizacional, o treinamento em Scrum oferecido para todos os profissionais e uma campanha de comunicação eficiente que orientou todos nas transformações que seriam feitas nas estruturas de cargos e salários da empresa. O principal ganho para a organização foi o aumento da responsividade às mudanças necessárias no software que comercializa e, com isso, a rapidez de entrega de novas versões e atualizações para o mercado. Uma vez que o contexto apresentado, no qual o mercado de sistemas de informação demanda organizações que tenham flexibilidade e trabalhem com um equilíbrio nos fatores qualidade e prazo, o método Scrum se apresentou uma referência eficiente para a estruturação dos processos de desenvolvimento de software ajustado às necessidades de mercado. Todavia, esse estudo serviu também para apresentar possíveis restrições e dificuldades que futuras organizações possam vir a ter com a escolha do método. Para isso, abrem-se novos campos de estudo para entender em quais outras ocasiões essas restrições também se aplicam e, com isso, evoluir na compreensão do Scrum. Referências Bibliográficas ALVES, R. F., VANALLE, R. Ciclo de Vida de Desenvolvimento de Sistemas visão conceitual dos modelos clássico, espiral e prototipação, CARVALHO, B. V.; MELLO, C. H. P. Revisão, análise e classificação da literatura sobre o método de desenvolvimento de produtos ágil Scrum. Anais do XII Simpósio de Administração da Produção, Logística e Operações Internacionais - SIMPOI, São Paulo/SP, FRANCO, 2006 CARVALHO, E. Engenharia de Processos de negócios e a engenharia de requisitos: análise e comparações de abordagens e métodos de elicitação de requisitos de sistema orientada por processos de negócio f. Dissertação (Mestrado em Engenharia de Produção) COPPE, UFRJ. Rio de Janeiro, FILHO M. G.; FERNANDES, F. C. F. Manufatura enxuta: uma revisão que classifica e analisa os trabalhos apontando perspectivas de pesquisas futuras, Gestão e Produção, 2004 GIL, A. C. Métodos e técnicas de pesquisa social. São Paulo, Atlas, GOLDRATT, E. M. e COX, J. A Meta. São Paulo, IMAM, MAFFEO, B. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro: Campus,

14 MAR, K.; SCHWABER, K. Scrum With XP. Disponível em < Consultado em abril de MENEGON, N. L.; ANDRADE, S. R. Projeto do Produto em Engenharia de Produção, Encontro Nacional de Engenharia de Produção ENEGEP, PRESSMAN, R.S. Software Engineering: a practitioner s approach. 3 ed. New York: McGraw-Hill, RISING, L.; JANOFF, N. S. The Scrum Software Development Process for Small Teams, IEEE Software, Vol. 17, No. 4, July-August ROSE, T. P.; MELLO, C. H. Proposta sistemática para a gestão de projetos baseada na metodologia ágil Scrum, Encontro Nacional de Engenharia de Produção ENEGEP, São Carlos, São Paulo, SENGE, P. The Fifth Discipline: the Art and Practice of the Learning Organization. New York: Currency, STAA, A.V. Engenharia de Programas. 2ª ed. Rio de Janeiro: Livros Técnicos e Científicos, STANDISH GROUP. Extreme CHAOS. The Standish Group International Inc., Disponível em: < Consultado em abril de SUTHERLAND, J. Agile Development: lessons learned from the first scrum. Cutter Agile Project Management Advisory Service. Executive Update, Vol. 5, No SUTHERLAND, J.; SCHWABER, K.; SHARON, Y.; DEVOS, M.; BEEDLE, M. SCRUM: An extension pattern language for hyperproductive software development, TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p , YOURDON, E. Análise Estruturada Moderna. 3ª ed. Rio de Janeiro: Campus, WOMACK, J. P.; JONES, D. T. Soluções Enxutas: Como Empresas e Clientes Conseguem Juntos Criar Valor e Riqueza. Editora Campus,