ACP概念解析

一、Kano

在《敏捷估计和规划》一书中，在确定合意性优先级一章中专门介绍了这个模型，这个模型可以作为我们确定需求优先级的一个参考。KANO模型定义了三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。

客户满意性模型KANO

1. 基本型需求：顾客认为产品“必须有”的属性或功能。当其特性不充足时，顾客很不满意；当其特性充足时，对客户满意度没有多少影响，顾客充其量是满意。例如只要酒店浴室满足了我的基本需要，我并不会关心洗漱台的台面是用什么材料制作的。
2. 期望型需求：要求提供的产品或服务比较优秀，但并不是“必须”的产品属性，有些期望型需求连顾客都不太清楚，但是是他们却希望得到 的。顾客通常谈论的是期望型需求，期望型需求又叫做线性需求，这类需求越多越好。线性需求在产品中实现的越多，顾客就越满意，当没有满意这些需求时，顾客 就不满意。因此，产品的价格通常和线性特性相关。如果酒店有健身器材，我会更加高兴，相比没有这类器材的酒店，我下次可能就会在此入住这里。
3. 兴奋型需求：提供给顾客一些完全出乎意料的产品属性，使顾客产生惊喜。兴奋点和惊喜点常常是一些未被用户了解的需求，客户在看到这 些功能之前并不知道自己需要它们。当其特性不充足时，并且是无关紧要的特性，则顾客无所谓，当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从 而提高顾客的忠诚度。这类需求可以为产品增加额外价格。

评估需求类型

在应用这个模型时，需要注意随着时间的发展，功能会在模型中向下移动。例如手机彩屏以前是期望的，而已经是必须的。所以需求的正确归类非常重 要。使用Kano模型最简单的方法就是考虑每个主题或故事，对它所属的类型进行讨论。我们可以设计一套问卷，对用户进行问卷调查。Kano建议通过对一个 功能问两个问题来确定分类：一个问题是如果产品中有这个功能，用户会觉得如何；另一个问题就是如果功能不存在，用户又是觉得如何。对每个问题采用5点的度 量方式进行回答：

1. 我希望这样
2. 我预期这样
3. 我没有意见
4. 我可以忍受这样
5. 我不希望这样

经过调查后根据下图的归类矩阵，将问题进行归类来确定需求的类型

 

Kano模型分析

这3种不同类型如下图所示：

 

由图可以看出，

• 右下方箭头：一旦实现了一定数量的必须功能，就无法再通过增加这类功能来提高客户的满意度了。无论增加多少必须功能，客户满意度都不会超过中点以上。
• 左上方箭头：只是实现一部分兴奋点就可以明显的提升客户满意度，这也是为什么企业把追求卓越作为企业的价值观之一
• 中间的箭头：期望型功能的增加和客户满意度呈线性增长，所以这类需求越多越好

通过以上分析，我们会对这三类需求分别对待：

1. 对于必须完成的功能，在产品发布时需要完成，但并不是要求在第一次迭代时就开发完成。
2. 完成尽可能多的线性需求
3. 如果时间允许，至少应该确定少量的兴奋点优先级，把它们包含进发布计划

二、SMART

smart是目标原则。

 

三、INVEST

INVEST是用户故事的原则。但是要注意大小写混合时，认不出来。

四、WIP

参考链接：https://www.jianshu.com/p/3e2ccd0e58cc

什么是WIP限制

在敏捷开发中，WIP限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中的工件数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队在持续交付通道中的瓶颈是非常容易辨别的。

为什么说WIP限制很重要？

WIP限制通过强制让团队聚焦在更小的一套任务中来改善吞吐量和减少“将要完成”的工作量。从根本上来讲，WIP限制鼓励的是“完成”的文化。更重要的是，WIP限制可以让阻碍和瓶颈显而易见。当有明确指示现有工作遇到瓶颈时，团队可以聚焦在阻塞问题上尽快的理解、实施和解决。一旦消除阻塞，团队中的工作将再次开始流动。这些优势可以确保在最短的时间内向用户交付有价值的增量，从而使得WIP限制成为敏捷开发中一个非常有价值的工具。

“此外，多任务处理只是看似时间安排紧密。”

开发期间，大家很容易会想“当我开始另一项工作的时候，我会暂停这项工作”。同时打开两个问题意味着在两个事务之间前后切换或者在团队成员之间转移工作。降低一件事的投入加大另一件事的投入并不意味着自由-因为它会花费时间并且削弱焦点。解决一件原始问题总是好过开始并且未完成一项新工作。换句话说，WIP限制防止我们阻碍自己的流。

最后，WIP限制指出了长期闲置或过载的区域。它们帮助团队看到整个流程中的低效事件而不仅仅是某些特定区域。

专家提示：

对于刚刚使用WIP限制的团队，会觉得并不方便。只需要花点时间在最开始的几次迭代中进行讨论。了解团队何时以及为何达到了WIP限制。起初，要抵制随意调整WIP限制的诱惑。如果违规行为接连不断，那就表明WIP的限制过于严格或者团队的流程效率太低。

在敏捷团队中使用WIP限制

现在你已经认可它们的价值了，那我们回归实际问题。

每当铺开一条新的工作流时，团队都要判断并决定每种情况下的WIP限制。我们建议在监控几次迭代确定每种情况下平均数量的工作项后再设置WIP限制。

 

敏捷团队使用WIP限制的4个目标

与任何新活动一样，WIP限制最初使用起来比较尴尬。而WIP限制的目标是在中期使团队达到最优状态，所以短期的尴尬实际上是好事。它会迫使团队触碰到他们流程中的一些痛点。

团队在使用WIP 限制几周后，就可以根据需要进行调整。正因为团队一直在受挫，因此可以抵制调高WIP限制的诱惑。而且还能抓住机会，提高团队整体能力-理论上，可以通过教育团队让每个成员获得新技能或在某些方面提高开发过程的效率。

 

 

目标1：不断调整单个任务的大小

在分解需求和用户故事时，保证单个任务的工作量不超过16个小时是非常重要的。这么不仅可以提高团队确切预估的能力，还能有避免瓶颈。没有什么能比大工作项阻塞通道更能降低团队速度加剧WIP限制了。

目标2：将WIP限制规划为团队的技能

上面的例子是假设团队成员的技术能力相似。如果你的团队有技术专家，那么当专家牵涉其中时WIP限制应该有所不同。这个时候需要创建特定于专家工作的状态。如果在该状态下出现瓶颈，正好可以趁机让团队其他成员学习一些额外的专家具备的技能，以此来增强整个团队的流。

目标3：减少闲置

当一个团队成员出现停工期的时候，鼓励他们去帮助上游或下游团队成员。他们不仅能为团队的整体生产力做出贡献，还可以在此过程中学到一些东西。

目标4：保护一种可持续工程文化

WIP限制并不意味着开发人员需要急于工作以避免某些情况下工作过载。它旨在保护以保证产品质量和代码库健康为前提的扎实的敏捷工作实践。