此作业要求参见：https://edu.cnblogs.com/campus/nenu/2018fall/homework/2324
组名：可以低头，但没必要
组长：付佳
组员：张俊余 李文涛 孙赛佳 田良 于洋 刘欣 段晓睿
可以低头，但没必要小组“取件帮”项目Postmortem结果
整理：付佳
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：取件帮主要解决东北师范大学净月校区部分师生没时间取快递、不想取快递而另一部分同学并不排斥取快递这种两极分化问题，力求在这二者之间达到一个动态平衡。
该项目主要有两个功能，功能一为发布快递信息（不想取快递的人）；功能二为帮忙取快递（有时间取快递的人）。
对典型用户和典型场景的详细描述参见：查看入口 要求4立会内容部分。
2.是否有充足的时间来做计划?
答：有时间，我们小组在选题阶段确定选题之后就花费了大量的时间来定义典型用户、典型场景、需求分析、设计E-R图、设计原型等。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：一般是通过每日立会讨论，当日会议master会在开会之前提出本次会议将讨论的问题，每位组员提前整理自己的想法，会上讨论。有不同意见时，组长综合各位组员意见组织大家进行投票，大家都比较善于沟通，好的意见多数情况下会得到大部分组员的支持。
4.用户量、用户对重要功能的接受程度和我们事先的设想一直吗？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：本项目Alpha阶段共有八名用户，预计为小组开发人员，由于教师规定测试开发人员不算做用户，因此重新授权八位用户。用户量没有变化。用户在帮取的时候更加注重送达时间和送达地点这一点是我们做设计的时候没有想到的。
我们离目标确实更近了，目前该项目已实现帮取与发布功能。后续将持续优化。
经验教训是团队开发的时候最好不要使用一种崭新的语言，如果真的决定使用，那么一定要花大量的时间进行学习。本项目实现形式是微信小程序，语言类似web前端，数据库使用知晓云。unlucky，小组八位成员没有一位之前接触过前端，大家完全处在一个边摸索边学习的状态。
如果重来一遍，我们依旧会选择做微信小程序。但是会减少原型设计的时间，本次开发原型共设计两次，墨刀和PS页面各一次，浪费了很多时间，耽误了后续学习小程序开发的时间。原因在于第一次设计的原型页面不美观，遭到了组员的反对，经验是分工要合理，原型设计分配给更加熟悉设计的人员。
计划
1.你原计划的工作是否最后都做完了?如果有没做完的，为什么?
答：原计划的工作全部完成，且超额完成了Beta阶段部分工作。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
答：没有，所有的事情在后续工作中经过检验都是值得的。
3.是否每一项任务都有清楚定义和衡量的交付件?
答：是。教师规定的任务颗粒度，我们组在leangoo看板上具体制定了各项任务的负责人、截止时间、任务描述。此外组长会对每一个有不一意见的任务进行解释，因此每一项任务都有清楚定义和衡量的交付件。
4.是否项目的整个过程都按照计划进行?
答：基本上。因为小组每天都会召开立会总结昨日工作，如果该项工作完成会继续制订今日计划；如果未完成，小组成员集体讨论未完成原因，确认是否该项任务有一定难度，会重新制订执行计划和执行方式。故，该项目在Alpha阶段大方向始终按照计划执行。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
答：一般会设置缓冲区。例如一般会给任务设置一个较早的deadline，以方便组长检查修改。缓冲区为整个项目的按计划完成增加了保障。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：每个阶段初始分析任务、安排任务比较琐碎，需要组长更加了解本组人员；功能测试时间要安排的长一点；单元测试要更加全面。
7.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：学会了按照颗粒度分析任务，划分任务。如果重来一遍，应该将任务划分的更加细致。
资源
1.我们有足够的资源来完成各项任务么?
答：多数情况下是有的。腾讯提供开发教程，版本控制参考廖雪峰博客，数据库使用知晓云。最大的资源限制是时间，由于不熟悉小程序开发，因此有时候开发时间不够。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：大部分任务截止时间是组长根据之前开发经验制订。例如一个静态页面的时间，一个查询功能的时间，多数情况下按照功能来制订。其他资源只是比较粗糙的制定一个deadline，具体看执行人自由发挥，没有考虑精度问题。
3.用户测试的时间，人力和软件/硬件资源是否足够?
答：不富裕但足够。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
答：没有。我们组成员之间随着不断地熟悉在制订任务分配时有非常细致的分工，完全依据个人精力和能力来分配任务。
5.有什么经验教训？如果历史重来一遍，我们会做什么改进？
答：经验是在充分了解现阶段任务的基础上基于对本组成员的了解分配任务，这一点我们做的越来越好。教训是任务分配要尽早，给开发留出比较充足的时间。如果重来一遍，我们会在Alpha阶段开始的前半天就制定出任务分配。
变更管理
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最多，为什么？
答：发布信息功能模块bug最多。因为开发人员在添加信息函数上有一个冲突没有解决，而双方一直没有发现。
5.代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：项目开始大家按照口头约定的代码规范进行执行，后来程序越来越复杂就开始按照自己的编程风格写代码了。至于代码复审，由于开发迭代周期短，所以并没有进行。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：我们学会了团队开发时的版本控制。如果重来一遍，我们将会制订书面版的代码规范并严格执行，且每次更新代码都要检查冲突并解决。
测试/发布
1.团队是否有一个测试计划？为什么没有？
答：有测试计划，但是测试周期制订的比较短，而且大家已经过于熟悉本项目了所以反馈不多。
2.是否进行了正式的验收测试？
答：没有。时间比较紧张因此未进行。
3.团队是否有测试工具来帮助测试？
答：没有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：在手机端可以进行效能测试。从实际看这些测试有用，方便后续的debug和测试。目前对效能测试不多，改进是后续将加大对效能测试分析的力度。
5.在发布的过程中发现了哪些意外问题？
答：发布的时候因为小程序审核需要一定的时间，所以只能对用户进行单独的授权才可以使用，但是不影响我们预计的八位用户这个数据量。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
答：经验是要有一个详细的测试计划，此次开发测试周期短，最后导致几个遗留问题解决时间较长。如果重来一次，我们会制订一个比较好的测试计划，进行单元测试、功能测试、效能分析等。