Alpha事后诸葛亮

一、组长博客：地址

二、Postmortem模板

设想和目标

1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们要解决的问题是让大学生可以通过福鱼网站将暂时无用的商品，如看过的教科书、购买后没怎么穿过的衣服、离校后无法带走的电动车等，将它们卖给有需求的人，使这些物品的价值得到充分的利用，让买家卖家都得到好处。
典型用户场景：福大大四毕业生小林即将去外省工作，但是无法将电动车带走，于是使用福鱼网站上架自己的电动车，而大一新生小张刚好需要，于是两人通过福鱼协商，并交易成功。

2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
达到了一部分的目标并按照计划时间交付，尚未上市，暂时没有用户。

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

4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：错误估计自身的空余时间及学习能力，促使成果不尽如人意。
如果历史重来一遍，我们将会将目标定的低一些。

计划

1.我们是否有充足的时间来做计划？
由于都没有什么经验，对于计划一开始显得有点手足无措，所以花很多了时间来做计划。

2.团队在计划阶段怎么解决同事们对于计划的不同意见？
在这个阶段中，我们进行了讨论，提出自己的看法，有的人提出应该实现什么功能，在这个过程中是否会出现什么问题等等，对于不同的意见，使用少数服从多数的方式来解决分歧。

3.你原计划的工作是否最后都做完了？如果没有为什么？
没有完成，网页功能未实现，因为没有接触过，一开始学也不知道知道是学什么，所以没有完成。

4.有没有发现你做了一些事后看起来没必要活没有多大的事？
有啊，因为第一次学，不知道首先学什么，往往学了一个中途又要去学另一个。

5.是否每一项任务都有清楚的定义和交付件？
部分有，因为成员没有开发经验，所以比较混乱吧。

6.是否项目的整个过程都按计划进行，项目出了什么意外？有没有什么风险当时没有估计到？
大家都没有经验，需要学习html,css等新的知识，有的花费了较多时间。事先没有这样的经验，大家开始都忙无头绪，从最容易的入手，有些情况没有事先考虑只能进行百度或者询问大佬。事先没有考虑分开做的原因，遇见的问题也各种各样，在运行时出现bug，没有考虑系统兼容性，修改了很多次。因为大家都没有开发经验，在进行编写时也遇见新问题，再一次进行百度和询问大佬。

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

8.将来的计划会做什么修改？
留下缓冲区，加班熬夜完成应该的任务。

9.我们学到了什么？如果重来一遍，我们会做什么改进？
相信这次经历给我们的成员带来了挺多东西，过程虽然真的很艰难，如果还有下一次，我们应当在讨论时更加深入一点，这样成果可以更好

资源

1、我们有足够的资源来完成各项任务么?
时间资源:课程安排，作业安排，考试安排太多，没有足够的时间资源；人力资源:足够，但没有大佬；软件/硬件资源:通过自身努力和借鉴别人优秀的模板，以及全体成员出资，基本足够。

2、各项任务所需的时间和其他资源是如何估计的，精度如何?
时间依据分配人力以及完成时限动态安排，其余资源根据成员个人专业度和熟练度安排分配。

3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
​软硬件，人力基本足够，时间资源略有不足。关于美工设计与文案确实有所低估，所需资源分配不够充足。

4、你有没有感到你做的事情可以让别人来做（更有效率）?
前端安排的人不少，可以安排更多的后端人员。

5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验就是看视频教程得开倍速，要边实践，多记笔记多百度。如果历史重来，我们会在具体安排上更精确，设计更精确的各项目完成时间及要求以便作维护修改。

变更管理

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

• 2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
  我们采用了可视性，关键性为重的评判标准，即决定了实现过程更清晰，作用更关键的功能作为“必须实现”的功能（比如前端的页面设计），其次尽量选择简单易上手的功能，而其他暂时难以实现的功能则作为“推迟”的功能。

• 3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  我们对出口条件的定义是：项目经过多次测试与完善，运行过程中没有明显的bug，能够保证users用户正常使用。

• 4.对于可能的变更是否能制定应急计划?
  暂时没有制定应急计划，对于（未来）可能出现的变更，我们会对相关成员进行积极的沟通。

• 5.员工是否能够有效地处理意料之外的工作请求？
  鉴于我们组会议时分工明确，且基本没有负担太多的工作，意料之外的工作请求比较少，因此对于突发情况还是能够接受的。

• 6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  我们学到了：实现功能时应从简单的功能入手，循序渐进；对成员分工时，应该有大致的方向和目标，根据每个成员擅长的方向分配适当的任务；有意外变更时，应当积极与相关成员沟通，努力解决。
  改进：组内成员需要更多的沟通，需要更多的提速，以便更早完成任务，及时对接。

设计/实现

1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在上周，由组长林涛完成，是合适的时间和合适的人。

2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在设计过程中，对于如何安排功能板块、如何实现网站功能等，由于大家都是新手，不知道要如何去完成。通过参考别的网站的模块设计和功能，学习各种教程，最后做出自己的网站设计。

3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
使用了ProcessOn的uml工具，它很好的帮助将需求和系统的体系架构转化成代码和可视化。

4、比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有什么区别，无更新。

5、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
首页的商品秒杀倒计时，由于要自动计时，过时间之后会继续计数，尚未完成下一步的操作。在开发时由于并未做过类似的倒计时商品，对于如何设置倒计时没有概念，所以把握不好。

6、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
采用结对编程的方法，由另一位同学去审查代码寻找问题，严格执行了代码规范。

7、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学习到了如何将构想实现出来，包括网页模块设计、功能实现，以及如何运用uml工具等辅助。如果重来一遍，会在前期考虑的更加细致一点，比如所需要的功能、商品的分类等，提高网页的可操作性。

测试/发布

• 团队是否有一个测试计划？是否进行了正式的验收测试？
  有测试计划。未进行正式验收测试。

• 团队是否有测试工具来帮助测试？
  因为是Web开发，所以前端可以直接使用Chrome的开发者工具或者FireFox的开发者工具、FireBug插件进行调试。性能测试工具有LoadRunner、JMeter等。后端数据库测试工具有sql server profiler等。

• 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
  查看各个函数耗时、内存占用、CPU占用率等，找出性能瓶颈；以及在实际访问页面时页面排版、页面跳转是否出现Bug。在数据库测试中，测试查找最占用时间、最占用系统资源的查询语句，检测是否存在死锁等。测试过程中找到的大部分问题已经进行改善优化。

• 在发布的过程中发现了哪些意外问题？
  产品暂时还没有发布，先进行本地的测试。以后发布计划租用云服务器，搭建Web服务器，能够进行线上访问。

• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
  学到了HTML、JS、CSS等Web前端开发的必备知识；数据库的设计和实现，数据库软件的使用；以及前后端的交互过程，网页的运作过程，对整个Web开发的流程有了更加深入的了解。如果历史重来一遍，会更加合理安排时间，安排计划，加强队员之间的交流。

团队的角色，管理，合作

1.团队的每个角色是如何确定的？是不是人尽其才？
因为团队主要成员大多数都为无经验的新手，我们角色的确定是先按经验分，再按兴趣分，是不是人尽其才我们不敢确定，但是我们团队尽量做到不强迫组员
原则，以致于影响团队积极性。

2.团队成员之间有互相帮助么？
这是肯定有的，总有学得快的或是之前有小部分经验的人存在，互相询问和互相讨论也是我们团队学习技术的方式之一。

3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
出现这一类问题时，我们会先线上讨论，如若无果，会召开线下会议，按照多数人的意愿来解决问题，就算在客观角度里是效率更低的方法，我们比起效率会
先注重团队协调性。

4、个人感谢部分。
每个成员明确公开地表示对成员帮助的感谢 ：
我感谢王德钊同学对我的帮助， 因为在我忙于校选课论文时，他帮我整合评分表。

5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果重来一遍，我会一开始就确定分工，分前端、后端两个小组，各再分配一负责人；找时间让大家出来一起写代码、赶项目。

总结：

1.你觉得团队目前的状态属于CMM/CMMI中的哪个阶段？
我认为我们的团队处于第二个阶段，即管理级，我们只是遵守了当时项目成立时的计划，按计划分工，没有系统的管理措施，大多数问题靠投票解决。

2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段？
我认为我们团队目前处于磨合阶段，毕竟当时组队时临时拼凑的，大家不能说上人尽其才，因为都不了解，但是分工没有什么异议，所以我认为处于磨合阶段。

3.你觉得团队在这个里程碑相比前一个里程碑有什么改进？
更加团结了。

4.你觉得目前最需要改进的一个方面是什么？
我认为是管理方面的，因为我们不能说是一个系统规范的团队。大家只是组队，重要部分拿捏靠组长和投票，不算一个规范的管理方法。

按照敏捷开发原则，我们小组做的最好的应该是激励项目人员，大家都是从零开始，对于犯错误的包容度较大，事例说不上具体，因为大家在代码错误出BUG的时候都是互相检查鼓励的。

三、答辩总结

1.贡献比例

组员	分工	贡献比例
林涛（组长）	规划项目进程、找资源、页面制作、分配任务、审查文档、写博客	20%
童圣滔	页面制作、部分文档编写	9%
林红莲	页面制作、ppt制作	15%
潘雨佳	页面制作、ppt制作	10%
于瀚翔	数据库构建、演讲、展示	9%
袁正闻	数据库构建、部分文档编写	4%
吕瑞峰	页面制作、部分文档编写	8%
蒋梦迪	部分文档编写、美术素材收集	4%
王德钊	部分文档编写	4%
吴友昆	页面制作、部分文档编写	8%
覃鸿浩	美术素材收集、设计评审表、评分	9%

2.现场答辩得分

• 平均得分：89.5
• 总分（乘以60%）：53.7

3.提问回答

• Q：功能如何实现？
  A：买云服务器，搭建web服务器，实现数据库与前端相接。

• Q：如何推广？
  A：线上空间转载。

• Q：如何盈利？
  A：广告。

4.PSP与学习进度条

个人PSP

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	20
Estimate	估计这个任务需要多少时间	20	10
Development	开发	30	30
Analysis	需求分析 (包括学习新技术)	30	20
Design Spec	生成设计文档	10	10
Design Review	设计复审	10	10
Coding Standard	代码规范 (为目前的开发制定合适的规范)	20	20
Design	具体设计	30	30
Coding	具体编码	80	60
Code Review	代码复审	30	30
Test	测试（自我测试，修改代码，提交修改）	30	30
Reporting	报告	10	10
Test Repor	测试报告	20	20
Size Measurement	计算工作量	10	10
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	20	20
	合计	370	330

个人学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	0	0	14	14	学习了Axure Rp9
2	400	400	20	34	学习了HTML、CSS
3	1000	1400	30	64	学习了Javascript
4	200	1600	10	74	继续学习web前端
5	400	2000	4	78	远程操控数据库
6	100	2100	2	80	学习JS
7	200	2300	0	80	无