Escolar Documentos
Profissional Documentos
Cultura Documentos
por
Aleckssandro Tavares
Gravataí, 2008
SUMÁRIO
RESUMO........................................................................................................03
ABSTRACT....................................................................................................04
LISTA DE ABREVIATURAS.........................................................................05
LISTA DE FIGURAS......................................................................................06
INTRODUÇÃO...............................................................................................07
1 REFERENCIAL TEÓRICO.........................................................................13
1.1 Processo de Software..........................................................................13
1.2 Gerenciamento de Projetos.................................................................15
1.3 Metodologias Ágeis..............................................................................22
1.4 Scrum...................................................................................................23
1.5 Ruby on Rails.......................................................................................33
2 ESTADO DA ARTE....................................................................................36
2.1 Estudos da Aplicação de Práticas do PMBOK com Agile...................37
2.2 Projetos com Metodologias Ágeis.......................................................40
2.3 Comparativo com Estudos e Projetos Apresentados..........................41
3 SOLUÇÃO IMPLEMENTADA....................................................................43
3.1 Levantamento de Requisitos, Product Backlog e Escopo...................43
3.2 Planejmento.........................................................................................44
3.3 Visão Geral do Sistema em Casos de Uso.........................................45
3.4 Arquitetura............................................................................................49
3.5 Diagrama de Classe Conceitual..........................................................51
3.6 Layout do Site......................................................................................52
CONSIDERAÇÕES FINAIS...........................................................................53
REFERÊNCIAS BIBLIOGRÁFICAS.............................................................56
ANEXO 1: Declaração Preliminar de Escopo............................................59
ANEXO 2: Plano de Gerenciamento do Escopo.......................................65
RESUMO
Motivação
Objetivo do Trabalho
mesmo tempo, comprovar que o uso de práticas Ágeis com PMBOK é viável
com devidas adaptações de acordo com o tipo de projeto. Tentar identificar
como adaptar os processos do PMBOK para co-existir com o modelo Ágil. Não
uma forma estática ou única, já que cada projeto pode ter as suas
necessidades de adaptações.
Estrutura do Trabalho
1.1.1 CMM
1.1.3 MPS.BR
deve ser definido por quem utiliza estes modelos, fazendo-se as adaptações
necessárias para a sua realidade. Ainda, como bem salientado por REINEHR,
sobre estes modelos e normas, eles possuem foco na organização e são de
difícil aplicação a pequenas equipes:
Projeto tem sido a linguagem cada vez mais comum nas empresas,
ainda que isso não garanta que elas estejam conduzindo os projetos da melhor
maneira ou alcancem os resultados esperados da forma mais eficaz.
O PMI é uma associação mundial sem fins lucrativos com foco exclusivo
em Gerenciamento de Projetos. Sua origem se deu em 1969 nos EUA através
de cinco voluntários e atualmente conta com mais de 270.000 associados no
mundo inteiro (PMI-SP, 2008).
1.2.1 PMBOK
1.2.2. Projeto
Quando diz temporário, significa que o projeto deve ter um inicio e fim
definidos. Basicamente quando os objetivos do mesmo são alcançados chega-
se ao fim, logo para isso é importante ter bem claro quais os objetivos do
projeto. Quando se fala em temporário pensa-se instintivamente em um curto
espaço de tempo, porém projetos podem levar dias, meses ou até anos, no
entanto precisa ter uma data de fim já que um projeto não é eterno. O produto
gerado pelo projeto até pode ter vida “eterna” e/ou indeterminada, mas não o
projeto.
Ferramentas
Entradas Saídas
Técnicas
Iniciação Planejamento
Controle Execução
Encerramento
Criar a EAP
Definição de Controle do
Atividades Cronograma
Seqüenciamento
de Atividades
Estimativa de
Recurso das
Tempo
Atividades
Estimativa de
Duração das
Atividades
Desenvolvimento
do Cronograma
Estimativa de Controle de
Custos Custos
Custos
Orçamentação
Planejamento da Garantia da Controle da
Qualidade
Qualidade Qualidade Qualidade
Planejamento de Montagem da Gerenciar a
Recursos Equipe Equipe do Projeto
Recursos
Humanos
Humanos
Desenvolvimento
do Time
Planejamento das Distribuição das Relatório de
Comunicações Informações Desempenho
Comunicação
Gerenciamento
das Partes
Interessadas
Planejamento do Monitoramento e
Gerenciamento Controle de Riscos
dos Riscos
Identificação de
Riscos
Análise Qualitativa
Riscos de Riscos
Análise
Quantitativa dos
Riscos
Planejamento de
Respostas a
Riscos
22
1.4 SCRUM
24
Ao final do Sprint deve sair produto com valor agregado, ou seja, é feito
um incremento no produto. Esse ciclo se repete várias vezes até que o Product
Backlog seja todo atendido (CONTROL CHAOS, 2008). Ver ciclo na Figura 1.4.
1.4.1.1 Pregame
1.4.1.2 Game
1.4.1.3 Postgame
O SCRUM não define como esta lista é formada, podendo ser usadas
várias técnicas de captura de requisitos. Uma das técnicas utilizadas é tratar
cada item da lista como uma história, ou User Stories como no XP
(MOUNTAIN, 2008).
É uma lista que contém as tarefas que o Scrum Team irá trabalhar
durante o Sprint. Os itens do Product Backlog priorizados pelo Product Owner,
e que a equipe após estimativa inicial e a percepção do trabalho necessário se
comprometeu a entregar dentro do Sprint, são depois quebrados em tarefas
que formam o Backlog do Sprint.
Essas tarefas devem ser atendidas dentro do Sprint, mas caso não
sejam, devem fazer parte do próximo Sprint Backlog.
Cada tarefa deve ser estimada pela equipe quanto ao número de horas
necessário para completá-la. E é responsabilidade da equipe manter atualizada
diariamente a lista de tarefas, com as tarefas já concluídas, e a estimativa de
tempo necessário para a conclusão das tarefas ainda em andamento. Tarefas
já concluídas devem ter o número de horas para a conclusão estimadas como
zero.
120
Re m aining Effort in Hours
100
80
60
40
20
0
26/10 27/10 28/10 29/10 30/10 31/10 01/11 02/11 03/11 04/11 05/11 06/11 07/11 08/11 09/11
Date
não deve ter a data final alterada para que as métricas de velocidade do time
sejam consistentes.
1.5.1 Ruby
É uma linguagem open source, criada para ser mais do que simples,
para ser natural segundo seu criador. Desde 1995 quando teve sua primeira
versão pública tem crescido o número de programadores adeptos a nova
linguagem. Ela conta com uma comunidade ativa, embora as principais
decisões quando não há consenso sejam tomadas por “Matz”. Não há
nenhuma empresa por trás da linguagem, sendo mantida exclusivamente pela
comunidade.
1.5.3 MVC
Felizmente este cenário está mudando, e está cada vez mais comum
encontrar a adoção de ambos os processos ou metodologias em conjunto nas
empresas, adaptados para conviverem num mesmo ambiente fornecendo o
que cada uma tem de positivo para o processo como um todo.
Importante salientar que o Escopo está sendo tratado como mais amplo
que o Product Backlog. Enquanto o Product Backlog contempla as
funcionalidades do produto, e logo define o escopo do produto, o Escopo está
sendo tratado como toda a visão do projeto, que vai mais além do que o
produto em si e por isso define o escopo do projeto, conforme distinção de
escopo feita pelo PMBOK Guide (PMBOK, 2004 p. 104).
3.2. Planejamento
Figura 3.1, o qual possui dois casos de uso. Cada um destes dois casos de uso
foi detalhado em outro diagrama, resultando em mais dois diagramas. São os
diagramas “Navegar no Web Site” da Figura 3.2 e “Gerenciar Web Site” da
Figura 3.3.
3.4. Arquitetura
Para ter uma idéia de alto nível das classes que serão necessárias no
produto, mas ao mesmo tempo sem entrar no detalhe foi feito um diagrama de
classe conceitual baseado na análise inicial das quatro User Stories
(funcionalidades) priorizadas pelo cliente (Product Owner) para serem
entregues na primeira versão (release) implantada do software. O diagrama
pode ser observado na Figura 3.5.
Versão Doc.:
ANEXO 1
Declaração Preliminar de 1.0
Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai
Informações do Projeto
Representante do Cliente Gerente do Projeto
Justificativa do Projeto
O site institucional da editora é o principal canal de comunicação com os clientes. Para isso
precisa manter-se sempre atualizado com notícias, lançamentos e promoções. Porém atualmente
o site é com conteúdo estático requerendo um especialista para a sua atualização.
Este projeto irá proporcionar uma área de administração para o gerenciamento do conteúdo do
site de forma dinâmica, sem a necessidade de um especialista.
Objetivos e Metas
Situação Atual
A editora possui um Site Institucional e uma Loja Virtual. Ambos são independentes, estando
inclusive hospedados em servidores de fornecedores diferentes. O site é hospedado na LocaWeb
e a loja no Shopping dos Correios.
O conteúdo do site é totalmente estático, ou seja, em HTML, sem banco de dados e sem área de
administração. Quando necessário atualizações de conteúdo, sejam banners, notícias, novos
produtos, etc, precisam de um especialista para editar as imagens, html e posterior upload do
conteúdo atualizado para o servidor de hospedagem.
Nem todos os pedidos ou compras são feitos pela loja, sendo que alguns pedidos são gerenciados
também por telefone e e-mail. Logo nem todos clientes ficam cadastrados na loja online.
Situação Desejada
Maior flexibilidade para editar o conteúdo do site de forma dinâmica através de uma área de
administração. A edição deverá ser possível por uma pessoa, sem a necessidade de
conhecimento prévio de html.
Também é desejo do cliente concentrar a administração dos clientes pela site já que nem todos
clientes são cadastrados na loja online e também para não ficar dependente do fornecedor da
loja online.
60
Versão Doc.:
ANEXO 1
Declaração Preliminar de 1.0
Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai
Prazo e Marcos
Principais marcos:
Custos
O projeto será efetuado sem custo de desenvolvimento para a empresa Adhonai. Outros custos
operacionais, como hospedagem ficarão a cargo da editora.
Lista inicial de funcionalidades listadas pelo cliente. Esta lista poderá ser alterada ao longo do
projeto. Funcionalidades poderão ser alteradas quanto a sua prioridade, poderão ser quebradas
em outras funcionalidades ou poderão ser canceladas. Novas funcionalidades poderão ser
adicionadas.
Na lista abaixo, o campo “Prioridade” indica a relevância usando numeração seqüencial. Quanto
menor o número, maior a prioridade.
O produto está organizado em módulos para facilitar o entendimento das funcionalidades. São
eles:
Abaixo segue lista de funcionalidades (Product Backlog) que está ordenada pela prioridade
definida pelo cliente. Para a definição das funcionalidades foram considerados 4 papéis:
61
Versão Doc.:
ANEXO 1
Declaração Preliminar de 1.0
Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai
• Cliente: Pessoa que já fez compra na editora pela loja online, telefone, e-mail ou
pessoalmente.
• Usuário: Pessoa que navega no site da editora sem ser cliente da mesma.
• Administrador: Papel de administrador do site, com acesso a área de administração do
mesmo.
• Gerente: Gerente da editora, que pode ou não ser o administrador.
Versão Doc.:
ANEXO 1
Declaração Preliminar de 1.0
Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai
Principais Entregas
A principal entrega é basicamente o site institucional da editora. Este estará dividido em dois
subprodutos:
Site institucional: Site web aberto na internet para qualquer tipo de usuário;
Premissas
O cliente estará disponível ao longo do projeto sempre que necessário para planejamento
das funcionalidades, Sprints e validação do software.
Não faz parte do escopo criar uma nova loja online ou sistema de CRM para gerenciar
clientes.
Restrições
Riscos
Versão Doc.:
ANEXO 1
Declaração Preliminar de 1.0
Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai
Organização do Projeto
Metodologia
Este projeto usará Metodologias Ágeis para o planejamento e execução. Terá como base o
SCRUM.
Sprints / Iterações
Para as entregas de software será dividido em Iterações (Sprints) com tempo a ser definido ao
longo do planejamento.
Dicionário da EAP
Versão Doc.:
ANEXO 1
Declaração Preliminar de 1.0
Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai
das releases.
Relatório de Desempenho E-mail enviado ao cliente com status de Deverá conter o status do projeto,
andamento do projeto. quantidade de tarefas concluídas e
faltantes e o gráfico de burndown.
Product Backlog Lista de pendências do projeto. Conterá Cada item da lista será priorizada e
funcionalidades do produto e itens que deverá conter o status do item ao longo
correspondem ao projeto. das iterações.
Planejamento Releases Organização das releases, seu tamanho em Os itens atendidos a cada release só
semanas, iterações e os itens que serão serão planejados no início da release.
atendidos.
Arquitetura Macro Documento descrevendo a arquitetura macro do Deverá conter diagrama de caso de uso
produto, quanto a camadas, banco de dados, de nível zero e diagrama ilustrando as
módulos, integrações, etc. camadas do software e integrações.
Hospedagem Configurar ambiente de hospedagem do site. Ambiente apto a hospedar o produto
(site) para as integrações e validação do
cliente.
Banco de Dados Instalação e configuração do gerenciador de MySql instalado e configurado.
banco de dados.
Linguagem de Programação Instalação e configuração da linguagem de Ruby instalado e configurado com o
programação utilizada no projeto e frameworks framework Rails.
necessários.
Integração com Loja Funcionalidades específicas de integração com Funcionalidades de integração
a loja online da Adhonai. funcionando conforme validação do
cliente.
Site Público Funcionalidades públicas. Site institucional. Site publicado na internet e disponível
para qualquer pessoa de acordo com
validação do cliente.
Administração Funcionalidades de administração do site. Área de administração funcionando
conforme validação do cliente.
Disponível apenas para usuários
restritos.
Layout Definição de layout do site, quanto a cores, HTML funcionando seguindo a definição
html, css, imagens, etc e funcionalidades TableLess.
referentes a layout.
Lições Aprendidas Documento descrevendo as lições aprendidas Listagem de lições aprendidas.
no projeto. Reflexão e análise feita após a
entrega do projeto e aceite do cliente.
65
Versão Doc.:
ANEXO 2
Plano de Gerenciamento do 1.0
Escopo Data:
29/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai
Metodologia
Este projeto usará Metodologias Ágeis para o planejamento e execução, usando princípios do Manifesto Ágil
(www.agilemanifesto.org).
Nesta reunião o cliente escreveu em post-its as funcionalidades desejadas para o site, sendo apenas uma
funcionalidade (ou história) por post-it.
As a <Role>
I want <Feature>
So that <Benefit>
Sprint / Releases
Para as entregas de software será dividido em Sprints coforme fluxo do SCRUM e releases.
Cada Sprint representará um período de 2 semanas, ao final do qual, software com valor agregado deverá ser
gerado para validação do cliente.
A cada 4 semanas, ou seja, a cada 2 Sprints uma versão do software pronto e validado pelo cliente será
implantado em produção.
Serão até 6 Releases, ou seja, até 6 meses de projeto. Com Releases programadas de Julho a Dezembro.
Caso Backlog seja atendido antes deste prazo, projeto será considerado finalizado com a devida
concordância do cliente.
As prioridades serão descritas por numeração seqüencial indicando a ordem de prioridade. Quanto menor o
número de prioridade, maior a prioridade.
66
Versão Doc.:
ANEXO 2
Plano de Gerenciamento do 1.0
Escopo Data:
29/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai
A prioridade de número 1 indica que deverá ser a primeira funcionalidade a ser atendida, a prioridade de
número 2 indica que deve ser o segundo item a ser atendido. E assim por diante.
No início de cada Release o cliente definirá qual as prioridades, entre as funcionalidades, a serem atendidas
no Release
Com base na priorização do cliente, os itens serão atendidos nos Sprints na ordem de prioridade. Porém, no
início de cada Sprint, o cliente poderá mudar o item a ser atendido no Sprint.
O cliente poderá acrescentar novas funcionalidades ao Product Backlog, assim como também poderá
cancelar itens de backlog ou mudar a prioridade. Porém uma Sprint uma vez iniciada não deverá mais ser
alterada.
As mudanças serão tratadas conforme necessidade do cliente, através do processo normal do SCRUM, nas
reuniões de Sprint Planning e Sprint Review.
Verificações do Escopo
No início será verificado o que ainda falta ser atendido no Product BackLog e o que será atendido no Sprint.
E ao final de cada Sprint para definição do que foi realmente atendido ou não e como está o Product
BackLog ao final do Sprint.
O escopo, ou Product Backlog, estará sempre sendo revisado também quando houverem mudanças de escopo
solicitadas pelo cliente.
Ao final de cada Sprint após atualização do backlog será enviado relatório por e-mail para o cliente com o
status de andamento do projeto.