敏捷与SCRUM培训测试
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
敏捷与SCRUM 笔试题
姓名:
一、选择题
1.团队成员在执行相关禅道任务的时候,发现需求不明确,应该找谁?
____C_____
A、ScrumMaster
B、部门经理
C、ProcuctOwner
D、团队其他成员
2. 团队成员在执行相关禅道任务的时候,发现需要申请一台测试机,应该找谁?___A______
A、ScrumMaster
B、部门经理
C、ProcuctOwner
D、团队其他成员
3. 团队成员在工作中,对自己的职业规划和技术能力提升产生困惑,应该找谁?
______B___
A、ScrumMaster
B、部门经理
C、ProcuctOwner
D、团队其他成员
4.以下哪些角色不是SCRUM框架中定义的角色_________D_________
A、ScrumMaster
B、部门经理
C、ProductOwner
D、架构师
5. SCRUM框架下,测试工作应该由谁来完成?______D___________
A、ScrumMaster
B、测试部门
C、开发人员
D、团队
6. SCRUM框架下,那个角色对团队的开发效率负责?__________A_______
A、ScrumMaster
B、部门经理
C、ProcuctOwner
D、团队
7. SCRUM框架下,那个角色对软件的交付负责?__________D _______
A、ScrumMaster
B、部门经理
C、ProcuctOwner
D、团队
8. SCRUM框架下,那个角色对软件商业价值负责?________C_________
A、ScrumMaster
B、部门经理
C、ProcuctOwner
D、团队
二、问答题
1.PO创建需求的INVEST原则是什么?
独立性(Independent)—要尽可能的让一个用户故事独立于其他的用户故事。
可协商性(Negotiable)—一个用户故事的内容要是可以协商的,用户故事不是合同。
有价值(Valuable)—每个故事必须对客户具有价值(无论是用户还是购买方)。
可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。
短小(Small)—一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。
可测试性(Testable)—一个用户故事要是可以测试的,以便于确认它是可以完成的。
2.PO做需求变更的步骤是什么?
1. 与客户一起,约定变更管理的流程. 最好在合同中约定,至少也要在启动会上约定。
2. 提出变更申请应该按照约定的流程通过由负责人提交给项目经理。
3. 项目经理收到需求变更申请,先了解前因后果和客户的目标,然后优先从系统外解决,如
果不行的话再进行变更工作量的评估和影响的分析,进行审批。
4. 审评过程中销售人员起到很重要的作用,因为销售要给出变更所需费用的来源,并要给出
承诺,否则变更没办法继续。
5. 其他审批人则根据自己的角色和职责进行审批即可。
6. 审批结束,进入执行环节,对绝大多数的变更,都可以不用马上执行变更动作,可以几个
变更作为一批一起执行,一方面可以降低频繁变更对项目工作的影响,另一方面对一些客户一时兴起变过来过不久又变回去的变更可以起到拦截作用。
7. 采用敏捷的开发方式进行开发,所以将需求纳入产品Backlog,然后分成Sprint Backlog,最
后是Backlog Item
3.SM如何通过禅道生成Sprint backlog?
来源于产品清单
当前迭代要实现需求对应的任务列表
由团队产生和维护
在禅道的‘需求’中提需求,创建任务,指派给团队对应人员,标记开始日期,结束日期,优先级,任务说明,附件等。
。
4.SCRUM的核心价值观包含哪些?
承诺,专注,公开,敬重,勇气
5.如果在云知声现在的组织架构下推行敏捷,需要着重注意哪些问题?
1.立项时明确人员,明确人员职责,各个节点的交付日期,交付质量标准。
2.避免大包大揽,明确需求边界。
3.会议不宜过长。
4.面对面沟通优于电话沟通优于即时工具优于邮件
5.边开发边交付,大版本切分完成的小功能交付
6.不出现delay,重承诺