Gamma阶段事后分析
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决的是安卓游戏的自动化异常检测问题，定义的足够清楚，对于典型用户的描述和典型场景的描述也足够清晰。
具体来讲，通过提供用户测试的选择，让用户自由对他的游戏进行黑盒测试，发现问题由本程序进行报告并提供操作记录，使用户能够针对性的从黑盒测试中寻找异常的成因。具体的用户详见[软件工程]功能规格说明书。
这部分内容在Beta和Gamma阶段仍然不变。
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划功能：经过三轮迭代，功能基本完成。原定的异常判断功能的优化和控件识别两方面功能由于工作量较大，没有从Alpha一开始就着手因此放弃，转而着重提升用户体验，在原计划之外走了另一条路。
Beta阶段按照原定计划交付，Gamma阶段迟交一天，因为进行完备测试发现了较多需要改的问题，但是没有对整体产生较大影响。
用户数量达标：目标是50人，截止2019.6.18凌晨0时，达到了62次下载5次保存。
-
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
-
合作
经过Alpha阶段的磨合，从beta阶段开始由于在分配任务上对每个人不再是每天分配一个一个小任务，而是直接指定长远的内容，因此成员对职责认知更加清晰，成员每天都有自觉地积极完成自己的任务，分工上较之Alpha也更加明确。
-
测试
Alpha阶段的测试做得无法令人满意，Beta和Gamma阶段对这方面进行了着重的强化。
Beta阶段对白盒测试有了重大突破，首先是学习并且顺利实践了接口的自动测试和覆盖率测试的工具并生成报告，接着又完善了对UI的单元测试。
Gamma阶段一开始就着手制定了详细的黑盒测试计划，实践证明，在测试上有计划的进行功能测试远远比凭空想对功能进行测试要覆盖得全面和完备。
-
文档完善
除开最开始的代码规范（团队项目规范.md），在Beta阶段和Gamma阶段新增了前端开发配置方法（PyQt5.md）、测试工具说明（测试工具以及计划.md）、界面改进方案（界面改进方案.md）、黑盒测试方案（黑盒测试方案.md）、后端接口文档（API文档.txt）、测试报告（TestReport）等。
-
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
基本一致。我们在主要功能上进行了多次优化，从功能到用户体验都有很大的提升。比如最初的界面功能堆积在一起，优化之后更清爽，也方便使用。比如最初的程序在退出上都有问题，到现在完整的开启到使用到退出的流程都是完整的。因此我们认为我们离目标近了很多了。
有什么经验教训? 如果历史重来一遍,我们会做什么改进?
如果重来一遍，我们会分出开发力量到建立智能模型识别控件上去，让程序达到最初设想的智能上去。在实际开发前，我们没有实际上手的经验，唯一的方向是老师指导的monkeyrunner，因此当时的方针是一个阶段完成monkeyrunner的自动测试，在有了实际经验之后再加入模型智能化。然而实际的操作之后，我们发现引入模型的工作量是非常大的，如果从Alpha阶段开始还好，从后续阶段再开始就太迟了。
当然这也是实践之后才能得到的经验了，对于刚上这门课的没有经验的我们而言，一个阶段解决一个大方向的问题是很正常的想法。只有经过实际操作之后才能有现在的视野，这也是这门课给我们的提升之一。
计划
-
是否有充足的时间来做计划?
是的。虽然在Beta阶段最后的测试发布总结反思和Gamma阶段的计划阶段在同一周，但是经过两轮迭代之后对于之后的内容已经有很清楚的想法了。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们充分考虑成员提出的问题。对于不同意见我们通过讨论来解决，对于自己的任务有疑问或困难都可以向pm协商或者请求其他成员的协助，如果有原计划中不合适的项目将会在讨论后修改或者去除。
这一点无论是方针还是实施都从Alpha阶段一直保持。
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
完成了。对于无法完成的智能化的各种内容问题详见上文，我们及时走了另一条路着重对用户体验进行优化，达到了计划中的效果。
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
我们认为可能有一些相对价值较小的事，但是也仅仅是相对其他工作而言，因此所有工作都是必要的。
-
是否每一项任务都有清楚定义和衡量的交付件?
交付件：
- PM：博客、issue、文档
- 后端：可以提供给前端的接口
- 前端：可以提供给用户的界面
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
是有按计划进行。
Gamma阶段发现了超过预期的bug，造成了debug时间过长，这是由于前两个阶段的测试做得不够完善导致的，最终没有对整体造成大的问题。
-
在计划中有没有留下缓冲区，缓冲区有作用么？
有留下缓冲区。作用是像上一个问题中的意外情况都能够在有缓冲区的情况下解决，以避免造成更大的损失。另一方面缓冲区还能应对环境的变化，比如Gamma阶段其他课程有各式的考核，缓冲区也能在进度较缓的时候停下来去解决其他课程上的问题，这也是这一阶段我们仍然能够顺利进行的原因之一。比如在Gamma阶段按照各课程的进度，在5.31日没有开会，给全员留出了对另一门课的大作业的时间。
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
调整任务分配方式，将细分的当日任务和长远的任务计划结合，详见下一问。
我们学到了什么? 如果历史重来一遍,我们会做什么改进?
最大的修改是本项第一条中的"每天对团队成员分配当天任务"，这一点要改成每一位成员都会提前分配至少一周的任务，可能会有的变动和问题再商讨中解决。如此，成员会对自己的任务有一个充分且系统的认知，同时在完成任务后也会考虑之后会有的可能的变化，同时自身机动调节轻重任务，更加高效，而不是每天分配任务的时候由pm指定。
上文是Alpha阶段的回答，这里引用回来，Gamma阶段结束后，我们认为，Alpha阶段采取的细分的小任务模式方便监督和进度催促，对于刚开始不熟悉流程有很大的帮助，同时我们任务如果成员主动性不强可以通过这种方式适当施加压力催促。
对于上文提到的提前分配任务的方式，确实在提升积极性和对成员的大局观上有很大的好处，但是在Gamma的实践中发现这种方式对于环境变化的适应能力不足，当其他方面的压力来临，轻松的环境虽然有助于提升心情和积极性，也有造成摸鱼情况的风险，PM及时意识到并进行了适当调整。
因此最终的结论是将两种方法结合起来，首先对每个人的分工有一个大方向并告知，让他有一个完整的概念，然后将完成这个大任务需要的小任务进行细分。最初上手不熟悉的时候指定小任务，这会起到引领作用，相当关键；熟练上手环境稳定的时候就可以不需要指定小任务了，可以让成员自行完成，向大方向努力；当情况不稳定的时候就需要重新恢复到指定任务的情况，引领成员。总结起来就是大小结合，适度调整。
重来一遍我们就会采取上述策略，这样应该会更高效的完成任务，成员的体验也会更好。
资源
-
我们有足够的资源来完成各项任务么?
除人力资源外基本足够。在转会阶段之后我们组只有4个人，因此人员紧张，我们的策略是到中期让一位开发同学转为测试以确保各个阶段都有人把控。
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项所需时间估计基本准确。不准确的项目就是如上文所说的对接出现的意外。
-
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间足够。人力资源不足，如本节第一问所说。
软件资源足够，但是硬件上只有win10系统，对于自身制定的测试计划是足够的。已经能够做到详细的测试，在后文测试部分详细讲。
美工设计方面没有低估，在Alpha阶段之后在Beta阶段进行了一次大翻新，比起Alpha阶段的界面更加适合使用，但是进一步的设计和美化是在无能为力。
-
你有没有感到你做的事情可以让别人来做（更有效率）?
确实会有，但是每个成员都认为有自己的工作，也许不是最合适的，但是都是能解决的。当我们分工到个人，每个人的效率才会体现，而不是互相推脱。如果遇到困难，也能在其他成员的帮助下解决，这也是一种提升和学习的过程。
变更管理
-
每个相关的员工都及时知道了变更的消息?
是的。我们有重大变化会及时通过微信进行通知，即使没有及时查看微信，至少每天的例会上也会当面讲清楚。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
首先是pm在项目计划时指定核心功能和完成的内容，之后在实践过程中对功能有疑问或者意见及时反应后全员讨论决定。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有清晰定义，见[软件工程]功能规格说明书功能描述及验收标准。
-
对于可能的变更是否能制定应急计划?
能。若每日总结时发现有任务有困难，会及时对任务进行调整，添加临时任务或去除无用任务。
-
员工是否能够有效地处理意料之外的工作请求？
能。比如Gamma阶段发现adb监听需要用到接口可能会冲突，那么临时添加任务测试adb监听是否冲突，之后顺利解决。
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目冲刺开始前，设计阶段，由pm完成，pm进行总体设计并与成员进行交流细分任务。
是合适时间合适的人选。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有了，经过了Alpha阶段之后程序的基本框架已经定下，因此具体细节可以由开发人员自行决定，对于偶有的不清晰的地方与PM交流之后就能确定。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？
使用github进行项目管理，issue和燃尽图对项目进度进行监控，项目初期有原型图，是很实用的工具。
Alpha阶段没有做好测试，从Beta开始我们调整了测试的方式，首先是对单元测试和覆盖测试都进行了学习并应用到项目中，之后的Gamma阶段重新审视了黑盒测试的不足，制定了测试计划，使得整个测试变得完整，测试质量大大提高。
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
bug最多的是后端的异常处理，因为需要考虑各种情况难免有遗漏，之后测试阶段也都发现了并且修复掉了。
发布之后没有什么重大bug，但是收到的反馈中有一个影响用户体验的问题，他指出后端获取屏幕被拉伸了导致不好看，这个问题本身在[Gamma]Scrum Meeting#4中有提到："想办法将窗口变化大小适配图片或是将图片拉伸后通过计算得到原本坐标"，我们选择的是后者，因为我们在开发环境中使用模拟器进行测试，模拟器是默认横屏的，我们最初是担心分辨率问题导致图片不清晰，结果清晰度问题不大所以没有进行其他修改，但是对于连接手机来说竖屏拉伸之后比例就会比较难看，这确实欠缺考虑。
发布后发现路径带中文无法运行，因为在开发时直接用的代码和包装好的程序，没有额外进行完整的打包和对项目名字的纠结，因此没有发现路径的问题。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由后端负责人进行。是严格执行了代码规范。
测试/发布
-
团队是否有一个测试计划？为什么没有？
有测试计划。
-
是否进行了正式的验收测试？
-
团队是否有测试工具来帮助测试？
有的，通过coverage来进行覆盖，并且生成了单元测试报告和覆盖率报告，详情同样见Gamma阶段测试报告。
-
在发布的过程中发现了哪些意外问题？
没有遇到意外。
团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
通过个人意愿、实践经历和个人能力决定的。
我们认为做到了人尽其才。
-
团队成员之间有互相帮助么？
有。包括但不限于线上讨论、例会交流、直接面对面查看等等。
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
不紧急的有因为麻烦而直接在例会反馈，紧急的bug或者问题时候也有直接到宿舍找人当面讨论。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
我们认为经过三轮迭代已经达到了已管理级的要求，开发过程中确实将任务具体到个人也将任务细分的具体且精细，也能够通过例会和燃尽图进行监控和管理，对于任务的验收落实方面较之Alpha阶段有所提高。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我们认为团队处于规范阶段，但已经能看到创造阶段的一些现象：
- 角色和职责能够根据项目的要求自然地转换，在项目冲刺中期由开发转为测试的同学能迅速上手测试的任务。
- 高度自治。不再需要领导的时时教诲与介入。从Beta阶段开始为每个人分配告知了长远的任务的，因此成员对自己的任务有总体认知，能主动完成任务、提出问题、解决问题。
相对的，离创造阶段还缺乏的，比如完全集中注意力到目标上，这一点在Gamma阶段受到环境的影响，成员都有其他课程的压力。比如独立放手工作上，由于能力的不足或者其他的各种原因，还无法达到。
团队成员们必须努力工作，才能使团队保持在这一阶段, 他们同时还要抵御外界的压力，以免使团队分裂，或者回到磨合阶段。
老师讲到的规范阶段的情况，我们认为十分符合我们当时的状态，如果我们能提升自己、低于外界压力，团队就能更进一步，但是如果无法抵御的话，就可能回到磨合阶段。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
6.无论团队内外，面对面的交流始终是最有效的沟通方式。事例：每天(除清明放假)进行例会报告情况，面对面进行交流。
7、可用的软件是衡量项目进展的主要指标。事例：我们团队做的是从0到1的项目，在alpha阶段任务尤其重，因此果断舍弃了对界面的优化设计，着重对核心功能进行实现，在阶段完成交付了可用的软件。
11、只有能自我管理的团队才能创造优秀的架构, 需求和设计。事例：我们的成员能主动完成任务，自主提出问题，比如Gamma阶段发现adb监听需要用到接口可能会冲突，那么临时添加任务测试adb监听是否冲突，而不是想到了先把功能往上一加，不能用在去掉。
改进：
- 设计并美化前端
- 进一步提升用户体验
讨论照片
