《敏捷无敌》

下载本书

添加书签

敏捷无敌- 第9部分


按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 Enter 键可回到本书目录页,按键盘上方向键 ↑ 可回到本页顶部!
  敏捷圣贤:哪个猴子?Sorry,我已经没印象了。我知道你说的那个中文的敏捷论坛网站,不过我已经很久没有登录去看了,那里真正有价值的东西太少。
  阿捷大致把现在他的项目背景、开发方式、项目管理的方法和工具,以及目前遇到的问题等一股脑讲给敏捷圣贤。他本以为敏捷圣贤会很惊讶于Agile公司系统的庞大和繁杂,却没想到敏捷圣贤对他说:“你之前所说的问题,其实是当前大型软件公司开发的通病,我一点也不惊讶。既然你想用敏捷开发来改变现状,那么我想知道,关于敏捷软件开发,你又了解多少呢?”
  阿捷:嗯,我知道TDD,FDD,结对编程……
  阿捷把这些天学来的敏捷开发词汇全都敲了出来。
  敏捷圣贤:嗯!这都是一些具体的开发模式,对于提高你们的编程效率是有帮助的。但对于项目的整体改善,效果不大,你需要改善项目整体管理方式才行!
  阿捷:奥!是什么样的管理方式?
  敏捷圣贤:如果你想使用一个轻量级、能很快取得巨大成效且流程简单容易使用的东西,那就是Scrum!
  阿捷:Scrum?这是什么的缩写?
  敏捷圣贤:Scrum不是什么缩写,就是一个单词!你看过橄榄球吧?
  阿捷:在电视里看过!橄榄球分为英式和美式,英式不穿防护服和不戴头盔;美式都要带,而且比较野蛮。其实橄榄球起源就在英国,美式橄榄球是后来由移民带到美洲后演变发展而来的。我觉得,共同点是将球送到对方的阵区内,本质区别是英式玩球,美式玩人。但橄榄球跟软件开发有什么关系?
  喜欢体育的阿捷从前寒假的时候都会在家里看美国超级碗的转播。
  敏捷圣贤:有关系!你看电视比赛时,当比赛出现小的犯规或因为队员受伤等原因中断的时候,怎么处理的?
  阿捷:争球!双方各三名前锋队员相互搂抱,半蹲顶架在一起。由有球权的队投球。投球队员投球后,双方队员互相顶推,中间的队员抢球。投球队员绕到球队的后面将球捡起,可以传球或带球跑,比赛继续进行。
  敏捷圣贤:嗯!差不多!你知道在橄榄球中这个术语叫什么吗?
  阿捷:国内都叫司克兰。
  敏捷圣贤:嗯,英文就是Scrum!意思是密集争球!实际上,我想说的Scrum这个敏捷项目管理方式,寓意就来自于“密集争球(scrum)”,寓指整个团队攒足力量,为了一个共同的目标,一起向前快跑!
  阿捷没想到这软件开发还跟橄榄球扯上了,马上输入:呵呵,这个比喻很贴切。

第3章 橄榄球与软件开发(5)
敏捷圣贤:根据我的实践,Scrum是目前最符合敏捷开发模式的敏捷项目管理方式,能带来很多好处。
  阿捷马上问道:最初是谁提出的这个思想?都有哪些公司在用?
  敏捷圣贤:Scrum是在十多年前由Ken Schwaber和Jeff Sutherland博士共同提出的,现在此方式已被众多大、中、小型企业使用,其中包括Yahoo!,Microsoft,Google,Lockheed Martin,Motorola,SAP,Cisco,GE Medical,CapitalOne和US Federal Reserve。许多使用Scrum的团队都取得了重大的改进,其中更有个别在生产效率和职业道德方面得到了彻底的改革。
  阿捷:这么多大公司都在用,看来不错。我们该怎么使用它?到底如何做才算是“Scrum”?
  敏捷圣贤:Scrum其实仅仅定义了一个开发框架(Framework),具体的编程实践,完全取决于每个团队,并且是完全基于常识进行管理的。首先,我们来看看Scrum是如何符合我们所熟知的敏捷开发原则的。
  阿捷没有马上回答,等着敏捷圣贤把剩下的话说完。
  敏捷圣贤:保持简单:Scrum本身就是很简单轻量级的流程,它能简化我们的开发流程。
  接受变化:Scrum鼓励将工作细分成小块。它关注的是一小段一小段时间,但是只有在这些时间段的中间,我们才可以重新调整工作的优先级。
  不断迭代:Scrum需要在小于30天的一次次迭代中构建应用程序。
  不断的反馈和改善:在每一次迭代的末尾,Scrum流程要求我们回顾以前是怎么做的,并且思考我们下次可以做哪些不同的事来改善流程。
  协作:Scrum强烈鼓励团队成员的协作和沟通。如果没有这些,Scrum就一点用都没有。
  减少浪费:Scrum帮助我们识别做那些只对客户或者团队有价值的事情。
  阿捷:嗯,这些原则真的很实用。那具体的Scrum的流程又是什么样的呢?
  敏捷圣贤:在讲流程之前,我先给你讲几个关键的定义。
  “产品订单”(Product Backlog):这是你构建一个产品所需做的所有事情的一个高层次的列表,并按优先级排列,这样可以保证你总是工作在最重要的任务上。比如对于整个Agile OSS 产品套件,你的TD-SCDMA就是其中的一个Product Backlog,而且是比较重要的Backlog,要是我,就绝不会让这个Backlog Block整整两个月没有进展。
  “冲刺”(Sprint):一个Sprint就是一次为完成特定目标的迭代,一般是2~4周。
  “冲刺订单”(Sprint Backlog):是Sprint的工作任务列表。一个“冲刺”订单来自于产品订单上最高优先级的一些任务,以及产生的附加任务,每一个任务都应该有一个明确的“完成(Done)”的定义。比如对于你的TD项目组,在每一个开发的版本上都要列出优先的开发任务。
  “产品负责人”(Product Owner):这个人负责维护产品订单内容和优先级。
  阿捷:这些新名词还真的需要时间慢慢习惯才行。那流程到底是怎样的呢?
  敏捷圣贤:它是一个非常轻量级的流程。简单讲是先建立一个产品“订单”(Backlog),做一个短期“冲刺”(Sprint)计划,执行这个计划,每天开会讨论计划中的问题和进展,计划完成后演示工作成果,再对该阶段的工作做回顾、反思,接着不断重复以上流程。
  阿捷:就这样简单吗?有点太粗略了,你能不能讲得更细一些?

第3章 橄榄球与软件开发(6)
敏捷圣贤:我可以给你一些细的指导,可是时间不允许!我现在正在San Francisco的机场,等着转机去东京呢!马上要登机了。你在北京?北京好像现在已经很晚了吧?
  阿捷:啊?我这里快凌晨3点了,别管我时间了。赶紧教教我在这个流程中的每一步都该做哪些事情好吗?
  敏捷圣贤:嗯,那我得简短些!
  敏捷圣贤:当你构建产品订单时,要创建一个按优先级排列的所有功能的列表,把最重要的功能放在列表的最前面。
  阿捷有点发傻:如果需要把所有的事情都放进去,不就和敏捷的简单原则相悖吗?
  敏捷圣贤:最初的计划是非常非常高层次的,仅仅是我们对客户从今天开始想要的那些功能的粗略的认识。一旦认识发生变化,就要及时调整。下一步做Sprint“冲刺”计划。你要从产品订单拿出一些优先级最高的任务,制订一个2~4周的计划,决定如何完成这些任务。然后开始执行这个计划。
  阿捷有点明白了:好的。那其他的呢?
  敏捷圣贤补充着:每天开一次短会,检查Sprint中每个任务的进展状况,对未完成的任务,要求任务所有人给出新的剩余工作量的估算。
  阿捷:啊?每天都开一次碰头会,那得浪费多少时间啊!
  敏捷圣贤:所以你作为Scrum Master要让会议开得很短,对于你现在的TD项目组来说,5个人,我觉得只要花10分钟就够了。在Sprint完成之后,大家聚在一起,展示一下工作成果,这时候一定要让产品负责人知道已经完成了哪些工作。
  阿捷:好的,然后再开一次回顾会议?我们以前项目做完后,都会搞一次的。
  敏捷圣贤:对,一个Sprint结束后,做一次反省。从团队的角度来审视哪里做得好,并继续保持,找出不好的地方,并寻求改善方法。
  阿捷:这个流程真的很简单。不错。
  敏捷圣贤:还有,在一个Sprint做完之后,你要重新调整一次产品订单,然后再做计划,开始下一个Sprint。
  阿捷:好的。呵呵,听起来Scrum还不错。我想下周一就开始,我的项目团队做一个两周的Sprint,看看效果如何。你觉得好吗?
  敏捷圣贤:呵呵,不会吧,阿捷,这么着急?你是我遇到的第一个刚听了Scrum,马上就要实施的人!可是你真的准备好了吗?
  阿捷很有信心:差不多吧!Scrum这玩艺儿听你讲起来挺简单的!我在网上再找点资料。
  敏捷圣贤:这么有信心!祝你成功!我得走了,已经开始通知旅客登机了!
  阿捷:哈哈,好的。谢谢你!祝你旅途愉快!再见!
  敏捷圣贤:再见!
  阿捷突然又想到一件事情,赶紧和敏捷圣贤说:等一下,还有一个问题。我们原来实行的是CMM/CMMI那套,后来又是六西格玛,现在是ISO 9000,每周的开发都要和美国那边做汇报,现在大家都还在采用传统的瀑布开发模式,要是就我一个组采用Scrum,能跟其他组融合吗?会不会相互冲突?如果冲突怎么办?而我又该如何向我的Manager解释这些呢?
  当阿捷敲完这长长的一串时,敏捷圣贤的头像已经变成灰色,他已经下线了。阿捷有点发呆地看着电脑屏幕,看来这些问题只能依靠自己解决了。
  一切来得都是这么突然,去得又是这么快,仿佛像梦境一般。阿捷闭上眼睛,仔细地回顾着跟敏捷圣贤的这段对话!敏捷圣贤的话像是在阿捷的心头点燃了一把火,烧暖了阿捷的身体。
  为了更好地总结自己的学习与实践心得,阿捷决定在BlogSpot上建一个Blog,记录下自己在敏捷路上的点点滴滴。
  
小提示:按 回车 [Enter] 键 返回书目,按 ← 键 返回上一页, 按 → 键 进入下一页。 赞一下 添加书签加入书架