标签：android 使用 sp 数据 问题 bs 代码 ad ef
设想和目标
解决外卖信息的碎片化和多平台化，通过信息整合的方式来给用户提供一个更优惠更快速方便的外卖平台。
有时间，但是我们第一次面临7个人团队来进行一个我们完全未知难度的项目，我们认为在最开始我们已经做好了充分的计划和准备，但是我们在途中还是遭遇了很多的苦难与变化，还好我们最后都一一解决，但是这样也极大的减缓了我们的进度。
在团队运作的过程中，我们遭遇了非常多的分歧，我们对于不同意见的处理方法，是在我们集体讨论后，进行一些技术验证，然后去决定一个争论的结果。
计划
原计划的部分功能没有实现，只有在M2进行实现，我们在途中遭遇了很多技术的困难，耽误进度。
其中很多突然的变化，让一些工作成了无用功，但是在某些方面也有一定价值
这个方面我们没有做好，我们在内部之间的交付没有做好代码上的约定，导致了高耦合，花了大量的时间去解决这些本来可以避免的细节问题。
没有，我们的计划过于理想，其中有些部件的完成进度被耽搁，导致了整个项目的延迟。
没有，我们是交付之间的人员直接对接与沟通，两人在deadline的一定弹性范围内就开始联系交付。
将来希望对我们的任务做更小，更细节的分类和定位，更准确的时间预计，更灵活、正确的人员安排，让交付的耦合度降低。
资源
我们对于我们这次项目的知识储备相当缺乏，对于项目需要的技术也是未接触过，另外，服务器这一重要的硬件设备我们也是缺乏，最后学校配给的服务器还是无法满足我们的需求。
最开始非常天真理想的去估计，时间估计很短，但是实际过程中发现需要的时间远远不止那么少。
我们使用了开源平台来进行app的兼容和运行测试，没有大问题，对于客户测试，我们团队内部和周边的朋友也投入了一些时间进行使用。
UI这方面的工作我们最后分配挺乱的，最后由我们几个同学进行了UI元素的创作与编辑，由android开发人员进行筛选和编排，这些业务的重叠区应该分离开，将相关的任务分配到该分配的人员。
变更管理
我们会第一时间和相关人员说明更新
我们根据项目本身的功能来决定，对于多个网站信息这种可以重复劳动得到的就决定推迟。
大家都不太懂“出口条件”是什么，经过这一个项目之后，稍稍清楚了一些。但是说实在的，在这个项目里面我们没有用到太多。
尽量主管的人员继续解决，如果速度太慢我们就会分配更多的人员
能，我们尽量对工作进行科学的分配。
设计/实现
像数据库的设计工作在最开始就着重研究了，因为作为核心型的数据点，我们希望数据库和爬虫与设备都有良好的连接约定，android设计师在android端开发的时候设计的有些界面的设计过早，大家为了字体的大小，按钮的尺寸争论，事实上这些事情不应该由开发人员在项目早期来做。
大致上没有
数据库使用了ER图来辅助设计，单元测试未采用，我们对于每一个组件在交付前都会做一些测试。
爬虫涉及的信息流变化大，数据杂，Bug也最多。
代码主要是相关的开发人员进行复审，我们希望最了解代码的人去负责自己的区域。
测试/发布
我们的测试计划是在开发时同步测试，然后再整合后结合现在存在的开放性测试平台和人工测试同步进行测试。
我们在验收阶段都会对功能进行一个全面的诊断，在项目交付时用了1问中的方法进行测试。
有，百度BTC开放平台。
我们是在在开发完成的时候运用相关的性能工具对软件进行效能测试，再进行进一步开发。有用，解决我们几个内存占用太多的问题。
我们希望对单元增加更多测试。
发现了app之前没有发现的bug，有几个app崩溃的问题，另外，获得发布资格的过程中我们也遇到了很多问题，很多发布平台的审核标准太严格，不严谨，没有给开发者正确的答复。
敏捷开发原则：
我们团队在这一点上做的很好，我们团队的app点子最早是张明同学的一个点子，他也为这个项目的开发做出了很多，我们充分信任他，并把服务器和app后台的开发交给他，并由他做最后的整合，他把各个内部交付的组件都理解的很好，我们因为他的开发实力弥补了我们之前的一些进度的推迟。
我们团队在开发的时候总是选择进行面对面交流，负责爬虫的小伙伴总是选择结对编程，面对面的交流让两个人的沟通更好，互相进行想法的评估，同时也加快了代码的开发速度和提高了正确性。
我们M2需要注意的：
对第二阶段的更充分的计划，对任务的准确划分和拿捏
提前的部件设计和约定，避免后期开发的一些苦难。
对新加入的成员慢慢带入团队，逐渐增加融入感。
对于测试的严谨，希望在时间允许的情况下，单元测试能够实施。
标签：android 使用 sp 数据 问题 bs 代码 ad ef
原文地址：http://www.cnblogs.com/sixsix/p/4133179.html
