敏捷是一个很流行的一个词语，但是在敏捷里面，包括很多团队也是刚开始用Scrum，怎么让质量成为敏捷的一个助力而不是拖累，这个是我主要想谈的。
关于质量的定义，我前不久接触到一个文章，里面有一个图讲到质量的五个维度，但是我做了一些微调，改成了四个。接下来就从我定义的4个维度的质量分别探讨一下。
1. 基于价值的质量，交付影响而不是交付产品
在IT业有一个很著名的人叫做 温伯格 的咨询师， 他提到质量的定义叫做质量是对某些人的价值，价值是什么意思？
福特问客户想要什么，他说要一匹更快的马，但是福特提供给了客户汽车。马和汽车是提供给客户的产品，价值是什么？客户可能有天天从各个城市飞来飞去需求，他希望有更快的马来助力，这个就是价值的意思。客户的需求往往是方案，它很少告诉你这个东西背后是什么目的。所以User Story的背后，就是价值。
在工作上，我认为我们不是在交付产品，而是是交付影响力，就是交付对用户的影响。你让我开发一匹更加的马，我要问这个马用来干什么，对你有什么影响，因为我交付的是影响而不是产品。
Impact Mapping通过 Why Who How What得到一些想法：我们做产品是为了什么？影响哪些人？
-如果说一个咖啡馆老板，他想赚一个亿，谁能帮助他达成这个目标？
-如果说顾客可以帮助他达成这个目标，那怎么帮助他达成？
比如顾客（who）买了咖啡之后，觉得不错然后会推荐给其他朋友（how），所以顾客通过把咖啡店推荐给好友的行为可以帮助他赚到一个亿（why）的小目标，但是需要注意的是，这个"who"可以很多。
有了前面的铺垫后就能得到"what"
为了鼓励顾客去推荐好友这个行为，我可能会开发一个“推荐赚积分积分换咖啡”（what）的功能系统。我们开发Story不是Story本身，产品本身不是我们直接的目标，我们的目标其实是为了影响“顾客去推荐好友”这样一个行为，这个影响，最终达到业务目标，就是这个why。
我们跟产品合作，他们给我们做了一次what，他会说你给我做一个积分换咖啡的功能，其实背后这些功能会带来什么样的价值，才是更需要探讨的。但是这样的思想框架并不是真的去问why 、who等等，而是告诉我们真正需要交付的东西，而不是真正的产品。所以说提出一个可能符合背后目标的更好的what出来，这才是框架的一个根本目的。
2. 基于产品的质量，利用反馈
例如，我们要研发更快的马，或者研发一辆汽车，这个就是产品本身，定下来仍然有质量因素在里面，就是怎么把东西做对。
Cynefin模型：
simple ：你要解决问题很简单，你有一些最佳实践套用就可以了，如果你的公司，你的研发在这个象限上，其实是恭喜你，其实是非常舒服的
complicated ：比较繁杂的场景，这个场景下你的解决方案可能有多个，可能不存在最佳实践，又或者可能有多个实践，可能找几个专家来帮你搞定，这个是一个场景
complex ：没有办法简单找几个专家来研究得出结论，这个应付的东西是各个维度，有可能是质量出问题，加上预算有限，加上产品方向不清，需求不清，产品跟架构师之间合作不来，各种交织在一起，但是有一个目标需要推进。
chaotic ：就是混乱，如果碰到这种，这个挑战确实是非常大，可能不是一般的管理者能够应付得了，需要CXO坐在一起给出方向。
disorder ：管理者把解决问题分解成多个子领域，分解成多各个情境来逐个击破。
产品研发大部分属于第二和第三象限，这两个维度的实现就是先做，然后再反馈。反馈有一个原理：越早的反馈越便宜。
举个例子
在产品研发中，有一个很大的问题，就是你的技术团队和产品经理的鸿沟。这个鸿沟很常见，但是在我自己的工作场景里面这个鸿沟不常见，我一直是技术领域的人，但是我在产品上或者需求上跟产品经理一直是通力协作的，用实时的反馈来跨越反馈，而不要等产品经理已经设计了两个月，然后给我们开发完上线后，再提出需求不对，这样就比较被动。