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

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

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

 

题目

选项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团队行为，自组织当紧急需求变化时候1backlog的意义迭代计划时候3任何计划都需要缓冲项目中每个团队组成3，4多功能特性团队团队沟通的主要方式4用户故事渐进细化，推迟细节需求决策项目的特性清单（Product Backlog）1，3backlog是团队的，不是专属的。不要偏激。项目的特性清单（Product Backlog）最重要和必选的内容是1决定了迭代的计划迭代跟踪2，3，4站立会议不是一个汇报会议。迭代的度量应该包括2，3，4度量从多个角度迭代演示会议的内容1，2，3没有实现的，不要浪费时间最应该参加迭代评估（演示）的人员2用户才能确认需求迭代回顾会议的内容1，2，3，4也要关注量化的前端需求分析过程2，4用户口头或书面的需求，是造成需求变更的主要原因。要分析这些背后的原因，找到真正的需求。单个需求项的拆分4任何需求都可以通过一定手段分割为更细的粒度，比如场景/分支。需求分析人员和开发人员比例1业务层面的分析人员不可缺，越是“变更频繁”的需求，越需要投入分析。需求变更如何处理3，4backlog的意义需求管理包括1，2，3，4backlog的意义需求文档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敏捷测试的要点自动化测试所占比例应该2100%自动化是幻想大型项目（上百人）的项目2特性团队如何算是敏捷度高的过程？4不要成为教义的奴隶，而是看目的和结果