Scrum: o sucesso nos projetos através da Gerência Ágil Objetivos
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO...
-
Upload
juliano-oliveira -
Category
Technology
-
view
11.970 -
download
1
description
Transcript of TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO...
CURSO DE SISTEMAS DE INFORMAÇÃO
Juliano Silva de Oliveira
METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR
Capão da Canoa, junho de 2010.
UNIVERSIDADE DE SANTA CRUZ DO SUL
METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR
Trabalho de conclusão apresentado ao curso de
Sistemas de Informação da Universidade de Santa
Cruz do Sul, para obtenção do título de Bacharel em
Sistemas de Informação.
Orientadora: Prof.ª Daniela Duarte da Silva Bagatini.
Capão da Canoa, junho de 2010.
“In the end, The Love you take
Is equal to The Love you make.”
(The Beatles – The End)
AGRADECIMENTOS
Este é o trabalho que culmina minha passagem pelo curso de Sistemas de Informação,
logo, é impossível não deixar de lembrar que diversas pessoas possibilitaram que eu pudesse
chegar até este ponto.
Agradeço, aos meus familiares – que sempre estiveram do meu lado –, aos meus
colegas – que junto comigo, batalharam por este curso –, aos meus professores – que, a pesar
das longas viagens, sempre estavam dispostos a dar o melhor de si –, e a todos que de forma
direta ou indireta, contribuíram para minha chegada até aqui.
RESUMO
Este trabalho trata do mapeamento entre os processos de Gerência de Requisitos e
Desenvolvimento de Requisitos do Modelo MPS.BR alinhados a metodologia ágil Scrum.
MPS.BR é um modelo de qualidade do processo de software fundamentado em normas e
modelos conceituados, organizado de maneira a facilitar sua implantação por pequenas e
médias empresas de desenvolvimento de software do mercado brasileiro. Scrum é uma
metodologia ágil, amparada nos princípios e valores do Manifesto Ágil. É um framework para
gerenciamento de projetos de desenvolvimento de software, baseado em processos empíricos,
com iterações curtas e entregas rápidas de software pronto.
Os processos de Gerência e Desenvolvimento de Requisitos, do Modelo MPS, foram
mapeados com as práticas Scrum. Alguns resultados esperados dos processos mapeados são
parcialmente ou não satisfeitos pela prática Scrum. Nestes casos, algumas ações podem ser
tomadas no intuito de adicionar características, que não destituem os conceitos básicos de
Scrum, mas que satisfazem os processos do modelo MPS.
ABSTRACT
This paper is about a mapping between MPS.BR model’s Requirements Management and
Requirements Development processes aligned at Scrum Agile Methodology.
MPS.BR is a Process Quality Model based at standards and other models conceptualized,
organized to facilitate its implantation at small and medium software development companies
from Brazilian market. Scrum is an Agile Methodology, based at Agile Manifesto’s principles
and values. It’s a framework for management software development projects, based at
empirical processes, with short iterations and quick delivery of software done.
The MPS.BR model’s Requirements Management and Requirements Development process
were mapped with Scrum practices. Some process expected results mapped are partly or not
satisfied by the Scrum practices. In these cases, some actions can be taken to add features that
not deprive the Scrum basic concepts, but satisfy the MPS model’ processes.
LISTA DE ABREVIATURAS
ABNT Associação Brasileira de Normas Técnicas
AP Atributos de Processo
BP Backlog do Produto
BPV Backlog do Produto para a Versão
BS Backlog da Sprint
BV Bussines Value
CMMI-DEV Software Capability Maturity Model for Development
DRE Processo de Desenvolvimento de Requisitos
GRE Processo de Gerência de Requisitos
IEC International Electrotechnical Commission
ISO International Organization for Standardization
JAD Joint Application Development
MPS.BR Melhoria do Processo de Software Brasileiro
MR-MPS Modelo de Referência do MPS.BR
PCP Processo de Projeto e Construção do Produto
PO Product Owner
RAP Resultados esperados de atributos de processo
ROI Return Of Investiment
RPVE Reunião de Planejamento da Versão para Entrega
SM ScrumMaster
SOFTEX Associação para Promoção da Excelência do Software Brasileiro
SPICE Software Process Improvement and Capability Eternation
TS Time Scrum
VAL Processo de Validação
VER Processo de Verificação
XP Extreme Programming
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................................... 9
2 REQUISITOS DE SOFTWARE ......................................................................................... 11
2.1 Visão geral sobre requisitos .............................................................................................. 11
2.2 Tipos de requisitos ............................................................................................................ 14
2.2.1 Requisitos funcionais ..................................................................................................... 14
2.2.2 Requisitos não funcionais .............................................................................................. 14
2.2.3 Requisitos de domínio ................................................................................................... 16
2.3 Processo de engenharia de requisitos ............................................................................... 16
2.3.1 Estudo de viabilidade..................................................................................................... 17
2.3.2 Elicitação e análise de requisitos ................................................................................... 18
2.3.3 Validação de requisitos .................................................................................................. 19
2.3.4 Gerenciamento de requisitos ......................................................................................... 20
2.4 Requisitos e os modelos MPS.BR e Scrum ...................................................................... 21
3 FRAMEWORK SCRUM .................................................................................................... 22
3.1 Visão geral sobre metodologias ágeis .............................................................................. 23
3.2 Introdução ao Scrum ......................................................................................................... 23
3.2.1 Times Scrum, seus papéis e responsabilidades ............................................................. 24
3.2.2 Eventos .......................................................................................................................... 25
3.2.3 Artefatos ........................................................................................................................ 27
3.2.4 Software Pronto ............................................................................................................. 29
3.3 Fluxo do Scrum ................................................................................................................ 29
4 MODELO MPS.BR ............................................................................................................. 33
4.1 Introdução ao Modelo MPS.BR ....................................................................................... 33
4.2 Base técnica do Modelo MPS.BR .................................................................................... 34
4.3 Estrutura do MR-MPS.BR ................................................................................................ 36
4.3.1 Níveis de maturidade ..................................................................................................... 36
4.3.1.1 Processos .................................................................................................................... 37
4.3.1.2 Capacidades de processos ........................................................................................... 38
4.4 Processo de Gerência de Requisitos ................................................................................. 39
4.4.1 Processo GRE – Propósito ............................................................................................. 40
4.4.2 Processo GRE – Resultados Esperados ......................................................................... 40
4.5 Processo de Desenvolvimento de Requisitos ................................................................... 42
4.5.1 Processo DRE – Propósito ............................................................................................. 43
4.5.2 Processo DRE – Resultados Esperados ......................................................................... 43
5 METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E
DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR .................................. 46
5.1 Mapeamento entre os processos GRE e DRE com Scrum ............................................... 46
5.2 Resultado do mapeamento entre os processos GRE e DRE com Scrum ......................... 51
5.3 Estendendo o Scrum ......................................................................................................... 53
6 APOIO A PRÁTICA DE SCRUM E PROCESSOS DE GERÊNCIA E
DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR .................................. 55
6.1 Dificuldades práticas na implantação do processo GRE .................................................. 56
6.2 Dificuldades práticas relacionadas a requisitos de software ............................................ 57
6.3 Dificuldades práticas relacionadas ao Scrum ................................................................... 58
6.4 Além das limitações de MPS e Scrum ............................................................................. 59
7 CONCLUSÃO ..................................................................................................................... 60
7.1 Trabalhos futuros .............................................................................................................. 61
8 REFERÊNCIAS .................................................................................................................. 62
ANEXO A – Manifesto Ágil - Valores .................................................................................. 65
ANEXO B – Manifesto Ágil - Princípios ............................................................................... 66
ANEXO C – Atributos de Processo - AP 1.1 ......................................................................... 67
ANEXO D – Atributos de Processo - AP 2.1 ......................................................................... 68
ANEXO F – Atributos de Processo - AP 3.1 ......................................................................... 70
ANEXO G – Atributos de Processo - AP 3.2 ......................................................................... 71
9
1 INTRODUÇÃO
A sociedade moderna, formada por indivíduos, luta diariamente contra o acaso e o
caos. O ser humano parece estar sempre caminhando no sentido de buscar uma ordem para o
contexto em que vive, seja pensando a respeito do sentido de sua própria existência ou
buscando administrar os processos existentes de uma maneira mais eficiente e eficaz.
As instituições que compõe a sociedade moderna têm em sua formação estes
indivíduos, logo, a necessidade de ordenar, administrar, aplicar uma forma de trabalho nestas
organizações é inerente ao seu processo de gerenciamento.
Segundo Chiavenato (2000), toda a produção de bens e serviços é realizada dentro de
organizações. Na área da tecnologia da informação, não é diferente, todos os produtos e
serviços, mesmo o de desenvolvimento de software, é realizado por organizações. E elas estão
sob as mesmas regras das demais empresas. Lutam diariamente para sobreviver ao mercado.
Dentre as estratégias utilizadas para serem competitivas, as organizações, desde cedo,
têm focado no controle de seus processos, buscando produzir mais e com mais qualidade, ao
mesmo tempo em que se consome menos. Na história das organizações, existiram diversos
modelos que propiciaram este pensamento, como o Taylorismo, o Fordismo ou o Toyotismo
(CHIAVENATO, 2002).
A indústria do software também tem os seus modelos. Ao entender que, devemos ter
plena consciência dos modelos, devemos entender também, e com muito mais ênfase, os
modelos que hoje estão na vanguarda das gestões organizacionais.
Com isto em mente, a pretensão do presente trabalho é de poder apontar como uma
organização pode melhorar seus produtos, serviços e processos, sob o ponto de vista dos
requisitos de software, usando o modelo MPS.BR juntamente com o modelo de
desenvolvimento ágil Scrum.
Este trabalho será focado nos processos do MPS.BR relacionados a requisitos de
software justamente porque requisitos e Scrum têm um ponto fortemente em comum: o foco
10
em pessoas e as implicações do envolvimento delas no processo de desenvolvimento de
software.
Para tal objetivo, uma visão geral sobre requisitos será apresentada no capítulo dois; o
capítulo três fará uma apresentação das metodologias ágeis e um maior detalhamento do
Scrum; o capítulo quatro mostra o modelo MPS.BR, com um foco maior sobre os processos
de gerência e desenvolvimento de requisitos; o capítulo cinco, é dedicado ao mapeamento,
resultados e análise do uso do Scrum associado aos processos de requisitos do MPS.BR; o
capítulo seis trará considerações a respeito da possibilidade da aplicação prática do assunto
abordado; e por fim as conclusões do trabalho.
11
2 REQUISITOS DE SOFTWARE
Os requisitos são intrínsecos ao processo de desenvolvimento de software, entendê-los
corretamente evita a grande maioria dos problemas que uma aplicação poderá ter. Requisitos
são temas recorrentes em diversos trabalhos acadêmicos. Neste trabalho, para que se possa
compreender o que o modelo MPS.BR e o Scrum apregoam a respeito de requisitos, faz-se
uma abordagem da área apresentando algumas considerações a respeito.
2.1 Visão geral sobre requisitos
Requisitos segundo Parzianello (2009) “são descrições das propriedades necessárias e
suficientes de um produto de software que devem ser atendidas para garantir que se cumpra o
que foi projetado, atendendo as necessidades de seus usuários”. De acordo com Ávila (2007),
requisitos são “o conjunto de necessidades explicitadas pelo cliente que deverão ser atendidas
para solucionar um determinado problema de negócio no qual o cliente faz parte”. Ou ainda,
são necessidades ou expectativas expressas, geralmente, de forma implícita ou obrigatória
(Associação Brasileira de Normas Técnicas – ABNT, 2000).
Podemos entender requisitos como necessidades de um cliente ou usuário que deverão
ser atendidas para solucionar um determinado problema do negócio no qual o cliente faz
parte.
Enxergando o contexto dos requisitos de uma maneira mais ampla, podemos dizer que
eles possuem três focos: negócios, usuários e o software. Os requisitos de usuário dirão o quê
deve ser feito, enquanto que os requisitos de negócio, são elementos que correspondem às
regras do negócio, respondem o porquê algo deve ser feito. E os requisitos de software
mostrarão como a solicitação do usuário será atendida dentro das regras do negócio (figura 1).
Fonte: PARZIANELLO, 2009.
Entender os requisitos é descobrir o que o cliente quer com o sistema
2004, p. 24). Logo, por requisitos abrangerem todas as características importantes do software
que será produzido, a elaboração destes torna
projeto de software.
É na análise de requisitos
apresentado na tabela 1 por Á
requisitos podem aumentar consideravelmente
contrário, a correção, ainda ne
tabela 1).
Tabela 1
% do custo de
desenvolvimento
Análise de Requisitos
Projeto
Codificação teste de unidade
Teste
Validação e Documentação
Manutenção
Fonte: ÁVILA, 2007.
Figura 1 – O Contexto dos Requisitos
ntender os requisitos é descobrir o que o cliente quer com o sistema (
requisitos abrangerem todas as características importantes do software
que será produzido, a elaboração destes torna-se uma das fases mais importan
É na análise de requisitos que boa parte dos erros são introduzidos.
por Ávila (2007), mostram que defeitos não tratados ainda na fase de
requisitos podem aumentar consideravelmente o custo do desenvolvimento do projeto. Ao
contrário, a correção, ainda nesta fase, possui um custo baixo (conforme primeira linha da
Tabela 1 – Cenário Atual de Desenvolvimento
% do custo de esenvolvimento
% dos erros introduzidos
% dos erros encontrados
05 55 18
25 30 10
50
10 10 50
10
05 22
12
(WAZLAWICK,
requisitos abrangerem todas as características importantes do software
se uma das fases mais importantes de todo o
boa parte dos erros são introduzidos. Cenários, como
, mostram que defeitos não tratados ainda na fase de
o custo do desenvolvimento do projeto. Ao
conforme primeira linha da
Custo relativo de correção
1
1 - 1.5
1 - 5
10 - 100
13
Diversos estudos de caso mostram que pelo menos um terço dos defeitos encontrados
nos projetos de software são originados de erros no levantamento de requisitos
(PARZIANELLO, 2009).
Pela sua importância, a análise de requisitos é uma das fases que mais precisam
atenção. E mesmo tendo consciência a respeito de sua natureza e de como elicitar requisitos,
ainda há uma grande dificuldade em atingir o sucesso nessa tarefa em um projeto de software.
Um ponto que não pode ser deixado de lado, em nenhuma fase da produção de um
software ou de qualquer produto ou serviço, e que na fase de análise de requisitos assume uma
importância maior ainda, é a natureza humana. Ela está envolvida em cada ação para se
chegar ao entendimento dos requisitos, e cabe aos analistas entender o impacto da natureza
humana ao elicitar requisitos de software.
Chiavenato (2002, p. 113) expõe através da Hierarquia das Necessidades de Maslow,
que nas motivações humanas, muitas de nossas necessidades são implícitas, e podem ser
organizadas em níveis, com uma hierarquia de importância e influência. Estes requisitos dos
seres humanos apresentados por Maslow, de realização pessoal, estima, amor/relacionamento,
segurança e fisiologia, são implícitos. Requisitos implícitos fazem parte dos humanos assim
como fazem parte dos softwares.
A Norma NBR ISO 9000:2000, ao conceituar requisitos, diz que eles podem ser
implícitos ou obrigatórios, e explica em nota que, “geralmente implícito significa que é uma
prática costumeira ou usual para a organização, seus clientes e outras partes interessadas, e
que a necessidade ou expectativa sob consideração está implícita”. A mesma norma também
aponta que “um requisito especificado é um requisito declarado, por exemplo, em um
documento” (ABNT, 2000, p. 7).
Logo, requisitos implícitos para quem os solicita, acabam não sendo especificados por
não serem implícitos para os analistas que deveriam documentá-los. Tem-se então um
problema entre a maneira como diferentes pessoas enxergam a realidade.
14
Assim, sendo requisitos um tema central no cenário de desenvolvimento de software, é
necessário conhecer algumas das principais definições da engenharia de requisitos, importante
no dia a dia de profissionais envolvidos com o ciclo de vida do software.
2.2 Tipos de requisitos
Sommerville (2003) classifica os requisitos de software em três tipos: Requisitos
funcionais, Requisitos não funcionais e Requisitos de domínio.
2.2.1 Requisitos funcionais
Requisitos funcionais são declarações detalhadas das funções que o sistema deve
executar e como deve ser seu comportamento diante de entradas e situações específicas
(SOMMERVILLE, 2003).
Ávila (2007) citam alguns exemplos de requisitos funcionais:
• O software deve permitir o cadastro de produtos.
• O software deve permitir o gerenciamento do estoque.
• O software deve permitir a geração de relatório dos produtos em estoque.
2.2.2 Requisitos não funcionais
Requisitos não funcionais são as restrições sobre as funções que serão oferecidas pelo
sistema. Eles também podem ser a respeito de requisitos relacionados ao processo utilizado
para o desenvolvimento do software, como especificações dos padrões de qualidade. Os
requisitos não funcionais surgem em razão do usuário, do orçamento disponível, das políticas
organizacionais ou até mesmo de necessidades externas, como necessidades legais ou de
segurança (SOMMERVILLE, 2003).
Segundo Andrade (2007), alguns exemplos de requisitos não funcionais são:
• O software deve ser compatível com o
Firefox (1.0 ou superior);
• O software deve garantir que o tempo de retorno das c
do que cinco segundos.
Os diferentes tipos de requisitos não funcionais estão representados na figura
classificados por Sommerville (2003) conforme a sua procedência
Figura 2
Fonte: SOMMERVILLE, 2003
Os requisitos de produto são procedentes do comportamento do produto, como o
desempenho, o espaço requerido
procedimentos do cliente e do
serão utilizados, quais os prazos de entrega e os requisitos de implementação. Os fatores
externos ao sistema ou ao processo de desenvolvimento, como questões legais ou éticas, são
representados pelos requisitos externos.
O software deve ser compatível com o browser IE (versão 5.0 ou superior) e
Firefox (1.0 ou superior);
e deve garantir que o tempo de retorno das consultas não seja maior
segundos.
Os diferentes tipos de requisitos não funcionais estão representados na figura
classificados por Sommerville (2003) conforme a sua procedência:
Figura 2 – Tipos de Requisitos Não Funcionais
Os requisitos de produto são procedentes do comportamento do produto, como o
desempenho, o espaço requerido e outros. Requisitos organizacionais especificam políticas e
procedimentos do cliente e do desenvolvedor, como questões relacionadas aos padrões que
serão utilizados, quais os prazos de entrega e os requisitos de implementação. Os fatores
externos ao sistema ou ao processo de desenvolvimento, como questões legais ou éticas, são
los requisitos externos.
15
IE (versão 5.0 ou superior) e
onsultas não seja maior
Os diferentes tipos de requisitos não funcionais estão representados na figura 2,
Os requisitos de produto são procedentes do comportamento do produto, como o
. Requisitos organizacionais especificam políticas e
desenvolvedor, como questões relacionadas aos padrões que
serão utilizados, quais os prazos de entrega e os requisitos de implementação. Os fatores
externos ao sistema ou ao processo de desenvolvimento, como questões legais ou éticas, são
16
2.2.3 Requisitos de domínio
Nascimento (2009) e Sommerville (2003) explicam que os fundamentos do domínio
da aplicação são representados pelos requisitos de domínio, que descrevem características do
sistema e qualidades que refletem o domínio, ao invés de serem captados a partir dos usuários
do sistema.
Andrade (2007) indica alguns exemplos de requisitos de domínio:
• O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 +
Nota2 * 3) / 5;
• Um aluno pode se matricular em uma disciplina desde que ele tenha sido
aprovado nas disciplinas consideradas pré-requisitos.
2.3 Processo de engenharia de requisitos
Sommerville (2003) aponta que a engenharia de requisitos é um processo que envolve
todas as atividades exigidas para criar e manter o documento de requisitos do sistema. Ávila
(2007) descreve diferentes definições encontradas na literatura técnica:
• Termo usado para descrever as atividades relacionadas à investigação e
definição de escopo de um sistema de software;
• Processo sistemático de desenvolvimento de requisitos através de um processo
de análise onde os resultados das observações são codificados e a acurácia das
observações é constantemente verificada;
• Processo de descobrir, analisar, documentar e verificar as funções e restrições
do sistema;
• Atividades relacionadas à produção (levantamento, registro, validação e
verificação) e gerência (controle de mudanças, gerência de configuração,
rastreabilidade, gerência de qualidade dos requisitos) de requisitos.
A figura 3 descreve, de maneira geral, o processo de engenharia de requisitos,
composto por atividades relacionadas.
Figura
Fonte: SOMMERVILLE, 2003.
2.3.1 Estudo de viabilidade
Autores como Sommerville (2003), recome
sistema, o processo de engenharia de requisitos
viabilidade que indicará se vale a pena ou não seguir adiante no projeto.
Ele explica que o estudo de viabilidade deve responder as
• O sistema contribui para os objetivos gerais da organização?
• O sistema pode ser implementado com a utilização de tecnologia atual dentro
das restrições de custo e prazo?
• O sistema pode ser integrado com outros sistemas já em operação?
Deve-se buscar informação através dos gerentes de departamentos, engenheiros de
software e usuários finais do sistema e através do relatório de estudo de viabilidade
recomendar se o desenvolvimento do sistema deve
mudanças em questões importantes do projeto, como o enfoque do sistema, o orçamento
disponível ou o cronograma de desenvolvimento.
Figura 3 – Processo de Engenharia de Requisitos
Autores como Sommerville (2003), recomendam que ao iniciar o projeto de um novo
genharia de requisitos deve ser iniciado com um estudo de
viabilidade que indicará se vale a pena ou não seguir adiante no projeto.
Ele explica que o estudo de viabilidade deve responder as seguintes perguntas:
O sistema contribui para os objetivos gerais da organização?
O sistema pode ser implementado com a utilização de tecnologia atual dentro
das restrições de custo e prazo?
O sistema pode ser integrado com outros sistemas já em operação?
se buscar informação através dos gerentes de departamentos, engenheiros de
software e usuários finais do sistema e através do relatório de estudo de viabilidade
recomendar se o desenvolvimento do sistema deve iniciar/continuar ou não, podendo sugeri
mudanças em questões importantes do projeto, como o enfoque do sistema, o orçamento
disponível ou o cronograma de desenvolvimento.
17
ndam que ao iniciar o projeto de um novo
deve ser iniciado com um estudo de
seguintes perguntas:
O sistema pode ser implementado com a utilização de tecnologia atual dentro
O sistema pode ser integrado com outros sistemas já em operação?
se buscar informação através dos gerentes de departamentos, engenheiros de
software e usuários finais do sistema e através do relatório de estudo de viabilidade
continuar ou não, podendo sugerir
mudanças em questões importantes do projeto, como o enfoque do sistema, o orçamento
18
2.3.2 Elicitação e análise de requisitos
Após os estudos de viabilidade apontarem que o projeto deve seguir em frente, inicia-
se a etapa de elicitação e análise dos requisitos. É nesta etapa que os requisitos são obtidos.
A elicitação é a tarefa de identificar os fatos que compõem os requisitos do sistema, de
forma a prover o mais correto e mais completo entendimento do que é demandado pelo
cliente. Para isso, os responsáveis pelo desenvolvimento do sistema terão de trabalhar com os
clientes e usuários finais a fim de descobrir as necessidades e restrições relacionadas ao
sistema a ser desenvolvido (SPÍNOLA, 2009).
A etapa de elicitação e análise de requisitos, como já comentado anteriormente, é um
estágio decisivo e difícil dentro do projeto de qualquer sistema, por diversos fatores, como os
listados por Ávila (2007):
• Falta de conhecimento do usuário das suas reais necessidades;
o Usuário com vaga noção do que precisa e do que um produto de
software pode oferecer;
• Falta de conhecimento do desenvolvedor do domínio do problema;
o Desenvolvedor sem conhecimento adequado do domínio, o que leva a
decisões erradas;
• Domínio do processo de levantamento de requisitos pelos desenvolvedores;
o Desenvolvedor não ouve o que os usuários têm a dizer e força suas
próprias visões e interpretações.
• Comunicação inadequada entre os desenvolvedores e usuários;
o Usuários incapazes de expressar suas necessidades apropriadamente;
o Significados diferentes a termos comuns;
• Dificuldade de o usuário tomar decisões;
o Falta de entendimento sobre as conseqüências das decisões ou as
alternativas positivas;
• Problemas de comportamento;
o O levantamento de requisitos é um processo social;
o Conflitos e ambiguidades nos papéis que os usuários e desenvolvedores
desempenham;
19
• Questões técnicas;
o Complexidade crescente dos sistemas atuais;
No interesse de obter-se um melhor desempenho na elicitação, técnicas foram criadas
para apoiar essa atividade. Spínola (2009) comenta algumas delas:
• Entrevista: Técnica no qual os requisitos são levantados através de entrevistas
com os usuários. Essa técnica pode ser realizada de diversas formas e na
literatura técnica há uma boa quantidade de materiais que orientam como
aplicar corretamente esta técnica de levantamento de requisitos.
• Prototipação: É o desenvolvimento de uma versão inicial do sistema para
experimentação. Isso permitirá aos usuários identificar os pontos fortes e
fracos do sistema. Essa técnica possui como desvantagem os custos de
aprendizagem e os custos de desenvolvimento.
• JAD (Joint Application Development): Técnica que deve ser usado no caso em
que existe a necessidade de consenso entre diversos usuários. Ela permite que
todos os envolvidos tenham uma visão global do sistema através de reuniões e
workshops que promovam interação e aumentem o comprometimento dos
envolvidos com os requisitos a serem levantados.
• Questionários: Técnica indicada para quando há diversos grupos de usuários
que podem estar em diferentes locais. Neste caso, elaboram-se pesquisas
específicas de acompanhamento com usuários selecionados. Esta técnica
permite a padronização das perguntas e tratamento estatístico das respostas.
2.3.3 Validação de requisitos
Enquanto a análise de requisitos envolve trabalhar com requisitos incompletos, o
processo de validação deve ser executado no sentido de elaborar-se um esboço completo do
documento de requisitos (SOMMERVILLE, 2003).
Durante esse processo, deve-se examinar a especificação do software, assegurando que
os requisitos estão livres de ambigüidades, inconsistências ou omissões, detectando ou
20
corrigindo possíveis problemas ainda durante a fase de definição dos requisitos (ÁVILA,
2007). Esse processo é finalizado após obter o aceite do cliente sob os requisitos levantados.
A dificuldade dessa atividade não deve ser subestimada, pois os usuários devem
pensar no sistema em operação e imaginar como o sistema se adequaria ao seu trabalho.
Devido a essa dificuldade, raramente o processo de validação consegue descobrir todos os
problemas com os requisitos.
2.3.4 Gerenciamento de requisitos
Ávila (2007) afirma que o processo de gerenciamento de requisitos é a atividade de
administrar os requisitos ao longo do tempo. Explica que softwares complexos estão sempre
sendo modificados. Isso ocorre por conta da natureza volátil dos requisitos, que são
influenciados por diversos fatores, como mudanças externas nos ambientes (como mudanças
de legislação, mercado ou estratégia da empresa), erros cometidos no processo de elicitação
dos requisitos, entre outros.
As modificações necessárias precisam ser gerenciadas de uma maneira ordenada, para
que não se perca controle dos prazos e custos de desenvolvimento do projeto (ÁVILA, 2007).
Os benefícios dessa prática são a longo prazo e algumas atividades precisam ser
levadas em conta durante o gerenciamento dos requisitos, como o controle das mudanças, a
gerência de configuração e a rastreabilidade.
Devido às necessidades de alterações dos requisitos, é preciso ter um único canal para
o controle das mudanças, podendo assim, diferenciar o que era requisito original, o que foi
introduzido e o que foi descartado. Ávila (2007) indica que antes de aceitar ou rejeitar alguma
mudança, deve-se analisá-la conforme os impactos e custos que ela pode ter no sistema. Para
isso indica os seguintes passos:
• Checar validade de solicitação de mudança;
• Identificar os requisitos diretamente afetados com a mudança;
• Identificar dependências entre os requisitos para buscar os requisitos afetados
indiretamente;
21
• Assegurar com solicitante a mudança a ser realizada;
• Estimar custos da mudança;
• Obter acordo com o usuário sobre o custo da mudança.
A Gerência de Configuração: Consiste em definir os critérios que permitem realizar
modificações, seja na especificação dos requisitos ou na implantação do sistema, e o controle
sistemático das modificações de maneira a manter a consistência e a integridade do software
com as especificações.
A rastreabilidade é a capacidade de acompanhar a vida de um requisito
bidirecionalmente, ou seja, partindo de requisitos e chegando ao projeto ou partindo de
projeto e chegando a requisitos.
2.4 Requisitos e os modelos MPS.BR e Scrum
Tanto o modelo MPS.BR como o Scrum não resolverão os problemas relacionados a
requisitos. Ambos apenas fornecem ferramentas para gerenciar melhor os requisitos, sendo
que o primeiro é focado nos processos que envolvem a gerência dos requisitos e o segundo
assume que os requisitos mudam ao longo do processo de desenvolvimento e tem como
estratégia iterações curtas, que permitem uma avaliação dos requisitos periodicamente.
Tais modelos servem como guias de boas práticas para o alcance do sucesso de um
projeto de software.
Nos capítulos seguintes, os requisitos serão vistos sob o ponto de vista da metodologia
ágil e do modelo de processo, e ao final, tentaremos mostrar como eles podem trabalhar de
maneira conjunta e como isso pode contribuir para o sucesso da gestão dos requisitos e
conseqüentemente para o sucesso do produto ou serviço a ser desenvolvido.
3 FRAMEWORK SCRUM
Nas mais diferentes áreas, nos mais variados serviços, a agilidade é quase que um
paradoxo, todos querem ser servidos por ela, mas poucos se dispõem a provê
desenvolvimento ágil de softwares é, para muito
série de profissionais, de todas as partes do mundo,
metodologias ágeis, divulgando e aprimorando
aceitabilidade dentro das empres
Dentre os principais métodos ágeis de desenvolvimento de software podem ser
citados: Scrum, Extreme Programming, Lean Software Development, entre outros.
1 corrobora a afirmação inicial
respondida por 2.570 participantes, de 88 países, e que teve como resultado que Scrum ou
alguma variação deste, é utilizado por mais de 70 % dos participantes.
Gráfico 1
Fonte: VERSIONONE, 2009.
Este capítulo tem como foco os conceitos básicos que levam ao entendimento do
Scrum e que permitirão uma avaliação do uso deste
MPS.BR.
Nas mais diferentes áreas, nos mais variados serviços, a agilidade é quase que um
paradoxo, todos querem ser servidos por ela, mas poucos se dispõem a provê
oftwares é, para muitos, algo intangível, que não existe. Mas uma
de todas as partes do mundo, dedicam-se a aplicar os conceitos das
metodologias ágeis, divulgando e aprimorando esses conceitos que ganham,
dentro das empresas de tecnologia da informação.
Dentre os principais métodos ágeis de desenvolvimento de software podem ser
citados: Scrum, Extreme Programming, Lean Software Development, entre outros.
inicial, mostrando a pesquisa apresentada pela VersionOne (2009),
respondida por 2.570 participantes, de 88 países, e que teve como resultado que Scrum ou
alguma variação deste, é utilizado por mais de 70 % dos participantes.
Gráfico 1 – Utilização de metodologias ágeis
Este capítulo tem como foco os conceitos básicos que levam ao entendimento do
Scrum e que permitirão uma avaliação do uso deste framework juntamente com o modelo
22
Nas mais diferentes áreas, nos mais variados serviços, a agilidade é quase que um
paradoxo, todos querem ser servidos por ela, mas poucos se dispõem a provê-la. O
, algo intangível, que não existe. Mas uma
se a aplicar os conceitos das
cada vez mais a
Dentre os principais métodos ágeis de desenvolvimento de software podem ser
citados: Scrum, Extreme Programming, Lean Software Development, entre outros. O gráfico
rando a pesquisa apresentada pela VersionOne (2009),
respondida por 2.570 participantes, de 88 países, e que teve como resultado que Scrum ou
Este capítulo tem como foco os conceitos básicos que levam ao entendimento do
juntamente com o modelo
23
3.1 Visão geral sobre metodologias ágeis
As metodologias ágeis são o resultado do esforço de um grupo de dezessete
desenvolvedores experientes e consultores, que em 2001, compuseram um manifesto o qual
valoriza um conjunto de valores e práticas comuns para o desenvolvimento de software de
uma maneira mais ágil. O manifesto ágil identifica valores e princípios que devem prevalecer
no desenvolvimento de software (BECK, 2001 apud DIAS, 2010; ANEXOS A e B).
Segundo Dias (2010), a essência das metodologias ágeis é o enfoque do
desenvolvimento de software calcado na agilidade, na flexibilidade, nas habilidades de
comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em
curtos períodos de tempo. A agilidade não significa a falta de estrutura, mas sim a capacidade
de adaptação a situações inesperadas.
Podemos identificar quatro aspectos que o manifesto ágil impulsiona: a cultura, a
comunicação, as pessoas e o processo. O manifesto prega que os projetos dêem o suporte
necessário às necessidades da equipe, formando profissionais motivados e confiantes, que
reflitam sobre como tornarem-se mais efetivos, empregando seus esforços em entregar
software funcionando (PRIKLADNICKI, 2009).
Como comentado anteriormente, Scrum é um de vários métodos ágeis, como o
Adaptative Software Development (ASD), Crystal Clear, Extreme Programming, Lean
Software Development, Feature Driven Development (FDD), Agile Unified Process.
Pela importância que tem adquirido perante a comunidade de desenvolvedores e pelas
características que garantem um compromisso com a entrega de valor ao cliente, sem perder o
foco nos processos, na cultura e nas pessoas que desenvolvem, o Scrum faz parte do escopo
deste trabalho.
3.2 Introdução ao Scrum
Porque Scrum? No Guia do Scrum, Schwaber (2009), explica que Scrum não é um
processo e nem uma técnica, é um framework com objetivo de transparecer a eficácia, onde se
24
pode empregar diversos processos e técnicas. Scrum é baseado em processos empíricos,
possui uma abordagem iterativa e incremental, o que permite uma maior previsibilidade e
controle dos riscos.
Ao assumir que o objetivo do projeto é o produto e não a documentação, Scrum busca
gerar apenas a documentação suficiente e necessária para atingir o objetivo de entregar um
produto que dê ao cliente um retorno rápido do seu capital investido. Ao defender que abraçar
as mudanças é mais importante do que seguir um plano, Scrum vem de encontro às
metodologias tradicionais de desenvolvimento de software, exigindo muita disciplina e
organização para que se tenha a habilidade de ser flexível com estabilidade (MACHADO,
2009).
O Scrum consiste em Times Scrum com seus papéis associados, Eventos com duração
fixa e Artefatos. O framework possui também Regras, que irão delimitar a atuação dos
diferentes papéis e eventos e serão descritas ao longo deste capítulo (SCHAWBER, 2009, p.
4).
3.2.1 Times Scrum, seus papéis e responsabilidades
Schwaber (2009), explica que os Times Scrum devem ter como objetivo a
flexibilidade e produtividade e que para isso eles necessitam ser auto-organizados,
interdisciplinados e trabalharem em iterações. Os Times Scrum têm pelo menos três papéis: o
ScrumMaster, o Product Owner e o Time.
O ScrumMaster é a pessoa responsável por garantir que o processo seja entendido e
seguido, é ele quem deve verificar se o Time Scrum está aderindo aos valores, princípios,
práticas e regras do Scrum. Apesar do ScrumMaster não gerenciar o Time Scrum, pois este
deve ser auto-organizado, ele deve fazer com que o Time Scrum entenda e use
autogerenciamento e interdisciplinaridade.
A responsabilidade de gerenciar o Backlog do Produto (lista de requisitos) que será
desenvolvido é do Product Owner. Ele também é responsável por garantir que o trabalho
25
realizado pelo Time tenha valor, garantindo uma priorização correta dos itens do Backlog.
Seu sucesso depende que haja respeito com relação as suas decisões.
O Time é formado pelos desenvolvedores de software, que a cada Sprint, baseados nas
prioridades do Backlog, devem entregar Software Pronto. Times também precisam tomar a
decisão de como realizar a tarefa de entregar o Software Pronto dentro do prazo, e para isso
precisam ser auto-organizados e interdisciplinares.
3.2.2 Eventos
Os Eventos no Scrum devem possuir regularidade e por isso têm duração fixa.
Reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião Diária, a Revisão da
Sprint e a Retrospectiva da Sprint são os elementos com duração fixa empregados no
framework.
Na Reunião de Planejamento da Versão para Entrega, o Time Scrum estabelecerá,
através de planos e metas, quais as prioridades do Backlog do Produto que formarão o
Backlog do Produto para a Versão, quais os riscos envolvidos, qual a data de entrega e o
provável custo da versão a ser entregue. O planejamento deverá levar em conta o objetivo de
alcançar a satisfação do cliente e o retorno do investimento (ROI1) desejados, ele permitirá
que a organização avalie o progresso do projeto, possibilitando correções nos planos a cada
Sprint.
A Sprint é um evento de duração fixa, na qual o ScrumMaster deverá garantir que
nenhuma mudança afete o objetivo da Sprint. Por mudança, entendem-se também as
mudanças na composição do time e das metas de qualidade. As Sprints são formadas pela
reunião de Planejamento da Sprint, o desenvolvimento, a Revisão da Sprint e a Retrospectiva
da Sprint.
No Scrum, para diminuir a complexidade do projeto, recomenda-se que as Sprints
tenham entre duas a quatro semanas. Dessa forma, evita-se que o plano de desenvolvimento
1 ROI significa em inglês Return Of Investiment, é a relação entre o dinheiro ganho ou perdido através de
um investimento, e o montante de dinheiro investido. (WIKIPEDIA. Retorno sobre investimento. Disponível em: < http://pt.wikipedia.org/wiki/Retorno_sobre_investimento >. Acesso em: jun. 2010.)
do projeto perca a validade pelas mudanças que podem ocorrer em um plan
longo. Em Scrum, a previsibilidade do projeto será controlada dentro do período
compreendido por cada Sprint.
As Sprints são precedidas pela reunião de Planejamento da Sprint. Nesta reunião,
Schwaber (2004), recomenda uma duração de oito ho
Sprints mais curtas, uma duração de cerca de cinco por cento do tamanho da Sprint. A reunião
é dividida em duas etapas de quatro horas, sendo que na primeira etapa o objetivo é o time
discutir quais itens do Backlog
sugestões, mas a decisão de quais itens serão produzidos é exclusivamente do Product Owner.
Porém cabe ao Time definir, baseado em sua experiência, qual a quantidade de itens será
possível produzir dentro da Sprint.
Na segunda etapa o time deve discutir como os itens escolhidos serão transformados
em Software Pronto. As tarefas para a concretização desta tarefa formarão o Backlog da
Sprint (figura 4). Ao efetuar o planejamento da Sprint e estabelecer
equipe deverá levar em conta a Meta da Versão para Entrega.
Figura 4
Fonte: KNIBERG, 2007, p. 22.
Ao término de cada Sprint, o Time Scrum deverá reunir
Nesta reunião a equipe deve
enfrentados, como foram solucionados no decorrer da Sprint
corrigir deficiências e/ou imped
demonstrar o trabalho pronto, e o Product Owner deve identificar os itens do Backlog da
Sprint que foram feitos e os que não foram feitos, e discutir como o restante do Backlog do
do projeto perca a validade pelas mudanças que podem ocorrer em um plan
longo. Em Scrum, a previsibilidade do projeto será controlada dentro do período
compreendido por cada Sprint.
As Sprints são precedidas pela reunião de Planejamento da Sprint. Nesta reunião,
Schwaber (2004), recomenda uma duração de oito horas para Sprints de um mês e no caso de
Sprints mais curtas, uma duração de cerca de cinco por cento do tamanho da Sprint. A reunião
é dividida em duas etapas de quatro horas, sendo que na primeira etapa o objetivo é o time
discutir quais itens do Backlog do Produto serão produzidos na Sprint. O time poderá dar
sugestões, mas a decisão de quais itens serão produzidos é exclusivamente do Product Owner.
ime definir, baseado em sua experiência, qual a quantidade de itens será
entro da Sprint.
Na segunda etapa o time deve discutir como os itens escolhidos serão transformados
ronto. As tarefas para a concretização desta tarefa formarão o Backlog da
. Ao efetuar o planejamento da Sprint e estabelecer as metas da mesma, a
equipe deverá levar em conta a Meta da Versão para Entrega.
Figura 4 – Formação do Backlog da Sprint
Ao término de cada Sprint, o Time Scrum deverá reunir-se para a Revisão da Sprint.
quipe deve fornecer feedback, discutir sobre sucessos
enfrentados, como foram solucionados no decorrer da Sprint, com o objetivo de identificar e
corrigir deficiências e/ou impedimentos no processo de desenvolvimento.
trabalho pronto, e o Product Owner deve identificar os itens do Backlog da
Sprint que foram feitos e os que não foram feitos, e discutir como o restante do Backlog do
26
do projeto perca a validade pelas mudanças que podem ocorrer em um planejamento muito
longo. Em Scrum, a previsibilidade do projeto será controlada dentro do período
As Sprints são precedidas pela reunião de Planejamento da Sprint. Nesta reunião,
ras para Sprints de um mês e no caso de
Sprints mais curtas, uma duração de cerca de cinco por cento do tamanho da Sprint. A reunião
é dividida em duas etapas de quatro horas, sendo que na primeira etapa o objetivo é o time
do Produto serão produzidos na Sprint. O time poderá dar
sugestões, mas a decisão de quais itens serão produzidos é exclusivamente do Product Owner.
ime definir, baseado em sua experiência, qual a quantidade de itens será
Na segunda etapa o time deve discutir como os itens escolhidos serão transformados
ronto. As tarefas para a concretização desta tarefa formarão o Backlog da
as metas da mesma, a
se para a Revisão da Sprint.
sucessos, problemas
com o objetivo de identificar e
vimento. A equipe deve
trabalho pronto, e o Product Owner deve identificar os itens do Backlog da
Sprint que foram feitos e os que não foram feitos, e discutir como o restante do Backlog do
27
Produto será efetuado, fazendo projeções de prováveis datas de entrega com base na
velocidade estimada da equipe.
O Scrum estabelece que após a revisão da Sprint e antes do planejamento da próxima
Sprint, o Time Scrum deve realizar uma reunião com o tempo fixo de três horas para
Retrospectiva da Sprint. Nesta reunião o ScrumMaster deve encorajar o Time a revisar o
processo de desenvolvimento, inspecionando quais mudanças podem torná-lo mais eficaz e
gratificante para a próxima Sprint (SCHWABER, 2009).
Durante as Sprints a equipe deve realizar uma Reunião Diária de quinze minutos, que
deve ser sempre no mesmo horário e local. No Guia do Scrum2 ela é relatada como
fundamental ao processo empírico do Scrum. Nessa reunião, o ScrumMaster deve garantir
que a reunião aconteça e ajudar para que o Time seja o responsável pela condução da mesma,
obedecendo ao tempo estabelecido. Nela cada membro deve explicar: O que ele realizou
desde a última reunião diária; O que ele vai fazer antes da próxima reunião diária; E quais os
obstáculos estão em seu caminho. O objetivo da Reunião Diária é inspecionar o progresso da
Meta da Sprint e ajudar o time a alcança-lá.
3.2.3 Artefatos
O framework também emprega os seguintes Artefatos: Backlog do Produto, que
consiste em uma lista de todos os requisitos necessários ao produto; O Backlog da Sprint, que
é a lista de itens do Backlog do Produto que, em uma Sprint, serão transformados em
Software Pronto; O Burndown de Versão para Entrega, que mede o Backlog do Produto em
relação ao tempo estimado para entrega do produto; E o Burndown de Sprint, que mostra os
itens do Backlog da Sprint em relação ao tempo da Sprint. O burndown é um gráfico que
mostra o backlog a ser desenvolvido pelo tempo estimado de desenvolvimento.
Schwaber (2009) indica o Backlog do Produto como uma lista de todos os requisitos
necessários ao produto que está sendo desenvolvido, ele deve estar disponível e priorizado
pelo Product Owner, que desempenha o papel responsável pelo conteúdo deste Backlog,
2 Detalhes sobre o Guia do Scrum em SCHWABER, 2009.
cabendo ao Product Owner fazer com que o Backlog tenha inicialmente os requisitos
conhecidos e melhor entendidos.
neste sentido. O Backlog é dinâmico, mudando constantemente no sentido de identificar o que
é o mais apropriado, competitivo e útil ao Produto.
O Backlog do Produto deve ser uma lista com to
tecnologias, melhorias e correções de defeitos. Seus itens devem conter atributos como:
descrição, prioridade e estimativa. Ele deve estar ordenado por pri
maior a prioridade do item, maior deverá
deverá ser o seu desenvolvimento. Os itens do Backlog do Produto deverão ser decompostos
de maneira a poderem ser realizados dentro da duração de uma Sprint.
Figura
Fonte: inspirada em SCHWABER, 2004.
Os itens do Backlog deverão ter suas estimativas de esforço calculadas durante o
Planejamento da Versão para Entrega, sendo atualizadas em qualquer tempo pelo Time.
Com a soma das estimativas de esforço necessário para o té
Produto, registradas ao longo do tempo através de um gráfico, é possível analisar a velocidade
do Time, podendo-se traçar uma linha de tendência que mostrará uma estimativa do progresso
do desenvolvimento do Produto. Este gráfico é cham
Entrega. Geralmente as unidades de tempo utilizadas são Sprints e o esforço estimado deve
estar em qualquer unidade de medida de trabalho adotada pelo Time Scrum.
Schwaber (2009) também explica que o Backlog da Sprint é todo
Time identifica como necessário para alcançar a Meta da Sprint, consiste nas tarefas
necessárias para transformar os itens do Backlog do Produto em
cabendo ao Product Owner fazer com que o Backlog tenha inicialmente os requisitos
endidos. À medida que o Produto evolui, o Backlog também caminha
neste sentido. O Backlog é dinâmico, mudando constantemente no sentido de identificar o que
é o mais apropriado, competitivo e útil ao Produto.
O Backlog do Produto deve ser uma lista com todas as características, funções,
tecnologias, melhorias e correções de defeitos. Seus itens devem conter atributos como:
descrição, prioridade e estimativa. Ele deve estar ordenado por prioridade (f
maior a prioridade do item, maior deverá ser o seu nível de detalhamento e com mais urgência
deverá ser o seu desenvolvimento. Os itens do Backlog do Produto deverão ser decompostos
de maneira a poderem ser realizados dentro da duração de uma Sprint.
Figura 5 – Exemplo de Product Backlog
: inspirada em SCHWABER, 2004.
Os itens do Backlog deverão ter suas estimativas de esforço calculadas durante o
Planejamento da Versão para Entrega, sendo atualizadas em qualquer tempo pelo Time.
Com a soma das estimativas de esforço necessário para o término do Backlog do
Produto, registradas ao longo do tempo através de um gráfico, é possível analisar a velocidade
se traçar uma linha de tendência que mostrará uma estimativa do progresso
do desenvolvimento do Produto. Este gráfico é chamado de Burndown da Versão para
Entrega. Geralmente as unidades de tempo utilizadas são Sprints e o esforço estimado deve
estar em qualquer unidade de medida de trabalho adotada pelo Time Scrum.
Schwaber (2009) também explica que o Backlog da Sprint é todo o trabalho que o
Time identifica como necessário para alcançar a Meta da Sprint, consiste nas tarefas
necessárias para transformar os itens do Backlog do Produto em Software Pronto
28
cabendo ao Product Owner fazer com que o Backlog tenha inicialmente os requisitos
medida que o Produto evolui, o Backlog também caminha
neste sentido. O Backlog é dinâmico, mudando constantemente no sentido de identificar o que
das as características, funções,
tecnologias, melhorias e correções de defeitos. Seus itens devem conter atributos como:
oridade (figura 5). Quanto
ser o seu nível de detalhamento e com mais urgência
deverá ser o seu desenvolvimento. Os itens do Backlog do Produto deverão ser decompostos
Os itens do Backlog deverão ter suas estimativas de esforço calculadas durante o
Planejamento da Versão para Entrega, sendo atualizadas em qualquer tempo pelo Time.
rmino do Backlog do
Produto, registradas ao longo do tempo através de um gráfico, é possível analisar a velocidade
se traçar uma linha de tendência que mostrará uma estimativa do progresso
ado de Burndown da Versão para
Entrega. Geralmente as unidades de tempo utilizadas são Sprints e o esforço estimado deve
o trabalho que o
Time identifica como necessário para alcançar a Meta da Sprint, consiste nas tarefas
Software Pronto. Os itens do
Backlog da Sprint devem ser decompostos ao ponto que possam s
Diária. O Time, e somente ele, pode modificar o Backlog da Sprint ao longo da mesma,
atualizando também as estimativas de trabalho restante.
Assim como o Burndown da Versão para entrega, é possível usar a soma das
estimativas de esforço necessárias para o término do Backlog da Sprint e registrá
do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que
trabalho restante ao longo do tempo (figura 6
Fonte: inspirada em SCHWABER, 2004
3.2.4 Software Pronto
O framework Scrum tem como regra que se deve ter como resultado incrementos de
funcionalidade do Produto potencialmente entregáveis ao final de cada Sprint. O conceito de
“Pronto” deve incluir toda a análi
testes.
3.3 Fluxo do Scrum
Isotton Neto (2008), com base no artigo “
Schwaber (1996), define que Scrum é formado pelos seguintes grupos de fases:
Backlog da Sprint devem ser decompostos ao ponto que possam ser entendidos na Reunião
Diária. O Time, e somente ele, pode modificar o Backlog da Sprint ao longo da mesma,
atualizando também as estimativas de trabalho restante.
Assim como o Burndown da Versão para entrega, é possível usar a soma das
sforço necessárias para o término do Backlog da Sprint e registrá
do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que
go do tempo (figura 6).
Figura 6 – Burndown da Sprint
pirada em SCHWABER, 2004.
Scrum tem como regra que se deve ter como resultado incrementos de
funcionalidade do Produto potencialmente entregáveis ao final de cada Sprint. O conceito de
“Pronto” deve incluir toda a análise, projeto, refatoramento, programação, documentação e
Isotton Neto (2008), com base no artigo “The Scrum Development Process
), define que Scrum é formado pelos seguintes grupos de fases:
29
er entendidos na Reunião
Diária. O Time, e somente ele, pode modificar o Backlog da Sprint ao longo da mesma,
Assim como o Burndown da Versão para entrega, é possível usar a soma das
sforço necessárias para o término do Backlog da Sprint e registrá-las ao longo
do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que mostre o
Scrum tem como regra que se deve ter como resultado incrementos de
funcionalidade do Produto potencialmente entregáveis ao final de cada Sprint. O conceito de
se, projeto, refatoramento, programação, documentação e
The Scrum Development Process”, de
), define que Scrum é formado pelos seguintes grupos de fases:
30
Pregame:
• Planejamento – Definição de um novo release baseado no Backlog do Produto
(BP) e estimativa de cronograma e custo. Se for o início de um novo projeto,
essa fase consiste em conceitualização e análise do produto. Se for um projeto
em andamento, esta fase é limitada à análise. Os passos dessa fase são:
o Desenvolvimento claro e objetivo do BP;
o Definição da data de entrega e funcionalidades de uma ou mais Sprints;
o Definição do release mais apropriado para o início do
desenvolvimento;
o Mapeamento e estimativa das atividades a serem incluídas no Backlog
do Produto;
o Definição do Time Scrum (TS);
o Avaliação e controle de riscos envolvidos no projeto;
o Avaliação das ferramentas de desenvolvimento e infra-estrutura do
projeto;
o Estimativa de custos.
• Arquitetura – Definição de como os itens do BP serão implementados.
Modificações na arquitetura do sistema e design de alto nível também são
realizadas nessa fase. Os passos desta fase:
o Revisão e ajustes ao BP;
o Identificação das mudanças necessárias para a implementação do BP;
o Realizar a análise do domínio;
o Refinar a arquitetura do sistema;
o Identificação de possíveis problemas ou impedimentos na
implementação dos requisitos;
o Reunião de revisão do design, onde são apresentadas as propostas de
melhoria e mudanças na implementação de cada item do BP.
Game:
• Sprints – Desenvolvimento das funcionalidades do novo release, respeitando-
se as variáveis tempo, requisitos, qualidade e custo. Normalmente, serão
utilizadas múltiplas Sprints para a evolução incremental do sistema. Os passos
dessa fase:
o Reunião de Planejamento da Sprint a fim de definir as atividades a
serem incluídas na iteração corrente.
o Reuniões Diárias com o TS para revisar o andamento do projeto;
o Revisão e ajustes nos requisitos do projeto;
o Sprints iterativos até que se tenha “Sof
Nesta fase, é importante que as definições da Sprint, comentadas no item “3.2.2
Eventos” desse capítulo, sejam plenamente seguidas pelo TS.
Postgame:
• Fechamento – Entrega e empacotamento do “Software Pronto”. Preparação do
produto desenvol
treinamento e marketing são
A figura 7 mostra de o fluxo Scrum de maneira
Fonte: inspirada em KNIBERG, 2007
Reunião de Planejamento da Sprint a fim de definir as atividades a
serem incluídas na iteração corrente.
Reuniões Diárias com o TS para revisar o andamento do projeto;
Revisão e ajustes nos requisitos do projeto;
Sprints iterativos até que se tenha “Software Pronto”.
Nesta fase, é importante que as definições da Sprint, comentadas no item “3.2.2
e capítulo, sejam plenamente seguidas pelo TS.
Entrega e empacotamento do “Software Pronto”. Preparação do
produto desenvolvido para a entrega. Documentações, testes, materiais de
treinamento e marketing são artefatos típicos dessa fase.
A figura 7 mostra de o fluxo Scrum de maneira ilustrativa.
Figura 7 – Fluxo do Scrum
KNIBERG, 2007
31
Reunião de Planejamento da Sprint a fim de definir as atividades a
Reuniões Diárias com o TS para revisar o andamento do projeto;
Nesta fase, é importante que as definições da Sprint, comentadas no item “3.2.2
Entrega e empacotamento do “Software Pronto”. Preparação do
vido para a entrega. Documentações, testes, materiais de
32
O framework foi concebido de maneira simples e aberto, permitindo que
características sejam adicionadas sem que a filosofia básica do Scrum seja alterada.
Nesse capítulo, buscou-se apresentar uma visão para o entendimento do assunto
abordado, porém dificilmente seria possível esgotar o assunto, diante das mais diversas
possibilidades da aplicação da metodologia. É possível concluir que Scrum é uma abordagem
baseada na flexibilidade, adaptabilidade e produtividade, com ênfase no gerenciamento do
projeto.
33
4 MODELO MPS.BR
As atividades das empresas ocorrem através de processos. Conforme Pádua (2007),
processos são um conjunto de ações e atividades inter-relacionadas, realizadas para obter um
conjunto especificado de produtos, resultados ou serviços. Baseados em boas práticas de
execução, surgiram diversos modelos de processos, todos visando o aumento da eficiência e
eficácia nas atividades das organizações. O Modelo de Melhoria do Processo de Software
Brasileiro – MPS.BR, é um exemplo, e por ser uma importante iniciativa brasileira na área de
qualidade do desenvolvimento de software, é objeto de estudo desse trabalho.
4.1 Introdução ao Modelo MPS.BR
O modelo MPS.BR é uma proposta brasileira, para micro, pequenas e médias
empresas, de um modelo de maturidade de processos de desenvolvimento do software
Brasileiro (Associação para Promoção da Excelência do Software Brasileiro – SOFTEX,
2009a).
O viés do MPS.BR são os processos, a qualificação desses reflete na qualidade do
produto, além disso proporciona: diminuição de retrabalho, maior produtividade, redução do
tempo para atender às necessidades de negócio, maior competitividade, maior precisão nas
estimativas, entre outros.
O MPS.BR é um programa coordenado pela Associação para Promoção da Excelência
do Software Brasileiro – SOFTEX que tem apoio do Ministério da Ciência e Tecnologia
(MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de
Desenvolvimento (BID).
O modelo está documentado através de guias, que auxiliam no entendimento e
implementação do mesmo. Além do Guia Geral, que expõe uma descrição do modelo e
detalha o Modelo de Referência MR-MPS, há também os guias de Avaliação, Aquisição e os
guias de Implementação, que divididos por níveis, formam o conjunto de documentos do
modelo MPS. Os componentes do modelo podem ser observados na figura 8.
Fonte: SOFTEX, 2009.
O Modelo de Referência MR
pelas organizações que se submeterão
são indicados os níveis de maturidade, processos e seus atributos. O MR
técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI
4.2 Base técnica do Modelo MPS.BR
A ISO/IEC 12207 (
Electrotechnical Commission
processos. A norma contém
fornecimento, aquisição, desenvolvimento,
As normas ISO possuem reconhecimento internacional e, portanto, identificação de qualidade,
quando o assunto é exportação. A ISO12207, em especial, teve grande aceitação, servindo de
base para diversas normas
ISO12207 permite que processos de apoio possam ser combinados e executados junto a
outros, a qualquer momento
Standardization – ISO, 2010a)
Já a ISO/IEC 15504, também conhecida por SPICE (
and Capability Etermination), presta
com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de
Figura 8 – Modelo MPS.BR
O Modelo de Referência MR-MPS refere-se aos requisitos que devem ser atendidos
pelas organizações que se submeterão a avaliação ou desejam desenvolver bo
são indicados os níveis de maturidade, processos e seus atributos. O MR-MPS tem sua base
técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI
4.2 Base técnica do Modelo MPS.BR
A ISO/IEC 12207 (International Organization for Standardization/International
Electrotechnical Commission) estabelece uma arquitetura comum para o ciclo de vida de
processos, atividades e tarefas a serem aplicadas durante o
fornecimento, aquisição, desenvolvimento, operação, manutenção de produtos de software.
As normas ISO possuem reconhecimento internacional e, portanto, identificação de qualidade,
quando o assunto é exportação. A ISO12207, em especial, teve grande aceitação, servindo de
base para diversas normas e modelos que surgiram posteriormente. A organização da
ISO12207 permite que processos de apoio possam ser combinados e executados junto a
outros, a qualquer momento (SOFTEX, 2009a, p.14; International Organization for
).
ISO/IEC 15504, também conhecida por SPICE (Software Process Improvement
), presta-se à realização de avaliações de processos de software
com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de
34
requisitos que devem ser atendidos
a avaliação ou desejam desenvolver boas-práticas. Nele
MPS tem sua base
técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI-DEV.
nization for Standardization/International
o ciclo de vida de
processos, atividades e tarefas a serem aplicadas durante o
operação, manutenção de produtos de software.
As normas ISO possuem reconhecimento internacional e, portanto, identificação de qualidade,
quando o assunto é exportação. A ISO12207, em especial, teve grande aceitação, servindo de
e modelos que surgiram posteriormente. A organização da
ISO12207 permite que processos de apoio possam ser combinados e executados junto a
SOFTEX, 2009a, p.14; International Organization for
Software Process Improvement
se à realização de avaliações de processos de software
com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de
35
uma unidade organizacional. Um dos importantes conceitos introduzido por essa norma foi o
de “capacidades”. Tal capacidade tem a finalidade de indicar como um processo atende
determinada classe de requisitos. Quanto à dimensão dos processos, estes são agrupados em
cinco categorias: cliente-fornecedor (impactam na relação cliente-fornecedor), engenharia
(implementam ou mantém um sistema ou produto e sua documentação), suporte (processos
que podem ser empregados por outros), gerência (práticas genéricas usadas por quem
gerenciam projetos ou processos), empresa (objetivos do negócio). Assim, pode ocorrer de
uma empresa possuir maiores capacidades em algumas categorias ante outras, permitido que a
empresa possa buscar por sua certificação enquanto aprimoram outros processos que precisam
de melhorias (SOFTEX, 2009a, p. 14-15; ISO, 2010b).
E o CMMI-DEV (Software Capability Maturity Model for Development) é a versão do
CMMI dirigido à melhoria do processo de desenvolvimento de produtos e serviços. Foi criado
pelo SEI (Software Engineering Institute) da CMU (Carnegie Mellon University). O CMMI é
um modelo de referência com as melhores práticas para a maturidade dos processos das
organizações. Koscianski (2006) comenta que o objetivo do CMMI é: servir de guia para
melhoria de processos na organização e das habilidades dos profissionais em gerenciar o
desenvolvimento, aquisição e manutenção de produtos ou serviços. Desta maneira, espera-se
que a organização construa software com mais qualidade de maneira eficiente. No modelo
CMMI quatro áreas de conhecimento estão presentes: Engenharia de Sistemas, Engenharia de
Software, Desenvolvimento e Integração de Produtos e Processos e Fontes de Aquisição. O
modelo apresenta-se através de duas representações:
• Representação por Estágios: Organiza as áreas de processo em níveis de
maturidade, de 1 a 5.
• Representação Contínua: Apresenta níveis de capacitação, de 0 a 5. As áreas de
processo são agrupadas por categorias afins.
O modelo CMMI é complexo e caro, e a idéia de tê-lo como base no MPS.BR é trazer
para o modelo brasileiro, as boas práticas de gerenciamento de processos, tornando-os mais
fáceis e baratos.
4.3 Estrutura do MR-MPS.BR
O Modelo de Referência do MPS.BR (MR
processos de desenvolvimento de software através de níveis de maturidade, que por sua vez
são formados por conjuntos de processos, sendo que há um propósito e um conjunto de
resultados esperados para cada um dos 21 processos do MR
Para cada conjunto de proc
organização (seguindo a proposta da ISO 15504)
de atributos de processos (AP) e resultados esperados de atributos de processo (RAP)
figura 9 mostra a estrutura do Modelo de Referência.
Fonte: SOFTEX, 2009a
4.3.1 Níveis de maturidade
Os níveis de maturidade foram definidos de maneira que haja um amadurecimento
gradual dos processos, eles caracterizam estágios de melhori
na organização. São sete níveis de maturidade:
Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F
(Gerenciado) e G (Parcialmente Gerenciado).
A divisão em sete estágios tem como objetivo permitir uma implementação e
avaliação mais gradual e aderente, em comparação ao CMMI que possui cinco estágios.
A escala de maturidade inicia no nível G e progride
MPS.BR
O Modelo de Referência do MPS.BR (MR-MPS.BR) define a maturidade dos
to de software através de níveis de maturidade, que por sua vez
são formados por conjuntos de processos, sendo que há um propósito e um conjunto de
resultados esperados para cada um dos 21 processos do MR-MPS.BR (SOFTEX, 2009a)
Para cada conjunto de processos, novas capacidades de processos são exigidas da
(seguindo a proposta da ISO 15504), sendo estas capacidades mensuradas através
de atributos de processos (AP) e resultados esperados de atributos de processo (RAP)
tura do Modelo de Referência.
Figura 9 – Estrutura do MR-MPS.BR
Os níveis de maturidade foram definidos de maneira que haja um amadurecimento
gradual dos processos, eles caracterizam estágios de melhoria da implementação de processos
na organização. São sete níveis de maturidade: A (Em Otimização), B (Gerenciado
Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F
(Gerenciado) e G (Parcialmente Gerenciado).
em sete estágios tem como objetivo permitir uma implementação e
avaliação mais gradual e aderente, em comparação ao CMMI que possui cinco estágios.
A escala de maturidade inicia no nível G e progride até o nível A, conforme tabela 2
36
MPS.BR) define a maturidade dos
to de software através de níveis de maturidade, que por sua vez
são formados por conjuntos de processos, sendo que há um propósito e um conjunto de
(SOFTEX, 2009a).
essos, novas capacidades de processos são exigidas da
, sendo estas capacidades mensuradas através
de atributos de processos (AP) e resultados esperados de atributos de processo (RAP). A
Os níveis de maturidade foram definidos de maneira que haja um amadurecimento
a da implementação de processos
A (Em Otimização), B (Gerenciado
Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F
em sete estágios tem como objetivo permitir uma implementação e
avaliação mais gradual e aderente, em comparação ao CMMI que possui cinco estágios.
até o nível A, conforme tabela 2.
37
Tabela 2 – Níveis de Maturidade e Processos do Modelo de Referência do MPS.BR
Nível Processo
A - Em Otimização
B - Gerenciamento Quantitativo Gerência de Projetos – GPR (evolução)
C – Definido
Gerência de Riscos – GRI
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
D - Largamente Definido
Verificação – VER
Validação – VAL
Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
E - Parcialmente Definido
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
F – Gerenciado
Medição – MED
Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
G - Parcialmente Gerenciado Gerência de Requisitos – GRE
Gerência de Projetos – GPR
Fonte: SOFTEX, 2009a
4.3.1.1 Processos
Para cada um dos sete níveis foram atribuídos perfis de processos que serão o foco de
melhoria da organização. Atinge-se um determinado nível de maturidade quando o propósito
e os resultados esperados dos processos do nível são atendidos. Segundo Diniz (2009a) alguns
processos do MPS.BR afetam o desenvolvimento, no sentido de dar-lhe transparência, outros
afetam a gerenciabilidade do desenvolvimento. Por consequência, reduzem-se os riscos e
aumenta-se a produtividade. Ao passo que os níveis de maturidade são alcançados, os
processos implementados em cada nível também amadurecem (conforme tabela 2).
38
No modelo descrito no Guia Geral do MPS.BR (2009a, p. 16), os processos são
formados por propósitos e resultados. Os propósitos descrevem os objetivos gerais da
execução dos processos, enquanto que os resultados esperados dos processos determinam os
resultados que devem ser obtidos com a implementação do processo, ou seja, o efetivo
alcance dos propósitos.
4.3.1.2 Capacidades de processos
A implementação do conjunto de processos de cada um dos níveis de maturidade do
modelo é comprovada através da aquisição de determinadas capacidades. A capacidade do
processo caracteriza a habilidade do processo de atingir os objetivos de negócio, assim indica
o grau de refinamento com que os atributos de processos (AP) são executados e a
comprovação do sucesso da implementação destas capacidades é feita através da
demonstração de resultados esperados destes atributos. A tabela 3 mostra os níveis de
capacidade do MPS.BR:
Tabela 3 - Atributos de Processo do MPS.BR
Código Descrição
AP 1.1 O processo é executado
AP 2.1 O processo é gerenciado
AP 2.2 Os produtos de trabalho do processo são gerenciados
AP 3.1 O processo é definido
AP 3.2 O processo é implementado
AP 4.1 O processo é medido
AP 4.2 O processo é controlado
AP 5.1 O processo é objeto de melhorias e inovações
AP 5.2 O processo é otimizado continuamente
Fonte: SOFTEX, 2010a, 17-21.
Ao longo deste trabalho os processos de Gerência e Desenvolvimento de Requisitos
serão descritos, assim como seus propósitos e resultados esperados. O processo de Gerência
de Requisitos está incluso no nível G, enquanto que o processo de Desenvolvimento de
Requisitos está no nível D.
Os níveis, além de graduais, são acumulativos, e isto implica que a organização,
evoluir de nível, deverá manter as capacidades adquiridas nos níveis anteriores. O modelo
descreve nove atributos de processo, e seus respectivos resultados esperados de atributo de
processo (RAP), sendo que destes, dois estão presentes no nível G e ci
maturidade do MPS.BR. A figura 10
nível G ao nível D (SOFTEX, 2009a, p. 16
Figura 10 – Evolução dos AP em relação aos níveis G, F, E e D do MPS.BR
Fonte: SOFTEX, 2009a, p. 22.
O detalhamento de cada
deste trabalho.
4.4 Processo de Gerência de Requisitos
O processo Gerência de Requisitos (GRE) consta no nível de maturidade G do modelo
MPS.BR, que é o primeiro nível do
organização. Uma mudança de cultura organizacional e uma definição do conceito acerca do
que é “projeto” para a organização são implantados e caracterizam um grande desafio para a
organização, o que pode dete
(SOFTEX, 2009b, p. 6).
Para esse processo os Atributos de Processos (capacidades) esperados são:
• O processo é executado (RAP
Os níveis, além de graduais, são acumulativos, e isto implica que a organização,
evoluir de nível, deverá manter as capacidades adquiridas nos níveis anteriores. O modelo
descreve nove atributos de processo, e seus respectivos resultados esperados de atributo de
processo (RAP), sendo que destes, dois estão presentes no nível G e cinco no nível D de
maturidade do MPS.BR. A figura 10 mostra a evolução dos AP em relação aos níveis, do
(SOFTEX, 2009a, p. 16-17).
Evolução dos AP em relação aos níveis G, F, E e D do MPS.BR
detalhamento de cada AP dos níveis G ao D está descrito nos Anexos C
4.4 Processo de Gerência de Requisitos
O processo Gerência de Requisitos (GRE) consta no nível de maturidade G do modelo
MPS.BR, que é o primeiro nível do modelo e por isso, tem um grande impacto para a
organização. Uma mudança de cultura organizacional e uma definição do conceito acerca do
que é “projeto” para a organização são implantados e caracterizam um grande desafio para a
que pode determinar o sucesso ou insucesso da implementação do modelo
e processo os Atributos de Processos (capacidades) esperados são:
O processo é executado (RAP 1) e;
39
Os níveis, além de graduais, são acumulativos, e isto implica que a organização, ao
evoluir de nível, deverá manter as capacidades adquiridas nos níveis anteriores. O modelo
descreve nove atributos de processo, e seus respectivos resultados esperados de atributo de
nco no nível D de
mostra a evolução dos AP em relação aos níveis, do
Evolução dos AP em relação aos níveis G, F, E e D do MPS.BR
ao D está descrito nos Anexos C, D, E, F e G
O processo Gerência de Requisitos (GRE) consta no nível de maturidade G do modelo
modelo e por isso, tem um grande impacto para a
organização. Uma mudança de cultura organizacional e uma definição do conceito acerca do
que é “projeto” para a organização são implantados e caracterizam um grande desafio para a
rminar o sucesso ou insucesso da implementação do modelo
e processo os Atributos de Processos (capacidades) esperados são:
40
• O processo é gerenciado (RAP 2, RAP 3, RAP 4, RAP 5, RAP 6, RAP 7, RAP
8, RAP 9 e RAP 10).
4.4.1 Processo GRE – Propósito
O processo GRE tem por objetivo o gerenciamento dos requisitos do produto e dos
componentes do produto do projeto, além da identificação de inconsistências entre os
requisitos, os planos do projeto e os produtos de trabalho do projeto (SOFTEX, 2009a, p. 28).
O principal objetivo deste processo é o controle da evolução de todos os requisitos recebidos
ou gerados pelo projeto, incluindo requisitos funcionais, não funcionais e os requisitos
impostos ao projeto pela organização (SOFTEX, 2009b, p. 18).
Neste processo, passos são definidos para assegurar que o conjunto de requisitos
acordados (1) é gerenciado e (2) fornece apoio às necessidades de planejamento e execução
do projeto. Estabelece que quando requisitos são recebidos, antes de serem incorporados ao
escopo do projeto, devem ser revisados e um compromisso entre as partes interessadas é
firmado.
Documentar todas as mudanças nos requisitos, garantir a rastreabilidade bidirecional
entre os requisitos e os produtos, além de identificar inconsistências entre requisitos, planos
do projeto e produtos de trabalho do projeto também fazem parte das atribuições do Processo
de Gerência de Requisitos.
4.4.2 Processo GRE – Resultados Esperados
Segundo a SOFTEX (2009b, p. 20), esperam-se cinco resultados da implementação do
processo GRE, a saber:
GRE 1 – Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores
responsáveis de requisitos, utilizando critérios objetivos. Ou seja, é preciso garantir que os
requisitos estejam claramente definidos, comprovados através de um documento de requisitos
– que pode ter o formato que melhor atender as necessidades da organização. Após a
41
identificação dos requisitos, eles precisam ser avaliados, tanto pela equipe técnica da
organização quanto pelo cliente, com base em critérios que garantam que os requisitos
propostos atendem às necessidades e expectativas do cliente e dos usuários. Um registro de
aceite dos requisitos aprovados, obtido pelos fornecedores de requisitos será um marco do
projeto, a partir do qual todas as mudanças nos requisitos deverão ser tratadas no interesse de
minimizar o impacto dessas mudanças no projeto em termos de escopo, estimativas e
cronograma. A cada mudança nos requisitos aprovada, deve-se prover uma avaliação e
registro de aceite da mudança aprovada.
GRE 2 – O Comprometimento da equipe técnica com os requisitos aprovados é
obtido. Os requisitos aprovados pelos critérios estabelecido no GRE1 deverão obter o
comprometimento da equipe técnica. Para formalizar que toda a equipe técnica tem
conhecimento e aprovam os requisitos, um documento deve ser registrado, por exemplo, uma
ata de reunião, e-mail ou algum outro mecanismo. A cada mudança registrada nos requisitos,
um novo comprometimento da equipe deve ser obtido (SOFTEX, 2009b, p. 21).
GRE 3 – A rastreabilidade bidirecional entre os requisitos e os produtos de
trabalho é estabelecida e mantida. Obter esse resultado significa que é possível rastrear a
dependência entre os requisitos e o produto de trabalho, ou seja, quais artefatos são de quais
produtos. Desta forma, facilitando a avaliação do impacto das mudanças nos requisitos, por
exemplo, nas estimativas, nos produtos ou tarefas do projeto (SOFTEX, 2009b, p. 21).
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. O que resulta no
estabelecimento de algum mecanismo para identificação de inconsistências entre os requisitos
e os demais elementos do projeto. Todas as inconsistências identificadas devem ser
registradas e ações corretivas deverão ser tomadas a fim de resolvê-las, sendo que estas ações
deverão ser acompanhadas até que as inconsistências sejam resolvidas (SOFTEX, 2009b, p.
21-22).
GRE 5 – Mudanças nos requisitos são gerenciadas ao longo do projeto. Como é
raro não haver mudanças nos requisitos ao longo do projeto, espera-se que a organização
realize o gerenciamento das mudanças que venham a ocorrer. As mudanças devem ser
42
registradas, juntamente com um histórico das decisões tomadas, que deverão ser tomadas com
base na análise do impacto da mudança no projeto (SOFTEX, 2009b, p. 22).
Estes são os cinco resultados esperados do propósito do processo de Gerência de
Requisitos, que juntamente com o processo de Desenvolvimento de Requisitos são os
processos que atuam na gestão dos requisitos no MPS.BR, A seguir, faz-se uma análise do
processo Desenvolvimento de Requisitos, seu propósito e resultados esperados.
4.5 Processo de Desenvolvimento de Requisitos
O processo de Desenvolvimento de Requisitos (DRE) está presente no nível D de
maturidade do MPS.BR. Evoluir para o nível D implica na definição de processos geralmente
mencionados como sendo relacionados à engenharia de requisitos propriamente dita.
Neste nível, cinco novos processos são implementados, que incrementam a capacidade
de definição dos processos já alcançada no nível E, e que inclui todos os processos que
pertencem aos níveis G e F do MPS.BR.
A SOFTEX (2009c, p.6-7) indica que os processos do nível D sejam implementados
de forma iterativa e alinhados ao ciclo de vida definido do produto, indicando inclusive uma
possível sequência de execução dentro do processo de desenvolvimento, sendo:
Desenvolvimento de Requisitos (DRE), Projeto e Construção do Produto (PCP), Integração
do Produto (ITP), Verificação (VER) e Validação (VAR).
Detalhes do processo DRE, objeto de estudo deste trabalho, são apresentados a seguir.
Para este processo os Atributos de Processos (capacidades) esperados são:
• O processo é executado (RAP 1);
• O processo é gerenciado (RAP 2, RAP 3, RAP 4, RAP 5, RAP 6, RAP 7, RAP
8, RAP 9, RAP 10);
• Os produtos de trabalho do processo são gerenciados (RAP 11, RAP 12,
RAP13, RAP 14);
43
• O processo é definido (RAP 15, RAP16, RAP 17, RAP 18) e;
• O processo está implementado (RAP 19, RAP 20, RAP 21, RAP 22)
4.5.1 Processo DRE – Propósito
Ao implementar o processo de Desenvolvimento de Requisitos, a organização terá
como propósito definir os requisitos do cliente, do produto e dos componentes do produto
(SOFTEX, 2009a, p. 38), atendendo assim a necessidade de todos os envolvidos no projeto. O
levantamento de requisitos e seu gerenciamento, além do refinamento dos mesmos, a
descrição em termos técnicos, dos cenários e conceitos operacionais requeridos são
elaborados em um nível de detalhes que permite a realização de projetos técnicos para a
resolução do problema em questão (SOFTEX, 2009c, p.7).
4.5.2 Processo DRE – Resultados Esperados
Os requisitos do cliente, do produto e dos componentes do produto deverão ser
analisados, validados e gerenciados ao longo do ciclo de desenvolvimento ou de manutenção
do produto, o que faz com que os resultados esperados do processo DRE estejam relacionados
aos resultados esperados dos processos PCP, GRE, VER e VAL, por serem produtos
requeridos para sua execução ou por terem uma interface com o processo propriamente dito
(SOFTEX, 2009c, p. 7).
O processo DRE possui oito resultados esperados, como segue:
DRE 1 – As necessidades, expectativas e restrições do cliente, tanto do produto
quanto de suas interfaces, são identificadas. Segundo a SOFTEX (2009c, p. 10), para se
alcançar este resultado, é preciso utilizar algum método adequado para identificar as
necessidades, expectativas e restrições do cliente, também comenta algumas técnicas de
elicitação de requisitos, como: entrevistas; questionários; construção de cenários operacionais
e análise de tarefas do usuário final; protótipos e modelos; técnicas facilitadoras de
especificação de aplicações (como, por exemplo, JAD); casos de uso; brainstorming;
observação de produtos e ambientes existentes; análise de casos de negócio; estudo de fontes
44
de informação como documentos, padrões ou especificações; etnografia; QFD (Quality
Function Deployment) e engenharia reversa (para sistemas legados); e estórias de usuários
(Metodologias ágeis);
DRE 2 – Um conjunto definido de requisitos do cliente é especificado a partir das
necessidades, expectativas e restrições identificadas. As necessidades, expectativas e
restrições identificadas, deverão ser transformadas em requisitos do cliente (SOFTEX, 2009c,
p. 11);
DRE 3 – Um conjunto de requisitos funcionais e não funcionais, do produto e dos
componentes do produto que descrevem a solução do problema a ser resolvido, é
definido e mantido a partir dos requisitos do cliente. Ou seja, o resultado alcançado deve
ser a consolidação das necessidades, expectativas e restrições do cliente na forma de
requisitos do produto e dos componentes do produto. A SOFTEX (2009c, p. 11-12), destaca
que definir os requisitos funcionais envolve analisar os requisitos do cliente, identificando as
funções que são necessárias ao produto. Os requisitos funcionais descrevem as funções ou
serviços que são esperados do sistema que será gerado. Os requisitos não funcionais são
requisitos que impõe condições ou qualidades que são específicas que o produto e/ou seus
componentes devem atender.
DRE 4 – Os requisitos funcionais e não funcionais de cada componente do
produto são refinados, elaborados e alocados. Para se alcançar este resultado implica em
derivar requisitos funcionais e não funcionais que resultem de decisões de projeto; alocar
requisitos funcionais e não funcionais e restrições para cada um dos componentes do produto;
e estabelecer os relacionamentos entre os requisitos do cliente e os requisitos funcionais e não
funcionais de cada um dos componentes do produto, de acordo com o processo de Gerência
de Requisitos. É necessário comprovar que o conjunto de requisitos funcionais e não
funcionais foi refinado, detalhado e documentado durante o ciclo de vida do desenvolvimento
do produto e de seus componentes (SOFTEX, 2009c, p. 12);
DRE 5 – Interfaces internas e externas do produto e de cada componente do
produto são definidas. Isso será útil para projetar e construir os componentes do produto.
Geralmente as definições são quanto aos tipos e formatos de dados de entrada e saída entre os
45
componentes, especificações de protocolo de comunicação, entre outros (SOFTEX, 2009c. p.
13);
DRE 6 – Conceitos operacionais e cenários são desenvolvidos. Os cenários podem
ser modelados por UML (Unified Modeling Language), no qual o cenário é uma seqüência
específica de ações que ilustra o comportamento de um caso de uso. Para se alcançar este
resultado, é necessário definir o ambiente de operação do produto, seus limites e restrições;
também é necessário elaborar um conceito operacional detalhado, do produto e seus
componentes, que defina a interação do produto, do usuário final e do ambiente, de maneira a
satisfazer as necessidades de operação, manutenção e apoio; e revisar os conceitos
operacionais e cenários para refinar e descobrir novos requisitos (SOFTEX, 2009c, p. 13-14);
DRE 7 – Os requisitos são analisados, usando critérios definidos, para balancear
as necessidades dos interessados com as restrições existentes. Isso determinará se os
requisitos, analisados em conjunto com os cenários e conceitos operacionais, são necessários,
corretos, testáveis e suficientes para atingir os objetivos e requisitos do cliente (SOFTEX,
2009c, p. 14);
DRE 8 – Os requisitos são validados. Este resultado visa garantir que os requisitos
sejam validados através de técnicas adequadas, o que garantirá o desempenho do produto no
seu ambiente alvo, além de permitir que problemas sejam encontrados, evitando retrabalho e
custos (SOFTEX, 2009c, p. 14-15);
Modelos para Maturidade de Melhoria do Processo Software, como o MPS.BR, são
hoje referências no mercado como boas práticas fornecidas de como o processo, e
consequentemente, o produto de software, podem ser melhorados e avaliados.
Ao finalizar a descrição dos resultados esperados dos processos relacionados a
requisitos, do MPS.BR, em conjunto com as informações adquiridas sobre requisitos (capítulo
02) e Scrum (capítulo 03), possível propor o mapeamento e alinhamento destes, conforme
será apresentado no capítulo a seguir.
46
5 METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E
DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR
Organizações que buscam a melhoria de seus processos através de modelos como o
MPS.BR e que acreditam que a introdução de conceitos ágeis, como o Scrum, em seus
processos é uma alternativa capaz de promover a melhoria de qualidade dos seus produtos, e
consequentemente, aumento da competitividade no mercado (SZIMANZKI, 2009), podem
necessitar de orientação que demonstre a possibilidade da aplicação prática conjunta de
MPS.BR e Scrum.
Para que a organização atinja maturidade e agilidade através do MPS.BR e Scrum, é
necessário que ambos modelos possam ser realizados em conjunto e que suas práticas e
objetivos sejam satisfeitas. Assim, o presente capítulo apresenta o mapeamento MPS.BR e
Scrum. Pretende-se atender os resultados esperados dos processos de Gerência e
Desenvolvimento de Requisitos do MPS.BR e satisfazer todos os preceitos da prática do
Scrum.
5.1 Mapeamento entre os processos GRE e DRE com Scrum
Para analisar se as práticas encontradas no Scrum satisfazem cada um dos resultados
esperados dos processos de Gerência e Desenvolvimento de Requisitos do MPS.BR, foram
definidos os critérios apresentados na tabela 4. Os critérios demonstram o quanto uma prática
Scrum pode estar presente em um resultado de processo, como: é possível evidenciar
(Satisfeito), evidencia-se em parte (Parcialmente Satisfeito) e não é possível evidenciar que a
prática Scrum pode atender um resultado de processo.
Tabela 4 – Critérios de análise do uso conjunto das metodologias
Classificação Critérios
Não Satisfeito Não há evidências da prática na metodologia
Parcialmente Satisfeito Há evidências da prática na metodologia, embora a prática não esteja plenamente atendida.
Satisfeito A prática está totalmente atendida na Metodologia.
Fonte: inspirada em SZIMANSKI, 2009.
47
Para cada um dos processos, foi realizada uma análise detalhada dos resultados
esperados em relação às práticas encontradas no Scrum, classificando cada resultado esperado
de acordo com os critérios estabelecidos na tabela 4. Abordagem similar já foi utilizada e
apresentada à comunidade científica, como na obra “Implementando maturidade e agilidade
em uma fábrica de software através de Scrum e MPS.BR nível G”, de Szimanski (2009). No
entanto, o foco de pesquisa foram os processos do nível G e o que se propõe é o mapeamento
entre os processos GRE e DRE do MPS.
As tabelas 5 e 6 ilustram a ordem de mapeamento, o processo MPS e o resultado
esperado, a classificação de acordo com os critérios de análise e um resumo das práticas
Scrum que podem atender ao resultado esperado. Após o resumo do mapeamento, é
apresentada uma descrição para cada alinhamento entre resultado esperado e práticas (MAP).
O processo de Gerência de Requisitos é composto por cinco resultados esperados, já
detalhados no capítulo 4, de forma correspondente, a tabela a seguir apresenta cinco
mapeamentos entre este processo com as práticas Scrum (tabela 5).
Tabela 5 – Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum
Map
ea-
men
to MPS.BR – Nível G
Gerência de Requisitos (GRE) Scrum
Abrev. Resultados Classificação Resumo das Práticas
MAP 1 GRE 1
Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos
SATISFEITO
Elaboração do Backlog do Produto, Backlog da Versão para Entrega e
Backlog da Sprint, priorizados por Business
Value e Retorno do Investimento
MAP 2 GRE 2 O comprometimento da equipe técnica com os requisitos aprovados é obtido
SATISFEITO
Planejamento da Versão para Entrega e geração do Backlog do Produto para
a Versão
MAP 3 GRE 3
A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida
NÃO SATISFEITO
Prática não mencionada no Scrum
MAP 4 GRE 4
Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e corrigir inconsistências em relação aos requisitos
SATISFEITO Reunião Diária,
Revisão e Retrospectiva da Sprint
MAP 5 GRE 5 Mudanças nos requisitos são SATISFEITO Planejamento da Versão
48
gerenciadas ao longo do projeto
para Entrega, Reunião Diária,
Revisão e Retrospectiva da Sprint
Fonte: Autor.
O resumo da análise do mapeamento do processo de Desenvolvimento de Requisitos é
apresentado na tabela 6. Esse processo é composto por oito mapeamentos, que correspondem
aos resultados esperados.
Tabela 6 – Resumo do mapeamento entre o processo DRE do MPS.BR e Scrum
Map
ea-
men
to MPS.BR – Nível D
Desenvolvimento de Requisitos (DRE) Scrum
Abrev. Resultados Classificação Resumo das Práticas
MAP 6 DRE 1
As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces, são identificadas
SATISFEITO
Elaboração do Backlog do Produto,
Reunião de Planejamento da Versão para Entrega e
Reunião de Planejamento da Sprint
MAP 7 DRE 2
Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, expectativas e restrições identificadas
SATISFEITO
Backlog do Produto, Backlog do Produto para
a Versão e Backlog da Sprint
MAP 8 DRE 3
Um conjunto de requisitos funcionais e não-funcionais, do produto e dos componentes do produto que descrevem a solução do problema a ser resolvido, é definido e mantido a partir dos requisitos do cliente
SATISFEITO Reunião de
Planejamento da Sprint
MAP 9 DRE 4
Os requisitos funcionais e não-funcionais de cada componente do produto são refinados, elaborados e alocados
SATISFEITO Backlog da Sprint
MAP 10 DRE 5
Interfaces internas e externas do produto e de cada componente do produto são definidas
PARCIALMENTE SATISFEITO
Backlog do Produto, Backlog do Produto para
a Versão e Backlog da Sprint
MAP 11 DRE 6 Conceitos operacionais e cenários são desenvolvidos
PARCIALMENTE SATISFEITO
Reuniões de Planejamento da Versão para Entrega e da Sprint
MAP 12 DRE 7
Os requisitos são analisados, usando critérios definidos, para balancear as necessidades dos interessados com as
SATISFEITO Reuniões de
Planejamento da Versão para Entrega e da Sprint
49
restrições existentes
MAP 13 DRE 8 Os requisitos são validados SATISFEITO Conceito de
“Software Pronto”
Fonte: Autor.
Uma descrição detalhada dos mapeamentos gerados entre os processos de Gerência de
Requisitos e Desenvolvimento de Requisitos do MPS.BR com a prática da metodologia ágil
Scrum é apresentada a seguir, conforme ilustrado nas tabelas 5 e 6:
MAP 1 – No Scrum os requisitos são entendidos diretamente com os clientes, cabendo
ao Product Owner (PO) identificar tanto os requisitos como os fornecedores de requisitos. O
PO deve avaliar os requisitos, obtendo como resultado o Backlog do Produto (BP). O PO
deve usar como critério a priorização por Business Value (BV) e Retorno do Investimento
(ROI). O mesmo BP é refinado e os requisitos são novamente analisados quando o Time
Scrum (TS) define o Backlog do Produto para a Versão (BPV) e o Backlog da Sprint (BS).
Para registrar toda a comunicação realizada, artefatos como estórias de usuário, Atas, BP,
Plano de Execução do Projeto, podem ser gerados. Cabe ressaltar que o MPS.BR não indica o
formato dos artefatos que devem ser gerados, ficando a critério da organização. Portanto o
Scrum atende ao resultado esperado GRE 1.
MAP 2 – Scrum atende o resultado esperado GRE 2. Através da Reunião de
Planejamento da Versão para Entrega (RPVE), PO e ScrumMaster (SM) trabalham para que
todo o TS entre em acordo sobre o entendimento dos requisitos, gerando planos e metas que
formarão o BPV. Desta forma, a equipe técnica está se comprometendo com requisitos
aprovados a partir de critérios estabelecidos conforme GRE 1.
MAP 3 – Scrum não atende a GRE 3, a rastreabilidade bidirecional entre os requisitos
e os produtos de trabalho não é mencionada na prática Scrum. Uma possível solução será
abordada mais adiante, onde se apresentam sugestões para cobrir incompatibilidades com o
MPS.BR. Verificar GAP 1, no tópico “5.3 Estendendo o Scrum”, neste capítulo.
MAP 4 – O resultado esperado GRE 4 é atendido pelo Scrum. O objetivo deste
resultado esperado, a necessidade de revisões em planos e produtos de trabalho do projeto,
realizadas visando à identificação e correção de inconsistências em relação aos requisitos é
uma das maiores evidências na prática Scrum. As Reuniões Diárias, a Reunião de Revisão da
50
Sprint e a Reunião de Retrospectiva da Sprint, além do fluxo de desenvolvimento do Scrum, o
capacitam a abraçar mudanças ao longo do projeto, permitindo que o projeto esteja apto, a
partir de constantes revisões, a identificar e corrigir as mudanças de requisitos que ocorrerão
ao longo do desenvolvimento do projeto.
MAP 5 – Satisfeito pela prática Scrum. Assim como no MAP 4, características
elementares do Scrum encaminham para que as mudanças nos requisitos sejam gerenciadas ao
longo do projeto. Uma vez que com a RPVE, as Reuniões Diárias, e as Reuniões de Revisão e
Retrospectiva da Sprint garantem um gerenciamento das mudanças dos requisitos, ficando a
critério do TS a forma de documentar as mudanças, podendo ser através de estórias de
usuário, ou alguma outra ferramenta que também seja adequada para este fim.
MAP 6 – As necessidades, expectativas e restrições do cliente, tanto do produto
quanto de suas interfaces, são identificadas na fase de elaboração do BP e nas Reuniões de
Planejamento da Versão para Entrega e de Planejamento da Sprint, realizadas pelo TS. Os
artefatos gerados, BP, BPV e BS devem conter itens que traduzam as necessidades,
expectativas e restrições do cliente e do produto que foram identificadas. Cabe ressaltar que
tanto MPS.BR como Scrum não determinam qual o método mais adequado para identificar
necessidades, expectativas, restrições do cliente, apenas exemplificam técnicas de elicitação
de requisitos, como entrevistas, questionários, casos de uso, estórias de usuário, outros.
MAP 7 – Scrum satisfaz DRE 2. Ao elaborar o BP, BPV e BS, se obtém como
produto de trabalho, conjuntos definidos de requisitos do cliente. Todos os conflitos e
questões relevantes a serem verificadas ou validadas deverão ser resolvidos através da
elaboração do BP pelo PO e das Reuniões de Planejamento da Versão para Entrega e de
Planejamento da Sprint, realizadas pelo TS.
MAP 8 – Scrum atende ao DRE 3 através da reunião de Planejamento da Sprint. É
com a elaboração do BS que os requisitos funcionais e não-funcionais, do produto e dos
componentes do produto, são definidos e mantidos.
MAP 9 – O alcance deste resultado é evidenciado pelo Backlog da Sprint. É na
elaboração do BS que os requisitos funcionais e não funcionais são refinados, detalhados e
documentados. Portanto, Scrum atende ao DRE 4.
51
MAP 10 – Na prática Scrum, não há uma definição explícita quanto à definição de
interfaces internas e externas do produto e de cada componente do produto, no entanto,
espera-se que estas definições sejam feitas em ou no BP, pelo PO, ou em outras fases como na
reunião que define o BP para Versão de Entrega, ou no BS, realizados pelo TS. Desta
maneira, o resultado esperado DRE 5 é parcialmente satisfeito pelo Scrum. Verificar GAP 2,
no tópico “5.3 Estendendo o Scrum”.
MAP 11 – Mais uma vez, Scrum não indica o que deve ser realizado, mas deixa
espaço, através das reuniões de Planejamento da Versão para Entrega do Planejamento da
Sprint, para que os conceitos operacionais e cenários sejam desenvolvidos pelo TS. Scrum
atende parcialmente ao DRE 6. Verificar GAP 3, no tópico “5.3 Estendendo o Scrum”.
MAP 12 – Na prática do Scrum, por primar pelo empirismo, espera-se que o TS tenha
a experiência necessária para analisar os requisitos, levando em conta os critérios definidos,
os cenários, conceitos operacionais e todo o fluxo de desenvolvimento do produto. Não há
uma fase específica que satisfaça DRE 7, porém Scrum dispõe dos momentos apropriados
para tarefas que satisfaçam o resultado esperado, como as reuniões de Planejamento da
Versão para Entrega e da Sprint. Scrum atende DRE 7.
MAP 13 – Scrum atende a DRE 8. A prática Scrum, assim como o resultado esperado
DRE 7, não determina a melhor forma de validação dos requisitos, porém na metodologia
ágil, o TS deve ter definido claramente o que é “Software Pronto”, e isso deve incluir a
garantia de que o produto terá o desempenho adequado quando entregue ao cliente.
Feitas as análises, segue um resumo dos resultados encontrados do mapeamento entre
os modelos.
5.2 Resultado do mapeamento entre os processos GRE e DRE com Scrum
O mapeamento, alinhamento e comparativo dos processos GRE, DRE e as práticas
Scrum tiveram por objetivo verificar a compatibilidade entre os modelos. Com isto,
descobriu-se que o Scrum satisfaz boa parte dos resultados esperados dos processos
analisados, no entanto, alguns resultados não podem ser atendidos
tabela 7 e no gráfico 2.
Critérios
Satisfeito
Parcialmente satisfeito
Não satisfeito
Fonte: Autor.
Fonte: Autor.
Ao observar os resultados, percebe
ou que carecem de atenção por parte da organização
ao MPS.BR, este é o caso dos seguintes resultados não atendidos pelos Scrum: (1) a
rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e
analisados, no entanto, alguns resultados não podem ser atendidos, conforme apresentado na
Tabela 7 – Resultado da avaliação
GRE DRE
80% 75%
atisfeito 0% 25%
20% 0%
Gráfico 2 – Resultado da avaliação
Ao observar os resultados, percebe-se que há, no Scrum, algumas atividades ausentes
ou que carecem de atenção por parte da organização, para que este esteja totalmente alinhado
este é o caso dos seguintes resultados não atendidos pelos Scrum: (1) a
rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e
52
conforme apresentado na
algumas atividades ausentes
totalmente alinhado
este é o caso dos seguintes resultados não atendidos pelos Scrum: (1) a
rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e
53
mantida, (2) Interfaces internas e externas do produto e de cada componente do produto são
definidas, (3) Conceitos operacionais e cenários são desenvolvidos.
Neste trabalho, são apresentadas sugestões que visam alinhar totalmente o Scrum aos
processos GRE e DRE do MPS.BR, sem que haja uma deturpação dos preceitos empregados
nas metodologias ágeis.
Assim, entende-se que a metodologia ágil Scrum possibilita novas formas para
realização da melhoria de processo, principalmente em ambientes de mudanças constantes,
como a área de requisitos de software, aproveitando a experiência de cada um dos indivíduos
e a agilidade com que cada um dos times tem para se adaptar a uma nova situação.
5.3 Estendendo o Scrum
Alterar as características de um framework seria criar um novo framework. Na
tentativa de alinhar o Scrum aos processos GRE e DRE do MPS.BR, foram adicionadas
características visando não modificar os principais elementos da metodologia ágil, entendendo
desta forma, como uma extensão do Scrum.
Para cada lacuna (GAP) identificada no alinhamento realizado, serão propostas
sugestões que podem contribuir para o completo alinhamento entre os modelos.
GAP 1 – A prática Scrum não menciona o rastreamento bidirecional dos requisitos,
isso pode ser facilmente resolvido com a geração de um artefato como uma matriz de
rastreabilidade. Essa matriz deve possuir a identificação dos requisitos e permitir a
rastreabilidade bidirecional horizontal e vertical dos mesmos, estabelecendo as dependências
entre os requisitos, os produtos de trabalho em um mesmo nível (horizontal) ou em níveis
diferentes (vertical). Esta sugestão é embasada no relato de Campos (2008), que indica que
esta prática já é adotada por algumas organizações.
GAP 2 – Scrum não define em que momento interfaces internas externas do produto e
de cada componente do produto devem ser definidas, apenas fornece eventos onde esta
definição pode ocorrer. Para que o método ágil satisfaça a esta necessidade do MPS, a
54
sugestão é que a organização determine junto ao Time Scrum em que etapa do ciclo de
desenvolvimento ocorrerão estas definições.
GAP 3 – Assim como em GAP 2, Scrum apenas fornece eventos onde a ação pode
ocorrer, mas não determina quais ações o Time Scrum deve realizar, pois a metodologia ágil
defende que o Time Scrum deve ser auto-suficiente e maduro para tomar as decisões
necessárias ao desenvolvimento. Cabe então a organização, juntamente com o Time Scrum,
determinar como, e quando ocorrerá o desenvolvimento do cenário operacional do produto.
Cabe ressaltar que, para que a organização esteja alinhada com a correta filosofia do
desenvolvimento ágil, qualquer característica adicionada ou modificada no ciclo de
desenvolvimento Scrum, deve levar em conta as definições e regras que envolvem cada papel
e evento do framework Scrum.
55
6 APOIO A PRÁTICA DE SCRUM E PROCESSOS DE GERÊNCIA E
DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR
Neste capítulo, os temas abordados serão revistos com um enfoque prático, no intuito
de compilar informações sobre problemas que podem ocorrer na prática dos processos GRE e
DRE, do Scrum e problemas relacionados a requisitos de software, como eles podem se
complementar, contribuindo para que organizações possam minimizar estes problemas.
A validação prática da aplicação de Scrum aos processos GRE e DRE diretamente em
uma organização se mostra uma tarefa complexa, no caso da implantação do nível G do
MPS.BR, algumas empresas podem levar de 12 a 18 meses para atingirem este nível, como no
caso da empresa Prodabel (SOUZA, 2007), que realizou um projeto de implantação com
previsão de 15 meses para alcançar este nível do MPS.
Travassos (2009), em “iMPS 2009: Caracterização e Validação de Desempenho de
Organizações que Adotaram o Modelo MPS”, aponta que empresas no estágio inicial do
modelo MPS tiveram uma redução da produtividade, um aumento no custo médio dos
projetos e um percentual significativo de empresas em que não houve alteração na
satisfação do cliente.
Gráfico 3 – Variação de desempenho de 22 empresas com MPS – Níveis G
Fonte: TRAVASSOS, 2009.
O gráfico 3 mostra o resultado da variação 2008-2009 de desempenho de 22 empresas
com MPS nível G, onde cada indicador sinaliza cada um dos itens avaliados e o nível de
56
confiança3, que tenta sugerir o quanto o comportamento descrito pelo indicador poderia estar
representando o comportamento das empresas considerando o grupo específico sob análise
(TRAVASSOS, 2009).
O mesmo trabalho mostra que as empresas, ao alcançarem níveis maiores de
maturidade, conseguem mudar positivamente este cenário. A seguir, são apresentados alguns
problemas práticos encontrados na implementação do processo GRE e como a aderência as
práticas Scrum pode contribuir para maximizar os resultados, contrastando com os resultados
apresentados no gráfico 3.
6.1 Dificuldades práticas na implantação do processo GRE
Estando o processo GRE presente no nível inicial do MPS, algumas das dificuldades
encontradas na sua implementação têm forte relação com as mudanças na cultura
organizacional necessárias para o emprego do MPS.BR. A tabela 8 mostra alguns exemplos
de dificuldades relatadas e como as práticas ágeis podem contribuir para minimizar estes
problemas.
Tabela 8 – Dificuldades encontradas no MPS.BR e possíveis soluções pelo Scrum
Dificuldades no uso inicial do MPS.BR Possíveis soluções com Scrum
Membros do projeto não compreendem os processos como um todo, o que gera resistências na adequação ao modelo;
Scrum possui um fluxo simples, de fácil compreensão; O ScrumMaster tem a responsabilidade em fazer com que todos os envolvidos compreendam o fluxo de desenvolvimento e o emprego dos princípios e valores ágeis, o que traz para todos os envolvidos um maior conhecimento do processo de desenvolvimento como um todo;
Membros do projeto não compreendem os motivos da necessidade de confecção de artefatos que evidenciam os resultados esperados;
Mudanças necessárias ao projeto são descartadas devido a etapas burocráticas;
Mudanças são abraçadas por equipes ágeis; As metodologias ágeis formam frameworks que permitem que as mudanças sejam avaliadas e incorporadas com facilidade; Scrum permite a formação de equipes confortáveis às mudanças;
Mudanças necessárias ao projeto somente são incorporadas ao processo após o término do projeto;
Métodos ágeis prevêem que as mudanças devem ocorrer dentro do próprio projeto de desenvolvimento, entre as Sprints, quando
3 Indicador calculado considerando-se a população como sendo o número total de questionários válidos
para cada grupo e a amostra do número de respostas válidas para cada questão (TRAVASSOS, 2009).
57
identificadas nas Reuniões de Revisão e Retrospectiva das Sprints;
Foco nos processos e não nas pessoas;
Em implementações falhas do MPS, os colaboradores envolvidos podem achar que, por culpa do MPS, a organização passa a dar mais valor aos processos do que as pessoas. Isso é uma inverdade com relação ao MPS e Scrum pode auxiliar a evitar este tipo de problema por ter grande foco no entendimento e experiência do Time Scrum;
Faltam referências quanto a design, codificação, ferramentas, testes automatizados, etc.
Na implementação dos processos iniciais do MPS o enfoque inicial é do ponto de vista da organização gerencial, deixando para os próximos níveis questões como design, codificação, ferramentas, testes automatizados, etc. Porém ao empregar Scrum em conjunto com estes processos, a equipe terá como referência os valores e princípios ágeis, que incorporam estas questões dentro do ciclo de desenvolvimento ágil;
Faltam referências quanto ao gerenciamento de riscos.
Obrigação de gerar documentos sem explicar detalhes de como fazê-los.
MPS.BR não obriga a geração de documentos específicos, porém formalizações são necessárias para comprovar os resultados esperados. Os artefatos gerados na prática Scrum podem ser utilizados para evidenciar os resultados esperados dos processos MPS, eles foram criados para serem simples, de fácil assimilação e para que seu uso maximize o entendimento do Time Scrum sobre o processo de desenvolvimento;
Fonte: BERNABÓ, 2007; RIBEIRO, 2007; Autor.
6.2 Dificuldades práticas relacionadas a requisitos de software
Por GRE e DRE tratarem sobre requisitos de software, alguns problemas práticos
relacionados a requisitos de software acabam por dificultar a implementação dos processos do
MPS. A tabela 9 mostra alguns problemas e como as práticas ágeis podem contribuir para
minimizá-los.
Tabela 9 – Dificuldades encontradas em Requisitos e possíveis soluções pelo Scrum
Dificuldades relacionadas a Requisitos Possíveis soluções com Scrum
Envolvimento interessados inapropriados na elicitação dos requisitos;
O levantamento dos requisitos é responsabilidade do Product Owner, cabendo a ele focar quem são os stakeholders;
Problemas políticos na organização, resultando em reestruturação de papéis e a mudança de visão do negócio, com impacto na mudança de escopo;
No caso de mudanças, como a troca do responsável pelo Backlog do Produto, Scrum permite que, através de iterações curtas e incrementais, a equipe possa adaptar-se a mudanças, portanto no caso de uma mudança na visão do negócio, os métodos
58
ágeis levam vantagem por adaptarem-se mais rapidamente as mudanças que os métodos tradicionais; Isso tem impacto em todo o planejamento do projeto;
Detalhamento técnico desnecessário durante a especificação funcional do sistema;
Um dos princípios das Metodologias ágeis é a simplicidade, que pode colaborar para evitar informações desnecessárias nas especificações;
Complexidade no detalhamento dos casos de uso para definição da solução;
Metodologias ágeis introduzem as estórias de usuário (user stories), que são descrições textuais sucintas sobre as funcionalidades do sistema, escritas pela equipe técnica em conjunto com o cliente. Isso intensifica o envolvimento com o cliente, gera requisitos menos complexos, não deixando de serem informativos a respeito do requisito a ser desenvolvido.
Dificuldades para validação de casos de uso por parte do usuário;
Falta de conhecimento dos analistas de requisitos em um domínio específico do problema.
Alteração constante dos requisitos, causando retrabalho;
Apesar de Scrum abraçar mudanças, após o Time Scrum selecionar quais itens do Backlog do Produto farão parte da Sprint, estes itens não deverão sofrer alterações; Cabe ao Product Owner gerenciar as mudanças necessárias aos itens do Backlog do Produto;
Fonte: NASCIMENTO, 2009; Autor.
6.3 Dificuldades práticas relacionadas ao Scrum
A implantação de metodologias ágeis também se mostra complexa, por exigir uma
mudança na cultura e na forma de realizar os processos. A tabela 10 mostra algumas das
dificuldades encontradas na implementação de Scrum e como MPS.BR pode contribuir para
minimizá-las.
Tabela 10 – Dificuldades encontradas em Scrum e possíveis soluções pelo MPS.BR
Dificuldades relacionadas ao Scrum Possíveis soluções com o MPS.BR
Por valorizar o Software Pronto mais que documentações abrangentes, muitas organizações interpretam que métodos ágeis, como o Scrum, não há documentação dos produtos desenvolvidos, o que é uma inverdade. Scrum defende que se deve ter a documentação suficiente para o entendimento de todos os envolvidos, ao invés de uma documentação gigantesca que toma grande tempo para a confecção e desestimula os usuários do produto a lerem;
Neste caso, MPS.BR pode fazer com que equipes ágeis tenham documentos mais abrangentes do que talvez teriam caso não tivessem a necessidade de evidenciar os resultados esperados;
O suporte a equipes distribuídas por acarretar vários problemas que inexistem quando os integrantes da equipe de desenvolvimento e do cliente se encontram próximos;
O uso de uma documentação formal pode ser necessário; MPS pode contribuir por formalizar processos e por ter documentações mais abrangentes;
59
O tamanho do projeto pode ser considerado uma limitação ao Scrum; Quanto maior a equipe, mais complexa é a comunicação, o que torna o processo menos ágil;
Rastreabilidade bidirecional dos requisitos;
A necessidade da comprovação da rastreabilidade bidirecional, exigida pelo MPS, contribui para que o método ágil também tenha esta avaliação, que permite uma análise mais confiável do impacto das mudanças nos requisitos, com relação ao produto de trabalho;
Pelos princípios ágeis, as decisões do time têm mais prioridade que as decisões da organização. Isso resulta na falta de definição de um padrão de processo;
Através de processos bem elaborados e documentados, Times Scrum podem ter uma base para tomar as suas decisões;
O time de desenvolvimento não segue todos os preceitos da prática Scrum;
Em uma organização que será avaliada em MPS, os processos estabelecidos precisam ser seguidos, logo, se os preceitos do Scrum estiverem determinados dentro dos processos, a equipe terá de desempenhá-los, sob o risco de não estarem cumprindo com o determinado pelo processo;
Fonte: Autor.
E estas foram apenas algumas das dificuldades no desenvolvimento de software, que
tem relação com os temas abordados no trabalho. Como qualquer processo, o
desenvolvimento de software tem entradas, processamentos e saídas que precisam estar bem
claros e bem definidos para todos os envolvidos.
6.4 Além das limitações de MPS e Scrum
Dada as especificidades, as soluções adotadas pelas organizações podem variar, até
porque não há uma solução completa para todos os processos envolvidos. Modelos de
qualidade poderão auxiliar na organização dos processos; Frameworks para desenvolvimento
poderão impor uma cultura relacionada ao desenvolvimento, mas serão necessárias outras
soluções que complementem dificuldades que MPS.BR e Scrum não atendem ou atendem
parcialmente, como algumas respostas sobre “como fazer” determinados artefatos ou produtos
de trabalho ou quais as melhores práticas de engenharia de requisitos. Ainda há os problemas
relacionados com contratos de trabalho, como os relacionados com a pós-entrega do produto,
sua manutenção e o auxílio aos usuários. As organizações acabam por montar o seu próprio
conjunto de soluções que atendem as suas necessidades e assim, construindo o seu próprio
framework de trabalho.
60
7 CONCLUSÃO
Diante de problemas cada vez mais complexos, o ser humano sente a necessidade de
administrar, gerenciar, tornar as coisas mais simples para o seu próprio entendimento.
Na indústria do software, os requisitos são apenas uma das questões que envolvem o
desenvolvimento de software. Por mais que se passe a utilizar técnicas que melhorem a
elicitação dos requisitos, ainda assim há, dentre outras, a questão de como gerenciar estas
informações, como gerenciar os recursos disponíveis ou como gerenciar o projeto como um
todo.
Não há a resposta correta para todas as perguntas, mas há várias direções que podem
ser escolhidas pela organização. Scrum é uma delas. Os métodos ágeis vêm tomando espaço,
sendo tema de trabalhos e estudos, recebendo críticas e elogios. E dessa forma vem moldando
o nosso presente e futuro na maneira de fazer software.
Ao mesmo tempo, modelos como o MPS.BR, apresentam-se como uma possível
solução para as questões que atordoam as organizações, como a qualidade do processo. Estes
modelos também vêm sendo abordados em trabalhos e pesquisas, possibilitando que as
organizações tenham um bom embasamento no momento de tomar decisões.
Diferentes correntes nos levam a melhoria. Seja através de um MPS ou através de uma
metodologia ágil, o objetivo é o mesmo, o que muda são as formas de se obterem os
resultados e o que se busca são maiores possibilidades de atender aos requisitos do cliente.
Em realidade, o que se pode afirmar é que existe uma sinergia muito grande entre os modelos,
ou seja, um pode complementar o outro.
O mapeamento entre os processos de Gerência e Desenvolvimento de Requisitos com
o método ágil Scrum, busca um entendimento de como conciliar o Modelo MPS com o
método ágil, tirando o melhor proveito de ambos.
Com certeza, os temas abordados neste trabalho, jamais serão discutidos ao
esgotamento. Com certeza, jamais haverá um consenso sobre a melhor forma de trabalho para
uma organização. O que foi exposto aqui são apenas alternativas para as organizações que
61
desejam melhorar, não apenas seus produtos, mas também seus processos e comunicações
internas. De fato, o que se espera é que esse trabalho contribua para que as organizações
reflitam sobre como seus processos são executados e como é possível melhorá-los adotando
boas práticas.
7.1 Trabalhos futuros
Como sugestão para trabalhos futuros, indica-se:
• Aplicar o mapeamento proposto diretamente em uma organização.
• Apurar melhor os artefatos gerados resultantes do mapeamento.
• Validar se os artefatos indicados evidenciam os resultados esperados.
• Verificar se há necessidade de adaptações, ou até mesmo, se novos artefatos
serão necessários para o alinhamento preterido.
62
8 REFERÊNCIAS
AGILE MANIFESTO. Manifesto for Agile Software Development. 2001. Disponível em <http://agilemanifesto.org >. Acesso em: mar. 2010.
ANDRADE, C. et al. Projeto de Software Orientado a Objetos com UML 2.0. Revista SQL Magazine. Edição 45, Ano 4, Ed. DevMedia, 2007. p. 24-31.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS - ABNT. NBR ISO 9000:2000 – Sistema de gestão da qualidade e garantia da qualidade – Fundamentos e Vocabulário. Rio de Janeiro: ABNT, 2000.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR Guia Geral: 2009, 2009a. Disponível em <http://www.softex.com.br>. Acesso em: dez. 2009.
______ Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS, 2009b. Disponível em <http://www.softex.com.br>. Acesso em: dez. 2009.
______ Guia de Implementação – Parte 4: Fundamentação para Implementação do Nível D do MR-MPS, 2009c. Disponível em <http://www.softex.com.br>. Acesso em: dez. 2009.
ÁVILA, A. L.; SPÍNOLA, R. O. Introdução à Engenharia de Requisitos. Revista Engenharia de Software. Edição especial, Ano 1, 1ª ed, Ed. DevMedia, 2007. p. 46-51.
BECK, Kent; FOWLER, M. Extreme programming applied. Boston: Addison-Wesley, 2001.
BERNABÓ, Juran; NOVELLO, Alexandre; TELES, Vinícius Manhães. Improvecast 3 - CMM? MPS.BR? ISO? Não, tô fora! Disponível em <http://improveit.com.br/podcast/improvecast-3-cmm-mpsbr-iso-nao-to-fora>. Acesso em: maio de 2010. Publicado em 22 jun. 2007.
CAMPOS, A. C. C., et al. Apoiando a implementação do modelo de maturidade MPS Nível G. Revista Engenharia de Software. Ano 1, 7ª ed, Ed. DevMedia, 2008. p. 50-57.
CHIAVENATO, Idalberto. Introdução à Teoria Geral da Administração. 6ª ed. ver. E atualizada. Rio de Janeiro: Campus, 2000. p. 1-4.
63
______, Idalberto. Introdução à Teoria Geral da Administração. Vol. II. 6ª ed. ver. e atualizada. Rio de Janeiro: Campus, 2002.
DIAS, Marisa Villas Boas. Métodos Ágeis de Desenvolvimento de Software. Revista Engenharia de Software Magazine. Edição 20, Ano 2, Ed. DevMedia, 2010. p. 05-21.
DINIZ, Samuel. Desmistificando o MPS.BR – Gerência de Requisitos (GRE). Blog do Samuel Diniz. 2009a. Disponível em <http://blogdosamueldiniz.blogspot.com>. Acesso em: mar. 2010.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION – ISO. ISO/IEC 12207:2008 – Systems and software engineering -- Software life cycle processes. 2008. Disponível em < http://www.iso.org/>. Acesso em: abr. 2010a.
______. ISO/IEC 15504 – Information technology -- Process assessment. 2008. Disponível em < http://www.iso.org/>. Acesso em: abr. 2010b.
ISOTTON NETO, Erasmo. Scrumming: Ferramenta Educacional para Ensino de Práticas do Scrum. Pontifícia Universidade Católica do Rio Grande do Sul. Porto Alegre, 2008.
KNIBERG, Henrik. Scrum e XP direto das Trincheiras: Como nós fazemos Scrum. InfoQ. 2007. KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software: aprenda as metodologias mais modernas para o desenvolvimento de software. 1ª ed. São Paulo. Novatec Editora, 2006. p. 95-115.
MACHADO, M.; MEDINA, S. G. SCRUM – Método Ágil: uma mudança cultural na Gestão de Projetos de Desenvolvimento de Software. Revista Científica Intr@ciência. São Paulo: UNIESP, 2009.
NASCIMENTO, M. C.; KALINOWSKI, M.; SPÍNOLA, R. O. Soluções Concretas para Problemas Práticos da Engenharia de Requisitos. Revista Engenharia de Software. Ano 2, 13ª ed, Ed. DevMedia, 2009. p.8-15.
PÁDUA P. F. Wilson. Alguns Elementos de Engenharia de Software. Revista Engenharia de Software. Edição especial, Ano 1, 1ª ed, Ed. DevMedia, 2007. p. 4-8.
PARZIANELLO, Luiz Cláudio. Apostila do Curso Requisitos de Software: Conceitos e Práticas para Equipes Ágeis. Porto Alegre: [S.n.], 2009.
64
PRIKLADNICKI, Rafael. Apostila do Curso Gerenciamento de Projetos com Scrum: Uma nova forma de pensar projetos. Porto Alegre: [S.n.], 2009.
RIBEIRO, A. F. MPS.BR – Mitos e Verdades a Respeito de Um Modelo de Maturidade. Revista Engenharia de Software. Ano 1, 2ª ed, Ed. DevMedia, p. 32-35, 2007.
SCHWABER, Ken. Agile Project Management with Scrum. Microsoft Press, [S. I.] 2004.
______, Ken. Guia do Scrum, maio de 2009. Disponível em <http://www.scrumalliance.org>. Acesso em: dez. 2009.
______, Ken. The SCRUM Development Process. Burlington, MA, USA, 1996.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. Tradução Maurício de Andrade. São Paulo: Ed. Pearson Addison Wesley, 2003. p. 79-123.
SOUZA J. P.; PINTO, M. V. “Prodabel: diagnóstico da implantação do nível G do MPS.BR”. I Workshop de Empresas (W6-MPS.BR). Belo Horizonte. 30 nov. 2007.
SPÍNOLA, Rodrigo Oliveira. Engenharia de Requisitos. Revista SQL Magazine. Edição 71, Ano 5, Ed. DevMedia, 2009. p. 64-66.
SZIMANSKI, F.; ALBUQUERQUE, J.; FURTADO, F. Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G. In: XI Encontro de Estudantes de Informática do Tocantins, 2009, Palmas. Anais do XI Encontro de Estudantes de Informática do Tocantins. Palmas: Centro Universitário Luterano de Palmas, 2009. p. 161-170.
TRAVASSOS, G. H.; KALINOWSKI, M. “iMPS 2009: Caracterização e Validação de Desempenho de Organizações que Adotaram o Modelo MPS”. 1 ª ed. Campinas, SP: SOFTEX, 2009.
VERSIONONE. State of Agile Development Survey 2009. Disponível em <http://www.versionone.com>. Acesso em: mai. 2010.
WAZLAWICK, Raul S. Análise e Projeto de Sistemas de Informação Orientado a Objetos. 1ª ed. São Paulo: Ed. Campus, 2004.
65
ANEXO A – MANIFESTO ÁGIL - VALORES
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós
mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. Fonte: AGILE MANIFESTO, 2001.
66
ANEXO B – MANIFESTO ÁGIL - PRINCÍPIOS
Nós seguimos os seguintes princípios: Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua
de software de valor. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis
se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com freqüência, na escala de semanas até meses, com
preferência aos períodos mais curtos. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e
diariamente, durante todo o curso do projeto. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e
suporte necessário, e confiar que farão seu trabalho. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um
time de desenvolvimento, é através de uma conversa cara a cara. Software funcional é a medida primária de progresso. Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. Contínua atenção a excelência técnica e bom design aumentam a agilidade. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. As melhores arquiteturas, requisitor e designs emergem de times auto-organizáveis. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e
otimizam seu comportamento de acordo.
Fonte: AGILE MANIFESTO, 2001.
67
ANEXO C – ATRIBUTOS DE PROCESSO - AP 1.1
Atributo de Processo (AP) AP 1.1 - O processo é executado
Descrição: Medida do quanto o processo atinge o seu propósito
Resultado Esperado (RAP):
RAP 1 - O processo atinge seus resultados definidos.
Fonte: SOFTEX, 2009a, p. 17.
68
ANEXO D – ATRIBUTOS DE PROCESSO - AP 2.1
Atributo de Processo (AP) AP 2.1 - O processo é gerenciado
Descrição: Medida do quanto à execução do processo é gerenciada
Resultado Esperado (RAP):
RAP 2 - Existe uma política organizacional estabelecida e mantida para o processo;
RAP 3 - A execução do processo é planejada;
RAP 4 - (A partir do nível F). Medidas são planejadas e coletadas para monitoração da execução do processo e ajustes são realizados;
RAP 4 - (Para o nível G) A execução do processo é monitorada e ajustes são realizados;
RAP 5 - (Até o nível F) As informações e os recursos necessários para a execução do processo são identificados e disponibilizados;
RAP 5 - (A partir do nível E) Os recursos e informações necessários para executar o processo definido são disponibilizados, alocados e utilizados;
RAP 6 - (Até o nível F) As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas;
RAP 6 - (A partir do nível E) Os papéis requeridos, responsabilidades e autoridade para execução do processo definido são atribuídos e comunicados;
RAP 7 - (Até o nível F) As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência;
RAP 7 - (A partir do nível E) As pessoas que executam o processo definido são competentes em termos de formação, treinamento e experiência;
RAP 8 - A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento;
RAP 9 - (Até o nível F) Os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização;
RAP 9 - (A partir do nível E) Métodos adequados para monitorar a eficácia e adequação do processo são determinados e os resultados do processo são revistos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização;
RAP 10 - (Para o nível G) O processo planejado para o projeto é executado;
RAP 10 - (A partir do nível F) A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades;
Fonte: SOFTEX, 2009a, p. 17-18.
69
ANEXO E – ATRIBUTOS DE PROCESSO - AP 2.2
Atributo de Processo (AP) AP 2.2 - Os produtos de trabalho do processo são gerenciados
Descrição: Medida do quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente
Resultado Esperado (RAP):
RAP 11 - Os requisitos dos produtos de trabalho do processo são identificados;
RAP 12 - Requisitos para documentação e controle dos produtos de trabalho são estabelecidos;
RAP 13 - Os produtos de trabalho são colocados em níveis apropriados de controle;
RAP 14 - Os produtos de trabalho são avaliados objetivamente com relação aos padrões, procedimentos e requisitos aplicáveis e são tratadas as não conformidades.
Fonte: SOFTEX, 2009a, p. 18-19.
70
ANEXO F – ATRIBUTOS DE PROCESSO - AP 3.1
Atributo de Processo (AP) AP 3.1 - O processo é definido
Descrição: Medida do quanto o processo padrão é mantido para apoiar a implementação do processo definido
Resultado Esperado (RAP):
RAP 15 - Um processo padrão é descrito, incluindo diretrizes para sua adaptação para o processo definido para um projeto;
RAP 16 - A seqüência e interação do processo padrão com outros processos são determinadas;
RAP 17 - Os papéis e competências requeridos para executar o processo são identificados como parte do processo padrão;
RAP 18 - A infra-estrutura e o ambiente de trabalho requeridos para executar o processo são identificados como parte do processo padrão.
Fonte: SOFTEX, 2009a, p. 19.
71
ANEXO G – ATRIBUTOS DE PROCESSO - AP 3.2
Atributo de Processo (AP) AP 3.2 - O processo está implementado
Descrição: Medida do quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados
Resultado Esperado (RAP):
RAP 19 - Um processo definido é implementado para o projeto baseado nas diretrizes para seleção e/ou adaptação do processo padrão;
RAP 20 - A infra-estrutura e o ambiente de trabalho requeridos para executar o processo definido são disponibilizados, gerenciados e mantidos;
RAP 21 - Dados apropriados são coletados e analisados, constituindo uma base para o entendimento do comportamento do processo, para demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo;
RAP 22 - Produtos de trabalho e lições aprendidas são coletados e armazenados na biblioteca de ativos de processo, para uso futuro e apoio à melhoria contínua do processo.
Fonte: SOFTEX, 2009a, p. 19.