在为团队进行过几次Scrum的交流培训后,在PM和团队的大力支持下,团队决定开始在新的release开发中使用Scrum的一些理念和良好做法,我作为Scrum的爱好者,是很高兴的,同时也是不安的,因为自己也只是个Scrum的初学者而已。书到用时方恨少,真正开始实施了Scrum,才发现了很多书本外的问题,需要学习总结解决,因此用BLOG记录一下一些心得和想法,供日后印证。
1.团队的抵触情绪
无论团队对于敏捷也好Scrum也好是多么心向往之,但是抵触情绪仍然是存在的。原因一是由于对既有流程和方法的熟悉,二是对未知事物的恐惧,三是对项目风险的担心。
我个人认为对于此问题的解决方式是:
- 悄悄转型,慢慢转型,不要流于形式上的完全敏捷,在演进中渐进敏捷。Scrum也好敏捷也好,有一个理念就是先做起来再说,然后迭代演进。
- 先引入良好做法,不改变开发流程框架,甚至可以与旧流程同时进行。比如我非常认同团队中的一位Senior Engineer依然编写传统的架构设计文档。
- 一定要选择一个好的试点项目,最好是熟悉的、风险小的项目
2.大家都喜欢 How to Demo
在Sprint会议中,我发现大家一致交口称赞的部分就是商定Howto demo。
在传统开发中,很少这样逆向思维的考虑一个feature如何演示,而更多的是定义一个feature该如何去做,大家一直都是这样做,也没觉得这有何不妥。
没想到一旦使用了How to Demo的方式,大家纷纷表示这方式很好。首先,程序员队伍表示这种方法很好的澄清了需求,有些问题在讨论How To Demo中不知不觉都得到了澄清和解答,有些关键的需求问题也很快都暴露了出来。其次,PM也很开心,因为他更加清楚自己所负责的项目的产品是什么样子了,该如何向老板演示和汇报。最后,PV也很高兴,因为PV发现把How toDemo稍微改动一下就是Test Plan。
所以我觉得对于刚开始使用Scrum的团队,也许How to Demo是一个用于对团队破冰、让团队喜欢上Scrum的Killer Practise 啊呵呵。
3.故事点数和人/天
传统开发模式下程序员们习惯用多少人/天来估算工作量。而Scrum中使用故事点。就我个人体会,这个思想转变是需要一段时间的。那么,在团队最初使用Scrum时,不妨就使用人/天,而不是故事点。
在经历几个sprint之后,自然就可以从历史数据中推算出团队的估算人/天和实际的人/天之间的差异,即团队的生产率。然后将
估算人/天 概念慢慢转换为 理想人/天 概念,再慢慢演进到 故事点 的概念。
甚至在估算中,未必最初就要使用点数卡牌技术,仍然采用传统的由任务owner自己来估算人/天的方式,能够让团队的抵触情绪降低。
4.项目经理的欲壑难填
传统模式下的PM,总是希望在一个Sprint backlog中多放一些任务,哪怕明知道做不完,也愿意多放一些任务进去。简言之,宁可做不完,宁可部分完成,也不能没活干,让兄弟们闲着。
但是这正是传统模式的通病以及Scrum的优点,必须让PM深刻了解放入Sprint backlog的任务必须是理论上可以完成的、可以交付的任务,如果只能完成部分,那么就不要放入这个Sprint中去。
当然你的PM会很不满意,并认为这个规则很没道理,把计划做充分一点又有何不可呢?此时我建议用另外的一些方式说服PM
- 和PM商量是不是有一些任务是可以继续拆分的,那么把大任务拆分成数个小任务,然后将可以完成的一个或几个小任务放入sprint
- 告诉PM在Scrum中,可以使用UNPLANNED ITEM LIST处理这种情况,可以把想完成但是在此Sprint中来不及完成的任务先放在UNPLANNED ITEM LIST中,然后每日通过燃尽图跟踪进度,一旦发现进度超前,那么可以把UNPLANNED ITEM LIST中的任务随时放入当前的Sprint.
5. 画一张较好的图表
什么样的图表是较好的图表呢?我觉得非常简单,照着“硝烟中的Scrum和XP”一书的封面画就行了。
这张图中容易忽视的东西有以下几点:
1.右上角的Sprint Goal,这个东西很重要,一定要画到图中
2.向PM阐述右下角的unplanned item和next的作用
3.向团队阐述任务从上到下是按重要性排列的
4.传统开发中任务必须有owner,但是这种图中并没有,要让团队明白,团队是一体,团队所有人的GOAL是一样的,就是图中右上角
后记
忙碌了一天,PM的评价是“Scrum还真不错,因为我能感觉到项目在前进”,团队的评价是“哎呀,这个release似乎比上次轻松呢”,这就是对我最大的褒奖,我很开心。
但是仍有一些担忧,首先是团队这种高涨的士气和对Scrum的热情能持续多久。其次是在sprint执行过程中,会出现什么样的问题。
不过问题暴露的越多,就能对Scrum有更深的体会吧 :)
分享到:
相关推荐
2017-Scrum-Guide-Chinese-Simplified
极限编程,scrum
名称:Agile SCRUM for Trello boards -------------------- 版本:1.4.7 作者:https://xaviesteve.com 分类:生产工具 -------------------- 概述:使用故事点、项目和进度条为您的 Trello 看板充电。 用于 Trello...
硝烟中的Scrum和XP--我们如何实施Scrum.Henrik Kniberg著,李剑译.
这是scrum培训教程。Scrum是一个敏捷开发框架;Scrum是一个迭代式的软件开发渐进过程,通常被用于敏捷软件的开发;Scrum要求团队在每一次迭代的结尾完成一些可以交付的工作片段。迭代要短,有时间限制。
Scrum 的权威指南:游戏规则
2020-Scrum-Guide-Chinese-Simplified
敏捷项目管理-Scrum-PMP考点汇总的敏捷项目管理。
Scrum 已经被应用于开发软件、硬件、嵌入式软件、交互功能的网络、自动驾驶汽车、学 校、政府、市场、管理组织运营,和我们其他日常生活中,作为个体和群体的一切。 随着技术、市场和环境的复杂性和互相间影响的急速...
The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core ...
scrum guide
由创始人发布和维护的敏捷开发指南
2017年12月Scrum指南有Jeff和ken更新,由敏捷咨询机构ShineScrum翻译提供,为目前最新版本
中英文版的文档,简洁明了的描述,对SCRUM的整体架构的简介
光环培训课程标准版,非常适用。
Scrum敏捷项目管理Scrum敏捷项目管理Scrum敏捷项目管理Scrum敏捷项目管理Scrum敏捷项目管理Scrum敏捷项目管理Scrum敏捷项目管理Scrum敏捷项目管理Scrum敏捷项目管理
敏捷开发实践-我们这样实践Scrum 敏捷开发实践-我们这样实践Scrum 敏捷开发实践-我们这样实践Scrum
2. Scrum Team 在 一个 Sprint 期间将选择的工作转化为价值的 Increment。 3. Scrum Team 和利益攸关者检视结果并为下一个 Sprint 进行调整。 4. 重复 Scrum 是易于理解的。原封不动地去尝试,并确定其哲学、理论...
Getting Agile with Scrum Mike Cohn Scrum is one of the leading agile software development processes. Over 12,000 project managers have become certified to run Scrum projects . Since its origin on ...
硝烟中的Scrum和XP-SCRUM与极限编程中文版pdf,教你我们该如何实施Scrum,一些前奏知识,阅读多了解肯定有好处,书籍较清淅。