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

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

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

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

[b]SCRUM[/b]
[color=red]SCRUM是一套敏捷开发的框架[/color]，说的是在进行一次敏捷开发的过程中，所需要参与的角色，进行的活动和输出的产物。
角色有三个：
[list]
[*][u]团队负责人[/u]：作为客户代表，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI负责。没有BA的情况下，可以充当BA的角色，来规避因需求问题导致过量生产和返工所产生的浪费。
[*][u]SCRUM MASTER[/u]：主要负责消除团队障碍。我觉得他可以负责开发公共组件，解决复杂问题来规避多余动作。通过制定沟通机制，开发流程规避过程不当造成的浪费。通过协调开发计划，来规避等待所造成的浪费。
[*][u]团队[/u]：一个完成的软件开发团队应该包括销售，售前，用户，研发，测试，售后等所有相关人员，因为任何几个角色都有可能导致软件开发的失败。对于团队而言最重要的是加强沟通，使信息能够准确的传递给团队的每一个人。
[/list]
其他的不一一细说了，我认为SCRUM的核心是通过敏捷回顾来持续改进，从而消除浪费。因为在软件开发中遇到的小问题非常多，从而造成大量的浪费，所以必须通过敏捷回顾，不断的总结团队做得好的习惯和遇到的问题，在下一个迭代的开发中的解决这些问题。

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

[b]最后推荐书籍：[/b]
[list]
[*]《丰田汽车案例-精益制造的14项管理原则》
[*]《硝烟中的Scrum和XP》
[/list]

[b]推荐博客：[/b]
[list]
[*]http://yizhituzei.blogbus.com 一只土贼的博客博客波波客
[/list]