在近几年比较火的敏捷开发大背景下，我们的项目团队的需求管理，也一直在探寻着敏捷开发的轻量化管理的原则，并且由于我们团队采用了Featureteam的团队运作模式，所以版本的需求都是由各个FT自己独立管理的方式，理想状态是，各FT自己管理需求，自己去做质量管理，自己评估把控进度和最后版本的顺利发布。而现实往往和理想之间，总会存在差距。下面就来谈谈，咱们浏览器项目需求管理那些事~
需求管理1.0时代---FT自管理 excel规划表
我们知道，敏捷价值观中有一个是关于文档的，认为：
这个原则本身是一种比较好的价值观，认为在开发过程中，有可用的软件好过详尽的文档描述，来引导团队快速迭代做出可用的软件。我们的项目需求管理1.0时代，就是用excel列表的方式来轻量化去管理需求，通过项目群来同步版本需求规划。
这个变化将需求的评估充分放权给FT内部完成，你需要根据火车版本的周期，来评估和规划，版本周期内可以完成的需求，而不是所有的需求都想挤上同一趟火车。
2、我们将产品管理委员会对需求的评审时间，延后到合流阶段，建立了合流评审的机制。这样做的好处是，当开发到合流阶段时，需求功能已经基本完成并可以使用了，这样给到老大进行评审时就比较直观，这样再评审后的既定时间内稍作修改基本就可以达成需求的预期，也减少了合流后的需求变更带来的质量风险。同时，对需求的变更管理也进行了规范，需求的重大变更或新增均需要有充分的理由给到GM审批，通过才能合入。
经过一段时间的运作，我们来看下实际的效果：
（1）版本从延期不可控到逐步可控再到基本无延期；
（2）需求变更逐步改善，变更率下降了到67%；
（3）质量逐步提升，千行缺陷率也下降明显；
大大降低了项目的时间和人力成本，同时也为产品需求的快速上市提供了保障。
当然，敏捷项目需求管理的方法，我们仍在不断总结和迭代优化中，希望大家也一起来多探讨更好的管理模式，期待更优的需求管理4.0时代的到来！
更多敏捷测试管理文章，请前往51Testing软件测试网。
,
