团队成员：
需求分析：
需求分析采用NABCD模型。
N：（Need，需求）
需求一：事件管理。包括事件的添加、修改和删除，同时提供多种方式查询事件。
需求二：提醒功能。添加事件的同时可以设置事件的提醒时间、提醒方式。
需求三：完成项记录。对已经完成的事件自动生成记录方便用户查看。
需求四：其他功能。语音录入、换肤和锁定悬浮通知等。
A（Approach，做法）
1） 对于app的开发，我们选择了Hbudlier作为平台；
2） 界面设计模仿小米备忘录和“Nota”。
3）确定好方向和开发语言，分配队员分工，开始工作。
4） 先做出基本功能，再不断完善。
B（Benefit，好处）
随时随地记录自己的计划和时间安排。页面简洁，人性化。
C（Competitors，竞争）
没想过竞争，自娱自乐。
D（Delivery，推广）
可以向亲戚好友同学们推广。
原型系统
主页面：
横拉菜单：
添加事件：
PSP表格：
| 预计耗时（分钟） | 实际耗时（分钟） | ||
| Planning | 计划 | 2 | 2 |
| Estimate | 估计这个任务需要多少时间 | 2 | 2 |
| Development | 开发 | 20 | 40 |
| Analysis | 需求分析 | 10 | 10 |
| Design Spec | 生成设计文档 | 0 | 0 |
| Design Review | 设计复审（和同事审核设计文档） | 0 | 0 |
| Coding Standerd | 代码规范（为目前的开发制定合适的规范） | 0 | 0 |
| Design | 具体设计 | 10 | 30 |
| Coding | 具体编码 | 0 | 0 |
| Code Review | 代码复审 | 0 | 0 |
| Text | 测试（自测，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 10 | 15 |
| Text Report | 测试报告 | 8 | 14 |
| Size Measurement | 计算工作量 | 2 | 1 |
| Postmortem & Process Improvement Plan | 事后总结，并提出过程改进计划 | 0 | 0 |
| Sum | 合计 | 32 | 57 |
心得总结：
合作是件愉快的事情，比自己一个人轻松许多，开心。