团队作业6.2——事后诸葛亮分析

这个作业属于哪个课程	软件工程
这个作业要求在哪里	团队作业6——复审与事后分析
这个作业的目标	复审与事后分析
团队Gitee仓库链接	Gitee鏈接

团队成员:

姓名	学号
蔡梓严（队长）	3122004686
刘睿	3122004697
吴炳辉	3122004709
陈翼	3122006207
林诗芸	3222004596
卢铭	3122007933
巫育平	3122004708

目录

• 1、项目管理之事后诸葛亮会议
  • 1.1、设想与目标
  • 1.2、计划
  • 1.3、资源
  • 1.4、变更管理
  • 1.5、设计/实现
  • 1.6、测试/发布
  • 1.7、总结
• 2、全组讨论的照片
• 3、团队成员在Alpha阶段的角色和具体贡献

1、项目管理之事后诸葛亮会议

1.1、设想与目标

• 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
  我们的目标是解决超市购物平台用户的需求，包括完善购物车功能、优化搜索功能、提供购物卡充值等功能。通过问卷调查，我们确保了对典型用户和场景的清晰描述，以构建一个高效满足用户需求的平台。
  定义得很清晰， 对典型用户和典型场景有清晰的描述，具体的描述可以参考需求规格说明书。

• 我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
  原计划的功能：基本达到，但部分功能可能需要进一步优化。
  交付时间上，我们基本按计划进行，
  用户数量未达到预期，但正在逐步发展。

• 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
  与上一个阶段相比，团队软件工程质量有所提高。代码优化程度更高，系统流畅性更好，团队沟通更加密切，任务规划更合理，团队合作更紧密，工程效率更高。

• 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？
  用户数量有所增加，但尚未达到预期水平。用户对重要功能的接受程度较高，与预期存在较小差别。我们正在逐步向目标靠近，但需要更多宣传和改进以推动用户增长。

• 有什么经验教训? 如果历史重来一遍, 我们会做什么改进？
  教训：首先要建立良好的规划，其次是每个人要有高度的执行力，然后成员之间要做好良好的沟通。
  改进：1.如果历史重来，我会利用前面的时间制作计划更好的计划，同时确定清楚大的框架，减少后面对框架的修改整合。2. 在做项目工作安排时，设置多些缓冲时间，不让团队最后处于一直踩deadline或者超时完成任务。3. 结合团队成员的实力，开会后确认团队开发成员有这个能力实现产品功能，再行设计产品需求。

1.2、计划

• 是否有充足的时间来做计划？
  理论上时间十分充足，但是因为学业以及每位成员都有自己的事务，并不能很好地在一起做计划，所以时间还是比较紧迫。
  尽管理论上时间充足，但由于成员的学业和个人事务，团队并不能充分集中在计划上，时间仍然比较紧迫。

• 团队在计划阶段是如何解决成员对于计划的不同意见的？
  在计划阶段，团队通过开展团队会议解决成员对计划的不同意见。每个成员表达观点，讨论并达成共识，如无法达成一致则通过投票表决确定计划，确保每个人理解并支持。

• 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？
  大部分原计划的工作都完成了，但一些细节和优化任务可能未在原计划时间内完全实现。

• 有没有发现你做了一些事后看来没必要或没多大价值的事?
  没有发现做了事后看来没有必要或价值不大的事情，每个任务都具有一定价值，即使是被删除的设计也是经验的积累。

• 是否每一项任务都有清楚定义和衡量的交付件?
  大多数任务都有清晰定义和可衡量的交付成果，但仍有一些模糊、难以划分的任务。

• 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
  项目整体按计划进行，但在冲刺阶段部分功能因优化问题延迟，收尾工作紧迫。主要风险出现在功能优化、bug测试和修复方面，原因是团队成员缺乏项目经验和时间安排不合理。

• 在计划中有没有留下缓冲区，缓冲区有作用么?
  计划中设置了周末或没课的某天作为缓冲区，以缓解成员压力，确保项目有序进行。

• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  从中学到了更加重视团队合作的重要性。如果历史重来一遍，团队将更多留出时间处理细节，灵活调整计划。

1.3、资源

• 我们有足够的资源来完成各项任务么
  人力资源：分工明确，人手充足，但缺乏开发经验，没有一个经验比较丰富的队员带领。 开发资源：开发设备够用，环境配置都没有问题； 时间资源：开发时间比较紧迫，且后期时间分配不够合理。

• 各项任务所需的时间和其他资源是如何估计的，精度如何?
  通过开会确定工作量和分工，讨论资源的估计和分配，人力资源和开发资源的的估计没有差错，时间资源的估计与实际相差较大。所需时间的估计都是根据任务的具体难度设定的，且参照当天课内作业的数量做微调。任务估计精度精确到天数。

• 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
  人力资源和软件/硬件资源充足，但测试优化的时间不足。我们的项目美工设计方面较为简约，所以没有什么大问题。主要是文案（即博客撰写），为了做到尽最大程度描述清楚本团队的工作，所以都是投入了大量精力

• 你有没有感到你做的事情可以让别人来做（更有效率）？
  由于是初次合作，也不能做到随时交流，导致开发效率比较低；但是团队在计划任务分工时一定程度地考虑了队员技术栈、时间等相关因素，所以基本分工较为合理，每个人都在自己负责的任务上有独特的优势，队员大多未出现这种想法。

• 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  经验教训：我们学到了对资源进行更灵活的优化，随着项目的进行进行合理的重新分配。
  改进：提前了解各位队员之后的时间安排，留有充分的缓冲区。确保每个队员都能在项目中投入较多精力，保证项目进度，做好项目方面的实时监督与加强项目资源的管理与部署。

1.4、变更管理

• 每个相关的员工都及时知道了变更的消息?
  是的，我们通过微信群来通知大家项目的进展及变动，会有定期的团队会议来汇报项目情况以及讨论项目变更改进，同时在gitee上大家进主页的时候也会看到团队项目的动态变化。

• 我们采用了什么办法决定“推迟”和“必须实现”的功能?
  以项目的开发进度和功能模块来决定。评估功能的重要等级：若这个功能在项目的运行中是必不可少的，就是必需实现；若它可有可无，只是锦上添花的话，则可以作推迟处理。

• 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  有清晰地定义出口条件，即：依照测试计划对软件进行测试，对大部分Bug调试修复后，在基本功能可以顺利运行、没有恶性Bug的情况下，我们认为软件已经足够好，可以发布Alpha版本。

• 对于可能的变更是否能制定应急计划?
  有，因为留有缓存期，在面对紧急情况，如出现意想不到的BUG时可以有足够的人力与时间进行处理，减小了带来的影响，推进了项目完成。

• 员工是否能够有效地处理意料之外的工作请求？
  基本上都可以，每个成员在完成自己任务的基础上，遇到意料之外的工作都能在会议讨论协商后接受需求补充或变更，去思考怎么完成，涉及到新的知识点也会在力所能及的情况下去努力学习并且运用到实际。

• 我们学到了什么？如果重来一遍，我们会做什么改进？
  任务和更改的及时通知是非常重要的，遇到变更或者其他紧急情况才能在尽量少的时间内解决，如果重来一遍，会提前确保任务不需要修改，如果遇到瓶颈的功能，会选择直接剔除，从而节省时间来完善其他功能，推进项目的进度。

1.5、设计/实现

• 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
  设计工作在确认选题后的一周内就完成，参与人员为全团队成员，之后的开发任务都是按照设计内容进行，后续没有出现较大的矛盾，所以是合适的时间，合适的人

• 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
  有。随机应变，综合考虑软件基本功能和时间限制，最后我们会选择票决，因为团队总共七名成员，所以每次都可以得出决策结果。

• 团队是否有测试工具来帮助测试？
  运用了单元测试优化软件。首先，在一个模块内的队员进行组内测试，对对方实现的函数和功能进行运行测试，然后，不同模块的同学进行组与组之间的互测。单元测试很有效，部分的bug由单元测检出。

• 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  在商品信息部分产生的 Bug 最多。其原因是这部分包含的功能最多且容易被发现。在发布 Alpha 版本后，由于使用用户数量有限，目前暂时未发现其他重要的 Bug。

• 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
  代码复审严格执行了代码规范，同时团队成员交换审核其他人写的代码，确保代码的可读性和易读性，但在一些复杂功能的实现中可能需要更深入的复审。

• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  我们学到了一个真正的项目的开发流程经过。如果重来一遍，应该多督促成员线下一起编程，这样讨论问题的效率可以得到大幅提升，歧义想法也可以及时探讨

1.6、测试/发布

• 团队是否有一个测试计划？为什么没有？
  有，在原先的项目安排中有给出了测试计划。

• 是否进行了正式的验收测试？
  是，我们对项目的所有功能都进行了完整的测试，并在小组范围内进行了小规模的真实应用测试，整体达到我们的预期。

• 团队是否有测试工具来帮助测试？
  运用了单元测试优化软件，其它的没有使用。首先，在一个模块内的队员进行组内测试，对对方实现的函数和功能进行运行测试，然后，不同模块的同学进行组与组之间的互测。单元测试很有效，部分的bug由单元测检出。

• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  经验：测试对于一个合格的产品来说十分重要，它能发现很多在单独编写一个接口代码时未出现的bug,可以避免糟糕的用户体验以及用户隐私泄露等严重问题。如果之后有较为复杂的程序，我们可以了解一些自动化测试工具来提高测试效率。
  改进：
  增强测试覆盖： 通过增加测试用例的广度和深度，以提高对各种情况的覆盖，减少发布后发现的问题。
  注重用户反馈： 设立更强大的用户反馈机制，包括用户体验反馈和功能建议，以更及时地了解用户需求和问题。
  改进发布说明： 在发布说明中更详细地说明项目目标、范围和预期的用户体验，以提高团队和用户对系统的理解。

1.7、总结

• 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
  我认为我们到达了CMMI二级，管理级。在管理级水平上，我们在项目实施上能基本遵守既定的计划和流程，有资源准备，相关的功能实现都分配到位了，对整个流程有监测与控制，对每位队员完成情况都有所掌握，对于进度慢的队员进行积极地督促，同时通过站立会议讨论其遇到的问题和难点。

• 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  磨合，因为这是团队合作的第一个项目，在这过程中产生了大量的问题，最后呈现的结果也是不尽人意。但同时我们也有了这个项目的经验。

• 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
  更进一步了解项目结果、团队技术水平的不足以及一些不够完善的地方，也能够在一定的成果展示里提高我们对团队合作的自信心。

• 你觉得目前最需要改进的一个方面是什么?
  这次开发的过程中，总感觉时间不够，东西很多，开发团队的技术水平，需要各个成员自己认真去下功夫精进自己的技术水平，才能推动项目的完成速度和完成质量。

• 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则?
  快速迭代；多沟通，尽量减少文档；及早考虑测试。
  团队在灵活性等方面做得较好，但还需加强自我反思能力。

2、全组讨论的照片

3、团队成员在Alpha阶段的角色和具体贡献

我们将20N,N是团队人数7人，即140分的贡献分进行分配，其中有5分的基础分，其余分数则由团队成员为项目的贡献程度、完成模块功能的情况、任务的实际工作量和博客编写等来进行分配，分配结果如下。

姓名	角色	贡献分	具体贡献
蔡梓严	PM	5+5*5=30	参与项目各个方面的部署与分工、编写团队项目所有博客、参与用户调研、保证项目正常推进、和团队项目展示
刘睿	开发	5+3*3=14	商品功能信息、用户登录与注册功能、订单与支付功能
吴炳辉	开发	5+4+3*3=19	模块开发分工、商品信息功能、购物车功能、订单与支付功能
陈翼	数据库管理	5+5*4=25	参与架构设计、数据库表设计、版本发布说明、协助测试
林诗芸	测试	5+5*3=20	参与各模块的测试、编写测试计划、发布测试报告
卢铭	gitee仓库管理	5+6*2=17	管理github团队仓库、参与团队评审
巫育平	开发	5+4+3*3=15	每日燃尽图、管理员模块功能、购物车功能