1.

Proposta fundamentada para um futuro desenvolvimento de software,

obedecendo a metodologia SCRUM

Este trabalho refere-se a proposta de transição de processos de desenvolvimento de software

baseados em modelos Tradicionais, para processos baseados em modelos Agile, tendo como
objeto a aplicação do modelo Scrum ao processo de desenvolvimento de software na CGD.

1.1. Estádios do processo de desenvolvimento

Segundo Koscianski (2006), o ciclo de vida de SCRUM é dividido em 3 fases: Pré-Game

Phase; Game Phase; Pós-Game phase.

Associando o ciclo do modelo de desenvolvimento de software da CGD atual ao ciclo da

metodologia SCRUM, as fases do novo processo de desenvolvimento de software da CGD
atravessa para as seguintes: Análise do Pedido; Desenvolvimento; Desfecho do pedido.

Análise do pedido

A análise do pedido é imprescindível em qualquer organização de produção de bens e

serviços, uma vez, que se trata da fase em que é descortinada a necessidade, os objetivos e
âmbito do projeto do cliente.

A finalidade primordial desta fase é traduzir as necessidades do cliente em elementos,

especificamente, backlog do produto organizada pela ordem de prioridades com as histórias do
usuário, critérios de aceitação, cronograma inicial e estimativa dos custos associados. É
estabelecida a visão do projeto e expectativas garantindo recursos para sua execução, e a
definição da arquitetura do sistema.

Comparativamente, ao outro modelo de desenvolvimento de software da CGD, esta traduz em

redução dos detalhes da especificação e na documentação a ser realizada. Porquanto, o
SCRUM se sobressai agregando atividades de monitoramento e feedback através de reuniões
rápidas e diárias com toda equipa.

Desenvolvimento
Definido o planeamento do sprint, as atividades poderão ser iniciadas. Nesta fase o sistema é
desenvolvido em sprints, resultando em um incremento do produto de mais alto valor possível.

As atividades realizadas com objetivo de desenvolver o incremento de um produto de software

são as seguintes:

 Planeamento do sprint;
 Desenvolvimento do produto de software;
 Revisão do desenvolvimento;
 Retrospetiva do desenvolvimento;
 Aceitação do incremento de produto software;
 Entrega de produto de software aos utilizadores na versão beta.

Ainda existem outras atividades contínuas, que são realizadas ao longo de toda fase de
desenvolvimento, em particular, gestão do backlog de produto e reunião diária.

Descrição sucinta das atividades da fase de desenvolvimento

Planeamento do sprint: Antes do início de cada Sprint, a equipa de desenvolvimento e o

Product Owner, com base no Backlog de produto, chegam a acordo sobre as stories a
desenvolver para o novo incremento. O planeamento termina com a elaboração do Backlog do
Sprint, que consiste em atividades a realizar para conclusão de cada uma das stories
escolhidas para serem desenvolvidas durante o Sprint.

Desenvolvimento do produto de software: É considerado o coração do processo de

desenvolvimento, a equipa de desenvolvimento cria uma versão incremental e potencialmente
utilizável do produto de software. A sua duração, definida na atividade de planeamento do
Sprint, deverá ser de 2 a 4 semanas.

Reunião diária: Esta reunião realizada diariamente tem como objetivo a comunicação entre os
elementos da equipa e a inspeção do Sprint. Com a duração de 15 minutos no máximo, deverá
ser realizada de pé. Cada elemento da equipa deverá responder a três questões:

1. O que fiz ontem?

2. O que vou fazer hoje?

3. Quais os meus impedimentos?

Revisão do Desenvolvimento: Realizada 1 dia antes final do Sprint, permite que a equipa
apresente ao cliente ou a qualquer parte interessada, o incremento de produto realizado. A
partir do feedback dos presentes, adapta o Backlog do produto se necessário.

Retrospetiva do desenvolvimento: Trata-se de uma oportunidade na qual a equipa discute o

que pode ser melhorado para conseguir realizar melhor e mais rápido trabalho para próximo
sprint.

Aceitação do incremento de produto software: Nos testes de aceitação é obtida a confirmação

de que as stories desenvolvidas satisfazem os requisitos do cliente, cumprindo os respetivos
critérios de aceitação. Os testes de aceitação devem ser realizados pelo cliente em conjunto
com a equipa de desenvolvimento

Entrega de produto de software aos utilizadores na versão beta: Atividade na qual é

disponibilizado o incremento do produto de software aos utilizadores finais.

Desfecho do pedido

Nesta fase é realizada a preparação para a entrega de software ao cliente. As seguintes

atividades são realizadas nesta fase conclusiva:

 Facultar a documentação de arquitetura do sistema;

 Disponibilizar os manuais do produto de software;
 Realizar a passagem da informação/documentação necessária para as equipas que
vão manter o produto de software;
 Averbar e partilhar as lições aprendidas no projeto;
 Formalizar a conclusão do pedido junto dos Stakeholders;
 Preparação de treinamento e lançamento do produto.

1.2. Papéis e responsabilidades dos membros no desenvolvimento de software,

baseado no modelo SCRUM

A essência do Scrum é uma pequena equipa de pessoas, altamente flexível e adaptativa. A

equipa Scrum é constituída pelo Product Owner, a Equipa de Desenvolvimento e o Scrum
Master. As Equipas Scrum são auto‐organizadas e multifuncionais.
Enquanto no modelo de desenvolvimento de software da CGD atual é constituída por vários
intervenientes: Diretor de Projeto, Sponsor, Responsável do Pedido/ Gestor de projeto, Equipa
de Projeto (Responsável de equipa (Team Leader), Programadores, Analistas Funcionais,
Responsáveis Técnicos) etc. Para atender a essência do SCRUM esses intervenientes serão
dissolvidos em 3 papéis fundamentais da metodologia SCRUM.

Depois da análise dos papéis dos principais constituintes do modelo de desenvolvimento de

software da CGD atual a dissolução será da seguinte forma:

 As funções do programador e responsável técnico encaixa no papel de equipa de

desenvolvimento no modelo SCRUM;
 As funções do responsável pelo pedido, gestor de projeto e analista funcional será
convertido para papel de Product Owner no modelo SCRUM.

Responsabilidade de Product Owner

O Product Owner (PO) representa a voz do cliente e é responsável por maximizar o valor do
produto.

Determinar as atividades gerais do início do projeto; Avaliar a viabilidade e garantir a entrega

do produto ou serviço; Assegurar os recursos financeiros do projeto, Representar o usuário ou
cliente, Ser responsável pela gestão do Backlog do Produto, Auxiliar a criar e aprovar as User
Stories, Explicar as User Stories para o equipa de Desenvolvimento; Definir os critérios de
aceitação e Participar do projeto e da Retrospetiva da Sprint.

Responsabilidade de equipa de desenvolvimento

O Time de Desenvolvimento é formado por profissionais que realizam o trabalho de entregar

um Incremento potencialmente liberável do produto "Pronto" ao final de cada Sprint.

Garantir um entendimento claro dos requisitos; Desenvolver a lista de tarefas baseado nas
User Stories aprovadas; Calcular os esforços para as tarefas identificadas; Estimar User
Stories aprovadas pelo PO; Criar entregáveis de alta qualidade; Desenvolver o Backlog da
Sprint e o gráfico Burn Down; Identificar oportunidades de melhoria; Participar do projeto e da
Retrospetiva da Sprint.

Responsabilidade de scrum Master

O Scrum Master é responsável por promover e apoiar o Scrum, conforme definido no Guia do
Scrum.
Guiar o time para que sejam autos organizados e multifuncionais; Elimina impedimentos para o
progresso da construção; Garante que o Board do Scrum se mantenha atualizado; Liderar e
guiar a organização na adoção do Scrum; Motivar mudanças para implementar a produtividade
do Time do Scrum (PO e TD); Trabalhar com outros Scrum Masters para aumentar a
efetividade do Scrum; Planejar a implementação do Scrum na organização; Auxiliar o Time do
Scrum (PO e TD) e as partes interessadas a entender e executar o Scrum.

Este trabalho teve como essencial preocupação responder aos desafios da aplicação do
modelo Scrum ao processo de desenvolvimento de software da Caixa Geral de Depósitos
(CGD)