确定选题
1.确定团队选题
微信记账小程序
2.系统详细描述
该系统是主要基于微信小程序，面向用户主要是大学生群体，系统的主体功能是可记录个人每天的收入开支，并提供各种模块的记账（例如旅行记账、装修记账等），以扇形图和曲线图展现每个月的收入开支情况走向。具体做法：用户只需在小程序中搜索“记账小程序”或扫描相应二维码即可进入随手记多人记账页面，随时随地记录收支。
3.给出预期的用户数量
12个人
4.阐述系统的：真实性、可用性 以及价值所在
1）真实性：现在的大学生人手一部手机，手机上都会安装微信程序，微信小程序近几年来很热门，我们要设计的这款程序也是基于微信平台实现的微信小程序，不占内存，直接打开微信就能使用，是真实可靠可实现的一款记账程序。
2）可用性：要使用这个记账小程序，只打开微信搜索程序名称，点击程序就能开始使用。用户选择要记账的类型模块，再记录收入开支，程序每个月统计数据，生成扇形图或曲线图告诉用户这个月的收入和花销的走向。
3）价值所在：经常有些同学抱怨说怎么这个月也没买什么，正常的衣食住行，怎么月末还没到钱又花光了，不仅花光还透支，下个月吃土还花呗，每逢双十一双十二，一边高喊再喊再买就剁手，一边还是忍不住买买买，买完没记账或者手写记了几次账嫌麻烦就不记了，所以都忘记了自己把钱花到了哪些地方。而我们要设计的记账小程序可方便用户不用再手写记账，也不用另外下载app占内存，只要打开微信就能使用，并且还分不同的模块，例如去旅游可用旅游记账模块。
NABCD分析：
- Need（需求）
很多大学生觉得记账是一件麻烦的事，懒得去记录自己的每个月的消费情况，但是又会抱怨自己不知道把钱到花到哪里，从而无法很好的了解自己的财务情况。所以，我们团队要做的就是设计一款可用手机记账的小程序。通过简便的记账方式，促进用户记账的积极性及兴趣，让大学生了解自己的消费情况，从而有效控制花费，并计划消费。
- Approach（方法）
我们团队本身就是一个由大学生组织起来的团队，因此会比较了解大学生群体的生活习惯，而且推广程序的途径也比较多。我们设计的记账程序主要特色是分模块，不仅有分衣食住行，还有分旅行、家庭、班级模块等等，以及除了个人的记账，还可以用于班级的开销记账，班级的生活委员可用这款软件清晰的记录班级消费情况。记录的同时，用户还可以备注商家信息等等。每次软件更新保护用户的数据不丢失，界面简洁，不同用户可根据自己爱好选择皮肤。程序除了能统计每个月的开销，还可设置预算下个月的开销。
- Benefits （收益）
1.帮用户记录每天的收入与开销。 2.设置每个月预算，月末查看总开销，可控制用户每个月的开支。 3.提醒用户不要挥金如土。 4.可为了将来要去旅行或买心心念念的东西做一个省钱计划。
- Competition (竞争) —对于竞争对手和其他可选择的方案来说，这种单位成本收益的优势在哪里？
不用另外下载软件直接基于微信平台，方便简洁不占内存；我们的软件是针对大学生群体，我们就是用户本身，直接可进行对软件的测试，制作的产品功能更能从用户的实际需求和体验的角度出发；身边也都是大学生群体，可以询问身边人对这个软件的建议和想法。
- Deliver（推广）。
可直接通过微信推广，将程序连接发到各种班级群或者初高中同学群，也可以通过社团等等推广程序。
5.给出团队项目的码云链接
https://gitee.com/carolfantasy/team_programming__accounting_small_program.git
制定团队计划
1.将团队的任务计划添加到码云的团队项目issues里面（博客中提供码云的团队项目issues截图）
2.给出团队项目的时间安排表
- 矫正公式：Y=X+-X/N
- Y是实际时间花费，X是对于某件事的估计时间， 中间的+-表明加上，或者减去，N是做过类似开发工作的次数
| 时间 | 任务 | 预期时间 | 矫正时间 |
|---|---|---|---|
| 第 6-7 周 | 1. 制定团队计划 | 1天 | 1.5天 |
| 2. 需求规格说明书 | 3天 | 3天 | |
| 3. 原型设计，队员估计任务难度并学习必要的技术 | 5天 | 5.5天 | |
| 4. 编码规范完成、平台环境搭建完成、初步架构搭建 | 2天 | 2天 | |
| 5. 架构设计，WBS, 团队成员估计各自任务所需时间 | 1天 | 0.5天 | |
| 6. 测试计划制定 | 1天 | 1.5天 | |
| 第8-9周 | 1. 团队项目Alpha任务分配计划 | 1天 | 1天 |
| 2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | 10天 | 11天 | |
| 第10周 | 1. 用户反馈+测试计划改进 | 2天 | 2天 |
| 2. 团队Alpha阶段个人总结 | 1天 | 1天 | |
| 3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 | 4天 | 4天 | |
| 第11周 | 1. 项目复审 | 3天 | 2.5天 |
| 2. 团队项目Alpha博客：事后分析 | 3天 | 3.5天 | |
| 3. 每个团队有一人必须离开，自己寻找下一个接纳自己的团队。团队发博客宣布离队和接纳的成员。 | 1天 | 1天 | |
| 第12-13周 | 1. 团队项目Beta任务分配计划，介绍新成员 | 1天 | 1天 |
| 2. 连续7天的Beta敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | 13天 | 13天 | |
| 第14周 | 1. 团队项目Beta博客：发布说明、测试报告、展示博客 | 6天 | 6天 |
| 2. 团队Beta阶段个人总结 | 1天 | 1天 | |
| 第15周 | 1. 项目复审 | 6天 | 6天 |
| 2. 团队项目Beta博客：事后分析， 宣布每人的贡献分 | 1天 | 1天 | |
| 第16周 | 1. 团队整个阶段总结，分析用户数据，整理文档，保证以后的团队能接手。 | 7天 | 7天 |
团队的分工
| 姓名 | 分工 |
|---|---|
| 邱晓娴 | 开发 |
| 张晨晨 | 美工 |
| 黄登峰 | 测试 |
| 陈凯欣 | 开发 |
| 何雨柔 | PM |
每个人完成的情况
| 姓名 | 完成的任务 | 完成情况 |
|---|---|---|
| 邱晓娴 | 需求规格说明书 part2 | %65 |
| 学习必要的技术 | %10 | |
| 平台环境搭建 | %0 | |
| 张晨晨 | 需求规格说明书 part3 | %70 |
| 学习必要的技术 | %10 | |
| 平台环境搭建 | %0 | |
| 黄登峰 | 需求规格说明书 part1 | %100 |
| 制定测试计划 | %10 | |
| 陈凯欣 | 制定编码规范 | %0 |
| 学习必要的技术 | %10 | |
| 平台环境搭建 | %0 | |
| 何雨柔 | 制定团队计划 | %100 |
| 架构设计 | %0 |
每个人的感想
陈凯欣：团队合作最需要沟通交流，在时间安排方面由于我们第一次做这种团队合作项目，其实对时间的拿捏应该会有偏差，不仅要讨论还要参考前人经验。至于每个人的分工，组长和PM都能把每人的任务分配清楚，接下来就要把自己的任务做好，并配合其他人一起工作。
邱晓娴：需求分析是很关键的一个步骤，决定开发产品的起点高度。这周我们团队搜集了关于同款微信记账小程序和app，参考同类产品完成的功能和特色，初步确定了我们产品需要完成的功能，PM也大致分配了每个人的任务。在接下来的几周，我相信我们团队能够齐心协力、共同进步。
何雨柔：在本次团队合作中我主要担任的是PM的角色，要考虑到产品的各方面，还要考虑到团队每个人的分工情况。产品的功能也要切实的贴合我们组成员的开发能力，不能过于复杂而导致成员开发很困难，也不能过于简单凸显不出我们团队产品的特色和成员的开发能力。还要协调各个角色之间的关系，让本次团队合作圆满完成。是一次挑战，也是一次锻炼。
黄登峰：这次组成了一个团队，我认为团队的合作精神非常重要。在这次的团队中，我担任测试的角色，主要就是在产品大概完成时，开始找错，纠错的任务。团队合理的分工与合作可以大大提高团队的效率，我希望我们的团队也能如此。
张晨晨：之前尝试了结对编程，感受了1+1>2，这次的团队也是一样，但是这次分工更明确，然后我觉得团队在这个过程中交流很重要，虽然是分工合作，但是交换有用的信息，互帮互助会很好的增加效率！
