漫谈敏捷开发-从精益到敏捷(摘录JAVAEYE)
软件开发是一种非零和博弈，意思是某一方的获得不是建立在另一方的损失之上（赌 博就是一种零和博弈，获得和失去的总和等于零），所以软件开发必须实现双赢，帮助客户成功的同时帮助自己成功。如：通过软件帮助客户把手上的5块钱变成50块钱，然后从客户那里拿5块钱。通过软件帮助客户节约50块钱，然后从客户那里拿5块钱。
从精益说起
敏捷开发源于丰田的精益思想。传统的汽车制造是以计划驱动，如根据往年的经验判断今年应该生产多少汽车，但是这样带来的问题是有可能等汽车生产出来，市场已经不需要了，而这就是一种极大的浪费。精益思想是以价值为驱动的方法论，精益思想的核心是消除浪费，它认为不为客户创造价值的活动和尽管是创造价值的活动，但是所消耗的资源超多了“绝对最小”（投入产出比低）都视为浪费。浪费有七种：过量生产（生产多于所需），库存（不直接产生价值，并增加管理成本），搬运，返工，过程不当（对最终产品不能增加价值的活动），多余动作（任何不增加价值的设备和人员的动作），等待（两个关联的要素间，未能同步）。
敏捷开发源于丰田的精益思想。传统的汽车制造是以计划驱动，如根据往年的经验判断今年应该生产多少汽车，但是这样带来的问题是有可能等汽车生产出来，市场已经不需要了，而这就是一种极大的浪费。精益思想是以价值为驱动的方法论，精益思想的核心是消除浪费，它认为不为客户创造价值的活动和尽管是创造价值的活动，但是所消耗的资源超多了“绝对最小”（投入产出比低）都视为浪费。浪费有七种：过量生产（生产多于所需），库存（不直接产生价值，并增加管理成本），搬运，返工，过程不当（对最终产品不能增加价值的活动），多余动作（任何不增加价值的设备和人员的动作），等待（两个关联的要素间，未能同步）。
再谈敏捷开发
敏捷开发的核心就是消除浪费。那么在软件开发当中应该如何消除浪费呢？
• 过量生产：在我们开发的产品当中，如果需求（用户故事）不是把握的很好，那么就会造成很大一部分功能用户从来都不会使用，这就是生产多于所需。所以我们需要用户和业务分析师（BA）或者需求分析师一起来规避过量生产。
• 库存：在我们的软件开发过程中，如果一直处于开发中，那么产品未给客户带来直接的价值，这就是一种库存。所以我们可以通过迭代开发和快速交付来减少库存。
• 返工：这个在软件开发当作比较常见，可能是对需求理解不透彻，开发出来的功能，不是客户所想的，导致返工。也有可能是当初的设计不合理，不能满足客户的新需求，导致返工。也有可能是开发人员不注意编码质量，导致代码的坏味道越来越重，最终导致代码无法修改，导致返工，我曾经遇到一个核心类有几千行，无人敢动。所以我们需要BA来规避需求风险，需要架构师来规避设计风险，需要好的基础和习惯来提高软件质量。
• 过程不当：我觉得这个主要体现在沟通方面。比如我和某同学讲述一个需求，如果别人不用心听，那么信息就不会有效的传递给他，或者是我表达的是A，而他听到的是B。所以在沟通的过程中一定要通过消除沟通壁垒来消除浪费，在表述者和聆听着之间存在两道沟通壁垒，减少第一个壁垒，表述者应该尽量站在聆听者的知识背景上去清楚的表达内容。减少第二个壁垒，聆听者应该怀着一个开放的心态，去用心的接收表述者传达的信息，不要在没完全听明白表述者传达的信息之前，就用惯性思维去抵触信息的传递。另外一点，我提倡定期沟通，而不是时时沟通，定期沟通是消除信息传递不畅导致的浪费，不提倡时时沟通，是为了减少开发人员的任务切换，从而提高效率。
• 等待：这个可能是不同模块之间的依赖和接口的联调需要等待，所以这个可以通过合理的计划来减少等待。也有可能是测试和研发的资源和计划不对称，导致开发的时候，测试闲置，开发完之后，测试资源不足。这个可以通过迭代开发持续交付的方式，来提高测试资源的利用。
• 多余动作，我觉得主要体现在重复开发。比如每个模块可能都会开发上传组件，分页组件和验证组件，可能都会调界面样式，可能花时间解决一个重复的问题。所以要减少多余动作造成的浪费，我觉得应该加强团队沟通，有专门的人负责公共组件的开发和复杂问题的解决。
敏捷开发的核心就是消除浪费。那么在软件开发当中应该如何消除浪费呢？
• 过量生产：在我们开发的产品当中，如果需求（用户故事）不是把握的很好，那么就会造成很大一部分功能用户从来都不会使用，这就是生产多于所需。所以我们需要用户和业务分析师（BA）或者需求分析师一起来规避过量生产。
• 库存：在我们的软件开发过程中，如果一直处于开发中，那么产品未给客户带来直接的价值，这就是一种库存。所以我们可以通过迭代开发和快速交付来减少库存。
• 返工：这个在软件开发当作比较常见，可能是对需求理解不透彻，开发出来的功能，不是客户所想的，导致返工。也有可能是当初的设计不合理，不能满足客户的新需求，导致返工。也有可能是开发人员不注意编码质量，导致代码的坏味道越来越重，最终导致代码无法修改，导致返工，我曾经遇到一个核心类有几千行，无人敢动。所以我们需要BA来规避需求风险，需要架构师来规避设计风险，需要好的基础和习惯来提高软件质量。
• 过程不当：我觉得这个主要体现在沟通方面。比如我和某同学讲述一个需求，如果别人不用心听，那么信息就不会有效的传递给他，或者是我表达的是A，而他听到的是B。所以在沟通的过程中一定要通过消除沟通壁垒来消除浪费，在表述者和聆听着之间存在两道沟通壁垒，减少第一个壁垒，表述者应该尽量站在聆听者的知识背景上去清楚的表达内容。减少第二个壁垒，聆听者应该怀着一个开放的心态，去用心的接收表述者传达的信息，不要在没完全听明白表述者传达的信息之前，就用惯性思维去抵触信息的传递。另外一点，我提倡定期沟通，而不是时时沟通，定期沟通是消除信息传递不畅导致的浪费，不提倡时时沟通，是为了减少开发人员的任务切换，从而提高效率。
• 等待：这个可能是不同模块之间的依赖和接口的联调需要等待，所以这个可以通过合理的计划来减少等待。也有可能是测试和研发的资源和计划不对称，导致开发的时候，测试闲置，开发完之后，测试资源不足。这个可以通过迭代开发持续交付的方式，来提高测试资源的利用。
• 多余动作，我觉得主要体现在重复开发。比如每个模块可能都会开发上传组件，分页组件和验证组件，可能都会调界面样式，可能花时间解决一个重复的问题。所以要减少多余动作造成的浪费，我觉得应该加强团队沟通，有专门的人负责公共组件的开发和复杂问题的解决。
wf1006 
wangq 
chyx413332087