精益软件开发七项原则
消除浪费，创建知识，快速交付，整体优化，内建质量，推迟决策，对人尊重
消除浪费
七种致命的浪费：
缺陷：
导致昂贵的返工 没有增加价值
传统开发：侧重在缺陷发生后找出缺陷，在后期修复发现的缺陷是特别昂贵的
改进方法：自动化测试，创建新的测试来检测这个缺陷
过度生产
运输-传递
典型的瀑布过程，其间充满了传递活动
等待-延迟
最有成效的安排：集成式产品团队（问的问题没有延迟）
半成品工作
已经开始但是尚未完成--->半成品
精益方法中使用单件流，使某项工作尽快的流到部署阶段
不让半成品工作在队列中堆积起来
一项工作只有在可进行部署，做了晚会智能的文档记录，经过测试和没有错误时，才可以说是已经完成了
移动-任务切换
任务切换和中断扼杀了生产力（不专注，重新启动，重新学习）
使用单件流，是某项功能特征或任务被持续完成
过度作业-不必要的流程
没有达成任何产出的过程，文档没有任何人能看懂，可以自动化却手工方式进行，原本可以很简单但是现在被弄得很复杂
内建质量
（大野耐一）：
不能在生产线的最后工序才检测产品的质量
过程中的每一个工序都应该能进行错误验证和自检
当发现问题时，整个生产线要停止下来，直到发现问题和纠正问题的根源，这样他就不会再次发生了
传统软件开发：
让缺陷一直到最后才被检测
精益的方法
在编写实现功能特征的代码时，就编写能够验证错误的测试
这些测试能够防止因引入未经检测的缺陷而造成的后续修改
创建知识
不要忘记已经学到的经验教训
不能烦同样的错误，团队成员也不应学你已经解决的东西
找到记录团队知识的办法
能够轻松的找到，存储相应部分知识，发挥最佳的判断能力，尝试保持良好的平衡
推迟决策
只有拥有大部分可用信息的时候，才能做出最好的决定
如果不必立刻做出一个特别的决定，那就等具备更多的知识和信息的时候再去做
（不能等太久 也不能阻碍其他项目）
可以同时探寻多个解决方案，但最终选择最好的那个确保最大的成功
快速交付
以较短的迭代，以小批量的方式开发功能特征，并快速交付给客户
在相关联需求能够调整前，这些功能特征就被实现并交付了
客户有机会在使用这些功能特征后提供反馈意见，并在其他需求实现钱就能进行调整变更
每一个段迭代完成时，都提供了一个机会，可以给予真实的反馈和使用，对需求进行调整和重新定义优先级
最终的成果是，获得一个更贴近客户实际需求的铲平，同时还笑出了大量的浪费和因需求造成的返工
对人尊重
积极投身其中，并思考着的人，提供了最可持续发展的竞争优势
不要浪费最宝贵的资源——团队成员的智慧
全局优化
在对一个本地的局部过程做优化时，几乎总是会以整个价值流为代价的瓶颈和机会成本
一般情况下，在尝试优化的过程中，应该总是包含尽可能多的价值流
精益创业环
精益创业环认为，软件产品的发展，是知识围绕客户“开发->测量->认识”的循环过程
精益思想原则
价值，价值流（业务流中有价值的活动），流动，需求拉动，完美
成本低，质量好，周期短，柔性高的产品
精益与看板产品开发框架
以精益思想为理念，快速产品验证对齐方向，确保产品做正确的事情，消除业务流中的瓶颈和等待，从理念，产品，实现三个方面构筑起新的高效研发模式
关键实践（1）采用MVP/MVF（最小可用产品/特性），快速验证客户需求
是传统快速原型方法的演进，将最小可用产品演示给客户看，使其能真正看到解决方案。演示可能是产品截图和实体模型，样式主要是关键特性，创新点
MVP原型分为：探索性，实验型，演进型原型
也可能扩展为最小技术框架原型（MVA）
后续调整：客户调整，业务结构调整，产品特征调整，技术调整，渠道调整，平台调整
精益创业过程
关键实践（2）产品功能特性探索和验证，实现产品特性快速验证和完善
产品功能特性探索和验证
通过客户和问题的假设，提出产品需要增加特性的假设，通过MVP构建并是寄给客户使用，不断搜集使用中的问题和反馈，以此反馈不断检验提出的假设，并调整架设。同时在产品应用过程中，形成稳定客户和销售模式
关键实践（3）看板管理展现价值流，通过拉动式管理，消除瓶颈与等待，提升交付吞吐量
敏捷和精益的区别
基本观点在哲学上不同
敏捷：
尽快交付可用的产品，可用的产品>文档
与客户保持密切协作
及时获得客户反馈
精益：
开发最小可用的产品
基于看板梳理价值流，消除价值流中的浪费
角度不同
敏捷
敏捷的关注点稍窄一些，主要关心的是围绕软件开发的具体开发时间和项目管理
一般不太关系在其中进行软件开发的商业上下文环境
精益
精益采用的是比较宽泛的视角，偏好一体看待软件开发以及整个业务环境
472
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
