Desenvolvimento de Software enxuto

Por David J.Anderson.David J.Anderson é o autor de três livros, Lições no gerenciamento do Agile: Na estrada a Kanban, que foi publicado em 2012, Kanban: Alteração evolucionária com êxito para o negócio de tecnologia, [1] que foi publicado em 2010, e Gerenciamento do Agile para a tecnologia de programação: Aplicando a teoria das restrições de resultados de negócios, [2] que foi publicado em 2003.Ele foi um membro da equipe que criou o método de desenvolvimento de software Agile, Desenvolvimento orientado para recurso, em Cingapura entre 1997 e 1999.Criou MSF para CMMI a melhoria do processo, e co- criou a observação técnica do instituto de tecnologia de programação, “CMMI e agile: Porque não abraço dois!” Fosse um fundador de sociedade magra os sistemas (http://www.leansystemssociety.org).É CEO de ponto central Sem Gordura - Kanban Universidade Inc., um treinamento acreditado e a organização de padrões de qualidade que oferece o treinamento de Kanban em uma rede de parceiros em todo o mundo e dele leva uma training para uma empresa e gerenciamento de consultoria internacionais, E J.Anderson & Associates Inc.(http://www.agilemanagement.net) que ajuda os negócios de tecnologia melhorar seu desempenho com as melhores políticas de gerenciamento e tomada de decisão.

Em 2011 de novembro, novembro de 2012 atualizado.

Anderson descreve o Desenvolvimento de Software Magro.

Aplica-se a

Leve, desenvolvimento de software, gerenciamento de projeto, Team Foundation Server

• Introduction

• Leve e Agile

• Leve além do Agile

• Definindo um Desenvolvimento de Software Magro

• Valores

• Princípios

• Práticas

O termo Desenvolvimento de Software Magro foi inventado como título para uma conferência organizada por iniciativa da ESPRIT de União Europeia, em Stuttgart, na Alemanha, em outubro de 1992.Independentemente disso, no ano seguinte, Robert "Bob" Charette, em 1993 sugeriu o conceito de "Desenvolvimento de Software Leve" como parte de seu trabalho, explorar melhores formas de gerenciar risco em projetos de software.O termo “Software magro” data de 1991, sugerido por James Womack,r Daniel Jones e Daniel Roos, no livro The Machine That Changed the World: The Story of Lean Production[3] como o termo em inglês para descrever a abordagem de gerenciamento usada na Toyota.A ideia de que o software magro pode ser aplicável durante a programação do software foi estabelecido muito cedo, apenas 1 a 2 anos após o termo ter sido usado pela primeira vez em associação com as tendências nos processos de fabricação e de engenharia industrial.

No segundo livro, publicado em 1995, Womack e Jones[4] definiram cinco colunas principais do Pensamento Leve.Eram eles:

• Valor

• Fluxo de valor

• Fluxo

• Receptor

• Perfeição

Esta se tornou a definição padrão de trabalho para softwares magros na maior parte da próxima década.Sugeriu-se que a busca pela perfeição foi obtida eliminando o desperdício.Quando houve 5 pilares, foi no 5º, a busca da perfeição através da identificação sistêmica de atividades de desperdício e a sua eliminação, que realmente repercutiu em um grande público.O Leve tornou-se associada quase exclusivamente com a prática de eliminação de resíduo através dos anos 90 e o início do século XXI.

A definição de Womack e Jones para Software magro não é compartilhada universalmente.Os conceitos básicos de gerenciamento na Toyota são muito mais sutis.A palavra “desperdício”, em português, é descrita de uma forma muito mais rica com três termos japoneses:

• Muda – literalmente significando “desperdício”, mas inferindo uma atividade inútil adicionada

• Mura – significando ”irregularidade“, mas interpretado como “variabilidade no fluxo”

• Muri – significando “sobrecarga” ou “irracionalidade”

Para alcançar a perfeição, as atividades sem valor agregado são reduzidas. Além disso, o fluxo é suavizado e a sobrecarga, eliminada.Além disso, a abordagem Toyota foi baseada em um respeito básico para pessoas e fortemente influenciada pelos ensinamentos da garantia de qualidade do século XX e especialistas no controle do processo estatístico, tais como W.Edwards Deming.

Infelizmente, há quase tantas definições para Magro quanto autores no assunto.

Leve e Agile

Bob Charette foi convidado mas não pode participar da reunião de 2001 em Snowbird, Utah, onde o Manifesto para Desenvolvimento de Software Agile [5] foi criado.Apesar de perder esta reunião histórica, o Desenvolvimento de Software Magro foi considerado como uma das várias abordagens da Agile para o desenvolvimento de software.Jim Highsmith dedicou um capítulo no seu livro de 2002[6] para uma entrevista com Bob sobre o tópico.Posteriormente, Mary & Tom Poppendieck continuaram com o autor sobre uma série de 3 livros[7, 8, 9].Durante os primeiros anos do século XXI, os princípios Magros foram usados para explicar porque os métodos Ágeis eram melhores.O Leve explicado que os métodos Agile contém pouco "resíduo" e, portanto, produziu um melhor resultado econômico.Princípios leves foram usados como um"doador de permissão" para adotar métodos do Agile.

Leve além do Agile

Nos últimos anos, o Desenvolvimento de Software Leve realmente emergiu como disciplina própria relacionada, mas não especificamente, a um subconjunto do movimento Agile.Essa evolução iniciou com a síntese das ideias do Desenvolvimento de Produtos de Software Magro e do trabalho de Donald G.Reinertsen[10,11] e ideias emergentes do mundo não Agile de engenharia de sistemas de grande escala e os trabalhos de James Sutton e Peter Middleton[12].Eu também sintetizei o trabalho de Eli Goldratt e W.Edwards Deming e desenvolveu um foco no fluxo em vez da redução de lixo[13].A pedido de Reinertsen por volta de 2005, eu introduzi o uso dos sistemas kanban que limitam o trabalho em andamento e o novo trabalho "puxar" somente quando o sistema está pronto para processamento.Alan Shalloway adicionou seus pensamentos no desenvolvimento de software Magro em seu livro de 2009 no tópico [14].Desde 2007, o surgimento do Lean à medida que uma nova força no progresso de profissão de desenvolvimento de software foi focalizada em melhorar o fluxo, em gerenciar o risco, e em melhorar a tomada de decisões (de gerenciamento).Kanban se tornou um elemento importante para as iniciativas Leves no trabalho relacionado a TI.Parece que um foco no fluxo, em vez de um foco na eliminação de resíduos, está se mostrando um melhor catalisador para a melhoria contínua dentro das atividades de trabalho do conhecimento, tais como o desenvolvimento de software.

Definindo um Desenvolvimento de Software Magro

Definir o Desenvolvimento de Software Magro é desafiador porque não há nenhum método ou processo de Desenvolvimento de Software Magro específico.O Leve não é um equivalente do Processo de Software Pessoal, Modelo em V, Modelo em Espiral, EVO, Desenvolvimento de Recurso Orientado, Programação Extrema, Scrum ou Desenvolvimento de Teste Orientado.Um processo de ciclo de vida de desenvolvimento de software ou um processo de gerenciamento de projetos pode ser chamado "magro" se foi verificado como alinhado com os valores do movimento de Desenvolvimento de Software Magro e os princípios de Desenvolvimento de Software Magro.Aqueles que antecipam uma receita simples que pode ser seguida e chamada de Desenvolvimento de Software Lean serão decepcionados.Você deve formar ou personalizar seu próprio processo de programação de software por meio do entendimento dos princípios Magros e adotando os valores principais do Magro.

Há várias escolas de pensamento dentro do Desenvolvimento de Software Magro.O maior, e resultar teoricamente, escola são a sociedade magra os sistemas, que inclui Donald Reinertsen, Jim Sutton, Alan Shalloway, Bob Charette, Mary Poppendeick, e David J.Anderson.Mary de trabalho e de Tom Poppendieck desenvolvido antes de training de sociedade e seus oferece suporte de credo separada, como o trabalho de Craig Larman, de Bas Vodde15,16 [], e, mais recentemente, Jim de Coplien17 [].Pesquisas deste artigo ser amplamente representante do ponto de vista magro de sociedade de sistemas como expresso em seu credo e fornecer uma síntese e um resumo das suas exibições.

Valores

A sociedade magra os sistemas publicou o credo18 [] em 2012 conferência19 []magra de software e os sistemas.Isso foi baseado em um conjunto de valores publicados um ano anterior.Esses valores são:

• Aceitar a condição humana

• Aceitar que a complexidade e a incerteza são naturais ao trabalho de conhecimento

• Funcionar para obter um Resultado Econômico melhor

• Ao ativar um melhor Resultado Sociológico

• Busque, adote e questione ideias de uma ampla variedade de disciplinas

• Uma comunidade baseada em valor melhora a velocidade e profundidade da alteração positiva

Aceitar a Condição Humana

O trabalho do conhecimento como a programação de software é empreendido por seres humanos.Nós seres humanos somos complexos de forma inerente e, como pensadores lógicos, somos levados também por nossas emoções e por alguns traços animalistas inerentes que não podem ser superados de forma aceitável.Nossa psicologia e nossa neuropsicologia devem ser levadas em consideração durante a criação dos sistemas ou dos processos nos quais trabalhamos.Nosso comportamento social também deve ser acomodado.Os seres humanos são inerentemente emocionais, sociais e tribais e nosso comportamento muda com fadiga e estresse.Os processos com sucesso serão aqueles que abordem e acomodem a condição humana em vez do que aqueles que tentam negar e assumir o comportamento como máquina, lógico.

Aceitar que a Complexidade e a Incerteza são Naturais ao Trabalho de Conhecimento

O comportamento de clientes e dos mercados são imprevisíveis.O fluxo de trabalho em um processo e uma coleção de trabalhadores é imprevisível.Os defeitos e o retrabalho necessário são imprevisíveis.Há uma chance inerente ou um comportamento aparentemente aleatório em vários níveis no desenvolvimento de software.A finalidade, as metas e o escopo dos projetos tendem a ser alterados enquanto estão sendo entregues.Parte dessa incerteza e variabilidade, embora desconhecida inicialmente, é reconhecível no sentido de que pode ser estudada e quantificada e seus riscos podem ser gerenciados, mas certa variabilidade não pode ser reconhecida antecipadamente.Como resultado, os sistemas do Desenvolvimento de Software Magro devem ser capazes reagir a eventos subsequentes e o sistema deve ser capaz se adaptar às condições alteradas.Portanto, qualquer processo de Desenvolvimento de Software Magro deve existir em uma estrutura que permite a adaptação (do processo) para desdobrar eventos.

Funcionar para obter um Resultado Econômico melhor

As atividades humanas como o Desenvolvimento de Software de Inclinação devem ser centradas na produção de um melhor resultado econômico.O capitalismo é aceitável quando contribui para o valor do negócio e o benefício do cliente.Os investidores e os proprietários de negócios merecem uma retorno sobre o investimento.Os funcionários e trabalhadores merecem uma taxa de pagamento justa para um esforço adequado ao executar o trabalho.Os clientes merecem um bom produto ou serviço que fornece seus benefícios prometidos em troca de um preço justo.Os melhores resultados econômicos envolverão a entrega de mais valor para o cliente, em menor custo, ao gerenciar o capital implantado por investidores ou proprietários da maneira mais eficaz possível.

Ativar um resultado sociológico melhor

Os melhores resultados econômicos não devem ser enviados às custas daqueles que executam o trabalho.Criar um local de trabalho que respeita as pessoas aceitando a condição humana e forneça sistemas de trabalho que respeitam a natureza psicológica e sociológica de pessoas é essencial.Criar um ótimo local para fazer um ótimo trabalho é um valor principal da comunidade de Desenvolvimento de Software Magro.

Princípios

A comunidade Lean Software & Systems aparece estar de acordo com alguns conceitos básicos que sustentam os processos de Desenvolvimento de Software Magro.

• Siga um pensamento de sistemas e abordagem de design

• Os resultados emergentes podem ser influenciados pela Arquitetura do Contexto de um sistema adaptável complexo

• Respeite as pessoas (como parte do sistema)

• Use o Método Científico (para conduzir as melhorias)

• Incentivo à liderança

• Gerar visibilidade (no trabalho, no fluxo de trabalho e na operação do sistema)

• Reduzir Tempo de Fluxo

• Reduzir o desperdício e melhorar a eficiência

Siga um pensamento de sistemas e abordagem de design

Isso é normalmente conhecido, na literatura de software magro, como “otimizar o todo”, o que indica que é a saída de todo o sistema (ou processo) que desejamos otimizar, e não devemos equivocadamente otimizar partes esperando que elas magicamente otimizem o todo.A maioria dos profissionais acredita que o corolário é verdadeiro, que a otimização de partes (otimização local) leva a um resultado de qualidade inferior.

Uma Abordagem de Design e Pensamento para Sistemas Magros exige a consideração das demandas no sistema realizada por participantes externos, como clientes, e o resultado desejado solicitado por esses participantes.Nós devemos estudar a natureza de demanda e compará-la ao recurso do nossa sistema de entrega.A demanda incluirá o chamado “demanda de valor", para os clientes que estão dispostos pagar e "demanda de falha“, que é normalmente retrabalho ou demanda causada por uma falha no fornecimento de demanda de valor.A demanda de falha frequentemente tem duas formas: o retrabalho na demanda de valor entregado anteriormente e serviços adicionais ou suporte para uma falha ao fornecer a demanda de valor.No desenvolvimento do software, a demanda de falha é normalmente solicitada para correções e solicitações de bug para a função de atendimento e help desk ao cliente.

Uma abordagem de design de sistemas exige que nós também seguimos a abordagem Planejar-Fazer-Estudar-Agir (PDSA) para processar o design e a melhoria.W.Edwards Deming usou as palavras “estudar” e “capacidade” para implicar que nós estudamos a filosofia natural da comportamento do nosso sistema.Esse sistema consiste em nosso processo de desenvolvimento de software e todas as pessoas que o operam.Ele terá um comportamento observável em termos de tempo de espera, qualidade, quantidade de recursos ou funções entregues (conhecido na literatura Agile como a "velocidade"), e assim por diante.Essas métricas irão exibir variabilidade e, estudando o meio e a extensão da variação, podemos desenvolver uma compreensão de nosso recurso.Se este é incompatível com as expectativas de demanda e do cliente, então o sistema precisará ser remodelado para fechar a lacuna.

A demanda também ensinou que a capacidade é 95% influenciada pelo design do sistema e somente 5% é contribuído pelo desempenho de indivíduos.Em outras palavras, podemos respeitar as pessoas não responsabilizando-as por um intervalo na capacidade em relação à demanda e por reformular o sistema que lhes permite ser bem-sucedido.

Para entender o design do sistema, precisamos ter uma compreensão científica de dinâmica de recurso do sistema e como pode ser afetado.Os modelos são desenvolvidos para prever a dinâmica do sistema.Quando há muitos modelos possíveis, vários populares estão em uso comum: a compreensão do custo econômicos; os conhecidos custos de transação e coordenação relacionados à produção de produtos ou de serviços de valor do cliente; a teoria de restrições – a compreensão de gargalos; e a teoria de conhecimento profundo – o estudo e o reconhecimento de variabilidade comuns ao design de sistemas ou especiais e externo ao design do sistema.

Os resultados emergentes podem ser influenciados pela Arquitetura do Contexto para um sistema adaptável complexo

Os sistemas complexos possuem condições iniciais e regras simples que, quando executados iterativamente, geram um resultado emergente.Os resultados emergentes são difíceis ou impossíveis de prever dado as condições iniciais.A experiência da ciência da computação "O jogo da vida" é um exemplo de um sistema complexo.Um sistema adaptável complexo tem dentro dele alguma consciência autodescritiva e um método interno de reflexão que permite considerar quão bem seu conjunto atual de regras está permitindo obter um resultado desejado.O sistema adaptável complexo pode escolher se adaptar – para alterar as regras simples – para fechar o intervalo entre o resultado atual e o resultado desejado.A adaptação do Jogo da Vida para que as regras pudessem ser reescritas durante o jogo seria um sistema adaptável complexo.

Nos processos de desenvolvimento de software, as "regras simples" de sistemas adaptativos complexos são as políticas que compõem a definição do processo.O princípio básico aqui é baseado na crença que o desenvolver de produtos de software e serviços não é uma atividade determinística e, portanto, um processo definido que não possa se adaptar não será uma resposta suficiente para os eventos imprevisíveis.Portanto, o processo criado como parte de nossos pensamento do sistema e abordagem de design deve ser adaptável.Adapta-se através da modificação das políticas de que é feito.

A abordagem Kanban para o Desenvolvimento de Software Magro utiliza esse conceito tratando as políticas do sistema kanban de recebimento como as “regras simples”, e as condições iniciais são que o trabalho e o fluxo de trabalho são visualizados, que o fluxo é gerenciado usando uma compreensão da dinâmica do sistema, e que a organização usa uma abordagem científica para compreender, propor e implementar melhorias no processo.

Respeite as pessoas

A comunidade Lean adota a definição de Peter Drucker de trabalho do conhecimento, que afirma que os trabalhadores são trabalhadores do conhecimento se tiverem mais conhecimento sobre o trabalho que exercem do que seus chefes.Isso cria uma implicação de que os trabalhadores estão em melhor posição para tomar decisões sobre como realizar o trabalho e como modificar os processos para melhorar como o trabalho é executado.Portanto a opinião do trabalhador deve ser respeitada.Os funcionários devem ser autorizados a se organizar sozinhos para concluir o trabalho e obter os resultados desejados.Eles também deveriam estar autorizados a sugerir e implementar oportunidades de melhoria de processo ou “eventos kaizen”, como são conhecidos na literatura de software magro.Fazer políticas de processo explícito para que os trabalhadores estejam cientes das regras que restringem é uma outra maneira de respeitá-los.As regras claramente definidas incentivam a auto-organização removendo o medo e a necessidade de coragem.Respeitar as pessoas, estimulando-as e fornecendo a elas um conjunto de políticas explicitamente declaradas, é a essência do respeito à condição humana.

Use o Método Científico

Procure usar modelos para entender a dinâmica de como o trabalho é feito e como o sistema de desenvolvimento de software Lean está funcionando.Observe e estude o sistema e seus recursos e, em seguida, desenvolva e aplique modelos para prever seu comportamento.Colete dados quantitativos em seus estudos e use os dados para compreender como o sistema está executando e para prever como pode mudar quando o processo é alterado.

A Lean Software & Systems utiliza métodos gráficos estatísticos, como gráficos de controle de processos estatísticos e histogramas de análise espectral de dados brutos para que a velocidade e tempo de execução compreendam o recurso do sistema.Também usam modelos como: a teoria de restrições para entender gargalos; o sistema de conhecimento profundo para entender a variação interna ao design do sistema versus a que é influenciada externamente; e uma análise dos custos econômicos na forma de tarefas executadas apenas para coordenar, configurar, entregar ou limpar produtos ou serviços de valor para o cliente que são criados.Alguns outros modelos estão entrando em uso, como a teoria da Opção Real, que procura aplicar a teoria da opção financeira, oriunda do gerenciamento de riscos financeiros, à tomada de decisões no mundo real.

O método científico sugere: nós estudamos; nós postulamos um resultado baseado em um modelo; nós perturbamos o sistema com base nessa previsão; nós observamos novamente para ver se a perturbação gerou os resultados que o modelo previu.Caso contrário, então vamos verificar os dados e reconsiderar se o nosso modelo está correto.O uso de modelos para conduzir aprimoramentos do processo muda isso para uma atividade científica e o tira de uma atividade supersticiosa baseada em intuição.

Incentivo à liderança

A liderança e o gerenciamento não é a mesma.O gerenciamento é a atividade dos processos de design, criação, modificação e exclusão da política, tomando decisões estratégicas e operacionais, reunindo recursos, fornecendo financiamentos e facilidades e comunicando informações sobre contextos, como estratégia, metas e resultados desejados.A liderança é sobre a visão, a estratégia, as táticas, a coragem, a inovação, o julgamento, a defesa, e muitos outros atributos.A liderança pode e deve vir de qualquer um dentro de uma organização.Pequenos atos de liderança dos trabalhadores vão criar uma cascata de melhorias resultarão nas alterações necessárias para criar um processo de Desenvolvimento de Software Lean.

Gera visibilidade

O trabalho do conhecimento é invisível.Se você não consegue ver alguma coisa, é (quase) impossível controlá-lo.É necessário gerar visibilidade no trabalho que está sendo realizado e o fluxo deste trabalho através de uma rede de indivíduos, habilidades, e departamentos até que esteja concluído.É necessário criar visibilidade no design do processo encontrando maneiras de visualizar o fluxo do processo e tornando as políticas do processo explícitas para que todos possam consultar e considerar.Quando todas essas coisas são visíveis, então o uso do método científico é possível e as conversações sobre aperfeiçoamentos potenciais podem ser colaboradoras e objetivas.A melhoria do processo colaborativo é quase impossível se o trabalho e o fluxo de trabalho estão invisíveis e se as políticas de processo não são explícitas.

Reduzir Tempo de Fluxo

O profissional de programação de software e os acadêmicos que estudam engenharia de software focaram tradicionalmente em medir o tempo gasto em uma atividade.A comunidade de desenvolvimento de Software Magro descobriu que pode ser mais útil medir o tempo real decorrido no calendário para algo ser processado.Isso é normalmente conhecido como Tempo de Ciclo, e geralmente qualificado pelos limites das atividades executadas.Por exemplo, o Tempo de Ciclo com a Análise para Pronto para Implantação deveriam medir o tempo decorrido total para um item de trabalho, como uma história de usuário, a ser analisada, criada, desenvolvida, testada de várias maneiras e colocadas em fila pronta para implantação em um ambiente de produção.

Focalizar no tempo que o trabalho leva para percorrer pelo processo é importante de várias maneiras.Um tempo de ciclo mais longo têm sido mostrado para correlacionar com um crescimento não-linear da taxa do bug.Portanto, um tempo de ciclo mais curto leva a uma qualidade maior.Isso é contra-intuitivo, pois pareceria ridículo que os bugs pudessem ser inseridos em código enquanto estivessem em fila, com nenhum humano de fato tocando neles.Tradicionalmente, a profissão de engenheiro de programação e os acadêmicos que a estudam ignoraram esse tempo ocioso.No entanto, a evidência empírica sugere que o tempo de ciclo seja importantes para a qualidade inicial.

Alan Shalloway também falou sobre o conceito de “trabalho induzido”. Sua observação é que uma latência ao executar uma tarefa pode resultar nessa tarefa levando muito mais esforço do que pode precisar.Por exemplo, um erro encontrado e corrigido imediatamente pode levar apenas 20 minutos para corrigir, mas se o bug analisado, é colocada na fila e aguarda por vários dias ou últimas semanas para ser corrigido, podendo envolver várias ou muitas horas para realizar a correção.Portanto, o tempo de atraso do ciclo "induziu" o trabalho adicional.Como este trabalho é evitável, em termos Magros, deve ser considerado como “desperdício”.

A terceira razão para focar no tempo de ciclo é uma razão relacionada ao mercado.Cada recurso, função ou história do usuário tem um valor.O valor pode ser incerto, mas entretanto, há um valor.O valor pode variar ao longo do tempo.O conceito de valor variando ao longo do tempo pode ser expresso economicamente como uma função de recompensa do mercado.Quando a função de recompensa do mercado para um item de trabalho for compreendida, mesmo que a função exiba uma distribuição de valores para a incerteza, é possível avaliar um “custo do atraso.” Os custos de atraso permitem que nós coloquemos um valor em redução do tempo de ciclo.

Com alguns itens de trabalho, a função de recompensa do mercado não começa até uma data conhecido no futuro.Por exemplo, um recurso projetado para ser usado durante o feriado de 4 de junho nos Estados Unidos não tem valor antes desta data.Reduzir o tempo de ciclo e ser capaz de prever o tempo de ciclo com alguma certeza ainda é útil em tal exemplo.Idealmente, queremos iniciar o trabalho para que o recurso seja entregue "a tempo", quando é necessário e não significativamente antes da data desejada, não depois, com atraso na entrega incorrendo em um custo de atraso.A entrega just-in-time garante que o uso otimizado é feito de recursos disponíveis.A entrega inicial implica que nós talvez tenhamos trabalhado em algo diferente e temos, por implicação, incorrido uma oportunidade de custo de atraso.

Como resultado desses três motivos, o Desenvolvimento de Software Magro procura minimizar tempo de fluxo e registrar os dados que permitem previsões sobre o tempo de fluxo.O objetivo é minimizar a demanda de falha de erros, desperdício de sobrecarga devido ao atraso na correção de erros, e maximizar o valor oferecido evitando o custo de atraso e o custo de oportunidade de atraso.

Reduzir o desperdício e melhorar a eficiência

Para cada atividade de valor adicionado, há as atividades de configuração, limpeza e entrega necessárias, mas não adiciona valor em seu próprio direito.Por exemplo, uma iteração de projeto que desenvolve um incremento do software de trabalho requer um planejamento (uma atividade de configuração), um ambiente e talvez uma ramificação de código em controle de versão (conhecidos coletivamente como gerenciamento de configuração e também uma atividade de configuração), um plano de versão e executar a versão atual (uma atividade de entrega), uma demonstração para o cliente (uma atividade de entrega) e talvez um detalhamento de ambiente ou uma reconfiguração (uma atividade de limpeza.) Em termos econômicos, a configuração, limpeza, e atividades de entrega são os custo de transação sobre a realização do trabalho de valor agregado.Esses custos (ou sobrecargas) são considerados desperdício no software magro.

Qualquer forma de sobrecarga de comunicação pode ser considerado lixo.As reuniões para determinar o status do projeto e para agendar ou atribuir o trabalho para membros da equipe devem ser considerados um custo de coordenação na linguagem econômica.Todos os custos de coordenação são desgastados no pensamento Magro.Métodos de desenvolvimento de software leve procura eliminar ou reduzir custo de coordenação através do uso da colocação de membros da equipe, reuniões frente a frente curtas como displays em tamanho natural e controles visuais como paredes de cartões.

A terceira forma mais comum de desperdício no Desenvolvimento de Software Magro é a falha na demanda.A demanda de falha é uma carga no sistema de desenvolvimento de software.A demanda de falha é normalmente retrabalho ou novas formas de trabalho geradas como um efeito colateral de má qualidade.Os formulários mais comuns de demanda de falha na programação de software são bugs, defeitos de produção e atividades de suporte ao cliente excluídas de uma falha ao usar o software de forma pretendida.A porcentagem de trabalho em andamento de demanda de falha é normalmente conhecida como Carga de Falha.A porcentagem de trabalho que agrega valor em relação à demanda de falha é uma medida da eficiência do sistema.

A porcentagem de trabalho de valor agregado em relação ao trabalho total, incluindo qualquer valor que não adiciona custo de transação e de coordenação, determina o nível de eficiência.Um sistema sem custo de transação e de coordenação e nenhuma falha de carregamento deve ser considerada 100% eficiente.

Tradicionalmente, a ciência de gerenciamento ocidental ensinou que a eficiência pode ser melhorada com o aumento do tamanho de lotes de trabalho.Normalmente, a transação e custo de coordenação são fixos ou aumentam apenas ligeiramente com um aumento no tamanho do lote.Como resultado, os maiores lotes de trabalho são mais eficientes.Esse conceito é conhecido como “economia de escala.” No entanto, em problemas de trabalho de conhecimento, os custos de coordenação tendem a aumentar não linearmente com o tamanho do lote, enquanto os custos de transação geralmente podem exibir um crescimento linear.Como resultado, a abordagem do século XX tradicional para eficiência não é apropriada para problemas de trabalho de conhecimento como o desenvolvimento de software.

É melhor para focar na redução das despesas gerais, mantendo o tamanho dos lotes pequenos, a gim de melhorar a eficiência.Portanto, a maneira Magra de ser eficiente é reduzir o desperdício.Os métodos de desenvolvimento de software leve focalizam sobre métodos de planejamento rápidos e baratos; baixa sobrecarga de comunicação; mecanismos de coordenação de sobrecarga de baixa eficácia, tais como controles visuais nos sistemas kanban.Também incentivam testes automatizados e implantação automatizada para reduzir os custos de transação de entrega.As ferramentas modernas que minimizam os custos de desmontagem e configuração de ambientes, como os sistemas modernos de controle de versão e o uso de virtualização, também ajudam a melhorar a eficiência de pequenos lotes de desenvolvimento de software.

Práticas

Desenvolvimento de Software Leve não prescreve práticas.É mais importante demonstrar que as definições de processo reais estão alinhadas com os princípios e os valores.No entanto, um número de práticas estão sendo adotadas normalmente.Essa seção fornece uma breve visão geral de alguns desses.

Fluxogramas cumulativos

Os fluxogramas cumulativos tem sido uma parte padrão de relatório no Team Foundation Server desde 2005.Os fluxogramas cumulativos plotam um gráfico da área de itens de trabalho cumulativos em cada estado de um fluxo de trabalho.Eles são ricos em informações e podem ser usados para derivar o tempo médio de ciclo entre as etapas de um processo, bem como a taxa de transferência (ou "velocidade").Os diferentes processos do ciclo de vida de desenvolvimento de software geram diferentes assinaturas visuais em fluxogramas cumulativos.Os profissionais podem aprender a reconhecer padrões de disfunção no processo exibido no gráfico de área.Um processo realmente Magro mostrará as áreas de cor igualmente distribuídas, surgindo suavemente em um ritmo constante.A imagem irá aparecer suave sem etapas serrilhadas ou blocos de cor visíveis.

Na sua forma mais básica, os diagramas de fluxo cumulativos são usados para visualizar a quantidade de trabalho em andamento em qualquer estágio dado no ciclo de vida do item de trabalho.Isso pode ser usado para detectar gargalos e observa os efeitos de “mura” (variabilidade no fluxo).

Controles visuais

Além do uso de diagramas de fluxo acumulado, as equipes de Programação de Software Leves usam placas físicas, ou projeções de sistemas de visualização eletrônica, para visualizar o trabalho e observar seu fluxo.Tais membros da equipe de ajuda de visualizações observam a acumulação do trabalho em andamento e habilita para ver afunilamentos e os efeitos de "muro". Os controles visuais também permitem aos membros da equipe se auto-organizarem para escolher trabalhos e colaborar em conjunto sem planejamento ou gerenciamento específico ou intervenção.Esses controles visuais são geralmente denominados “card walls” ou às vezes (incorretamente) “kanban boards”.

Sistemas virtuais Kanban

Um sistema kanban é uma prática adotada de fabricação magra.Ele usa um sistema de cartões físicos para limitar a quantidade de trabalho em andamento em qualquer estágio determinado no fluxo de trabalho.Tais sistemas limitados de trabalho em andamento criam um “recebimento” onde o trabalho é iniciado somente quando há um kanban livre indicando que o trabalho pode ser "recebido" em um estado específico e o trabalho pode progredir a partir dele.

No Desenvolvimento do Software Leve, os kanbans são virtuais e geralmente controlados pela definição de um número máximo para uma determinada etapa no fluxo de trabalho de um tipo de item de trabalho.Em algumas implementações, os sistemas eletrônicos acompanham o kanban virtual e fornece um sinal quando o novo trabalho pode ser iniciado.O sinal pode ser visual ou na forma de um alerta, como um email.

Os sistemas virtuais Kanban são combinados com frequência com os controles visuais para fornecer um sistema visual kanban virtual que representa o fluxo de trabalho de um ou vários tipos do item de trabalho.Esses sistemas são geralmente chamados “placas kanban” ou “sistemas kanban eletrônicos". Um sistema kanban virtual visual está disponível como um plug-in para o Team Foundation Server, chamado Visual WIP [20].Esse projeto foi desenvolvido como código aberto por Hakan Forss, na Suécia.

Tamanhos pequenos de lotes/fluxo de uma só parte

Desenvolvimento de Software Leve requer que o trabalho seja empreendido em lotes pequenos, geralmente denominados "iterações" ou "incrementos", ou que itens de trabalho fluem independente, conhecidos como "o fluxo de parte única". O fluxo de parte única requer uma estratégia de gerenciamento de configuração sofisticada para ativar o trabalho concluído seja entregue quando o trabalho incompleto não é liberado acidentalmente.Isso é normalmente alcançado usando estratégias de ramificação no sistema de controle de versão.Um lote pequeno de trabalho normalmente seria considerado um lote que pode ser empreendido por uma equipe pequena de 8 ou menos pessoas em 2 semanas.

Os lotes pequenos e o fluxo de uma só parte requer interação frequente com proprietários de negócios para reabastecerem o backlog ou a fila ou o trabalho.Também requerem um recurso para liberar com frequência.Para ativar a interação frequente com executivos e entrega frequente, é necessário reduzir o custo de transação e de coordenação de ambas as atividades.Uma maneira comum de fazer isso é o uso de automação.

Automação

Desenvolvimento de Software Leve espera um alto grau de automação para ativar economicamente o fluxo de uma parte e incentivar a alta qualidade e a redução de falha na demanda.O uso de testes automatizados, implantação automatizada e fábricas de software para automatizar a implantação de padrões de design e a criação de seções repetitivas de variabilidade baixa do código de origem serão comuns nos processos de Desenvolvimento de Software Magro.

Eventos Kaizen

Na literatura leve, o termo kaizen significa "melhoria contínua" e um evento kaizen é o ato de fazer uma mudança em um processo ou a ferramenta que esperamos que resulte em uma melhora.

Os processos de Desenvolvimento de Software Leve usam várias atividades diferentes para gerar eventos kaizen.Eles são listados aqui.Cada uma dessas atividades é projetada para estimular uma conversa sobre os problemas que podem prejudicar a capacidade e, portanto, a habilidade de entregar uma demanda.A essência de kaizen no trabalho de conhecimento é a de que devemos estimular conversas sobre problemas em grupos de pessoas de equipes diferentes e com diferentes habilidades.

Reuniões standup diárias

As equipes de desenvolvedores de software, geralmente até 50, normalmente se encontram através de um sistema de controle visual como um painel exibindo uma visualização de seu trabalho em andamento.Eles abordam a dinâmica de fluxo e os fatores que afetam o fluxo de trabalho.É dada atenção especial a trabalhos bloqueados externamente e a trabalhos atrasados devido a bugs.Geralmente , problemas com o processo se tornam evidentes após uma série de reuniões diárias.O resultado é que um grupo menor pode permanecer após a reunião para discutir o problema e propor uma solução ou uma alteração no processo.Um evento de kaizen irá ocorrer.Essas reuniões espontâneas são geralmente chamadas de círculos espontâneos de qualidade, na literatura antiga.Como reuniões espontâneas que estão realmente no centro de uma cultura de kaizen.Os gerentes estimulam o surgimento de eventos kaizen após reuniões standup diárias, a fim de impulsionar a adoção do Leve dentro de sua organização.

Retrospectivas

As equipes de projeto podem agendar reuniões regulares para refletir no desempenho recente.Geralmente eles são feitos depois que entregáveis específicos do projeto estejam concluídos ou depois de incrementos de timeboxing conhecidos com iterações ou sprints no desenvolvimento ágil de software.

As retrospectivas normalmente usam uma abordagem prática para reflexão ao fazer perguntas como “o que deu certo?”, “o que nós faríamos de maneira diferente?” e “o que devemos parar de fazer”?

As retrospectivas normalmente produzem uma reserva de sugestões para eventos kaizen.A equipe pode dar prioridade a alguns deles para a implementação.

Análises de Operações

Uma revisão das operações normalmente é maior do que uma retrospectiva e inclui representantes de um fluxo de valor completo.É comum para até 12 departamentos apresentar o objetivo, os dados quantitativos que mostram a demanda que eles receberam e reflete a sua capacidade de entregar contra a demanda.Geralmente, as análises de operações são realizadas uma vez por mês.As principais diferenças entre uma revisão de operações e uma retrospectiva é que revisões de operações abrangem um conjunto maior de funções, abrange normalmente um portfólio de projetos e outras iniciativas, e usa dados objetivos e quantitativos.As retrospectivas, em comparação, tendem a ter o escopo de um único projeto; envolve apenas algumas equipes como a análise, o desenvolvimento e o teste; e normalmente são de natureza prática.

Uma revisão das operações provocará discussões sobre a dinâmica que afeta o desempenho entre equipes.Talvez uma equipe gere uma demanda de falha processada por outra equipe?Talvez essa demanda de falha interrompa o trabalho e faça com que a segunda equipe não cumpra compromissos e não atenda às expectativas?Uma revisão das operações fornece uma oportunidade para discutir tais problemas e de propor alterações.As análises de operações produzem uma pequena lista de pendências de possíveis eventos kaizen que podem ser priorizados e agendados para futura implementação.

Não existe nenhum processo único de Desenvolvimento de Software Magro.Um processo pode ser chamado de Magro se está claramente alinhado com os valores e princípios de Desenvolvimento de Software Magro.Desenvolvimento de Software Leve não prescreve nenhuma prática, mas algumas atividades se tornam comuns.As organizações leves procuram incentivar kaizen através da visualização do fluxo de trabalho e trabalho em progresso e através de uma compreensão de dinâmicas do fluxo e os fatores (tais como estrangulamentos, disponibilidade não instantânea, variabilidade e resíduos) que o afetam.Aperfeiçoamentos de processo são sugeridos e justificados como maneiras de reduzir fontes de variabilidade, eliminar o desperdício, melhorar o fluxo, ou ainda melhorar o fornecimento de valor ou o gerenciamento de riscos.Como tal, os processos de Desenvolvimento de Software Magro sempre estarão evoluindo e são personalizados exclusivamente para a organização na qual evoluem.Não será natural simplesmente copiar uma definição de processo de uma organização para outra e esperar que ele funcione em um contexto diferente.Também será improvável que retornando a uma organização após alguns semanas ou meses para encontrar o processo em uso para ser o mesmo que foi observado anteriormente.Sempre estará evoluindo.

A organização que usa um processo de desenvolvimento de software magro poderia ser chamada de magra se exibisse somente pequenas quantidades de desperdício em todos os três formas (“mura", ” muri “,” e “muda ") e poderia ser mostrada otimizando a entrega de valor através do gerenciamento efetivo de risco.A busca pela perfeição em software magro é sempre uma jornada.Não há nenhum destino.As verdadeiras organizações magras estão sempre buscando uma melhoria adicional.

Desenvolvimento de Software Leve ainda é um campo emergente, e podemos aguardar para continuar a evoluir durante a próxima década.

1. Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

2. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

3. Womack, James P. Daniel, T.Jones e Daniel Roos, The Machine That Changed the World: The Story of Lean Production, 2007 edição atualizada, Free Press, 2007

4. James P. Womack, e. Daniel T.Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2ª Edição, Free Press, 2003

5. Beck, Kent et al, The Manifesto for Agile Software Development, 2001 http://www.agilemanifesto.org/

6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

7. Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003

8. Poppendieck, Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006

9. Poppendieck, Mary and Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009

10. Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997

11. Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

12. Sutton, James e Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers, Productivity Press, 2005

13. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

14. Shalloway, Alan, and Guy Beaver and James R.Trott, Programação de Software Magro-Ágil: Obtendo a Agilidade da Empresa, Addison-Wesley, 2009

15. Larman, Craig e Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008

16. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison Wesley Professional, 2010

17. Coplien, James O.e Gertrud Bjornvig, Arquitetura Magra: para Desenvolvimento do Software Agile, 2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/