漫谈敏捷开发-精益和敏捷

聊聊软件开发
软件开发是一种非零和博弈，意思是某一方的获得不是建立在另一方的损失之上（赌 博就是一种零和博弈，获得和失去的总和等于零），所以软件开发必须实现双赢，帮助客户成功的同时帮助自己成功。如：通过软件帮助客户把手上的5块钱变成50块钱，然后从客户那里拿5块钱。通过软件帮助客户节约50块钱，然后从客户那里拿5块钱。

从精益说起
敏捷开发和丰田的精益思想颇有相似之处。传统的汽车制造是以计划驱动，如根据往年的经验判断今年应该生产多少汽车，但是这样带来的问题是有可能等汽车生产出来，市场已经不需要了，而这就是一种极大的浪费。精益思想是以价值为驱动的方法论，精益思想的核心是消除浪费，它认为不为客户创造价值的活动和尽管是创造价值的活动，但是所消耗的资源超多了“绝对最小”（投入产出比低）都视为浪费。浪费有七种：过量生产（生产多于所需），库存（不直接产生价值，并增加管理成本），搬运，返工，过程不当（对最终产品不能增加价值的活动），多余动作（任何不增加价值的设备和人员的动作），等待（两个关联的要素间，未能同步）。

再谈敏捷开发
敏捷开发的核心就是消除浪费。那么在软件开发当中应该如何消除浪费呢？

• 过量生产：在我们开发的产品当中，如果需求（用户故事）不是把握的很好，那么就会造成很大一部分功能用户从来都不会使用，这就是生产多于所需。所以我们需要用户和业务分析师（BA）或者需求分析师一起来规避过量生产。
• 库存：在我们的软件开发过程中，如果一直处于开发中，那么产品未给客户带来直接的价值，这就是一种库存。所以我们可以通过迭代开发和快速交付来减少库存。
• 返工：这个在软件开发当作比较常见，可能是对需求理解不透彻，开发出来的功能，不是客户所想的，导致返工。也有可能是当初的设计不合理，不能满足客户的新需求，导致返工。也有可能是开发人员不注意编码质量，导致代码的坏味道越来越重，最终导致代码无法修改，导致返工，我曾经遇到一个核心类有几千行，无人敢动。所以我们需要BA来规避需求风险，需要架构师来规避设计风险，需要好的基础和习惯来提高软件质量。
• 过程不当：我觉得这个主要体现在沟通方面。比如我和某同学讲述一个需求，如果别人不用心听，那么信息就不会有效的传递给他，或者是我表达的是A，而他听到的是B。所以在沟通的过程中一定要通过消除沟通壁垒来消除浪费，在表述者和聆听着之间存在两道沟通壁垒，减少第一个壁垒，表述者应该尽量站在聆听者的知识背景上去清楚的表达内容。减少第二个壁垒，聆听者应该怀着一个开放的心态，去用心的接收表述者传达的信息，不要在没完全听明白表述者传达的信息之前，就用惯性思维去抵触信息的传递。另外一点，我提倡定期沟通，而不是时时沟通，定期沟通是消除信息传递不畅导致的浪费，不提倡时时沟通，是为了减少开发人员的任务切换，从而提高效率。
• 等待：这个可能是不同模块之间的依赖和接口的联调需要等待，所以这个可以通过合理的计划来减少等待。也有可能是测试和研发的资源和计划不对称，导致开发的时候，测试闲置，开发完之后，测试资源不足。这个可以通过迭代开发持续交付的方式，来提高测试资源的利用。
• 多余动作，我觉得主要体现在重复开发。比如每个模块可能都会开发上传组件，分页组件和验证组件，可能都会调界面样式，可能花时间解决一个重复的问题。所以要减少多余动作造成的浪费，我觉得应该加强团队沟通，有专门的人负责公共组件的开发和复杂问题的解决。

我很喜欢这幅图片，我把它称为“举重若轻”，对于软件开发而言，它是一项非常复杂非常重的活动，那么如何能够举重若轻呢?我觉得应该采取敏捷的方式，将软件开发活动细化为一个一个非常轻的活动（迭代），那么我们就能做到举重若轻了。

SCRUM
SCRUM是一套敏捷开发的框架，说的是在进行一次敏捷开发的过程中，所需要参与的角色，进行的活动和输出的产物。
角色有三个：

• 团队负责人：作为客户代表，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI负责。没有BA的情况下，可以充当BA的角色，来规避因需求问题导致过量生产和返工所产生的浪费。
• SCRUM MASTER：主要负责消除团队障碍。我觉得他可以负责开发公共组件，解决复杂问题来规避多余动作。通过制定沟通机制，开发流程规避过程不当造成的浪费。通过协调开发计划，来规避等待所造成的浪费。
• 团队：一个完成的软件开发团队应该包括销售，售前，用户，研发，测试，售后等所有相关人员，因为任何几个角色都有可能导致软件开发的失败。对于团队而言最重要的是加强沟通，使信息能够准确的传递给团队的每一个人。

其他的不一一细说了，我认为SCRUM的核心是通过敏捷回顾来持续改进，从而消除浪费。因为在软件开发中遇到的小问题非常多，从而造成大量的浪费，所以必须通过敏捷回顾，不断的总结团队做得好的习惯和遇到的问题，在下一个迭代的开发中的解决这些问题。

XP
XP是实现敏捷开发的一些非常好的实践。

• 用户故事：是站在用户的角度和应用场景下来描述业务需求。格式为作为..我能..以便于..如作为网络管理员，我能查实时的查看每个设备的CPU利用率，以便于我能即时发现有问题的设备。
• TDD：狭义的测试驱动开发，是通过先写测试代码再写程序代码的方式，来理清编码思路和写有效的代码，之所以说有效的代码，是因为有时候写的方法，你会发现从来没有任何其他的方法会调用它，如多余的修改器（setter）和访问器（getter）。我强烈建议业务服务层代码使用TDD进行开发。进行TDD时很重要的一点是你要会使用IDE的部分快捷键，让代码自动生成。
• 持续集成：通过自动化构建工具（cc），持续集成版本，从而可以快速的反馈集成问题。
• 结对编程：两个程序员用一个电脑进行编程，一个人负责编码，另一个人负责思考，在编写之前需要和结对的同学表述自己的编程思路，从而将每一个程序员的优秀习惯传播给整个团队，但是遗憾的是结对编程对程序员的要求比较高，最好是两个程序员有一定的能力，并且能力差不多，如果一个能力很高的程序员和一个能力低的程序员结对可能效率很低。

最后推荐书籍：

• 《丰田汽车案例-精益制造的14项管理原则》
• 《硝烟中的Scrum和XP》

推荐博客：

• http://yizhituzei.blogbus.com 一只土贼的博客博客波波客

最近公司在逐渐引入敏捷开发，对以前的项目管理产生了很多启发，之后会再总结一些文章出来，欢迎各位拍砖！

为什么要引入? 具体引入什么?

嗯，主管觉得要与时俱进，所以决定引入敏捷开发，主管可能看重的是持续交付和持续改进。
目前引入了迭代开发，持续集成，敏捷回顾。
当然由于是逐渐引入，所以目前进行的敏捷开发看起来不是那么系统化，遇到的问题也很多，需要持续改进。

也就是说，其实没人明确说过，为什么要引入敏捷开发。
也没人说过，这些引入是针对你们组织目前的哪些不足。

的确是。不过也许maybe可能是信息停留在领导那里，未有效的传递出来。

其实引入敏捷开发的好处有很多，如：

在敏捷开发中处理BUG可以：
1.降低BUG处理的难度。因为设计和编码刚完成，印象深刻，新集成的代码比较少，定位简单。
2.有效的提高测试资源的使用。以前是整个版本完成之后才修改BUG，这会出现测试资源的闲置。
3.随时有可用的版本发布。就能够交付价值，或迅速定位问题所在，在下个版本中改进。

建议每天先确认有多少个BUG需要修改，每天抽2个小时解决BUG，严重的BUG即时处理。

对于进行敏捷开发的公司而言，每个公司的环境和资源不一样，所进行的敏捷开发的方式会不一样，SCRUM和XP只是用来借鉴和参考的，最重要的是能够通过持续改进的方式走出适合自己企业的敏捷之路。达到消除浪费，产生价值！

目前我们公司的团队组成比较复杂，是跨地域研发团队，实施敏捷其实很难，所以很多东西都剔除掉了，比如站立会议，改为日报，但目前来看效果不佳。

日报是最应该被废除掉的东西，异地的话，可以考虑各自举行站立会议，敏捷强调的是面对面沟通。

周报倒可以有也可以不有，我们现在周报是为了给上面看，建了个团队博客，每周发一次，但内容都是周会要口述的。

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。