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

发表于:2013-03-20来源:letagilefly.com作者:徐 毅 标签:敏捷
敏捷和瀑布对接所面临的问题,我们就曾经历过一次事件,我个人对此印象很深刻。某天中午时分收到印度同事来信,说他们发现了一个 bug ,需要我们团

  敏捷和瀑布对接所面临的问题,我们就曾经历过一次事件,我个人对此印象很深刻。某天中午时分收到印度同事来信,说他们发现了一个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

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)