O Triunfo da Toyota (Revista Epoca)

Oi pessoal,

Segue o link da reportagem da revista Epoca sobre o modelo de negocio da empresa Toyota.

Este modelo deu origem ao que nos chamamos na área de informática de: "Lean Software"

Link do texto: http://epocanegocios.globo.com/Revista/Epocanegocios/0,,EDG76927-8382-2,00.html

(Passo 22) Fim do Projeto

“Parabéns” fim do projeto.

(Passo 21) Se existe outro Sprint volte para o (Passo 9)

Chegamos ao termino do nosso Sprint, caso exista um próximo Sprint a ser executado vamos iniciar todo o nosso planejamento e execução do mesmo.
Se não termos mais Sprints a serem realizados chegamos ao fim do nosso projeto.

(Passo 20) Atualizar Product Burndown chart

(Passo 19) Atualizar Release Burndown chart

(Passo 18) Sprint Retrospective

A reunião de retrospectiva do Sprint é realizada no fim de cada Sprint, após a reunião da revisão do Sprint. A equipe e o ScrumMaster realizam uma reunião para avaliação das coisas boas e ruins da Sprint que foi realizada. O Product Owner não assiste esta reunião.
A reunião de retrospectiva deve ter um tempo aproximada de 3 horas. Esta reunião é importante para revisão e melhoria do processo.

(Passo 17) Sprint Review

1 - Equipe apresenta os resultados obtidos durante o Sprint
2 - Informal
2.1 - 2 horas de apresentação
3 - Todo o time participa
4 - Todas as pessoas são convidadas

(Passo 16) Atualizar o Sprint Burndown Chart

(Passo 15) Jogue o dado e descubra quantas tarefas foram realizadas

Vamos descobrir quantas tarefas foram realizadas, isto é, implementadas pela equipe de desenvolvimento.

(Passo 14) Equipe escolhe as Tarefas

Uma tarefa é uma das funcionalidades existentes no nosso Backlog, neste caso, o Backlog da Sprint, e que tem um tempo estimado de 4 a 16 horas. Quem determina quais as tarefas irão ser executadas pelos membros da equipe é a própria equipe. Conforme a execução das tarefas a equipe vai atualizando os controles de tempo restante para o termino da tarefa no Burndown do Sprint.

(Passo 13) Reunião de Dally

É uma reunião diária de acompanhamento de execução do projeto realizada pela equipe. Nesta reunião participa com direito a falar apenas os denominados “porcos”, “frangos” podem participar, mas não tem direito a falar nesta reunião.
Esta reunião deve ter no maximo 15 minutos de duração e deve ser conduzida pelo “ScrumMaster”. Recomenda-se que esta reunião seja realizada no período matutino, bem no inicio das atividades da equipe. Também recomenda-se que os participantes fiquem de pé. Esta reunião não é para solução de problemas e sim de sincronismo entre os membros da equipe de como esta indo a execução das atividades realizadas no “Sprint”.
O ScrumMaster deve realizar três perguntas a equipe:
1 – O que fiz desde a ultima reunião?
2 – O que farei ate a próxima reunião?
3 – Existe algum obstáculo (Impedimento)?

Impedimento
--------------------
Impedimento é qualquer coisa que atrapalhe um membro da equipe de executar o trabalho. Os impedimentos podem ser identificados nas reuniões diárias, onde cada membro da equipe tem a oportunidade de comunicar o ScrumMaster do impedimento existente. O ScrumMaster é responsável pela solução dos impedimentos. O ScrumMaster pode realizar reuniões complementares para solucionar os impedimentos identificados quando as reuniões diárias não permitirem a solução.

(Complemento) Execução da Sprint

O “Sprint Gols” são o resultado de uma negociação entre o Product Owner e a equipe de desenvolvimento.
Scrum faz o seu foco na entrega de um produto de demonstração, mesmo que este produto tenha poucas funcionalidades e problemas de requisitos não funcionais que ainda não foram implementados. O Product Owner sabe que ele terá este produto de demonstração já disponível ao termino do primeiro Sprint. Devemos lembrar que no desenvolvimento iterativo, as próximas Sprint´s podem aumentar a robustez ou o tamanho do produto de demonstração com a execução das funcionalidades existentes nos próximos Sprint´s.
A equipe deve estar comprometida com o acordo realizado com o Product Owner e no fim do Sprint deve ser realizado uma reunião de revisão da Sprint.
Todos as funcionalidades acordadas com a entrega no Sprint devem ser realizadas, mas caso não seja possível o Product Owner tem que ser informado no momento que foi identificado a impossibilidade do acordo firmado ser realizado. A não entrega de todas funcionalidades acordadas no inicio de cada Sprint não pode vir a se tornar uma rotina, isto é, ela deve ser evitada.

(Passo 12) Montar Sprint Burndown Chart

Um “Sprint Burndown Chart” é um gráfico com as informações referentes a execução do Sprint. O eixo X mostra os dias de trabalho do Sprint e o eixo Y mostra a quantidade de esforço necessária para terminar a Sprint. A representação do esforço necessário pode ser em horas reais de trabalho.
Este gráfico mostra a execução indo de cima para baixo com relação ao esforço necessário de execução e da esquerda para direita com relação aos dias de trabalho.

(Passo 11) Quebrar Sprint Backlog em Tarefas e Estimar o Tempo

“Product Backlog Item Effort” é a estimativa de tempo necessário para a realização de um item do Backlog.
Alguns praticantes de Scrum preferem estimar o esforço por dias de trabalho, mas outros preferem fazer estimativa utilizando unidade de medidas menores que um dia. Um exemplo é o uso de pontos de cartão de historia, pontos de função, “t-shirt”, etc.

(Passo 10) Reunião de Planejamento do Sprint (Sprint Planning Meeting)

A reunião de planejamento do Sprint é uma negociação entre a equipe e o Product Owner sobre o que a equipe fará de execução de funcionalidades durante a próxima Sprint.
Nesta reunião é definido as funcionalidades que entram na Sprint e as que ficam fora, conforme a priorização do Product Owner.
O tempo necessário para esta reunião é de aproximadamente 4 horas.
1 - Product Owner seleciona itens do Product Backlog
2 - Sprint Backlog é criado
2.1 - Tarefas identificadas e estimadas (1 a 16 horas)
2.2 - De forma coletiva e não apenas feito pelo ScrumMaster
2.3 - Equipe compromete-se a concluir as tarefas

(Passo 9) Distribuir Itens do Backlog por Sprint

Em Scrum, um item do produto Backlog (“PBI”, “Backlog item”, ou “item”) é uma unidade de trabalho a ser realizada pela equipe em uma execução de “Sprint”. Um item de Backlog é decomposto em uma ou mais tarefas.
O Sprint Backlog é a relação de funcionalidades que devem ser realizadas em uma iteração, isto é, um Sprint.
1 - Cada indivíduo escolhe o trabalho que fará
1.1 - Trabalhos nunca são atribuídos
2 - Atualização diária da estimativa do trabalho restante
3 - Qualquer membro da equipe pode: adicionar, apagar ou mudar tarefas
4 - Atualize as coisas a serem feitas na medida em que se tornam mais conhecidas
Nesta tarefa temos que pegar os Itens de Backlog e distribuir por Sprint, respeitando a priorização do Product Owner.

(Passo 8) Montar Release Burndown Chart

Release é um produto gerado pela equipe de desenvolvimento e que vai ser instalado no cliente. Um release tipicamente é gerado após a execução de um ou mais Sprints, que resultaram um produto com algum valor agregado ao cliente.
Em Scrum, o gráfico de “Release Burndown” é uma grande figura com as informações do andamento do projeto para a geração de um “Release”. Esta figura mostra quanto de trabalho esta alocado em cada Sprint e as Sprint necessárias para a liberação de um “Release”. Mas neste gráfico nos temos a visão de todos os “Releases”.

(Passo 7) Montar Product Burndown Chart

Burndown charts mostra o trabalho restante (a ser realizado) com relação ao tempo necessário para a sua realização. O trabalho restante (a ser realizado) é representado pelas coordenadas de Y e o tempo necessário para a realização deste trabalho é representado pelas coordenadas X. Deve ser traçado uma linha com a representação da execução do trabalho, onde esta linha representa o esforço já realizado na execução das tarefas. Espera-se que a execução das atividades (tarefas) leve a linha de inicio em Y ao encontro de X, onde este encontro representa o termino das execuções das tarefas.
A literatura de Scrum define que temos dois tipos de “Burndown”, sendo a primeira referente a “Sprint Burndown”, que mostra o acompanhamento diário das execuções das tarefas existentes num “Sprint” e o segundo “Product Burndown” que representa as execução das tarefas existentes em todos as “Sprint”, que representa o projeto por inteiro.
Com estes dois “Burndown” podemos ter uma visão de como esta indo a execução do “Sprint” atual e como esta indo a execução do projeto inteiro pelo controle de todos as “Sprints” existentes no projeto.

(Passo 6) Definir a qtd de Sprint´s

1 – Progresso do projeto é baseado em uma serie de iterações (Sprint)
2 – Todas Sprint devem ter um objetivo, isto é, gerar algo de valor
3 – Ocorrem em um período de duas a quatro semanas
4 – Esses período são chamado de time-box
5 – O produto é desenvolvido durante o Sprint
6 – Nenhuma mudança deve ocorrer durante o Sprint
Um Sprint é uma interação, isto é, um período de tempo onde uma quantidade de funcionalidades serão implementadas. Uma Sprint não deve passar de 30 dias e ser menor que 2 semanas.
Uma Sprint tem seu inicio com uma reunião de planejamento. Uma Sprint possui as reuniões diárias de 15 minutos. Uma Sprint possui uma reunião de revisão do Sprint ao seu termino e também possui uma reunião de retrospectiva após a reunião de revisão.
Durante uma Sprint a equipe não pode ser interrompida com pedidos adicionais de novas funcionalidades. Com esta regra a equipe mantém o foco no compromisso assumido de entregar as funcionalidades selecionadas para a execução da Sprint no prazo combinado.
A quantidade de Sprint é calculada pegando o total de pontos das funcionalidades e dividindo pela velocidade da equipe.

(Passo 5) Velocidade da equipe?

Velocidade é a capacidade da equipe de executar funcionalidades (tarefas). Esta velocidade pode ser recalculada ao termino de cada Sprint e desta maneira realizar uma previsão se o projeto vai estar atrasado ou adiantado em relação ao cronograma inicial.
Uma vez identificada a velocidade de execução de um Sprint, esta velocidade pode ser utilizada para planejar as datas de conclusão das Sprint do projeto e das versões de demonstração.
A equipe deve estimar a velocidade que ela acredita ser capaz de realizar (Exemplo: 5, 7, 10, 15 pontos por Sprint).

(Passo 4) Equipe identifica a qtd de pontos de esforço para cada Item do Backlog

(Passo 3) Fazer a classificação dos itens Backlog (priorização)

(Passo: 2) Criar Backlog

Jogue o dado e com o valor obtido como resultado da jogada multiplique por “5”, descobrindo a quantidade de itens que seu Product Backlog deve possuir. O valor numero “1” não é valido.

Product backlog:
1 – Lista de todo o trabalho que deve ser feito no projeto
2 – Os itens que compõem a lista são chamados de historias ou itens de backlog
3 – Todos podem incluir historias
4 – Somente o product owner pode priorizá-las
5 – Product Owner pode refazer a priorização (novamente) no inicio de cada Sprint

Produto backlog (ou “backlog”) são os requisitos funcionais e não funcionais de um sistema. Estes requisitos são priorizados pelo “product owner” e é dele e somente dele a responsabilidade da priorização dos requisitos. Todos os requisitos dão origem a “list of product backlog items”, isto é, lista de todos os requisitos que compõem o sistema (escopo).
Durante um planejamento de “sprint”, os itens existentes na nossa lista de “backlog” são movidos para a “sprint” respeitando a priorização do “product owner”.

(Passo: 1) Quantidade de profissionais na equipe Scrum?

Jogue o dado e descubra a quantidade de profissionais multidisciplinares sua equipe vai possuir.

Equipe Scrum
1 - O time é funcional
2 - Deve ter em media 7 pessoas.
3 – Deve estar no projeto em tempo integral
4 – Auto Organizável

Uma equipe em Scrum é constituída de aproximadamente 7 pessoas. Num projeto de desenvolvimento de software uma equipe em Scrum é constituída de Engenheiros de Software, Arquitetos, Programadores, Analista, Peritos em Qualidade, Testadores, Web designers. Mas em Scrum as equipes são generalistas e não especialistas. Todos os membros da equipe podem e devem desempenhar todos os papeis, conforme a necessidade e definição da equipe.
Durante a execução do Sprint a equipe se auto organiza, para poder atender os acordos firmados na execução do Sprint. O Scrum Máster tem a responsabilidade de resguardar a equipe do Product Owner.
Em Scrum, um membro da equipe é definido como qualquer pessoa que trabalha para atender os objetos do Sprint.
Estes são as três papeis existentes em um projeto utilizando Scrum:
1 - Product Owner
2 - ScrumMaster
3 - Team

Plannig Poker

Jogo do Scrum do Abu

Oi pessoal,

Este é o tabuleiro do Jogo do Scrum feito por mim.

Ele demonstra o processo SCRUM.

Falou...

Apresentação de Scrum na Estacio de Sá