Processos ÁgeisAprenda o que são processos ágeisConheça as metodologias Scrum e Extreme Programming e quais as diferenças entre as metodologias tradicionais e ágeis Leonardo Simas, Osias Carneiro, Vagner Fonseca e Weslley Leandro

O desenvolvimento de tecnologias e a necessidade crescente de sistemas de informação vem desafiando as empresas responsáveis pela criação de aplicações. É difícil acompanhar as mudanças de tecnologias, as soluções cada vez mais complexas, as interferências do mundo externo, mudanças nos requisitos, entre outros. Para tentar amenizar esses problemas, a Engenharia de Software procura definir metodologias de desenvolvimento de software, que possibilitam uma organização nos processos e etapas desde sua especificação até a implantação, como os processos ágeis. Há diversas maneiras de se desenvolver um software de maneira rápida, por meio dos métodos ágeis de desenvolvimento de software. Essa metodologia de desenvolvimento evoluiu a partir da metade dos anos 90, com o fortalecimento da Engenharia de Software e com o surgimento de novas maneiras de se pensar ao construir um software. O objetivo deste artigo consiste em realizar uma abordagem a respeito das metodologias tradicionais e as metodologias de processos ágeis, apresentando um breve histórico e focando nas duas principais metodologias de desenvolvimento “Scrum” e “Extreme Programing (XP)”. Metodologias TradicionaisO modelo em Cascata, um dos mais utilizados até pouco tempo atrás (LEACH, 2000), definia etapas que deveriam ser sequenciais, uma só deve ser iniciada após o termino da sua antecessora, como observado na Figura 1. Um modelo inflexível onde o cliente só poderia validar o que foi desenvolvido no final do processo depois do software completamente desenvolvido, alterações na especificação eram difíceis ou simplesmente impossíveis de serem realizadas durante o desenvolvimento. Muitas vezes gerava o famoso “big bang” onde no final o software já não atendia as necessidades por mudanças no ambiente externo ou precisava ser alterado e um novo fluxo se iniciaria. O modelo em Espiral (Figura 2) sugere uma sequência de etapas mas, diferente do cascata, o

software é divido em versões chamadas de incremento. Possui quatro atividades:1. Determinação dos objetivos da iteração2. Análise dos riscos3. Desenvolvimento4. Validação, Testes e planejamento da próxima iteração

Figura 1. Etapas do modelo em cascata

Dessa forma é possível lidar melhor com alterações durante o projeto e a validação do que se está desenvolvendo é melhor para o cliente, que acompanha o desenvolvimento. Mas assim como no modelo em cascata não permite etapas sendo realizadas em paralelo ou que precisem de comunicação com outras etapas.

Figura 2. Modelo em Espiral

O modelo Iterativo e Incremental apresenta um ciclo de vida iterativo baseado no aumento e no refinamento sucessivo de um sistema através de múltiplos ciclos de desenvolvimento de análise, de projeto, de implementação e de teste” (LARMAN, 2000).

Atualmente é o modelo mais utilizado, ou outros modelos baseados neste, que traz alguns benefícios como (MARTINS, 1999):

● A redução de riscos com os custos e prazos planejados;● A equipe fica focada com os objetivos de cada incremento, trabalhando de maneira mais

eficiente;Um modelo emergente que combina um melhor gerenciamento e a preocupação com “como as pessoas trabalham” (CANTOR, 1999).

Figura 3. Modelo Iterativo e Incremental Processos ÁgeisAs metodologias ágeis promovem o desenvolvimento com o trabalho em equipe, colaboração e adaptabilidade durante o ciclo de vida do projeto. Assim como no modelo iterativo e incremental, o software é dividido em versões, ou seja, possuem incrementos que são partes menores do software e são realizados em torno de uma a quatro semanas, passando por todas as etapas desde especificação até a fase de testes.

Com o objetivo de minimizar a quantidade dos possíveis erros a cada iteração, ela pode não gerar uma versão com funcionalidade suficiente para o mercado e várias iterações podem ser necessárias para lançar uma nova funcionalidade.

Há uma priorização na comunicação “cara a cara” entre os integrantes da equipe do que a documentação (não quer dizer que não há documentação) e por isso sugere que todos trabalhem na mesma sala.

É necessário um representante do cliente para que se possa tirar dúvidas e esclarecer questões que possam surgir durante as iterações e que esteja disponível para atender os os demais participantes no projeto do software. Manifesto ÁgilAo passar dos anos as organizações passaram a estar mais focadas em resultados rápidos e

precisos, contratando empresas de desenvolvedoras de software para agilizar os seus processos institucionais e devido aos projetos de software sofrer diversas transformações, nos últimos tempos metodologias de desenvolvimento, como o Scrum e o XP, se fortaleceram. Entre elas, a metodologia de desenvolvimento ágil de software se consolidou no mundo de desenvolvimento de software e em 2001 o “Manifesto Ágil” termo criado após a criação da Aliança Ágil onde foram apresentados alguns métodos de desenvolvimento de software entre eles se destacam os métodos Scrum e Extreme Programming (XP), e também foram fundamentados alguns princípios e características entre os métodos. Esses métodos aumentam o desempenho e provendo mais qualidade ao produto final. ScrumNo início do ano de 1986 Hirotaka Takeuchi e Ikujiro Nonaka, escreveram um artigo, foi observado que equipes pequenas e com baixo nível de especialização, obtêm melhores resultados do que equipes grandes, nisso há uma semelhança com uma equipe de rugby, quando uma falta é cometida, eles se arranjam em uma formação coesa de nome Scrum.

O Scrum é uma metodologia ágil iterativa e incremental, pois trata-se de um framework que facilita a visualização de problemas, mesmo os que possuem de dificuldade elevada.

Scrum tem por objetivo agregar o máximo de valor ao negócio com o menor tempo possível, focando no Retorno de Investimento (ROI), administrando complexidade, imprevisibilidade e mudança por meio da visibilidade, inspeção e adaptação (SUTHERLAND, 2002).

Quanto aos papéis executados o Scrum determina três (SCHWABER, 2009):

● Scrum Master - Tem a função de líder de equipe, protegendo-a de obstáculos e problemas que a impeçam de realizar seu trabalho.

● Product Owner - Maximiza o trabalho do time Scrum, definir recursos, escolher datas de lançamento, fornecer feedback dos processos e garantir que as regras Scrum sejam seguidas, ou seja, é o cliente ou alguém que o represente.

● Time Scrum - Responsável pelo desenvolvimento do projeto, tem de 5 à 9 integrantes, define tarefas e o esforço para realizar as tarefas com a qualidade desejada pelo Product Owner.

Para SUTHERLAND(2008) as princípais ferramentas do Scrum são o backlog do produto, backlog do sprint, burndown para entrega e burndown do sprint.

SCHWABER(2009) define que o backlog do produto é um documento com requisitos separados por prioridades que são indispensáveis ao produto. Backlog do sprint é a lista de tarefas que a equipe executará para transformar o backlog do produto em um incremento entregavel ao cliente. Um burndown de versão para entrega mede o backlog de produto restante ao longo do tempo de um plano de entrega. O burndown de sprint mede os ítens do burndown de sprint restantes ao longo do tempo de uma sprint.

O scrum utiliza-se de eventos de duração fixa, planejamento de versão para entrega, sprint, reunião diária, revisão e retrospectiva da sprint

● Planejamento da versão: é onde os documentos que definem os requisitos do produto são concebidos (backlog de produto), suas prioridades e a estimativa de esforço para cada requisito.

● Reunião da sprint: aqui os requisitos são apresentados à equipe e são definidos, de acordo com a habilidade de cada um, a tarefa que executarão (backlog da sprint) essa reunião tem em média 3 a 12 horas dependendo da sprint.

● Sprint: para SCHWABER (2009) essa fase é a coroação do Scrum, com duração por volta de 30 dias, nesse momento os requisitos são desenvolvidos e implementados, ao final é entregue um incremento funcional ao cliente.

● Revisão da sprint: Reunião entre a equipe com no máximo duas horas de duração onde os resultados são apresentados, deve-se ter cuidado ao dizer “realizado” já que os resultados serão apresentados ao cliente.

● Retrospectiva do sprint: Nessa reunião verifica-se o que foi feito de positivo e também os pontos negativos, afim de revisar o que foi feito de errado para ser corrigido em versões posteriores, atualizando-se o backlog do produto.

Figura 4. As etapas da metodologia Scrum e sua duração média Extreme Programming (XP)O Extreme Programming (XP), metodologia criada por Kent Beck, está voltado principalmente para pequenas e médias equipes, visando o desenvolvimento de software que se baseiam em requisitos vagos e que se modificam rapidamente (Beck, 1999). O método XP se diferencia dos demais devido a uma abordagem incremental, fortalecendo a comunicação (feedback) entre as pessoas envolvidas no processo de desenvolvimento. O XP possui quatro valores fundamentais: comunicação, simplicidade, feedback e coragem (Beck, 1999). Para alcançar sucesso na utilização do XP, é preciso seguir todos esses valores.

● Comunicação: deve ocorrer da maneira mais direta (face-a-face) e eficaz possível, a fim de oferecer agilidade aos assuntos tratados, esclarecendo dúvidas de imediato e evitando especulações ou mal entendidos entre as partes. O cliente deve estar a disposição da equipe e membros introvertidos devem ser evitados.

● Simplicidade: é preciso simplicidade no desenvolvimento das funcionalidades solicitadas. O desenvolvedor deve implementar apenas o necessário para atender ao usuário, sem se preocupar com funcionalidades que podem ser importantes no futuro, pois elas podem nunca ser utilizadas.

● Feedback: com partes funcionais em mãos, o cliente estará apto a conduzir a equipe de desenvolvimento, estabelecendo prioridades e identificando erros imediatamente. Em contrapartida, o desenvolvedor poderá apontar riscos e estimativas.

● Coragem: por se tratar de uma metodologia nova, que contraria o modelo tradicional, a equipe precisa de coragem para implantar os três valores anteriores. Nem todos possuem facilidade de comunicação ou paciência para obter feedback constante do cliente.

Além dos quatro valores básicos, o XP baseia-se em diversas práticas (Figura 5). Para Beck (1999) existem doze principais práticas de desenvolvimento, elencadas e descritas abaixo:

● Planejamento: consiste em definir o que será feito e o que será adiado. O foco deve estar nos requisitos atuais e não nos futuros. A escolha deve gerar o máximo de valor para o cliente.

● Entregas frequentes: trata-se de construir um software simples e em seguida adicionar funcionalidades conforme elas forem surgindo. Com isso, o feedback do cliente será mais rápido e surpresas serão evitadas.

● Metáfora: são comparações e analogias utilizadas para explicar situações mais facilmente, sem o uso de termos técnicos. Essa técnica facilita a comunicação e a fixação dos assuntos entre as partes.

● Projeto simples: o software desenvolvido deve ser o mais simples possível para resolver o problema atual do cliente, sem se preocupar com requisitos futuros. Esses devem ser adicionados assim que forem realmente necessários.

● Testes: garantem resultados corretos das funcionalidades. Os testes devem ser feitos de preferência antes do desenvolvimento (TDD - Test Driven Development).

● Programação em pares: dois desenvolvedores trabalharão em um único computador. Enquanto um codifica o outro observa, buscando estratégias para otimizar o código do colega. A troca de experiências e idéias é um dos grandes benefícios.

● Refatoração: consiste em reescrever um código ilegível, duplicado, despadronizado etc. sem alterar o seu comportamento.

● Propriedade coletiva: o código pertence a toda a equipe. Dessa forma, qualquer desenvolvedor que julgar necessário modificá-lo, poderá fazé-lo.

● Integração contínua: a integração entre as partes do software deve ser efetuada, preferencialmente, várias vezes ao dia.

● 40 horas de trabalho semanal: mais de 40 horas semanais de trabalho significa problema no projeto e deve ser resolvido com melhor planejamento, não com aumento de horas trabalhadas.

● Cliente presente: o cliente deve estar sempre disponível para tirar dúvidas, evitando atrasos na comunicação e implementações erradas. É interessante torná-lo parte da equipe de desenvolvimento.

● Código padrão: seguir padrões previamente acordados de codificação reforça a comunicação entre os programadores, facilitando o entendimento e a manutenção.

Figura 5. Valores, princípios e práticas do Extreme Programming Relato - Implantação de Processos ÁgeisSegundo o estudo de caso realizado no Banco Central do Brasil (MELO e FERREIRA, 2010), a implantação de processos ágeis pode solucionar questões que não são abordadas pelas metodologias tradicionais. A empresa utilizava um processo derivado do Rational Unified Process (RUP), um processo iterativo, mas robusto. A empresa planejou dois projetos pilotos com duas equipes contendo 7 e 6 pessoas respectivamente, sendo que a maioria dos desenvolvedores possuíam experiência de 2 ou mais anos na área de desenvolvimento, mas poucos conheciam as metodologias a serem utilizadas ou sobre os conceitos de processos ágeis. No início do primeiro projeto foram apresentados os conceitos sobre métodos ágeis e as metodologias Scrum e XP, para familiarização da equipe. Segundo o relato (MELO e FERREIRA, 2010), as equipes compreenderam e aplicaram facilmente as práticas de pares e de equipes do XP, sendo que a programação em pares foi de fácil compreensão e absorção pela equipe e a prática

da “metáfora” a mais complexa de ser interpretada. A prática de execução de testes pelo cliente bem como as entregas curtas, apesar de bem compreendidas, não foram de fácil aplicação devido cultura do cliente. Mesmo que as entregas agregassem funcionalidades de certo valor, a organização não tinha o costume de receber soluções inacabadas. A equipe relata que houve um ganho quanto a rapidez no aprendizado de tecnologias, conceitos e padrões. A produtividade foi medida nos dois projetos pilotos utilizando, a medição por pontos de função e pelas horas gastas nos mesmos. No primeiro houve um ganho de mais de 8% e no segundo mais de 30% em relação a média da organização. O primeiro era mais complexo que o segundo e a curva de aprendizado foi maior, pois foi a primeira vez que utilizaram processos ágeis e o segundo aprendeu com os erros do primeiro. Os clientes compararam os resultados obtidos com suas experiências passadas usando metodologias tradicionais, com isso foi gerado uma nítida satisfação do cliente, pois foi possível observar benefícios como:

● Redução no prazo de entrega● Facilidade/possibilidade de alterações● Entendimento aprimorado sobre os custos● Maior segurança quanto aos testes realizados

A implantação de qualquer metodologia em uma organização é um processo lento, complexo e exige mudanças na cultura organizacional da empresa, logo dois pilotos não foram suficientes para a mudança. Mas os ganhos com produtividade e satisfação do cliente compensam tais custos e obstáculos e favorece a implementação. ConclusãoNeste artigo abordamos a respeito do Scrum e XP que são metodologias de desenvolvimento de software utilizadas nos projetos piloto do Banco Central do Brasil. Aplicar um processo ágil em uma organização requer uma mudança na cultura da mesma exigindo tempo e gerenciamento dessa implantação. A organização deve precisa ter um ambiente favorável a comunicação, o tamanho do projeto pode inviabilizar essa comunicação, são indicadas a formação de equipes de no máximo 20 ou 40 pessoas sendo ela composta por pessoas experientes. Os processos ágeis atendem muito bem projetos e organizações que preenchem esses requisitos mas apesar de já proporcionarem resultados de sucesso há aqueles que afirmam que ainda é preciso de mais resultados para comprovar o sucesso desses métodos.

Referências

OLIVEIRA, Alexsandro; MATEUS, Andrade; VINICIUS, Corrêa; Uma Introdução às Metodologias Ágeis de Desenvolvimento de Software. Salvador, Bahia. SILVA, Maysa Alves da Conceição; FILHO, Heitor Roriz; SILVA, Helena de Fátima Nunes; Análise do BA durante o processo Scrum. Artigo apresentado no XVII Simpósio de engenharia de produção, Bauru, São Paulo, Brasil, 2010. BONA, Cristina. Avaliação de Processos de Software: Um Estudo de Case em XP e ICONIX. 2002. 122 f. Dissertação (Mestrado em Engenharia de Produção) - Universidade Federal de Santa Catarina. Florianópolis, 2002. Agile Alliance. Acesso em: 25 de julho de 2011. Disponível em: <http://www.agilealliance.org> Manifesto para Desenvolvimento Ágil de Software. Acesso em 26 de julho de 2011. Disponivel em <http://agilemanifesto.org/iso/ptbr/> Agile Software Development. Acesso em 29 de julho de 2011. Disponível em: <http://en.wikipedia.org/wiki/Agile_software_development> Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Acesso em 28 de julho de 2011. Disponível em:<http://www.inf.ufrgs.br/~dsogari/material/S5/INF01127/Material/Comparacao-Metodos-Ageis-Tradicionais.pdf> MELO, Claudia de O, FERREIRA, and Gisele R. M. Adoção de métodos ágeis em uma Instituição Pública de grande porte - um estudo de caso., In Proceedings of the Brazilian Workshop for Agile Methods (WBMA 2010) in the Brazilian Conference on Agile Methods (Agile Brazil 2010), pp. 112-125. June, 2010. Disponível em: <http://www.agilcoop.org.br/files/WBMA_Melo_e_Ferreira.pdf>

Leonardo Simas (leosimasgoncalves@gmail.com) é graduando em Sistemas de Informação pela Universidade do Estado da Bahia (UNEB) e estagiário no Instituto Recôncavo de Tecnologia.

Osias Carneiro (osiascarneiro@hotmail.com) é graduando em Sistemas de Informação pela Universidade do Estado da Bahia (UNEB) e estagiário no Instituto Recôncavo de Tecnologia.

Vagner Fonseca (vagner.fonseca@gmail.com) é graduando em Sistemas de Informação pela Universidade do Estado da Bahia (UNEB), foi coordenador do grupo de desenvolvimento da XI Escola Regional de Computação Bahia Alagoas Sergipe (XI ERBASE), participou do projeto de desenvolvimento de agente para sistema de Segurança de Notebooks Leadership e estagiário da Gerência de Informática da UNEB.

Weslley Leandro (weslleyleandro@gmail.com) é graduando em Sistemas de Informação pela Universidade do Estado da Bahia (UNEB) e estagiário na Wcs Design.