Universidade de BrasíliaInstituto de Ciências Exatas

Departamento de Ciência da Computação

Um Estudo de Caso para a Avaliação do SCRUM sob aóptica do MPS.BR Nível G

Gabriel Siqueira Rodrigues

Marcos Vinícius Silva Godinho

Monogra�a apresentada como requisito parcial

para conclusão do Bacharelado em Ciência da Computação

Orientadora

Prof.a Dr.a Genaina Nunes Rodrigues

Brasília

2011

Universidade de Brasília � UnB

Instituto de Ciências Exatas

Departamento de Ciência da Computação

Bacharelado em Ciência da Computação

Coordenador: Prof. Dr. Marcus Vinicius Lamar

Banca examinadora composta por:

Prof.a Dr.a Genaina Nunes Rodrigues (Orientadora) � CIC/UnB

Prof. Ms. Fernando A. A. C. de Albuquerque � CIC/UnB

Prof. Ms. Hilmer Rodrigues Neri � CIC/UnB

CIP � Catalogação Internacional na Publicação

Rodrigues, Gabriel Siqueira.

Um Estudo de Caso para a Avaliação do SCRUM sob a óptica do

MPS.BR Nível G / Gabriel Siqueira Rodrigues, Marcos Vinícius Silva

Godinho. Brasília : UnB, 2011.

173 p. : il. ; 29,5 cm.

Monogra�a (Graduação) � Universidade de Brasília, Brasília, 2011.

1. processo de desenvolvimento, 2. estudo de caso, 3. métodos ágeis,

4. SCRUM, 5. MPS.BR, 6. modelos de capacidade, 7. gerência de

projeto, 8. gerência de requisitos

CDU 004.4

Endereço: Universidade de Brasília

Campus Universitário Darcy Ribeiro � Asa Norte

CEP 70910-900

Brasília�DF � Brasil

Universidade de BrasíliaInstituto de Ciências Exatas

Departamento de Ciência da Computação

Um Estudo de Caso para a Avaliação do SCRUM sob aóptica do MPS.BR Nível G

Gabriel Siqueira Rodrigues

Marcos Vinícius Silva Godinho

Monogra�a apresentada como requisito parcial

para conclusão do Bacharelado em Ciência da Computação

Prof.a Dr.a Genaina Nunes Rodrigues (Orientadora)

CIC/UnB

Prof. Ms. Fernando A. A. C. de Albuquerque Prof. Ms. Hilmer Rodrigues Neri

CIC/UnB CIC/UnB

Prof. Dr. Marcus Vinicius Lamar

Coordenador do Bacharelado em Ciência da Computação

Brasília, 9 de fevereiro de 2011

Agradecimentos

Agradecemos à nossa orientadora, Prof.a Dr.a Genaina Nunes Rodrigues, pela com-preensão e pelas críticas muito bem colocadas que de�niram o rumo deste estudo. E àempresa e-Sec, principalmente o Rodrigo, o Luciano, o Brandão, o Cristiano, a Fábia, oAlexandre, o Elder, o Daniel e o Mikate, que permitiram o desenvolvimento deste trabalho,acreditando e abraçando a idéia.

i

Resumo

Nesse trabalho apresentamos um estudo de caso sobre a adoção de um processo ágilem uma pequena empresa de software sem processo de�nido. Apresentamos uma pesquisasobre métodos ágeis, SCRUM e MPS.BR.

Avaliamos a compatibilidade entre SCRUM eMPS.BR, descrevendo lacunas do SCRUMe como o adaptamos para preenchê-las.

Apresentamos uma análise qualitativa da implantação do processo na empresa, de-screvendo os dois projetos utilizados no estudo.

Ao �nal do trabalho propomos um processo para a empresa estudada que cumpra osrequisitos do nível G do Modelo de Referência MPS.BR.

Palavras-chave: processo de desenvolvimento, estudo de caso, métodos ágeis, SCRUM,MPS.BR, modelos de capacidade, gerência de projeto, gerência de requisitos

ii

Abstract

We present a case study on the adoption of an agile process in a small software companywithout a de�ned process. We present a survey of agile methods, SCRUM and MPS.BR.

We evaluated the compatibility between SCRUM and MPS.BR, describing shortcom-ings of Scrum and how we adapt to �ll them.

We present a qualitative analysis of the deployment process in the company, describingthe two projects used in the study.

At the end of the paper, we propose a process for the studied company that meets therequirements of the level of the Reference Model G MPS.BR.

Keywords: software process, case study, agile methods, SCRUM, MPS.BR, capabilitymodels, project management, requirements management

iii

Sumário

1 Introdução 11.1 Engenharia de Software e Métodos Ágeis . . . . . . . . . . . . . . . . . . . 1

1.1.1 Processo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Metodologias de Desenvolvimento de Software . . . . . . . . . . . . 21.1.3 Metodologias Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Processos Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 O SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Modelo de Qualidade de Processo . . . . . . . . . . . . . . . . . . . . . . . 51.5 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6.1 Justi�cativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6.2 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6.3 Objetivos especí�cos . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6.4 Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6.5 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Métodos Ágeis e o SCRUM 72.1 Predeterminante contra Adaptativo . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Separação de Projeto e Construção . . . . . . . . . . . . . . . . . . 72.1.2 A Imprevisibilidade dos Requisitos . . . . . . . . . . . . . . . . . . 92.1.3 Controlando um Processo Imprevisível - Iterações . . . . . . . . . . 9

2.2 Colocando as Pessoas em Primeiro Lugar . . . . . . . . . . . . . . . . . . . 102.2.1 Pessoas são Unidades de Programação Substituíveis? . . . . . . . . 102.2.2 Programadores são Pro�ssionais Responsáveis . . . . . . . . . . . . 102.2.3 Gerenciando um Processo Orientado a Pessoas . . . . . . . . . . . . 112.2.4 O Papel da Liderança de Negócio . . . . . . . . . . . . . . . . . . . 12

2.3 O Processo Auto-Adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 O SCRUM como Alternativa Ágil . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 Empírico e Adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Conteúdo do SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6 Papéis do SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.1 O ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6.2 O Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6.3 A Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7 Time-Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.7.1 Reunião de Planejamento da Release . . . . . . . . . . . . . . . . . 18

iv

2.7.2 Reunião de Planejamento da Sprint . . . . . . . . . . . . . . . . . . 192.7.3 A Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.7.4 Reunião Diária . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.7.5 Revisão da Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7.6 Retrospectiva da Sprint . . . . . . . . . . . . . . . . . . . . . . . . 22

2.8 Artefatos do SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8.1 Backlog do Produto e Burndown da Release . . . . . . . . . . . . . 232.8.2 Backlog da Sprint e Burndown da Sprint . . . . . . . . . . . . . . . 24

2.9 A De�nição do Conceito de Pronto . . . . . . . . . . . . . . . . . . . . . . 252.10 Estimando o Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.10.1 Story Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.10.2 A Escala Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.10.3 Técnicas de Estimativas . . . . . . . . . . . . . . . . . . . . . . . . 26

3 MPS.BR 283.1 O Modelo MPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.1 O Modelo de Referência MR-MPS . . . . . . . . . . . . . . . . . . . 293.2 Níveis de Maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3 Nível G � Parcialmente Gerenciado . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Gerência de Projetos � GPR . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Gerência de Requisitos - GRE . . . . . . . . . . . . . . . . . . . . . 32

4 Estudo de Caso 354.1 Divisão do Estudo e Hipóteses Levantadas . . . . . . . . . . . . . . . . . . 354.2 A Empresa Estudada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.2 Desenvolvimento de Produtos . . . . . . . . . . . . . . . . . . . . . 364.2.3 Tipos de Projetos Desenvolvidos . . . . . . . . . . . . . . . . . . . . 374.2.4 A Equipe de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . 374.2.5 O Processo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . 374.2.6 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 Primeiro Estudo de Caso: Adoção do SCRUM . . . . . . . . . . . . . . . . 404.3.1 Pré-Requisitos para a Adoção do SCRUM . . . . . . . . . . . . . . 404.3.2 Realização do Projeto Piloto . . . . . . . . . . . . . . . . . . . . . . 414.3.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Segundo Estudo de Caso: Adoção do MPS.BR Nível G . . . . . . . . . . . 444.4.1 Melhorando o Processo . . . . . . . . . . . . . . . . . . . . . . . . . 444.4.2 Realização do Segundo Projeto . . . . . . . . . . . . . . . . . . . . 454.4.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Avaliação Qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.1 Suporte do Scrum ao MPS.BR . . . . . . . . . . . . . . . . . . . . . 48

5 Conclusão 52

v

I O Processo Proposto 53I.1 O Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

I.1.1 De�nição de Pronto . . . . . . . . . . . . . . . . . . . . . . . . . . . 53I.1.2 Elaborar Documento de Visão . . . . . . . . . . . . . . . . . . . . . 53I.1.3 Realizar planejamento macro do Projeto . . . . . . . . . . . . . . . 54I.1.4 Elaboração de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . 56I.1.5 Reunião de Abertura . . . . . . . . . . . . . . . . . . . . . . . . . . 56I.1.6 Reunião de Estimativa . . . . . . . . . . . . . . . . . . . . . . . . . 57I.1.7 Montagem de Ambiente . . . . . . . . . . . . . . . . . . . . . . . . 57I.1.8 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . 58I.1.9 Reunião de Planejamento da Sprint . . . . . . . . . . . . . . . . . . 59I.1.10 Execução da Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 60I.1.11 Reunião de Revisão da Sprint . . . . . . . . . . . . . . . . . . . . . 62I.1.12 Reunião de Retrospectiva da Sprint . . . . . . . . . . . . . . . . . . 63I.1.13 Validação da Release . . . . . . . . . . . . . . . . . . . . . . . . . . 64I.1.14 Empacotar e Implantar . . . . . . . . . . . . . . . . . . . . . . . . . 64I.1.15 Obter Homologação . . . . . . . . . . . . . . . . . . . . . . . . . . . 65I.1.16 Fornecer Treinamento . . . . . . . . . . . . . . . . . . . . . . . . . 65I.1.17 Encerrar Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

I.2 Artefatos Complementares . . . . . . . . . . . . . . . . . . . . . . . . . . . 66I.2.1 Ata de Reunião . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66I.2.2 Documento de Visão . . . . . . . . . . . . . . . . . . . . . . . . . . 67I.2.3 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . 67I.2.4 Diagrama de Realização de Casos de Uso . . . . . . . . . . . . . . . 67I.2.5 Planilha de Execução . . . . . . . . . . . . . . . . . . . . . . . . . . 67I.2.6 Lista de Riscos Comuns . . . . . . . . . . . . . . . . . . . . . . . . 67

I.3 Método de Estimativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68I.3.1 Esforço e Complexidade . . . . . . . . . . . . . . . . . . . . . . . . 68I.3.2 Estimativa de Complexidade . . . . . . . . . . . . . . . . . . . . . . 68I.3.3 Estimativa de Esforço . . . . . . . . . . . . . . . . . . . . . . . . . 69I.3.4 Medição de Esforço . . . . . . . . . . . . . . . . . . . . . . . . . . . 69I.3.5 Capacidade do Time . . . . . . . . . . . . . . . . . . . . . . . . . . 70I.3.6 Interação com o Product Owner . . . . . . . . . . . . . . . . . . . . 70

I.4 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70I.4.1 Gerência SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71I.4.2 Modelagem UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71I.4.3 Comunicação com o Product Owner . . . . . . . . . . . . . . . . . . 71I.4.4 Base de Conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . 72I.4.5 Controle de Versão . . . . . . . . . . . . . . . . . . . . . . . . . . . 72I.4.6 Ambiente Integrado de Desenvolvimento . . . . . . . . . . . . . . . 72

II Validação do Processo 73II.1 Gerência de Projetos � GPR . . . . . . . . . . . . . . . . . . . . . . . . . . 73II.2 Gerência de Requisitos - GRE . . . . . . . . . . . . . . . . . . . . . . . . . 75

Referências 77

vi

Lista de Figuras

2.1 Visão geral do SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Detalhamento da iteração entre os membros e a construção dos artefatos

durante a Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Exemplo de grá�co Burndown . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Processo utilizado no projeto piloto . . . . . . . . . . . . . . . . . . . . . . 424.2 Processo resultante do segundo estudo de caso . . . . . . . . . . . . . . . . 46

I.1 Visão geral do processo da e-Sec . . . . . . . . . . . . . . . . . . . . . . . 54

vii

Capítulo 1

Introdução

Nesse capítulo introduzimos os conceitos de processo de desenvolvimento de software,metodologias ágeis, SCRUM e o Modelo MPS.BR que são os temas tratados nessa mono-gra�a. Em seguida especi�camos o projeto que desenvolvemos.

1.1 Engenharia de Software e Métodos Ágeis

Com o crescimento da importância e complexidade de sistemas de software a comu-nidade tem continuamente tentado desenvolver tecnologias que tornem mais fácil desen-volver e manter sistemas de software de qualidade. Esse conjunto de tecnologias abrangeprocessos, métodos e ferramentas e é o objeto de estudo da Engenharia de Software.

A Engenharia de Software surgiu por volta de 1968 junto com os circuitos integrados ea consequente demanda por sistemas de software cada vez mais complexos (22), capazes deaproveitar as novas capacidades de hardware na solução de um conjunto mais abrangentede problemas. Com a crescente complexidade do software necessários surgiu a necessidadeda aplicação de processos, pois o desenvolvimento ad hoc (sem que haja um processode�nido) se tornava muito dispendioso.

Esses processos foram evoluindo e se diversi�cando ao longo dos anos. Existem hojevárias abordagens diferentes. A escolha da melhor abordagem vai depender de diversosfatores sendo que não existe uma abordagem ideal.

1.1.1 Processo de Software

Processo de Software é o roteiro de atividades que se segue objetivando produzir umsoftware de alta qualidade em tempo. O processo organiza o desenvolvimento o afastandodo caos.

Pressman (17) a�rma que : �Os processos de software formam a base para o con-trole gerencial de projetos de software e e estabelecem o contexto no qual os métodostécnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios,formulários etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada eas modi�cações são adequadamente geridas".

As principais atividades de um processo de software segundo Sommerville (22) são:

Especi�cação É de�nido por clientes e engenheiros o que precisa ser desenvolvido e suasdiversas restrições

1

Desenvolvimento O software é projetado e programado

Validação Nessa etapa o software é veri�cado para ver se atende ao que o cliente queria

Evolução de Software O software é modi�cado para se adaptar às mudanças no re-querido pelo cliente e pelo mercado

1.1.2 Metodologias de Desenvolvimento de Software

A prática do desenvolvimento de software é uma atividade caótica em sua maior parte,normalmente caracterizada pela expressão "codi�car e consertar". O software é escritosem um plano de�nido e o projeto do sistema é repleto de várias decisões de curto prazo.Isso funciona muito bem se o sistema é pequeno - mas à medida que o sistema cresce,torna-se cada vez mais difícil adicionar novos recursos a ele. Defeitos subsequentes setornam cada vez mais dominantes e cada vez mais difíceis de serem eliminados. Um sinaltípico de um sistema desse tipo é uma longa fase de testes depois que o sistema está"pronto". Esta longa fase de testes entra em confronto direto com o cronograma, poistestes e depuração são atividades cujos tempos são impossíveis de serem estimados.

Este estilo de desenvolvimento é utilizado há muito tempo, mas também existe uma al-ternativa há muito tempo: Metodologia. Metodologias impõem um processo disciplinadono desenvolvimento de software, com o objetivo de torná-lo mais previsível e mais e�-ciente. Elas fazem isso desenvolvendo um processo detalhado com uma forte ênfase emplanejamento e inspirado em outras disciplinas de engenharia. Por isso são chamadas demetodologias de engenharia (4).

Metodologias de engenharia estão disponíveis há muito tempo. Elas não têm sidopercebidas como sendo particularmente bem-sucedidas. Elas têm sido notadas menosainda por serem populares. A crítica mais frequente é que estas metodologias são buro-cráticas. Há tanta coisa a se fazer para seguir a metodologia que o todo o ritmo dedesenvolvimento �ca mais lento.

1.1.3 Metodologias Ágeis

Como uma reação às metodologias tradicionais, um novo grupo delas surgiu nosúltimos anos. Durante algum tempo elas foram conhecidas como metodologias leves,mas agora o termo mais aceito é metodologia ágil. Para muitas pessoas o apelo dasmetodologias ágeis é a reação delas à burocracia das metodologias monumentais. Estasnovas metodologias tentam criar um equilíbrio entre nenhum processo e muito processo,provendo apenas o su�ciente de processo para obter um retorno razoável.

O resultado disso tudo é que os métodos ágeis têm algumas mudanças de ênfase signi-�cativas em relação aos métodos de engenharia. A diferença mais evidente é que metodolo-gias ágeis são menos centradas em documentação, normalmente enfatizando uma quan-tidade menor de documentos para uma dada tarefa. De várias maneiras, elas são maisvoltadas ao código-fonte do programa: seguindo um caminho que diz que a parte-chaveda documentação é o próprio código-fonte.

Menos documentação é apenas um sintoma de duas diferenças mais profundas, segundoMartin Fowler (4):

2

Metodologias ágeis são adaptativas ao invés de predeterminantes. Metodologiasde engenharia tendem a tentar planejar uma grande parte do processo de desenvolvi-mento detalhadamente por um longo período de tempo. Isso funciona bem até ascoisas mudarem. Então a natureza de tais métodos é a de resistir à mudança. Paraos métodos ágeis, entretanto, mudanças são bem-vindas. Eles tentam ser proces-sos que se adaptam e se fortalecem com as mudanças, até mesmo ao ponto de seauto-modi�carem.

Métodos ágeis são orientados a pessoas ao invés de serem orientados a processos.O objetivo dos métodos de engenharia é de de�nir um processo que irá funcionarbem, independentemente de quem os estiverem utilizando. Métodos ágeis a�rmamque nenhum processo jamais será equivalente à habilidade da equipe de desenvolvi-mento. Portanto, o papel do processo é dar suporte à equipe de desenvolvimento eseu trabalho.

Processos ágeis têm por objetivo criar software útil o mais rápido possível e respondera mudanças de requisitos com o menor custo. Apesar de existirem diferentes abordagense não existir uma de�nição clara para processo ágil é possível identi�car característicascomuns em uma família de processos chamados ágeis. Estes processos são iterativos,geram pouca documentação, o software é entregue incrementalmente e desenvolvido emciclos de curta duração.

1.2 Processos Ágeis

O marco inicial do �Movimento Ágil� na indústria de software é a publicação do �Man-ifesto Ágil� em 2001(3). Esse manifesto apresenta os seguintes pontos chaves na suaintrodução:

�Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mes-mos e ajudando outros a fazê-lo. Através desse 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.�Esse documento é assinado com um manifesto em alusão a movimentos de vanguarda

na arte e na política. É bem o que o movimento ágil pretendia ser, quebrando os paradig-mas da Engenharia de Software vigente, introduzindo uma nova forma de pensar emEngenharia em Engenharia, bem distinto dos processos sólidos e burocráticos então vi-gentes.

Os processos ágeis privilegiam a entrega de software útil ao cliente ao invés de produçãode documentos detalhados. Nos processos ágeis não é feita uma análise de requisitosdetalhada no início do processo, ao invés disso são detalhados alguns requisitos iniciais,su�cientes para se iniciar o desenvolvimento.

3

Cada versão do software é desenvolvida para atender a um novo conjunto pequenode requisitos. Essa nova versão é entregue ao cliente que fornece que o critica e junto aodesenvolvedor levanta novos requisitos. Assim o software é desenvolvido incrementalmentea medida que os requisitos vão se tornando mais claros.

Processos iterativos segundo Sommerville (22) são adequados para desenvolvimentode software para negócios, de e-commerce e pessoais, pois re�etem a maneira fundamen-tal como as pessoas tendem a pensar nos problemas. Raramente as pessoas trabalhamna solução completa antecipadamente, mas seguem em direção à solução por meio deuma série de passos, retrocedendo quando percebem que cometeram um erro. O desen-volvimento iterativo é preferível porque nesses casos é quase impossível entender todo oproblema antes que uma parte do sistema esteja em operação.

No entanto os processos ágeis têm algumas limitações e não são aplicados a todos ossistemas de software. Os principais problemas citados por Sommerville (22) com desen-volvimento iterativo são:

É difícil estimar custo com antecedência. Como os requisitos do sistema só são de-scobertos a medida que é desenvolvido não podemos no início do progresso estimar oscustos de desenvolvimento. Uma organização que produza software para si mesmaterá di�culdades em avaliar quanto de recursos será destinado ao projeto e se émais lucrativo desenvolvê-lo ou comprar uma solução já pronta. Uma empresa quedesenvolva software sob encomenda terá di�culdade em fazer um orçamento.

É difícil de acompanhar o desenvolvimento do projeto. Em um processo de de-senvolvimento ágil não sabemos inicialmente a complexidade do projeto desen-volvido, todas as funções a serem implementadas e consequentemente não temosum cronograma de atividades. Isso di�culta a gerência acompanhar o progresso doprojeto e prever quando estará concluído. A falta de documentação di�culta rastreara introdução de erros e coletar dados que possibilitem uma melhora do processo.

Desaconselhável para projetos que envolvam alto risco e alto custo de teste. Processoságeis por sua natureza iterativa são baseados em uma boa carga de testes. Em umprojeto que seja muito caro ou impossível de se testar o sistema, como no caso desoftware embarcado em uma aeronave, é muito ine�ciente utilizar um método ágil.Os métodos ágeis adequados à áreas que seja mais importante entregar um softwarerápido ao usuário do que entregar um sistema plenamente con�ável.

1.3 O SCRUM

O SCRUM está entre os métodos ágeis mais utilizados hoje. Seu criador, Ken Schwaberfoi um dos signatários originais do Manifesto Ágil (3). O SCRUM é baseado em práticasaceitas pelo mercado, utilizadas por décadas. Ele é de�nido então em uma teoria deprocessos empíricos.

É uma metodologia de desenvolvimento de produto consistindo de práticas e regrasutilizadas pela administração, pelos clientes e pela gerência de projeto para maximizar aprodutividade e o valor do esforço de desenvolvimento. Ele não é um processo ou umatécnica para o desenvolvimento de produtos. Ao invés disso, é um framework dentro

4

do qual você pode empregar diversos processos e técnicas (12). Nesse trabalho ele seráreferenciado como framework SCRUM.

Tem como principais características ágeis a adaptatividade e o desenvolvimento comfoco nas pessoas e nas interações entre elas.

1.4 Modelo de Qualidade de Processo

Existem hoje várias abordagens diferentes para desenvolvimento de software, não ex-istindo abordagem ideal. Dado esse contexto surge a importância de modelos de qualidadede processo, através do qual se pode avaliar organizações quanto a sua maturidade emrelação ao desenvolvimento de software independente da abordagem utilizada.

Um modelo de qualidade de processo descreve boas práticas de Engenharia de Softwareque um processo deve evidenciar para ter um certo nível de maturidade. O CMMI (Capa-bility Maturity Model Integration) é um modelo de qualidade de processo mundialmentereconhecido. O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultanea-mente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelode qualidade de processo (Modelo MPS).O Modelo MPS.BR é compatível com CMMIe voltado para a realidade brasileira, sobre tudo para as pequenas e médias empresas(PMEs).

As organizações responsáveis pelos modelos como CMMI e MPS.BR são também re-sponsáveis por modelos de avaliação e programa de certi�cação que avaliam e atestam amaturidade do processo.

1.5 Motivação

Mais de 70% das empresas brasileiras de software são pequenas empresas, muitasdas quais sem processo de software de�nido(15). O MPS.BR foi criado para atendera demanda do mercado nacional e tem crescido o interesse das empresas em adotar omodelo.

Os métodos ágeis tem sucesso crescente nos último anos. Os seus defensores citam quesão de fácil adoção e adaptável à equipe pequenas. Nesse contexto é de grande interesseno campo de pesquisa de Engenharia de Software estudo de casos reais que levantemdados sobre a compatibilidade e viabilidade entre métodos de desenvolvimentos ágeis eo MR-MPS.BR em pequenas empresas. Nesse trabalho, investigamos a adoção de ummodelo ágil e o nível G do MPS.BR como opção de baixo custo para pequenas empresasbrasileiras.

1.6 Projeto

1.6.1 Justi�cativa

Com o objetivo de aumentar a qualidade e competitividade das empresas brasileirasde software é de interesse pesquisar métodos de desenvolvimento alinhados a realidade dopaís.

5

Alinhado a esse objetivo, realizamos um estudo de caso que analisa a viabilidade ee�ciência da adoção de um processo de software baseado no framework SCRUM por umapequena empresa de software brasileira.

1.6.2 Objetivo Geral

Propor e avaliar a implantação de um processo de software baseado em SCRUM queatenda o MPS.BR nível G em uma pequena empresa de software.

1.6.3 Objetivos especí�cos

• De�nir o processo: Procuramos nesse trabalho de�nir um processo baseado emSCRUM que atendesse ao MPS.BR nível G e que atendesse as necessidades especí-�cas de uma empresa de pequeno porte;

• Implantar o processo;

• Fazer uma análise qualitativa da implantação;

• Avaliar a compatibilidade do MPS.BR e SCRUM.

1.6.4 Resultados Esperados

Esperamos conseguir implantar um processo e�ciente de software em uma pequenaempresa que seja avaliado com nível G do MPS.BR e avaliar a implantação.

1.6.5 Estrutura do Trabalho

O presente trabalho está dividido em 5 capítulos e 2 anexos sendo que é este o primeiroe apresenta o trabalho desenvolvido.O Capítulo 2 descreve as principais característicasdos métodos ágeis e mais detalhadamente o framework SCRUM.O Capítulo 3 apresenta oMPS.BR de forma geral e detalha o Modelo de Referência MPS.BR nível G. O Capítulo 4a apresentação o estudo de caso. O Capítulo 5 apresenta a conclusão do projeto e propõetrabalhos futuros. O Anexo I descreve o processo resultante e o Anexo II apresenta comocada item do MPS.BR nível G é atendido pelo processo descrito.

6

Capítulo 2

Métodos Ágeis e o SCRUM

Esse capítulo apresenta o propósito dos métodos ágeis e como estes podem ser aplicadosutilizando o SCRUM. Enfoca a adaptatividade de um processo e os aspectos humanosenvolvidos no desenvolvimento de software - o relacionamento entre cliente e equipe dedesenvolvimento e entre a equipe entre si - como os principais trunfos dos métodos ágeis.

2.1 Predeterminante contra Adaptativo

Esta seção apresenta observações sobre processos predeterminantes, adaptativos e asobre a diferenciação entre design e construção no desenvolvimento de softwares feitas porMartin Fowler (4).

2.1.1 Separação de Projeto e Construção

As metodologias de engenharia enfatizam o planejamento antes da construção. Pro�s-sionais de engenharia trabalharão em uma série de desenhos que indicam precisamenteo que precisa ser construído e como todas as coisas devem se encaixar. Muitas decisõesde design, tais como a maneira de lidar com a carga em uma ponte, são feitas à medidaque os desenhos são produzidos. Os desenhos são então entregues para um outro grupo,normalmente de outra empresa, pra serem construídos. Assume-se que o processo deconstrução irá seguir os desenhos. Na prática, os construtores vão se deparar com algunsproblemas, mas normalmente são pequenos.

Uma vez que os desenhos especi�cam as partes e como elas se encaixam, eles agemcomo uma fundação para um plano de construção detalhado. De tal plano pode serderivado o que precisa ser feito e quais dependências existem entre as tarefas. Isso per-mite um cronograma e um orçamento razoavelmente previsíveis para a construção. Aindaespeci�ca em detalhes como as pessoas que farão a construção devem fazer seus trabalhos.Isso permite que os trabalhadores da construção possam ser menos habilidosos intelec-tualmente, embora frequentemente sejam muito habilidosos manualmente.

Então, o que vemos são duas atividades fundamentalmente diferentes:

Design difícil prever e requer pessoas caras e criativas;

Construção mais fácil de prever.

7

Uma vez que tivermos o design, podemos planejar a construção. Uma vez que tivermoso plano para a construção, nós podemos lidar com a construção de uma forma muito maisprevisível. Em engenharia civil, a construção é muito maior tanto em custo como emtempo que design e planejamento.

Então, a abordagem das metodologias de engenharia de software é algo semelhante aisto: nós queremos um cronograma previsível que possamos utilizar pessoas com poucahabilidade. Para fazer isto, devemos separar as atividades de design e construção. Logo,nós precisamos descobrir como fazer o design do software de forma que a construção sejaalgo simples, uma vez que o planejamento esteja feito.

Então qual o formato deste planejamento? Para muitos, este é o papel de notaçõesde modelagem, tais como a UML. Se nós conseguirmos fazer todas as decisões utilizandoUML, poderemos criar um plano de construção e entregá-lo aos programadores, para umaatividade estritamente de construção.

Mas aqui se encontra a pergunta crucial: Você pode criar um design que é capazde transformar a programação em uma atividade de construção previsível? E, em casopositivo, o custo de fazer isto é su�cientemente baixo para que essa seja uma abordagemvantajosa?

Tudo isso traz à tona algumas perguntas. A primeira é a questão do quão difícil éconseguir um design estilo UML em um estado que possa ser entregue aos programadores.O problema com um design UML é que ele pode parecer muito bom no papel, e ainda serseriamente problemático quando você tem que traduzi-lo em código-fonte. Os modelosutilizados por engenheiros civis são baseados em diversos anos de prática adquirida emcódigos de engenharia. Além disso, questões-chave, tais como o modo que forças físicasatuam no projeto, são triviais à análise matemática. A única checagem que podemosfazer em diagramas UML são revisões cuidadosas. Enquanto estas são úteis, levam aerros que são frequentemente descobertos apenas durante a codi�cação e testes. Atémesmo designers habilidosos, são frequentemente surpreendidos quando transformamostais designs em software.

Outro problema é o custo comparativo. Quando se constrói uma ponte, o custo doesforço de design é aproximadamente 10% do total, com o resto sendo construção. Emsoftware, a quantidade de tempo gasta em codi�cação é muito, muito menor. McConnell(14) sugere que para um projeto de larga escala, apenas 15% do projeto é codi�caçãoe testes unitários - uma inversão quase perfeita da proporção em construção de pontes.Mesmo que você considere toda a etapa de testes como sendo construção, o design aindarepresenta apenas 50% do trabalho. Isso levanta uma questão importante sobre a naturezado design em software comparado com seu papel em outros ramos da engenharia.

Estes questionamentos levaram Jack Reeves (18) a sugerir que na verdade o código-fonte é um documento de design e que a fase de construção é apenas o uso do compiladore do linker. De fato, tudo que pode ser tratado como construção pode e deve ser autom-atizado.

• Em software, a construção é tão barata que pode ser considerada gratuita;

• Em software, todo o esforço é design, logo requer pessoas criativas e talentosas;

• Processos criativos não são planejados facilmente, logo a previsibilidade é provavel-mente um objetivo impossível;

8

• Nós devemos ter muito cuidado com a metáfora tradicional de engenharia paraconstruir software. Esse é um tipo diferente de atividade e requer um processodiferente;

2.1.2 A Imprevisibilidade dos Requisitos

Há um comentário que eu escuto em todos os projetos problemáticos que encontro.Os desenvolvedores vêm a mim e dizem: "o problema com este projeto é que os requisitosestão sempre mudando". O que acho surpreendente a respeito dessa situação é que alguémainda se surpreende com ela. Se mudanças em requisitos de negócio ao construir softwaresão a regra, a pergunta é o que devemos fazer a esse respeito.

Um caminho é tratar requisitos mutantes como resultado de uma engenharia de requi-sitos pobre. A ideia por trás da engenharia de requisitos é a de obter uma visão completa-mente clara dos requisitos antes de começar a construir o software, obter uma aprovação docliente destes requisitos, e depois implantar procedimentos que limitam mudanças nestesrequisitos.

Mas mesmo que você pudesse concordar e realmente conseguisse um conjunto preciso eestável de requisitos, ainda assim isso provavelmente não seria su�ciente. Na economia dehoje, as forças de negócio fundamentais estão mudando o valor dos requisitos de softwaremuito rapidamente. O que pode ser um bom conjunto de requisitos agora, não será umbom conjunto de requisitos em seis meses. Mesmo que os clientes possam �xar seusrequisitos, o mundo dos negócios não vai parar para eles. E muitas mudanças no mundodos negócios são completamente imprevisíveis: qualquer um que diga o contrário está oumentindo, ou já conseguiu um bilhão de dólares no mercado de ações .

Tudo mais no desenvolvimento de software depende dos requisitos. Se você não podeobter requisitos estáveis, então você não pode ter um plano de projeto estável.

Mas se você está em uma situação que não é previsível, você não pode usar umametodologia previsível. Essa é a dura realidade. Isto signi�ca que muitos dos modelospara controle de projetos e muitos dos modelos para o relacionamento com clientes sim-plesmente não se aplicam mais. Os benefícios da previsibilidade são enormes, é muitodifícil abrir mão deles. Como muitos problemas, a parte mais difícil é simplesmenteperceber que o problema existe.

Entretanto, abandonar a previsibilidade não signi�ca que você precise voltar ao caosincontrolável. Ao invés disso, você precisa de um processo que lhe dê controle sobre aimprevisibilidade. É justamente esse o ponto principal da adaptatividade.

2.1.3 Controlando um Processo Imprevisível - Iterações

Então como controlamos um mundo imprevisível? O mais importante, e ainda maisdifícil, é saber com precisão onde estamos. Precisamos de um mecanismo honesto defeedback que possa dizer-nos com precisão qual é a situação em intervalos frequentes.

A chave para este feedback é o desenvolvimento iterativo. Esta não é uma ideianova. Desenvolvimento iterativo já existe por algum tempo sob vários nomes diferentes:incremental, evolucionário, em estágios, espiral... muitos nomes. A chave para o desen-volvimento iterativo é frequentemente produzir versões que funcionam do sistema �nal,que contém um subconjunto dos recursos requeridos. Estas versões são bastante limi-

9

tadas em funcionalidade, mas devem ser �éis às demandas do sistema �nal. Elas devemser totalmente integradas e cuidadosamente testadas como se fossem a entrega �nal.

O ponto é que não existe nada como um sistema testado e integrado para trazer umadose de realidade a qualquer projeto. Documentos podem esconder todo tipo de falhas.Código-fonte não-testado pode esconder muitas falhas. Mas quando as pessoas sentam emfrente a um sistema e trabalham com ele, as falhas se tornam verdadeiramente aparentes:tanto em termos de defeitos como em termos de requisitos mal-interpretados.

Desenvolvimento iterativo faz sentido em processos previsíveis também. Mas é essen-cial em processos adaptativos, pois um processo adaptativo precisa ser capaz de lidar commudanças nas funcionalidades requisitadas. Isso leva a um estilo de planejamento ondeos planos de longo prazo são bastante �uidos, e os únicos planos estáveis são os de curtoprazo, feitos para uma única iteração. O desenvolvimento iterativo lhe dá uma fundação�rme em cada iteração onde você pode basear seus planos futuros.

Uma pergunta comum é o quão longa uma iteração deve ser e qual o tamanho idealpara cada iteração. Pessoas diferentes darão respostas diferentes. XP sugere interaçõesentre uma e três semanas. SCRUM sugere a duração de um mês. Em Crystal, vai sermaior. A tendência, entretanto, é fazer cada iteração o tão curta quanto possível. Issoprovê feedback mais frequente, para que você possa saber com mais frequência onde está.

2.2 Colocando as Pessoas em Primeiro Lugar

Executar um processo adaptativo não é fácil. Particularmente, exige uma equipebastante e�caz de desenvolvedores. A equipe precisa ser efetiva tanto na qualidade deseus indivíduos, quanto em como essa equipe interage como um time de verdade. Existetambém uma sinergia importante: não apenas a adaptatividade requer uma equipe maisforte, mas também a maioria dos bons desenvolvedores prefere um processo adaptativo.

Esta seção apresenta observações sobre o papel das pessoas no processo de desenvolvi-mento de software feitas por Martin Fowler (4).

2.2.1 Pessoas são Unidades de Programação Substituíveis?

Um dos objetivos das metodologias tradicionais é desenvolver um processo onde aspessoas envolvidas são partes substituíveis. Com tais processos, você pode tratar pessoascomo recursos que estão disponíveis de várias formas. Você tem um analista, algunsprogramadores, alguns especialistas em testes, um gerente. Os indivíduos não são tãoimportantes, somente suas funções. Desta forma se você planeja um projeto, não importaqual analista ou quais especialistas em testes você vai ter, apenas que você saiba quantosdeles você terá, para saber o quanto o número de recursos afetará seu planejamento.

Mais isso levanta uma questão-chave: as pessoas envolvidas em um desenvolvimentode software são peças substituíveis? Uma das principais características das metodologiaságeis é que elas rejeitam tal premissa.

2.2.2 Programadores são Pro�ssionais Responsáveis

Um conceito-chave da noção Taylorista é que as pessoas que estão fazendo o trabalhonão são as melhores pessoas para descobrir qual a melhor forma de fazer este trabalho. Em

10

uma fábrica, isso pode ser verdade por uma série de motivos. Em parte por que muitostrabalhadores fabris não são as pessoas mais inteligentes ou criativas, em parte por queexiste uma tensão entre a administração e os trabalhadores a respeito da administraçãoganhar mais dinheiro enquanto os trabalhadores ganham menos.

A história recente cada vez mais nos mostra o quanto isto é falso no caso do de-senvolvimento de software. Cada vez mais pessoas brilhantes e capazes são atraídas aodesenvolvimento de software, atraídas tanto pela sua ostentação como pelas recompensaspotencialmente grandes. Esquemas como os de programas de distribuição de ações cadavez mais alinham os interesses dos programadores com os da empresa.

Quando você quer contratar e reter boas pessoas, você deve reconhecer que eles sãopro�ssionais competentes. Assim sendo, elas são as melhores pessoas para decidir comoconduzir seus trabalhos técnicos. A noção Taylorista de um departamento de planeja-mento que decide como as coisas são feitas, só funciona se os planejadores entenderemmelhor o problema do que as pessoas o executando. Se você tem pessoas brilhantes emotivadas executando o trabalho, isso não se sustenta.

2.2.3 Gerenciando um Processo Orientado a Pessoas

A orientação a pessoas se manifesta de várias formas em processos ágeis. Isto leva adiversos efeitos, nem todos consistentes.

Um dos elementos-chave é o de aceitação do processo, ao invés da imposição do pro-cesso. Normalmente, processos de software são impostos pela administração. Destaforma, estes processos frequentemente sofrem resistência, particularmente quando a ad-ministração está há muito tempo distante da atividade do desenvolvimento de software.Aceitar um processo requer comprometimento, e como tal precisa do envolvimento ativode toda a equipe. Isso resulta no fato que apenas os próprios desenvolvedores podemoptar por seguirem um processo adaptativo.

Outro ponto é que os desenvolvedores devem ser capazes de tomar todas as decisõestécnicas. O SCRUM vai direto a esse ponto, já que em seus processos de planejamentoapenas os desenvolvedores podem fazer estimativas de tempo sobre uma determinadotarefa que será executada.

Tal liderança técnica é uma grande mudança para muitas pessoas em posições gerenci-ais. Tal abordagem exige um compartilhamento de responsabilidade onde desenvolvedorese gerência têm uma divisão igual na liderança do projeto. Perceba que eu digo igual. Agerência ainda exerce um papel, mas reconhece o conhecimento dos desenvolvedores.

Uma razão importante para essa divisão é a velocidade de mudança das tecnologiasem nossa indústria . Depois de poucos anos, o conhecimento técnico se torna obsoleto.Esta meia-vida das habilidades técnicas não tem paralelo em nenhuma outra indústria.Até mesmo os técnicos têm que reconhecer que, ao entrar na área gerencial, suas habil-idades técnicas se tornarão obsoletas. Ex-desenvolvedores precisam reconhecer que suashabilidades técnicas desaparecerão rapidamente e precisam con�ar nos desenvolvedoresatuais.

11

2.2.4 O Papel da Liderança de Negócio

Mas as pessoas técnicas não podem fazer todo o processo sozinhas. Elas precisam deorientação nas necessidades de negócio. Isso leva a outro aspecto importante dos processosadaptativos: eles precisam de contato próximo ao conhecimento de negócio.

Isso vai além do envolvimento do negócio usual na maioria dos projetos hoje. Equipeságeis não podem existir com comunicação ocasional. Elas precisam de acesso contínuo aoconhecimento de negócio. Além disso, este acesso não é algo que é administrado em nívelgerencial, e sim algo que está presente para cada desenvolvedor. Uma vez que os desen-volvedores são pro�ssionais capazes em suas próprias áreas de conhecimento, eles precisamtrabalhar como iguais com os outros pro�ssionais das outras áreas de conhecimento.

Uma grande parte disso, é claro, é devido à natureza do desenvolvimento adaptativo.Uma vez que toda a premissa do desenvolvimento adaptativo é que as coisas mudamrapidamente, você precisa de contato constante para tornar as mudanças visíveis a todos.

Não há nada mais frustrante para um desenvolvedor que alguém ver seu trabalho durodesperdiçado. Então, é importante assegurar que conhecimento de negócio de qualidadeesteja não só disponível ao desenvolvedor, mas que também seja de su�ciente qualidadepara que seja con�ável.

2.3 O Processo Auto-Adaptativo

Até agora, a adaptatividade foi discutida no contexto de um projeto adaptando seusoftware para atender aos requisitos mutáveis de seus clientes. Entretanto, há um outroângulo para a adaptatividade: o próprio processo mudar ao longo do tempo. Um projetoque se inicia utilizando um processo adaptativo não terá o mesmo processo um ano depois.Com o tempo, a equipe vai encontrar aquilo que funciona para ela, e alterar o processode acordo.

A primeira parte da auto-adaptatividade são revisões regulares do processo. Normal-mente você as faz ao �m de cada iteração. No �m de cada uma delas, tenha uma reuniãocurta e faça as seguintes perguntas (coletadas por Norm Kerth (11)):

• O que �zemos bem?

• O que aprendemos?

• O que podemos fazer melhor?

• O que nos intriga?

Estas perguntas levarão a ideias para mudar o processo para a próxima iteração.Desta forma, o processo que inicia com problemas pode melhorar à medida que caminha,adaptando-se de forma melhor à equipe que o utiliza.

Se a auto-adaptatividade ocorre dentro de um projeto, ela é ainda mais marcantedentro da organização. Para aprofundar o processo de auto-adaptatividade,é importanteque as equipes façam uma revisão mais formal ao �nal de grandes marcos do projeto,seguindo as sessões retrospectivas descritas por Norm Kerth. Essas retrospectivas en-volvem um encontro de 2 a 3 dias fora da empresa, com um facilitador treinado. Elas nãosomente ensinam a equipe, mas também ensinam a organização como um todo .

12

A consequência da auto-adaptatividade é que você nunca deveria esperar encontraruma metodologia corporativa única. Ao invés disso, cada equipe deve, não apenas es-colher seu próprio processo, mas também ativamente ajustar seus processos à medidaque avançam no projeto. Processos publicados e a experiência de projetos anteriores po-dem agir como inspiração e uma linha-mestre, mas é responsabilidade pro�ssional dosdesenvolvedores adaptarem o processo à tarefa atual.

Essa auto-adaptatividade é mais marcante no SCRUM, ASD e Crystal. As regrasrígidas do XP parecem proibi-la, mas isso é apenas uma impressão super�cial, uma vez queXP, de fato, estimula ajustes no processo. A principal diferença é que seus proponentessugerem segui-la literalmente por diversas iterações, antes de adaptá-la. Além disso,revisões não são nem encorajadas, nem são parte do processo, apesar de haver sugestõesque revisões sejam incorporadas como umas das práticas do XP.

2.4 O SCRUM como Alternativa Ágil

O SCRUM vem sendo utilizado para o desenvolvimento de produtos complexos desdeo início dos anos 90. Ele não é um processo ou uma técnica para o desenvolvimento deprodutos. Ao invés disso, é um framework dentro do qual você pode empregar diversosprocessos e técnicas. O papel do SCRUM é fazer transparecer a e�cácia relativa dassuas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê umframework dentro do qual produtos complexos podem ser desenvolvidos.

2.4.1 Empírico e Adaptativo

Sempre que podemos utilizamos processos de�nidos porque eles são mais previsíveise levam a produtos que podem ser cobrados como commodities. No entando, quando oproblema é complexo de mais e não entendemos bem o modelo subjacente sobre o qualo processo opera, não é possível de�nir um processo e�ciente logo no primeiro ciclo dedesenvolvimento do produto. Dessa forma teríamos que fazer vários ciclos completos dedesenvolvimento para um mesmo produto para conseguir de�nir um processo e�ciente.(19)

Processos empíricos são utilizados quando não se conhece bem os elementos do pro-cesso. O SCRUM, fundamentado na teoria de controle de processos empíricos, empregauma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.Três princípios guiam a implementação de controle de processos empíricos:

Transparência: A transparência garante que aspectos do processo que afetam o resul-tado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectosnão apenas devem ser transparentes, mas também o que está sendo visto deve serverdadeiro e conhecido. Isto é, quando alguém que inspeciona um processo acreditaque algo está pronto, isso deve ser equivalente à de�nição de pronto utilizada(20).

Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma frequên-cia su�ciente para que variações inaceitáveis no processo possam ser detectadas. Afrequência da inspeção deve levar em consideração que qualquer processo é modi�-cado pelo próprio ato da inspeção. Um outro fator em inspeção é o inspetor, quedeve ter as habilidades necessárias para veri�car o que lhe é cabido(19).

13

Adaptação: A adaptação consiste nos ajuste feitos nas desconformidades encontradasna inspeção. Uma vez encontrados falhas que irão levar o produto a ter qualidadeinferior aos níveis toleráveis, o processo ou o material sendo processado deverá serajustado. Esse ajuste deve ser feito o mais rápido possível para minimizar desviosposteriores(20).

Existem três pontos para inspeção e adaptação em SCRUM. A Reunião Diária é uti-lizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptaçõesque otimizem o valor do próximo dia de trabalho. Além disso, as reuniões de Revisãoda Sprint e de Planejamento da Sprint são utilizadas para inspecionar o progresso emdireção à Meta da Release e para fazer as adaptações que otimizem o valor da próximaSprint. Finalmente, a Retrospectiva da Sprint é utilizada para revisar a Sprint passadae de�nir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora egrati�cante(20).

2.5 Conteúdo do SCRUM

O framework SCRUM consiste em um conjunto formado por times SCRUM e seuspapéis associados, eventos com duração Fixa (time-boxes), artefatos e regras.

Times SCRUM são projetados para otimizar �exibilidade e produtividade. Para esse�m, eles são auto-organizáveis, interdisciplinares e trabalham em iterações 2.1.

Existem apenas três papéis no SCRUM: O Product Owner, A Equipe e o ScrumMaster.Toda responsabilidade de gerência está dividida entre esses três papéis(19).

O Product Owner é responsável por representar quem tem interesse no produto �nal,por maximizar o valor do trabalho que o Time SCRUM faz;

O ScrumMaster é responsável por garantir que o processo seja compreendido e seguido;

A Equipe executa o trabalho propriamente dito.

A Equipe consiste em desenvolvedores com todas as habilidades necessárias para trans-formar os requisitos do Product Owner em um pedaço potencialmente entregável do pro-duto ao �nal da Sprint.

SCRUM emprega os eventos com duração �xa (time-boxes) para criar regularidade.Entre os elementos do SCRUM que têm duração �xa temos a Reunião de Planejamento

da Release, a Reunião de Planejamento da Sprint, a Sprint, a Reunião Diária, a Revisão

da Sprint e a Retrospectiva da Sprint.O coração do SCRUM é a Sprint, que é uma iteração de um mês ou menos, de duração

consistente com o esforço de desenvolvimento. Todas as Sprints utilizam o mesmo modelode SCRUM e todas as Sprints têm como resultado um incremento do produto �nal que épotencialmente entregável. Cada Sprint começa imediatamente após a anterior.

O SCRUM utiliza quatro artefatos principais. O Backlog do Produto é uma listapriorizada de tudo que pode ser necessário no produto. O Backlog da Sprint é uma listade tarefas para transformar o Backlog do Produto, por uma Sprint, em um incrementodo produto potencialmente entregável.

14

Figura 2.1: Visão geral do SCRUM

Um Burndown é uma medida do Backlog restante pelo tempo. Um Burndown deRelease mede o Backlog do Produto restante ao longo do tempo de um plano de release.Um Burndown de Sprint mede os itens do Backlog da Sprint restantes ao longo do tempode uma Sprint.

As Regras fazem o elo entre os eventos com duração �xa (time-boxes), os papéis e osartefatos do SCRUM. Por exemplo, uma regra do SCRUM diz que somente membros doTime - as pessoas comprometidas em transformar o Backlog do Produto em um incremento

15

- podem falar durante uma Reunião Diária(20).

2.6 Papéis do SCRUM

Como vimos o SCRUM possui três papéis, vamos detalhá-los melhor aqui:

2.6.1 O ScrumMaster

O ScrumMaster tem um papel de facilitador e treinador do time. Ele é responsávelpor garantir que o Time SCRUM esteja aderindo aos valores do SCRUM, às práticas e àsregras. Ele ajuda o Time SCRUM e a organização a adotarem o SCRUM. O ScrumMastereduca o Time SCRUM treinando-o e levando-o a ser mais produtivo e a desenvolver pro-dutos de maior qualidade. O ScrumMaster ajuda o Time SCRUM a entender e usar auto-gerenciamento e interdisciplinaridade. O ScrumMaster também ajuda o Time SCRUM afazer o seu melhor em um ambiente organizacional que pode ainda não ser otimizado parao desenvolvimento de produtos complexos. Quando o ScrumMaster ajuda a realizar essasmudanças, isso é chamado de �remoção de impedimentos�. No entanto, o ScrumMasternão gerencia o Time SCRUM; o Time SCRUM é auto-organizável(20). O ScrumMasterprecisa estar comprometido com o time, não pode se ausentar dar reuniões e das ativi-dades que lhe são cabidas por possuir outras prioridades(19). As responsabilidades de umScrumMaster pode ser resumida nos seguintes itens:

• Remover as barreiras entre o desenvolvimento e o Product Owner de forma que oProduct Owner direcione o desenvolvimento do projeto(19):

• Ensine o Product Owner como maximizar o ROI e alcançar seu objetivo através doSCRUM.

• Melhorar as vidas do time de desenvolvimento facilitando a criatividade e a trans-ferência de poder.

• Melhorar a produtividade do time de desenvolvimento de todas as formas possíveis.

• Melhorar as práticas de engenharia e ferramentas de tal forma que cada incrementode funcionalidade é entregável.

• Manter informações sobre o progresso do time atualizadas e visível para todas aspartes.

2.6.2 O Product Owner

O Product Owner é a única pessoa responsável pelo gerenciamento do Backlog doProduto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém oBacklog do Produto e garante que ele está visível para todos. Todos sabem quais itenstêm a maior prioridade, de forma que todos sabem em que se irá trabalhar.

O Product Owner é uma pessoa, e não um comitê. Podem existir comitês que acon-selhem ou in�uenciem essa pessoa, mas quem quiser mudar a prioridade de um item, teráque convencer o Product Owner. Empresas que adotam SCRUM podem perceber queisso in�uencia seus métodos para de�nir prioridades e requisitos ao longo do tempo.

16

Para que o Product Owner obtenha sucesso, todos na organização precisam respeitarsuas decisões. Ninguém tem a permissão de dizer ao Time para trabalhar em um outroconjunto de prioridades, e os Times não podem dar ouvidos a ninguém que diga o con-trário. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlogdo Produto. Essa visibilidade requer que o Product Owner faça seu melhor, o que faz opapel exigente e recompensador ao mesmo tempo(20).

O Product Owner quase sempre não fala a mesma linguagem do Time. O ProductOwner é uma pessoa que entende do negócio e provavelmente não irá aprender falar emtermos de tecnologia. Por isso é importante que o ScrumMaster facilite o encontro doProduct Owner com o Time e ensine o Time a falar nos termos dos objetivos e necessidadesdo negócio(20).

2.6.3 A Equipe

Times de desenvolvedores transformam o Backlog do Produto em incrementos de fun-cionalidades potencialmente entregáveis em cada Sprint. Times também são interdisci-plinares: membros do Time devem possuir todo o conhecimento necessário para criar umincremento no trabalho.

Membros do Time frequentemente possuem conhecimentos especializados, como pro-gramação, controle de qualidade, análise de negócios, arquitetura, projeto de interface deusuário ou projeto de banco de dados. No entanto, o conhecimento que os membros doTime devem compartilhar - isto é, a habilidade de trabalhar um requisito e transformá-loem um produto utilizável - tendem a ser mais importantes do que aqueles que eles nãodividem. As pessoas que se recusam a programar porque são arquitetas ou designers nãose adaptam bem a Times. Todos contribuem, mesmo que isso exija aprender novas ha-bilidades ou lembrar-se de antigas. Não há títulos em Times, e não há exceções a essaregra. Os Times também não contém subtimes dedicados a áreas particulares como testesou análise de negócios.

Times também são auto-organizáveis. Ninguém - nem mesmo o ScrumMaster - dizao time como transformar o Backlog do Produto em incrementos de funcionalidades en-tregáveis. O Time descobre por si só. Cada membro do Time aplica sua especialidade atodos os problemas. A sinergia que resulta disso melhora a e�ciência e e�cácia geral doTime como um todo.

O tamanho ótimo para um Time é de sete pessoas, mais ou menos duas pessoas.Quando há menos do que cinco membros em um Time, há menor interação e, como re-sultado, há menor ganho de produtividade. Mais do que isso, o time poderá encontrarlimitações de conhecimento durante partes da Sprint e não ser capaz de entregar umaparte pronta do produto. Se há mais do que nove membros, há simplesmente a neces-sidade de muita coordenação. Times grandes geram muita complexidade para que umprocesso empírico consiga gerenciar. No entanto, temos encontrado alguns Times bem-sucedidos que excederam os limites superior e inferior dessa faixa de tamanhos. O ProductOwner e o ScrumMaster não estão incluídos nessa conta, a menos que estejam realmentecomprometidos no desenvolvimento.

A composição do Time pode mudar ao �nal da Sprint. Toda vez que o Time muda, aprodutividade ganha através da auto-organização é reduzida. Deve-se tomar cuidado aomudar a composição do Time.

17

2.7 Time-Boxes

Os Eventos com Duração Fixa (Time-Boxes) no SCRUM são a Reunião de Planeja-mento da Release, a Reunião de Planejamento da Sprint, a Sprint, a Reunião Diária, aRevisão da Sprint e a Retrospectiva da Sprint.

2.7.1 Reunião de Planejamento da Release

O propósito do planejamento da release é o de estabelecer um plano e metas que oTime SCRUM e o resto da organização possam entender e comunicar. O planejamentoda release responde às questões:

• Como podemos transformar a visão em um produto vencedor da melhor maneirapossível?

• Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Inves-timento (ROI) desejados?

O plano da release estabelece a meta da release, as maiores prioridades do Backlogdo Produto, os principais riscos e as características gerais e funcionalidades que estarãocontidas na release. Ele estabelece também uma data de entrega e custo prováveis quedevem se manter se nada mudar. A organização pode então inspecionar o progresso efazer mudanças nesse plano da release a cada Sprint.

O planejamento da release é inteiramente opcional. Se um Time SCRUM iniciar otrabalho sem essa reunião, a ausência de seus artefatos aparecerá como um impedimentoque deverá ser resolvido. O trabalho para resolver o impedimento se tornará um item noBacklog do Produto.

Ao se utilizar SCRUM, os produtos são construídos iterativamente, de modo quecada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco.Mais e mais Sprints vão adicionando incrementos ao produto. Cada incremento é umpedaço potencialmente entregável do produto completo. Quando já tiverem sido criadosincrementos su�cientes para que o produto tenha valor e uso para seus investidores, oproduto é entregue.

Muitas organizações já possuem um processo de planejamento de release, e na maiorparte desses processos o planejamento é feito no início do trabalho da release e não émodi�cado com o passar do tempo. No planejamento de release do SCRUM, são de�nidosuma meta geral e resultados prováveis. Esse planejamento geralmente não requer mais doque 15-20% do tempo que uma organização costumava utilizar para produzir um planode release tradicional.

No entanto, uma release com SCRUM realiza planejamento no momento da execuçãode cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma formaque realiza um planejamento diário no momento da execução de cada Reunião Diária.De forma geral, os esforços para uma release com SCRUM provavelmente consomemligeiramente mais esforço do que os esforços para um planejamento de release tradicional.

O planejamento da release requer estimar e priorizar o Backlog do Produto para arelease. Há diversas técnicas para fazê-lo que estão fora do alcance do SCRUM, mas queapesar disso são úteis quando usadas com ele.

18

2.7.2 Reunião de Planejamento da Sprint

A Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. É�xada em oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas,aloca-se para essa reunião aproximadamente 5% do tamanho total da Sprint, e ela consistede duas partes.

A primeira parte, um evento com duração �xa de quatro horas, é o momento no qualé decidido o que será feito na Sprint. A segunda parte, outro evento com duração �xa dequatro horas, é o momento no qual o Time entende como desenvolverá essa funcionalidadeem um incremento do produto durante a Sprint.

Há duas partes na Reunião de Planejamento da Sprint: a parte do �o quê?� e a partedo �como?�. Alguns Times SCRUM juntam as duas.

Na primeira parte, o Time SCRUM trata da questão do �o quê?�. Aqui, o ProductOwner apresenta ao Time o que é mais prioritário no Backlog do Produto. Eles trabalhamem conjunto para de�nir qual funcionalidade deverá ser desenvolvida durante a próximaSprint. As entradas para essa reunião são o Backlog do Produto, o incremento maisrecente ao produto, a capacidade do Time e o histórico de desempenho do Time. Cabesomente ao Time a decisão de quanto do Backlog ele deve selecionar. Somente o Timepode avaliar o que ele é capaz de realizar na próxima Sprint.

Uma vez selecionado o Backlog do Produto, a Meta da Sprint é delineada. A Meta daSprint é o objetivo que será atingido através da implementação do Backlog do Produto.Ela é uma descrição que fornece orientação ao Time sobre a razão pela qual ele estádesenvolvendo o incremento. A Meta da Sprint é um subconjunto da Meta da Release.

O motivo para se ter uma Meta da Sprint é dar ao time alguma margem com relaçãoà funcionalidade. Por exemplo, a meta para a Sprint acima poderia também ser: �Au-tomatizar a funcionalidade de modi�cação de conta de clientes através de um middleware

seguro capaz de recuperar transações.� Conforme o Time trabalha, ele mantém a metaem mente. Para satisfazer a meta, ele implementa a funcionalidade e a tecnologia. Se otrabalho se mostrar mais difícil do que o time esperava, o time então irá colaborar com oProduct Owner e implementar a funcionalidade apenas parcialmente.

Na segunda parte da Reunião de Planejamento da Sprint, o Time trata a questão do�como?�. Durante as quatro horas seguintes da Reunião de Planejamento da Sprint, oTime de�ne como transformará o Backlog do Produto selecionado durante a Reunião dePlanejamento (o quê) em um incremento pronto. O Time geralmente começa projetandoo trabalho. Enquanto projeta, o time identi�ca tarefas. Essas tarefas são pedaços detal-hados do trabalho necessário para converter o Backlog do Produto em software funcional.

As tarefas devem ser decompostas para que possam ser feitas em menos de um dia.Essa lista de tarefas é chamada de Backlog da Sprint. O time se auto-organiza para seencarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint, tanto durantea Reunião de Planejamento da Sprint quanto no próprio momento da execução da Sprint.

O Product Owner está presente durante a segunda parte da Reunião de Planejamentoda Sprint para esclarecer o Backlog do Produto e para ajudar a efetuar trocas. Se oTime concluir que ele tem trabalho demais ou de menos, ele pode renegociar o Backlogdo Produto escolhido com o Product Owner.

O Time também pode convidar outras pessoas a participarem da reunião para forneceremconselhos técnicos ou sobre o domínio em questão.

19

Geralmente, um Time novo percebe pela primeira vez se irá ganhar ou perder comoum Time - não individualmente - nessa reunião. O Time percebe que deve contar con-sigo mesmo. Conforme ele percebe isso, ele começa a se auto-organizar para assumir ascaracterísticas e comportamento de um verdadeiro Time.

2.7.3 A Sprint

A Sprint é uma iteração. Sprints são eventos com duração �xa. Durante a Sprint, oScrumMaster garante que não será feita nenhuma mudança que possa afetar a Meta daSprint. Tanto a composição do time quanto as metas de qualidade devem permanecerconstantes durante a Sprint. As Sprints contêm e consistem na reunião de Planejamentode Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint2.2. As Sprints ocorrem uma após a outra, sem intervalos entre elas.

Um projeto serve para cumprir alguma função. Em desenvolvimento de software, oprojeto é utilizado para desenvolver um produto ou sistema. Cada projeto consiste emuma de�nição do que será desenvolvido, um plano para desenvolvê-lo, o trabalho realizadode acordo com o plano e o produto resultante.

Cada projeto possui um horizonte, que é o período de tempo para o qual o plano éválido. Se o horizonte for longo demais, a de�nição poderá ter mudado, variáveis demaispoderão ter surgido, o risco poderá ser grande demais etc. SCRUM é um framework paraprojetos cujo horizonte não é superior ao período de um mês, onde já há complexidadesu�ciente tal que um horizonte mais longo seria arriscado demais. A previsibilidade doprojeto deve ser controlada pelo menos a cada mês, e o risco de que o projeto saia decontrole ou se torne imprevisível é contido pelo menos a cada mês.

As Sprints podem ser canceladas antes que o prazo �xo da Sprint tenha acabado.Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possafazê-lo sob in�uência das partes interessadas, do Time ou do ScrumMaster. Sob quetipo de circunstâncias pode ser necessário cancelar uma Sprint? A gerência pode precisarcancelar uma Sprint se a Meta da Sprint se tornar obsoleta. Isso pode ocorrer se a empresamudar de direção ou se as condições do mercado ou tecnologia mudarem. Em geral, umaSprint deve ser cancelada se ela não �zer mais sentido dadas as circunstâncias atuais.Porém, por causa da curta duração das Sprints, raramente isso faz sentido.

Quando uma Sprint é cancelada, todos os itens do Backlog do Produto que estejamprontos são revisados. Eles são aceitos se representarem um incremento potencialmenteentregável. Todos os outros itens do Backlog do Produto são devolvidos ao Backlogdo Produto com suas estimativas iniciais. Assume-se que qualquer trabalho realizadonesses itens é perdido. Cancelamentos de Sprints consomem recursos, já que todos têmque se reagrupar em outra reunião de Planejamento de Sprint para iniciar uma novaSprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time e sãomuito incomuns.

2.7.4 Reunião Diária

Cada time se encontra diariamente para uma reunião de 15 minutos chamada ReuniãoDiária. Essa reunião é sempre feita no mesmo horário e no mesmo local durante as Sprints.Durante a reunião, cada membro explica:

20

Figura 2.2: Detalhamento da iteração entre os membros e a construção dos artefatosdurante a Sprint

• O que ele realizou desde a última reunião diária;

• O que ele vai fazer antes da próxima reunião diária;

• Quais obstáculos estão em seu caminho.

As Reuniões Diárias melhoram a comunicação, eliminam outras reuniões, identi�cam eremovem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápidade decisões e melhoram o nível de conhecimento de todos acerca do projeto.

O ScrumMaster garante que o Time realize essa reunião. O Time é responsável porconduzir a Reunião Diária. O ScrumMaster ensina o time a manter a Reunião Diáriacom curta duração, reforçando as regras e garantido que as pessoas falem brevemente.O ScrumMaster também enfatiza a regra de que galinhas não estão autorizadas a falar enem a interferir de modo algum na Reunião Diária.

A Reunião Diária não é uma reunião de status. Ela é só para as pessoas que estãotransformando os itens do Backlog do Produto em um incremento (o Time), e para maisninguém. O Time se comprometeu com uma Meta da Sprint, e a esses itens do Backlogdo Produto.

A Reunião Diária é uma inspeção do progresso na direção da Meta da Sprint (as trêsperguntas). Geralmente acontecem reuniões subsequentes para realizar adaptações aotrabalho que está por vir na Sprint. A intenção é otimizar a probabilidade de que o Time

21

alcance sua Meta. Essa é uma reunião fundamental de inspeção e adaptação no processoempírico do SCRUM.

2.7.5 Revisão da Sprint

Ao �nal da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints de um mês,essa é uma reunião com duração �xa de quatro horas. Para Sprints de durações maiscurtas, essa reunião não deve tomar mais do que 5% do total da Sprint.

Durante a Revisão da Sprint, o Time SCRUM e as partes interessadas colaboram sobreo que acabou de ser feito. Baseados nisso e em mudanças no Backlog do Produto feitasdurante a Sprint, eles colaboram sobre quais são as próximas coisas que podem ser feitas.Essa é uma reunião informal, com a apresentação da funcionalidade, que tem a intençãode promover a colaboração sobre o que fazer em seguida.

A reunião inclui ao menos os seguintes elementos. O Product Owner identi�ca o que foifeito e o que não foi feito. O Time discute sobre o que correu bem durante a Sprint e quaisproblemas foram enfrentados, além de como esses problemas foram resolvidos. O Timeentão demonstra o trabalho que está pronto e responde a questionamentos. O ProductOwner então discute o Backlog do Produto da maneira como esse se encontra. Ele fazprojeções de datas de conclusão prováveis a partir de várias hipóteses de velocidade. Emseguida, o grupo inteiro colabora sobre o que foi visto e o que isso signi�ca com relaçãoao que fazer em seguida.

A Revisão da Sprint fornece entradas valiosas para as reuniões de Planejamento deSprints seguintes.

2.7.6 Retrospectiva da Sprint

Após a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, oTime SCRUM tem a reunião de Retrospectiva da Sprint. Nessa reunião, com duração �xade três horas, o ScrumMaster encoraja o Time a revisar, dentro do modelo de trabalho edas práticas do processo do SCRUM, seu processo de desenvolvimento, de forma a torná-lo mais e�caz e grati�cante para a próxima Sprint. Muitos livros documentam técnicasque são úteis em Retrospectivas.

A �nalidade da Retrospectiva é inspecionar como correu a última Sprint em se tratandode pessoas, das relações entre elas, dos processos e das ferramentas. A inspeção deveidenti�car e priorizar os principais itens que correram bem e aqueles que, se feitos de mododiferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composição do time,preparativos para reuniões, ferramentas, de�nição de �pronto�, métodos de comunicaçãoe processos para transformar itens do Backlog do Produto em alguma coisa �pronta�.

No �nal da Retrospectiva da Sprint, o Time SCRUM deve ter identi�cado medidas demelhoria factíveis que ele implementará na próxima Sprint. Essas mudanças se tornam aadaptação para a inspeção empírica.

2.8 Artefatos do SCRUM

Os artefatos do SCRUM incluem o Backlog do Produto, o Burndown da Release, oBacklog da Sprint e o Burndown da Sprint.

22

2.8.1 Backlog do Produto e Burndown da Release

Os requisitos para o produto que o(s) Time(s) está(ão) desenvolvendo estão listadosno Backlog do Produto. O Product Owner é o responsável pelo Backlog do Produto, porseu conteúdo, por sua disponibilidade e por sua priorização. O Backlog do Produto nuncaestá completo. A seleção inicial para o seu desenvolvimento somente mostra os requisitosinicialmente conhecidos e melhor entendidos.

O Backlog do Produto evolui à medida que o produto e o ambiente em que ele seráusado evoluem. O Backlog é dinâmico, no sentido de que ele está constantemente mu-dando para identi�car o que o produto necessita para ser apropriado, competitivo e útil.Enquanto existir um produto, o Backlog de Produto também existirá.

Ele representa tudo que é necessário para desenvolver e lançar um produto de sucesso.É uma lista de todas as características, funções, tecnologias, melhorias e correções dedefeitos que constituem as mudanças que serão efetuadas no produto para releases futuras.Os itens do Backlog do Produto possuem os atributos de descrição, prioridade e estimativa.A prioridade é determinada por risco, valor e necessidade. Há diversas técnicas para darvalor a esses atributos.

O Backlog do Produto é ordenado por prioridade. O Backlog do Produto de maisalta prioridade leva a atividades de desenvolvimento imediatas. Quanto mais alta suaprioridade, mais urgente ele é, mais se pensou sobre ele e há mais consenso no que dizrespeito ao seu valor. O Backlog de mais alta prioridade é mais claro e possui maisinformações detalhadas do que o Backlog de prioridade mais baixa. Fazem-se melhoresestimativas quando baseadas em uma maior clareza e em mais detalhes. Quanto maisbaixa a prioridade, menor é o nível de detalhe, até que mal se consiga entender o item.

À medida que um produto é utilizado, que seu valor aumenta e que o mercado fornecefeedback, o Backlog do Produto torna-se uma lista maior e mais aprofundada. Os requi-sitos nunca param de mudar. O Backlog do Produto é um documento vivo. Mudançasnos requisitos de negócios, condições do mercado, tecnologia e equipe causam mudançasno Backlog do Produto.

Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser maisdetalhados. Os itens do Backlog do Produto que ocuparão os Times SCRUM pelas váriasSprints seguintes deverão ter granularidade mais �na, tendo sido decompostos de formatal que cada um dos itens possa ser feito dentro da duração da Sprint.

O grá�co de Burndown 2.3 da Release registra a soma das estimativas dos esforçosrestantes do Backlog do Produto ao longo do tempo. O esforço estimado deve estar emqualquer unidade de medida de trabalho que o Time SCRUM e a organização tenhamdecidido usar. As unidades de tempo geralmente são Sprints.

As estimativas dos itens do Backlog do Produto são inicialmente calculadas duranteo Planejamento da Release, e posteriormente à medida que itens forem sendo criados.Durante a preparação do Backlog de Produto, os itens são revistos e revisados. Entretanto,eles podem ser atualizados em qualquer momento.

O Time é responsável por todas as estimativas. O Product Owner pode in�uenciar oTime, ajudando-o a entender e a escolher as mudanças, mas a estimativa �nal é feita peloTime.

O Product Owner mantém o Backlog do Produto e o Burndown do Backlog da Releaseatualizados e publicados todo o tempo. Uma linha de tendência pode ser traçada baseadana mudança do trabalho restante.

23

Figura 2.3: Exemplo de grá�co Burndown

2.8.2 Backlog da Sprint e Burndown da Sprint

O Backlog da Sprint consiste nas tarefas que o time executa para transformar itensdo Backlog do Produto em um incremento �pronto�. Muitas delas são elaboradas du-rante a Reunião de Planejamento da Sprint. O Backlog da Sprint é todo trabalho que oTime identi�ca como necessário para alcançar a Meta da Sprint. Os itens do Backlog daSprint devem ser decompostos. A decomposição deve ser su�ciente para que mudançasno progresso possam ser entendidas na Reunião Diária.

O Time modi�ca o Backlog da Sprint no decorrer da Sprint, bem como surge Backlogda Sprint durante a Sprint. Quando chega às tarefas individuais, o Time pode descobrirque mais ou menos tarefas serão necessárias, ou que uma determinada tarefa levará maisou menos tempo do que era esperado. À medida que novo trabalho surge, o Time oadiciona ao Backlog da Sprint.

À medida que se trabalha nas tarefas ou que elas são completadas, os esforços esti-mados restantes para cada tarefa são atualizadas. Quando se veri�ca que determinadastarefas são desnecessárias, elas são removidas.

Somente o Time pode modi�car o seu Backlog da Sprint durante uma Sprint. Somenteo Time pode mudar o seu conteúdo ou as suas estimativas. O Backlog da Sprint é umretrato em tempo real altamente visível do trabalho que o Time planeja efetuar durantea Sprint, e ele pertence unicamente ao Time.

O Burndown do Backlog da Sprint é um grá�co da quantidade restante de trabalho doBacklog da Sprint em uma determinada Sprint ao longo do tempo da Sprint. Para criaresse grá�co, determine quanto trabalho resta somando as estimativas do Backlog a cadadia da Sprint.

A quantidade de trabalho restante para uma Sprint é a soma do trabalho restante paratudo do Backlog da Sprint. Acompanhe essas somas diariamente e utilize-as para criar umgrá�co que mostre o trabalho restante ao longo do tempo. Traçando uma linha atravésdos pontos no grá�co, o Time pode gerenciar seu progresso em completar o trabalho deuma Sprint. A duração não é considerada em SCRUM. O trabalho restante e a data sãoas únicas variáveis de interesse.

24

Uma das regras do SCRUM está ligada ao objetivo de cada Sprint, que é ter comoresultado incrementos de funcionalidade potencialmente entregáveis que estejam de acordocom uma de�nição de �pronto� operacional.

2.9 A De�nição do Conceito de Pronto

O SCRUM exige que os Times desenvolvam um incremento de funcionalidade do pro-duto a cada Sprint. Esse incremento deve ser potencialmente entregável, pois o ProductOwner pode optar por implantar a funcionalidade imediatamente. Para isso ser possível,o incremento deve ser um pedaço completo do produto. Ele deve estar �pronto�. Cada in-cremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado,garantindo que todos os incrementos funcionem juntos.

No desenvolvimento de produtos, a�rmar que a funcionalidade está pronta pode levaralguém a presumir que ela está pelo menos bem codi�cada, refatorada, que tenha pas-sado por testes unitários, que tenha sido feito o build e que tenha passado por testesde aceitação. Outros podem presumir que apenas o código tenha sido desenvolvido. Seninguém sabe qual a de�nição de �pronto�, os outros dois pilares do controle de proces-sos empíricos não funcionam. Quando alguém descreve algo como �pronto�, todos devementender o que �pronto� signi�ca.

�Pronto� de�ne o que o Time quer dizer quando se compromete a �aprontar� um item deBacklog do Produto em uma Sprint. Alguns produtos não contêm documentação, de formaque sua de�nição de �pronto� não inclui documentação. Um incremento completamente�pronto� inclui toda a análise, projeto, refatoração, programação, documentação e testespara o incremento e todos os itens do Backlog do Produto no incremento.

Os testes incluem testes de unidade, de sistema, de usuário e de regressão, bem comotestes não-funcionais como de performance, de estabilidade, de segurança e de integração.�Pronto� inclui também qualquer internacionalização necessária. Alguns Times aindanão são capazes de incluir em sua de�nição de �pronto� tudo o que é necessário para aimplantação. Isto deve estar claro para o Product Owner. Esse trabalho restante deveráser feito antes que o produto possa ser implantado e utilizado.

2.10 Estimando o Backlog

Neste capítulo muito foi dito sobre estimativas, mas nada sobre como realizá-la. Estaseção detalha a forma mais utilizada em método ágeis para este �m: Story Points; e temcomo referência Mike Cohn (1).

2.10.1 Story Points

Story Points são uma unidade de medida para expressar o tamanho total de umaEstória de Usuário 1, recurso, Caso de Uso ou uma outra unidade funcional qualquer quefaça parte do Backlog. Quando estimamos com Story Points, atribui-se um valor cadaitem do Backlog. O valor bruto em si e a escala utilizada não é o mais importante, mas

1Estórias de Usuários são pequenas descrições de funcionalidades utilizadas comumente como unidades

funcionais em métodos ágeis. User Story em inglês, daí o nome da medida

25

sim os valores relativos. Um item que tenha o valor 2 deve ser o dobro do item de valor1. Um item de valor 7 deve ter um terço do item de valor 21, e assim por diante.

O número de Story Points associado a um item representa a dimensão global deste.Não existe uma fórmula de�nida para a de�nição do tamanho de um item. Em vezdisso, uma estimativa de Story Points é uma mistura da quantidade de esforço envolvidono desenvolvimento da funcionalidade, da complexidade do desenvolvimento, do riscoinerente a ela, da incerteza acrescida na medida que os valores aumentam, e assim pordiante.

Existem duas maneiras comuns para começar. A primeira abordagem é selecionar umitem que você espera ser um dos menores do Backlog e estimá-lo em 1 Story Point. Asegunda abordagem consiste em selecionar um item que parece ser algo de tamanho médioe dar-lhe um valor em algum lugar no meio do intervalo que você pretende usar. Depoisde bastante arbitrariamente atribuindo o valor em Story Points para o primeiro item, osoutros são estimados relativamente ao inicial ou a quaisquer outros que foram estimados.

2.10.2 A Escala Utilizada

Duas escalas são bastante utilizadas em estimativas com Story Points:

• 1, 2, 3, 5 e 8

• 1, 2, 4 e 8

Existe uma lógica por trás de cada uma dessas sequências. O primeira é a sequênciade Fibonacci. Uma escala de estimativa muito útil, pois as diferenças entre os valoresaumentam no decorrer da sequencia. A segunda é espaçada de tal forma que cada númeroé o dobro do número que o precede. Essas sequências não-lineares funcionam muito bemcomo escalas de estimativas, pois re�etem a maior incerteza associada às estimativaspara as unidades maiores de trabalho. Como citado anteriormente, tudo depende darelatividade dos valores. Por isso, de acordo com Mike Cohn, não existe a escala certa.Cada um tem sua preferência (1): "Qualquer sequência funciona bem, embora a minhapreferência pessoal seja a primeira escala".

2.10.3 Técnicas de Estimativas

As três técnicas mais comuns para efetuar estimativas são as seguintes:

• Opinião de Especialista

• Analogia

• Desagregação

Cada uma destas técnicas podem ser usadas por si só, mas elas devem ser combinadaspara obter melhores resultados.

26

Opinião de Especialista

Esta abordagem é menos útil em projetos ágeis do que em projetos tradicionais. Emum projeto ágil, as estimativas são atribuídas aos itens do Backlog. Desenvolver este item éprovável que sejam necessárias uma variedade de habilidades normalmente desempenhadaspor mais de uma pessoa. Isso torna difícil encontrar peritos adequados que possam avaliaro esforço em todas as disciplinas. Em um projeto tradicional de que as estimativas estãoassociadas com as tarefas, isso não é um problema signi�cativo, pois provavelmente cadatarefa é realizada por uma pessoa.

Um grande benefício de estimar por especialistas é que normalmente não leva muitotempo. Normalmente, um desenvolvedor lê um item do Backlog, faz uma ou duas perguntaesclarecedoras e, em seguida, fornece uma estimativa com base na sua intuição. Existemevidencias que indicam que esse tipo de estimativa é mais precisa que outras abordagensmais analíticas (10).

Analogia

Ao estimar desta forma, não se compara todos os itens do Backlog contra uma refer-ência universal. Em vez disso, compara-se cada novo item com uma variedade de outrosque já estiveram valores estimados. Isso é conhecido como triangulação. Para decidir seum item deve ser estimado em cinco Story Points, veja se este parece um pouco maior doque um item que você estimou em três e um pouco menor do que um outro estimado emoito.

Desagregação

Desagregação refere-se a dividir um item ou funcionalidade em partes menores, maisfáceis de estimar. Se a maioria dos itens de Backlog levam em torno de 2 a 5 dias para sedesenvolver, vai ser muito difícil estimar um item único que leve 100 dias. Item maioressão notoriamente mais difíceis de serem estimados, além de que, nesse caso, haverá poucositens de tamanho parecido para comparar com itens tão grandes.

Deve-se levar em conta que a desagregação do Backlog atinge seu limite na medidaem que o número divisões torne-se muito grande, tornando o trabalho de estimar inter-minável.

27

Capítulo 3

MPS.BR

O MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa mobilizador,de longo prazo, criado em dezembro de 2003, coordenado pela Associação para Promoçãoda Excelência do Software Brasileiro (SOFTEX), que conta com apoio do Ministérioda Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), ServiçoBrasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Interamericanode Desenvolvimento (BID).(21)

O objetivo desta iniciativa é desenvolver e disseminar um modelo de melhoria de pro-cessos brasileiro (o modelo de referência MPS, MR-MPS) visando estabelecer um caminhoeconomicamente viável para que organizações, incluindo as pequenas e médias empresas(principal foco), alcancem os benefícios da melhoria de processos e da utilização de boaspráticas da engenharia de software em um intervalo de tempo razoável. O modelo foi de-senvolvido levando em consideração normas internacionais, modelos internacionalmentereconhecidos, boas práticas da engenharia de software e as necessidades de negócio daindústria de software brasileira(13).

Nesse capítulo abordaremos o nível G do MPS.BR detalhadamente pois o utilizamoscomo um guia de boas práticas e modelo de qualidade para a investigação de adoção deprocesso proposta. Escolhemos o nível G pois é o nível mais acessível adotado por maisda metade das empresas já avaliadas pelo MPS.BR até 2009(13). E como, descrito nocapítulo, trata-se de um modelo incremental de níveis de maturidade, iniciando-se pelonível G.

3.1 O Modelo MPS

O modelo MPS incorpora práticas internacionalmente reconhecidas para implemen-tação e avaliação de processos de engenharia de software. As normas ISO/IEC 12207 eISO/IEC 15504 foram usadas como base técnica para de�nir os componentes do modeloMPS. Adicionalmente, tendo em vista a importância do modelo CMMI para organizaçõesbrasileiras que atuam em mercados internacionais, a equipe técnica do modelo MPS con-siderou o CMMI como um complemento técnico para a de�nição dos processos do modeloMPS(13).

28

3.1.1 O Modelo de Referência MR-MPS

O modelo de referência MPS (MR-MPS) é documentado no Guia Geral do MPS,disponível no site da SOFTEX. O Guia Geral do MPS provê uma de�nição geral do modeloMPS. O MR-MPS está em conformidade com a norma ISO/IEC 15504, satisfazendo osrequisitos para modelo de referência de processos de�nidos na ISO/IEC 15504-2(13).

O MR-MPS de�ne sete níveis de maturidade de processos para organizações que pro-duzem software: A (Em Otimização), B (Gerenciado Quantitativamente), C (De�nido),D (Largamente De�nido), E (Parcialmente De�nido), F (Gerenciado) e G (ParcialmenteGerenciado). Cada um dos níveis de maturidade (do nível G - primeiro estágio de maturi-dade ao nível A - mais maduro) apresenta cumulativamente um conjunto de processos eatributos de processos que indicam onde a unidade organizacional tem que investir esforçopara melhoria, de forma a atender aos seus objetivos de negócio e ao MR-MPS. Assim,os níveis de maturidade são de�nidos em duas dimensões: a dimensão de capacidade deprocessos e a dimensão de processos.

A dimensão de capacidade de processos do MR-MPS é constituída de um frameworkde medição. A capacidade de processos é de�nida em uma escala ordinal que representacapacidade crescente do processo. Esta escala vai desde não atingir o propósito básicodo processo até atingir precisamente objetivos de negócio atuais para o processo. Dentrodo framework a medida da capacidade é baseada em um conjunto de nove atributosde processo (AP), em total conformidade com a ISO/IEC 15504-2: AP 1.1 (o processo éexecutado), AP 2.1 (o processo é gerenciado), AP 2.2 (os produtos de trabalho do processosão gerenciados), AP 3.1 (o processo é de�nido), AP 3.2 (o processo está implementado),AP 4.1 (o processo é medido), AP 4.2 (o processo é controlado), AP 5.1 (o processo éobjeto de inovações), AP 5.2 (o processo é otimizado continuamente).

Cada AP contém um conjunto de resultados de atributo de processo (RAP) utilizadospara avaliar a implementação de um AP. A dimensão de processo do MR-MPS, por suavez, é constituída do conjunto de processos de engenharia de software que deve ser avaliadopara o nível de maturidade pretendido.

3.2 Níveis de Maturidade

Os níveis de maturidade estabelecem patamares de evolução de processos, caracter-izando estágios de melhoria da implementação de processos na organização. O nível dematuridade em que se encontra uma organização permite prever o seu desempenho futuroao executar um ou mais processos. O MR-MPS de�ne sete níveis de maturidade: A (EmOtimização), B (Gerenciado Quantitativamente), C (De�nido), D (Largamente De�nido),E (Parcialmente De�nido), F (Gerenciado) e G (Parcialmente Gerenciado). Para cadaum destes sete níveis de maturidade é atribuído um per�l de processos que indicam ondea organização deve colocar o esforço de melhoria. O progresso e o alcance de um determi-nado nível de maturidade MPS se obtém quando são atendidos os propósitos e todos osresultados esperados dos respectivos processos e dos atributos de processo estabelecidospara aquele nível.(21)

29

3.3 Nível G � Parcialmente Gerenciado

O Nível G é o primeiro nível do MPS.BR adotado pela maioria das empresas certi�-cadas até o presente ano. Vamos detalhar mais o nível G pois é o que temos por objetivotratar nesse trabalho. O nível de maturidade G é composto pelos processos Gerênciade Projetos e Gerência de Requisitos. Neste nível a implementação dos processos devesatisfazer os atributos de processo AP 1.1 e AP 2.1.

3.3.1 Gerência de Projetos � GPR

O processo de gerência de projetos é a primeira camada do processo de engenharia desoftware que abrange todo o processo de desenvolvimento, do começo ao �m. A gerên-cia de projetos oferece uma compreensão do escopo do trabalho a ser feito, dos riscos,dos recursos exigidos, das tarefas a serem executadas, dos marcos de referência a seremacompanhados, do custo e da programação a ser seguida(17).

O MPS.BR destaca o processo de gerência de projetos com o objetivo de estabelecere manter planos que de�nam as atividades, recursos e responsabilidades do projeto, bemcomo prover informações sobre o seu andamento que permitam a realização de correçõesquando houver desvios signi�cativos no seu desempenho(21).

Resultados Esperados

Os resultados esperados pela correta implantação do processo de gerência de projetos,representados pela sigla GPR n, atribuído ao nível G do MPS.BR são apresentados aseguir:

GPR 1. O escopo do trabalho para o projeto é de�nido, apresentando todo o trabalhonecessário para entregar um produto e/ou serviço que satisfaça as necessidades, car-acterísticas e funções especí�cas para o projeto, de forma a concluí-lo com sucesso;

GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizandométodos apropriados. Todo o trabalho deve ser decomposto em componentes menores,a �m de facilitar seu gerenciamento. A estrutura de decomposição fornece umareferência para atribuição de tamanho, esforço, cronograma e responsabilidades, eé utilizada como uma estrutura subjacente para planejar, organizar e controlar otrabalho executado no projeto;

GPR 3. Omodelo e as fases do ciclo de vida do projeto são de�nidos, permitindo planejaro projeto, incluindo marcos importantes para o controle e revisões. No ciclo devida são de�nidas as fases e as atividades do projeto, de acordo com o escopo dosrequisitos, as estimativas para os recursos e sua natureza. A determinação das fasesdo ciclo de vida do projeto possibilita períodos planejados de avaliação e de tomadade decisões, nos quais compromissos signi�cativos são realizados com relação aosrecursos, abordagem técnica, reavaliação de escopo e custo do projeto;

GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho sãoestimados com base em dados históricos ou referências técnicas, incluindo os dadosde custo, esforço e tempo de projetos executados anteriormente, além de dadosapropriados de escala para equilibrar as diferenças de tamanho e complexidade;

30

GPR 5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de con-trole, são estabelecidos e mantidos. São identi�cadas as tarefas do projeto e poten-ciais gargalos, que são resolvidos quando possível, e o cronograma das atividadesé estabelecido, com início, duração e término. Com base no cronograma e na es-timativa de custos, re�etida pelos recursos requeridos, é estabelecido o orçamentodo projeto. Este resultado é importante porque o cronograma e o orçamento sãoinstrumentos fundamentais para o acompanhamento do dia-a-dia do projeto. Destaforma, sempre que necessário, devem ser revistos e atualizados;

GPR 6. Os riscos do projeto são identi�cados e o seu impacto, probabilidade de ocor-rência e prioridade de tratamento são determinados e documentados. Para facilitara identi�cação dos riscos, é interessante elaborar-se uma lista de riscos mais co-muns, que deve ser examinada pelo gerente do projeto e/ou equipe do projeto paraidenti�car quais destes são potenciais riscos para o projeto em questão. Os riscosidenti�cados devem ser registrados, bem como o acompanhamento dos seus esta-dos e ações tomadas. No nível G, os riscos são acompanhados para veri�car comoafetam o projeto e para se tomar as medidas, aplicáveis mesmo que ainda sem umgerenciamento completo;

GPR 7. Os recursos humanos para o projeto são planejados considerando-se o per�le o conhecimento necessário para executá-lo, determinando-se as funções, respon-sabilidades e relações hierárquicas do projeto. As funções do projeto podem serdesignadas para pessoas ou grupos, os quais podem ser internos ou externos à orga-nização;

GPR 8. As tarefas, os recursos e o ambiente de trabalho necessários para executar oprojeto são planejados, devendo ser especi�cadas as tarefas e previstos os recursos eo ambiente necessário, incluindo, por exemplo, equipamentos, ferramentas, serviços,componentes, viagens e requisitos de processo. Este planejamento é importante, poisrecursos especiais precisam de suporte orçamentário, o que pode se tornar críticoem alguns projetos, se não forem previstos;

GPR 9. Os dados relevantes do projeto são identi�cados e planejados quanto à forma decoleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança. O motivo dese coletar cada dado também deve ser evidenciado, pois coletá-lo, armazená-lo,distribuí-lo de forma controlada e mantê-lo atualizado, implica em custo. A questãoda con�dencialidade, mesmo quando não declarada pelo cliente, deve ser tratadacom extremo cuidado;

GPR 10. Planos para a execução do projeto são estabelecidos e reunidos no Plano doProjeto. Todas as informações de�nidas e coletadas para o projeto devem ser orga-nizadas de forma a possibilitar um gerenciamento adequado do projeto. A reuniãodesses documentos é conhecida como sendo o Plano do Projeto;

GPR 11. A viabilidade de atingir as metas do projeto, considerando-se as restrições e osrecursos disponíveis, é avaliada. Se necessário, ajustes são realizados. O estudo daviabilidade considera o escopo do projeto e examina aspectos técnicos, �nanceiros

31

e humanos. Deve-se considerar também os objetivos de negócio da organização.Muitas vezes é preferível não iniciar ou parar um projeto do que prosseguir com umprojeto inviável, o que pode levar a perdas maiores, tanto para o fornecedor comopara o cliente;

GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromissocom ele é obtido. Negociações devem ser realizadas quando existem con�itos entreas diversas variáveis do projeto, como requisitos, custos e prazos. A solução doscon�itos e estabelecimento de compromissos é fundamental para que o projeto possaefetivamente contar com recursos planejados, para atingir as metas de�nidas;

GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano doProjeto e os resultados são documentados. O acompanhamento pode ser realizadoutilizando-se ferramentas de planejamento, em que se pode examinar o previstocontra o realizado, usando-se indicadores de progresso e cumprimento de marcos,entre outros. Pode também ser feito por meio de reuniões e comunicação pessoal;

GPR 14. O envolvimento das partes interessadas no projeto é gerenciado, podendo in-cluir o cliente e o usuário, a direção da organização e os membros da equipe do pro-jeto. Este resultado é importante porque o distanciamento da gerência do projetoem relação aos interessados pode acarretar desvios em relação às reais necessidadesque o projeto deverá atender;

GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no plane-jamento. Os marcos do projeto precisam ser previamente de�nidos ao se realizaro planejamento do projeto. As revisões em marcos podem ter um caráter formal,com participação de gerências superiores, representantes do cliente e outras partesinteressadas no projeto. Este resultado é importante, porque as revisões em marcossão oportunidades para veri�car, de forma ampla, o andamento de todo o projeto,independente do acompanhamento do dia-a-dia;

GPR 16. Registros de problemas identi�cados e o resultado da análise de questões per-tinentes, incluindo dependências críticas, são estabelecidos e tratados com as partesinteressadas. Todos os problemas encontrados com os resultados anteriores devemser registrados e gerenciados até a sua correção;

GPR 17. Ações para corrigir desvios em relação ao planejamento e para prevenir arepetição dos problemas identi�cados são estabelecidas, implementadas e acompan-hadas até a sua conclusão. Como resultado dos acompanhamentos citados ante-riormente, problemas são identi�cados, analisados e registrados. Ações corretivasdevem ser estabelecidas para resolver problemas que possam impedir o projeto deatingir seus objetivos. O controle dos problemas levantados, as ações tomadas, osresponsáveis pelas ações e os resultados devem ser registrados.

3.3.2 Gerência de Requisitos - GRE

Os problemas que os projetistas de software têm para solucionar são, muitas vezes,muito complexos. Compreender a natureza desses problemas pode ser muito difícil, es-pecialmente se o sistema é novo. Consequentemente, é difícil estabelecer o que o sistema

32

deve fazer. As descrições das funções e das restrições são os requisitos do sistema, eo processo de descobrir, analisar e documentar essas funções e restrições é chamado deengenharia de requisitos (22).

O propósito desse processo no Nível G do MPS.BR é gerenciar os requisitos dos pro-dutos e componentes do produto do projeto e identi�ca (21).

Algumas das atribuições do processo de requisitos são: revisão dos requisitos recebidosde um fornecedor de requisitos e prevenir seu mal entendimento; documentar as mudançasnos requisitos e suas justi�cativas; manter a rastreabilidade bidirecional entre os requisitose produtos de trabalho em geral; identi�car inconsistências entre os requisitos, os planosdo projeto e os produtos de trabalho do projeto; entre outras (21).

Resultados Esperados

Segundo (21), os resultados esperados pela correta implantação do processo de gerênciade requisitos, representados pela sigla GRE n, atribuído ao nível G do MPS.BR são:

GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos, coma �nalidade de garantir que os requisitos estejam claramente de�nidos. Para que issoocorra, deve-se rever com o fornecedor de requisitos se as necessidades e expectativasestão sendo atendidas com os requisitos propostos e, com essa con�rmação, criarum documento de requisitos. Todas as comunicações com o fornecedor de requisitosdevem ser registradas em atas, e-mails, ferramentas de comunicação ou outros meios,sendo necessário uma comprovação de que os interessados estão de acordo com oconteúdo registrado;

GRE 2. Os requisitos de software são aprovados utilizando-se critérios objetivos, en-volvendo a equipe técnica da organização e o cliente. Esses critérios devem serestabelecidos previamente, tais como: possuir identi�cação única; estar claro eapropriadamente declarado; ser relevante; ser completo; estar consistente com osdemais requisitos; ser implementável, testável e rastreável. Deve ter muita cautelaao aprovar novos requisitos, pois uma mudança nos requisitos de um projeto podeimpactar signi�cativamente em termos de escopo e estimativas de cronograma eesforço;

GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é es-tabelecida e mantida, permitindo rastrear a dependência existente entre eles. Comisso, facilita-se a avaliação do impacto das mudanças de requisitos que possam ocor-rer, por exemplo, nas estimativas do escopo, nos produtos de trabalho ou nas tarefasdo projeto;

GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visandoidenti�car e corrigir inconsistências em relação aos requisitos. Ao identi�car algumainconsistência entre os requisitos e os demais elementos do projeto, estas devemser registradas e cabendo executar ações corretivas a �m de resolvê-las. Se houvermudanças nos requisitos, deve-se executar essa revisão para identi�car se todos osartefatos do projeto estão consistentes;

33

GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto através de docu-mentação das mudanças e de manutenção do histórico das decisões tomadas acercadessas mudanças. Estas decisões são tomadas por meio da realização de análisesde impacto da mudança no projeto e podem incluir aspectos como: in�uência emoutros requisitos, expectativa dos interessados, cronograma, riscos e custo.

34

Capítulo 4

Estudo de Caso

Para cumprir nosso objetivo que é propor e avaliar a implantação de um processo desoftware baseado em SCRUM que atenda o MPS.BR nível G em uma pequena empresade software, realizamos um estudo de caso.

4.1 Divisão do Estudo e Hipóteses Levantadas

Dividimos nosso trabalho em dois estudos de caso, cada uma com a avaliação de umadas seguintes hipóteses:

Hipótese 1: É viável e satisfatório adotar um processo baseado no SCRUM em umaempresa brasileira de software de pequeno porte sem processo de�nido.

Hipótese 2: É viável e satisfatório adotar um processo baseado no SCRUM em uma em-presa brasileira de software de pequeno porte, atendendo as exigências do MPS.BRnível G.

As hipóteses se referem a processos baseados em SCRUM visto que este é um frame-

work de processos e não um processo em si 2.4.A primeira hipótese remete à busca de uma alternativa de processo para adoção em

pequenas empresas sem processo de�nido, que constitui um caso típico entre as empresasde software brasileiras(15). O primeiro estudo constitui um estudo de viabilidade daadoção do framework SCRUM, de forma a validar essa hipótese.

O segundo estudo é onde realmente cumprimos nosso objetivo inicial, tentando adaptaro processo baseado em SCRUM para atender o nível G do MPS.BR.

4.2 A Empresa Estudada

A e-Sec é uma empresa de desenvolvimento de software de pequeno porte com focoem desenvolvimento de soluções de segurança digital. Suas principais atividades é licen-ciamento de soluções de software para certi�cação digital, consultoria e desenvolvimentode software por demanda, relacionado à área de atuação da empresa.

Nesta seção efetuamos o levantamento do funcionamento da e-Sec e das suas necessi-dades. Os seguintes pontos foram analisados:

35

• Os aspectos relacionados ao modelo de negócio da e-Sec que impactam diretamenteno desenvolvimento de software. Levantamento do tipo de software desenvolvido, oestilo de cliente envolvido com este e as características dos projetos realizados naempresa.

• As características da equipe de desenvolvimento de software. Necessário para veri-�car se o formato da equipe disponível e o estilo dos pro�ssionais se encaixam coma proposta ágil.

• O mapeamento do processo praticado. Mesmo sem a de�nição formal de processona empresa, foi esboçado as atividades e fases existentes no desenvolvimento.

• O diagnóstico dos problemas relacionados com o processo da empresa. Levantar asnecessidades e falhas existentes no procedimento utilizado.

4.2.1 Histórico

O início das atividades que vieram a resultar na constituição da e-Sec se deu em1997, através de um trabalho de graduação em criptogra�a do Departamento de Ciênciada Computação da Universidade de Brasília, orientado pelo Professor Pedro Rezende,executado pelos futuros sócios fundadores: Luciano Coelho, José Luiz Brandão e RodrigoSodré.

Nos anos seguintes, com a execução de diversos outros serviços de desenvolvimentode soluções seguras, a e-Sec vem pesquisando e evoluindo continuamente seus produtospara os mais diversos �ns. O EVO Autoridade Certi�cadora foi negociado com o gov-erno de Portugal para o órgão CEGER. Recentemente está em fase �nal de implantaçãona Secretaria Nacional de Segurança Pública, em licitação vencida pela e-Sec, como in-fraestrutura de suporte para um sistema de comunicação segura também desenvolvidopela e-Sec. Atualmente a empresa Certisign, uma das principais fornecedoras de tecnolo-gia para certi�cação digital do país, é parceira da e-Sec em revenda de seu produto EVOSDK para seus clientes, visto a excelência de sua qualidade. Dentre as principais empre-sas públicas que utilizam este produto podemos citar: ITI, SENASP, TJ-MT, MP-MT,Aeronáutica, Exército, CNJ, CAESB, SABESP, PETROBRÁS, POUPEX, PROSSERGS,MEC, TJ-DF, TJ-PA, TJ-RO, TC-DF, TST.

4.2.2 Desenvolvimento de Produtos

A e-Sec destaca-se pelo desenvolvimento próprio dos recursos de segurança, projetando-os na íntegra ou na sua adaptação às particularidades de cada projeto. Indo além dosprodutos prontos con�gurados, um sistema de segurança projetado e/ou adaptado aocontexto em que vai atuar atinge um novo nível de integração que permite ganhos adi-cionais ao ambiente, tais como maior nível de automatização, menor tempo de resposta aincidentes, melhor usabilidade e melhor aproveitamento dos recursos em geral.

A iniciativa de desenvolver seus próprios produtos de segurança deu à e-Sec a exper-iência diferenciada que levou a ser contratada pelos projetos ao qual foi contratada, men-cionados anteriormente. Tais projetos contribuíam, por sua vez, na evolução dos produtosdesenvolvidos pela e-Sec, o que cria um ciclo positivo de crescimento e aprimoramento deambos produto e serviços da empresa.

36

4.2.3 Tipos de Projetos Desenvolvidos

A e-Sec trabalha com basicamente três modelos de negócio: prestação de serviço dedesenvolvimento de software, venda de produtos e consultoria. A partir desses modelosde negócio, os projetos desenvolvidos seguem dois tipos de produção de software distintos,explicados a seguir.

Desenvolvimento de Software por Demanda

Nesse tipo de desenvolvimento, uma empresa pública ou privada contrata a e-Sec paradesenvolver um sistema com um escopo inicial bem de�nido. Os requisitos, o prazo deconclusão, os custos e a qualidade do software demandado são de�nidos em contrato.

Na maioria dos casos a contratação é efetuada por empresas públicas. De modo queo contrato consiste em um edital de licitação com todos esses pormenores descritos.

O software produzido pela prestação de serviço de desenvolvimento é executado dentrode um escopo de�nido pelo cliente (tanto de tempo, quanto de custo). Consiste emum projeto de desenvolvimento de software por demanda, de acordo com a necessidadeespecí�ca de um cliente.

Desenvolvimento de Produtos

Nesse segundo tipo de produção a e-Sec destina parte de seus recursos para a criaçãoe manutenção de seus produtos. Estes são criados na tentativa de suprir certa demandade software na fatia de mercado a qual a empresa atua. Em muitos casos os produtossão frutos da generalização de software um anteriormente desenvolvido por demanda, deforma que na sua adaptação seja retirada alguns requisitos especí�cos do cliente anterior.

No software produzido a partir do desenvolvimento de produtos, o escopo é �exívele a solução deve atender uma gama considerável do mercado de solução de segurançadigital, de forma que o mesmo software resolva o problema de diversos clientes de formaabrangente.

4.2.4 A Equipe de Desenvolvimento

A e-Sec tem executado com sucesso projetos de duração de 3 a 24 meses com equipesde tamanho médio de 5 pro�ssionais. Sendo que a maior parte da equipe é composta pormembros de conhecimento heterogêneo e com alto grau de conhecimento e experiênciaem sua área de especialidade. Estagiários e outros funcionários com menor experiênciacompõe o restante da equipe.

Normalmente, a equipe é composta pelo gerente de projeto, um ou dois analistasdependendo do tamanho e complexidade do projeto e pelos desenvolvedores. Na maioriados casos o gerente de projeto acumula a função de analista, participando ativamente dolevantamento do escopo e dos requisitos do sistema em construção.

4.2.5 O Processo de Desenvolvimento

O processo de desenvolvimento não era de�nido e não estava descrito, mas aconteciacomo um processo iterativo de 7 fases: contratação, análise, desenvolvimento, testes,correções e adequações, homologação e implantação.

37

Devido a erros na avaliação do cronograma e orçamento do projeto nem sempre asfases de análise e testes eram bem executadas.

Contratação

Caso o cliente possua os requisitos do sistema a ser desenvolvido, a área comercialrepassa estes para a área técnica. No caso do cliente não possuí-los o suporte de pré-vendas avalia a possibilidade de levantar os requisitos junto ao cliente, caso seja inviável�nanceiramente e o cliente não queira ou não possa remunerar esta atividade de levanta-mento de requisitos, o suporte é encerrado.

Com os requisitos em mãos, a área técnica analisa a documentação e faz a estimativade prazos e custos para desenvolvimento, para isso, utilizando um cronograma de projeto.A partir daí, a área comercial avalia a viabilidade �nanceira do projeto em conjunto coma área técnica.

Análise

Parte da análise é efetuada no levantamento de requisitos em conjunto com a con-tratação, durante a elaboração do escopo inicial do projeto. Com os requisitos em mãos,é feita a modelagem do sistema, de forma que todos os requisitos sejam cumpridos. Paraisso, geralmente o sistema é detalhado em casos de uso, os quais são documentados tex-tualmente. No entanto a modelagem com casos de uso nem sempre é executada.

Após a modelagem, o cronograma do projeto é detalhado e avalia-se a viabilidade doprojeto de acordo com a previsão do cronograma inicial do projeto. Caso não esteja, ocronograma é reavaliado conjuntamente com o cliente. Se o novo cronograma estiver emcondições de prosseguir, inicia-se o desenvolvimento dos módulos do sistema.

A fase de análise é executada sempre que é necessário iterações de adequações do pro-jeto, tanto em evoluções quanto em correções de decisões errôneas em análises anteriores.

Desenvolvimento

O desenvolvimento consiste na implementação dos módulos levantados na fase deanálise. O trabalho é delegado aos desenvolvedores envolvidos no esforço de implemen-tação e é acompanhado pelo gerente de projeto. Novas tarefas de implementação sãopassadas aos programadores na medida em que as anteriores são �nalizadas. Não existede�nição do tempo gasto em cada iteração.

Testes

A fase de testes ocorre em iterações conjuntamente com as fases de análise e desen-volvimento com o objetivo de detectar erros de programação e identi�car a necessidade deadequações e evoluções do sistema. A partir da �nalização da primeira versão funcionaldo sistema, este é apresentado ao cliente para que seja testado e validado. De acordo como cronograma, novas versões mais completas vão sendo apresentadas incrementalmente.

A iteratividade do processo de testes é dependente do nível de acompanhamento que ocliente apresenta no projeto. Em alguns casos o cliente acompanha a evolução do sistemadesde versões mais iniciais, com poucos módulos funcionais. Em outros, o cliente preferetestar uma versão mais completa.

38

Correções e Adequações

De acordo com o feedback do cliente na fase de testes, são requisitadas as correções dosbugs e adequações do sistema a serem efetuadas. Todas essa requisições são avaliadas pelaa equipe técnica e comercial, de forma que o orçamento do projeto não seja prejudicado.Caso sejam pertinentes, são repassadas para uma nova análise e executadas na fase dedesenvolvimento, em mais uma iteração análise, desenvolvimento, testes.

Homologação

À medida que o desenvolvimento de versões funcionais do sistema é encerrada, ela éenviada ao cliente para homologação. Caso homologado, o setor �nanceiro é noti�cadopara a fatura, caso contrário, é executada a fase de correções e adequações. Após ahomologação do último módulo, com todos os requisitos cobertos pelo sistema, as fasesde desenvolvimento e testes é �nalizada.

Implantação

Após a homologação do sistema, em versão �nal ou não, este é colocado em produçãocom o suporte da equipe técnica do cliente.

4.2.6 Problemas

Devido a inde�nição do processo os membros da equipe de desenvolvimento não sabemexatamente o que fazer, dependendo da experiência do gestor do projeto para direcioná-los. É comum um desenvolvedor �car ocioso por falta de orientação. Essa inde�nição tam-bém acarreta em di�culdade de acompanhamento do estado do projeto. Sem a de�niçãode marcos do projeto é difícil estimar quanto foi executado ou quanto falta para �nalizar.

Com o processo de desenvolvimento inde�nido é difícil avaliar as práticas e proporsoluções aos problemas que são identi�cados. Alguns destes problemas serão listados aseguir:

Mudança de pessoas envolvidas: Algumas vezes durante a execução do projeto mu-dam as pessoas envolvidas no projeto do lado do cliente . É difícil situar os novosenvolvidos no que está sendo desenvolvido e que escolhas foram tomadas anterior-mente.

Análise de custo e contratação: Não é de�nido um método de cálculo de custo doprojeto, o que torna a empresa muito dependente da experiência de algumas pessoas.O risco de um cálculo errado de custo, e consequente prejuízo, é elevado.

Modelagem: inde�nição quanto a quais artefatos gerar. Essa fase é frequentementenegligenciada quando o cronograma não é favorável.

Ambiente de desenvolvimento: A equipe perde muito tempo con�gurando o ambientee solucionando problemas.

Inde�nição no início de um projeto: A não existência de manuais com padrões, comopor exemplo nome do projeto na base de controle de versão, leva o desenvolvedor a

39

perder tempo pensando em seu próprio padrão ou consultando alguém um membroda equipe mais experiente.

Inexistência de padrões: Como os procedimentos e artefatos não são padronizados, édifícil a consulta e entendimento posterior.

Inexistência histórico de erros e requisições de mudanças: Di�culdade de acom-panhamento de mudanças. As requisições são comunicadas por e-mail e não sãocatalogadas.

Inexistência de métricas de estimativas de custos e prazo: Pela inexistência de de�niçãode método as estimativas são muito imprecisas. O que di�culta o planejamento eimpacta todo o projeto desde o seu início.

Os problemas levantados estão diretamente relacionados com a inexistência de pro-cesso de�nido. Como não foi adotada uma cultura de documentação as soluções sãodesenvolvidas mas são perdidas.

4.3 Primeiro Estudo de Caso: Adoção do SCRUM

Esse estudo de caso tem como objetivo avaliar a primeira hipótese do nosso trabalho.Iniciamos esse estudo revisando a teoria do SCRUM. Utilizamos para a adoção prin-

cipalmente o Scrum Guide(20).Como vimos, o SCRUM é um framework de processo e não um processo em si. Desta

forma quando se adota o SCRUM em um projeto é preciso fazer escolhas que adaptem oSCRUM ao seu ambiente. Esse é o primeiro passo de adoção do SCRUM. Iremos listar napróxima seção os pontos de adaptação e as de�nições realizadas. Como orienta Schwaber(19) procuramos aproveitar as técnicas e ferramentas que já eram utilizadas com sucessono ambiente.

Em seguida executamos um projeto com esse processo. Iremos descrever o projeto emseguida.

4.3.1 Pré-Requisitos para a Adoção do SCRUM

As adaptações necessárias para a implantação do SCRUM são descritas nessa seção.

Escolha da Ferramenta de Gerência do SCRUM

Para adoção do processo SCRUM procuramos uma ferramenta de gerência de tarefase dos itens do Backlog. Depois de uma pesquisa e avaliação das opções escolhemos o Agiloque é um plugin para o TracI.4.1.Com essa escolha presamos pela adaptação a cultura daempresa que já tinha familiaridade com o Trac de projetos anteriores.

De�nição da Visão do Sistema

O processo SCRUM começa com a visão do sistema. O SCRUM não especi�ca comode�nir essa visão. No entanto decidimos que seria melhor de�nir um modelo de documento

40

de visão bem estruturado, pois isso ajudaria a contornar o problema de mudança deenvolvidos levantado 4.2.6.

De�nição dos Itens do Backlog

O SCRUM especi�ca que o Backlog contém os requisitos para que o produto sejaentregue com sucesso. No entanto ele não especi�ca como esses requisitos devem serdescritos. Na empresa estudada já era utilizado com sucesso a especi�cação de sistemacom requisitos funcionais, casos de uso e diagrama UML de realização de casos de uso. Apartir disso, de�nimos que os itens do Backlog seriam compostos por casos de uso.

Método de Estimativas

Aplicamos a técnica de estimativa de Story Points descrita na seção 2.10.

De�nição dos Time-Boxes

De�nimos que as Sprints teriam duração de uma semana. Escolhemos essa duraçãoporque queríamos ciclos curtos de feedback, Julgamos que isso ajudaria a diminuir os riscose nos ajudaria a obter mais experiência na condução das cerimônias.

A duração das outras reuniões não achamos necessário restringir, pois a Sprint reduzidadiminui também o tamanho do conteúdo a ser discutido. Entre 1 a 4 horas cada reuniãose resolvia tranquilamente.

No ambiente da e-Sec julgamos que obrigar a reunião diária não era necessária porque a equipe era su�cientemente pequena e bem integrada. Um acompanhamento diáriopor parte do ScrumMaster é su�ciente.

4.3.2 Realização do Projeto Piloto

O Projeto piloto da adoção de SCRUM na e-Sec foi o projeto Exército-Noti�cação umprojeto para o Exército Brasileiro.

O Exército Brasileiro propôs a criação de um sistema WEB de Noti�cações eletrônicasonde seria possível enviar noti�cações de forma mais ágil, barata e con�ável. O sistemaserá desenvolvido de forma que existam três tipos de usuários: Administrador, Operadore Destinatário.

O Administrador poderá criar contas de operadores e destinatários e terá liberdadepara gerenciá-los. O Operador poderá criar documentos e enviar noti�cações aos des-tinatários. A noti�cação será um e-mail enviado ao destinatário informando que existeum documento direcionado a ele, com o link para este documento. O Destinatário rece-berá as noti�cações e poderá realizar o download do documento a ele destinado mediantevalidação de seu certi�cado digital pertencente à hierarquia da ICP-Brasil.

Começamos o processo com a análise inicial, obtendo escopo do projeto com Docu-mento de Visão, o levantamento dos requisitos e a construção dos artefatos especi�cados,como especi�cado no processo de�nido.

Os requisitos iniciais do sistemas são os descritos a seguir:

• Existência de uma funcionalidade que vise gerenciar o cadastro de usuários do sis-tema;

41

Figura 4.1: Processo utilizado no projeto piloto

• Existência de uma funcionalidade que vise permitir a autenticação do usuário nosistema;

• Um usuário somente poderá acessar o sistema através de Certi�cação Digital;

• Documentos somente poderão ser enviados para usuários cadastrados;

• Existência de três per�s de usuário: Administrador, Operador e Destinatário;

• Existência de uma funcionalidade que vise inserir um documento dentro do sistema;

• Um documento poderá ser enviado para um ou mais usuários;

• Existência de uma funcionalidade que vise enviar ao usuário uma noti�cação de queexiste um documento destinado a ele;

• Existência de uma funcionalidade que vise permitir que o usuário que recebeu umnoti�cação possa efetuar download do seu documento;

• O usuário deverá, através do seu certi�cado digital, assinar eletronicamente umcomprovante de recebimento do documento;

• Existência de uma funcionalidade que permita que o administrador consulte as no-ti�cações; enviadas por ele e a situação delas: Recebida ou Não Recebida.

Com o escopo inicial do projeto, realizamos a Reunião de Planejamento da Release.De�nimos o Backlog inicial, realizando as estimativas dos itens do Backlog.

42

O próximo passo foi a execução das Sprints, sendo que cada uma delas iniciou com aReunião de Planejamento. Ao �nal de cada Sprint foi realizada um Reunião de Revisãoda Sprint, onde também eram realizados os testes do que foi implementado. Também erarealizada uma retrospectiva da Sprint, conforme o SCRUM recomenda. No total foramrealizadas 4 Sprints.

4.3.3 Resultados Obtidos

Conseguimos com a implantação do processo resolver algum dos problemas que havíamoslevantado:

Os membros da equipe não sabem o que fazer: agora com um processo de desen-volvimento bem de�nido cada um sabe seu papel;

Di�culdade de acompanhamento do projeto: consideramos que agora podemos fazerum acompanhamento razoável do estado do projeto, a qualquer momento o Scrum-Master é capaz de informar qual o estado atual do projeto e qual a estimativaatualizada de término do projeto;

Inexistência de métodos de estimativas de esforço e prazo: publicamos ummétodopadronizado de estimativa de esforço e prazo;

Desde a primeira Sprint a tentativa de utilização do SCRUM pareceu melhor do que ainde�nição anterior e os envolvidos se mantiveram motivados a adotar o processo durantetoda a execução do projeto. Na última Sprint o desenvolvimento já estava razoavelmentealinhado.

Podemos desta forma con�rmar que o SCRUM é de fácil adoção, não sendo necessáriogrande investimento em treinamento. Apenas o ScrumMaster precisa dominar os conceitosdo framework SCRUM e entender o ambiente para fazer as adaptações apropriadas. Noentando nessa adoção, apesar de a orientação do SCRUM ter melhorado o desenvolvimentona e-Sec nesse processo, alguns problemas ainda persistiam.

Problemas

Demorou um pouco até o time se adaptar a todos os conceitos. Nas primeiras Sprintsos membros do time tiveram di�culdade em se concentrar em executar somente o que estáde�nido em cada tarefa. Desta forma ao chegar ao �nal da Sprint pouco do trabalho quetinha sido planejado estava completamente executado. Algumas Sprints depois o timecomeçou a se concentrar melhor em cada tarefa.

Mas o maior problema que nos deparamos foi o teste e validação das tarefas execu-tadas durante a Sprint. Inicialmente decidimos efetuar a veri�cação das tarefas durantea Revisão da Sprint e nesse ponto sempre nos deparávamos com uma enxurrada de er-ros de codi�cação, padrão visual e bugs em geral. Os problemas entravam no Backloge as correções eram executadas na Sprint seguinte, e as funcionalidades tinham que sernovamente revistas na reunião da Sprint seguinte. Chegamos a conclusão que a raiz doproblema era o nosso conceito de pronto das tarefas, e isso foi revisto no segundo estudode caso.

43

Avaliação da Primeira Hipótese

Hipótese: É viável e satisfatório adotar um processo baseado no SCRUM em umaempresa brasileira de software de pequeno porte sem processo de�nido.

Avaliamos que a hipótese é sim válida. Conseguimos desenvolver um projeto comsucesso na e-Sec. A adoção do SCRUM se mostrou viável e satisfatória. Apesar de nãoter resolvido todos os problemas que levantamos na nossa análise inicial, resolveu umaparte.

4.4 Segundo Estudo de Caso: Adoção do MPS.BR NívelG

O estudo de caso consistiu no estudo do MPS.BR com o foco no preenchimento daslacunas do processo utilizado na primeira parte, para atender o modelo de referência donível G, e na resolução do problemas encontrados na execução anterior. No �nal avaliamosa segunda hipótese.

Por ser muito extenso e detalhista, a descrição do processo resultante desseestudo está no anexo I e a validação deste perante o MPS.BR está no anexoII.

4.4.1 Melhorando o Processo

A adoção do MPS.BR e a resolução dos problemas da execução anterior são descritosnessa seção.

Lacunas do SCRUM em Relação ao MPS.BR

O framework SCRUM oferece suporte à vários itens referentes à gerência de projetos.Muitos dos itens são explicitamente satisfeitos aplicando-se o Scrum. No entando al-guns itens constituem lacunas não especi�cados nos manuais de SCRUM que estudamos.Quanto a gerência de requisitos o SCRUM atende a todos os itens, menos ao GRE 3.

Estes itens de são:

GPR 4 Estimativas de esforço e custo com base em dados históricos ou referências téc-nicas;

GPR 6 Análise de Riscos;

GPR 7 Necessidade de recursos humanos;

GPR 8 Necessidade de recursos de ambiente de trabalho;

GPR 9 Necessidade de dados quanto à forma de coleta, armazenamento e distribuição;

GPR 11 Análise de Viabilidade do Projeto;

GPR 12 Obtenção de comprometimento formal com os interessados.

GRE 3 Rastreabilidade bidirecional entre os requisitos e os produtos de trabalho.

44

Para cumprir o GPR 4 foi necessária uma reestruturação do método de estimativaaplicado, com a inclusão de medição de esforço durante o andamento do projeto, possibil-itando o armazenamento de dados históricos de esforço realizado para posterior utilizaçãonas estimativas dos projetos futuros.

Os itens relacionados à análise de risco e viabilidade do projeto; e de necessidades derecursos humanos, de ambiente e de dados (GPRs 6 a 11) tem como objetivo garantir aqualidade do planejamento e evitar que a falta de recursos ou riscos prejudiquem o projeto.A análise de todos estes pontos foram inseridos no cheklist na Reunião de Planejamentoda Release como obrigatórios e são registrados em ata I.1.9.

O GPR 12 trata do comprometimento formal entre cliente e empresa desenvolvedora.Na e-Sec todo projeto é formalizado em contrato, onde o escopo é detalhado. O SCRUMnão menciona esse formalismo.

No caso do GRE 3, rastreabilidade bidirecional requisitos/produtos de trabalho, oSCRUM não especi�ca nada sobre. A solução implantada foi a utilização de ferramentaspara manter os requisitos e a rastreabilidade destes nos casos de uso desenvolvidos; e paragerenciar o Backlog, onde se mantém a rastreabilidade dos casos de usos e das tarefasligadas a ele. Através da ferramenta de gerência SCRUM é possível veri�car para cadaalteração no repositório de código fonte a tarefa a qual ela se relaciona e o histórico demodi�cações desta tarefa. A tarefa referencia o caso de uso e no Diagrama de Realizaçãode Casos de Uso mantido pode-se rastrear o requisito.

Solução de Teste, Validação e Conceito de Pronto

A �m de solucionar os problemas de teste e validação encontrados no projeto piloto,percebemos que devíamos inserir uma atividade de teste durante a Sprint de forma aminimizar os erros encontrados durante a revisão da Sprint.

O ideal é que as funcionalidades sejam concluídas e testadas durante a Sprint. Assimde�nimos o nosso conceito de pronto. Uma atividade só está pronta e pode deixar oBacklog quando foi executada e testada por uma pessoa diferente do desenvolvedor.

4.4.2 Realização do Segundo Projeto

O projeto implementado na segunda parte do estudo de caso foi o projeto e-Sec-Licença, um projeto interno da e-Sec. O sistema tem a �nalidade de gerenciar o licencia-mento dos produtos comercializados pela e-Sec.

Os papéis SCRUM foram distribuídos da mesma forma que o projeto anterior, aprovei-tando a experiência adquirida pelos membros da equipe com o primeiro projeto: ProductOwner: o papel foi realizado por José Brandão, que é membro da e-Sec e que conhecia osrequisitos do sistema. ScrumMaster: Marcos Godinho. Time: Gabriel Rodrigues, MarcosGodinho, Cristiano Cristo.

Começamos o processo com a análise inicial, obtendo escopo do projeto com Docu-mento de Visão, o levantamento dos requisitos e a construção dos artefatos especi�cados,como especi�cado no processo de�nido.

Os requisitos iniciais do sistemas são os descritos a seguir:

• Permitir ao Administrador cadastrar, listar, modi�car e deletar cadastro de usuáriosdo sistema, que podem ser administrador ou usuário-cliente.

45

Figura 4.2: Processo resultante do segundo estudo de caso

• O usuário-cliente deve estar associado a um cliente previamente cadastrado.

• Permitir ao Administrador cadastrar, listar, modi�car e deletar cadastro de Clientes.

• Permitir ao Administrador gerenciar licenças adquiridas por um Cliente.

• O sistema deverá gerar um arquivo de licença quando esta for cadastrada.

• Permitir ao Usuário-Cliente visualizar as licenças que possui e seus períodos degarantia.

• Permitir ao Usuário-Cliente baixar uma licença do produto a que tenha direito.

• Permitir ao Administrador gerenciar os períodos de garantia a que um Cliente temdireito.

• Os períodos de vigência das garantias de uma mesma licença não podem se sobrepor.

• Permitir ao Administrador gerenciar versões dos produtos.

• Noti�car o Usuário-Cliente que uma nova versão do produto a que ele tem direitoestá disponível.

• Permitir ao Usuário-Cliente listar as versões do produto a que tem direito de baixar.

• Permitir ao Usuário-Cliente baixar uma versão do produto a que tenha direito.

46

• Permitir ao Administrador cadastrar, listar, modi�car e deletar cadastro de Produ-tos.

A partir do escopo inicial de�nido na análise inicial efetuamos a Reunião de Abertura,situando o time no projeto a ser desenvolvido e discutindo as necessidades adicionais parao início da execução.

Com a equipe entendendo o escopo inicial do projeto, realizamos a Reunião de Planeja-mento da Release. De�nimos o Backlog inicial, realizando as estimativas de complexidadedos itens do Backlog e desenvolvemos um plano de desenvolvimento da release, de acordocom a de�nição do processo.

O próximo passo foi a execução das Sprints, sendo que cada uma delas iniciou coma Reunião de Planejamento e �nalizou com as Reuniões de Revisão e Retrospectiva.Durante a execução das Sprints aplicamos o método de teste idealizado e procuramosseguir a de�nição de pronto. No total foram realizadas 4 Sprints.

4.4.3 Resultados Obtidos

As novas práticas inseridas com a adoção do MPS.BR e as correções dos problemassurgidos na primeira parte melhoraram signi�cantemente o processo e o desenvolvimentodesse segundo projeto.

O conceito de pronto de�nido em conjunto com os testes durante a Sprint melhorarama qualidade do software produzido.

O cumprimento dos requisitos de gerência de projetos proposto no MPS.BR, descritoscomo lacunas do SCRUM na seção 4.4.1, melhorou o planejamento do projeto. Itenscomo necessidades de recursos humanos e físicos e os riscos projeto sendo necessariamentelevados em consideração no início do projeto evitaram futuros problemas, permitindopensar premeditadamente ao invés de remediar o surgimento dos possíveis impedimentos.

A de�nição da gerência de requisitos com base no MPS.BR melhorou o entendimentoe a clareza do escopo do projeto. A rastreabilidade implantada dos requisitos facilitou avalidação do sistema. É fácil veri�car onde cada requisito se vê presente no sistema.

Problemas

Apesar do bom funcionamento do processo, na medida em que este cresce e se tornamais complexo, também cresce a di�culdade do seu entendimento. Na execução do projetoapareceram algumas di�culdades com a aplicação das práticas implantadas. Surgiu anecessidade de uma melhor documentação.

Para os próximos projetos é importante a criação de uma base de conhecimento de fácilconsulta. Para facilitar a manutenção dessa base de conhecimento, utilizamos ferramentasao estilo Web Wiki I.4.4.

Avaliação da Segunda Hipótese

Hipótese: É viável e satisfatório adotar um processo baseado no SCRUM em umaempresa brasileira de software de pequeno porte, atendendo as exigências do MPS.BRnível G.

47

Deixando claro que o processo é baseado no SCRUM, um framework, avaliamos que ahipótese é sim válida. Os requisitos do MPS.BR nível G foram cumpridos.

O SCRUM é de fácil adoção e aceitação por uma equipe desacostumada com qualquerespécie de processo. Sua aplicação como primeiro passo para um processo mais elaboradoé de grande utilidade.

4.5 Avaliação Qualitativa

Nossa avaliação é que na e-Sec foi possível e satisfatório adotar um processo baseadoem SCRUM e adaptá-lo para cumprir todos os requisitos no MPS.BR nível G. No entandoa adoção de um processo SCRUM sem as devidas adaptações não garante que todos ositens sejam cumpridos.

4.5.1 Suporte do Scrum ao MPS.BR

O framework Scrum oferece bom suporte a Gerência de Projetos, muitos dos itens sãoexplicitamente satisfeitos aplicando-se o SCRUM. No entando alguns itens constituemlacunas não especi�cados nos manuais de SCRUM que estudamos.

Estes itens são:

GPR 4 Estimativas de esforço e custo com base em dados históricos ou referências téc-nicas;

GPR 6 Análise de Riscos;

GPR 7 Necessidade de recursos humanos;

GPR 8 Necessidade de recursos de ambiente de trabalho;

GPR 9 Necessidade de dados quanto à forma de coleta, armazenamento e distribuição;

GPR 11 Análise de Viabilidade;

GPR 12 Obtenção de comprometimento formal com os interessados.

GRE 3 Rastreabilidade bidirecional entre os requisitos e os produtos de trabalho.

O dimensionamento das tarefas é uma prática que aparece nos manuais de SCRUM(20) (19) no entando é deixado ao implementador selecionar o método exato de dimen-sionamento. É fortemente enfatizado que a estimativa seja feita pelo time (20) e que aestimativa seja feita em uma medida de complexidade relativa e sem unidade, os StoryPoints. Não encontramos grande di�culdade de começar a utilizar a estimativa em Story

Points com escala baseada na sequencia de Fibonacci, encontrando resultado satisfatóriodesde as primeiras Sprints. No entando de�nir uma forma prática de cruzar os dados deestimativa de complexidade com os dados de esforço efetivo, de forma a criar um processode melhoria das nossas estimativas se mostrou um desa�o.

As práticas de análise de riscos, viabilidades; levantamento de necessidade de recursoshumanos, de ambiente de desenvolvimento e de dados não apareceu como itens obri-gatórios ou se quer recomendados nos manuais de SCRUM que seguimos, no entando dis-tribuímos essas práticas nas atividades do processo Scrum sem qualquer di�culdade. Isso

48

demonstrou um impacto muito positivo da adoção do MPS.BR justamente com SCRUMna e-Sec, em que os dois se complementaram e ajustaram muito bem.

Já no item GPR 12 se entendermos que o comprometimento exigido pelo MPS.BRdeve ser formalizado em um documento seria um item que o SCRUM não assegura. Noentando a prática de participação do Product Owner na Reunião de Planejamento daRelease e ao dar a ele a responsabilidade pelo Backlog do produto estamos assegurando oseu comprometimento com o plano pela prática do processo ao invés da formalização emdocumento. Pelas características dos projetos da e-Sec julgamos que a formalização emdocumento é mais apropriada.

Quanto a gerência de requisitos o SCRUM atende a todos os itens, menos ao GRE3. Cumprir esse item depende de soluções técnicas do ambiente de desenvolvimento. Nae-Sec o ambiente atende a esse requisito como explicado II.2.

De forma geral fornecer evidências que todas as exigências do MPS.BR estão sendoatendidas é desa�ador, pois o SCRUM não presa pela geração de documentação.

Fazendo uma leitura crítica do SCRUM levantamos alguns pontos de diferenças dospressupostos do SCRUM que não são válidos para o ambiente da e-Sec:

Constante mudança dos requisitos: os projetos na e-Sec costumam ter escopo bemde�nido, dado a forma como o cliente negocia projetos de software. Então na e-Secé mais importante cumprir o prazo e manter o custo do que responder a mudançasconstantes.

Presença do Product Owner: nem sempre o cliente disponibiliza alguém para acom-panhar o projeto ativamente.

Entrega constante de valor: nem sempre o cliente está interessado em veri�car e uti-lizar versões preliminares do software

Podemos citar como diferença do processo adotado com relação ao SCRUM, decor-rentes dessas diferenças:

Planejamento da Release mais estruturado: na adaptação do processo ao MPS.BRadicionamos algumas atividades a reunião de planejamento da release que a deixarammais estruturada.

ScrumMaster realiza o papel do Product Owner: quando o Product Owner nãoestá presente nas cerimônias o ScrumMaster executa seu papel.

Acompanhamento diário: Na e-Sec achamos difícil reunir todas as pessoas diaria-mente, no entanto elas se comunicam ao longo do dia.

Modelagem com casos de uso: é uma forma de modelagem com a qual a empresa jáestava acostumada, preferimos mantê-la

Time reduzido: Apesar do Guia do SCRUM citar o mínimo aconselhável de 5 pessoaspara um Time podemos executar dois projetos bem sucedidos com Times de 3 e 4membros.

Podemos citar com bené�cos para pequenas empresas as seguintes características doSCRUM:

49

É de fácil adoção: Não é burocrático e enfadonho, como os processos que envolvemuma grande quantidade de documentação e atividades. Por isso, os desenvolve-dores não sentem resistência em adotá-lo. Conseguimos adotá-lo com sucesso já noprimeiro projeto mesmo sem nenhum membro ter experiência prática com ele. Elogo sentimos as vantagens de ter um processo de desenvolvimento e uma gerênciade projeto.

É barato: Não adiciona grande sobrecarga de fases, reuniões e documentos além donecessário para a construção dos entregáveis. Sobrecarga que aumentaria o prazopara a produção de um software em funcionamento, pois necessitaria de mais tempopara realizar as demais atividades e maior necessidade de prática. Também nãoexige uma grande quantidade de papéis na equipe (analista, testador, gerente deprojetos,...), o que incrementaria a necessidade de recursos humanos.

É �exível: No time todos podem fazer todas as atividades, o que garante maior �exibil-idade pois a equipe pode ser alocada de várias formas e nunca ninguém �ca ocioso,esperando o trabalho de uma outra especialidade �car pronto.

Dentre as críticas comumente levantadas em relação aos métodos ágeis, duas nós ob-servamos que não são válidas para o SCRUM:

É difícil estimar custo com antecedência. Achamos que podemos ter boas estima-tivas de esforço e custo já na reunião de planejamento da release, e que esssas es-timativas irão �cando mais precisas já nas primeiras Sprints. Apesar da análise deestimativa que utilizamos não ser tão complexa e não haver um grande decomposiçãoe análise das partes do sistema, por outro lado existe muito comprometimento dosmembros do time com suas próprias estimativas e com o sucesso do projeto.

É difícil de acompanhar o desenvolvimento do projeto. Consideramos o acompan-hamento dos nossos projetos muito satisfatório. O grá�co Burndown da Releasefornece uma boa visão do andamento do projeto. Podemos validar isso analisandoos itens de gerência de projeto do MPS.BR.

Veri�camos ainda que os livros SCRUM que consultamos não são su�cientes para aimplantação de um processo de software e�ciente em uma organização. Eles descrevem ofuncionamento do framework como uma metodologia com fases, cerimônias e princípios,sem descrever os pontos de adaptação e um método de especi�cação de processo.

Outro ponto é que o SCRUM não contempla fases e métodos de desenvolvimento desoftware, mas sim de produto em geral.Através dos estudo de caso realizado percebemosque o SCRUM garante uma gerência de projeto ágil, mas não garante todas as atividadestradicionais relativas ao ciclo de desenvolvimento, como por exemplo a não contemplaçãoda atividade de teste. Portanto, o SCRUM em si não é su�ciente para garantir que osoftware seja bem construído e tenha qualidade.

No entanto, através da excelente adaptatividade inerente ao SCRUM e institucional-izada em suas reuniões de retrospectiva, foi possível detectar as de�ciências relativas aoprocesso e tomar as devidas providências para solucioná-las. Como, por exemplo, os prob-lemas relativos a teste e validação. A partir da detecção do problema re�namos o conceito

50

de pronto 2.9, que faz parte do SCRUM, e garantimos assim que o software atendesse aosrequisitos de qualidade.

A adoção do MPS.BR fez com que o processo evoluísse no planejamento de projetoscom a adição da análise de riscos e de viabilidade; e do levantamento de necessidades derecursos humanos e físicos. Além disso, melhorou o entendimento e a clareza do escopodo projeto, com a rastreabilidade dos requisitos/produtos de trabalho, de forma que oprojeto objetive o total cumprimento dos requisitos.

51

Capítulo 5

Conclusão

Nesse trabalho, propusemos e avaliamos a implantação de um processo de softwarebaseado em SCRUM que atenda o MPS.BR nível G em uma pequena empresa de software,o qual se mostrou uma alternativa viável por ser de fácil adoção, de baixo custo e adaptávelà realidade deste tipo de ambiente.

Fizemos uma adoção gradual do processo, aprimorando-a longo das Sprints e dos pro-jetos, até chegar ao processo resultante exibido no anexo I. Sua construção gradual éresultado das características auto-adaptáveis institucionalizadas no modelo do SCRUMque voltam os olhares da equipe para o processo. A adoção do MPS.BR trouxe mel-horas ao planejamento de projetos e na construção/manutenção do escopo do projeto.Complementando os pontos mapeados como lacunas do SCRUM.

Com o nosso trabalho concluímos que o SCRUM não cumpre todos os requisitos doMPS.BR nível G, mas é um ótimo ponto de partida para a sua implantação, visto quesua especi�cação atende a vários itens da gerência de projetos e requisitos exigidas. Alémdisso, sua implantação mostrou-se de fácil adoção, de baixo custo e adaptável.

Apesar da comprovação da viabilidade, são necessários mais estudos com foco emoutras organizações com as características semelhantes para generalizar os resultados aquiobtidos.

Trabalhos futuros também poderiam abordar a qualidade dos processos ágeis, in-vestigando a utilização destes como alternativa para adoção de níveis mais elevados doMPS.BR.

Julgamos que o nosso trabalho teve caráter bem generalista e um escopo extenso.Dessa forma passamos por diversos temas que merecem investigação mais profunda, comoo desenvolvimento de um método de estimativa e acompanhamento relacionado ao custo�nanceiro e não só de esforço de implementação; e a implantação de técnicas de garantiade qualidade, como a automatização de testes.

52

Anexo I

O Processo Proposto

Nesse capítulo vamos descrever o processo de software que implantamos na e-Sec bemcomo as ferramentas auxiliares utilizadas. Este processo é uma adaptação do SCRUMas necessidades da empresa. Como descrito na seção 2.5 o SCRUM é um framework deprocesso ágil, para utilizá-lo é necessário preencher algumas lacunas que iremos destacarao longo deste capítulo.

Ao desnvolver este processo levamos em conta a forma de trabalho na e-Sec e procu-ramos resolver os problemas levantados 4.2.6.

I.1 O Processo

I.1.1 De�nição de Pronto

No processo uma tarefa é considerada pronta quando foi devidamente executada, in-serida no sistema de versionamento e testada por um integrante do time diferente do quea executou.

Aqui descreveremos as atividades do processo de desenvolvimento implementado. Parao entedimento completo destas atividades é necessário o entendimento da metodologiaSCRUM, suas práticas, seus papéis e respectivas responsabilidades. Todos os artefatosmencionados durante a descrição do processo fazem parte do SCRUM ou são descritos napróxima seção.

O nosso processo é constituido das atividades apresentadas na �gura:

I.1.2 Elaborar Documento de Visão

Responsável: ScrumMaster

Participantes: Gerente de Projeto, Cliente, Comercial

Artefatos de entrada: Possivelmente editais e contratos

Artefatos de saída: Documento de Visão

Objetivo: Levantar o escopo da release, de�nindo os requisitos

Ferramentas: OpenO�ce.org Word Processor

53

Figura I.1: Visão geral do processo da e-Sec

Templates Utilizados: template-doc-visão.odt

Critérios de Instanciação para projetos: Todos os Projetos

Indicadores:

Pontos de Veri�cação de QA:

Descrição: Ao �nal dessa atividade o ScrumMaster tem que ter conhecimento sobre oescopo, prazo e requisitos do sistema. Dependendo do projeto nesta fase podem ser feitasreuniões com o cliente, ou lidos editais de contratação disponibilizados.

Sub-Atividades:

I.1.3 Realizar planejamento macro do Projeto

Responsável: ScrumMaster

54

Participantes: Gerente de Projeto

Artefatos de entrada: Documento de Visão, Casos de Uso

Artefatos de saída: Plano inicial do Projeto, Backlog do Produto

Objetivo: De�nir um plano inicial do projeto

Ferramentas: OpenO�ce.org Word Processor

Templates Utilizados: template-plano-projeto.odt

Critérios de Instanciação para projetos: Todos os Projetos

Indicadores:

Pontos de Veri�cação de QA:

Descrição:

Sub-Atividades:

• Possivelmente o ScrumMaster atribui a alguém a tarefa de elaboração dos casosde uso do sistema e do diagrama de cobertura. Caso contrário esta atividade éexecutada por ele mesmo.

• São levantadas possíveis necessidades do ambiente de trabalho, de dados e de re-cursos humanos não antes previstas. O ScrumMaster planeja como resolver essasnecessidades, resolvendo ele mesmo ou delegando a outro membro do time.

• O ScrumMaster cria um plano de desenvolvimento inicial com esforço e prazo, ob-servando as datas de entregues especi�cadas em edital ou contrato, ou estabelecidasjuntamente com o Gerente de Projeto negociando com este o Time alocado paraeste projeto.

• O ScrumMaster faz um levantamento dos principais riscos do projeto. Para ajudarnessa parte é utilizada a Lista de Riscos Comuns I.2.6, com problemas levantadosem projetos anteriores. Para cada risco é levantado seu impacto e probabilidade deocorrência.

• Uma vez levantados os riscos são de�nidas atitudes para minimizá-los. As atitudesconsistem em ações que ajudem a diminuir a probabilidade de ocorrência do riscolevantado ou minimizar os possíveis danos causados.

• A viabilidade do projeto é analisada, se necessário ajustes são realizados.

• Construção do backlog inicial do sistema na ferramenta de contendo todos os casosde uso a serem desenvolvidos bem como atividades relacionadas a treinamento,con�guração de ambiente e outras necessidades impactantes.

É realizado o planejamento macro do projeto. Ao �nal desta etapa o ScrumMasterdeve ter segurança que o projeto pode ser executado com sucesso e que ele tem os recursosnecessários.

55

I.1.4 Elaboração de Casos de Uso

Responsável: Analista

Participantes: ScrumMaster

Artefatos de entrada: Documento de Visão, contrato ou edital

Artefatos de saída: Diagrama de casos de uso, diagrama de realização de caso de uso

Objetivo: Especi�car melhor do sistema

Ferramentas: Enterprise Architect

Templates Utilizados:

Critérios de Instanciação para projetos: Todos os Projetos

Indicadores:

Pontos de Veri�cação de QA:

Descrição:São elaborados casos de uso que cubram todos os requisitos contidos no documento

de visão.

Sub-Atividades:

• Elaborar casos de uso

• Elaborar diagrama de casos de uso

• Elaborar diagrama de cobertura

I.1.5 Reunião de Abertura

Responsável: ScrumMaster

Participantes: Time, [Gerente de projetos]

Artefatos de entrada: Documento de Visão, Backlog do Produto, Diagrama de Casosde Uso, Diagrama de Realização de Casos de Uso, Plano do Projeto

Artefatos de saída: de�nição da arquitetura e ambiente de desenvolvimento (em ata)

Objetivo: Situar o time no projeto e de�nir con�guração do ambiente de desenvolvimento

Ferramentas: Ferramenta de Gerencia SCRUM I.4.1, Processador de Texto

Templates Utilizados:

Critérios de Instanciação para projetos: Todos os Projetos

Indicadores:

56

Pontos de Veri�cação de QA:

Descrição: Nesta etapa o time deve entender o sistema de forma geral, seus objetivose os usuários envolvidos. É discutida a arquitetura do sistema, ferramentas utilizadase necessidade de estudo e treinamento. O ScrumMaster revisa com o time o plano doprojeto.

Sub-Atividades:

I.1.6 Reunião de Estimativa

Responsável: ScrumMaster

Participantes: Time

Artefatos de entrada: Backlog sem estimativas

Artefatos de saída: Backlog com estimativas de complexidade

Objetivo: Estimar a complexidade de cada item do Backlog do Produto

Sub-Atividades:

Ferramentas: Ferramenta de gerência SCRUM I.4.1

Templates Utilizados:

Critérios de Instanciação para projetos: Todos os Projetos

Indicadores:

Pontos de Veri�cação de QA:

Decription: É feito o levantamento de estimativas de complexidade dos itens do back-log. Sendo assim, para cada item do backlog é estimada sua complexidade, em pontos decomplexidade, de acordo com a seção I.3.

Sub-Atividades:

I.1.7 Montagem de Ambiente

Responsável: ScrumMaster

Participantes: Time

Artefatos de entrada: Backlog do Projeto

Artefatos de saída: Con�gurações do ambiente

Objetivo: Con�gurar ambiente para desenvolvimento do projeto

Ferramentas: Ferramenta de Gerencia SCRUM I.4.1

57

Templates Utilizados:

Critérios de Instanciação para projetos: Todos os Projetos

Indicadores:

Pontos de Veri�cação de QA:

Descrição:São realizadas as con�gurações necessárias no ambiente, conforme levantado no plano

do projeto. As tarefas a serem realizadas constam do Backlog do Produto em sua primeiraSprint.

Sub-Atividades:

I.1.8 Planejamento da Release

Responsável: ScrumMaster

Participantes: Gerente de Projeto

Artefatos de entrada: Backlog do Produto, Plano do Projeto

Artefatos de saída: Backlog do Produto com itens priorizados para a release atual.(Backlog da Release)

Objetivo: Levantar o escopo da release, de�nindo o backlog.

Ferramentas: Ferramenta de gerenciamento SCRUM I.4.1

Templates Utilizados:

Critérios de Instanciação para projetos: Projetos que precisem ser divididos em maisde uma release.

Indicadores:

Pontos de Veri�cação de QA:

Sub-Atividades:

• ScrumMaster revisa o plano do projeto com o estado atual do Backlog e as estima-tivas mais recentes do time.

• Após isso é estimada a capacidade produtiva da equipe em pontos de complexidadepor Sprint utilizando as planilhas de execução (seção I.4.1) de projetos anteriores quetenham características semelhantes ao atual e/ou experiência de desenvolvimento dotime. Esse cálculo é explicado em .

• O Gerente de Projeto prioriza os ítens do Backlog.

• Gerente e Projeto e ScrumMaster negociam uma seleção do backlog e um prazo.

58

• Dividindo o total de pontos por complexidade do backlog pela capacidade da equipetemos a estimativa do número de Sprints necessárias para a conclusão da release.Com isso podemos estimar o tempo total que levará a conclusão da release.

• É feito um levantamento dos principais riscos do projeto. A equipe discute quaispontos do plano tem maior possibilidade de não sair de acordo com o esperado.Para ajudar nessa parte é utilizada a Lista de Riscos Comuns I.2.6, com problemaslevantados em projetos anteriores. Para cada risco levantado é discutido seu impactoe probabilidade de ocorrência.

• Uma vez levantados os riscos são de�nidas atitudes para minimizá-los. As atitudesconsistem em ações que ajudem a diminuir a probabilidade de ocorrência do riscolevantado ou minimizar os possíveis danos causados.

• É revisada a estimativa do número de Sprints necessárias para concluir a versão.

• A viabilidade do projeto é analisada, se necessário ajustes são realizados e um novaseleção do Backlog e prazo são negociados com o Gerente de Projeto

I.1.9 Reunião de Planejamento da Sprint

Responsável: ScrumMaster

Participantes: Time, [Gerente de Projeto]

Artefatos de entrada: Backlog do produto

Artefatos de saída: Backlog do produto modi�cado e Sprint Backlog

Objetivo: De�nir o que será desenvolvido durante a Sprint e um plano de desenvolvi-mento

Ferramentas: Ferramenta de gerenciamento SCRUM I.4.1

Templates Utilizados:

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

Nessa atividade a presença do Gerente de Projeto é recomendável se possível. Naausência do Gerente de Projeto o ScrumMaster executará esse papel.

Esta reunião está dividida em duas partes:

Primeira Parte

O Gerente de Projeto negocia com o time o que será desenvolvido durante o período daSprint. Isso inclui os erros e requisições de mudanças detectados e registrados em iteraçõesanteriores. Cabe ao Gerente de Projeto priorizar os itens do Backlog e o time selecionarquanto do Backlog ele irá se comprometer para essa Sprint. Os itens prioritários aceitospela equipe são inseridos no Backlog da Sprint.

59

Sub-Atividades:

• Priorizar os itens do backlog

• Selecionar itens do backlog

• De�nir a meta da Sprint

Segunda Parte

O time analisa o Backlog da Sprint identi�cando tarefas menores. Cada item doBacklog é dividido em tarefas detalhadas de forma mais técnica: criar tela de login, criartabelas do banco de dados X ou Y, etc.

Perceba que nesse ponto a atenção dispendida para o planejamento da Sprint, e onível de detalhamento do seu Backlog, é maior que o usualmente utilizada no SCRUM.Tradicionamente no SCRUM a equipe de�ne a maior parte do re�namento ténico dositens do backlog durante a Sprint. Percebemos que a reunião em questão é uma ótimaoportunidade para sanar o maior número de dúvidas possíveis, mesmo que ela dure odobro do usual no SCRUM (3 a 4 horas). O tamanho reduzido de Sprint implementado(1 ou 2 semanas dependendo do projeto) torna o Backlog da Sprint pequeno, fazendo comque esse re�namento não seja dispendioso.

Dessa forma, o time estima o esforço, em horas de trabalho (maiores detalhes emI.3.3), necessário para executar cada tarefa e atribui a um membro. O esforço estimadoserá usado para traçar o grá�co Burningdown durante a execução da Sprint. Esse assuntoserá detalhado na seção destinada às estimativas I.3.

Se a equipe identi�car que o trabalho para este incremento excede sua capacidade elepode negociar com o Gerente de Projeto mudanças no Backlog da Sprint.

Sub-Atividades:

• Detalhar itens em tarefas

• Estimar tarefas em horas

• Atribuição de tarefas

I.1.10 Execução da Sprint

Responsável: Time

Participantes: ScrumMaster

Artefatos de entrada: Backlog da Sprint

Artefatos de saída: Incremento de Software (ou outros artefatos entregáveis)

Objetivo: Executar o plano de desenvolvimento

Ferramentas: Ferramenta de gerenciamento SCRUM I.4.1

Templates Utilizados:

60

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

Durante a Sprint o time trabalha para executar o que está de�nido no Backlog doproduto. Ao decorrer da Sprint tarefas necessárias que não foram antes previstas podemser reconhecidas.

Sub-Atividades:

• Escolher tarefa e marcar como em realização

• Realizar tarefa

• Reatribuir a tarefa como teste

• Testar e fechar tarefa

Acompanhamento Diário

O acompanhamento diário é uma inspeção do progresso na direção da Meta da Sprint.Não realizamos uma reunião formal mas o time e o ScrumMaster devem se comunicar di-ariamente. É responsabilidade do ScrumMaster fazer as seguintes perguntas aos membrosda Equipe:

• O que foi feito ontem?

• O que será feito hoje?

• Existe algum impedimento?

Para o bom andamento da Sprint o ScrumMaster:

• Garante a remoção de todos os impedimentos surgidos, resolvendo ou delegandosuas resoluções com a criação de tarefas com prioridade máxima.

• Acompanha o estado das tarefas e do grá�co Burndown da Sprint, tomando asmedidas necessárias para o sucesso da Sprint.

Realização de Tarefas

A rotina diária de implementação segue as seguintes orientações:

• O time executa as tarefas para as quais se comprometeu

• Finalização de uma tarefa (parte do acompanhamento diário):

� Commit do código com o texto: Tarefa <no> - <sumario da tarefa executada>

� Reatribuir tarefa para o desenvolvedor responsável pelo teste, modi�cando otempo total da tarefa, o tempo restante (necessário para o teste) e adicionandoum comentário de conclusão

61

Teste

A tarefa deve ser veri�cada quanto aos seguintes aspectos:

• Funcionalidade;

• Padrões visuais na interface grá�ca;

• Revisão do código;

• Veri�cação se existem atualizações do documento de implantação.

Caso seja encontrado algum erro:

• Resolvê-lo caso seja um problema de resolução imediata, que não envolva entendi-mento profundo da tarefa em questão;

• Fazer comentário das alterações (se for o caso);

• Caso exista erro mas a correção não seja imediata, reatribuir a tarefa para desen-volvedor com devidos comentários;

• Se não houver erros o testador faz um comentário simples e marca a tarefa comopronta.

I.1.11 Reunião de Revisão da Sprint

Responsável: ScrumMaster

Participantes: Time (se possível também o Product Owner)

Artefatos de Entrada: Backlog da Sprint, Backlog da Release

Artefatos de Saída: Backlog da Release

Objetivo: Veri�car o que foi executado durante a Sprint e selecionar o que será entregueao Product Owner

Ferramentas: Ferramenta de gerenciamento SCRUM I.4.1

Templates Utilizados:

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

A equipe veri�ca o que foi planejado e cumprido durante a Sprint. Cada tarefa é veri�-cada se foi cumprida e testada, a equipe conversa sobre ela e possivelmente veri�ca seufuncionamento na hora. Em seguida, avalia-se a viabilidade da realização de uma entregacom o que tem pronto. A preparação da versão a ser entregue é realizada na atividade dePublicação.

62

Sub-Atividades:

• Veri�cação se cada tarefa está pronta

• Veri�ca-se a possiblidade de entrega

• É de�nido o que será entregue

I.1.12 Reunião de Retrospectiva da Sprint

Responsável: ScrumMaster

Participantes: Time

Artefatos de Entrada: Backlog da Sprint, Burndown da Sprint, Backlog do Produto,Burndown do Produto e plano de desenvolvimento da release.

Artefatos de Saída: Planilha de Execução, Lista de Riscos Comuns, Ata de Reuniãode Retrospectiva da Sprint

Objetivo: Avaliar o andamento da release e reavaliar o processo de desenvolvimento

Ferramentas:

Templates Utilizados:

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

Essa atividade é o coração da adaptatividade do processo. A equipe deve identi�car oque correu bem, o que correu mal e o que poderia ser melhor. São levantados os pontos deatenção encontrados, estes podem ser incluídos na Lista de Riscos Comuns. As medidasde melhoria factíveis que deverão ser implementadas na próxima Sprint são discutidas.

A partir da experiência e das estimativas de capacidade de trabalho do time levantadosnessa Sprint o cronograma da release e o plano de desenvolvimento podem ser adaptados,se necessário.

A reunião segue o seguinte roteiro:

• Avaliar o que foi bem e o que deu errado durante a Sprint;

• Alimentar a lista de pontos de atenção a partir do item anterior;

• Levantar o número de pontos de complexidade cumpridos;

• Levantar o número de horas trabalhadas;

• Revisar a estimativa de capacidade da equipe:

� Foi muito trabalho? Onde se estimou pra baixo?

� Foi pouco trabalho? Onde se estimou pra cima?

63

� Registrar como ponto de atenção.

• Atualizar a planilha de execução da release.

• Revisar a Capacidade do Time e o cronograma da release.

I.1.13 Validação da Release

Responsável: Gerente de Projeto

Participantes: ScrumMaster

Artefatos de entrada:

Artefatos de saída:

Objetivo: Validar a Release

Ferramentas:

Templates Utilizados:

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

I.1.14 Empacotar e Implantar

Responsável: Gerente de Projeto

Participantes: ScrumMaster

Artefatos de entrada:

Artefatos de saída:

Objetivo: Validar a Release

Sub-Atividades:

Ferramentas:

Templates Utilizados:

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

64

I.1.15 Obter Homologação

Responsável: Gerente de Projeto

Participantes:

Artefatos de entrada:

Artefatos de saída:

Objetivo:

Ferramentas:

Templates Utilizados:

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

I.1.16 Fornecer Treinamento

Responsável: Time

Participantes: ScrumMaster e Gerente de Projetos

Artefatos de entrada:

Artefatos de saída:

Objetivo:

Ferramentas:

Templates Utilizados:

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

I.1.17 Encerrar Projeto

Responsável: Gerente de Projetos

Participantes: Time

Artefatos de entrada:

Artefatos de saída:

65

Objetivo:

Sub-Atividades:

Ferramentas:

Templates Utilizados:

Critérios de Instanciação para projetos:

Indicadores:

Pontos de Veri�cação de QA:

As estimativas são revistas e é alimentada uma base com dados históricos.

Avaliação

Responsável: Gerente de Projeto

Participantes: Membro responsável pela publicação da versão em avaliação

Artefatos de Entrada: Versão de avaliação

Artefatos de Saída: Registros de requisições de mudanças e correções de erro

Objetivo: Disponibilisar a versão para ser executada por usuários em teste ou produção

É gerado um Change Log das funcionalidades adicionais e problemas corrigidos. Osartefatos necessários para a realização da entrega são disponibilizados. O Gerente deProjeto �ca responsável pela avaliação da versão disponibilizada e registrar os erros e asrequisições de mudança na ferramenta destinada a esse �m I.4.3.

I.2 Artefatos Complementares

Esta seção contém a descrição dos artefatos adicionais (não encontrados no SCRUM)utilizados pelo processo aqui descrito.

I.2.1 Ata de Reunião

As reuniões descritas no processo possuem como artefato de saída sua respectivas atas.As atas de reunião não possuem formato �xo em nosso processo. Devem possuir os

pontos chaves de cada reunião como de�nido no processo.

66

I.2.2 Documento de Visão

O Documento de Visão faz parte da fase inicial do processo RUP. Fornece uma basede alto nível - algumas vezes contratual - para os requisitos técnicos mais detalhados.Também pode conter uma especi�cação de requisitos formal. O documento de Visãocaptura restrições de design e requisitos de nível muito elevado para que o leitor possacompreender o sistema a ser desenvolvido. Ele fornece informações para o processo deaprovação do projeto e, portanto, está intrinsecamente relacionado ao Caso de Negócio.Ele comunica os principais questionamentos relacionados ao projeto e funciona como umregulador com base no qual todas as decisões futuras deverão ser validadas (2).

A importâcia desse artefato em nosso processo deve-se pela sintetização do escopodo projeto dentro de um único documento. Tornar necessária a sua contrução garanteque pelo menos um membro da equipe pense e elabore premeditadamente um rascunhodos requisitos, dos atores e das reponsabilidades destes dentro do sistema. Deixando oentendimento do sistema catalogado e estruturado para os demais membros da equipe,e também facilita o levantamento de requisitos e casos de uso que, juntamente com oDocumento de Visão, fazem parte da Análise Inicial.

I.2.3 Diagrama de Casos de Uso

Os diagramas com atores, casos de uso e relacionamentos entre eles são denominadosdiagramas de casos de uso e ilustram os relacionamentos no modelo de casos de uso (2).

I.2.4 Diagrama de Realização de Casos de Uso

Este diagrama permite a restreabilidade dos requisitos levantados e dos respectivoscasos de uso que os implementam. Essa conexão é reprensentada no diagrama por umaseta ligando o requisito e o caso de uso (16).

I.2.5 Planilha de Execução

A planilha onde são registrados todos os dados de históricos de esforço (em horas tra-balhadas) e pontos de complexidade de cada Sprint executada em um projeto é chamadade Planilha de Execução.

Surgiu da necessidade de armazenamento do histórico das estimativas de complexidadee do esforço realmente necessário em cada Sprint. Esses dados são essencias para o cálculoda capacidade do time em pontos de complexidade por Sprint, explicado em I.3.5.

I.2.6 Lista de Riscos Comuns

Constitui num catálogo de riscos comuns identi�cados no desenrolar dos projetos re-alizados. Essa lista contém a descrição de cada risco e as tags associadas a esse risco,facilitando a posterior consulta.

A identi�cação de riscos relacionados a um projeto tende a ser complexo pelos inúmerosfatores relacionados. Uma lista de riscos já identi�cados e catalogados por tags facilitaessa tarefa.

67

I.3 Método de Estimativa

Estimar e planejar são críticos para o sucesso de qualquer projeto de desenvolvimentode software. Planos guiam nossas decisões de investimento. Baseado em estimativasde�nimos o preço e viabilidade de um projeto. Planos nos ajuda a saber se um projeto estános trilhos para entregar as funcionalidades requeridas no prazo especi�cado. Conseguirestimar adequadamente o custo de um projeto e manter o prazo são fundamentais para osuceesso de um projeto.

O método de estimativa implementado tem como base a técnica de Story Points ap-resentada na seção 2.10. Utilizamos o nome Pontos de Complexidade ao invés de StoryPoints por conveniência. Pontos de Complexidade facilita a absorção pela equipe dedesenvolvimento do conceito inerente, sem a necessidade de maiores explicações.

Adicionalmente a técnica de Story Points (Pontos de Complexidade em nosso contexto)introduzida nas estimativas do Backlog do Produto, utilizamos uma segunda etapa deestimativas durante o planejamento da Sprint I.1.9. Como explicado, os itens do Backlogescolhidos para Sprint são detalhados em tarefas menores, onde aplica-se a estimativa deesforço em horas de trabalho. Essas estimativas e a medição do esforço realizado fornecemuma ferramenta poderosa para a melhoria das estimativas futuras e permitem uma maiorprecisão no planejamento, do que a utilização de Story Points individualmente.

I.3.1 Esforço e Complexidade

Tanto a ténica de estimativa de Opinião de Especialista quanto a Analogia 2.10.3 têmuma maior efetividade utilizando uma base de dados de estimativas e medições anteriores.Para esse intuito utilizamos dois conceitos para retratar o estimado e o medido.

Complexidade aqui é tratada como a estimativa, o trabalho juntamente com sua im-previsibilidade e risco inerentes. Esta é estimada utilizando a ténica de Story Points.Batizado de Pontos de Complexidade como já mencionado.

No contexto do processo em questão, esforço é traduzido em horas de trabalho. Essaé a forma mais direta de medição do esforço no desenvolvimento de software.

I.3.2 Estimativa de Complexidade

A estimativa de complexidade tem como base a técnica de Story Points apresentadana seção 2.10. De�nimos o valor de um item de Backlog típico, bem entendendido portodos os membros do Time, como referência inicial. A escolha deste item é arbitrária,normalmente um de tamanho médio, atribuindo um valor em algum lugar no meio daescala. O importante é que os itens do Backlog tenham suas complexidades mensuradasrelativamente, ou seja, um item do Backlog de complexidade 40 tem o dobro do esforçoestimado item de complexidade 20.

Utilizamos uma escala de Pontos de Complexidade baseada na sequência de Fibonaccicom os valores: 1,2,3,5,8,13,20,40,100. Foi escolhida por ser não-linear, traduzindo aincerteza e os riscos existentes nas estimativas de itens maiores; e por ter uma gama devalores médios maior que o usual 1, facilitando a escolha do item inicial.

1Escalas usuais apresentadas na seção 2.10.2.

68

As técnicas de Opinião de Especialistas e Analogia 2.10.3 são utilizadas largamente.É importante que o ScrumMaster tenha um ótimo conhecimento da arquitetura usada noprojeto. Assim ele haje como um especialista durante as estimativas.

Na técnica de analogia compara-se cada novo item com uma variedade de outros quejá estiveram valores estimados. Isso é conhecido como triangulação. Para decidir se umitem deve ser estimado em cinco Pontos de Complexidade, veja se este parece um poucomaior do que um item que você estimou em três e um pouco menor do que um outroestimado em oito.

I.3.3 Estimativa de Esforço

Durante o desenvolvimento do processo, percebemos que o acompanhamento de umaSprint pequena, utilizando os pontos de complexidade para montar o Burndown não erae�ciente. Normalmente o fechamento de um item do Backlog (um caso de uso, por exem-plo) demora de 2 a 3 dias para ser �nalizado. Com isso o Burndown não é frequentementeatualizado, diminuindo a e�cácia de seu acompanhamento.

Com a introdução da subdivisão e detalhamento dos itens do Backlog da Sprint emtarefas de carater técnico, como visto em I.1.9, a possibilidade de estimativa de esforçoem horas tornou-se palpável já que as tarefas são pequenas (levam em média de 2 a 12horas) e, em sua grande maioria, velhas conhecidas da equipe de desenvolvimento (criarum formulário, implementar envio de email, etc).

A partir dessas questões, decidimos utilizar estimativas de esfoço em horas de trabalhodurante as Sprints. Possibilitando a atualização diária do Burndown: se uma tarefa nãoé concluída ao �m do dia, o valor do esforço restante para a conclusão desta é atualizado.Isso é feito estimando o restante do trabalho a ser feito.

O sucesso da estimativa de esforço depende da divisão das tarefas de forma que elas seassemelhem a outras de conhecimento da equipe e que seu tamanho permita o julgamentoem horas de trabalho. A importância desses valores no processo está na comparaçãoentre o estimado e o real, registrado durante a execução das tarefas (explicado na próx-ima subseção). O resultado disso será um bom conjunto de métricas para estimativasposteriores.

I.3.4 Medição de Esforço

A medição do esforço realizado é feito alterando diáriamente o valor do atributo esforçode cada tarefa sendo executada dentro da Sprint. Os membro do time devem efetuar essaatualização ao �nalizar uma tarefa ou ao �nal do espediente, caso esteja faltando algopara �nalizá-la. É responsabilidade do ScrumMaster acompanhar essa atualização diária,garantindo o funcionamento da medição.

É medido o número de horas que o desenvolvedor trabalhou com a tarefa alocadae não horas ideiais (horas trabalhadas sem o cafezinho, leitura de email, navegação naweb). Isso facilita a medição e não a torna uma tarefa odiável. Algumas empresasutilizam sistemas de medição de produtividade que chegam a obrigar o desenvolvedor aregistrar suas paradas de 5 minutos para conversar ou responder emails pessoais. Poucosdesenviolvedores têm tanta disciplina, o que torna esse tipo de medição de horas ideiasum tanto quanto impraticável.

69

Ao �nal de cada Sprint o montante do esforço realizado é registrado na Planilha deExecução. Esses dados são essencias para o cálculo da capacidade do time.

I.3.5 Capacidade do Time

A divisão entre o montante em Pontos de Complexidade realizado em uma Sprint eo esforço medido, permitem a introdução da relação Pontos de Complexidade por Hora,utilizada para calcular a capacidade do time. A Capacidade do Time é obtida multipli-cando Pontos de Complexidade por Hora pelo número de horas totais que a equipe temdisponibilizada para um Sprint.

Considere o seguinte o exemplo: Deseja-se calcular a capacidade de um time quedispõe de 120 horas para a realização de uma Sprint. Na anterior foram concluídos 45Pontos de Complexidade e durante sua realização foi contabilizado um esforço de 90 horasde trabalho. O que nos dá 45 / 90 = 1/2 Pontos de Complexidade por Hora. Logo, aCapacidade do Time é de 1/2 * 120 = 60 Pontos de Complexidade.

O cálculo de capacidade também pode ser efetuado da mesma forma sobre as estatís-tica de uma Release inteira. É importante observar que a Capacidade do Time não éum valor absoluto. Como explanado em Estimativa de Complexidade I.3.2 , Pontos deComplexidade é uma grandeza de caráter relativo, e é estimada em diferentes tipos deprojeto utilizando como base inicial diferentes referenciais.

Para a determinação da Capacidade do Time inicial em uma Release é necessáriocalculá-lo com base em projetos extremamente parecidos. Existe também a possibili-dade de estimar essa capacidade aplicando algum fator de correção na relação Pontos deComplexidade por Hora.

Exemplo: uma nova Release necessitará da utilização de uma tecnologia X aindanão experimentada dentro da empresa, mas essa Release assemelha-se com uma anterior,exceto pela tecnologia X. A Release anterior resultou em uma relação de 0.8 Pontos deComplexidade por Hora. Pela adição de X na nova Release a considera-se 50

I.3.6 Interação com o Product Owner

O SCRUM exige uma presença ativa do Product Owner o que realmente é bené�copara o processo. No entando nos projetos da e-Sec nem sempre o cliente disponibiliza umapessoa para se dedicar tanto ao acompanhamento do projeto. Desta forma foi necessárioadaptarmos o nosso processo a essa realidade.

Na auxência do Product Owner nas cerimônias o ScrumMaster executa seu papel,entrando em contato com este por meio de telefone, e-mail ou pela ferramenta utilizadapara este �m, descrita a seguirI.4.3.

I.4 Ferramentas

Essa seção detalha as principais ferramentas utilizadas para a aplicação do processodescrito.

70

I.4.1 Gerência SCRUM

Antes implantação do processo, buscamos diversas alternativas de ferramentas degerência do Scrum. Preferimos evitar o famoso quadro de Post-its pois, apesar de práticoe didático, é um tanto quanto primitivo.

A ferramenta escolhida, o Agilo (7), supri todas as necessidades básicas para a im-plantação do Scrum. É uma ferramenta open source (a versão de entrada) e de interfaceweb baseada na ferramenta Trac (6), explanada em I.4.3.

Fornece as seguintes funcionalidades direcionadas ao Scrum:

• Gerência do Backlog do Produto e das Sprints, além de permitir a criação de outrosBacklogs;

• Permite a divisão dos itens do backlog em tarefas, mantendo o rastreamento entreitem do Backlog e tarefas relacionadas;

• Gerência de Time e de sua capacidade de trabalho em horas;

• Grá�co Burndown da Sprint com curva de capacidade do time, curva ideal, curvaatual e curva de tendência. Atualizado conforme os valores de tempo restante paraconclusão de uma tarefa é modi�cado;

É uma ferramenta excelente para a aplicação do Scrum, mas deixa a desejar em algunsaspectos relacionados à armazenamento e apresentação de dados históricos. Por isso osdados históricos e as métricas dos projetos são armazenados na Planilha de Execução,explicada anteriormente .

I.4.2 Modelagem UML

Alguns artefatos do processo são compostos por diagramas UML. É o caso do Dia-grama de Casos de Uso e do Diagrama de Realização de Casos de Us o. A ferramentautilizada para esta função é o Enterprise Architect (9). É uma ferramenta CASE com-ercial. Existem diversas alternativas Open Source para este programa mas decidimosutilizá-la pois a e-Sec já possuía uma licença desta, além de ser de alta qualidade.

I.4.3 Comunicação com o Product Owner

A participação do Product Owner durante o desenrolar do projeto é essencial para oseu sucesso. É importante que ele forneça o feedback das suas impressões do sistema, doserros encontrados e de sujestões de melhoria e evolução. Para esse intuito utilizamos oTrac (6).

O Trac é uma ferramenta open source e de interface web para controle de mudançasem projetos de desenvolvimento de software. O objetivo do é ajudar a rastrear essasmudanças, entender o porque de cada uma e qual o seu impacto no projeto como um todo.Ele fornece uma maneira bidirecional de comunicação e de registro e acompanhamento doprojeto, facilitando o entendimento mútuo entre as partes.

A ferramenta permite o registro, rastreamento e controle:

• de erros encontrados pelo Product Owner;

71

• de melhorias e alterações dos requisitos propostas pelo Product Owner;

• de dúvidas da equipe de desenvolvimento;

Além disso, o Trac possui uma ferramenta de base de conhecimento integrada quefunciona.

I.4.4 Base de Conhecimento

A implantação de um processo de desenvolvimento e�ciente depende de uma série deatividades diárias, habilidades e termos técnicos que devem ser entendidos por todos osparticipantes, incluindo o Product Owner e outros envolvidos por parte do cliente. Parafacilitar a manutenção dessa base de conhecimento , utilizamos ferramentas ao estilo Web

Wiki.UmaWeb Wiki permite que os documentos sejam editados colectivamente com uma

linguagem de marcação muito simples e e�caz, através da utilização de um navegadorweb.

O Trac possui uma ferramenta de base de conhecimento integrada. É utilizada paracompartilhar uma base de conhecimento entre o Product Owner e a equipe.

Para conhecimentos técnicos gerais e independentes de projetos (tutorias de progra-mação, informações sobre atividades do processo, etc) utilizamos uma famosa ferramentaWeb Wiki : a MediaWiki (8).

I.4.5 Controle de Versão

Os artefatos gerados no decorrer do projeto, que não possuem uma ferramenta es-pecí�ca de gerenciamento, devem ser incluídos na base de versionamento especí�ca paracada projeto. Estes artefatos são código fonte, documentação, diagramas UML, scriptsde banco de dados, etc.

A ferramenta utilizada para o controle de versão dos arquivos gerados durante o de-senrolar de um projeto é o Subversion (5). Atualmente, é a ferramenta mais utilizada nomercado e fornece uma ótima documentação.

I.4.6 Ambiente Integrado de Desenvolvimento

A ferramenta de suporte ao desenvolvimento utilizada é o Eclipse IDE (? ). Alémde facilitar a atividade de codi�cação - como funcionalidade de auto-complete, busca dereferências à métodos, classes e variáveis - a plataforma fornece uma série de plugins

que permitem a integração da IDE com o controle de versão e a ferramenta de gerênciaSCRUM. Isso possibilita a atualização e submissão de versões, e a visalização das tarefasalocadas ao desenvolvedor diretamente pela interface da IDE.

72

Anexo II

Validação do Processo

Vamos nesse capítulo analisar cada ítem dos dois processos exigidos no MPS.BR nívelG e como o processo da implantado os atente.

II.1 Gerência de Projetos � GPR

GPR 1. O escopo do trabalho para o projeto é de�nido.

De�nimos o escopo do projeto na Análise Inicial nos artefatos gerados, como oDocumento de Visão. Ao longo do projeto esse escopo é mantido no Backlog doproduto.

GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionadosutilizando métodos apropriados.

As tarefas são estimadas na Reunião de Planejamento da Release e nas Reuniõesde Planejamento das Sprints. O dimensionamento é progressivamente detalhado amedida que o projeto evolui. Para estimar é utilizado o método descrito na seçãoEstimativa I.3.

GPR 3. O modelo e as fases do ciclo de vida do projeto são de�nidos.

Sim, o modelo e as fases do ciclo de vida do projeto são bem de�nidos, conformevisto na descrição de todo o processo I.1.

GPR 4. O esforço e o custo para a execução das tarefas e dos produtos detrabalho são estimados com base em dados históricos ou referências téc-nicas.

No modelo de medição utilizamos dados históricos I.3 providos por outros projetoscom características similares. Além disso, os projetos anteriores permanecem nabase da empresa para consulta, permitindo utilizá-los em estimativas futuras. Oconhecimento dos custos de execução das tarefas e a medição do trabalho cumpremesse item.

GPR 5. O orçamento e o cronograma do projeto, incluindo a de�nição demarcos e pontos de controle, são estabelecidos e mantidos.

73

Na Reunião de Planejamento da Release ?? é levantado um cronograma na formade estimativa do número de Sprints e data de entrega da Release. O �nal de cadaSprint é um ponto de controle. ??

GPR 6. Os riscos do projeto são identi�cados e o seu impacto, probabilidadede ocorrência e prioridade de tratamento são determinados e documen-tados.

Os riscos do projeto são levantados na Reunião de Planejamento da Release e acom-panhados a cada Reunião de Planejamento da Sprint e são documentados em Ata.Ações para diminuir probabilidade e/ou impacto dos riscos são inseridos no Backlogdo Produto.

GPR 7. Os recursos humanos para o projeto são planejados considerando oper�l e o conhecimento necessários para executá-lo.

De acordo com o escopo do projeto e as tecnologias envolvidas, a equipe é escolhida.Caso seja necessário algum recurso humano adicional, é levantado na Reunião dePlanejamento da Release. Ou seja, existe sim este planejamento.

GPR 8. Os recursos e o ambiente de trabalho necessários para executar oprojeto são planejados.

Os recursos que normalmente são utilizados pela equipe estão documentados nabase de conhecimento. Na Reunião de Planejamento da Release são levantadosnovos recursos necessários ao projeto. Novas necessidades podem ser levantadas nasReuniões de Planejamento da Sprint ou no Acompanhamento Diário onde é respon-sabilidade do ScrumMaster assegurar a disponibilidade dos recursos necessários.

GPR 9. Os dados relevantes do projeto são identi�cados e planejados quanto àforma de coleta, armazenamento e distribuição. Um mecanismo é estab-elecido para acessá-los, incluindo, se pertinente, questões de privacidadee segurança.

Assim como item anterior essas necessidades de dados são levantadas na Reunião dePlanejamento de Release, Reuniões de Planejamento da Sprint e AcompanhamentoDiário, como impedimentos.

GPR 10. Um plano geral para a execução do projeto é estabelecido com aintegração de planos especí�cos.

Um plano geral é de�nido na Reunião de Planejamento da Release, podendo seradaptado nas reuniões de Retrospectiva das Sprints.

GPR 11. A viabilidade de atingir as metas do projeto, considerando as re-strições e os recursos disponíveis, é avaliada. Se necessário, ajustes sãorealizados.

É feito análise de viabilidade na Reunião de Planejamento da Release.

GPR 12. O Plano do Projeto é revisado com todos os interessados e o com-promisso com ele é obtido.

74

O Plano do Projeto é realizado na Reunião de Planejamento da Release em que oProduct Owner representando o cliente e o ScrumMaster e Time se comprometemcom o projeto.

GPR 13. O projeto é gerenciado utilizando-se o Plano do Projeto e outrosplanos que afetam o projeto e os resultados são documentados.

O Plano do Projeto é acompanhado a cada Reunião de Retrospectiva da Sprint,revisando o Plano do Projeto e o grá�co Burndown. Além disso é feito o acom-panhamento diário da Sprint. Todas as reuniões são documentadas em Atas, comoresultado dos demais planejamentos que afetam o projeto.

GPR 14. O envolvimento das partes interessadas no projeto é gerenciado.

Desde o escopo inicial do projeto, na Análise Inicial, até o �nal do projeto todasas decisões que impactam no escopo, no prazo ou no custo são de conhecimento deambas as partes e são devidademente registradas por via documental, email ou viaferramenta de comunicação I.4.3.

GPR 15. Revisões são realizadas em marcos do projeto e conforme estabele-cido no planejamento.

Revisões são realizadas ao �nal de cada Sprint internamente na Reunião de Revisãoda Sprint e externamente, com o cliente, na fase de Avaliação I.1.17.

GPR 16. Registros de problemas identi�cados e o resultado da análise dequestões pertinentes, incluindo dependências críticas, são estabelecidose tratados com as partes interessadas.

Os problemas são levantados no acompanhamento diário como impedimentos. Oserros veri�cados junto ao cliente ou internamente são inseridos no Backlog paraposterior correção.

GPR 17. Ações para corrigir desvios em relação ao planejado e para prevenira repetição dos problemas identi�cados são estabelecidas, implementadase acompanhadas até a sua conclusão.

Isso é feito com o acompanhamento da tarefa de remoção do impedimento.

II.2 Gerência de Requisitos - GRE

GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornece-dores de requisitos, utilizando critérios objetivos.

Os requisitos são descritos no documento de visão que deve ser aprovado pelofornecedor de requisitos. As especi�cações seguintes e mudanças nos requisitos sãoregistradas na ferramenta adequadaI.4.3. O GRE 1 especi�ca que devem havercritérios objetivos para aceitar os requisitos. A avaliação de aceitar que requisitodeve ser desenvolvido é feita na reunião de planejamento da Sprint, onde o Time ne-gocia com o Product Owner que requisito será desenvolvido naquela Sprint. Comoo Product Owner é dono do Backlog ele pode inserir novos requisitos, mas o Time

75

só se compromete com ele na reunião após julgar sua viabilidade e estimar suacomplexidade. No entanto não há uma compilação de critérios.

GRE 2. O comprometimento da equipe técnica com os requisitos aprovados éobtido

O Time estima o Backlog da Release e junto com o ScrumMaster análisa a viabili-dade na Reunião de Planejamento da Release. Se o Time e o ScrumMaster avaliaremo projeto como viável estarão comprometidos com ele.

GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos detrabalho é estabelecida e mantida. No processo desenvolvido o conjunto inicialde requisitos é especi�cado e documentado no Documento de Visão, o Modelo deCobertura de Requisitos mantem a rastreabilidade bidirecional entre requisitos ecasos de uso. Os casos de uso são registrados em ferramenta apropriada. Cadatarefa levantada é registrada e é associada a um ou mais casos de uso que ajudam acumprir na mesma ferramenta que possui o registro dos casos de uso. Ao submeterqualquer alteração no repositório do projeto é inserido um comentário que indicaqual tarefa a alteração se refere. A ferramenta que gerencia caso de uso e tarefas écapaz de listar as alterações do repositório referentes a cada tarefa.

Através da ferramenta de gerência SCRUM é possível veri�car para cada alteraçãono repositório de código fonte a tarefa a qual ela se relaciona e o histórico de modi-�cações desta tarefa. A tarefa referencia o caso de uso e no Diagrama de Realizaçãode Casos de Uso mantido pode-se rastrear o requisito.

GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadasvisando identi�car e corrigir inconsistências em relação aos requisitos.

Toda tarefa é testada por uma pessoa diferente de quem a desenvolveu. Além dissoperiodicamente são criadas versões para que o Product Owner ateste sua qualidadena fase de Avaliação I.1.17.

GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

Os requisitos podem ser modi�cados pelo Product Owner. Mudanças nos requisitossão gerenciados com modi�cações ou inserções de novos casos de uso e atividadesno Backlog da Release. Se as modi�cações se referirem as Sprint corrente esta podeser cancelada. Novos ítens no Backlog são reestimados e priorizados na próximareunião de Planejamento da Sprint.

76

Referências

[1] Mike Cohn. Agile Estimating and Planning. Prentice-Hall, 2005. 25, 26

[2] Rational Software Corporation. Rational Uni�ed Process 2002.05.00. Rational Soft-ware Corporation, 2002. 67

[3] Manifesto for Agile Software Development. Kent beck et al, 2001. 3, 4

[4] Martin Fowler. The new methodology, 2005. 2, 7, 10

[5] http://subversion.apache.org/, jan 2011. 72

[6] http://trac.edgewall.org/, jan 2011. 71

[7] http://www.agile42.com/cms/pages/agilo, jan 2011. 71

[8] http://www.mediawiki.org/wiki/MediaWiki, jan 2011. 72

[9] http://www.sparxsystems.com.au/products/ea/8/index.html, jan 2011. 71

[10] Carleton A. Moore Joseph A. Dane Johnson, Philip M. and Robert S. Brewer. Em-prically guided software e�ort estimation. IEEE Software, 2000. 27

[11] Norman L. Kerth. Project Retrospectives: A Handbook for Team Reviews. DorsetHouse Publishing Company, 2001. 12

[12] Kane Mar and Ken Schwaber. Scrum with xp. Informit, 2002. 5

[13] Sheila Reinehr Mariano Montoni Ana Regina Rocha Kival Chaves Weber GuilhermeHorta Travassos Marcos Kalinowski, Gleison Santos. Mps.br: Promovendo a adoçãode boas práticas de engenharia de software pela indústria brasileira. 2010. 28, 29

[14] Steve McConnell. Rapid Development: Taming Wild Software Schedules. MicrosoftPress, 1 edition edition, july 1996. 8

[15] MCT. Pesquisa de qualidade no setor de software brasileiro 2009, jan 2011. 5, 35

[16] Dan Pilone. UML Pocket Reference. O'Reilly Media, 2003. 67

[17] Roger S. Pressman. Engenharia de Software. McGraw-Hill, 6a edition, 2006. 1, 30

[18] Jack W. Reeves. What is software design? C++ Journal, 1992. 8

77

[19] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press, 1 edition,2004. 13, 14, 16, 40, 48

[20] Ken Schwaber and Je� Sutherland. Scrum guide. Scrum.org, 2009. 13, 14, 16, 17,40, 48

[21] SOFTEX. MPS.BR: Guia Geral. SOFTEX, maio 2009. 28, 29, 30, 33

[22] Ian Summerville. Engenharia de Software. Addison-Wesley, 8a edition, 2007. 1, 4,33

78