待业的日子--工作总结_项目管理_非技术区_程序员俱乐部

离职一个多月了。前几天进行了第一次面试，问了下你觉得敏捷有什么好处，还一下把我给问住了，所以特来写篇博文梳理一下我的认识的敏捷。水平有限，敬请谅解。

背景

在我入职前，大版本的开发和交付要经历较长的时间，质量很不稳定。由于对软件质量要求较高等各种原因，没人敢乱动乱码， 但是新特性还要开发，导致整个代码臃肿不堪，上千行的函数随处可见。最后的最后，大家发现这不能忍啊，活没法干下去了。

敏捷介入

公司花重金聘请了敏捷顾问团队，跟项目组共同开发特性，进行一对一的敏捷培训。效果上说还是达到了目的，开发效率，产品质量都有了很大提高，支撑了之后多个版本的稳定开发和交付。敏捷顾问撤离，还是保留了每日版本构建，项目组持续集成，状态墙，TDD，结对编程，每日站会等敏捷实践和活动。

价值思考

其实这一点我后续的实际体会不多，都是从老员工的讲述中得到的。敏捷顾问当时非常强调从价值出发去考虑问题，再分析特性的时候，会以”这个特性有什么价值“、”这个特性不做会怎么样“、“这个特性要满足什么目的”，“这个特性有副作用”这样的思维方式去思考特性的价值。这样想清楚了才会去思考方案有什么，哪个方案最合理。通过价值思考可以明确特性开发完后软件的外部行为是什么样的，会引导你思考开发的代价，收益率这些问题。不过还是做了很多没用的特性，我们都知道价值不大什么没价值，但是，哈哈。。

做一个刚刚好的软件系统

在明确特性的价值和目的后，就要思考投入多少资源去做成什么样子了。一个仅仅用于演示和一个要在全球部署的特性当然是完全不一样的。一开始我觉得在早期做的好一点会更好吧。但是在后面的实际工作中，发现你的精力，资源都是有限的、总有人会提出垃圾的需求做完后被废弃、还有就是把代码写好然后去拥抱变化吧。大型的软件系统应该是逐步演进，那么就不必纠结于一开他有多简单了。

纵向划分story

在划分story的时候更习惯横向地思维方式。拿切蛋糕来作比喻，story应该是一小块完整的蛋糕（可测试，可交付）；而不是被划分成水果层，奶油层，蛋糕坯。可以工作的软件胜过面面俱到的文档。

各种自动化脚本工具

敏捷不光有一组理念，一些支撑这些理念的方法论，一堆支撑这些方法论的实践，还有支撑实践地工具。有现成的各种单元测试框架，有持续集成工具cruisecontrol等等，但也有很多不适用于本项目组甚至没有的工具，就需要自己去开发很多脚本和工具来提高生产率。总之就是能用机器干的，就别手工劳动。通过工具可以很好地提高团队的开发效率，更重要的是承载了处理问题的宝贵思路和经验。

保证大家都清楚

早期开发和测试分家的时候，开发完了然后交给测试，然后各种bug，各种攻关关，各种延期，各种哈，身心憔悴啊。最崩溃的是开发认为这不是问题，但是测试觉得这直接关乎x亿用户的正常使用啊。其实到底是不是风险，影响有多大，谁知道呢，bug在运行几年后才随机出现，而且无法复现的情况有的是。所以理想的情况是开发，测试，项目经理，维护等各路人马对特性，目标，影响，潜在风险等都非常明了，甚至提出自己的意见使方案看起来是经过各个角度的深思熟虑的。后续因为实现、进度等原因的变更也要及时知会，这样，辛辛苦苦写完代码推翻重来的风险大大降低。在大公司，沟通永远有着高昂的成本。

用例

我认为用例是设计、实现层面最好的书面材料和沟通媒介。通过用例详细描述特性或者问题修复后的软件外部表现，提供明确的运行结果，直观，无二义性，有说服力。后期如果能加入自动化用例库，至少在版本发布前大家心里都有底。如果护周期很长的软件系统有很长的维护周期，自动化用例库和团队内部使用的形形色色的自动化工具，是最宝贵的资产。

TDD

先写用例，再写代码。一开始的时候还真是把人给憋的，几十分钟写个用例还真是很痛苦。到后来不写几个用例还真不会写代码了。其实在写代码之前能否写出用例，可以说明是否理解了需求或方案，根据方案设计代码应有的执行结果，对代码的逻辑流程，异常输入的处理是否思考到位。而不是在写代码的过程才去取理解问题，并不断修改代码。遵从TDD写出来的代码短小，逻辑清楚。但是也有一个问题，通过打桩，用例来驱动coding只是代码的写作方式，并不是设计，一堆mock并不能解决缺乏设计而导致的缺乏灵活性，缺少维护手段等问题。

结对编程

在老员工带新员工的时候效果不错。倒不是说对代码本身的学习，老员工高效率的工作方式让人受益匪浅。不过我也看到过老员工之间及其默契的结对，当一个人还没明白为什么用例失败的时候，另一个人已经把代码修复了。至于提高代码质量上，我倒是没发现有不可替代的价值。

迭代回顾

从我自身的经验来看，迭代回顾会议的效果十分有限。迭代回顾并不能解决各种老大难问题，很多问题几乎在每个迭代回顾会议上都能听到。不过倒是一个充分沟通的平台，至于下情能否上达就是另一回事了。不过一些能立即实施的措施，经验倒是能在迭代回顾会议上得到传播。不过只要团队的内部沟通顺畅，这都不是问题。我认为迭代回顾会议的目的应该是站在团队层面，对迭代中不符合预期的情况提出解决的方案，提升团队的效率，逐步完善团队能力。

更高的代价

敏捷对每个人的能力要求还是很高的，或者说要付出的代价是很大的。比如工具，敏捷还是比较依赖工具的，在我们产品内部，由于项目组较多，导致有各种各样自己开发的工具，有python2.7的，python3的，有tcl的，有shell的，有bat的等等等等，这维护代价。还有就是如果一个特性做出改动，一天甚至更多的用例修改也是让人感觉厌烦的事情。