Parte II Processos ágeis

PARTE IIPROCESSOS ÁGEIS

Agile Alliance - Disponível em: <www.agilealliance.org>. Acesso em: 04 abr. 2012.

Imaster – Disponível em: http://imasters.com.br/artigo/7240/gerencia-de-ti/gerenciamento-de-projetos-web-vamos-de-scrum . Acesso em: 09 abr. 2012.

PHAM, Andrew; PHAM, Phuong-van. Scrum em Ação: Gerenciamento e Desenvolvimento Ágil de Projetos de Sofware. São Paulo: Novatec, 2011. 287 p.

Scrum Alliance – Disponível em: www.scrumalliance.org/. Acesso em: 15 mar. 2012.

Scrum – Disponível em : http://www.scrum.org/storage/Scrum%20Guide%202011%20-%20PTBR.pdf. Acesso em: 02 abr. 2012.

Mountain Goat Software – Disponível em www.mountaingoatsoftware.com. Acesso em: 10 mar. 2012.

Referências

Parte II - Processos Ágeis◦ Metodologias Tradicionais◦ Manifesto Ágil

Parte III - Scrum◦ Histórias conhecidas◦ Projetos fracassados◦ Problemas de práticas prescritivas◦ Onde queremos chegar◦ História do Scrum◦ Papéis do Scrum

PO - Product Owner SM - Scrum Master TM - Team Members

◦ Histórias

Roteiro

◦ Histórias◦ Product Backlog◦ Sprint◦ Sprint Backlog◦ Tarefas da Sprint◦ Impedimentos das tarefas◦ Sprint Burndown◦ Quando uma Sprint é cancelada◦ Cerimônias ou reuniões Scrum

Planejamento da Sprint Reuniões diárias Revisão da Sprint

◦ Quado de Kanban◦ Ciclo de vida do Scrum◦ Estimativas e entregas◦ Exercícios

Roteiro (continuação)

Modelo Constrói e Conserta (caótico)

Metodologias Tradicionais

Modelo Cascata

Metodologias Tradicionais (continuação)

Modelo Cascata

◦ Etapas sequenciais

◦ Modelo inflexível

◦ Cliente só valida o que foi desenvolvido no final do processo

◦ Dificuldade para implementar alterações

◦ Famoso Big Bang

Metodologias Tradicionais (continuação)

Modelo Espiral

Metodologias Tradicionais (continuação)

Modelo Espiral

◦ Software dividido em versões chamados de incremento

◦ Cliente acompanho o desenvolvimento

◦ Maior facilidade para alterações

◦ Assim como o cascata não permite etapas em paralelo

Metodologias Tradicionais (continuação)

Modelo Iterativo e Incremental

Metodologias Tradicionais (continuação)

Modelo Iterativo e Incremental

◦ Ciclo de vida iterativo, baseado no aumento e no refinamento sucessivo de um sistema por meio de multiplos ciclos de desenvolvimento.

◦ Atualmente o modelo mais utilizado.

◦ Redução de riscos, custos e prazos.

◦ Equipe focada com os objetivos de cada incremento.

Metodologias Tradicionais (continuação)

Nível típico de custos e de pessoal do projeto ao longo do seu ciclo de vida

Metodologias Tradicionais (continuação)

Influência das partes interessadas ao longo do tempo

Metodologias Tradicionais (continuação)

Seqüência típica de fases no ciclo de vida de um projeto

Metodologias Tradicionais (continuação)

Relação entre o produto e os ciclos de vida do projeto

Ciclo de Vida (continuação)

Exemplo de ciclo de vida

Promovem o desenvolvimento de trabalho em equipe.

Colaboração.

Adaptabilidade durante o ciclo de vida do projeto.

Software dividido em versões (Iterativo e Incremental) realizados de 1 a 4 semanas, passando por todas as etapas.

Minimiza os erros, pois cada versão é validada.

Processos Ágeis

Comunicação cara a cara, todos trabalhando na mesma sala.

Representante do cliente sempre presente nas reuniões esclarecendo dúvidas que podem surgir durante as iterações.

Processos Ágeis (continuação)

Necessidade de resultados rápidos e precisos.

Fortalecimento da metodologia ágil.

Aliança Ágil -2001◦ Ler:

http://hp.br.inter.net/jrotta/docs/omanifestoagil.pdf

http://manifestoagil.com.br/

Manifesto Ágil

“Estamos descobrindo maneira 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ções 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ça mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens a direita, valorizamos mais os itens à esquerda.”

Manifesto Ágil (contínuação)

http://manifestoagil.com.br/principios.html

12 Princípios do processo ágil

Extreme Programming (XP)

Scrum

Feature Driven Development (FDD)

Dynamic Systems Development Method (DSDM)

Exemplo de Processos Ágeis

Agileplatform - http://www.outsystems.com/

VisionProject - http://www.visionproject.se/

Pivotaltracker - http://www.pivotaltracker.com/

TargetProcess - http://www.targetprocess.com/

Algumas ferramentas que suportam Metodologia Ágil

PARTE III

http://www.scrumalliance.org/

http://www.scrumalliance.org/user_groups/19

http://www.implementingscrum.com/

http://pt.wikipedia.org/wiki/Scrum

http://www.scrumalliance.org/scrum_certification

Scrum

Atraso em projetos Mudança frequente de escopo Falta de funcionalidades na entrega Custos elevados Clientes insatisfeitos Falta de cooperação da equipe Síndrome do estudante Equipe desmotivada Funcionalidades demais, uso de menos

Histórias conhecidas

Segundo PMI Brasil, os problemas mais freqüentes em gerenciamento de projetos levantados são:

◦ Não cumprimento de prazos (72%)

◦ Problemas de comunicação (71%)

◦ Mudança de escopo (69%)

◦ Estimativa errada de prazo (66%)

Problemas

67%

33%

O destino dos projetos

São entregue com atraso ou suspensoSão entregues no prazo, no custo e de acordo com o que foi pedido

Projetos fracassados

Fonte Carlos Junior - DevCursos

65%

15%

20%

Dos 33%

Vão para o lixoSão parcialmente us-adosSão usados apro-priadamente

Fonte Carlos Junior - DevCursos

Projetos fracassados (continuação)

45%

7%

13%

16%

19%

Uso das funcionalidades

NuncaSempreFrequentementeAs vezesRaramente

Fonte Carlos Junior - DevCursos

Projetos fracassados (continuação)

Falta de envolvimento do usuário

Requisitos e especificações incompletas

Falta de suporte da direção

Falta de pessoas e recursos

Fracasso, porquê?

Práticas prescritivas tornou evidente que:

◦ Os detalhes são complexos para as pessoas

◦ Os clientes ou usuários não tem certeza do que eles querem

◦ Eles tem dificuldades de expressar tudo o que querem e pensam

Problemas de práticas prescritivas

Práticas prescritivas tornou evidente que:

◦ Muitos detalhes dos que ele querem só serão revelados durante o desenvolvimento

◦ Na medida em que eles veem o produto sendo construído, mudam de idéia

◦ Forças externas (como um produto ou serviço da concorrência) trazem mudanças ou melhorias nos requisitos

Problemas de práticas prescritivas

Precisamos rever nossos conceitos!!!

Onde queremos chegar? Aumento da produtividade.

Melhor qualidade.

Equipe motivada.

Entrega rápida do produto.

Aumento da satisfação do cliente.

Viabilizar inovação.

Foco no retorno de investimento (ROI).

Surgiu em 1986.

Em 1986 Ikujiro Nonaka e Irotaka Takeuchi escreverão um artigo afirmando que equipes pequenas e com baixo nível de especialização tem melhores resultado que equipes grandes.

O nome Scrum vem do Rugby, quando uma falta é cometida os jogadores se arranjão em uma forma coesa chamada “Scrum”

História do Scrum

Iterativo e Incremental.

Framework que facilita a visualização de problemas mesmo que possuem dificuldade elevada.

Tem por objetivo agregar o máximo de valor ao negócio com o menor tempo possível focando no retorno de investimento (ROI).

Scrum (continuação)

Quem utiliza Scrum

PO - Product Owner

SM - Scrum Master

TM – Team Members

Papéis do Scrum

Papéis do Scrum

Responsável pela definição do escopo do projeto.

É ele quem estabelece e comunica a visão do produto e prioriza cada uma de suas funcionalidades

Define o que é necessário e qual a importância de cada uma das funcionalidades.

PO - Product Owner

Garante o ROI

◦ índice que expressa o quanto determinada funcionalidade irá retornar ao cliente quando implementada no produto final. Através do ROI o PO pode priorizar o projeto de maneira a ter o maior retorno em menor tempo.

PO - Product Owner (contiuação)

Especificar quais são as funcionalidades esperadas no produto e priorizá-las por ROI.

Estabelecer uma visão compartilhada do produto entre clientes e desenvolvedores.

Definir datas para lançamentos e entregas.

Age como mediador quando o produto deve atender a vários clientes.

Pode dispor de uma equipe de apoio para auxiliar na geração da documentação (artefatos).

Product Owner (continuação)

Um membro extra do time que participa das reuniões de Sprint Planning e Sprint Review.

Tipicamente, alguém do Marketing ou um usuário chave em desenvolvimentos internos.

Pode ser um representante do cliente ou um procurador do cliente.

Quem pode ser um PO?

É a glândula pineal de um time Scrum.

Regulador do ritmo do desenvolvimento.

Facilitador das reuniões.

SM - Scrum Master

Faz com que a equipe viva os valores e práticas de Scrum

Protege a equipe de:◦ Riscos e interferências externas◦ Excesso de otimismo

Resolve os problemas que aparecerem◦ Logísticos◦ De conhecimento/habilidade

Também ajuda o PO a manter o Product Backlog

SM – Scrum Master (continuação)

Monitorar o progresso do projeto.

Garantir que impedimentos ao progresso sejam resolvidos.

Remover a barreira entre desenvolvimento e cliente.

Melhorar o dia-a-dia do time facilitando a criatividade e o fortalecimento.

SM – Scrum Master (continuação)

Mantém o Backlog do Sprint◦ Tarefas completadas◦ Identifica eventuais problemas

Mantém um gráfico de “quanto falta”.

SM – Scrum Master (continuação)

O papel ScrumMaster é, normalmente, exercido por um gerente de projetos ou um líder técnico, mas pode ser desempenhado por qualquer um.

Quem pode ser um SM?

Responsável em desenvolver o produto

Equipes auto organizadas e multidisciplinares (trabalho colaborativo)

Promover a colaboração como a principal ferramenta de trabalho

TM – Team Members

Se adequar ao ritmo de trabalho necessário para finalizar um incremento previsto.

Participar das reuniões do Scrum e defender suas ideias de estimativas e possibilidades.

Auto gerenciar suas tarefas para cumprir a previsão.

Adereçar seus impedimentos ao SM.

TM – Team Members (continuação)

Sem nível hierárquico nem papéis◦ Mas com várias especialidades

Estão todos no mesmo barco

Geralmente equipes pequenas (até 10)◦ Existem casos com equipes maiores (800)◦ Usa-se também Scrum hierárquico

Comunicação é essencial◦ Encontro Scrum diário

TM – Team Members (continuação)

Não basta ser uma equipe, é preciso ser um time.

TM – Team Members (continuação)

Projeto sem Gerente?

É só uma troca◦ A gerência passa a ser descentralizada ou

distribuída.

◦ Troca-se o papel tradicional de gerente por Grupo de Gerência Light + a Equipe Auto Organizada.

Cadê o Gerente ou a Gerência???

Uma história possui 3 componentes básicos:◦ Ator

A visão é sempre do ator

O Ator exerce um papel Pessoa ou sistema Ex: Como gerente do hotel eu quero....

◦ Objetivo◦ Justificativa

Histórias no Scrum

Uma história possui 3 componentes básicos:

◦ Objetivo O que o usuário quer fazer? Qual o problema a ser resolvido? Como deve ser o comportamento do sistema nessa

história? Qual o resultado final da história?

EX: ....saber que clientes estão hospedados há mais de 30 dias para, caso deseje, cobrar as estadias vencidas.

História no Scrum (continuação)

Uma história possui 3 componentes básicos:

◦ Justificativa Por que a história é necessária? Provê uma visão abrangente do problema. Facilita o entendimento da equipe. Fornece mais informações sobre a história A justificativa é opcional Ex: ... Reduzindo o custo de inadimplência

História no Scrum (continuação)

Como gerente do hotel eu quero... saber que clientes estão hospedados há mais de 30 dias para, caso deseje,

cobrar as estadias vencidas.... seduzindo o risco de inadimplência.

História – Exemplo

Independente Flexível Agrega valor ao usuário Estimável Realizável em uma Sprint Testável

O conjunto de histórias irão formar o Product Backlog

História – Características

Lista de necessidades do Cliente

Conjunto de histórias que darão origem ao produto

Ordenado por prioridade de implementação◦ Responsabilidade do PO.

Evolui com o produto e a dinâmica do ambiente

Product Backlog

Características da Histórias:

◦ Descreve funcionalidades que devem gerar valor para o cliente.

◦ Necessidades do cliente.

◦ Vale como requisitos.

◦ Como se fosse um caso de uso.

◦ PO indica o valor agregado

Product Backlog (continuação)

Características da Histórias:

◦ Realizável em uma Sprint.

◦ Testável ao final do desenvolvimento.

Product Backlog (continuação)

Os participantes devem ser convidados com antecedência.

Na sala de reuniões deixar disponível para todos os presentes etiquetas coloridas colantes (post-it’s), papel e canetas.

O objetivo da reunião é fazer com que todos os envolvidos passem a ter conhecimento do projeto.

Executando o Product Backlog

Exemplo de Product BacklogSistema Web de streaming de vídeo

ITEM DESCRIÇÃO TAMANHO ROI STATUS

ES006 REGISTRO DE IMÓVEIS EM

DÉBITO

8 ALTO A FAZER

ES002 EMITIR BOLETO DE COBRANÇA

5 MÉDIO A FAZER

ES005 ALTERAR CORES DO SISTEMA

5 BAIXO A FAZER

ES001 ...

Exemplo de Product Backlog (continuação)

OBS: O Product Backlog deve ser atualizado constantemente pelo Product Owner

Ciclo de vida do Scrum

Iterações para a implementação das histórias/tarefas.

Normalmente 15 a 30 dias.

Membros da equipe vão pegando as tarefas e as realizando

SM facilita o trabalho da equipe

Sprint

Pode ser necessário tirar dúvidas com o PO ou com especialistas.

IMPORTANTE – Durante a Sprint não mudar nada.

O Scrum permite incluir algumas histórias durante a Sprint, mas isso não é recomendado.

Dentro da Sprint é criado o Sprint Backlog através da reunião de planejamento.

Sprint (continuação)

Conjunto de histórias oriundas do PB, selecionadas para serem comtempladas em uma Sprint.

Seleção é feita pela ordenação do PB e de acordo com a velocidade do time.

As histórias devem ser trabalhadas por prioridade.

Sprint Backlog

Exemplo Sprint Backlog

Atividades a serem realizadas para implementação de uma história.

Deve consumir de um a dois dias de trabalho de um membro da equipe.

Exemplo de tarefas:◦ Construir uma base de dados◦ Montar uma interface◦ Desenhar um botão

Tarefas da Sprint

Algum fator externo está impedindo a continuação de alguma tarefa.◦ Exemplo:

dependência de algum produto contratado de um fornecedor.

Algum software para executar um trabalho.

O SM é responsável por resolver os impedimentos.

Impedimentos das tarefas

Ciclo de vida do Scrum

Acompanhamento do trabalho da equipe

Eixo horizontal – dias da Sprint

Eixo vertical – horas (tarefas) ou pontos (histórias)

Se o trabalho da equipe estiver abaixo da linha padrão a equipe está andando rápido demais ao contrário esta atrasada

Sprint Burndown

Exemplo - Sprint Burndown

Sprint Burndown

Somente o PO pode cancelar uma Sprint.

Casa o Sprint se tornar obsoleta.

Isso pode ocorrer se empresa mudar a direção ou se as condições de mercado ou tecnologia mudarem.

Mas, dada a curta duração do Sprint, o cancelamento raramente faz sentido.

Quando uma Sprint é cancelada

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.

Cerimônias ou Encontro Scrum

O quê vai ser feito?◦ Qual necessidade do cliente vai ser atendido?

PO inicia a reunião fazendo uma proposta da Meta da Sprint.

Explicação pelo PO das histórias prioritárias do Product Backlog para equipe.

Planning Poker◦ Estimar o valor de cada uma das histórias

Planejamento do Sprint

Sprint 30 dias – 4 horas.

Sprint 15 dias – 2 horas.

A equipe decide o quanto que conseguirá fazer na Sprint.

Definição da META da Sprint.

Planejamento do Sprint (continuação)

Planejamento do Sprint (continuação)

Reunião de Planejamento da Sprint

Meta da Sprint

Sprint Backlog

Product Backlog

Competências da Equipe

Condições de Negócio

Tecnologia

Produto Atual

Gerência

◦ As histórias selecionadas no Product Backlog são explodidas em tarefas.

◦ As tarefas identificadas constituem o Sprint Backlog.

◦ Se a equipe desejar as tarefas podem receber estimativas em horas.

Planejamento do Sprint (continuação)

Outros convidados podem ser convidados para esclarecer o domínio ou ajudar na parte técnica.

Ao final, tarefas bem definidas e entendidas.

O planejamento das Sprints por ser dividido em 2 ou mais reuniões.

Planejamento do Sprint (continuação)

Ciclo de vida do Scrum

Encontro de toda a equipe.

Face a face.

15 minutos.

Em pé.

Discute-se o trabalho apenas.

Reuniões diárias do Scrum

O que fiz? O que pretendo fazer? Impedimentos?

Não é reunião para discussões técnicas.

Serve para que todos saibam o que está acontecendo e se coordenem.

O PO só participa se necessário como visitante.

A reunião é conduzida pela equipe com o SM.

Reuniões diárias do Scrum (continuação)

Time de desenvolvimento apresenta o resultado da Sprint para o PO, para a sua aprovação.

O PO aprova as histórias que entender que foram satisfeitas

Muito importante de definição de PRONTO.

Caso o PO não aceite, a história é recusada e vai voltar para o product backlog para ser novamente priorizável.

Revisão da Sprint

PO informa se a meta da Sprint foi ou não atingida.

Prestação de contas – transparência.

Gera subsídio para reunião de planejamento da próxima Sprint.

Sprint = 30 dias -> 4 horas

Sprint = 15 dias -> 2 horas

Revisão da Sprint (continuação)

Nessa reunião a equipe muitas vezes vai utilizar um recurso que é o Quadro de Tarefas herdado do Kanban.

A equipe passa as tarefas entre as colunas.

Reuniões diárias do Scrum (continuação)

Quadro de Tarefas herdado do Kanban

Quadro de Tarefas herdado do Kanban

Quadro de Tarefas herdado do Kanban

Exemplo de quadro do Scrum

Ciclo de vida do Scrum

Técnica para estimar histórias.

Equipe trabalha na estimação com a ajuda do SM.

Usa-se cartas com pontuação baseada na série de Fibonacci (0, 1, 2, 3, 5, 8, 13).

Para cada história a equipe, após discutir o problema, joga a carta que acredita representar o esforço necessário para desenvolver a história.

Caso não haja concordância, discutir mais e jogar de novo.

A estimativa deve ser encontrada por unanimidade.

Planning Poker

O uso do Planning Poker reforça fortemente o conceito de colaboração e comprometimento.

O grupe se reúne geralmente na reunião Sprint Planning e esclarece as histórias com o PO para depois estimar uma a uma.

Fazer a leitura do artigo:◦ http://www.ramonduraes.net/2011/05/19/o-efeito-

da-tecnica-planning-poker-na-pratica/

Planning Poker (continuação)

Exemplo de pontos contados

Baseados nos pontos, as histórias são incluídas em uma Sprint baseadas na velocidade da equipe.

Velocidade indica o quanto o time consegue fazer numa Sprint.

Normalmente medida em pontos.

Na primeira Sprint é um “chute”... Ao longo do desenvolvimento estabiliza.

Usada para o planejamento das Sprints

Pode ser usada para o planejamento de Releases (Entregas)

Velocidade da Equipe

Versão do Produto pronto para ser utilizada.

Normalmente compreende várias sprints.

Releases/Entregas

Pronto

Brazip Scrum

Scrumhalf

FireScrum

Scrumrf

IceSrum

Outros: http://www.gestaoetc.com.br/64/softwares-para-o-gerenciamento-de-projetos-ageis-tais-como-o-scrum/

Sistemas para gerenciamento Scrum

Pesquisar e apresentar uma ferramenta para acompanhamento de projeto Scrum.

A pesquisa deve comtemplar:◦ Característica da ferramenta (Pós e contras)◦ Instalação/Plataforma necessária◦ Forma de distribuição (freeware, demo, etc)◦ Entre outras

Exercícios

Conforme o Scrum, quais seriam as vantagens e desvantagens em utiliza-lo em um projeto Web.

◦ Enviar resposta para: frufrek@utfpr.edu.br

Exercícios

Como podemos gerenciar riscos dentro do Scrum utilizando o PMBOK?

◦ Pesquisar a respeito◦ Discussão em sala◦ Enviar o trabalho para o email:

frufrek@utfpr.edu.br

Exercícios