一.设想和目标
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：测试
|
名字 |
角色 |
团队贡献分 |
可验证的贡献 |
|
蔡双浩 |
Dev |
19 |
个人中心的开发 关注、粉丝功能的开发 收藏功能的开发 |
|
陈创智 |
Dev |
18 |
创作中心的开发 草稿箱的开发 |
|
陈纪禧 |
Dev |
21 |
帖子显示模块的开发 点赞、评论、收藏、关注接口的开发 |
|
程伟杰 |
PM |
23 |
博客，团队文档的编写 注册登录模块的开发 界面、功能的设计 |
|
高山 |
Test |
17 |
提交测试计划 编写测试报告 |
|
谢立新 |
Dev |
22 |
系统架构的原型设计 首页模块的开发 搜索功能的开发 |