“事后诸葛亮”分析

“事后诸葛亮”分析

1. 会议照片：

• 出于最近课程作业较多成员较为忙碌，改为微信群聊讨论的会议方式

2. 会议分析内容：

设想和目标

• 我们的软件要解决什么问题？

为广大热爱网购或者只能通过网购这种渠道获取自己想要的商品的群体，以及需要售货渠道的商家，提供一个线上的购物商城；

• 我们达到目标了么?

没有，迫于时间成本只实现了软件其中的部分功能：
实现了用户登录注册、商家的登录注册，商家对后台商品的增删改查管理、用户的首页浏览商品，首页导航栏、商品的分类，以及商品加购和购物车展示功能；
未实现当初设想的收藏，订单管理，支付功能以及个人中心的信息管理功能（这些功能仅有静态的只供查看页面的功能，原因为时间不够继续做前后端的交互）

计划

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

有，但是迫于需要不断学习新技术而不够做完一整个项目。

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

没有，因为队内成员全是初次做项目，没有相关的合作开发经验，并对相关技术的了解一片空白，需要在兼顾其他科目学习的情况下学习相关技术的原理，因此时间窘迫。

• 是否项目的整个过程都按照计划进行，项目出了什么意外?

没有，时常会因为其他科目的学习而影响到项目的进行，比如在计划时间内学习相关技术并提前布置好开发的框架这一过程中，便因为其他科目的影响以及低估了相关技术的学习时间而来不及实施。

• 将来的计划会做什么修改？

会根据本阶段队内成员展示出来的学习能力以及抗压能力做出适当的调整，例如延长开发周期，组织技术交流分享会议等。

资源

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

有，网上有相关的开发讲解视频以及博文，可以通过学习他们的经验来进行开发。

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

组长（兼 项目经理）通过网上相关视频以及博文学习该如何预估任务量，但预计任务量的精度较差，尤其体现在前后端交互的任务量预估上。

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

测试的时间并不足够，在人力上资源足够，但在相关的软硬件资源上（由于缺乏经验，对测试软硬件的了解不足）并不足够，对于那些不需要编程的资源的难度并不会低估。

变更管理

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

是的，组长通过微信群或者私聊，以及码云gitee的 issue 及时告知队员相关的变更信息。

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

在做需求分析以及需求改进时就已经根据每个功能的难易以及重要度做出“推迟”和“必须实现”的决策。

• 项目的出口条件有清晰的定义么?

有。

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

能，例如在本次开发过程中出现了前端进度跟不上计划进行的情况，并因此制定了调动其他成员参与前端开发的计划

设计/实现

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

设计工作在确定选题以后就开始由组长（兼项目经理)进行分析需求以及设计原型，并在制定完计划后组织相关成员共同完成系统设计。

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

并没有，成员根据组长的需求分析并按照组长的指挥安排完成各自的工作

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

开发过程是后台连接数据库的交互部分，经常出现数据库数据类型与前后端匹配不上的情况，测试与发布过程是登录注册界面功能经常出现bug，理由是前端获取登陆注册数据的判断逻辑出现错误；

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

在项目冲刺初期由项目经理制定了代码风格规范，并及时更新到GitHub上；并没有严格执行代码规范，例如在前端开发上文件的命名出现了不规范现象（以中文拼音直接命名）。

测试/发布

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

有。测试人员在开发人员开发完某个功能后便会组织进行相关的单元测试或者集成测试。

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

没有，但是进行了由测试人员与开发人员进行面对面交流探讨并现场演示软件功能，以此替代验收

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

部分测试采用了测试工具，例如进行各个单元测试时采用了相关的集成技术工具。

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

没有购买网上服务器，在另辟蹊径的情况下不懂得如何配置本机ip地址以作为服务器供他人使用，且出于功能并未齐全的缘故，因此不做正式的发布；
提供了由github下载相关文件，并附上如何使用的注解以代替正式的发布，可以按照使用注解进行相关功能的体验；

3. 总结:

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

可管理级别，项目的整个开发过程还是十分有序的，但是出于时间成本以及队员相关技术经验的匮乏而完成不够出色

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

规范阶段，理由是队内成员基本没有分歧，且按照组长的指挥领导有序进行开发，并能够做到互相帮助。

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

队员应根据自身的学习情况进行时间安排，努力学习好相关的技术知识，以防开发过程出现慌乱瞎忙的情况；

• 如果历史重来一遍，我们会怎么做

鉴于开发过程由于经验不足导致低估了许多任务的工作量和难度，导致经常出现进度缓慢的现象，如果再来一次，根据此次教训我会安排全员都投入代码功能开发中，而不是细分出各个职责，各尽其职；
而其余阶段的任务也应该由组长分配划分，倘若出现人力资源不够的情况，则分配更多的成员过去帮忙。

4. 团队贡献分分配：

成员	贡献分	可验证的贡献
温泽坤（组长）	22	需求分析与原型设计，系统设计以及项目管理与博客撰写，前后端交互的实现
黄浩	20	辅佐需求分析与原型设计，项目管理与博客撰写
韩逸朗	20	相关数据库设计与后端开发，前后端交互的实现
蔡昱鹏	18	数据库数据设计，辅佐后端开发
纵恒	20	前端开发以及前后端交互的实现
高圣	20	前端开发以及辅佐前后端交互的实现
许李姿	20	前后端的功能测试，以及测试计划的制定与报告编写
廖紫茵	20	前后端的功能测试，以及测试计划的制定与报告编写