事后诸葛亮
| 软件工程 | 班级链接 |
|---|---|
| 作业要求 | 作业要求 |
| 作业目标 | 评审与事后总结 |
| github仓库 | 团队项目 |
队名：P人大联盟
团队成员
| 姓名 | 学号 |
|---|---|
| 王睿娴 | 3222003968 |
| 张颢严 | 3222004426 |
| 梁恬（组长） | 3222004467 |
| 潘思言 | 3222004423 |
1 事后诸葛亮分析
1.1 会议照片
1.2 设想和目标
1.2.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 要解决的主要问题：
- 爬取针对指定时间和地区范围的微博用户发布的评论数据。
- 对爬取的文本进行情感分析。
- 输出情感正负向结果及对应的词云图、饼状图。
- 使用AI助手给出相关情感分析结论与改进建议。
- 定义清晰：
- 已清楚定义目标和功能，覆盖范围明确，数据分析逻辑清晰。
- 目标用户：
- 媒体公司、品牌推广团队、市场调研人员、社交媒体运营人员，以及对公众舆情感兴趣的研究机构和个人。
- 典型场景：
- 品牌舆情监控：企业实时分析用户对品牌活动的反馈并快速调整策略。
- 热点话题研究：研究人员分析某社会事件在不同地区的公众情绪。
- 市场营销：营销人员分析某广告活动的情绪反馈，优化投放策略。
- 公共事件管理：政府机构了解公众对政策或突发事件的情绪变化，及时采取应对措施。
1.2.2 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 头脑风暴：组织团队讨论，听取每位成员的意见。
- 优先级排序：通过优先级矩阵评估任务重要性和可行性。
1.2.3 用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
- 用户量和用户对重要功能的接受程度与预期基本一致。
- 目前原型开发已接近目标功能框架，功能实现与目标接近，仍需进一步优化体验和算法精度。
1.3 计划
1.3.1 是否有充足的时间来做计划？
- 组内成员人数偏少，需要完成的任务较多，时间相对比较紧迫。部分任务的时间预估较为乐观，导致计划初期压力较大。尽管如此，团队在沟通和协调上做了较好的调整，确保了大部分任务能够按时完成。
1.3.2 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 设立负责人：由模块负责人（组长）综合协调，确保团队内的意见能够得到充分表达和讨论。
- 例会：Alpha冲刺阶段每天固定时间进行任务复盘，及时解决任务中的争议点和不确定性。
1.3.3 你原计划的工作是否最后都做完了？如果有没做完的，为什么？
- 已完成全部预期功能，部分任务虽然提前完成，但仍需进行相应调整。整体来看，原定的工作目标和时间安排基本按计划完成。
1.3.4 有没有发现你做了一些事后看来没必要或没多大价值的事？
- 没有。团队在计划阶段通过合理分配任务和及时调整工作重点，避免了做无用功。每项任务都有清晰的目标和优先级，确保工作尽可能有价值。
1.3.5 是否每一项任务都有清楚定义和衡量的交付件？
- 大部分任务有明确的交付件和验证标准，每次提交都需要对应处理的issues，并进行详细说明。这确保了每个任务的可跟踪性和可评估性，减少了模糊性和执行中的偏差。
1.3.6 是否项目的整个过程都按照计划进行？项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
- 大部分项目过程按照计划进行。
1.4 资源
1.4.1 我们有足够的资源来完成各项任务么？
- 人力资源：团队分工明确，虽然人手略显不足，但每位成员都有合作开发经验，可以高效配合，弥补了人力资源的不足。
- 开发资源：开发设备与环境配置均能支持项目的需求，且使用的开发工具与平台都比较成熟，减少了技术上的障碍。
- 时间资源：开发时间较为紧迫，尤其在冲刺阶段需要优化时间分配，确保按时交付。
1.4.2 各项任务所需的时间和其他资源是如何估计的，精度如何？
- 任务时间和资源的估算主要基于团队以往项目的经验及历史数据。在相对简单的任务上，时间和资源估算精度较高；但对于复杂任务，估算精度略有欠缺，后期有所偏差。今后在遇到新类型任务时，应加强早期风险评估和灵活调整。
1.4.3 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
- 测试资源：人力资源和软件/硬件资源充足，基本满足需求。但在测试的优化和反复调试阶段，时间显得有些紧张，特别是在压力测试和性能优化上，需要更多时间投入。
- 非编程资源：项目几乎所有资源都需要编程实现，因此没有出现对于美工设计/文案等非编程任务资源低估的问题。不过，对于测试阶段的时间安排没有完全充分考虑，导致后期测试任务比较密集。
1.4.4 你有没有感到你做的事情可以让别人来做（更有效率）？
- 每个人的分工较为明确，团队成员在各自负责的领域都有独特优势，能在自己的专长领域内高效工作。整体来看，没有发现现有任务可以更有效率地由其他人替代。
1.4.5 有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 经验教训：项目初期对资源的识别和分配需要更加精准，尤其是在需求不完全明确的情况下。
- 改进措施：未来应更早识别和分配资源。此外，加强项目初期对资源需求的预估，并为不可预见的任务留出足够的缓冲时间，避免出现资源紧张的局面。
1.5 变更管理
1.5.1 每个相关的成员都及时知道了变更的消息？
- 是。项目中的变更通过多个渠道及时传达给相关人员，主要通过群聊和issue系统的邮件通知。这样能够确保每位成员在变更发生时迅速了解并作出相应的调整。对于较大的变更，还会安排专门的沟通会议确保信息的传递不遗漏。
1.5.2 我们采用了什么办法决定“推迟”和“必须实现”的功能？
- 功能的优先级是根据用户需求和团队可行性评估来共同决定的。每个功能的优先级会与需求方确认，并根据开发和测试进度进行动态调整。
- 需要推迟实现：根据实现的复杂度、开发资源的紧张程度以及测试阶段的反馈决定是否推迟。
- 必须按时实现：如果是用户体验中关键的功能，或者是项目交付所必须的功能，则无论开发情况如何，都必须按时交付。
1.5.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
- 项目的出口条件有清晰的定义，具体为：
- 功能测试：所有预定功能必须正常工作，无严重Bug。
- 用户反馈：已通过小组成员反馈修复了大部分关键问题。
- 版本发布：经过充分测试的版本，满足基本发布标准，可以在无恶性Bug的前提下进行Alpha版本发布。
1.5.4 对于可能的变更是否能制定应急计划？
- 能。团队在遇到突发情况时，能够迅速调整开发计划，必要时重新评估优先级，确保变更不会对项目的整体进度造成太大影响。
1.5.5 成员是否能够有效地处理意料之外的工作请求？
- 团队成员能够灵活应对突发请求，并有效安排资源来处理新的工作任务。然而，有时由于多个任务的优先级冲突，部分突发任务可能会导致已有任务的延迟。为了避免这种情况，未来可以在项目初期就设定好灵活的优先级调整机制。
1.5.6 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 经验教训：清晰的沟通和更严格的变更控制对于提升团队效率至关重要，特别是在面对需求变动或技术难题时。我们在一些情况下没有及时传达变更，导致了部分误解和任务优先级混乱。
- 改进措施：
- 加强日常的沟通，确保每位成员都能即时了解项目变化。
- 制定严格的变更管理流程，包括及时的变更审核和变更影响分析，确保团队对每个变更都有明确的响应措施。
- 为突发的工作请求预留更多缓冲时间，并提前做好资源调配的准备，以减少意外任务对正常进度的干扰。
1.6 设计/实现
1.6.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作由经验丰富的成员完成，时间合适且人员安排合理。
1.6.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 设计过程中有部分模棱两可的情况，通过团队讨论和决策来解决。
1.6.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 团队采用了单元测试，效果较好。
1.6.4 什么功能产生的Bug最多，为什么？
- 各个模块都有不同的bug。
1.6.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 代码复审按规定流程进行，严格执行代码规范，确保代码质量。
1.6.6 我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 在设计初期考虑更多的潜在问题，尤其是并发和性能方面的问题，避免后期出现重大bug。
1.7 测试/发布
1.7.1 团队是否有一个测试计划？为什么没有？
- 团队有测试计划，并按照计划执行。
1.7.2 是否进行了正式的验收测试？
- 进行了正式的验收测试，确保项目满足客户需求。
1.7.3 团队是否有测试工具来帮助测试？
- 团队没有使用测试工具帮助测试。
1.7.4 在发布的过程中发现了哪些意外问题？
- 发布中发现了部署到网站时情感分析失败的bug。原因是开发环境与部署环境的不同。
1.7.5 我们学到了什么？如果重来一遍，我们会做什么改进？
- 应该更早进行测试，避免发布时出现问题。
1.8 总结
1.8.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
- 团队目前大致处于 执行级（CMMI一级）。
1.8.2 你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段？
- 团队处于磨合阶段，团队成员之间的协作逐步形成，但仍需进一步优化沟通和协调机制，以提升整体效率。
1.8.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进？
- 在这个里程碑，相比之前，团队在任务管理、沟通协作上有所改善，特别是针对需求变更和冲突解决的机制逐步完善。但整体流程上还存在优化空间，尤其是任务的时间和资源估算。
1.8.4 你觉得目前最需要改进的一个方面是什么？
- 最需要改进的方面是团队的资源和时间管理。
2 团队成员在Alpha阶段的角色和具体贡献
2.1 团队贡献分计算方式
| 工作量(40%) | 质量(30%) | 团队合作(20%) | 创新和解决问题能力(10%) |
|---|---|---|---|
| 根据成员完成的工作量和任务难度进行分配。 | 根据成员工作成果的质量,包括代码质量、文档完整性等。 | 根据成员对团队合作的贡献,如帮助同伴、共享知识等。 | 根据成员提出的创新想法和有效解决问题。 |
2.2 团队贡献分
| 团队成员 | 角色 | 团队贡献分 | 角色对应的可验证贡献 |
|---|---|---|---|
| 张颢严 | BA，DS，Dev，Test，Tech Writer | 20.2（8.3 + 6 + 3.8 + 2.1） | （1）需求说明规格说明书博客中的功能性需求和技术需求编写； (2)团队项目github仓库里多个深度学习的情感分析模型构建代码； （3）团队项目github仓库里情感分析模块开发代码和Alpha阶段冲刺博客里的对应更新代码和运行成果； （4）测试与发布里关于情感分析模块的测试截图； （5）团队项目所有博客中关于其个人与情感分析模块的内容撰写 |
| 王睿娴 | Dev，Test，Tech Writer | 19.9 （8 + 6 + 3.8 + 2.1） | （1）团队项目github仓库里数据收集模块开发代码和Alpha阶段冲刺博客里的对应更新代码和运行成果； （2）测试与发布里关于数据收集模块的测试截图； （3）团队项目所有博客中关于其个人与数据收集模块的内容撰写 |
| 潘思言 | RM，UI，Dev，Test，Tech Writer | 20.1（8.2 + 6 + 3.8 + 2.1 ） | （1）测试与发布博客及其中尝试部署中的网页链接； （2）测试与发布博客中尝试部署中的网页页面； （3）团队项目github仓库里用户交互和AI链接模块开发代码和Alpha阶段冲刺博客里的对应更新代码和运行成果； （4）测试与发布里关于用户交互模块的测试截图； （5）团队项目所有博客中关于其个人与用户交互模块和AI链接模块的内容撰写，以及第6次作业博客基本架构的撰写 |
| 梁恬 | PM，Dev，Arch, Test，Tech Writer | 19.8 （ 7.5 + 6 + 4.6 + 1.7 ） | （1）团队项目博客中的团队任务分配，WBS图，issue，leangoo，团队计划的制定，编写与调整； （2）团队项目github仓库里数据可视化，数据预处理和提问生成模块开发代码和Alpha阶段冲刺博客里的对应更新代码和运行成果； （3）团队项目系统设计博客中的系统设计，团队项目github仓库里系统整合调用的开发代码和Alpha阶段冲刺博客里的对应更新代码和运行成果； （4）测试与发布里关于数据可视化，数据预处理和提问生成模块，系统测试的测试截图； （5）团队项目所有博客中关于其个人与数据可视化，数据预处理和提问生成模块的内容撰写，前5次作业博客基本架构的撰写 |
