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

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

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

 

题目	选项1	选项2	选项3	选项4
对计划的发布版本应该	按产品特性交付：需要交付的特性都必须交付，必要时要推迟发布时间	按日期交付：按照预定发布时间进行发布，必要时候裁剪部分功能特性。	临时决定：我们会平衡一下，临时根据市场要求和开发进展来确定，可能会同时调整交付时间和特性。	在迭代模式下，没有必要计划版本。每个迭代都应该完成可发布的版本，按照市场需要发布迭代版本即可。
敏捷计划时机	提前做好计划，阶段性（按月和周）按照计划查看团队进展	每个迭代都制定计划和调整计划	每天都不断地做计划，当事情发生变化我们就会制定新的计划	没有必要做计划，只要不断滚动的从backlog中取出最高优先的需求来开发即可。
计划的频度	做很短的计划，很少超过一两周	做短期的迭代计划（1个月内）以及中长期的版本计划（几个月到1年），迭代计划比较细，版本计划只做概要计划	做长期计划，包括详细的任务和分工。后期可以根据实际进展修订。	频繁的做及时性计划
外部对项目的管理方式	管理是正式的、结构化的，要求周期性进行，并且由一个独立机构进行技术审核	管理是非正式的，由高层管理者通过“走动式管理”完成	管理是共同承担责任。计划由所有团队成员和资深管理人员共同制定，从而不需要强制就可以共同遵从	不需要管理，每个人都是自管理
项目内部的管理方式	管理是正式的、结构化的，要求周期性进行，并且由一个独立机构进行技术审核	管理是非正式的，由高层管理者通过“走动式管理”完成	管理是共同承担责任。计划由所有团队成员和资深管理人员共同制定，从而不需要强制就可以共同遵从	项目经理管理Master（或组长），master（或组长）管理开发人员
对发布版本计划	概念阶段/项目早期就开始制定版本计划，并每个迭代进行及时维护	包括每个版本的发布时间、发布内容、迭代数量。	每个版本计划都要准时完成，不能推迟发布。	每个版本的范围是固定的，不允许调整。
迭代的周期	迭代周期必须要固定不变，保证节奏	项目中每个特性团队的迭代起始周期都应该步调一致。	要根据版本发布要求，需求稳定性，用户反馈难度，迭代开销和压力大小来确定迭代周期长度。	1周最好
迭代计划	每个迭代前应该召开迭代计划会议	迭代会议内容：需求澄清，任务分解，工时估算。	明确迭代目标和迭代达成准则	在迭代会议上完成所有任务的责任人分配和确认；
参加迭代计划会议的人员包括	规划人员，项目经理	设计和开发人员	测试人员	实际用户
迭代计划任务	每个用户故事都应该分解到2天以内的任务	任务的估算应该由经验丰富的老员工来做。	迭代计划中应该包括修复故障的任务	任务的优先级应该依据需求的优先级。
每个迭代的目标输出	必须是通过测试的代码	必须是通过测试的特性	某些特性可以只是完成分析和定义	某些特性可以只是完成系统设计和分解。
工作任务如何分配	领导/经理指定每个人的工作（设计、编码、测试等），并及时进行沟通确认。	成员一起来分解需求到任务和估算，并从任务列表领取他们将要进行的工作	成员直接领取需求，并承诺交付时间	以上都不是
当紧急需求变化时候	规划人员重新排列特性清单中优先级，开发团队决定哪些工作要重新认领	项目经理增加紧急任务，扩大加班时间。	开发团队拼命工作适应变化，并将项目拖回到正常轨道上来	紧急需求应该放到下一个迭代或防火墙团队，不应该干扰现有的任务
迭代计划时候	应该用任务把开发人员的可用工作量填满	应该包括加班时间	应该保留20%左右的缓冲	应该加大开发人员的并发任务，来充分利用资源。
项目中每个团队组成	由可以应付团队各方面工作的通才组成(特种兵)，他们每个人都精通从系统设计，开发和测试等各项技能。	不同专业的人员组成专业团队，比如：系统设计组，UI开发组，业务开发组，协议开发组，数据库开发组，平台开发组，集成测试组，系统测试组等；	包括端到端特性可能会涉及的各个专业人员，比如：UI，业务，协议，数据库和平台支撑；	可以应付团队端到端交付需求的成员，包括系统，开发，测试，UCD等。
团队沟通的主要方式	需求和规格应该足够清晰和明确，并在开发前完成评审和确认，不需要下游人员反复再去询问。	迭代早期只确定一个需求的标题，临到开发前一刻才进行沟通和确认需求细节。	需求不需要提前定义，成员可以随时和其想交流的人员进行交流和确认。	频繁（每天/每周）召开团队会议讨论需求，包括开发人员、分析人员、用户代表。
项目的特性清单（Product Backlog）	应该包括需求，故障和问题	应该由项目经理或团队组长来维护和控制	每个团队成员都可以维护和修改其内容和状态；	必须用故事卡片粘贴到墙上。
项目的特性清单（Product Backlog）最重要和必选的内容是	每个特性的标题，优先级和估算	每个特性的标题，详细描述	每个特性的责任人和状态	以上都是
迭代跟踪	团队每天必须进行站立会议，向项目经理或团队组长汇报和沟通每个成员的工作进展，计划和问题。	可以根据需要采用日跟踪（比如站立会议）和周跟踪（比如周例会）	跟踪内容包括：进度，工作量，范围，故障等过程信息和度量；	需要的团队协作越多，跟踪的频度越高。
迭代的度量应该包括	只要每天跟踪特性与任务完成情况（燃尽）即可，不需要过程度量	燃尽趋势，工作量负载	故障趋势	持续集成质量
迭代演示会议的内容	迭代的完成情况与计划目标的比较	测试通过的特性的演示	对需求的反馈	实现中的特性的演示
最应该参加迭代评估（演示）的人员	项目经理	用户代表	开发人员	测试人员
迭代回顾会议的内容	项目的过程度量/指标分析	优秀实践	经验教训	改进任务计划
需求分析过程	与用户进行面对面沟通，把用户口头或书面提出的需求记录为用户故事	从用户场景出发，在限定的时间箱内进行需求分析，达到可以估算和分解任务的程度就可以开始，然后在开发过程中完善需求细节。	我们在开始开发前形成一个尽可能完全和详细的需求列表	需求可以使用用例/用户故事/功能特性等方法，可以支持UML或者其他图形建模，需求根据需要可能1-5页
单个需求项的拆分	有些需求很复杂，无法拆分到一个迭代内的任务。	不能按照功能步骤来拆分需求，比如：启动，操作，保存。	不能按照设计子系统来拆分需求，比如GUI，服务，数据库。	对复杂的需求，其分析和拆分活动可以做为一个迭代内的任务。
需求分析人员和开发人员比例	1名需求分析人员对4名开发人员或者更少	1名需求分析人员对10名开发人员或者更少	每个开发人员要兼任需求分析人员。	一个项目有一两位专职的需求分析人员；
需求变更如何处理	应该有正式的需求变更控制流程，所有的需求变更都要经过批准和签署，并保证有相应的人力和时间资源；	变更请求越来越频繁，而且优先级在提高，我们尽可能将它们放入下一个发布中完成	将它放入项目的backlog中，和其他所有需求一起进行优先级排序。	根据backlog的排序来确定开发的顺序。
需求管理包括	特性清单（Product Backlog）中的需求完成状态和完成工作量需要被及时更新。	需求项与前端需求（市场/用户需求），后端测试用例的追踪关系被及时更新。	需求的优先级变更被及时更新	需求的工作量估算变化被及时更新。
需求文档	需求文档随着迭代的进展，渐进细化。	测试人员要根据详细的需求文档才能来编写测试用例	自始自终都不需要需求文档，通过用户故事卡片和口头沟通来做各项工作。	测试代码就是需求文档，没有必要其他形式。
需求研讨会	每个迭代前或早期都应该否及时召开需求分析研讨会	用户代表、测试人员都应该参加。	要确认需求优先级和澄清需求	需求研讨会是高效收集和确认需求的一种方法。
如何确定需求优先级	对客户的价值和使用频度	开发成本	开发的风险	没有必要确定优先级，用户都急着要。
谁为技术架构负责	架构由专门的架构组负责，构架组成员可以从每个团队中经验丰富的开发人员兼任；	架构是项目中所有团队成员的责任，每个开发人员都负责修改和维护构架；	项目组中有专职的构架师岗位，专门负责牵头各个团队的设计人员进行构架设计、讨论和培训传达；	每个开发人员在开发代码时候，发现构架不合理，都应该及时重构涉及构架的代码和测试代码，并通知全体人员；
构架设计如何适应未来需求	由于架构变更代价很高，我们设计时考虑所有已知可能的需求，设计高可扩展方案来适应未来的需求	只考虑当前需要的，采用“最先能够工作，最简单和直接”的策略来最大化我们的生产率	只聚焦当前需求，但是会应用一些可扩展的设计模式来保证将来的变更会相对容易一些。	预测短期之内要变更的需求，并设计对应的可扩展方案。对未来更远的不确定性需求，暂时不做考虑。
如何评价构架设计质量？	关键构架需求有设计方案记录	关键构架需求被实现并测试通过	构架设计被项目大部分相关干系人一致评审通过。	测试故障中没有构架引起的
设计研讨会	应该在迭代早期通过设计研讨会完成所有特性的设计	可以在迭代开发中，按需发起设计研讨会	是一种团队共同进行的设计活动	仅仅对涉及多人协作的需求，才进行设计研讨会
对详细设计	检查详细设计的程度（由开发人员来把握），以可以指导下一步开发为准	致力于简练的文字和清晰的图表；减低文字冗余和避免较大的篇幅	测试代码是一种很好的详细设计替代物	编码前应该评审详细设计文档
对详细设计文档	每个设计活动后应该完成设计文档并评审和归档。	每个迭代结束前必须完成设计文档和归档	每个版本发布前必须完成设计文档的编写和归档	阶段性（比如开发阶段末，项目收尾前）通过逆向工程或总结完成设计文档并归档，做为后续维护的参考资料。
单元测试	必须实施TDD	可以根据实际需要选择采用TDD还是手工自测方式	单元测试最基本要求是实现代码覆盖	单元测试最基本要求是实现功能覆盖
编码要求	符合编码规范，提交代码前要通过静态分析工具检查	代码通过测试人员测试后，再进行重构，以保证复杂度低和不冗余。	提交代码前，要通过结对人员的复审；	提交代码前，要完成单元测试
冒烟测试的频度	每天进行一次或者多次	每周一次	间隔大于一周	按照测试版本的需要临时构建
开发人员CheckIn代码的频率	每人每天进行一次或者多次	项目组每天一次或多次	每周一次或多次	特性完成时CheckIn
持续集成包括	频繁提交代码和持续构建	持续手工验证新功能	持续自动化回归测试老的功能	持续部署和反馈
独立的系统测试	测试前应该有一个测试准入检查	测试人员每个迭代早期介入参与需求研讨，设计测试用例。	每个对外发布的特性，都应该经历过3轮以上的系统测试。	每个对外发布的版本，只要经过1轮系统测试即可。
测试人员何时开展测试	每个发布版本前（可能长于1个月）提交版本测试清单	每个迭代开发完成后（小于1个月）根据开发完成的特性清单来测试	开发人员交付任何特性则立即被测试	每天不断执行测试用例（不管代码是否存在），驱动开发人员进行开发；
测试人员工作方式	全职参与到一个项目团队	在多个在团队中共享/兼职工作	独立的测试团队	根据不同的阶段来划分，开发阶段内参与开发团队，开发完成后独立测试团队。
自动化测试所占比例应该	90%以上	大于60%	25%----60%	小于25%
大型项目（上百人）的项目	应该按照子系统划分为多个小团队	应该按照需求类别划分为多个小团队	应该按照小版本划分为多个小团队	应该按照岗位分工划分为多个小团队
如何算是敏捷度高的过程？	严格按照XP或Scrum的要求做到每个步骤	一切向4大敏捷价值观看齐	确保自己的每个行为都符合著名的12大敏捷原则。	能够更快速而且低成本的达到项目的业务目标，选用甚至创造最适合自己的实践和方法

参考答案和提示：

 

题目	答案	答案的补充解释
对计划的发布版本应该	2	迭代的核心观念
敏捷计划时机	2	以迭代为单位进行团队计划
计划的频度	2	兼顾短，中长期计划
外部对项目的管理方式	1	项目是投资行为
项目内部的管理方式	3	自组织
对发布版本计划	1，2	交付时间导向
迭代的周期	2，3	不要偏激
迭代计划	1，2，3	鼓励在过程中团队沟通，鼓励自发自愿
参加迭代计划会议的人员包括	1，2，3	实际用户一般是涉及需求确认和验收
迭代计划任务	1，3，4	负责任务的人应该参加估算
每个迭代的目标输出	3，4	不要偏激
工作任务如何分配	2	团队行为，自组织
当紧急需求变化时候	1	backlog的意义
迭代计划时候	3	任何计划都需要缓冲
项目中每个团队组成	3，4	多功能特性团队
团队沟通的主要方式	4	用户故事渐进细化，推迟细节需求决策
项目的特性清单（Product Backlog）	1，3	backlog是团队的，不是专属的。不要偏激。
项目的特性清单（Product Backlog）最重要和必选的内容是	1	决定了迭代的计划
迭代跟踪	2，3，4	站立会议不是一个汇报会议。
迭代的度量应该包括	2，3，4	度量从多个角度
迭代演示会议的内容	1，2，3	没有实现的，不要浪费时间
最应该参加迭代评估（演示）的人员	2	用户才能确认需求
迭代回顾会议的内容	1，2，3，4	也要关注量化的
前端需求分析过程	2，4	用户口头或书面的需求，是造成需求变更的主要原因。要分析这些背后的原因，找到真正的需求。
单个需求项的拆分	4	任何需求都可以通过一定手段分割为更细的粒度，比如场景/分支。
需求分析人员和开发人员比例	1	业务层面的分析人员不可缺，越是“变更频繁”的需求，越需要投入分析。
需求变更如何处理	3，4	backlog的意义
需求管理包括	1，2，3，4	backlog的意义
需求文档	1	需求文档的意义。不要偏激
需求研讨会	1，2，3，4
如何确定需求优先级	1，2，3	迭代的意义
谁为技术架构负责	1	谁都有责任=谁都没有责任
构架设计如何适应未来需求	3，4	不要偏激
如何评价构架设计质量？	2，4	构架的实质
设计研讨会	2，3，4	不要偏激
对详细设计	1，2，3	详设的作用
对详细设计文档	4	详设的作用
单元测试	2，4	不要偏激
编码要求	1，3，4	及时做重构
冒烟测试的频度	1	持续
开发人员CheckIn代码的频率	1	持续
持续集成包括	1，2，3，4
独立的系统测试	1，2，3	质量
测试人员何时开展测试	3	不要偏激
测试人员工作方式	1、4	敏捷测试的要点
自动化测试所占比例应该	2	100%自动化是幻想
大型项目（上百人）的项目	2	特性团队
如何算是敏捷度高的过程？	4	不要成为教义的奴隶，而是看目的和结果