事后诸葛亮分析报告
| 软件工程 | 计科21级12班-广东工业大学计算机学院 |
|---|---|
| 这个作业要求在哪里 | 团队作业6——复审与事后分析 |
| 这个作业的目标 | 复审与事后分析 |
一、事后诸葛亮分析
🦀🦀会议图片🦀🦀
🦀🦀设想和目标🦀🦀
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要管理学生上课的出勤情况，希望在一定程度上提高学校管理效率、教师教学效率和学生出勤率。我认为我们的软件目标定义得较为清晰，真实地模拟了当代学生线上请假的流程。
2. 我们达到目标了么
达到了部分，仍有需要改进的地方。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
提高了。代码在一定程度上进行了优化，系统流畅性更高；同时开发组也进行了更多的沟通，使得开发效率进一步提升。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
一致，基本功能都已完成，离目标也越来越接近了。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
大的框架一定要确定清楚，如果一开始定义得不够清晰，后面再对大框架进行改进会花费很多时间。再来一遍会在进行开发前进行更多的团队沟通，确保总体框架没问题再进行开发。
🦀🦀计划🦀🦀
1. 是否有充足的时间来做计划?
时间上并不是很充足，我们团队的同学之前对项目开发的流程都不是很熟悉，在确定总体计划之前进行了多次更改。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
更多的是进行线上沟通，在小组群里发表各自的意见，大多都能经过沟通统一意见，极少数情况需要经过投票统一意见。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本都做完了。有些功能由于时间关系没有完善得很好。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
由于一开始不知道项目开发的具体流程，花了很多时间学习别人开发项目的流程，但是收获的东西没有很多，并且还导致团队进度放慢了。
5. 是否每一项任务都有清楚定义和衡量的交付件?
总体是清晰的，但是在分工上还有一定的改进空间。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本上都在按照计划进行，一开始前端组由于两个人分工不是很明确，导致在交接的时候出现了一些小麻烦，不过后面经过调整也基本解决问题了。没有考虑到使用系统人数过多时会出现什么情况，因为一开始考虑到团队能力有限，计划只做一个小型的考勤系统。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有。
缓冲区在项目计划中的作用主要包括以下几个方面：
应对风险： 通过在计划中留有缓冲区，项目团队可以更好地适应这些变化和风险。
应对不确定性： 缓冲区可以用于应对这种不确定性，确保即便任务花费的时间超出了最初的估算，项目仍然能够按时完成。
应对变更： 缓冲区为项目团队提供了灵活性，使其能够容纳一些变更而不至于影响整个项目计划。
8.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划书对一个项目的重要性，如何合理地规划时间，如何进行清晰的分工，如何推动团队在规定的时间内完成工作。再来一遍会将开发时间调得更早一些，后面开发组才有更多的时间进行改进。并且团队成员的沟通也很重要，再来一遍一会将这个地方重视起来。
🦀🦀资源🦀🦀
1. 我们有足够的资源来完成各项任务么?
考虑了项目范围，Bug修复，测试，功能覆盖等因素，我们觉得我们的资源足够完成各项任务。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
通过任务分解，过去项目经验，专业知识，风险考虑，团队成员的工作负荷等进行估计。
精度对于我们当前的项目规模我们觉得已经很高了。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
考虑测试时间，测试人力，软硬件资源等因素，我们觉得都很足够。
对于美工设计、文案等不需要编程的资源，我们感觉低估了他们的难度，因为我们一开始没有对这些资源进行充分的准备。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
我们每个人都各司其职，都被分配到了各自最擅长的领域，所以我们工作起来都觉得效率很高，很顺利。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我们没有特别明确的需求分析，没有进行相关文档记录。如果历史重来一遍，可能会考虑在项目启动前进行更全面的风险评估，采用更灵活的方法来应对变化，以及加强与所有团队成员之间的协作和沟通。这些改进将有助于提高项目的透明度、灵活性和成功交付的概率。
🦀🦀变更管理🦀🦀
1. 每个相关的员工都及时知道了变更的消息?
是的，每次变更都会在群里通知负责项目各个部分的成员，大家也都很关注群里的消息，能及时回复以告诉其他成员自己已收到变更消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
以线上讨论的形式，根据功能的重要性和实现难度，各个成员说出自己的想法以及支撑这个想法的原因，组长负责记录大家的意见，最后意见不统一采用了投票以多数决定少数的方式。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
各个功能模块都基本完成，测试后没有bug，并且让第一次使用的用户了解系统的功能后能够轻易上手。
4. 对于可能的变更是否能制定应急计划?
能制定紧急计划，我们先把基础的功能模块完成，再在这个基础上进行进一步的功能扩展，途中有一两个功能实现遇到了瓶颈，都及时进行了变更，最后对项目进度的影响不大。
5. 员工是否能够有效地处理意料之外的工作请求？
基本上都可以，每个成员在完成自己任务的基础上，遇到意料之外的工作请求，都会去思考怎么完成，涉及到新的知识点也会在力所能及的情况下去努力学习并且运用到实际。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在团队合作中，每个人之间进行及时的沟通是必要的，遇到变更或者其他紧急情况才能在尽量少的时间内解决，与此同时，一个项目应该做好保底工作，在完成最基础功能的情况下，遇到难以完成的功能能及时变更，不浪费大家的时间。重来一遍的话，我们会把遇到瓶颈的那个功能直接剔除，节省时间来完善其他功能，推进项目的进度。
🦀🦀测试/发布🦀🦀
1. 团队是否有一个测试计划？为什么没有？
有，我们对每个模块，每个阶段都有明确的测试计划。
2. 是否进行了正式的验收测试？
是，我们对项目的所有功能都进行了完整的测试，并在小组范围内进行了小规模的真实应用测试，整体达到我们的预期。
3.在发布的过程中发现了哪些意外问题？
学生的申请在老师界面不能及时展示：意外问题可能包括学生在申请老师界面上的实际体验与预期不符，可能导致流程延迟或信息不准确。
请假申请时请假时间在课程结束后，不合实际：意外问题可能引起请假流程的混淆，学生可能会在实际请假时间与系统接受的时间之间存在不一致。
4.我们学到了什么? 如果重来一遍, 我们会做什么改进?
**我们学到了：**
需要及时反馈机制： 了解到学生申请老师界面不能及时展示、请假时间设置问题等，强调了在测试阶段及时发现并解决问题的重要性。
要更全面优化用户体验： 发现了管理员修改个人信息时退出登录的问题，强调了在用户界面设计中优化用户体验的需求。
要注重安全性和验证： 意识到注册时缺乏手机号格式验证和验证码验证，强调了系统安全性和用户身份验证的重要性。
**如果重来一遍, 我们会做以下改进：**
增强测试覆盖： 通过增加测试用例的广度和深度，包括边界条件、异常情况等，以提高对各种情况的覆盖，减少发布后发现的问题。
注重用户反馈： 设立更强大的用户反馈机制，包括用户体验反馈和功能建议，以更及时地了解用户需求和问题。
加强安全性： 在系统中增加更强的安全性措施，例如手机号格式验证、验证码验证等，以确保用户数据的安全性。
改进发布说明： 在发布说明中更详细地说明项目目标、范围和预期的用户体验，以提高团队和用户对系统的理解。
🦀🦀团队的角色，管理，合作🦀🦀
1. 团队的每个角色是如何确定的，是不是人尽其才？
我们团队的角色的确定是根据项目的特定需求、规模和性质而定。根据成员的技能、经验和专业领域分配角色。这样可以保证尽量发挥每个人的最大作用，做到人尽其才。
2. 团队成员之间有互相帮助么？
有，我们经常互相给予帮助。这种互相帮助的文化有助于建立一个强大的团队，促进团队成员之间的信任和合作，提高项目的整体效率和成功可能性。
🦀🦀总结:🦀🦀
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
由于部分成员缺乏协作经验，所以我认为目前团队状态处于初始级，部分可以达到可重复级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段。
1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
使用 GitHub来管理代码的版本、在代码中添加注释、进行代码复审等。
制定明确的代码规范、定期进行代码复审、持续改进代码规范等。
2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
可以通过重构代码、采用合适的设计模式、编写全面的单元测试、定期进行代码审查、对程序进行性能优 化等方式进行提高。
衡量质量的提高可以通过以下指标来进行评估：代码覆盖率、缺陷率、代码复杂度等方面。
3. 其它软件工具的应用，应该如何提高？
①实践和项目应用：在实际项目中推动软件工具的应用，通过实践中的使用加深团队对工具的理解和熟练度。鼓励团队成员分享使用工具的最佳实践，促使经验的共享和学习。
②定期更新与技术支持：确保所使用的软件工具保持最新版本，以获得最新功能和修复已知问题。存在技术支持时，鼓励团队成员向供应商寻求帮助，解决使用中的问题。
③收集团队成员对软件工具的反馈，了解使用中的问题和需求。将用户反馈整合到工具的改进计划中，确保工具能够更好地满足项目需求。
④创建详细的使用手册和文档，以便新成员能够快速上手并学习使用工具。
4. 项目管理有哪些具体的提高？
①明确项目目标和范围
②建立良好的沟通机制
③确保项目中的问题能够及时解决。
④可以在文档中提及培训计划和绩效评估，以促进团队的技能提升。
⑤灵活性。
⑥定期进行项目回顾
5. 项目文档的质量如何提高？
①在编写项目文档之前，要明确文档的目标和需求，确保文档内容符合读者的期望和需求。
②制定统一的文档格式和结构，以便读者能够快速找到所需信息。
③避免冗长重复内容，使用简洁清晰的语言表达全面的信息
④保持文档的实时性和准确性。
⑤在编写完成后，进行审查和反馈，以确保文档质量符合要求，并及时进行修订和改进。
7. 对于人的领导和管理，有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
①明确团队共同目标和期望
②建立开放沟通
③设定清晰的角色和责任
④定期绩效回馈
⑤激励和奖励
二、团队贡献分
🦀🦀评分方式🦀🦀
🦀🦀小组成员贡献分🦀🦀
| 姓名 | 角色 | 团队贡献分 |
|---|---|---|
| 傅浩钊 | 后端开发 | 19.7 |
| 容伟亮 | 后端开发 | 19.7 |
| 车文超 | 后端开发 | 19.6 |
| 魏晓琪 | 测试 | 19.6 |
| 朱乐言 | 项目经理、测试 | 20.6 |
| 马佳纯 | 前段开发 | 20.4 |
| 肖依敏 | 前段开发 | 20.4 |
