产品经理需要了解的敏捷方法实践

 

互联网产品的开发周期短，需求不断变化，所以敏捷方法是很适合互联网产品开发项目的。但综观国内，能灵活且高效地使用敏捷方法去进行项目管理的成功案例并不多。大的方面在这里就不啰嗦了，如需了解，可以看这里。

 

公司的一个项目也曾尝试使用敏捷方法，但实践中留下了诸多问题。大家都在抱怨根本没有敏捷可言，最后做得不伦不类。究其原因，主要还是由于公司原有的组织架构和业务类型造成的。

 

组织架构：公司现有的组织架构是矩阵型，QA和developer分别隶属于不同的Manager。这样就造成QA在项目中不能全力投入，QA manager有可能会安排别的任务给QA。敏捷项目则最好是QA和developer隶属于同一个manager，这样就便于协调QA的任务分配，保证QA可以全力跟进项目；另外，敏捷项目中的人数为4-7人为宜，其中1-2人为QA。这么小的团队，没必要再加入一个QA manager的角色，这样只会增加了沟通的渠道数，反而影响了进度。

 

项目类型：公司业务范围属有线电视领域，客户为有线电视运营商。这类客户是对产品的稳定性和可靠性要求特别高。他们往往会在lab里面试用产品半年至数年之久，这样用户的反馈就非常慢，周期也拉得很长了。用户的需求很难及时地反馈并反应到产品上面来，所以敏捷开发对这类的产品根本不适合。

 

采用敏捷方法的项目对项目组成员要求较高，起码整体是在同一个水平线上，没有明显示短板。另外则要求团队的合作意识较强，最好是已经进行了一段时间的磨合，团队成员之间相互了解，相互信任。敏捷方法非常强调信任：产品的Owner要信任团队成员；团队成员之间要相互信任；QA和developer之间要相互信任。出现了问题，不需要直接找QA，直接由developer来认领； 任务单也是一样，由成员自己来主动认领。

 

产品的Owner则负责整体工作的协调，并负责确定项目的范围。在用户反馈方面，负责汇总和筛选，制定出下一个版本的Feature List。

 

这里要强调的是QA需求在需求分析阶段就介要入，只有这样，在测试的过程中才不会有遗漏项没用测试用例覆盖到。

 

另外，团队成员的座位安排也非常重要，他们要集中在某一区域，这样非常方便口头沟通和交流。即节省时间又可以避免距离较远而影响沟通效率的情况。

 

好的，就这些吧。