团队作业6——复审与事后分析

作业所属课程	课程
作业要求	作业要求
目标	复审与事后

一、Alpha阶段项目复审

• 复审博客
  
  

二、事后诸葛亮分析

一、 设想和目标
1.1 我们的软件要解决什么问题？ 是否定义得很清楚？

• 本小程序解决咨询对象的心理方面存在的问题。
• 定义很清楚。
• 具体见https://www.cnblogs.com/zxccode/p/15496793.html。
  1.2 我们达到目标了么？
• 我们已推出体验版心灵社区，能按原计划交付时间交付。
• 由于体验版人数有限，已在班群发布，并邀请部分人员进行体验
• 

1.3 用户对重要功能的接受程度和我们事先的预想一致么?

• 目前只有体验版，尚未正式发布，内测用户基本能接受软件提供的功能。

二、 计划
2.1 是否有充足的时间来做计划?

• 有，并在相应时间内制定了较为详尽的计划。

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

• 团队成员若对计划产生分歧，则令其分别论述其观点的优势所在与对方观点的劣势所在，通过少数服从多数的原则决定团队计划。

2.3 原计划的团队工作是否最后都做完了?

• 基本做完了，因为是第一次团队项目，我们会根据实际情况来制定最近的计划，我们会隔一段时间再给出之后一段时间的计划，并根据变化及时修改计划，完成计划的迭代。

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

• 没有，做的每一件事都有他相应的价值，哪怕是绕了一些弯路，我们也可以从中吸取经验，得出更好的方法。

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

• 每一项任务都有相对详尽的定义以及衡量的交付件。

2.6 是否项目的整个过程都按照计划进行？

• 项目的整个开发过程基本都能按原定计划进行。
  2.7 在计划中有没有留下缓冲区，缓冲区有作用么?
• 计划中留有空余的时间供团队成员合理分配自己的工作用时，我们认为是有作用的。
  2.8 将来的计划会做什么修改？
• 继续完善补充功能，争取小程序的上线发布。

三、 资源

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

• 资源相对充足。一方面，网上有相应教程与资料，另一方面，我们有进工作室的同学作为外援，可以说是我们团队的指导老师。

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

• 以软件的各个功能为单位，对所需时间进行估计，精度为天数。

3.3 测试的时间，人力和软件/硬件资源是否足够?

• 所有成员都一起进行软件测试，通过在不同环境不断运行调试，资源相对足够。

3.4 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

• 对于美工的设计以及文案的设计我们也给予了高度的重视，前端是我们项目的着重点，因此做的非常好。

四、 变更管理

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

• 可以及时知道变更消息。更新的代码能及时上传到团队的码云中，重要消息也会在团队微信群中通知。

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

• 参考之前写的需求与系统设计博客:
  《需求规格说明书》（https://www.cnblogs.com/zxccode/p/15526072.html）
  需求改进&系统设计（https://www.cnblogs.com/zxccode/p/15558938.html）。
• 在微信群聊交流总结。

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

• 完成以下条件即可出口：
• 各模块之间连接无明显问题。
• 实现发布，查看，搜索，聊天的基本功能。
• 实现登录评论、编辑个人信息等的必要辅助功能。
• 日常使用中不出现明显bug。

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

• 有，如有变更我们会迅速拟定会议时间开会，及时给出应急计划。

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

• 由于经验不足，有时一些新增的需求与改进，组长带领组员一起讨论，最后基本都解决了。

五、 设计/实现

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

• 设计工作在确定选题后开始的，并在需求分析时不断改进。
• 由团队的所有成员讨论确定。
• 由于是小团队的小项目，故时间与人员都较为合适。

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

• 参考原始方案，然后展开讨论，最终确定方向。

5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
　我们用到了单元测试工具，这边为了测试不用模块的功能。这些工具也是极大了提高了我们的测试效率。

5.4 什么功能产生的Bug最多，为什么？
广场这一模块的功能产生的bug最多，因为需要注意到很多的细节。

5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由开发人员，PM负责。在代码复审时会严格查看开发人员的代码规范的。

六、测试/发布

6.1 团队是否有一个测试计划？为什么没有？

• 有。团队有一个较为详细的测试计划，具体参照（https://www.cnblogs.com/zxccode/p/15558938.html）

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

• 有。 对所有功能都进行了测试。

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

• 有。使用junit进行单元测试。

6.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们将各个模块的测试进行分配，每个组员进行用例测试。最后的运行结果证明了测试工作还是有用的，发现了很多之前没发现的潜在问题，并及时解决。

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

• 暂时没有。

六、总结

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

• 二级，还能继续进步，还在继续补充功能。

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

• 在团队任务分配方面更加规范和明确，大家彼此之间也更熟悉，相较上一个阶段感觉更加顺利。

6.3 会议照

七、团队评分

• 团队总分=20*6=120

• 姓名	学号	团队贡献分	可验证模块
  周讯超	3119005352	23	ui设计兼部分前端页面
  林佳浩	3119005329	22	后端开发
  黄欣茵	3219005356	21	pm
  江男辉	3219005357	19	设计更新，队伍评价
  夏依达	3219005359	18	博客编写，队伍评价
  阿卜杜乃比	3119005315	17	部分前端页面