敏捷里面的故事划分

  敏捷也实践了不少时间，做过的项目从新的feature的开发，到SP,维护，各种类型的项目都用敏捷运作过。每一类型的故事划分都有其特色。最近新搞了一个团队，对于敏捷所谓只闻其声，为见其行。在一次plan meeting上，新的团队对故事划分的concern充分反映了是否敏捷化的人对流程的认识的差异。

  故事很简单，做一个报表。这个报表比较复杂，很难在一个sprint中完成，所以很自然的需要去分解成一个个小的故事。缺乏敏捷经验的人，会习惯性的把故事分成前后台的方式。首先这就是在大原则上走错了。所谓故事，一定是在最终用户的立场上去理解的。每做完一个故事，一定需要对用户在商业价值上有所提升。试想一下，单纯完成了前台或者后台有什么意义呢？

  虽然我们面对的是一个完整的报表，我们的PO将它分解成了一个迭代和增量开发的序列。比如说第一个小故事是查出所有数据，没有任何过滤条件，权限控制等等。机会可以理解为数据库里存什么就显示什么，当然是以报表的方式。那么接下来的小故事，将会是添加某些描述性的列，增加排序，分组，增加色块标记等等。我个人觉得这是一个非常经典的敏捷式的故事划分。不过，我扫了一下会议上开发人员的脸，绝大部分甚至包括已经在敏捷中工作了1年多的开发，都显得很不爽。他们觉得为什么添加几个描述的列还要做一个单独的故事呢，我顺手就做掉了。这样一来每次都需要改接口，改存储过程，改前台的模板，等等吧。相当的浪费时间。对于一个成熟的Scrum Master来说，应该能理解开发人员习惯性的采取技术性的思维习惯去思考问题，而不是站在用户立场。我知道他们这个看法是因为看到了一个已经做好的原型报表，都觉得按照这个做就可以了。其实，这正是一个非常非常违背敏捷精神的立场。做敏捷一定想到一个字，就是“变”。这个变是随时发生而且是鼓励发生的。千万不要以为你看到的原型就一定是你最终生成的。这种假设是不成立的。一旦整个团队在潜意识里有了这个假设，那么就回到了瀑布模式。我们在思考问题的时候，一定要坚持，每个故事的完成后，都需要PO或者Stakeholders去review，那个时候各种想法都会扑面而来。他们在面对一个脑海里面的系统的时候，想法很多是天真而单纯的，而一旦他们面对一个真实可用的系统后，灵感会刷刷的往外冒，这是他们的工作，他们的专业体现，他们的追求。而作为一名合格的敏捷下的开发人员，需要提高的除了完成每个故事的质量和速度外，更为重要的是让自己具有承认并拥抱改变的勇气。另外就是在技术上要能灵活运用各种手段去让整个项目在一定的限度下容忍和支持这些改变。这才是敏捷开发人员的核心竞争力。我们可以很潇洒的说，这个改变，改改配置就好了，哦，这个啊，很简单。这才是一种良性的互动。正因为有了这样的鼓励，那些市场人员才会更加有大胆的想法，这样整个产品才会更有生气和竞争力，才能达到整个团队的共赢。试想一下，如果需求人员每提出一个改变，就遭到技术人员强烈的抵制，就算公司会压住开发人员必须完成，试想一下还有哪个人没事就提想法呢，那整个产品是按开发人员的思路前进还是与用户靠的更近的市场人员呢？单方面的胜利是不是很苍白无力？

  上面说的呢，是一个大原则问题，而不是具体到某一个故事。其实对于这几个故事是否合并，完全由整个团队决定，如果开发，测试，文档都没有意见，那当然可以将其合并，因为PO不了解各个角色对故事难度的评估，决定故事的人是整个团队而不是某一个人。保证敏捷的民主与开放也是大前提之一。