此作业要求参见：https://edu.cnblogs.com/campus/nenu/2018fall/homework/2449
组名：可以低头，但没必要
组长：付佳
组员：张俊余 李文涛 孙赛佳 田良 于洋 刘欣 段晓睿
可以低头，但没必要小组“取件帮”项目Postmortem结果
整理：张俊余
设想和目标
1.在Beta阶段的软件质量提高了吗？是在哪里体现出来的？
答：取件帮在beta阶段的质量取得了显著的提高，具体表现在以下几个方面：（1）软件在原有的基础上在发布快递信息模块上完善了功能，具体表现在对输入是否为空进行判断，若关键信息填写为空，则会提示重新输入完整信息；（2）在“帮取”按钮上做了优化，具体表现在如果帮取自己的快递则会显示“不能帮取自己的快递”提示并拒绝帮取请求，帮取别人快递的时候弹出提示，让帮取者再次确认信息后方可帮取，增加了安全性；（3）加入了个人中心功能，个人中心里可以看到帮取或者发布的快递信息，可以提交用户使用反馈，查看关于我们信息；
2.在Beta阶段软件工程的质量提高了吗？具体表现在那些方面？
答：Beta阶段软件工程的质量也得到了提高。主要表现在一下几个方面：（1）提交代码时commit信息规范化，要求使用标准英文，词义和语法让人能正常阅读；（2）代码编写更加规范，根据制定的代码规范严格遵守；
3.用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：本项目Beta阶段共有15名用户，和预想一致。用户在使用小程序的时候开始关注页面设计和页面展示效果是我们之前没想到的；
我们离目标确实更近了，项目完成度已达90%，只剩收货地址管理这一项功能待开发；
经验教训是团队开发的时候版本控制一定要做的细致，提交记录和提交信息一定要完整，否则在回归测试上会出现不协调的问题；
如果重来一遍，我们依旧会选择做微信小程序。但是会减少原型设计的时间，本次开发原型共设计两次，墨刀和PS页面各一次，浪费了很多时间，耽误了后续学习小程序开发的时间。原因在于第一次设计的原型页面不美观，遭到了组员的反对，经验是分工要合理，原型设计分配给更加熟悉设计的人员。
计划
1.你原计划的工作是否最后都做完了?如果有没做完的，为什么?
答：原计划的工作全部完成，项目整体完成度已达90%，并且用户有比预期增速更快的趋势；
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
答：没有，所有的事情在后续工作中经过检验都是值得的。
3.是否每一项任务都有清楚定义和衡量的交付件?
答：是。教师规定的任务颗粒度，我们组在leangoo看板上具体制定了各项任务的负责人、截止时间、任务描述。此外组长会对每一个有不一意见的任务进行解释，因此每一项任务都有清楚定义和衡量的交付件。
4.是否项目的整个过程都按照计划进行?
答：基本上。因为小组每天都会召开立会总结昨日工作，如果该项工作完成会继续制订今日计划；如果未完成，小组成员集体讨论未完成原因，确认是否该项任务有一定难度，会重新制订执行计划和执行方式。故，该项目在Beta阶段大方向始终按照计划执行。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
答：一般会设置缓冲区。例如一般会给任务设置一个较早的deadline，以方便组长检查修改。缓冲区为整个项目的按计划完成增加了保障。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：每个阶段初始分析任务、安排任务比较琐碎，需要组长更加了解本组人员；功能测试时间要安排的长一点；单元测试要更加全面；回归测试要更加细致；
7.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：学会了按照颗粒度分析任务，划分任务。如果重来一遍，应该将任务划分的更加细致。
资源
1.我们有足够的资源来完成各项任务么?
答：多数情况下是有的。腾讯提供开发教程，版本控制参考廖雪峰博客，数据库使用知晓云。最大的资源限制是时间，由于不熟悉小程序开发，因此有时候开发时间不够。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：大部分任务截止时间是组长根据之前开发经验制订。例如一个静态页面的时间，一个查询功能的时间，多数情况下按照功能来制订。其他资源只是比较粗糙的制定一个deadline，具体看执行人自由发挥，没有考虑精度问题。
3.用户测试的时间，人力和软件/硬件资源是否足够?
答：不富裕但足够。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
答：没有。我们组成员之间随着不断地熟悉在制订任务分配时有非常细致的分工，完全依据个人精力和能力来分配任务。
5.有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：经验是在充分了解现阶段任务的基础上基于对本组成员的了解分配任务，这一点我们做的越来越好。教训是任务分配要尽早，给开发留出比较充足的时间。如果重来一遍，我们会在Beta阶段开始的前半天就制定出任务分配。
变更管理
1.每个相关的员工都及时知道了变更的消息?
答：是的。每次立会的时候每个人都会汇报一下自己的进度。每位同学在checkin之后会在微信群里通知大家。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：根据需求分析时制订的要求，核心功能（帮取与发布信息）必须实现。具体到问题细节，实现方法A较为困难则寻找实现方法B，若均困难且距离deadline有一定时间则务必实现，不可推迟。否则推迟。比如数据库存快递状态不可以存文本必须存状态代码，原则是必须的，实现方法不限。
3.项目的出口条件（ExitCriteria）有清晰的定义吗?
答：出口条件理解为“做好了”，能实现核心功能，且实现核心功能的方法符合逻辑，用户体验较好。
4.对于可能的变更是否能制定应急计划?
答：能。按照紧急程度有不用应对措施比如立会讨论，微信群讨论，电话联系等。
5.员工是否能够有效地处理意料之外的工作请求？
答：是的。大家相处的很融洽，一般额外工作也只会分配给当前有能力有时间的人来完成，所以都会欣然接受。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：学会了精益求精和与人沟通。在实现的基础上反复修改是为了精益求精，修改之后及时告知伙伴以便对方及时更新代码，也是对项目的一种负责。如果重来一遍，我们还会按照现在的形式进行，改进应该会是在checkin时对操作描述的更加清晰。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：本项目先由代码组前端成员设计出简单的页面，然后进行功能实现。功能实现后前端成员再进行检查与美化完成详细UI。是合适的时间，合适的人选。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有，但不多。功能性和美观性抉择时，选择功能性。功能实现后再根据时间和能力进行美观性的改进。
3.团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
答：没有运用单元测试（unit test），测试驱动的开发（TDD）、UML工具。运用了 leangoo看板、燃尽图、todolist、版本控制来帮助设计和实现。测试时选择开发IDE预览和手机端测试，感觉都挺有效的。
4.什么功能产生的Bug最多，为什么？
答：个人中心按钮出现不兼容的情况，在某些手机上出现了串行等现象；
5.代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：项目开始大家按照口头约定的代码规范进行执行，后来程序越来越复杂就开始按照自己的编程风格写代码了。至于代码复审，由于开发迭代周期短，所以并没有进行。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们学会了团队开发时的版本控制。如果重来一遍，我们将会制订书面版的代码规范并严格执行，且每次更新代码都要检查冲突并解决。
测试/发布
1.团队是否有一个测试计划？为什么没有？
答：有测试计划，但是测试周期制订的比较短，而且大家已经过于熟悉本项目了所以反馈不多。
2.是否进行了正式的验收测试？
答：没有。时间比较紧张因此未进行。
3.团队是否有测试工具来帮助测试？
答：没有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：在手机端可以进行效能测试。从实际看这些测试有用，方便后续的debug和测试。目前对效能测试不多，改进是后续将加大对效能测试分析的力度。
5.在发布的过程中发现了哪些意外问题？
答：发布的时候因为小程序审核需要一定的时间，所以只能对用户进行单独的授权才可以使用，但是现在经过前期铺垫之后审核速度有一定加快。不过还是应该在审核这一部分留取更多的时间从而方便接入新用户；
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：经验是要有一个详细的测试计划，此次开发测试周期短，最后导致几个遗留问题解决时间较长。如果重来一次，我们会制订一个比较好的测试计划，进行单元测试、功能测试、效能分析等。