1.基本情况：

组长博客链接：https://www.cnblogs.com/yaningscnblogs/p/14050343.html
答辩总结：答辩中，对于老师提出的意见，我们认为能够帮助我们更加完善我们小组的产品，我们将基于现有功能，做出相应的修改，使我们的产品功能更加完备。
全组讨论的照片
评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例（禁止一锅端平的情况，如果没有评估，全组平均后，组长得分减 50%）

成员	工作	贡献比例（%）
吴凝	管理前后端任务进度；新增物品具体页面，弹窗等功能以及轮播图等具体样式；编写order的models以及新增user的部分接口	35.5
吴奕含	修改评论样式，添加了隐藏项；修改了后端已完成部分的整合bug	22.5
梁瑾	实现了物品模块接口	13.5
陈燕琴	尝试编写了信息模块接口代码	4.5
林碧晴	修改了消息界面的样式	7
黄嘉颖	实现了用户信息修改接口	9
张文婕	攥写团队的博客，并且进行项目答辩	8

2.总结思考

2.1. 设想和目标（4分）

2.1.1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

答：我们的软件要解决当前大部分人想要快捷地向周边制定范围内的人群借用物品的需求。目前来看，我们的定义大部分是比较清楚地，边界比较明显。我们的用户面涉及比较广，但是对于典型用户和典型场景也有了比较清晰的描述。

2.1.2.我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)?

答：我们的目标大部分完成了，原计划的功能基本实现了，但是由于后端的知识比较匮乏，目前还在学习当中，前后端的对接还在进行当中，因此还不能按照原计划时间交付，需要延后一段时间。由于目前还没有将全部功能完善，小程序还没有进行面世，根据答辩时，老师提出的问题，我们也还需要继续改进，所以用户数量为零，还没有达到我们的目标数量。

2.1.3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

答：用户量目前还不能在我们的考量范围内，需要等我们的程序进行全部功能的进一步完善之后，才能开始进行用户量的计算。目前为止，我们小组成员对程序的试运行时，大部分功能和我们预想一致，我们的接受程度是比较可观的，但是具体面向用户是什么情况，还要等待程序面世之后，才能具体进行调查。我们认为，我们在逐步靠近目标了。

2.1.4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

答：从一开始就应该更加具体地明确小组成员的分工情况，并且在项目推行的过程中，应该边学习，边进行开发，提高效率。除此之外，也应该多借鉴网上的成功项目，作为模板来设计UI界面。

2.2. 计划（5分）

2.2.1. 是否有充足的时间来做计划?

答：是。

2.2.2.团队在计划阶段是如何解决同事们对于计划的不同意见的？

答：同事们在遇到意见相左时，可以互相理解，并进行再商讨，得到一个双方都满意的答案。

2.2.3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

答：没有都做完。因为一开始，安排了大部分时间进行相关知识的学习，导致最后的具体操作时间比较少，不能够完全进行具体功能的实现。

2.2.4.有没有发现你做了一些事后看来没必要或没多大价值的事?

答：有。一个人专门管理前后端所有进度。

2.2.5.是否每一项任务都有清楚定义和衡量的交付件?

答：否。

2.2.6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

答：项目进行过程中，团队成员在不同阶段都有期末考试，时间很紧张，导致原定计划没有顺利进行。没有估计到后端推展的难度，因为团队中成员都对后端不熟悉。前期对UI设计功能展示方面考虑涉及比较多，没有更多的关注具体界面风格方面的问题，导致后期老师提出我们的界面风格问题，现在还需要花时间继续改进。

2.2.7.在计划中有没有留下缓冲区，缓冲区有作用么?

答：没有。

2.2.8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

答：设置缓冲区，留出富裕时间。适当安排团队成员进行加班工作，尽量在DDL前将工作完成。

2.2.9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

答：学到了应该各司其职。如果再来一遍，我们会一开始就设置好各个板块的负责人，帮助进度更好地推展。

2.3. 资源（3分）

2.3.1.我们有足够的资源来完成各项任务么?

答：有。

2.3.2.各项任务所需的时间和其他资源是如何估计的，精度如何?

答：UI优化需要一周左右的时间，后端也需要一周左右的时间。

2.3.3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

答：测试的时间，人力方面比较匮乏，小组只有7个人。对于不需要编程的资源，并没有低估难度，因为她们的设计对接下来前后端的推展，也有很大的帮助。

2.3.4.你有没有感到你做的事情可以让别人来做（更有效率）?

答：后端的负责让别人来做比较有效率。

2.3.5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

答：我们应该更加合理高效地分配时间，利用好每一分每一秒。

2.4. 变更管理（4分）

2.4.1.每个相关的员工都及时知道了变更的消息?

答：是。

2.4.2.我们采用了什么办法决定“推迟”和“必须实现”的功能?

答：根据项目的基本功能，以及当前进度，及时地调整我们的功能实现。

2.4.3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

答：在测试端能够按照我们的预期实现。

2.4.4.对于可能的变更是否能制定应急计划?

答：能。

2.4.5.员工是否能够有效地处理意料之外的工作请求？

答：能。

2.4.6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

答：从一开始就应该尽可能周全地制定我们的计划，尽量避免在进行过程当中做变更，也应该做后备方案，以防万一。

2.5. 设计/实现（4分）

2.5.1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

答：设计工作在Alpha冲刺之前完成，由吴凝和梁瑾完成。是合适的时间，合适的人。

2.5.2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？

答：目前为止，还没碰到过此类情况。

2.5.3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

答：否，只用了AxureRP9实现。有效。

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

答：没有区别，不需要更新。

2.5.5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

答：有后端涉及的功能Bug比较多，因为我们团队成员在后端方面的知识都是从零开始的。目前还没发布。

2.5.6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

答：我们项目还没有进行到该阶段。

2.5.7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

答：学到了AxureRP9更多的交互用法。如果能重来，我们会更早进行设计工作的开展。

2.6. 测试/发布（3分）

2.6.1.团队是否有一个测试计划？为什么没有？

答：团队还在具体实现阶段，目前还没有进展到测试阶段，测试计划还在设计当中。

2.6.2.是否进行了正式的验收测试？

答：还没。

2.6.3.团队是否有测试工具来帮助测试？

答：没有。

2.6.4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

答:尽可能在测试功能是发现更多问题，带着问题进行测试。由于还没有进行实际运行，这些测试工作还没展开。改进还需要在之后正式测试中发现。

2.6.5.在发布的过程中发现了哪些意外问题？

答：还没发布。

2.6.6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

答：该部分相关知识还没有学到。

2.7. 团队的角色，管理，合作（3分）

2.7.1.团队的每个角色是如何确定的，是不是人尽其才？

答：团队里的角色是团队成员各自根据自己喜好认领的，算是人尽其才。

2.7.2.团队成员之间有互相帮助么？