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

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

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

　　我还记得，第一个Sprint，我们全部满足了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的文章，可以在她网站上免费下载，点击这篇博文即可。

　　对持续集成纪律的遵守：因为我们对持续集成相关纪律的坚决执行和绝不姑息，使得我们可以长期拥有可工作的build；当然也因为我们在SCM（问@秦之远）和测试自动化两方面（问我）取得的一些成。虽然ATDD实践本身，严格来说并不依赖自动化，全手工方式进行测试，也可以使用ATDD实践，但缺少测试自动化和持续集成的话，Scrum无法提高成效、迭代增量式也难以真正体现其威力。

　　至于老产品那600多人的转型，吕毅作 为其中一大需求领域的部门经理，有很直接的体会；以及其他很多的同事，不再一一列举了。这个过程绝不是蜜月之旅，相反，经历了长时间的混乱（有点像团队 模型中的磨合期）。从矩阵式按职能划分的组织结构，直接转变为按产品需求领域划分、以跨职能特性团队为基本构成单元的组织结构，IPA经历了近半年的混沌 期。随后才渐渐地摸出门道，走上正轨。我记得，后来我曾问过王献：从你质量经理的角度看，咱们的敏捷转型是成功的吗？（他时任质量经理，后掌管杭州质量部门，现已转战另一产品线。我、俞森、王献，从前纬创到外派诺基亚一直都是队友，后来各自有各自发展道路：俞森测试一条路走到黑；王献转战质量；我则移情敏捷。）他说：各种质量指标、交付速度等都有提高。