|
为了解决问题，我对2名需求人员(PO)进行了用户故事方法系统化的培训和辅导。项目管理论坛
在用户故事编写方面，严格要求PO(2名需求人员)按照用户故事经典三段论的格式进行编写。并有效采用了史诗故事和用户故事两层需求描述的层级。在用户故事验收标准方面，根据产品情况采用了“需求点”的验证方式。项目经理博客
项目管理者联盟
在用户故事估算方面，采用了计划扑克进行估算，开发与测试同时参与估算，通过估算，大家对需求的理解达成了真正的一致。training.mypm.net
项目经理博客
在发布计划方面，采用了时间驱动的发布计划。项目管理者联盟
项目管理论坛
在迭代过程中，当开发认为他已经完成了故事的开发时，会召集PO和测试进行MiniShow,做到了及早用可工作的软件来验证PO\开发\测试的对需求理解是否真正的一致，如果发现彼此的理解存在偏差，会及时进行修正。PgMp.mypm.net
当测试完成后，PO会进行需求的用户验证，因为采用了用户故事方法。用户能够得以场景式的进行功能验证，更容易参与，从而用户的反馈更加保真。项目管理者联盟
项目管理者联盟
在团队方面，从PO角色职责的角度，对需求人员进行了多次的点对点辅导。使PO主动打破了职能墙，开始积极参与团队的各项活动中，使需求人员真正成为了团队的PO。项目管理者联盟
经过一段时间的改进，相关Leader终于意识到过多过程文档编写的弊端，减少了过程文档的要求，降低了团队成员不必要的浪费。项目管理者联盟
当2名需求人员成长为成熟的PO,在分享敏捷改进的经验感悟时，她们总结出用户故事的实践价值如下：www.mypm.net
• 便于团队成员内部快捷地达成真正的一致，节省了沟通成本;项目管理者联盟
• 便于迭代的精准计划、价值导向的适应性调整，增强了团队成员的目标感;项目管理者联盟
• 便于快速稳定交付，提升了团队的效率产能;
• 便于用户提供业务场景层级的价值反馈，提升了用户验证的质量;项目管理者联盟
• 促进团队从关注任务到关注价值的思维转变, 增强了团队整体对产品业务的理解，提升了团队的凝聚力。项目管理者联盟
文章首发于王凌宇的个人微信公众号：凌宇哥聊敏捷（ID：agile-lean） 项目管理者联盟 项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
