团队作业——Alpha冲刺

团队作业——Alpha冲刺

时间安排及内容要求

时间 内容
11.1-11.16 12次 Scrum
11.16-11.20 测试报告 与 用户反馈
11.21-11.24 展示博客
11.25 课堂展示
11.25-11.28 事后诸葛亮

1. 冲刺(12次 Scrum)

团队在日期区间[11.1,11.16]内,任选12天进行冲刺,冲刺当天晚10点前发布一篇随笔,共十二篇。具体的博文规范如下:

1)第 1 篇 Scrum 冲刺博客对整个冲刺阶段起到领航作用,应该主要包含四个部分的内容:

  • 各个成员在 Alpha 阶段认领的任务
  • 明日各个成员的任务安排
  • 整个项目预期的任务量(使用整数表示,与项目预估的总工作小时数一致。比如项目A预估需120小时才能完成,则任务量为120。)
  • 团队成员贡献值的计算规则

2)第 2-11 篇 Scrum 冲刺博客是冲刺阶段的主要产出,主要包含四个部分的内容:

  • 各个成员今日完成的任务(如果完成的任务为开发或测试任务,需给出对应的Github代码签入记录截图;如果完成的任务为调研任务,需给出对应的调研总结博客链接;如果完成的任务为学习技术任务,需给出学习总结博客链接)
  • 各个成员遇到的问题
  • 明日各个成员的任务安排
  • 各个成员今日对项目的贡献量(使用整数表示,如无产出则为0,整个冲刺阶段所有成员的贡献量总和应与项目预期任务量相近

3)第 12 篇 Scrum 冲刺是对冲刺阶段的总结,主要包含两个部分的内容:

  • 各个成员今日完成的任务(要求同上)
  • 项目的发布说明,主要包含:本版本的新功能软件对运行环境的要求系统已知的问题和限制软件的发布方式以及发布地址

除上述博客内容外,每次 Scrum 冲刺博客都需要提供当天站立式会议照片一张,发布项目燃尽图,并描述项目整体的进展情况。

参考博客:

2. 测试报告 与 用户反馈

各个团队的项目已经发布了,那么它是不是如各个团队预期的一样能受到大量用户的青睐呢?如果有了真实的用户,团队要如何保证软件在用户试用的时候不崩溃呢?为了改进项目与保障软件的可靠性,团队需利用[11.16,11.20] 这段时间完成两个任务:
1)发布一篇项目的测试报告,内容包括如下几个方面:

  • 团队项目软件的总体测试计划,记录测试过程,给出测试结果,并说明这些测试怎样对软件的质量提供保障?
  • 在测试过程中发现了多少Bug?将Bug在任务管理系统中进行记录,修复Bug的任务也需要计入燃尽图的统计。
  • 给出场景测试(scenario testing):各个团队在需求规格说明书中都设想了许多用户场景,你们的软件是否满足了他们的需求,怎样组合功能来满足他们的需要?
  • 给出测试矩阵(test matrix):在什么样的平台、硬件配置、浏览器类型……上对你的软件进行测试?(App需考虑多种机型,Web需考虑多种浏览器)
  • 对关键模块进行性能测试(performance testing):对核心的模块进行必要的性能测试与压力测试,并说明软件在怎样的服务器配置下可以承担最高多少的并发量?

2)发布一篇项目的用户反馈博客,内容包括如下几个方面:

  • 项目的下载量/使用量,日常活跃的用户(Web可以使用统计插件,App可以使用埋点)
  • 用户反馈了多少Bug?你们在收到反馈后是如何处理的?
  • 用户给项目提出了哪些建议,哪些建议是打算纳入Beta 阶段开发中的?

参考博客:

3. 展示博客

发布一篇Alpha版本项目展示博客,包括如下内容:

  • 成员简介:团队成员简介与对应的个人博客地址。
  • 演示动态图:为避免现场演示翻车,各个团队需要给出项目各个功能点运行的gif图
  • 预期用户量:预期的典型用户,预期的功能描述,预期的用户数量在哪里? 事先定义的软件下载量达到了么?为什么没有达到?
  • 目标用户视频或介绍:团队的产品如何满足了用户的需求?要看到目标用户使用产品的过程和评价 (视频或者活人上台介绍) ?
  • 分工协作:团队的成员如何分工协作的?有什么经验教训?
  • 项目管理:团队是如何进行项目管理的,如何平衡 时间/质量/资源 争取如期完成任务的?
  • 质量控制:在产品之外,团队代码的软件工程质量如何?如何用数据来证明?比如测试用例数目,代码覆盖率数目等。
  • 成员角色与贡献:团队成员在 Alpha 阶段的角色和具体贡献。
  • 用户反馈:团队从用户那里得到了什么反馈,有什么样的bug?这是预料之中的还是没想到的?

4. 课堂展示

各组需带各自电脑并调试好相关应用,方便于课堂演示,每组限时15分钟。若APP可采用xx手机助手协助演示。

5. 事后诸葛亮

Alpha冲刺,很多同学经历了“Learning by doing”的学一门新的编程语言、学Git、学做一个完整的项目。但是,各组对于软件工程的“Learning by doing”的意涵了解的还不深刻,遇到的问题也不少。停一停,开个总结会,来次事后诸葛亮,为了下一步走的更好。以小组为单位发布一篇针对问题的总结。

事后诸葛亮博客主要包括如下内容:

  • 项目的预期计划
  • 项目的现实进展
  • 完成项目过程中的体会
  • 团队成员的分工及在Alpha阶段的工作量比例
  • 下阶段展望与团队总结,团队总结提纲可参照邹欣老师的博客

注意事项

1、在本次任务过程中,团队要有一篇单独的随笔置顶,集中记录所有敏捷冲刺日志、测试报告、展示博客、事后诸葛亮博客的链接集合贴方便助教统计,作业提交该篇博客即可。

2、要求人人编码(除了PM可能有出入)、人人Git——否则本次作业全组不得分。

3、要求要有完善的单元测试及详细记录。——否则本次作业全组不得分。

友情提示
Alpha版本周期将近一个月,大家要合理安排节奏,虎头蛇尾或者临时抱佛脚都不是好的节奏。

posted @ 2017-10-29 01:01  福大软工和面向对象  阅读(658)  评论(0编辑  收藏  举报