Beta阶段事后分析

设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

    答：解决当前社团管理问题，定义比较清楚，有清晰描述。具体说明

  2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

    答：计划的功能基本上都实现了，当前主要问题就是小程序没有过审，并且因为小程序的原因，用户数量没能达到预期。

  3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

    答：提高了，任务进展速度比上一阶段快了不少，不仅上一阶段的bug都解决了，并且基本功能都已经实现，并且项目管理更加的规范，任务更加细分，GitHub使用更加频繁。

  4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

    答：不一致，离我们的目标更接近了。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

	答：应该更加及时的关闭issue，更早的将小程序进行审核。

计划

  1. 是否有充足的时间来做计划?

    答：有的，一周的时间足够我们对项目重新进行规划和反思。

  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

    答：计划都是在开会讨论的过程中定下来的，如果有不同意见，提出自己的方案，并提出理由即可。

  3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

    答：基本上都做完了。

  4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

    答：没有。

  5. 是否每一项任务都有清楚定义和衡量的交付件?

    答：定义十分清楚，交付需要在开会时展示代码，并且需要将代码上传到服务器后在网页端测试无误，才能交付。

  6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

    答：基本上都是按照计划进行的，唯一的意外就是小程序多次不过审，主要原因是小程序审核规则在一年间变化过大。

  7. 在计划中有没有留下缓冲区，缓冲区有作用么?

    答：有缓冲区的，每个任务期限都比较长，并且会因为计网实验等因素进行延长；有作用，缓冲区能够让他们有充分的时间开发，但是在一定程度上会产生拖延的现象。

我们学到了什么?如果历史重来一遍, 我们会做什么改进?

 答：我们学到了在对项目没有了解充分的情况下，不要轻易地做计划，任务的划分也不能太粗线条，粒度要细，争取每一天都要有进展。

资源

  1. 我们有足够的资源来完成各项任务么?

    答：经过alpha阶段之后，我们每个人都进步不小，基本上掌握了相关的知识，可以完成各项任务。

  2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

    答：因为是第二次分配，对任务有了更好的理解，根据第一阶段相关工作所花时间，进行任务规划和资源分配，精度不错。

  3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

    答：足够，我们分配给后端一人在开发全程进行测试工作，美工设计尽量沿用上一届的思路，难度降低不少。

  4. 你有没有感到你做的事情可以让别人来做（更有效率）?

    答：可能全栈大佬来做PM会更有效率，安排也更加合理。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

答：任务的粒度可以更加细分。

变更管理

  1. 每个相关的员工都及时知道了变更的消息?

    答：β阶段转走和转入一名同学，在会议上都已经进行了说明，大家都知道变更信息。

  2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

    答：“推迟”就是不影响整体进度的功能，需要开会讨论，其他的功能都是必须实现。

  3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

    答：在截止日期前能够完成尽可能多的功能，并且目前已经完成的功能在使用过程中不会出现致命bug，则我们的项目就能够出口了。

  4. 对于可能的变更是否能制定应急计划?

    答：可以的，在图片上传中间件没有调试好时，我们采用图床来储存相关图片。

  5. 员工是否能够有效地处理意料之外的工作请求？

    答：能够，后端的工作更多的靠前端推动，比如api的提出，以及api的修改，这些工作都是十分的突然，但是都处理的很好。

我们学到了什么?如果历史重来一遍,我们会做什么改进?

答：我们学会了这种任务驱动型的工作方式，合作更加的紧密。

设计/实现

  1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

    答：设计工作在计划的那一周进行的，是合适的时间，大家一起设计的，比较合适。

  2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

    答：无。

  3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

  4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

    答：社团信息编辑产生的bug最多，因为前端和后端没有沟通好，导致数据类型不合适，并且部署上也有问题，发布之后没有特别大的重要bug。

  5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

    答：主要由组员yzx进行负责，代码签入和bug修复，都需要由负责人员和yzx单独展示。遵守了代码规范。

我们学到了什么?如果历史重来一遍, 我们会做什么改进?

​ 答：我们学会了如何减小代码签入引入bug的风险，如果历史重来，我们将会更加贯彻这一点。

测试/发布

  1. 团队是否有一个测试计划？为什么没有？
    答：我们的测试计划就是在保持回归测试都正确的前提下，不断添加对新增API的测试部分，并保证其正确性。

  2. 是否进行了正式的验收测试？
    答：在实现了项目的总体功能后，我们将前后端代码合并并进行了单元测试及场景测试作为验收测试，确保整体功能无误。

  3. 团队是否有测试工具来帮助测试？
    很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
    答：我们主要使用 rails test 及 simplecov 插件帮助测试。

    • 相较于手动测试，书写测试文件更有事半功倍的效果，不用每一次都对旧的功能再进行一遍手动测试，同时通过 rails test 的结果也可以观察到是代码错误还是测试失败，或是其他一些问题。
      simplecov 插件使测试覆盖率有了更直观的体现，帮助我们增添了大量未覆盖部分的测试代码。

  4. 在发布的过程中发现了哪些意外问题？
    答：小程序因为各种奇怪的理由无法通过审核。

我们学到了什么?如果重来一遍, 我们会做什么改进?
答：我们可能会自费更好的服务器，方便开发，能够承受压力测试。

团队的角色，管理，合作

  1. 团队的每个角色是如何确定的，是不是人尽其才？

    答：团队角色一般采取认领的方式，大家先在群里讨论出前端和后端的具体分工，然后大家自行认领，基本上算得上人尽其才。

  2. 团队成员之间有互相帮助么？

    答：有，后端的工作一般都是寻找api的bug，后端常常一起负责。前端经常进行技术交流。

  3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

    答：一般通过PM来寻找合作的同学，尽量发挥PM的协调作用。

每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

我感谢 _______<姓名>______对我的帮助， 因为某个具体的事情: _____________________。
李堂训：我感谢徐雁齐对我的帮助，因为在我对小程序刚开始修改时，提供了不少技术上的帮助。
徐雁齐：我感谢张家榕对我的帮助，和我一起讨论场地查询api的设计，并在开发过程中解答了我很多技术上的问题，推进了项目的进展。
张家榕：我感谢颉哈郗对我的帮助，完善了后端程序的测试部分，对项目的推进帮助很大。
颉哈郗：我感谢张家榕对我的帮助，耐心指导我使用git，帮助大家管理后端代码，解决了图片上传学生认证等难题，在后端发挥了巨大的作用。
许天立：我感谢李堂训对我的帮助，因为在我刚进入小组，学习小程序开发相关知识的时候，他给了我引导。
叶志翔：我感谢颉哈郗对我的帮助，写了大量的测试文件，检测出很多潜在的问题，不仅提高了代码覆盖率，更是帮助我们定位了bug。
黎明：我感谢李堂训对我的帮助，因为他经常及时提醒我开会，并且分配、记录任务，有效推动了项目进展。

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

​ 答：CMMI一级，完成级，项目目标和要做的事情都很清晰，但是在完成项目的过程中，往往会遇到很多的困难，完成具有很大的偶然性。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

​ 答：属于磨合阶段，主要是开发过程中没有严格按照流程进行。

你觉得团队在这个里程碑相比前一个里程碑有什么改进?

​ 答：代码规范，任务进展，测试等等方面相对于上一阶段有很大的进步。

你觉得目前最需要改进的一个方面是什么?

​ 答：工作流程还是需要改进，GitHub还是没有按照规定使用，上传代码、issue关闭不及时。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

  • 业务人员和开发人员在项目开发过程中应该每天共同工作 。我们基本上每次会议时间都会超过1个小时，在这个时间里大家一起讨论问题，解决问题，并且向PM提出一些资源上的要求。
  • 可用的软件是衡量项目进展的主要指标。每次例会我们主要通过展示自己部分代码的效果来确认工作量。

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

  1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

    答：GitHub上传要更加的及时，需要灵活的使用issue机制。

  2. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

    答：小程序还是没有审核通过，因此用户数据较少。

  3. 项目文档的质量如何提高？

    答：在新增api和网页新的功能时，需要添加新的文档内容。

  4. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

    答：我们贡献评价体系太过笼统，可以加入互评的体系。

  5. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。

    答：我对代码规范必须是一个人负责比较认可，因为如果每个人的代码按照自己的标准必然会造成阅读上的困难，所以在这一阶段，我们按照严格的代码标准进行开发。

讨论图片

posted @ 2020-06-10 22:12  Roger海贼团  阅读(160)  评论(2)  编辑  收藏  举报