scrum vs kanban

Scrum vs Kanban

Scrum – O que é? Um framework ágil no qual as pessoas podem endereçar problemas adaptativos e complexos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível de maneira iterativa e incremental.
Como Funciona? Divide o projeto em ciclos, as Sprints, que fragmentam o volume de trabalho da equipe para que possam atuar nos itens de maior prioridade primeiro.


Kanban – O que é? Um método para definir, gerenciar, e melhorar serviços de modo que os times se aprimorem colaborativamente e evoluam experimentalmente. Pode ser caracterizado como um método “comece pelo que você faz agora” – um catalizador para mudanças rápidas e focadas nas organizações – que reduz a resistência a mudanças benéficas alinhadas com os objetivos da organização.
Como funciona? Baseia-se em tornar visível o que de outra forma seria conhecimento intangível, para garantir que o serviço funciona na quantidade certa de trabalho. para fazer isso, usamos um sistema de fluxo de entrega que limita a quantidade de trabalho em andamento (WIP) usando quadros visuais que ajudam as equipes a se auto-organizarem para realização do trabalho.


As equipes Scrum trabalham em Sprints que podem durar de 1 a 4 semanas.Kanban é um método contínuo sem delimitação de tempo.
O trabalho do Scrum Master é ajudar o Product Owner e a Equipe de Desenvolvimento a desenvolver e manter bons hábitos.É trabalho do SDM ajudar o SRM e a Equipe de Desenvolvimento a desenvolver e manter bons hábitos. (Os papéis de SDM e SRM) não são obrigatórios no Kanban.
Cada Sprint começa com uma reunião de Planejamento da Sprint – facilitada pelo Scrum Master e atendida pelo PO e Equipe de Desenvolvimento. Juntos, selecionam itens de alta prioridade que a equipe se comprometerá a entregar naquela Sprint. Os itens selecionados são conhecidos como o Sprint Backlog.Os itens são “puxados” diretamente do Product Backlog.
A equipe de desenvolvimento trabalha com os itens do Sprint Backlog apenas durante aquela Sprint. Os novos requerimentos devem, exceto em circunstâncias excepcionais, aguardar a próxima Sprint.Cada coluna tem um limite estrito de trabalho em andamento (WIP). Os limites do WIP garantem que os itens se movam no board no menor tempo possível. Uma coluna vazia- ou quase vazia – é um sinal para a coluna anterior liberar outro item. Este é o sistema de “puxar” em ação.
A Daily Meeting é uma reunião curta, de no máximo 15 minutos, em que o Time de Desenvolvimento normalmente informa o que foi feito, o que será feito e se há algum impedimento.A Kanban Meeting é uma reunião (geralmente) diária que promove a auto-organização e revisão de planejamento para aqueles que colaboram para entregar o serviço. Geralmente usa um formato “stand-up” para incentivar uma reunião curta e enérgica com foco em concluir itens de trabalho e desbloquear problemas.
É na Sprint Review que acontecem demonstrações de novas features para os Stakeholders e os feedbacks são recolhidos. Todos os itens incompletos retornam ao Product Backlog.Cada item é empacotado para ser liberado assim que estiver pronto.
É na Sprint Retrospective que o time avalia o que correu bem, o que poderia ser melhorado, etc – gerando pontos de ação para melhorar as próximas Sprints.Demonstrações das novas features para os Steakeholders acontecem nas reuniões de Demo, que são opcionais.
Assim que finalizados os itens já são liberados para uso.Na Service Delivery Review o time examina e melhora a efetividade do serviço. Objetivo: melhoria contínua do processo .
A Replenishment Meeting é uma reunião facilitada pelo SRM com objetivo de reabastecer o backlog de trabalho. Pode acontecer em intervalos regulares ou , idealmente, quando necessária.

Resenha | Astrofísica para apressados

Meu primeiro livro do Neil deGrasse Tyson. Na curiosidade e na frustração de não ter conseguido assistir a série Cosmos, encontrei este livro na feira do livro na Usp. Então vamos lá às minhas considerações. 🙂

Os primeiros capítulos são bem teóricos, o que pode causar cansaço em certos momentos, mas entre um capítulo e outro a coisa desenrola e surgem partes bem curiosas sobre a origem dos planetas, seus nomes e luas com personagens Sheakesperianos. Um capítulo dedicado a explicar a origem dos principais elementos da tabela periódica, bem como uma explicação porque a lua e o sol – este último trilionésimo maior – tem o mesmo tamanho visto do céu. O último capítulo fecha com uma visão pessoal do Neil sobre as diferenças sociais, a falta de oportunidade dos países na ótica de um astrofísico e o quão inferior somos em relação ao universo e o cosmos.


O que foi bom =)

  • Origem dos elementos da tabela periódica
  • Origem dos nomes dos planetas e luas
  • Abriu minha mente para pensar melhor na vida

O que não foi tão bom =(

  • Leitura muita das vezes é técnica
  • Dificuldade de imaginação

Nota: 3/5

Recomendo!

Considerações finais: É difícil durante a leitura criar uma imagem concreta das muitas coisas descritas no livro. Um computador ao lado para consultas ajuda a compreensão. Ah! E assistam a série!

RD – do ponto A ao B

“Nos tempos antes de Cristo, havia uma ave estúpida chamada Fênix que, a cada cem anos, construía uma pira e se consumia em suas chamas. Deve ter sido prima-irmã do homem. Mas, toda vez que se queimava, ressurgia das cinzas e novamente renascia. E parece que estivemos fazendo e refazendo inúmeras vezes a mesma coisa, só que com uma vantagem que a Fênix nunca teve. Nós sabemos a estupidez que acabamos de cometer”

Trecho do livro Fahrenheit 451 – Ray Bradbury

Após 8 anos de Raiadrogasil – com muito trabalho, paciência e persistência – ao lado do grande amigo e profissional Ricardo Almeida, chegamos no nosso ponto B. Não foi nada fácil e falhamos muito! Mas diferente da fênix, percebemos os erros rápido o suficiente para termos chances de corrigir #FailFast.

Cinco anos após formação do primeiro time Scrum, entre desentendimentos como “quem autorizou colar essas coisas na parede”, inúmeras discussões ágeis sobre os processos burocráticos, gerentes inertes e desenvolvedores que não enxergavam valor na forma que trabalhávamos com testes, criamos inúmeras palestras e workshops sobre scrum, integração contínua, testes automatizados, como entregar valor, ALM e outros. Com o tempo – e com o incômodo que gerávamos 🙂 – ganhamos um espaço isolado só nosso para por em prática tudo que gostaríamos. Nascia o Garage.

A partir daí vieram Lean Inceptions, automações de deploy com Circle-CI, Jenkins, testes automatizados, refatorações, pair programming, tudo isso com um ritmo sustentável de trabalho e, com períodos regulares, melhorávamos nossos processos.

Entregávamos valor sem fazer hora-extra e com qualidade! (Tá, deixamos de comer as pizzas patrocinadas pelo gerente pra ficarmos até mais tarde, mas foi melhor xD). Tínhamos feedback a curto prazo e nosso cliente passou a enxergar com outros olhos tudo aquilo que fazíamos. Como se diz:

Fazer o dobro do trabalho na metade do tempo

Jeff Sutherland

Foram tantos elogios que o próprio presidente da Raiadrogasil, Marcílio Pousada, veio nos visitar no Garage. Ao ver a sala lotada de post-its e uma longa explicação do nosso método de trabalho, decidiu então convidar os diretores para conhecer nosso espaço e os aconselhou a seguirem este caminho.

Os próximos passos a pedido do presidente foram: Contratação de uma consultoria ágil, criação de duas squads e formação da iniciativa RD Agile na organização!

Como diz John Kotter – professor da Harvard Business School – no livro Liderando Mudanças “Formar uma coalizão forte”.

Com isto alcançamos o ponto B. Celebremos curtas vitórias!

Ricardo e eu
Lean Inception com todos os envolvidos do e-commerce – na Garage

Agradeço a todos que trabalharam e acreditaram nessa evolução! Juliano Celestino, Luis Paulo Rodrigues, Diego Rocha Ramos, Henrique Smoco.

Em agosto de 2018, deixei este legado, realizado e orgulhoso com um trabalho bem feito para um próximo desafio. Fui contratado como Agile Coach para ajudar o banco Santander nos caminhos da agilidade, junto com a BRQ.

Squad Health Check Model – Em Português

Como não encontrei a versão em português da técnica de facilitação criada pelo Spotify, decidi traduzir os cards, o manual e montei um deck. Abaixo segue o download de todo material que produzi.

  • Template
  • PDF das cartas traduzidas Pt-Br
  • Sleeve (Plástico que serve para proteger as cartas)
  • Deck
O Resultado final

Este template foi criado para facilitar a visualização de uma tribo após os dados serem colhidos nos times.

O template – Download abaixo
Exemplo de uma carta traduzida – Download abaixo
Sleeve ideal para as cartas do SHC

O Sleeve é encontrado facilmente em qualquer loja de Boardgames espalhadas por São Paulo. Esta foi comprada na Domain Games (R. Domingo de Morais) e custou R$ 13,00. 

Espero que ajude a vocês na busca da evolução contínua e gradual.

Para quem deseja saber mais ou como rodar a dinâmica, segue o link: https://labs.spotify.com/2014/09/16/squad-health-check-model/

Kaizen! 🙂