首先向园子里的所有朋友说声新年快乐！
去年有半年时间我呆在客户现场做项目，一直到按时保量成功交付。在项目开发期间出现过不少插曲，很大一部分都是需求方面的变化，我们团队也曾经担心着急过，怕项目不能按计划完成。后来事实证明，这些担心是多余的，只要有良好的开发过程，就能做到拥抱变化。
在去客户现场之前，团队已经将需求文档整理为用户故事列表，全部放在Mingle里管理。到达现场之后的一周，也就是项目正式开始的第一周（我们称之为第0个迭代），项目经理和业务分析师与客户一起，完成了最初几周的迭代计划。从我们开发人员的角度来说，知道了要做什么，就可以开工了。
前两个迭代进展很顺利，不仅仅是开发人员上手很快，而且实际的工作量超出了计划，完成更多的故事。于是第三个迭代的第一天，经理就信心满满的拿着项目去给客户演示。
在我们项目中，每个迭代结束后会给客户进行演示，它的好处有几点：
- 1. 确定开发出来的产品符合客户的要求
- 2. 收集客户反馈，帮助团队做持续改进
- 3. 给客户信心，让他们看到团队的工作成果和效率
- 4. 给团队成员信心和成就感
然而客户却表示，这完全不是他想看到的系统，没有反映需求，没有反映公司的精神和宗旨等。但是呢，他也说不出来他需要的系统到底是什么样。这个时候，团队的所有人都很郁闷，到底做成什么样才能真正反映出需求，让客户第一眼看到就说：恩，这就是我想要的系统。反正想是想不明白，在这之后，团队进行了一次简短的站立式会议，作出决定，花一下午的时间重新进行需求会议，与客户沟通，挖掘出我们要的信息。
会议一开始，项目经理简单介绍会议的安排，然后便开始需求的讨论。客户和团队一起头脑风暴，客户说出自己想要的功能，我们进行梳理，其中不断的提问和确认，直到弄清楚所有需求相关的细节。本来这个会议的初衷是引导客户，挖掘出我们需要的信息，但回忆起来，当时客户在会议上占了主动地位，也许是因为经验不足，只有项目经理有QuickStart的经验。不管怎么说，不管走了多少弯路，我们还是了解了不少需求，比如如何才是反映公司的精神。会议结束后，团队成员们马上设计用户界面原型，根据他们的要求，作出核心页面的lofi-prototype，给客户确认。客户看后，很满意，觉得这已经比较好的反映了需求。
事后我们总结，为了避免大的需求变动，我们应该做好几点：
- 1. 团队对需求的理解要和客户达成一致
- 2. 与客户之间的沟通尽量频繁
- 3. 尽早给客户演示，也能尽早获得反馈
- 4. 做好lofi-prototype
- 5. 在开始用户故事之前，向客户确认需求的范围以及细节
这次需求变动对开发进度影响很大，我们花了一个迭代的时间，重写了大部分的用户故事，重新进行迭代计划。但由于有了这次教训，在后来的开发过程中，我们按照上面的几点执行。在此之后，需求再没有大的改动，发布出来的产品也非常符合客户的要求。现在回首看来，这次问题的出现还是团队经验不足，如果从最开始就最好的话，那么这次大的需求变动也不会出现。
但是，微小的需求变动还是出现过很多次，这些大多数是细节方面的问题。其实仔细想想，不管需求怎么变动，都是有风险的。比如对于某个功能，要去掉这个，加上那个。只要这个变动对客户有价值，那么我们就应该去做。必不可少的，我们会修改现有代码或者添加新的代码。那么是否有信心做这件事情，尤其是在项目的后期？有没有担心改动会破坏现有功能？有没有担心修复好的Bug重出江湖？对于这些，我们是不会担心的。因为：
- 1. 现有的每个功能都有对应的功能测试
- 2. 每行代码都有单元测试覆盖
- 3. 对于已有的每个Bug，都有测试来保证它们不会再出现
- 4. 有持续集成工具，在很短的时间内，对一次改动进行反馈，如果出现问题，我们能很快知道并修复
- 5. 你写的每行代码，都会有你的结对成员帮你Review
通过以上的措施，就能将需求变动（也可以说对现有代码的修改）的风险降到最低。因为需求变动对客户来说是很有价值的，我们很愿意去做这件事情（排除个人情绪）。
有一次团队跟客户吃饭，他说道只有变化才是不变的，我们一片感概声。既然需求变动是不可避免的，那么就应该将它的风险减到最小，做到拥抱变化。
写到这里，可能有人会问，最开始不是耽误了几个迭代的时间吗？为什么对开发进度没有影响呢？其实很大一部分原因是随着团队成员对项目的理解，对开发工具、语言、框架的熟悉程度加深，开发效率也越来越高。但如何把握好进度呢，以后我会写关于项目进度的体会。
================================================================================
看了看回复，大家都说的很好，一些观点又让我有些体会：
1. 客户并非真的说不清楚想要什么，而是客户不是以我们能理解的语言来描述需求。我相信，如果对行业特别了解，理解企业文化，那么一定可以把握客户所谓需求的背后含义。弄清楚每一个需求的背后含义，就能做出很符合客户想法的系统。
2. 客户看到真正系统后，一定会知道这个是不是他需要的。因此，尽快让客户接触到真正系统并提出反馈意见，这就是lofi或者hifi，以及小版本发布的意义所在。
3. 每个功能尽量用最简单的实现，除非客户自己提出来。有时候最简单的时候足以满足客户的要求，达到他的期望值。即使花大力气实现漂亮的功能，客户也不能理解你所做的工作到底有多难，真是吃力不讨好。
4. 与客户利益一体。当客户感觉到，你的成功就是他的成功，***难你就等于***难自己的时候，你的项目就等于成功了。每个项目背后都会 有目标，比如帮助企业达到什么目的，又或者是政策需要，也可能是上级的任务。这个目标会给客户带来压力，他一方面想让项目按时按量做好，另一方面又会觉得我花钱就得让你多做事，要不然我就亏了。因此，就看如何去把握了。
5. 每一种软件开发过程都有自己的适用范围，我们团队所参与的是企业的应用系统，我想对于这样的项目，上面的心得是会有帮助的
posted on
