Deadline：2017-11-06（周一） 21:00pm
0、评分规则:
按时交 - 有分，内容包括以下5个方面：
- Beta阶段敏捷冲刺每日报告 - 30分
- Beta版本测试报告 - 30分
- Beta版本发布说明 - 10分
- Beta展示博客 - 20分
- Beta阶段总结报告 - 20分
- Beta阶段项目复审 - 20分
注意事项：
- 晚交 - 0分
- 迟交两周以上 - 倒扣本次作业分数
- 抄袭 - 倒扣本次作业分数
1、Beta阶段敏捷冲刺每日报告 (30分)
经过紧张的Alpha阶段，很多组已经从完全不熟悉语言和环境，到现在能够实现初步的功能。下一阶段即将加快编码进度，完成系统功能、强化软件工程的体会。
- 凡事预则立，在Beta开始前，以小组为单位，在敏捷冲刺前（11月1日 周三）发布一篇博客，描述 (5分)：
- 下一阶段需要改进完善的功能，如果要大规模改变设计，请看DCR 的内容
- 下一阶段新增的功能
- 需要改进的团队分工（针对之前的不足，需要加强和改进团队协作和分工的地方）
- 需要改进的工具流程（如版本控制、测试工具等），alpha 阶段用纸和笔做燃尽图的，必须升级到使用软件工具管理燃尽图。
- 冲刺的时间计划安排（冲刺时间为期5天，安排在2017.11.2——2017.11.6之间）
参考
- 设计变更（DCR）：参考课本第15章有关内容
- http://www.cnblogs.com/yc-chen/p/6129224.html
- Beta阶段的冲刺时间为期5天，安排在2017.11.2——2017.11.6之间。
安排连续5天的敏捷冲刺。每天举行站立式会议，讨论项目每个成员的昨天进展、存在问题、今天安排。团队在冲刺的5天内，每天发布一篇随笔（ 每篇5分）：-
每个人的工作：
(1) 昨天已完成的工作
(2) 今天计划完成的工作
(3) 工作中遇到的困难
(4) 每个人的贡献比
选用合适的工具制作并发布项目燃尽图
-
每人的代码/文档签入记录
(1) 不能每天都在 “研讨”， 但是没有代码签入。
(2) 签入记录对应的Issue内容与链接，代码必须每天可执行。
(3) 必要的code review，编码规范不是摆设，文档要随时更新。
适当的项目程序／模块的最新（运行）截图。
-
参考
- Scrum/sprint http://www.cnblogs.com/xinz/archive/2012/10/05/2712602.html
- 每日例会（scrum meeting）报告。(例子)
- 敏捷项目协作工具 https://www.leangoo.com/
- 如何使用Leangoo自动生成燃尽图 http://www.scrumcn.com/agile/scrum/8569.html
2、Beta版本测试报告 (30分)
请根据团队项目中软件的需求文档、功能说明、系统设计和Beta阶段的计划安排，写出软件的测试过程和测试结果，并回答下述问题。
- 在测试过程中总共发现了多少bug？每个类别的bug分别为多少个？
bug的分类：- 修复的bug；
- 不能重现的bug
- 这个产品就是这样设计的，不是bug；
- 没有能力修复，将来也不打算修复；
- 这个bug的确应该修复，但是没有时间在这个版本修复，延迟到下一个版本修复。
- 场景测试（scenario testing），包括以下内容：
- 你预期不同的用户会怎样使用你的软件？
- 他们有什么需求和目标？
- 你的软件提供的功能怎么组合起来满足他们的需要？
根据不同项目的特点，进行必要的性能测试、压力测试等，并给出测试的过程和结果
你们在什么样的平台、硬件配置、浏览器类型等条件上对你们的软件进行测试？——测试矩阵（test matrix）
你认为你们团队的软件在什么条件下，就可以认定其已经足够好，可以发布Beta版本？——出口条件（exit criteria）
参考：
- 测试的计划及执行： http://www.cnblogs.com/xinz/archive/2011/11/19/2255542.html
- 测试报告实例：http://www.cnblogs.com/buaase/p/5094119.html
3、版本发布说明 (10分)
软件发布的同时，在团队博客上写一个发布说明
- 列出这一版本相对于Alpha版本的新功能
- 列出这一版本对Alpha版本修复的缺陷
- 对运行环境的要求
- 安装方法
- 描述系统已知的问题和限制
- 说明软件的发布方式以及发布地址
对于功能的描述除了文字以外，可以通过图片、视频等进行辅助说明。
参考
- Beta版本发布说明的实例：http://www.cnblogs.com/buaase/p/5094106.html
3、Beta版本展示博客 (20分)
- 团队成员的简介和个人博客地址，团队的源码仓库地址。
-
我们要做软件工程，那就要有一点工程的样子：
团队项目的目标，预期的典型用户，预期的功能描述，预期的用户数量在哪里？
beta 发布之后一定会比alpha 阶段更能满足用户的需求， 请录一段视频， 展现目标用户使用 beta 产品的情况。
团队的成员如何分工协作的？有什么经验教训？
团队是如何进行项目管理的？
团队如何平衡 时间/质量/资源 争取如期完成任务的？
beta 阶段每个团队在软件工程方面有哪些具体改进？(例如 代码测试覆盖率从 x 提高到 y)，也要列出来。
- 团队项目的实际进展（拷贝那些 scrum 过程中的燃尽图即可），发布的功能（拷贝发布文档）。说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？
- 展示建议：把beta阶段每天的会议图片， 燃尽图分别做出一个 GIF 动画， 放在最后的报告中，显示工作的进展。
- 也可以采取其他方式
到了beta， 代码的情况也请列出来， 到底有多少行， 多少文件， 文档在哪里，如果一个新团队要接手这个项目，他们应该怎么做？ 这有说明么？
团队可以用视频显示， 如何在一个全新的电脑上，下载所有代码，构建，发布，并运行你们的程序。
5、Beta阶段总结分析报告 (20分)
请各小组在Deadline之前，召开事后诸葛亮会议，发布一篇事后分析报告。
总结的提纲内容，请参照课本15章内容或邹欣老师的博客：
项目管理之事后诸葛亮会议：http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html
博客要附上全组讨论的照片。
团队成员在Beta阶段的角色和具体贡献：
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 马小哥 | PM | 推广活动 | |
| Phone | Dev | 多少注释 | |
| Pipe | Test | 被修复了 |
6、Beta阶段项目复审 (20分) （ 该部分截止时间：11月13日 21:00 pm ）
每个复审人看本班级其余团队的总结展示博客，以及代码质量，实际测试结果， 决定名次（没有并列），说明项目的优点和缺点分析（不少于 140 字）
（注： 因为需要等其他团队发布Beta阶段完整信息，该部分内容可以等到11月13日和个人作业一起提交）
- 谁来做复审人：可以每个团队选一个本团队的代表，或者团队成员一起开评审会讨论决定
- 团队博客列出团队的排名（没有并列），和对这些团队的点评（不包括本团队）
- 复审看什么：
- 软件的质量：解决原计划解决的问题了么，软件运行质量如何？用户有多少，用户反馈如何？
- 软件工程的质量：代码在哪里？ 代码能在新的机器上构建成功么？ 代码可维护性如何？每日构建有么？
- 项目如何管理的？燃尽图反映真实状态么？老师和助教的点评有回答或改进么？
- 复审怎么做：
- 通过看博客和代码，博客评论交流的方式平均并排名次。 大家都是学过软件工程，做过项目的人了，评论要有点专业性，不能光谈感性认识 （这个小组做的App 看起来还可以...), 而是要点评这个产品和软件工程相关的地方，书上提到下面的公式：
- 软件 = 程序 + 软件工程
- 软件（的质量） = 程序（的质量）+ 软件工程（的质量）
- 我们要好好测试一下程序的质量，给出明确的，定量的评定。同时我们要观察这个小组软件工程的质量（通过他们的每日例会，燃尽图，以及其它博客）点评他们项目的目标实现了么？项目的风险是如何应对的？找到用户的痛点并解决了么？ 对主要和次要的需求是如何取舍的？如果换成我来领导这个小组，我会做什么不一样的事情？
- 通过看博客和代码，博客评论交流的方式平均并排名次。 大家都是学过软件工程，做过项目的人了，评论要有点专业性，不能光谈感性认识 （这个小组做的App 看起来还可以...), 而是要点评这个产品和软件工程相关的地方，书上提到下面的公式：
| 小组的名字和链接 | 优点 | 缺点，bug报告（至少140字） | 最终名次（无并列） |
|---|---|---|---|
| team1 | ...... |
程序有什么具体的bug？ 项目的目标实现了么？ 项目的风险是如何应对的？ 找到用户的痛点并解决了么？ 对主要和次要的需求是如何取舍的？ 源代码管理如何？ 如果换成我来领导这个小组，我会做什么不一样的事情？ ...... |
|
| team2 | ...... | ...... |