朋友关于scrum的一些分享

产品拥有者与业务分析员分离

首先，他们那边产品拥有者（product owner，以下简称po)和业务分析员（business analyzer，以下简称ba)是不同的人担任的，而且，po一般就是真实的最终用户；而我们公司po一般就是由ba来担任的。如果ba有过相当丰富的行业经验，让ba来做po可能也没有多大问题。如果ba的行业经验并不是很足，往往就会对用户的需求理解有误差，在一些细节上把握不准，从而没有自信。另外一方面，ba毕竟是在敏捷小组内的成员，让ba代表po做验收，并不能代表真实的客户真的满足。甚至于，ba有可能为了团队的燃尽图好看些，会故意减低验收标准。

ba会做整个项目的模糊的规划

尽管是用迭代的方式开发，开发人员一个迭代只关心当前迭代的用户故事，但是ba需要在更高层次上对项目做总体的规划。他们的工作方式是，让需求方的真实的用户，把自己想要的功能，写成一个一个纸条，ba对这些纸条整理，归类，细化，直到细化成一个一个的用户故事。这个过程其实就是一个需求分析的过程，需要ba和po长时间，集中精力，面对面的合作，才能完成。一旦这个用户故事被定义出来了，最后确认后，后面的迭代过程中将尽量避免用户故事的变更。 ba选取这些用户故事中可以做的，普通的故事让开发人员里面中等水平的人先做几个故事，根据他们的表现来得出一个经验的开发人员的效率。这个效率将作为整个项目过程中的一个标准，后面都参照这个效率。ba再以这个效率为准，估算整个项目需要的故事点，进而安排项目进度。当然这个估算很不靠谱，只是用来粗略的估算项目需要的时间的，而不是作为传统开发方式中的项目计划，以后要严格执行。 我们公司以前是没有这个过程的。领导经常会问我们，我们要几轮迭代才能做完，大概什么时候能交付上线，而我们都难以回答。我以前以为实施敏捷了，我们就只关心眼前的迭代周期，总体什么时候完成，我们不关心。照他们公司的做法，这个估算是应该交给BA来做的。但是BA的估算，一开始肯定也不会准确的，只能通过长期的工作来积累经验，找到合适的经验值。

迭代计划会的故事点的评估是全员参与，且以BA之前的实验为标准的

等项目开始正式的开发后，每轮迭代开始的计划会上，敏捷小组的所有成员还会再次评估故事点。因为对于不同的人来说，同样的故事难易度是不一样的，所以大家评估的标准不是这个用户故事的难易度，而是以当初BA做实验得到的结果为参照来做。比如，如果你觉得当初那两个中等水平的开发人员做那个故事要用2天，那么他们做这个故事要用几天呢？如果大家偏离了那个标准，ba最初做的计划将失去意义。而且，这个评估过程，是要所有人都参与的，而不是听开发人员的一面之词。当大家的评估有差异的时候，让所有人解释为何对相同的用户故事评估不同，也是让大家深入理解故事的一种方式。最终，大家将达成相对一致的评估方案，并且不应该和BA最初的评估相差太远。 我们公司的迭代计划会上，只有开发人员评估的，而且开发人员的评估标准都是以个人认为的故事的难以度为标准的，所以会出现同一个故事的评估结果差距很大的现象。大家从来没有想过要找到什么统一的标准来评估，所以不同的迭代，开发人员的产出率也很不稳定。他们公司让BA先做实验，先评估，再所有人评估，而且要以之前的实验作为标准评估，目的就是想要让故事点的评估变得更稳定可靠。但是我也不敢确定这个就一定有效果。正如每个开发人员的开发能力有差异一样，大家对用户故事的规模认识上也会有差异。 这样的评估方式可能产生和BA做计划时相差太大的评估结果。但是，我的朋友说，有差异是正常的，只要不太大就行，如果真的太大，就得要master试图调解以下。如果团队成员都真的评估成和BA最初的评估差别很大了，那也没有办法，只好这样做下去。但是总体上，有些评估过高，有些评估过低，应该和BA最初的评估差不多，当然这只是经验之谈。

团队考核，不关注燃尽图是否燃尽

朋友说，燃尽最好，燃不尽也不要紧，对团队考核时不是关注与燃尽图是否最终燃尽，而是关注于团队的产出率是否稳定，是否提升。我们公司现在的做法正好不是这样的，就是考核燃尽图是否燃尽，这样做已经出现了一些弊端。有些开发人员一开始评估时就非常谨慎，故意高估故事点数，结果造成本来评估要3天做完的故事，一天就做完了，燃尽图出现跳水。有时跳水得厉害，又在迭代中后期加故事，导致燃尽图陡降陡升。更有甚者，qa和ba为了燃尽，有时会降低测试标准和验收标准。当然导致燃尽图陡升陡降的原因不止是这一方面，只有开发人员参与评估故事点，评估故事点的标准太主观，ba做PO减低了验收标准，都是原因之一。

故事不一定要拆分成任务

有些故事评估出的故事点很多，大家很担心负责故事的人万一没有做好，进度难以掌控，因而尽量想把大故事拆分成一个个的小任务。但是确实有很多故事很难拆分，硬拆只会拆出开发人员看得懂，但是qa难以测试，po更不好验收的任务来。我们现在也为这个事纠结。而他们的做法其实很简单，就是不拆。

QA也可以和开发结对，所有用户故事都是结对完成

这个确实很新鲜，我们没有试过，我们只是部分故事结对，而且还是开发人员结对，QA不参与结对的。不过，我觉得这个值得一试。

一些问题依旧没法解决

比如： 1，遗留系统再开发，由于开发人员对遗留系统的掌握不透彻，评估几乎不可能 2，迭代周期里面，前期QA闲着没事，后期QA忙得来不及测试，负荷不均 3，多轮迭代后进度偏差太大时，要么加人，要么加班

个人的感觉

别人的经验并不一定正确，但是总有些借鉴意义。敏捷开发的核心还是在人，人是神奇的生物，可以做一些模糊的判断，看是不靠谱的评估，也是有可能得到合理结果的。当然，前提是团队通过多轮迭代，协作磨合，加深领域认识，提高代码质量，最终才能达到效率提升，输出稳定，评估准确的效果。

转载于:https://my.oschina.net/komodo/blog/919175