打开网易新闻 查看精彩图片

精益生产（Lean Manufacturing）是一套源自丰田生产系统（Toyota Production System）的管理方法，由丰田喜一郎、大野耐一 、新乡重夫、 丹尼尔T琼斯、詹姆斯·沃麦克 等人逐步整理与发展。它的核心精神并不只是提高生产速度，而是从客户真正需要的价值出发，重新思考产品、生产流程与工作的安排方式。

在精益思想中，企业应该先确认市场与客户的实际需求，再投入资源进行生产，而不是先大量制造产品，再期待市场接受。同时，通过将复杂流程拆分成较小的工作阶段，团队可以更容易发现问题、改善品质，也能降低不必要的等待与浪费。

更重要的是，精益生产并不是一套执行一次便完成的管理工具，而是一种持续改善的工作方式。每位参与生产的人，都需要思考如何提升品质、生产力与效率，找出最适合自己的工作方法，并持续检视与改善既有流程，而不是一味沿用过去的做法。

精益生产（Lean Manufacturing）的核心概念

  1. 开发产品应着重于需求而非供给端，简单来说就是做别人想要或是已经下订产品；而不是先做一个产品，再期望有人会想买这个产品
  2. 如果将整个制造过程切成数个小段的生产区间，则能提升效率
  3. 花费时间思考如何提升产品品质与生产力及效率
  4. 生产者有责任找出最适合自己的工作方式
  5. 生产者有必要持续改善自己得工作方式，而不是一昧的追寻以往既定的做法

此外也必须减少资源浪费，指的是任何无法创造价值的事情都必须要被排除。以下以软件开发为例，举出七种资源浪费情境

1. 过多做到一半的工作

当功能定义, 规格, 设计等文件被工程师实际写成软件之前，都算是做到一半的工作，因而造成浪费(因为没有实际产出)

2. 过度加工

在产品规划过程中，花费大量的时间反复纠节于小细节上是不必要的，例如PM开的规格书或是设计师的设计草稿；但由于现代社会的分工，每个员工被要求做出完美的文件或相关产出

3. 一人多工

同样在现代社会，公司为了挤出员工的最大产值，常常出现一个人需要同时处理多个专案的状况；但软件开发是需要抽象与创新思考的工作，当员工不断的切换心智来处理不同专案工作时，中间转换思考的时间就是一种浪费

4. 等待与延迟

当产品Owner与团队没有良好搭配时，通常会造成过多等待时间的浪费，因为团队前进需要产品Owner的决策或是检视相关工作结果并给予反馈，没有反馈或是较慢的反馈，都会导致产品开发进度缓慢或是没有进度

5. 忽视产品缺失(增加修正时间的浪费)

随着产品不断开发，越晚发现产品缺失，则需要付出越大的心力来修正这些缺失。解决方式就是快速反馈，快速测试，找出问题后即时修正及优化。很可惜的这样的情况并不常发生，因为团队需要一个"自在"的场合来分享并吸收这些反馈与建议，如果没有则产品Owner必须要自己创造这样得场合

6. 交付

产品文件或讯息往往在交付给下一个人的过程中产生认知误差或错误，甚至造成制作延迟与制作缺失

7. 过度生产

顾名思义就是开发根本没有需求的功能出来。预防过度生产的做法就是使用Smallest Possible Feature or Product(MVP)的概念来开发产品，必且先验证产品的需求假设，再进行规模化或是优化开发

如果希望更有系统地掌握精益管理工具与方法，可以参考优思学院提供的线上课程内容。除了阅读相关知识外，通过专业课程学习会更有效率，从基础概念到实际案例，都有助于建立更完整的精益管理知识体系。

敏捷开发(Agile Development)历史

敏捷开发是一个概念，而不是一个规范，当然现在已经有许多方法与工作流程被设计出来，实践这样的敏捷开发概念，但实际上还是必须依照自己公司文化，思考出可行的方式，一步步落实才能成功。

另外，由于敏捷软件开发一开始是由工程师们所讨论出的概念，因此最初并没有考虑到如何将设计师纳入这样的开发概念内，因此后来又衍伸出敏捷设计(Agile UX)等想法，试着将设计团队融入敏捷开发。

敏捷宣言(Agile Manifesto)

2001年17个软件开发者于美国犹他的一间饭店中，讨论各种软件开发上遇到的问题与解法，并融合为一个基本共识，也就是敏捷宣言。

  1. Individuals and interactions over processes and tools
    团队内的互动重于工作流程与工具
  2. Working software over comprehensive documentation
    实际的软件产出重于详细的规格文件
  3. Customer collaboration over contract negotiation
    与客户合作重于合约谈判
  4. Responding to change over following a plan
    针对问题快速改善重于遵循既定作法

过了几个月后，根据上述四个核心价值，衍生出更实际的12个原则

  1. 团队最优先的任务，是透过及早并持续地交付有价值的软件来满足客户需求。
  2. 欢迎客户改变需求，甚至已处开发后期亦然。敏捷流程掌控变更，以维护客户的竞争优势。
  3. 经常交付可用的软件，频率可以从数周到数个月，以较短时间间隔为。
  4. 业务人员与开发者必须在专案全程中天天一起工作。
  5. 积极的辅助成员来建构专案，给予他们所需的环境与支援，并信任他们可以完成工作。
  6. 面对面的沟通是传递资讯给开发团队及团队成员之间效率最高且效果最佳的方法。
  7. 以产出可用的软件作为最主要的进度评估方法。
  8. 敏捷程序提倡可持续的开发。赞助者、开发者及使用者应当能不断地维持稳定的步调。
  9. 持续追求优越的技术与优良的设计，以强化敏捷性。
  10. 以精简为本，它是极力减少不必要工作量的艺术。
  11. 最佳的架构、需求与设计皆来自于能自我组织的团队。
  12. 团队定期自省如何更有效率，并据之适当地调整与修正自己的行为。

总结

精益生产与敏捷开发其实有许多相似之处，例如将长期专案切成各个短期目标进行开发，并快速交付给客户或是进行需求验证，重视团队内的合作关系与沟通，强调团队及个人皆需思考如何优化自身的产出。

而两者不同之处在于一个是偏向硬件产品生产，另一个则是聚焦在软件开发上。因此精益生产非常重视资源浪费，并提出七种避免资源浪费的情境，但不代表这些避免浪费的原则，就对软件开发没有帮助，应该要学习这两种开发方式的优点，并以自己做得到的范围开始实践，朝向这样的目标前进。

不一定要被称为敏捷开发才能敏捷