题目
团队作业3成绩
团队/分值 | TD | BZ | GJ | CJ | SI | WBS | GS | JG | DB | SS | SJ | CS | DC | 总分 |
1 | 0.25 | 0.75 | 1 | 0.5 | 1 | 0.5 | 1 | 1 | 1 | 1 | 1 | 1 | 11 | |
六个核桃 | 1 | 0.25 | 0.75 | 1 | 0.5 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 10 |
NO.NE | 1 | 0.25 | 0.75 | 1 | 0.5 | 1 | 0.25 | 0 | 1 | 0 | 0 | 1 | 1 | 7.75 |
六指神功 | 1 | 0.25 | 0.75 | 0.5 | 0.5 | 1 | 0.25 | 0 | 0.5 | 1 | 0 | 1 | 0 | 6.75 |
wt.dll | 1 | 0.25 | 0 | 1 | 0.5 | 1 | 0.25 | 0.5 | 0 | 1 | 1 | 1 | 1 | 8.5 |
男神组合 | 1 | 0.25 | 0 | 1 | 0 | 0.5 | 0.25 | 0.5 | 0.5 | 1 | 0 | 1 | 0.5 | 6.5 |
总分
团队作业3 评分标准
检查项 | 分值 | 备注 | ||
---|---|---|---|---|
需求&原型改进 | TD | 使用前的场景(痛点) 使用后的场景(痛点的解决) | 1 | 主要回答: 1.客户的问题的场景我们是不是真的找到了? 2.我们为产品设定的使用场景是否真的会发生? 如果找不出有与目标用户沟通的痕迹,比如只是单纯的重复之前说过的用户痛点,可给 0 分或给低分 |
BZ | 描述上次规格说明书不足的地方 | 0.25 | ||
GJ | 规格说明书具体改进的内容发布在随笔上 | 0.75 | ||
CJ | 用户场景描述 | 1 | 以完成某个目的为导向,按顺序描述各个操作步骤得1分。参照《构建之法》P211的例子。 对登陆注册过于详细而主要功能简单扣0.5; 好几项目的混合的用户场景扣0.25分 | |
SI | 功能四象限 | 0.5 | 将登陆和注册放到第一象限的不得分; 最能体现APP竞争力的功能没放在第一象限扣0.25分; 将基本功能放在第一象限扣0.25分; 没有使用四象限表格的形式扣0.25分; | |
WBS | WBS | 1 | 子节点覆盖父节点包含的所有内容 0.5分; 叶子节点的粒度天内能完成0.25分; 按模块划分0.25分; 完全见不到WBS结构的倒扣1分 | |
GS | 各成员估计完成任务需要的时间 | 0.5 | 给出的是这次作业的时间倒扣0.5分; 没有标注成员对应哪个部分扣0.25分; | |
系统设计 | JG | 架构设计 | 1 | 有分层且与项目模块结合0.5; 各种图示建模0.5; |
DB | 数据库设计 | 1 | 表结构 或 ER图 至少要有一个 | |
Alpha任务分配计划 | SS | 以需求分析为主,选择和排序本次迭代需要实现的订单条目 | 1 | 所列任务组合起来不能够使应用达到差不多能用,扣0.25分; 缺少杀手功能的初步实现,扣0.25分; 由于题目没有指明哪种排序方法,不对排序评分; 任务粒度太大扣0.25分; 任务量过少,扣0.25分; 如果描述的不是 Alpha 版本的功能,该项不得分; |
SJ | 以设计为主,确定系统设计方案和工作内容 | 1 | 没有分配任务给团队成员,扣0.25分; 没有描述针对各个任务所要采用的技术方案,扣0.5分 | |
测试计划 | CS | 测试计划 | 1 | |
附加分 | DC | 用户痛点部分使用各种调查方式 | 1 |