Gerenciamento de Projetos Ágeis

William LimaAvanti Agência Digital

– Fred Brooks (The Mythical Man-Month)

“- Como um projeto atrasa 2 anos?

- Um dia de cada vez!”

Scrum, O que é?

• Não é uma sigla para nada

• É o momento do jogo de Rugby quando a equipe está toda unida

com um único propósito em uma formação específica onde a

participação de todos é essencial, a falta de comprometimento de

um membro pode fazer a formação cair, então a união e o foco no

objetivo (mover a bola em direção ao gol) é primordial.

Scrum, O que é?

Em desenvolvimento de software é uma metodologia usada para uma

gestão dinâmica de projetos.

Um processo de desenvolvimento iterativo e incremental para

gerenciamento de projetos e desenvolvimento ágil de software.

É utilizado para trabalhos complexos nos quais é impossível predizer

tudo o que irá ocorrer.

Manifesto AgilO início do manifesto para desenvolvimento ágil de software se teve com um grupo de profissionais

e pesquisadores de TI com o objetivo de criar uma nova forma de melhor o desempenho de seus

projetos, surgindo então o seguinte manifesto:

"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos 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.”

Princípios

O manisfesto ágil traz doze princípios de um processo ágil:

• Nossa maior prioridade é satisfazer o cliente, através da entrega

adiantada e contínua de software de valor;

• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.

Processos ágeis se adequam a mudanças, para que o cliente possa

tirar vantagens competitivas;

• Entregar software funcionando com freqüencia, na escala de

semanas até meses, com preferência aos períodos mais curtos;

Princípios

• Pessoas relacionadas à negócios e desenvolvedores devem

trabalhar em conjunto e diáriamente, durante todo o curso do

projeto;

• Construir projetos ao redor de indivíduos motivados. Dando a eles o

ambiente e suporte necessário, e confiar que farão seu trabalho;

• O Método mais eficiente e eficaz de transmitir informações para, e

por dentro de um time de desenvolvimento, é através de uma

conversa cara a cara;

Princípios

• Software funcional é a medida primária de progresso;

• Processos ágeis promovem um ambiente sustentável. Os

patrocinadores, desenvolvedores e usuários, devem ser capazes de

manter indefinidamente, passos constantes;

• Contínua atenção à excelência técnica e bom design, aumenta a

agilidade;

Princípios

• Simplicidade: a arte de maximizar a quantidade de trabalho que não

precisou ser feito;

• As melhores arquiteturas, requisitos e designs emergem de times

auto-organizáveis;

• Em intervalos regulares, o time reflete em como ficar mais efetivo,

então, se ajustam e otimizam seu comportamento de acordo.

Características do Scrum

• Trabalha de forma iterativa e incremental

• As equipes são mutli-funcionais (cross-functional) e auto-

organizadas (self-organizing)

• Foca em prioridade: equipe sabe por onde começar e o que é mais

prioritário para o cliente

• Objetividade: metas menores (por sprints) atingíveis e claras.

Características do Scrum

• Visibilidade: clara visibilidade do que está completo e as pendências o

que reduz os riscos e as incertezas associadas ao projeto

• Aumento do ROI*: entregando funcionalidades antes para a validação

do cliente.

• Maior flexibilidade a agilidade: permite rever o planejamento, mudar de

direção ou fazer adaptações para as próximas iterações.

• Não há prática de engenharia prescrita (o Scrum adequa-se a todas)

*Retorno sobre investimento

Ciclo um projeto sem Scrum

Requerimento

Projeto

Implementação

Verificação

Manutenção

Ciclo de um projeto com Scrum

Requerimento

Projeto

Implementação

Verificação

Manutenção

N Vezes

Ciclo de Vida Scrum

O ciclo de vida do Scrum é baseado em três fases principais, divididas em subfases. Sãoo

estas o pré-planejamento, desenvolvimento e pós-planejamento.

• O pré-planejamento é a fase no qual são feitas estimativas de esforço para o

desenvolvimento de cada requisito, bem como a definição da equipe de desenvolvimento,

as ferramentas que serão utilizadas e a real necessidade de treinamento.

• Na segunda fase - denominada de desenvolvimento - são identificados previamente as

inúmeras variáveis técnicas e do ambiente para serem observadas e controladas durante o

desenvolvimento, aumentando assim a flexibilidade para acompanhar as mudanças.

• Por fim, na fase de pós-planejamento, são realizadas reuniões para analisar o progresso

do projeto e demonstrar o software atual para os clientes.

Ciclo de Vida ScrumQuer que eu desenhe?

O Framework Scrum

Ok, Ok, vamos por partes!

• Papéis e Responsabilidades

• Artefatos

• Cerimônias

Papéis e ResponsabilidadesProduct Owner - Scrum Master - Equipe/Time de Desenvolvimento

Product Owner• Encomenda o projeto e define os requisitos e as prioridades para

o produto.

• Representa o cliente ou um grupo deles.

• Define o produto.

• Conhecedor das necessidades do cliente.

• Organiza o backlog de produto.

• Cria as estórias de usuários.

• Tira duvida da equipe de desenvolvimento.

• Aceita ou não o incremento.

Scrum Master

• Deve ser um dos membros da equipe de

trabalho.

• Tem a responsabilidade de orientar o time

para que sejam atendidos os valores e as

práticas do Scrum.

• Participa ativamente das reuniões propostas.

• Assegura o entendimento do Scrum.

• Remove conflitos e impedimentos.

• Imparcial / Neutro.

Time/Equipe de Desenvolvimento

• Uma equipe Scrum tem tipicamente de 6 a 9

membros úteis.

• Caso haja mais membros do que o

administrável, o projeto deve ser dividido em

vários sub-projetos.

• Os membros do time são responsáveis por

negociar com o PO os requisitos que serão

trabalhados em cada Sprint.

• Trabalham nas produtividades definidas

pelo PO.

Product Owner - Scrum Master - Time de Desenvolvedores

Em resumo é isso!

Artefatos do ScrumVisão - Estórias - Backlog: Product Backlog / Sprint Backlog - Burndown -

Taskboard / Kanban

Visão

Todo Produto necessita de uma visão,

um objetivo, uma meta. A visão do

produto nos faz parar e pensar, porque

vamos construir este software? Qual o

real propósito deste trabalho que será

realizado?

Começar o projeto pelo Product

Backlog sem a visão é como fazer

compras com fome. Tudo parece uma

boa idéia, uma boa funcionalidade.

Estórias

É um descritivo claro e objetivo, porém

resumido, da funcionalidade que será

desenvolvida.

Muitas vezes uma estória cabe em um

post-it por conta da sua objetividade;

Backlog

É a lista de requisitos da aplicação que

será necessária para o seu

entendimento e desenvolvimento. O

responsável por ela é o Product Owner.

O backlog é dividido em duas partes

sendo elas o Product Backlog e o Sprint

Backlog.

Product Backlog

O product backlog é uma lista de tudo o

que possa ser necessário no produto, e

é a única fonte de requisitos para que

sejam feitas alterações no produto.

Nessa lista contém todas as

funcionalidades - que são visíveis ao

cliente - e também requisitos técnicos

para poder desenvolver o produto onde

os itens da lista devem estar definidos

em 10 dias para iniciar o

desenvolvimento.

Sprint Backlog

O sprint backlog é uma lista de tarefas

identificadas pela equipe de Scrum para ser

concluída durante o sprint.

Durante a reunião de planejamento do

sprint, a equipe seleciona um determinado

número de itens do product backlog,

geralmente sob a forma de histórias de

usuários, e identifica as tarefas necessárias

para que estas seja completadas.

A maioria das equipes também estimam

quantas horas cada tarefa vai levar para ser

concluída.

Gráfico de Brundown

É um gráfico que mostra a linha de

esforço frente aos trabalhos que

precisam ser realizados.

Os eixos que forma esse gráfico

analisam a quantidade de trabalho a ser

completado (eixo y) e as datas ou dias

de execução (eixo x).

O Burndown, assim como o Backlog,

também é divido em duas partes, um

gráfico para o Produto e outro para o

Sprint.

Taskboard - Kanban

É uma espécie de quadro onde cada

estória é colada, a partir dele dá para

saber quais atividades ainda estão na

fila de desenvolvimento, quais foram

feitas e quais estão sendo

desenvolvidas.

Utilizando-o dá para se ter uma visão

geral em poucos segundos de como o

projeto está.

Pode ser utilizado com tarefas no lugar

de estórias.

Cerimonias ScrumRelease Planning - Sprint Planning - Daily Scrum - Sprint Review -

Retrospectiva do Sprint

Release Planning

No início de um projeto o time criará um Release Plan em alto nível.

Não é possível que o time conheça tudo no início, portanto, um plano

detalhado não é necessário.

Esta reunião está a cargo do Time de Desenvolvimento, deve ter a

participação ativa do Scrum Master e Product Owner.

Release Planning

O Release Plan deverá abordar:

• A quantidade e a duração dos Sprints

• Quantas pessoas ou times deverão participar do projeto

• O número de Releases

• O valor a ser entregue em cada Release

• A data de liberação do(s) Release(s)

Release Planning

As principais informações para o Release Planning são:

• A priorização dos Product Backlogs

• A estimativa da velocidade

• O Product Owner deve atender as datas importantes (time-to-

market) impostas pelo mercado.

Sprint Planning

A reunião Sprint Planning é realizada com a presença do Product Owner, Scrum Master e de todo Scrum

Team, e quaisquer interessados, diretores ou representantes do cliente.

Durante a reunião Sprint Planning, o Product Owner explica as funcionalidades de maior prioridade para o

Scrum Team. Durante esta reunião o Scrum Team faz perguntas que sejam suficientes para que eles

possam, depois da reunião, definir quais atividades eles irão mover do Product Backlog para o Sprint

Backlog.

Juntos, o Scrum Team e o Product Owner definem um objetivo para o Sprint (Sprint Goal), que é uma breve

descrição do que pretende-se atingir no Sprint. O sucesso do Sprint será verificado posteriormente durante a

reunião Sprint Review, baseado no Sprint Goal em vez de em itens específicos do Sprint Backlog.

Depois da reunião Sprint Planning, o Scrum Team reune-se separadamente para discutir o que foi dito e

decidir o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá

negociações com o Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles

podem se comprometer.

Sprint Planning

• É definido o objetivo do sprint.

• A lista de membros da equipe (e seus níveis de comprometimento, se não

100%) – capacidade da equipe.

• O sprint backlog uma lista de atividades que deverão ser executadas para

concluir cada item do backlog (estória ou caso de uso).

• Estimativas para cada item/atividade do sprint backlog.

• Uma data definida para a apresentação do sprint.

• Data e local definidos para a reunião diária.

Daily ScrumTodos os dias do Sprint, o Scrum Team realiza reuniões diárias. Essas reuniões geralmente são realizadas no

mesmo local e horário todos os dias. O ideal é que as Reuniões de Daily Scrum sejam realizadas pela manhã, uma

vez que ela apoia a determinar as atividades do dia.

Todos os membros do time devem participar da Reunião de Daily Scrum. Outras pessoas (por exemplo, a gerência

de um departamento, um vendendor ou um desenvolvedor de outro projeto) podem estar presentes, mas apenas

como ouvintes. Isso torna as Reuniões de Daily Scrum uma excelente forma do Scrum Team comunicar a situação

atual - se você está interessado em saber em que ponto o projeto está, frequente esta reunião diária.

A Reunião de Daily Scrum não é uma reunião usada para solucionar problemas ou dúvidas. As dúvidas que

surgirem deverão ser postergadas e, de modo geral, serem tratadas pelo grupo envolvido imediatamente após a

Reunião de Daily Scrum. Durante a reunião, cada membro do Scrum Team responde às seguintes perguntas:

1. O que você fez ontem?

2. O que você vai fazer hoje?

3. Existe algum impedimento?

Daily ScrumO Scrum Master é responsável por solucionar quaisquer impedimentos identificados o mais

rapidamente possível. Geralmente são impedimentos:

• Meu _____ quebrou e eu preciso de um novo hoje.

• Eu ainda não recebi o software que pedi um mês atrás.

• Eu preciso ajudar ao(à) ________ a depurar um problema.

• Eu estou me esforçando para aprender ________ e gostaria de fazer isto em par com alguém.

• Não consigo retorno da equipe de suporte técnico do fornecedor.

• O grupo _______ não tem tempo para se reunir comigo.

• O diretor da área me pediu para trabalhar em outra coisa por um dia ou dois.

Sprint ReviewAo final de cada Sprint, uma Reunião Sprint Review é realizada. Durante esta reunião, o

Scrum Team apresenta o que foi realizado durante o Sprint. Tipicamente, esta

apresentação é feita na forma de uma demonstração das novas funcionalidades.

Participantes da Reunião Sprint Review, tipicamente inclui o Product Owner, o Scrum

Team, o Scrum Master, a diretoria, clientes e engenheiros de outros projetos.

Durante a Reunião Sprint Review o projeto é avalidado baseado no Sprint Goal,

determinado durante a Reunião Sprint Planning. O ideal é que a equipe tenha concluído

todos os itens do Product Backlog alocados para o Sprint, mas é mais importante que

eles alcancem Sprint Goal.

Força a equipe a realmente terminar as coisas e liberá-las (mesmo que seja apenas em

um ambiente de teste)

RetrospectivaÉ a reunião de lições aprendidas (Lessons Learned) – o que podemos fazer melhor no próximo

sprint?

O ScrumMaster se reúne 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.

• Bom: se pudéssemos faríamos do mesmo modo;

• Poderia ter sido melhor: faríamos tal item de maneira diferente;

• Melhorias: idéias concretas de como melhorar o processo / ferramentas, etc no próximo sprint.

Ciclo de Vida ScrumE agora? Entendeu?

Referências

• https://www.scrumalliance.org/

• http://www.codeproject.com/Articles/4798/What-is-SCRUM

• http://unifenas.br

• https://www.scrum.org/Scrum-Guide

• http://scrummethodology.com/