mÉtodos Ágeis de desenvolvimento de software:...
TRANSCRIPT
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
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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 2009. 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.
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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.
4.1. 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.
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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.
4.2.1. 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 macro-
atividade. 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.
4.2.2. 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).
4.2.3. 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.
4.2.4. 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)
4.2.5. Técnicas da Quarta Geração
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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).
4.2.6. 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.
4.3. 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
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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.
4.4. 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.
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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.
4.5. 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
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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.
5.1. 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.
5.2. 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.
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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?
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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.
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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.
5.3. 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.
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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 2011. 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.
5.4. 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
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
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, 2001.
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, 2009. 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. 2009. 225 f.
Dissertação (Mestrado em Engenharia de Produção) – COPPE, UFRJ. Rio de Janeiro, 2009.
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, 1999.
GOLDRATT, E. M. e COX, J. A Meta. São Paulo, IMAM, 1990.
MAFFEO, B. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro: Campus, 1992.
XXXI ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Inovação Tecnológica e Propriedade Intelectual: Desafios da Engenharia de Produção na Consolidação do Brasil no
Cenário Econômico Mundial Belo Horizonte, MG, Brasil, 04 a 07 de outubro de 2011.
14
MAR, K.; SCHWABER, K. Scrum With XP. Disponível em <http://www.controlchaos.com/XPKane.htm>.
Consultado em abril de 2011.
MENEGON, N. L.; ANDRADE, S. R. Projeto do Produto em Engenharia de Produção, Encontro Nacional de
Engenharia de Produção ENEGEP, 1998.
PRESSMAN, R.S. Software Engineering: a practitioner’s approach. 3 ed. New York: McGraw-Hill, 1992.
RISING, L.; JANOFF, N. S. The Scrum Software Development Process for Small Teams, IEEE Software, Vol.
17, No. 4, July-August 2000.
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, 2010.
SENGE, P. The Fifth Discipline: the Art and Practice of the Learning Organization. New York: Currency,
1990.
STAA, A.V. Engenharia de Programas. 2ª ed. Rio de Janeiro: Livros Técnicos e Científicos, 1987.
STANDISH GROUP. Extreme CHAOS. The Standish Group International Inc., 2009. Disponível em:
<http://www.standishgroup.com>. Consultado em abril de 2011.
SUTHERLAND, J. Agile Development: lessons learned from the first scrum. Cutter Agile Project Management
Advisory Service. Executive Update, Vol. 5, No. 20. 2004
SUTHERLAND, J.; SCHWABER, K.; SHARON, Y.; DEVOS, M.; BEEDLE, M. SCRUM: An extension
pattern language for hyperproductive software development, 2000.
TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p. 137-
146, 1986.
YOURDON, E. Análise Estruturada Moderna. 3ª ed. Rio de Janeiro: Campus, 1990.
WOMACK, J. P.; JONES, D. T. Soluções Enxutas: Como Empresas e Clientes Conseguem Juntos Criar Valor
e Riqueza. Editora Campus, 2006.