如何画故事地图视频如何画故事地图，如何画故事地图图片 _睿知

如何画英语故事地图
首先，把英语翻译成汉语。然后画出动作或者需要的场景和人物。画完后可以选择插画的形式和四格。数字，，让人看着很迷茫。然后画一个写有英语对话的对话框。【其实可以模仿书，只是高一的那些。】
故事地图怎么画
故事怎么画？决定权在你。你根据人物、地点或时间来画。如果是基于性格，那就是性格的变化& # 039；s感情，时间，心理。如果属于地点，当然是人物变化所涉及的实际地点的变化。如果是属于时间的，那当然是人物在不同时期所做的所有变化。看你怎么看待这个问题了。
最初，世界地图是怎样画出来的
16世纪，荷兰出现了伟大的制图员墨卡托。早在1537年，他就绘制了第一张地图(巴勒斯坦)，随后到佛兰德斯进行实地测绘任务，以哥伦布发现的磁子午线为标准子午线作为测图的起点。1940年，在鲁汶成立了地图工作室，将测得的地图按比例印刷出来，引起广泛关注，制成地球仪。1968年，著名的航海图& quot世界计划& quot被制造出来。这张地图采用了墨卡托设计的等轴测投影，称为& quot墨卡托投影& quot 。它使航海家能够直线航行(即等距航线)，并第一次在地图上展示了整个世界。1630年后，它被广泛采用，并在世界航海、贸易和探险中发挥了重要作用。它仍然是最常用的图表投影。想象一个与地球方向相同的圆柱体& # 039；s轴在地球上切割或切割，按等角条件将十字线投影到圆柱面上。将柱面展开成平面后，得到一个平面网格。后经线是一组等距离的垂直平行线，纬线是一组垂直于经线的平行线。相邻纬线之间的距离从赤道到两极逐渐增加。任一方向上一点的长度比相等，即没有角变形，但面积变形显著，随离参考平行线的距离增大而增大。这种投影具有将等角航线表示为直线的特点，因此被广泛用于编制航海图和航空图。扩展墨卡托原理简介& # 039；的世界地图；假设地球被封闭在一个空心圆柱体内，其参考纬度与圆柱体相切(赤道) 。然后，假设地心有一盏灯，把球面上的图形投射到圆柱体上，然后展开圆柱体。这是在选定的参考纬度上通过墨卡托投影绘制的地图。墨卡托投影没有角变形，各点到各方向的长度比相等。它的经度和纬度线是平行的直线，并以直角相交。经线间距相等，纬线间距从参考纬度向两极逐渐增大。墨卡托投影的地图上，长度和面积明显变形，但基准纬度没有变形。形变从参考纬度向两极逐渐增大，但由于具有各个方向膨胀相等的特点，保持了正确的方向和相互位置关系。在地图上保持正确的方向和角度是墨卡托投影的优势。墨卡托投影地图常用作航海图和航空图。如果你沿着墨卡托投影图上两点之间的直线。你总是可以以相同的方向到达目的地，因此有利于船只在航行中定位和确定航向，给水手带来了极大的便利。参考百度百科-墨卡托百度百科-墨卡托投影
【如何画故事地图视频如何画故事地图，如何画故事地图图片】

文章插图
需求全景之用户故事地图
不懂需求分析的开发不是好的开发。经过上周一周的紧张准备，我在周五做了一个关于需求全景和用户故事图的分享；在此期间，我快速阅读了杰夫& # 039；s 《用户故事地图》。总结你上周学到的和分享的，作为这篇文章。首先，需求全景，从字面上理解，是指对需求的完整理解，也是项目中经常提到的全貌。比如买房，我们在售楼部看到的沙盘，就是高空俯瞰全景的感觉。那么用户故事图就是帮助我们构建需求全景图的工具。随着敏捷软件开发的兴起，它带来了许多积极的影响。例如，人们开始认识到大的需求可以被分割成小的用户故事。但需求拆分也带来了相应的负面效应，即容易只见树木不见森林，失去了对需求全景的理解。用户故事图是在需求拆分过程中保持需求全景的一种方式。那么什么是用户故事地图呢？它是一个方向图，以时间轴为横轴，优先级为纵轴，然后会覆盖所有的用户故事，表达需求全景。用户故事图是这样的：上图中，时间轴标注为横轴，优先级为纵轴，里面有完整的用户故事。我们用卡片来表示用户故事，同时我们看到这里有不同的颜色来表示不同层次的用户故事：上半部分是骨干部分(橙色和蓝色)，下半部分是细分需求的用户故事(黄色) 。通常，当我们创建用户故事地图时，我们首先从用户那里讲述用户故事& # 039；s的观点，并在讲述的同时把重要的步骤记录在便签纸上，从左到右排列。这个过程的输出是地图的主要部分。在这个过程中，我们需要注意几个原则。第一，要努力把故事讲完整；第二，要以广度为主，不要过多涉及细节。故事讲完了，我们就有了主体部分。此时，我们处于只见森林不见树木的状态。接下来，在第二步中，我们将回过头来讨论每一步的细节。在这个过程中，我们会对一些问题进行头脑风暴和思考，比如用户在这一步会做什么，如何让用户在这一步获得更好的体验，如何处理问题，然后将这些细节纵向排列在每一步之下。就这样，我们形成了画面中的网格结构，达到了一种既见林又见树的状态。同时我们可以看到，用户故事图上有一条蓝带，标明了三个发布计划。也就是说，在我们完成了需求细分之后，需要进行第三步，通过充分的讨论，对细分需求，也就是用户故事进行优先排序。并根据优先级，制定发布计划。这里需要提一下MVP的概念。MVP，最小可行Proct是最小化可用产品。这个概念源于精益，目的是以最小的投入发布对用户有价值的产品，帮助我们快速获得反馈，快速试错，通过迭代找到产品的正确方向。以MVP为例，如果产品需要登录功能，那么MVP1只能用最简单的用户名和密码登录。然后在后续MVP中登录手机验证码；然后在后续的MVP中实现其他如微信扫码登录等等。最后，我们用一句话来总结用户故事图：用户故事图是一个识别和梳理需求的工具，同时，它可以帮助我们构建需求全景图。通常在项目的初始阶段，也就是inception阶段，我们的产品经理，BA，Tech lead，会和客户一起梳理需求，达成共识。这个过程中使用的工具和输出是用户故事地图；然后在项目进入交付阶段，我们会把用户故事图带给交付团队，以用户故事图为载体，帮助交付团队理解需求。
用户故事图也是一个很好的交流平台。例如，在项目交付的中间，当利益相关者从客户& # 039；s端来了，我们可以方便的展示自己目前的进度，已经完成了哪些部分，还剩下哪些部分等等。这是一个非常简单的取钱场景。首先我们按时间顺序列出取钱的步骤：开车去银行，用ATM，查账户，取钱，拿交易单，开车去high 。或者还有另一种情况。查完账，发现自己太穷，于是取消交易，开车回家。这就是我们所说的广度遍历，从用户的角度讲述一个完整的故事& # 039；的观点。第二步，对上述步骤进行细分。比如查账的时候，有几种情况：查往来账；查看固定帐户和交易记录。每一个都是一个用户故事，按照必要程度从上到下排序。同时，比如提现也细分为：用户可以有提现的选项；用户可以有默认金钱选项，改善用户体验；用户可以选择无卡取现。经过第二步拆分和设置优先级，我们可以确定第一个上线，也就是第一个MVP:包括两个用户故事，用户可以看到当前余额，用户有提现选项，这是一个基本模型的实现。那么后面的第二次可以是支持用户更愉快更方便的取钱；第三次是支持用户无卡取钱。需要提到的是，整个过程的第一步是讲述用户故事；第二步，细分需求；第三步，分清轻重缓急，制定发布计划。是一个可以商量的过程，没有标准答案。解释中穿插了构建用户故事地图的练习。题目来源于《用户故事地图》这本书，对上班过程(从起床开始到公司结束)的需求进行了梳理和拆分，划分了MVP 。实践没有标准答案。练习时先梳理一下骨干故事：回忆起床的过程，分为几个阶段：如起床、洗漱、穿衣、出门、上班、到公司。如果任务太多，可以通过摘要行的任务描述一堆任务，也就是介绍任务层次结构。当我们提取用户故事的主干时，建议使用不同颜色的注释来覆盖下面任务卡所表达的意思。即使你不& # 039；如果手头没有不同的颜色，你可以将纸条45度变成菱形，让故事层次更清晰。用便签代替直接写在白板上，因为便签可以更方便的移动(体现优先级，顺序等。)并进行讨论。在需求拆分的第二步，我们需要头脑风暴，在此期间，我们可以用问题来启发他人：想想你今天早上做了什么？是不是还有一些不好的早晨断水，没有热水，忘带手机，没有& # 039；don’不要上地铁。再想想一个完美的早晨是什么样的。头脑风暴的过程是一个完全发散的过程。在这个过程中，我们不& # 039；不需要筛选，我们可以把想到的都列出来。为了充分发挥每个人& # 039；的创造力，这是一个我们获胜的舞台& # 039；不要否认别人。同时头脑风暴要先聚焦主场景，再聚焦次场景，什么是主场景？比如一个创建试题的步骤，创建试题是主场景，编辑试题和删除试题是副场景。第三步，讨论细分需求，排列优先级和必要性。经过第二步的头脑风暴，我们得到的用户故事是充实的，甚至是近乎臃肿的，那么我们就在这个时候进行讨论和收敛。同时，在完成优先排序后，我们可以制定发布计划。比如mvp1，意思是我们要迟到了，几分钟后需要出门，所以我们会拉一条丝带或者画一条彩色的线，把所有不必要的任务转移到丝带下面。然后会有其他的目标，比如过一个奢华的早晨；两周长假的前一天早上。如前所述，建立用户故事地图的过程没有标准答案。有些人可能会列出更多细节，比如把早餐做成热面包片和热牛奶。
《用户故事地图》有个比喻。一个用户& # 039；的任务就像一块石头。如果他用锤子敲打它，他会变成一块鹅卵石。其实在练习过程中也会有一些尴尬的点。每个人& # 039；的任务可能不同。有的人起床化妆，有的人起床运动，有的人起床带孩子，或者遛狗。这里引入用户画像的概念。用户画像就是我们根据不同的场景对用户进行分类，针对每一类用户创建用户画像。使用用户画像的最大好处是建立共情。当你建立用户画像的时候，你会有代入感，会从用户出发思考& # 039；的观点。用户故事地图本身就期望用户加入到梳理需求中来，这就是所谓的参与式设计。相比之下，实证设计侧重于前期的客户调研，然后设计师自己完成产品设计。在刻画用户的形象时，我们需要讨论哪些客户会使用我们的产品，为我们的产品付费，列出各种用户，讨论他们如何使用，思考他们需要什么功能。通常，当我们得到一个项目时，它的需求文档看起来是这样的：然后我们想把同样的需求翻译给用户& # 039；从用户的角度：有了需求文档& # 039；s的视角，我们开始尝试构建用户故事图：第一步，梳理应用的骨干业务流程，然后老师布置作业，然后学生回答问题，然后老师批改，最后学生检查结果。这是完整的用户故事，其中我们有不同的用户角色。第二步，准备核心用户的用户之旅。比如提问者在提出问题时，首先需要创建问题，然后创建试卷，再将问题与试卷关联起来。同样，老师布置作业时，先创建作业，再将作业与试卷关联起来，然后选择布置作业的班级。然后学生的过程& # 039；答案包括首先检查作业，然后回答问题，最后提交答案。老师改卷子的时候，需要先检查学生提交的卷子，然后批改，最后发布成绩。之后，学生可以查看自己的成绩。第三步是从核心场景中头脑风暴出每个用户任务的功能需求，比如为作者创建主题的用户任务。核心场景是创建一个主题。第四步：集体讨论每个用户的功能需求。其他次要场景的任务。次要场景比如上图中的编辑话题和删除话题，所谓次要场景就是即使没有这两个功能系统，比如如果我没有& # 039；t包含这两个场景我第一次上线的时候，那么产品还是可用的，用户暂时可以在后台编辑删除话题。第五步：头脑风暴每个功能性需求的配套需求紫色部分就是配套需求，相对于功能性需求也变成了非功能性需求。支持需求指的是一些技术故事，比如邮件服务器的集成。那么，之所以在用户故事图上列出这些支撑需求，是因为技术负责人和开发团队可以提前对这些需求进行技术预研或实现。然后，当我们的功能需求涉及到，例如，与电子邮件服务器的集成时，我们可以直接引用预先研究的结果。保证我们的交货时间表。这些支持需求通常由技术主管和BA一起列出。那& # 039；这就是为什么不仅产品经理和BA(业务分析师)需要学习用户故事地图，开发人员和测试人员也需要学习，因为有一天你会成为技术领导者！)以上是对用户故事地图内容的总结。最后强烈推荐《用户故事地图》这本书。作者是这个工具的作者。根据作者& # 039；的亲身经历，这本书讲述了用户故事图是如何让需求梳理的更加清晰，以及如何把项目从混乱的需求中拯救出来。同时语言轻快，阅读快乐！
用户故事地图2：如何创建故事地图
1.任务就是我们所做的；动词短语：故事地图中几乎所有描述用户如何使用软件的注释都使用了动词短语；项目本身充满了各种任务，包括开发和测试任务；任务是构建故事地图的基本模块。2.我的任务和你的不同。在考虑用户的时候，有一点要记住：1)用户使用软件的目的不同；2)用户会在不同的情况下使用软件，有时还要考虑其他人和事物的影响等。3.我只是更注重细节。使用目标水平的概念可以帮助总结小任务或分解大任务。按照从左到右的顺序组织卡片，第一个任务在左边，第二个在右边。试着指着第一个音符开始讲故事。首先，我& # 039；我会这样做& quot；每个音符都是一个步骤，每个音符之间隐藏着一句话& quot.然后我."故事按照从左到右的叙述流程组织，这是人们讲故事最自然的方式。在叙述过程中，找出你可能遗漏的步骤，补充细节。细节、替代、变化和异常构成了故事地图的主体。如果你从左往右看地图，你会发现有些故事需要放在一起。在这些类似的任务上面，放一张不同颜色的纸条，纸条上写一个动词短语，这样就可以涵盖下面所有任务卡的意思了。这些被标记为更高目标级别的任务被称为& quot活动& quot(活动由一群相似的人在相似的时间完成的任务组成，旨在实现特定的目标)，活动构成故事地图的主干。活动的描述方式和任务的描述方式有很大的区别，应该用用户习惯的方式命名。仅仅通过添加或删除任务，它就可以帮助你实现不同的目标。使用分段来确定与特定结果相关的所有任务和细节。任务是描述人们做什么的动词短语；任务有不同的目标级别；故事地图中的任务按照叙事线索从左到右排列；地图的深度包含了可变的、可供选择的任务；通过故事地图顶部的活动将任务组织在一起；活动构成了故事地图的主干；通过分割地图找出实现特定结果所需的任务；1)梳理问题：用户是谁？它带来了什么价值？2)构建一个全景图，先有广度，不要深度，一公里宽，一厘米深。尽量用故事地图描述一切，包括用户的苦与乐。3)探索。深入展开，讨论其他类型的用户，这些人要做什么，哪些环节会出错。使用用户画像、原型和实验来不断优化解决方案，并尝试改变和改进故事地图。4)制定出版策略。请记住一点：要开发的东西总是太多。专注于业务目标和目标用户的实现，果断砍掉那些不& # 039；不能帮助取悦用户，也不能帮助公司实现最小的解决方案。5)制定学习策略。你可能已经确定了最小可行的产品方案，但是请记住，这些都是实际验证之前的假设。故事和讨论可以帮助我们发现最大的风险，为一个子集的用户切割更小的MVP实验，并逐渐了解什么对用户真正有价值。6)制定发展战略。去掉所有不必要的东西后，剩下的需要投入开发。根据实施的先后顺序，进一步划分最小可行方案，前期重点解决关键技术问题和开发风险。通过建立一个故事地图，帮助团队看到全景，同时看到树木和森林，这是故事地图可以带来的最大好处之一。让故事有效的两个最重要的东西：故事地图是一个简单有效的方法，可以把产品愿景变成待办事项。它帮助我们了解开发什么，用户是谁，价值是什么。
1)第一层次：高层次的使用步骤；2)层次2:将这些步骤分解成对应于每个用户的活动& # 039；的角色；3)第3级：这些活动被细分为特定的用户故事，其格式为& quot作为一个角色，我希望功能创造价值& quot 。这些用户故事加起来形成了第一个产品待办事项列表。在每个级别，团队可以决定哪些细节需要深入研究，哪些依赖团队需要考虑。在团队对细节探索到合理的程度后，可以优先考虑待办事项列表。细化程度取决于项目规模和项目阶段，可以细化到活动或故事层面。通常使用简单的投票方法来确定优先级，如点卡或用卡诺模型投票。该团队将每个用户故事标记为& quot基本需求& quot，& quot预期需求& quot和& quot刺激需求& quot 。

文章插图
如何构建用户故事地图
用户故事(User story)是敏捷开发中提出的一个概念，从用户的角度来描述用户所渴望的功能。这是一种描述需求的方式。当我们告诉R & amp关于需求，用户故事可以让研发；了解需求的背景，并进一步理解它们。故事的格式通常是：作为一个xxx(某类用户)，我想让xxx(做一件事)达到xxx(某个结果或动机) 。在写用户故事之前，我们可以思考：(1)这是一个什么样的用户？(2)在什么场景下，你想解决什么问题？(3)你在解决问题的过程中遇到过哪些问题？(4)最终用户希望如何解决？另外，在写用户故事的时候，要注意& quot投资& quot:独立性：独立性原则要求用户故事的问题应该是相互独立的，而不是相互依赖的。用户& # 039；独立的故事可以降低区分需求优先级和制定迭代计划的难度。可协商：用户故事是可协商的，这意味着故事中描述的需求不是详尽的，而只是对需求的简短描述，更多的细节将在与用户的讨论中产生。有价值：用户故事必须反映用户关心的价值。可估计：虽然用户故事中的需求描述不够详细，但也必须使开发人员能够估计故事规模和开发工作量，否则无法制定迭代计划。小：用户故事尽量避免史诗巨制故事。小故事容易估算，也容易制定迭代计划和跟踪监控。可测试性：用户故事必须是可测试的，以便于验证故事是否完成。