这篇文章适合的人：所有任务执行人员和任务分配人员，主要针对IT和行业来叙述的。
对于首次看的人，建议带着你的疑问，全篇阅读，如果KYM无法解决请下方留言。
对于只是使用KYM工具的人，可以直接看怎么做KYM。
场景：回想下你的疑问
场景1：有一天领导A给你下了一个任务a：把某某需求分析下，或把某某需求方案设计下，或把某某需求开发下(一句话任务)。
场景2：紧接着领导B给你又下另外的任务b：把某某需求出下测试策略，或把某某需求测试下(一句话任务)。
场景3：然后突然有一天领导A来问你：某某活a干完了吗?进展到哪了?领导B也来问：某活b干完了吗?进展如何?有木有阻塞?
你有没有遇到以上这种场景?当时是不是很懵逼?当然为什么会出现以上问题呢？在于一句话任务包含的信息不全，任务的deadline或者里程碑没讨论，任务是否有风险等等，此外做为任务执行者有没有反馈自己计划，目前有木有另外的任务，有没有考虑任务的并发。
带着你的疑问问题，让我们看下KYM(know your mission)这个工具是如何来解决这些问题的。
进入正题前先了解下黄金圈法则，个人感觉KYM和黄金圈法则讲述了相同的道理：先了解Why，再关注How，最后关注What。普通人思考行动和交流的方式是由What到How再到Why但激励型领袖会却相反。你想想自己接到任务后是如何思考的，是不是这样的：任务是什么怎么做很少问为什么要做这个任务，还是这样的：这个任务为啥要做可不可以不做或者做后会带来什么效益然后思考任务如何做是什么。
我们按照黄金圈法则来介绍KYM。
为什么要做KYM(Why)
当你接到一个任务时，可能这个任务执行的的时间和资源有限，但如何更好的完成这个任务呢?这也是为什么要做KYM?我们来分析下完成一个任务的过程，来回答这个问题。
1)这个任务为何要做?把任务的投入及其所带来的效益分析清楚，或许不需要做，了解清楚用户为什么提需求及其痛点是什么，或许已有功能也能满足需求。
2)任务交付是否冲突：接新任务时一定要知道自己目前任务何时完成有何阻塞，新的任务是何时完成可能有啥风险。一定要知道有多少人力，任务完成需要多少人力，如果不考虑这些就有交付的风险，切记一旦答应下来就要全力以赴。
3)这个任务都有哪些子任务(拆分子任务)：
任务拆解成子任务后，才好安排计划，定里程碑点。
4)这个任务的子任务哪些是优先级高的，哪些是必须要完成的，哪些是容易完成的，哪些(子任务或者任务的环节)是最容易出问题的，做好风险识别：一个测试对象或一个需求哪些地方容易出现bug?哪些地方风险比较高?会出现什么样的风险?做好风险识别后才可以进一步好分析风险和风险控制。
5)这个任务要分析风险发生的影响和可能性：任何风险都有两个重要属性，即风险发生的可能性和风险发生后的影响。风险发生的可能性有多大，和任务完成的过程中所依赖的人员和工具设备有关，比如人员是新手或者有某方面的缺点，设备是快到期的老设备(某些硬件可能只有3-5的寿命)等等。风险发生后影响到最大的是用户，要深入研究用户的痛点，用户为什么提需求，解决用户什么样的问题，用户无法容忍哪些问题。
6)收集更多的信息，更好的进行风险识别，风险分析和风险控制：包括不限于用户有哪些？是不是通用需求(仅解决某一用户的问题)?用户为何提交需求?用户最关心什么?什么时候交付给用户?完成任务需要哪些团队?需要多少人力?需要哪些方面的人员比如Python或JAVA还是C++开发人员?开发人员的经验和能力是什么?测试人员的工作经验和能力是什么?过程中发现哪些问题?需求变更后是否澄清给相关方?完成任务需要什么工具设备?工具设备是否已具备能力?哪些功能是可以自动化守护?交付的时间点是什么是否延期?需要交付的有哪些?
7)按照风险大小排序选出高优先级的问题(风险控制)：注意风险是不断变化的，在任务完成的过程中，风险是迭代的。
如何在有限的任务执行时间和资源的条件下，KYM工具可以帮助你任务拆解并列出优先级，收集任务更多的相关信息，识别出风险，分析风险(影响和发生概率)并做好风险控制(按优先级高低来控制)，最终准时保质的交付产品给用户。
在拆分任务和收集更多信息后，问的问题和识别出的风险，会促使开发人员和测试人员主动向需求人员，向更靠近用户的人员甚至最终的用户了解更多的信息，也促进参与该特性的人员之间的沟通，及时获取有价值的信息，提前发现风险所在。
怎样做KYM(How)-CIDTESTD
CIDTESTD来源于《Heuristic Testing Strategy Model》早期的版本，链接为http://www.satisfice.com/tools/htsm.pdf。
从CIDTESTD八个方面来做KYM，CIDTESTD包括Customers用户、Information信息、Developer Relations开发者关系、Test Team测试团队、Equipment &Tools设备和工具、Schedule进度、Test Iterm测试项、Deliverables交付件，详见如下图。
CIDTESTD是从波及人员来看涉及用户、开发、测试人员；从工具角度，考虑了工具设备；从测试点来说，有哪些测试项；从进展来看，考虑了进度；从输出来看，考虑了交付件，比如交付什么软件什么文档等等；还有产品相关的信息。
以上图片来自异步社区，如有侵权，请通知删除。
使用了CIDTESTD后的一点点，感受：
1) 从波及人员来看涉及用户、开发人员、测试执行人员，个人觉得少了需求分析人员、方案设计人员、测试设计师以及用服人员，一个需求从用户提出到交付给用户的过程中所涉及的人员，也就是需求从分析到方案设计到开发到测试再到交付的每个环节都有可能出问题。a)用户为什么提交什么需求，痛点问题是什么，需求间的优先级，交付的时间点，能带来多大效益；b) 开发人员的经验和能力(是不是新员工，是不是可信的老司机，不可信老司机的应对措施，开发编程规范如python的，开发设计要求:比如客户端哪些界面跳转哪些不跳转，客户端传给服务端后服务端的处理逻辑是否合理是不处理直接入库是不打日志还是其它等等)；c) 测试人员的经验和能力(曾经跨城市两地间进行测试过，另外一个团队作为特性测试人员，不能当面沟通要尽量视频会议沟通测试内容；测试本身是启发式的，测试过程中发现问题要重新设计测试项而不是一成不变的)；d) 需求分析人员的经验和能力(需求是否清楚明确，必须要做的原因，所带来的收益是否明确，需求的优先级高低)；e)方案设计人员的经验和能力(方案解决的需求点和场景点以及波及点是否列清楚，流程图是否画清楚，数据库表结构设计是否合理，接口消息是否讨论清楚，依赖的第三方组件或第三方团队的开发是否交付或可观的进度)；f)用服人员的经验和能力(功能验收完交付给用服，用服是否明确知道功能如何使用，功能交付项是否清楚)；g)测试设计师(测试架构师或测试策略设计师)的经验和能力(测试点的设计是否全，测试点的优先级是否列出，自动化思路是否合理)；
2) 从工具角度，考虑了工具设备，最开始认为制造和使用工具是人类和其他动物的最大区别，当然有些动物也可以使用工具甚至制作工具，作为智人是不是更要懂得工具的妙处，这里的工具包括但不限于a)测试环境(真实测试和模拟测试环境)；b)测试工具(模拟测试工具发送和接收http/snmp/ftp等类型消息如postman和mib，自动化用例生成工具，自动化脚本工具如Robot Framework和Selenium，数据库工具如pgadmin，性能压力测试工具如loadrunner，安全测试工具burpsuite和webinspect，nessus等)；c)测试管理工具(测试用户维护工具如Wiki，测试报告归档工具如SVN和Wiki，故障管理工具jira和Wiki等，风险跟踪工具用于风险识别风险分析风险控制最终得到解决，测试策略编写工具如xmind)；
3) 从测试点来说，有哪些测试项(测试点存在的意义为何要测试这一点，测试点的优先级是否列出，测试用例是否归档，自动化用例是否编写完成，需求变更后是否对测试点做修改，测试方法是否可靠合理，测试数据是否构造完成，测试中发现问题是否启发式增加测试点)；
4)从进展来看，考虑了进度(任务总归是否deadline的有里程碑点的，任务是有计划的，每天进展是否和预期一致，阻塞问题是否有人解决是否上报领导，测试要增量进行否则前期工作可能白费也要减少回归测试减少重复劳动，所依赖的是否如期提供，随着时间推移所依赖的优先级和风险会慢慢提高)；
5) 从输出来看，考虑了交付件，比如交付什么软件什么文档等等；
6)还有产品相关的信息(这些信息包括不限于测试注意事项，测试过程中收集到的问题，发现的bug是否解决，需求变更点，方案设计和业界比较)。
1)2)作为测试的输入项，3)执行过程中，随时关注进度4)，最终到5)作为测试的输出项。这个过程中1)2)3)4)是不断迭代的，需要不断地收集更多的信息，识别风险控制风险，以尽可能少的时间发现尽可能多的尽可能重要的问题(bug)。
什么是KYM(What)
说了这么多，那么什么是KYM呢?
比How更重要的是先想清楚Why的问题，了解清楚任务本身以及任务的背景，明确最终要达到的目的，然后再开始考虑How的问题，并且在执行任务的过程中，不断深入理解Why，不断迭代和优化Why，使得最终我们输出的What和任务目标始终是对齐的，邰晓梅老师把这种方法叫Know Your Mission ，简称KYM。KYM和黄金圈法则讲述的是一样的道理。
邰老师把KYM当做一种testing heuristic，因为在很多种情况下，KYM会启发我们问各种各样的问题，提醒我们在关注具体的测试细节前先要收集必要的信息、了解测试任务的背景。
问问题的能力是测试人员来说是非常重要的，KYM的本质是通过不断地问问题，收集信息，了解上下文，对测试最终要达成的目标有个更加清晰的认识，这个目标将不断指引测试人员的一切活动，无论是测试分析，测试设计，还是测试执行、测试管理等活动，都围绕测试目标进行，KYM向航海中的灯塔一样，时刻帮助测试人员辨别方向。
KYM不是一件必须要做的事情，不是一个必须使用的方法，当某些特定的上下文(testing is context driven)下就不必做KYM。把KYM当做是一种采用启发式heuristic的方法，体现测试人员思考方式，影响测试策略的制定，能帮助测试人员做出更好的判断，能锻炼各种测试技能：问问题的能力，迅速提取有价值信息的能力，自我测试管理的能力，识别风险的能力，基于风险调整测试策略的能力，把测试项目全局的能力，站在用户角度测试的能力等等。
什么时候应用KYM(When)
从项目的任何阶段开始介入，KYM贯穿整个测试项目始终，它不是一次性的行为。
KYM使用注意事项(note)
1) KYM不要当做形式化，将CIDTESTD制作成KYM思维导图，但不能强制大家必须使用
可以根据所处的测试上下文，更加灵活地选用合适的方式来应用KYM，记住应用的原则：Apply Heuristic,Not to Follow Them.
2) 重结果不重过程：思维导图只是KYM的一个可见的结果。
3) KYM不要过度关注需求的细节：把握主干，忽略细节。站在更高的层次把我信息，提取有价值的信息，进行拆解并获取刚刚好的信息后续不断调整，不要指望一次投入就获取所有的信息，而是要有条理地、分步骤地、逐层递进地不断挖掘信息。
