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: [email protected]
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:
Exercícios