本文主要是介绍PMI-ACP认证考试学习笔记(二),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
PMI-ACP认证考试学习笔记(二)
价值驱动交付
在一个敏捷项目里,交付价值驱动着项目中的行为和决策。对于敏捷团队来说,关注交付价值的最大化是一个永恒的主题。
敏捷方法推崇尽早地交付价值。这就意味着团队更注重于尽快交付项目当中价值最高的部分。
价值驱动交付就是对项目中排列有附加价值的活动与减小风险的活动之前的优先级做选择,然后按照这个优先级执行。
价值优先级
敏捷团队通常使用优先级的方法来确认他们正在交付的价值。在每一个迭代结束的时候,团队都会和客户在一起评审待开发项,来确定下一个迭代需要改变哪些事情,以及下一个迭代应该做哪些需求。
在两个迭代之间,可以重新对优先级进行排序,并在下一个迭代中规划相关工作。
基于不同的敏捷方法,客户价值的优先级方案会有基本类似的方式。而术语经常发生变化,例如:
- Scrum 中的 Product Backlog
- FDD中的 功能性列表
- DSDM中的 基于优先级的需求列表
其实意思都是一样的。
项目的工作可以通过优先级的列表识别客户所需的价值。
MoSCoW方法
MoSCoW优先级方案是在DSDM里使用的。
一般在迭代计划会上使用MoSCoW方法进行这种排序,将要Sprint Backlog中的条目分为四级(其实只有前3级):
- Must:必须做的;
- Shoud:应该做的;
- Could:可以做的;
- Would not:不要做的。
要按照这些顺序来做,保证Product Owner所需要的Must、Should完成,并力争Could能完成;在发生重要变更的时候,牺牲Could乃至Should保证变更。
- “必须做的”要求或特性是系统的基础;没有它们,系统就不工作或没有价值。
- “应该做的”得特点是:应该先有它们,这样系统才能正常工作;如果它们不存在,那么解决方法可能会是昂贵的或者是非常麻烦的。
- “可以做的”的特点是:提供了产品的附加价值,可以让产品更具有亮点;
- “不要做的”的特点是:在这个产品中肯定没有的功能。
KANO模型分析法
KANO模型分析法是授野纪昭基于KANO模型对顾客需求的细分原理,开发的一套结构型问卷和分析方法。
KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品性能和用户满意之间的非线性关系。
https://baike.baidu.com/item/KANO%20%E6%A8%A1%E5%9E%8B/19907824?fr=aladdin#5
受行为科学家赫兹伯格的双因素理论的启发,东京理工大学教授狩野纪昭(Noriaki Kano)和他的同事Fumio Takahashi于1979年10月发表了《质量的保健因素和激励因素》(Motivator and Hygiene Factor in Quality)一文,第一次将满意与不满意标准引人质量管理领域,并于1982年日本质量管理大会第12届年会上宣读了《魅力质量与必备质量》﹙Attractive Quality and Must-be Quality﹚的研究报告。
KANO模型定义了三个层次的顾客需求:基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。
KANO模型是一个典型的定性分析模型,KANO模型分析法并一般不直接用来测量用户的满意程度,主要用于识别用户对新功能的接受度,帮助企业了解不同层次的用户需求,找出顾客和企业的接触点,识别使顾客满意的至关重要的因素。
KANO模型的属性分类
在卡诺模型中,将产品功能/需求和服务的特性分为五种属性:必备属性、期望属性、魅力属性、无差异属性、反向属性。
(1)魅力属性:用户意想不到的,如果不提供此需求,用户满意度不会降低,但当提供此需求,用户满意度会有很大提升;
(2)期望属性:当提供此需求,用户满意度会提升,当不提供此需求,用户满意度会降低;
(3)必备属性:当优化此需求,用户满意度不会提升,当不提供此需求,用户满意度会大幅降低;
(4)无差异属性:无论提供或不提供此需求,用户满意度都不会有改变,用户根本不在意;
(5)反向属性:用户根本都没有此需求,提供后用户满意度反而会下降
我们做产品设计时,需要尽量避免无差异属性、反向属性,至少做好必要属性、一维属性,努力做魅力属性。
根据KANO模型进行用户需求分类
根据KANO模型,我将其属性分类与用户需求优先级进行对应,便于实际应用,主要定义了三种:
- 基本型需求(必备属性)
- 期望型需求(期望属性)
- 兴奋型需求(魅力属性)
这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。
MVP(Minimum Viable Product)
敏捷MVP是三个术语的集合,每个术语具有重要意义:
- 最少(minimum):表示它使用最少和最简单的功能交付。
- 可行(Viable):提供客户价值并提高客户满意度,收集客户反馈。
- 产品(Product):最终产品。
敏捷最低可行产品是交付客户价值的敏捷项目管理的最小单位。 分析从最低可行产品(MVP)收集的敏锐度比开发具有成熟功能的产品要便宜,因为直接开发具有成熟功能的产品而不进行任何分析会由于不正确的假设而增加涉及的风险和成本。 敏捷MVP是一个迭代过程,它基于从连续反馈中积累的数据。 最低可行产品基于关键功能,例如最少的功能集,客户反馈和最少的工作量。
MVP可以定义为您打算在当前市场情况下测试的最终产品的最小形式或原型。在这种开发策略的帮助下,您(以及您的开发团队)将能够使有关该产品的某些假设无效或生效,从而了解您的主要受众对该产品的特性和功能的反应。
通过使用这种方法,您不仅可以深入了解产品的未来,还可以适当地分配总预算,从而实现业务的最终目标。简而言之,您可以将MVP描述为一个反复持续的过程,在该过程中,您可以确定用户的痛点,并通过随时间推移实施这些更改来最终确定产品的适当功能。
MVP的开发遵循严格的措施和学习策略,随着您和您的团队不断了解用户的需求和要求,这将帮助您发布可以随时改进的产品。这样的立场将帮助您更好地为客户服务。
详细的内容,请看我的另外一篇博文:[敏捷开发培训] 构建Agile MVP
增量交付
敏捷开发的基石是“增量交付”。增量交付是指为及时反馈和接纳,频繁向客户交付连续改善的工作产品。为演示和反馈,往往在每一个冲刺或迭代的末期交付产品。频繁反馈可使客户评价产品并提出新的需求。在敏捷流程中,接受变动/更新/改善的需求,以确保客户得到有价值和质量的产品。一个冲刺或迭代往往历时2-4 周,交付一个新的并逐步完善的产品。
提供客户价值涉及的3个重要的话题
- 聚焦创新而不是效率和优化
- 专注于执行
- 精益思想
这篇关于PMI-ACP认证考试学习笔记(二)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!