Conheça o Rational Unified Process (RUP)

O Rational Unified Process (RUP) é uma metodologia completa criada pela Rational
para viabilizar que grandes projetos de software sejam bem sucedidos. O RUP é na
verdade um produto composto de material de referência na forma de páginas HTML,
descrevendo toda a metodologia.

Princípios Básicos

Um grande problema nos projetos atuais é o grande dinamismo e complexidade dos

negócios nos dias de hoje. Cada vez mais os sistemas são complexos e precisam estar
prontos em menos tempo. Mais do que isso, as necessidades mudam ao longo do
tempo e a especificação de um sistema provavelmente será alterada durante seu
desenvolvimento. Além disso, temos tecnologias novas (software e hardware) surgindo
a cada dia. Algumas funcionam bem. Outras não. Visando atacar estes problemas, o
RUP adota as seguintes premissas básicas: Uso de iterações para evitar o impacto de
mudanças no projeto, Gerenciamento de mudanças e Abordagens dos pontos de
maior risco o mais cedo possível.

Estrutura Básica do RUP

A figura abaixo apresenta os elementos básicos do RUP. Nesta metodologia, o projeto

passa por quatro fases básicas. Estas fases são: Inception - entendimento da
necessidade e visão do projeto, Elaboration - especificação e abordagem dos pontos
de maior risco, Construction - desenvolvimento principal do sistema, Transition -
ajustes, implantação e transferência de propriedade do sistema.

Figura: Modelo Básico do RUP

1
Apesar de parecer um modelo em cascata, na verdade cada fase é composta de uma
ou mais iterações, o que se assemelha a um modelo em espiral. Estas iterações são em
geral curtas (1-2 semanas) e abordam algumas poucas funções do sistema. Isto reduz o
impacto de mudanças, pois quanto menor o tempo, menor a probabilidade de haver
uma mudança neste período para as funções em questão.

Além das fases e iterações, existem os workflows. Cada workflow é na verdade uma
sequência de tarefas encadeadas e relacionadas a um aspecto importante do projeto,
tal como análise do negócio, testes, etc. Os gráficos da figura mostram a ênfase de
cada workflow em cada etapa do projeto.

Conteúdo do RUP

O que é o RUP afinal? Sabemos neste ponto que é uma metodologia completa e vimos
sua estrutura básica. Porém o que ele oferece?

O RUP, além de uma metodologia, é um produto comercializado pela Rational, que é

uma grande documentação baseada em hipertexto (HTML). Do conteúdo deste
material, destaco os seguintes assuntos:

Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo as

tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos. Cada
tarefa, subproduto e papel são descritos em detalhe. Este modelo pode ser seguido à
risca ou adaptado conforme sua necessidade específica.

Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela,
a qual workflow ela pertence e quais são os subprodutos de entrada e saída.

Modelo de equipe: Os diversos papéis necessários no projeto são descritos em

detalhe. Assim como no MSF, cada papel pode ser representado por mais de uma
pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho
necessário. Porém o RUP aborda os papéis em um maior nível de detalhe. Ao todo são
mais de 30. Exemplos de papéis são: analista de sistemas, analista de negócio, etc.

Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos

documentos (artifacts) gerados ao longo do projeto. Estes documentos são descritos
em detalhe, assim como as tarefas que os geram e as que os utilizam. Para os usuários
das ferramentas Rational, existe um recurso adicional e-coach, que orienta o usuário a
usar ferramentas como o Requisite Pro passo a passo. Os documentos são totalmente
compatíveis com a UML, o que reforça a questão de padronização.

Como Adotar

Com base nestes recursos a adoção do RUP pode ser feita de mais de uma maneira.
Um extremo seria usar o RUP à risca, ou seja, aplicar todos os métodos e processos
exatamente como são propostos. A vantagem desta abordagem é que nada deve ser
alterado, pois o RUP é bem completo e detalhado. Porém existe um preço a ser pago,
pois o RUP na íntegra é complexo. Esta abordagem implicaria em treinamentos,
2
projetos piloto, etc. Propostas de projetos de adoção do RUP são descritos no próprio
produto.

O extremo oposto seria adotar outro modelo de processo mais simples ou conhecido
(o atual, se existir) e utilizar o material do RUP como fonte de referência
complementar para assuntos não abordados em outro modelo como, por exemplo, os
modelos de documentos.

A primeira abordagem é interessante para empresas que precisam de uma grande

formalização do processo de desenvolvimento de software e cujo método atual seja
totalmente inadequado ou inexistente. A segunda abordagem seria interessante para
quem já tem alguma metodologia que considera adequada, mas que tem deficiência
em alguma área como, por exemplo, suporte a UML. Soluções intermediárias também
são possíveis.

3
 Conceitos de XP

A Extreme Programming se baseia em uma série de conceitos que são ou novos ou só

eram utilizados para desenvolvimento no nível acadêmico.

Cada um destes conceitos pode ser localizado inteiramente ou parcialmente em cada

uma das etapas do desenvolvimento de software. Por exemplo, a programação em par
é parte tanto do processo de análise quanto do processo de desenvolvimento; as
histórias dos usuários estão diretamente ligadas à parte de planejamento.

A compreensão completa de cada um dos conceitos da Extreme Programming tem

importância fundamental e sua parcela de colaboração no sucesso da Extreme
Programming.

Os principais conceitos da Extreme Programming são:

 Equipe;
 Planejamento;
 Programação em Par;
 Design Evolucional;
 Integração do Sistema;
 Estilo Consistente;
 Protótipo.

Equipe

A Extreme Programming segue baseada na linha de valorização do recurso humano

observando as relações interpessoais. Cada membro da equipe exerce um papel
diferente e tem direitos que implicam em deveres dos outros membros. Existe então
um comprometimento geral no crescimento e formação dos integrantes do grupo de
trabalho. Para qualquer empresa este crescimento implica em agregar valor ao capital
intelectual.

Todos os trabalhadores de uma organização, independente da posição hierárquica, do

mais baixo ao presidente da empresa, não só pode como deve contribuir para a
formação do capital intelectual desta organização, mas para isso deve haver uma
política clara, definida e principalmente um sistema de informações por trás de tudo,
que não precisa ser complexo, mas deve possuir as funções básicas de armazenar,
criando um banco de dados, tratar e divulgar a informação de forma objetiva e
possivelmente agregando valor.

As Duas Equipes

4
A Extreme Programming, sempre se preocupando com a relação entre os indivíduos,
divide a equipe responsável pelo software a ser desenvolvido em duas: a equipe do
cliente e a equipe dos desenvolvedores. Estas equipes devem colaborar em tudo que
for necessário para que o melhor software possível seja desenvolvido.

No entanto, como parte do processo de divisão de tarefas cada equipe tem seus
objetivos específicos, direitos e participantes.

Equipe do Cliente

A equipe do cliente é composta por pessoas que vivenciam o problema e serão

diretamente beneficiadas pela solução que o software desenvolvido implementará.

A tarefa da equipe do cliente é de cobrar e colaborar para que tudo seja feito para que
o produto final atenda completamente aquilo que é esperado para a solução do
problema.

É requisito da Extreme Programming que a equipe de cliente esteja sempre junto

auxiliando a equipe de desenvolvimento em todos os passos, podendo estar alojada
fisicamente, por exemplo, na mesma sala.

Equipe de Desenvolvimento

Os desenvolvedores são responsáveis por estimar as tarefas, ajudar os

clientes a verem as conseqüências de suas decisões, adaptarem os seus
processos de desenvolvimento e entregar o sistema. Essa não é uma tarefa
fácil.

Para ajudar na tarefa de desenvolvimento a Extreme Programming

desenvolveu uma série de métodos, entre eles a metáfora e as histórias do
usuário, que ajudam os desenvolvedores.

Existem ainda outros conceitos aplicados e que também colaboram para o sucesso do
trabalho da equipe. Por exemplo, aspectos do paradigma adotado. No caso do
paradigma orientado a objeto, têm-se os objetos e suas relações como facilitador na
construção, alteração e entendimento do sistema.

Como ocorre na equipe do cliente, na equipe dos desenvolvedores cada individuo

recebe uma tarefa específica que deve cumprir para que os objetivos sejam atingidos.

Planejamento

Na Extreme Programming, o planejamento é dividido em planejamento de releases, de

interações e tático. Todos eles de igual importância e com políticas bem definidas. A
maior parte do planejamento e do desenvolvimento propriamente dito é baseada nas
histórias contadas pelo contador de história, denominadas histórias do usuário.

5
Fisicamente as histórias dos usuários são anotadas em pedaços de papel (cartões) e
segue uma padronização utilizada para as estimativas e testes do sistema. Será
percebida ao longo da análise de cada parte do planejamento a importância das
histórias do usuário.

Planejamento de Releases

Releases são as versões do software liberadas para implantação. É aconselhado que o

tempo entre um release e outro seja de no máximo três semanas.

O planejamento dos releases ocorre nas reuniões de planejamento. Nestas reuniões

cada equipe, bem como cada participante da equipe, tem seu papel.
É importante que desenvolvedores tomem as decisões técnicas e os
clientes tomem as decisões relativas ao negocio. O planejamento de
releases possui uma série de regras que permitem que todos os envolvidos
no projeto tomem as suas próprias decisões. As regras definem um método
para negociar uma agenda a que todos devem se comprometer.

Nas reuniões de planejamento de versão as histórias devem ser divididas por versão
cabendo a equipe de clientes definirem prioridades e a equipe de desenvolvimento
verificar a possibilidade e os prazos baseando-se nas estimativas já feitas nos cartões
das histórias de usuários.

Existe o planejamento baseado em tempo e baseado em escopo. No primeiro, as datas

das versões estão fixadas por algum motivo. Cabe aos clientes definir o que deve estar
incluído no sistema em cada data e os desenvolvedores analisarão as possibilidades. Já
no segundo, as datas serão definidas segundo as versões que os clientes desejam.
Chamando atenção que as versões não devem ser muito distantes como aconselha.

Planejamento de Interações

Inicialmente o produto não existe, depois é criada uma versão que atenda às
funcionalidades básicas que é melhorada até atingir o sistema completo que é
desejado necessário para o cliente.

Pode-se dizer que cada interação tem um resultado final. Existe, por exemplo, uma
interação que leva ao release, mas esta interação é formada de outras interações que
deram origem às partes integrantes do release.

Para uma equipe que está desenvolvendo em Extreme Programming pela primeira vez
ou mesmo para um cliente que nunca participou de um projeto em Extreme
Programming, é importante que a primeira interação que dará origem a um release,
denominado sistema central, seja executada com perfeição.
A entrega desse sistema central é um marco importante. Ele prova para a
equipe do cliente que a XP (Extreme Programming) funciona. Ele prova
para a equipe de desenvolvimento que eles podem fazer com que ela
aconteça.

6
 O planejamento de interações é desenvolvido a todo o momento, principalmente
quando se faz o planejamento de releases.

Planejamento Tático

O planejamento tático baseia-se principalmente na separação de tarefas para uma

determinada versão do software a ser desenvolvida.

Geralmente uma tarefa é feita por um desenvolvedor voluntário e outro que desejou
ajudá-lo. Aqui entra os aspectos de desenvolvimento em par, chamado em Extreme
Programming de pair programming

Todo o planejamento deve ser acompanhado e controlado para realmente se ter

certeza de que será possível entregar no prazo aquilo que foi planejado para um
release. Em Extreme Programming, as reuniões no início de cada dia servem
exatamente para este fim.

Programação em Par

Toda produção de código em Extreme Programming é feita por dois programadores

sentados lado a lado em uma mesma máquina. Esta prática assegura que toda a
produção de código é revisada por ao menos duas pessoas, resultando assim em
melhor desenho, melhor teste e melhor código.

Apesar de parecer ineficiente se ter dois programadores fazendo o trabalho de um

programador, alguns estudos feitos em North Carolina State University em Raleigh,
mostram que apesar do trabalho feito em dupla produzir menos código ele produz um
código mais livre de erros do que o código produzido por um programador
trabalhando sozinho.

Alguns programadores opõem-se a programação em par sem nunca terem ao menos a

tentado. É necessário alguma pratica para fazer isto bem, e você precisa fazer isto bem
por algumas semanas para poder ver os resultados. Noventa por cento dos
programadores que aprendem a programar em par preferem este modo de
programação, portanto programação em par é altamente recomendado para todos os
times.

Programação em par, além de fornecer melhor código e teste também auxilia na

comunicação do conhecimento através do time. Como os pares são mudados
periodicamente, todos têm o beneficio de um conhecimento distribuído pelo grupo.
Programadores aprendem, suas habilidades são aprimoradas ao mesmo tempo em
que eles se tornam mais valiosos para o time e para a empresa. Mesmo fora da
Extreme Programming, Programação em par representa um grande ganho para todos.

7
Design Evolucional

Seguindo a metodologia extreme programming um sistema, para ser construído, deve

possuir um protótipo que servirá de base para a implementação do mesmo aos
poucos, abstraindo as rotinas que não interessam às regras do negócio em questão e
concentrando-se em modularizar o problema ao máximo, assim um grande sistema é
construído através de pequenos pedaços que compõe o todo.

Nesta técnica o mesmo protótipo utilizado para apresentar o sistema ao cliente poderá
ser utilizado para iniciar o desenvolvimento, desta forma a preocupação com layout de
interface está separada da preocupação com codificação da lógica de negócio.

Outro ponto importante é a entrega de várias versões com pequenas melhorias sendo
implementadas evolutivamente. Desta forma se o cliente não estiver satisfeito com
uma funcionalidade poderá sinalizar para a equipe de desenvolvimento que não terá
que varrer uma área muito grande de código para corrigir tal funcionalidade.

Ainda pela metodologia várias versões do software devem ser lançadas, e a cada uma
delas uma funcionalidade é liberada após testada e homologada, ou seja o sistema
tem uma evolução através de rápidas e pequenas implementações.

Integração do Sistema

Por possuir um protótipo em parte funcional, um sistema construído segundo esta

metodologia pode ter seus módulos facilmente integrados, porém é necessário que
haja alguém responsável por manter tal integração. A harmonia entre os pedaços do
sistema deve ser considerada durante o desenvolvimento, e não em uma fase
separada, para que ao término do desenvolvimento o trabalho de integração esteja
automaticamente concluído.

Para que a integração possa proceder de maneira contínua é necessário que exista um
repositório único onde estarão os códigos fontes do sistema, tal repositório possui um
mecanismo de travas de versões de cada arquivo fonte, assim, evita-se perda de
códigos acidentais e garante-se a integridade dos mesmos, permitindo verificar se
alguns trechos de código foram alterados simultaneamente e dando a possibilidade a
quem estiver atualizando o repositório escolher a melhor versão para ser integrada.

Além de possibilitar manter sempre a versão mais recente do sistema rodando, mesmo
que este ainda possua partes não homologadas, pois cada desenvolvedor apenas
colocará no repositório o código que julgar suficientemente estável para começar a ser
testado para entrar em produção no próximo release liberado, integrado ou
homologado.

Por ter a filosofia de integração contínua, o sistema deve sempre ser revisado para que
este se mantenha rodando durante toda a fase de desenvolvimento. Assim, sempre
um par de programadores deverá estar adequando todo o código que for adicionado
ao repositório.

8
Integração Contínua

Se um módulo de um sistema funciona perfeitamente quando executado sozinho isto

não significa que ele funcionará perfeitamente quando estiver sendo executado em
conjunto com os outros módulos.

Nos métodos de desenvolvimento tradicionais, onde muitas vezes os programadores

não têm uma visão do sistema como um todo e sim apenas a visão específica do
módulo construído por ele, cada programador ao terminar de escrever um novo
módulo, o testa, e o integra ao sistema de forma paralela com outros programadores.
Sem ao menos verificar se o resultado de toda esta integração foi satisfatório ou não.

Ao se fazer integrações periódicas do sistema inteiro assim como um teste conciso

destas integrações à medida que pequenas partes do projeto são criadas a equipe de
desenvolvimento tem um trabalho extra que é recompensado mais tarde na hora da
integração final.

Times de programação em extreme programming chegam a fazer integrações e testes

do sistema várias vezes ao dia (cerca de oito a dez vezes) evitando o tão conhecido
“inferno da integração” que tanto acomete os sistemas desenvolvidos usando-se os
métodos tradicionais.

Estilo Consistente

Consiste em uma padronização do código escrito pela equipe de desenvolvimento e

tem como objetivo otimizar a criação dos módulos do sistema, centralizando trechos
de código que mais tarde poderão sofrer eventuais alterações, a depender das
necessidades, seja por conta da adição de funcionalidades, modificação de regras de
negócio ou até mesmo correção de erros, que por ventura não tenham sido
detectados antes da liberação da funcionalidade.

Antes de desenvolver cada funcionalidade, unidades de testes devem ser

desenvolvidas para que no momento em que estas estejam prontas, possam ser
validadas de forma quase que automática. Em resumo a fase de testes começa antes
da codificação de fato.

O Extreme Programming utiliza o conceito de código compartilhado, isto quer dizer

que qualquer um dos desenvolvedores da equipe está apto a mexer em qualquer
ponto do sistema sem a necessidade de realizar uma análise muito aprofundada do
código em si, bastando apenas se focar mais na regra de negócio em si. O principal
neste caso é a preocupação com a finalidade da funcionalidade em si e não com a
forma de como é codificada.

O uso de padronização de código em outras formas de desenvolvimento também

poderia otimizar o desenvolvimento do projeto. Mesmo que não seja utilizado o pair
programming, quando da união dos módulos, é mais fácil de entender o que o outro
desenvolvedor codificou.

9
Para que o estilo consistente possa funcionar da melhor forma possível todos devem
estar atentos para os padrões que estão sendo definidos, e tais padrões são definidos
em tempo real, por isso é interessante para a equipe que todos os desenvolvedores
estejam sincronizados com as maneiras como o projeto é ‘governado’. Além disso
torna-se importante que todos os elementos da equipe sejam proativos para que os
padrões continuem num constante aperfeiçoamento.

Para exemplificar podemos citar um grupo de desenvolvedores que utiliza bibliotecas

de códigos como frameworks, componentes personalizados para facilitar a criação das
funcionalidades. Um framework em sua essência é uma biblioteca de códigos que
oferece além de código pronto, uma padronização da maneira de criar os novos
pedaços de códigos que são realmente necessários à regra de negócio em questão, são
nesses trechos que se encontram de fato a ‘inteligência’ do sistema em
desenvolvimento.

Protótipo

Com a criação de um protótipo é mais rápido realizar a codificação, pois todo o

desenvolvimento é padronizado, além disso torna-se mais fácil testar pois o código é
mais homogêneo e é de conhecimento de todos os membros da equipe de
desenvolvimento.

O cliente pode entender melhor a solução do problema proposta pela equipe de

desenvolvimento, inclusive o cliente pode verificar se o layout de interface proposto
está bom ou não. Em resumo o cliente pode ver melhor como estarão arrumadas as
funcionalidades do sistema.

Por estar tendo uma visão inicial da cara do sistema o cliente pode perder o foco das
funcionalidades e querer que a equipe se foque em detalhes irrelevantes da parte do
layout de interface.

Ë importante que a equipe de desenvolvimento não deixe que o próprio protótipo não
vire o sistema em si, isto é o protótipo desenvolvido é tão detalhado que parte das
funcionalidades aparentam estar implementadas. Com isso perde-se tempo de
desenvolvimento além de poder passar uma falsa imagem do sistema para o cliente.

Simple Picture - Protótipo Evolutivo

Simple Picture para a metodologia de desenvolvimento Extreme Programming significa

ter um protótipo que além de conter toda a cara do sistema servirá como base para a
construção do mesmo, por esse motivo tal protótipo deve ser feito de forma que toda
a estrutura do sistema esteja pronta ao final da construção deste protótipo tenhamos
todo o escopo do sistema funcional. Assim a navegação deve estar construída ao final
desta fase e, portanto, a integração do sistema será facilitada pois, toda a estrutura de
interface entre os módulos estará pronta.

10
 Devemos observar que todos os membros da equipe de desenvolvimento devem
compartilhar do mesmo protótipo gerado para que durante a fase de desenvolvimento
dos componentes do sistema não tenhamos versões concorrentes do mesmo
caminhando em paralelo.

O objetivo deste procedimento no projeto é a facilidade da realização dos testes e

consequentemente na criação do código. Como vimos, devemos fazer os testes antes
da codificação, o protótipo fica no intermédio destes processos. Pois além de fazer o
interfaceamento entre as funcionalidades do sistema, ele serve também como meio de
auxilio à comunicação entre cliente e desenvolvedores.

11
 O que é Scrum?

O SCRUM é um modelo de desenvolvimento ágil de software que fornece métodos

para se definir o planejamento, os principais papéis de pessoas e a forma de trabalho
do time. O nome SCRUM é derivado de uma jogada de rúgbi, onde todo o mesmo time
avança como apenas uma unidade, trabalhando com os mesmos jogadores e em
conjunto, passando sempre a bola pra um e para outro.

A idéia do SCRUM é justamente definir papéis bem específicos para as pessoas

envolvidas no projeto e como cada pessoa vai jogar, ou seja, o que cada uma vai ter
que fazer para o time seguir em frente no jogo: que no nosso caso é o próprio
desenvolvimento do software.

Em geral e de forma reduzida, esta metodologia funciona da seguinte forma:

1. O produto é definido: quais são os seus requisitos? O que realmente o cliente

quer? O responsável por esta tarefa é o que chamamos de Proprietário do
Produto (Product Owner, em inglês).
2. O Proprietário do Produto define quais são as funcionalidades do programa que
mais importam, criando assim o que chamamos de Product Backlog.
3. Com as prioridades definidas, uma pessoa é definida para ser o ScrumMaster,
uma espécie de coordenador do projeto. O ScrumMaster, junto com o
Proprietário do Produto e o Time de desenvolvimento definem o que
chamamos de Sprints.
4. Cada Sprint possui uma parte de todo o Product Backlog, e devem ser
trabalhados de acordo com as prioridades definidas no Product Backlog. Os
Sprints devem ser preparados de uma forma de que durem de 2 a 4 semanas, e
que no final de cada período tenham um produto apresentável para o cliente.
5. Os Sprints vão sendo feitos até o Product Backlog acabar e o Proprietário do
Produto definir que o projeto está pronto. Mas isso não quer dizer que novas
funcionalidades não podem ser incluídas: basta ir adicionando no Product
Backlog e realizando outros Sprints.

Durante os passos reais de desenvolvimento, os Sprints, a principal ferramenta de

medição de desempenho é o Burndown Chart, que é uma das características mais
especiais do SCRUM e que o torna um grande diferencial, no sentido positivo.

Falando mais detalhadamente, o SCRUM tem três partes principais em seu modelo:
Papéis (Roles), Cerimônias (Cerimonies) e Artefatos (Artifacts). Cada um destes três
pilares contém outros sub-itens. Todas estas três partes principais são utilizadas no
que chamamos de ciclo de desenvolvimento, ou seja, o Sprint. Cada Sprint possui suas
fases e utiliza destes papéis, cerimônias e artefatos para alcançar seu objetivo final.

12
Papéis do SCRUM (Roles)

Como a metodologia define como o time deve trabalhar, o primeiro passo para o
desenvolvimento por SCRUM é definir quem vai fazer o quê. Por isso chegamos a três
entidades principais: o Proprietário do Produto (Product Owner), o ScrumMaster e o
Time.

Proprietário do Produto (Product Owner)

O Proprietário do Produto representa os interesses do cliente. Ele tem que ser a

interface entre o cliente e o time de desenvolvedores, ou seja, estar sempre em
contato com o cliente e saber exatamente o que o projeto tem que ser.

Ele tem as seguintes responsabilidades:

 Definir as características e conteúdo do produto;

 Decidir sobre a data de término;
 Ser responsável pela rentabilidade do produto;
 Priorizar as funções de acordo com o valor de mercado e com o cliente;
 Ajustas recursos e priorizar tarefas a cada 30 dias, como necessário;
 Aceitar ou rejeitar o resultado do trabalho.

ScrumMaster

O ScrumMaster é o líder da equipe de desenvolvimento e durante o trabalho, fica mais

em contato com o Proprietário do Produto. Ele gerencia e repassa o trabalho que foi
decidido durante o planejamento pelo Proprietário do Produto. Ele deve:

 Assegurar que a equipe de desenvolvimento funcione plenamente e seja

produtiva;
 Ajudar na cooperação entre todas as funções e papéis do time;
 Remover barreiras;
 Proteger a equipe de interferências externas;
 Assegurar-se de que a metodologia está sendo seguida, incluindo chamadas
para reuniões diárias (Daily Scrum Meetings), revisões de atividade (Sprint
Reviews) e reuniões de planejamento das atividades (Sprint Planning).

Devido a todas estas responsabilidades, o ScrumMaster é o que podemos chamar de

Coordenador do Projeto. Ele facilita a comunicação entre as pessoas e faz o projeto
andar de verdade.

Além de comandar as reuniões diárias, o ScrumMaster têm três principais

responsabilidades:

1. Precisa saber quais atividades foram concluídas, quais foram iniciadas,

quaisquer novas tarefas que foram descobertas e qualquer estimativa que
possa ter mudado. Isto permite a ele atualizar sempre o Burndown Chart, que
permite mostrar quanto trabalho falta para um Sprint acabar, dia por dia. Ele
13
 também tem que sempre olhar cuidadosamente para o número de tarefas em
aberto. Estes trabalhos em aberto devem ser minimizados o máximo possível
para garantir um trabalho sempre limpo e eficiente.
2. Deve avaliar as dependências superficiais e bloqueios que causam prejuízos ao
andamento do Projeto. Estes itens devem receber prioridades e serem
acompanhados. Um plano de solução deve ser implementado de acordo com a
ordem de prioridade destes impedimentos. Alguns podem ser resolvidos pelo
time, outros podem ser resolvidos através de vários times, e outros podem
precisar de envolvimento da gerência, pois podem ser problemas relacionados
à empresa que bloqueiam qualquer membro do time a fazer qualquer coisa.
Como exemplo deste tipo de impedimento externo, temos as questões
judiciais.
3. O ScrumMaster deve perceber e resolver problemas pessoais ou conflitos entre
os integrantes do time de desenvolvimento SCRUM. Este tipo de problema
deve ser clarificado pelo ScrumMaster e resolvido por diálogo com o time, ou
então o ScrumMaster terá que ter ajuda da gerência ou do departamento de
Recursos Humanos. Alguns estudos apontam que 50% dos problemas de
desenvolvimento acontecem por razões pessoais. O ScrumMaster precisa estar
sempre atento ao time para fazer dele totalmente funcional e produtivo.

A Equipe de Desenvolvimento

A equipe de desenvolvimento é quem vai colocar a mão na massa para que o software
comece a ter cara e funcionamento. Pode haver uma ou mais equipes de
desenvolvimentos, dependendo da complexidade do software.

Algumas características das equipes de desenvolvimento:

 São pequenas e multidisciplinares, com em média 7 participantes;

 Definem metas de cada Sprint, junto ao ScrumMaster, e especificam seus
resultados de trabalho;
 Têm o direito de fazer tudo dentro dos limites das diretrizes do projeto para
atingir a meta de cada Sprint;
 Organizam os trabalhos para atingir os objetivos dos Sprints;
 Trabalham para atingir todos os resultados definidos pelo Proprietário do
Produto.

Cerimônias SCRUM (Cerimonies)

As cerimônias SCRUM são eventos que acontecem dentro de um ciclo de

desenvolvimento utilizando esta metodologia. Existem três tipos de cerimônias
SCRUM: a reunião de Planejamento do Sprint, as reuniões diárias SCRUM e a reunião
de revisão do Sprint. Estes três tipos de evento caracterizam bem o ciclo de vida de
cada Sprint: início, meio e fim.

Reunião de Planejamento do Sprint

14
Como dito anteriormente em resumo, o primeiro passo de um projeto SCRUM é
quando o Proprietário do Produto desenvolve um plano para o projeto de software.
Neste plano, o Proprietário do Produto trabalha bem próximo ao cliente para definir
todas as funcionalidades que o cliente quer no seu produto. A partir desta lista, ele
também tem que definir as prioridades de cada funcionalidade de acordo com várias
variáveis: valor de mercado, importância de base, importância para o cliente, entre
outras. Esta lista final é o que chamamos de Product Backlog e é a base para a reunião
de planejamento do Sprint.

Nesta reunião, o ScrumMaster trabalha junto com o Proprietário do Produto e a

Equipe de Desenvolvimento para definir qual a carga de tempo que cada
funcionalidade do Product Backlog terá. Isto ajuda o Proprietário do Produto a definir
prazos reais para o projeto e o habilita a poder verificar como está o andamento do
projeto durante todo o período de desenvolvimento. Esta carga de tempo e esforço é
definida de acordo com o tamanho do(s) time(s), horas disponíveis e o nível de
produtividade do time.

Quando as prioridades e prazos das funcionalidades do software são definidas por

completo, o Proprietário do Produto sai de cena e o ScrumMaster começa a trabalhar
juntamente com a Equipe de Desenvolvimento para a quebra destas tarefas grandes
em pequenas tarefas, divididas por todos os integrantes da equipe de
desenvolvimento de acordo com suas especialidades. Esta reunião de planejamento
geralmente dura até 4 horas e é ela quem define o Sprint Backlog, um dos artefatos
SCRUM.

Uma vez definido o Sprint Backlog, com a listagem de todas as tarefas, seus
responsáveis e seus prazos, o processo de desenvolvimento começa.

Reuniões Diárias SCRUM

Uma das principais características deste modelo de desenvolvimento ágil são as

reuniões diárias SCRUM, onde o ScrumMaster se reúne com a equipe de
desenvolvimento para saber como anda o projeto. Esta reunião acontece todo dia
durante o ciclo de desenvolvimento (Sprint) e tem uma duração curta de
aproximadamente 15 minutos.

Durante a reunião, cada um dos membros responde as seguintes três perguntas:

1. O que fiz ontem?

2. O que farei hoje?
3. Quais impedimentos e dificuldades apareceram no caminho?

O ScrumMaster tem um papel muito importante nestas reuniões: ele terá que
identificar todos os problemas ou novas tarefas que surgirem e planejar como estas
aparições serão resolvidas. Além do mais, ele terá assim uma visão completa do
projeto e poderá gerenciar todas as sub-tarefas de cada Sprint, preenchendo assim o
Burndown Chart.

15
Reunião de Revisão do Sprint

No final do período do Sprint, a reunião de revisão do Sprint é feita. Nesta reunião, a

equipe de desenvolvimento, junto ao ScrumMaster, se reúne com o Proprietário do
Produto (e convidados, caso ele achar adequado, como por exemplo o cliente ou
acionistas do projeto). Esta reunião dura aproximadamente 4 horas.

Na primeira parte da reunião, o resultado do Sprint é apresentado para o Proprietário

do Produto, ou seja, tudo que foi desenvolvido durante o ciclo de desenvolvimento. As
funcionalidaes são revisadas e o valor do produto é definido. Depois de revisar todo
este resultado, o Proprietário do Produto define quais itens do Product Backlog foram
completados no Sprint, discutindo então com os membros da equipe e o cliente quais
serão as novas prioridades. Este é o primeiro passo para criar um novo Sprint, caso seja
necessário, pois dessa primeira parte da reunião, um novo Product Backlog é gerado.

Na segunda parte da reunião, o ScrumMaster se reunie com a equipe de

desenvolvimento e revisa os altos e baixos do ciclo. O time conversa para saber o que
foi bom e como se pode melhorar ainda mais o ambiente, as ferramentas e o convívio
entre o time e suas funções. Esta parte é basicamente um aprimoramento interno.

Depois que esta reunião é finalizada, um novo ciclo Sprint pode começar até que todo
o produto seja implementado/finalizado e o Product Backlog esteja limpo de
pendências.

Artefatos SCRUM (Artifacts)

Os artefatos SCRUM são as ferramentas básicas para se trabalhar com este modelo de
desenvolvimento. Estes artefatos servem como guias e indicadores durante o
processo. São dividos em três: Product Backlog, Sprint Backlog e Burndown Chart.

Product Backlog

Como vimos anteriormente, no início do projeto, o Proprietário do Produto prepara

uma lista de funcionalidades desenvolvida em conjunto com o cliente, que é
organizada por prioridade de entrega. Essa lista chama-se Product Backlog. A equipe
SCRUM contribui para o Product Backlog estimando o custo do desenvolvimento das
funcionalidades.

O Product Backlog deve incluir todas as funcionalidades visíveis ao cliente, mas

também os requisitos técnicos para poder desenvolver o produto, e em torno de dez
dias de desenvolvimento esses itens deverão estar prontamente definidos para o seu
desenvolvimento começar. As tarefas que tem mais prioridade e complexidade são
quebradas em sub-tarefas para poderem ser estimadas e testadas.

Pense no Product Backlog como uma WishList: uma lista de itens que queremos ter.

16
Sprint Backlog

Assim que a equipe de Scrum escolher e definir a lista de requisitos e a prioridade de

seus itens do Product Backlog, cada um desses itens agora será dividido em partes
menores para o Sprint Backlog. Ou seja, uma lista especificando os passos necessários
para implementar uma funcionalidade do sistema.

Logo após o Sprint Backlog estar concluído, o total de horas trabalhadas é comparado
com o total previsto anteriormente no Product Backlog. Caso haja uma diferença
significativa, a equipe SCRUM deve negociar novamente com o cliente o número
correto de horas, para que o Sprint seja realizado com maior probabilidade de sucesso.

Burndown Chart

O Burndown Chart é um gráfico que mostra a quantidade de trabalho cumulativo

restante de um Sprint, dia por dia. Neste gráfico, a altura indica a quantidade de
tarefas do Sprint Backlog não completadas, e o comprimento são os dias. Com isto,
podemos visualizar facilmente se um trabalho está tendo progresso, completando as
tarefas, enquanto vemos que as colunas do gráfico vão caindo em sua altura. Se um
ciclo de desenvolvimento, ou Sprint, tem a duração de 30 dias, haverá 30 colunas
juntas. As colunas têm que diminuir ao longo do comprimento e antes ou até o 30º dia
não poderá haver colunas: indicando que todos as tarefas foram completadas e o
Sprint foi um sucesso.

Durante as reuniões diárias do Sprint, o ScrumMaster acompanha os membros da

equipe para ver o que foi terminado. Assim, dia a dia, ele ajusta o Burndown Chart e a
qualquer momento todo o time pode ter uma idéia de como o processo está andando.
O mesmo gráfico pode ser mostrado para o Proprietário do Produto ver que está tudo
indo bem.

Por essas razões, o Burndown Chart é um dos principais recursos de medição do

processo de desenvolvimento e um diferencial para a metodologia SCRUM.

Bibliografia:

http://www.linhadecodigo.com.br

http://www.adonaimedrado.pro.br

http://www.devin.com.br

17