诺基亚实施敏捷软件开发的前世今生(2)

　　敏捷和瀑布对接所面临的问题，我们就曾经历过一次事件，我个人对此印象很深刻。某天中午时分收到印度同事来信，说他们发现了一个bug，需要我们团队的帮助。我时任团队(团队名：Thunder;取意雷霆一击)ScrumMaster，我判断认为不需要现在打扰团队，可以等到Scrum日会时再告知团队成员并商量处理方案，于是乎，从班加罗尔-杭州这个角度来看的话，我们并未作出回应。让我吃惊的是，下午大概2~3点的时候，又收到对方的一封邮件催促，邮件内容大意是，要求我们尽快或立刻调试解决此bug，他们有50多名测试人员因为这个bug的阻碍而无法继续干活……

　　FemtoGW项目扩张很快，我们很快又填充了很多前西门子的同事，也增加了很多新招聘进来的同事。不得不说，就我所接触过的那几位前西门子的同事，的确能力很强，包括丁俊华、滕帆(两人最开始都在Thunder，后来去其他团队担当ScrumMaster，也是我们虚拟架构师团队的成员)等，以及和我不争不相识的测试同仁刘哲文。当然，我还见识了出自华为的卢红旭同学敢加班敢熬夜的牛逼精神，就是可惜这小子花了太多时间在炒股上。

　　王婆卖瓜，自卖自夸。要问我谁最棒，我一定告诉你，那就是我们Thunder团队的兄弟们(包括几位姐妹)最棒!虽然一直都是人来人往，但Thunder的精神却一直延续着。我还记得他们都是(如有遗漏，敬请谅解，并联系我加进来)：李程远、丁俊华、滕帆、陆宏斌(后继任ScrumMater至今)、胡振东、张博涛、胡笳、Zhao Congxin(女)、张翠香。我依然记得，曾经，因为Sprint即将结束，我们却被一个小bug给困扰无法通过持续集成，我和陆宏斌、胡振东一起加班奋战到凌晨3点多终于搞定，带着极大的满足感打车回家，但是……等我到家门口一掏裤兜才发现忘记拿钥匙，兜里总共只有100来块前，刚好够打车到公司往返的路费……

　　我还记得，第一个Sprint，我们就100%全部满足了DoD的所有要求，这几乎是我们团队甚至项目所有团队的唯一一次，而且这个DoD的还设定得非常苛刻，没记错的话，我们要求代码覆盖率必须超过85%、圈复杂度低于5。也正因为太苛刻难以达成，后来就降低了其中的一些要求。不过，其中有一条要求到最后也没有改变或者是拿掉，那就是：DONE意味着除了在本机或测试机上测试通过，还必须在CI环境下测试通过。这其实是一个非常苛刻的条件，团队越多越苛刻。能够做到这一点，时任部门经理陈濯非(昵称：Trophy;他虽不在项目里挂名，但却非常关注和投入这个项目)的大力支持功不可没，我们从一开始就明确了CI纪律必须遵守不得违反，一旦build失败所有人都不准check-in代码。为了帮助团队做到这一点，我们组建了一个虚拟的CI团队，我记得至少包括我、@秦之远、黎晰和其他几个开发，组成类SWAT团队。专门负责照顾CI实践的健康运转，如果CI出现问题，例如build失败，我们就要集合起来，去定位问题然后分发问题甚至直接解决问题，确保CI系统中的build一直正常。而@秦之远也就是从这个时候，开始钻研CI，并逐渐成长为组织内当仁不让的CI专家。

　　@hanzhi窦是我们的产品负责人(Product Owner，简写为PO)，在此之前，他是我们CCC(Chorus Competence Center)的几名技术专家之一，有着深厚的技术积累。加入FemtoGW项目后，就走上了敏捷的道路，成为了一名PO。关于PO这块的工作，和他交流、学习是上佳之选，我就不再废话。不过有一点，我想要告诉大家，FemtoGW项目包括老产品近600人的研发，我们用来管理产品列表的工具都是Excel。我想老窦对我最深刻的印象，估计是“刺头”，每次Sprint评审会议，30几好人济济一堂，总能听到我抗议、反驳其他团队介绍其需求已经DONE的结论，我坚持要求严格地按照DoD的标准判决，DONE就是DONE，NOT-DONE就是NOT-DONE，没有中间的灰色地段。尤其是在所有团队连续三四个月都无法DONE掉任何一个用户故事(因为CI的build一直fail)，老窦非常想要通过DONE来增进团队的成就感、提振团队士气的时候，我却一如既往的坚持不妥协(呃，Thunder团队自己也无法DONE，CI影响到的是所有团队)……

　　当时，我们还对一个重要实践进行了尝试 —— ATDD(Acceptance Test Driven Development，接收测试驱动开发)。我则几乎全程参与了这个尝试，但我个人感到非常遗憾的是，后半程王献接手后，他跟老窦一起把它从一个实践变成了一个流程。我跟王献和都是好友，但这个操作，我个人确实难以认同，因为我认为ATDD的关键就在于互动和交流，这个流程则极大地削弱了它们的作用，或者说“解除了对它们的依赖”。

　　当时在组织内有好几个改进措施，都给ATDD的尝试打下了基础。

　　对robotframework的全面采纳和推广：我是测试自动化组最初的两名成员(我和俞森，组长是邹仲毅)之一，经历了多个工具的兴衰，时任robotframework内部培训师和测试自动化教练。robotframework的试点非常成功，也很适合敏捷这种研发模式，所以被大范围推广，以图提高自动化比例。这个工具本身就是面对接收测试(Acceptance Test，敏捷下有了新的含义，和过去的UAT不同)的，也支持ATDD。

　　用户故事兴、功能SPEC衰：敏捷转型对我们当时沿用的研发模式和流程产生了极大的冲击，其中就包括FRS(Feature Requirement Specification)，此feature非彼feature，不是敏捷环境下常说的特性，可看做是多个模块构成的一个小功能集。当时对于开发和测试来说，这是一份非常重要的文档，它是开发和测试的依据。转向敏捷之后，有了用户故事，FRS就显得有些多余，然后陈学凯牵头在想办法如何能妥善地处理或转化这份文档的内容。商讨过程中，结合robotframework测试用例的一些特点，我提出了“Executable Requirement”(可执行需求)的设想，我想这跟Gojko Adzic在《实例化需求》中提到的“Living Documentation”(活文档)有异曲同工之妙(ps. 他也采访过我哦，英文版鸣谢名单里有)。

　　Elisabeth Hendrickson：这主要是对我个人的影响。Elisabeth是敏捷测试方面的专家，曾获得敏捷联盟2010年的Gordon Pask大奖，她曾开办有Quality Tree公司提供敏捷、敏捷测试方面的咨询，由于刚刚加入了Pivotal Labs公司，她已经不再经营此业务。我非常有幸能够在我迷茫和犹豫的时刻，参加了她的敏捷测试和ATDD培训(5天)，这位受人尊敬的专家(据Michael Bolton八卦说，好像是Brian Marick吧都认为跟她抢单失败一点都不丢脸)也和我有相似的观点，让我倍受鼓舞，更加坚信我的测试理念和坚持并非不切实际也绝不理想化。她介绍ATDD的文章，可以在她网站上免费下载，点击这篇博文即可。

原文转自：http://letagilefly.com/post/2013/03/%e8%af%ba%e8%ae%b0%e6%95%8f%e6%8d%b7%e4%b9%8b%e5%89%8d%e4%b8%96%e4%bb%8a%e7%94%9f-10201.html