Gamma阶段事后分析
作者：互联网
目录
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们在Beta，Gamma阶段的软件主要解决用户在线答题，评论，以及上传题目的问题。我们的软件功能定义很明确，就是要打造一个物理理论考试的复习与自我测试的在线答题平台，对于用户和场景都很明确，主要用户是选修大学物理或大学物理实验的同学以及物理实验教师，主要场景也是在线答题，评论以及上传题目。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 我们达到了目标，原计划的功能全部实现了，也按照原定交付时间交付了，我们原计划的用户为100人，但是由于题量不是很丰富，并且现在不是考试的时期，用户需求不大等原因，现在为50人左右。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
- 和Alpha阶段相比，软件工程的质量有所提高，相对于Alpha阶段，我们在每次commit代码时，更加详细地注解每次commit的功能。此外在Alpha阶段提交代码时，都是各自commit后然后自行关闭issue，而在beta，gamma阶段都是大家开完例会后报告给PM，再由PM统一管理issue，这样PM就能更加及时详细地了解项目进度，并及时调整大家工作分配和进度，能让大家的合作更加协调，提高工作效率。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户量没有达到，用户对于重要功能的接受程度基本和我们事先的预想一致吧。我们离目标近了很多了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 经验教训就是，我们没有提前找题目，等到测试和发布时再找题目已经很紧迫了，最终导致题目量不足，发布时对于用户的吸引力大大减小了，此外在展示时，老师提到自动生成试卷也是一个好的方向，我们目前只是完成了一个在线答题平台所应具有的一些基础功能，其实还可以有更多的进步空间，希望下一届能够继续改进吧。
计划
是否有充足的时间来做计划?
- 我们在Beta，Gamma阶段都使用了一整周来进行计划，所以我们认为我们的计划还是比较充分的。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 通过协商讨论，各抒己见，PM从中调和，达成一致意见。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 都做完了并且按时交付了。
有没有发现你做了一些事后看来没必要或没多大价值的事?
- 我们认为我们题库所有的功能都是有着其重要的意义的，这些功能都能够支撑整个项目存活下去，并不断改进发展其吸引力。
是否每一项任务都有清楚定义和衡量的交付件?
- 我们在实现每一个功能前都做好了详细的规划目标，在排版布局方面遵从Beta阶段的风格，使得每个功能完美对接。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 项目的代码工程按计划进行了，只是到最后才发现题目量不太充足，我们只是到下一届的群里要到了一些试题，但是没有更多的或的题目的途径，如果能够和物理老师沟通交流一下可能会取得更好的效果。这些主要都是由于我们太注重软件实际的功能，而对这些软件之外的东西考虑不足吧。
在计划中有没有留下缓冲区，缓冲区有作用么?
- 有，主要是缓冲计划，不至于太赶。
将来的计划会做什么修改？
- 会留出更多的时间给缓冲吧，以后再开发软件工程的话。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 产品的功能是一方面，而产品所提供的服务又是一方面，不能只实现了功能，而没有考虑给用户更好的体验，如果历史再来一遍，我们会留出更多的缓冲区去实现软件代码以外的产品服务。
资源
我们有足够的资源来完成各项任务么?
- 我们队伍中有两个比较熟悉这方面开发的队员，他们对于前端以及后端的把控都十分出色，所以我们有充足的资源来完成我们的任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?
- 主要依据Alpha阶段的队员效率来估计的，不同队员的效率不同，擅长也不同，就扬长避短，尽可能使得整个项目平稳进展。整体项目精度还可以，主要是由于一些deadline的出现，可能会占用队员的时间，在完成这些deadline后，队员的效率明显加快了许多。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试的时间，人力和软件/硬件资源是足够的。主要还是低估了寻找题目的难度。
你有没有感到你做的事情可以让别人来做（更有效率）?
- 有些同学擅长web开发，有过经验，可能他做哪个任务效率都很快，而有的同学在完成任务前需要学习，那么效率肯定慢一些，但是可能把所有的任务都交给效率快的同学吗？答案是不可以。如果把所有的任务都交给效率快的同学，那这样就没有办法锻炼所有人了，这样熟练的同学还是很熟练，不熟练的同学还是什么都不会，那么我想这门课的意义肯定大大减小了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 我们应该会专门分出人员去寻找题目或者去和物理老师进行沟通。
变更管理
每个相关的员工都及时知道了变更的消息?
- 我们在高速开发时期，每天都有例会，此外如果有重要的通知我们也会及时在微信群里进行通知，而且只有所有人都回答“收到”，我们才认为所有人都知道了消息。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 主要是例会讨论，每个人发表意见，并发表看法，最后由PM整合意见。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 实现了我们想要的功能，能够给用户比较舒适的体验，能够满足用户的需求，经过测试，没有比较影响功能或者用户体验的bug。
对于可能的变更是否能制定应急计划?
- 比如在Gamma阶段初期，我们所有队员都有deadline，但是我们能够及时调整任务，把控项目进度，最后在deadline后及时进入快速开发，最后按时交付了项目。所以我认为我们能够根据可能的变更制定应急计划。
员工是否能够有效地处理意料之外的工作请求？
- 有些同学可能在一段时期很忙，不能有效处理，但是我们也会进行沟通，及时调整分配任务，可以通过PM调度到有空闲时间的同学身上。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 处理突然的变更是有效率损失的，如果再来一遍，我们会更多地考虑计划，最小化变更的出现几率。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作是在项目的起始阶段(每个迭代的第一周)由PM完成，PM是最了解需求的岗位，所以是合适的时间也是合适的人完成的。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 遇到过，比如网页的布局什么的，都是由负责的人互相协商解决的。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 我们运用了单元测试、gitlab代码管理、issue进度管理等工具，这些工具比较有效，我们没有UML文档。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 主要是前端出现了一些比如页面晃动，页面大小不合适的bug，这些是由于前端代码比后端更加繁琐造成的，但是最后也没有造成很不好的影响，这些bug一旦发现，是比较好处理的。在发布之后没有发现什么bug，bug的出现可能是由于开发人员的失误等等原因造成的，这些在设计时也无法预估到具体是哪些bug。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 我们在前端代码以及后端代码各有一位比较熟练的同学进行代码复审，比较严格地执行了代码规范。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
- 设计的越明确，越能减少推翻重来的可能性，也就越提高效率， 如果重来一遍，我们会把每个人负责的任务在设计阶段就以文档形式发放给每个人。
测试/发布
团队是否有一个测试计划？为什么没有？
- 有。就是让我们每个组员模拟真实用户以用户需求为导引进行测试，我们对于我们的重要功能的代码进行了单元测试
是否进行了正式的验收测试？
- 根据不同的浏览器，模拟用户进行了验收测试，还算比较正式。
团队是否有测试工具来帮助测试？
- 例如单元测试等。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 主要是测试这个请求响应的耗时，加载页面的速度，以及最后报告生成的准确度。这些工作都非常有必要，因为这都和用户体验息息相关，我们应该在细节上更加注意，精益求精。
在发布的过程中发现了哪些意外问题？
- 发布时发现题目数量不是很充足，影响了用户数量。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
- 测试应该更早地进行，需要留出更多的时间给缓冲。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
- 主要是通过这个自愿报名，然后进行分工吧，人尽其才不好说，每个人做了自己想做的事情吧。
团队成员之间有互相帮助么？
- 有的，我们有问题会及时在微信群及时交流。此外，如果有的同学遇到了问题可以向有经验的同学请教，我们在Alpha阶段甚至用过远程协助来帮助同学处理一些配置环境的问题。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 主要是在群里或者例会中讨论，以理服人。
总结:
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 规范吧。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 我们在这个里程碑中终于找到了我们的核心功能，不过在我们的项目展示中，老师引导我们给了更多的思路，我们的题库功能还有很大的改进空间(比如自动生成试卷)，这些可能要留给下一届的同学来完成改进它了。
你觉得目前最需要改进的一个方面是什么?
- 技术学习，提高大家积极性。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 无论团队内外，面对面的交流始终是最有效的沟通方式。比如说，我们有问题都放到每日例会上来讨论，及时把问题沟通清楚。
- 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势。比如说，我们经常讨论如何让我们的这个物理实验网站变得更加有吸引力，应该向哪些方面扩展。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
- 代码要保质保量，定期进行代码复审。
- 完善我们的文档，让我们的产品更加规范化。
标签：功能,代码,用户,事后,阶段,测试,团队,我们,Gamma 来源： https://www.cnblogs.com/mizhiniurou/p/11086776.html