M1事后分析报告
我们的项目整体分为服务端和客户端。服务端准备架设在服务器上，进行多平台用户数据的存储。客户端目前打算做两个，一个基于Windows平台，一个基于Android平台。主要需要实现的功能有两个：
- 对于个人用户，实现个人的设置闹钟，取消闹钟的操作，这些操作将会上传至数据库，并被同步到所有的客户端上。在服务器端要实现用户注册、数据的增删改查等功能。
- 对于群组，我们还要加入用户的好友功能，可以根据其他人的ID来添加好友，将好友拉入群组，如果好友同意的话，这个群组可以设定群组闹钟，这些闹钟会被共享给整个组内的所有成员。对于这个功能，我们在服务器端还要加入用户的好友数据，以及群组。
【计划】
我们目前打算用Bmob后端云，这也是我们在第一轮迭代之前需要完成的。另一个需要在第二轮迭代完成的是windows端的客户端，我们需要在第一轮迭代前实现Beta版本。
对于这个项目，我们认为用心做就一定会有用户，界面简介，没有广告，做良心的应用。
M1事后分析报告
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
软件的灵感来源于组员的最初需求，生活中经常会发现很多社团会议难以加入日历项，大多数会议也只是口头通知，我们的闹钟提醒软件就是由活动发起用户建立群组来提醒所有组员，从而解决这些问题。定义和典型用户及场景已在说明书中明确说明。
2. 是否有充足的时间来做计划?
有时间，但是没有充分利用时间来做计划，对计划的执行力度不够。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
主要是在团队会议讨论阶段，大家提出自己的看法，最后由几位核心负责人总结并制定计划。
计划
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们目前打算用Bmob后端云，这也是我们在第一轮迭代之前需要完成的。另一个需要在第二轮迭代完成的是windows端的客户端，我们需要在第一轮迭代前实现Android版本。
对于这个项目，我们认为用心做就一定会有用户，界面简介，没有广告，做良心的应用。
目前原计划的实现Android版本完成了一部分。因为第一轮我们的开发主力被学院调走参加挑战杯比赛。落在其余组员身上的压力过大，以至于没有完成。
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
有，而且这些事浪费了我们时间。比如纠结用何种开发工具。
3. 是否每一项任务都有清楚定义和衡量的交付件?
不是，因为开发人手不够，所以任务只有少数人清楚。
4. 是否项目的整个过程都按照计划进行?
不是，项目中途有很多突发状况，出现很多次人手不足的情况，导致后来一直要赶进度。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，还是有一定作用的，缓解了一部分人员短缺和突发状况的问题，但是不能从根本上解决问题。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将开发工程师人数提升到4人。分别负责2名前端，1名后端，1名UI界面。测试由工作量较小者完成
资源
- 我们有足够的资源来完成各项任务么?
人力资源不够充足。
完成任务的学习资料很充足。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
由于第一轮人手不足，所以开发人员压力比较大，没有很细致的考虑资源分配和任务分配的问题，所以也谈不上精度如何。只是在有限时间内，每个人能做多少就做多少。
- 用户测试的时间，人力和软件/硬件资源是否足够?
在百度开发者平台发布时，留有开发者联系方式。至今为止没有用户联系过我们。但是身边的同学在使用过我们的Agenda Manager之后，提出了一些建议。
人力资源自然是不够的。
软件和硬件资源充足。
- 你有没有感到你做的事情可以让别人来做（更有效率）?
本来人手就不足，基本是每个人的利用率最大化了，所以基本没有人可以代替别人完成任务。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
不是。在更换PM的时候，前一位PM没有及时的得到消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据功能的优先级即重要程度来确定，将一些次重要的功能留给下一个阶段实现。
- 项目的出口条件（Exit Criteria）是否得到清晰的定义?
是的，如下：
（1）、注册新用户并登录
（2）、通过ID添加好友
（3）、创建群组
（4）、邀请好友进入群组
（5）、被邀请的好友选择接受或拒绝
（6）、创建群组的用户在本地创建好日程提醒
（7）、可以创建多个日程
（8）、将日程提醒推送给群组内每个人
（9）、组内用户收到推送后选择接受或拒绝
（10）、某个用户拒绝后，创建者收到反馈。
（11）、日程提醒的时间格式应为: year – month – hour - minute
（12）、创建日程提醒的人可以手动修改或删除该日程的任意信息。
（13）、日程提醒过后，可自动删除该项
（14）、实现自动登录，即在退出后的短时间内，无需再次通过用户名和密码登录。
（15）、到设定好的日程提醒时间后，完成弹窗震动或响铃提醒。
（16）、重启后，原有日程提醒不失效。
4. 对于可能的变更是否能制定应急计划?
目前采用的是较简单的顶替做法，没有系统地制定应急方案。
5. 员工是否能够有效地处理意料之外的工作请求？
能。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作由主力开发人员完成，都在M1前期完成。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
经常碰到，大部分是由具体执行的人自己解决，如果问题比较严重，就会拿出来和其他组员进行讨论，再由核心成员一起制定解决方案。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
M1阶段没有进行单元测试。
4. 什么功能产生的Bug最多，为什么？
闹钟提醒功能BUG最多。
因为开发人员对于Android的广播、注册机制了解不够透彻。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
开发进度一直很拖，最后没有进行代码复审。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
团队有明确的测试计划。
2. 是否进行了正式的验收测试？
是。在Android 内测版完成编码后，由本队的测试员进行了全方位的测试。
3. 团队是否有测试工具来帮助测试？
由于是移动端的App，所以仅需进行使用测试。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
在M1阶段，我们仅进行了使用测试。
5. 在发布的过程中发现了哪些意外问题？
由于是第一次发布产品，所以有很多需要严格执行的程序。比如要有独立版权的App图标，并且图标必须是512X512高清图；有登录功能的产品需要提供测试账号、测试密码等。
1) 对比敏捷的原则，你觉得你们小组做得最好的是什么？
- 保持简明，尽可能简化工作量。任何还没有明确的工作都会花不可知的时间，因此在计划中时刻最大化未完成的工作量，不把那些还没有做的工作和正在做的工作混起来。
- 敏捷流程中保持可持续的开发速度。不论目前手头的事有多少，总能在一个长期恒定的开发速度中完成任务，因此中间的一些突发状况也能较好地应对过去。
- 注重需求，把客户当做团队的一部分，时刻注意新的需求的产生，并制定实现的新方案。
2) 什么是在下个阶段 M2 要改进的地方？越具体越好。
- 我们认识到了具备一位统揽全局的PM之重要，在第二轮我们将任命一名专职的PM，以掌控全局。
- 改善整体的团队成员分配，我们需要在第二轮迭代中引进一位能够编写代码的同学，这样我们就有了4位主力进行开发。此举能够大大加快我们的进度。解决我们码力不足的尴尬境地。
- 提高全体成员的积极性。这对我们而言是不简单的工作，因为我们还同时有编译原理和数据库作业，所以一定要拿出成果，及时播报成果，让队伍有了成就感，就自然有了团队的向心力。这个任务交给黄上，由他来带动整体的气氛。
- 重构代码，整合Bmob提供的API。
- 严格执行绩效制度，想要得分就一定要对团队有正贡献。用以防止我们出现人手不足的这种情况，让所有的同学能够加入到开发过程中来。每次的任务都有任务点(Mission Point)来标记，最后将按照任务的权重来分配分数。
