用UDDD破解软件开发的三大魔咒

［按：本文内容，改编于我于2016年3月16日在简寻公司所做的同名微课的语音文字材料。感谢简寻公司的小妹将我的微信语音，转换为以下文字，供我修改，帮我了却半年以来想向各位匠友详解之前的VRD工作坊（本文所描述的UDDD的前身就是VRD）步骤的心愿。］

大家好，很高兴和在这个场合，跟大家一起聊聊怎样破解程序猿的三大魔咒。

因为今天时间有限所以我只能是把这个过程，蜻蜓点水般的讲一遍！大家有问题呢，我也会在群里头。大家随时可以继续提问！

大家因为都是用手机上或者是电脑上来看的话，一个屏幕可能不太方便，因为我还有一些ppt，比较好的方法就是找一个电脑，然后电脑上打开ppt。手机上就听我语音。

咱们之前的题目叫“用UXDD破解软件开发的魔咒”，但是我后来把UXDD改成了UDDD。因为我觉着UX(用户体验)的核心还是用户数据。还是基于用户数据的，所以我就把这个X改成了D。

大家可以看我简书上的PPT（http://www.jianshu.com/p/4fb58e08e934，如果微信图片看不清，可以点击“阅读原文”链接查看大图）。图片标了号的。这里面，咱们先看程序员三大魔咒吧！首先第一个，就是“三个需求变化就能够杀死程序员”。

因为我了解到咱们这个群里头的大部分人都是程序员。所以“需求的变化”对于程序员意味着什么，大家应该都很清楚。今天我讲的这个分享，我在以前都讲过很多次。我的风格就是，只讲落地的步骤，概念会在落地的过程中体现出来。

第1号图片有用红笔写的一些数字，1-11表示的是在后面的落地步骤中，从1到11步就能解决这个问题：“三个需求能杀死程序员”。再往下呢，就是画了三个红圈蓝圈是吧，这是什么意思呢？

这个图想表达的就是测试覆盖率悖论。有很多公司是要考核团队的测试覆盖率的。考核的一般就是看你生产代码的测试覆盖率情况。

红圈表示的是业务需求，蓝圈表示的是代码。在项目初期的时候，业务需求会不断地被识别出来，不断地扩大，不断地滚动。而代码会比较少。

随着项目进展，红圈也在不断的滚动，蓝圈的代码越来越多，理论上这两个圈应该是重合的，但实际上是不重合的。

有两个原因造成了不重合，第一个原因就是方言。就是需求、开发和测试人员他们各讲各的方言，所以理解会有偏差。第二个原因呢就是开发总会有滞后。所以等你开发完了，过几个月你发现市场需求也变了。所以这两个原因会造成蓝圈和红圈不会重合。

到了右边，比方说有一块代码，有一块业务需要变动了，希望增加一块业务，还需要砍掉一块业务。增加一块业务，蓝圈也会跟着增加代码，但是砍掉的业务一般来说程序员不会删掉原来的旧代码。旧代码还会在系统里面留着。因为他怕删旧代码，就把这个系统给搞挂了，所以一般这个垃圾代码不会删除。这就造成了，如果你真的利用生产代码的测试覆盖率进行指标考核的话，就会造成很多垃圾代码被测试覆盖到了。这是很大的浪费。

在下面我要讲的1-16步呢，是解决怎样识别红圈，相当于把业务识别出来并且使用自动化测试去覆盖。从20-22步这三个步骤，是用于去删除垃圾代码的。

咱们刚从上面讲到了两大魔咒，一个是三个需求杀死程序员，一个是不知道怎样安全的去删除垃圾代码，现在看下第三个魔咒，就是你的系统怎么去划分。

大家做开发一般都讲究做三层架构，最上面是表示层，中间是逻辑层，最下面是数据层。但是这样划分，其实还是一个大泥球，你看这图中间有三个红圈交叉在一起，每个红圈都代表着一个业务领域，比方说微信，有朋友圈、有红包、有聊天，这三个领域是不同的，如果你不按DDD（领域驱动设计）去划分的话，把它们写在这三层里面，他们还是杂乱在一起，所以造成了这个大泥球架构，所以这就加剧了上述第二个魔咒，不好去删除耦合度比较强的逻辑的垃圾代码。那么这第三个魔咒就是，怎么去切业务领域。

这是在后面的第12-14步来讲，咱们看看第2号图，一个三合一图，把软件开发的三个过程放到了一起，设计思维（Design Thinking），精益创业（Lean Startup），敏捷(Agile)放到了一起。这个图的目的是让大家知道咱们软件开发并不是敏捷这一块工作，之前还有很多事情，最开始呢得有从0到1 的设计思维，然后还得有精益创业过程。

这个图把软件开发切两刀，横着切是把具体跟抽象切开，竖着是把用户问题和解决方案切开。一般开发的起点，是从具体的用户问题开始，先去定义挑战，然后去观察人，去分析，然后再去看看有什么痛点，目标。然后看有什么解决方案，做试验。这些都是设计思维，即产品从0到1的过程。

有人会说那我现在的产品已经开发两年了，这个事情还有没有必要做？如果你的团队对你们的用户是什么样子的，痛点是什么，你们产品独特的竞争优势还不清楚的话，还是有那必要做的。

到了这个图的右边，有一个圆圈。左侧有三个过程的交汇点。咱们看这个绿色的圈，从做试验开始，往下走，先构建做试验的系统，然后度量指标是否符合期望，如果不符合期望就得转进，换一个方向去尝试。如果觉得靠谱的话，就继续进行迭代。所以这个绿色的精益创业和蓝色的敏捷，在构建的这一段是重合的。

这张图为什么放到这呢，因为是把后面大图浓缩了一下。我后面的 大图都能找到和这张图对应的地方。

现在进入重点，怎么去落地。落地过程看第3号图（第4号图是第3号图的文字解释及补充），从左上角看，有红蓝绿三个小人，分别写着DPT，D就是领域专家，P就是程序员，T就是测试工程师。后面讲的内容他们三者都要一起参与，而且要用相同的语言。

这三个角色，或者说团队所有人至始至终一起去参与UDDD过程很重要。一般常见的模式，业务、开发、测试是分开的，靠文档来沟通，这样效率是极低的。业务形成需求抛给开发，开发完了再丢给测试，看上去分工比较合理，但实际上，如果一个人不去在前期讨论阶段就参与一件事情，那么他对于这件事的积极性是不会被调动出来的。

就好比开会，中国人一般不会在会上讨论，而只是在会上表决某件事，因为事先在开会前，该讨论的都已经讨论好了。如果把开发比做开会的话，同样的道理，应该提前让开发参与进来，发布产品前让这几个角色一起来讨论，让他们有参与感，这样积极性才高。

我并不是去抹杀分工，分工是有必要的，因为术业有专攻。但讨论要在一起，比如说让程序员参与用户访谈的过程，会提高开发和测试人员的积极性，同时也省去了写文档和读文档进行知识传递的时间，能让他们把本职工作和产品整体做得更好。

咱们开始看第三张图的第1个步骤“猜测、假说和目标客户信息”，这里有三个单词，猜测(ASSUMPTIONS)、假说(PROBLEM HYPOTHESIS)，目标客户信息(TARGET CUSTOMER PROFILE)。这三步应该是在开始的时候去定义的，我解释一下，猜测就是没有任何的事实依据，假说就是你根据某些事实依据得出一些结论或假设。之所以做这个事，是因为咱们的产品都是基于一个假设，比如举个猜测的例子，“用户有难以在微信朋友圈发现有用信息的问题”，这句话就可以作为一个猜测。假说是比较详细的，把时间、地点、人物、问题描述的更加清楚，我认为它是猜测的细化版。

有了这两条之后，你就可以往下去印证你之后的一个猜测是不是对的，这样说起来，咱们开发团队所做的猜测和假说都有可能是错的，这需要在之后去进行不断验证并进行调整，2号图里有个转进就是这个意思。

转进是很重要的一个概念，发现了不对，就需要快速调整方向。

目标客户的信息怎么去确定？有些团队发现很难去定义客户的特点，我最近读了一本书《精益客户开发》，这本书会教你，如何去通过定位特征的范围去引导你。特征范围就是找两个极端的特征，比方说 目标用户是对钱在意还是时间在意；诸如此类，你可以找到这种两级范围，然后让团队成员来讨论到底属于哪一种，通过这种引导性的问题，去帮公司更好的确定目标客户。

第2步是“用户现场体验”，我画了两个小人，左边是站着的，右边是坐着用电脑的，这就是说咱们需要去客户那做客户访谈或者说是用户现场体验。我觉得这一步是很关键的一步，因为猜测和假设做好了，目标用户也大致确定了，但是没有经过印证，所以必须得去客户那印证一下。跟看病是一样的 ，得先跟客户确认病症，才能对症下药。为什么你对用户的病症把握不准，会导致需求一直在变呢？因为你在猜嘛，你没有去做详细的用户访谈就拍脑袋想一个，很容易摇摆不定，所以就陷入了第一个魔咒。所以今天最关键的就是一定要团队一起把症状-用户的需求搞清楚，看这个怎么去落地。比如说8人团队，有3类人包括开发、测试、需求分析。可以把他们分成四组，去同时做用户现场体验。比方说可以根据前面确定的目标用户的特征，选择一些用户去访谈。建议你对每一种目标用户至少访谈3次，建议对一个迭代至少访谈五次以上。访谈时自己尽量不要说很多话，让用户去说，去描述他的行为。你尽量记原话，这才是用户数据。用户数据可以分为两个层面，一个是定量，一个是定性，定量比如说用户输入速度、登录速度提升2个点，定性就是去定义用户的痛点、喜好、期待和问题。今天主要分享定性的用户数据，定量的可以参考《精益数据分析》。定性注意在访谈时记用户原话、用户目标、完成事情的步骤，痛点就是不爽的点在哪里。另外还要记用户的特征，比如说年龄、职业等。

花半天做完用户现场体验回来之后，下午就可以做第3步“用户体验地图”（EXPERIENCE MAP）了。因为时间间隔久了会遗忘。这个过程就是去分析用户数据。分析的过程是这样子的，比如说把、还是这八个人，分成四组访谈了三次，回来之后一起去讨论，可以找张大白纸，用黄签往上贴用户原话、行为、痛点，一个便签只写一点，按时间发展顺序从左到右贴。边贴边念给其他人听，听的人发现如果和自己写的相近，可以贴在它的边上。这样就做好了分类。分完之后，可以在分好类的每堆黄色便签上面，分别贴一个绿色的签，并起一个名字，代表的是这堆黄色签所代表的任务。之后再把绿色的便签也做分组，每一组再贴一个蓝色的便签，并起一个名字，代表行为。其好处就是便于整理汇报，领导可以直接看上面的绿签和蓝签，程序员可以看细节的黄签，左边UA(User Attributes)代表了用户信息，比如特点、职业、性别可以写在这个地方。

讨论的时候也可能发现一些设计的想法和问题，橙色贴想法，红色贴问题。红色签能提醒你下次继续访谈把问题弄清楚。

接下来就是要贴点投票选出最大的痛点，即第4步“用户痛点”（PAIN POINTS）。具体做法是让大家每人拿5个小圆点，选出你认为的最大痛点的黄签，然后在这些黄签上贴圆点进行投票。可以5个圆点都贴在一个黄签上，也可以分开贴。都贴完后，数各个被贴圆点的黄签所贴圆点个数，按点数排序，找出最大的那个痛点，记下来进入第四步-用户痛点。痛点这个表就相当于给你排了接下来解决问题的优先级，把痛点反过来表述，就成为你下一步工作的目标。

这就进入了第5步“产品目标”（GOALS），这里写了一句“BIGGEST IMPACT”，表示“最大影响”。意思就是要从商业角度，从这些目标中，选出能为产品或生意带来最大“影响”的目标。即最大的痛点不一定是能给公司生意造成最大的影响的。这个时候就要权衡一下，找到能给生意造成最大影响的点。

说完了第5步确定产品迭代的目标，下一步第6步就是建立“用户画像”(PERSONAS)，给目标用户起个名字，找个照片，添加一下属性，让画像可视化。之所以要做用户画像，是因为它能保证产品涉及的用户交互的风格和用户画像所描述的风格是一样的。因为不同种类的用户的使用习惯是不一样的，如果不加区分，完全兼顾所有用户的习惯，会导致产品风格比较混乱且不统一。所以用户画像的目的就是让用户交互是根据一、两个用户风格来确定的，让产品更加专注一致。另外一个好处就是，可以拿用户画像的名字去指代用户，会比“一般用户”之类称呼更直接，更具引导意义。用户画像可以用用户数据来支持，比如说可以从公司的市场、销售、客户服务等部门，或第三方数据平台找到一些资料，来验证你的用户画像的猜测是不是对的。

第7步“创意思维”（IDEATION），图上有一些山和一个箭头，意味我们一般只按照既定计划来开发，这有可能会陷入一个局部优化的陷阱。即可能还有更好的方案，但我们还没有去尝试。所以创意思维可以比较好的弥补这一点。比如说八个人，可以去做一个工作坊，首先每个人各自分头写自己的解决方案，来避免在口头集体讨论的头脑风暴中，出现嗓门大的人让不爱讲话的人不敢表达自己想法的问题。然后每个人轮流面向大家表达自己的想法；之后再两人一组分头讨论，并各自形成一个方案；然后再每个组轮流面向大家去分享各自的方案。相当于是第一轮每个人想，第二轮是每两个人一起想。最后大家投票选择最好的方案，去指导今后的工作。

第8步"用户场景"（SCENARIOS）和第9步“故事板”（STORY BOARD）。就是把创意方案落地。第8步用户场景，就是按照前面“创意思维”所讨论的方案，写出用户达成其目标所经过的步骤。

接下来再去把上述用户场景中的各个步骤，请团队中的一两个会画画的同事，画成一个故事版。所谓故事版就是把“用户场景”的文字画成图，像连环漫画那种。为什么要把文字换成图呢？这是借鉴电影行业，便于导演和制片人去把握整个拍摄内容和方式。软件开发也类似，界面需要考虑用户的交互，画出来之后会比较便于向公司高层汇报，并便于程序员和测试工程师去估算接下来的工作量。我以前参加过敏捷的开发，有时候在迭代计划会议时，发现很难估算工作量。我觉得主要是因为缺少像“故事板”和下面将要讲到的“纸面原型”这些可视化的工具的辅助，造成对具体要做的那些工作内容比较模糊，难以估算。这里需要注意一下，故事版不是画界面，而是画用户与系统的交互，画操作步骤。

画完故事板，就能比较方便地过渡到第10步“纸面原型设计”（PAPER PROTOTYPE DESIGN）。把故事版做出一个原型出来。做原型可以用PhotoShop等软件去画出高保真的，但这样做会带来一个问题，就是画得越好，就越可能会阻止用户提出一些建议，因为一方面用户看你辛苦画出的成果，不忍心让你再花大量时间去修改；另一方面他们所提出的改进意见，在当场也无法立即对高保真作品进行实时修改，所以用户索性也不提改进意见了。为了鼓励用户提出建议，最好是把原型做的越不像真的越好，推荐用纸笔剪刀胶水啥的去设计，去手绘在纸上画出屏幕，将一个方案中所涉及的用户界面，一个一个地按照用户操作顺序，给做出来。

接下来就可以到第11步“纸面原型的用户测试”（PAPER PROTOTYPE USER TESTING）。这一步就已经是迭代到了获取用户反馈的时候了。可以把之前在“用户现场体验”中拜访的用户请来进行可用性测试。可以请一位团队成员协助扮演系统，来根据用户的操作，给用户展示纸面原型的界面。而你在这个过程中，跟用户去介绍系统功能并获取反馈。此时可以根据用户的建议，现场直接用纸、剪刀和胶水来立即修改纸面原型，这会比用软件原型工具进行修改要快很多。如果用户和你交互完并表示认可了，那么就算是把需求搞明白了，可以解决第一个魔咒了。此时需求就不那么容易被反复修改了。

接下来再看第12步“事件风暴”（EVENT STROMING），这主要是解决第三个魔咒，即怎样去拆分系统。可以看第5号事件风暴这个图。

此时用户的行为已经清楚了，可以让团队一起在白纸上画一个时间轴，请团队中最懂业务的成员，去贴第一个代表事件的黄色的签，并在签上写下事件的名字，如“已下订单”。事件表示“所发生的事情”。然后可以让业务/程序员/测试人员，来贴在这个事件之前所发生的其他事件，并按照事件发生的时间先后排好顺序。然后再贴这个事件之后所发生的事件。直到把团队认为所有要关注的事件都贴完了，而且是按照时间顺序排好序了，那么这一步就算完成了。就是识别领域事件。接下来要识别命令。既然事件是已经发生的事情，那么肯定这个事件是由某个命令触发的。所以需要在每个黄签下面，贴绿签，来表示触发它的命令。在每个绿签上写命令的名字。另外还要识别有没有依靠外部系统，比如银行。如果有，就在相应的黄签边上贴红签，并在上面写下这个事件所涉及的外部系统名字。最后就是聚集。意思是把根据高内聚、低耦合的原则，把关系比较紧密的事件放在一起，形成一个个聚集根，每个聚集贴一张蓝签，并在上面写下这个聚集的名字。聚集的好处就是能保证数据的完整性，要访问这个聚集里面的各个元素，都统一由聚集根来提供访问入口。

第13步“核心领域”（CORE DOMAIN），是将上述每一个聚集，都各自画一个圆圈来圈起来，这样就把系统按照领域给拆分了。我在这幅图里画了三个圈，写了U和D，U标识上游UPSTREAM，D标识下游DOWNSTREAM，直线表示这两个领域有上下游关系，这样就能把系统有效拆分开，解决第三个魔咒了。

接着往下，到第14步“故事地图”（STORY MAP），就开始指导你写代码了。可以先选择上述核心领域中的一个圈，来分析该领域的哪些功能要实现。可以先把前面制作的相关纸面原型放在故事地图的最上端，来引导你去思考：完成这些界面需要有哪些功能。此时可以先贴蓝色签，表示行为；再贴绿签，表示任务。这里的行为和任务，就是前面第3步用户体验地图里面的行为和任务。再往下再去贴黄色的签，来表示产品功能。你需要按照三个层次来贴：最小需求（MIN. REQ.，即产品能发布见用户的“内裤版”功能）、主要需求（MAJ. REQ.，即大部分用户都需要的功能）、锦上添花需求（NICE TO HAVE，即用空就做，没空拉倒的功能）。从而把优先级分开。还可以在边上贴代表痛点的红签，和代表输出和要度量数据的橙签，供人参考。

这一步之后就是第15步“测试问题引导”，我画了一个问号，表示你要去为上面“故事地图”中的每一个黄签来设计测试场景去做测试了。我在这里写了决策树（DECISION TREE）和定价类划分（EQUIVALENCE PARTITION）这两种帮助你做测试问题引导的方法。

接下来就是第16步“验收测试”（ACCEPTANCE TESTS）。你可以把上面每一个测试问题，写成GIVEN-WHEN-THEN的格式，GIVEN代表测试之前的准备条件，WHEN代表调用所要测试的行为，THEN代表验证这个行为的结果是否符合你的期望。

然后到17步“纸笔建模法”（PAPER-PEN MODELLING）就是开始为写代码做准备了。这是我自己琢磨出来一个方法。可以想象时光倒退100年，那时没有电脑。上面的验收测试中所涉及的所有数据，都不得不通过用纸和笔画表格记录下来。可以试着在这个表格上写几行数据，然后也是根据“高内聚、低耦合”的原则，把表中总是一起出现的列提取出来，形成一个类，并画出它与进行这个提取的类之间的关系。通过这种不断提取，去引导你到第18步“面向对象的模型”（OBJECT-ORIENTED MODEL），慢慢地把这个模型做出来。接下来到19～22步，都是TDD了，即测试行动开发。你从第18步建模出来的类，可以指导你去写测试代码。通过第19步设计(DESIGN)一些测试用例，到第20步编写验收测试代码(AC TEST CODE)和意图代码(INTENT CODE)，并以此在第21步中驱动出生产代码（PRODUCTION CODE），再回到第19步重构（REFACTOR），重构你的测试代码和生产代码。等重构完且生产代码相对稳定之后，如果发现验收测试运行较慢，可以再为生产代码补写一些单元测试代码，即进入第22步单元测试（UNIT TEST）。到这里似乎整个过程就结束了。但这个“结束”是画引号的。这里比较重要的，是第20步的验收测试代码，是用自然语言编写的，这意味着业务及测试人员都可以看懂。这样他们能帮程序员验证，哪些测试是没有用户价值的，是可以删掉的。如果我们的自动化测试，已经把第1号图中中间右侧那个表示当前有用户价值的业务的场景全覆盖了，那么就能够放心大胆的去删第20、21和22步中的垃圾代码了，这样就解决了我们的第二个魔咒。

第6号图表示了如何把UDDD这个过程应用到工作中。

这里有一个周一到周五的详细安排，比如周一上午各个小组各自去做用户现场体验，下午就可以做用户体验地图，去识别痛点和目标；周二上午可以做用户画像，下午可以做创意思维；周三可以做纸面原型；周四可以找目标用户做纸面原型的用户测试；周五可以事件风暴、领域划分和故事地图。这样安排呢，就差不多一周能把这个过程走一遍。我觉得，目前国内敏捷开发的迭代基本上就是两周一个迭代。在每个迭代前都应该花这段时间去收集和分析这些用户数据，从而能稳定你的需求，更安心的删除垃圾代码，高效的拆分系统。

问题1：8人团队是要完整开发团队吗？

这个八人团队一般是一个特性团队，它完成了一个产品特性（Feature）的端到端（即从用户数据搜集分析直到产品上线整个过程）的开发。这个团队也会不断去接一些新的产品特性。一般这样的团队规模根据亚马逊的两个披萨原则，比较好是在8人左右。

问题2：请问伍老师，形成故事地图及之前的步骤，一般是不是product owner的工作？

在理论上是由PO来负责。但在实际实施时，只由他一个人来做，我觉得是不好的。因为一个人的思路有限，另外也无法有效调动其他人的工作积极性。他可以引导大家，请大家作为帮手，去共同完成这件事。经过前期团队全员的充分讨论，还可以省去后面的靠文档进行交流的时间，并避免之后的一些因理解偏差而导致的返工浪费。

问题3：开发、测试一般会忙自己手上的任务

他们确实有时是需要各忙各的，但之前需求的梳理及讨论是避免不了的，也是需要一起来做的，这和之后的各忙各的并不矛盾。

问题4：伍老师，第14和15步没有太明白，可否再讲一下，多谢

第15步那个问号，其实就是在第14步用户故事写完后，作为过渡到第16步编写验收测试前的一个过渡。此时你需要在编写用户验收测试之前，去想想看，如何通过决策树和等价类划分这些方法，去思考出用户在验收时想测试的一些问题，以此引导出验收测试用例。

问题5：暴徒式开发是类似结对那种形式吗，多人结对在一起？或者是有其它形式？

另外，大家可以参考一种方法叫mob programming 暴徒式开发，就是若干个完成某个产品特性所需的各个角色的大牛，在同一个会议室里，在同一时间，在同一台电脑上（如果是5～6人，最好能有两台大屏幕电视或投影仪同时显示），共同解决同一个问题，而不是分头开发。其好处就是可以避免开大部分信息同步会议（例如站会、进度同步会、Code Review等等），从而消除这些时间浪费，因为要同步的信息，已经在暴徒式开发过程中就同步了。

我觉得暴徒式开发应该算是最高级别的结对编程和特性团队的实践。特性团队也就是多职能人员，包括开发、业务、测试角色所组成的一个团队。当然有时候他们也会各干各的，但当需要讨论时，他们不仅一起讨论，还同时一起把活儿给干了。当然并不是所有事情都一起干，像写报告这些需要独立完成的工作，也是会独立干的。

问题6：第14步故事地图度量的数据是什么时候提炼的？

这个度量的数据可以在第4步“用户痛点”和第5步“产品目标”来得到。就是在识别用户痛点和产品目标的时候，应该去考虑设计出一些指标，来衡量如何解决用户痛点和达成产品目标。然后就可以用在第14步。度量指标可以分成效率、效能、满意度三类。

问题7：在什么团队用过这套流程

ThoughtWorks的国外交付团队。ThoughtWorks在国内六个城市有办公室，大部分办公室都有一些国外交付团队。这些项目都不同程度地使用这个流程去开发，而且有些团队做得比我讲的内容更加专业。

注：本次分享有关用户数据方面的技术，参考了Chris Nodder在视频培训网站lynda.com的用户体验设计技术课程UX Design Techniques的内容，参见：http://www.lynda.com/Web-User-Experience-tutorials/UX-Design-Techniques-Overview/144083-2.html。

操练成就匠艺。全栈开发者的编程操练社区：bjdp.org北京设计模式学习组。微信订阅号：bjdp_org，QQ群号：235913915。