设想和目标
虽然我们是从零开始的一个自定义项目，但语音Coding助手从一开始的设计与目标就很明确：加入语音接口使其能在shell端实现命令语音实现以及编辑运行脚本，设计前端编辑器并将后端shell与编辑器结合起来形成一个完整的项目，完善功能以及实现英文听写......而我们以及跨过了alpha阶段正在逐步着手下一阶段的工作和任务。而在每天的Scrum Meeting中我们又会不断地提出新的需求与需要解决的问题，但并不会使我们项目的整体主线产生大的偏移。我们项目的典型用户其实主要分为两类，一类是肢体障碍人群，帮助肢体残障人群进行方便的编程活动也是我们最初做这个项目的初衷；第二是那些通勤中的程序员，为了缓解广大程序猿在通勤过程中记录idea，连接云服务器，运行脚本的需要。所以我们是特别需要用户反馈的一款项目，因为方便快捷的使用是这款语音Coding助手最重要的地方，如果用户实现起来都很困难，那么我们的工作将没有任何意义。所以不断的听取试用的同学以及助教的建议来改善我们的需求与目标也是十分重要的。而更加详细的典型用户和典型场景的描述在我们之前的功能规格说明书已经描述分析的十分清楚了。
计划
我们团队的计划大致分为两种，一种是在每个阶段初期我们会制定比较长远的计划，比如这个阶段需要攻克的主要任务以及达到的预期目标，这些都是大家都商量拟定好的，而我们在这个阶段的所有工作也都是照着这个计划朝着阶段性的里程碑目标进行着。而每天细分的个人的计划是我们的PM和每个人在Scrum Meeting中行进分配与协商，根据每个人不同的时间安排与能力，在与组员个人进行交流与确认之后，PM会在github上面发布详细的issue，每一项具体任务的定义与交付以及对应的分类和隶属的阶段都有详细的定义与记录，具体可以查看我们团队的github issue。项目在alpha阶段的整个过程也都正常按照计划进行，个人的任务也都按时交付。但在即将要发布的时候，我们却发现了一个史诗级的bug，将termux包名改为我们自己的包名之后致使termux自己维护的源的包出现了错误的情况，具体详情可以查看我们当时的issue说明。而这个问题也影响了我们在alpha阶段的预期发布，导致既定发布时间延迟。这个风险是在计划过程中不太好估计到的，因为之前接触的很多Android项目并不会因为更改包名而出现类似的问题。我们的问题是在alpha阶段计划中并没有留下缓冲区，每天的工作推进松弛有度，导致在冲刺阶段出现了问题延迟了发布。缓冲区是每个项目必需的给项目交付时间留有余地的预先性设定，可以在遇到未知风险的时候可以从容的在缓冲区处理并按时交付，而我们团队在alpha阶段所经历的这次bug风险正是因为没有留有缓冲区而导致的发布延迟。所以在beta阶段我们会改进这一点，在前期的工作中加紧一些，留下几天的缓冲区，可以从容应对未知突发的风险，如果没有遇到可以在缓冲区进行项目的完善和优化。
资源
我们团队在alpha阶段是6个成员，人力资源方面是充足的。而且我们团队成员在后端开发方面也很有经验，可能在前端方面大家经验都有所欠缺，所以alpha阶段前端还是有很大一部分时间在于Android前端的学习以及完成了一个简易的前端编辑器。alpha阶段后端的任务可能偏重一些，所以在这一阶段后期也有一位负责前端的人员快速投入到了后端的工作中，协助后端工作人员解决项目在后期遇到的困难。而在beta阶段由于转会我们的团队也是变成了5人，在人力资源安排上也进行了一定的调整，任务也更加艰巨。而在每项任务的时间与人员等资源安排上也会在组会上根据任务的难易程度和繁琐程度来讨论协商，根据alpha阶段的经验，我们对于任务资源的拆分和分配还算合理，大家都能在规定时间内通过自助的结对编程等方式准时完成任务。
变更管理
如果有什么变更的消息，我们的PM会在github上面发issue并 “@” 相关部分的成员，github会通过邮箱来告知成员有新的变更通知。如果是比较紧急的一些变更消息或者突然的一些工作请求组长或者PM会在我们的团队群里面去通知大家，在这个信息泛滥的时代相信大家也会时不时的注意一下自己手机上的消息，所以通知还是可以及时的传达给每一个成员以获得更快的反馈。另外每日组会也是很重要的一个收集以及传播信息的有效的方式，每天我们我们都会准时召开例会，会总结一下当前的进度以及决定第二天的任务之类的。所以例如“推迟”和“必须实现”等这种信息基本都是在每日组会进行一个商量决定以及分配的。对于项目的出口条件，我们的alpha阶段完成的部分已经是一个比较完整的改自termux 的语音助手了，所以说我们可以说在alpha阶段我们已经完成了我们之前既定的所有任务与目标——“做好了alpha阶段”。不过离一个完善的项目当然还很远，我们的出口条件就是很好的完成我们已经拟定好的任务，这个项目可以被他人顺利很好的使用，这就是我们阶段性的“做好了”。而由于每日例会的存在，特别紧急需要的变更也不太可能出现，所以只要按部就班有反馈与分配，同时变更就会跟进到每一个成员。
设计/实现
我们整体的设计工作是在每个阶段初期的正式组会上完成的，由组长提出一个大概的框架，然后大家一起讨论将这颗集任务，分工，目标等多项设计的框架树填充完整，然后各尽其责。在实际工作过程中前端和后端都出现了一定的bug，其中后端一个很致命的bug也在前面的“计划”部分有过介绍。而在发布之后会有一些需要改进的影响用户体验的bug，后面我会在“改进”部分详谈，并没有再出现过其他重要的bug。
测试/发布
我们在alpha阶段重点是在于后端shell对于语音的识别等方面，所以我们的测试重点也在语音接口与termux测试（前端只是简单的编辑器，基本在试用过程中就可以把测试完成了），包括单个字符，其他未知字符，字符组合，已经定义好的python关键字等，具体测试相关的内容可见测试报告，其中还有对不同机型不同环境的各种操作测试。在发布方面由于我们没有设置缓冲区的缘故，所以我们的发布时间被延迟了，所以我们首先通过百度云盘来发放apk从而获得第一轮的用户反馈信息。而在发布过程中，我们首先选用了学长推荐的酷安app平台，可是在等待审核过程中发现酷安需要盖有公章的安全测试报告之类的东西，不能稳定而快速地通过审核，所以转而在应用汇app平台发布。之后我们肯定会去在各种app平台去发放我们的产品。
对比敏捷的原则，你觉得你们小组做得最好的是什么？
我认为我们小组做的最好的是“在团队内部，最具有效果并且最具有效率传递信息的方法，就是面对面的交谈。”因为我们完全落实了课程所提倡要求的每日例会，而每日例会也确实给我们团队提供了更多的面对面的交谈机会，即使是有多人不能当面当场的情况，我们也会决定一个例如晚上的时间进行一个视频会议，同样可以起到面对面交谈的作用。大家可以当面反馈交流，更高效明确自己的任务目标以及与其他成员之间的协作与交付关系。
什么是在下个阶段要改进的地方？越具体越好
- 首先当然是完成好我们beta阶段最基本的工作，连接后端shell和前端编辑器，并且使功能完整无误
- 有用户反馈voice的button可以改成是悬浮型（可移动）的，以便使用
- 在软件第一次启动的时候我们会加上一个教程，因为用户可能会因为操作上的错误而导致软件不能正常运作
- 前端编辑器有一个保存文本不会自动刷新的小bug，我们也会不断寻找类似的有关用户使用感受方面的bug并不断修复
