GCGL软件工程Postmortem
一.设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要通过实时监控交通流量、智能信号灯控制和优化车辆调度，构建一个高效的城市智能交通管理平台，有效缓解城市交通拥堵问题，提高应急车辆通行效率，并为各类交通参与者提供最优出行方案。定义清楚，对用户和应用场景有清晰描述。 - 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
由于时间安排和项目工作量关系，有部分目标未达成，软件未投入实际应用阶段。 - 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
应用并未上线面向大众用户。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
项目设立时未充分考虑项目工作量，时间管理出现问题，工作效率较低。如果重来，我们将会制定更充分的项目时间表并提高工作效率。
二.计划
- 是否有充足的时间来做计划?
有充足的时间来做计划 - 团队在计划阶段是如何解决同事们对于计划的不同意见的？
通过团队商议讨论，最终达成意见统一 - 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
由于课程和项目工作量时间冲突的原因，工作没有全部做完 - 有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有 - 是否每一项任务都有清楚定义和衡量的交付件?
是 - 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
否，项目工作量过大没能很好地完成项目，在项目立项时没意识到这一点 - 在计划中有没有留下缓冲区，缓冲区有作用么?
有 - 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将会完善项目时间管理，留足缓冲区
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
将重新审视项目的可完成性，努力完成项目
三.资源
- 我们有足够的资源来完成各项任务么?
项目人力资源只有三人，时间也比较紧缺。 - 各项任务所需的时间和其他资源是如何估计的，精度如何?
主要是对项目各阶段时间的估计，精度以周为单位。 - 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
硬件资源足够，但人力资源紧缺，项目还未考虑到美工和文案设计。 - 你有没有感到你做的事情可以让别人来做（更有效率）?
项目分工较为明确合理，不觉得我做的工作让别人做会更有效率。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
会对项目时间和人力资源安排进行充分考虑，使项目工作量可以适配我们所拥有的时间和人力资源。
四.变更管理
- 每个相关的员工都及时知道了变更的消息?
每个相关员工都及时知道变更消息 - 我们采用了什么办法决定“推迟”和“必须实现”的功能?
通过分析项目需求，项目最基本的监控交通流量、智能信号灯控制功能为必须实现，其他如优化交通方案等功能为推迟。 - 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
定义为项目能实现设定需求，通过了充分测试，代码能通过代码审查，缺陷率和测试通过率满足最低要求。 - 对于可能的变更是否能制定应急计划?
能 - 员工是否能够有效地处理意料之外的工作请求？
能，员工都积极配合
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
对成员的任务划分更加细致明确，对风险有应急预案
五.设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目初期阶段由杜树扬完成，时间合适，小组成员一致认为是合适人选。 - 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
无 - 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
有，这些工具能够显著提高工作效率。 - 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
并未发现有功能的bug比较多 - 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由各个成员各自负责自己所写的代码，严格执行代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在设计阶段应该进行更充分讨论，明确项目各部分负责人。
六.测试/发布
- 团队是否有一个测试计划？为什么没有？
有 - 是否进行了正式的验收测试？
暂未进行正式验收测试，只是通过运行代码来进行初步测试。 - 团队是否有测试工具来帮助测试？
无，采用人工手动测试 - 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
通过不断增加负载直到系统无法继续处理来找出系统的极限。压力测试帮助确定系统在极端条件下的可靠性和稳定性，识别瓶颈和可能崩溃的地方。它不仅测试系统如何处理过载，还测试它恢复正常运行的能力（例如，负载移除后系统能否恢复到正常状态）。
测试工作有用，虽然压力测试可以模拟极端条件，但在一些场景下，它们可能与实际生产环境的负载模式有所不同。通过模拟更真实的用户行为（例如，模拟用户的行为模式、并发访问模式等），能够使测试更具代表性。 - 在发布的过程中发现了哪些意外问题？
未发现意外问题。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
应该学会使用测试工具测试软件，摆脱手动测试。
团队的角色，管理，合作*
- 团队的每个角色是如何确定的，是不是人尽其才？
通过团队讨论商议确定，每个人都有各自负责的部分 - 团队成员之间有互相帮助么？
有 - 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
通过商议讨论解决问题
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于CMMI二级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
处于磨合阶段，团队成员还要多交流磨合
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
任务分配更合理
你觉得目前最需要改进的一个方面是什么?
团队成员各自工作时间不重叠，团队协同性不够
浙公网安备 33010602011771号