前面我们提到过，敏捷开发能帮我们拟定待办事项清单，也就是“用户故事”。有人问，如果故事规模小，使用用户故事来构建描述一个系统，特别是一个有一定规模的系统，将会十分困难，那是否一定能使用故事去对系统需求做合理的结构化呢？本篇将围绕这个问题来展开。
上篇提到，我们在撰写用户故事的时候，要多关注“价值”，所以我们会设身处地地从客户/用户的角度思考问题，会想尽办法囊括所有需要做的事项，但如上文所说，如果是一个有规模的系统，这样做的结果可能会是你列了很多待办事项，却找不到一个切入点，更别说你可能还做不到把所有事项都列清。
如何更快地提供价值？
OpenView风投公司创始人，斯科特·马克斯韦尔说，困难不是设想自己要做到什么，而是发现自己能做什么。必须明白自己能在哪方面以最少的精力创造出最大的价值，然后立即付诸实践，然后继续找出下一个能增加价值的事项。可能有人会说，那要怎么知道哪些事项具有更大的价值呢？
我还记得当时公司接了一个很大型的项目，里面有各种各样的子系统，当时公司派去调研的PM叫苦连天，客户讲的很多专业知识都听不懂，每天都在项目群里喊：XXX项目好难。后来公司开了一个内部会议，让各项目部的PM跟开发在开发项目之余要去学习一些项目涉及的领域内的专业知识，起因就是从这里来的。那么回到上面的问题，怎么知道哪些事项具有更大的价值？那肯定就是找领域内的专业人士啦，如果说找不到，那就自己成为这个“专业人士”。
找出最有价值的20%
《敏捷革命》说，“很多产品80%的价值都体现在20%的功能上”，我们假设这句话是对的，那么我们在每一个冲刺阶段上就要尽快做出那最有价值的20%的功能，因为它可以产生80%的价值。这就要求我们在每一个冲刺阶段，甚至于可能是每一天都要对待办事项清单进行更新，因为有可能面临的环境改变了，需求变化了等等。同样的道理，优先级顺序也会处在不停地变动之中。
笔者目前正在做一个面向学校教育的SaaS项目，定制化需求特别多，客户自己也没有想清楚要怎么做，而且市场上也没有什么竞品可以让我们对标，在这种情况下，我们做出来的原型自己心里其实也没底，而客户又好像没仔细看就把原型给确认了，这导致在前期开发中经常有意见不一致的问题出现，无形中就产生了浪费现象。基于这种情况，部门会议的时候针对这个问题展开了一场讨论。笔者整理成了流程，方便大家理解。
xxx项目敏捷流程
基于上述的一个项目情况，我们改变了策略，既然把完整的原型给到客户并不能收到什么有效的反馈，那我们就把原型分版本给到客户。80%的价值体现在20%的功能上，那我们就要去挖掘客户需要的那20%的功能是什么，在这之上去确立我们的版本目标。注意，这里要圈个重点，我们需要的是客户的有效反馈，从而适时调整我们的待办事项、优先级甚至于目标。
这条敏捷流程，笔者的部门在近期准备开始实施，要注意的是，这是笔者跟笔者部门的同事根据具体的某个项目制定出来的流程，不是适合每个项目，各位看官可以参考借鉴，但不能打包票可以解决问题，还请各位看官审慎思考，这世界不存在一成不变的东西，我们可以质疑一切。
再回到文中一开始的问题，当一个大系统被缩减到剩下1/5，基于这1/5去画原型，写用户故事是否也就变得没有那么困难了呢？
思考
1. 针对文中所说，“产品80%的价值都体现在20%的功能上”，你认同这句话吗？
2. 笔者的部门最近在开发项目的时候遇到个有趣的问题，在交付版本给客户这件事上，有同事认为应该UI开发先行，客户都比较注重体验感官，要是体验不好会给客户带来不好的印象；有同事则认为应该功能开发先行，功能涉及到很多复杂业务逻辑，这些走通了，UI可以慢慢调整。那各位看官觉得呢？可以在下方评论留言互动。
网友评论