1、基本情况
答辩总结：
·因为alpha阶段的产品做得偏离了方向，所以beta冲刺大家非常拼命，也拿出了相应的
成果，基本功能已经初步完成，剩下的就只有更多的数据收集和一些bug的修改，以及柯
老板提出的拍照上传的功能，我们会在最后的final阶段完成的。
讨论照片：
工作流程：
·beta阶段的开发阶段分为重构首页，美化地图，优化推荐功能以及收集数据，分配给不同人手进行开发。
分工以及贡献比例
| 组员 |
组员分工 |
工作量比例 |
| 黄纯朴 |
分工协调、团队督促、博客撰写、美化地图 |
10.5% |
| 魏祖文 |
前后端交互、云开发 |
16% |
| 谈世宏 |
前端开发、云开发 |
16% |
| 苏炜斌 |
前端开发主力 |
16% |
| 谢鑫杰 |
前端开发、收集数据 |
10.5% |
| 蔡震泽 |
前端开发、ppt制作以及答辩 |
8% |
| 李赫 |
云开发 |
7% |
| 熊崟 |
收集数据、前端开发 |
8% |
| 平措旺堆 |
收集数据、工具人 |
8% |
2、总结
2.2.1. 设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决在校学生到食堂吃饭不知道吃什么的问题。
定义得很清楚。
典型用户：在校学生以及学校教职工。
典型场景：到食堂吃饭，可是档口太多，不知道吃啥。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
原计划功能基本完成，数据收集尚未齐全。beta阶段按照原计划时间交付。已经发布了，争取早日达到目标用户量。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户暂时为我们的开发人员，所以大体一致。我们会继续努力，在final阶段尽量拉多一些人来使用，争取一步一步向目标靠近。
4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：时间还是留得不够多，最后一天晚上的时间超级赶，还是要留下更多时间呀。
改进：多留一些缓冲区。
2.2.2. 计划
1、是否有充足的时间来做计划?
有很充足的时间来做计划，我们从团队建立就开始讨论选题内容了。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
团队在计划阶段没有什么不同意见，如果有的话，会进行讨论，最后大部分情况下遵从少数服从多数、菜鸡服从大佬的规则。
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大部分工作完成了，小部分没有完成。原因：预想的和现实不一样，能力不足。
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
我们组的重心放错了，所以在功能实现方面上绕了不少弯路。
5、是否每一项任务都有清楚定义和衡量的交付件?
一开始没有考虑这个情况，没能给每一项任务下一个清楚定义和衡量的交付件，导致后面有些任务节奏有点乱。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
并没有完全按照计划进行，因为在alpha阶段重心偏离，做得不好，所以beta阶段大家时间紧任务重，开发人员
累得都快晕过去了。风险：alpha阶段重心偏离了。原因：我这个组长的锅呜呜呜。
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、在发布的过程中发现了哪些意外问题？
1.0版本发布遇到了用户重复授权以及刷一刷遇到机型适配的问题，我们之后开发的2.0版本要用户上传
信息以及调用摄像头，估计会遇到问题。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
要留更多的时间来完成测试。
改进：加紧完成任务，留出更多的时间。
2.2.7. 团队的角色，管理，合作
1、团队的每个角色是如何确定的，是不是人尽其才？
根据成员意愿和能力来确定角色，但是部分组员基础较差，感觉没有合理人尽其才。
2、团队成员之间有互相帮助么？
有，大家互相帮助，不局限于自己任务。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
进行共同讨论来进行解决
我很感谢 魏祖文，苏炜斌，黄纯朴 对我的帮助，魏祖文，苏炜斌两位位大佬撑起大片个beta冲刺，纯朴在beta冲刺的过程努力组织大家为beta冲刺提高了不少效率。
4、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学会了相关任务的知识，队友间的合作也越来越顺畅。如果历史重来，会再好好安排一下团队的角色，争取更大的人尽其才。
2.2.8. 总结
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
管理级。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
分工明确，小组成员间更加熟悉。
4、你觉得目前最需要改进的一个方面是什么?
除了几个大佬，大家基础差，应该继续学习。
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
原则5-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
事例：鼓励几个开发大腿，始终相信他们能够完成任务。
原则4-业务人员和开发人员在项目开发过程中应该每天共同工作。
事例：beta阶段xdm天天线下一起肝，玫瑰园的椅子都快被我们霸占了。