Conheça os principais processos ágeis

PROCESSOS ÁGEIS DE DESENVOLVIMENTO DE

SOFTWARE

1Sistemas de Informação, Engenharia de Software – UNIME

Isaias Silva1, Everton Pereira

1, Diógenes Duarte

1

{isaiasilva.info}@gmail.com, {evertonps.20, wanteddio}@hotmail.com

Resumo. Atualmente os métodos de desenvolvimento de software tem despertado um

grande interesse da comunidade de engenharia de software, e organizações que buscam

uma alternativa para os processos de desenvolvimento de sistemas de uma maneira

rápida, simples, eficiente e gerenciável, contornando assim os diversos problemas de

desenvolvimento de software existente. Hoje no mercado de tecnologia de informação e

de projetos vários métodos que utilizam a abordagem ágil e que, por seguirem os

princípios ágeis, apresentam uma série de atividades semelhantes no seu processo

interno de desenvolvimento. Este artigo apresenta uma comparação entre os processos

propostos pelos métodos ágeis XP, SCRUM, FDD e ASD efetuando uma abordagem

que os diferencie, apresentando um breve histórico de como surgiu tal metodologia e

focando em dois dos diversos métodos existentes o “SCRUM” e o “EXTREME-

PROGRAMMING”, abordaremos também uma entrevista sobre a adoção dos métodos

ágeis nas organizações.

Palavras-chave: XP, SCRUM, FDD, ASD, MÉTODOS ÁGEIS, ÁGEIS,

DESENVOLVIMENTO.

1. INTRODUÇÃO

À medida que as organizações tornam-se cada vez mais dependentes da indústria do

software, ficam mais evidentes os problemas relacionados ao processo de

desenvolvimento de sistemas: alto custo, alta complexidade, dificuldade de manutenção,

e uma disparidade entre as necessidades dos usuários e o produto desenvolvido

(SOMMERVILLE, 2003). Acreditando que o processo utilizado é um dos motivos para a ocorrência desses

problemas, um segmento crescente da Engenharia de Software vem defendendo a

adoção de processos mais simplificados conhecidos como métodos ágeis, que visam à

desburocratização das atividades associadas ao desenvolvimento (FOWLER, 2001).

Os métodos ágeis de desenvolvimento, planejamento e análise de viabilidade e de uso

ao desenvolver ou iniciar o desenvolvimento de um novo sistema têm despertado um

grande interesse entre a comunidade de desenvolvimento de sistemas, programadores e

empresas, acredita-se que devido a esta demanda, uma considerável quantidade de

métodos apresentando características ágeis tem surgido nos últimos anos, métodos estes

que possa abordar e simplificar todas as fases desde a prototipagem até a entrega final e

que venha ser rápido simples e fácil de gerenciar.

Para auxiliar os profissionais, ligados ao desenvolvimento de software, interessados na

utilização da abordagem ágil que possibilite aos tais uma leque de possibilidades entre

os diversos métodos que se adapte às necessidades dos seus projetos, equipes e/ou

organizações, este artigo apresenta uma comparação entre os processos de

desenvolvimento de alguns destes, detalhando especificamente o Extreme Programming

(XP) (BECK, 2000) e o Scrum BEEDLE et al, 1998), falaremos também porém sem

entrar em muito detalhe do Feature Driven Development (FDD) (DE LUCA, 2002) e

Adaptive Software Development (ASD) (HIGHSMITH, 2002).

2. MÉTODOS ÁGEIS E O MANIFESTO ÁGIL

A “indústria do software” sempre contou com métodos cujos processos de

desenvolvimento eram baseados em um conjunto de atividades predefinidas, descritas

como processos prescritivos (AMBLER 2004), onde muitas vezes, o trabalho começava

com o levantamento completo de um conjunto de requisitos, seguido por um projeto de

alto-nível, de uma implementação, de uma validação e, por fim, de uma manutenção

(SOMMERVILLE 2003). A partir da década de 90, começaram a surgir novos métodos

sugerindo uma abordagem de desenvolvimento ágil onde os processos adotados tentam

se adaptar às mudanças, apoiando a equipe de desenvolvimento no seu trabalho (BECK,

et. al., 2001). Estes novos métodos surgiram como uma reação aos métodos

tradicionais1 de desenvolvimento de sistemas, ganhando com o passar dos anos um

número cada vez maior de adeptos.

Em fevereiro de 2001 um grupo de 17 programadores, engenheiros de software e

pessoas diretamente ligadas ao desenvolvimento de sistemas, entre eles, Robert C.

Martin, Andrew Hunt, Jim Highsmith, Brian Marick, Kent Beck e outros, formaram a

Aliança para o Desenvolvimento Ágil de Software, que formulou o manifesto ágil que

contem um conjunto de princípios na qual define os principais critérios para os

processos de desenvolvimento ágil de sistemas (AMBLER, 2004). Os doze princípios

(BECK, et. al. 2001), aos quais os métodos ágeis devem se adequar são:

Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e

contínua de software de valor.

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos

ágeis se adequam a mudanças, para que o cliente possa tirar vantagens

competitivas.

Entregar software funcionando com frequência, na escala de semanas até meses,

com preferência aos períodos mais curtos.

Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto

e diariamente, durante todo o curso do projeto.

Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e

suporte necessário, e confiar que farão seu trabalho.

O Método mais eficiente e eficaz de transmitir informações para, e por dentro de

um time de desenvolvimento, é através de uma conversa cara a cara.

Software funcional é a medida primária de progresso.

Processos ágeis promovem um ambiente sustentável. Os patrocinadores,

desenvolvedores e usuários, devem ser capazes de manter indefinidamente,

passos constantes.

Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser

feito.

As melhores arquiteturas, requisitos e designs emergem de times auto

gerenciáveis.

Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se

ajustam e aperfeiçoam seu comportamento de acordo.

Com base nos princípios descritos acima, cada um dos métodos ágeis - incluindo os

utilizados nesta comparação apresentam um conjunto de atividades a serem adotadas

durante o processo de desenvolvimento do sistema. É importante mencionar que antes

de iniciar a comparação entre as semelhanças e diferenças entre os métodos foi

realizado um estudo detalhado do método (XP, Scrum) e uma pequena abordagem dos

métodos (FDD e ASD).

3. METODOLOGIAS TRADICIONAIS

Antigamente, em meados da década de 70, os projetos de desenvolvimento de software

eram conduzidos de forma desorganizada, sem planejamento e desestruturados,

gerando, grande parte das vezes, um produto final de má qualidade. Segundo Pressman

(2006), as crises que ocorreram na época, forçaram as empresas a desenvolverem seus

projetos de uma forma padronizada, gerando uma documentação que acompanhe o

produto que está sendo desenvolvido. Diante disso, ainda de acordo com Pressman

(2006), surgiram muitas metodologias voltadas a esse tipo de desenvolvimento, além da

criação de novas linguagens de modelagem com o intuito de facilitar o entendimento do

produto tanto pela empresa desenvolvedora, como pelo cliente contratante. Com essa

realidade, surgiu a necessidade do projeto de desenvolvimento de software ser

executado de forma estruturada, planejada e padronizada, fazendo com que as

necessidades fossem atendidas e o investimento realizado fosse retornado. Assim,

surgiram metodologias que dividem o processo em fases pré-definidas com foco sempre

na qualidade final do produto.

Segundo Sommerville (2007), os processos eram sempre iniciados com uma fase de

análise, em que se estabeleciam os requisitos de acordo com as necessidades do cliente.

Em seguida, era realizada a modelagem, que gerava a documentação necessária para a

próxima etapa. Por último, têm-se as etapas de desenvolvimento e testes, estas

sequências e etapas têm lá suas vantagens como por exemplo a boa definição dos

requisitos e tempo hábil de desenvolvimento dos diagramas, porém em alguns

momentos os programadores se viam amarrados a requisitos desatualizados que não

correspondia a real necessidade dos clientes, modificações no ambiente externo, e a

negligência em alguns desses aspectos pode ressaltar no fracasso do projeto.

Como podemos observar na FIGURA. 1, segundo Chaos (2009), apesar da tendência

crescente de PMOs em empresas, o resultado não foi animador. Algumas pessoas

argumentam que estão apenas medindo orçamento, tempo e espaço (deixando de fora

qualidade, risco e satisfação do cliente).

Figura 1 – Gráfico CHAOS Fonte: Chaos (2009)

3.1 CASCATA

O 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 2. 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.

Figura 2. Etapas do modelo em cascata

3.2 ESPIRAL

O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar os

diversos modelos existentes à época, eliminando suas dificuldades e explorando seus

pontos fortes. Este modelo foi desenvolvido para abranger as melhores características

tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo,

um novo elemento - a análise de riscos - que falta a esses paradigmas.

O modelo em Espiral conforme a FIGURA 3 foi proposto em 19888 por Boehm como

forma de efetuar a integração com os modelos existente na época. O modelo foi

proposto visando abranger as melhores características e práticas do ciclo de vida

clássico e da prototipação do software, acrescentando, um novo elemento que é a

analise dos riscos, algo que falta no ciclo de vida em cascata e na prototipagem. Este

modelo sugere uma sequência de etapas, mas, diferente da cascata, o software é divido

em versões chamadas de incremento. Possui quatro atividades básicas:

1. Determinação dos objetivos da iteração

2. Análise dos riscos

3. Desenvolvimento

4. Validação, Testes e planejamento da próxima iteração.

Figura 3. Modelo em Espiral

3.3. ITERATIVO E INCREMENTAL

De acordo com Pressman (2006), esse modelo é uma versão mais evoluída do modelo

Cascata. A diferença com o modulo anterior é que o modelo Incremental define que o

sistema desenvolvido pode sempre ganhar novas funcionalidades e crescer, sendo que o

conjunto desses novos requisitos será desenvolvido por um incremento que segue todos

os ciclos descritos no modelo Cascata, como é exibido na ilustração da FIGURA. 4.

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 4 – Modelo Incremental Fonte: Sommerville (2005)

4. XP - EXTREME PROGRAMMING

XP é uma abreviação de Extreme Programming (programação extrema) que é uma

metodologia ágil com foco em qualidades de projetos e agilidade de equipes. Segundo

Beck (2000) a XP é uma maneira leve, eficiente, de baixo risco, flexível, previsível,

científica e divertida de se desenvolver software.

De acordo com Astels (2002), as práticas do Extreme Programming foram criadas para

funcionar em conjunto e disponibilizar maior valor do que cada uma poderia fornecer

individualmente. Essa metodologia de desenvolvimento de sistemas de software

também se preocupa demasiadamente com relação a alteração constante dos requisitos

do sistema. Sobre esse assunto, o processo enfatiza que o desenvolvedor deve procurar

permitir que o projeto seja flexível, ao invés de lutar contra as alterações de requisitos

durante o desenvolvimento.

Segundo Fowler (2001), esse processo é uma metodologia ágil centralizada em equipes

pequenas e médias que irão desenvolver sistemas com requisitos vagos e em constante

mudança. Nesse modelo, é adotada a estratégia de acompanhamento constante e

realização de vários ajustes durante o desenvolvimento do sistema.

Segundo Beedle (2001), o Extreme Programming possui um conjunto de tarefas que

devem ser seguidas pelas equipes. Conforme relatado por Highsmith (2001), o primeiro

projeto que realmente utilizou o Extreme Programming foi o C3, da montadora de

carros Chrysler. Após alguns anos de tentativas utilizando metodologias tradicionais

sem sucesso, a montadora optou por trocar o processo de desenvolvimento para

Extreme Programming e o projeto acabou ficando pronto em pouco mais de um ano.

Alguns autores, como apontado por Cockburn (2001), afirmam que a maioria das

principais regras do Extreme Programming podem causar polêmica a primeira vista e

outras nem fazem sentido se forem aplicadas isoladamente. A sinergia de seu conjunto

que sustenta o sucesso dessa metodologia, encabeçando uma verdadeira revolução na

engenharia de software.

O XP distingue-se de outras metodologias por:

Feedback rápido, concreto e contínuo.

Abordagem incremental de planejamento, obtendo um plano geral do projeto.

Confiança nos testes automatizados escritos por programadores e clientes

Monitorar o desenvolvimento, evolução e detecção de erros nos projetos,

dentre outras.

Abordagem incremental

É voltada para projetos cujos requisitos são vagos e mudam com frequência.

Equipes pequenas (em geral, 12 desenvolvedores), desenvolvimento de

sistemas orientados a objeto e incremental.

XP é um processo de desenvolvimento que busca assegurar que o cliente receba o

máximo de valor de cada dia de trabalho da equipe de desenvolvimento e é organizado

em torno de um conjunto de valores e práticas que atuam de forma harmônica e coesa

para assegurar que o cliente sempre receba um alto retorno do investimento em software

(MANHÃES, 2004). Independentemente do tipo da fábrica de software em questão, sua

estrutura organizacional pode seguir modelos distintos: Fábricas Organizadas por

Projetos e Fábricas Organizadas por Células.

Os princípios chaves e as práticas que compõem essa metodologia, não possuem nada

de novo, quando analisadas individualmente. Nesse método, essas típicas práticas das

metodologias ágeis foram reunidas e alinhadas de tal forma que se criasse uma

independência entre elas e, assim, surgiu uma nova metodologia de desenvolvimento de

software. Os quatro princípios chaves dessa metodologia, os papeis e as

responsabilidades e as principais práticas estão listadas a seguir.

Comunicação: Muitos problemas que ocorrem no decorrer do

desenvolvimento do sistema de software podem ser relacionados como falhas de

comunicação entre a equipe de desenvolvimento e o contratante ou entre a

própria equipe de desenvolvimento. Um programador, analista ou gerente pode

deixar de comunicar um fato importante à outra pessoa, um desenvolvedor pode

deixar de levantar uma questão importante à equipe ou ao próprio cliente. O

Extreme Programming mantém o fluxo de comunicação através da utilização de

algumas práticas que não podem ser desenvolvidas sem comunicação. Alguns

exemplos são: programação em pares (prática descrita a abaixo), testes de

unidade e estimativa de esforço de cada ação;

Simplicidade: Sempre se deve selecionar a alternativa mais simples que tem

uma probabilidade de funcionar. O Extreme Programming baseia-se no fato de

que é menos custoso fazer algo mais simples e alterá-lo conforme as

necessidades que surgirem do que tentar prever as possíveis alterações futuras,

introduzindo uma complexidade que pode não ser necessária no futuro;

Feedback: Todos os problemas devem ser evidenciados o quanto antes para que

possa ser corrigido o mais cedo possível. Para que possa ser incorporada de

forma rápida ao sistema de software que está sendo construído, todas as

necessidades são descobertas o quanto antes;

Coragem: Para apontar um problema no sistema de software é preciso coragem,

para simplificar um código que já foi testado e aprovado, para solicitar ajuda

quando for necessário, para comunicar ao cliente possíveis alterações nos prazos

estimados para entrega de versões e também para realizar alterações no processo

de desenvolvimento do sistema.

Os papéis e responsabilidades do Extreme Programming estão descritos a seguir:

Gestor: É o elemento responsável pela tomada de decisões. Para desempenhar o

seu papel, o gestor comunica-se a equipe do projeto para identificar qualquer

dificuldade, deficiência no processo ou algum outro tipo de impedimento, além

de determinar também qual a situação atual do projeto.

Consultor: É um elemento externo à equipe e possui conhecimento técnico

específico necessário para o projeto em questão. O consultor também ajuda a

equipe a resolver problemas específicos.

Desenvolvedor: Codifica programas, organiza testes e mantém o código fonte

o mais simples e coeso possível. Uma característica essencial que o

desenvolvedor deve possuir é a habilidade de comunicação e coordenação com

os outros elementos da equipe.

Cliente: É responsável por escrever as estórias e os testes dos requisitos

funcionais, além de selecionar e validar os requisitos do sistema. É ele quem

define a prioridade de implementação para cada requisito;

Testador: É o elemento responsável por auxiliar o cliente a escrever os testes

dos requisitos funcionais. Ele também executa os testes dos requisitos

periodicamente e comunica o resultado desses testes para o restante da equipe;

Monitor: Acompanha a conformidade das estimativas realizadas pela equipe de

desenvolvimento do sistema, como estimativas de esforço, e informa o quanto

precisas são tais estimativas, com o intuito de melhorar as futuras estimativas. O

monitor também acompanha o progresso de cada iteração e é responsável por

avaliar se o objetivo é viável de acordo com as limitações de recursos e tempo,

além de verificar se alguma mudança pode ser necessária no processo;

Treinador: É o elemento responsável por garantir a integridade do processo

como um todo. Geralmente, uma pessoa que detém uma longa experiência em

Extreme Programming é designada para esse papel, devido ao fato que ele é o

guia para todos os elementos do projeto executarem o processo de forma

adequada.

As doze práticas do Extreme Programming estão listadas a seguir e na FIGURA. 5:

Figura 5 – Agrupamento das práticas do Extreme Programming Fonte: Beck (2001)

Padrão na codificação: Os desenvolvedores devem escrever todo o código

fonte alinhados as regras que enfatizam a comunicação durante a codificação.

Esse padrão é definido antes de iniciar o projeto e deve ser seguido por toda a

equipe de desenvolvimento;

Semanas de quarenta horas: O Extreme Programming possui uma regra, para

cada elemento da equipe, que limita em quarenta horas o tempo total que se deve

trabalhar em uma semana.

Cliente no mesmo local da equipe: Um usuário que responda pelo cliente deve

integrar-se a equipe de desenvolvedores do sistema, disponível

preferencialmente em tempo integral para responder as possíveis dúvidas dos

elementos do projeto;

Integração contínua: São geradas versões internas e o sistema é integrado

quantas vezes ao dia for preciso, após uma estória ser finalizada;

Propriedade coletiva: Os desenvolvedores da equipe possuem a permissão de

alterar parte do código fonte em qualquer lugar do sistema e a qualquer

momento;

Programação em pares: Dois desenvolvedores codificam o sistema em um

mesmo computador. Geralmente, um é responsável por codificar enquanto o

outro fica responsável por procurar erros;

Jogo de planejamento: Os desenvolvedores do sistema e o cliente entram em

comum acordo para definirem o esforço necessário para programar, desenvolver

e analisar as estórias e a duração das iterações. Sendo que o cliente decide o

escopo que será executado na iteração, a FIGURA 6 mostra um quadro de

estórias como exemplo:

FIGURA 6 - Quadro Estórias XP (fonte:

http://blog.improveit.com.br/articles/page/24)

Incrementos curtos: Um incremento funcional e simples qualquer é gerado

rapidamente com duração máxima de dois meses. Isso é feito para ter um retorno

por parte do cliente em tempo hábil e poder incorporar correções e mudanças do

sistema que está sendo desenvolvido;

Metáfora: Nessa prática é elabora uma descrição que permite todos os

envolvidos no projeto explicarem como o sistema funciona. A prática da

metáfora é de grande ajuda para os envolvidos compreenderem os elementos

básicos do sistema bem como os seus relacionamentos, gerando um vocabulário

comum para os envolvidos. Ela também sugere uma estrutura de como o

problema e a solução podem ser vislumbrados do sistema que está sendo criado;

Projeto simples: Essa prática solicita que o sistema deve ser projetado da

forma mais simples possível, respeitando as necessidades atuais do projeto. As

complexidades irrelevantes devem ser removidas quando descobertas;

Testes: Os testes funcionais são escritos pelo cliente, enquanto que os testes de

unidade são escritos pela equipe do projeto e executados continuamente;

Reestruturação: Consiste na melhoria contínua do sistema. São realizadas

atividades como remoção de códigos fontes duplicados, melhorias na

comunicação, simplificações no processo, etc.

4. SCRUM

O Scrum é um método de desenvolvimento de sistema de software ágil que apresenta

uma longa comunidade de usuários de acordo com Cockburn (2001). O principal

objetivo desse método é oferecer um processo conveniente para projeto e a construção

de software em ambientes complexos, onde os requisitos não são claros e mudam com

muita frequência. Esse método apresenta uma abordagem empírica e utiliza ideias da

teoria de controle de processos da indústria para o desenvolvimento de sistemas de

software, aplicando o processo de flexibilidade, produtividade e adaptabilidade.

Segundo Schwaber (2004), o principal objetivo do Scrum é o desenvolvimento de

sistemas de software envolvendo uma porção de variáveis técnicas e de ambiente, como

requisitos, tecnologia e recursos, que podem mudar durante o processo onde os

membros trabalham de uma forma flexível em casa, na empresa ou em qualquer outro

lugar apto para a realização das atividades, visto que o ambiente é passível de sofrer

grandes mudanças.

Ainda segundo o mesmo autor, o Scrum é o mais perplexo e paradoxal processo para

gerenciamento de projetos complexos, porém, é um método incrivelmente simples. Ele

não é um processo prescritivo, também não descreve o que fazer em cada circunstância.

Ele é usado para trabalhos complexos nos quais é impossível predizer tudo que irá

acontecer durante o desenvolvimento do sistema de software.

Segundo Beedle (2001), o Scrum é um método de desenvolvimento ágil que procura

uma forma empírica de lidar com o caos, em detrimento a um processo bem definido.

Sua função primária é ser utilizado em gerenciamento de projetos de desenvolvimento

de sistemas de software. Ele tem sido utilizado com sucesso para esse fim, assim como

o Extreme Programming (XP). Além de tudo, esse método pode ser aplicado em

qualquer situação em que um grupo de pessoas precisa trabalhar junto para atingir um

objetivo comum, por exemplo, uma festa de aniversário.

De acordo com Highsmith (2004), um processo de desenvolvimento de sistema de

software extremamente definido tem uma probabilidade de sucesso drasticamente

reduzida quando utilizado no desenvolvimento de um produto. Para o autor, o Scrum

utiliza uma implantação de um controle descentralizado que lida de forma eficiente com

situações menos previsíveis, o que aparece como uma possível solução para atacar esse

problema.

Conforme apresentado por Schwaber (2004), o Scrum é um modelo de desenvolvimento

ágil de sistema de software que permite manter o foco na entrega de maior valor de

negócio e no menor tempo possível. Com isso, permite-se a rápida e contínua inspeção

do sistema em produção, em intervalos de duas a quatro semanas conhecidos como

Sprints. Esse método é dividido sucintamente em três papéis:

Product Owner: É o representante de todos envolvidos e responsável por listaras

prioridades e os requisitos. Juntamente com outros envolvidos, ele é o

responsável por revisar e aprovar as entregas ao final de cada Sprints;

Scrum Master: É o gerente do projeto, responsável por garantir a aplicação das

práticas e valores do Scrum, assim como repassar os ensinamentos do método

aos outros membros do projeto. As suas principais responsabilidades são

remover os obstáculos, conduzir o daily Scrum, revisar cada Sprint, intermediar

a comunicação entre o time e o product owner, etc;

Scrum Team: Correspondem aos membros encarregados de realizar as

atividades do projeto. Suas principais atividades são organizar e gerenciar suas

próprias atividades e geralmente são dedicados integralmente ao projeto.

Schwaber (2004) apresenta alguns novos artefatos em relação às metodologias

anteriores:

Product Backlog: Corresponde a lista de requisitos e atividades do projeto que

foram priorizados pelo product owner e possuem tempo estimado de entrega.

Normalmente as estimativas são em dias, sendo que para casos mais prioritários os

prazos são mais precisos. Os requisitos podem sofrer mudanças de acordo com a

necessidade do projeto e qualquer membro do time pode

alterar os itens com a autorização do product Owner. Podem ser requisitos funcionais ou

não-funcionais, sendo que os itens são selecionados para o próximo Sprint de acordo

com a prioridade. Também podem ser atualizados pelo product owner a qualquer

momento, que detém a responsabilidade desse artefato;

Release Burndown: É considerado o principal gráfico de controle do Scrum e

representa o trabalho restante dentro do Sprint de uma versão do sistema que

será entregue. No exemplo mostrado na FIG. 7, o eixo horizontal do gráfico

exibe as iterações e o eixo vertical a quantidade de trabalho restante. Segundo

Mountain (2011), esse tipo de gráfico funciona bem em muitas situações e com

diversas equipes, porém, em projetos com muitas mudanças de requisitos, talvez

tal gráfico não seja adequado;

Taskboard: É um grande painel que possibilita colocar várias informações

relevantes para o acompanhamento do Sprint.

Figura 7 – Release Burndown Fonte: Mountain (2011)

.

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, a fim de revisar o que foi feito de errado para ser corrigido

em versões posteriores, atualizando-se o Backlog do produto.

Segundo Mountain (2011), no gráfico da FIG. 9 é exibida uma introdução do que é

essencial para o desenvolvimento utilizando o método Scrum. À esquerda, é

representado o product backlog, que é priorizado pelo product owner e contém todos os

requisitos necessários para o desenvolvimento do ciclo atual. As semanas do sprint

estão representadas no maior círculo.

Figura 9 – Visão geral do Scrum Fonte: Mountain (2011)

5. FDD – FEATURE DRIVEN DEVELOPMENT

Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é uma

metodologia ágil para gerenciamento e desenvolvimento de software. Ela combina as

melhores práticas do gerenciamento ágil de projetos com uma abordagem completa para

Engenharia de Software orientada por objetos, conquistando os três principais públicos

de um projeto de software: clientes, gerentes e desenvolvedores.

Seus princípios e práticas proporcionam um equilíbrio entre as filosofias tradicionais e

as mais extremas, proporcionando uma transição mais suave para organizações mais

conservadoras, e a retomada da responsabilidade para as organizações que se

desiludiram com as propostas mais radicais.

5.1 PAPEIS E ATORES

No FDD existem diversos papeis que um membro da equipe possa assumir. Um mesmo

papel pode ser assumido por diversos membros e cada membro pode assumir diversos

papeis ao mesmo tempo. Vejamos os principais papeis desta metodologia.

Gerente do Projeto é o responsável pela parte financeira, comercial e

administrativa do projeto, é este que define o calendário e o cronograma e é o

responsável por garantir condições seguras e viáveis do ambiente de trabalho.

Chefe de Design – é responsável pela arquitetura e do design do projeto.

Gerente de Desenvolvimento – líder do desenvolvimento do projeto, também é

desenvolvedor, porém é o responsável para resolver os diversos conflitos

existentes tanto pessoais como no código.

Programador Chefe – responsável por uma equipe menor de programadores e

pela divisão das tarefas e atividades entre eles. É necessário que seja um

profissional experiente, pois é de inteira responsabilidade dele a interação e

implementação das classes.

Dono da classe ou programador – é um membro da equipe sob o comando do

Programador Chefe e do Gerente de desenvolvimento, responsável pelo

desenvolvimento, implementação de funções e rotinas, documentação da sua

classe desenvolvida.

Analista ou Especialista da Área - O especialista pode ser um cliente, um

analista de negócio, um patrocinador ou um utilizador, na maioria das vezes é

um profissional com vasta experiência na analise e no desenvolvimento de

sistemas da empresa, alguém de confiança do chefe que possui os devidos

conhecimentos da regra de negocio. É o responsável pelo preço do sistema a ser

desenvolvido juntamente com o gerente do projeto e os sócios da organização.

5.2 PROCESSOS DO FDD

São cinco os principais processos da metodologia do FDD, vejamos:

1. Develop an Overall Model é o processo responsável por tratar a utilização dos

requisitos e funcionalidades pedidas pelo cliente e fazer o estudo destes

requisitos de forma a ter uma noção da estrutura do sistema, baseia-se no

desenho do sistema.

2. Build by Features list é o processo na qual se constrói uma lista de

características detalhadas e ordenadas por ordem hierárquica;

3. Plan By Feature é o processo responsável por tratar a utilização do

planejamento de como tais características do processo 2 deve ser desenvolvido;

4. Design by Feature Sua característica em particular é o estudo de uma forma de

criar os diagramas bem detalhados.

5. Build By Feature Faz todas as alterações necessárias para ser possível construir

uma Feature

5.3 FERRAMENTAS DO FDD

O Uso do FDD em um projeto, é possível utilizando uma ferramenta que permita

organizar todas as implementações, vejamos um exemplo de tais ferramentas:

FDD Manager,

MagicDraw,

OptimalJ,

Poseidon,

Rose,

Simply

6. ASD – ADAPTIVE SOFTWARE DEVELOPMENT

Desenvolvimento de Software Adaptativo é um processo de desenvolvimento de

software, que cresceu fora de rápido desenvolvimento de aplicações de trabalho por Jim

Highsmith e Bayer Sam. ASD incorpora o princípio de que a adaptação contínua do

processo para o trabalho na mão é o estado normal das coisas.

O ASD possui um ciclo de desenvolvimento de software passeado em planejar, projetar

e construir.

Diante do turbulento ambiente o ASD propõe que durante a fase de planejamento

haveria uma troca para a predição, com o objetivo de prever o ambiente de incertezas. O

Objetivo seria explorar experimentar, sem deixar de lado o planejamento por completo,

mais assumindo a falta de decisão. Outra fase do ciclo ASD, seria o trabalho

colaborativo entre os envolvidos, criando informações suficientes para que os mesmos

possam agilizar com rapidez na resolução de problemas. Há também a necessidade de

um feedback sobre cada tarefa para assim ser possível aprender com os erros anteriores,

melhorando-os e os aperfeiçoando-os nas demais interações.

O desenvolvimento ASD para ser colaborativo necessita atender algumas

características, vejamos:

Foco na Missão - fazer com que a equipa tenha um objetivo definido e

permitindo assim que sejam feitas as melhores decisões.

Funcionalidades - Entregar resultados mais palpáveis ao cliente, através de

funcionalidades codificadas no sistema.

Iterativo - foco na entrega de releases e evolução do produto.

Períodos fechados (time-boxes): O objetivo da equipe deve ser definido em um

determinado período, definindo as prioridades para que seja entregue o

combinado e no prazo.

Dirigido a riscos: Analise e avaliação dos riscos do projeto continuamente, assim

como em um desenvolvimento em um modelo espiral.

Tolerante a mudanças: incorporar as mudanças que forem aparecendo durante o

projeto.

É necessário observar e analisar o desempenho de cada interação observando os

seguintes aspectos:

Qualidade resultante sob a perspectiva do cliente.

Qualidade resultante sob a perspectiva técnica.

O funcionamento da equipa de desenvolvimento

Práticas que os membros empregam para desenvolver o sistema.

O estado atual do projeto.

7. SEMELHANÇAS E DIFERENÇAS ENTRE OS MODELOS TRADICIONAIS

COM OS MODELOS AGEIS DE DESENVOLVIMENTO DE SOFTWARE

A adoção de metodologias ágeis tem crescido muito graças constatação prática de

profissionais, que tem experimentado em seus projetos as limitações e desafios das

práticas tradicionais. O pensamento ágil propõe organizar os esforços produtivos de

forma a gerar valor mais cedo, facilitar a aderência a requisitos mutáveis e manter a

visibilidade constante e precisa durante a execução de um projeto. Como resultado deste

pensamento, organizações são capazes de reduzir significativamente o risco associado

ao desenvolvimento de software.

As FIGURA 10 mostra a diferença, ao longo do tempo, de projetos geridos segundo

metodologias tradicionais e ágeis:

FIGURA 10 Comparativo Ágil: Fonte:

http://www.oncast.com.br/box_comparativo_agil.php

Para ser realmente considerada ágil a metodologia deve aceitar a mudança ao invés de

tentar prever o futuro. O problema não é a mudança em si, mesmo porque ela ocorrerá

de qualquer forma. O problema é como receber, avaliar e responder às mudanças. As

aplicações baseadas em Web são mais bem modeladas usando metodologias ágeis, uma

vez que a ambiente Web é muito dinâmica.

Alterações nos requisitos no modelo Clássico não são desejáveis. Por serem

relativamente novas, existem poucas ferramentas disponíveis que suportam o processo

ágil de desenvolvimento. Dentre as existentes, a maioria suporta apenas a Extreme

Programming e ainda estão em fase de pesquisa e desenvolvimento. A XPlanner é uma

ferramenta de código livre muito conhecida que suporta a XP, principalmente

auxiliando a fase de planejamento [XPlanner, (2004)]. O desenvolvimento desta

ferramenta ainda está em progresso, mas já existe uma versão estável para o

gerenciamento de estórias do usuário, gerenciamento de tarefas, verificação de

progresso do projeto e gerenciamento das métricas individuais e da equipe. Dentre as

funcionalidades futuras da ferramenta estão a integração com outras metodologias ágeis,

em especial a Scrum.

Por exemplo, um artigo [Charette, R., (2001)] comparando métodos ágeis com as

metodologias tradicionais pesadas mostrou que os projetos usando os métodos ágeis

obtiveram melhores resultados em termos de cumprimento de prazos, de custos e

padrões de qualidade. Além disso, o mesmo estudo mostra que o tamanho dos projetos e

das equipes que utilizam as metodologias ágeis têm crescido. Apesar de serem

propostas idealmente para serem utilizadas por equipes pequenas e médias (até 12

desenvolvedores), aproximadamente 15% dos projetos que usam metodologias ágeis

estão sendo desenvolvidos por equipes de 21 a 50 pessoas, e 10% dos projetos são

desenvolvidos por equipes com mais de 50 pessoas, considerando um universo de 200

empresas usado no estudo.

8. Estudo de Caso – Entrevista

Entrevista realizada no SERPRO com os senhores, Serge Rehem e Fábio Rilston que

nos disponibilizaram a seguinte entrevista sobre métodos e processos ágeis no

SERPRO, portanto desde já todos os direitos reservados aos mesmos.

Respondendo as perguntas no evento maré de agilidade na Bahia o Sr. Fábio Rilston

consultor de qualidade na empresa pública SERPRO:

Manoel Pimentel e Everton Pereira - O Serpro acabou de adotar o processo ágil

dentro da sua realidade, então gostaria de saber do Sr. Fábio, qual foi o principal motivo

que levou o Serpro naturalmente a procurar uma solução baseada na agilidade misturado

com sua realidade? Como é que isso aconteceu?

Fábio Rilston - Bom à iniciativa do ágil dentro do Serpro surgiu da necessidade da

organização ter uma nova ótica de processos que simplificasse os processos para a

plataforma Java a plataforma que utilizamos, a organização está investindo muito nesse

segmento desde 2009, vários clientes do governo federal têm adotado esta metodologia.

Então buscamos adequar o processo até então utilizado e às características dessa

plataforma ágil em Java e que tivesse não só o uso de todo os métodos ágeis, mas

primasse também por uma simplificação do nosso próprio processo para se adequar

melhor às características dessa plataforma, juntamente com o framework que temos e

estamos implantando o except demoselle.

Manoel Pimentel e Everton Pereira - Fábio, e me diz uma coisa, esse processo de

implantação ou de criação foi tranquilo você encontrou resistência, quais foram os

principais obstáculos que você teve na realização desse processo lá no Serpro?

Fábio Rilston - A principal resistência foi à quebra de paradigma porque a organização

já tem um processo bem consolidado, um processo de software baseado CMMI, Ruby,

CMPP, que já duram mais de oito anos de execução dentro das equipes de

desenvolvimento do Itaú, esse paradigma já estava bastante arraigado dentro das

equipes, a organização teve que trabalhar um pouco esse conceito na cabeça dos

desenvolvedores, pois precisávamos de bons pilotos para execução do roteiro e segundo

uma equipe motivada para enxergar o ágil não como um adversário do processo

tradicional mas como uma nova vertente de trabalho que privilegia todos esses

conceitos de entrega mais rápida, entregas curta para o cliente, envolvimento da equipe,

integrações contínuas enfim, toda uma série de características do ágil que entendemos

que irá trazer um benefício um diferencial para a empresa Serpro em alguns tipos de

projetos que são adequados ao ágil e gente trabalhou essas equipes depois do

desenvolvimento do roteiro mostrando os benefícios a serem alcançados e conseguimos

no final pilotos com sucesso de implementação de um novo roteiro ágil para definição

desses projetos e a gente segue agora numa segunda etapa para consegui consolidar

todas essas experiências e gerar uma nova versão desse roteiro para uso nacional.

Manoel Pimentel e Everton Pereira - Quais as unidades locais ou regionais já

estão usando esse modelo baseado em agilidade?

Fábio Rilston - Fortaleza, já trabalha com três projetos pilotos a mais de três anos, em

Brasília já iniciado há dois anos Brasília, em Belo Horizonte estamos iniciando dentro

da ReceitaNet que vai trabalhar junto ao cliente receita federal todo módulo novo de

consulta de declarações utilizando essa nova tecnologia esse novo modelo ágil.

Manoel Pimentel e Everton - Como foi composto esse mix de metodologia utilizado?

Fábio Rilston - Bom primeiramente a organização fez um estudo primeiro de artigo de

academia que relacionava esse casamento entre tecnologia ágil e tecnologia

convencional de processos e verificamos a viabilidade de adotar ou não tal metodologia,

o ideal seria a organização adotar uma solução híbrida devido ao contexto de

complexidade de processos já instalados na empresa, até pelo fato de ser empresa de

grande porte uma empresa distribuída nacionalmente, então essa abordagem ela

trabalhou com um mix de 3 dos principais métodos do mercado, nós trabalhamos com

Xp, Scrum e o Open Up onde a estudamos cada característica desses modelos ágeis que

poderiam ser utilizadas na prática dentro da realidade da empresa Serpro, selecionamos

práticas ágeis q poderiam ter sido adotada e consolidamos essas práticas num roteiro

inicial que foi aplicado aos projetos pilotos com bastante sucesso até o momento.

Manoel Pimentel e Everton - Quais foram os projetos pilotos assim de produtos que o

grande público conhece de repente?

Fábio Rilston - Primeiro, o produto assim com mais alcance entre o público foi é o

sistema de controle de concursos públicos desenvolvido para cliente Esaf que controla

toda a realização de concursos federais para os órgãos do governo e faz toda parte desde

inscrição do aluno até a correção das provas que foram realizadas para adoção do

funcionário no emprego público.

Manoel Pimentel e Everton – De maneira geral pra concluir nossa conversa, quais

foram às lições aprendidas pro Serpro e as equipes que já estão utilizando os modelos

que tiveram nesses processos pilotos e como estão funcionando?

Fábio Rilston - Bom, a princípio a organização percebeu que o ágil é factível em que

traz uma série de benefícios pra equipe em termos de agilidade, em termos de

desenvolvimento da equipe, em termos de funcionamento do conceito de houting, para

trabalhar com uma equipe coesa que encara o projeto não só como mais uma demanda

de trabalho mais sim como um filho que tá nascendo que precisa ser criado.

Manoel Pimentel e Everton – Muito obrigado

Fábio Rilston - Ok

9. Conclusões

Neste artigo falamos a respeito do Scrum e XP que são metodologias de

desenvolvimento de software mais utilizadas por empresas de desenvolvimento, além de

noções de outros métodos ágeis e mostramos a diferença ao longo do tempo em se usar

o método ágil e o método tradicional.

Através da entrevista foi possível concluir que os processos ágeis são metodologias

novas de desenvolvimento de software que precisa ser tratada como uma criança,

necessitando assim de estudo, apoio, e de aprendizagem, foi possível verificar também

que os métodos ágeis trazem grandes benefícios para a equipe de desenvolvimento não

só na agilidade e rapidez no decorrer do tempo, mas em custo e em funcionamento do

produto final, além de proporcionar uma equipe coesa que encara o projeto não só como

uma demanda, mas sim como algo prazeroso de ser feito, atendendo assim os princípios

do manifesto ágil.

10. Referências

Agile Manifesto (2004) Disponível em http://agilemanifesto.org/, acessado em 12 de

Junho de 2012.

BECK, K. Extreme Programming Explained. Massachusetts: Addison-Wesley, 2000.

BECK, K. et al.Agile Manifesto. 2001. Disponível em: http://www.agilemanifesto.org

Acesso em: 10/06/2012

BEEDLE, M; et al. SCRUM: An extension pattern language for hyperprodutive

software development. In: Pattern Languages of Programs'98 Conference, Monticello,

1998.

DE LUCA, J. Feature-Driven Development (FDD) Overview Presentation. 2002.

Disponível em: www.nebulon.com/articles/fdd/download/ fddoverview.pdf >. Acesso

em: 26/06/2012

FDD - http://www.featuredrivendevelopment.com/, acessado em 26 de Junho de 2012

SCHWABER, K. Scrum Development Process. In: OOPSLA’95 Workshop on Business

Object Design and Implementation. Springer-Verlag, Atlanta, 1995.

SCHWABER, K; BEEDLE, M. Agile Software Development with SCRUM. New

Jersey: Prentice Hall, 2002.

SOMMERVILLE, I. Engenharia de software. São Paulo: Addison-Wesley, 2003.

XPlanner, (2004)]XPlanner, disponível em http://www.xplanner.org/, acessado em 12

de Junho de 2012.