M1事后总结报告

设想和目标

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

解决外卖信息的碎片化和多平台化，通过信息整合的方式来给用户提供一个更优惠更快速方便的外卖平台。

• 我们的客户定向于现在所有的外卖服务的购买者，尤其是最近的一波外卖打折风波让外卖这种独特的信息网的的信息价值攀升，是否有充足的时间来做计划?

有时间，但是我们第一次面临7个人团队来进行一个我们完全未知难度的项目，我们认为在最开始我们已经做好了充分的计划和准备，但是我们在途中还是遭遇了很多的苦难与变化，还好我们最后都一一解决，但是这样也极大的减缓了我们的进度。

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

在团队运作的过程中，我们遭遇了非常多的分歧，我们对于不同意见的处理方法，是在我们集体讨论后，进行一些技术验证，然后去决定一个争论的结果。

计划

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

原计划的部分功能没有实现，只有在M2进行实现，我们在途中遭遇了很多技术的困难，耽误进度。

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

其中很多突然的变化，让一些工作成了无用功，但是在某些方面也有一定价值

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

这个方面我们没有做好，我们在内部之间的交付没有做好代码上的约定，导致了高耦合，花了大量的时间去解决这些本来可以避免的细节问题。

• 是否项目的整个过程都按照计划进行?

没有，我们的计划过于理想，其中有些部件的完成进度被耽搁，导致了整个项目的延迟。

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

没有，我们是交付之间的人员直接对接与沟通，两人在deadline的一定弹性范围内就开始联系交付。

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

将来希望对我们的任务做更小，更细节的分类和定位，更准确的时间预计，更灵活、正确的人员安排，让交付的耦合度降低。

资源

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

我们对于我们这次项目的知识储备相当缺乏，对于项目需要的技术也是未接触过，另外，服务器这一重要的硬件设备我们也是缺乏，最后学校配给的服务器还是无法满足我们的需求。

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

最开始非常天真理想的去估计，时间估计很短，但是实际过程中发现需要的时间远远不止那么少。

• 用户测试的时间，人力和软件/硬件资源是否足够?

我们使用了开源平台来进行app的兼容和运行测试，没有大问题，对于客户测试，我们团队内部和周边的朋友也投入了一些时间进行使用。

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

UI这方面的工作我们最后分配挺乱的，最后由我们几个同学进行了UI元素的创作与编辑，由android开发人员进行筛选和编排，这些业务的重叠区应该分离开，将相关的任务分配到该分配的人员。

变更管理

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

我们会第一时间和相关人员说明更新

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

我们根据项目本身的功能来决定，对于多个网站信息这种可以重复劳动得到的就决定推迟。

• 项目的出口条件（Exit Criteria）是否得到清晰的定义?

大家都不太懂“出口条件”是什么，经过这一个项目之后，稍稍清楚了一些。但是说实在的，在这个项目里面我们没有用到太多。

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

尽量主管的人员继续解决，如果速度太慢我们就会分配更多的人员

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

能，我们尽量对工作进行科学的分配。

设计/实现

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

像数据库的设计工作在最开始就着重研究了，因为作为核心型的数据点，我们希望数据库和爬虫与设备都有良好的连接约定，android设计师在android端开发的时候设计的有些界面的设计过早，大家为了字体的大小，按钮的尺寸争论，事实上这些事情不应该由开发人员在项目早期来做。

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

大致上没有

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

数据库使用了ER图来辅助设计，单元测试未采用，我们对于每一个组件在交付前都会做一些测试。

• 什么功能产生的Bug最多，为什么？

爬虫涉及的信息流变化大，数据杂，Bug也最多。

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

代码主要是相关的开发人员进行复审，我们希望最了解代码的人去负责自己的区域。

测试/发布

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

我们的测试计划是在开发时同步测试，然后再整合后结合现在存在的开放性测试平台和人工测试同步进行测试。

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

我们在验收阶段都会对功能进行一个全面的诊断，在项目交付时用了1问中的方法进行测试。

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

有，百度BTC开放平台。

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

我们是在在开发完成的时候运用相关的性能工具对软件进行效能测试，再进行进一步开发。有用，解决我们几个内存占用太多的问题。

我们希望对单元增加更多测试。

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

发现了app之前没有发现的bug，有几个app崩溃的问题，另外，获得发布资格的过程中我们也遇到了很多问题，很多发布平台的审核标准太严格，不严谨，没有给开发者正确的答复。

敏捷开发原则：

• 以有进取心的人为项目核心，充分支持信任他们

我们团队在这一点上做的很好，我们团队的app点子最早是张明同学的一个点子，他也为这个项目的开发做出了很多，我们充分信任他，并把服务器和app后台的开发交给他，并由他做最后的整合，他把各个内部交付的组件都理解的很好，我们因为他的开发实力弥补了我们之前的一些进度的推迟。

• 无论团队内外，面对面的交流始终是最有效的沟通方式

我们团队在开发的时候总是选择进行面对面交流，负责爬虫的小伙伴总是选择结对编程，面对面的交流让两个人的沟通更好，互相进行想法的评估，同时也加快了代码的开发速度和提高了正确性。

我们M2需要注意的：

对第二阶段的更充分的计划，对任务的准确划分和拿捏

提前的部件设计和约定，避免后期开发的一些苦难。

对新加入的成员慢慢带入团队，逐渐增加融入感。

对于测试的严谨，希望在时间允许的情况下，单元测试能够实施。