前言
修真院一直不忌讳给新人员工更多的机会，也不会降低对于品质的要求。
90%以上的员工都是自己手把手培养出来的新人，在这里不计较工作年限，不计较学历，但会对职业素养要求很高。
技术不够扎实，可以给你制订计划培养，改变你的思维方式和学习方法，但是职业素养却是当前立刻要求改变的。
这段时间又有新的小伙伴加入，给他们的项目都是新手上手级的项目，但在完成的过程中，发现他们对Demo环节的理解，还是有问题。
比如说，“做到什么样的程度才算是Demo通过？”
Demo的时候，产品经理的角色是验收还是一起参与向公司中层汇报？
按照修真院原有的教学流程，这些问题应该是在复盘项目之前都必须要了解清楚的，但是从现在来看，关于敏捷开发流程中的Demo环节，还是没有重点讲清楚。
所以今天打算针对Demo这一个环节，来讲一下，也做为修真院后面师弟师妹们的学习教材。
一 为什么要有Demo
之前在各种场合都讲过，环境是分成开发，测试和线上三种的。
线上是交给用户使用，测试交给QA使用，开发是研发团队的。
什么时候我们认为开发阶段结束，可以交付给QA了呢？总要有一个标志性的事件。
这个事件，我们称之为Demo。
Demo的价值和意义，从小的地方说，就是在需求讲解时，产品把需求交付给研发团队。
那么过了研发周期之后，研发团队就要把产品交付给产品经理。
当然最终交付的重点还是在线上，但是Demo代表一个阶段性的验收，指的就是功能完成，产品经理想要看到的样子都有了，可能进行正式的测试了。
这也代表着QA团队出场和研发团队可以参与下一个迭代的研发了。
所以Demo是一个重要的里程碑，很多时候可能研发团队都会误以为，自己的工作只到了Demo阶段就结束-这当然是另一个错误的认知。
二 Demo应该谁参加
Demo是一个公司级别，或者是项目级别的事情，所以理应是和项目相关的所有人。
产品团队，UI团队，研发团队，测试团队，运营团队，或者是其他的销售。
同时为了确保验收的质量，还应该有各组的Leader，或者是公司和项目小组相关的中层骨干。
除研发团队外，其他的成员都可以成为Demo的验收方。
不同的地方在于，产品团队重点验收研发是否如期或者是按照需求开发完成，其他人可能还会关注在需求评审之前没有注意过，可能连产品经理自己都忽视了的体验优化。
Demo也应该是一个开放的会议，任何人对项目感兴趣，想要了解，不存在保密风险的情况下都可以自由选择参加。
所以Demo通常会以邮件的形式发送给你权限之内能告知的所有人，除了以上提到的关键角色，其他非关键角色都可以自己来判断是否有参加的必要。
三 Demo的形式
如果在线下，大家在同一个地方，很方便面对面，那么找个会议室是最高效的沟通方式。
而修真院在这么多年来一直是线上协作开发，大家在线上的交流更多，所以通常都会选择以屏幕分享的方式去完成。
QQ群或者是讨论组就可以完成这个功能，有时候我们也会找个会议室，一边投影投出来，一边在线上分享。
这里有一个很关键的地方，就是如果你在线下，那么你必须要去会议室，而不是在工位上戴着耳机，这个小细节，是我观察了很久慢慢意识到，是一个需要强调的环节。
能当面说，就不要电话，能电话说就不要用聊天软件，能用聊天软件，就不要用邮件，能用邮件，就不要用纸面文件。这是一个办公室沟通的小技巧，一个简单的小规则，却能让你的工作效率大幅提升。当然，重要的事情必须邮件或者是纸质文档留痕，这是《职场生存指南》中的内容，不过多说。
四 Demo之前的准备
在确定可以Demo之前，有三件事情要做。
1。性能测试
2。UI自检
3。CodeReview
今天的重点是讲Demo，所以对于这三点不详情展开说，性能测试的结论，必须是通过或者是不通过，如果性能测试不通过，没有Demo的必要。
UI自检测是前端或者是客户端自我审查的必要阶段，特别是针对没有经验的新人来说，很多新人在初入行的时候，根本就不会注意到一些常见的问题。
Codereview 是代码质量的保证，CodeReview重点看三点，一是看是否和方案设计相符，有没有研发成员中途修改方案的情况发生，二是看代码规范，是否符合各小组的编码规范，包括命名，结构，最佳实践等，三是看潜在风险，是否有研发人员自己并无意识，或者是受限于能力而无法判断的风险。
这三个结论都是通过的时候，才可以发送会议邀请邮件，开始Demo。
五 Demo的进程
在会议室里的时候，拿着自己的笔记本（如果你没有，你还是在使用PC，那就只能发呆了），研发团队来派出一个主讲人，按照Story的顺序去演示功能。
同时在场的所有人，都可以在听主讲人讲解的时候，按自己的意愿随机测试，看看是否能抓出几只Bug。
在这里有几个常犯的错误如下：
1。Demo分成多个主讲人：我们不推荐这种方式，在研发阶段各有分工，但是最终所有的人都要为整个项目的最终结果负责。一个主讲人理应理解所有的业务流程，不能说我对这个不熟悉，所以这部分内容让谁谁谁来讲。
2。Demo的时候未按Story的顺序来演示：这是多次发现Demo的时候有遗漏，在测试环境里被发现有Bug，或者是上线之后也有遗漏。Story可以有一个约束和提醒，不至于的所有人的人都遗忘。
3。Demo的时候未有真实数据：这是研发团队新人的容易忽视的问题，经常用自己顺手的随意的文字或图片或者数据来演示。产品有功能上的需求，也有视觉和性能上的要求，不正确的内容没办法看出来一个产品的真实的样子，尽可能真实的创造用户的使用环境，这是Demo数据的价值。
4。Demo的时候没有人随机测试：如果所有的人都只盯着投影仪，或者是盯着自己的屏幕分享，这场Demo会议就失败了一半。软件里的可以点测的路径很多，Demo时很容易遗漏，所以参于Demo的人，以自己的角度去随机检测，才能够尽可能多的发现问题。
六。Demo通过的判断标准
Demo如果通过，研发团队就要打Tag，封版本，到测试环境。
所以Demo时候的代码就代表着，你连一个字都不应该出错，出错了，就代表Demo不通过。
按这个推论来做，Demo通过的方式很简单，不应该有任何一个肉眼能够发现的错误。
无论是功能，还是文案，还是样式。
这一点是需要和研发团队反复确认的，要求在Demo之前认真做好持续集成，每日测试和交叉验证。
很多新人没有这种习惯，又或者是在任务阶段就没有被培养出来严谨的职业素养，总是认为自己的主要功能完成了，一点小问题随便改改就可以了。
然而总是各种各样的小问题影响进度，也阻碍你在技术水准上的提升，更能训练出来持续集成的职业素养。
按照当前修真院内部的规则，如果发现有一个肉眼确认的问题，就应该中止Demo，打回重新自测。
但实际情况里，通常都会有放水的情况，记录下这些问题，然后标记上责任人。
如果说Demo未通过，就应该把这些记录做为Demo的结论发出来，同时给出下一次Demo的时间。
如果说Demo通过了，就给出Demo通过的结论。
这些在修真院内部都是公开的邮件，格式都可以看参考。
结语
对Demo的认知，本身就是职业素养的一种。
不同的公司，对Demo有不同的要求很正常，但是在修真院，就需要按照这个标准来。
所以，这篇文章一是分享，二是要求，还有关于Demo未通过的绩效考核，这些都是公司内部管理的问题，不公开讨论。
最终期望的是什么？
Demo是否顺利，其实并不是在Demo的会议上，而是在你的需求是否理解透彻，方案是否合乎情理，持续集成是否实施，研发的时候是否按照Story的优先级去做，以及你的自检是否认真仔细。
从这个角度来说，各项基本内容做好了，才算是你有了Demo的底气，要把Demo做好，功夫却在Demo之外，这是一个水到渠成的事情。
但流程就是流程，最好的方式，就是通过Demo的总终结果来反思自己哪里可以做的更好，祝大家Demo顺利~
