一.设想和目标

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

• 我们要开发一个平台供师生和院校团体发布信息，接收资讯。
• 定义很清楚了。
• 对各用户和场景皆有清晰描述。
• 详情请查看我们的《软件规格需求说明书》
• 链接：https://www.yuque.com/qg05r4/pswt5r/ba2h5n

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

• 有，并在相应时间内制定了较为详尽的计划。

3. 团队在计划阶段是如何解决成员对于计划的不同意见的？

• 团队成员之间及时沟通，交流，最终得出一个大家都能接受的方案。

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

• 项目开始之初要尽快分配前期工作，迅速得出项目的设想与目标，并及时与项目成员交流，改进需求分析，让各位成员都能迅速明白我们的项目的设想和目标，方便后续工作的开展。

二.计划

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

• 做完了，因为是第一次团队项目，我们会根据实际情况来制定最近的计划，不会盲目空想以后计划，我们会隔一段时间给出之后一段时间的计划，并根据变化及时修改计划，完成计划的迭代。

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

• 没有，做的每一件事都有相应的价值存在，正因为做了，就算是不好的方法，我们也可以从中吸取经验，得出更好的方法。

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

• 每一项任务都有相对详尽的定义，若出现定义上或理解上的问题，队员们可以及时讨论，得到清楚的定义。
• 交付件无定量，经验不足，难以制定定量的交付件。

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

• 大部分时间都是按照计划进行的。但是当别的课程布置了量很大的作业时，我们会有不可抗力因素，要优先完成别的迫切要交的作业，再来完成团队项目。另外开发时间超出估算，开发难度超出预计，这些是经验不足产生的问题。不过最后我们还是能按时完成每周的团队项目任务，但某些时候队员压力比较大。

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

• 计划中留有空余的时间供团队成员合理分配自己的工作用时，我们认为是有作用的。

6. 将来的计划会做什么修改？

• 计划会根据实际情况作出修改，无法确定是什么修改。

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

• 计划需要迅速制定，且灵活，留有空余时间，提前分配好修改计划的空间。

三.资源

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

• 我们有较为合理的成员分配方式，各位成员可以发挥所长，各司其职来完成相应工作，但资源是不足的，需要边做边学习，获取更多的资源。

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

• 综合考虑任务难度与任务量，将各项任务分成1-10小时的小任务，精度：小时。

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

• 时间，人力足够，但软硬件资源有所欠缺。
• 不需要编程的资源估计难度与实际相差不大。

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

• 暂无。

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

• 将资源获取的部分在整个项目进程中提前，会使我们对项目开发理解得更好。

四.变更管理

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

• 都及时知道，通过微信群和羽雀文档安排。

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

• 参考构建之法，将功能分为四个象限，优先完成主要的功能（1，2象限的功能），推迟完成辅助功能。

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

完成以下条件即可出口：

• 各模块之间连接无明显问题；
• 实现发帖，看贴，标签管理的基本功能；
• 实现登录注册、点赞、评论、收藏、评论、编辑个人信息的必要辅助功能；
• 日常使用中不出现明显bug。

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

• 有，如有变更我们会迅速讨论，及时给出应急计划。

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

• 能，遇到这样的任务请求我们可以很快沟通并处理。

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

• 管理需要明确且灵活，给各位成员留有改变相应安排的余地，这样会使我们在项目开发中更得心应手，任务执行起来更有目标性。

五.设计/实现

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

• PM负责功能与界面设计，Dev负责架构设计，时间合适，人员合适。

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

• 给出原始方案，然后沟通解决，后续改进。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

• 由于时间较紧，相关测试学习成本过大，我们没有运用以上工具。

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

• 主页显示产生的Bug最多，因为主页显示与其他模块关系密切，数据交互起来容易产生奇怪的Bug。
• 发布之后发现的重要的bug：有时候界面会同时打开两次。
• 没考虑到这些情况是因为我们缺乏经验，且使用的技术很多坑，对新手不友好，一时间会出现很多奇怪的bug。

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

• 我们采用  Git Flow + Pull Requests 模式来做Code Review，严格执行了代码规范。

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

• 我们会把设计做得更细致，提前完成每个功能模块的构思，给出一套完整的设计方案。

六.测试/发布

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

• 有。

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

• 有，对所有功能都进行了测试。

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

• 没有用到测试工具，因为第一次进行测试，所以就先采用了人工测试。

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

• 查看软件对系统内存的占用量，并根据用户感受来跟踪软件效能。
• 测试工作有用。

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

• 没有。

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

• 我们学到了软件测试/发布的基本知识和基本流程，如果重来一遍，我们会尽量使用一些有效的软件测试工具。

总结:

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

• 二级。

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

• 磨合。

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

• 技术、开发经验缺乏，需要进一步学习掌握。

博客要附上全组讨论的照片

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

我们将20N的瓜分配给所有成员，总分20*6 = 120分。

PM：项目经理    Dev：开发    Test：测试