Developer

Im

Biblioteca MSDN

Este artigo foi traduzido por mquina. Para visualizar o arquivo em ingls, marque a caixa de seleo Ingls. Voc tambm pode exibir o
texto Em ingls em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.

Traduo
Ingls

Desenvolvimento de software lean

Visual Studio 2013

Outras verses

Por David J. Anderson. David J. Anderson o autor de trs livros, Lies no gerenciamento do Agile: Na estrada a Kanban, que foi publicado em 2012,
Kanban: Alterao evolucionria com xito para o negcio de tecnologia, [1] que foi publicado em 2010, e Gerenciamento do Agile para a tecnologia de
programao: Aplicando a teoria das restries de resultados de negcios, [2] que foi publicado em 2003. Ele foi um membro da equipe que criou o
mtodo 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 observao tcnica do instituto de tecnologia de programao, CMMI e agile: Porque no abrao 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 organizao de padres 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 negcios de tecnologia melhorar seu desempenho com as melhores polticas de gerenciamento e
tomada de deciso.
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 alm do Agile
Definindo um Desenvolvimento de Software Magro
Valores
Princpios
Prticas
O termo Desenvolvimento de Software Lean foi inventado como ttulo para uma conferncia organizada por iniciativa da ESPRIT de Unio 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 Lean" 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 ingls para descrever a abordagem de gerenciamento usada na Toyota. A ideia de que o software magro pode
ser aplicvel durante a programao do software foi estabelecido muito cedo, apenas 1 a 2 anos aps o termo ter sido usado pela primeira vez em
associao com as tendncias nos processos de fabricao 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
converted by W eb2PDFConvert.com

Perfeio
Esta se tornou a definio padro de trabalho para softwares magros na maior parte da prxima dcada. Sugeriu-se que a busca pela perfeio foi
obtida eliminando o desperdcio. Quando houve 5 pilares, foi no 5, a busca da perfeio atravs da identificao sistmica de atividades de
desperdcio e a sua eliminao, que realmente repercutiu em um grande pblico. O Leve tornou-se associada quase exclusivamente com a prtica de
eliminao de resduo atravs dos anos 90 e o incio do sculo XXI.
A definio de Womack e Jones para Software magro no compartilhada universalmente. Os conceitos bsicos de gerenciamento na Toyota so
muito mais sutis. A palavra desperdcio, em portugus, descrita de uma forma muito mais rica com trs termos japoneses:
Muda literalmente significando desperdcio, mas inferindo uma atividade intil adicionada
Mura significando irregularidade, mas interpretado como variabilidade no fluxo
Muri significando sobrecarga ou irracionalidade
Para alcanar a perfeio, as atividades sem valor agregado so reduzidas. Alm disso, o fluxo suavizado e a sobrecarga, eliminada. Alm disso, a
abordagem Toyota foi baseada em um respeito bsico para pessoas e fortemente influenciada pelos ensinamentos da garantia de qualidade do sculo
XX e especialistas no controle do processo estatstico, tais como W. Edwards Deming.
Infelizmente, h quase tantas definies para Magro quanto autores no assunto.

Leve e Agile
Bob Charette foi convidado mas no pode participar da reunio de 2001 em Snowbird, Utah, onde o Manifesto para Desenvolvimento de Software
Agile [5] foi criado. Apesar de perder esta reunio histrica, o Desenvolvimento de Software Magro foi considerado como uma das vrias
abordagens da Agile para o desenvolvimento de software. Jim Highsmith dedicou um captulo no seu livro de 2002[6] para uma entrevista com Bob
sobre o tpico. Posteriormente, Mary & Tom Poppendieck continuaram com o autor sobre uma srie de 3 livros [7, 8, 9]. Durante os primeiros anos
do sculo XXI, os princpios Magros foram usados para explicar porque os mtodos geis eram melhores. O Leve explicado que os mtodos Agile
contm pouco "resduo" e, portanto, produziu um melhor resultado econmico. Princpios leves foram usados como um"doador de permisso" para
adotar mtodos do Agile.

Leve alm do Agile

Nos ltimos anos, o Desenvolvimento de Software Leve realmente emergiu como disciplina prpria relacionada, mas no especificamente, a um
subconjunto do movimento Agile. Essa evoluo iniciou com a sntese das ideias do Desenvolvimento de Produtos de Software Magro e do trabalho
de Donald G. Reinertsen[10,11] e ideias emergentes do mundo no Agile de engenharia de sistemas de grande escala e os trabalhos de James
Sutton e Peter Middleton[12]. Eu tambm sintetizei o trabalho de Eli Goldratt e W. Edwards Deming e desenvolveu um foco no fluxo em vez da
reduo 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 tpico [14]. Desde 2007, o surgimento do Lean medida que uma nova fora no progresso de
profisso de desenvolvimento de software foi focalizada em melhorar o fluxo, em gerenciar o risco, e em melhorar a tomada de decises (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 eliminao de resduos, est se mostrando um melhor catalisador para a melhoria contnua dentro das atividades de trabalho do
conhecimento, tais como o desenvolvimento de software.

Definindo um Desenvolvimento de Software Magro

Definir o Desenvolvimento de Software Enxuto desafiador porque no h nenhum mtodo ou processo de Desenvolvimento de Software Enxuto
especfico. O Leve no um equivalente do Processo de Software Pessoal, Modelo em V, Modelo em Espiral, EVO, Desenvolvimento de Recurso
Orientado, Programao 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 princpios de Desenvolvimento de Software Magro. Aqueles que antecipam uma receita simples que pode
ser seguida e chamada de Desenvolvimento de Software Lean sero decepcionados. Voc deve formar ou personalizar seu prprio processo de
programao de software por meio do entendimento dos princpios Magros e adotando os valores principais do Magro.
H vrias escolas de pensamento dentro do Desenvolvimento de Software Magro. O maior, e resultar teoricamente, escola so 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 sntese e um resumo das suas exibies.

Valores
converted by W eb2PDFConvert.com

Valores
A sociedade magra os sistemas publicou o credo 18 [] em 2012 conferncia 19 []magra de software e os sistemas. Isso foi baseado em um conjunto
de valores publicados um ano anterior. Esses valores so:
Aceitar a condio humana
Aceitar que a complexidade e a incerteza so naturais ao trabalho de conhecimento
Funcionar para obter um Resultado Econmico melhor
Ao ativar um melhor Resultado Sociolgico
Busque, adote e questione ideias de uma ampla variedade de disciplinas
Uma comunidade baseada em valor melhora a velocidade e profundidade da alterao positiva

Aceitar a Condio Humana

O trabalho do conhecimento como a programao de software empreendido por seres humanos. Ns seres humanos somos complexos de
forma inerente e, como pensadores lgicos, somos levados tambm por nossas emoes e por alguns traos animalistas inerentes que no
podem ser superados de forma aceitvel. Nossa psicologia e nossa neuropsicologia devem ser levadas em considerao durante a criao dos
sistemas ou dos processos nos quais trabalhamos. Nosso comportamento social tambm deve ser acomodado. Os seres humanos so
inerentemente emocionais, sociais e tribais e nosso comportamento muda com fadiga e estresse. Os processos com sucesso sero aqueles que
abordem e acomodem a condio humana em vez do que aqueles que tentam negar e assumir o comportamento como mquina, lgico.

Aceitar que a Complexidade e a Incerteza so Naturais ao Trabalho de Conhecimento

O comportamento de clientes e dos mercados so imprevisveis. O fluxo de trabalho em um processo e uma coleo de trabalhadores
imprevisvel. Os defeitos e o retrabalho necessrio so imprevisveis. H uma chance inerente ou um comportamento aparentemente aleatrio em
vrios nveis no desenvolvimento de software. A finalidade, as metas e o escopo dos projetos tendem a ser alterados enquanto esto sendo
entregues. Parte dessa incerteza e variabilidade, embora desconhecida inicialmente, reconhecvel no sentido de que pode ser estudada e
quantificada e seus riscos podem ser gerenciados, mas certa variabilidade no 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
condies alteradas. Portanto, qualquer processo de Desenvolvimento de Software Magro deve existir em uma estrutura que permite a adaptao
(do processo) para desdobrar eventos.

Funcionar para obter um Resultado Econmico melhor

As atividades humanas como o Desenvolvimento de Software de Inclinao devem ser centradas na produo de um melhor resultado econmico.
O capitalismo aceitvel quando contribui para o valor do negcio e o benefcio do cliente. Os investidores e os proprietrios de negcios
merecem uma retorno sobre o investimento. Os funcionrios e trabalhadores merecem uma taxa de pagamento justa para um esforo adequado
ao executar o trabalho. Os clientes merecem um bom produto ou servio que fornece seus benefcios prometidos em troca de um preo justo. Os
melhores resultados econmicos envolvero a entrega de mais valor para o cliente, em menor custo, ao gerenciar o capital implantado por
investidores ou proprietrios da maneira mais eficaz possvel.

Ativar um resultado sociolgico melhor

Os melhores resultados econmicos no devem ser enviados s custas daqueles que executam o trabalho. Criar um local de trabalho que respeita
as pessoas aceitando a condio humana e fornea sistemas de trabalho que respeitam a natureza psicolgica e sociolgica de pessoas
essencial. Criar um timo local para fazer um timo trabalho um valor principal da comunidade de Desenvolvimento de Software Magro.

Princpios
A comunidade Lean Software & Systems aparece estar de acordo com alguns conceitos bsicos 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 adaptvel complexo
Respeite as pessoas (como parte do sistema)
Use o Mtodo Cientfico (para conduzir as melhorias)
converted by W eb2PDFConvert.com

Incentivo liderana
Gerar visibilidade (no trabalho, no fluxo de trabalho e na operao do sistema)
Reduzir Tempo de Fluxo
Reduzir o desperdcio e melhorar a eficincia

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 sada de todo o sistema (ou
processo) que desejamos otimizar, e no devemos equivocadamente otimizar partes esperando que elas magicamente otimizem o todo. A
maioria dos profissionais acredita que o corolrio verdadeiro, que a otimizao de partes (otimizao local) leva a um resultado de qualidade
inferior.
Uma Abordagem de Design e Pensamento para Sistemas Magros exige a considerao das demandas no sistema realizada por participantes
externos, como clientes, e o resultado desejado solicitado por esses participantes. Ns 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 esto 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 servios adicionais ou suporte para uma
falha ao fornecer a demanda de valor. No desenvolvimento do software, a demanda de falha normalmente solicitada para correes e
solicitaes de bug para a funo de atendimento e help desk ao cliente.
Uma abordagem de design de sistemas exige que ns tambm 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 ns 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 observvel em termos de tempo de espera, qualidade, quantidade de recursos ou funes entregues (conhecido na
literatura Agile como a "velocidade"), e assim por diante. Essas mtricas iro exibir variabilidade e, estudando o meio e a extenso da variao,
podemos desenvolver uma compreenso de nosso recurso. Se este incompatvel com as expectativas de demanda e do cliente, ento o sistema
precisar ser remodelado para fechar a lacuna.
A demanda tambm ensinou que a capacidade 95% influenciada pelo design do sistema e somente 5% contribudo pelo desempenho de
indivduos. Em outras palavras, podemos respeitar as pessoas no responsabilizando-as por um intervalo na capacidade em relao demanda e
por reformular o sistema que lhes permite ser bem-sucedido.
Para entender o design do sistema, precisamos ter uma compreenso cientfica de dinmica de recurso do sistema e como pode ser afetado. Os
modelos so desenvolvidos para prever a dinmica do sistema. Quando h muitos modelos possveis, vrios populares esto em uso comum: a
compreenso do custo econmicos; os conhecidos custos de transao e coordenao relacionados produo de produtos ou de servios de
valor do cliente; a teoria de restries a compreenso 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 adaptvel complexo
Os sistemas complexos possuem condies iniciais e regras simples que, quando executados iterativamente, geram um resultado emergente. Os
resultados emergentes so difceis ou impossveis de prever dado as condies iniciais. A experincia da cincia da computao "O jogo da vida"
um exemplo de um sistema complexo. Um sistema adaptvel complexo tem dentro dele alguma conscincia autodescritiva e um mtodo interno
de reflexo que permite considerar quo bem seu conjunto atual de regras est permitindo obter um resultado desejado. O sistema adaptvel
complexo pode escolher se adaptar para alterar as regras simples para fechar o intervalo entre o resultado atual e o resultado desejado. A
adaptao do Jogo da Vida para que as regras pudessem ser reescritas durante o jogo seria um sistema adaptvel complexo.
Nos processos de desenvolvimento de software, as "regras simples" de sistemas adaptativos complexos so as polticas que compem a
definio do processo. O princpio bsico aqui baseado na crena que o desenvolver de produtos de software e servios no uma atividade
determinstica e, portanto, um processo definido que no possa se adaptar no ser uma resposta suficiente para os eventos imprevisveis.
Portanto, o processo criado como parte de nossos pensamento do sistema e abordagem de design deve ser adaptvel. Adapta-se atravs da
modificao das polticas de que feito.
A abordagem Kanban para o Desenvolvimento de Software Magro utiliza esse conceito tratando as polticas do sistema kanban de recebimento
como as regras simples, e as condies iniciais so que o trabalho e o fluxo de trabalho so visualizados, que o fluxo gerenciado usando uma
compreenso da dinmica do sistema, e que a organizao usa uma abordagem cientfica para compreender, propor e implementar melhorias no
processo.

Respeite as pessoas
A comunidade Lean adota a definio de Peter Drucker de trabalho do conhecimento, que afirma que os trabalhadores so trabalhadores do
conhecimento se tiverem mais conhecimento sobre o trabalho que exercem do que seus chefes. Isso cria uma implicao de que os trabalhadores
esto em melhor posio para tomar decises sobre como realizar o trabalho e como modificar os processos para melhorar como o trabalho
executado. Portanto a opinio do trabalhador deve ser respeitada. Os funcionrios devem ser autorizados a se organizar sozinhos para concluir o
trabalho e obter os resultados desejados. Eles tambm deveriam estar autorizados a sugerir e implementar oportunidades de melhoria de
processo ou eventos kaizen, como so conhecidos na literatura de software magro. Fazer polticas de processo explcito para que os
trabalhadores estejam cientes das regras que restringem uma outra maneira de respeit-los. As regras claramente definidas incentivam a autoconverted by W eb2PDFConvert.com

organizao removendo o medo e a necessidade de coragem. Respeitar as pessoas, estimulando-as e fornecendo a elas um conjunto de polticas
explicitamente declaradas, a essncia do respeito condio humana.

Use o Mtodo Cientfico

Procure usar modelos para entender a dinmica 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 mtodos grficos estatsticos, como grficos de controle de processos estatsticos e histogramas de anlise
espectral de dados brutos para que a velocidade e tempo de execuo compreendam o recurso do sistema. Tambm usam modelos como: a
teoria de restries para entender gargalos; o sistema de conhecimento profundo para entender a variao interna ao design do sistema versus a
que influenciada externamente; e uma anlise dos custos econmicos na forma de tarefas executadas apenas para coordenar, configurar,
entregar ou limpar produtos ou servios de valor para o cliente que so criados. Alguns outros modelos esto entrando em uso, como a teoria da
Opo Real, que procura aplicar a teoria da opo financeira, oriunda do gerenciamento de riscos financeiros, tomada de decises no mundo
real.
O mtodo cientfico sugere: ns estudamos; ns postulamos um resultado baseado em um modelo; ns perturbamos o sistema com base nessa
previso; ns observamos novamente para ver se a perturbao gerou os resultados que o modelo previu. Caso contrrio, ento 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 cientfica e o tira de uma atividade supersticiosa baseada em intuio.

Incentivo liderana
A liderana e o gerenciamento no a mesma. O gerenciamento a atividade dos processos de design, criao, modificao e excluso da
poltica, tomando decises estratgicas e operacionais, reunindo recursos, fornecendo financiamentos e facilidades e comunicando informaes
sobre contextos, como estratgia, metas e resultados desejados. A liderana sobre a viso, a estratgia, as tticas, a coragem, a inovao, o
julgamento, a defesa, e muitos outros atributos. A liderana pode e deve vir de qualquer um dentro de uma organizao. Pequenos atos de
liderana dos trabalhadores vo criar uma cascata de melhorias resultaro nas alteraes necessrias para criar um processo de Desenvolvimento
de Software Lean.

Gera visibilidade
O trabalho do conhecimento invisvel. Se voc no consegue ver alguma coisa, (quase) impossvel control-lo. necessrio gerar visibilidade
no trabalho que est sendo realizado e o fluxo deste trabalho atravs de uma rede de indivduos, habilidades, e departamentos at que esteja
concludo. necessrio criar visibilidade no design do processo encontrando maneiras de visualizar o fluxo do processo e tornando as polticas
do processo explcitas para que todos possam consultar e considerar. Quando todas essas coisas so visveis, ento o uso do mtodo cientfico
possvel e as conversaes sobre aperfeioamentos potenciais podem ser colaboradoras e objetivas. A melhoria do processo colaborativo
quase impossvel se o trabalho e o fluxo de trabalho esto invisveis e se as polticas de processo no so explcitas.

Reduzir Tempo de Fluxo

O profissional de programao de software e os acadmicos 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 calendrio 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 Anlise para Pronto para Implantao deveriam medir o tempo decorrido total para
um item de trabalho, como uma histria de usurio, a ser analisada, criada, desenvolvida, testada de vrias maneiras e colocadas em fila pronta
para implantao em um ambiente de produo.
Focalizar no tempo que o trabalho leva para percorrer pelo processo importante de vrias maneiras. Um tempo de ciclo mais longo tm sido
mostrado para correlacionar com um crescimento no-linear da taxa do bug. Portanto, um tempo de ciclo mais curto leva a uma qualidade maior.
Isso contra-intuitivo, pois pareceria ridculo que os bugs pudessem ser inseridos em cdigo enquanto estivessem em fila, com nenhum humano
de fato tocando neles. Tradicionalmente, a profisso de engenheiro de programao e os acadmicos que a estudam ignoraram esse tempo
ocioso. No entanto, a evidncia emprica sugere que o tempo de ciclo seja importantes para a qualidade inicial.
Alan Shalloway tambm falou sobre o conceito de trabalho induzido. Sua observao que uma latncia ao executar uma tarefa pode resultar
nessa tarefa levando muito mais esforo 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 vrios dias ou ltimas semanas para ser corrigido, podendo
envolver vrias ou muitas horas para realizar a correo. Portanto, o tempo de atraso do ciclo "induziu" o trabalho adicional. Como este trabalho
evitvel, em termos Magros, deve ser considerado como desperdcio.
A terceira razo para focar no tempo de ciclo uma razo relacionada ao mercado. Cada recurso, funo ou histria do usurio 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 funo de recompensa do mercado. Quando a funo de recompensa do mercado para um item
de trabalho for compreendida, mesmo que a funo exiba uma distribuio de valores para a incerteza, possvel avaliar um custo do atraso.
Os custos de atraso permitem que ns coloquemos um valor em reduo do tempo de ciclo.

converted by W eb2PDFConvert.com

Com alguns itens de trabalho, a funo de recompensa do mercado no comea at uma data conhecido no futuro. Por exemplo, um recurso
projetado para ser usado durante o feriado de 4 de junho nos Estados Unidos no 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 necessrio e no significativamente antes da data desejada, no depois, com atraso na entrega incorrendo em
um custo de atraso. A entrega just-in-time garante que o uso otimizado feito de recursos disponveis. A entrega inicial implica que ns talvez
tenhamos trabalhado em algo diferente e temos, por implicao, incorrido uma oportunidade de custo de atraso.
Como resultado desses trs motivos, o Desenvolvimento de Software Magro procura minimizar tempo de fluxo e registrar os dados que permitem
previses sobre o tempo de fluxo. O objetivo minimizar a demanda de falha de erros, desperdcio de sobrecarga devido ao atraso na correo
de erros, e maximizar o valor oferecido evitando o custo de atraso e o custo de oportunidade de atraso.

Reduzir o desperdcio e melhorar a eficincia

Para cada atividade de valor adicionado, h as atividades de configurao, limpeza e entrega necessrias, mas no adiciona valor em seu prprio
direito. Por exemplo, uma iterao de projeto que desenvolve um incremento do software de trabalho requer um planejamento (uma atividade de
configurao), um ambiente e talvez uma ramificao de cdigo em controle de verso (conhecidos coletivamente como gerenciamento de
configurao e tambm uma atividade de configurao), um plano de verso e executar a verso atual (uma atividade de entrega), uma
demonstrao para o cliente (uma atividade de entrega) e talvez um detalhamento de ambiente ou uma reconfigurao (uma atividade de
limpeza.) Em termos econmicos, a configurao, limpeza, e atividades de entrega so os custo de transao sobre a realizao do trabalho de
valor agregado. Esses custos (ou sobrecargas) so considerados desperdcio no software magro.
Qualquer forma de sobrecarga de comunicao pode ser considerado lixo. As reunies para determinar o status do projeto e para agendar ou
atribuir o trabalho para membros da equipe devem ser considerados um custo de coordenao na linguagem econmica. Todos os custos de
coordenao so desgastados no pensamento Magro. Mtodos de desenvolvimento de software leve procura eliminar ou reduzir custo de
coordenao atravs do uso da colocao de membros da equipe, reunies frente a frente curtas como displays em tamanho natural e controles
visuais como paredes de cartes.
A terceira forma mais comum de desperdcio 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 formulrios mais comuns de demanda de falha na programao de software so bugs, defeitos de produo e
atividades de suporte ao cliente excludas 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 relao demanda de falha
uma medida da eficincia do sistema.
A porcentagem de trabalho de valor agregado em relao ao trabalho total, incluindo qualquer valor que no adiciona custo de transao e de
coordenao, determina o nvel de eficincia. Um sistema sem custo de transao e de coordenao e nenhuma falha de carregamento deve ser
considerada 100% eficiente.
Tradicionalmente, a cincia de gerenciamento ocidental ensinou que a eficincia pode ser melhorada com o aumento do tamanho de lotes de
trabalho. Normalmente, a transao e custo de coordenao so fixos ou aumentam apenas ligeiramente com um aumento no tamanho do lote.
Como resultado, os maiores lotes de trabalho so mais eficientes. Esse conceito conhecido como economia de escala. No entanto, em
problemas de trabalho de conhecimento, os custos de coordenao tendem a aumentar no linearmente com o tamanho do lote, enquanto os
custos de transao geralmente podem exibir um crescimento linear. Como resultado, a abordagem do sculo XX tradicional para eficincia no
apropriada para problemas de trabalho de conhecimento como o desenvolvimento de software.
melhor para focar na reduo das despesas gerais, mantendo o tamanho dos lotes pequenos, a gim de melhorar a eficincia. Portanto, a
maneira Magra de ser eficiente reduzir o desperdcio. Os mtodos de desenvolvimento de software leve focalizam sobre mtodos de
planejamento rpidos e baratos; baixa sobrecarga de comunicao; mecanismos de coordenao de sobrecarga de baixa eficcia, tais como
controles visuais nos sistemas kanban. Tambm incentivam testes automatizados e implantao automatizada para reduzir os custos de transao
de entrega. As ferramentas modernas que minimizam os custos de desmontagem e configurao de ambientes, como os sistemas modernos de
controle de verso e o uso de virtualizao, tambm ajudam a melhorar a eficincia de pequenos lotes de desenvolvimento de software.

Prticas
Desenvolvimento de Software Leve no prescreve prticas. mais importante demonstrar que as definies de processo reais esto alinhadas com
os princpios e os valores. No entanto, um nmero de prticas esto sendo adotadas normalmente. Essa seo fornece uma breve viso geral de
alguns desses.

Fluxogramas cumulativos
Os fluxogramas cumulativos tem sido uma parte padro de relatrio no Team Foundation Server desde 2005. Os fluxogramas cumulativos plotam
um grfico da rea de itens de trabalho cumulativos em cada estado de um fluxo de trabalho. Eles so ricos em informaes e podem ser usados
para derivar o tempo mdio de ciclo entre as etapas de um processo, bem como a taxa de transferncia (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 padres de disfuno no processo exibido no grfico de rea. Um processo realmente Magro mostrar as reas
de cor igualmente distribudas, surgindo suavemente em um ritmo constante. A imagem ir aparecer suave sem etapas serrilhadas ou blocos de
cor visveis.
Na sua forma mais bsica, os diagramas de fluxo cumulativos so usados para visualizar a quantidade de trabalho em andamento em qualquer
converted by W eb2PDFConvert.com

Na sua forma mais bsica, os diagramas de fluxo cumulativos so usados para visualizar a quantidade de trabalho em andamento em qualquer
estgio 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
Alm do uso de diagramas de fluxo acumulado, as equipes de Programao de Software Leves usam placas fsicas, ou projees de sistemas de
visualizao eletrnica, para visualizar o trabalho e observar seu fluxo. Tais membros da equipe de ajuda de visualizaes observam a acumulao
do trabalho em andamento e habilita para ver afunilamentos e os efeitos de "muro". Os controles visuais tambm permitem aos membros da
equipe se auto-organizarem para escolher trabalhos e colaborar em conjunto sem planejamento ou gerenciamento especfico ou interveno.
Esses controles visuais so geralmente denominados card walls ou s vezes (incorretamente) kanban boards.

Sistemas virtuais Kanban

Um sistema kanban uma prtica adotada de fabricao magra. Ele usa um sistema de cartes fsicos para limitar a quantidade de trabalho em
andamento em qualquer estgio 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 especfico e o
trabalho pode progredir a partir dele.
No Desenvolvimento do Software Leve, os kanbans so virtuais e geralmente controlados pela definio de um nmero mximo para uma
determinada etapa no fluxo de trabalho de um tipo de item de trabalho. Em algumas implementaes, os sistemas eletrnicos 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 so combinados com frequncia com os controles visuais para fornecer um sistema visual kanban virtual que
representa o fluxo de trabalho de um ou vrios tipos do item de trabalho. Esses sistemas so geralmente chamados placas kanban ou sistemas
kanban eletrnicos". Um sistema kanban virtual visual est disponvel como um plug-in para o Team Foundation Server, chamado Visual WIP [20].
Esse projeto foi desenvolvido como cdigo aberto por Hakan Forss, na Sucia.

Tamanhos pequenos de lotes/fluxo de uma s parte

Desenvolvimento de Software Leve requer que o trabalho seja empreendido em lotes pequenos, geralmente denominados "iteraes" ou
"incrementos", ou que itens de trabalho fluem independente, conhecidos como "o fluxo de parte nica". O fluxo de parte nica requer uma
estratgia de gerenciamento de configurao sofisticada para ativar o trabalho concludo seja entregue quando o trabalho incompleto no
liberado acidentalmente. Isso normalmente alcanado usando estratgias de ramificao no sistema de controle de verso. 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 interao frequente com proprietrios de negcios para reabastecerem o backlog ou a fila
ou o trabalho. Tambm requerem um recurso para liberar com frequncia. Para ativar a interao frequente com executivos e entrega frequente,
necessrio reduzir o custo de transao e de coordenao de ambas as atividades. Uma maneira comum de fazer isso o uso de automao.

Automao
Desenvolvimento de Software Leve espera um alto grau de automao para ativar economicamente o fluxo de uma parte e incentivar a alta
qualidade e a reduo de falha na demanda. O uso de testes automatizados, implantao automatizada e fbricas de software para automatizar a
implantao de padres de design e a criao de sees repetitivas de variabilidade baixa do cdigo de origem sero comuns nos processos de
Desenvolvimento de Software Magro.

Eventos Kaizen
Na literatura leve, o termo kaizen significa "melhoria contnua" e um evento kaizen o ato de fazer uma mudana em um processo ou a ferramenta
que esperamos que resulte em uma melhora.
Os processos de Desenvolvimento de Software Leve usam vrias atividades diferentes para gerar eventos kaizen. Eles so 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 essncia 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.

Reunies standup dirias

As equipes de desenvolvedores de software, geralmente at 50, normalmente se encontram atravs de um sistema de controle visual como um
painel exibindo uma visualizao de seu trabalho em andamento. Eles abordam a dinmica de fluxo e os fatores que afetam o fluxo de trabalho.
dada ateno especial a trabalhos bloqueados externamente e a trabalhos atrasados devido a bugs. Geralmente , problemas com o processo se
tornam evidentes aps uma srie de reunies dirias. O resultado que um grupo menor pode permanecer aps a reunio para discutir o
problema e propor uma soluo ou uma alterao no processo. Um evento de kaizen ir ocorrer. Essas reunies espontneas so geralmente
chamadas de crculos espontneos de qualidade, na literatura antiga. Como reunies espontneas que esto realmente no centro de uma cultura
de kaizen. Os gerentes estimulam o surgimento de eventos kaizen aps reunies standup dirias, a fim de impulsionar a adoo do Leve dentro
converted by W eb2PDFConvert.com

de kaizen. Os gerentes estimulam o surgimento de eventos kaizen aps reunies standup dirias, a fim de impulsionar a adoo do Leve dentro
de sua organizao.

Retrospectivas
As equipes de projeto podem agendar reunies regulares para refletir no desempenho recente. Geralmente eles so feitos depois que
entregveis especficos do projeto estejam concludos ou depois de incrementos de timeboxing conhecidos com iteraes ou sprints no
desenvolvimento gil de software.
As retrospectivas normalmente usam uma abordagem prtica para reflexo ao fazer perguntas como o que deu certo?, o que ns faramos de
maneira diferente? e o que devemos parar de fazer?
As retrospectivas normalmente produzem uma reserva de sugestes para eventos kaizen. A equipe pode dar prioridade a alguns deles para a
implementao.

Anlises de Operaes
Uma reviso das operaes 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 anlises de operaes so realizadas uma vez por ms. As principais diferenas entre uma reviso de
operaes e uma retrospectiva que revises de operaes abrangem um conjunto maior de funes, abrange normalmente um portflio de
projetos e outras iniciativas, e usa dados objetivos e quantitativos. As retrospectivas, em comparao, tendem a ter o escopo de um nico projeto;
envolve apenas algumas equipes como a anlise, o desenvolvimento e o teste; e normalmente so de natureza prtica.
Uma reviso das operaes provocar discusses sobre a dinmica 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 faa com que a segunda equipe no
cumpra compromissos e no atenda s expectativas? Uma reviso das operaes fornece uma oportunidade para discutir tais problemas e de
propor alteraes. As anlises de operaes produzem uma pequena lista de pendncias de possveis eventos kaizen que podem ser priorizados
e agendados para futura implementao.

No existe nenhum processo nico de Desenvolvimento de Software Magro. Um processo pode ser chamado de Magro se est claramente alinhado
com os valores e princpios de Desenvolvimento de Software Magro. Desenvolvimento de Software Leve no prescreve nenhuma prtica, mas algumas
atividades se tornam comuns. As organizaes leves procuram incentivar kaizen atravs da visualizao do fluxo de trabalho e trabalho em progresso e
atravs de uma compreenso de dinmicas do fluxo e os fatores (tais como estrangulamentos, disponibilidade no instantnea, variabilidade e
resduos) que o afetam. Aperfeioamentos de processo so sugeridos e justificados como maneiras de reduzir fontes de variabilidade, eliminar o
desperdcio, 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 estaro evoluindo e so personalizados exclusivamente para a organizao na qual evoluem. No ser natural
simplesmente copiar uma definio de processo de uma organizao para outra e esperar que ele funcione em um contexto diferente. Tambm ser
improvvel que retornando a uma organizao aps alguns semanas ou meses para encontrar o processo em uso para ser o mesmo que foi
observado anteriormente. Sempre estar evoluindo.
A organizao que usa um processo de desenvolvimento de software magro poderia ser chamada de magra se exibisse somente pequenas
quantidades de desperdcio em todos os trs formas (mura", muri , e muda ") e poderia ser mostrada otimizando a entrega de valor atravs do
gerenciamento efetivo de risco. A busca pela perfeio em software magro sempre uma jornada. No h nenhum destino. As verdadeiras
organizaes magras esto sempre buscando uma melhoria adicional.
Desenvolvimento de Software Leve ainda um campo emergente, e podemos aguardar para continuar a evoluir durante a prxima dcada.
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 edio atualizada,
Free Press, 2007
4. James P. Womack, e. Daniel T. Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2 Edio, 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
converted by W eb2PDFConvert.com

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, Programao 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/

Contribuies da comunidade

Esta
pgina

til?
Sim

Centros do desenvolvedor

No

Windows
Office
Visual Studio

Microsoft Azure
Mais...

Recursos de aprendizagem
Micro so ft Virtu al Academy
Ch an n el 9
MSDN Magazin e

Comunidade
F ru n s
B lo gs
Co dep lex
O p en So u rce

Suporte
Su p o rte au t n o mo

Programas
B izSp ark (p ara in ician tes)

converted by W eb2PDFConvert.com

Micro so ft Imagin e (fo r stu den ts)

B rasil (Po rtu gu s)

B o letim in fo rmativo

Privacidade & co o kies

Termo s de u so

Marcas co merciais

2016 Micro so ft

converted by W eb2PDFConvert.com