CENTRO UNIVERSITÁRIO UNISEB
TRABALHO DE CONCLUSÃO DE CURSO
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
Análise do uso das metodologias SCRUM e MPS.BR no estudo de caso
real no desenvolvimento de aplicações comerciais
Aluno: Mateus Henrique Mancine
Orientador: Prof. Ms Thiago Wellington Joazeiro de Almeida
RIBEIRÃO PRETO
2011
ii
MATEUS HENRIQUE MANCINE
Análise do uso das metodologias SCRUM e MPS.BR no estudo de caso
real no desenvolvimento de aplicações comerciais
Trabalho de conclusão de curso - Centro
Universitário UNISEB – Ribeirão Preto –
Bacharelado em Ciência da Computação
Orientador:
Prof
Joazeiro de Almeida
RIBEIRÃO PRETO
2011
Ms Thiago Wellington
iii
Ficha Catalográfica
M268a
1.
Mancine, Mateus Henrique.
Analise do uso das metodologias Scrum e Mps,br no estudo de
caso real no desenvolvimento de aplicações comerciais. Mateus
Henrique Mancine. - Ribeirão Preto, 2011.
27 f., il..
Orientador: Prof. Me. Thiago Wellington Joazeiro de Almeida.
Trabalho de conclusão de curso apresentado ao Centro
Universitário UNISEB de Ribeirão Preto, como parte dos
requisitos para obtenção do Grau de Bacharel em Ciência da
Computação sob a orientação do Prof. Me. Thiago Wellington
Joazeiro de Almeida.
1. Scrum com Mps,br. 2. caso real. 3. Aplicações comerciais.
I. Título. II. Almeida, Thiago Wellington Joazeiro de.
CDD 005.74
iv
Para meu amigo Emerson que foi de grande
importância para a realização deste trabalho.
v
Agradeço a Deus por ter colocado pessoas que
durante o curso me apoiaram e incentivaram em
momentos de desânimo e por capacitar-me para
realização deste trabalho.
vi
“Se o Senhor não edificar a casa, em vão trabalham os que a edificam...”
(Salmos 127:1)
vii
RESUMO
O número de organizações que buscam melhores resultados no desenvolvimento
de software por processos de produção e estrutura organizacional cresce a cada dia,
algumas dessas empresas de desenvolvimento de software já utilizam modelos
internacionais de qualidade em busca dessa melhoria, entretanto, a aplicação destes
modelos é cara e complexa.
Com a finalidade de aprimorar o processo de desenvolvimento de software no
Brasil, a SOFTEX elaborou o modelo MPS.BR, cujo objetivo é atender pequenas e
médias empresas, sendo uma ótima alternativa dentre as metodologias de melhoramento
de processos de desenvolvimento de software.
Outra metodologia muito aplicada é o SCRUM, que tem o propósito de agilizar
o desenvolvimento de software e possibilitar a entrega de projetos, de forma a atender
os requisitos de maior valor agregado ao cliente.
No Brasil, uma prática utilizada é a adoção das duas metodologias, SCRUM e o
MPS.BR, que em conjunto buscam a agilidade no desenvolvimento mantendo um
processo mapeado, garantindo assim, a qualidade no produto entregue ao cliente.
Neste trabalho foi realizado a análise sobre o uso da metodologia SCRUM junto
com o MPS.BR na gestão do desenvolvimento de softwares em uma empresa privada na
cidade de Ribeirão Preto.
viii
ABSTRACT
The number of organizations that looks for better results in the software
development applied for production processes and organizational structure grows every
day, some of these software development companies already use international models
for quality improvement, and the application of these models is expensive and complex.
In order to improve the process of software development in Brazil, SOFTEX
developed the model called MPS.BR, which aims to assist small and medium
enterprises, becoming a great alternative between methodologies for improving software
development processes. Another method applied is SCRUM, which aims to speed up the
software development and enable the delivery of projects to meet the requirements of
higher added value to the customer.
In Brazil, the common use is the adoption of the two methodologies, SCRUM
and MPS.BR together, which seek to maintain an agile development process mapped,
thus ensuring the quality of the delivered product.
In this work, it will be fulfilled an analysis about applying SCRUM together
MPS.BR methodologies at the software development management at private company
placed at Ribeirão Preto city.
ix
LISTA DE ABREVIATURAS E SIGLAS
BID – Banco Interamericano de Desenvolvimento.
CMMI – Capability Maturity Model Integration.
FINEP – Financiadora de Estudos e Projetos.
GPR – Gerência de Projetos.
GRE – Gerência de Requisitos.
MCT – Ministério de Ciência e Tecnologia.
MPS.BR – Melhoria de Processos do Software Brasileiro.
SEBRAE – Serviço Brasileiro de Apoio às Micro e Pequenas Empresas.
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro.
x
SUMÁRIO
1.
Introdução ................................................................................................................. 1
2.
Fundamentos Teóricos .............................................................................................. 3
2.1.
MPS.BR – Melhoria de Processo de Software Brasileiro.................................. 3
2.2.
Nível G de maturidade do MPS.BR................................................................... 6
2.2.1.
Processo de gerencia de projetos - GPR ..................................................... 6
2.2.2.
Processo de gerencia de requisitos - GRE .................................................. 8
2.3.
3.
SCRUM ............................................................................................................. 9
2.1.1.
Papéis do SCRUM.................................................................................... 10
2.1.2.
Time-Boxes............................................................................................... 12
2.1.3.
Product Backlog ....................................................................................... 14
2.1.4.
Sprint Backlog .......................................................................................... 14
Estudo de Caso ....................................................................................................... 16
3.1.
A Empresa........................................................................................................ 16
3.2.
Metodologia ..................................................................................................... 17
3.2.1.
Questionário Sobre MPS.BR.................................................................... 17
3.2.2.
Questionário Sobre SCRUM .................................................................... 19
3.3.
Analise ............................................................................................................. 21
4.
Conclusão ............................................................................................................... 25
5.
Referências ............................................................................................................. 27
1
1. Introdução
A indústria do software criou nos últimos anos alguns padrões e processos no
desenvolvimento de software que possibilitou gerar um produto final com mais
qualidade. E com isso a Engenharia de Software ganhou o seu espaço em todas as
empresas que atuam com desenvolvimento de novos softwares. Através desta
engenharia é possível adotar modelos e definir como será todo o desenvolvimento do
software detalhando cada fase e cada recurso necessário. O quão efetivo e eficiente será
a adoção de modelos, dependerá da maturidade da equipe e do conhecimento sobre a
metodologia. Para isso algumas empresas têm analisado e discutido junto com suas
equipes métricas que possam analisar se um determinado procedimento ou metodologia
tem gerado algum efeito sobre a produtividade e qualidade do software.
De acordo com Neto (2010), a empresa de software que deseja sobreviver no
mercado atualmente deve perseguir continuamente metas de qualidade em seus projetos.
Hoje existem grandes empresas e órgãos governamentais criando critérios de pontuação
técnica em suas licitações para favorecer fornecedores com certificados de qualidade em
seus processos de produção.
Cada vez mais, empresas e organizações necessitam de produtos com qualidade,
livres de erros e com soluções imediatas. Para atender a esta demanda, empresas de
software visam, em seus projetos, o aumento da confiabilidade, o menor número de
conflitos e a redução dos custos, resultando em maior satisfação do cliente (Santesso,
2009).
No mundo empresarial, em qualquer seguimento, a competitividade levantada
pela qualidade impulsiona não só os resultados na forma dos produtos oferecidos, como
também a produção por meio de processos. Nas empresas de software isso se reflete
perfeitamente na qualidade dos produtos, processos e distribuição (Neto, 2010).
A qualidade de software passou a representar um requisito básico e não mais um
fator diferencial, logo as buscas pela adoção de processos de qualidade se tornam
imprescindíveis, com as definições atuais de modelos de qualidade foi criado o MPS.BR
(Melhoria de Processo de Software Brasileiro) que adota as definições sugeridas pelo
CMMI, mas busca reduzir a formalidade exagerada (Teixeira, 2007).
2
Neste trabalho o objetivo será analisar as práticas do SCRUM junto ao processo
de gerência e desenvolvimento do MPS.BR, aplicado em uma empresa brasileira,
utilizando o melhor de cada metodologia, com a finalidade de melhorar constantemente
o seu processo de desenvolvimento de software sem perder a agilidade de entrega.
Através da análise de dados reais, serão apresentados os benefícios obtidos na
utilização desse conjunto de modelos, demonstrando as melhorias alcançadas na
maturidade da empresa no desenvolvimento de software. A técnica utilizada para
obtenção desses dados é a entrevista.
Neste trabalho será mostrado como uma empresa, que é uma das maiores
empresas de âmbito nacional no seguimento de desenvolvimento e manutenção de
software administrativo, cujo nível de manutenção é considerável alto, vem aplicando o
nível de maturidade do MPS.BR junto ao método ágil SCRUM, seguindo seus conceitos
e práticas com a finalidade de melhorar o seu processo de desenvolvimento de software,
entregando seus produtos de forma rápida e com um alto padrão de qualidade.
3
2. Fundamentos Teóricos
2.1. MPS.BR – Melhoria de Processo de Software Brasileiro
De acordo com a SOFTEX (2011), o objetivo do MPS.BR é:
“O MPS.BR tem como objetivo disseminar o Modelo de Referência para
Melhoria do Processo de Software visando estabelecer um caminho
economicamente viável para que organizações, incluindo as pequenas e médias
empresas, alcancem os benefícios da melhoria de processos e da utilização de
boas práticas da engenharia de software em um intervalo de tempo razoável.”
Surge então, em dezembro de 2003, o MPS.BR, coordenado pela Associação
para Promoção da Excelência do Software Brasileiro (SOFTEX) apoiado pelo
Ministério da Ciência e Tecnologia (MCT), Serviço Brasileiro de Apoio às Micro e
Pequenas empresas (SEBRAE), Banco Interamericano de Desenvolvimento (BID) e
pela Financiadora de Estudos e Projetos (FINEP) (SOFTEX,2011).
Segundo a (SOFTEX, 2011) a mudança nos negócios motiva as empresas de
desenvolvimento de software a melhorar as estruturas organizacionais e os processos de
produção, buscando alcançar competividade pela qualidade dos produtos e serviços.
Como em vários outros setores, a qualidade é um diferencial que influência
diretamente no sucesso das empresas de software, assim, para ter um produto
competitivo no mercado nacional ou internacional é imprescindível manter a busca pela
eficiência dos processos de desenvolvimento, ofertando produtos com padrões de
qualidade internacional (SOFTEX, 2011).
O modelo MPS.BR busca se adequar ao perfil de empresas dos mais diferentes
tamanhos, independente de serem empresas públicas ou privadas, a SOFTEX busca
também que o seu modelo seja compatível com padrões de qualidades internacionais.
Santesso (Santesso, 2009) descreve o MPS.BR como um modelo de referência
que visa atingir maior qualidade no processo de desenvolvimento de software,
principalmente em organizações com recursos limitados para investimento em
qualidade. Este modelo não define novos conceitos, apenas adequa as estratégias de
implementação à realidade brasileira.
4
O MPS.BR tem como base os princípios de engenharia de software, como
processos definidos e modelos de melhorias de processos, o modelo se baseia em
conceitos de maturidade e na capacidade do processo de desenvolvimento para avaliar a
melhoria da qualidade da produção dos produtos de software e serviços relacionados
(SOFTEX,2011).
A maturidade do modelo MPS.BR é representada por patamares de evolução.
São divididos em sete níveis com o objetivo de possibilitar a implementação e avaliação
mais adequada a cada empresa, possibilitando vislumbrar os resultados das melhorias
dos processos em prazos mais curtos.
Estando em um determinado nível de maturidade, uma empresa consegue prever
quais os esforços futuros para conseguir um nível de maturidade mais elevado, assim
facilitando o foco nas melhorias dos seus processos.
Segundo (Neto, 2010) o modelo de maturidade do MPS.BR é semelhante ao
modelo do CMMI, entretanto com um número maior de níveis de maturidade, com mais
estágios, é possível se adequar melhor a realidade brasileira, resultando em avaliações
em prazos mais curtos.
A SOFTEX define os sete níveis de maturidade do MPS.BR como:
• A - Em Otimização
• B - Gerenciado Quantitativamente
• C - Definido
• D - Largamente Definido
• E - Parcialmente Definido
• F - Gerenciado
• G - Parcialmente Gerenciado
5
Figura 01 – Níveis de maturidade do MPS.Br
O nível G é o primeiro nível na escala de maturidade cuja progressão vai até o
nível A (SOFTEX,2011).
A SOFTEX apresenta no guia, quais os processos devem ser atendidos em cada
nível de maturidade.
Segue abaixo os processos por cada nível segundo a (SOFTEX, 2011):
Nível A
Otimização dos processos
Nível B
Gerência de Projetos – GPR (evolução)
Nível C
Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
Nível D
Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
6
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
Nível E
Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP
Nível F
Medição – MED
Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
Nível G
Gerência de Requisitos – GRE
Gerência de Projetos – GPR
2.2. Nível G de maturidade do MPS.BR
Este trabalho abordará o nível G de maturidade, composto por: Gerência de
Projeto - GPR e Gerência de Requisitos - GRE.
2.2.1.1. Processo de gerencia de projetos - GPR
O processo de Gerência de Projetos segundo a (SOFTEX,2011) é estabelecer e
manter definições de atividades, recursos e responsabilidades para um projeto, prover
informações sobre o andamento do projeto para eventuais correções do projeto e este
processo evolui de acordo com o nível de maturidade.
7
Uma das atividades prevista para o GPR é implementar um plano de controle de
determinado projeto para obter o comprometimento e mantê-lo durante sua execução.
Teixeira (Teixeira, 2007) cita em seu trabalho que o GPR pode ser comparado ao
processo de construção de uma casa, pois o processo de tal construção inicia-se com
atividades que passam desde a preparação do terreno até a própria construção,
posteriormente estas atividades são dividas em tarefas menores o que simplifica a
construção. Com isso espera-se um melhor entendimento de cada tarefa e
consequentemente um resultado mais satisfatório.
Os resultados esperados segundo a (SOFTEX, 2011) para o GPR no nível de
maturidade G do MPS.BR são:
GPR 1. O escopo do trabalho para o projeto é definido;
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados
utilizando métodos apropriados;
GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos;
GPR 4. (Até o nível F) O esforço e o custo para a execução das tarefas e dos
produtos de trabalho são estimados com base em dados históricos ou referências
técnicas;
GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos
e pontos de controle, são estabelecidos e mantidos;
GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de
ocorrência e prioridade de tratamento são determinados e documentados;
GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil
e o conhecimento necessários para executá-lo;
GPR 8. (Até o nível F) Os recursos e o ambiente de trabalhos necessários para
executar o projeto são planejados;
GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à
forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido
para acessá-los, incluindo, se pertinente, questões de privacidade e segurança;
GPR 10. Um plano geral para a execução do projeto é estabelecido com a
integração de planos específicos;
8
GPR 11. A viabilidade de atingir as metas do projeto é explicitamente avaliada
considerando restrições e recursos disponíveis. Se necessário, ajustes são
realizados;
GPR 12. O Plano do Projeto é revisado com todos os interessados e o
compromisso com ele é obtido e mantido;
GPR 13. O escopo, as tarefas, as estimativas, o orçamento e o cronograma do
projeto são monitorados em relação ao planejado;
GPR 14. Os recursos materiais e humanos bem como os dados relevantes do
projeto são monitorados em relação ao planejado;
GPR 15. Os riscos são monitorados em relação ao planejado;
GPR 16. O envolvimento das partes interessadas no projeto é planejado,
monitorado e mantido;
GPR 17. Revisões são realizadas em marcos do projeto e conforme estabelecido
no planejamento;
GPR 18. Registros de problemas identificados e o resultado da análise de
questões pertinentes, incluindo dependências críticas, são estabelecidos e
tratados com as partes interessadas;
GPR 19. Ações para corrigir desvios em relação ao planejado e para prevenir a
repetição dos problemas identificados são estabelecidas, implementadas e
acompanhadas até a sua conclusão;
2.2.2. Processo de gerencia de requisitos - GRE
O processo de Gerência de Requisitos segundo a (SOFTEX, 2011) tem o
objetivo de gerenciar os requisitos de um determinado projeto e identificar problemas
destes requisitos.
Teixeira (Teixeira, 2007) cita que o requisito é uma definição documentada que
uma particularidade ou comportamento de um produto de software ou serviço deve
atender para chegar a um objetivo. Gerenciamento de requisitos é o ato de entender e
gerenciar as mudanças. Estes requisitos devem ser descritos de forma a estabelecer um
consenso entre as partes, buscando o correto entendimento das funcionalidades do
produto ou serviço.
9
Os resultados esperados segundo a (SOFTEX, 2011) para o GRE no nível de
maturidade G do MPS.BR são:
GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de
requisitos;
GRE 2. Os requisitos são avaliados com base em critérios objetivos e um
comprometimento da equipe técnica com estes requisitos é obtido;
GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de
trabalho é estabelecida e mantida;
GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas
visando identificar e corrigir inconsistências em relação aos requisitos;
GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
2.3. SCRUM
O SCRUM foi idealizado com o intuito de gerenciar o processo de produção em
fábricas de automóveis japoneses (Nonaka, 1986). Este artigo diz que pequenas equipes
multidisciplinares alcançam melhores resultados, uma alusão ao SCRUM do Rugby
para referenciar as reuniões de equipes adaptáveis.
A jogada do Rugby denominada de SCRUM tem o objetivo de reunir os
jogadores para planejar a próxima jogada, dividindo assim a partida em partes menores
para atingir o objetivo maior que é ganhar o jogo.
Em 1995, Jeff Sutherland e Ken Schwaber descreveram o SCRUM como um
framework para o desenvolvimento de software. Entretanto, o SCRUM é considerado
um processo incremental e iterativo para qualquer tipo de trabalho, cuja finalidade é
aperfeiçoar o andamento de um projeto através de seu processo muito bem definido.
Suas principais características são a sua adaptabilidade e seu empirismo (Neto, 2010).
O SCRUM por ser empírico busca analisar os resultados dos processos visando
corrigi-los se necessário, mas aceita falhas que são naturais de produção, procurando
exibi-las o mais rápido possível (SANTESSO, 2009).
10
Segundo o SCRUM.ORG (2010), o SCRUM é um processo e sim um
framework onde são encontrados diversas técnicas e processos.
Segundo o SCRUM.ORG (2010), é dito que:
“O papel do SCRUM é fazer transparecer a eficácia relativa das suas
práticas de desenvolvimento para que você possa melhorá-las, enquanto
provê um framework dentro do qual produtos complexos podem ser
desenvolvidos.
“
Fundamentado na teoria de controle de processos empíricos, o SCRUM se
sustenta em três pilares (SCRUM.ORG, 2010) que estão descritos abaixo:
• Transparência
Através da transparência pode-se assegurar que as características de um processo
que afetem o resultado ficam visíveis para os administradores dos resultados.
Entretanto estas características não devem ser apenas transparentes, mas também
conhecidas, ou seja, quando alguém inspeciona algo que está correto, o que foi
julgado como correto deve estar de acordo com a definição de correto.
• Inspeção
As características de um processo devem ser inspecionadas frequentemente para
que uma eventual variação deste processo seja detectada.
• Adaptação
Caso o responsável pelas inspeções constatar que existem aspectos do processo
que estão fora dos padrões e o produto final não será aceitável, o processo é
ajustado rapidamente para evitar problemas posteriores.
2.1.1. Papéis do SCRUM
O Framework SCRUM é formado por times onde cada membro possui um
papel, os papéis são: o time de SCRUM, ScrumMaster e Product Owner. Informalmente
denominam-se os membros do time de SCRUM de “porcos” e qualquer outra pessoa é
denominada de “galinha”. Tais “galinhas” não podem interferir no trabalho dos
11
“porcos”, segundo o SCRUM.ORG (2010). Os “porcos” e “galinhas” vem da seguinte
estória:
“Uma galinha e um porco estão juntos quando a galinha diz: “Vamos abrir um
restaurante!” O porco reflete e então diz: “Como seria o nome desse
restaurante?” A galinha diz: “Presunto com Ovos!” O porco diz: “Não,
obrigado, eu estaria comprometido, mas você estaria apenas envolvida!.”
Esta história ilustra o quão importante é o foco da equipe e o comprometimento
para garantir a conclusão de um projeto (Neto, 2010).
2.1.1.1.
Product Owner
O Product Owner representa os interesses de pessoas que investem no projeto, e
também consegue verbas, definem os requisitos do projeto, tais requisitos irão gerar o
Product Backlog (Neto, 2010).
O Product Owner é o único responsável por gerenciar Product Backlog para
garantir o trabalho realizado pelo time. Este membro também tem como
responsabilidade de garantir a visibilidade do Product Backlog para o time e que todos
saibam a prioridade de cada item a se trabalhar. O Product Owner também pode ser um
membro do desenvolvimento do projeto, entretanto nunca pode ser o Scrum Master
(SCRUM.ORG, 2010).
2.1.1.2.
Scrum Master
O Scrum Master tem a responsabilidade de garantir que o time absorva os
valores do SCRUM adotando suas praticas e regras, O ScrumMaster ajuda o Time a ser
auto organizado e multidisciplinar para que o time torne-se mais produtivo e capaz de
desenvolver produtos de melhor qualidade. O ScrumMaster nunca pode ser o Product
Owner (SCRUM.ORG, 2010).
12
2.1.1.3.
Time SCRUM
O time tem o papel de desenvolver o que está descrito no Product Backlog. O
conhecimento de cada membro do time deve ser compartilhado, para o SCRUM o
conhecimento compartilhado é mais importante que o conhecimento não compartilhado.
Recomenda-se que um time seja formado por sete pessoas com a exceção do Scrum
Master e do Product Owner, pois o menor número de pessoas existe menos interação
entre os membros e possivelmente a limitação de conhecimento e consequentemente a
menor produtividade e qualidade do produto, e caso existam mais pessoas no time
existirá a necessidade de uma coordenação maior e mais complexa o que também
prejudica o desenvolvimento do produto (SCRUM.ORG, 2010).
2.1.2. Time-Boxes
O Time-Boxes no SCRUM são todas as atividades realizadas pelo framework,
tais atividades são:
2.1.2.1.
Reunião de planejamento do release
O planejamento do release tem o objetivo planejar e estabelecer metas, prazos e
prioridades para que a organização possa transformar determinado projeto em um
produto da melhor forma possível e alcançar a satisfação do cliente (SCRUM.ORG,
2010).
2.1.2.2.
O Sprint
O Sprint trata-se de uma iteração de duração recomendada de duas semanas.
Durante tal iteração a composição do time e suas metas devem permanecer constantes
até o final da iteração.
13
Os Sprints podem ser cancelados pelo Product Owner, apesar dele poder sofrer
influência das partes interessadas. Recomenda-se o cancelamento do Sprints quando por
alguma causa não faça mais sentido sua continuação, entretanto devido ao curto período
de interação dificilmente isso acontece. Eventualmente quando o cancelamento é feito
todos os itens não realizados no Sprints devem retornar ao Product Backlog
(SCRUM.ORG, 2010).
2.1.2.3.
Reunião de Planejamento do Sprint
A reunião de planejamento do Sprint tem a duração recomendada de quatro horas
para um Sprint de duas semanas.
O objetivo da reunião é planejar quais itens do ao Product Backlog serão feitos
no Sprint.
O Product Owner mostra ao time as prioridades do Product Backlog e o time
decide quais itens são selecionados de acordo com a quantidade de itens que o time
poderá entregar até o termino do Sprint (SCRUM.ORG, 2010).
2.1.2.4.
Revisão do Sprint
Quando é encerrado o Sprint uma reunião de Revisão de Sprint acontece. Essa
reunião tem duração recomendada de duas horas.
Durante esta reunião o Product Owner verifica o que foi ou não feito e o Time
discute quais foram os problemas ocorridos durante o Sprint (SCRUM.ORG, 2010).
2.1.2.5.
Daily Scrum
Diariamente cada o time realiza uma reunião de 15 minutos em pé onde cada
membro do time responde as seguintes perguntas:
1. O que foi feito após a última reunião?
14
2. O que vou fazer até a próxima reunião?
3. Quais foram os problemas encontrados desde a última reunião?
O Scrum Master deve conduzir a reunião para que ela seja breve e que as
“galinhas” não façam parte da Daily Scrum.
A Daily Scrum melhora a comunicação do time, ajuda a tomada rápida de
decisões e faz com que todos os membros do time saibam o que está acontecendo acerca
do Sprint (SCRUM.ORG, 2010).
2.1.3. Product Backlog
Todos os requisitos que devem ser atendidos estão listados no Product Backlog
cujo responsável é o Product Owner. Os requisitos listados são aqueles que inicialmente
são mais conhecidos e atendidos.
O Product Backlog representa o que é necessário para que o produto possa se
desenvolver de forma competitiva, e também é considerado dinâmico, pois sofre
mudanças constantemente devido as mudanças de requisitos de um produto.
A prioridade dos requisitos contidos no Product Backlog é determinada por
riscos e valor das necessidades definidas pelo Product Owner (SCRUM.ORG, 2010).
2.1.4. Sprint Backlog
O Sprint Backlog representa todos os requisitos selecionados do Product
Backlog durante a reunião de planejamento do Sprint, e pode ser considerado como o
“retrato em tempo real” daquilo que o time planejou realizar durante o Sprint
(SCRUM.ORG, 2010).
A figura abaixo exibe resumidamente o ciclo do Scrum, destacando suas fases de
planejamento, ciclos de interação e entrega.
15
Figura 02 – Clico do SCRUM
16
3. Estudo de Caso
3.1. A Empresa
Neste trabalho será analisada uma empresa que vem aplicando o SCRUM e
MPS-BR no dia a dia. Este estudo de caso está relacionado com uma das maiores
empresas de âmbito nacional no segmento de desenvolvimento e manutenção de
software administrativo, neste trabalho, por motivos de confidencialidade, tal empresa
será denominada como Empresa Modelo.
Constatou-se que esta empresa possui cento e quarenta e um funcionários diretos
e cinco representantes comerciais, os quais estão estabelecidos em diversas regiões do
país, sendo que alguns destes também realizam trabalhos técnicos, através do suporte e
atendimento aos seus clientes.
Esta empresa atua em vários Estados da Federação e conta com um total de cento
e trinta e dois clientes, sendo que a maioria destes possui mais de um produto instalado
e em alguns casos todos.
Os produtos da empresa modelo têm como foco a administração dos dados de
seus clientes, através da integração das informações processadas em cada produto, onde
o resultado gerado por um normalmente é a entrada para outro realizar o seu
processamento. Para os casos de clientes que possuem mais de um fornecedor de
software administrativo, a interligação das informações também é realizada, mas não de
uma forma tão eficiente como mencionado anteriormente, devido às divergências
existentes nas características dos produtos de cada fornecedor.
17
3.2. Metodologia
Um questionário foi elaborado e aplicado à diretoria da empresa, ao gerente de
projetos e aos analistas de sistemas. Através deste questionário, uma análise será feita
para entender quais foram os ganhos reais na implementação do SCRUM e do MPS.BR.
O MPS.BR foi implementado no nível G e é utilizado para os processos de
implantação de sistemas, conforme já relatado. Pretende-se com a análise dos resultados
obtidos, relatar os pontos positivos e negativos, bem como propor sugestões para a
implementação do modelo em uma organização. O mesmo procedimento de
questionário e levantamentos de pontos e sugestões também foi aplicado para o
SCRUM.
3.2.1. Questionário Sobre MPS.BR
1. O que motivou a empresa a investir na implantação do MPS.BR Nível G?
2. Como era definido o escopo dos projetos antes da implantação do MPS.BR?
3. Como o escopo de um projeto de implantação é definido hoje após a implantação
do MPS.BR? Existem modelos a serem seguidos?
4. Sabe-se que não existiam métodos adequados para mensurar o tamanho de um
projeto, hoje, após a definição do escopo de um projeto existem métodos
apropriados para definir as tarefas e dimensionar um projeto?
5. Quais controles para cronogramas e pontos de controles de projetos foram
implementados para evitar gargalos e elevação do orçamento do projeto?
6. Como são identificados os riscos do projeto? Existe a gestão de tais riscos?
Como são definidos os impactos e probabilidades dos riscos?
18
7. Sabendo que cada produto da empresa possui uma equipe com colaboradores
fixos, como é feita a gestão dos recursos humanos em diferentes projetos de
implantação?
8. Existe estrutura de armazenamento dos dados do projeto? Como é feira a
distribuição destes dados? Quem é responsável por definir as questões de
segurança?
9. Como é monitorado o projeto do ponto de vista de cumprimento de prazos
considerando restrições encontradas durante o projeto?
10. Os clientes participam de revisões de projetos? De qual forma?
11. Como são gerenciadas as expectativas dos clientes durante o projeto?
12. Sabendo-se que ações corretivas devem ser implementadas para corrigir um
problema, como é feito o monitoramento dos riscos para que se evite que os
riscos vem a ocorrer? Existem padrões de ações a serem tomadas?
13. Como é obtido o comprometimento da equipe para um projeto?
14. Existe um mecanismo que permita rastrear a interdependência de requisitos e o
impacto de mudanças dos requisitos? Explique.
15. Como são tratadas as mudanças de requisitos durante o projeto? Existem
ferramentas que registram as necessidades de mudanças?
16. Quais a principais dificuldades encontradas durante gerencia do projeto?
19
17. Quais foram os ganhos obtidos após a implantação da gerencia de projeto
estabelecida pelo MPS.BR?
18. Quais a principais dificuldades encontradas durante gerencia de requisitos?
19. Quais foram os ganhos obtidos após a implantação da gerencia de requisitos
estabelecida pelo MPS.BR?
3.2.2. Questionário Sobre SCRUM
1. O que motivou a empresa a investir na implantação do framework SCRUM?
2. Todas as equipes sejam elas de qualquer área da empresa utilizam o SCRUM?
Por quê?
3. O SCRUM utilizado pela empresa segue todas as recomendações do Guia Geral
do SCRUM?
4. Sabe-se que o SCRUM é um processo empírico, desta forma como são feitas a
analise de resultados obtidos? As falhas no produto são exibidas para que a
correção seja feita o mais rápido possível?
5. Sabemos que para um administrador necessita que exista transparência nos
processos e resultados, de qual forma o SCRUM contribuiu para que tal
transparência existisse?
20
6. O processo de manutenção de software é inspecionado frequentemente para
evitar eventuais variações do processo? Como isso é feito?
7. Eventualmente caso seja detectado uma falha no processo de manutenção que
impedirá que o software seja aceitável no fim do ciclo de manutenção o
processo é ajustado para que o produto seja entregue de forma aceitável? De que
forma são feitas as adaptações no processo?
8. Podemos dizer que todos os membros das equipes que utilizam o SCRUM são
comprometidos com o processo?
9. Existe o papel do Product Owner? Como é feita a gerencia do Product Backlog?
10. Sabemos que as equipes que utilizam os SCRUM tem uma pessoa como
ScrumMaster, tal pessoa busca deixar sua equipe multidisciplinar a fim de
melhorar a produtividade e a qualidade dos produtos?
11. O ProductOwner participa das reuniões de planejamento de Sprint ou tal tarefa
foi atribuída à outra pessoa? Por quê?
12. São realizadas Reuniões de revisões de Sprint? Quando uma equipe não
consegue cumprir todas as tarefas selecionadas para o Sprint o que é feito?
13. São feitas reuniões diárias entre as equipes? Como são realizadas tais reuniões?
14. Quais as dificuldades encontradas para implantar o SCRUM na empresa?
15. Quais os ganhos encontrados após a implantação do SCRUM?
21
3.3. Analise
Ao receber as respostas dos questionários, foram feitas análises das respostas com o
objetivo de entender a evolução da gestão do desenvolvimento de software bem como
os efeitos gerados em cima da produtividade e gestão do desenvolvimento de software
comparando-as com os procedimentos executados antes da implantação de tais
metodologias, com isto pode-se constatar que:
Antes da implantação do MPS.BR a empresa não possuía processos definidos de
desenvolvimento de software, os papéis de cada indivíduo não eram claros e não existia
a garantia de padronizações em seus produtos. Com o aumento no quadro de
funcionários e ampliação da carteira de clientes, a empresa percebeu a necessidade da
criação e certificação de processos.
Dentre as várias metodologias disponíveis no mercado foi escolhido o MPS.BR
pelas seguintes motivações:
- Menor custo de implantação se comparado com demais já existentes no
mercado;
- Possibilidade de implantar o modelo em conjunto com outras empresas da
região possibilitando assim a diminuição dos custos;
- Subsídios do governo através da SOFTEX;
Para a implantação do MPS.BR a empresa criou um modelo de processo de
definição de escopo de projeto, o modelo fica a critério da empresa para nível G do
MPS.BR, e segundo o gerente de projetos o processo é simples e tem muito a ser
melhorado, mas o mais importante é que o processo está padronizado.
Após a definição do escopo, o projeto é mensurado, foi criado um método para
estimar o tamanho do projeto baseado nas funcionalidades do produto, tal método segue
os seguintes passos:
- Elencar as funcionalidades que sofrerão manutenção e/ou desenvolvimento;
- Determinar o nível de complexidade da funcionalidade como baixa, média, ou
alta. Para realizar a classificação das funcionalidades foi criada uma planilha de cálculo
22
onde são determinadas algumas características da funcionalidade, como número de
relacionamentos, números de campos, número de quebra para relatórios, etc., e a
planilha se encarrega de apontar o nível de complexidade. A empresa se preocupa em
dizer que a planilha foi construída baseando-se na experiência dos responsáveis de cada
setor de desenvolvimento. Hoje o uso é facultativo, e é mais utilizada para
colaboradores iniciantes.
Sabendo que o nível G não exige planos de contingências ou processos mais
aperfeiçoados de gestão de risco a empresa passou a fazer uma gestão simples dos riscos
dos projetos, existe apenas um repositório com os principais riscos que possam vir a
ocorrer nos projetos e algumas ações preventivas e corretivas que facilite o gerente de
projetos no levantamento e acompanhamento dos riscos.
Existe uma particularidade na gestão de recursos humanos, a empresa possui
vários produtos e cada um destes produtos possui equipes distintas. Na maioria dos
projetos são implantados todos os produtos, e de acordo com a complexidade do
projeto, definida no levantamento prévio, os técnicos necessários para cada atividade,
como, treinamento, conversão, customização, implantação e acompanhamento, os
recursos selecionados, passam a ser coordenados pelo Gerente do Projeto, e não mais
pelos seus coordenadores, e ao término do projeto o colaborador retorna ao setor de
origem, e para obter-se o comprometimento de todos é realizada a reunião de kick-off e
recebem uma cópia do plano de projeto.
O nível G do MPS.BR exige a presença de uma estrutura de armazenamento dos
dados do projeto, para atender tal exigência a empresa criou um repositório restrito com
os principais artefatos do projeto. É um repositório único, com os produtos, onde é
controlado o acesso pelo nível de usuário.
Os prazos de entregas dos projetos são definidos nos editais de licitações, e em
cada ponto de controle e marco acompanha-se o cumprimento das atividades. Em
situações em que os prazos não são cumpridos, podem-se incluir mais recursos no
projeto, ou em último caso, a empresa negocia um prazo mais adequado com o cliente.
Em todos os projetos da empresa os clientes aprovam o plano de projeto logo
após a conclusão do planejamento, e somente após a aprovação inicia-se a fase de
23
execução. Mas existe um plano específico para gerenciar as expectativas, entretanto,
especifica-se no plano de projeto itens como prazo, restrições, escopo e não escopo.
A empresa também conta com uma ferramenta interna onde estão todos os
requisitos dos produtos e suas interdependências, em tal ferramenta registra-se as
mudanças, o processo da empresa, as mudanças passam por uma análise, aprovação e
aceitação.
Durante a implantação do MPS.BR na questão da gerencia de projetos a empresa
deparou-se com uma grande dificuldade que é a gestão de pessoas, a empresa diz que
seus projetos envolvem em média trinta técnicos, e que grande parte desses técnicos
trabalham no cliente por meses, causando assim um certo desconforto. Além dos
técnicos, têm-se os usuários do cliente, que em média, chegam a quinhentas pessoas.
Já a dificuldade de gerencia de requisitos houve um consenso que a maior
dificuldade são as mudanças constantes dos requisitos. O gerente de projetos da empresa
expressou tal dificuldade citando a seguinte frase:
“andar sobre a água e desenvolver requisitos de sistema é fácil, desde que os
dois estejam congelados”
Após ter finalizado o processo de implantação do MPS.BR pode-se dizer que a
visão do projeto foi o principal ganho, em outras palavras, a empresa conseguiu
padronizar o processo e junto com a padronização, conseguiu identificar falhas. Com os
feedbacks dos projetos, a empresa mudou até a forma vender, aumentando assim o
faturamento.
Quanto à gestão de requisitos, auxiliou muito no planejamento do projeto e
principalmente no controle do mesmo, permitindo especificar claramente quando
começa e quando termina um projeto.
Após a implantação do MPS.BR a empresa percebeu que o modelo atendia os
projetos de implantação, mas na manutenção o mesmo não se encaixava com as
necessidades e históricos da empresa, com isso, membros da empresa participaram de
vários treinamentos de outros processos de gerenciamento, até encontrar um que se
aproximasse às expectativas da empresa, então, a empresa começou a trabalhar com o
SCRUM.
24
Todas as áreas da empresa receberam o treinamento do SCRUM, mas nem todas
as áreas se adaptaram com o modelo, e como a empresa obrigou a utilização do modelo
apenas para o setor de desenvolvimento de software, algumas áreas optaram por não
trabalharem com o SCRUM.
O gerente de projetos da empresa diz que a empresa absorveu apenas algumas
das boas práticas do SCRUM, e fez algumas adaptações, criando assim o modelo ágil da
empresa.
Segundo o processo da empresa, ao final de cada é realizada uma reunião de
encerramento, onde é apresentado os resultado e problemas ocorridos ao longo do ciclo,
juntamente com o plano de ação. E a empresa também busca a transparência de seu
processo através de dois itens, os quadros AGILE RADIATOR e o segundo, as reuniões
de encerramento.
Um dos itens do SCRUM que a empresa não absorveu foi à inspeção do
processo de desenvolvimento, entretanto, a empresa tem previsão de implantação de um
setor de qualidade para 2012, cuja responsabilidade será inspecionar os processos da
empresa, garantindo assim que a empresa esteja trabalhando no padrão dos processos
definidos.
Mesmo não possuindo o setor de qualidade a empresa possui uma equipe
responsável por realizar adaptações ao processo, o EPG (Engineering Process Group), as
solicitações de mudanças no processo são registradas e analisadas pelo grupo e se
pertinentes, são implementadas e disseminada aos envolvidos.
A empresa diz que ainda não pode afirmar que todos os membros das equipes
estão comprometidos com o processo, entretanto, diz que é notável a participação de
todos, mas somente com a implantação do setor de qualidade, poderá ter a dimensão
correta da institucionalização do processo.
Hoje os coordenadores dos setores exercem o papel de PO do produto e a gestão
do Product Backlog é realizada com o auxilio de uma ferramenta interna, onde são
registrados, classificados e ordenados os itens do produto, segundo a empresa o PO é
peça fundamental na passagem do conhecimento à equipe.
25
Já quanto ao Scrum Master, a empresa afirma que cada equipe possui um
membro com este papel, mas, infelizmente não estamos preparados a montar equipes
homogenias e multidisciplinares, mas a intenção da empresa é mudar isso assim que
alcançar uma maior maturidade.
As reuniões diárias não são realizadas conforme descrita no guia do SCRUM, é
tida como opcional e infelizmente algumas equipes não a adotam, mas recebem o
incentivo para realiza-las.
A empresa vê o SCRUM como uma ferramenta fácil de aprender, mas muito
difícil de aplicar, e isso se dá por causa das pessoas, a principal mudança e a mais difícil
é transformar uma equipe formada por especialista com papéis e funções bem definidas
em uma equipe homogenia e multidisciplinar.
Os ganhos obtidos com o SCRUM não foi apenas conseguir agilizar o processo
de desenvolvimento de software, mas o fato da empresa conseguir inserir uma
ferramenta de gestão, onde as equipes se planejam para executar as tarefas do dia-a-dia e
a transparência nos projetos foram os pontos determinantes.
4. Conclusão
Conforme dito por (SANTESSO, 2009) o número de empresas que adotam
metodologias ágeis cresce a cada dia, devido às características de tais metodologias,
entretanto, as metodologias ágeis deixam a desejar no que se diz a respeito de
documentação do projeto, e as duas metodologias se complementam trazendo resultados
satisfatórios.
Pode-se concluir que isso é verdade, pois, no caso real a empresa estudada
conseguiu documentar o seu processo através do MPS.BR, entretanto, precisava agilizar
o processo de desenvolvimento, e tal agilidade foi obtida através das boas práticas do
SCRUM, apesar de ter sido pouco adaptado para atender a realidade da empresa.
A implantação de ambas as metodologias teve momentos de dificuldades, mas
também houveram resultados muito positivos, como melhorias no desenvolvimento
consequentemente a melhoria dos seus produtos, e até na parte comercial da empresa,
conforme relatado.
26
A expectativa da empresa é melhorar cada vez mais o seu processo de
desenvolvimento e subir o nível de maturidade do MPS.BR, o que motiva a realização
de trabalhos futuros, pois futuramente a empresa terá como mensurar o quanto estas
metodologias foram importantes.
27
5. Referências
NETO, Pedro Silva, 2010 - Estudo de caso de um processo de gerenciamento de
projetos de software baseado em métodos ágeis e no modelo MPS.BR
NONAKA, Hirotaka, 1986 - The New Product Development Game, 1986. Disponível
em:
<http://www.sao.corvallis.or.us/drupal/files/The%20New%20New%20Product%20Dev
elopment%20Game.pdf> acessado em 27-ago-2011
SANTESSO, Paul, 2009 - Utilização de Métodos Ágeis SCRUM com MPS.BR de
Nível G
SOFTEX.
Guia
Geral.
2011.
Disponível
em:
<http://www.SOFTEX.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf>
Acessado em 06-Ago-2011.
SCRUM.org
–
Guia
geral.
Disponível
em:
<http://www.SCRUM.org/storage/SCRUMguides/SCRUM%20Guide%20%20PTBR.pdf> Acessado em 27-Ago-2011
TEIXEIRA, Marcelo, 2007 - Uma análise do SCRUM sob a perspectiva do MPSBR
Uma análise do SCRUM sob a perspectiva do MPS.BR