传统软件开发方法
传统软件开发方法的共同特点是强调计划、管控和结构化的工程方法，并遵循严格的生命周期概念，把软件开发分割为顺序阶段构成的过程，瀑布式开发方法是其中的代表之一。
到了上世纪90年代初，CMMI和PMI项目管理知识体系成为传统产品开发管理方法的典型代表。
我个人认为，传统软件开发方法的假设是：需求确定后就不会变了。然而，时代变了，这个假设是否还站得住脚？
从另一个角度看，我们也就理解了为什么项目经理会对需求变更如此痛恨。你想嘛，项目经理的职责是让项目按时完成（想想KPI怎么定的？），立项后，工期就定死了，我一开始把项目计划做好了，需要变更了，你让我的项目如何按时完成？
所以，具有这样思维模式的项目经理面对敏捷和精益这样的概念时，第一念头就是：它们能帮助让项目按时完成吗？
当然，我并不是说项目按时完成不重要。而是想表达：我们应该清楚自己最终追求的是项目按时完成，还是做好的产品服务用户。
那么，如果“需求确定后就不会变了”这个假设不成立，我们的产品开发应该如何应对呢？
《精益产品开发》 从原则，方法，实施三个方面来说明我们应该如何应对。
产品开发与生产制造的不同
产品开发相对生产有两个最本质的不同：其一，价值的不确定性，它决定我们无法一开始就明确定义价值，或者说“价值定义”的过程应该是一个持续探索的过程，因此才有了精益创业、精益数据分析等实践体系；其二，过程的不确定性，如每个任务的处理时长不等，且可能在过程中发生变化，它决定了价值流动的管理和改进方法不同，如产品开发中看板方法就与生产中的十分不同。
在软件行业，产品开发与生产的本质不同，深有体会啊。生产常常有批量的含义，而产品开发没有，你听说过“批量生产软件”的说法吗？
部署与发布的区别
为更好地管理发布，团队应该区分发布和部署。部署属于技术范畴的概念，发布是属于市场范畴的概念。它们具有如下意义：
- 部署（deployment）：将软件安装到一个特定的环境
- 发布（release）：让一个或一组特性对应用可见和可用。
上家公司时，我们每周会部署两次，没做完的新功能，我们同时会部署上去，只不过，用户是看不到这些功能的，应该feature toggle是off的，偶尔也会向部分用户打开。
等我们确定功能完全OK了，就会把相应的feature toggle完全打开，所有用户就可以看这个新功能了。
这是区分了部署和发布两个概念的做法。
而现在所在家公司由于历史原因，服务器要跟着APP的版本走。APP端的人每个月发布一次，以至于管理人员也认为服务器端也必须一个月发布一次。导致的问题之一就是服务器端一次性部署大量的服务，不论这些服务是否有变更接口外在行为。
这是没有区分部署和发布两个概念的做法。
看板系统的设计、站会的设计
- 看板系统能全面地反映需求交付过程吗？
- 瓶颈和问题能在看板墙上得到即时体现吗？
- 团队可以根据看板墙上的信息协作和做决定吗？
只要问这三个问题，你就知道你的看板系统设计如何。
何勉老师在书提到了一个案例：一家企业网盘的需求被两端——前端和后端——分别实现。团队也按前端和后端来区分。每个团队还有各自的测试人员。
面对这样的情况，我们如何处理，才能更好的交付产品价值呢？我目前所在公司也遇到同样的问题，一个产品的开发甚至涉及到服务器端、APP端、Web端、硬件端。
一个需求同时涉及这么多的端。看板系统如何设计？如何站会？如何测试？好问题。
从这本书里，我得到的答案是：
- 只要这个需求的涉及人员的任务卡片都应该放在同一个看板上，有时甚至包括市场人员。
- 站会时，只要这个需求的涉及人员都应该在一起站，有时甚至包括市场人员。
小结
这些只是一部分，书中的很多想法击中了我。因为现实，我就遇到这样那样的问题，苦于不知如何解决。
另，回过头来看，不管传统软件开发方法，精益，还是敏捷，我们都应该始终记得不论开发、测试、项目管理人员，公司决策层，我们的最终目标：为用户提供更好的服务。按时完成任务只是我们达到这个目标的手段。
但是如何才能达到这个共识呢？留给读者一个问题。
