待业的日子--工作总结

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

背景

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

敏捷介入

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

价值思考

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

做一个刚刚好的软件系统

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

纵向划分story

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

各种自动化脚本工具

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

保证大家都清楚

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

用例

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

TDD

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

结对编程

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

迭代回顾

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

更高的代价

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

相关推荐