敏捷无敌之DevOps时代
上QQ阅读APP看书,第一时间看更新

第03章 橄榄球与敏捷软件开发

阿捷在帕洛阿尔托的一切都进行得异常顺利。

由于Charles只提了阿捷这一个候选人,所以阿捷也没有什么压力。在程式化地回答了自己哪年加入Agile,都在什么公司做过怎样的职位之后,几个面试官分别从不同的角度了解了阿捷对Agile公司和这个职位的看法。

阿捷发现,国外面试和国内面试最大的区别其实在于:国内的面试大多都是在研究如何考你,而国外的面试更多的是在于了解你。首先去了解你是一个怎样的人,其次是了解你是否真正适合这个职位。人和人都是平等的,对于一个职位也只有适合和不适合。

对于面试,有三个问题让阿捷记忆犹新:第一,分析Agile公司现在在业界技术上的优势和劣势;第二,如果让你带领中国的TD团队,你觉得哪里最需要改进;第三,你觉得TD项目能够为Agile公司带来怎样的收益。

阿捷知道,在Agile做一名一线经理,不仅仅是管理好技术带好队伍,还要有项目预算和规划的能力,并能够由此帮助总部研发中心开拓本地的市场。这就是所谓的矩阵式管理中阿捷这颗螺丝钉应做的事情。

又逢周五。忙完一周工作,阿捷独自回到家里,遛好了小黑,自己却没有什么心思吃饭,凌晨一点还要和美国那边开电话会议,睡觉怕又是后半夜了。小黑吃饱了,把头搭在阿捷的拖鞋上睡着了。

阿捷决定还是先打个瞌睡。可是,上好闹钟,躺了下来,睡意全无,只好瞅着天花板出神。透过窗外昏暗的灯光,阿捷注意到屋角有一只小飞虫,不停地飞来飞去,一会儿撞上这面墙,一会儿又撞上另一面墙。阿捷叹了一口气,多么像以后的自己啊,可能以后会撞得更加体无完肤。

既然没办法静下来,阿捷决定还是上网消磨一会儿时间。

在《浩方》(一个游戏对战平台)上激战了一个多小时的CS(《反恐精英》)后,阿捷把自己的郁闷一股脑地撒向对方,也不知道打了多少个回合,点杀了多少位英雄。直到闹钟响起,阿捷才发现已经到了零点,要赶紧准备晚上的电话会了。

屏幕从CS切换过来后,阿捷发现屏幕上有一个MSN小窗口在不断地闪啊闪,这么晚了,谁啊?

打开MSN窗口,发现原来是大学的室友猴子。

“Hi,阿捷!在吗?怎么不说话?”

“瞎忙活什么呢?”

“不在还开什么MSN,浪费感情。”

阿捷心里一笑,一边心想“这个猴子,还是这个猴急脾气”,一边回复道:“Hi,猴子,不好意思啊!我刚才CS呢。”

“哦,我说呢,没事!趁着周末,那还不大家一起切磋切磋,来个通宵?”

“啊哈,那可不敢,你当初在学校里面打DOOM(《毁灭战士》,一款动作设计游戏)就那么厉害,我不是自讨苦吃啊。”

“少来!又不是想灭你,我们一起组队灭其他人啊!现在不是搞什么北京CS社区大赛嘛,我们这个小区总是凑不够,你来帮帮忙。”

阿捷只好实话实说:“哎,今晚不行啊,马上要和美国那边开电话会呢,改天陪你通宵吧。”

“不错啊,升官了吧?都赶上和美国那边开会了。”

“哪里。就是我们原来的头儿被别的公司挖走了,我被大老板抓了替罪羊,顶着雷呢!好麻烦啊,不知道该怎么搞!”

“难得的机会啊!好好干!以后多弄几个名额把咱们兄弟几个都招进去啊,然后下班就联网打CS!”

“你这死猴子,哪儿那么容易。我最近脑袋快赶上大头同学了,头发也白了不少。项目时间紧,任务重,老板给的资源还少,这可怎么干啊?”

“嗯。我知道都不容易。对了,现在不都是流行什么敏捷开发嘛,既然你都是经理了,为啥不在你的项目组里也玩玩敏捷开发呢?”

阿捷还没来得及和猴子解释“其实自己就是个代理项目经理,还没有真正一线经理的权力”,就被猴子所说的敏捷开发所吸引了,“敏捷开发?没有听说过啊!我们Agile公司一直遵循的是瀑布开发模型。”

“那你们也太老土了吧。怪不得你们的项目经理都被别人挖走了。其实我也没研究明白。你知道的,我们这个网络游戏行业会接触到很多关于VC的故事。最近老听人讲,如果现在想拿投资,VC考察的第一个指标就是,你是否在实施敏捷开发,否则一切免谈!我们那会儿,大伙比着烧钱,现在都不敢乱烧了。”

“这样啊,看来‘敏捷’真的很流行!但是如何能够真正敏捷起来做开发呢?我现在在项目管理上就有很多问题啊。”

“那我也说不明白。这样吧,给你推荐一个敏捷论坛,里面有很多关于敏捷开发的介绍,要是你能找到‘敏捷圣贤’这个人,也许你的这些问题就都能够找到答案了!”

“敏捷圣贤?好奇怪的名字。是个什么人啊?哪个公司的?”

“我也不知道。很神秘的一个家伙,我只是之前想用敏捷开发的方法开发网游而在那个论坛上发过帖子,结果只有他非常详尽地解答了我所有的问题,并且告诉我那个项目用敏捷开发并不合适。他真的很牛,基本上所有关于敏捷的事情他都能告诉你!”

“哦,这样厉害啊。多谢了,我回头泡泡论坛去。猴子我不能多聊了,马上1点了,我开会了。下回联手CS吧。”

“好,加油!阿捷,你小子还要多练练枪法啊。再见!”

这些天,阿捷一直泡在这个敏捷论坛里面,吸收着关于敏捷的点点滴滴,囫囵吞枣地理解着“敏捷”。阿捷发现,这个号称最大的敏捷开发中文论坛里面,混杂着这样几种人。

· 真正的“大牛”,很少发言,但每次发言都一语中的。

· 像自己这样只看文章但很少回复的潜水员。

· 一些厂商的代表,不遗余力、不分时机地发布着垃圾产品广告。

· 一些貌似正在实施敏捷的人。

阿捷把自己项目中遇到的问题,在论坛里发了帖子请教别人,却无人问津。没过两天帖子也就被别人用无聊的灌水淹没了,而期望的“敏捷圣贤”却一直没有出现。

阿捷满怀希望地问了很多人,可是没有人能够解决他的问题,也没有人知道如何找到敏捷圣贤,甚至许多人都没听说过论坛里有这么一个ID(身份证明)!几经周折,阿捷终于在论坛早期的精华帖中找到了一个邮件地址crystalagile@gmail.com,据帖子主人说,曾经有一个叫“敏捷圣贤”的朋友通过这个邮件地址和他讨论过软件工程方面的问题,由此促使他写下了这篇帖子。

阿捷用这个电子邮件地址试着给传说中的“敏捷圣贤”发了一份电子邮件。

敏捷圣贤:

你好!别人都这么称呼你!我也只好这么称呼你了。

我现在遇到一些很棘手的问题,我在论坛里发了很多帖子,但是没有人能够帮助我。有人告诉我,可能只有你才能帮助我!

我是Agile公司的一名项目经理,之前我们采用的传统软件开发模式已经不能满足现在的需要。我想采用敏捷的方式来帮助我们进行开发。

我看过《人月神话》,我知道对于目前的软件开发,还没有什么“银弹”,但我还是希望从你那里获得帮助,能解决我的问题!

如果方便,可以回邮件或者加MSN吗?我的MSN是agilejie@ hotmail.com。

盼复!极其盼复。

阿捷

时间一天天过去。白天上班,阿捷还要和大民阿朱他们一起为了项目早日发布而浴血奋战,晚上则依旧是一周两次和美国总部那边开电话会。在其他的时间里,阿捷如饥似渴地学着敏捷的知识。阿捷有一种预感,如果还有一种方法可以帮助他们按时发布Agile OSS 5.0的TD-SCDMA产品,能够帮助中国的销售团队拿到中国移动的TD订单,那就只有“敏捷开发”。阿捷还有一种预感,那就是敏捷圣贤一定会给他回信。阿捷每天下班回到家,第一件事情就是去查自己的MSN上有没有新加入朋友的请求,而每次的结果都很失望。渐渐地,阿捷的心已经有点凉了,自己有时候也在找借口安慰自己:“反正项目延误也不是TD一个项目组的事情,周晓晓和Rob他们两个组的进度更慢。”

又一个周五的晚上,时钟已经指到了凌晨两点,小黑早就已经回到自己的小窝里打起了小呼噜,而阿捷还在开着本周的电话会。情况不容乐观,不仅中国这三个组,美国那边的开发情况也不乐观,项目延误已经成为板上钉钉的事情了。版本经理甚至建议将开发计划延迟到2008年的5月份。在一阵悲观情绪之中,阿捷结束了这周的电话会。突然间,MSN弹出一个让阿捷怦然心动的窗口,“Hi,阿捷,请加我。”这个人的签名居然是“敏捷圣贤”!

阿捷一阵激动,赶紧通过“敏捷圣贤”的请求!那边已经发过来了信息!

敏捷圣贤:你好,阿捷?

阿捷:圣贤你好!我是阿捷。

敏捷圣贤:你是怎么知道我的?

阿捷:嗯,是猴子告诉我的,我们上学的时候住一个宿舍!

敏捷圣贤:哪个猴子?抱歉,我已经没印象了。我知道你说的那个中文的敏捷论坛网站,不过我已经很久没有登录去看了,那里真正有价值的东西太少。阿捷大致把现在他的项目背景、开发方式、项目管理的方法和工具,以及目前遇到的问题等一股脑讲给敏捷圣贤。他本以为敏捷圣贤会很惊讶于Agile公司系统的庞大和繁杂,却没想到敏捷圣贤对他说:“你之前所说的问题,其实是当前大型软件公司的通病,我一点也不惊讶。既然你想用敏捷开发来改变现状,那么我想知道,关于敏捷软件开发,你又了解多少呢?”

阿捷:嗯,我知道TDD,FDD,结对编程……

阿捷把这些天学来的敏捷开发词汇全都敲了出来。

敏捷圣贤:嗯!这都是一些具体的开发模式,对于提高你们的编程效率是有帮助的。但对于项目的整体改善,效果不大,你需要改善项目整体管理方式才行!

阿捷:奥!是什么样的管理方式?

敏捷圣贤:如果你想使用一个轻量级、能很快取得成效且流程简单,容易使用的东西,那就是Scrum!

阿捷:Scrum?这是什么的缩写?

敏捷圣贤:Scrum不是什么缩写,就是一个单词!你看过橄榄球吧?

阿捷:在电视里看过!橄榄球分为英式和美式,英式不穿防护服,不戴头盔;美式都要带,而且比较野蛮。其实橄榄球起源就在英国,美式橄榄球是后来由移民带到美洲后演变发展而来的。我觉得,共同点是将球送到对方的大门,本质区别是英式靠球技,美式靠团队。但橄榄球跟软件开发有什么关系?

喜欢体育的阿捷有机会都会在家里看美国超级碗的转播。

敏捷圣贤:有关系!你看电视比赛时,当比赛出现小的犯规或因为队员受伤等原因中断的时候,怎么处理的?

阿捷:争球!双方队员相互搂抱,半蹲着顶在一起。由裁判投球后,双方队员互相顶推,中间的队员抢球。抢到球的一方开始进攻,比赛继续进行。

敏捷圣贤:嗯!差不多!你知道在橄榄球中这个术语叫什么吗?

阿捷:国内都叫司克兰。

敏捷圣贤:嗯,英文就是Scrum!意思是密集争球!实际上,我想说的Scrum这个敏捷项目管理方式,寓意就来自于“密集争球”(Scrum),意指整个团队攒足力量,为了一个共同的目标,一起向前快速推进!

阿捷没想到这软件开发还跟橄榄球扯上了,马上输入:这个比喻很贴切。

敏捷圣贤:根据我的实践,Scrum是目前最符合敏捷开发模式的敏捷项目管理方式,能带来很多好处。

阿捷马上问道:最初是谁提出的这个思想?都有哪些公司在用?

敏捷圣贤:Scrum是90年代初由施瓦伯和苏瑟兰(Ken Schwaber和Jeff Sutherland博士)共同提出的,现在此方式已被众多大中小型企业使用,其中包括Yahoo!(雅虎),Microsoft(微软),Google(谷歌),Lockheed Martin(洛克希德·马丁),Motorola(摩托罗拉),SAP(思爱普),Cisco(思科),GE Medical(通用医疗)和CapitalOne(第一资本)。许多使用Scrum的团队都取得了重大的突破,其中更有个别在生产效率和团队职业素养方面得到了彻底的改善。

阿捷:这么多大公司都在用,看来不错。我们该怎么使用它?到底如何做才算是Scrum?

敏捷圣贤:Scrum其实仅仅定义了一个框架(Framework),具体的编程实践,完全取决于每个团队,并且是完全基于经验进行管理的。首先,我们来看看Scrum是如何符合我们所熟知的敏捷开发原则的。

阿捷没有马上回答,等着敏捷圣贤把剩下的话说完。

敏捷圣贤:Scrum遵循的敏捷开发原则有以下几点。

1.保持简单:Scrum本身就是简单轻量级的流程,一页纸就能说清楚,与传统模式相比,它能极大简化我们现有的开发流程。

2.接受变化:Scrum鼓励将工作细分成小块。它关注的是一小段一小段时间,只有在这些时间段的中间,我们才可以重新调整工作的优先级。

3.不断迭代:Scrum需要在小于30天的一次次迭代中构建应用程序。不断的反馈和改善 - 在每一次迭代的末尾,Scrum流程要求我们回顾以前是怎么做的,并且思考我们下次可以做哪些事情来改善流程。

4.协作:Scrum鼓励团队成员的协作和沟通。如果没有这些,Scrum就一点用都没有。

5.减少浪费:Scrum帮助我们识别做那些只对客户或者团队有价值的事情。

阿捷:嗯,这些原则真的很实用,的确跟《敏捷宣言》里面讲的一致。那具体的Scrum的流程又是什么样的呢?

敏捷圣贤:在讲流程之前,我先给你讲几个关键的定义。

1.“产品需求列表”(Product Backlog):这是构建一个产品需要做的所有事情的一个高层次的列表,并按优先级排列,这样可以保证你总是工作在最重要的任务上。比如对于整个Agile OSS 5.0产品套件,你的TD-SCDMA就是其中的一个Product Backlog,而且是比较重要的Backlog,要是我,绝不会让这个Backlog整整两个月没有进展。

2.“冲刺”(Sprint):一个Sprint就是一次为完成特定目标的迭代,一般是1~3周。之所以叫冲刺Sprint,而不是叫迭代,就是希望大家能够保持一种紧迫感,努力快速完成任务。

3.“冲刺需求列表”(Sprint Backlog):这是Sprint的工作任务列表。一个“冲刺”需求列表包含产品需求列表上最高优先级的一些需求,以及产生的附加任务,每一个任务都应该有一个明确的“完成”(Done)的定义。对于你的TD项目组,就是对每一个开发的功能及对应的任务拆解后,定好验收标准。

4.“产品负责人”(Product Owner):这个人负责维护产品需求列表内容和优先级,还有产品发布计划以及最终的验收。对了,他还要对ROI(投资回报)负责。

5.“Scrum Master”:这个人负责执行这个框架流程,帮助大家消除工作障碍,保护团队不受外界打扰,这就像‘牧羊犬’保护羊群一样;同时领导团队不断改进工作流程,这一点上,他应该是一个‘变革发起者’的角色。

6.“开发团队”(Team):这些就是真正完成具体开发工作的人,一般5~9人规模。对于一次冲刺Sprint中的任务做出承诺,尽最大努力完成。

阿捷:这些新名词还真的需要时间慢慢习惯才行。那流程到底是怎样的呢?

敏捷圣贤:作为一个轻量级的流程,简单讲是先建立一个产品“需求列表”,做一个短期“冲刺”计划,并执行这个计划,每天开会讨论计划中的问题和进展,冲刺完成后演示工作成果,再对该阶段的工作做回顾、反思,接着不断重复以上流程。

阿捷:就这样简单吗?有点太粗略了,你能不能讲得更细一些?

敏捷圣贤:我可以给你一些细的指导,可是时间不允许!我现在正在旧金山的机场,等着转机去东京呢!马上要登机了。你在北京?北京好像现在已经很晚了吧?

阿捷:啊?我这里凌晨3点了,别管我时间了。赶紧教教我在这个流程中的每一步都该做哪些事情好吗?

敏捷圣贤:嗯,那我简短些!

敏捷圣贤:当你构建产品需求列表时,要创建一个按优先级排列的所有功能的列表,把最重要的功能放在列表的最前面。

阿捷有点犯傻,心想:如果把所有的事情都放进去,不就和敏捷的简单原则相悖吗?

敏捷圣贤:最初的计划是非常高层次的,仅仅是我们对客户开始想要的那些功能的粗略认识。一旦认识发生变化,就要及时调整。所以我们不会把里面的东西全部细化,只对最高优先级的部分细化。下一步做Sprint计划。你要从产品需求列表中选出一些优先级最高的,制订一个1~3周的计划,决定如何完成这些任务。然后执行这个计划。

阿捷有点明白了问道:“好的。那其他的呢?”

敏捷圣贤补充说道:每天开一次短会,检查Sprint中每个任务的进展状况,对未完成的任务,要求任务所有人给出新的剩余工作量的估算。

阿捷:啊?每天都开一次碰头会,那得浪费多少时间啊!

敏捷圣贤:所以你作为Scrum Master要让会议开得很短,对于你现在的TD项目组来说,5个人,我觉得只要花10分钟就够了。在Sprint完成时,大家聚在一起,展示一下工作成果,这时候一定要让产品负责人知道已经完成了哪些工作,并让他验收。

阿捷:好的,然后再开一次回顾会议?我们以前项目做完后,都会搞一次的。

敏捷圣贤:对,一个Sprint结束后,做一次反省。从团队的角度来审视哪里做得好,并继续保持,找出不好的地方,寻求改善方法。

阿捷:这个流程真的很简单。不错。

敏捷圣贤:还有,在一个Sprint做完之后,你们要重新调整一次产品需求列表,尤其是需求的优先级,然后再做计划,开始下一个Sprint。

阿捷:好的。听起来Scrum还不错。我想下周一就开始,我的项目团队做一个两周的Sprint,看看效果如何。你觉得可以吗?

敏捷圣贤:呵呵,不会吧,阿捷,这么着急?你是我遇到的第一个刚听了Scrum,马上就要实施的人!可是你真的准备好了吗?

阿捷很有信心:差不多吧!Scrum听你讲起来挺简单的!我在网上再找点资料。

敏捷圣贤:这么有信心!祝你成功!我得走了,已经开始通知旅客登机了!

阿捷:哈哈,好的。谢谢你!祝你旅途愉快!再见!

敏捷圣贤:再见!

阿捷突然又想到一件事情,赶紧和敏捷圣贤说:“等一下,还有一个问题。我们原来实行的是CMMI(Capability Maturity Model Integration,软件能力成熟度集成模型),后来又是六西格玛,现在是ISO 9000,每周的开发都要和美国那边做汇报,现在大家都还在采用传统的瀑布开发模式,要是就我一个组采用Scrum,能跟其他组融合吗?

会不会相互冲突?如果冲突怎么办?而我又该如何向我的Manager(经理)解释这些呢?”

当阿捷敲完这长长的一串文字时,敏捷圣贤的头像已经变成灰色,下线了。阿捷有点发呆地看着电脑屏幕,看来这些问题只能依靠自己解决了。

一切来得是这么突然,去得又是这么快,仿佛像梦境一般。阿捷闭上眼睛,仔细地回顾着与敏捷圣贤的这段对话!敏捷圣贤的话像是在阿捷的心头点燃了一把火,阿捷感到整个身心都暖暖的。

本章知识要点

1. 相对于传统的开发模式来讲,敏捷是软件开发中用于应对快速变化的市场和需求,并作出快速反应的一种方式。

2. Scrum坚持如下的敏捷开发原则:保持简单、接受变化、不断迭代、不断地反馈和改善、协作和减少浪费。

3. Scrum是一种灵活的软件管理过程,它可以帮助你驾驭迭代、递增的软件开发过程。

4. Scrum提供了一种经验方法,它使得团队成员能够独立、集中地在创造性的环境下工作。它发现了软件工程的社会意义。Scrum一词来源于橄榄球运动,指“在橄榄球比赛中,双方队员站在一起,当球在他们之间投掷时奋力争球。”

5. Scrum这一过程是迅速、有适应性、自组织的,它代表了从顺序开发过程以来的重大变化。

6. Scrum的迭代过程称为Sprint(冲刺),时间为1~3周。

7. Scrum团队一般由5~9人组成,Scrum团队不仅仅是一个程序员队伍,它还应该包括其他一些角色,如设计人员、测试人员和运维人员等,是一个跨职能、无角色的特性团队。

8. Scrum包含三类角色:Scrum Master,Product Owner,Dev Team。

9. Scrum是一个非常轻量级的流程。简单讲是先建立一个产品Backlog(需求列表),做一个短期Sprint(冲刺)计划,执行这个计划,每天开会讨论计划中的问题和进展,冲刺完成后演示工作成果,再对该阶段的工作做回顾、反思。然后继续重复以上流程。

冬哥有话说

敏捷开发的方法有很多,Scrum只是其中一种;不同方法的形式不尽相同,但背后的原则是相对不变的,即敏捷宣言的12条原则。

Scrum、Kanban,SAFe、LeSS等敏捷框架以及DevOps,仔细探究,其原则都有相近之处,所以学习方法与实践,不要只得其形,不得其神;原则就是方法与实践的神,是根本;而具体的方法和实践,要在不同的场景下面适度调整,并非一成不变;背后相对稳定的,是它们所遵循的原则。

Scrum遵循的敏捷开发原则,最重要的是“减少浪费”,来源于精益思想。在唐·雷勒特森(Don Reinertsen)的《产品开发流》(Product Development Flow)中,称之为经济视角。

采用经济视角来看待敏捷开发中的实践,我们会发现许多实践之间是相通的。例如“保持简单”,是因为变化是永恒的,要“拥抱变化”,在变化面前,过度的设计往往会变成了浪费;再比如阿捷提到的TDD测试驱动开发,就是先编写满足需求的测试用例,再编写能够通过测试的代码,“保持简单”的设计,同时可以持续“不断的获得反馈”。

关于一个Sprint的长度,从早先建议的2~4周,已经变成了1~3周,并且倾向于越短的迭代,目的是快速获取用户/客户反馈,借以调整产品需求列表(Product Backlog)的内容以及相关优先级。产品开发中最大的浪费,就是开发出用户不需要的功能。这也是“减少浪费”原则的一种体现。

很多人对敏捷开发有误解,认为短周期的交付,不经过传统瀑布模式中各类严格的评审阶段,交付出的产品质量会大打折扣。事实上并非如此。敏捷开发强调“内建质量”(Build Quality In),质量活动贯穿在敏捷的每一个过程中,并且通过例如持续集成、自动化测试、持续交付等活动,形成快速反馈闭环。此外,文中提到完成的定义DoD(Definition Of Done,完成定义),也是内建质量的一种体现,与DoD相对应的,还有DoR(Definition Of Ready,就绪定义)。

精华语录

________________________

________________________

________________________