项目Scrum历程随手记 - 第一次Scrum Sprint Meeting

在为团队进行过几次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有更深的体会吧 ：）