1、基本情况
答辩总结：
·产品偏离了最开始的方向，地图和刷一刷功能做得没那么好，外卖订单功能虽然做得完整，但却偏离了一开始的想法。组员答辩结
束之后，开了会，做了认真的反省，决心在beta冲刺中将我们的项目开发重心重新放回地图和刷一刷功能，争取在beta答辩中拿出
令大家满意的产品。
讨论照片：
工作流程：
·Alpha阶段的开发工作分为地图页面部分、刷一刷页面部分、外卖订单功能页面部分，分配给不同人手，开始进行开发。
分工以及贡献比例
| 组员 |
组员分工 |
工作量比例 |
| 黄纯朴 |
分工协调、团队督促、博客撰写 |
11% |
| 魏祖文 |
前端设计、视频剪辑 |
11% |
| 蔡震泽 |
前端设计、ppt制作以及答辩 |
11% |
| 谈世宏 |
后端设计、部分前端设计 |
15% |
| 苏炜斌 |
后端设计、部分前端设计 |
15% |
| 谢鑫杰 |
数据库设计、推荐算法负责 |
11% |
| 李赫 |
数据库设计、推荐算法 |
9% |
| 熊崟 |
推荐算法 |
9% |
| 平措旺堆 |
工具人、文档制作、前端设计 |
8% |
测试组提问部分
1、食堂该如何实现预约小桌or大桌？是让商家帮忙占座吗
该功能有欠考虑，发现其实现的难度大，听取柯老板建议后，决定删去该功能。
2、商家账号是后台手动分配还是商家自己注册？
目前是后台手动分配。
3、首页扫一扫的功能是怎样的？
扫一扫功能的设想原本是可以直接扫店家的二维码可以得到该家店的基本信息以及周围人对该店的评价，达到避雷的效果，但在柯老板建议下，决定删去改功能。
2、总结
2.2.1. 设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决在校学生到食堂吃饭不知道吃什么的问题。
定义得很清楚。
典型用户：在校学生以及学校教职工。
典型场景：到食堂吃饭，可是档口太多，不知道吃啥。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
我们的地图功能大概完成百分之八十，刷一刷功能完成比较惨。未能按照原计划时间交付。由于小程序还在测试阶段，用户暂时只供组内测试，
希望快点做出更加完善的产品出来供更多人来测试。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户暂时为我们的开发人员，所以大体一致。我们会继续努力，争取一步一步向目标靠近。
4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：我们把重心放偏了，我们想要完成的功能太多，结果导致亮点功能未能成功完成（也是组长我的锅呜呜呜）。
改进：我们会在beta冲刺中把我们的重心移回来，努力完成地图美化以及刷一刷功能。
2.2.2. 计划
1、是否有充足的时间来做计划?
有很充足的时间来做计划，我们从团队建立就开始讨论选题内容了。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
团队在计划阶段没有什么不同意见，如果有的话，会进行讨论，最后大部分情况下遵从少数服从多数、菜鸡服从大佬的规则。
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大部分工作完成了，小部分没有完成。原因：预想的和现实不一样，能力不足。
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
我们组的重心放错了，所以在功能实现方面上绕了不少弯路
5、是否每一项任务都有清楚定义和衡量的交付件?
一开始没有考虑这个情况，没能给每一项任务下一个清楚定义和衡量的交付件，导致后面有些任务节奏有点乱。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
并没有完全按照计划进行，在完成项目的时间段中碰上了考试，主要开发人员既要复习考试又要小程序开发，时间赶不及，任务无法
按原计划完成。风险可能就是当时没能想到有些功能实现起来很麻烦而且紧跟着考试，再加上平常还要上课，完成任务时间非常少。
7、在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区。缓冲区起到了很大的作用。
8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
重新制定我们接下去要完成的任务，合理安排人手来干活，会考虑加班完成，留下更多的缓冲区。
9、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划制定应该更加详细，组员之间交流沟通应该更加密切。
改进：之后会制定更加详细的计划，作为组长我也会加强督促组员，让组员间的沟通交流更加密切。
2.2.3. 资源
1、我们有足够的资源来完成各项任务么?
组内大家都缺少项目开发经验，导致学习成本较高，时间资源较为不足。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需时间和其他资源主要由负责完成任务的组员估计，精度一般，只大概估计一下，有一些情况当时未能考虑进去。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
不够充足。
我们没有低估难度，但美工设计实在是得有天分，我们大家地图平面设计实在做得很差。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
大家都没有啥开发经验，所以也不存在让别人来做更有效率吧，只能大家一起不断努力。
5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
要充分利用资源，抓紧空余的时间，尽早地完成任务，防止意外情况发生，没办法有充足的时间处理。
如果历史重来，会在比较空闲的时间安排多一点的任务，在有意外情况（比如考试以及考试复习）发生时，减少任务。
2.2.4. 变更管理
1、每个相关的员工都及时知道了变更的消息?
如果有变更，会在群里艾特全体成员通知大家，保证消息通知到位。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
在需求分析部分，我们就已经决定好重点开发内容，但是我们却跑偏了，很尴尬（组长我背大锅）。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
项目具备了能完好运转核心功能及其他相关的基本功能。
4、对于可能的变更是否能制定应急计划?
一开始并没有制定应急计划，等到碰到突然地变更时才临时改变计划，导致后期的任务完成得比较匆忙。
5、员工是否能够有效地处理意料之外的工作请求？
若出现意料之外的工作请求，会根据组员现有的任务情况来判断哪个组员比较适合完成，在给予分配，保证能完成请求。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
安排任务时也要考虑一下突发情况，预想好会出现的情况并考虑解决办法。如果历史重来，会再考虑周全些，把一些可能出现
意外情况也考虑进计划安排里。
改进：根据任务重要性和难易程度，合理进行安排。
2.2.5. 设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在Alpha冲刺快开始的时候，由组长组织会议，组员共同讨论决定。是的。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
共同讨论解决。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
暂时还没有，uml挺有用的。
4、比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
有区别，但是不大。一开始想法太多，代码实现无法实现所有功能。否。
5、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
刷一刷功能。智能推荐难度太大了，没办法做好。刚开始饼画太大了。
6、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由于时间不足，暂时没有进行严格的代码复审。
7、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
代码复审应该随时进行，而不是等项目完结后再进行。测试要及时赶上。
2.2.6. 测试/发布
1、团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
有，计划在项目大致完成时进行测试。
否，因为项目完成进度还差很多。
2、团队是否有测试工具来帮助测试？
使用微信小程序自带的真机调试进行测试。
3、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
小程序还未完全完成，暂时不考虑测量和跟踪软件性能。测试工作的效果和需要改进的地方还无法得知。
4、在发布的过程中发现了哪些意外问题？
项目还未完成，还没有发布，所以还没有什么意外问题。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
要留更多的时间来完成测试。
改进：加紧完成任务，留出更多的时间。
2.2.7. 团队的角色，管理，合作
1、团队的每个角色是如何确定的，是不是人尽其才？
根据成员意愿和能力来确定角色，但是部分组员基础较差，感觉没有合理人尽其才。
2、团队成员之间有互相帮助么？
有，大家互相帮助，不局限于自己任务。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
进行共同讨论来进行解决
我很感谢 苏炜斌 对我的帮助，共同处在压力下，与他的交流能适当缓解压力。
4、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学会了相关任务的知识，队友间的合作也越来越顺畅。如果历史重来，会再好好安排一下团队的角色，争取更大的人尽其才。
2.2.8. 总结
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
初始级别。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?\
磨合。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
任务安排变得更加清晰，小组成员间更加熟悉。
4、你觉得目前最需要改进的一个方面是什么?
小组成员要加强沟通。任务分配要更加清晰。
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
原则5-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
事例：鼓励几个开发大腿，始终相信他们能够完成任务。
