如何组织需求讨论会

讲故事的过程我们一般通过需求讨论会的形式来进行,确保以上应该参与的人员都到场。既然是个会议,我们就必须确保会议的高效,这里可以参考三星高效会议的8点原则:

(1)凡是会议,必有主题;
(2)凡是主题,必有议程;
(3)凡是议程,必有决议;
(4)凡是决议,必有跟踪;
(5)凡是追踪,必有结果;
(6)凡是结果,必有责任;
(7)凡是责任,必有奖罚;
(8)凡是奖罚,必须透明。

针对需求讨论会,我们至少需要有以下安排

  • 会议主题:XXX产品需求讨论会,目的是在4小时内对XXX产品的XXX内容进行讨论
  • 会议议程:
    • 组织者:产品经理XXX或者项目经理XXX
    • 参与者:业务方或最终用户,产品/项目经理,团队技术人员(架构,开发,测试等)
    • 讨论内容(按照优先级排序的故事列表)
  • 会议分工:
    • 主持人:由产品经理和项目经理轮换组织
    • 需求记录人:由技术团队内某人承担,负责在讨论过程中将用户故事和所产生的功能点进行详细记录,形成文档或者录入系统。
    • 问题记录人:由技术团队内某人承担,负责在讨论过程中将无法现场确认的问题进行记录,形成文档或者录入管理系统。
  • 会议交付物:
    • 针对议程中的每个用户故事所产生的文档或者管理系统记录
    • 讨论过程中所记录的问题列表或者管理系统记录
    • 针对用户故事文档的下一步操作,如:制定开发计划,预算等等
    • 针对问题的跟踪方式,如:问题列表的状态由谁负责维护,每个问题由谁负责解决跟进,每个问题预计解决的时间。

需求讨论会的过程就是按照以上3个步骤讨论故事和分析故事的过程,我们可以按照以下流程进行

  • 讨论会前期准备

    • 可以在进行正式的需求讨论会前先进行一次头脑风暴,邀请用户和技术一同参与,在这个过程中大家可以自由讨论。目的是让大家现对产品的大致情况有所了解。
  • 讨论会过程
    • 首先由主持人(产品经理PO/项目经理ScrumMaster)向团队列出会议所要讨论的故事列表,这个过程不用讨论细节,目的是让大家知道会议的内容和目标,便于控制进度。
    • 根据所列出的故事列表优先级,从第1个故事开始梳理故事主线,分解功能点,并由专人负责记录
    • 重复以上过程直到完成列表中所有故事的讨论
  • 注意事项
    • 一定要按照故事列表逐个讨论,每个讨论都要细化到功能点并完成记录,再进入下一个故事的讨论;不要先讨论所有故事主线,在一并分解功能点。这样做的目的是让团队可以聚焦,避免多条线索交织造成干扰。
    • 在讨论每个故事的时候,不要讨论与当前主线无关的内容;特别是技术团队容易从一个功能点扩散到其他功能点,因为这是技术团队对产品的视角;这种扩散会降低效率。主持人在看到这种情况的时候应该适时制止,告诉团队其他的功能点可以留到其他故事中讨论,只要的产品的一部分,我们在后续的故事中肯定会涉及。
    • 完成每个故事的讨论后可以进行短暂休息,在讨论过程中要确保每个参与成员都集中精力,避免形成小组讨论的形式。建议每个故事的讨论都站立在白板前进行。
    • 主持人可以由PO和ScrumMaster按照故事进行轮换,主持人的主要职责是确保过程的顺畅,团队精力的集中。
    • 待确认事项
    • 建议在白板上开辟一片区域对讨论中出现的团队无法当场确认的问题进行记录,避免在这些问题上纠结太久,影响会议效率。
时间: 2024-11-05 04:52:04

如何组织需求讨论会的相关文章

用户故事驱动的敏捷开发 – 1. 规划篇

敏捷开发现在已经不是新鲜事物了,我们都从各种渠道听到过不同的团队实施敏捷的胜果,听的时候觉得很美,回到家就发现那都是别人家的团队,结合自己的情况一看就发现问题一大堆.就算是最终打算一试,也经常会不知如何开始.这就是我希望编写这份文档的原因,能够找到一个遵循的敏捷项目管理模型,虽然我们都知道没有一个放之四海而皆准的方法,但在更高的层面上我觉得这仍然是可行的.也就是说,管理模型是一致的,但是其中采用的方法可能各有不同,最终目标是唯一的:打造一支可以快速适应变化的高质量团队,并输出高质量的产品! 今天

01《软件需求模式》

这本书可以帮助分析师编写出更好的需求,这些模式提供了一种方法表达关于不同类型需求的全面的结构化知识.需求开发是探险之旅,不只是简单的收集或抄写的过程.所以我选择了这本书作为十月份的阅读书籍. 这本书的目的是帮助决定和定义新的软件系统需要做什么,建议添加哪些额外的特性,使系统更好或者更卓越.这本书的主要读者是涉及决定一个新的软件系统需要什么的任何人.例如说:业务分析师.软件架构师和工程师.软件开发人员.软件测试人员.项目经理. 阅读这本书我将能够定义更好的需求——更详细.准确以及清晰.并且更少的不

什么是软件需求?什么是功能需求?

我们的软件产品或者项目,其需求都有三个层级和三个方面. 一.我们首先看需求的三个层次 软件需求包括3个不同的层次――业务需求.用户需求和功能需求. 业务需求 (Business requirement)表示组织或客户高层次的目标.业务需求通常来自项目投资人.购买产品的客户.实际用户的管理者.市场营销部门或产品策划部门.业 务需求描述了组织为什么要开发一个系统,即组织希望达到的目标.使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(pr

产品经理 - 需求调研常用方法

需求获取一般包括这几种方式: 观察法.体验法.问卷调查法.访谈法.单据分析法.报表分析法.需求调研会法.这是需求调研的"七种武器",它们各有优缺点,无论你想要了解的是什么需求,都需要将这些方式组合应用,针对你想要了解的内容,以及需要了解的对象的工作特点,采用不同的方式.学会并坚持使用这七种武器后,我想你很快就会成为需求调研的真正高手. 观察法 观察法,就是你自己跑到工作现场,看!这个看上去相当简单,貌似走马观花,有些不在行的兄弟会弄得跟公费旅游一般,车间里走走散散心,撩撩HR妹子,就认

掌握需求过程(第3版)Mastering the Requirements Process:Getting Requirements Right , Third Edition ——词汇表

actor(参与者)   与产品用例交互的人或自动化系统.参与者也被称为用户或最终用户. Adjacent development(相邻系统)  向你研究的工作系统提供信息或接收信息的系统(人.组织机构.计算机系统等). Agile development(敏捷开发)  利用迭代开发开开发软件的一种方式.存在许多敏捷技术,包括Scrum.极限编程和水晶开发等.我们使用术“迭代”来指所有敏捷或迭代开发. Agile Manifesto(敏捷宣言)  一组规则,关注向顾客交付能工作的系统.协作式的工

Scrum Mastery:有效利用组织的5个步骤

组织以什么样的方式能最大限度的发挥Scrum的优势?组织在哪些方面阻碍了个人的发展?Scrum是一种能使业务变得敏捷的框架.而组织恰恰需要变得敏捷.只是,组织本身有时候并没有足够的能力来帮助Scrum团队的成长,甚至还会阻碍Scrum团队的成长.组织本身所具备的公司架构和企业文化,将影响内部的团队和产品.所以组织的作用不能忽略,且与组织背道而驰没有任何益处.必须有效利用组织来获得最大效益.有效利用组织的5个步骤 第1步:明确组织需求,融汇贯通 深入思考什么才是组织真正想要的.或许先要有一个明确的

UML和模式应用5:细化阶段(1)--概述

1.前言 从本文开始进入细化阶段,讨论迭代技术的基础,本次讨论将着重讨论第一次迭代,以POS机为例. 2. 第一次迭代处理的需求(以NextGen POS项目处理销售用例) 实现 处理销售 用例中基本和关键的场景:输入商品项目并收取现金 实现用于支持迭代初始化需要的启动用例 不处理任何特殊和复杂的部分,仅仅针对场景的简单理想路径,并对此进行设计和实现 不与外部服务进行协作 不应用复杂的定价规则 不考虑UI支持.数据库内容的支持 3. 迭代过程,并非一次就实现所有需求 迭代生命周期方法的关键理解:

CISSP AIO 2th: Information Security Governance and Risk Management

2.11 Security Steering Committee(安全指导委员会) A security steering committee is responsible for making decisions on tactical and strategic security issues within the enterprise as a whole and should not be tied to one or more business units. The group sho

16--论信息系统项目的范围管理

摘要 2013 年 8 月,笔者作为项目经理参与XX省电子政务网一期工程的建设工作.作为该单位的重点战略项目,该项目总投资为3200万人民币,项目周期为26个月,共有7个单位参与建设.该项目采用 B/S 结构,系统基于ORACLE数据库的JAVA/JAVA EE多层体系结构,以LINUX为主的作为操作系统, 应用面向对象设计.面向服务(SOA).面向接口技术.组件式开发技术,采用MVC.ORM.Web Service.AJAX技术. 该项目按照统一组织领导.统一规划建设.统一数据标准.统一外网平