Deadline：

2017-12-10 23:00PM，以博客发表日期为准。

 

评分基准:

• 按时交 - 有分，检查的项目包括后文的三个方面

• 冲刺计划安排（单独1篇博客）

• 七天的敏捷冲刺（每两天发布1篇，共3篇博客）

• 源代码管理

 

晚交 - 0分

迟交一周以上 - 倒扣本次作业分数

抄袭 - 倒扣本次作业分数

 

Beta版本冲刺

 

经过紧张的Alpha阶段，很多组已经从完全不熟悉语言和环境，到现在能够实现初步的功能。下一阶段即将加快编码进度，完成系统功能、强化软件工程的体会。

1. 凡事预则立，在Beta开始前，以小组为单位，在敏捷冲刺前发布一篇博客，描述：         

• 需要改进的团队分工（针对之前的不足，需要加强和改进团队协作和分工的地方）

• 需要改进的工具流程（如版本控制、测试工具等），alpha 阶段用纸和笔做燃尽图的，必须升级到使用软件工具管理燃尽图。

• 冲刺的时间计划安排（冲刺时间为期七天，安排在2017.12.4——2017.12.10之间）

• 参考链接：

             设计变更（DCR）：参考课本第15章有关内容 

 

2. Beta阶段的冲刺时间为期七天，安排在2017.12.4——2017.12.10之间。

• 安排连续七天的敏捷冲刺。

• 每两天举行站立式会议，讨论项目每个成员的进展、存在问题、接下来两天的安排。

• 团队在冲刺的七天内，每两天天发布一篇随笔，共三篇：

           a. 提供当天站立式会议照片一张； 

           b. 每个人的工作 （有work item 的ID）：

• •   已完成的工作；
  •   接下来两天计划完成的工作； 
  •   工作中遇到的困难；  
  •   每个人的贡献比

3. 发布项目燃尽图；请用专业的工具完成。

4. 每人的代码/文档签入记录；

• 不能每天都在 “研讨”， 但是没有代码签入。

• 签入记录对应的Issue内容与链接，代码必须每天可执行。

• 必要的code review，编码规范不是摆设，文档要随时更新。

• 采用Coding实现版本控制和协同化编程

• 适当的项目程序／模块的最新（运行）截图。

3. 如果你的项目是有价值的，很有可能别的团队会继续开发。  到时候会不会出现源代码找不到、没有文档等尴尬的情况呢？ 团队要考虑如何进行高效的源代码管理，请在beta 进行的过程中试着回答关于源代码管理的10 个问题： 

 

参考链接