Deadline：##
2017-11-11 10:00PM，以博客发表日期为准。
评分基准:##
- 按时交 - 有分（需求&原型改进与系统设计-10分，敏捷冲刺-70分），检查的项目包括后文的三个方面
- 需求&原型改进与系统设计（基本分5分，根据完成质量加分，原则上不超过满分10分）
- 七天的敏捷冲刺（每篇基本分5分，根据完成质量加分，原则上不超过满分10分）
- 日志的集合贴
- 晚交 - 0分
- 迟交两周以上 - 倒扣本次作业分数
- 抄袭 - 倒扣本次作业分数
Task1：需求&原型改进与系统设计##
-
给目标用户展现原型，与目标用户进一步沟通理解需求。
a. 思考：他们的痛是什么？场景是什么？（用产品之前/之后，有照片或视频显示用户调查的过程，使用了各种调查手段的，加分）
b. 参考：
- -《构建之法》第10章典型用户和场景
- http://www.cnblogs.com/xinz/archive/2011/10/30/2229236.html
- 阿里巴巴卫哲：http://iamsujie.com/8000/8018/
-
修改完善上周提交的需求规格说明书。
a. 上周的《需求规格说明书》初稿有哪些不足？特别是：功能考虑不全或需求文档描述缺少的地方。
b. 将具体改进内容发布在随笔上。
c. 建议：用一个场景，像讲故事 （User Story）那样，描述用户怎么使用几个相联系的功能，解决了用户的问题。
-
参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限。
-
任务分解WBS
一个团队项目要在一段时间内完成诸多任务，满足用户需求，实现团队目标，从哪里入手？
WBS（Work Breakdown Structure）即工作分解结构，是根据项目目标把工作分解成许多层次分明的、可交付成果的工作任务，然后用逻辑图形或树形结构表示出来。a. 请给出团队项目的WBS；
b. 团队成员估计各自任务所需时间
-
在设计阶段，我们要清楚：软件是怎么解决这些需求的？
一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。- 如何才能最大限度地实现这些需求，这就是架构设计要解决的问题。请给出系统的架构设计
- 完成团队项目的数据库设计，并在随笔中提供相应ER图（如果必要）
参考实例：
- http://www.cnblogs.com/bugphobia/p/4946840.html
- http://www.cnblogs.com/bugphobia/p/4946844.html
- http://www.cnblogs.com/bugphobia/p/4946849.html
分析设计方法：http://www.cnblogs.com/xinz/p/4525232.html
Task2：7天敏捷冲刺##
召开的迭代计划会议，阅读或再次阅读《构建之法》第六章内容，为项目冲刺的安排和问题提供助力。
-
在2周的时间内，安排七天的敏捷冲刺（可根据实际安排）。
a. 每天举行站立式会议，讨论项目每个成员的昨天进展、存在问题、今天安排。
b. 控制站立式的时间，不宜过长。
c. 站立式会议的目的是有效沟通项目的进度、问题、计划、调整。
-
团队在冲刺的2周内，选择7天每天发布一篇随笔，共七篇：
a. 每个人的工作 （有work item 的ID）：
- - 昨天已完成的工作。
- 今天计划完成的工作。
- 工作中遇到的困难。
b. 发布项目燃尽图；
- - 请理解燃尽图横坐标和纵坐标指的是什么。
- 请理解燃尽图实线和虚线分别代表什么。
- 结合《构建之法》里的“项目收敛”相关内容理解燃尽图的作用。
- 燃尽图可以用手画， 可以用excel， 可以用自己选择的工具或者leangoo
c. 每人的代码/文档签入记录：
- - 不能每天都在 “研讨”， 但是没有代码签入。
- 签入记录对应的Issue内容与链接，代码必须每天可执行。
- 必要的code review，编码规范不是摆设，文档要随时更新。
d. 适当的项目程序／模块的最新（运行）截图。
-
在本次任务过程中，团队要有一篇单独的随笔置顶，集中记录所有敏捷冲刺日志的集合贴，方便统计。
参考链接：##
- Scrum/sprint http://www.cnblogs.com/xinz/archive/2012/10/05/2712602.html
- 每日例会（scrum meeting）报告。(例子)
- 敏捷项目协作工具