Beta阶段事后分析

Posted 2020-12-10 rogerpirates

设想和目标

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. 团队是否有一个测试计划？为什么没有？

2. 是否进行了正式的验收测试？

3. 团队是否有测试工具来帮助测试？

很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

5. 在发布的过程中发现了哪些意外问题？

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

团队的角色，管理，合作

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

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

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

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

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

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

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

我感谢 _______<姓名>______对我的帮助， 因为某个具体的事情: _____________________。

总结:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   答：我对代码规范必须是一个人负责比较认可，因为，我们当前的代码因为赶工期，代码没有严格按照之前的风格进行书写，如果代码下一届继续开发，可能会带来阅读上的困难。