Académique Documents
Professionnel Documents
Culture Documents
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
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.
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
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
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.
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.
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.
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.
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.
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
B o letim in fo rmativo
Termo s de u so
Marcas co merciais
2016 Micro so ft
converted by W eb2PDFConvert.com