Conforme mencionado no capítulo dedicado à introdução deste trabalho, durante os últimos 10 (dez) anos vêm ganhando cada vez mais aceitação na indústria os métodos de desenvolvimento ágil de software (RAUTIAINEN; SCHANTZ; VÄHÄNIITTY, 2011; CARVALHO; MELLO, 2009).
Os métodos de desenvolvimento ágil de software surgiram em resposta aos problemas percebidos na indústria, especialmente quanto à baixa taxa de sucesso dos projetos (ROSE; MELO, 2010). Segundo o Chaos Report, um relatório que buscava avaliar e melhor compreender as falhas em projetos de desenvolvimento de software, em 1995 aproximadamente um terço dos projetos eram cancelados, dois terços custavam mais de 200% além do custo inicialmente previsto e mais de 80% eram considerados fracassados em algum aspecto, como custo ou prazo (JOHNSON, 1995).
Inicialmente, os métodos ágeis eram conhecidos como métodos leves de desenvolvimento de software e se desenvolveram a partir de meados dos anos 90. A denominação desenvolvimento ágil de software veio somente após a publicação do Manifesto Ágil, em fevereiro de 2001. Tal manifesto contém um conjunto de valores e princípios descritores da abordagem, a qual se propõe a produzir software de maneira mais eficiente e adaptativa. Foi elaborado por especialistas em engenharia de software que se reuniram em Utah, nos Estados Unidos, para discutir formas mais ágeis de desenvolver software (WIKIPEDIA, 2011).
O manifesto em si contempla um texto de poucas linhas, reproduzidas abaixo. Ele lança um conjunto de valores e possui uma subparte, na qual são apresentados os princípios descritores da abordagem, a qual se propõe a produzir software de maneira mais eficiente e adaptativa (BECK et al., 2011, p. 1).
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
- Indivíduos e interações, mais que processos e ferramentas; - Software em funcionamento, mais que documentação abrangente; - Colaboração com o cliente, mais que negociação de contratos; e - Responder a mudanças, mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Junto ao manifesto, foram apresentados os princípios que orientaram, que serviram como plano de fundo ao Manifesto Ágil. Assim, quanto aos princípios orientadores dos métodos ágeis, são doze e encontram-se listados a seguir (BECK et al., 2011, p.1):
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazerem o trabalho.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto- organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo
Originalmente, os métodos ágeis foram adotados por times de três a oito pessoas, as quais trabalhavam em um único produto. Ultimamente, a tendência tem sido estendê-los ao nível empresarial e utilizá-los em larga escala (RAUTIAINEN; SCHANTZ; VÄHÄNIITTY, 2011). Nesse sentido, pesquisas da Forrester Research indicam que nos últimos anos tais métodos não só ganharam aumento nos níveis de adoção, como também rapidamente passaram a fazer parte do pensamento dominante das abordagens de desenvolvimento (FORRESTER, 2010).
As principais metodologias de desenvolvimento ágil de software utilizadas nos últimos anos, dentre elas o Scrum e o XP, são baseadas nos princípios definidos no Manifesto Ágil e buscam melhor time-to-market, clientes mais satisfeitos e software de melhor qualidade (FOGELSTRÖM et al., 2009; RAUTIAINEN; SCHANTZ; VÄHÄNIITTY, 2011).
O conceito de agilidade não é único da área de desenvolvimento de software. São relatadas ocorrências na literatura de negócios desde 1991, quando um grupo de pesquisadores da Lehigh University, na Pensilvânia, introduziu o termo manufatura ágil. O
relatório tinha como objetivo prover os Estados Unidos de mecanismos para recuperar sua preeminência em fabricação e identificou os princípios ágeis emergindo e sendo adotados em empresas japonesas, europeias e americanas (CONBOY; FITZGERALD, 2004).
Uma das maiores influências do conceito de agilidade, e que representa também uma das principais influências nos métodos ágeis de desenvolvimento, reside no sistema de produção adotado pela Toyota, cujo foco era a redução e a eliminação de desperdícios. Tal sistema é frequentemente denominado lean thinking (pensamento enxuto), lean production (produção enxuta) ou lean manufacturing (manufatura enxuta) (PROPPENDIECK; PROPPENDIECK, 2003).
Segundo Proppendieck e Proppendieck (2003), o lean thinking surgiu no final da década de 1940, quando o Japão estava com suas fábricas totalmente destruídas por causa da segunda guerra mundial e no Japão não havia demanda suficiente para a absorção de um modelo de produção em massa. Além disso, alguns estudos tinham verificado baixa produtividade dos japoneses em relação aos americanos nas grandes indústrias automotivas.
A Toyota precisou buscar formas de produzir automóveis com maior agilidade, mais qualidade e menor custo, por isso realizou estudos e os resultados apontaram como principal causa os desperdícios existentes no sistema de produção.Foi proposto, então, o lean thinking ou Sistema Produtivo Toyota, que sofreu inúmeros aperfeiçoamentos ao longo dos anos e hoje é muito conhecido pelo termo just-in-time (PROPPENDIECK; PROPPENDIECK, 2003).
O lean thinking pode ser visto como uma filosofia que visa maior produção com menos recursos, sejam eles humanos, materiais, de tempo, espaço, etc. Funciona como uma espécie de antídoto contra desperdícios encontrados na organização e é pautado por cinco princípios, conforme segue (WOMAK, 1998):
Compreenda como o valor é percebido pelo cliente; Elimine desperdícios em toda a cadeia de valor; Estabeleça um fluxo contínuo do início ao fim;
Faça conforme demanda do cliente, não gere estoque; e Busque a excelência através de melhoria contínua.
De acordo com Liker (2004), alguns autores contam que, na primeira linha do primeiro livro texto publicado pela Toyota Motor Corporation, consta um trecho no sentido de que o Sistema Toyota de Produção é uma série de atividades com o objetivo de diminuir o custo por meio do aumento da produtividade, através da completa eliminação de desperdícios.
Com relação a essa completa eliminação de desperdícios, que constitui um dos pontos centrais do Sistema Toyota de Produção, há diferentes tipos de desperdícios, classificados pelo lean thinking por meio dos termos muda, muri e mura. Mura (desnivelamento ou inexistência de fluxo contínuo) trata da falta de regularidade em uma operação, como altos e baixos na programação ou ritmo de trabalho irregular. Não tem como causa a demanda do cliente final, mas sim o próprio sistema de produção. Faz com que os operadores tenham picos de trabalho intensos e depois momentos de espera. Sua correção facilita a atuação e a detecção nos pontos de desperdício. Numa analogia, seria algo como diminuir o nível da água para fazer surgirem as pedras.
Muri (sobrecarga de pessoas ou equipamentos): se refere à sobrecarga de
equipamentos ou de operadores, exigindo que operem em ritmo mais intenso ou acelerado, empregando mais força ou esforço, por um período maior de tempo do que podem suportar. A sobrecarga nas pessoas resulta em problemas de segurança e qualidade, e nos equipamentos causa interrupções e defeitos.
Muda (nenhuma agregação de valor): relaciona-se a qualquer atividade que consuma
recursos sem criar valor para o cliente, a atividades supérfluas que aumentam os lead times – que se referem ao tempo entre a entrega da matéria-prima e a saída do produto ou serviço finais, prontos para a entrega – pois causam movimentos extras para obter peças ou ferramentas, criam excesso de inventário/estoques ou resultam em aumento de diversos tipos de espera no processo.
A influência nos modelos de desenvolvimento ágil de software é tão forte que alguns autores apresentam, inclusive, comparações entre os desperdícios identificados na manufatura e os identificados no desenvolvimento de software, conforme exemplo apresentado no Quadro 7, cujo autor se baseia na premissa de que os passos fundamentais no desenvolvimento de software são a análise e a codificação (PROPPENDIECK; PROPPENDIECK, 2003).
Quadro 7 - Desperdícios na manufatura e no desenvolvimento de software
Fonte: Proppendieck e Proppendieck (2003).
Abaixo, é apresentada uma breve descrição de cada um dos sete desperdícios da manufatura listados no quadro, de acordo com Shingo (1996). Ao lê-los, torna-se possível fazer inferências quanto aos equivalentes no desenvolvimento de software:
Inventário ou estoque: está relacionado ao fato de que o acúmulo de produtos gera investimentos desnecessários para a organização, ao desperdício com inventários em organizações que mantêm estoques, os quais imobilizam o capital e não adicionam valor à empresa;
Excessos com processamento ou processos desnecessários: é inerente a atividades ou funções que não agregam valor, a atividades que não alteram o produto ou cuja alteração não seja percebida pelo cliente final, como características desnecessárias do produto, e também tem relação com o uso inapropriado de competências e ferramentas;
Transporte: relativo a qualquer transporte de materiais, normalmente oriundo de excessos em instalações ou em processos, os quais impõem distâncias ou obstáculos a serem transpostos, tratando-se de um processo que não agrega valor, pois não altera o produto e, por isso, deve ser eliminado ou minimizado;
Espera: ocorre devido à falta de materiais a serem processados, o que provoca ociosidade de mão-de-obra, informação ou recursos, quando o fluxo de valor permanece estático;
Movimentação: refere-se a qualquer movimentação que gere fadiga e seja desnecessária, podendo estar relacionada a esforço físico, de falta de acesso pelas pessoas a ferramentas, a informações ou a outras pessoas;
Defeitos: tem relação com a fabricação de produtos defeituosos, os quais geram custos para a organização e demandam mais recursos para que seja feita sua reposição; e
Produção exagerada: tem dois tipos, um com relação a fazer mais produtos do que realmente é necessário (quantitativa) e outro relacionado a produzir antes que seja necessário (qualitativa). Impacta em todos os outros, pois haverá o transporte, a espera do produto no estoque, a movimentação do operador para levar o produto, o processamento extra caso ocorra alguma alteração no produto, etc.
Outros três importantes conceitos do Sistema Toyota de Produção que inspiraram os métodos ágeis são a produção puxada, o fluxo contínuo e o nivelamento da produção (ou Heijunka). A produção puxada é o método de controle da produção em que as atividades de um fluxo posterior avisam às atividades de um fluxo anterior quanto às suas necessidades. Dessa forma, uma etapa do processo só produz (materiais ou informações) quando a etapa posterior requisita. O acionador de todo o processo seria a solicitação do cliente em si (GHINATO, 1996).
Para viabilizar a produção puxada, vêm os conceitos de fluxo contínuo e Heijunka. O fluxo contínuo se refere à produção de um item ou pequenos lotes de item por vez ao longo de uma série de etapas de processamento, continuamente, sem interrupções, sendo que em cada etapa se realiza apenas o que é exigido pela etapa seguinte (GHINATO, 1996).
Já o Heijunka é o nivelamento do tipo e da quantidade de produção durante um período fixo de tempo, é a criação de uma programação nivelada através do sequenciamento de pedidos em um padrão repetitivo e do nivelamento das variações diárias de todos os pedidos para corresponder à demanda no longo prazo. Ele que permite à produção atender eficientemente às exigências do cliente, ao mesmo tempo em que evita excesso de estoque, reduz custos, mão-de-obra e tempo entre a entrega da matéria-prima e a saída do produto ou serviço em todo o fluxo de valor (GHINATO, 1996).
Dessa forma, Leffingwell (2011) apresenta, em seu livro, um trecho intitulado „gerenciamento de requisitos em ágil é fundamentalmente diferente‟. Primeiramente, ele faz referência aos dois primeiros princípios do manifesto ágil: nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado; e mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento, pois processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
A ideia é que os métodos ágeis fazem uso de uma abordagem mais flexível para gerenciamento dos requisitos, tratando-os de maneira mais temporal, interativa e sob demanda, sem o uso de especificações tradicionais de requisitos ou de projeto, e sem o compromisso de entregar todo o escopo num prazo ou com um custo fixos. Com isso, o triângulo de ferro do gerenciamento de projetos é alterado, pois passa a ter cronograma e recursos fixos, enquanto o escopo (ou os requisitos) é que são variáveis (LEFFINGWELL, 2011). A visão prática de como isso acontece será apresentada no tópico que abordará o modelo de desenvolvimento ágil Scrum, enquanto a Figura 12 apresenta a ideia de maneira visual.
Figura 12 - Métodos ágeis fixam recursos e prazos e variam o escopo
Fonte: Leffingwell (2011).
Outra fonte de inspiração dos métodos ágeis, segundo Meso e Jain (2006), são aspectos relacionados à teoria de sistemas complexos e sistemas adaptativos. Segundo esses autores, estudos indicam que metodologias utilizadas na aplicação dos métodos ágeis usam alguns conceitos e princípios de auto-organização chamados isomorphies, que representam padrões pelos quais sistemas complexos adaptativos podem florescer e se adaptar diante de desafios no ambiente que os circunda.
Em suma, as metodologias ágeis são pautadas por interações mais curtas e pela busca por equilíbrio entre ausência de processo e excesso de processo, no sentido de que seja contemplado apenas o mínimo necessário para o retorno desejado. Devem ser analisadas com foco na sua capacidade de adaptação e na diretriz para que as pessoas estejam em primeiro lugar, e não com foco na interpretação restrita dos termos leveza ou agilidade (FOWLER, 2005).
Originalmente, os métodos ágeis foram adotados por times de três a oito pessoas, as quais trabalhavam em um único produto. Ultimamente, a tendência tem sido estendê-los ao
nível empresarial, utilizá-los em larga escala (RAUTIAINEN; SCHANTZ; VÄHÄNIITTY, 2011). Segundo pesquisa realizada pela Forrester Research, nos últimos anos tais métodos não só ganharam aumento nos níveis de adoção, como também rapidamente passaram a fazer parte do pensamento dominante das abordagens de desenvolvimento (FORRESTER, 2010).
Numa pesquisa realizada por Begel e Nagappan (2007), onde foram estudados o uso e as percepções dos métodos de desenvolvimento ágil de software na Microsoft, são relatados os principais benefícios e problemas identificados. O estudo tem relevância por ser um dos poucos encontrados que avaliam a questão num ambiente em que os métodos ágeis são empregados em larga escala. A pesquisa foi enviada para mais de 2.800 engenheiros da Microsoft e teve 487 respostas válidas, o equivalente a 18% dos desenvolvedores, 18% dos testers e 10% dos gerentes de programas da empresa, com média de 9,2 anos de experiência profissional.
A Tabela 2 e a Tabela 3 apresentam, respectivamente, os principais dez principais benefícios e os dez principais problemas com métodos ágeis identificados por meio da pesquisa. Em ambos os quadros são apresentadas duas colunas, uma com o nome do benefício ou problema e a outra com a quantidade de vezes que o item foi citado.
Tabela 2 - Principais benefícios dos métodos ágeis
Tabela 3 - Principais problemas dos métodos ágeis
Fonte: Begel e Nagappan (2007).
Os principais modelos de desenvolvimento ágil de software utilizados nos últimos anos, dentre eles o Scrum e o XP, são baseados nos princípios definidos no Manifesto Ágil e buscam melhor time-to-market, clientes mais satisfeitos e software de melhor qualidade (FOGELSTRÖM et al., 2009; RAUTIAINEN; SCHANTZ; VÄHÄNIITTY, 2011). No próximo tópico é feita uma breve descrição a respeito de alguns deles.
3.2 MODELOS
Em notícia veiculada na revista Application Development Trends, especializada em notícias sobre novidades, desafios e melhores práticas em desenvolvimento de aplicações, são mencionados alguns resultados de uma pesquisa sobre o mercado de desenvolvimento de software norte-americano em 2009. Dentre eles, dados indicam que metodologias ágeis como Scrum e XP são a abordagem primária de desenvolvimento para pelo menos 39% dos desenvolvedores norte-americanos participantes da pesquisa, enquanto o desenvolvimento em cascata é a metodologia primária de apenas 16,5% dos respondentes. Também é verificado que entre 2008 e 2009 houve um crescimento de 9% no número de desenvolvedores que utilizam métodos ágeis em alguma parte do seu trabalho (DESMOND, 2010).
Já em outra pesquisa, publicada em maio de 2010 pela Forrester Research Inc., verificou-se que metodologias categorizadas como ágeis, dentre elas Scrum, XP e FDD, foram indicadas como o método primário de desenvolvimento por pelo menos 35% dentre 1.298 profissionais pesquisados. Os métodos iterativos apareceram com 21% e o
desenvolvimento em cascata com 13% (WEST; HAMMOND, 2010). A Figura 13 apresenta os resultados com mais detalhes:
Figura 13 - Resultados de pesquisa sobre abordagens de desenvolvimento
Fonte: Forrester (2010).
Tais informações demonstram que os métodos de desenvolvimento ágil de software já têm grande representatividade e vêm ganhando cada vez mais espaço, o que confirma as informações sobre o aumento da aceitação dos métodos ágeis na indústria nos últimos 10 anos, apresentadas no capítulo introdutório a partir de afirmações feitas por Rautiainen, Schantz e Vähäniitty (2011), e Carvalho e Mello (2009).
Também é possível verificar que algumas metodologias específicas têm sido adotadas com maior frequência, como é o caso do Scrum, que aparece com 10,9% dentre todas as metodologias, conforme dados apresentados na Figura 13. Noutra pesquisa, publicada pela VersionOne (2010), também foi feito um estudo sobre a adoção das metodologias, mas considerando apenas as inspiradas nos princípios ágeis. O Scrum aparece mais uma vez como a metodologia mais comumente empregada, conforme mostra a Figura 14.
Figura 14 - Metodologias ágeis mais comumente adotadas
Fonte: VersionOne (2010).
Cumpre destacar que não foram identificados estudos que apresentem um panorama sobre a adoção das metodologias ágeis no Brasil, nem tampouco na Administração Pública Federal.
Proceder-se-ão a seguir a uma breve apresentação sobre algumas das metodologias ágeis mais citadas. Cumpre destacar, antes, que a metodologia Scrum se mostrou a mais amplamente adotada e constitui objeto de estudo do presente trabalho, por isso, será apresentada com maiores detalhes em um tópico específico.
Extreme Programming (XP) 3.2.1
Segundo Teles (2005), a fundamentação da Extreme Programming (XP) tem relação com as práticas de desenvolvimento presentes na comunidade que lidava com o desenvolvimento de software na linguagem SmalTalk, uma linguagem de programação orientada a objetos. Dentre tais práticas, podem ser citadas a refatoração, a programação em pares, as mudanças rápidas, o feedback constante com o cliente, o desenvolvimento iterativo, os testes automatizados e outras.
Data de 1996 o primeiro relato de uso conjunto das práticas da XP, ano em que o senhor Kent Beck, que trabalhava como consultor para melhoria de desempenho em desenvolvimento de software na linguagem SmalTalk, foi contratado para analisar um projeto de conversão do sistema de folha de pagamento da Chrysler. Durante o projeto, ele acabou
apontando várias oportunidades de melhoria no processo de desenvolvimento e buscou implantar práticas baseadas na sua experiência como consultor. Essas práticas viriam a compor o modelo de desenvolvimento ágil XP (Kent, 1999).
As práticas adotadas em XP não são novas em si mesmas, mas foram consolidadas e alinhadas a partir de várias iniciativas para melhoria do processo de desenvolvimento, a fim de funcionarem umas com as outras de maneira integrada e inovadora, formando assim uma nova metodologia para desenvolvimento de software (BECK, 1999). Nas palavras de Beck (1999), após várias experimentações práticas de sucesso, a metodologia foi teorizada por meio de princípios e práticas. O termo extremo tem como propósito inspirar a ideia de que os princípios e práticas da metodologia sejam levados ao extremo.
Na Figura 15 é apresentado o ciclo de vida do processo XP. Destaca-se o objetivo de serem entregues frequentemente pequenas versões do produto, por meio de interações curtas, alimentadas pelos comentários e opiniões sobre a última versão entregue (BECK, 1999).
Figura 15 - Ciclo de vida do processo XP
Fonte: Abrahamsson et al. (2002).
A metodologia XP é composta das fases de: exploração, onde o cliente escreve histórias em cartões, cada um contendo funcionalidades desejadas para o primeiro release; planejamento, onde são definidas, em conjunto com o cliente, as prioridades das histórias e as estimativas de esforço e prazo; interações para release, que contempla as diversas interações rumo à conclusão do primeiro release, iniciando-se pela arquitetura e com as funcionalidades