Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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