设想和目标
1. 我们的软件要解决什么问题定义得很清楚对典型用户和典型场景有清晰的描述h3>
帮助选修物理实验的学生撰写实验 告，计算实验数据，验证计算结果，并提供一个讨论的平台。
全体成员认为该问题定义的很清楚。
典型用户和典型场景在测试 告中有描述，全体成员认为描述很清晰。
2. 我们达到目标了么（原计划的功能做到了几个照原计划交付时间交付了么计划达到的用户数量达到了么
我们没有达到目标。原计划功能有三个：
- 物理实验的评价
- 实验流程
- 理论题库
其中物理实验评价被推迟到 Beta 阶段，理论题库只有一个十分简陋的 Demo，实验流程未达到上线标准。从交付上来说无论从质从量来说都不甚合格。
计划的用户数量为 30，达到了项目预期。
3. 用户量，用户对重要功能的接受程度和我们事先的预想一致么离目标更近了么h3>
用户量达到了团队的预期。
用户对重要功能的接受度可以通过生成 告的数量来判断
….
对于这个项目的目标是有接近，但对项目的增量开发目标接近程度很低。
4. 有什么经验教训历史重来一遍, 我们会做什么改进h3>
在目标设定上团队全体成员认为没有问题。如果重来一遍，可能我们会做出同样的选择。
计划
1. 是否有充足的时间来做计划h3>
PM 个人认为使用了较为充足的时间来做计划。
团队其它成员对此问题无法回答。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的h3>
计划基本由 PM 一人在个人考量与询问团队成员想法后制定，在制定完成后会通过全体成员。在实施过程中并没有遇到不同意见。
3. 你原计划的工作是否最后都做完了有没做完的，为什么h3>
没有都做完。
李煦通
主要的时间花费在恢复数据库上，经常卡在一个问题上很长时间，做起来没有动力，进而导致不愿意在这方面投入时间。
石奇川
题库只是先实现了一个简单的，期望目标的功能较多，目前现有的参考不多；实验流程没有什么思路，也就没实现，教师评价也没有具体的考虑，然后由于个人原因比较拖延，进度不多。
王嘉睿爵
完成了 站 bug 的检查以及较建议的压力测试，须进一步做复杂的模拟用户操作的压力测试及负载测试来测试本项目。
游心
部分完成了实验流程的收集整理，还有一部分需要再去找学弟学妹收集。实验脚本部分基本上都没有遗留问题，有些路径依赖还需要探讨改进。
刘子渊
计划的工作是撰写本阶段博客，就这个意义上来说是完成了。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事h3>
李煦通
没有。
石奇川
没有。
游心
没有。
王嘉睿爵
在 Alpha 阶段有，熟悉了部分框架与语言，但本测试并没有实际参与代码的单元测试，因此测试时该部分对总体贡献不大。Beta 阶段可以深入前后端的单元测试。
刘子渊
作为一个 PM，制定计划的同时也撰写了本阶段的博客，因此没有什么是没有必要或没价值的事。
5. 是否每一项任务都有清楚定义和衡量的交付件h3>
学习任务没有清楚的定义和可以衡量的交付件。
全体成员认为其余任务都有清楚定义和可衡量的交付件。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外么风险是当时没有估计到的，为什么没有估计到h3>
项目并没有按照计划进行，项目出现的意外是数据库没有按时恢复。该意外发生的原因是低估了回复数据库的难度。
整个 站的运行非常依赖于数据库，但有关数据库的文档并没有留下来，只能通过代码寻找有关数据库的信息。同时数据库的结构又非常复杂，包含了两个不同的框架的表，也有共同使用的表。另外在过去的开发过程中，进行了多次的数据库更改，但并没有留下文档，反而保留了旧的代码，形成了很多误导，导致走了很多弯路。
具体详见数据库恢复文档。
7. 在计划中有没有留下缓冲区，缓冲区有作用么h3>
PM 觉得留下了缓冲区，具体来说制定了一个最低的完成标准，然后以此为底线开发。
该缓冲区有作用，甚至预留的还不够多。
8. 将来的计划会做什么修改如：缓冲区的定义，加班）
PM 认为应该当断则断，尽早的提出重构。同时应该建立一个更加畅通的交流机制，比如如果有问题不能解决及时提出，以寻求其它组员在人力/技术上的支持。
全体组员对此表示赞同。
9. 我们学到了什么历史重来一遍，我们会做什么改进h3>
对预后不好的事项（此处比如数据库恢复问题），应该即使指定攻坚策略，比如重构或者多投入人力。具体来说，应当指定一个必须完成的线，当逾期时，应该短时间诊断问题所在，集中力量解决该问题。
资源
1. 我们有足够的资源来完成各项任务么h3>
李煦通
在恢复数据库的过程中，经常陷在问题里面，导致自己一个人做时间不足，希望可以有人和我一起共同完成。
石奇川
有足够的资源，只是我太拖延，导致进度慢。
游心
有。
王嘉睿爵
有。
刘子渊
有足够的资源。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何h3>
对于时间和其它资源的估计由于对于任务了解不够（之前没有使用同语言开发同类型项目的经历），导致估计基本上只是一个感性认识，其精度很粗。
到了后期由于卡在关键任务上不能执行下一步计划，因此估计完全失控。
3. 测试的时间，人力和软件/硬件资源是否足够那些不需要编程的资源（美工设计/文案）是否低估难度h3>
时间足够；人力资源（测试人员有足够精力进行测试），因此足够；软件资源足够，压力测试及负载测试有许多可以利用。
对于不需要编程的资源，如题库的答案验证等，均及时地得到了反馈，因此未低估其难度。
PM 知道撰写博客会花费较多时间，因此有一个充分的心理准备，没有低估其难度。
4. 你有没有感到你做的事情可以让别人来做（更有效率）h3>
李煦通
希望有人可以和我一起来恢复数据库。
石奇川
工作量倒是可以一个人搞定，但是想要有个人能够催一下我的进度，应该能提升效率。
游心
工作量上一个人可以搞定。
王嘉睿爵
只要善于运用各项测试工具均可高效给出测试结果以及 bug 清单，目前本人所做处于一个基本阶段，应更加细致与完善。
刘子渊
在撰写博客/制定计划上人与人之间的差距比较小，因此个人认为让别人来做效率会持平。
5. 有什么经验教训历史重来一遍, 我们会做什么改进h3>
经验教训同计划修改部分一样。做到了上述修改会使得我们将有限的时间用在刀刃上，并且消除一些惰性因素，使得项目的完成度更加有保障。
变更管理
1. 每个相关的员工都及时知道了变更的消息h3>
所有的变更都是在 PM 那里完成的。由于当变更发生时，并没有对应的正在进行的实际任务，因此变更只有 PM 知道。在会议上 PM 同成员谈论了相关变更，由于同样的原因，实际上并没有造成太大的影响。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能h3>
根据实现难度和项目剩余开发时间决定的。时间是第一要素，然后在估计可以完成的功能中选择价值最高的完成。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么h3>
有清晰的定义。详见测试 告 Alpha 版本的出口条件 一节。
4. 对于可能的变更是否能制定应急计划h3>
制定了应急计划。对于进度不顺畅的情况有了较为充分的预期，并定义了最低的可交付功能条件。
5. 员工是否能够有效地处理意料之外的工作请求h3>
由于 1. 中所说的理由，没有这样的实际场景。
6. 我们学到了什么历史重来一遍，我们会做什么改进h3>
PM 应该将变更尽早的通知全体，即使在 PM 已经指定了决策的情况下。这样可以让全体成员从宏观上知道项目的风向标发生了那些变化，并比对自己的工作是否对这种变化有正/负贡献。
设计/实现
1. 设计工作在什么时候，由谁来完成的适的时间，合适的人么h3>
整体的设计工作在最初完成，具体的设计工作则是当 PM 认为本项任务拥有一个短期内可进行的估计时进行具体设计。任务的负责人按照对应的任务类别（开发、测试、脚本和实验、前端）分派到各负责人手上。
任务的具体设计形式是由 PM 提出，然后和相关负责人探讨得出相应的设计方案，也即设计方案得到了相应人员的同意。全体组员认为实在合适的时间进行了设计，并交给了合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的h3>
设计工作有遇到模棱两可的时候，但这种模棱两可会在 PM 同相应负责人交流的时候通过问答形式消除。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现工具有效么较项目开始的 UML 文档和现在的状态有什么区别区别如何产生的要更新 UML 文档h3>
没有。由于进度拖的比较严重，前期在修问题，后期在赶进度，因此没有使用相应工具。
4. 什么功能产生的 bug 最多，为什么布之后发现了什么重要的 bug么我们在设计/开发的时候没有想到这些情况h3>
移动端和题库的功能 bug 最多：很多 js 插件不支持移动端，加上浏览器不支持等。因为在开发时主要考虑设计的是 PC 端的实现，只利用框架自带的移动端响应式，未细致考虑插件不兼容问题。
发布后发现的疑似重要 bug 是 1071 告无法生成。该 bug 的具体原因还没有定位。在设计/开发时未发现的原因可能是因为对具体的使用场景了解不够细致所致。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范h3>
该问题由开发组人员石奇川、李煦通和游心回答。
石奇川
前端代码没有严格执行代码规范，也发现上次继承下来的东西也没有执行当时的代码规范。
李煦通
主要工作都在恢复数据库上，只对很少的代码进行了修改。
游心
负责收集整理实验相关部分，没有代码修改。
6. 我们学到了什么历史重来一遍, 我们会做什么改进h3>
学到了共同做项目相互配合以及合理地分配时间。
在实现的过程中遇到困难要及时和大家沟通，寻求帮助，不要一个人埋头干。
测试/发布
1. 团队是否有一个测试计划么没有h3>
没有，测试按照开发给定的功能逐个从移动端以及 PC 端进行测试，未事先拟好测试计划。
2. 是否进行了正式的验收测试h3>
进行了验收测试，并给出出口条件，详见测试 告 Alpha 版本的出口条件 一节。
3. 团队是否有测试工具来帮助测试h3>
有，进行压力及负载测试时使用 Apache 自带 ab 工具，模拟发送用户请求至多个主要页面以进行测试。
4. 团队是如何测量并跟踪软件的效能的件实际运行的结果来看，这些测试工作有用么有哪些改进h3>
除测试给出 bug 清单外，主要根据压力及负载测试结果进行评估。从 站响应及返回数据情况来看，数据处理及 告生成功能响应时间较快且稳定；相反，讨论区的大文章（含图片）响应较慢，且存在概率较大（高并发情况下 25% 左右）的 Request Failed，此处应当进一步改进。
详细测试结果可详见测试 告 Alpha 版本的出口条件 一节。
5. 在发布的过程中发现了哪些意外问题h3>
遇到的问题主要存在于浏览器兼容性与移动端兼容性。Microsoft Edge以及 Firefox 浏览器均不支持“工具”功能；移动端的 pdf 显示插件以及讨论区的前端界面，均存在较差的用户体验。这在发布之前没有考虑到。
6. 我们学到了什么果历史重来一遍, 我们会做什么改进h3>
学习到了测试工具的应以及软件发布之前的全方位考虑思维。如果重来一遍，测试人员应当在项目开始之尽快拟定测试 告，与开发形成相互促进的合作关系，在开发过程中不断进行测试，反馈问题，以优化项目。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才h3>
通过志愿 + 协商方式决定。
PM 觉得自己还是比较适合开发工作。测试觉得自己还能做的更好。其余组员表示达到了人尽其才。
2. 团队成员之间有互相帮助么h3>
有。在相关技术问题上会请教相应人员，比如配置开发环境等。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题h3>
通过协商讨论解决。整个项目过程中没有出现特别大的分歧，包括争吵。
4. 我们学到了什么历史重来一遍，我们会做什么改进h3>
如果历史重来一遍，可能 PM 会选择当一个开发；测试人员应当在项目开始之尽快拟定测试 告，与开发形成相互促进的合作关系。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次h3>
处于第二级可管理级。不过也比较勉强，与初始级的差别并没有特别显著。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段h3>
磨合阶段，有一定的熟悉程度，但对相互之间的工作模式还不太了解，因此对于一些行为中反映出的言外之意不能很好把握。团队需要在加强沟通，及时交流问题和工作中的困难，并发表自己对于项目的一些看法。
你觉得目前最需要改进的一个方面是什么h3>
如前所述，需要在团队沟通方面进行加强。
对照敏捷开发的原则，你觉得你们小组做得最好的是哪几个原则出具体的事例。
保持简明——尽可能简化工作量的技艺——极为重要：PM 会在任务有明确轮廓时进行分发，而不会只有大体设计时就进行分发。这样可以使得每项任务的完成指标比较明确，有明确的目标指向。
什么是在下个阶段要改进的地方体越好。
在下个阶段，我们要改变工作模式，每天抽出一段时间进行共同开发，比如每天晚上 1 到 2 小时，这样可以及时了解各个成员间的进展与问题，也方便进行讨论。
即使进行代码复审，帮助掌握进度的同时确保一份代码两人负责，减少 bug 的发生概率。
进一步增加测试的复杂度，从简单的模拟发送请求到编写脚本测试每一个功能。
文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树数据库组成表32474 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！