看看你对敏捷迭代方法的理解：敏捷迭代考试试题附带答案

在学习和实践了一段敏捷方法后，可以检验一下对敏捷知识和思想的领会程度。本试题是一个面向实践的参考，不涉及敏捷的理论条款。

下面试题按照题目（题干）和选项（备选项）的方式排列，注意题目是多选题。“参考答案”在最后。

 

<

题目	选项1	选项2	选项3	选项4
对计划的发布版本应该	按产品特性交付：需要交付的特性都必须交付，必要时要推迟发布时间	按日期交付：按照预定发布时间进行发布，必要时候裁剪部分功能特性。	临时决定：我们会平衡一下，临时根据市场要求和开发进展来确定，可能会同时调整交付时间和特性。	在迭代模式下，没有必要计划版本。每个迭代都应该完成可发布的版本，按照市场需要发布迭代版本即可。
敏捷计划时机	提前做好计划，阶段性（按月和周）按照计划查看团队进展	每个迭代都制定计划和调整计划	每天都不断地做计划，当事情发生变化我们就会制定新的计划	没有必要做计划，只要不断滚动的从backlog中取出最高优先的需求来开发即可。
计划的频度	做很短的计划，很少超过一两周	做短期的迭代计划（1个月内）以及中长期的版本计划（几个月到1年），迭代计划比较细，版本计划只做概要计划	做长期计划，包括详细的任务和分工。后期可以根据实际进展修订。	频繁的做及时性计划
外部对项目的管理方式	管理是正式的、结构化的，要求周期性进行，并且由一个独立机构进行技术审核	管理是非正式的，由高层管理者通过“走动式管理”完成	管理是共同承担责任。计划由所有团队成员和资深管理人员共同制定，从而不需要强制就可以共同遵从	不需要管理，每个人都是自管理
项目内部的管理方式	管理是正式的、结构化的，要求周期性进行，并且由一个独立机构进行技术审核	管理是非正式的，由高层管理者通过“走动式管理”完成	管理是共同承担责任。计划由所有团队成员和资深管理人员共同制定，从而不需要强制就可以共同遵从	项目经理管理Master（或组长），master（或组长）管理开发人员
对发布版本计划	概念阶段/项目早期就开始制定版本计划，并每个迭代进行及时维护	包括每个版本的发布时间、发布内容、迭代数量。	每个版本计划都要准时完成，不能推迟发布。	每个版本的范围是固定的，不允许调整。
迭代的周期	迭代周期必须要固定不变，保证节奏	项目中每个特性团队的迭代起始周期都应该步调一致。	要根据版本发布要求，需求稳定性，用户反馈难度，迭代开销和压力大小来确定迭代周期长度。	1周最好
迭代计划	每个迭代前应该召开迭代计划会议	迭代会议内容：需求澄清，任务分解，工时估算。	明确迭代目标和迭代达成准则	在迭代会议上完成所有任务的责任人分配和确认；
参加迭代计划会议的人员包括	规划人员，项目经理	设计和开发人员	测试人员	实际用户
迭代计划任务	每个用户故事都应该分解到2天以内的任务	任务的估算应该由经验丰富的老员工来做。	迭代计划中应该包括修复故障的任务	任务的优先级应该依据需求的优先级。
每个迭代的目标输出	必须是通过测试的代码	必须是通过测试的特性	某些特性可以只是完成分析和定义	某些特性可以只是完成系统设计和分解。
工作任务如何分配	领导/经理指定每个人的工作（设计、编码、测试等），并及时进行沟通确认。	成员一起来分解需求到任务和估算，并从任务列表领取他们将要进行的工作	成员直接领取需求，并承诺交付时间	以上都不是