Metodologia de Desenvolvimento

Gerenciamento gil de Projetos de Sistemas de TI

A funo primria desta metodologia padro Scrum o gerenciamento de projetos de
desenvolvimento de Sistemas de TI na NUCLEP em conjunto com a ferramenta Trello para a
documentao de cada etapa do projeto disponvel em www.trello.com.

Caractersticas
Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente
interessados pelo resultado);
Entregas frequentes e intermedirias de funcionalidades 100% desenvolvidas;
Planos frequentes de mitigao de riscos desenvolvidos pela equipe;
Discusses dirias de status com a equipe de desenvolvimento quando cada membro da equipe
de desenvolvimento responde s seguintes perguntas:
O que fiz desde ontem em direo a meta?
O que estou planejando fazer at amanh em direo?
Existe algo me impedindo de atingir meta?
Transparncia no planejamento e desenvolvimento;
Reunies frequentes com as partes interessadas para monitorar o progresso;
Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquer
problema no visto;
Locais e horas de trabalho devem ser considerados no sentido de que "trabalhar horas extras" no
necessariamente significa "produzir mais".

Sprint (corrida, tiro)

Uma sprint a unidade bsica de desenvolvimento em Scrum. Sprints so um esforo dentro de
uma faixa de tempo (ou seja, restrito a uma durao especfica) de comprimento constante. No
nosso caso, definido como uma semana.
Cada sprint precedido por uma reunio de planejamento (Sprint Planning), onde as tarefas para a
sprint so identificadas e um compromisso estimado para o objetivo da sprint definido e seguido
por uma reunio de reviso ou de retrospectiva, onde o progresso revisto e lies para os prximos
sprints so identificadas.
Durante cada sprint, a equipe cria um incremento de produto potencialmente entregvel (por
exemplo, software funcional e testado). O conjunto de funcionalidades que entram em um sprint
vm do Product Backlog, que um conjunto de prioridades de requisitos de alto nvel definidos
pelo Product Owner.
Quais itens do backlog que entram para a sprint so determinados durante a reunio de
planejamento da sprint (Sprint Planning). Durante esta reunio, o Product Owner informa a equipe
dos itens no backlog do produto que ele ou ela quer concludos.
A equipe ento determina quantos eles podem se comprometer a concluir durante o prxima sprint,
e registram isso no backlog da sprint. Durante um sprint, ningum est autorizado a alterar o
backlog da sprint, o que significa que os requisitos so congelados para esse sprint.
O desenvolvimento de cada sprint deve terminar na "caixa de tempo" prevista. Se os requisitos no
so completados por qualquer motivo, eles so deixados de fora e voltam para o backlog do
produto. Depois que um sprint completado, a equipe demonstra como usar o software.
O Scrum permite a criao de equipes auto-organizadas, encorajando a co-localizao de todos os
membros da equipe e a comunicao verbal entre todos os membros e disciplinas da equipe no
projeto.
Um princpio chave do Scrum o reconhecimento de que, durante um projeto, os clientes podem
mudar de ideia sobre o que eles querem e precisam (muitas vezes chamados requisitos churn), e que
os desafios imprevisveis no podem ser facilmente tratados de uma maneira preditiva ou planejada
tradicional. Como tal, o Scrum adota uma abordagem emprica, aceitando que o problema no pode
ser totalmente entendido ou definido, focando na maximizao da habilidade da equipe para
entregar rapidamente e responder s necessidades emergentes.

Cada sprint uma iterao que segue um ciclo (PDCA) e entrega incremento de software
pronto.
Um backlog conjunto de requisitos, priorizado pelo Product Owner (responsvel pelo ROI
e por conhecer as necessidades do cliente);
H entrega de conjunto fixo de itens do backlog em srie de interaes curtas ou sprints;
Breve reunio diria, ou daily scrum, em que cada participante fala sobre o progresso
conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avanando (tambm
chamado de Standup Meeting ou Daily Meeting, j que os membros da equipe geralmente
ficam em p para no prolongar a reunio).
Breve sesso de planejamento, na qual os itens do backlog para uma sprint (iterao) so
definidos;
Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

O Scrum facilitado por um Scrum Master, que tem como funo primria remover qualquer
impedimento habilidade de uma equipe de entregar o objetivo da sprint. O Scrum Master no o
lder da equipe (j que as equipes so auto-organizadas), mas atua como um mediador entre a
equipe e qualquer influncia desestabilizadora. Outra funo extremamente importante de um
Scrum Master o de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum,
motivando-os e mantendo o foco na meta da Sprint.
Papis
Scrum um esqueleto de processos que contm grupos de prticas e papis pr-definidos. Os
principais papis so:
1. o ScrumMaster, que mantm os processos (normalmente no lugar de um gerente de
projeto) o Gerente Geral de TI assume o papel de ScrumMaster.
2. o Proprietrio do Produto, ou Product Owner, que representa os stakeholders e o negcio
o Lder de Equipe, Edenilso assume o papel de proprietrio de produto para a equipe de
desenvolvimento.
3. a Equipe de Desenvolvimento, o grupo multifuncional entre 3 a 9 pessoas e que fazem a
anlise, projeto, implementao, teste etc.

Papis principais
Os papis principais em equipes Scrum so aqueles comprometidos com o projeto no processo do
Scrum - so os que produzem o produto (objetivo do projeto).
Product Owner (dono do produto)
O Product Owner representa a voz do cliente e responsvel por garantir que a equipe
agregue valor ao negcio. O Product Owner escreve centrado nos itens do cliente (histrias
tipicamente do usurio), os prioriza e os adiciona para o product backlog. Equipes de Scrum
devem ter um Product Owner, e, embora esse possa tambm ser um membro da equipe de
desenvolvimento, recomenda-se que este papel no seja combinado com o de ScrumMaster.

Equipe de Desenvolvimento (Development Team)

A equipe de desenvolvimento responsvel pela entrega do produto. A equipe tipicamente
composta de 5-9 pessoas com habilidades multifuncionais que fazem o trabalho real (analisar,
projetar, desenvolver, testar tcnicas de comunicao, documentos, etc.) Recomenda-se que a
equipe seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma
forma de projeto ou gesto de equipe.

Scrum Master
Scrum facilitado por um Scrum Master, que responsvel pela remoo de impedimentos
capacidade da equipe para entregar o objetivo da sprint / entregas. O Scrum Master no o
lder da equipe, mas age como um tampo entre a equipe e qualquer influncia ou distrao. O
Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master
o responsvel pela aplicao das regras. Uma parte fundamental do papel do Scrum Master
proteger a equipe e mant-la focada nas tarefas em mos. O papel tambm tem sido referido
como um lder-servo para reforar essa dupla perspectiva.

Papis auxiliares
Os papis auxiliares em equipes Scrum so aqueles com nenhum papel formal e envolvimento
frequente no processo de Scrum, mas, ainda assim, devem ser levados em conta.
Partes interessadas (clientes, fornecedores)
Estas so as pessoas que permitem o projeto e para quem o projeto vai produzir o acordado
benefcio, que justifica a sua produo. Eles s esto diretamente envolvidos no processo
durante as revises sprint.
Gerentes (incluindo gerentes de projeto)
Pessoas que iro configurar o ambiente para desenvolvimento de produtos.

Artefatos
BACKLOG
Um backlog uma lista de itens priorizados a serem desenvolvidos para um software. Este artefato
a principal fonte de informao para o Planejamento de sprint (Sprint Planning). No decorrer da
sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe ir trabalhar. O
Product Owner mantm uma lista priorizada de itens de backlog, o backlog do produto, o que pode
ser repriorizado durante o planejamento da sprint. A Equipe seleciona itens do topo do backlog do
produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A
Equipe ento planeja a arquitetura e o design de como o backlog do produto pode ser
implementado. Os itens do backlog do produto so ento destrinchados em tarefas que se tornam o
backlog da sprint.

Product Backlog
O Product Backlog mantido pelo Product Owner e uma lista de requisitos que tipicamente vm
do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por
deciso deste.

Sprint Backlog
O Sprint Backlog uma lista de itens selecionados do Product backlog e contm tarefas concretas
que sero realizadas durante a prxima sprint para implementar tais itens selecionados.
O Sprint Backlog uma representao em tempo real do trabalho que o Development Team planeja
concluir na sprint corrente, e ele pertence unicamente ao Development Team.

Burndown Chart
O Burndown um simples grfico, com dois eixos X e Y, baseado nas atividades que no
ultrapassem um dia de trabalho. O eixo Y indica o nmero de tarefas existentes na sprint e o eixo X
os dias que representam o tamanho da sprint.

Reunies Scrum
Durante a sprint, temos reunies informais dirias de status do projeto entre os membros da equipe
na medida da necessidade identificada pelos membros da equipe. Cada um deve verificar
diariamente o que tem feito em direo meta; o que est planejando fazer no dia e se tem algum
problema impedindo de realizar seu objetivo em direo a meta e deve convocar reunio com os
membros envolvidos.

Reunio de Reviso da Sprint e de Planejamento de nova Sprint.

No incio do ciclo de sprint, a cada semana por padro, temos uma reunio com toda a equipe de
desenvolvimento. Todos refletem sobre a sprint passada para cada projeto. necessrio avaliar o
trabalho que foi concludo e no concludo. Quanto retrospectiva da sprint, devemos responder s
questes: (a) o que correu bem durante a corrida, (b) o que foi concludo e (c) o que pode ser
melhorado na prxima sprint.

A seguir, necessrio revisar e planejar: (a) o trabalho que est a ser feito; (b) o Sprint Backlog
que detalha o tempo que levar para fazer esse trabalho, com toda a equipe; (c) identificar e
comunicar o quanto o trabalho susceptvel de ser feito durante a sprint atual.