敏捷冲刺(Beta版本)

评分基准:##

  • 按时交 - 有分(计划安排-10分,敏捷冲刺-70分),检查的项目包括后文的三个个方面
    • 冲刺计划安排(单独1篇博客,基本分5分,根据完成质量加分,原则上不超过满分10分)
    • 七天的敏捷冲刺(每天发布1篇,共7篇博客,每篇基本分5分,根据完成质量加分,原则上不超过满分10分)
    • 源代码管理 (附加题,满分10分)
  • 晚交 - 0分
  • 迟交一周以上 - 倒扣本次作业分数
  • 抄袭 - 倒扣本次作业分数

Beta版本冲刺##

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

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

    a. 下一阶段需要改进完善的功能,如果要大规模改变设计,请看DCR 的内容。

    b. 下一阶段新增的功能

    c. 需要改进的团队分工(针对之前的不足,需要加强和改进团队协作和分工的地方)

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

    e. 冲刺的时间计划安排(冲刺时间为期七天,安排在2017.11.26——2017.12.9之间)

    参考

  2. Beta阶段的冲刺时间为期七天,安排在2017.11.26——2017.12.9之间。

    a. 安排七天的敏捷冲刺。

    b. 每天举行站立式会议,讨论项目每个成员的昨天进展、存在问题、今天安排。

    c. 团队在冲刺的七天内,每天发布一篇随笔,共七篇:

      i. 每个人的工作 (有work item 的ID)
        (1) 昨天已完成的工作;
        (2) 今天计划完成的工作;
        (3) 工作中遇到的困难;
        (4) 每个人的贡献比

      ii. 发布项目燃尽图;请用专业的工具完成
      iii. 每人的代码/文档签入记录;
        (1) 不能每天都在 “研讨”, 但是没有代码签入。
        (2) 签入记录对应的Issue内容与链接,代码必须每天可执行。
        (3) 必要的code review,编码规范不是摆设,文档要随时更新。
        (4) 采用码云实现版本控制和协同化编程

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

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

参考链接:##

原文地址:https://www.cnblogs.com/happyzm/p/7871112.html