1

UNIVERSIDADE CANDIDO MENDES / AVM

PÓS-GRADUAÇÃO LATO SENSU

APLICAÇÃO DA METODOLOGIA ÁGIL NO GERENCIAMENTO DE PROJETO

Marcelle dos Santos Chicre da Costa

ORIENTADOR: Prof. Úrsula Gomes

Rio de Janeiro 2017

DOCUMENTO P

ROTEGID

O PELA

LEID

E DIR

EITO A

UTORAL

2

UNIVERSIDADE CANDIDO MENDES / AVM

PÓS-GRADUAÇÃO LATO SENSU

Apresentação de monografia à Universidade Cândido Mendes como requisito parcial para obtenção do grau de especialista em Gestão de Projetos. Por: Marcelle dos Santos Chicre da Costa

APLICAÇÃO DA METODOLOGIA ÁGIL NO GERENCIAMENTO

DE PROJETO

Rio de Janeiro 2017

3

AGRADECIMENTOS

A todas as amigas e parentes que, direta e

indiretamente, contribuíram para confecção desse

trabalho acadêmico.

4

DEDICATÓRIA

Aos meus pais pelo constante incentivo e amor.

Valéria dos Santos Chicre da Costa

Guilhermino Albano Chicre da Costa

5

RESUMO

A metodologia ágil é uma alternativa à gestão tradicional de projetos,

ela surge nos braços do desenvolvimento de software, podendo hoje ser

aplicada em vários tipos de projeto. Os métodos ágeis vem auxiliando muitas

equipes no desdobramento da imprevisibilidade dentro de um projeto através

de entregas incrementais e ciclos iterativos. As metodologias ágeis passaram a

ser uma alternativa aos métodos tradicionais, também conhecidos como

métodos pesados ou clássicos.

Os métodos ágeis visam promover um processo de gerenciamento

de projetos que incentiva a inspeção e adaptação frequente. Trata-se de uma

filosofia incentivadora do trabalho em equipe, a auto-organização, a

comunicação frequente, o foco no cliente e a entrega de valor e qualidade.

Basicamente, os métodos ágeis são um conjunto de práticas eficazes que se

destinam a permitir a entrega rápida e de alta qualidade do produto, tendo uma

abordagem de negócios que alinha o desenvolvimento do projeto com as

necessidades do cliente e os objetivos da empresa.

Este trabalho monográfico tem como objetivo a apresentação de

novas possibilidades no que tange a gestão de projetos através da metodologia

ágil.

6

METODOLOGIA

A metodologia ora em estudo destina-se a apoiar o usuário no

entendimento teórico e prático, adequando novos métodos de gestão no

mercado de trabalho, compartilhando o conhecimento e melhores casos para

sua aplicação.

A metodologia ágil está em ascendência nas empresas,

principalmente para projetos de desenvolvimento de software, por trazer

progresso ao projeto no que tange a entrega, um dos pontos principais para o

cliente. Dessa forma, o objetivo deste estudo é apresentar o método ágil como

uma alternativa, em alguns casos, aos processos tradicionais e pontuar sua

aplicação.

A metodologia adotada foi um levantamento bibliográfico em livros,

artigos, trabalhos acadêmicos e materiais encontrados na Internet. Para

subsidiar a teoria, foi efetuada uma pesquisa exploratória e qualitativa, dentro

de uma empresa americana do setor de TI, onde a metodologia ágil foi

aplicada.

7

SUMÁRIO

INTRODUÇÃO 08

CAPÍTULO I

Manifesto Ágil 10

CAPÍTULO II

Agile Scrum 18

CAPÍTULO III

Programação Extrema ou XP 25

CONCLUSÃO 31

BIBLIOGRAFIA 34

ÍNDICE 35

8

INTRODUÇÃO

Segundo Torreão (2005), um Projeto pode ser identificado como um

instrumento fundamental para qualquer alteração na atividade e no

desenvolvimento de um produto e de um serviço, envolvendo uma pessoa ou

milhares de pessoas, organizadas ou não em times, que pode durar horas, dias

ou anos.

A ideia de que rapidez tem a ver com trabalho sem qualidade é algo

que não se usa mais. O conceito de agilidade nos métodos ágeis está ligado ao

colaborativo com o foco na equipe, na comunicação e na diminuição dos erros.

Se o método é aplicado de forma coerente, o resultado é a entrega rápida e

projetos de sucesso.

Sabe-se que cada empresa utiliza uma forma de gestão que melhor

se adeque ao produto demandado visando o sucesso do Projeto e suprir as

expectativa do cliente. Atualmente existe um cenário competitivo, clientes mais

exigentes, solicitando principalmente um prazo menor, uma entrega mais

rápida das demandas, foi necessário adaptar as metodologias tradicionais de

gerenciamento de projetos para atender a essas novas exigências. Uma

dessas metodologias utilizadas é a metodologia ágil ou Agile (definição de ágil

ou métodos ágeis em inglês).

Esses princípios buscam a valorização da equipe e principalmente o

comprometimento dos envolvidos. O uso dos métodos ágeis hoje, vai além da

concepção de um software, podendo ser aplicado em outras áreas como

Marketing, Inovação, Consultoria, entre outras. Para entender a importância do

Agile.

Dessa forma dedicamos esses estudo aos métodos ageis da

seguinte forma: no capítulo 1, vamos analisar o nascimento dos métodos ágeis,

através da análise do Manifesto Ágil, seus ideais básicos e princípios. Nos

capítulos 2 e 3 iremos detalhar alguns dos métodos ágeis mais utilizados, os

projetos mais adequados para sua utilização, assim como os benefícios e

9

possíveis dificuldades de cada método como o Agile Scrum que busca

entregar resultados de maneira mais rápida e com menor custo, com o objetivo

de fornecer produtos e serviços que se alinhem as necessidades do cliente.

Como também analisaremos a metodologia de Programação extrema (do

inglês Extreme Programming) ou XP, baseada numa série de princípios e boas

práticas empregadas ao, sem esquecer-se do custo e qualidade.

10

CAPÍTULO I

Manifesto Ágil

Em 2001 foi formado em reunião, nos Estados Unidos da América

(EUA), a Aliança Ágil, quando dezessete especialistas em processos de

desenvolvimento de software estabeleceram princípios comuns de métodos de

criação de softwares e publicaram o Manifesto Ágil. Os resultados dessa

discussão deram origem à criação da Aliança Ágil.

Durante esta reunião um consenso sobre aspectos importantes em

desenvolvimento de software originaram-se. Logo, elevaram aquela reunião a

um grau maior. Resolveram, por fim, elaborar um documento que serviria como

escape aos antigos processos de desenvolvimento de software. A primeira

parte se resume a encontrar um nome que expressivo para o movimento,

métodos leves deixaram de ser uma opção válida, pois não explanavam o

significado desejado. Após analisarem vários nomes decidiram que a palavra

“agile” (ágil) melhor captava a abordagem proposta.

Os ideais básicos do Agile surgiram da necessidade de reforçar as

dimensões de compreensão e comunicação. O Manifesto Ágil sugere (BECK et

al., 2001):

1. Indivíduos e interações mais que processos e ferramentas;

2. Software em funcionamento mais que documentação abrangente;

3. Colaboração com o cliente mais que negociação de contratos;

4. Responder a mudanças mais que seguir um plano

11

Figura 1 – Manifesto Ágil

Fonte: infoq.com

1.1. Os doze princípios do manifesto ágil

Posteriormente, a segunda parte da reunião foi dedicada à escrita do

documento que resultaria no manifesto ágil, no mesmo estaria englobado a

declaração das crenças e valores que aquelas dezessete pessoas possuíam.

Por fim, na última parte e nos meses seguintes os princípios foram detalhados.

O manifesto ágil se tornou um grito de guerra para a indústria de software e

para aquelas dezessete pessoas, conseguindo demonstrar claramente o que

defende e o que opõe, deixando bem claro o que é, e o que não é ágil.

De acordo com (BECK et al., 2001) o “Manifesto Ágil”, estabeleceu doze

princípios de agilidade:

• 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 freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.

• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.

12

• 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-organizáveis.

• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

1.2. Sobre os autores do manifesto ágil

Neste tópico vamos relatar um pouco da história dos criados do

manifesto ágil, assim como a metodologia utilizada por cada um em diversas

empresas e projetos o que resultou numa série de estudos publicados.

Mike Beedle é o fundador e CEO da e-Architects Inc., uma empresa de

consultoria especializada em desenvolvimento de aplicativos usando objetos

distribuídos e tecnologias da Internet. Apesar das exigências empresariais de

Mike, ele continuou como consultor aplicando o Scrum e XP juntos através do

XBreed. Mike teve o privilégio de ser um dos primeiros a adotar o método

Scrum e introduziu o Scrum em 7 organizações desde meados dos anos 90. A

especialidade de Mike é treinar empresas na criação de arquiteturas

reutilizáveis em grande escala envolvendo muitas equipes de aplicativos. Seu

registro até agora é de 17 aplicações reutilizando os mesmos componentes,

tais como: workflows, componentes visuais, transações, objetos de negócios e

serviços de arquitetura. Mike publicou em várias áreas, incluindo tecnologia de

objetos, padrões, componentes, frameworks, desenvolvimento de software,

linguagens de programação, reutilização, fluxo de trabalho, BPR e Física. Ele

13

co-organizou vários workshops sobre objetos, padrões, componentes e

desenvolvimento de software durante a última década. Ele é co-autor de

Scrum, Agile Software Development com Ken Schwaber (Prentice Hall, outono

de 2001), um livro provocativo que supõe que o desenvolvimento de software é

mais como desenvolvimento de novos produtos do que os processos de

manufatura que a indústria de software usou nos último 20 anos.

Arie van Bennekum está ativamente envolvido no DSDM e no Consórcio

DSDM desde 1997. Antes disso, ele trabalhava com o Rapid Application

Development. Sua paixão por métodos ágeis é baseada em entregar aos

clientes o que eles realmente precisam de uma forma que realmente se adequa

aos usuários finais e negócios. Como as sessões facilitadas são muito

importantes dentro do método DSDM e sua paixão por processos de grupo e

comportamento humano, ele é freqüentemente envolvido em projetos como

facilitador e treinador. Atualmente, é membro do conselho do DSDM

Consortium Benelux e credenciado como DSDM-practitioner, DSDM-formador,

DSDM Consultor e IAF Certified Professional Facilitator (CPF).

Alistair Cockburn, fundador da Humans and Technology, é conhecido

por suas extensas entrevistas com equipes de projeto. Essas entrevistas,

juntamente com sua participação ativa em projetos ao vivo, formam a base

para seus projetos de metodologia: leve, mas suficiente e auto-evolutiva. O

trabalho de Alistair na década de 1990 cresceu para a família Crystal de

metodologias ágeis. Alistair e Jim Highsmith estão agora trabalhando juntos

para evoluir Crystal e as idéias Adaptive em recomendações para a criação de

ecossistemas de desenvolvimento de software ágil, o encontro de metodologia

genérica com a situação específica de uma equipe de projeto. Alistair e Jim

estão co-patrocinando a série de livros Agile Software Development para

publicar técnicas de crescimento pessoal e exemplos de metodologias ágeis

que foram usadas com sucesso.

Ward Cunningham é um fundador da Cunningham&Cunningham, Inc.

Ele também atuou como Diretor de P&D na Wyatt Software e como Engenheiro

de Princípios no Laboratório de Pesquisa de Computadores da Tektronix antes

14

disso. Ward é bem conhecido por suas contribuições para a prática em

desenvolvimento de programação orientada a objetos, a variação chamada

Programação Extrema, e as comunidades hospedadas por seu WikiWikiWeb.

Ele é ativo com o Grupo Hillside e tem servido como presidente do programa

da conferência Pattern Languages of Programs que patrocina. Ward criou o

método de design CRC, que ajuda as equipes a encontrar objetos principais

para seus programas. Ward escreveu para PLoP, JOOP e OOPSLA em

Patterns, Objects, CRC e tópicos relacionados.

Martin Fowler é o cientista-chefe da Thoughtworks, uma empresa de

consultoria e desenvolvimento de aplicações. Ele está envolvido há mais de

uma década em usar técnicas orientadas a objetos para sistemas de

informação. Embora seu principal interesse tenha sido em design de software

ele nunca foi capaz de evitar o processo de software e tem se interessado em

abordagens que permitem que a metodologia se ajuste às pessoas ao invés do

contrário. Ele é o autor de Analysis Patterns, UML Distilled, Refactoring e

Planning Extreme Programming.

Jim Highsmith é o desenvolvedor principal do "Adaptive Software

Development" Agile Method e autor de um livro com o mesmo nome. Ele falou

sobre Desenvolvimento Adaptativo e outros Métodos Ágeis em conferências

como OOPSLA, Cutter Summit, SD 2001, XP2001 e Processos Flexíveis,

Project World e XP Universe. Jim foi co-autor, com Martin Fowler, do "O

Manifesto Agile" artigo na edição de agosto de 2001 da revista

"Desenvolvimento de Software" e tem vários artigos adicionais "ágil" nas obras.

Jim e Alistair Cockburn estão trabalhando para combinar métodos ASD e

Crystal e também são co-editores de uma nova série de livros Addison-Wesley

sobre Desenvolvimento de Software Ágil.

Andrew Hunt é um parceiro da The Pragmatic Programmers e co-autor

do best-seller “The Pragmatic Programmer: From Journeyman to Master”, o

novo Ruby Programação, e vários artigos. Entre escrever, apresentação de

conferências, marcenaria e tocar piano, Andy encontra tempo para sua

empresa de consultoria especializada em desenvolvimento de software ágil.

15

Andy tem escrito software profissionalmente desde o início dos anos 80 em

diversas indústrias como telecomunicações, banca, serviços financeiros,

serviços públicos, imagens médicas, artes gráficas e serviços de Internet. Andy

veio de Raleigh NC e, com o co-autor Dave Thomas, é conhecido por trazer

métodos independentes e pragmáticos melhores práticas para projetos de

desenvolvimento de software em todo os EUA. Ele é presidente do capítulo

RTP da Independent Computer Consultant's Association e um membro da O

ACM eo IEEE.

Ron Jeffries é o proprietário de XProgramming.com e autor (com Ann

Anderson e Chet Hendrickson) de Extreme Programming Installed. Ron foi o

primeiro treinador de Extreme Programming, e é um colaborador prolífico para

os grupos de Internet relacionados ao XP, e um orador frequente em

conferências de software.

Jon Kern é apaixonado por ajudar os clientes a ter sucesso no

fornecimento de valor comercial através de esforços de desenvolvimento de

software. Sua carreira variada estendeu o R&D dos simuladores de vôo, a ser

um técnico em object-oriented nos anos 90, iniciando com C++ e

porteriormente, movendo-se para Java. Ele publicou pela primeira vez sua

metodologia de desenvolvimento iterativo leve em guias de desenvolvedores

para o Lotus Notes 4.5 e 5.0. Ele foi motivado pesadamente pelo mantra de

seu amigo Peter Coad para entregas "resultados de trabalho freqüentes,

tangíveis." Ele colocou suas técnicas para trabalhar em projetos do DoD, e

depois em sua própria empresa (Lightship, Inc.). Em 1999, juntou-se a Peter

Coad para o arranque da TogetherSoft, onde criou o grupo de mentores

profissionais e orientou o desenvolvimento de produtos. Jon foi co-autor do

Java Design, e trabalhou com Peter e Jeff De Luca (o principal contribuinte

para FDD) para ajudar a moldar o capítulo sobre Feature-Driven Development

(FDD) em Java Modelagem em cores com UML. Jon procura constantemente

melhores maneiras de as equipes alcançarem seus objetivos, de uma

perspectiva de tecnologia e de uma perspectiva de processo e metodologia.

Nas palavras de Jon, Pragmatic MDA via OptimalJ da Compuware

(http://www.optimalj.com) representa um avanço emocionante e revolucionário

16

em ter um ambiente que promove as melhores práticas, arquitetura sólida,

desenvolvimento ágil, qualidade por design (não acidente) e foco em entregar o

valor do negócio com o uso estratégico de recursos de TI.

Brian Marick é um programador e consultor de testes de software. Ele

veio para a Snowbird como representante de uma parte da comunidade de

testes de software que está desenvolvendo um estilo de teste enfatizando a

investigação, menor confiança na documentação, maior aceitação da mudança

e a noção de que um projeto é uma conversa contínua sobre qualidade. Ele

está começando uma pesquisa sobre o que o "Agile Testing" pode significar, e

como ele se encaixa com Agile Development.

Robert C. Martin é um profissional de software desde 1970. Ele é

presidente e fundador da Object Mentor Inc., uma empresa de consultores

altamente experientes que oferecem XP e consultoria de processo ágil,

consultoria de design de software, treinamento e serviços de desenvolvimento

para grandes corporações em todo o mundo. Em 1995, ele foi o autor do livro

best-seller: “Designing Object Oriented C ++ Applications” usando o Booch

Method, publicado por Prentice Hall. Em 1997 foi editor-chefe do livro: “Pattern

Languages of Program Design 3”, publicado por Addison Wesley. Em 1999 ele

foi o editor de "More C ++ Gems", publicado pela Cambridge Press. Ele é co-

autor de "XP in Practice", James Newkirk, e Robert C. Martin, Addision Wesley,

2001. Em 2002 foi publicado pela Prentice Hall o livro "Princípios, Padrões e

Práticas de Desenvolvimento de Software Ágil". De 1996 a 1999 ele foi o editor-

chefe do C ++ Report. Ele publicou dezenas de artigos em diversas revistas

especializadas e é palestrante regular em conferências internacionais e feiras.

Ken Schwaber é presidente da Advanced Development Methods (ADM),

uma empresa dedicada a melhorar a prática de desenvolvimento de software.

Ele é um desenvolvedor de software experiente, gerente de produto e consultor

da indústria. Schwaber iniciou a revolução dos produtos de gerenciamento de

processos do início da década de 1990 e também trabalhou com Jeff

Sutherland para formular as versões iniciais do processo de desenvolvimento

Scrum. Nos últimos cinco anos ele formalizou o Scrum, ajudou muitas

17

organizações a implementar com êxito produtos e sistemas usando o Scrum e

co-autoria do Scrum, Agile Software Development com Mike Beedle (Prentice

Hall, outono de 2001).

Jeff Sutherland é chefe no “Technology Officer” da PatientKeeper, uma

startup baseada no MIT que fornece aplicações móveis / sem fio para clínicos.

Ele foi CTO ou VP de Engenharia em nove empresas de tecnologia de software

e introduziu processos de desenvolvimento ágil melhorados para cada um

deles. Seu trabalho em componentes de objetos de negócios reutilizáveis

através do Grupo de Gerenciamento de Objetos e do OOPSLA Business

Object Workshop durante a última década levou a novos produtos de banco de

dados, ambientes de desenvolvimento de software, ferramentas CASE / OOAD

e aplicações verticais em vários setores. Como fundador e vice-presidente de

Engenharia da Individual Inc. ele lançou NewsPage pessoal. Como ex-vice-

presidente sênior de Engenharia e CTO da IDX Systems, ele desenvolveu

novos aplicativos de Internet para assistência médica. Seu trabalho em

grandes projetos de software baseados em componentes levou a inovações em

bancos, seguros, sistemas de bibliotecas, aeroespacial, arrendamento de

aeronaves e aeronaves, engenharia nuclear e robótica. Como um inventor do

processo de desenvolvimento do SCRUM, sua experiência em

desenvolvimento organizacional permitiu repetidamente que as equipes de

desenvolvimento de alta octanagem entreguem produtos de software de classe

mundial.

Dave Thomas acredita que o coração de um projeto não é a

metodologia, mas as pessoas. Os membros da equipe precisam ser

tecnicamente competentes, motivados e alinhados. Esse foco no indivíduo foi

uma das razões por que ele foi co-autor de “The Pragmatic Programmer”. Mas

o lado técnico não é suficiente. Cada membro da equipe também deve estar

envolvido: envolvido em seu trabalho, envolvido em sua equipe, e envolvido em

sua organização. Dave e Andy agora estão trabalhando em maneiras de ajudar

os indivíduos a fazer a transição para metodologias ágeis.

18

CAPÍTULO II

AGILE SCRUM

Neste capítulo vamos tratar de um dos métodos ágeis mais populares do

mundo atualmente, o Scrum. Muitas empresas estão deixando de lado modelos

tradicionais de gerenciamento e migrando para o modelo de trabalho proposto

pelo Scrum.

O Scrum busca entregar resultados de maneira mais rápida e com

menor custo, com o objetivo de fornecer produtos e serviços que se alinhem as

necessidades do cliente. Ao implementar o Scrum em sua organização, é

importante o alinhamento em favorecimento do cliente em primeiro lugar.

De acordo com (PRESSMAN, 2011):

A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento. A filosofia defende a satisfação do cliente e a entrega de incremental prévio; equipes de projetos pequenas e altamente motivadas; métodos informais; artefatos de engenharia de software mínimos e, acima de tudo, simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam a entrega mais que a análise e projeto (embora essas atividades não sejam desencorajadas); também priorizam a comunicação ativa e contínua entre desenvolvedores e clientes.

Pressman cita que uma das prioridades é a entrega, mas qual é o cerne de ser

ágil?

Atualmente, agilidade tornou-se a palavra da moda quando se descreve um moderno processo de software. Todo mundo é ágil. Uma equipe ágil é aquela rápida e capaz de responder apropriadamente a mudanças. Mudanças têm muito a ver com desenvolvimento de software. Mudanças no software que está sendo criado, mudanças nos membros da equipe, mudanças devido a novas tecnologias, mudanças de todos os tipos que poderão ter um impacto no produto que está em construção ou no projeto que cria o produto. Suporte para mudanças deve ser incorporado em tudo o que fazemos em software, algo que abraçamos porque é o coração e a alma do software. Uma equipe ágil reconhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as habilidades dessas pessoas, suas capacidades em colaborar, estão no cerne do sucesso do projeto.

19

O fundador do Scrum (Schwaber e Sutherland, 1995) o descreveu como

um processo de desenvolvimento ágil que tem sido usado para gerenciar o

desenvolvimento de produtos complexos desde o início da década de 1990.

No Scrum, os projetos são dividos em ciclos (tipicamente mensais)

chamados de Sprints. O Sprint representa um Time Box dentro do qual um

conjunto de atividades deve ser executado. Metodologias ágeis de

desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em

iterações, que são chamadas de Sprints no caso do Scrum.

As funcionalidades a serem implementadas em um projeto são mantidas

em uma lista que é conhecida como Product Backlog. No início de cada Sprint,

faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na

qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona

as atividades que ela será capaz de implementar durante o Sprint que se inicia.

As tarefas alocadas em um Sprint são transferidas do Product Backlog para o

Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente

de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre

o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do

dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades

implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint

Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim

reinicia-se o ciclo. Veja a ilustração abaixo:

20

Figura 2 - Fluxo do Sprint

Fonte: Libordi; Barbosa (2010, p. 18)

2.1. Product Backlog

O Product Backlog trate-se de uma lista abrangendo as funcionalidades

desejadas para determinado produto. O conteúdo desta lista é definido pelo

Product Owner. O Product Backlog não precisa estar completo no início de um

projeto. Pode-se começar com tudo aquilo que está mais claramente definido.

Com o tempo, o Product Backlog cresce e muda à medida que se aprende

mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do

Product Backlog e os descreve para a equipe. A equipe então determina que

itens será capaz de completar durante a Sprint que está por começar. Tais

itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao

fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais

tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da

equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades

diretamente relacionadas às funcionalidades solicitadas.O Daily Scrum não

deve ser usado como uma reunião para resolução de problemas. Questões

levantadas devem ser levadas para fora da reunião e normalmente tratadas por

21

um grupo menor de pessoas que tenham a ver diretamente com o problema ou

possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da

equipe provê respostas para cada uma destas três perguntas:

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer

hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e

que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de

status report na qual um chefe fica coletando informações sobre quem está

atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem

compromissos perante os demais.

O Scrum Master é responsável por tratar o mais rápido possível dos

impedimentos identificados no Daily Scrum.

2.2. Sprint Backlog

O Sprint Backlog é uma lista de tarefas que o Scrum Team se

compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do

Product Backlog, pela equipe, com base nas prioridades definidas pelo Product

Owner e a percepção da equipe sobre o tempo que será necessário para

completar as várias funcionalidades.

Cabe a equipe determinar a quantidade de itens do Product Backlog que

serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a

implementá-los.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog

atualizando-o para refletir que tarefas são completadas e quanto tempo a

equipe acredita que será necessário para completar aquelas que ainda não

estão prontas.

2.3. Scrum Master

O Scrum Master procura assegurar que a equipe respeite e siga os

valores e as práticas do Scrum. Ele também protege a equipe assegurando que

22

ela não se comprometa excessivamente com relação àquilo que é capaz de

realizar durante um Sprint.

O Scrum Master atua como facilitador do Daily Scrum e torna-se

responsável por remover quaisquer obstáculos que sejam levantados pela

equipe durante essas reuniões.

O papel de Scrum Master é tipicamente exercido por um gerente de

projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da

equipe.

2.4. Daily Scrum

O Daily Scrum trata-se de reuniões diárias. Ela tem como objetivo

disseminar conhecimento sobre o que foi feito no dia anterior, identificar

impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizadas no mesmo lugar, na

mesma hora do dia. Preferencialmente são realizadas na parte da manhã, para

ajudar a estabelecer as prioridades do novo dia de trabalho.

Todos os membros da equipe devem participar do Daily Scrum. Outras

pessoas também podem estar presentes, mas só poderão participar como

ouvintes. Isso torna os Daily Scrums uma excelente forma para uma equipe

disseminar informações sobre o estado do projeto.

O Daily Scrum não deve ser usado como uma reunião para resolução de

problemas. Questões levantadas devem ser levadas para fora da reunião e

normalmente tratadas por um grupo menor de pessoas que tenham a ver

diretamente com o problema ou possam contribuir para solucioná-lo.

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer

hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e

que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de

status report na qual um chefe fica coletando informações sobre quem está

23

atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem

compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo

Scrum Master o mais rapidamente possível.

2.5. Product Owner

O Product Owner é a pessoa que define os itens que compõem o

Product Backlog e os prioriza nas Sprint Planning Meetings.

O Scrum Team olha para o Product Backlog priorizado, seleciona os

itens mais prioritários e se compromete a entregá-los ao final de um Sprint

(iteração). Estes itens transformam-se no Sprint Backlog.

A equipe se compromete a executar um conjunto de atividades no Sprint

e o Product Owner se compromete a não trazer novos requisitos para a equipe

durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas

apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um

Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos

requisitos não são aceitos.

2.6. Scrum Team

O Scrum Team é a equipe de desenvolvimento. Nela, não existe

necessariamente uma divisão funcional através de papéis tradicionais, tais

como programador, designer, analista de testes ou arquiteto. Todos no projeto

trabalham juntos para completar o conjunto de trabalho com o qual se

comprometeram conjuntamente para um Sprint.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de

projetos Scrum com equipes maiores. A principal abordagem para trabalhar

com equipes grandes no Scrum é usando o conceito de "Scrum of Scrums".

Cada Scrum Team trabalha normalmente, mas cada equipe também contribui

com uma pessoa que deverá freqüentar o Scrum of Scrums Meeting para

coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são

24

análogos aos Daily Scrums, mas não acontecem necessariamente todos os

dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente

na maioria das organizações.

2.7. Sprint Review Meeting

Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta

reunião, o Scrum Team mostra o que foi alcançado durante o Sprint.

Tipicamente, isso tem o formato de um demo das novas funcionalidades.

Os participantes do Sprint Review tipicamente incluem o Product Owner,

o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros

projetos.

Durante o Sprint Review, o projeto é avaliado em relação aos objetivos

do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a

equipe completou cada um dos itens do Product Backlog trazidos para fazer

parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral

do Sprint.

25

CAPÍTULO III

Programação Extrema ou XP

Em 1996, Kent Beck e Ward Cunningham criaram a metodologia

Programação extrema (do inglês Extreme Programming) ou XP (FIGUEIREDO,

2005), baseada numa série de princípios e boas práticas, esta técnica permite

o desenvolvimento de forma ágil. O “Extreme” se deve ao fato dela empregar

ao extremo boas práticas da engenharia de software (BECK, 1999), sem

esquecer-se do custo e qualidade

XP é uma metodologia ágil para desenvolvimento de software, é

recomendada sua utilização em projetos com requisitos incertos e que mudam

com frequência, que possuam equipes pequenas, onde o sistema possa ser

desenvolvido de forma incremental (ou iterativa) e que a programação seja feita

usando o paradigma da orientação a objetos (OOP). O 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. Ele é 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.

Extreme Programming ressalta principalmente o trabalho em equipe. Os

gerentes, clientes e desenvolvedores são todos parceiros iguais em uma

equipe colaborativa. O XP implementa um ambiente simples de forma eficaz,

que permite as equipes tornarem-se altamente produtivas. A equipe se auto-

organiza em torno do problema para resolvê-lo de forma efetiva.

3.1. Valores da Extreme Programming

26

Figura 3 – Valores do XP

Fonte: Extreme Programming (2009)

As melhorias do Extreme Programming em um projeto de software se dá

de cinco formas essenciais: comunicação, simplicidade, feedback, coragem e

respeito. Esses são os pilares sobre os quais a metodologia XP é sustentada.

A seguir iremos detalhar cada um desses pilares que são essencias para guiar

o desenvolvimento.

Comunicação (Communication): Para que exista feedback a

comunicação precisa ser constante e intensa. A melhor forma de comunicação

entre duas pessoas é uma conversa face a face, conversas pelo telefone ou

através de mensagens instantâneas acabam não tendo a mesma eficiência. A

forma como nos comunicamos tem influência direta na compreensão da

mensagem, uma conversa face a face agrega valores como gestos,

expressões faciais, tom de voz, entre outros, isso acaba facilitando a

transmissão da mensagem e sua compreensão.

Simplicidade (Simplicity): Em projetos onde os requisitos podem mudar a

qualquer momento, criar funcionalidades desnecessárias só tornam o software

complexo e de difícil manutenção (BECK, 1999). Todo o código escrito deve

ser focado em criar funcionalidades priorizadas pelo cliente e que terão seu uso

de forma imediata. Fazer exatamente aquilo que o cliente precisa, da forma

mais simples possível, garante velocidade no desenvolvimento e facilidade na

manutenção.

27

Feedback: O feedback do cliente é parte essencial de uma iteração,

através dele os desenvolvedores conseguem avaliar o nível de sucesso de

uma nova versão e se as funcionalidades apresentadas atenderam as

expectativas dos usuários. A troca de informações deve ser constante, isso

gera uma união e reciprocidade entre todos os membros da equipe.

Coragem (Courage): Por ser uma metodologia relativamente nova e ser

contrária a vários processos tradicionais de desenvolvimento de software, a

adoção e aplicação exigem coragem da equipe. É preciso coragem para

manter o projeto simples, permitindo que o cliente priorize as funcionalidades

que deverão ser implementadas, aceitando mudanças constantes nos

requisitos e permitindo que todos tenham acesso aos códigos e possam

modificar os mesmos a qualquer momento

Respeito (Respect): O respeito é o valor que sustenta os demais, sem

respeito os outros valores perdem o sentido e a aplicação da metodologia se

torna inviável. Respeitar opiniões diversas, necessidades individuais, saber

ouvir e ter compreensão entre todos os membros da equipe é fundamental.

3.2. Práticas da Extreme Programming

Práticas em XP são derivadas de seus valores e representam aquilo que

a equipe executa diariamente, sua utilização depende do contexto, conforme o

contexto muda a aplicação da prática também deve mudar.

Na XP a presença do cliente é fundamental, as informações que o

mesmo fornece de forma rápida, permitem a obtenção do máximo de valor do

projeto, é essencial que ele participe ativamente do processo de

desenvolvimento.

Jogo de planejamento (Planning Game): O objetivo do jogo de

planejamento é que o cliente priorize aquilo que é importante para ele no

momento. O mesmo descreve de forma sucinta as funcionalidades que ele

deseja no sistema. O mesmo fica ciente do tempo e custo necessário para

28

desenvolver cada nova funcionalidade, esta prática assegura que o trabalho

seja direcionado para aquilo que é mais importante para o cliente.

Pequenas versões (Small Releases): A entrega constante de pequenas

versões, com novas funcionalidades, faz com que o cliente sinta confiança no

projeto. O mesmo ao iniciar o uso de uma nova versão, com as funcionalidades

que ele elegeu como prioritárias e que agregam valor ao negócio, produz um

ambiente de colabora- ção, motivando toda a equipe.

Metáfora (Metaphor): Numa equipe multidisciplinar onde os níveis de

conhecimento tendem a ser desproporcionais, ou seja, o desenvolvedor

entende muito de programação e o cliente entende muito das regras de

negócio, a comunicação pode se tornar complicada. O uso de metáforas

possibilita a transmissão de ideias de uma 22 formas mais clara e simples. Esta

prática facilita a comunicação entre o desenvolvedor e o cliente, estabelecendo

um vocabulário comum (BECK, 2004).

Projeto simples (Simple Design): Quanto mais simples for o sistema,

mais rapidamente o mesmo poderá ser adaptado à mudanças. A redução do

tempo e custo das mudanças depende de um projeto simples, ser simples não

significa que o mesmo não dispõe dos recursos necessários para atender o

cliente, significa que o projeto tem exatamente aquilo que o cliente precisa, no

nível de complexidade e flexibilidade necessários naquele momento.

Ritmo sustentável (Sustainable Pace): Pessoas cansadas não

conseguem aplicar a metodologia XP, o respeito pelos limites físicos e

necessidades individuais é essencial para a produção de um bom trabalho. A

XP recomenda que a carga horária de trabalho não ultrapasse oito horas

diárias e quarenta horas semanais.

Posse coletiva (Collective Ownership): Todos os desenvolvedores

devem ter acesso a todas as partes do código, podendo efetuar alterações

naquilo que for necessário. Esta prática é essencial para agilizar eventuais

correções ou revisões.

29

Programação em pares (Pair Programming): Dois programadores, de

forma coletiva, utilizam o mesmo computador para implementar determinadas

funcionalidades. Esta prática traz vários benefícios: revisão constante do

código; redução de erros; replicação de conhecimentos. As duplas devem ser

trocadas frequentemente, aumentando a união e disseminação das

experiências.

Padrões de codificação (Coding Standard): O padrão de codificação é

essencial para garantir uma manutenção rápida do software, o mesmo só pode

ser de posse coletiva se todos da equipe entenderem o código. Seguir um

padrão torna o código homogêneo, permitindo manutenções rápidas e seguras.

Desenvolvimento orientado a testes (Test Driven Development): Testes são

escritos para cada funcionalidade, antes de codificá-las, isto obriga um

planejamento das interfaces, classes e métodos, esta prática gera uma massa

de testes que pode ser usada a qualquer momento para validar todo o sistema

Refatoração (Refactoring): Consiste em organizar o código fonte de um

software, melhorando sua qualidade e facilitando o processo de manutenção.

Isso 23 é fundamental para tornar o código mais legível e detectar possíveis

erros.

Integração contínua (Continuous Integration): Logo após terminar

determinada rotina, o programador deve integrá-la ao projeto principal. Isso

deve ser feito várias vezes ao dia, visando a sincronização das atividades

individuais (BECK, 2004). Depois de algum tempo, adeptos de XP perceberam

que simplesmente aplicar todas as práticas, sem considerar os princípios e

valores por trás delas não era uma abordagem efetiva. O que faz sentido, de

acordo com a própria filosofia que XP segue: métodos ágeis devem ser

adaptativos e não-prescritivos. Esta observação levou à criação de uma nova

prática, chamada “Conserte XP quando ela não funciona”, que sugere que

quando não for possível aplicar XP em sua totalidade, as práticas devem ser

adaptadas de acordo com o ambiente. Desta forma, as práticas de XP não

devem ser vistas como dogmas, mas como orientações para organização do

projeto.

30

As práticas primárias são definidas como práticas se pode começar a

adotar imediatamente de forma segura para melhorar seu esforço de

desenvolvimento de um produto relacionado a software. Para definir qual

deverá ser adotado primeiro depende inteiramente de seu ambiente e o que

entende-se como sendo sua maior oportunidade de melhoria. Algumas

pessoas precisam de planejamento porque não sabem o que precisa ser feito.

Outros precisam de práticas relacionadas à melhoria de qualidade porque

estão criando defeitos demais para serem capazes de ver o que está

acontecendo.

As práticas corolárias são difíceis ou perigosas de serem implementadas

antes de se adotar as práticas primárias. Se você começar a implantar o

software diariamente, por exemplo, sem baixar a taxa de defeitos para algo

muito próximo de zero (com programação em par, integração contínua e

desenvolvimento orientado a testes), o que se tem é um desastre nas mãos. É

importante que exista confiança intuitiva sobre o próximo passa a ser

aprimorado. Se algumas das práticas a seguir parecer apropriada, tente-a.

Talvez funcione ou talvez você descubra que há mais trabalho a ser feito antes

que você possa usá-las para aprimorar seu processo de desenvolvimento.

31

CONCLUSÃO

Neste estudo monográfico foi evidenciado o conceito básico de

metodologia ágil, que visa melhorar a produtividade e aceitação do cliente. O

importante das metodologias ágeis é o foco na comunicação contínua com o

cliente, na entrega constante e na equipe de desenvolvimento. Dessa forma,

fica claro a mudança do conceito tradicional, em que primeiro planejamos todo

o produto, com uma análise completa, requisitos funcionais e não funcionais de

todo o produto, para depois iniciar o desenvolvimento, o que pode acarretar

problemas, pois um requisito mal entendido só será notado quando o produto

for entregue meses depois. Na metodologia ágil, planeja-se apenas o que será

feito naquele incremento, com detalhes, de forma que possamos desenvolver e

entregar ao cliente. Caso o requisito tenha sido mal interpretado, pode ser

rapidamente corrigido, pois o tempo do incremento é curso e a correção é

rápida, diferente de quando o produto foi entregue completo, e que aparece

muitos erros de requisitos, muitas coisas a serem corrigidas e melhoradas,

levando tempo da equipe e a desmotivação.

Outro ponto que apresentamos está relacionado as equipes a utilizar

os métodos ágeis, tratam-se de equipes pequenas, pois é mais fácil manter a

equipe motivada, integrada e com boa comunicação.

Quer ser ágil? Para ser ágil é preciso identificar alguns pontos

chaves como: comunicação com a equipe e com o cliente; desenvolvimento

com testes constantes (TDD), integração contínua, etc.

Para valorizar pessoas e suas interações é preciso fortalecer a

comunicação. Em vez de investir em novas ferramentas ou adotar processos

prescritos, sugerimos uma abordagem diferente, a Modelagem ágil. A utilização

de métodos de modelagem facilita a compreensão do problema e da solução,

além de melhorar a comunicação entre os stakeholders e resposta a

mudanças.

32

Buscou-se, ao longo deste estudo, fazer um levantamento

bibliográfico dos benefícios das metodologias ágeis no gerenciamento de

projetos. A partir do posicionamento dos autores pesquisados foi possível

identificar que as práticas apontadas pelas metodologias ágeis apresentadas

são eficientes para desenvolver sistemas, desde que usadas corretamente. As

metodologias ágeis surgem de uma mesma motivação e apresentam as

principais ideias em comum. O que identifica cada uma de forma unívoca é a

forma de implementar as ideias através de práticas para o dia a dia. Cada

conjunto de práticas dos métodos ágeis devem ser examinados de maneira

isolada. Resumidamente, pode-se entender que, para o desenvolvimento de

software, as metodologias baseadas em processos adaptativos têm potencial

de apresentar resultados melhores que os resultados apresentados pelas

metodologias baseadas em processos preditivos. Para as pessoas que

desenvolvem o sistema, as metodologias orientadas a pessoas apresentam

melhores condições de trabalho e melhores resultados que as metodologias

orientadas a processos. Metodologias ágeis têm sido bem aceitas pela

indústria de software e por pesquisadores da Engenharia de Software, quando

comparadas com as metodologias tradicionais, devido aos resultados

satisfatórios. Dentre seus benefícios, constatou-se que os métodos utilizados

para desenvolvimento de software podem ser considerados um diferencial que

promete aumentar a satisfação do cliente agregando maior valor ao produto

final, produzindo software alta qualidade e acelerando os prazos de

desenvolvimento de projetos.

A conclusão deste estudo evidência indícios da forma como o

mercado utiliza e encara as metodologias ágeis nos dias atuais. Com isso,

favorece a revisão constante dos conceitos da teoria, possibilitando maior

ênfase aos que são largamente utilizados com resultados satisfatórios,de modo

a filtrar e propor transformações aos que estão tornando-se arcaicos por falta

de aplicação.

A metodologia ágil, se utilizada da forma correta e com alinhamento

de expectativas e necessidades do cliente, traz grande ganho para o projeto,

como por exemplo, uma entrega adiantada e contínua com valor. Por esse

33

motivo é importante conhecer e estudar o método e aplicá-lo da melhor forma,

avaliando se o projeto está apto para utilizá-lo.

34

BIBLIOGRAFIA

BECK, K. Programação Extrema Explicada: Acolha as mudanças. Bookman,

2004.

COHN, Mike. Desenvolvimento de Software com Scrum: Aplicando métodos

ágeis com sucesso. Porto Alegre: Bookman, 2011.

LIBORDI, P. L. O.; BARBOSA, V. Métodos Ágeis. 2010. 35f. Artigo

(Especialização em TI) - Faculdade de Tecnologia – FT, Universidades

Estadual de Campinas, 2010.

PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: Ed. Mc Graw

Hill, 2007.

SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Person, 2010.

TORREÃO, P.G.B.C. Ambiente inteligente de aprendizado em educação em

gerenciamento de projetos. UFPE. Março, 2005.

WELLS, D. Extreme Programming: A Gentle Introduction. Extreme

Programming. 2009.

http://manifestoagil.com.br/, acessado em dezembro de 2016.

http://www.agilealliance.org, acessado em janeiro de 2017.

http://www.desenvolvimentoagil.com.br, acessado em janeiro de 2017.

35

ÍNDICE

FOLHA DE ROSTO 01 AGRADECIMENTOS 02 DEDICATÓRIA 03 RESUMO 04 METODOLOGIA 05 SUMÁRIO 06 INTRODUÇÃO 08

CAPÍTULO I

Manifesto Ágil 10

1.1. Os doze princípios do manifesto ágil 11

1.2. Sobre os autores do manifesto ágil 12

CAPÍTULO II

Agile Scrum 18

2.1. Product Backlog 20

2.2. Sprint Backlog 21

2.3. Scrum Master 21

2.4. Daily Scrum 22

2.5. Product Owner 23

2.6. Scrum Team 23

2.7. Sprint Review Meeting 24

CAPÍTULO III

Programação Extrema ou XP 25

3.1. Valores da Extreme Programming 25

3.2. Práticas da Extreme Programming 27

CONCLUSÃO 31 BIBLIOGRAFIA 34