向死而生,方得重生。

Search

2019-06-27

项目管理3 —— 敏捷项目管理过程


1、如何算是敏捷度高的过程? D. 能够更快速而且低成本的达到项目的业务目标,选用甚至创造最适合自己的实践和方法

2、大型项目(上百人)的项目 B. 应该按照需求类别划分为多个小团队

3、自动化测试所占比例应该 B. 大于60%

4、测试人员工作方式? A. 全职参与到一个项目团队 D. 根据不同的阶段来划分,开发阶段内参与开发团队,开发完成后独立测试团队。

5、测试人员何时开展测试?C. 开发人员交付任何特性则立即被测试

6、独立的系统测试A. 测试前应该有一个测试准入检查 B. 测试人员每个迭代早期介入参与需求研讨,设计测试用例 C. 每个对外发布的特性,都应该经历过3轮以上的系统测试

7、持续集成包括 A. 频繁提交代码和持续构建 B. 持续手工验证新功能C. 持续自动化回归测试老的功能 D. 持续部署和反馈

8、开发人员CheckIn代码的频率? A. 每人每天进行一次或者多次

9、冒烟测试的频度? A. 每天进行一次或者多次

10、编码要求 A.符合编码规范,提交代码前要通过静态分析工具检查 C.提交代码前,要通过结对人员的复审;D.提交代码前,要完成单元测试

11、单元测试 B. 可以根据实际需要选择采用TDD还是手工自测方式 D. 单元测试最基本要求是实现功能覆盖

12、对详细设计文档 D. 阶段性(比如开发阶段末,项目收尾前)通过逆向工程或总结完成设计文档并归档,做为后续维护的参考资料。

13、设计研讨会 B. 可以在迭代开发中,按需发起设计研讨会 C. 是一种团队共同进行的设计活动 D. 仅仅对涉及多人协作的需求,才进行设计研讨会

14、如何评价构架设计质量?B. 关键构架需求被实现并测试通过 D. 测试故障中没有构架引起的

15、构架设计如何适应未来需求 C. 只聚焦当前需求,但是会应用一些可扩展的设计模式来保证将来的变更会相对容易一些 D. 预测短期之内要变更的需求,并设计对应的可扩展方案。对未来更远的不确定性需求,暂时不做考虑。

16、谁为技术架构负责 A. 架构由专门的架构组负责,构架组成员可以从每个团队中经验丰富的开发人员兼任;

17、如何确定需求优先级 A. 对客户的价值和使用频度 B. 开发成本 C. 开发的风险

18、需求研讨会 A. 每个迭代前或早期都应该否及时召开需求分析研讨会 B. 用户代表、测试人员都应该参加 C. 要确认需求优先级和澄清需求 D. 需求研讨会是高效收集和确认需求的一种方法。

19、需求文档 A. 需求文档随着迭代的进展,渐进细化。

20、需求管理包括 A. 特性清单(Product Backlog)中的需求完成状态和完成工作量需要被及时更新。 B. 需求项与前端需求(市场/用户需求),后端测试用例的追踪关系被及时更新。 C. 需求的优先级变更被及时更新 D. 需求的工作量估算变化被及时更新。

21、需求变更如何处理 C. 将它放入项目的backlog中,和其他所有需求一起进行优先级排序。D. 根据backlog的排序来确定开发的顺序。

22、需求分析人员和开发人员比例 A. 1名需求分析人员对4名开发人员或者更少

23、单个需求项的拆分 D. 对复杂的需求,其分析和拆分活动可以做为一个迭代内的任务。

24、需求分析过程 B. 从用户场景出发,在限定的时间箱内进行需求分析,达到可以估算和分解任务的程度就可以开始,然后在开发过程中完善需求细节。 D. 需求可以使用用例/用户故事/功能特性等方法,可以支持UML或者其他图形建模,需求根据需要可能1-5页

25、迭代回顾会议的内容 A. 项目的过程度量/指标分析 B. 优秀实践 C. 经验教训 D. 改进任务计划

26、最应该参加迭代评估(演示)的人员 B. 用户代表

27、迭代演示会议的内容 A. 迭代的完成情况与计划目标的比较 B. 测试通过的特性的演示 C. 对需求的反馈

28、迭代的度量应该包括 B. 燃尽趋势,工作量负载 C. 故障趋势 D. 持续集成质量

29、迭代跟踪 B. 可以根据需要采用日跟踪(比如站立会议)和周跟踪(比如周例会) C. 跟踪内容包括:进度,工作量,范围,故障等过程信息和度量; D. 需要的团队协作越多,跟踪的频度越高。

30、项目的特性清单(Product Backlog)最重要和必选的内容是 A. 每个特性的标题,优先级和估算

31、项目的特性清单(Product Backlog)A. 应该包括需求,故障和问题 C. 每个团队成员都可以维护和修改其内容和状态; D. 必须用故事卡片粘贴到墙上。

32、团队沟通的主要方式 D. 频繁(每天/每周)召开团队会议讨论需求,包括开发人员、分析人员、用户代表

33、项目中每个团队组成 C. 包括端到端特性可能会涉及的各个专业人员,比如:UI,业务,协议,数据库和平台支撑; D. 可以应付团队端到端交付需求的成员,包括系统,开发,测试,UCD等。

34、迭代计划时候 C. 应该保留20%左右的缓冲

35、当紧急需求变化时候 A. 规划人员重新排列特性清单中优先级,开发团队决定哪些工作要重新认领

36、工作任务如何分配 B. 成员一起来分解需求到任务和估算,并从任务列表领取他们将要进行的工作

37、每个迭代的目标输出 C. 某些特性可以只是完成分析和定义 D. 某些特性可以只是完成系统设计和分解。

38、迭代计划任务 A. 每个用户故事都应该分解到2天以内的任务 C. 迭代计划中应该包括修复故障的任务 D. 任务的优先级应该依据需求的优先级。

39、参加迭代计划会议的人员包括 A. 规划人员,项目经理 B. 设计和开发人员 C. 测试人员

40、迭代计划 A. 每个迭代前应该召开迭代计划会议B. 迭代会议内容:需求澄清,任务分解,工时估算明确迭代目标和迭代达成准则

41、迭代的周期 B. 项目中每个特性团队的迭代起始周期都应该步调一致。 C. 要根据版本发布要求,需求稳定性,用户反馈难度,迭代开销和压力大小来确定迭代周期长度。

42、对发布版本计划 A. 概念阶段/项目早期就开始制定版本计划,并每个迭代进行及时维护 B. 包括每个版本的发布时间、发布内容、迭代数量。

43、项目内部的管理方式 C. 管理是共同承担责任。计划由所有团队成员和资深管理人员共同制定,从而不需要强制就可以共同遵从

44、外部对项目的管理方式 A. 管理是正式的、结构化的,要求周期性进行,并且由一个独立机构进行技术审核

45、计划的频度 B. 做短期的迭代计划(1个月内)以及中长期的版本计划(几个月到1年),迭代计划比较细,版本计划只做概要计划

46、敏捷计划时机 B. 每个迭代都制定计划和调整计划

47、对计划的发布版本应该 B. 按日期交付:按照预定发布时间进行发布,必要时候裁剪部分功能特性。

 

48、如何理解软件开发过程中的七大浪费成因?

  • 部分完成的工作价值不明 过时

  • 额外的特性没有价值 额外的成本

  • 重新学习 重新犯同样的错误

  • 任务转换 流动损耗+资源浪费

  • 移交 损失关键信息

  • 延迟 带来更多的变更机会,未向客户交付价值

  • 缺陷 成本 = 影响 × 修正时间


 

49、描述Scrum两级规划的管理过程

  • 1)产品规划,输出产品订单

  • 2)冲刺规划,输出冲刺订单

  • 以冲刺规划会议、每日站立会议确保迭代过程的实施;冲刺复审与冲刺回顾会议作为阶段性收尾


 

50、Lean方法认为是浪费的有:A. 缺陷 C. 过多的移交流程 D. 多开发了额外的功能

51、下面哪些属于敏捷开发方法? A. 极限编程 B. SCRUM C. Lean

52、下面哪些参数可用于评价一个敏捷项目的规模? C. 领域知识复杂度 D. 跨地域性

53、Lean方法强调Just In Time的项目管理,这种环境中通常强调库存数量为: D. 0

54、JIT这个概念意味着: B. 零库存

55、如何算是敏捷度高的过程? D. 能够更快速而且低成本的达到项目的目标,选用甚至创造最适合自己的实践和方法

56、以下哪个项目管理过程往往是渐进明细? B. 定义范围

0 comments:

Post a Comment