Outros métodos e

Scaling

Prof. Pedro Paulo Oliveira

Lean Kanban
O método Kanban introduz um sistema complexo adaptável cujo objetivo é catalisar um resultado Lean dentro de uma
organização. Sistemas complexos adaptáveis têm condições iniciais e regras simples que são necessárias para semear
comportamento emergente complexo e adaptável. Nesse caso, o resultado desejado é uma Cultura Kaizen − uma
organização focada em melhoria contínua que leva tanto a um melhor resultado econômico para o negócio quanto a um
melhor resultado sociológico para os funcionários.

O método Kanban usa propriedades fundamentais como condições iniciais para estimular um conjunto emergente de
comportamentos Lean. Em organizações que desejam como resultado uma cultura de melhoria contínua, observa-se que
todas as propriedades principais estão presentes:

 Visualize o fluxo de trabalho

 Limite o trabalho em progresso
 Torne as políticas do processo explícitas
 Meça e gerencie o fluxo

Propriedade Intelectual Saint Paul Educacional LTDA

Lean Kanban
Visualize o fluxo de trabalho
Há uma máxima no mundo da gestão que diz o seguinte: “Não se gerencia aquilo que não se vê”. Isso posto, podemos
visualizar o fluxo de trabalho de forma eletrônica ou simplesmente usando um quadro branco.
Uma boa ideia seria começar apenas com um quadro branco. Nada torna seu trabalho mais visível do que tê-lo visível a
todos o tempo todo e poder gerenciá-lo fisicamente. À medida que a maturidade da equipe aumenta e surge a
necessidade de coletar mais dados, convém mudar para uma versão eletrônica.
Geralmente, times que utilizam a “gestão à vista” iniciam com pelo menos dois tipos de estágios: o “em progresso” (o
trabalho que está sendo executado) e o “aguardando” (em que o trabalho está em uma “fila” para, num momento
oportuno, ser desenvolvido, testado ou colocado em produção).

Limite o Trabalho Em Progresso (WIP)

Os limites de WIP (Work In Progress) restringem a quantidade de trabalho em progresso dentro de determinado sistema
Kanban. A implementação dos limites de WIP permite que você complete um item de trabalho de maneira mais rápida ao
ajudar seu time a focar somente nas tarefas atuais.

Propriedade Intelectual Saint Paul Educacional LTDA

Lean Kanban
Aplicando limites de WIP, torna-se mais fácil identificar os gargalos e as folgas no sistema Kanban. Limitar o WIP é uma das
poucas prescrições do método Kanban, e essa prática permite que os times entendam quão importante é “parar de
começar e começar a terminar”. Nenhum sistema Kanban deveria trabalhar sem um mínimo de limite WIP.

Torne as políticas do processo explícitas

Muitas vezes, quando as pessoas estão trabalhando juntas, muitas suposições e políticas implícitas estão em jogo. As
pessoas invariavelmente fazem suposições sobre quase tudo. Às vezes, essas suposições são inconsistentes ou até
conflitantes, o que pode levar a mal-entendidos, baixa performance, discussões emocionais e subjetivas de problemas e
assim por diante.
Se você torna as políticas explícitas − por exemplo, visualizar seu fluxo de trabalho em um quadro Kanban, explicitando o
significado das diferentes fases do teu fluxo –, muitos conflitos podem ser resolvidos. Isso proporciona discussões mais
racionais e empíricas sobre como resolver os problemas inerentes a qualquer time. Além disso, fornece uma boa base para
o processo colaborativo de melhorias.

Meça e gerencie o fluxo

Ao discutir a respeito das métricas, uma regra básica deve ser sempre considerada: o seu sistema de entrega de
software tem certa capacidade. Logo, se você estressar o seu sistema para além de sua capacidade, isso resultará em uma
menor qualidade.

Propriedade Intelectual Saint Paul Educacional LTDA

Lean Kanban
Portanto, pense no seu plano apenas como uma ferramenta de alinhamento, não como um critério de sucesso, e meça e
gerencie seu fluxo para determinar se você ainda está alinhado a esse plano.
O que a maioria das organizações deseja é que o sistema de entrega de software seja estável e previsível para que elas
possam tomar decisões mais assertivas acerca de prazos, dependências, pessoal, escopo e custo, etc.
Upstream
Upstream é a gestão do fluxo estruturado de trabalho para avaliar, preparar e refinar ideias, oportunidades, de modo a
atender ao negócio antes de iniciar o desenvolvimento. Essa fase, que ocorre no momento do “nascimento” das
demandas, permite que os compromissos de entregas se tornem mais sustentáveis, com menor risco, menor incerteza e
gerem maior valor de negócio.

Downstream
Downstream são todas as etapas seguintes do fluxo de trabalho a partir das demandas que foram geradas no Upstream,
conforme pode ser visto na Figura 1.

Propriedade Intelectual Saint Paul Educacional LTDA

Lean Kanban

Figura 1: Visualização do UpStream e do DownStream.

Classes de serviço

Classes de serviço são tipicamente definidas com base no impacto do negócio. Diferentes tickets (cartões) são atribuídos
para cada classe e claramente identificam a classe de serviço de uma dada requisição.

Propriedade Intelectual Saint Paul Educacional LTDA

Lean Kanban
Cada classe de serviço traz seu conjunto de políticas próprio, o qual afeta a maneira como os itens são priorizados quando
eles são puxados para dentro do sistema Kanban. A classe de serviço também traz uma promessa explícita para o cliente. Os
tipos de classes de serviço mais utilizadas são:

 Expedite
 Prazo fixo
 Padrão

Cultura Kaizen
Para entender por que é tão difícil alcançar uma Cultura Kaizen, primeiro devemos entender como tal cultura seria. Só então
podemos discutir por que podemos querer alcançar tal cultura e quais seriam os seus benefícios.
Na Cultura Kaizen, a força de trabalho tem poder. Indivíduos sentem-se livres para agir e para fazer a coisa certa. Eles
espontaneamente se debruçam sobre os problemas, discutem as opções e implementam correções e melhorias.
Em uma Cultura Kaizen, a força de trabalho não tem medo. A norma subjacente é para a gestão ser tolerante a falhas se a
experimentação e a inovação fizerem parte do processo − assim como a melhoria de desempenho.

Propriedade Intelectual Saint Paul Educacional LTDA

Lean Kanban
Em uma Cultura Kaizen, indivíduos são livres (dentro de alguns limites) para se auto-organizarem em torno do trabalho que
eles fazem e em como fazê-lo. Controles visuais e sinais são evidentes, e as pessoas se oferecem para trabalhar em tarefas
de trabalho ao invés de serem atribuídas por um superior.
Uma Cultura Kaizen envolve um elevado nível de colaboração e uma atmosfera de coleguismo em que todos colocam o
desempenho da equipe e os negócios acima de si mesmos.

Propriedade Intelectual Saint Paul Educacional LTDA

eXtremme Programming
O eXtreme Programming é uma metodologia ágil de desenvolvimento de software voltada para times de pequeno a médio
porte, na qual os requisitos são vagos e mudam frequentemente. Desenvolvido por Kent Beck, Ward Cunningham e Ron
Jeffries, o XP, como é popularmente conhecido, tem como principal tarefa a codificação com ênfase menor nos processos
formais de desenvolvimento e com uma maior disciplina de engenharia ágil de software para codificação e testes. Tem
como valores a comunicação, a simplicidade, o feedback, a coragem e o respeito.
O XP valoriza a automatização de testes, os quais são criados antes, durante e depois da codificação. É flexível para a
mudança de requisitos, valorizando o feedback com o usuário e a qualidade do código-fonte final.
A ideia principal do XP é a criação de software de alta qualidade, abandonando todo tipo de overhead de processo que
não suporte diretamente a entrega de valor.

Papéis no XP
O time XP é formado por papéis com objetivos diferentes, porém complementares, como: o desenvolvedor
(programador), o cliente, o gerente, o coach, o testador, o tracker e o cleaner.
Uma pessoa pode assumir mais de um papel, como ser desenvolvedor e coach ou, então, desenvolvedor e tracker. Porém,
é aconselhável que alguns papéis, como coach e gerente, não sejam assumidos por uma mesma pessoa, porque seus
interesses são conflitantes. Por exemplo, o gerente, em determinados momentos, pode sofrer pressão muito grande para

Propriedade Intelectual Saint Paul Educacional LTDA

eXtremme Programming
entregar mais softwares e de forma mais rápida, e isso pode fazer com que, inconscientemente, ele repasse essa
pressão para o time e acabe deixando de lado as práticas ágeis do XP.
O coach, por sua vez, deve justamente manter o time atuando de forma ágil e disciplinada, mantendo a agilidade
mesmo em momentos de crise.
Reunião diária em pé
Para o time no XP, as reuniões diárias em pé são focadas e rápidas, ocorrem no começo do dia e duram até 15 minutos.

Propriedade coletiva de código

Propriedade coletiva é uma prática indispensável no XP, pois envolve colaboração, comunicação e feedback. Com a posse
coletiva, qualquer membro ou par do time pode implementar uma funcionalidade, arrumar um bug ou refatorar em
qualquer parte do código a qualquer momento.

Programação em par
No XP, todo o código de produção é criado por programação em par (pair programming). Isso significa ter duas pessoas −
piloto e copiloto − trabalhando juntas em apenas um computador, com foco em uma única tarefa e ao mesmo tempo. O
XP indica programar em par quando o código de produção for escrito. Não necessariamente se deve programar em par
100% do tempo, pois atividades como pesquisas e leituras não têm essa necessidade.

Propriedade Intelectual Saint Paul Educacional LTDA

eXtremme Programming
Spike de planejamento

Os spikes de planejamento fazem parte de uma prática que ajuda o time a gerar o conhecimento necessário para estimar
as histórias de usuários corretamente, diminuindo, assim, o risco no planejamento. O objetivo é aumentar a confiança
para um bom jogo do planejamento.

Um spike é um programa muito simples para explorar soluções potenciais. Faça spikes arquiteturais a fim de descobrir
respostas para dificuldades técnicas e para problemas de design, ou a fim de conhecer novas tecnologias (APIs,
frameworks, ferramentas, linguagens de programação, etc.).

Propriedade Intelectual Saint Paul Educacional LTDA

Ágil e Scrum escalado
Nexus framework

Nexus é um framework de processo para múltiplos times Scrum trabalharem juntos a fim de criarem um Incremento
Integrado. O Nexus é consistente com o Scrum, e suas partes serão familiares para aqueles que têm usado Scrum. A
diferença é que mais atenção é dada para as dependências e a interoperação entre os times Scrum, entregando pelo
menos um Incremento Integrado e “Pronto” a cada Sprint.

Propriedade Intelectual Saint Paul Educacional LTDA

Ágil e Scrum escalado
Os papéis do Nexus
O Nexus consiste em um time de integração do Nexus e aproximadamente 3 a 9 times Scrum.
O time de integração do Nexus é responsável por garantir que um Incremento Integrado (o trabalho combinado e
completado pelo Nexus) seja produzido pelo menos a cada Sprint. Os times Scrum são responsáveis por entregar
incrementos “Prontos” de produtos potencialmente possíveis de serem entregues, como indicado no
Scrum. Todos os papéis para os membros dos times Scrum são prescritos no Guia do Scrum.
O time de integração do Nexus é composto de:
 Product Owner
 Scrum Master
 Um ou mais membros do time de integração do Nexus.

Artefatos
Backlog do Produto
Há um único Backlog do Produto para todo o Nexus e todos os times Scrum. O Product Owner é o responsável pelo
Backlog do Produto, incluindo seu conteúdo, sua disponibilidade e sua ordenação.

Propriedade Intelectual Saint Paul Educacional LTDA

Ágil e Scrum escalado
Incremento Integrado
Um Incremento Integrado representa a soma atual de todos os trabalhos integrados completados para o Nexus. Deve ser
utilizável e potencialmente possível de ser entregue. Isso significa que ele deve atender à definição de “Pronto”.

Transparência do artefato
Assim como seu elemento de base − Scrum −, o Nexus é baseado na transparência. O time de integração do Nexus trabalha
com os times Scrum dentro de um Nexus e da organização para garantir que a transparência seja aparente em todos os
artefatos e que o estado integrado dos incrementos seja amplamente compreendido.

Eventos

Refinamento
O refinamento do Backlog do Produto em escala serve para dois propósitos: 1) ajudar os times Scrum a prever qual time irá
entregar cada item do Backlog do Produto e 2) identificar dependências entre esses times.

Propriedade Intelectual Saint Paul Educacional LTDA

Ágil e Scrum escalado
Planejamento da Sprint do Nexus
O propósito da reunião de planejamento Nexus é coordenar as atividades de todos os times Scrum no Nexus para uma
única Sprint.

A meta da Sprint do Nexus

A meta da Sprint do Nexus é um objetivo definido para a Sprint. Ela é a soma de todo o trabalho e de todas as metas das
Sprints dos times Scrum do Nexus.

Reunião diária do Nexus

A reunião diária do Nexus é um evento para os representantes adequados dos times de desenvolvimento individuais
inspecionarem a atual situação do Incremento Integrado e para identificarem questões de integração ou recentes
descobertas sobre as dependências ou impactos entre os times.

Revisão da Sprint do Nexus

A revisão da Sprint do Nexus é mantida no final da Sprint e proporciona retorno do Incremento Integrado que o Nexus
construiu ao longo da Sprint e adaptação do Backlog do Produto se necessário.

Propriedade Intelectual Saint Paul Educacional LTDA

Ágil e Scrum escalado
Retrospectiva da Sprint do Nexus
A retrospectiva da Sprint do Nexus é uma oportunidade formal para um Nexus inspecionar e adaptar a si mesmo e criar
um plano a fim de melhorias entrarem em vigor na próxima Sprint para garantir melhoria contínua.

Referência bibliográficas

BOEG, Jesper. 2012. PRIMING KANBAN – A 10 step guide to optimizing flow in your software delivery system. Trifork A/S
Anderson, David. 2010. KANBAN Successful Evolutionary Change for Your Technology Business. Blue Hole Press
Beck, Kent and Martin Fowler. 2000. Planning Extreme Programming. Addison-Wesley.
SCHWABER, Ken. 2018. Nexus Guide™ - The Definitive Guide to scaling Scrum with Nexus: The Rules of the Game.

Propriedade Intelectual Saint Paul Educacional LTDA

Obrigado