Task1：需求&原型改进与系统设计
- 给目标用户展现原型，与目标用户进一步沟通理解需求。
通过沟通，了解到用户的痛处在于身体与精神上为病魔等因素的极大摧残，又困于种种原因难以及时获得请假批准，以至学习与精神上收到强大损失。 上周的《需求规格说明书》初稿的不足之处
上周由于对用例图和流程图的了解认识不够正确，导致在作图与考虑用户关系上有所偏差，流程图上，没有认真思考，导致功能方面的设计也有所不足。
此外改进了产品功能和约束和依赖的关系。且增加了多种应用实例，相比之前只有一种应用实例来得更全面。下面给出一个实例截图。
- 任务分解WBS
分解模块功能如下
大致分工如下：
- 永鑫大佬，艺祥大佬，黄壘大佬：数据库的选择和使用，数据库和程序的联系。
- 东东大佬，子琦大佬：安卓端的学习和代码的编写。
- mok：信息的记录和博文的编写。
系统的用例图设计
- 系统的构架设计
完成团队项目的数据库设计，并在随笔中提供相应ER图
Task2：7天敏捷冲刺
在2周的时间内，安排七天的敏捷冲刺（可根据实际安排）。
a. 每天举行站立式会议，讨论项目每个成员的昨天进展、存在问题、今天安排。
b. 控制站立式的时间，不宜过长。
c. 站立式会议的目的是有效沟通项目的进度、问题、计划、调整。
团队在冲刺的2周内，选择7天每天发布一篇随笔，共七篇：
a. 每个人的工作 （有work item 的ID）：
昨天已完成的工作。
今天计划完成的工作。
工作中遇到的困难。
b. 发布项目燃尽图；
请理解燃尽图横坐标和纵坐标指的是什么。
请理解燃尽图实线和虚线分别代表什么。
结合《构建之法》里的“项目收敛”相关内容理解燃尽图的作用。
- 燃尽图可以用手画， 可以用excel， 可以用自己选择的工具或者
leangoo
c. 每人的代码/文档签入记录：
不能每天都在 “研讨”， 但是没有代码签入。
签入记录对应的Issue内容与链接，代码必须每天可执行。
必要的code review，编码规范不是摆设，文档要随时更新。
d. 适当的项目程序／模块的最新（运行）截图。