20201120-2 Beta事后诸葛亮会议

此作业的要求查看:作业要求 20201120-2 Beta事后诸葛亮会议

小组信息

组名: null

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

组长: 谢文强

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

1.设想和目标

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

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

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

答:原计划的主要功能顺利完成,并且按原计划交付时间交付。原计划达到的用户数量达到了,原计划用户数为50,已注册用户数量65。

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

答:和上一个阶段相比,团队软件工程的质量提高了。这一阶段,产品的细节优化和bug修复正在有条不紊地进行,从用户的建议中可看出本产品的用户体验提高了许多。

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

答:已注册用户数量65,活跃用户数量205,超出了我们事先设想的数量,也是对我们产品的认可。用户对重要功能的接受程度和我们事先设想的一致。我们当前的进度符合计划进程,我们考虑了用户的建议,在实现基本功能的基础上完善了其他功能,并进行了细节优化,修复了一些bug。经验教训就是在开发过程中尽量规范代码,避免不必要的问题。

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

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

2.计划

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

答:我们的Beta阶段工作已经基本完成。但是由于时间紧张,所以有两个功能还未完善。

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

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

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

答:由于时间紧迫,原计划的工作还差两个小功能没有完成。

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

答:是的,我们的整个Beta阶段都是按照计划有序的进行。

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

答:我们在计划中对无法预测的任务留下了缓冲区,当计划不能按计划完成时,我们会在缓冲区中努力完成任务。

将来的计划会做什么修改?(例如:缓冲区的定义,加班)

答:将来的计划我们会根据课程的变化和组员的变化动态的进行修改。会把时间分配的更加合理,提高效率。

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

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

3.资源

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

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

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

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

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

答:足够,没有低估难度。

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

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

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

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

4.变更管理

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

答:是的,我们每天都有Scrum立会并且在课余时间通过微信群发布变更消息。

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

答:我们根据项目的定位和核心功能决定“推迟”和“必须实现”的功能,核心功能都是“必须实现”得功能。对于工作量大的功能以及非必须功能在组内协商后可以进行推迟。

项目的出口条件(ExitCriteria)有清晰的定义吗?

答:出口条件为可以让用户做测试题并给出准确的测试结果项目并推送推荐内容。

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

答:可以,我们组内和谐并且相互帮助。在紧急的情况下可以通过视频会议对可能的变更制定应急计划。

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

答:不可以,因为员工的工作经验有限。但是我们会尽我们最大的努力完成任务。

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

答:我们将提高每个人的参与感,让每个组员都体会到项目的成长和自己的成长,并且让组员体验到更多的工作,大家一起成长。

5.设计和实现

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

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

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

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

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

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

什么功能产生的Bug最多,为什么?

答:当前产生bug最多的功能是散散心功能,因为此功能逻辑复杂,并且有多个不同的接口需要实现。

代码复审(CodeReview)是如何进行的,是否严格执行了代码规范?

答:在完成任务后,负责人先自己复查代码,然后我们将代码上传到代码托管平台后,所有组员review代码。产品上线后,组员体验程序并查找bug。暂未严格执行代码规范。

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

答:如果历史重来一遍,我们将严格执行代码规范,并且会将小程序的功能设计的更加完善。

6.测试和发布

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

答:有测试计划,但是因为是Beta阶段,时间较紧,我们没有进行全面的测试。我们对所以实现的功能在组内进行了测试。

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

答:我们组内成员对小程序进行体验,如果没有bug,验收测试通过。

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

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

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

答:我们团队该阶段还没有涉及到效能测试。

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

答:我们在alpha发布的小程序因域名未备案而被腾讯禁止访问。我们紧急换了一个备案过的域名。我们在beta发布遇到了停电,停网。

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

答:对重要的功能进行测试和效能分析优化。提前发布作品,防止意外的发生。

总结

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

答:我们的团队目前的状态属性CMM/CMMI中的“可管理级”。

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

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

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

答:提高组员的合作热情,让组员在合作中学习到更多的知识。

讨论合照

技术博客连接

1.Taro && 微信小程序

posted @ 2020-11-21 21:59  null小组  阅读(23)  评论(0编辑  收藏