目录
1. 组长博客（2分）
2. 总结思考(27分)
2.1. 设想和目标（2分）
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 解决任务群不够好用、想问学校的相关信息却不知去哪里问- 我们的软件定义得很明确。
- 典型用户是使用QQ任务群或经常查找校园相关信息的福大学生。
- 典型场景：同学A想让别人给他领快递
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
- 尚未达到目标。原计划在Alpha冲刺完成的功能达成了基本的页面设计和任务悬赏的主要功能，还有校园百科的主要功能没有完成。并没有成功按照原计划时间交付。并没有达到原计划的用户数量，因为尚在开发中，并未交付
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 尚未推广，并没有用户量。我们正朝着目标稳步前进。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 规划的时候应当保守一些。如果历史重来一遍，我们会预先一一排雷，检查功能的可实现性，从规划中排除比如调用微信支付这种难以实现的功能
2.2. 计划（5分）
- 是否有充足的时间来做计划?
- 是。但是我们之前忽视计划的重要性，讨论得不够，导致计划需要随着开发进展不断修补
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 我们团队确实出现过严重的意见分歧，解决的方法是意见方先回宿舍准备一天，然后在第二天开会的时候陈述利弊，最后交由大家不记名投票表决。
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 没有。作为组长，需要掌握实时的开发情况，但是我却没有主动去了解，导致后来产生了计划与实际的脱节。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 暂时没有。
- 是否每一项任务都有清楚定义和衡量的交付件?
- 没有。这需要前后端充分沟通后，再进行详细的计划后，才能达成的。我们中并没有谁有开发经验，大家都是走一步看一步。
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 没有。Alpha冲刺历程中经历了若干次考试，一遇到考试，相关人员的开发进度就会暂搁两天。像这种突发性事件就是之前没有估计到的。主要是对时间的把控不够灵活
- 在计划中有没有留下缓冲区，缓冲区有作用么?
- 之前有计划预留最后三天为缓冲区，大家停下手头的开发专心弄Alpha冲刺展示。确实派上用场的，虽然只是最后一天。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 加大每一天的工作量，尽量将工作提前到Beta冲刺之前完成的。毕竟马上就有大波考试来袭
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 应该以模块划分项目，这样容易对开发进度有直观的掌握，且便于任务分配
- 分配任务的时候，要给出明确的deadline和要求，并在验收时根据成品的情况进行评估，并调节之后的开发任务。
2.3. 资源（3分）
- 我们有足够的资源来完成各项任务么?
- 主要是学习资源的问题。知识就在网上，问题在于如何获取并吸收它。如果增大精力、时间投入，就能有足够的资源来完成了
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 主要是通过负责该任务的人自行估计。精度很差。
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 人力、资源是足够的，问题是调度太差了。在我们的开发过程中，经常遇上个别人在开发，其他人在等待的情况，再充分的资源利用不当也是白搭。我们没有低估那些不需要编程的资源 (美工设计/文案)的难度。
- 你有没有感到你做的事情可以让别人来做（更有效率）?
- 没有。我没有参与开发，相对他人来说已经是轻装上阵了，若连这一点工作都推诿他人，怕是颜面尽失。
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 事先沟通好开发语言吧。我们后端中两人Java，两人Python，最终统一为Java。这也是我们之前没有预测到的不确定因素
- 对时间资源的调配要留有余地：预先留下缓冲区，避免考试等其它因素对开发产生较大阻碍作用
2.4. 变更管理（4分）
- 每个相关的员工都及时知道了变更的消息?
- 基本是的。经常发全体成员消息、公告
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 挑拣出核心功能，把不确定性大的、难以把握投入的、过分细节的功能推后
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 有。功能完备，易用性强
- 对于可能的变更是否能制定应急计划?
- 很难，基本上就是粗暴堆时间（熬夜）
- 员工是否能够有效地处理意料之外的工作请求？
- 还行吧，一般有这种情况都要求赶紧和组长说，组长再找人一起解决，摊匀了突发压力
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 在开发之前，将模块的实现和个人职责分割得更详细，这样就能比较有效减少模糊地带
2.5. 设计/实现（4分）
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 前端的界面设计工作是三周前开始的，由文彬、文涛负责。后端是稍晚一些，由世杰牵头完成的
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有的，通过讨论利弊后下决定的
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 没有，下次考虑引进。
- 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 有一点区别，主要是需求有在变化，可以更新UML文档
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 接口调试相关的Bug最多，因为涉及到前后端的交互。由于一开始都不了解，所以很难考虑到这些情况。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 大家一起看代码，代码规范上尽量向阿里巴巴靠拢。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了代码规范的重要性，如果历史重来一遍，我们会更加注意代码的规范。
2.6. 测试/发布（3分）
- 团队是否有一个测试计划？为什么没有？
- 没有。直到Alpha冲刺快结束的时候仍没有足够多的功能设计完备，团队工作重心仍在开发商
- 是否进行了正式的验收测试？
- 没有
- 团队是否有测试工具来帮助测试？
- 没有
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 在工具上实时测量调试。有用。改进：还可以使用更专业的软件
- 在发布的过程中发现了哪些意外问题？
- 没有
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了测试的重要性，实时调试。改进：更加注重测试阶段。
- 看到别组服务器被攻击，我们之后会避免暴露接口，也要准备应对措施
2.7. 团队的角色，管理，合作（3分）
- 团队的每个角色是如何确定的，是不是人尽其才？
- 角色主要是依据需求分析阶段，各自提交的志愿调和而成的。后来有个别调动。称不上是人尽其才，但能说是人尽其力。
- 团队成员之间有互相帮助么？
- 有。基本上是大佬带小白。尤其是世杰，有应必答。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 直接在前端/后端的群里说出来，当线上无法解决的时候再线下沟通
- 每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
- 我感谢世杰对我的帮助， 因为他是团队中最carry的人，还经常帮助我收拾烂摊子
- 我感谢团队里所有人对我的包容，当然我并不想要这个，有错误就指出来，这样才利于整个团队，毕竟一将无能累死三军。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 我们学到了交流的重要性，如果历史重来一遍，我们会深化沟通和合作，解决开发短板
2.8. 总结（3分）
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 我觉得团队尚处于CMM的初始级。我们确实在项目开发过程中出现缺乏健全的管理制度。开发项目成效不稳定的情况
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 规范阶段。现在大家都熟悉自己的职责了，当然开发规范仍得加强
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 沟通和合作能力大大提高
- 你觉得目前最需要改进的一个方面是什么?
- 计划。我们之前进行的开发都是比较盲目的。
- 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 避免不必要的开销。我们经常是先开工，当然这么做会比较盲目。我们也拖延了难以把控开发投入的任务，专心于实现核心功能
3. 答辩总结（6分）
3.1. 团队贡献比例
| 组员 | 贡献百分比 | 分工 | 备注 |
|---|---|---|---|
| 杨世杰 | 17% | 后端 | 表现很好 |
| 陈文彬 | 15% | UI | 表现很好，拥有稳健的开发步伐 |
| 林宏海 | 15% | 前端 | 表现很好 |
| 林文涛 | 12% | UI | 表现很好 |
| 龚洋林 | 10% | 前端 | 符合预期 |
| 苏伟欢 | 10% | 后端 | 符合预期 活跃 |
| 林小棠 | 10% | 后端 | 符合预期 |
| 张越洋 | 4% | 制作PPT、展示、写博客 | 没有按时完成博客和PPT 没有预先模拟PPT展示，导致展示时重心偏移 没有把控好开发进度 缺乏沟通 |
| 邓志雄 | 4% | 提问、评分、制作评审表 | 符合预期 |
| 王淇弘 | 3% | 测试 | 严重缺乏沟通 |
3.2. 现场答辩得分：49.5
| 小组 | 评分情况 |
|---|---|
| 1 | 46.8 |
| 2 | 52.8 |
| 3 | 46.6 |
| 4 | 51 |
| 5 | 49.8 |
| 6 | 54.6 |
| 7 | 54.6 |
| 8 | 45.2 |
| 9 | 50.4 |
| 10 | 48.6 |
| 11 | 49.2 |
| 12 | 43.2 |
3.3. 回答提问
| 小组 | 提问 | 回答 |
|---|---|---|
| 1 | 筛选里是否考虑加任务分类？ | 有的，将在beta版本上线 |
| 3 | 如何平衡赏金机制？ | 是指发布者给予的酬劳吗，根据市场价格发布者自由决定 |
| 4 | 怎么保证所发出的任务的时效性？ | 发起者可设置任务持续时间或到期时间，beta版本上线 |
| 5 | 市场上的任务悬赏是否具有默认排序？如何更好的让别人查找到想要的悬赏信息 | 默认按发布时间排序，后续加入信用高的人将优先展示；可使用筛选/搜索功能 |
| 6 | 如何确保支付的安全性？ | 通过完善流程后续跟进 |
| 7 | 能否保证支付的安全和线上支付？ | 线上支付步骤较为繁琐，若反响较好后续会加入 |
| 8 | 后端算法如何更新任务，例如通过什么算法对任务进行排序？ | 信用度优先，其次按照时间降序 |
| 9 | 可以通过支付的信用问题，设置每个用户的信用分吗 | 后续可以考虑 |
| 10 | 如果是不碰面的任务，如何解决支付问题？ | 线上支付，通过完成订单进行反馈 |
| 11 | 可以尝试用微信本身的支付接口 | 申请较为繁琐，反响较好后续将会继续跟进 |
| 12 | 状态设计是否完备？ | 目前有未接单，已接单，beta版本将跟进已完成状态 |
4. 全组讨论的照片（1分）
无
5. PSP与学习进度条（4分）
5.1. 个人PSP表
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 10 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 10 |
| Development | 开发 | 50 | 40 |
| · Analysis | · 需求分析 (包括学习新技术) | 50 | 40 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 0 | 0 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 40 | 50 |
| · Test Report | · 测试报告 | 0 | 5 |
| · Size Measurement | · 计算工作量 | 0 | 5 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 40 | 50 |
| 合计 | 120 | 110 |
5.2. 个人学习进度条（每周追加）
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 300 | 300 | 7 | 7 | 增强代码能力 |