过程改进日记之学习Scrum2010-9-9：外部培训笔记

今天下午有个咨询公司给在我们公司范围做了个Scrum的培训试讲，我把主要的问题和解答记录下。（唉，都是我在问，兄弟部门的弟兄们仅问了一个还算有价值的问题。）

针对我们目前遇到的一些情况，在老师最后Q&A环节集中问了下，老师的一部分重要观点不是在回答我提问的时候说的，为了阐述方便，我也一并整合到问题的答案中，所以，老师的答案中也有我自己加进去的内容。大部分是老师原话我改得更顺畅些，极少一部分是根据老师零碎的提示改编，题目我自己取的。

㈠、过度承诺和分工模式
我：“我们尝试Scrum的方法有几周时间了，但每次燃尽图看起来都有大量任务没有完成，这方面应该是过度承诺的结果，请问如何避免过度承诺？”
老师：
首先，这是一种逐渐的学习过程，你们使用Scrum的时间还不长，缺乏足够的计划能力，或者说计划总是乐观，这些是好事，说明利用这个方法能够帮助你们更快的发现问题。
其次，燃尽图用来观察任务的趋势，但也不要太在意燃尽图的样子，最重要的是即使完不成Sprint目标，但你们至少可以也可以拿出一个可交付的工作成果。
我汗颜

：“但我们在Sprint中一个Backlog都没有完成？，我们所有的Backlog都分解了任务，但每个Backlog名下的任务都没有完成。一部分是因为新员工对开发环境等不熟悉，任务的估算没有依据，另外一部分是有外部依赖的需求，各种原因使得每一个需求都不能完成”
老师：
“那归根结底是乐观的表现，如果这样的话，你们已经发现了关键的原因，你们在后面的Sprint中自然会考虑到这些风险，就会减少过度承诺，Scrum不是灵丹妙药，一下子就解决问题了，还是要慢慢的改进。你们需要努力来达到每一个Sprint可以交付，哪怕很少的一部分。”
我：“我们现在的分工基本还是按照模块来分，除个别模块外，每个模块都有一个具体的工程师负责，工程师只是在各自模块中选择优先的任务，这样就可能导致所有的需求都没有100%完成”
老师：
“你们这种情况就是强分工的Team组成形式，每个人都只能解决唯一的一部分工作，这样的分工不能很好的体现Scrum的方法，就好比橄榄球运动，运动员之间并没有严格的分界线，而事实上，所有团队球类项目，队员之间的分工也越来越不明显，都是呈现弱分工趋势，随时都可以争球，随时可以发起攻击，才有更多胜率。”
“实在做不到弱分工，至少也应该使得工程师具备T模型的技能，所谓T模型，就象字形，具备几个方向的能力。即使不是精通，但至少要能参与，并慢慢熟悉，达到部分可以接替的目标。”
㈡、关于新人的情况
我：“新员工或实习生的比例较高的项目，Scrum是否合适？或者还是计划驱动的更好？”（这个问题我其实有答案，在《平衡敏捷和规范》一书中说新人更适合计划驱动的，但我想找到旁证）
老师：“Scrum是个框架，不排斥具体的工程实践方法，传统模式下新员工的传帮带方法都可以采用，比如codereview、结对编程等。”
我：“但是这会影响我们Sprint目标的实现”
老师：“新人的确会有影响，否则就不能称其为新人了，如果你们有条件，我倒是建议你们采用一些其它的方法，比如在他们被分配到各项目组前从公司层面采取类似‘新兵营’的项目，给一些时间不是那么紧的，技术难度不高、或者其它虚拟项目为他们训练基础能力，以确保到项目组内是个可用的资源。”

㈢、关于用户故事和架构
我：“有些事情比如发现架构有问题，需要重新架构，一般可以做为Backlog吗？”
老师：“Scrum是个比较轻量级的框架，他通过几个要素来驱动项目在最小的时间周期－24小时－做一次戴明环。以确保更快的发现和改进，因此，架构活动是否设为Backlog并没有明确的可以或不可以，不过我觉得还是不要这样做比较好，因为每一个Backlog尽可能要是一个可以交付的成果，架构无法单独来交付。
“一方面，架构能力提升需要更多时间，极端的敏捷号称架构也是可以随时变更的，但我对这个持保留意见，如果某人要植树，当然可以从把种子埋入土里开始，但这就对植树的人的能力要求非常高，更保险的做法是把健康的小树苗植入土里，同样，我们应该尽可能把最核心的框架在前面做好。这是比较易于普及和推广的做法。”
“另外一方面，如果真的项目组的实力，或者产品需求不稳定，确实需要改变架构，我建议把架构调整做为某一个Backlog的任务来安排。为什么要改架构，无外乎有一个现有架构不能实现的功能/性能，那我们就把架构任务分解到这个backlog下。”

㈣、关于代码重构
我：“代码重构经常发生，这类任务经常有，怎么管理”
老师：“代码重构应该成为一个惯例，这样确保代码的可读性或者提高软件效率，我建议不要做为任务。因为代码重构是每个任务的一部分，既然有编码，就有代码重构。”

㈤、任务的验证
这个问题我没问，原来是考虑我们现在每天看一下程序的方法对不对，以及有些问题不能验证，很是困惑，但是老师在培训的时候说了以下的话，我认为已经可以做为答案了
老师：“Scrum是一个轻量级的框架，他不排斥任何技术方法。Codereview、极限编程、集成构建、测试驱动、等等工程实践，他都可以包容到这个框中，任何你们认为有效的测试、验证方法都是可以的。”

㈥、关于Scrum Master
不是我：“刚才听你说Scrum Master这个角色，是不是这个人技术要很牛，不然没法指导别人用什么方法”
老师：“当然，Scrum Master有很强技术能力的话，他可以更好的寻找更多的方法，也更容易了解项目组实践某方法是否真的有好处，但这个是Scrum之外的贡献，反之，某个技术很牛的人同时也对Scrum很有兴趣，那当然欢迎”
“但实际上，Scrum Master的定义是指导Team有效地按照Scrum框架来展开研发活动，是一个服务者，与其说他是一个技术牛人，不如说他是一个很好的沟通者、协调者、他更需要具有良好的人脉，而不是职务权威，这些技能是软性的。”
“一般情况下，假设你们有个技术牛人在做Scrum Master，我觉得反而是让他做Team核心开发人员更有价值。”
不是我：“我们再考虑要不要让Scrum Master拥有一部分Team成员奖金分配权，这样能够让他更好的展开工作”
老师：“这不需要，Scrum Master最好不要拥有这样的权利，否则事实上会形成Scrum Master和Project Owner边界模糊的情况，Team的工作应该仅仅向Project Owner负责，Scrum Master也尽量要使用软能力来服务Team，帮Team阻挡不利于Scrum的因素，增加这样的考核会破坏工程师自我管理的目标。”