scrum案例

scrum 案例一: Spotify影片翻译中文字幕

Spotify公司是类似KKBOX的音乐平台,是全世界最有竞争力的公司之一。它将其敏捷作法做成动画影片,这影片是全球知名的敏捷案例,发布在各大敏捷社群,对学习者是很好的学习案例,其点阅率Part-1为9万; Part-2为4万6。

视频地址:

Part-1:https://youtu.be/Mpsn3WaI_4k
Part-2:https://youtu.be/X3rGdmoTjDc

第一次看到这影片时,觉得内容真的很棒!但是因为没有中文字幕,所以就算反覆看了很多遍,吸收率大概也只有50%。也因为旁白者的说话速度非常地快,所以当时我就有了一个想法:“如果能把它中文化,一定会有更多敏捷中文学习者受益。”,于是在2015年8月17日,我写了一封信给原上传作者,询问他是否需要将此影片翻译成中文字幕,以受益更多中文学习者,没想到他居然一口答应!

在取得原作者同意后,我开始召唤志工,原本预计召唤30位PMI-ACP,但是召开开始后并不是那么地顺利,因为这个项目议题不是很强势,大家可能会认为这只是翻译中文字幕而已,没有什么难度;不像当初我召集国家标准CNS的志工,一下子就有50几位志工自愿加入帮忙因为这个原因,后来实际只召唤到16位志工,其中仅7人为PMI-ACP,1人为CSM,也因为PMI-ACP人数不足,而让非PMI-ACP的志工加入此项目。

在此项目中,我带领大家实际用Scrum手法来执行。因为志工的人数不多,于是我分成两个Scrum团队,一组各有8位成员,再从各组挑出一位PMI-ACP来担任ScrumMaster,我在这项目里的角色是PO(产品负责人;产品负责人),尽量不要干扰成员及指引该如运行其项目。

在我们的团队里,没有人是专家,没有人会上字幕,大家都只是热心的志工,甚至对于英文也都仅是略懂而已,但是没关系,我们从头开始学习。

首先,我先用自动听打软件Dragon Speech产出正确率约80%的中文内容,如下Spotify翻译工作文档:https://goo.gl/itx6qE

接下来,我再请其中一位志工的先生(英国人)帮忙一一打打及顺稿,虽然只有两支13分钟的影片,但也是花了两个礼拜才完成,这些前置动作做完之后,才能开始中文翻译及上字幕的动作。

在进行第二支影片的听力打开动作时,我们就正式开始Scrum虚拟团队的运作,我开了三个线群组,将各组员分到自己的组别,再教导他们如何运作Scrum的项目。

我在项目期间,就是不断地教导两位ScrumMaster如何正确地运作Scrum项目及解决他们在实务上所碰到的困难。

在这项目最神奇的,就是所谓的团队「自我组织」,成员对于要做什么,是完全没有人在指挥的,对于该如何做?也是由成员自主决定的。一开始,成员感到非常地不习惯。

在项目的第一个Sprint,是属于团队组建的风暴期。我知道会有风暴阶段,所以将Sprint目标设计地非常小。就是:请请演示前5分钟上好中文字幕的Spotify Part-1影片,已经完成上传在Youtube上,而且用的是其中文字幕功能。这个目标不到一周就达成了,成员面临了是否要进度超前来完成工作意见分歧,有成员因线群组上的言语摩擦而退出,或者因家庭羁绊不能参加每天晚上的每日Scrum会议而更换ScrumMaster …等问题。

但是,很不可思议的,第一个Sprint,我们就已产出第一集前5分钟的Demo影片,并透过原上传作者Matt的验收和确认;第二个Sprint则已经把全部影片(含Part- 1和Part-2)翻译好并已上完中文字幕。在项目团队“自我组织”的运作下,短短2周就已经完成了这个敏捷项目,不仅创造了最高的翻译品质,也完成了这一次的Scrum项目。

这次的项目真是不可思议的奇迹,因为我们团队之间没有人有上过中文字幕的经验,不是每个人都是中文专家,过程中也遇到了不少障碍,甚至如何把字幕上Youtube都要重新学习,但是我们却翻译了极高品质的敏捷中文字幕,如此翻译水准,是一般的翻译社不论经过多少时间都无法达到的。最难得的是,所有志工都是无偿没有报酬的,却愿意牺牲个人休息,假日时间,甚至熬夜,来共同完成这个目标,真的很感谢所有志工们的帮忙,也期望这两支影片的完成,可以让更多敏捷中文学习者受惠,加速对敏捷项目实际运作的了解。

scrum 案例二: 荷兰铁路

Scrum为项目执行提供了可靠的、已被证实的基础。但是,在每个项目中,Scrum都必须根据具体需求和环境进行调整,这是项目成败的决定性因素。在这篇文章中,我们将会介绍我们如何成功地完成了一个大型的(20人年,超过十万行代码)、分布式(开发人员位于印度和荷兰)Scrum项目,而这个项目曾经在传统开发方式下被废弃过 。为了帮助读者顺利运作大规模项目,在这里我也会历数我们的经验教训,包括:项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。

背景

荷兰铁路可以跻身于世界上使用量最大的铁路系统之列,每天要运送120万乘客。该部门打造了一套全新的信息系统,为乘客提供更准确的列车信息,减少人为干预。作为该系统的一部分,我们做了这个PUB发布系统,对所有车站中的信息显示和音频广播做集中控制。

有人之前试过完成这个PUB系统,但是他们当时用的是传统的瀑布方法。客户把详细的需求文档规范交给了开发商,然后放任自流,等着完整的系统成形交付。三年之后,这个项目被取消掉了,因为开发商没能开发出一个可以工作的系统来。然后客户雇佣了我们公司从头做起,我们引入了敏捷开发方式,用上了Scrum,跟客户紧密协作,开放交流,小步前进。

起步

项目开始的时候,我们在第一个sprint开始前安排了一个启动阶段,耗时三周,准备好了sprint中所需的一切。这个启动阶段由一个项目经理,一个架构师和一个Scrum Master参与完成。

选择产品负责人是个很有难度的事情,我们找不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。我们提名了两个业务分析师来一起承担产品负责人的职责。他们能抽出时间来,而且他们从前也参与过构建PUB的工作,所以业务知识很丰富,足以担当起产品负责人的角色,为多组客户充当优秀的代理。有关优先级的和范围的高级决策,是由客户委任的项目经理负责,但是他时间不够用,对于需求的理解也有所欠缺。一般情况下大家的配合还可以,但偶尔项目经理也会对(他所缺席的)计划会议上制定的优先级进行调整,于是这个会议就得重新来过。在理想状态中,对优先级有最终决策权的人应当每次都参加sprint计划会议。

因为先前有人试着构建过PUB系统,所以有些部分的详细需求文档已经是现成的了。它们遵守了MIL标准,不过其形式不适于敏捷计划和估算[2],因为在敏捷开发中,需求应当被组织成小块的段落,每一块都可以在一个sprint中进行实现、测试和演示,但是现有的文档与此要求不符。产品负责人也没有多少编写用户故事的经验,为了解决这个问题,Scrum Master帮他们弄出了最原始的产品backlog,里面放着一些细粒度的、经过估算的用户故事,供前几个迭代使用。

我们所构建的软件只是某个大型软件系统的一部分,它还包括很多相关的软件系统,那些系统负责显示信息,还要在车站内安装相关显示设备。我们得保证每件事情都可以按时完成,才能把复杂的系统理顺。所以需要有一个整体的计划方案。经历了几次迭代,我们对系统的各个功能都按照自己的最大能力做出估算,这个问题也解决掉了,而且也有了一个比较靠谱的生产率。于是就可以用发布版本燃尽图来记录和沟通进度了。这里我们学到的东西就是,即使是信息量很少的情况下,有估算也比没估算好。

扩展到分布式团队

项目启动以后,一开始只有7个人,两星期一迭代。项目从一开始就计划着要用到印度的一些人力,所以从第一个sprint开始就有两个印度开发人员进入了团队。他们来到客户现场参与开发,用了六周时间熟悉领域知识、用户代表和团队其他成员。

建立团队伊始,就要决定如何协作。我们跟所有团队成员一起——也包括印度同事——组织了一个“规范和章程 [3] ”活动。我们定下来一些实践方式,如怎样做结对、用哪些工具、质量目标、每天的核心工作时间等等。然后在Wiki上记录下来。整个团队有了共识,事情就好办多了。一旦这些共识需要修改,比如在回顾会议上提出改进,这些实践就要在wiki上更新,这样有新人加入的时候,他们看到的总是最新内容。

在前几个迭代里面,团队成功地构建、测试、验证了组成系统核心的用户故事。这让客户很满意,尤其是跟过去相比,我们的进度更快,而且客户对项目的方向也有掌控权。

几个迭代以后,我们就扩展了项目:印度的开发人员返回本国,然后我们在印度和荷兰都增加了资源,这样变成了两个Scrum团队,每个团队5个开发人员,共享同一个测试人员。过后又变成了三个团队,一共三个测试人员。每个团队都既有印度员工,又有荷兰员工。这种方式让项目保持了很高的生产率和工作质量 。

那我们是怎样异地协同工作的呢?首先,我们频繁使用Skype。我们都有网络摄像头、耳机、麦克风,还有个大屏幕。所以我们既能一对一开会,也能全体参会。这些都用的是现成的东西和免费软件。没多花多少钱,只是用UPS保证断电的时候也能继续开Skype会议,这样提高了印度那边的网络联系能力。其次,只有在同一个地方的人才做结对。也就是说印度的人跟印度的人结对,荷兰的人跟荷兰的人结对。经验告诉我们,不管现在有了哪些工具,结对编程所需的交互协作还是需要两个人坐在一起的。

最后,我们用ScrumWorks记录谁在做什么事情,记录Sprint的进度。因为我们是分布式团队,所以这个比白板要好得多。在跟产品负责人讨论产品backlog的时候,ScrumWorks也起了很大作用。

在实施这种分布式模型的时候,我们也战胜了很多困难。例如,产品负责人不习惯说英语。按照Scrum的说法,计划会议分成两部分,在第一部分中,产品负责人给团队讲述用户故事,并且设置优先级。因为这种语言障碍的存在,这一部分的会就只让荷兰团队参加了。第二部分通常是大家讨论具体任务,做估算。这部分是跟印度团队一起用Skype来完成的,说的是英语,产品负责人不参加。我们还多花一些时间来沟通第一部分会议的内容。Sprint演示也只在荷兰进行。完成以后,荷兰团队再写封内部简报,告知印度团队——也包括公司其他人——演示的结果。事实证明,这个内部简报深受欢迎。

拆出一个只关注架构的团队

我们的项目只是整个应用链条中的一部分,必须要跟客户现有的IT基础架构无缝挂接。虽然我们的产品负责人对核心功能需求非常熟悉,但是在安全、日志、可用性、性能等方面就所知甚少了。要从客户的组织中了解这些需求难度很大,因为这得跟不同部门中的许多人沟通讨论。这种调查工作给Scrum的迭代节奏拖了后腿。为了解决这个问题,我们创建了一个独立团队,他们只关注架构方面的内容。他们的工作就是弄清楚非功能性需求,好让我们把它们转换成backlog中的用户故事。我们用“Scrum of Scrum”会议来跟特征团队沟通。我们都喜欢这种方式,因为特征团队可以全速前进。而且有些员工也喜欢在“架构团队”中工作。

文档

客户要求大量的文档,而且还要符合MIL文档规范。还要用荷兰语写。很明显,这项工作只能由荷兰人来干。而且开发跟测试都不熟悉MIL规范,写用户手册这样的文档也不是他们所擅长的。所以我们决定雇一个曾经写过MIL文档的技术文案。开发跟测试可以继续关注于各自职责。这个做法也很成功,不过我们发现这也要求技术文案和其他团队成员之间也要有大量的沟通交流,这是需要引起注意的,因为开发人员只想“做他们该做的事情”。

需求

我们的产品负责人是一些业务分析师,他们习惯于用荷兰语写出大量的需求文档。而在我们的过程中,只要backlog中有用户故事,产品负责人也能在计划会议上做解释,这就足够了。但是客户又要求有很多文档。所以我们打算和产品负责人一起把需求翻译成用户故事。结果就是需求被放在了两个地方:需求文档和 backlog。当需求发生变化的时候就会导致问题。我们做了大量的辅导工作,确保产品负责人不仅仅是关注需求文档,也要负责backlog。

有了一行文字表达的用户故事,再加上产品负责人的解释,我们的Scrum团队就可以构建和测试软件了。不过需求文档对外部的测试团队做测试还是很有价值的,虽然在好些迭代里面,我们很难把实现的用户故事跟需求文档中的某些部分“映射”起来。

回顾从前,我们其实一直都没有一个理想的需求管理过程。我们只是尽了最大努力,来应对这相互冲突的需求:我们需要用户故事,客户需要详细的需求文档。

测试

我们在项目中做了自动化测试,保证在每个Sprint结尾的时候都可以交付经过测试的软件,不带有回归的bug。即使随着系统扩展,我们还是做到了在8人的Scrum团队中只安排一个测试人员,而且保证了高质量:外部测试团队最多也就是能在每千行代码中发现一个缺陷。

我们的自动化测试包括两部分:单元测试和验收测试。在前者中,我们用的是JUnit,用Clover度量测试覆盖率,我们的目标是服务器端代码的测试覆盖率达到80%。验收测试用FitNesse作自动化。每个完成的用户故事,都会在FitNesse上有一套验收测试。有了庞大的测试套件,就能在 Sprint中找到并修复回归的bug。这种做法还有另外一个好处,就是测试人员从一开始就可以积极参与,在用户故事实现之前编写测试用例。

有一个地方让我们苦恼了很久。这个系统有一部分是一个用户界面很复杂的富客户端。对这东西做自动化测试要比对服务端做测试难得多。所以在UI方面的功能我们大部分还是依靠手工操作。随着系统的增长,回顾测试所花的时间就越来越长,更糟的是,外部团队只在这部分系统中会发现回归bug。如果有了自动化测试就能防止这一点。我们由此学到了一点,即便是自动化测试很困难,为它付出些努力,迟早会获得回报,尤其是在项目晚期。

产出成果

客户对我们的工作很满意。说点马后炮的话,跟大多数项目一样,功能、时间、预算都会随着项目进度发生变化,所以“按时按预算”完成只是个很模糊的完成标准而已。更为重要的是,我们在项目进程中常常跟客户讨论怎样把项目做好,他们都很满意。不幸的是,因为其他系统中的问题,产品在全国范围内部署的时候出了麻烦。

客户找了外部的审核公司来审核这个软件。他们的结论是:

  • 系统的可维护性非常好。
  • 源码质量非常高。
  • 在审核公司的报告中,他们说他们从来没有给过一个项目这么多正面评价。
总结

下面是我们从这个项目中学到的最重要的几点:

  • 很难找到一个既有丰富的需求知识、又有权利设置优先级的产品负责人。所以人们往往都要用几个人一起扮演产品负责人的角色,尤其是在大型项目里面。
  • 如果一定要按期完成工作,那就得保证产品backlog的完整,也要做好估算。对需求而言,即便信息量很小,有估算也比没估算的好。把估算跟团队生产率合并以后,发布计划就有了必要的信息。
  • Scrum对多个分布式团队很适用。我们每个Scrum团队都既有荷兰人又有印度人,这很好地发挥了团队精神,让我们注重有效沟通。在沟通中,利用现成的硬件和免费软件能节省成本。
  • 在启动分布式项目的时候,先把大家都聚到同一个地方,让大家对团队实践达成一致,这点效果很好。
  • 对于不适合放到Scrum Sprint中的工作(比如寻找关键人员,跟其他客户部门交流),可以让一个单独的团队去做,这样效率更高。特性团队可以集中精力开发软件。有一个专职的技术文案也很好,即便这会增加沟通成本。
  • 虽然软件开发过程不需要大量的需求文档,但客户可能需要。不过在Scrum项目中,需求文档代替不了用户故事。如果既有需求文档,又有用户故事,那就得在做计划的时候,就要考虑到在两个地方协调需求的额外开销。
  • 在增量式交付软件的过程中,自动化测试发挥着关键性作用,它可以排除回归bug的干扰。在项目结束之前,投资回报会高过成本的。