实践Scrum的感受

我曾经为之服务的一家公司，由于新项目的特点，也为了在公司的方法论资产做一个积累和提高，并且在详细调研了Scrum方法之后，公司老板作出决定，在E-Notebook项目中，开始采用敏捷开发方法，最近有空将其整理出来，做个留念：

和一开始接触任何事情一样，我先是有个了理论认识，在InfoQ上查阅了很多资料，知道了敏捷的宣言，如何来作，我也在理论上做了很多准备。知道了敏捷会议、敏捷例会、backlog、Sprint,燃尽图等等，并知道了其具体的含义和做法。但是在具体实践当中，还是有各种出乎意料的事情发生，所以也更加加深了对敏捷开放方法论的理解。

1）一开始，我总是认为在敏捷开发中，不需要做架构设计，所以在给我的组员交代任务时，我们只是进行了针对模块需求和功能的讨论，并采用敏捷方法推荐的方式（每个人对一个故事点的估计）来做了工作量的估计，并制订了backlog和燃尽图（用以跟踪项目进度和进度问题的图表工具）。但是我们开始工作的时候，发现虽然进行了讨论，并达成一致，但是由于每个人的能力不同，对设计和实现细节的理解也不尽相同，造成每个人的工作产出物（代码）在整体结构上的不一致，五花八门的，更要命的是，由于没有事前的统一规划，每个人的实现方式都不一致，为测试和联调带来了麻烦，而且没有统一的规划和设计，如一些系统用的常量，没有放到一个地方，连异常处理的方式都不一样，有的人是往上抛让框架或者最上层去处理，有的人是把异常丢给一个统一的处理器等等，有的地方写了日志逻辑，有的地方没有！一个小组最后在一个sprint中拿出的东西是如此的混乱！在第二个Sprint期间，我们改变了策略，那就是必须进行设计，并形成一定的文档，这样可以减少不一致性，和设计不正确性的可能（每个人的设计都不一样，所以会产生这样的问题），可以减少大家沟通上的成本，有利于模块之间的整合。综上，对于敏捷开发，不是不需要设计的，而是采用较轻的文档，最直接的沟通方式，方便的讨论等等形式来确认设计的，所以说在一个Sprint前期是需要做很多事情的，如设计活动。

2）我们每次Sprint会议开得都不错，主要是我们对敏捷开发这一块的思想理解比较透彻，

第一，我们利用Sprint会议达到对需求理解的一致性

第二，我们利用Sprint会议进行工作量的评估

第三，对风险的识别

第四，任务的分配

第五，对各个功能点的逻辑讨论，并达到一致意见

并且我们每次Sprint结束时（也就是客户认可完成标准时），我们都会开Sprint总结会，并在公司内部建立起一个wiki用来把总结的知识登录上去，以便共享。

3）我们基本每天开例会，也就是敏捷例会，主要目的是为了了解进度情况，可能出现的问题等等，会去Check每个人昨天完成了什么和今天要做的工作以及遇到的问题。这好像是完整地按照敏捷开发方法论的要求来做，不过在我们实施了一段时间，发现，很多时候流于形式了，这是因为对于一个复杂的工作，一天可能没有啥可以交代的，每天开例会，又给组员增加了压力，因为我每次都会问他完成了什么。后来我们觉得都没有必要每天搞一次，我就根据实际情况来安排例会的频率，有时候一天一次，有时候好几天一次。并及时地去更新燃尽图，并提交给PM。

4）我们在项目开始前有一个Productionbacklog,作为一个需求的范围，但是我们在每一个Sprint开始时就是根据Productionbacklog来制作Sprintbacklog,注意这里我们没有打散，

结果是组员对具体要做哪些具体的功能点不清楚，在做RTM时，也无法跟踪到很细的Item，所以大家就不得不化时间讨论一个Backlogpoint有多少子功能点。后来我们改进了工作方式，那就是在Sprint会议中把Sprintbacklog尽量细化到可以操作的地步。

综上，在按照backlog工作时，不是说把故事点列上去就可以了，而是应该关注它的操作性，毕竟Sprintbacklog是给内部看的，如果给客户看，那就简化一些就可以了。

5）我们和客户商量，并按照团队的生产率，制订了2周一次Demo的计划，并事先在Sprint会议上确认了如何演示的问题，并与客户达成一致。但是当到给客户做演示的时候，问题就来了，第一，客户在看完Demo后，改更需求，虽然说这很正常，但是就影响了下一个Sprint的计划，整个进度也受到了影响，我们事先没有考虑这一点，后来我改用每个正常Sprint之间加一个缓冲sprint的做法来解决，并写到项目计划中，使得变更能尽快反映到产品中去。综上，对于Sprint,我们应该灵活对待，应该根据项目特点进行改变使用。

6）敏捷开发方法提倡很少的文档，当不等于不要文档，文档的目的是为了有效的沟通，我们在第一个Sprint中，没有对关键部分写文档，造成沟通成本较高。所以我们应该正确理解敏捷方法中有关文档得思想！

综上，其实Scrum就是提供了一个方向，方法框架，具体怎么做，还得根据公司的特点，项目的特点，人员的特点，客户的特点来使用，并在一定条件下进行形式的变化。也就是说敏捷的核不变，但是具体的操作形式是可以变的。不能死板硬套，也不能排斥其他的方法论，一个Sprint可以看成一个迷你的传统他软件开发周期（瀑布模型），也不是不要做测试计划，也不是不要使用XP方法（可以看成一种更接近实战的方法，Srucm更加高层一些），结合不同的方法会得到很好的效果。