SlideShare uma empresa Scribd logo
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM
PARA O MPS.BR NIVEL G
SILVA JUNIOR, Luiz Navarro1
Curso de Especialização em Engenharia de Software
Faculdade Estácio – IDEZ
ljrnavarro@gmail.com
RESUMO
Este artigo tem como objetivo apresentar uma alternativa de adaptação das práticas ágeis da
metodologia Scrum com foco na aderência ao nível G do MPS.BR. A partir de um cenário
hipotético são apresentadas ferramentas, artefatos e atividades que visam facilitar a obtenção
dos resultados. Por fim é realizada uma validação da proposta apresentada e a aderência ao
MPS.BR através do mapeamento entre as atividades adaptadas e os resultados esperados pelos
processos do nível G.
Palavras-chave: Scrum, Mps.br, qualidade de Software, desenvolvimento de Software,
processos de software, maturidade de software.
ABSTRACT
This article aims to introduce a SCRUM methodolody's agile practices' adaptation alternative
focusing on the MPS.BR's level G adherence. Tools, artifacts and activities will be presented
from a hypothetical scenario, aiming to facilitate the outcomes achievement. Finally, there is a
validation of the presented proposal and the MPS.BR adherence through the adapted
activities' mapping and the expected outcome by the level G.
Key words: Scrum, Mps.br, Software Quality, Software Development, software processes,
software maturity.
INTRODUÇÃO
A população é tão dependente do uso de softwares que alguns autores listam essa
dependência como uma das doenças do século 21 (Fernandes, Daniela, 2011). Seja em
smartphones, tablets e até em geladeiras e fogões o software definitivamente faz parte da
nossa rotina e esse caminho não tem volta, ao contrário tende a evoluir.
A tecnologia vem se desenvolvendo de forma extremamente rápida. Coisas que há
alguns anos acreditava-se que levariam décadas para serem reais, atualmente são comuns.
Apesar de todo esse avanço tecnológico, todos os dias surgem novas tecnologias e mesmo
diante deste cenário dinâmico o desenvolvimento de softwares ainda enfrenta muitos desafios.
1
Aluno do Curso de Especialização em Engenharia de Software. Turma 2012.1. Trabalho de Conclusão de
Curso.
2
A busca pela qualidade de produtos de software bem como a redução de custos e
tempo são metas obrigatórias nas pequenas e médias empresas que desenvolvem.
Ao final dos anos 90 os processos tradicionais já não acompanhava a demanda
tecnológica, começaram então a surgir as primeiras metodologias de processos ágeis como:
Adaptive Software Development, , eXtreme Programming (XP), Feature Driven Development
(FDD) e Scrum.
Surgiram também os frameworks de qualidade os quais oferecem coleções de
diretrizes para melhoria de processos dentro das organizações de todos os ramos e não apenas
ligadas a tecnologia. Alguns modelos medem o nível de maturidade dos processos e
certificam às organizações que atingem e que atendem os requisitos de qualidade desejados,
os principais modelos são: CMMI e MPS.BR.
A união dos conceitos e práticas ágeis com as diretrizes dos modelos de melhoria de
processos de qualidade é uma alternativa recente, inovadora e eficaz para obter a melhoria nos
processos de desenvolvimento de softwares e assim alcançar qualidade nos produtos finais e
consequentemente, aumentar a competitividade no mercado. Portanto, seguindo esta
tendência, é objetivo deste trabalho propor uma adaptação de processos do Scrum ao MPS.BR
nível g que possa ser usada como facilitador para empresas de desenvolvimento de software
que desejam melhorar a qualidade da produção de seus produtos.
REFERENCIAL TEÓRICO
1. MPS.BR
MPS.BR (Melhoria de Processo de Software Brasileiro) é um modelo de referência,
que tem como objetivo melhorar a qualidade nos processos de desenvolvimento de software e
para isso tem como proposta resultados simples de serem implementados, é indicado para
organizações de pequeno e médio porte cujo poder de investimento nesta área é limitado.
(SANTANA, TIMÓTEO & VASCONCELOS).
O modelo de referência MPS.BR possui como foco o gerenciamento do processo
utilizado pela organização e não determina o modo de como realizar determinadas tarefas,
mas enumera as diretrizes que a empresa deve seguir para que se atinja determinado nível de
maturidade.
Segundo o (Softex, 2013) impulsionar a melhoria da capacidade de desenvolvimento
de software e serviços nas empresas brasileiras é uma das metas do programa MPS.BR.
3
O MPS.BR tem seus processos baseados nas normas NBR ISO/IEC 12207, fornece
diretrizes para atingir qualidade nas áreas de produção, fornecimento, aquisição e
funcionamento de software. O método de avaliação é baseado nas áreas dos processos e tem
como base a ISSO/IEC 15504 (COUTO, 2007).
O MPS.BR é composto por um conjunto de guias: Guia Geral, que define o modelo de
referência de uma forma geral; Guia de Aquisição, descreve os processos que tratam de
aquisição de software; Guia de Avaliação fornece as metas para avaliação e Guia de
Implementação que define os níveis de maturidade que consequentemente mapeiam a
evolução dos processos e classificam estes processos segundo seus requisitos de maturidade,
os níveis de maturidade são divididos em sete classificações segundo sua evolução, são estes:
A (Em Otimização); B (Gerenciado Quantitativamente); C (Definido); D (Largamente
Definido); E (Parcialmente Definido); F (Gerenciado); G (Parcialmente Gerenciado), estes
níveis evoluem do nível G ao A segundo a capacidade da organização de atingir os perfis de
processos exigidos.
O nível G de maturidade, alvo deste estudo, é formado pelos processos de Gerência de
Projetos (GPR) que engloba dezessete atividades ligadas a responsabilidades, atividades e
manutenção de planos e acompanhamento do andamento do projeto e Gerência de Requisitos
(GRE) que por sua vez engloba cinco atividades que buscam divergências entra o planejado e
o que está sendo desenvolvido. Estes dois processos atendem respectivamente aos atributos de
processo AP 1.1 e AP 2.1.
2. A METODOLOGIA ÁGIL SCRUM
Criada em 1996, a metodologia Scrum diferencia-se das outras por ter um foco maior
nas pessoas e não em documentações. Tem em sua essência o gerenciamento do projeto como
principal objetivo e se concentra em monitorar e ajustar o desenvolvimento do produto
conforme as mudanças que eventualmente ocorram durante o processo.
O Scrum, segundo Martins (2007b), é totalmente adaptável e empírico, e por ser mais
flexível é indicado em projetos susceptíveis a mudanças durante o desenvolvimento do
software, ao contrário dos métodos tradicionais caracterizados por serem complexos e
engessados. Possui a capacidade de gerar valor para o negócio o mais rápido possível, pois,
mesmo com um software ainda incompleto, é possível gerar partes funcionais, ou seja, ter um
software com um mínimo de funcionalidades prontas e entregáveis.
4
O Scrum tem como base algumas características de aplicabilidade, entre elas estão:
equipes pequenas, requisitos voláteis e ciclos de desenvolvimento curtos.
A organização dinâmica e iterativa do Scrum engloba três principais papeis, que estão
definidos no Quadro 1.
Quadro 1 - Papéis e Responsabilidades no Scrum
Papel Responsabilidades
Scrum Master
Tem a responsabilidade de gerenciar todo o processo do
Scrum e fazê-lo ser compreendido, entendido por toda a
equipe (Team) e principalmente alinhado aos interesses da
organização, é responsável também por solucionar todos os
impedimentos durante o decorrer da Sprint. Outra
responsabilidade muito relevante é atuar como facilitador
entre o Team e o Product Owner.
Product Owner
Representante dos Stakeholders do projeto, em muitos
casos é o próprio cliente do produto e está diretamente
focado no retorno sobre o investimento (ROI).
Tem também a responsabilidade na priorização e
elaboração dos requisitos do Product Backlog e deve estar
sempre disponível para o Team e presente durante as
cerimonias previstas.
Team (Time)
Equipe multidisciplinar e com diferentes habilidades
técnicas, responsável por transformar os requisitos
selecionados (Sprint Backlog) para a iteração em
funcionalidades e gerar um produto parcial integrável.
O Team tem a autoridade para alocar e priorizar as ações
que serão executadas durante a Sprint, em alguns casos
essas decisões devem ser decididas em conjunto com o
Scrum Master e/ou Product Owner. O Team também deve
informar sobre eventuais impedimentos ao Scrum Master.
Fonte: Engenharia de Software – Magazine, 2010.
5
O ciclo de desenvolvimento do Scrum é composto por três fases, conforme Quadro 2.
Quadro 2 – Fases do Scrum
Fase Definição
PRE-GAME
Esta fase se subdivide em outras duas: Planejamento que tem como objetivo
estabelecer um novo release, a visão do projeto, estabelecer prazos e custos.
A outra fase que se chama Staging tem como objetivo avaliar as bases para
construção do produto, como tipo do sistema, ambiente de
desenvolvimento, etc.
GAME
É a fase de desenvolvimento do release, formada por múltiplas sprints onde
temos ao final um conjunto de funcionalidades capaz de tornar um produto
parcial e funcional. Durante esta fase sempre devem ser observados prazos,
custos e qualidade, através dos artefatos de acompanhamento do Scrum.
POST-GAME
Fase de fechamento do produto onde ele é finalizado para distribuição. Durante
esta fase são realizadas outras atividades como: atividades de integração,
análise, documentação do usuário, treinamento e preparação do material de
marketing.
Fonte: Engenharia de Software – Magazine, 2010.
Como toda metodologia de desenvolvimento, no Scrum há alguns artefatos previstos e
algumas práticas pré-definidas, conforme Quadro 3.
Quadro 3 - Práticas a Artefatos previstas no Scrum
Artefatos / Práticas Definição
Product Backlog
Repositório de características e funcionalidades priorizadas e definidas
pelo cliente ou Product Owner no inicio do projeto que pode ser
mudado de acordo com o andamento do projeto.
Sprint Backlog ou
Selected Backlog
Lista de funcionalidades selecionadas a partir do Product Backlog para
serem desenvolvidas na iteração ou Sprint
Sprint
Iterações ou ciclos de desenvolvimento onde são desenvolvidos os
requisitos escolhidos na Sprint Backlog. Ao final de cada Sprint temos
um produto incompleto, porém funcional.
Daily Scrum
Reuniões diárias que servem para informar o andamento do projeto
dentro do Team bem como avaliar impedimentos, o que será e o que foi
feito. As reuniões devem durar no máximo 15 minutos.
Sprint Planning
Meeting
São reuniões divididas em duas partes, na primeira o Product Owner
prioriza as principais funcionalidades e juntamente com o Team define
o que será trabalhado, na segunda parte o Team organiza as
funcionalidades e assim monta o Sprint Backlog.
Sprint Review
Meeting
Reunião realizada no final da Sprint onde o Team apresenta o resultado
do desenvolvimento na iteração ao Product Owner. Neste momento
ainda podem ocorrer adaptações segundo decisão do Product Owner e
Team.
6
Sprint Retrospective
Meeting
Juntamente com o Team o Scrum Master elenca as lições aprendidas
durante a Sprint para servir como base de conhecimento, bem como
avalia o que pode ser melhorado no processo para a próxima Sprint.
Burndown Charts
Gráfico que mede a evolução e a velocidade da Sprint, ou seja,
possibilita a avaliação continua do progresso do Team em relação à
iteração.
Mede também a evolução do projeto como um todo.
Fonte: Dados da Pesquisa
O processo de desenvolvimento Scrum tem como ponto de partida uma visão completa
do produto que será desenvolvido (SCHWABER, 2008).
A visão contempla a lista de características do produto estabelecidas pelo cliente, além
de algumas premissas e restrições. A partir da visão o Product Backlog é formado baseado na
lista de requisitos conhecidos. O Product Backlog é então priorizado e dividido em iterações.
O fluxo de desenvolvimento detalhado do Scrum é pode ser visualizado na Figura 1.
Figura 1 – Ciclo do Scrum
Fonte: Disponível em: http://codeauth.blogspot.com.br/2012/11/primeiro-contato-com-Scrum-knowing-
Scrum.html. Aceso em 21/09/2013.
7
3. PROPOSTA ADAPTADA DO SCRUM
3.1 CENÁRIO HIPOTÉTICO
Para uma melhor compreensão da aplicação das ferramentas e atividades propostas
neste artigo, foi idealizado um cenário de uma empresa de tecnologia de desenvolvimento de
software que possui as seguintes características básicas: cinquenta clientes, uma equipe
multidisciplinar de dez pessoas, três produtos de software cujo suporte é feito totalmente
online. No contexto de gestão de projetos de software foram selecionados áreas com base na
semelhança das características de domínio, escopo, arquitetura, tempo, custo e equipe.
A dinâmica deste cenário se concentra em alguns marcos que serão descritos a seguir
juntamente com as ferramentas e artefatos que servirão de apoio à proposta apresentada.
O ponto de partida do processo é o registro das necessidades de atendimento ou
demandas pelos clientes que é feito através de um sistema online de cadastramento de
solicitações, neste sistema devem ser preenchidas as informações da solicitação como: cliente,
área de atuação, data de registro e tipo de atendimento, também são gravados todos os logs de
troca de informações entre o suporte e o cliente e por fim, permite que o cliente acompanhe
em qualquer momento qual a situação da demanda por ele registrada, estas demandas são
avaliadas por um Product Owner que os representa dentro da equipe e assume um papel de
interface entre a equipe e os anseios do cliente. O Product Owner classifica cada demanda
como um atendimento de suporte, uma falha do sistema ou uma solicitação de melhoria, a
partir daí começa a ser formado o Product Backlog com todas as demandas desejadas ou
falhas registradas no sistema de solicitações, classificadas e priorizadas pelo Product Owner .
O Product Backlog é um repositório inicial para o início do projeto e dinâmico ao longo das
iterações ou Sprints.
Com as funcionalidades cadastradas e priorizadas no Product Backlog o próximo
passo é a reunião de planejamento para um novo produto, e todas as decisões são registradas
no documento de visão, são avaliados custo e riscos iniciais do projeto, requisitos não
funcionais como arquitetura, tecnologia, infraestrutura, é informado também o plano de dados
que envolve a estrutura de pastas, segurança e regras de acesso aos dados do projeto, deve
conter também o cronograma do projeto que por sua vez deve informar quantas Sprints estão
previstas como também a previsão de conclusão do projeto, recomenda-se um prazo de
quinze dias para cada iteração.
As informações e características do projeto, após definidas, são devidamente
configuradas no redmine. O Redmine é uma ferramenta de gerenciamento de projetos que,
8
entre outras funcionalidades, permite registrar as atividades de desenvolvimento de software
pelo time e o acompanhamento de vários aspectos do projeto, é flexível ao ponto de
possibilitar vários tipos de dados como: Sprints planejadas, tempo de desenvolvimento de
cada atividade, usuários da equipe e seus papéis juntamente com os níveis de acesso.
A equipe e o Scrum Master definem os itens do Product Backlog que farão parte das
Sprints, ou seja, os itens do Sprint Backlog e posteriormente a equipe faz as estimativas de
cada funcionalidade levando em conta o que realmente será possível desenvolver alinhado
com as prioridades.
Inicia-se, por conseguinte o desenvolvimento das funcionalidades divididas entre as
Sprints e para isso se faz necessário à composição do Task Board, que tem o objetivo de
facilitar o gerenciamento, pelo Scrum Master e equipe, de todas as atividades que a equipe
está envolvida, permite também o acompanhamento real de quais tarefas estão sendo
executadas e por quem. Neste quadro estão todas as histórias (requisitos) do Sprint Backlog.
Na Figura 2 tem-se um modelo de Task Board.
Figura 2 – Task Board
Fonte: FABIO CRUZ, 2013.
Diariamente a equipe atualiza o Burndown Charts e realiza a Daly Scrum onde são
tratados os impedimentos pelo Scrum Master e é possível ter uma previsão de atraso ou
avanço das funcionalidades desenvolvidas. Todos os artefatos e informações das
funcionalidades são registrados no redmine e os documentos de especificação são
armazenados em um repositório de dados, recomenda-se uso do SVN por permitir a iteração
com o redmine e rastreabilidade das informações.
A sprint finaliza quando as funcionalidades previstas estiverem prontas dentro do
tempo previsto da Sprint. É então realizada a Sprint Review para aprovação do que foi feito e
a Sprint Retrospective que tem a finalidade de catalogar os dados do andamento de cada
9
Sprint e assim poder ter um histórico de todas as informações do projeto servindo como base
de conhecimento.
Inicia-se portando uma nova Sprint com um novo Sprint Backlog e o fluxo segue até
que todas as Sprints sejam finalizadas e o projeto esteja pronto com um produto funcional e
aprovado pelo Product Owner.
3.2 PROPOSTA DEADAPTAÇÃO DAS ETAPAS DO PROCESSO
Baseado no ciclo de desenvolvimento iterativo e incremental do Scrum chegou-se a
um processo composto por três etapas: Pregame, Game e Postgame. Para cada etapa do novo
processo serão descritos as atividades, objetivos, artefatos os marcos de entrada e saída que
caracteriza cada etapa.
Etapa PREGAME: Tem como ponto de entrada o Product Backlog coletado e
organizado pelo Product Owner, seus principais objetivos são definir o escopo do projeto a
partir do Product Backlog, analisar a viabilidade de prazo e custo e por fim elencar os riscos
do projeto. A partir das avaliações iniciais é elaborado o documento de visão do produto que
por sua vez deve conter informações de infraestrutura, arquitetura do software, tecnologia
entre outras, dentro do documento de visão também deve conter informações do cronograma
do projeto com suas Sprints, o plano de gerenciamento de dados e o orçamento do projeto.
Etapa GAME: Se caracteriza pela produção das funcionalidades do Product Backlog,
tem como objetivo principal organizar as Sprints juntamente com as funcionalidades do Sprint
Backlog e criar releases funcionais do software. Esta etapa se inicia com as reuniões de Sprint
Planning 1 e Sprint Planning 2. Na Sprint Planning 1 são levantados os dados que estão na
base de conhecimento para ajudar nas análises dos itens do Product Backlog , equipe e
Product Owner realizam a priorização e escolha dos itens do Product Backlog que irão
compor o Sprint. A equipe faz uso da técnica de Story Points combinado com Planning Poker
para realizar a análise de tempo de cada item do Sprint Backlog. Na Sprint Planning 2 a
equipe juntamente com o Scrum Master geram as atividades que irão compor o Task Board e
registra-las também no redmine no projeto e Sprint devidamente configurados.
Na sequencia é executada a Sprint, ou seja, é realizado desenvolvimento das tarefas do
Sprint Backlog e ao final da Sprint é possível ter um produto incompleto, porém parcialmente
funcional, permitindo a entrega de uma versão incremental potencialmente utilizável do
produto, em outras palavras, um pacote entregue é um pacote que pode ser utilizado em
produção gerando valor imediato para os interessados. E equipe registra diariamente no
10
redmine todos os passos que foram realizados em cada atividade, atualiza as referidas
atividades no Task Board, atualiza o Burndown Charts, armazena os artefatos gerados no
repositório e realiza a Daily Scrum juntamente com o Scrum Master, nesta reunião são
avaliadas as atividades que são e serão desenvolvidas por cada membro da equipe juntamente,
o Scrum Master analisa o desempenho e a evolução da Sprint e avalia e elimina os
impedimentos e os registra em um documento chamado de Impediment Backlog.
O Scrum Master trabalha monitorando as atividades e o progresso da equipe e principalmente
gerenciando os impedimentos encontrados de modo que não afetem a equipe.
Etapa POSTGAME: Após o desenvolvimento das atividades da Sprint, é necessária a
avaliação e aprovação do que foi feito pelo cliente, no nosso caso o Product Owner, isto é
feito na reunião chamada Sprint Review Meeting. Além da aprovação também são avaliados
alguns dados por toda a equipe tais como: desempenho da equipe, meta alcançada, velocidade
da equipe, os impedimentos que foram encontrados, análise das funcionalidades entregues
com possíveis observações de adaptações esta reunião se chamada Sprint Retrospective
Meeting. Ao final da Sprint Retrospective Meeting o Scrum Master cataloga as informações
em uma base de conhecimento que pode servir para projetos futuros.
Ao final desta etapa o Product Backlog pode ser atualizado, repriorizado e uma nova
Sprint pode ser iniciada caso não seja a última, voltando para a etapa Game. Na Figura 3
temos uma visão geral de todo o processo.
Figura 3 – Fluxo da Proposta Adaptada
Fonte: Dados da Pesquisa
11
4. VALIDAÇÃO DA ADERÊNCIA AO MPS.BR NIVEL G
Para cada área de processo do MPS.BR nível G foi realizada uma validação entre os
resultados esperados e as práticas do modelo adaptado, pode-se verificar que com as
adaptações e ferramentas adotadas todos os resultados esperados podem ser alcançados. Para
um melhor entendimento e validação da proposta os artefatos gerados e as atividades
desenvolvidas durante as etapas do processo foram referenciados segundo os resultados
esperados pelos processos de cada área.
Na etapa Pregame são gerados os seguintes artefatos: documento de visão que contêm
informações de cronograma do projeto com suas sprints, informações do plano de
gerenciamento de dados e informações sobre o orçamento. Também é formado e organizado o
Product Backlog, estes artefatos podem ser usados para alcançar os resultados esperados nos
processos GPR1, GPR3, GPR4, GPR5, GPR7, GPR8, GPR9, GPR10, GPR14, GRE1 e
GRE3.
Na etapa Game são gerados os seguintes artefatos: Sprint Backlog, Task Board,
Impediment Backlog e o Burndown Charts, também são realizadas as seguintes atividades:
Sprint Planning 1 e 2 e Daily Scrum e uso de Planning Pocker e Story Points para realizar as
estimativas, tais artefatos e atividades podem ser usados para alcançar os resultados esperados
nos processos GPR2, GPR3, GPR4, GPR5, GPR6, GPR10, GPR11, GPR12, GPR13, GPR14,
GPR16, GPR17, GRE2, GRE3, GRE4, GRE5.
Na etapa Postgame são realizadas as seguintes atividades: Sprint Review Meeting e
Sprint Retrospective Meeting que podem ser usados para alcançar os resultados esperados nos
processos GPR3, GPR4, GPR12, GPR13, GPR14, GPR15, GPR17 e GRE4.
Durante todas as etapas são utilizadas técnicas para apoiar o processo como, por
exemplo, os registros no redmine que é feito durante todas as etapas, o conjunto de atividades
e o modo iterativo e incremental baseado no Scrum juntamente com os perfis e
responsabilidades do processo são características fundamentais para validação da aderência.
Para uma melhor compreensão dos processos e validações de cada resultado, foram
detalhados os resultados esperados de cada processo juntamente com as referências da
proposta de processo elencando também as etapas que contemplam o resultado. O resultado
deste mapeamento detalhado pode ser observado no Quadro 4.
12
Quadro 4 – Mapeamento MPS.Br nível G
MPS.BR – Nível G Práticas Compatíveis
GESTÃODEPROJETOS(GPR)
Sigla Objetivos
Proposta Adaptada
Etapas
GPR1 Escopo do trabalho Pregame Elaboração da Visão do Produto e Definição dos Itens de Backlog (IBL).
GPR2
As tarefas e os produtos de trabalho
do projeto são dimensionados
utilizando métodos apropriados
Game Uso da técnica Story Points com Planning Poker.
GPR3 O modelo e as fases do ciclo de
vida do projeto são definidos
Pregame
Game
Postgame
Iterativo incremental. Fases: Pregame, Game e Postgame.
GPR4
Estimativa de esforço e o custo
baseado em dados históricos ou
referências técnicas
Pregame
Game
Postgame
Dados armazenados no Redmine: custo, documentações técnicas, detalhes da
funcionalidade e referências de todos os projetos.
GPR5
O orçamento e o cronograma do
projeto, incluindo a definição de
marcos e pontos de controle
Pregame
Game
O cronograma é estabelecido pela quantidade de Sprints definida na reunião de
Planejamento da Versão para Entrega. As Sprints são os pontos de controle,
acompanhamento através do Task Board, Burndown Charts e Daily Scrum e
também através por meio de milestones, versões e campos personalizados do
redmine. Orçamento do projeto é definido com base no cronograma e na
estimativa de custos e é acompanhado ao longo das Sprints. Tanto orçamento
quanto o cronograma são evidenciados no Documento de Visão.
GPR6 Riscos do projeto são identificados
e documentados
Game
Daily Scrum, listas de impedimentos registradas no Redmine e
responsabilidades do Scrum Master
GPR7 Planejamento de recursos humanos Pregame
Definição dos Recursos humanos (Time, Product Owner, Scrum Master)
baseado no perfil definidos no documento de visão.
GPR8 Planejamento das tarefas, os
recursos e o ambiente de trabalho
Pregame
Product Backlog e documento de visão. O ScrumMaster é responsável por
garantir os recursos necessários para o desempenho das atividades do Team,
registrando no documento de Visão a infraestrutura necessária para o
desenvolvimento do projeto.
GPR9
Planejamento de dados relevantes
do projeto. (armazenamento,
privacidade e segurança)
Pregame
Plano de dados definido junto com o documento de visão, onde cita a estrutura
de pastas do produto no repositório, estrutura dos documentos relevantes ao
desenvolvimento e a política de acesso conforme os perfis estabelecidos.
GPR10 Planos para a execução do projeto
Pregame
Game
Visão do Produto, registro do projeto no redmine, Product Backlog, Sprint
Backlog, Sprint planning e Daily Scrum
GPR11
A viabilidade de atingir as metas do
projeto, considerando as restrições e
os recursos disponíveis, é avaliada.
Game
Sprint Planning, Sprint Backlog, Task Board, acompanhamento da evolução
pelo Redmine e Daily Scrum
GPR12
O Plano do Projeto é revisado com
todos os interessados e o
compromisso com ele é obtido
Game
Postgame
Sprint Planning , Daily Scrum e Sprint Review .
GPR13 Monitoramento do progresso do
projeto
Game
Postgame
Burndown Charts , Daily Scrum, Sprint Retrospective Meeting, Task Board e
Sprint Review Meeting
GPR14 Gerenciamento do envolvimento
das partes interessadas no projeto
Pregame
Game
Postgame
Documento de Visão e todas as demais cerimônias do Scrum
GPR15
Revisões são realizadas em marcos
do projeto e conforme estabelecido
no planejamento
Postgame Sprint Review Meeting
GPR16
Identificação e registros de
problemas tratados com as partes
interessadas
Game Daily Scrum, Impediment Backlog
GPR17 Ações para corrigir e prevenir
desvios em relação ao planejado
Game
Postgame
Daily Scrum, Impediment Backlog e Retrospective Meeting
13
GERENCIAMENTODEREQUISITOS(GRE)
Sigla Objetivos Proposta Adaptada
GRE1 Entendimento dos requisitos
Pregame
Game
Visão do produto, Definição de itens de Backlog e Elaboração das tarefas da
Sprint, Task Board e registro dos requisitos via Redmine
GRE2 Comprometimento da equipe com a
aprovação dos requisitos
Game
Aprovação e Priorização de requisitos através do Product Owner , Sprint
Planning e Daily Scrum
GRE3
A rastreabilidade bidirecional entre
os requisitos e os produtos de
trabalho
Pregame
Game
Postgame
Registro de tarefas (histórias) via Redmine, rastreabilidade de artefatos através
dos campos personalizados da ferramenta. Mapeamento de documentos através
de Tags via repositório (Subversion) de versão.
GRE4
Revisões em planos e produtos
de trabalho do projeto
Game
Postgame
Daily Scrum Meeting e Sprint Review Meeting
GRE5
Gerenciamento de mudanças
nos requisitos
Game
Postgame
Sprint Planning, Daily Scrum Meeting e Sprint Review Meeting
Fonte: Dados da Pesquisa
5. CONCLUSÃO
Concluímos que com a adaptação e incorporação de algumas práticas, ferramentas e
artefatos, oriundas do Scrum, é possível chegar a um conjunto de atividades que visam
auxiliar à aderência ao nível G do MPS.Br e também servir como base inicial para melhoria
na qualidade de processos de desenvolvimento de software.
Foi possível também concluir que o conjunto de práticas do Scrum já oferece um bom
nível de aderência aos resultados esperados do nível G do MPS.Br, ou seja , para as áreas de
processo de Gestão de Projetos e Gerenciamento de Requisitos, e a adoção desta metodologia
já é um bom ponto de partida para alcançar um nível desejado de maturidade.
14
REFERENCIAS
AGILE ALLIANCE 2002. Agile Manifesto, http://www.agilealliance.org
Bassi, Dairton - Gestão de projetos em Scrum, USP – Universidade de São Paulo, Janeiro,
2010. Disponível em: http://www.agilcoop.org.br/files/AgilCoop-Verao10-Scrum.pdf. Acesso
em: 11/04/2013.
COUTO, A. B.; CMMI – Integração dos Modelos de Capacitação e Maturidade de
Sistemas. Ed. Ciência Moderna. Rio de Janeiro, 2007.
CRUZ, FABIO - Os 4 passos para gerenciar Riscos em Reuniões Diárias, 2013.
Disponível em: http://www.fabiocruz.com/os-4-passos-para-riscos-e-reunioes-diarias/. Acesso
em 10/10/2013.
GLOGER, B. The Zen of Scrum. Disponível em: http://www.glogerconsulting.de. Acesso
em março de 2007.
Mapas mentais para concursos de TI – MPS.BR, Novembro 2013. Disponível em
http://mapaseconcursosdeti.blogspot.com.br/2012/11/mps-br.html. Acesso em 13/06/2012.
MARTINS, José Carlos Cordeiro. Técnicas para gerenciamento de projetos de software.
São Paulo: Editora Brasport, 2007b.
[MPS.BR, 2012] –SOFTEX. MPS.BR – Guia Geral, versão 2012, Agosto de 2012.
Disponível em: www.softex.br. Acesso em: 15/03/2013.
[MPS.BR, 2011] – Guia de Implementação – Parte 2: Fundamentação para Implementação
do Nível F do MPS.BR , versão 1.1, junho 2007. Disponível em: www.softex.br. Acesso em:
15/03/2013.
REDMINE, Ferramenta para gerenciamento de projetos ágeis. Disponível em:
www.redmine.org. Acesso em 01/09/2013.
SANTANA, C. A.; TIMÓTEO, A. L.; VASCONCELOS, A. M. L.. Mapeamento do modelo
de Melhoria do Processo de Software Brasileiro (MPS.BR) para empresas que utilizam
Extreme Programming (XP) como metodologia de desenvolvimento. Disponível em:
<bibliotecadigital.sbc.org.br/download.php?paper=973>. Acesso em: 01 de julho de 2013
SOMMERVILLE (2003) - I. Engenharia de Software. Editora Addison-Wesley. 592p,
2003.
SCHWABER, K. Agile Project Management with Scrum, Microsoft Press, 2008.
SZIMANSKI, FERNANDO; FURTADO, FELIPE; ALBUQUERQUE, JONES - Extensão do
Scrum segundo o MPS.BR nível G. Engenharia de Software - Magazine, edição. 26, ano. 3,
p. 7-14, 2010 .

Mais conteúdo relacionado

Mais procurados

Agile Scrum Presentation-Detailed
Agile Scrum Presentation-DetailedAgile Scrum Presentation-Detailed
Agile Scrum Presentation-Detailed
Prashaanth T R
 
Gestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasGestão de Projetos de TI em Empresas
Gestão de Projetos de TI em Empresas
Camilo Almendra
 

Mais procurados (20)

Mapa Mental Scrum
Mapa Mental ScrumMapa Mental Scrum
Mapa Mental Scrum
 
Оценка задач выполняемых по итеративной разработке
Оценка задач выполняемых по итеративной разработкеОценка задач выполняемых по итеративной разработке
Оценка задач выполняемых по итеративной разработке
 
Ciclo de Vida Clássico da Engenharia de Software
Ciclo de Vida Clássico da Engenharia de SoftwareCiclo de Vida Clássico da Engenharia de Software
Ciclo de Vida Clássico da Engenharia de Software
 
[MoT SP #1] PRISMA para Testes Baseados em Risco
[MoT SP #1] PRISMA para Testes Baseados em Risco[MoT SP #1] PRISMA para Testes Baseados em Risco
[MoT SP #1] PRISMA para Testes Baseados em Risco
 
Qualidade de Software - Introdução
Qualidade de Software - Introdução Qualidade de Software - Introdução
Qualidade de Software - Introdução
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Agile Scrum Presentation-Detailed
Agile Scrum Presentation-DetailedAgile Scrum Presentation-Detailed
Agile Scrum Presentation-Detailed
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Gestão de Projetos de TI em Empresas
Gestão de Projetos de TI em EmpresasGestão de Projetos de TI em Empresas
Gestão de Projetos de TI em Empresas
 
Modelo V
Modelo VModelo V
Modelo V
 
Modelo plano de_testes
Modelo plano de_testesModelo plano de_testes
Modelo plano de_testes
 
Modelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de SoftwareModelo Incremental - Engenharia de Software
Modelo Incremental - Engenharia de Software
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
Ferramentas open source para auxiliar os testes de software
Ferramentas open source para auxiliar os testes de softwareFerramentas open source para auxiliar os testes de software
Ferramentas open source para auxiliar os testes de software
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
Ciclo desenvolvimento de sistemas
Ciclo desenvolvimento de sistemasCiclo desenvolvimento de sistemas
Ciclo desenvolvimento de sistemas
 
Curso Treinamento Automação de testes com Selenium Qualister
Curso Treinamento Automação de testes com Selenium QualisterCurso Treinamento Automação de testes com Selenium Qualister
Curso Treinamento Automação de testes com Selenium Qualister
 
Metodologias de desenvolvimento - Waterfall vs Agile
Metodologias de desenvolvimento - Waterfall vs AgileMetodologias de desenvolvimento - Waterfall vs Agile
Metodologias de desenvolvimento - Waterfall vs Agile
 
Diagramas de componentes
Diagramas de componentesDiagramas de componentes
Diagramas de componentes
 
Conceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidadeConceitos e fundamentos sobre testes de software e garantia da qualidade
Conceitos e fundamentos sobre testes de software e garantia da qualidade
 

Semelhante a PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G

Engenharia de software apostila analise de requisitos ii
Engenharia de software   apostila analise de requisitos iiEngenharia de software   apostila analise de requisitos ii
Engenharia de software apostila analise de requisitos ii
robinhoct
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiro
ingrid_fatec
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
Frank Coelho
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Raphael Donaire Albino
 
Modelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraModelo de referência e método de avaliação para
Modelo de referência e método de avaliação para
qualityquality
 
Modelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraModelo de referência e método de avaliação para
Modelo de referência e método de avaliação para
qualityquality
 

Semelhante a PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G (20)

Artigo corrigido
Artigo corrigidoArtigo corrigido
Artigo corrigido
 
Artigo
ArtigoArtigo
Artigo
 
Artigo asap - metodologia de gestão de projetos para implementação de pacot...
Artigo   asap - metodologia de gestão de projetos para implementação de pacot...Artigo   asap - metodologia de gestão de projetos para implementação de pacot...
Artigo asap - metodologia de gestão de projetos para implementação de pacot...
 
Artigo23
Artigo23Artigo23
Artigo23
 
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
 
Aplicação das abordagens Scrum e XP
Aplicação das abordagens Scrum e XPAplicação das abordagens Scrum e XP
Aplicação das abordagens Scrum e XP
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2
 
Gerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptxGerenciamento da Qualidade de Software 2.pptx
Gerenciamento da Qualidade de Software 2.pptx
 
Mpsbr
MpsbrMpsbr
Mpsbr
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Engenharia de software apostila analise de requisitos ii
Engenharia de software   apostila analise de requisitos iiEngenharia de software   apostila analise de requisitos ii
Engenharia de software apostila analise de requisitos ii
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiro
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcp
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Cmmi e mps.Br
Cmmi e mps.BrCmmi e mps.Br
Cmmi e mps.Br
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
 
Modelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraModelo de referência e método de avaliação para
Modelo de referência e método de avaliação para
 
Modelo de referência e método de avaliação para
Modelo de referência e método de avaliação paraModelo de referência e método de avaliação para
Modelo de referência e método de avaliação para
 
Erika questionario pt 2 (Eng Software III).
Erika questionario pt  2 (Eng Software III).Erika questionario pt  2 (Eng Software III).
Erika questionario pt 2 (Eng Software III).
 

PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G

  • 1. PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G SILVA JUNIOR, Luiz Navarro1 Curso de Especialização em Engenharia de Software Faculdade Estácio – IDEZ ljrnavarro@gmail.com RESUMO Este artigo tem como objetivo apresentar uma alternativa de adaptação das práticas ágeis da metodologia Scrum com foco na aderência ao nível G do MPS.BR. A partir de um cenário hipotético são apresentadas ferramentas, artefatos e atividades que visam facilitar a obtenção dos resultados. Por fim é realizada uma validação da proposta apresentada e a aderência ao MPS.BR através do mapeamento entre as atividades adaptadas e os resultados esperados pelos processos do nível G. Palavras-chave: Scrum, Mps.br, qualidade de Software, desenvolvimento de Software, processos de software, maturidade de software. ABSTRACT This article aims to introduce a SCRUM methodolody's agile practices' adaptation alternative focusing on the MPS.BR's level G adherence. Tools, artifacts and activities will be presented from a hypothetical scenario, aiming to facilitate the outcomes achievement. Finally, there is a validation of the presented proposal and the MPS.BR adherence through the adapted activities' mapping and the expected outcome by the level G. Key words: Scrum, Mps.br, Software Quality, Software Development, software processes, software maturity. INTRODUÇÃO A população é tão dependente do uso de softwares que alguns autores listam essa dependência como uma das doenças do século 21 (Fernandes, Daniela, 2011). Seja em smartphones, tablets e até em geladeiras e fogões o software definitivamente faz parte da nossa rotina e esse caminho não tem volta, ao contrário tende a evoluir. A tecnologia vem se desenvolvendo de forma extremamente rápida. Coisas que há alguns anos acreditava-se que levariam décadas para serem reais, atualmente são comuns. Apesar de todo esse avanço tecnológico, todos os dias surgem novas tecnologias e mesmo diante deste cenário dinâmico o desenvolvimento de softwares ainda enfrenta muitos desafios. 1 Aluno do Curso de Especialização em Engenharia de Software. Turma 2012.1. Trabalho de Conclusão de Curso.
  • 2. 2 A busca pela qualidade de produtos de software bem como a redução de custos e tempo são metas obrigatórias nas pequenas e médias empresas que desenvolvem. Ao final dos anos 90 os processos tradicionais já não acompanhava a demanda tecnológica, começaram então a surgir as primeiras metodologias de processos ágeis como: Adaptive Software Development, , eXtreme Programming (XP), Feature Driven Development (FDD) e Scrum. Surgiram também os frameworks de qualidade os quais oferecem coleções de diretrizes para melhoria de processos dentro das organizações de todos os ramos e não apenas ligadas a tecnologia. Alguns modelos medem o nível de maturidade dos processos e certificam às organizações que atingem e que atendem os requisitos de qualidade desejados, os principais modelos são: CMMI e MPS.BR. A união dos conceitos e práticas ágeis com as diretrizes dos modelos de melhoria de processos de qualidade é uma alternativa recente, inovadora e eficaz para obter a melhoria nos processos de desenvolvimento de softwares e assim alcançar qualidade nos produtos finais e consequentemente, aumentar a competitividade no mercado. Portanto, seguindo esta tendência, é objetivo deste trabalho propor uma adaptação de processos do Scrum ao MPS.BR nível g que possa ser usada como facilitador para empresas de desenvolvimento de software que desejam melhorar a qualidade da produção de seus produtos. REFERENCIAL TEÓRICO 1. MPS.BR MPS.BR (Melhoria de Processo de Software Brasileiro) é um modelo de referência, que tem como objetivo melhorar a qualidade nos processos de desenvolvimento de software e para isso tem como proposta resultados simples de serem implementados, é indicado para organizações de pequeno e médio porte cujo poder de investimento nesta área é limitado. (SANTANA, TIMÓTEO & VASCONCELOS). O modelo de referência MPS.BR possui como foco o gerenciamento do processo utilizado pela organização e não determina o modo de como realizar determinadas tarefas, mas enumera as diretrizes que a empresa deve seguir para que se atinja determinado nível de maturidade. Segundo o (Softex, 2013) impulsionar a melhoria da capacidade de desenvolvimento de software e serviços nas empresas brasileiras é uma das metas do programa MPS.BR.
  • 3. 3 O MPS.BR tem seus processos baseados nas normas NBR ISO/IEC 12207, fornece diretrizes para atingir qualidade nas áreas de produção, fornecimento, aquisição e funcionamento de software. O método de avaliação é baseado nas áreas dos processos e tem como base a ISSO/IEC 15504 (COUTO, 2007). O MPS.BR é composto por um conjunto de guias: Guia Geral, que define o modelo de referência de uma forma geral; Guia de Aquisição, descreve os processos que tratam de aquisição de software; Guia de Avaliação fornece as metas para avaliação e Guia de Implementação que define os níveis de maturidade que consequentemente mapeiam a evolução dos processos e classificam estes processos segundo seus requisitos de maturidade, os níveis de maturidade são divididos em sete classificações segundo sua evolução, são estes: A (Em Otimização); B (Gerenciado Quantitativamente); C (Definido); D (Largamente Definido); E (Parcialmente Definido); F (Gerenciado); G (Parcialmente Gerenciado), estes níveis evoluem do nível G ao A segundo a capacidade da organização de atingir os perfis de processos exigidos. O nível G de maturidade, alvo deste estudo, é formado pelos processos de Gerência de Projetos (GPR) que engloba dezessete atividades ligadas a responsabilidades, atividades e manutenção de planos e acompanhamento do andamento do projeto e Gerência de Requisitos (GRE) que por sua vez engloba cinco atividades que buscam divergências entra o planejado e o que está sendo desenvolvido. Estes dois processos atendem respectivamente aos atributos de processo AP 1.1 e AP 2.1. 2. A METODOLOGIA ÁGIL SCRUM Criada em 1996, a metodologia Scrum diferencia-se das outras por ter um foco maior nas pessoas e não em documentações. Tem em sua essência o gerenciamento do projeto como principal objetivo e se concentra em monitorar e ajustar o desenvolvimento do produto conforme as mudanças que eventualmente ocorram durante o processo. O Scrum, segundo Martins (2007b), é totalmente adaptável e empírico, e por ser mais flexível é indicado em projetos susceptíveis a mudanças durante o desenvolvimento do software, ao contrário dos métodos tradicionais caracterizados por serem complexos e engessados. Possui a capacidade de gerar valor para o negócio o mais rápido possível, pois, mesmo com um software ainda incompleto, é possível gerar partes funcionais, ou seja, ter um software com um mínimo de funcionalidades prontas e entregáveis.
  • 4. 4 O Scrum tem como base algumas características de aplicabilidade, entre elas estão: equipes pequenas, requisitos voláteis e ciclos de desenvolvimento curtos. A organização dinâmica e iterativa do Scrum engloba três principais papeis, que estão definidos no Quadro 1. Quadro 1 - Papéis e Responsabilidades no Scrum Papel Responsabilidades Scrum Master Tem a responsabilidade de gerenciar todo o processo do Scrum e fazê-lo ser compreendido, entendido por toda a equipe (Team) e principalmente alinhado aos interesses da organização, é responsável também por solucionar todos os impedimentos durante o decorrer da Sprint. Outra responsabilidade muito relevante é atuar como facilitador entre o Team e o Product Owner. Product Owner Representante dos Stakeholders do projeto, em muitos casos é o próprio cliente do produto e está diretamente focado no retorno sobre o investimento (ROI). Tem também a responsabilidade na priorização e elaboração dos requisitos do Product Backlog e deve estar sempre disponível para o Team e presente durante as cerimonias previstas. Team (Time) Equipe multidisciplinar e com diferentes habilidades técnicas, responsável por transformar os requisitos selecionados (Sprint Backlog) para a iteração em funcionalidades e gerar um produto parcial integrável. O Team tem a autoridade para alocar e priorizar as ações que serão executadas durante a Sprint, em alguns casos essas decisões devem ser decididas em conjunto com o Scrum Master e/ou Product Owner. O Team também deve informar sobre eventuais impedimentos ao Scrum Master. Fonte: Engenharia de Software – Magazine, 2010.
  • 5. 5 O ciclo de desenvolvimento do Scrum é composto por três fases, conforme Quadro 2. Quadro 2 – Fases do Scrum Fase Definição PRE-GAME Esta fase se subdivide em outras duas: Planejamento que tem como objetivo estabelecer um novo release, a visão do projeto, estabelecer prazos e custos. A outra fase que se chama Staging tem como objetivo avaliar as bases para construção do produto, como tipo do sistema, ambiente de desenvolvimento, etc. GAME É a fase de desenvolvimento do release, formada por múltiplas sprints onde temos ao final um conjunto de funcionalidades capaz de tornar um produto parcial e funcional. Durante esta fase sempre devem ser observados prazos, custos e qualidade, através dos artefatos de acompanhamento do Scrum. POST-GAME Fase de fechamento do produto onde ele é finalizado para distribuição. Durante esta fase são realizadas outras atividades como: atividades de integração, análise, documentação do usuário, treinamento e preparação do material de marketing. Fonte: Engenharia de Software – Magazine, 2010. Como toda metodologia de desenvolvimento, no Scrum há alguns artefatos previstos e algumas práticas pré-definidas, conforme Quadro 3. Quadro 3 - Práticas a Artefatos previstas no Scrum Artefatos / Práticas Definição Product Backlog Repositório de características e funcionalidades priorizadas e definidas pelo cliente ou Product Owner no inicio do projeto que pode ser mudado de acordo com o andamento do projeto. Sprint Backlog ou Selected Backlog Lista de funcionalidades selecionadas a partir do Product Backlog para serem desenvolvidas na iteração ou Sprint Sprint Iterações ou ciclos de desenvolvimento onde são desenvolvidos os requisitos escolhidos na Sprint Backlog. Ao final de cada Sprint temos um produto incompleto, porém funcional. Daily Scrum Reuniões diárias que servem para informar o andamento do projeto dentro do Team bem como avaliar impedimentos, o que será e o que foi feito. As reuniões devem durar no máximo 15 minutos. Sprint Planning Meeting São reuniões divididas em duas partes, na primeira o Product Owner prioriza as principais funcionalidades e juntamente com o Team define o que será trabalhado, na segunda parte o Team organiza as funcionalidades e assim monta o Sprint Backlog. Sprint Review Meeting Reunião realizada no final da Sprint onde o Team apresenta o resultado do desenvolvimento na iteração ao Product Owner. Neste momento ainda podem ocorrer adaptações segundo decisão do Product Owner e Team.
  • 6. 6 Sprint Retrospective Meeting Juntamente com o Team o Scrum Master elenca as lições aprendidas durante a Sprint para servir como base de conhecimento, bem como avalia o que pode ser melhorado no processo para a próxima Sprint. Burndown Charts Gráfico que mede a evolução e a velocidade da Sprint, ou seja, possibilita a avaliação continua do progresso do Team em relação à iteração. Mede também a evolução do projeto como um todo. Fonte: Dados da Pesquisa O processo de desenvolvimento Scrum tem como ponto de partida uma visão completa do produto que será desenvolvido (SCHWABER, 2008). A visão contempla a lista de características do produto estabelecidas pelo cliente, além de algumas premissas e restrições. A partir da visão o Product Backlog é formado baseado na lista de requisitos conhecidos. O Product Backlog é então priorizado e dividido em iterações. O fluxo de desenvolvimento detalhado do Scrum é pode ser visualizado na Figura 1. Figura 1 – Ciclo do Scrum Fonte: Disponível em: http://codeauth.blogspot.com.br/2012/11/primeiro-contato-com-Scrum-knowing- Scrum.html. Aceso em 21/09/2013.
  • 7. 7 3. PROPOSTA ADAPTADA DO SCRUM 3.1 CENÁRIO HIPOTÉTICO Para uma melhor compreensão da aplicação das ferramentas e atividades propostas neste artigo, foi idealizado um cenário de uma empresa de tecnologia de desenvolvimento de software que possui as seguintes características básicas: cinquenta clientes, uma equipe multidisciplinar de dez pessoas, três produtos de software cujo suporte é feito totalmente online. No contexto de gestão de projetos de software foram selecionados áreas com base na semelhança das características de domínio, escopo, arquitetura, tempo, custo e equipe. A dinâmica deste cenário se concentra em alguns marcos que serão descritos a seguir juntamente com as ferramentas e artefatos que servirão de apoio à proposta apresentada. O ponto de partida do processo é o registro das necessidades de atendimento ou demandas pelos clientes que é feito através de um sistema online de cadastramento de solicitações, neste sistema devem ser preenchidas as informações da solicitação como: cliente, área de atuação, data de registro e tipo de atendimento, também são gravados todos os logs de troca de informações entre o suporte e o cliente e por fim, permite que o cliente acompanhe em qualquer momento qual a situação da demanda por ele registrada, estas demandas são avaliadas por um Product Owner que os representa dentro da equipe e assume um papel de interface entre a equipe e os anseios do cliente. O Product Owner classifica cada demanda como um atendimento de suporte, uma falha do sistema ou uma solicitação de melhoria, a partir daí começa a ser formado o Product Backlog com todas as demandas desejadas ou falhas registradas no sistema de solicitações, classificadas e priorizadas pelo Product Owner . O Product Backlog é um repositório inicial para o início do projeto e dinâmico ao longo das iterações ou Sprints. Com as funcionalidades cadastradas e priorizadas no Product Backlog o próximo passo é a reunião de planejamento para um novo produto, e todas as decisões são registradas no documento de visão, são avaliados custo e riscos iniciais do projeto, requisitos não funcionais como arquitetura, tecnologia, infraestrutura, é informado também o plano de dados que envolve a estrutura de pastas, segurança e regras de acesso aos dados do projeto, deve conter também o cronograma do projeto que por sua vez deve informar quantas Sprints estão previstas como também a previsão de conclusão do projeto, recomenda-se um prazo de quinze dias para cada iteração. As informações e características do projeto, após definidas, são devidamente configuradas no redmine. O Redmine é uma ferramenta de gerenciamento de projetos que,
  • 8. 8 entre outras funcionalidades, permite registrar as atividades de desenvolvimento de software pelo time e o acompanhamento de vários aspectos do projeto, é flexível ao ponto de possibilitar vários tipos de dados como: Sprints planejadas, tempo de desenvolvimento de cada atividade, usuários da equipe e seus papéis juntamente com os níveis de acesso. A equipe e o Scrum Master definem os itens do Product Backlog que farão parte das Sprints, ou seja, os itens do Sprint Backlog e posteriormente a equipe faz as estimativas de cada funcionalidade levando em conta o que realmente será possível desenvolver alinhado com as prioridades. Inicia-se, por conseguinte o desenvolvimento das funcionalidades divididas entre as Sprints e para isso se faz necessário à composição do Task Board, que tem o objetivo de facilitar o gerenciamento, pelo Scrum Master e equipe, de todas as atividades que a equipe está envolvida, permite também o acompanhamento real de quais tarefas estão sendo executadas e por quem. Neste quadro estão todas as histórias (requisitos) do Sprint Backlog. Na Figura 2 tem-se um modelo de Task Board. Figura 2 – Task Board Fonte: FABIO CRUZ, 2013. Diariamente a equipe atualiza o Burndown Charts e realiza a Daly Scrum onde são tratados os impedimentos pelo Scrum Master e é possível ter uma previsão de atraso ou avanço das funcionalidades desenvolvidas. Todos os artefatos e informações das funcionalidades são registrados no redmine e os documentos de especificação são armazenados em um repositório de dados, recomenda-se uso do SVN por permitir a iteração com o redmine e rastreabilidade das informações. A sprint finaliza quando as funcionalidades previstas estiverem prontas dentro do tempo previsto da Sprint. É então realizada a Sprint Review para aprovação do que foi feito e a Sprint Retrospective que tem a finalidade de catalogar os dados do andamento de cada
  • 9. 9 Sprint e assim poder ter um histórico de todas as informações do projeto servindo como base de conhecimento. Inicia-se portando uma nova Sprint com um novo Sprint Backlog e o fluxo segue até que todas as Sprints sejam finalizadas e o projeto esteja pronto com um produto funcional e aprovado pelo Product Owner. 3.2 PROPOSTA DEADAPTAÇÃO DAS ETAPAS DO PROCESSO Baseado no ciclo de desenvolvimento iterativo e incremental do Scrum chegou-se a um processo composto por três etapas: Pregame, Game e Postgame. Para cada etapa do novo processo serão descritos as atividades, objetivos, artefatos os marcos de entrada e saída que caracteriza cada etapa. Etapa PREGAME: Tem como ponto de entrada o Product Backlog coletado e organizado pelo Product Owner, seus principais objetivos são definir o escopo do projeto a partir do Product Backlog, analisar a viabilidade de prazo e custo e por fim elencar os riscos do projeto. A partir das avaliações iniciais é elaborado o documento de visão do produto que por sua vez deve conter informações de infraestrutura, arquitetura do software, tecnologia entre outras, dentro do documento de visão também deve conter informações do cronograma do projeto com suas Sprints, o plano de gerenciamento de dados e o orçamento do projeto. Etapa GAME: Se caracteriza pela produção das funcionalidades do Product Backlog, tem como objetivo principal organizar as Sprints juntamente com as funcionalidades do Sprint Backlog e criar releases funcionais do software. Esta etapa se inicia com as reuniões de Sprint Planning 1 e Sprint Planning 2. Na Sprint Planning 1 são levantados os dados que estão na base de conhecimento para ajudar nas análises dos itens do Product Backlog , equipe e Product Owner realizam a priorização e escolha dos itens do Product Backlog que irão compor o Sprint. A equipe faz uso da técnica de Story Points combinado com Planning Poker para realizar a análise de tempo de cada item do Sprint Backlog. Na Sprint Planning 2 a equipe juntamente com o Scrum Master geram as atividades que irão compor o Task Board e registra-las também no redmine no projeto e Sprint devidamente configurados. Na sequencia é executada a Sprint, ou seja, é realizado desenvolvimento das tarefas do Sprint Backlog e ao final da Sprint é possível ter um produto incompleto, porém parcialmente funcional, permitindo a entrega de uma versão incremental potencialmente utilizável do produto, em outras palavras, um pacote entregue é um pacote que pode ser utilizado em produção gerando valor imediato para os interessados. E equipe registra diariamente no
  • 10. 10 redmine todos os passos que foram realizados em cada atividade, atualiza as referidas atividades no Task Board, atualiza o Burndown Charts, armazena os artefatos gerados no repositório e realiza a Daily Scrum juntamente com o Scrum Master, nesta reunião são avaliadas as atividades que são e serão desenvolvidas por cada membro da equipe juntamente, o Scrum Master analisa o desempenho e a evolução da Sprint e avalia e elimina os impedimentos e os registra em um documento chamado de Impediment Backlog. O Scrum Master trabalha monitorando as atividades e o progresso da equipe e principalmente gerenciando os impedimentos encontrados de modo que não afetem a equipe. Etapa POSTGAME: Após o desenvolvimento das atividades da Sprint, é necessária a avaliação e aprovação do que foi feito pelo cliente, no nosso caso o Product Owner, isto é feito na reunião chamada Sprint Review Meeting. Além da aprovação também são avaliados alguns dados por toda a equipe tais como: desempenho da equipe, meta alcançada, velocidade da equipe, os impedimentos que foram encontrados, análise das funcionalidades entregues com possíveis observações de adaptações esta reunião se chamada Sprint Retrospective Meeting. Ao final da Sprint Retrospective Meeting o Scrum Master cataloga as informações em uma base de conhecimento que pode servir para projetos futuros. Ao final desta etapa o Product Backlog pode ser atualizado, repriorizado e uma nova Sprint pode ser iniciada caso não seja a última, voltando para a etapa Game. Na Figura 3 temos uma visão geral de todo o processo. Figura 3 – Fluxo da Proposta Adaptada Fonte: Dados da Pesquisa
  • 11. 11 4. VALIDAÇÃO DA ADERÊNCIA AO MPS.BR NIVEL G Para cada área de processo do MPS.BR nível G foi realizada uma validação entre os resultados esperados e as práticas do modelo adaptado, pode-se verificar que com as adaptações e ferramentas adotadas todos os resultados esperados podem ser alcançados. Para um melhor entendimento e validação da proposta os artefatos gerados e as atividades desenvolvidas durante as etapas do processo foram referenciados segundo os resultados esperados pelos processos de cada área. Na etapa Pregame são gerados os seguintes artefatos: documento de visão que contêm informações de cronograma do projeto com suas sprints, informações do plano de gerenciamento de dados e informações sobre o orçamento. Também é formado e organizado o Product Backlog, estes artefatos podem ser usados para alcançar os resultados esperados nos processos GPR1, GPR3, GPR4, GPR5, GPR7, GPR8, GPR9, GPR10, GPR14, GRE1 e GRE3. Na etapa Game são gerados os seguintes artefatos: Sprint Backlog, Task Board, Impediment Backlog e o Burndown Charts, também são realizadas as seguintes atividades: Sprint Planning 1 e 2 e Daily Scrum e uso de Planning Pocker e Story Points para realizar as estimativas, tais artefatos e atividades podem ser usados para alcançar os resultados esperados nos processos GPR2, GPR3, GPR4, GPR5, GPR6, GPR10, GPR11, GPR12, GPR13, GPR14, GPR16, GPR17, GRE2, GRE3, GRE4, GRE5. Na etapa Postgame são realizadas as seguintes atividades: Sprint Review Meeting e Sprint Retrospective Meeting que podem ser usados para alcançar os resultados esperados nos processos GPR3, GPR4, GPR12, GPR13, GPR14, GPR15, GPR17 e GRE4. Durante todas as etapas são utilizadas técnicas para apoiar o processo como, por exemplo, os registros no redmine que é feito durante todas as etapas, o conjunto de atividades e o modo iterativo e incremental baseado no Scrum juntamente com os perfis e responsabilidades do processo são características fundamentais para validação da aderência. Para uma melhor compreensão dos processos e validações de cada resultado, foram detalhados os resultados esperados de cada processo juntamente com as referências da proposta de processo elencando também as etapas que contemplam o resultado. O resultado deste mapeamento detalhado pode ser observado no Quadro 4.
  • 12. 12 Quadro 4 – Mapeamento MPS.Br nível G MPS.BR – Nível G Práticas Compatíveis GESTÃODEPROJETOS(GPR) Sigla Objetivos Proposta Adaptada Etapas GPR1 Escopo do trabalho Pregame Elaboração da Visão do Produto e Definição dos Itens de Backlog (IBL). GPR2 As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados Game Uso da técnica Story Points com Planning Poker. GPR3 O modelo e as fases do ciclo de vida do projeto são definidos Pregame Game Postgame Iterativo incremental. Fases: Pregame, Game e Postgame. GPR4 Estimativa de esforço e o custo baseado em dados históricos ou referências técnicas Pregame Game Postgame Dados armazenados no Redmine: custo, documentações técnicas, detalhes da funcionalidade e referências de todos os projetos. GPR5 O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle Pregame Game O cronograma é estabelecido pela quantidade de Sprints definida na reunião de Planejamento da Versão para Entrega. As Sprints são os pontos de controle, acompanhamento através do Task Board, Burndown Charts e Daily Scrum e também através por meio de milestones, versões e campos personalizados do redmine. Orçamento do projeto é definido com base no cronograma e na estimativa de custos e é acompanhado ao longo das Sprints. Tanto orçamento quanto o cronograma são evidenciados no Documento de Visão. GPR6 Riscos do projeto são identificados e documentados Game Daily Scrum, listas de impedimentos registradas no Redmine e responsabilidades do Scrum Master GPR7 Planejamento de recursos humanos Pregame Definição dos Recursos humanos (Time, Product Owner, Scrum Master) baseado no perfil definidos no documento de visão. GPR8 Planejamento das tarefas, os recursos e o ambiente de trabalho Pregame Product Backlog e documento de visão. O ScrumMaster é responsável por garantir os recursos necessários para o desempenho das atividades do Team, registrando no documento de Visão a infraestrutura necessária para o desenvolvimento do projeto. GPR9 Planejamento de dados relevantes do projeto. (armazenamento, privacidade e segurança) Pregame Plano de dados definido junto com o documento de visão, onde cita a estrutura de pastas do produto no repositório, estrutura dos documentos relevantes ao desenvolvimento e a política de acesso conforme os perfis estabelecidos. GPR10 Planos para a execução do projeto Pregame Game Visão do Produto, registro do projeto no redmine, Product Backlog, Sprint Backlog, Sprint planning e Daily Scrum GPR11 A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Game Sprint Planning, Sprint Backlog, Task Board, acompanhamento da evolução pelo Redmine e Daily Scrum GPR12 O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido Game Postgame Sprint Planning , Daily Scrum e Sprint Review . GPR13 Monitoramento do progresso do projeto Game Postgame Burndown Charts , Daily Scrum, Sprint Retrospective Meeting, Task Board e Sprint Review Meeting GPR14 Gerenciamento do envolvimento das partes interessadas no projeto Pregame Game Postgame Documento de Visão e todas as demais cerimônias do Scrum GPR15 Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento Postgame Sprint Review Meeting GPR16 Identificação e registros de problemas tratados com as partes interessadas Game Daily Scrum, Impediment Backlog GPR17 Ações para corrigir e prevenir desvios em relação ao planejado Game Postgame Daily Scrum, Impediment Backlog e Retrospective Meeting
  • 13. 13 GERENCIAMENTODEREQUISITOS(GRE) Sigla Objetivos Proposta Adaptada GRE1 Entendimento dos requisitos Pregame Game Visão do produto, Definição de itens de Backlog e Elaboração das tarefas da Sprint, Task Board e registro dos requisitos via Redmine GRE2 Comprometimento da equipe com a aprovação dos requisitos Game Aprovação e Priorização de requisitos através do Product Owner , Sprint Planning e Daily Scrum GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho Pregame Game Postgame Registro de tarefas (histórias) via Redmine, rastreabilidade de artefatos através dos campos personalizados da ferramenta. Mapeamento de documentos através de Tags via repositório (Subversion) de versão. GRE4 Revisões em planos e produtos de trabalho do projeto Game Postgame Daily Scrum Meeting e Sprint Review Meeting GRE5 Gerenciamento de mudanças nos requisitos Game Postgame Sprint Planning, Daily Scrum Meeting e Sprint Review Meeting Fonte: Dados da Pesquisa 5. CONCLUSÃO Concluímos que com a adaptação e incorporação de algumas práticas, ferramentas e artefatos, oriundas do Scrum, é possível chegar a um conjunto de atividades que visam auxiliar à aderência ao nível G do MPS.Br e também servir como base inicial para melhoria na qualidade de processos de desenvolvimento de software. Foi possível também concluir que o conjunto de práticas do Scrum já oferece um bom nível de aderência aos resultados esperados do nível G do MPS.Br, ou seja , para as áreas de processo de Gestão de Projetos e Gerenciamento de Requisitos, e a adoção desta metodologia já é um bom ponto de partida para alcançar um nível desejado de maturidade.
  • 14. 14 REFERENCIAS AGILE ALLIANCE 2002. Agile Manifesto, http://www.agilealliance.org Bassi, Dairton - Gestão de projetos em Scrum, USP – Universidade de São Paulo, Janeiro, 2010. Disponível em: http://www.agilcoop.org.br/files/AgilCoop-Verao10-Scrum.pdf. Acesso em: 11/04/2013. COUTO, A. B.; CMMI – Integração dos Modelos de Capacitação e Maturidade de Sistemas. Ed. Ciência Moderna. Rio de Janeiro, 2007. CRUZ, FABIO - Os 4 passos para gerenciar Riscos em Reuniões Diárias, 2013. Disponível em: http://www.fabiocruz.com/os-4-passos-para-riscos-e-reunioes-diarias/. Acesso em 10/10/2013. GLOGER, B. The Zen of Scrum. Disponível em: http://www.glogerconsulting.de. Acesso em março de 2007. Mapas mentais para concursos de TI – MPS.BR, Novembro 2013. Disponível em http://mapaseconcursosdeti.blogspot.com.br/2012/11/mps-br.html. Acesso em 13/06/2012. MARTINS, José Carlos Cordeiro. Técnicas para gerenciamento de projetos de software. São Paulo: Editora Brasport, 2007b. [MPS.BR, 2012] –SOFTEX. MPS.BR – Guia Geral, versão 2012, Agosto de 2012. Disponível em: www.softex.br. Acesso em: 15/03/2013. [MPS.BR, 2011] – Guia de Implementação – Parte 2: Fundamentação para Implementação do Nível F do MPS.BR , versão 1.1, junho 2007. Disponível em: www.softex.br. Acesso em: 15/03/2013. REDMINE, Ferramenta para gerenciamento de projetos ágeis. Disponível em: www.redmine.org. Acesso em 01/09/2013. SANTANA, C. A.; TIMÓTEO, A. L.; VASCONCELOS, A. M. L.. Mapeamento do modelo de Melhoria do Processo de Software Brasileiro (MPS.BR) para empresas que utilizam Extreme Programming (XP) como metodologia de desenvolvimento. Disponível em: <bibliotecadigital.sbc.org.br/download.php?paper=973>. Acesso em: 01 de julho de 2013 SOMMERVILLE (2003) - I. Engenharia de Software. Editora Addison-Wesley. 592p, 2003. SCHWABER, K. Agile Project Management with Scrum, Microsoft Press, 2008. SZIMANSKI, FERNANDO; FURTADO, FELIPE; ALBUQUERQUE, JONES - Extensão do Scrum segundo o MPS.BR nível G. Engenharia de Software - Magazine, edição. 26, ano. 3, p. 7-14, 2010 .