Capítulo 2 Processos Ágeis de Desenvolvimento de Software



Baixar 198.02 Kb.
Página1/5
Encontro04.08.2016
Tamanho198.02 Kb.
  1   2   3   4   5
Capítulo

2
Processos Ágeis de Desenvolvimento de Software

Márcio Amorim de Medeiros1, Milton Moura Campos Neto2

Este capítulo discute sobre Processos Ágeis de desenvolvimento de software, uma nova abordagem de desenvolvimento, que surgiu como uma alternativa aos Processos Tradicionais na tentativa de reduzir os problemas e custos dos projetos de software. Ao longo deste capítulo será feita uma contextualização a respeito do paradigma ágil e enfatizado alguns processos como o Extreme Programming (XP), o Scrum e o Feature Driven Development (FDD).



2.1 Introdução

Os processos tradicionais de desenvolvimento de software não se adéquam à realidade de algumas organizações, em especial, as pequenas e médias fábricas de software que não possuem recursos suficientes para seguirem algum processo. Neste contexto, os processos ágeis surgiram como uma nova tendência de desenvolvimento para melhorar a qualidade dos sistemas e reduzir a quantidade de projetos fracassados, eliminando gastos com documentação excessiva, enfatizando a comunicação face-a-face, sendo mais flexíveis às mudanças e privilegiando as atividades que agregam maior valor ao negócio.

Os métodos tradicionais e os ágeis possuem o mesmo objetivo: satisfazer as necessidades dos usuários construindo sistemas de qualidade. A diferença entre eles está nos princípios utilizados por cada um [SATO 2007]. Os princípios relacionados aos processos tradicionais já foram abordados no Capítulo 1, já os ágeis serão detalhados no decorrer deste capítulo.

A adaptabilidade à mudança é um fator que deve está presente em um software, a fim de atender às novas necessidades dos clientes, das instituições ou do mercado. Os processos tradicionais tendem a planejar grande parte do desenvolvimento do software por um longo período antes de iniciar a implementação. Com isso, o software demora a ser disponibilizado ao cliente. Durante este tempo podem surgir novos padrões, políticas e tecnologias que afetam os requisitos do software, o cliente pode perceber que alguma funcionalidade não está conforme solicitado ou precisar de outras. Estes fatores implicam em mudança no sistema, que não são bem-vindas nos processos tradicionais, pois a fase de planejamento já foi concluída.

Outro fator que pode acontecer no desenvolvimento tradicional é a implementação de funcionalidades que não agregarão valor ao cliente, ou seja, o sistema disponibiliza funcionalidades aos usuários que serão de pouca ou nenhuma utilidade, enquanto outras mais prioritárias ainda não foram implementadas.

Os processos ágeis surgiram com a finalidade de desburocratizar o processo de desenvolvimento de software. Eles tentam se adaptar e se fortalecer com as mudanças. Os clientes têm, em curto espaço de tempo, versões de software executável, nas quais são priorizadas as funcionalidades que agregam mais valor ao seu negócio. Com isso, eles já podem sugerir novas funcionalidades e correções nestas versões intermediárias.

Na agilidade, outro fator determinante é o fato de “não documentar, apenas por documentar”. Só é documentado aquilo que for necessário em outro momento e que justifique o esforço e recursos gastos na documentação. Segundo [BECK 2000], nos processos ágeis, a documentação se restringe às estórias dos usuários, que são descrições simples do funcionamento do sistema, usadas para ajudarem os envolvidos no projeto a terem uma visão de seu funcionamento e entenderem os elementos básicos do projeto e seus relacionamentos.

Os Processos ágeis são orientados a pessoas ao contrário dos tradicionais que são orientados a processos. Assim, processos ágeis afirmam que a habilidade da equipe de desenvolvimento é imprescindível durante o desenvolvimento de software. O papel do processo é, por sua vez, dar suporte à equipe durante o trabalho



2.2 O Manifesto Ágil

No início de 2001, 17 especialistas em software reuniram-se para propor um conjunto de princípios e valores para agilizar o desenvolvimento dos seus sistemas tendo como base suas experiências em programação. Tais princípios foram motivados pela conclusão de que os processos de desenvolvimento estavam tornando-se cada vez mais burocráticos, dificultando a visibilidade e o entendimento das equipes de construção de softwares.

A essência deste movimento em prol da agilidade foi a definição de um novo enfoque de desenvolvimento de software, calcado no ágil, na flexibilidade, nas habilidades de comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de tempo. [HIGHSMITH 2004]

Como produto deste movimento, marco inicial do desenvolvimento ágil de software, foi produzido o Manifesto Ágil conforme ilustrado no Quadro 2.1



Quadro 2.1 O Manifesto Ágil. Adaptado de [AGILE MANIFESTO 2009]

Nós estamos descobrindo melhores maneiras de desenvolver software, fazendo e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:



Indivíduos e interação entre eles mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano
Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.


Assinam este manifesto:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,

Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,

Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas.




Os envolvidos na concepção do Manifesto Ágil se autodenominaram de Aliança Ágil. Os quatro valores propostos no manifesto foram então traduzidos em doze princípios que estão descritos a seguir:

  • A maior prioridade é satisfazer o cliente através de entregas antecipadas e contínuas de software de valor;

  • Mudanças de requisitos são bem vindas, mesmo que tardiamente no desenvolvimento. Processos ágeis tiram proveito das mudanças visando vantagem competitiva para o cliente;

  • Entrega frequente de software funcionando, em intervalos de duas semanas de trabalho até dois meses, com preferência a escala de tempo mais curta;

  • Pessoas das áreas de software e de negócios devem trabalhar juntas diariamente durante o desenvolvimento do projeto;

  • Construir projetos em torno de indivíduos motivados. Dê-los o ambiente e o suporte necessário e acredite neles para fazer o trabalho;

  • O Método mais eficiente e efetivo de repassar a informação dentro de uma equipe de desenvolvimento é a conversa face a face

  • Software funcionando é a primeira medida de progresso;

  • Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um passo constante indefinidamente;

  • Atenção contínua à excelência técnica e um bom projeto melhoram a agilidade;

  • Simplicidade: a arte de maximizar a quantidade de trabalho não realizado, é essencial;

  • As melhores arquiteturas, requisitos, e projetos emergem de times auto-organizáveis;

  • Em intervalos regulares, o time deve refletir sobre como se tornar mais efetivo, então melhora e ajusta seu comportamento de acordo com a reflexão.



  1   2   3   4   5


©principo.org 2016
enviar mensagem

    Página principal