此作业的要求查看：作业要求 20201029-3 事后诸葛亮会议

小组信息

组名: null

组员: 龚万福，夏柳青，胡希雅，杜蕾，张宵，赵新萍

组长: 谢文强

null小组的“心灵捕手”项目事后诸葛亮会议结果

1.设想和目标

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

答：“心灵捕手”是一个基于微信小程序的心理健康测评软件，我们的软件要解决的问题是为用户提供一个测试心理健康状态的工具。致力于解决用户的动态心理抑郁情况监测和初步筛选抑郁症。定位清晰，针对的是日常心理测试和初步筛选抑郁症。典型的用户和典型场景描述在选题需求分析视频展示中进行了清晰的描述。

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

答：我们组有充足的时间来做计划，在选题前后，我们对组员的技术栈进行调查null团队技术栈调查，根据组员的擅长点做出计划。以此提高工作效率，降低开发难度。

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

答：我们每天都有站立会，当遇到不同的意见时，我们现场发表不同意见的理由，随后全体对不同的意见进行投票（投票的形势遵循少数服从多数的原则）。根据投票决定计划执行方式。

用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？

答：当前用户量为56位，超出了我们事先设想的数量，也是对我们工作的认可。用户对重要功能的接受程度和我们事先设想的一致。我们当前的进度符合计划进程，实现了基本功能，所以我们现在离目标更近了。经验教训就是在开发过程中尽量有Plan B,以避免项目搁浅。

如果历史重来一遍，我们会做什么改进？

答：如果历史重来一遍，我们会在任务分配上做出改进，细化时间和人员分配。

2.计划

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

答：我们的alpha阶段工作已经全部完成。当前正做alpha阶段的总结和beta阶段的准备工作。

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

答：暂时没有发现没有必要的事，alpha阶段做的所有事都很有必要，就算是走的弯路也是我们项目开发的经验积累，避免下次在同样的地方走弯路。

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

答：是的，我们每一项任务都会在站立会上做出明确的说明，并在完成时检查是否符合要求。对可以公开的任务，我们还会写出博客供大家参考和检查。

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

答：是的，我们的整个alpha阶段都是按照计划有序的进行。

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

答：我们在计划中对无法预测的任务留下了缓冲区，当计划不能按计划完成时，我们会在缓冲区中努力完成任务。如域名的备案任务，域名备案未能按时完成，我们在缓冲区时间解决这个困难。

将来的计划会做什么修改？（例如：缓冲区的定义，加班）

答：将来的计划我们会根据课程的变化和组员的变化动态的进行修改。如被更换组员的任务交接。

如果历史重来一遍，我们会做什么改进？

答：在任务遇到不可解决的困难时，我们应及时的在小组中做出说明，大家一起想办法解决。

3.资源

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

答：有的，我们小组中有的组员有小程序开发经验，小程序开发教程也比较完善。并且我们用服务器为小程序提供服务。

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

答：我们先在站立会上预估任务所需的时间，然后留下缓冲时间。并且在任务分配时结合组员的实际情况分配。精度精确到小时。

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

答：我们的各项资源都足够。

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

答：有，但是我也按时完成了任务。在任务分配时，我们已经询问了组员的实际情况和意见，当前分配已经是最优解，任务可以准时完成即可。

如果历史重来一遍，我们会做什么改进？

答：我们会为重要的任务留下更多的缓冲时间和人员分配，以保证任务的出色完成。

4.变更管理

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

答：及时的知道了，因为我们每天都有站立会并且有变更消息都会在群里通知大家。

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

答：我们根据项目的定位和核心功能决定“推迟”和“必须实现”的功能，核心功能都是“必须实现”得功能。

项目的出口条件（ExitCriteria）有清晰的定义吗?

答：可以让用户做测试题并给出准确的测试结果项目的出口条件。

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

答：可以，我们组员可以通过视频会议对可能的b变更制定应急计划。

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

答：不可以，因为员工的工作经验有限。但是组员可以在站立会上对其他组员的请求进行力所能及的帮助。

如果历史重来一遍，我们会做什么改进？

答：我们将提高每个人的参与感，让每个组员都体会到项目的成长和自己的成长。

5.设计和实现

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

答：设计工作是在选题结束后立即进行的。由组长牵头，大家一起参与完成的。尽量服从有设计经验的组员的建议。是合适的时间，合适的人。

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

答：有，对模棱两可的情况，我们会设计出两个草图，让组员讨论并作出抉择（投票的形势遵循少数服从多数的原则）。

团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？

答：对部分功能我们利用工具来帮助设计和实现，如利用postman软件测试接口功能。这些工具有效。我们对整体功能的测试是通过组员和用户共同完成的。

什么功能产生的Bug最多，为什么？

答：答题历史记录产生的Bug最多，因为这个功能涉及的数据库表是最多的，也是逻辑比较复杂的。

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

答：在完成任务后，负责人先自己复查代码，然后我们将代码上传到代码托管平台后，所有组员复审代码。因为alpha阶段时间紧，没有严格执行代码规范。

如果历史重来一遍，我们会做什么改进？

答：如果历史重来一遍，我们将严格执行代码规范。

6.测试和发布

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

答：有测试计划，但是因为是alpha阶段，我们没有进行全面的测试

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

答：没有，时间有限。我们没有进行正式的验收测试。

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

答：我们有测试工具来帮助测试，当前已经用的有postman软件测试接口功能。

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

答：我们团队还没有涉及到效能测试。

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

答：我们测试发布的小程序因域名未备案而被腾讯禁止访问。我们紧急换了一个备案过的域名。

如果历史重来一遍，我们会做什么改进？

答：尽量提前将域名备案，对重要的功能进行测试和效能分析优化。

总结

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

答：我们认为目前的状态属性CMM/CMMI中的“可管理级”。

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

答：我们团队目前属于规范阶段。

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

答：加强合作关系，争取得到1+1大于2的效果。

讨论合照

技术博客连接

1.Docker 部署和运行Web服务

2.Django Rest Framework的创建、配置和简单使用