准备Scrum之旅 之 沟通当前的项目流程——《轻松Scrum之旅》（21）

 沟通当前的项目流程

 

    两个小时以后，电子商务通的项目经理Greg和测试经理Lisa，还有Peter、关毅，一起聚在了名叫夏威夷的会议室里。
    首先由Peter介绍目前采用的敏捷开发流程。
    Peter说：“在即将到来的3.0的开发中，我们准备采用四个星期的迭代。Sprint Backlog争取能在Sprint开始的前一周制定好。关毅，我们计划设两个Scrum团队，北京和加拿大，这样我们就需要有两个Sprint Backlog，你觉得怎么样？”
    “那很好，毕竟我们离得很远，沟通起来不方便，两个团队好一点。”关毅说。“不过，应该由谁来制定北京的Sprint Backlog呢？”关毅问。
    “由于我们还不了解你们团队的能力，所以一开始由我们来制定，以后可以由你们来决定每个Sprint做多少个任务。”Peter回答。
    “那3.0的产品Backlog我们什么时候能准备好？产品开发计划是怎么样的呢？”关毅接着问。
    “呵呵，3.0的开发计划正在筹备中，我们会在另外一个会议中一起讨论产品Backlog。今天是3月10号，3.0计划在9月30号发布。”Peter回答。
    “关毅，你们和北京电子商务通产品组的测试人员沟通方便吗？”测试经理Lisa问道。
    “很方便，他们部门就在我们楼里，不过之前联系得不多。”关毅回答。
    “太好了，我希望你们能加强沟通。之前北京的测试组和这边的开发团队由于时差和地理位置的缘故，沟通起来很不方便，效率很低，今后我希望北京开发的功能都能由北京的测试团队进行测试。”Lisa说。
    “也许我们应该打破过去将测试和开发分为不同部门的惯例，也许按产品分更合适一些。”Peter说道。
    “Peter，采用敏捷开发是不是意味着你们开发组不用再让我们测试组等得很辛苦了？过去要等好几个月才能拿到可以测试的东西，临发布前由于Bug太多，害得我们也得跟着一块儿加班。”Lisa不满道。
    “呵呵，这是我们的目标。以后你们顶多等一个月就能拿到可以测试的软件。不过不要高兴得太早，我们可不敢保证你们会比以前更轻松。”Peter笑道。
    “我们是不是讨论一下今后如何沟通会更有效？”关毅问道。
    “关毅，你有什么好的建议？我知道E公司北京研发中心和E公司美国总部合作的项目比较多，他们通常都是怎么沟通的？”Peter问道。
    “一般都是每周打一次电话沟通一下状态，仅此而已。不知道我们敏捷了是不是沟通应该更频繁一点？”关毅说。
    “让我想想。你们的早上8点相当于我们的下午5点，不过我们早上9点上班，就相当于你们的半夜了。这样吧，我们每周先开两次会，一次是你和我参加，在周一开，主要沟通一些计划和安排、遇到的技术困难等，另一次是全体成员的大会，在周五开，包括加拿大和北京电子商务通产品组的全体成员，主要是更新状态，你看怎么样？”Peter回答道。
    关毅点了点头：“OK，就这么定了。”

 

 

总结和思考
    在项目的开始制定一个有效的沟通计划至关重要，对于敏捷开发尤其如此。

 

    接下来，Peter又开始介绍敏捷开发具体流程的实施细节：“当拿到Sprint Backlog的时候，我们需要召开Sprint计划会议，把每个Backlog分解成具体的Task，就是早上每日Scrum会议所采用的小卡片。每个Task以小时为计量单位，并安排到人。我们在目前的试用阶段经常是这么分解的，你们可以参考。比如，完成一个用户登录校验功能的Backlog可以分解成调研校验功能所需技术（3小时）、设计校验功能（4小时）、开发校验功能（3小时）、编写校验功能的单元测试用例（3小时）、执行单元测试用例（1小时）、Code Review（1小时）、更新设计文档（2小时）、代码重构（2小时）……”
    两个小时的会议很快就结束了，走出会议室的时候，关毅觉得心里有底多了，剩下的就是要解决在电子商务通3.0版本的开发工作中北京团队具体要做什么的问题了。
    为什么刚才Greg发言很少呢？关毅忍不住问Peter：“Greg具体负责什么工作？”
    Peter说：“他是我们的项目经理。由于我们正在试着采用敏捷开发，Greg提倡团队自我管理，所以你会发现他只在团队需要帮助的时候才会出面。Greg很了不起，他是刚转到我们组的，过去我们的项目经理总是喜欢发号施令，Greg现在还相当于我们Scrum里面的产品负责人。接下来我们讨论产品Backlog的时候，他会带着我们一起来制定。”

 

Scrum博士扫盲
    什么是产品Backlog？什么是Sprint Backlog？
    产品Backlog指根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能，由Product Owner为Product Backlog中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。
    产品Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之制定一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好能保证团队的第一个Sprint有活可干。
    随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也会随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。
    在Sprint计划会议上，产品负责人为产品Backlog中的任务确定优先级，并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint中要完成哪些功能，并把它们挪到Sprint Backlog中去。