团队项目总结（事后诸葛亮）
设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件规避了其他新闻app的一些令用户痛苦的地方。（用户的感性评论容易受到攻击、有很多标题党新闻，不能实事求是、有删除用户评论的现象、广告太多。）
可以让用户安心的看新闻，放心大胆的评论
2、是否有充足的时间来做计划?
有很充足，按照老师的要求做了项目的需求分析和原型展示。
3、团队在计划阶段是如何解决同事们对于计划的不同意见的？
商量解决或实践后看结果。例如：在做个人详情界面时各个功能是用列表形式展示，还是九宫格形式展示？发生了争执最后是通过把这两种样式都做出来，进行比较投票解决的
4、如果历史重来一遍, 我们会做什么改进?
各个团队各自为战，导致UI这边各个团队做的功能有些重合，而且大家的数据结构有差异，给代码整合带来很大麻烦，同时，软件的具体功能没有定义清楚，比如，对于资源的定义，开始我们UI组并没有想到还要在线展示爬来的网页。
计划
1、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有，没做完的部分是：专项分析特朗普（中美关系）
原因：资源太少，分析不动。
2、有没有发现你做了一些事后看来没必要或没多大价值的事?
有：我们花费很长时间研究了新闻详情页的排版问题，没有用都不能做到动态排版，最终只能是用webview展示爬取下来的网页。
3、是否每一项任务都有清楚定义和衡量的交付件?
任务在任务看板上写的比较简介明了，大家都能明白。
4、是否项目的整个过程都按照计划进行?
队长一直在赶进度，队员因为一些技术问题的进度有时候不尽人意！
5、在计划中有没有留下缓冲区，缓冲区有作用么?
有，缓解紧张气氛，回顾之前的成果，对以后的工作进行调整。
6、如果历史重来一遍, 我们会做什么改进?
1、谋定而后动，尽最大努力提前计划好个功能在实现方式。
2. 预留必要的缓冲时间，留给后期的整合。
资源
1、我们有足够的资源来完成各项任务么?
资源（书籍，开源解决方案，服务器，素材）非常充足
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务估计精度不是很好，因为任务是由队长估计的，而由队员完成，队长不知道队员对技术的掌握程度如何，有时候估计的任务不是很精确。
3、用户测试的时间，人力和软件/硬件资源是否足够?
我们花了两天半的时间来做测试，相对于工程量而言，已经比较充足。
你有没有感到你做的事情可以让别人来做（更有效率）?
没有。
4、如果历史重来一遍, 我们会做什么改进?
1、分配任务时充分征求队员的意见，确保队员分配的任务可以顺利完成。
2、提前找好项目所需资源。
变更管理
1、每个相关的员工都及时知道了变更的消息?
可以，只要查看QQ就可以知道。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据功能在整个项目中的重要程度，和自身的技术水平。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
所有页面整合在一起，逻辑合理，风格统一，并且通过了各项测试，就“做好了”。
4、对于可能的变更是否能制定应急计划?
没有。
5、员工是否能够有效地处理意料之外的工作请求？
不能。
6、如果历史重来一遍, 我们会做什么改进?
1. 善用TFS的源代码管理，少用QQ互传文件。
2. 多开会交流，少通过短信通知。
设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在冲刺的前三天。由经验最丰富的队长来完成。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，经开会一起讨论解决。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
没有使用。
4、什么功能产生的Bug最多，为什么？
新闻列表展示。因为自身技术不高，经验根本就没有，而这个界面涉及的功能有很多，增加功能时，影响了之前写好的其他功能代码。
5、如果历史重来一遍, 我们会做什么改进?
将UI的部分组件控件化，方便修改与维护
测试/发布
1、团队是否有一个测试计划？为什么没有？
团队有明确的测试计划。
2、是否进行了正式的验收测试？
没有。
3、团队是否有测试工具来帮助测试？
没有。
4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们并不了解效能测试，但是会在beta中考虑，我们使用软件进行了负载测试，找到了几个致命的数据库操作的bug，在前几篇博文中我们有过总结。
5、在发布的过程中发现了哪些意外问题？
因为网络问题，（web端在本机上）安装到手机上后涉及到网络请求的功能时会闪退。
