conheça os principais processos ágeis processos Ágeis de ... · conheça os principais processos...
TRANSCRIPT
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.