事后诸葛亮分析报告

事后诸葛亮分析报告

一、会议照片

二、会议内容

（一）设想和目标

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

我们的软件旨在解决人们因不慎丢失物品而难以找回的问题。这个问题定义得非常清楚。我们也对典型用户和典型场景进行了清晰的描述：典型用户是丢失了物品或发现了他人物品并希望归还的个体；典型场景包括用户发布失物招领信息、浏览他人发布的失物信息、评论以及注册登录网站等。

2. 我们达到目标了吗？

基本达到目标，原计划的功能完成除了回复评论功能基本完成。

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

仅仅就内部测试人员来看，重要功能基本可以接受。

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

1.功能完整性：虽然大部分功能已经实现，但回复评论功能的缺失显示了在项目规划和执行中的疏漏。这可能影响到用户的交互体验，并可能导致用户满意度下降。

2.用户接受度测试不足：虽然内部测试人员认为重要功能基本可以接受，但这并不代表所有用户都会有同样的体验。在将软件推向市场前，更广泛、更全面的用户接受度测试是必要的。

3.缺乏实际用户反馈：在评估软件是否达到目标时，主要依赖于内部测试人员的反馈，这可能导致对实际用户需求的忽视。

改进：更全面的功能规划，增加用户接受度测试，积极收集用户反馈。

（二）计划

1. 是否有充足的时间来做计划?

我们团队在开发之前已经通过讨论定下了功能需求，有足够的时间来进行项目规划和策略制定。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

由于团队成员先前已有团队合作开发经验，熟知开发流程，并且团队沟通和谐有效，团队通过开放和透明的讨论来解决计划阶段的不同意见。这可能包括重新审视需求、重新分配任务、调整时间表或优化资源分配等方式。

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

网站的基础功能如发帖子、评论、注册登录都已经实现，并且暂无重大bug，大部分原计划的工作都已经完成。然而，存在一个已知的缺陷——无法回复评论，原计划中不包含了评论回复功能，但后期发现这个功能十分重要。

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

暂时没有。

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

团队为每个功能或模块制定了明确的需求和交付标准。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

团队采用了敏捷开发的方法，这意味着项目的过程可能不是完全按照传统的线性计划进行的，而是根据测试反馈和实际情况进行了调整。但这并不意味着项目没有计划，而是计划在执行过程中得到了灵活调整。

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

没有。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

对于将来的计划，我们团队可能会根据当前项目的执行情况和经验教训进行调整。例如，如果我们发现无法回复评论的缺陷是一个重要的问题，那么我们可能会调整计划，优先修复这个问题。此外，团队还可能根据项目的实际情况调整缓冲区的定义，以及是否采用加班等措施来确保项目的进度和质量。这些决策应该基于项目的整体目标、资源状况和风险评估来制定。

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

通过采用敏捷开发的方法，我们了解到项目计划可以根据实际情况进行调整，这有助于快速响应变化，并确保项目的顺利进行。改进：更全面地分析用户需求，设置缓冲区，持续收集用户反馈，强化团队协作和沟通，灵活调整计划。

（三）资源

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

团队包括了项目经理（PM）、用户界面设计师（UI）、前端和后台开发人员，这表示在人力资源方面，团队已经具备了完成网站开发所需的基本技能和角色。但是，在物质资源上有所欠缺。

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

由于团队成员先前已有团队合作开发经验，并熟知开发流程，他们使用了经验法则、类比估计或历史数据等方法来估计各项任务所需的时间和其他资源。

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

产品测试是在开发过程中一边测试一边完善的，团队在开发过程中已经分配了足够的时间用于用户测试。至于人力和软件/硬件资源是否足够，则需要具体分析。用户测试的资源是相对足够的。 对于不需要编程的资源，团队会分配少数非开发人员进行整合运用。

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

团队成员都各司其职，能够在自己的领域内高效完成任务，故而不存在这个问题。

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

一个完整的项目团队需要包含不同角色的专业人员，如项目经理、UI设计师、前端和后台开发人员等。这些角色各自承担着不同的职责，共同推动项目的进展。改进：加强物质资源管理，提高资源估计的精度，更加重视测试资源，更加合理地分配任务。

（四）变更管理

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

在发生变更时，团队内部有有效的沟通机制来确保每个相关的队员都能及时知道变更的消息。团队有一个明确的沟通策略或流程，以确保所有受变更影响的队员都能得到及时的通知。

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

我们可能采用了基于优先级、影响评估、资源限制等多种因素的综合考虑来决定“推迟”和“必须实现”的功能。团队需要定期回顾和评估这些因素，以做出合理的决策。

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

我们在项目开始前可能已经对出口条件进行了明确的定义，以确保项目能够按照预定的目标和质量标准完成。

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

团队内开发人员都具有一定的灵活性和适应性来应对可能的变更。所以没有制定应急计划。

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

在失物招领网站的开发初期，我们的团队就经过深入的讨论和协商，明确了项目的核心功能和关键需求。基于这些明确的功能需求，我们精心制定了一份详尽的计划表，详细规划了每个开发阶段的任务、时间节点和所需资源。这份计划表不仅是我们团队工作的指导方针，也是确保项目能够按时、按质完成的重要保障。
由于我们已经按照计划表中的任务和时间节点进行了有条不紊的开发工作，因此，对于突如其来的、意料之外的工作请求，我们很难再腾出额外的时间和资源来处理。这并非是因为我们不重视这些工作请求，而是因为我们的计划表是基于明确的功能需求制定的，每一个步骤和环节都紧密相连，不容有失。
当然，我们理解在项目开发过程中，可能会遇到一些不可预见的情况和变化。但是，为了确保项目的整体进度和质量，我们需要在保证核心功能和需求得到满足的前提下，谨慎地处理这些意料之外的工作请求。在必要的情况下，我们会根据实际情况进行调整和优先级排序，以确保项目能够按照预定的计划顺利推进。

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

在项目中，确保每个相关员工都能及时知道变更的消息是至关重要的。这有助于保持团队的同步性和避免由于信息不畅导致的误解和延误。改进：制定应急计划，增强灵活性以应对意料之外的工作请求，加强团队间的协作和沟通，持续学习和改进。

（五）设计/实现

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

在开始的时候，我们一起商议了接下来等待完成的大方向和各个工作。对于新增接口，功能需求分析，由需求分析工作的人员负责，再由前后端人员分别实现。

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

没有，功能需求以及框架设计由各自负责的人设计，如有问题会及时改正。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

没有，开发阶段的测试工作由开发人员负责，及时发现问题并修改，代码基本完成后由其他同学再进行全面的测试，发现问题及时报告沟通，尝试解决。

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

在开发期间，在注册登录功能上修正的bug最多，发布后发现了搜索功能的小bug，并无重要的bug，程序能正常运行，功能也基本能实现。进行时主要关心的是实现这些功能，而对于这一个功能对其他部分的影响没有做全面的考虑，以及一些小的细节没有注意到。

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

基本完成，时间有限，并没有深入、严格地进行代码复审。

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

在项目的开始阶段，团队就已经对设计工作的分配进行了明确的规划，确保了合适的时间和人员来完成各项任务。改进：引入单元测试和TDD，更全面的测试，严格执行代码复审，加强功能间的交互考虑。

（六）测试/发布

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

有，敏捷开发之前已经发布测试计划。

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

没有，因为时间有限，只将流程跑了一下看有没有什么问题。

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

是的。前端使用的测试平台：VSCode、Chrome。后端使用的测试平台：IDEA、Chrome、Linux 3.10.0-1160.114.2.el7.x86_64、apifox

4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

软件的效能主要是指并发性和压力测试，由于资源和人力不足的原因并没有测试，仅使用几个测试平台进行测试。

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

服务器不稳定，可能会死机，或因为异常原因关停，得人工重启。

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

使用多种测试工具来辅助测试工作，包括VSCode、Chrome、IDEA等，在测试方面要兼具专业性和工具选择的灵活性。改进：执行正式的验收测试，增加效能和压力测试，改进服务器稳定性，更新测试计划。

（七）总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

达到了CMMI二级——管理级的程度。我们团队完成了既定的计划和流程，但还没有一套完整的管理措施。

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

萌芽，还需要多改进和学习。

你觉得目前最需要改进的一个方面是什么?

团队应多面对面交流,增强团队凝聚力和互动性。

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

名字	角色	团队贡献分	可验证的贡献
廖莹（组长）	PM	18	PM工作、部分前端设计和项目分析、统筹安排、敏捷开发部分博文内容排版撰写、功能测试、复审
姚佳如	项目设计	17	需求分析、项目设计分析、功能测试、复审
李慧娣	项目设计	17	需求分析、项目设计分析、博文内容排版撰写、功能测试、复审
梁丽贤	前端	22	前端开发，测试
欧文杰	后端	22	后端开发、测试
肖杨	前端	22	前端开发、测试
黄诃华	后端	22	后端开发、测试