邓锄头挖科技▲没有“项目立项”的敏捷开发如何开始第一步？敏捷项目管理中并没有项目立项这回事

敏捷项目管理中并没有项目立项这回事，只有Sprint计划会议一说。
所谓立项还是沿袭了传统项目管理的说法，可是对任何员工来说，立项是神圣不可侵犯的，立项的项目一定会有人关注问题是怎么解决的，一定会关注项目结果。特别是对于对变更深恶痛绝的研发人员来说，立项了意味着变更要受到管理了，产品不能再随随便便地更改需求了。

文章图片
一提到立项，很多做过项目，甚至项目经验丰富的项目经理可能立即会联想到一系列规范的过程，其实并不需要那么负责，作为团队的管理者一定要记住不管做什么，一定是以结果为导向，采用最简单、最直接的方式达到目标。那么简化版本的立项应该怎么完成呢？
首先，先共识立项的目的。由于业务不同，团队执行能力不同，管理者在项目管理上的期望不同，立项的目的也是不一样的。在传统大企业的研发团队中，立项的目的要回答如下一些问题。第一个问题是为什么要做，一般是研发和测试团队来问产品经理的，敏捷的实施让研发和测试人员更加积极，原来的研发人员已经进入了怪圈，产品需求说一，研发就实现一，需求一有验证的逻辑错误，研发就按错误的逻辑实现出来。立项让研发和测试人员活了，让整个团队的成员都有了质疑精神。

文章图片
团队归纳了要做的三类事情：
1、为用户提供有价值的新功能或服务；
2、为改善和提升用户体验的功能的优化；
3、解决Bug 。
所以只要Sprint的需求用户故事能落实到这三类，这个问题就可以得到解决。第二个问题其实是项目优先级排序的问题，产品经理罗列的N多的用户故事，哪些更重要排在前面，也需要立项的时候回答清楚。

文章图片
【邓锄头挖科技▲没有“项目立项”的敏捷开发如何开始第一步？】项目交付的结果无须解释，但是这个结果要达到什么质量标准是必须在立项前定义清楚的，这里质量标准包括但不限于崩溃率、启动速度、功能的转化率、下载成功率、播放成功率、不可播率等。需求的理解在传统项目管理中需要定义烦琐的需求文档，在初次实施敏捷的软件研发团队先让产品、研发、测试达成需求的共识是必要的，这样大家可以分头去准备必要的需求文档、设计文档和测试用例。而对于风险好像除了进度风险团队就识别不出其他的风险了。