一、组长博客：
https://www.cnblogs.com/mhq-mhq/p/11923194.html
二、Postmortem模板
设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
设计一款简洁实用、功能齐全、为福大学子们量身定做的基于移动设备的线上任务交易平台APP——“福大帮帮”。在平台上，福大校园里的同学可以发布任务及酬劳，能提供帮助的同学可以领取任务给与帮助，这不仅帮助任务发布者以高效方便地寻求帮助并解决问题，也让任务领取者在帮助了他人的同时也获取相应酬劳，两全其美；同时在平台上，同学间也可进行二手物件交易，尤其是二手书交易。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
达到了一部分的目标并按照计划时间交付，但还未达到原计划的用户数量。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
软件还未开放公测，小范围内测中。用户对重要功能的接受程度和我们事先的预想基本一致，离目标越来越近了。
4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：想做的东西太多，但时间和准备上的不充足，让我们不得不放弃许多功能。如果历史重来一遍，我们会重新分析需求，细化任务分配，挑选最重要的功能来做。
计划
1、我们是否有充足的时间来做计划？
有充足的时间来做计划，在组完队后我们就找时间讨论要做的产品。
2、团队在计划阶段怎么解决同事们对于计划的不同意见？
在这个阶段中，我们进行了讨论，提出自己的看法，有的人提出应该实现什么功能，在这个过程中是否会出现什么问题等等，对于不同的意见，使用少数服从多数的方式来解决分歧。
3、你原计划的工作是否最后都做完了？如果没有为什么？
原计划的工作大部分都完成了，包括完成登录注册模块、 二手商品的发布等。剩余的部分比如任务发布还没有做完，主要是因为临近期末，大家都有一些考试，时间上不太好协调。
4、有没有发现你做了一些事后看起来没必要活没有多大的事？
肯定是有的，在刚开始做的时候，并没有很明确的思路，做了不少无用功。
5、是否每一项任务都有清楚的定义和交付件？
是，每一次Alpha冲刺的代码都有上传到Github。
6、是否项目的整个过程都按计划进行，项目出了什么意外？有没有什么风险当时没有估计到？
并没有完全按照计划进行，比如前端和后端之间的接口还没有完全确定下来，整个项目在相互联系方面并没有一个明确的规范，不同人完成的任务会有一定程度上的差异，需要统一，这个情况归结到底还是计划不够细致和沟通问题。风险的话是安全性方面做得不够，软件安全系数低，后期时间足够的话会考虑服务器安全部分加强安全性的途径，以及数据库部分没有用户认证。
7、在计划中有没有留下缓冲区，有什么作用？
有的，缓冲区的作用就是可以帮助我们更好地发现问题和更高效地解决问题，进行交流弥补沟通不足和不明确各部分任务完成情况的缺陷。
8、将来的计划会做什么修改？
基本上没有什么修改，只需要花时间把整个软件的功能做完。
9、我们学到了什么？如果重来一遍，我们会做什么改进？
完善计划和定制计划同样重要。原计划的实施情况已经符合我们的预期，但是在过程中总会有一些意想不到的突发情况，因此及时的微调计划对于整个项目的实行起到了很重要的作用。如果能重来一次，我希望在制定计划时能够留下更多的缓冲时间。
资源
1、我们有足够的资源来完成各项任务么?
相对来说有足够的资源来完成各项任务 ，我们组有很多大佬！
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
根据任务需要学习的内容难易程度还有开发难度，给与适当的时间；根据实现功能实现需要什么来确定资源，精度一般 。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
软硬件，人力基本足够，时间资源略有不足。关于美工设计与文案确实有所低估，所需资源分配不够充足。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
没有。组长在分配任务的时候就考虑了每个人的能力。
5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训还是时间估计的有点错误，和考试冲突的太频繁了，如果再来一次的话，我们一定会更加合理的安排好时间，。
变更管理
1、每个相关的员工都及时知道了变更的消息?
是的。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据实际情况决定。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，基本完成核心功能，无明显bug，根据实际使用情况和用户反馈来定义。
4、对于可能的变更是否能制定应急计划?
暂时没有制定应急计划，对于（未来）可能出现的变更，我们会对相关成员进行积极的沟通。
5、员工是否能够有效地处理意料之外的工作请求？
鉴于我们组会议时分工明确，且基本没有负担太多的工作，意料之外的工作请求比较少，因此对于突发情况还是能够接受的。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
对于业务逻辑和产品细节要求应该一开始尽可能的确定，且充分考虑其可行性，预估可能遇到的困难，才能减小变更发生的可能性 。
设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在选题报告的时候就开始了 ，由组长梅恒权完成，是合适的时间和合适的人。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计过程中的确有一两个地方模棱两可，是由具体设计的成员提出，然后先在UI设计师内部交流出一个方案，再来询问其他开发人员意见。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
使用了unit test的TDD工具，它很好的帮助将需求和系统的体系架构转化成代码和可视化。
4、比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
主体部分与项目开始的UML文档一脉相承，一些小边幅的修改需要更新UML文档。
5、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
搜索二手商品时产生的Bug最多，有时候会搜索不出来。 发布后尚未发现什么重大的bug 。
6、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
采用结对编程的方法，由另一位同学去审查代码寻找问题，严格执行了代码规范。
7、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
掌握了不断学习新技能的能力和各方面的基础知识。 如果再来一次，会花更多的时间在讨论需求上，同时做好代码规范。
测试/发布
1、团队是否有一个测试计划？是否进行了正式的验收测试？
有测试计划。未进行正式验收测试。
2、团队是否有测试工具来帮助测试？
直接在手机上安装我们的软件进行使用来测试。
3、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
查看各个函数耗时、内存占用、CPU占用率等，找出性能瓶颈；以及在实际访问页面时页面排版、页面跳转是否出现Bug。在数据库测试中，测试查找最占用时间、最占用系统资源的查询语句，检测是否存在死锁等。测试过程中找到的大部分问题已经进行改善优化。
4、在发布的过程中发现了哪些意外问题？
产品暂时还没有发布，先进行本地的测试。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了HTML、JS、CSS等Web前端开发的必备知识；数据库的设计和实现，数据库软件的使用；以及前后端的交互过程，网页的运作过程，对整个Web开发的流程有了更加深入的了解。如果历史重来一遍，会更加合理安排时间，安排计划，加强队员之间的交流。
团队的角色，管理，合作
1、团队的每个角色是如何确定的？是不是人尽其才？
是根据大家学习意愿，自己选择前端或者后端学习。还算是人尽其才，大家都尽力做好自己的部分工作。
2、团队成员之间有互相帮助么？
这是肯定有的，总有学得快的或是之前有小部分经验的人存在，互相询问和互相讨论也是我们团队学习技术的方式之一。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
不论什么类型的问题，我们团队的解决方法第一步都是团队讨论，然后进行集思广益解决问题。
4、个人感谢部分。
感谢小组的每一个人！大家在一起努力冲刺，做好自己的任务，没有人想要划水。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们在团队合作方面，能够及时沟通解决，没有出现大的问题，在这一方面我们是比较优秀的。
总结：
1、你觉得团队目前的状态属于CMM/CMMI中的哪个阶段？
我觉得团队目前的状态属于CMM/CMMI中的可重复级。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段？
我认为我们团队目前处于规范阶段。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进？
在团队的分工以及协作能力上大大提升。
4、你觉得目前最需要改进的一个方面是什么？
目前项目的功能比较少，因此我认为丰富功能才是应该改进的。
全组讨论的照片
三、答辩总结
1、贡献比例
| 队员姓名 | 分工 | 贡献比 |
|---|---|---|
| 梅恒权 | 团队项目管理员 （队长） | 10% |
| 王瑞卿 | 产品经理 | 9% |
| 杨欢 | 前端工程师 | 11% |
| 汪倍民 | 前端工程师 | 11% |
| 关文涛 | 后端工程师 | 11% |
| 黄益颂 | 后端工程师 | 10% |
| 陈梦雪 | 美工 | 10% |
| 朱庆章 | 美工 | 10% |
| 黄宇航 | 数据测试 | 9% |
| 胡康 | 数据测试 | 9% |
2、现场答辩得分
- 平均得分：91.5
- 总分（乘以60%）：54.9
3、提问回答
很遗憾没有其他小组对我们进行提问：）
4、PSP与学习进度条
个人PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时 （分钟） | 实际耗时 （分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| · Estimate | · 估计这个任务 需要多少时间 | 20 | 20 |
| Development | 开发 | 130 | 310 |
| · Analysis | · 需求分析 (包括学习新技术) | 50 | 180 |
| · Design Spec | · 生成设计文档 | 20 | 30 |
| · Design Review | · 设计复审 | 20 | 30 |
| · Coding Standard | · 代码规范 (为目前的开发 制定合适的规范) | 10 | 20 |
| · Design | · 具体设计 | 15 | 30 |
| · Coding | · 具体编码 | 15 | 20 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试， 修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 10 | 20 |
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 0 | 0 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 20 |
| 合计 | 160 | 350 |
个人学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 10 | 10 | 学会markdown写博客 |
| 2 | 500 | 500 | 26 | 36 | 学会json格式使用 使用request库调用API |
| 3 | 0 | 0 | 21 | 57 | 使用Axure进行原型设计 设计十三水原型 |
| 4 | 600 | 1100 | 16 | 73 | 进行UI设计 设计十三水UI |
| 5 | 0 | 1100 | 10 | 88 | 学会软件的选题分析 |
| 6 | 0 | 1100 | 13 | 101 | 学会软件的需求分析 |
| 7 | 1200 | 2300 | 12 | 113 | 学会对爬取数据进行 处理并分析利用 |
| 8 | 0 | 2300 | 10 | 123 | 学习MySQL |
| 9 | 100 | 2400 | 10 | 133 | 学习django |
| 10 | 1000 | 3400 | 20 | 153 | Alpha冲刺 |