精益思想的起源
TBD
精益思想的积木模型
思想基础
- 多数错误是系统性的。
- 很多团队陷入失败的泥潭之中，因为它们遵循着一个劣质的过程或一种糟糕的管理方法，并且过分相信这一过程。他们始终认为过程是正确的，并且一直相信：“只要正确地执行这个过程，就不会有这样的问题发生。”
- 管理层看上去更倾向于过分重视过程而低估团队的价值。
- 团队将是其自身过程的管理者---他们将创建、维护和改进这一过程以便使过程能够获得持续不断的改进。
- 人们的本性是好的：这就是所谓的XY理论吧。所以我们要以人为本。
- 当企业为客户提供了最大价值时，企业也实现了自身利益的最大化。
所以一切要以客户的价值为驱动力。
观点
- 看看时间，已经没有多少资源可用了（啥意思？）
- 使开发过程快速、灵活、机动
快速交付和频繁交付：能够为公司带来更早的回款，也能更早的为客户抢占市场。（P59:案例分析：金融服务）
- 增加过程可见性
可视化控件（SCRUM中称作信息发射器）：
- 有助于团队认识当前发生的事情，并有利于管理层向团队伸出援手。
- 可视化控件存在于组织中的所有层面：业务层、管理层、团队层。
- 当可视化控件不适合团队时，要及时作出调整和修正。
- 让经过的人们都能看到项目每部分的信息。
- 消除浪费的最佳方式是不开发不需要的功能。
- 过程就是变革的基础。（？）
- 把过程中的阻碍当作浪费看待。（如果障碍存在，那么过程必须被改进，而且一定有改进的空间。）
原则
- 全局优化
P53: 有公司花费80%的金钱用于项目开发，而往往项目开发的周期只有整个产品周期短20%。精益需要我们把重点放在花费的时间上而非金钱上。精益－企业级敏捷，需要贯穿从构思产品到产品实际部署完整的整个过程，而不单单是项目开发这一个过程。
-
消除浪费
一，使团队在一个时间段内只开发一个项目
- 一个人如果在同一时间参与两个项目，工作效率会下降20%.如果同时参与的项目多达三个之多，工作效率将会下降40%。更可怕的是，身兼多个项目的人往往是公司中掌握重要技术的关键人才，让他们工作效率降低，对于公司来说是一笔巨大的损失。现在的问题是：那我们该怎么做呢？项目就是有这么多？人数就那些？从管理层入手减少项目的数量？
- 减少在制品（Work-In-Process）
二，消除人员或信息等待过程中产生的延迟。
积极反馈？
三，消除从发生错误到错误被检测出来这个过程中的延迟
QA在循环最后是内在的浪费。QA的工作不是发现BUG，而是要与整个团队从项目开始就协同合作，一起来防止BUG。因此我们需要"测试前置"。（自动化测试就成了必不可少的一环）
任何人员，在任何时候陈述需求时，要确保团队问以下的问题："如何得知工作已经完成？"（DOD一定要有！一定要有！一定要有！DOD给了所有的开发人员一个开发完成的目标，能保证开发人员在过程中，时刻以这个目标作为准绳，也就能时刻检查产品是否与这个目标相违背。）
- 构建知识
创建知识意味着要知道如何开发软件去满足客户需求的过程。通过这种方式，可以更加容易地改进软件产品。（P24) (就是软件开发前的设计吗？）
- 品质构建
质量问题经常造成工作流上的延迟。软件开发人员按照各自的喜好进行编程，居然没有一套质量标准。（那我们到底应该怎么做呢？）
- 推迟委托
我理解这应该是推迟决策的意思吧。推迟决策意味在"在最后负责任的时刻"做出决定：不能太早，决策太早会使得你无法得到足够的信息。不能太晚，决策太晚会使你承担很大的风险和压力。甚至于错过最佳时机。
- 快速交付
跟观点中的快速、灵活、激动一致。
-
尊重员工
"过程"对不同的人意味着不同的事情。在软件开发中，我们认为过程是一个协议，是关于团队将如何一起工作的协议。
关于尊重员工这一部分，可以同《如何构建敏捷项目管理团队》这本书结合起来理解。
亨利福特发明了流水线，因此认为机器大于人，对员工缺乏必要的尊重。但事实上，只有生产线上的员工才掌握着第一手的资料。而且在那个年代，员工赚钱是为了养家糊口解决温饱问题。而当今社会，从马斯洛的需求理论来看，随着社会的不断进步和发展，人们工作已经不单单是为了养家糊口，而更多的是为了得到事业的成就感和自豪感。
态度
我们态度是我们持有的信仰体系所产生的结果，会影响我们对所有事物的看法。
- 管理者是重要的。他们需要为团队设置目标，并允许团队以自己的方式去筹划该如何实现目标。
- 要改正错误，不要让错误从你手边溜走哦，或者至少要把错误别出来，待到开发后期再去探寻产生错误的根本原因。（平时的交谈或者开发时，聊到任何一个可能的BUG，都必须要记录下来，否则就会让错误活生生的从你眼皮底下溜走了。）
知识
我个人更愿意把知识理解为：对于所有精益思想，精益观点，精益原则，静态态度的认知。
实践
- 运用价值流图找到延误
P29:图1-2 "公司现状"的价值流图：
我们利用价值流图找出问题，再利用精益思想(譬如5 why分析法)找出导致问题产生的根本原因。
- 运用可视化控件管理项目
可视化控件应该存在于项目的所有层面：业务层、管理层、团队层。包括"产品愿景"、"产品需求列表／发布计划／精益组合管理；迭代列表；素材点向上燃烧图；迭代向下燃烧图；商业价值交付表；障碍列表。
- 分阶段开发项目
- 持续的过程改进（Kaizen）
- 精益并不是关于帮助企业转型的方法，而是一个让企业学习转型的过程。但是，为了专线儿转型的目标是不对的，转型的目的是提高生产力和投资收益率。团队需要研究如何改进自身过程并改善与其他团队的依赖关系。管理层需要不断地寻找一种方法去减少迭代循环的时间并提高产品质量。团队要学会去发现并改进过程，找到组织结构中的障碍，以便进行修正。（P180)
- 敏捷中的回顾会议，就是一个很好的持续改进的例子。
- 将测试行为移到开发过程之前进行。
- 挑选风险最小的素材进行开发（注意：最大的风险就是去开发不需要的功能）
- 使用最小可市场化功能来制定发布周期计划。
- 跨职能团队完成一个项目后再转入另一个项目。
- 进入"工作现场"（就是进入正在开发软件的工作之中）。
精益思想的三大主题模型
精益与敏捷的关系
