我是10年毕业，然后做了2年开发(其实还有8个月的实习，这个就不算了)差不多2年的项目管理经验吧，也整理下自己的一些收获，有些地方可能有些理想化，有什么不对或者做的不好的地方，希望有人能够指正!

　　1.需求来源或挖掘

　　对于开发团队来说，需求的来源应该只有一个，那就是需求工程师(很多不专业的产品经理也是需求工程师的干活，而有些直接是项目经理去谈需求，这里统一为需求工程师)，我也见到过有客户直接把电话打给我们的开发人员的情况，这个时候我们也要求开发人员可以去听客户想要什么，但是了不要答应用户要不要实现的问题，接到电话后了解用户想要什么，然后反映给项目经理和需求工程师，由需求工程师来再次的跟客户联系，了解需求。

　　之前我们团队也一直在抱怨需求多变，朝令夕改，也一直在抱怨需求工程师就是一个传话筒，唯一的作用就是把各方的要求收集起来!这不是用户的问题，有可能用户自己都没有想明白，这时候就得需要需求工程师去了解业务，深度挖掘用户真正想要的是什么，然后来决定整个系统需要怎么样来实现。这其实就是一个化被动为主动的过程。

　　而就算再深度挖掘 也有很大的可能还是无法去真正理解到用户心理想要的，这个时候就得拥抱变化，所以我们才当初的瀑布式开发转投为敏捷开发。

　　看过一本书《你的灯亮着吗》，里面有一句很有意思的话：不管看上去如何，人们很少知道他们想要什么，直到你给了他们想要的东西。，这也是我们转投敏捷的一个原因，通过快速的迭代来产出成果，给用户一个东西后，让他更加的明白自己想要的是什么!

　　2.项目经理和需求

　　在说敏捷之前先交代下我们团队，我们团队是比较成熟的一个团队，开发人员5人，测试人员3人，需求工程人员1人，开发测试都是2-3年合作过来的人，彼此熟悉，而且部门经理是敏捷的推崇者。

　　在需求正式纳入之前，需求工程师和项目经理先要对需求进行一次探讨(如果可能，项目经理最好也参与进需求收集的过程，退一步也可以是需求收集的关键会议)，了解需求的信息，要了解到一个需求功能的以下几点：

　　1.功能的使用者是谁? who

　　2.功能的本质意图是为了解决什么样的问题? why

　　3.功能的主要内容是什么，关键字段是什么? what

　　这里不需要去讨论功能如何具体实现，而是做到项目经理心中有数，对业务有个清晰透彻的了解，是否有需求可以通过更好的方式去替换，需求工程师考虑的是否有欠缺。

　　PS：如果说项目经理充当了需求工程师的角色，那么上面的3个W还是要做到，因为项目经理是直接面对开发人员的，项目经理是否懂业务在整个开发中是很重要的一笔。

　　3.开发人员和需求

　　接下来就是敏捷的计划会议过程，是由需求工程师向开发人员宣贯需求，并对需求进行优先级排序，开发人员有任何问题都可以在会议上提出，如果能够更好的解决方案那就最好了!

　　在这里首先得要明确一点，在迭代会议上只做确定了的需求，需要保证的是，在这个会议上需求都是明确的，尽量保证是在三周之内不会发生变化的(对于在迭代周期内发生需求变化或者加塞的出现，下面会再讲)，还有一点要明确需求尽量在迭代周期之内不变，需要外部环境的支持，比如决策层，他们要有共识，采用迭代这种最小单元的模式!就算发生变化，也尽量在下个迭代去实现或者更改，如果没有共识，那么就需要项目经理或者部门经理去公关，去明确阐述迭代的优弊。

　　拿我们公司为例，在起先的项目过程中，我们并没有采用敏捷，所以就经历了很多痛苦：需求一接一堆，开发人员没命的工作，但是做出来东西后用户发现不是他们想要的，然后之前做的全都白费重新来过，一大堆的功能造成每一次上线就跟打仗一样，每次都是很大的升级，部署后经常会遇到这样那样的问题!在这样的情况下，领导就很容易接受我们部门经理提出的敏捷了(当然具体公关肯定不是这么简单的)。

　　开发人员明确需求后，对每一个功能进行估工时，其实这块是最麻烦的，我们现在的做法是：

　　对功能进行拆分，将每一个大的功能点拆分成最小执行单元，这里所说的最小执行单元指的是可估出来的功能模块，一般2天左右最好，最多不能超过3天，如果发现有超过4天的功能点，那就继续拆，直到拆解成1-3天的情况。拆分功能模块还有一个好处就是有利于开发人员更好的理解和设计需求。因为是全员参与的功能拆分，大家对每个模块都有一个清晰的了解，有利于接下来的进度安排以及风险管理!