Beta阶段复审
| 小组名字和链接 | 优点 | 缺点和bug报告 | 最终排名 |
|
RunningGuys |
1.提供方便快捷明确的注册与登录界面； 2.界面整洁给人焕然一新的感觉； 3.简单、易上手，能让用户更容易地使用软件。 |
1.输入正确帐号密码后，第一次按登录按钮时会因与服务器连接失败而提示登录失败，直接第二次按才能成功登录。 2.只能显示经纬度而不能显示具体的地理位置，约炮的难度就变的比较大了，比较大家都不太懂这个经纬度的知识。 3.没有做代码的备份，应对风险的能力不够强。 4.没有一个发布运动计划的环境平台，如果能有一个类似分享的功能，可能会更加激起用户跑步的动力。 5.创建计划第一次也不能成功，也要第二次才能，这样的细节对于给用户的印象有一定的不好的影响。 |
1 |
|
Sugar free |
1：能够可以出不同难度系数给每个处在不同阶段时期学习的学生 2：通过系统自己在线组卷测试 3：系统界面能够美观和实现和实现自己导出试卷 |
1.没有导入试卷和错题功能，对于学习来说导入和错题都是比较重要的功能，也是非常实用的功能，不然仅仅依靠数据库里面的题目，可能不能满足用户的需求。 2.前台管理功能还是会出现一些故障，前端界面的管理需要更加精细的开发。 3.只是实现了最基本的出卷功能，而没有太多的扩展功能，这样会导致这个出卷系统的功能过于单调。 4.源代码管理比较随意，没有管理文档，项目交接时会有一些问题，这样会导致项目的风险应对会比较大。 5.源代码没有太多注释，查看和修改代码会比较费力气，建议能够在编写源代码的时候多加上一些注释 6.后台题目的更新都是手动更新数据库，费时又费力。 |
2 |
|
217萌萌哒 |
1.界面简洁大方 2.记账功能简单明了，用起来比较方便 3.最核心的功能实现的比较好 |
1.在登录界面没有设置账号和密码的限制，这样登录界面就仅仅是一个界面，而没有太多的实际意义。 2.代码管理还不够好，且源代码的注释不够完整，查看和修改不是特别清楚和方便，项目的风险应对不够完善。 3.记账本就仅仅只有记账的功能，没有更多的扩展功能和一些联网的社交功能，可能不具备得到大部分用户青睐的特殊性。 5.每个人都负责一个部分固然分工明确，可是不同部分的代码开发也是有很大的关联的，多多交流才能加快开发的效率，也更能增加这个模块之间的联系。 |
3 |
|
为所欲为 |
1.基本游戏的功能比较完善 2.开发了基本功能以外的扩展功能，给用户更多的享受 3.界面比较美观大方 |
1.源代码没有注释，查看和修改不太方便 2.项目的风险管理不够完善，代码的注释还可以更加详细一点，以便于可能存在的项目交接的事项。也更方便代码的管理和修改。 3.24点游戏不能按钮输入，还是与之前一样只能通过键盘输入，还是会给游戏带来一些不方便。 4.没有实现好友pk的功能，一个人玩这样的游戏比较单调无聊，使这个游戏不具有社交性，这样就难以吸引比较多的用户。 5.绝大部分代码都是小组组长一个人提交的，在开发过程中，可能需要更多的团队配合，而不是组长一个人扛起大梁 6.app最主要的功能就是24点，我认为团队可以集中精力在游戏的功能开发创新，比如联网对战，比如成绩排行榜等等功能。那些微信功能只是锦上添花的功能，远没有游戏功能对项目重要。 |
4 |
事后诸葛亮分析
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
编写的app主要解决了个人学习提醒的功能，让使用者提前设置好学习计划安排，等到特定的时候提醒用户。促使用户合理地计划时间，养成良好的学习习惯增加学习的效率。也可以在网络上借鉴其他人的学习计划，取其精华去其糟粕，从而形成适合自己的学习计划。
2.团队在计划阶段是如何解决同学们对于计划的不同意见的？
大家的目标都有一个共同的目标出现分歧时，我们会及时讨论取得一个大家都认可的计划，在能力范围内让每个人发挥自己实力的最大化。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
用于对于产品的接受程度与我们的事先预想的不太一致，如果历史重来一遍，我们会将界面修改的更加美观，增加一项统计每天工作学习休息的时间比例。认真思考一下我们的产品与市面上功能相近的app之间的差异在哪里。
计划
1. 是否有充足的时间来做计划?
有，我们用了将近一周的时间，设想app的架构功能和app的制作方向，在进一步完善计划中的各种功能。
2. . 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有，有一部分的优化没有实现。在设计和实现的过程中学习app的开发用的时间稍微有点长，美化界面的经验不足。
3.有没有发现你做了一些事后看来没必要或没多大价值的事?
有，在做出不同的功能的时候发现，有的功能近乎相似，然后就又重新设计新的功能。
4. 是否每一项任务都有清楚定义和衡量的交付件?
虽然每一项任务都有清楚的定义，但是有时候预想的功能在使用代码实现的时候会有些出入，一个较简单的功能在编写的时候又是也可能出现一些差错导致任务时间的拖延。
5. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
并没有想象中那么顺利，在制定计划的把编写代码想的过于简单，导致经常出现一些bug让软件崩溃，主要是大家编程的能力有限，经常需要现场学习才行。
6.在计划中有没有留下缓冲区，缓冲区有作用么?
预留缓冲区为了应对出现的突发状况，或者想到新的想法可以直接添加进去。
7.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
我们学到了在项目中尽量为日后可能出现的变故留出时间空间。学到了计划并不能完美地执行，过程中可能会遇到许多的问题需要重新讨论解决，如果重来一遍，我们不会过分地注重计划， 而是注重过程。
资源
1. 我们有足够的资源来完成各项任务么?
有，通过发达的网络资源可以找到绝大多数我们需要的资源。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
时间上基本都是按照计划表来安排的，基本上都是在课余或者晚上的时间完成任务
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
a. 测试时间：基本足够，所有的软件功能都通过了测试
b. 人力资源：小组成员都有明确的分工，每个人都各尽其责完成各项指标。
的确，编程初期对美工这一方面就是以为随便添加一些图片之类的，但在实际操作的时候发现美工需要注意很多地方。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
同学直接每天都有见面的机会，一旦有变更的消息会立即开展站立式会议通知到每一个成员。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
在设定项目计划的时候我们设定了每个功能的优先级所以优先级低的功能可能会被推迟，
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
完成了用户使用状况的反馈后最初相应的调整，修改对应代码后。
4. 对于可能的变更是否能制定应急计划?
每个人有明确的分工，来应对紧急的计划
5. 员工是否能够有效地处理意料之外的工作请求？
经过统一的讨论后，基本都可以解决。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一个项目的消息变更是多么的重要，一定要在第一时间通知项目的所有组员，保证所有组员了解最新的消息。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
再设计工作之前小组内没有一个人做过项目的经理没有设计的经验，所以在想法都是通过小组成员之间意见的碰撞产生的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
小组成员的每个人都是通过单元测试的方法测试自己负责的部分，在通过讨论在合并到一起。测试工具倒是没有尝试过。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在软件运行的各部分功能切换的时候会出现bug，有时会卡着不动，编写的时候经常出现各种各样的问题在查找解决方案的时候会加入一些其他的代码。本以为没有什么bug但是在实际运行的时候居然有这么多。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们都有严格的遵守代码规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，在设计的时候就制订了测试计划
2. 是否进行了正式的验收测试？
正式进行了每个模块的测试，整体的测试在app完成后用虚拟机测试
3. 团队是否有测试工具来帮助测试？
用的是Eclipse中的安卓虚拟机。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
还是蛮有用的至少让我们发现了许许多多的问题
5. 在发布的过程中发现了哪些意外问题？
无
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
每个人都是项目负责的部分，都是靠竞争上岗。
2. 团队成员之间有互相帮助么？
当然有在编程出现瓶颈的时候会一起讨论下一步应该如何进行。
3.当出现项目管理、合作方面的问题时，团队成员是如何解决问题的？
当如果遇到有不同意见的地方，我们会采用每个人认真的阐述自己的观点并指出为何别人的观点不适宜于我们的项目，而自己的观点高明在哪里。在所有人阐述完以后我们再举行民主投票，采用支持者最多的观点的方法。如果有不可调和的地方，最终一般是由组长来决定。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一个人的能力始终是有限的只有大家拧成一股绳一起努力才能更快更有效的完成一件事情
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
1.项目经理每天都有督促、鼓励开发人员的进程。
2.每个人都牺牲了自己本来应该休息的时间去学习关于安卓开发的知识。
3.团队直接没有任何一点不和谐的因素，让团队的沟通变得十分的顺利
博客要附上全组讨论的照片
2.团队成员在Beta阶段的角色和具体贡献：
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
| 林清清 | PM | 18 | 项目主要开发 |
| 张中结 | 队长 | 19 | 项目规划和任务分配 |
| 陈惠 | Dev | 17 | 部分功能开发 |
| 郑莹 | Dev | 16 | 前端设计 |
| 林晓芳 | Test | 15.5 | 项目测试 |
| 栗海辉 | Dev | 14.5 | 前端设计 |