目录

一、 设想和目标

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

• 我们的项目是学生信息管理系统，主要是帮助管理员用户解决学生和课程信息的管理以及帮助普通用户对于选课和自身信息的管理，我觉得我们对典型用户和典型场景的描述较为清晰，针对管理员用户和普通学生用户，我们进行了调查和场景模拟，对于他们的需求进行了基本的功能实现，但后期仍有问题出现待我们去解决和增加。

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

• 我们达到了原计划的功能并按交付时间交付了，但对于原计划中的用户数量的后期增扩还没进行测试。

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

• 不太一致，因为我们疏忽了课程信息的内容，缺少了教师的部分。

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

• 对于功能的分析还是太浅薄，疏忽了一些界面逻辑以及信息细节。
• 若重来，我们会再多沟通，互相讨论找到策划的不合理之处并进行及时改进。

二、 计划

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

• 有。

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

• 大家未提出不同意见。

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

• 原计划都做完了

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

• 有，帮大家承担一部分活就很没必要。

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

• 是。

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

• 不是，中途有一周的博客因为内容的素材成员未完成而延期；有预估到，但因为个人懈怠没及时解决。

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

• 没有。

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

• 留下充足的缓冲区，对项目的不足进行及时补充和修改。

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

• 我们学到了一个项目落实到完成的整个过程，也试着按我们制定的计划流程来行动，发现合理的安排能减少很多无用功并提升效率。
• 若重来，将制定更合理的计划来推进项目。

三、 资源

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

• 人力资源：团队只有五个人，每人的任务量较大，完成难度不易。
• 开发资源：由于我们的成员代码薄弱的较多，开发过程也很磕磕绊绊，但通过网上查资料、和大佬讨论咨询，也努力克服众难实现了项目的基本功能。
• 设备资源：没有问题。
• 时间资源：时间较紧，平时的课程较多，其他课程的作业也挺繁琐。

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

• 根据任务量以及成员的实力评估，精度一般，因为大家完成任务的专注度总是飘忽不定。

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

• 除了人力资源不太够，其他都还好；对于美工设计难度评估还好，可能与我们之前的课设作业有做过美工界面设计等有关。

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

• 我们的分工都有按个人能力去分配，有但大家还是个人承担起自己的那一部分，不懂的在群里提出并大家一起解决。

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

• 团队的组建还是要早一点积极一点，争取合适的人员，使任务量分配更合理。
• 若重来，我们会提前学习自己负责分工的那部分知识，来提高团队效率。

四、 变更管理

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

• 是的。每位成员在提交或更新功能后，会在群里进行消息分享，登上GitHub的团队仓库即可查看变更消息。

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

• 我们根据用户需求、功能实现难度和功能之间的联系来决定。对于用户不太重要的功能合理安排推迟，优先实现必要功能，对于功能较复杂的也会稍往后推。

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

• 有
  • 系统可正常登陆使用
  • 多用户使用系统不崩溃
  • 测试发现的bug得到修复
  • 功能实现完整无bug

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

• 有，若我们的能力无法修复一些bug的话，我们将继续推出原版线下进行学习持续尝试直至能够推出最新版。

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

• 可以，我们相信三个臭皮匠顶一个诸葛亮，对于意料之外的工作，会齐心协力一起解决。

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

• 学会了成员之间及时沟通的重要性
• 若重来，我们会加强联系，来及时应对突发情况和难以解决的麻烦。

五、 设计/实现

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

• 在beta阶段开始的，由大家一起讨论商量前后端实现的可行性后确定下来，由彭靖玥同学进行界面的逻辑设计，前端代码由陈莹莹同学完成。

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

• 有，对于界面按钮的功能和逻辑是否合理性和必要性，大家一起进行了讨论和商榷。

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

• 我们使用的是java自带的junit单元测试，基本满足我们的测试需求。

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

• 登录和查询功能。在登录上面我们会出现登录失败的例子，找不到原因，但在重新设置后又可以正常登陆了，同时在课程信息查询和学生信息查询上会出现查询结果混乱的情况，这个也有在修复。
• 没提前想到的原因是大家主要将重心放在功能的实现上了，对于出现的bug情况没有全面考虑到。

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

• 由于人力和时间的不足，我们只进行了一次初审，由负责该部分的同学备注了各自的功能部分，不是很详尽。

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

• 我们学会了实现功能不可一味埋头苦干，还要灵活应对各种问题，而在开始前就应该有个评估和心里预测，避免后期心态崩掉拖慢进度。
• 若重来，我们会好好进行一个预期情况清单，加强沟通。

六、 测试/发布

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

• 有，但不算太完善，针对各个功能模块的测试计划。

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

• 项目问题还挺多的，待完善后再进行验收测试。

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

• 没有，我们采用的是人工测试。

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

• 我们只是在多台电脑上进行了多用户登录测试，这一点上测试结果还行，对于效能则由于时间关系并没有进行测试。

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

• 系统登录不进去，界面有乱码等。

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

• 我们学会了一个完善的测试计划对项目落地的帮助会很大，不会造成测试不完全和发布时出现很多突发问题。
• 若重来，我们会针对后续各种情况作出一个更完善的测试计划，并有时间去完成各类测试。

七、 总结

1. 每个成员在beta 阶段的实践和alpha 阶段有何改进?

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

• 达到了CMMI一级。我们完成了项目的目标，虽然在实施上遵守了既定的的流程和计划，但任务的完成充满偶然性。

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

• 处于磨合阶段。

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

• 成员之间的沟通和项目积极性方面是完成一切工作最大的问题。

八、 其他

1. 团队讨论照片
   

   

2. 个人本周完成情况

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