本文共 1302 字，大约阅读时间需要 4 分钟。
背景 自从我们使用scrum进行项目开发后，出现了这样那样的问题，有些是因为我们对scrum的理解不到位，有些则是客观因素导致的，针对这些问题，在每次迭代的总结会上，我们进行了反思，并根据具体环境对scrum进行了一一调整，想通过几篇文章和大家分享一下我的经验。 我说的不一定正确，只是描述问题，然后说说我对问题的看法，采取的解决方案，希望使用敏捷开发的大牛提供宝贵意见。 故事工作量估算导致的问题 我们在对backlog中的story进行估算的时候，我们采用了一些前人总结出的敏捷开发的最佳实践，其中一条直接导致了我们这次迭代提前结束： 1、共同估算：在估算前不应该指定谁将开发这个故事，而是以接收故事的小组为单 位集体估算，每个人提出自己的看法，大家综合。这样才能以集体智慧完成任务。 共同估算没有错，用集体智慧和知识对“做什么，怎么做，需要多少工作量”达成共识，共同估算也是为了提高团队成员主人翁的意识，大家会关心自己曾参与讨论的事情；共同估算意味着共同讨论，能提高团队成员对需求的理解程度，有助于开发出满足需求的功能，而且如果开发期间领了任务的人有事脱离岗位，另一个曾经参与讨论的人更容易接手些。 但，注意红色的部分，”在估算前不应该指定谁将开发这个故事“，这个最佳实践确使我们吃了亏。 我们项目组一个5个人，迭代周期为2周，一共6个story，在开发进行了1周后，三个人闲置了，因为他们已经完成了各自的story，而他们又没办法插手别人的story，因为别人进行了一半，而这个story的任务是有连续性的，闲置下来的人根本无法领这些未完成story下的任务，也就是出现了”任务对人的依赖性“。 不知道我描述清楚了没，我们的第一次迭代就这么提前结束了，因为我不可能让三个人闲着没事干，等着另外两个人。 经过总结会，我们决定在对story的工作量进行估算的时候，我们把谁做这个story规定好，这样每个人在本次迭代的任务量都是饱和的，除非划分不合理，不然不会出现上述情况，这时候问题又来了，在对每个人的story进行工作量估算的时候，各自都想争取到更多的时间，也就是都认为自己的story工作量巨大，如果不满足他的要求，很可能会引发抵触情绪。 在估算前，到底应不应该指定谁将开发这个故事？ 我们不能一棒子打死，简单答案绝不止是"应该"或”不应该“。要根据story的性质来决定，一般情况下： 1、对于功能性的Story，如开发一个用户管理模块，这种story，不应该指定由谁开发。分解后的任务粒度，应该尽可能地小，最好是1人日能完成，尽可能做到任务之间不要有依赖关系（尽可能，虽然很难）。 2、对于非功能性的Story，如解决某个架构上的难题，应该指定由谁开发，应该指定高水平的开发人员解决，对于大型项目，如果能有单独的一小部分人专门解决架构上的问题，环境上的问题，或者其他疑难问题，采用传统命令式的方式进行管理，我倒觉得更合适些。 最后针对迭代计划，进行一个宏观地评估，主要是为了避免出现任务粒度过大，依赖性强导致的"任务对人的依赖性"。 这篇就谈的这里，下篇谈谈敏捷开发实践中，关于文档的话题。
转载地址：http://qpdci.baihongyu.com/