更多相关文章阅读
其他
臺灣敏捷老專家：如何建立一个需求落点分析模型？
【目的】
提供团队在开发完一个 Sprint 的增量后针对需求的价值给出反馈，让工程师有机会就自己刚刚完成的任务有发表意见的机会，同时运用专家的视角将反馈传达给产品经理。
【步骤】
首先：在便利贴上画一个2*2的矩阵，垂直轴是对市场的差异化影响的大小，水平轴表示我们做的任务的关键性。
接着：让团队成员对刚完成 Sprint 的用户故事的落点进行评估。
团队在进行评估时，务必再说明一回各象限的意义，让点评更明确些
该怎么点评呢？
差异化活动
右上角的方框是用来表示我们完成的这些用户故事，它对市场差异性是有所帮助的任务，如上图的 U1 及 U2。
校验活动
右下角是指我们完成的任务仅仅是用来追上目前市场的水平，也就是市场上其他品牌基本上都已经有的功能，一般新的产品通常都要向已有产品靠齐，但如果花太多功夫在这个方框中，产品是不会有更大的成长的，反过来应该做适当的资源分配，多朝右上方的方块靠拢才是比较具有价值的用户故事。
合作伙伴活动
左上角是指如呼叫后台的 API 或是其他厂商所提供的支援 API 等，算是合作伙伴共同完成的任务，但这对产品的差异性是有帮租的，虽然不是自己做，但却也有一定的价值。
无用的活动
左下角，指的是我们做了一些对产品在市场差异化上完全没有帮助的功能。
基于目的的对准模型
图一、依据 Kent J. McDonald的Purpose-base Alignment Model 所改良的需求落点分析模型（注1，上面红色说明是依据 Kent 所发表的白皮书所加上的，黑色字体则是是 Niel Nickolaisen 原著的翻译)
上面二位作者的宗旨都是针对项目尚未开始时所设计用来【理解情境】用的模式，因此称之为“基于目的的对准模型”，下面则是我把程序反过来，拿来用在工程师开发完成需求后的落点评估说明。
为什么要工程师来评比呢？
因为刚刚完成任务的工程师，正是对该功能最熟悉的专家，他可以用最专业的立场来看它的价值，虽然主观了一点，但这不正是专家的意见吗？
下图说明，工程师在接到开发任务之前对所要完成的功能及相关信息是全然无知的（中间蓝色点线）必须透过持续的摸索与学习，在无数次的尝试失败之后，才能累计完成工作的足够技能，然后才能把工作完成（绿色点线为 PO 的认知，我们的目的正是将蓝线在顶峰的知识反馈传达给 PO）
图二、开发人员对需求了解的时间曲线
如上图的【红点】，是在描述在开发工作中我们持续学习相关新知识并把它们转化成实际技能的模式，这时候我们总会认为除了自己之外再没有一个人能比我们更了解这段代码了，此时我们达到了一种专业的领域，一种将需求转化成可工作软件的境界，而【需求落点分析模型】正是要在你成为领域专家时对需求进行评比的工具，原因是这个时候你具有最专业的视野，正是可以对所完成的需求进行反馈的最好时机，回顾会议似乎是一个好时机点，这个简单的模型是这样进行的;
范例：
假设这个 Sprint 完成了7个用户故事，Scrum Master 可以在回顾会议时首先把需求落点模型的图示画在白板上并加以简单说明，接着要求团队就刚刚完成的工作以他们自己的认知将便利贴贴在四个象限内，然后由 Scrum Master 收齐，交给 PO 做参考用。
实际运作时一个工程师的选择结果
说明：
1、在差异化活动里有 U1，U2，U5： 这是有意义的需求开发工作，越多越好！
2、在校验活动里有 U3，U4：我们正在追上市场的基本水平中，团队虽然忙碌但距离市场期望越来越近了。
3、在合作伙伴活动里有 U6：有协同合作的机会，交互配合度的好坏可以拿出来分享
4、在无用的活动里有一个 U7：这表示团队成员认为 U7是一个无意义的需求工作，平白耗费了工程师的资源。
上面这一张落点图示，是以一个人为标准一次点评完所有的用户故事，适合在 Review 会议后进行，另一种方式则是一次一个用户故事被所有人点评，团队每个人依序轮流点评，这种方式会进行得更快速但不适合较大的团队采用，优点是不需要事后再做统计的工作 。
PO 若有感兴趣的地方（例如发现团队跟自己的认知有差距时），可以再与团队进行沟通，而这种直接来自专家的反馈，可以提供 PO 做需求排序时的参考，当然有必要时更可以作为进一步沟通的依据。
需求落点模型可以让 PO 与团队开发成员，通过反馈的方式交换彼此的意见，并藉以提升二者对需求的共同认知。
专家有话说：
上文介绍的需求落点分析模型是让开发团队持续反馈成熟产品认知给 PO 的一个工具模型。
这种鼓励开发团队更多地反思产品设计，同步和 PO 认知的做法很值得借鉴。
基于以上模型，我认为针对不同的团队以及场景，实施方式还可以更灵活：
1、实施时机：文中基于需求理解时间曲线和 PO 需要获得团队最专业的反馈需求，把该活动放在回顾阶段进行。我以为在短迭代开发的前提下，以激励团队在前期更多地参与产品设计、达到团队共创为目的，我们可以在迭代计划阶段就来做这件事，促进团队对产品的参与度、理解度、在开发之前与 PO 达成一致以便更好的承诺，在开发过程中如果有进一步的认知，在回顾活动中可以再一次更新该模型，这样是不是一定程度上可以避免真正的 U7 类用户故事被实现，浪费了资源呢？
2、反馈内容：我们可以根据不同的产品形态，团队状态，以及产品阶段等场景通过调整纵轴的维度，来收集更适用的团队反馈。例如，针对有些产品的开发团队缺乏对市场认知的情况下，我们可以把收集维度按照团队能够提供的输出进行其他定制（可用性、用户价值等）
本期专家：
刘宏
资深敏捷教练，CSM/ACP，超10年敏捷与项目管理经验，精益看板与Scrum专家。
炫酷实用的 DevOps 仪表盘，你值得拥有的交付流水线信息整合工具
实现敏捷框架的比较：Scrum 方法 vs 看板方法 vs 精益开发 vs 极限编程