设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
虽然我们是从零开始的一个自定义项目，但语音Coding助手从一开始的设计与目标就很明确：加入语音接口使其能在shell端实现命令语音实现以及编辑运行脚本，设计前端编辑器并将后端shell与编辑器结合起来形成一个完整的项目，完善功能以及实现英文听写......而在每天的Scrum Meeting中我们又会不断地提出新的需求与需要解决的问题，但并不会使我们项目的整体主线产生大的偏移。我们项目的典型用户其实主要分为两类，一类是肢体障碍人群，帮助肢体残障人群进行方便的编程活动也是我们最初做这个项目的初衷；第二是那些通勤中的程序员，为了缓解广大程序猿在通勤过程中记录idea，连接云服务器，运行脚本的需要。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划中beta阶段的后端shell和前端编辑器的连接工作，UI风格优化，gamma阶段的编辑器的黑夜模式，按钮的悬浮可移动功能，编辑器的文件及文件夹系统等功能都已经完成。并且每项功能都是按照原计划规定时间完成并交付。在截至展示时间用户总数量达到了133，达到了我们预期的100+用户数量。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
在beta/gamma阶段我们团队完善了代码的注释工作以及相关文档工作以提高团队软件工程的质量，还有就是项目中间阶段的交付与项目管理方面在github上有具体详细而且责任分工明确的任务部署与简洁明了的看板展示，这也是我们在软件工程质量上改善的一部分。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我们一直以来是语音直接调用的科大讯飞的API，虽然能够满足一般的语音输入要求，但在一定程度上还是会有一些无法识别或者识别错误的情况，我们一直想要改善的是想自己用百度的模型去训一个自己的语音API，这可能是我们想要改进的一点。
计划
是否有充足的时间来做计划?
我们团队的计划大致分为两种，一种是在每个阶段初期我们会制定比较长远的计划，比如这个阶段需要攻克的主要任务以及达到的预期目标，这些都是大家都商量拟定好的，而我们在这个阶段的所有工作也都是照着这个计划朝着阶段性的里程碑目标进行着。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
一般我们在每日例会头脑风暴的时候大家都会提出不同的想法与意见，我们会根据自身经验去讨论决定选择哪一种。如果是一些没有踏入过的范畴我们会分配任务去先调研或者尝试，再做决断。
有没有发现你做了一些事后看来没必要或没多大价值的事?
我们在beta以及gamma阶段完成的任务基本都是提前已经设计好且必须要完成的任务，那些琐碎而没多大价值的事情我们从项目开始就没有太多的涉及到。
是否每一项任务都有清楚定义和衡量的交付件?
我们每一项任务甚至是部分bug之类的在github上面都有相应的issue以及其相关定义与comment来做交付。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
由于有了alpha阶段的经验，在beta以及gamma阶段项目的推进都很顺利，没有再出现意外。
在计划中有没有留下缓冲区，缓冲区有作用么?
在beta/gamma阶段我们都有在末期留下了半周到一周左右的缓冲区，缓冲区可以处理一些项目突发的情况以及预防未知的风险。
资源
我们有足够的资源来完成各项任务么？
在每项任务的时间与人员等资源安排上也会在组会上根据任务的难易程度和繁琐程度来讨论协商，所以虽然我们人比其他组少两个，但是我们还是能够很好的分配资源来完成各项任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?
主要是根据任务相应的负责人根据经验以及在实际工作过程中的体会与预测来估计。精度比较准确。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
我们团队从很早就开始制定并实施测试计划，所以在时间和人力方面是没有问题的。而在app的兼容性测试时我们通过一个专门的测试平台针对不同的机型进行了测试，所以在软硬件资源方面的问题也就迎刃而解了。
变更管理
每个相关的员工都及时知道了变更的消息?
如果有什么变更的消息，我们的PM会在github上面发issue并 “@” 相关部分的成员，github会通过邮箱来告知成员有新的变更通知。如果是比较紧急的一些变更消息或者突然的一些工作请求组长或者PM会在我们的团队群里面去通知大家。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
“推迟”和“必须实现”等这种信息基本都是在每日组会进行一个商量决定以及分配的。每日组会也是很重要的一个收集以及传播信息的有效的方式，每天我们我们都会准时召开例会，会总结一下当前的进度以及决定第二天的任务之类的。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
对于项目的出口条件，我们的beta/gamma阶段完成的部分已经是一个比较完整idea语音助手了，所以说可以我们已经完成了我们之前既定的所有任务与目标。
对于可能的变更是否能制定应急计划?
而由于每日例会的存在，特别紧急需要的变更也不太可能出现，所以只要按部就班有反馈与分配，同时变更就会跟进到每一个成员。
员工是否能够有效地处理意料之外的工作请求？
我们基本上没有出现过太多意料之外的工作请求，只要出现我们会在群里或者每日例会的时候去和谐的分配任务。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们整体的设计工作是在每个阶段初期的正式组会上完成的，由组长提出一个大概的框架，然后大家一起讨论将这颗集任务，分工，目标等多项设计的框架树填充完整，然后各尽其责。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在设计时没有遇到模棱两可的情况，基本在组会的时候都确定完毕了。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
具体代码规范相关内容请见我们的展示博客部分：Here！
测试/发布
团队是否有一个测试计划？为什么没有？
我们团队有完整的测试计划，详细内容可见我们beta/gamma阶段测试报告：Here！
团队是否有测试工具来帮助测试？
我们使用google官方提供的espresso框架进行模拟点击，输入，监听等事件。并且使用了腾讯的wetest平台进行了多种机型的兼容性测试。
在发布的过程中发现了哪些意外问题？
在beta/gamma阶段的发布过程都比较顺利，只是一些比较大的应用市场要求的安全测试报告等内容太过繁琐，审核时间太长，所以没有选择在其上面发布。
