团队作业6——事后分析

作业要求

这个作业属于哪个课程	计科34班
这个作业的要求在哪里	团队作业6——复审与事后分析
这个作业的目标	复审与事后分析
队名	发际线和我作队

一、 设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述
旨在解决以下问题：
为仓库管理者提供一个便捷的网上仓库存储系统，提高仓库管理的效率。
提供货物信息编辑、分类的功能，方便货物信息的管理。
典型用户：
仓库管理人：使用仓库管理系统来记录每天的进货出货的货物，极大地提高了管理的效率。
小卖部等小型商店的老板：使用该系统记录每天进货和上架的商品，提高管理效率。
典型场景：
小型仓库管理者对于新来的一批货物进行信息的录入
小卖部老板对于已经上架的商品进行库存修改
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?
系统的基本功能已经完成，但是预计用户数还是难以达到。

二、 计划

1. 是否有充足的时间来做计划?
   有。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的
   鼓励开放讨论创建一个开放的环境，让每个人都有机会表达自己的观点和想法。确保每个人都有机会发言，并尊重他们的意见。
   寻求共识：尝试找到一个大家都能接受的解决方案。这可能需要进行一些妥协和调整，但最终目标是达成共识。
   制定明确的计划：确保计划清晰明了，包括目标、时间表、责任分配等。这样可以减少误解和混淆，有助于团队成员更好地理解计划。
   定期检查进度：在项目执行过程中，定期检查进度并根据需要进行调整。这有助于确保项目按计划进行，同时也可以发现潜在的问题并及时解决。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   做完了
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
   没有
5. 是否每一项任务都有清楚定义和衡量的交付件?
   否
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
   是。暂时没有风险
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
   有。可以缓解压力，提高灵活性
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
   评估项目风险，对项目进行全面的风险评估，识别可能影响项目进度、资源或需求的潜在风险。
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
   通过实际参与项目的规划、执行和控制过程，可以学习到项目管理的基本概念、方法和工具，如时间管理、成本管理、质量管理等。
   在项目中，需要与不同背景和技能的团队成员合作，学会如何有效地沟通、协调和支持彼此，以提高团队的整体表现。
   项目过程中会遇到各种问题和挑战,通过解决这些问题，可以提高自己的分析和判断能力，学会如何在压力下做出明智的决策。
   需要学习和掌握一定的技术知识，如编程语言、设计工具、测试方法等。有助于提高专业技能和竞争力。
   业务理解：通过参与项目，您可以更深入地了解所在行业的业务流程、市场需求和竞争态势，从而提高自己的业务敏感度和洞察力。
   需要不断寻求改进和优化的方法，以提高效率和质量。这将有助于培养创新思维和解决问题的能力。
   需要与不同的利益相关者进行沟通，如客户、团队成员、上级领导等。通过有效的沟通，可以提高自己的表达能力和说服力。
   如果重来一遍，要先确定好项目整体架构，仔细分析客户需求

三、 资源

1. 我们有足够的资源来完成各项任务么?
   人力资源：团队只有五个人，每人的任务量一般，完成难度还算可以。
   开发资源：由于我们的成员代码薄弱的较多，开发过程也很磕磕绊绊，但通过网上查资料、和大佬讨论咨询，也努力克服众难实现了项目的基本功能。
   设备资源：没有问题。
   时间资源：时间较紧，平时的课程较多，其他课程的作业也挺繁琐。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
   根据任务量以及成员的实力评估，精度一般，因为大家完成任务的专注度不足。

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

4. 你有没有感到你做的事情可以让别人来做（更有效率）?
   我们的分工都有按个人能力去分配，有但大家还是个人承担起自己的那一部分，不懂的在群里提出并大家一起解决。

5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
   若重来，我们会提前学习自己负责分工的那部分知识，来提高团队效率。

四、 变更管理

变更管理是软件工程中的关键实践，用于管理软件项目中的变更，确保项目的稳定性和质量。通过以下步骤来实施变更管理：
1 变更识别：及时识别项目中的变更请求，包括功能需求变更、错误修复、优化等。
2 变更评估：对每个变更请求进行评估，了解其对项目进度、资源和风险的影响。进行优先级排序和决策，确定要接受或拒绝的变更。
3 变更规划：制定详细的变更计划，包括变更的时机、资源分配、测试策略和回滚计划等。
4 变更实施：按照变更计划执行变更，并记录执行过程中的关键数据和问题。
5 变更验证：对实施的变更进行验证，确保其符合规格要求，不引入新的问题。
6 变更审核：对变更实施的结果进行审查，评估变更对项目目标的影响，是否满足预期。
7 变更通知：及时向相关团队成员和利益相关者发布变更信息，确保大家都了解变更的影响和执行结果。
8 变更记录：记录所有的变更请求、评估结果、实施过程和验证结果，以便追溯变更历史和分析效果。
变更管理是项目成功的关键因素之一，它可以帮助团队更好地控制变更，减少风险和不必要的成本，确保软件项目的可靠交付和客户满意度。

五、 设计/实现

1. 设计工作是在团队作业发布后一周大家线下共同讨论的，确认好大概要选什么类型的项目，后续设计大致框架并开始开发。
2. 有，在是否要独立设立一个货物分类的界面这种情况，经讨论后认为其重要性需要独立一个界面。
3. 单元测试使用python自带的模块
4. 在数据库设计上出现的问题较多，因为我们组里很多人都是这学期才开始学习数据库开发。
5. 代码复审是在所有成员开发完所有模块和功能后，进行一次整体的代码复审，主要审查各模块代码中是否有明显的bug，各个模块之间的连接是否有问题等。由于每个成员都有自己的写代码习惯，所以并不是严格遵守代码规范，但每个模块的代码都有相应的注释，且没有出现较大问题。

综上，我们明白了不能一味的开发各模块，也要重视每个模块之间的联系，这样整体才能完成的更好，同时也要加强每个成员之间的联系，而不是每个成员独自开发。

六、 测试/发布

1. 有，每个模块都有对应的测试，但测试会相对简单一点。
2. 没有，因为在开发后端创建数据库时出现问题，除此之外都进行了测试。
3. 使用python里的自带模块进行测试
4. 测试了在各浏览器上的网站运转情况，测试了手机端运行，测试了多用户运行。

综上，我们学会了在做完一个项目后要对其进行一个完整的测试，这样不仅能发现其中潜在的问题，能够及时解决，还能优化整个项目，提升整个项目的效能。

七、 总结
1. 每个成员在beta 阶段的实践和alpha 阶段有何改进?

成员	改进内容
梁俊轩	懂得了如何更好地去组织成员干活，对于一个项目的开发测试有了更深刻的理解
雷棋皓	进一步加深了对前端技术的了解，因为要帮助后端开发，所以后端开发技术也有所进步
陈国威	对于后端开发有了新的认识
郭人诵	学习了如何建立一个数据库，学习了如何与他人一起协同开发
何其浚	学习了如何去进行软件测试

2.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到了CMMI一级。我们完成了项目的目标，虽然过程艰难，但还是完成了小目标。

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

4.你觉得目前最需要改进的一个方面是什么?
成员之间的沟通和项目积极性方面是完成一切工作最大的问题。

八、 其他

团队讨论照片：

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

姓名	角色	贡献分
梁俊轩	项目管理、代码测试	22
雷棋皓	前端开发	22
郭人诵	后端数据库开发	20
陈国威	协同后端开发	18.5
何其浚	协助测试	18