团队作业7——第二次项目冲刺(Beta版本)

Deadline
2017-12-10 23:00PM,以博客发表日期为准。
 
评分基准:
  • 按时交 - 有分,检查的项目包括后文的三个方面
  • 冲刺计划安排(单独1篇博客)
  • 七天的敏捷冲刺(每两天发布1篇,共3篇博客)
  • 源代码管理

 

晚交 - 0分

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

抄袭 - 倒扣本次作业分数

 
Beta版本冲刺
 
经过紧张的Alpha阶段,很多组已经从完全不熟悉语言和环境,到现在能够实现初步的功能。下一阶段即将加快编码进度,完成系统功能、强化软件工程的体会。
  1. 凡事预则立,在Beta开始前,以小组为单位,在敏捷冲刺前发布一篇博客,描述:         
  • 需要改进的团队分工(针对之前的不足,需要加强和改进团队协作和分工的地方)

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

  • 冲刺的时间计划安排(冲刺时间为期七天,安排在2017.12.4——2017.12.10之间)

  • 参考链接:

             设计变更(DCR):参考课本第15章有关内容 http://www.cnblogs.com/yc-chen/p/6129224.html

 
  1. Beta阶段的冲刺时间为期七天,安排在2017.12.4——2017.12.10之间。
  • 安排连续七天的敏捷冲刺。
  • 每两天举行站立式会议,讨论项目每个成员的进展、存在问题、接下来两天的安排。
  • 团队在冲刺的七天内,每两天天发布一篇随笔,共三篇:

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

           b. 每个人的工作 (有work item 的ID):

    •   已完成的工作;
    •   接下来两天计划完成的工作; 
    •   工作中遇到的困难;  
    •   每个人的贡献比
  1. 发布项目燃尽图;请用专业的工具完成。
  1. 每人的代码/文档签入记录;
  • 不能每天都在 “研讨”, 但是没有代码签入。

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

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

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

  • 适当的项目程序/模块的最新(运行)截图。

  1. 如果你的项目是有价值的,很有可能别的团队会继续开发。  到时候会不会出现源代码找不到、没有文档等尴尬的情况呢? 团队要考虑如何进行高效的源代码管理,请在beta 进行的过程中试着回答关于源代码管理的10 个问题: http://www.cnblogs.com/xinz/p/5044037.html  
 
参考链接
 
 
 
posted @ 2017-12-03 20:32  黄巧玲  阅读(212)  评论(0编辑  收藏  举报