您的位置:首页 > 其它

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

2010-09-10 19:16 260 查看
今天下午有个咨询公司给在我们公司范围做了个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的因素,增加这样的考核会破坏工程师自我管理的目标。”
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: