敏捷开发中如何作质量管理？

蔡建斌 -国际物流公司亚洲 IT 交付团队经理

导语

敏捷是一个很流行的一个词语，可是在敏捷里面，包括不少团队也是刚开始用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 ：管理者把解决问题分解成多个子领域，分解成多各个情境来逐个击破。

产品研发大部分属于第二和第三象限，这两个维度的实现就是先作，而后再反馈。反馈有一个原理：越早的反馈越便宜。

举个例子

在产品研发中，有一个很大的问题，就是你的技术团队和产品经理的鸿沟。这个鸿沟很常见，可是在我本身的工做场景里面这个鸿沟不常见，我一直是技术领域的人，可是我在产品上或者需求上跟产品经理一直是通力协做的，用实时的反馈来跨越反馈，而不要等产品经理已经设计了两个月，而后给咱们开发完上线后，再提出需求不对，这样就比较被动。

若是反馈能作到实时，下面就是实践。在新的产品研发开始的时候，我与技术人员产品经理会一块儿先把概念模型画下来，由于一个团队有不少的角色，包括架构师、开发、US、甚至外包人员，不一样的角色怎么确保理解的一致，最后明白如何作本身的工做。你怎么确保这份活动基于统一的理解，没有共识就比较容易出现鸿沟。把概念模型画下来就是为了现实上的例子，能够很简单，咱们有什么业务对象，他们之间关系是什么样，把这些东西画下来，你们基于一份共识去作各自的活，这个鸿沟会少一点。

3. 基于产出的质量，定义完成，以终为始

我本身是研发出身,研发质量产出是什么？就是须要创建条目化，短周期以内能够交付的东西，这个是产出，第一个产出是代码，尤为在软件行业，代码占了80%的产出，怎么把代码写对，就是第三个维度。

代码质量有一个心法叫作定义完成；

举个例子，不少程序员你问他这个Story作了没有，他给你的答案是什么？度量BUG是为零，程序员作完以后交给QA，QA告诉开发有没有BUG。你的QA下一道工序是个人客户，我应该告诉你有没有BUG或者有多少个BUG，而不是反过来。

需求质量也是很重要的产出；

你要保证你的产品经理作的需求是否是符合，是否是条目化，是否是按照优先级，你是否是作最重要的事情。你有三个团队，每一个团队都在按照优先级来作事，可是三个团队是否是有统一的优先级，不少团队是没有作到的。

有些需求你不作用户会不高兴，可是你作了也不会很高兴，就像咱们的实践同样，项目大的时候不作实践会很惨，可是作了项目也不必定会成功。

工做中当你问程序员说这个作完没有，不少程序员告诉你90%完成，或者完成了可是没有测，或者有几个BUG，或者须要重构一下，这种心态是很差的，可是没有反馈。

咱们叫作以终为始，用户故事只有两种状态，只有完成和没有完成，没有可是，没有完成你要把它完成掉。程序员会说这个作了90%，而后去作下一个故事，结果是没有一个能够工做。而咱们倡导的是把一件事情所有作完，才作下一个。

4. 过程质量，拆

有这样一句话，若是你用一样的方式去烤面包只会获得相同的面包。

过程质量就是写代码的质量，这个心法就是拆，拆成小的东西，拆成一个可交付的东西，其实写代码也是须要拆的。

举一个例子，不少程序员写代码，一天下班的时候代码尚未编译，咱们写代码方式应该是这样,不少程序员写代码是东写一点，西写一点，这个意味着什么？没有透明度，他不知道写哪个，这样的过程想代码质量好是不可能的。

总结

咱们已经讲了四个维度的质量，价值和成本，可不少团队的人没有办法控制价值的部分，有些人却能够。咱们是一个技术负责人，产品都不是咱们能控制的。你要考虑定制权在哪里？影响权在哪里？你能控制的东西就是你的成本，你不能控制的地方就是你不能提供的。

谁为质量负责?若是开发工程和QA之间出现问题，最后辛苦开发出来的功能，用户抱怨难用，就是价值和质量出现了问题，如今分工愈来愈细，在不少团队集中在某一层，好比程序员关心写代码，不关心价值和产品，产品经理只关心价值，不关心技术实现，这些鸿沟会影响整个质量。

文章来源：Worktile敏捷博客

欢迎访问交流更多关于技术及协做的问题。

文章转载请注明出处。