运用Scrum做项目管理真实案例之四

引言：

我会以系列文章的形式跟踪记录我现在正在做的一个完整运用Scrum管理项目的笔记，里面会有一些经验教训总结心得，以便读者与我互相学习勉励。有写的不对的或者写的不好的地方还请海涵，当然我更希望大家多多提宝贵意见，读者的支持是我最大的动力。（之一，之二，之三，之四，之五，之六）

============================================================================================

不好意思，最近一直都很忙，不仅仅是忙于工作，还有家里的一些事情需要处理。所以没有抽出时间来更新博客。

系列谈上一回我们主要谈到了沟通问题，相信大家都知道Scrum的5个价值观：沟通、公开、专注、尊重、勇气。所以我一直认为沟通是第一位的。只有拥有良好的沟通敏捷才可以成功。当然其他几个都同等重要。

到目前为止我们项目敏捷已经实施了将近3个多月了。按道理说我们应该有很多收获了，但是我个人总觉得收获不大，或者说是因为我们的进程太慢。总感觉使不上劲，最近看一些论坛说过一句话，敏捷实施的好不好或者彻不彻底要看你Scrum Master（SM）这个职位或者职责实施的彻不彻底。现在我们团队没有定义SM这个职位，所以我们敏捷其实是非常的不彻底的。只能靠我个人的努力不断的去接近。心力交瘁啊。

上干货，今天主要谈谈几个会议吧，其实Scrum中的所有会议都是非常重要的，1、Sprint计划会。2、每日例会。3、回顾会。4、反思会。有的地方还会加一个Release发布计划会。
Sprint计划会议：（这个会议我们做的最不好，所以我说的最多）

Product Owner（PO）讲解Story，特别是业务背景，验收准则等。然后Team团队一起评估Story，并分解成2~16小时的Task。我们一直都没有做好这一部分的工作，主要问题有这么几个方面：
1、我们没有真正意义上的PO，基本上是客户提出需求，然后主要有Project Manager（PM）来分析理解需求，然后Technical Manager（TM）协助PM编写Product
Backlog，当然写出来的Story就更偏向于功能级的Feature List。所以首先在需求讲解这一部分就比真正的PO要弱了很多，业务背景也差了许多。这是我们的不足之一。
2、开发人员没有很强的主动意识，或者还不愿意去改变，或者说公司并没有很直接的去推动敏捷。开发人员总是依赖于PM或者TM去分配任务，在计划会议的时候不喜欢或者说不善于去思考问题。导致Story分解Task的时候无法进行下去。或者非常困难的进行下去又都是形式上的分解。何为形式化分解了，就是每个任务都是分解成同样的5步：（1）需求理解。（2）界面设计。（3）测试用例和概要设计文档编写。（4）编码。（5）自测。当然分成这几步没错，也总比不分解要好的多，但是过于形式化，大家并不喜欢真正的去思考，最后还是跑到了老套路去了，一个功能模块一个人去完成，不论分解成5步也好还是10步也好。完全没有体现合作、协作、团队。不过追根到底可能还是跟我们一开始分解的Story太偏向功能模块有关。

3、评估时间与单位问题，常见的评估工作量有两种度量单位，1、Story Point。2、理想时间。对于第一种Story
Point来说比较抽象对于第一次实施敏捷的团队来说可能不好掌握，所以我们采用了理想时间。可是问题来了，虽然我解释了无数遍理想时间的意思是你完成一个task所需要的连续的理想的时间，强调是无打扰不间断很理想的。可是开发人员还是喜欢用8小时，16小时这样的时间段来评估任务。总是无法抛开1天8个小时这样的概念。在我强调我们最大利用率最多时有70%，也就是一天只有5.6小时理想时间时，他们依然很茫然。意识的改变真的是一件非常困难的事情。每天我在收集时间所用task时间的时候他们也总是把一天填满8个小时，每次我问实际时间是多少，他们总是说是8小时，似乎不填满8小时就是犯罪一般。
分析以上几方面的问题，我给出的一些建议是，1、增加与客户的联系，没有PO是硬伤，这个我也没有具体的办法，只能做好一切可能的沟通理解用户的业务背景与真实需求。2、Story编写应该跨功能，趋近客户价值。不应该是功能模块，这样不是敏捷的思想，没有价值可言。而且在分任务时必定会趋近瀑布模型一个人编写一个功能模块。增强开发主人翁意识，强迫每个人来分析Story应该如何划分task，要给出初步的界面设计和概要设计，要说出来，如果你来开发这个Story准备分几步来完成。并且如何完成。（简要说明）3、收集时间时，一天不然填满8小时甚至是不然填7小时，最多可填6小时或更少。估算时间时，就可以参考以前收集的时间来分析估算现在任务所需时间。
每日例会，也叫晨会：

晨会其实说起来简单，但是做好他也不是一件非常容易的事情。那么我觉得应该注意的几点是：
1、不要超过15分钟。（7人左右团队）
2、回答三个问题的时候，要注意，1）我昨天做了什么？但是要说明做的情况，是否已经做完？做完了是否解决了什么特别的技术问题？没做完预计什么时候可以做完？2）今天将要做什么？但是要说明今天的任务预计什么时候做完？3）遇到了什么困难？包括昨天我们遇到的困难？超过2小时候的困难一定要记录到Block看板里。还有今天我处理的事情中我可能会遇到的困难，我需要帮助。那么其他人员尽量主动的思考是否可以帮助到他的。然后约定时间会后一起沟通解决。
3、会上不要解决任何技术问题，如果会上有很多技术问题的话，那么一定是会下大家都很少沟通的原因。会上应该找好可以帮助到自己的人，然后会下去解决。
回顾会：暂时我们没有这一部分。这里也不做分析。
反思会：
反思会个人认为对于敏捷的持续改进来说非常有作用。在反思会当中，团队会自我发现我们在上一个sprint中大家最关心的碰到的问题。或者我们做的好的地方，大家都很认同的。那么反思会应该是在一个好的沟通环境当中，大家都非常放松畅所欲言。好的东西，我们要总结出来为下一个sprint发扬使用。不好的方面我们要选出2~3项做更深入的分析，找出深层次的原因，拿出解决方案。然后制定负责人，在下一个sprint中取改进。很重要的一点就是，如果有多个sprint都提到了同样的不好的地方，我们就要引起注意，把他特别的拿出来做分析讨论。拿出可执行的解决方案。派专人跟踪执行情况。作为一个团队，我们每一个人都有责任和义务一起去思考拿出解决方案，并一同协作解决。等会我会加上我们几次反思会的一些成果分享给大家。我也非常想看到大家的分享。呵呵
最后还是强调Scrum的价值观：沟通、公开、专注、尊重、勇气。