项目回顾
设想和目标
- 我们的软件要解决什么问题？是否定义的很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们要解决线下考试进行考务安排困难、现有系统无法支持大规模在线考试的问题。
- 对于需求我们没有定义的很明确，只包含了一个模糊的最终目标和众多不重要的功能点，没有对需求进行进一步分析。
- 没有对典型用户和典型场景进行相关调研。
- 是否有充足的时间来做计划
- 团队具有充足的时间来做详细的调研与计划设定，在计划阶段并没有合理利用时间。
- 团队在计划阶段是如何解决对于计划的不同意见的？
- 在计划阶段，我们团队并没有很好的对计划的不同意见进行合理的解决，大部分情况下为”一言堂“。
用户量、用户对重要功能的接受程度和我们实现的预想一直么？我们离目标更近了么？有什么经验教训？如果历史重来一遍，我们会做什么改进?
- 由于项目并没有达到可用阶段，所以用户量为零，用户期望的重要功能并没有实现
- 我们离目标的进度仿佛一直没有变动，回顾原因后，认为离目标的进度没有变动的原因主要是对项目的目标定义不清楚，对我们需要在项目中完成的内容没有很好的分析
- 在此次项目中我得到的经验教训是：应认真对需求分析，分析项目中真正需要完成的部分，少做无用功
- 如果重来一遍，对需求重新调研并且分析，并且尝试调研典型用户以及场景，将其细分后，分析出项目真正需要完成的部分
计划
- 你原计划的工作是否最后都做完了？如果有没做完的，为什么？
- 原有计划到课程结束时也没有完成。由于团队内对项目技术掌握不成熟，无法进行高效的开发。
- 有没有发现你做了一些事后看来没必要或没多大价值的事？
- 在对整个项目过程进行分析，我认为我所做的50%的功能都是可以通过调用现有系统接口来完成的。
- 是否每一项任务都有清楚定义和衡量的交付件？
- 大多数的任务都没有清楚定义和衡量的交付件。
- 是否项目的整个过程都按计划进行？
- 项目的整个过程都在延期的状态。
- 在项目中有没有留下缓冲区，缓冲区有作用么？
- 在项目中没有留下缓冲区，以致项目完成度低、项目整体延期。
- 将来的计划会做什么修改？
- 将来会尝试在发布任务时留下缓冲区以对项目中可能存在的问题进行缓冲，避免项目出现大规模延期的情况
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 在此次项目中，我初步学到了如何去制定项目计划
- 如果重来一次，会在计划中留下部分缓冲区对项目可能存在的问题进行缓冲，避免出现大规模延期或其他可能导致项目无法正常完成的情况。
资源
- 我们有足够的资源来完成各项任务么？
- 我们具有足够的资源完成各项任务
- 各项任务所需的时间和其他资源是如何估计的，精度如何？
- 各项任务所需时间和其他资源是根据功能模块的复杂度而言，精确到了天
- 测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源(美工设计/文案)是否低估难度？
- 测试的时间、人力和软件/硬件资源足够。
- 项目中几乎没有使用到不需要编程的资源
- 你有没有感到你做的事情可以让别人来做(更有效率)?
- 对于部分任务而言，我感觉别人来做可以更有效率，比如配置页面路由等
有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 项目中对于完成任务所需时间安排不明确，过度高估完成任务所需时间
- 重来一遍的话，我们会根据团队成员水平重新安排任务时间
变更管理
- 每个相关的员工都及时知道了变更的消息吗？
- 不是所有人都能在第一时间收到变更消息
- 我们采用了什么办法决定“推迟”和“必须实现”的功能？
- 我们并没有使用任何办法决定“推迟”和“必须实现”的功能
- 项目的出口条件(Exit Criteria——什么叫“做好了”)有清晰的定义么？
- 有较为模糊的定义，即通过开发人员的简单测试并通过后
- 对于可能的变更是否能制定应急计划？
- 对于可能的变更，我们并没有很好的制定应急计划的能力
- 员工是否能够有效地处理意料之外的工作请求？
- 部分团队成员可以有效地处理
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 要做好变更预案，以备计划外的变更情况
- 如果重来一遍，我们会对出口条件进行明确定义，并在发布变更消息时准确通知到每一个人并保证收到
设计/实现
- 设计工作在什么时候，有谁来完成？是合适的时间，合适的人么？
- 设计工作在项目的初期就开始设计，由团队原先的UI设计师完成
- 时间认为较为合适，但是人选不合适
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有，对于页面布局问题上存在，后团队沟通选出一个较为合适且编写较简的样式
- 团队是否运用单元测试(Unit Test)、测试驱动的开发(TDD)、UML或其他工具来帮助设计和实现?这些工具有效么？
- 有使用Postman工具来帮助后端实现
- 使用中出现了Postman接口调用不产生跨域问题，并不是很有效的帮助完成后端开发
- 什么功能产生的BUG最多，为什么？在发布后发现了什么重要的BUG？为什么我们在设计/开发时没有想到这些情况？
- 所有需要向后台获取数据的功能都存在共性问题，即跨域调用，由于初期开发时忽略了跨域问题，导致前端调用接口时无法调用
- 我们的项目由于没有完成并没有进行发布
- 开发时由于忽略了Postman调用接口不会产生问题而对跨域问题进行了忽略
- 代码复审(Code Review)是如何进行的，是否严格执行了代码规范？
- 并没有很好的进行Code Review
- 并没有统一的代码规范，每个人遵守着自己的规范
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 应对项目中可能遇到的问题进行较为完善的估计
- 在项目初期对项目设计选用合适的人选，并对项目进行过程中可能存在的问题进行充分的估计，制定统一的代码规范
测试/发布
- 团队有没有测试计划？为什么没有？
- 团队有测试计划并进行了测试
- 有没有做过正式的验收测试？
- 没有做过正式的验收测试
- 团队是否有测试工具来帮助测试？
- 团队没有测试工具来帮助测试
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些工作有用么？应该有哪些改进？
- 仅根据实际的运行结果来定义
- 从实际效果来看，这些工作较为有用
- 应使用一些自动化测试工具以及性能测试工具进行测试
- 在发布的过程中发现了那些意外问题？
- 项目并没有进行最终发布
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 应对测试用例设计充分，并使用一些工具协助测试
- 编写大量的测试用例进行测试，并使用一些自动化测试工具进行测试
总结：
团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
- 初期是根据每个人所擅长的技术进行分配，团队成员变更后几乎所有团队成员都是开发人员
- 并不是所有人都是人尽其才
- 团队成员之间有互相帮助吗？
- 团队成员之间有互相帮助
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 团队成员内讨论或寻求老师帮助
每个成员明确公开地表示对别人帮助的感谢：
我感谢王建对我的帮助，因为在她的帮助下我们共同的完成了题库子模块的页面显示。
每个成员的软件工程水平有什么提高？有什么数据证明这些提高？
- 团队成员的软件工程水平没有明显的提高，提高的部分更多是个人的技术能力
你觉得团队目前的状态属于CMMI中的哪个级别？你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段？你觉得团队在这个里程碑相比前一个里程碑有什么改进？对比本书5.3.7TSP的原则或者敏捷流程的原则，你觉得目前最需要改进的一个方面是什么？
- 目前状态处于CMMI中的一级甚至可能没有达到
- 团队目前依旧处于萌芽期
- 相对前一个里程碑，团队成员有了更多的团队协作部分
- 最需要改进的是指定切合实际的计划和承诺
