一、设想和目标

1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的软件旨在解决行人跌倒检测的问题，通过深度学习技术，能够实时、准确地识别出行人是否发生跌倒情况。这个问题定义相对清晰，明确聚焦于行人这一主体在日常活动场景中的跌倒检测这一关键行为判定。典型用户群体为老人和小孩的家属。典型场景方面，像是养老院的公共活动区域、医院的病房及走廊、社区的道路及休闲广场，还有家居环境中的客厅、卧室等区域，都是容易发生行人跌倒且需要及时监测的场所。我们对这些典型用户及场景都有相应较为清晰的描述，以助于更好地明确软件的应用范围和使用情境。

1.2 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

• 功能方面：原计划的核心功能是利用深度学习算法实现对行人跌倒的准确检测，并具备实时预警等功能。目前，基本的跌倒检测功能已成功实现，并且检测的准确率在经过多轮测试和优化后达到了预期设定的一定标准。实时预警功能也已能够稳定运行，能够及时将检测到的跌倒情况发送给相关接收端。
• 交付时间：按照原计划的项目时间节点，软件的开发和初步测试等环节都按时完成，成功交付了可以部署使用的版本，保障了后续测试、推广等工作能够按计划开展。
• 用户数量：原计划达到的用户数量可能尚未完全实现，仍需要加大市场推广等力度来进一步拓展用户群体。

1.3 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

和上一阶段相比，团队软件工程质量有了较为明显的提高。

• 代码规范方面：制定并严格遵循了更为完善的代码编写规范，代码的可读性、可维护性显著增强。
• 软件测试环节：拓展了测试用例的覆盖范围，不仅增加了正常场景下的测试数量，对于各类边界情况、异常情况的测试用例也更为丰富。
• 项目文档管理：文档的完整性和详细程度大幅提升，从需求文档、设计文档到测试文档等，都做到了及时更新、内容详实，方便新成员快速了解项目以及后续的维护与拓展。

1.4 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？

• 用户量方面：如前文所述，当前实际用户量与事先预想不一致，还未达到预期设定的目标数量，仍需要在市场推广、产品宣传等方面加大投入，提高产品的知名度和认可度，来吸引更多的潜在用户使用。
• 用户对重要功能的接受程度：从已有的试用用户反馈来看，对于跌倒检测的准确性和实时预警这两个重要功能，大部分用户还是比较认可的，认为在实际应用场景中确实能起到有效的监测作用，基本和我们事先预想的用户接受程度相符。不过，也有部分用户反馈在软件操作的便捷性、界面友好性等方面还有改进空间，整体而言，在核心功能接受度上符合预期，但在周边用户体验相关方面还需要进一步优化，从而更好地契合用户需求，进一步扩大用户群体，总体是朝着目标在逐步迈进，但距离最终目标还有一定的努力空间。

1.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进？

• 经验教训：
  在软件开发过程中，对于一些极端复杂场景的考虑和应对稍显不足，使得在实际使用中，这些特殊情况会对软件的性能表现有一定影响，需要后续花费额外的时间和精力去优化完善。
• 改进措施：
  在技术研发阶段，会加大对复杂场景的模拟和应对研究，收集更多极端情况下的数据用于模型训练，不断优化深度学习算法，提高软件在各类场景下的鲁棒性和准确性，确保功能的稳定性和可靠性。

二、计划

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

原计划的大部分工作都已完成。

2.2 有没有发现你做了一些事后看来没必要或没多大价值的事?

在软件界面设计的初稿阶段，过度追求界面的美观性而设计了一些较为复杂的交互元素，后来经过与潜在用户沟通以及实际测试发现，对于这类功能性为主的软件，用户更关注操作的便捷性和信息呈现的直观性，那些复杂的交互设计反而增加了使用难度，没有太大必要。

2.3 是否每一项任务都有清楚定义和衡量的交付件?

是的，我们为每一项任务都设定了明确的交付标准和衡量指标。这有助于团队成员理解各自的责任和目标，同时也便于项目管理和进度跟踪。

2.4 是否项目的整个过程都按照计划进行？

项目的大部分过程是按照计划进行的。

2.5 在计划中有没有留下缓冲区，缓冲区有作用么?

有预留部分但是不够充足。这些缓冲区在处理技术问题时发挥了重要作用。

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

将来的计划中，我们会提高对技术挑战的预估，以便更准确地规划项目时间线。

2.7 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学到的最重要的一点是，项目计划需要足够的灵活性来应对不可预见的变化。

三、资源

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

通常需要评估团队的人力资源、时间窗口和预算来确定是否有足够的资源。如果资源不足，可能需要重新规划项目或寻求额外支持。

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

任务所需时间和资源通常基于历史数据、专家判断和类似项目的经验来估计。精度可能会因项目复杂性和不确定性而异。

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

测试资源的充足性取决于项目需求和测试策略。有时非编程资源的需求和难度可能会被低估，需要通过实际项目经验来调整预估。

3.4 你有没有感到你做的事情可以让别人来做（更有效率）？

是的，有时某些任务可能更适合由具有特定技能或经验的团队成员来完成，以提高效率和效果。

3.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

经验教训可能包括更准确地估计资源需求、优化任务分配和加强跨部门沟通。如果重来，会改进资源规划、风险管理和团队协作。

四、变更管理

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

大部分相关员工都能及时获得变更信息，但在某些情况下信息传递不够及时。

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

通过团队讨论和优先级评估来决定“推迟”和“必须实现”的功能。

4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

是的，项目的出口条件通常有清晰的定义，包括完成所有预定的功能点、通过所有测试、满足性能标准以及获得关键利益相关者的批准。

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

可以，项目团队通常会制定应急计划来应对可能的变更，包括变更管理流程、风险评估和备选方案。

4.5 员工是否能够有效地处理意料之外的工作请求？

是的，员工通常能够通过优先级排序、时间管理和沟通协调来有效处理意外工作请求。

4.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

学到了更好的风险管理和沟通技巧。如果重来，会加强项目规划、风险识别和团队协作。

五、设计/实现

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

在选题之后开始设计工作，由PM来完成。

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

有，把问题在会议中提出来，一起讨论解决。

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

有，团队使用自动化测试和代码质量分析工具来辅助测试

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

复杂功能和多组件交互易出错。发布后发现的Bug通常是因为测试覆盖不足或未预见的场景。设计时可能因缺乏全面性而未考虑某些情况。

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

通过团队互审进行，严格执行代码规范。

5.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

学到了需求管理、测试覆盖和代码质量的重要性。如果重来，会加强需求确认、测试计划和团队沟通。

六、测试/发布

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

团队制定了测试计划，但在执行过程中未能严格遵循。

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

进行了正式的验收测试，但由于时间限制，测试覆盖范围不够广泛。

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

团队有一定的测试工具，但使用频率和效果不理想。

6.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用吗？应该有哪些改进？

团队通过性能测试工具和监控系统来测量和跟踪软件效能。实际运行结果表明，这些测试有助于发现性能瓶颈。改进措施可能包括增加自动化测试、实时监控和用户反馈分析

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

发布过程中可能发现的问题包括意外的性能下降、兼容性问题和未预见的用户行为。这些问题通常需要紧急修复和回滚计划。

6.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

学到了提前识别风险、加强测试覆盖和用户沟通的重要性。如果重来，会改进需求分析、测试策略和应急响应计划。

七、总结

7.1 团队的每个角色是如何确定的？

是在第一次开会的时候，根据大家擅长的部分进行讨论后选择。

7.2 团队成员之间有互相帮助么？

有每一次大家在遇到难题的时候，会在群里进行求助，大家共同想办法解决。

7.3 当出现项目管理、合作方面的问题时，团队成员如何解决问题?

没有出现，因为我们每次沟通都很及时。

团队讨论照片

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