设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
要解决的问题：目前外卖网站比较多，用户很难快速找到合适的外卖，我们集合各个网站的外卖信息，为用户提供便利。在M1阶段我们基本实现了餐站app的基本功能。在M2阶段我们主要是修复M1阶段的BUG，
完善、拓展软件功能、优化网络爬虫
2. 是否有充足的时间来做计划?
用于计划的时间还算比较充足。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们会用专门的时间开展组会，组会时全员到齐，大家各抒己见，经过讨论后得到一个大家都认可的计划。
对于用户量
用户量比较少，与我们事先设想的很不符。活跃用户基本都是我们的测试人员。
我们认为原因如下：我们本来打算做一个涵盖各大外卖网站的信息汇总以及区功分能的app，但是由于爬虫问题，导致我们只能成功获取了一个网站的信息，无法实现横向比较功能。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有都做完，我们计划爬取美团等网站的内容，但是由于他们的反爬虫机制，导致我们没能成功爬取信息。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有，我们做的事情不是为了查找、修复BUG就是为了实现新功能。就算有所失败也算是宝贵的经验。
3. 是否每一项任务都有清楚定义和衡量的交付件?
不是每一项任务都有清楚地定义。比方说改进UI，这种任务依靠感觉以及一些网上的资料，但是网上的资料各种各样，我们没有类似的知识。
4. 是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到?
爬虫模块并没有按照计划进行。风险，应该就是爬虫没能成功实现导致我们的应用丧失了一个最主要的卖点：相同菜品不同餐站价格比较。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区。缓冲区是一个余量。有时我们的工作不会像认为的那样顺利进行。缓冲区的存在让我们有了一道保险。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
我们将来的计划将更加精准地考虑大家的能力区别，尽量平衡大家的工作时间。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在爬虫问题中，我们深刻了解了对风险预计不足的结果。如果历史重来一遍，我们将考虑每个功能无法实现所带来的后果，即风险评估。
多考虑一些功能，根据风险评估以及预期效果来选择实现一些功能。同时在某些功能无法实现时也能够找到一些其他功能实现，使我们的应用能够保证竞争力。
资源
1. 我们有足够的资源来完成各项任务么?
我们的资源比较充足。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需的时间都是根据M1的经验估计的，经历了M1阶段，大家对任务所需时间都有了一定了解，所需时间和估计的基本一致，相差一般在1个小时以内。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
我们使用了开源平台来进行app的兼容和运行测试，没有大问题，对于用户测试，我们团队内部和周边的朋友也投入了一些时间进行使用。
对于不需要编程的资源没有低估难度。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
基本而言是不会的，因为具体模块一般是分配给固定的同学。因此对于那些模块来讲，其他同学的熟悉程度比不上接受那些模块任务的同学。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
由张明培育在项目开始阶段。是。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？
我们用了单元测试功能。单元测试可以提升反馈速度，减少重复工作，提高开发效率，很有效。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
下拉刷新功能导致的BUG最多。
发布之后的BUG如下（在客户端测试中更详细）：
BUG1：出现在主界面的下拉刷新控件。当下拉刷新时，会默认选定手指划过屏幕时经过的某一商品，但是并不会进入其详细页，即使切换筛选方式仍然会选定相应的商品栏，如下左图所示；有时会发生刷新之后在筛选条件和商品目录之间出现空白的意外情况，如下中图所示；严重时，甚至会导致应用崩溃，不响应。
BUG2：在“更改位置”的输入框中，如果输入不合理，如输入“博客”、“aaa”等，则会直接停止运行；如果输入地址非北京地区，如“四川”、“中国”等，则只会显示在北京地区的搜索甚至不显示搜索结果。
产生BUG1的主要原因是我们没有考虑到下拉刷新功能会与其他功能产生冲突。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
在开发过程的同时进行代码复审，如果有错误就及时修正错误；如果无法修正则返回上一版本。
代码规范：在客户端软件内、客户端与服务端api之间、服务端代码中严格执行了代码规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试计划。
首先，在开发过程中，开发人员会对代码正确性及可行性进行测试。
在开发结束后，由专门的测试人员对软件的每个功能进行单元测试；对整个项目的每个环节进行性能测试；
2. 是否进行了正式的验收测试？
进行了正式的验收测试。
3. 团队是否有测试工具来帮助测试？
服务端接口测试脚本，客户端功能测试-手动测试/百度MTC，服务器性能测试-服务器自动测试工具。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
用了百度MTC进行了客户端性能测试，服务器性能测试说明服务器可以承载我们的应用，爬虫性能测试则是单元测试，爬虫的效果基本准确。
5. 在发布的过程中发现了哪些意外问题？
推广费用比较贵，经费有限，我们不能承担。
总结:
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
互相之间的配合更默契，矛盾比之前少了很多。
团队讨论合照在下面
