Negotiation 可协商的
是缩写 INVEST 的一部分, INVEST 描述了一个好的用户故事应有的各种特性。可协商性表示用户故事不是一成不变的,而是具有可塑性的,再从记事卡片转变为工作软件的过程中是可以被质疑和修改的。
Negotiation 谈判
敏捷宣言中认为谈判的价值低于客户合作。典型的谈判会涉及合同,合同会将客户排除在执行组织之外。当然有些谈判时必要的,他提升了合同收益,解决了意见分歧,但敏捷并不看重这两点。
Net Present Value(NPV) 净现值
计算项目价值时把货币的时间价值作为因素计入的一种方法。净现值计算公式中还会考虑项目成本(另参见“现值”)
Osmotic communication 渗透式沟通
以聆听方式发生的沟通。一位团队成员无意中听到作战室中另外两位团队成员交谈并知晓相关信息就是渗透式沟通的一个实例。
Pair Programming 结对编程
极限编程方便论所倡导的一种实践方式,开发人员两人一组一起工作,一个程序员“敲键盘”写代码,另一个旁观其操作,以不同的视角参与编程。理想情况下,结对编程比单兵作战效率更高。
Parking Lot Chart 停车场图.
主要在需求收集活动中使用的一种图表,用来叫停任何可能游离当前目标的会话(或用来叫停任何与当前议题无关的会话)。某位干系人提出的一个问题可能很重要,但不一定与当前议题相关,可以把这个议题“停放”一旁暂时搁置。稍后再做商议。活动结束时应该重温一遍停车场图上的所有事项。
Persona 人物
团队创造的一个虚拟人物或身份,用来模拟与系统的交互,以便收集需求。如果团队创建了一个销售系统点。那他们可以虚构一个叫“泰勒”的任务来代表如下行为的用户,即买了一大堆物品,然后在当天稍晚全部退货并获记账参数(参见“极限人物”)
Pig 猪
全身心投入敏捷项目并受项目结果影响的人员(另参见“鸡”)
Plan-Do-Check-Act(PDCA) PDCA 循环(计划-执行-检查-修正)
提出并普及的工作循环,提出工作应该按照计划、执行、检查、修正的顺序循环进行。相比于传统项目。敏捷项目以规格更小。速度更快的迭代方法来实现 PDCA 循环。
Planning Game 计划游戏
创建版本发布计划的一种手段。团队会估算开发每个需求所要花费的工夫。根据上述信息,客户综合考虑商业价值和所花工夫/成本后排出需求的优先级。
Planning Poker 计划扑克
遍布于敏捷项目的形式多样的一种训练。传统方式是团队成员先各自估计开发某项用户需求所需花费的工夫,并在索引卡上写下估计结果。然后所有团队成员同时翻开各自的索引卡,接下来的讨论将集中于估计结果中的高值和低值,目的是为了弄清为何教务团队成员认为这项需求开发特备困难或特备容易。接着团队开展讨论,需要的话重复上述过程,知道所有成员的估计结果达到相对一致,估计结果可以使小时数、天数和理想天数,或者如 XS,S,M,L或 XL 这样的近似估计,或是裴波那契序列中的点数。
Present Value (PV)现值
计算项目价值时把货币的时间价值作为因素计入的一种方法。将一个潜在投资项目或投资机会和另一个进行比较时,现值计算时非常有用的方法。
Process Tailoring 过程制定
对敏捷过程进行提炼。以适应项目或环境需求。过程定制基于下述原则:过程应该服务于项目而不是相反。在项目的整个生命周期中,敏捷过程定制会重复进行多次。
Product Backlog 产品未完项(产品待办事项)
所有已知的、即将通过项目实现的需求,无论是规划的迭代还是版本发布中包含的需求都算在内。
Product Owner 产品负责人
敏捷项目中的角色、代表客户、用户和干系人,理解并倡导潜在需求的总体商业价值。产品负责人负责维护产品未完项,并在每次迭代计划会议上牵头第一部分的讨论。
Product Road Map 产品路线
显示当前产品功能及/或规划产品功能概况的一个组件。产品路线不如发布计划那么详细。
Programmer (XP)程序员(XP)
极限编程方法论中定义的一个角色,一结对的方式进行工作,一个人写代码,另一个人旁观
并给出意见建议。
Progressive Elaboration 渐进明细
计划工作并非堆积在前期,而是周期性发生的一种迭代方法。采用渐进明细方式的项目的典型做法是,计划一部分、执行一部分、监控一部分,然后重复上述周期。敏捷项目是高度的渐进明细型项目。
Project 项目
为创造独特的产品、服务或成果而进行的临时性工作。
Qualitative 定性的
无法测量但仍会影响产品质量的描述性因素。
Quality 质量
符合规范或要求。
Quantitative 定量的。
影响产品质量的可(量化)测量因素。
Relative sizing 相对规模估计
基于另一个功能或用户故事的规模来估计当前的规模。不进行实际的时长估计,而是将一组用户故事从难度最高到最低进行排序,是相对规模估计的一个实例。
Release 版本
一组封装的迭代结果,旨在交付给最终用户和客户。每个版本交付的工作软件被期望是高度稳定的。
Return on Investment (ROI)投资回报率
指组织得到的回报与投资总额的百分比
Risk 风险
任何会给项目带来正面或负面影响的不确定性因素
Risk burn-down chart 风险燃尽图
一种图表,上面罗列了项目成功且与每项需求相关的各种风险,随着项目不断推进和功能完成开发,项目风险将会不断减少或“燃烧殆尽”。
Role 角色
个人与敏捷项目打交道的方式。敏捷项目的角色包含客户、产品负责人、干系人、团队成员、测试员、跟踪员、敏捷教练或 Scrum Master,以及教练
Root Cause Analysis 根本原因分析
一种分析问题的技术,通过问题表象来了解引起这些现象的根本问题。根本原因分析有时需
要借助根本原因和五问法来进行。
Root Cause Diagram 根本原因图
别名石川图、鱼骨图和因果图的一种图表。根本原因图用于说明不同因素如何相互关联,同时识别出根源问题。