David Anderson - Kanban. Kanban

David J Anderson

Mudança evolutiva bem-sucedida para seu negócio de tecnologia

Publicado com permissão de Lean Kanban Inc.

Agradecemos à Comunidade Lean Kanban Rússia representada por Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov e Igor Filipyev por sua ajuda na preparação da publicação.

Nenhuma parte deste livro pode ser reproduzida de qualquer forma sem a permissão por escrito dos detentores dos direitos autorais.

* * *

Dedicado a Nikola e Natalie

Prefácio

Sempre presto atenção ao trabalho de David Anderson. Eu o conheci em outubro de 2003, quando ele me enviou uma cópia de seu livro Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. Como o título sugere, o livro foi fortemente influenciado pela Teoria das Restrições (TOC) de Eliyahu Goldratt. 1
A Teoria das Restrições é uma metodologia de gerenciamento de produção popular desenvolvida na década de 1980 por Eliyahu Goldratt, que se baseia em encontrar e gerenciar as principais restrições do sistema que determinam o sucesso e a eficiência de todo o sistema como um todo. Observação. ed.

Mais tarde, em março de 2005, visitei David na Microsoft, na época em que ele trabalhava de perto com fluxogramas cumulativos. Ainda mais tarde, em abril de 2007, tive a oportunidade de observar como funciona o inovador sistema kanban que ele implementou na Corbis.

Eu dou toda essa cronologia para que você tenha uma ideia do ritmo imparável em que o pensamento gerencial de David está avançando. Ele não se apega a uma única ideia, tentando encaixar o mundo inteiro nela. Pelo contrário, procura considerar o problema como um todo, está aberto a várias soluções, experimenta-as na prática e avalia os princípios do trabalho. Você verá os resultados dessa abordagem neste livro.

Claro, a velocidade é boa desde que esteja na direção certa, e tenho certeza de que David está se movendo na direção certa. Admiro especialmente o trabalho mais recente com sistemas kanban. Sempre acreditei que os princípios do lean podem ser aplicados diretamente ao desenvolvimento de produtos, ao contrário das ideias do TOC. Além disso, em outubro de 2003, escrevi a David o seguinte: “Uma das principais fraquezas da TCC é a subestimação da importância do tamanho do partido.

Se sua principal prioridade é encontrar e corrigir a restrição, isso geralmente significa que você está apenas resolvendo o problema errado." Eu ainda acredito que esta afirmação é verdadeira.

Em nossa reunião em 2005, sugeri novamente a David que olhasse além do foco apenas nos gargalos da TOC. Expliquei a ele que o hype do Sistema Toyota de Produção (TPS) não tinha nada a ver com encontrar e eliminar gargalos. A Toyota obtém ganhos de produtividade reduzindo o tamanho dos lotes e a variabilidade, o que reduz a quantidade de estoque necessária. Foi a redução desses estoques que levou à obtenção de benefícios econômicos, e isso foi possível por meio de sistemas de redução de trabalho em processo como o kanban.

Em 2007 visitei a Corbis. O resultado da introdução do sistema kanban foi impressionante. Mostrei a David que ele havia melhorado muito a abordagem kanban usada na Toyota. Por que eu pensei assim? O Sistema Toyota de Produção é otimizado para lidar com tarefas repetitivas e previsíveis com duração uniforme e custos de atraso uniformes. Nessas condições, é bastante correto usar abordagens como a priorização FIFO (“first in, first out”). Também é perfeitamente correto bloquear a chegada do trabalho se o limite de tarefas não concluídas for atingido. No entanto, se estamos lidando com atividades não repetitivas, imprevisíveis com diferentes durações e diferentes custos de atraso, essas abordagens não podem ser consideradas ótimas - e esse é exatamente o caso do desenvolvimento de software. Precisamos de sistemas mais avançados, e este é o primeiro livro que os descreve em detalhes práticos.

Gostaria de alertar os leitores sobre algumas coisas. Primeiro, se você acha que sabe como os sistemas kanban funcionam, provavelmente está se referindo aos usados na manufatura enxuta. As ideias deste livro são muito mais avançadas do que os sistemas simples que usam limites de WIP estáticos. 2
WIP - trabalho em andamento, o número de tarefas em andamento. Observação. ed.

Agendamento FIFO e classe única de serviço. Por favor, preste atenção a essas diferenças.

Segundo, não pense que essa abordagem é um sistema de controle visual. A visualização do trabalho em andamento obtido com os quadros kanban é muito útil, mas é apenas um pequeno aspecto dessa abordagem. Se você ler este livro com atenção, encontrará muitas coisas interessantes nele. As informações mais valiosas estão ocultas, por exemplo, em aspectos como a estrutura dos processos de recebimento e envio de tarefas, gerenciamento de recursos insubstituíveis e uso de classes de serviço. Não se distraia com a parte visual, senão perderá os momentos mais emocionantes.

Terceiro, não desconsidere esses métodos só porque eles parecem muito fáceis de usar. A facilidade de uso é o resultado das ideias de David sobre como obter o máximo benefício com o mínimo de resultados. Ele conhece bem as necessidades dos praticantes e prestou muita atenção ao que realmente funciona. Métodos simples mostram alta estabilidade e quase sempre levam aos melhores resultados a longo prazo.

Este é um livro fascinante e necessário e merece um estudo cuidadoso. O nível de benefício que você obtém disso depende de quão seriamente você leva a leitura. Nenhum outro livro apresentará melhor essas ideias avançadas. Espero que gostem tanto quanto eu.

Dom Reinertsen,

Parte I
Fundamentos

Capítulo 1
Resolvendo o Dilema do Gerente Ágil

Em 2002, eu era gerente de desenvolvimento em um escritório remoto na divisão de telefonia móvel da Motorola em Seattle (chamada PCS) e me vi em uma situação difícil. Meu departamento fazia parte de uma startup que a Motorola havia adquirido um ano antes. Desenvolvemos software de rede para transmissão de dados sem fio, como download sem fio e controle de instrumentos. Esses aplicativos de back-end faziam parte de sistemas integrados fortemente acoplados ao código do cliente de telefonia móvel, bem como a outros elementos em redes de telecomunicações e infraestrutura operacional, como faturamento. Os prazos foram estabelecidos por gerentes que não prestaram atenção à complexidade de engenharia do projeto, seus riscos ou sua escala. O código principal evoluiu a partir de uma inicialização, com muitos recursos originalmente planejados sendo adiados para mais tarde. Um desenvolvedor sênior insistiu que nossos produtos fossem chamados de "protótipos". Precisávamos desesperadamente aumentar a produtividade e a qualidade do produto para acompanhar as demandas do negócio.

Em minhas atividades diárias em 2002 e no processo de trabalho no livro anterior 1
Anderson, David J. Gerenciamento Ágil para Engenharia de Software: Aplicando a Teoria das Restrições para Resultados de Negócios. Upper Saddle River, NJ: Prentice Hall, 2003.

Eu estava preocupado principalmente com duas questões. Primeiro, como proteger a equipe das demandas cada vez maiores do negócio e alcançar o que hoje é chamado de “ritmo ideal” na comunidade ágil. E segundo, como posso implementar com sucesso uma abordagem ágil em toda a organização, superando a inevitável resistência à mudança?

Encontrando o ritmo certo

Em 2002, a comunidade ágil pensava que o ritmo ideal era simplesmente uma “semana de trabalho de 40 horas”. 2
BECK, Kent. Programação Extrema Explicada: Abrace a Mudança. Boston: Addison Wesley, 2000. Edição Russa: Beck K. Extreme Programming. São Petersburgo: Peter, 2002.

Princípios do Manifesto Ágil 3
Beck, Kent et al., “Os Princípios por trás do Manifesto Ágil”. http://www.agilemanifesto.org/principles.html. Tradução russa: http://agilemanifesto.org/iso/ru/principles.html .

Eles disseram que “processos ágeis contribuem para o desenvolvimento ideal. Patrocinadores, desenvolvedores e usuários devem estar preparados para manter um ritmo constante indefinidamente.” Dois anos antes, minha equipe na Sprint PCS ficava ouvindo de mim que "o desenvolvimento de software em escala é uma maratona, não um sprint". Se os membros da equipe mantivessem um ritmo constante durante o processo de trabalho em um projeto de um ano e meio, não poderiam se esgotar em um mês ou dois. O projeto tinha que ser planejado, orçado, cronometrado e avaliado para garantir que os membros da equipe passassem uma quantidade razoável de tempo trabalhando todos os dias e não estivessem muito cansados. Como gerente, minha tarefa era atingir esse objetivo e atender a todos os requisitos do negócio.

Quando eu estava no meu primeiro cargo gerencial (foi em 1991, em uma start-up que fazia placas de captura de vídeo para computadores pessoais e menores), o CEO 3
Chief Executive Officer - Chief Executive Officer (CEO). Observação. ed.

Ele disse que a gerência tinha uma “opinião extremamente negativa” sobre mim. Eu sempre respondia "não" quando nossas oportunidades como desenvolvedores já estavam esgotadas e cada vez mais produtos ou recursos eram exigidos de nós. Em 2002, tornei-me um hábito: passei mais dez anos me recusando a obedecer aos caprichos dos empresários.

As equipes de desenvolvimento e os departamentos de TI das empresas são fortemente dependentes de outros grupos que estão constantemente negociando, implorando, ameaçando e refazendo até mesmo os planos mais óbvios e objetivamente desenhados. Vulneráveis também incluem planos baseados em análise cuidadosa e experiência histórica. A maioria das equipes, sem uma análise completa e experiência histórica, não conseguia lidar com aqueles que as empurravam para assumir compromissos obscuros e muitas vezes impossíveis.

Enquanto isso, os funcionários aceitaram a carga de trabalho insana e as cargas de trabalho exorbitantes se tornaram a norma. Ninguém parece ter pensado no fato de que engenheiros de software também podem ter uma vida social ou familiar. Parece duro, mas é verdade! Conheço muitos exemplos em que a carga de trabalho excessiva destruiu para sempre os relacionamentos familiares. É difícil simpatizar com o típico desenvolvedor geek. No meu estado natal, Washington, a renda de um engenheiro de software perde apenas para a de um dentista. Como nos tempos de Ford, ou seja, na década de 1920, quando as pessoas em suas fábricas ganhavam cinco vezes mais do que a média nacional, nunca ocorre a ninguém pensar na monotonia do trabalho ou no bem-estar dos especialistas: são pagou muito! É difícil imaginar sindicatos em indústrias baseadas em conhecimento como o desenvolvimento de software, porque ninguém examinará seriamente as causas das doenças físicas e psicológicas experimentadas pelos desenvolvedores. Empregadores mais responsáveis oferecem, por exemplo, medidas como massagem ou psicoterapia. Ou passam dias de saúde mental - e isso em vez de prestar atenção ao estudo das causas do problema. Um redator técnico de uma conhecida empresa de software me disse uma vez: "Tudo bem se eu tomar antidepressivos, porque todo mundo toma!" Os programadores geralmente aceitam todas as demandas, são bem pagos e sofrem as consequências. Eu queria mudar esse estado de coisas, encontrar uma abordagem ganha-ganha que me permitisse dizer sim e ainda proteger minha equipe, garantindo que o ritmo ideal fosse alcançado. Eu queria trazer os membros da minha equipe de volta à comunidade e à família e melhorar as condições que estavam causando estresse e problemas de saúde para desenvolvedores com menos de trinta anos. Então decidi começar a lidar com esses problemas.

Em busca de uma gestão de mudanças bem-sucedida

A segunda questão que tem estado em minha mente é a gestão de mudanças em grandes organizações. Fui gerente de desenvolvimento na Sprint PCS e depois na Motorola. Em ambas as empresas, havia uma forte necessidade de mudar para métodos de trabalho mais flexíveis. Mas em ambos os casos, tive problemas para implementar métodos ágeis em mais de uma ou duas equipes.

Nas duas vezes, não tive autoridade suficiente para simplesmente ordenar que as alterações fossem feitas em várias equipes. Tentei implementar mudanças a pedido da alta administração, mas não tive a autoridade necessária. Pediram-me para influenciar os colegas a implementar as mesmas mudanças em suas equipes que fiz na minha. Mas eles não tinham pressa em adotar métodos que pareciam funcionar melhor em minha equipe. Essa resistência provavelmente teve várias razões. Na maioria das vezes, ouvi dizer que cada equipe tem sua própria situação e meus métodos precisarão ser adaptados às necessidades específicas dos outros. Em meados de 2002, percebi que era inútil prescrever rigidamente qualquer processo de desenvolvimento de software - simplesmente não funcionaria.

O processo teve de ser adaptado a cada situação específica, pelo que foi necessária uma liderança ativa de cada equipa. E isso muitas vezes não era suficiente. Mesmo com uma liderança adequada, não há certeza de que mudanças significativas possam ocorrer sem uma estrutura estabelecida e conselhos sobre como adequar os processos às diferentes situações. Se o gerente, coach ou engenheiro responsável não tiver uma ideia clara do que fazer, qualquer adaptação provavelmente será subjetiva. Ao mesmo tempo, há uma alta probabilidade de erros - por exemplo, a introdução de um modelo de processo inadequado.

Tentei abordar essa questão no livro Agile Management for Software Engineering que estava escrevendo na época. Eu me perguntei: "Por que o desenvolvimento ágil produz melhores resultados econômicos do que as abordagens tradicionais?" Eu queria aplicar a estrutura da teoria das restrições para esse propósito. 4
Goldratt, Eliyahu M. O que é essa coisa chamada Teoria das Restrições e como ela deve ser implementada? Great Barrington, MA: North River Press, 1999.

No processo de pesquisar e escrever este livro, percebi que cada situação é única. E como uma restrição ou gargalo pode ser o mesmo para qualquer equipe e projeto a qualquer momento? Cada equipe é única: diferentes habilidades, oportunidades, experiência. Cada projeto difere dos demais em termos de orçamento, cronograma, escopo e riscos. As organizações também são diferentes: possuem diferentes cadeias de valor e operam em diferentes mercados (Figura 1.1). Pareceu-me que isso poderia fornecer uma pista para entender a resistência à mudança. Se as mudanças propostas nos métodos e comportamentos de trabalho não derem, na opinião do funcionário, uma vantagem óbvia, ele não as aceitará. Se essas mudanças não afetarem o que a equipe percebe como limitador ou impeditivo, a equipe resistirá. Ou seja, as mudanças propostas fora do contexto serão rejeitadas pelos funcionários que conhecem perfeitamente o contexto do trabalho.

Arroz. 1.1. Por que as metodologias genéricas de desenvolvimento estão erradas

Parece que seria melhor se o novo processo começasse a se desenvolver, eliminando uma limitação após a outra. Este é o ponto principal da teoria das restrições de Goldratt. Percebendo que ainda tinha muito a aprender, percebi o valor do material e apressei-me a trabalhar no manuscrito. Ficou claro para mim que o livro não dava conselhos sobre como implementar ideias em uma escala maior, nem ajudava muito a encontrar maneiras de gerenciar a mudança.

A abordagem de Goldratt, descrita em , visa encontrar limitações e, em seguida, formas de eliminá-las para que não prejudiquem mais o desempenho. Depois disso, surge uma nova restrição e o ciclo se repete. É uma abordagem iterativa que melhora sistematicamente o desempenho, identificando e removendo obstáculos.

Percebi que você pode combinar essa abordagem com algumas técnicas do campo da manufatura enxuta. Ao modelar o fluxo de trabalho do ciclo de vida de desenvolvimento de software como um fluxo de valor e criar um sistema de rastreamento e visualização para capturar as mudanças de estado do trabalho emergente “fluindo” pelo sistema, pude identificar as restrições. A capacidade de identificar a restrição é o primeiro passo para o modelo subjacente de TOC. Goldratt já desenvolveu uma aplicação dessa teoria para problemas de fluxo de trabalho que leva o nome desajeitado de "drum-buffer-rope". No entanto, percebi que uma versão simplificada deste sistema pode ser implementada na área de desenvolvimento de software.

Em termos de origem, drum-buffer-rope é um exemplo de uma classe de soluções conhecidas como sistemas puxados. Como veremos em , o kanban também é um exemplo desse tipo de sistema. Um efeito colateral dos sistemas pull é que eles limitam o WIP a uma quantidade predeterminada, evitando que os funcionários fiquem sobrecarregados. Além disso, apenas os trabalhadores que enfrentam diretamente a restrição permanecem totalmente carregados; todos os outros devem ter tempo livre. Percebi que os sistemas puxados poderiam resolver os dois problemas que me preocupavam. O sistema puxado me permitirá introduzir mudanças incrementais, o que (eu esperava) reduziria significativamente a resistência a elas, além de facilitar o alcance do ritmo ideal. Tomei a decisão de mudar para o sistema tambor-tampão-corda o mais rápido possível. Eu queria experimentar a evolução incremental do processo e ver se ela proporcionava um ritmo ideal e reduzia a resistência à mudança.

Tal oportunidade apareceu no outono de 2004 na Microsoft, que é descrita em detalhes neste livro na análise do exemplo.

Do tambor-tampão-corda ao kanban

A solução de corda-tampão de tambor na Microsoft valeu a pena. A resistência foi fraca, o desempenho mais do que triplicou, o lead time foi reduzido em 90% e a previsibilidade melhorou em 98%. No outono de 2005, relatei os resultados alcançados em uma conferência em Barcelona 5
Anderson, David J. e Dragos Dumitriu, “From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department,” Proceedings of the TOCICO World Conference, Barcelona, novembro de 2005.

E no inverno de 2006 ele fez outro relatório. Meu trabalho chamou a atenção de Donald Reinertsen, que fez uma visita especial ao meu escritório em Redmond. Ele queria me garantir que tudo estava pronto para uma transição completa para o kanban.

Kan-ban - uma palavra japonesa que se traduz literalmente como "placa de sinal". Na produção, esse quadro é usado para visualizar o ritmo crescente de produção, o que permite que mais produtos sejam produzidos. Os funcionários em cada estágio do processo não podem passar para a próxima fase do trabalho até que o sinal apropriado seja dado através do quadro Kanban. Embora eu soubesse da existência desse mecanismo, não estava convencido de que fosse útil ou mesmo viável em relação ao trabalho intelectual, principalmente o desenvolvimento de software. Eu entendia que o kanban oferecia o ritmo ideal, mas não sabia de sua boa reputação como um método de incentivar a melhoria incremental do processo. Eu não sabia que Taiichi Ohno, um dos criadores do Sistema Toyota de Produção, disse: “Os dois princípios principais do Sistema Toyota de Produção são a automação just-in-time e a automação assistida por humanos, ou autonomia. Uma ferramenta é usada para gerenciar o sistema - isso é kanban. Em outras palavras, o Kanban é vital para o processo. kaizen(“melhoria contínua”) utilizada pela Toyota. É o mecanismo que faz o sistema funcionar. Agora, com cinco anos de experiência, aceito isso como uma verdade absoluta.

Felizmente, Don fez um argumento convincente para mudar de corda de tambor para kanban. Parecia bastante esotérico: o sistema kanban fornece uma transição mais suave do tempo de inatividade para um gargalo do que a corda do tambor-tampão. No entanto, entender essa distinção não é essencial para ler e entender este livro.

Reexaminando a solução implementada pela Microsoft, percebi que se a percebêssemos imediatamente como resultado de um sistema kanban, o resultado seria o mesmo. Achei interessante que duas abordagens diferentes levam ao mesmo resultado. Então, como era o mesmo processo, não me senti obrigado a vê-lo apenas como produto do sistema tambor-amortecedor-corda.

Comecei a preferir o termo "kanban" a essa frase complexa. É usado na manufatura enxuta (o mesmo que o Sistema Toyota de Produção). Esse corpo de conhecimento recebeu muito mais distribuição e reconhecimento do que a teoria das restrições. Kanban, apesar de sua origem japonesa, é menos metafórico do que tambor, amortecedor e corda combinados. Esta palavra é mais fácil de pronunciar, explicar e, como se viu mais tarde, ensinar e implementar. Este é o lugar onde ele ficou preso.

O surgimento do método Kanban

Em setembro de 2006, deixei a Microsoft para liderar o desenvolvimento de software na Corbis, uma empresa privada de armazenamento de fotos e propriedade intelectual localizada no centro de Seattle. Inspirado pelo que a Microsoft havia conquistado, decidi implementar um sistema kanban pull na Corbis. Aqui, também, os resultados foram muito bem sucedidos, levando ao desenvolvimento da maioria dos conceitos apresentados neste livro. É um conjunto estendido desses conceitos – visualização de fluxo de trabalho, tipos de itens de fluxo de trabalho, cadências, classes de serviço, relatórios especiais de gerenciamento e análise de atividades – que definem o método Kanban.

Neste livro, descrevo o Kanban (em maiúsculas) como um método de mudança evolucionária usando o sistema puxado kanban (em letras minúsculas), visualização e outras ferramentas para catalisar a introdução de ideias enxutas no desenvolvimento de tecnologia e nas operações de TI. É um processo evolutivo e passo a passo. O Kanban permite que você obtenha a otimização do processo específico do contexto com resistência mínima à mudança, mantendo o ritmo ideal para todas as pessoas envolvidas.

O livro de David Anderson, Kanban, assume a partir da primeira página.

Com fotos, gráficos e conclusões A biografia condensada de David revela a metodologia Kanban para o maníaco por gerenciamento de projetos experiente. O gerenciamento de projetos é interessante quando contado em primeira pessoa pelo desenvolvedor direto do método.

Sobre o autor

Listado no blog oficial de David J Anderson como p Presidente da Lean Kanban Inc. Também ele t gestor de gestão e consultor desde os anos 2000, orador e anfitrião de conferências desde 2005. Pela primeira vez em uma posição de liderança, ele estava em 1991, então sua experiência permite que você compare honestamente kanban e cascata, ágil, scrum e outras metodologias de gerenciamento de projetos.

Ele criou o kanban para elevar o nível do trabalho intelectual e criativo. O objetivo de David era entregar no prazo, cumprir metas e gerenciar adequadamente as empresas atuais em geral.

Usando exemplos reais da vida da Microsoft, Motorola e Corbis, ele contou e mostrou os princípios, métodos e instruções para a implementação do kanban em uma empresa.

Carga semântica e essência do livro

Livro . Rota alternativa paraAgile é escrito pela pessoa que inventou o kanban em primeiro lugar. O livro é muito interessante e informativo. Aqui, a linha entre a filosofia do Kaizen é muito interessantemente revelada ( melhoria continua), metodologia ( Magro) e Kanban (um método de conservação de recursos humanos e materiais).

Kaizen é a filosofia e a ética da relação entre os trabalhadores da fábrica e a administração.

A manufatura enxuta é um sistema de gerenciamento de projetos criado na Toyota para eliminar todo desperdício de tempo e recursos dos processos da empresa.

Kanbané um método de gerenciamento de projetos que fornece uma maneira limitar tarefas em execução simultânea. Se houver um limite de pessoas, ferramentas ou tempo, o kanban ajuda a distribuir tarefas e projetos.

Anderson foi muito influenciado pela teoria das restrições ao escrever este livro. O livro está cheio de limites de WIP, gargalos e a capacidade dedeterminar honestamente a carga máxima por unidade de tempo, que mantém a qualidade em um nível ideal.

A Teoria das Restrições (TOC) do Dr. Eliyahu Goldratt é uma metodologia de gerenciamento de negócios de manufatura. Um físico israelense desenvolveu uma teoria e um método prático para gerenciar organizações, algoritmos para operação de produção, logística e comercialização de mercadorias. Uma abordagem sistemática para identificar restrições nas empresas ajuda a configurar tudo. De acordo com a experiência de Goldratt, Na maioria das vezes, a política da empresa se torna uma restrição.

Limite de WIP (trabalho em andamento) — o número de tarefas que podem ser abertas ao mesmo tempo.

Gargalo - um momento no fluxo de trabalho em que há um sério problema limitação de recursos ou oportunidades. Nos diagramas, realmente parece um gargalo estreito de uma garrafa: antes e depois de tal situação, as linhas se expandem nos diagramas.

Estereótipos sobre Kanban

Quando ouvimos falar de kanban, muitas vezes imaginamos um quadro com adesivos - esse estereótipo nos é imposto pela mídia. Figurativamente, há uma lista de tarefas de adesivos abertas, em execução e concluídas na parede. . Você pode usar paredes e programas virtuais para gerenciar projetos, onde serão inseridas listas de tarefas, prioridades e outras nuances.

A metodologia kanban aqui não será um quadro, nem adesivos, mas o processo de monitoramento e transferência de tarefas na parede. Por quais regras, quem e por que move adesivos, quantos adesivos podem ser mantidos na coluna "realizada", por que limitar o número nesta coluna - é o que David diz nas páginas " Kanban. Um caminho alternativo para o Agile.

Kanban não é um quadro pegajoso, os adesivos são apenas um indicador de carga de trabalho.

Anderson projetou o kanban para que não iniciemos um novo projeto até que os anteriores sejam concluídos. Portanto, o número de adesivos é selecionado por desenvolvedor - 3-5, por exemplo, e exatamente tantas tarefas por unidade de tempo podem ser abertas para ele. Somente depois de completar qualquer uma das tarefas, ele pode assumir uma nova.

Falamos muito em horas-homem e seu preço, mas muitas vezes não percebemos que existe uma hora de trabalho produtivo e uma hora tirada da vida. E há uma semana de trabalho produtivo, cujo campo você tem que tirar licença médica. David fala sobre esse ritmo de trabalho quando cada hora é produtiva e este é um estado saudável constante da equipe.

Ágil, Scrum e Kanban

Anderson tem certeza de que as metodologias Agile e Scrum são estereotipadas e rígidas. Para ele, a gestão de projetos deve ser individual em cada empresa. Portanto, Agile e Scrum com seus algoritmos de ação padronizados estão desatualizados, como a metodologia clássica de passo a passo Waterfall. Uma proibição de kan - o método é assim específico da empresa, o que assusta os adeptos de metodologias flexíveis!

Agile é uma metodologia ágil com a qual a programação começou historicamente no formato de lançamento de atualizações nos programas a cada dois meses. As iterações de programação de algumas semanas para adicionar cada recurso aceleram o processo de desenvolvimento e reduzem o risco.

Scrum é outra metodologia ágil com iterações curtas, mas mais controle sobre o processo de programação. Existem sprints - períodos de tempo com certas tarefas a serem concluídas. Eles são estritamente limitados. Existem backlogs - listas de tarefas em geral, que são distribuídas pelo proprietário do produto. Não pertence à equipe de desenvolvimento, mas prioriza as tarefas.

David Anderson

Kanban. Um caminho alternativo para o Agile

David J Anderson

Mudança evolutiva bem-sucedida para seu negócio de tecnologia

Publicado com permissão de Lean Kanban Inc.

Agradecemos à Comunidade Lean Kanban Rússia representada por Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov e Igor Filipyev por sua ajuda na preparação da publicação.

Nenhuma parte deste livro pode ser reproduzida de qualquer forma sem a permissão por escrito dos detentores dos direitos autorais.

* * *

Dedicado a Nikola e Natalie

Prefácio

Sempre presto atenção ao trabalho de David Anderson. Eu o conheci em outubro de 2003, quando ele me enviou uma cópia de seu livro Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. Como o título sugere, o livro foi fortemente influenciado pela Teoria das Restrições (TOC) de Eliyahu Goldratt. Mais tarde, em março de 2005, visitei David na Microsoft, na época em que ele trabalhava de perto com fluxogramas cumulativos. Ainda mais tarde, em abril de 2007, tive a oportunidade de observar como funciona o inovador sistema kanban que ele implementou na Corbis.

Gostaria de alertar os leitores sobre algumas coisas. Primeiro, se você acha que sabe como os sistemas kanban funcionam, provavelmente está se referindo aos usados na manufatura enxuta. As ideias deste livro são muito mais avançadas do que os sistemas simples que usam limites de WIP estáticos, agendamento FIFO e uma única classe de serviço. Por favor, preste atenção a essas diferenças.

Resolvendo o Dilema do Gerente Ágil

No meu dia-a-dia em 2002 e no meu livro anterior(1), me preocupei principalmente com duas questões. Primeiro, como proteger a equipe das demandas cada vez maiores do negócio e alcançar o que hoje é chamado de “ritmo ideal” na comunidade ágil. E segundo, como posso implementar com sucesso uma abordagem ágil em toda a organização, superando a inevitável resistência à mudança?

Encontrando o ritmo certo

Em 2002, a comunidade ágil percebeu o ritmo ideal simplesmente como "40 horas semanais de trabalho"(2). Os princípios do Manifesto Ágil(3) afirmavam que “os processos ágeis promovem o desenvolvimento ideal. Patrocinadores, desenvolvedores e usuários devem estar preparados para manter um ritmo constante indefinidamente.” Dois anos antes, minha equipe na Sprint PCS ficava ouvindo de mim que "o desenvolvimento de software em escala é uma maratona, não um sprint". Se os membros da equipe mantivessem um ritmo constante durante o processo de trabalho em um projeto de um ano e meio, não poderiam se esgotar em um mês ou dois. O projeto tinha que ser planejado, orçado, cronometrado e avaliado para garantir que os membros da equipe passassem uma quantidade razoável de tempo trabalhando todos os dias e não estivessem muito cansados. Como gerente, minha tarefa era atingir esse objetivo e atender a todos os requisitos do negócio.

Quando eu estava no meu primeiro cargo gerencial (foi em 1991, em uma startup que fazia placas de captura de vídeo para computadores pessoais e menores), o CEO disse que a gestão tinha uma "opinião muito negativa" de mim. Eu sempre respondia "não" quando nossas oportunidades como desenvolvedores já estavam esgotadas e cada vez mais produtos ou recursos eram exigidos de nós. Em 2002, tornei-me um hábito: passei mais dez anos me recusando a obedecer aos caprichos dos empresários.

Sobre o livro
Um guia detalhado sobre kanban de um pioneiro kanban de 30 anos no desenvolvimento de software.

David Anderson, que implementou o método kanban em várias empresas e o aperfeiçoou constantemente, mostra como introduzir efetivamente ideias enxutas no desenvolvimento de tecnologia e operações de TI - com mínima resistência à mudança, mantendo o ritmo ideal para todos os funcionários envolvidos no trabalho .

O Kanban identifica rapidamente os problemas que afetam o desempenho e força a equipe a se concentrar em resolvê-los para manter o fluxo de trabalho. Ao tornar visíveis os problemas de qualidade e processo, o kanban oferece uma oportunidade de avaliar o impacto de defeitos, restrições, variabilidade e custos econômicos no fluxo de trabalho e no rendimento dos funcionários.

Simplesmente limitar os trabalhos inacabados por meio do Kanban resulta em melhor qualidade e produtividade do trabalho. A combinação de fluxo de trabalho simplificado e qualidade aprimorada ajuda a reduzir os prazos de entrega e melhora a previsibilidade e a probabilidade de entrega do trabalho no prazo. Ao estabelecer cadências de lançamento regulares e aderência consistente aos cronogramas, o kanban ajuda a construir confiança com os clientes e outros membros do fluxo de valor - outros departamentos, fornecedores e parceiros dependentes.

Foi comprovado que o Kanban aumenta a satisfação do usuário por meio de lançamentos regulares, confiáveis e de alta qualidade de software valioso. Também foi comprovado que melhora a produtividade, a qualidade e reduz o tempo de produção. Há evidências de que o kanban pode ser um catalisador para o surgimento de uma organização mais ágil por meio de uma mudança cultural evolutiva.

Este livro responde as perguntas:

- O que é Kanban?
Por que sua empresa precisa disso?
- Como implementá-lo?
- Como reconhecer oportunidades de melhoria nos negócios - e o que fazer com elas?

Para quem é este livro?
Para gerentes e chefes de empresas de TI.

Sobre o autor
David Anderson é o fundador da Lean Kanban University e da David J Anderson School of Management, dedicada a ajudar líderes e gerentes a alcançar melhores resultados por meio das melhores práticas.

Anderson tem 30 anos de experiência em empresas de tecnologia. Ele introduziu práticas de gerenciamento ágil para empresas como Motorola e Microsoft.

David foi o primeiro a usar Kanban no desenvolvimento de software em 2005.

Kanban significa "placa de sinalização" em japonês. Na fabricação, essa placa é usada para visualizar taxas crescentes, o que permite produzir mais produtos a um custo menor. Um exemplo notável é a abordagem da Toyota, graças à qual por muitos anos o princípio do "just in time" foi efetivamente implementado com custos mínimos.

David Anderson fornece um conjunto estendido de ideias (visualização do processo e regras de trabalho, digitação de itens de trabalho, classes de serviço, cadências, métricas e gráficos para análise e contabilidade gerencial) que definem o método kanban.

O livro descreve as ferramentas para introduzir efetivamente ideias enxutas no desenvolvimento de tecnologia e operações de TI com resistência mínima à mudança, mantendo um ritmo ideal para todos os funcionários envolvidos.

Publicado em russo pela primeira vez.

Detentores de direitos autorais! O fragmento apresentado do livro é colocado em acordo com o distribuidor de conteúdo legal LLC "LitRes" (não mais que 20% do texto original). Se você acredita que a postagem de material viola seus direitos ou de outra pessoa, por favor nos avise.

O mais fresco! Recibos de livros hoje

Testamento de Yvette Blanche
Demange Patricia
Periódicos

Suzanne se levantou da pedra e estava prestes a voltar para o carro quando ouviu uma voz:

- Venha! Venha até mim! Venha até mim! Venha!

E, como da primeira vez, essas palavras distintas foram seguidas por um soluço ininteligível. A garota congelou. A voz era tão queixosa que ela não conseguia se mexer.

E então ela ouviu estas palavras novamente:

"Venha, venha... venha para mim!" Venha!

De repente, pareceu a Susanna que seu cérebro iria explodir com essa frase. Por vários minutos ela ficou imóvel, mas então reuniu suas forças e correu para o carro estacionado sob as árvores. Ela rapidamente inseriu a chave de ignição e ligou o motor. Ela queria sair daqui o mais rápido possível. Desde que você não saiba ou ouça nada. Não pode ser! Ela é apenas Susanna Lambert, Susanna Lambert, Susanna Lambert...
Lobisomem
Moedor Alexandra
Periódicos

Ele seguiu Julia até o próprio pântano... A garota sentiu seu olhar sobre ela e ficou entorpecida de horror. As pernas imediatamente começaram a afundar cada vez mais no pântano frio. Precisamos sair daqui antes que seja tarde demais! Ela tentou se virar para o caminho: aqui está, terra firme, literalmente a um metro de distância... Mas havia algo muito mais perigoso do que um pântano fétido esperando por ela: um lobisomem coberto de lã cinza! Sua figura curvada de repente emergiu da escuridão. A cabeça maciça balançava lentamente no ritmo do vento, e nas profundezas das órbitas oculares, as brasas dos olhos brilhavam sinistramente em vermelho. Julia fez uma última tentativa de lidar com seu próprio medo, mas o horror a paralisou: ela não conseguia dar um passo. Uma criatura misteriosa que parecia um lobo, enquanto isso, estava se aproximando. Havia apenas alguns passos entre eles. Agora você já pode ver a lã cinza nas patas do monstro, aqui garras afiadas brilharam ao luar ...
Mago decidiu. Formação
Nazimov Konstantin
Efeitos colaterais

Um estudante, ele é um estudante em todos os lugares. Entretenimento e tentativas de ganhar. Uma das coisas de sempre levou a uma tragédia, e acabei... no mundo da magia. Boa sorte com isso, gostei. Eles até ajudaram e acabaram sendo ... um aluno, mas já na academia de magia e começou a trabalhar.

Mas a vida transforma pessoas e magos como quer. Este mundo não conhecia o grande planejador, com sua capacidade de ganhar dinheiro do nada. Ninguém construiu pirâmides financeiras. Portanto, posso me virar ao máximo. Mas, problemas sérios e golpes se foram. Uma das ideias acabou sendo tal que meus amigos e eu não conseguimos digerir o resultado. Eu tive que sair do meu caminho e levar as coisas para um nível completamente diferente. E é difícil puxá-lo: aqui está o ouro dos sacos de dinheiro e a guilda de ladrões, pessoas comuns e burocratas. E também problemas com artefatos e garotas, dívidas de cartão e belos carros. Você tem que decidir rapidamente, reagir instantaneamente. Eh, mas eu quero viver lindamente e espero que dê certo, embora não seja um fato...
senhora de branco
Gray Lara
Detetives e Suspense, Suspense

Todos os dias depois da meia-noite algo acontece no castelo...

Katerina entendeu que sua vida estava por um fio. Ela agarrou sua saia com uma mão para que a bainha não interferisse em sua corrida, a outra mão estava estendida para a frente para não bater a cabeça na parede. Finalmente uma porta! A garota a abriu abruptamente e saiu correndo do corredor. O perseguidor não ficou para trás: seus passos foram ouvidos cada vez mais claramente. Ele poderia alcançar Katerina a qualquer momento!

- Para ajuda! Para ajuda! a menina gritou. - Alguém! Ajuda!

Ela tropeçou em uma pedra e bateu forte, caindo no chão. Katerina rastejou para o lado e se escondeu. Felizmente, estava escuro, e o perseguidor passou correndo sem notá-la. Katerina olhou ao redor: estava deitada em um quarto escuro sem janelas, sem luz, nada se via...
Coringa de corrida. Jogo de sobrevivência
Nazimov Konstantin
Ficção, ficção heróica

O jogo não é como eu imaginei. Mentiras e traição, suborno e até escravidão andam de mãos dadas aqui. Existem jogadores normais, que são muitos, que tentam viver de acordo com as regras e honra. E acontece também que o preto é apresentado como branco, uma mentira para a verdade.

Pela vontade da mente da rede, tarefas e missões complexas são colocadas diante de mim, das quais eu nem suspeitava. As corridas de eliminação ou sobrevivência são substituídas pela fuga dos caçadores de recompensas. Temos que entrar em um confronto com a injustiça e a maldade. Para melhorar a vida de jogadores comuns que, em sua credulidade e ingenuidade, correram atrás de promessas e se viram em uma situação desesperadora. Pendure-se no jogo do mundo vizinho, onde os monstros se encontram a cada passo, e considere você nada além de suas presas. Sem tudo isso, você não pode alcançar a linha de chegada.

Ao longo do jogo, amigos e inimigos estão lado a lado comigo, alguns ajudam em momentos difíceis, outros estão prontos para enfiar uma faca nas minhas costas, mas tenho que confiar em mim e boa sorte. Uma meta é definida, a gasolina é despejada no tanque, um amuleto está no pescoço e o pé pressiona o pedal do acelerador no chão. A vitória virá e eu alcançarei meu objetivo! Espero que sim…
Fantasmas da névoa
Moedor Alexandra
Periódicos

Até agora, Elena não dava importância ao fato de o dono da casa de hóspedes onde ela ficar estava sozinho o tempo todo. Ela assumiu que sua esposa estava ocupada na cozinha ou ocupada com algum outro negócio e, portanto, não apareceu na frente dos convidados ...

Conjunto "Semana" - principais novos produtos - líderes para a semana!

2. Reitor Amaldiçoado
Lena de verão
Romances , Romances de ficção de amor , Ficção , Ficção policial ,

Eu tinha um ano para terminar. Um ano - e eu poderia ter a liberdade e a independência com que sonhava desde a infância. No entanto, a morte repentina e muito suspeita de minha mãe virou meu mundo de cabeça para baixo. Ela deixou muitas perguntas, e a única chance de encontrar respostas é ir para a universidade mais elitista da República. Achei que o esnobismo dos novos colegas seria meu principal problema, mas me enganei. As respostas que procuro podem me custar a vida e, por algum motivo, agora estou mais preocupado com a vida do reitor local, que está sob maldição.
Academia Arcturus. noiva loba
Cal Sylvia
Ficção, Ficção humorística

Às vezes a traição não é o fim, mas o começo.

Ocasionalmente - esta é a porta para outro mundo, onde a guerra está no limiar. Onde lobisomens lutam até a morte por suas mulheres e homens carregam armas com balas de prata. Onde um misterioso assassino vagueia, roendo as gargantas de todos que se parecem tanto com você. Onde sorrisos bem-humorados são uma chance certa de cair em uma armadilha, e um rosnado de lobo atrás de suas costas é uma chance de escapar.

Prepare-se, a academia de lobisomens está esperando por você aqui, um maníaco do lado de fora da porta e um homem misterioso que por algum motivo decidiu que pode vir até você à noite.

E tudo porque a traição não é o fim, mas apenas o começo.
Arcturus Academy 2. A esposa do lobo
Cal Sylvia
Fantasia, Cyberpunk

Dizem que a vida e a confiança se perdem apenas uma vez. Uma vez tive sorte, mas é improvável que a sorte esteja destinada a se repetir. O maníaco que mata as meninas é encontrado, mas o marionetista ainda está puxando as cordas de seus bonecos. A morte segue implacavelmente, e eu devo estar um passo à frente. Desta vez, para salvar não só a si mesma, mas também o lobisomem, com quem está ligada por laços inquebráveis. Ele é mais forte do que o resto, e esta é sua fraqueza. Para mantê-lo vivo, terei que traí-lo. Ou existe outra saída?

Portal para o aluno. Autotreinamento

* * *

Prefácio

Parte I Fundamentos

Capítulo 1 Resolvendo o Dilema do Gerente Ágil

Encontrando o ritmo certo

Em busca de uma gestão de mudanças bem-sucedida

Do tambor-tampão-corda ao kanban

O surgimento do método Kanban

Sobre o autor

Usando exemplos reais da vida da Microsoft, Motorola e Corbis, ele contou e mostrou os princípios, métodos e instruções para a implementação do kanban em uma empresa.

Carga semântica e essência do livro

Kaizen é a filosofia e a ética da relação entre os trabalhadores da fábrica e a administração.

A manufatura enxuta é um sistema de gerenciamento de projetos criado na Toyota para eliminar todo desperdício de tempo e recursos dos processos da empresa.

Limite de WIP (trabalho em andamento) — o número de tarefas que podem ser abertas ao mesmo tempo.

Gargalo - um momento no fluxo de trabalho em que há um sério problema limitação de recursos ou oportunidades. Nos diagramas, realmente parece um gargalo estreito de uma garrafa: antes e depois de tal situação, as linhas se expandem nos diagramas.

Estereótipos sobre Kanban

Kanban não é um quadro pegajoso, os adesivos são apenas um indicador de carga de trabalho.

Ágil, Scrum e Kanban

Agile é uma metodologia ágil com a qual a programação começou historicamente no formato de lançamento de atualizações nos programas a cada dois meses. As iterações de programação de algumas semanas para adicionar cada recurso aceleram o processo de desenvolvimento e reduzem o risco.

Este livro responde as perguntas:

O mais fresco! Recibos de livros hoje

Conjunto "Semana" - principais novos produtos - líderes para a semana!

ARTIGOS RELACIONADOS

Parte I
Fundamentos

Capítulo 1
Resolvendo o Dilema do Gerente Ágil