敏捷实践指南Word文档下载推荐.docx
《敏捷实践指南Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《敏捷实践指南Word文档下载推荐.docx（71页珍藏版）》请在冰豆网上搜索。
2.1可确定的工作与高度不确定的工作
项目工作包括可确定的工作与高度不确定的工作。
可确定的工作项目具有明确的流程，它们在以往类似的项目中被证明是行之有效的。
在完成设计后制造汽车、电器或建造住宅，这些都是可确定的工作的例子，其所涉及的生产领域和过程通常都很好理解，并且执行的不确定性和风险通常较低。
新的设计、解决问题和之前未做过的工作都是探索性的。
它要求主题专家携手合作，解
决问题，并创建解决方案。
遭遇高度不确定的工作的人员包括软件系统工程师、产品设计师、医生、教师、律师和许多解决问题的工程师等。
随着可确定的工作日益实现自动化，项目团队也越来越多地从事高度不确定的工作，从事这些工作就需要使用本实践指南所述的有关技术。
高度不确定的项目变化速度快，复杂性和风险也高。
这些特点可能会给传统预测法带来
问题，传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。
而敏捷方法的出现是为了在短时间内探讨可行性，根据评估和反馈快速调整。
2.2《敏捷宣言》及思维模式
我们通过身体力行和帮助他人来揭示更好的软件开发方式。
经由这项工作，我们形成了如下价值观：
1.个体与交互重于过程和工具
2.可用的软件重于完备的文档
3.客户协作重于合同谈判
4.响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
敏捷背后的12法则:
1.我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2.欢迎对需求提出变更——即使是在项目开发后期。
要善于利用需求变更，帮助客户获得竞争优势。
3.要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4.项目过程中，业务人员与开发人员必须在一起工作。
5.要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。
6.无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7.可用的软件是衡量进度的主要指标。
8.敏捷过程提倡可持续的开发。
项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9.对技术的精益求精以及对设计的不断完善将提升敏捷性。
10.要做到简洁，即尽最大可能减少不必要的工作。
这是一门艺术。
11.最佳的架构、需求和设计出自于自组织的团队。
12.团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
《敏捷宣言》价值观、原则和通用实践之间的关系
在艾哈迈德-西德基（AhmedSidky）启发下提出的模式将敏捷明确表述为一种思维模式，它由《敏捷宣言》的价值观所界定，受《敏捷宣言》原则指导，并通过各种实践实现。
图2-4结合上下文将敏捷定位为一个总称，它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。
图2-4还将敏捷方法和看板方法视为精益方法的子集。
这样做的原因是，它们都是精益思想的具体实例，都反映了诸如以下概念：
“关注价值”、“小批量”和“消除浪费”。
-------<
-------------
敏捷是一种方法、手段、实践、技术还是框架？
根据具体情况，上述词语均适用。
除非
使用其他词语明显更为合适，否则，本实践指南使用“方法”一词。
endofsidebar>
---------------
最终目标不是为了敏捷而敏捷，而是为了向客户持续交付价值流，并达成更好的商业成果。
2.3精益与看板方法
看待精益、敏捷与看板方法三者之间关系的一种思路是，将敏捷和看板方法视为精益思
想的衍生物。
换言之，精益思想是一个超集，与敏捷和看板方法拥有共性。
这种共性非常相似，重点在于交付价值、尊重人、减少浪费、透明化、适应变更以及持
续改善等方面。
项目团队有时会发现将各种方法结合起来使用更为有用，只要是对组织或团队有效的方法，无论来源如何，都应该采纳。
无论使用什么方法，目标都是为了实现最佳结
果。
看板方法受到最初的精益制造体系的启发，专门用于知识型工作。
它在2000年代中期出现，是当时非常盛行的敏捷方法的一种替代方法。
看板方法不如某些敏捷方法规范，破坏性也较小，原因在于它是原始的“原地出发”方法。
在有必要或适当的情况下，项目团队可以相对轻松地应用看板方法，并向其他敏捷方法发展。
-----------------------------------<
-----------------------------------
围绕看板方法以及其是否属于精益或敏捷运动可能总是会有大量讨论。
它从精益制造构
思而来，也围绕精益制造，但更广泛地应用于敏捷环境中。
2.4不确定性、风险和生命周期选择
有些项目在项目需求、以及如何使用现有知识和技术满足这些需求方面，具有很大的不
确定性。
这些不确定因素可能导致大量变更和项目复杂性的提高。
随着项目不确定性的增加，返工的风险和使用不同方法的需求也会增加。
为了减轻这些风险的影响，团队选择的生命周期要能够通过较少的工作增量解决项目的大量不确定性问题。
团队可以利用较少的工作增量验证自身的工作，并且可以对接下来的工作做出相应变更。
与静态书面规范相比，当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求。
图2-5受斯泰西复杂性模型启发的不确定性和复杂性模型
团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。
但是，随着项目不确定性的增加，变更、做无用功和返工的可能性也会随之增加，而这不仅代价高昂，而且耗费时间。
许多项目一开始处于斯泰西复杂性模型的左下部分，并无真正的手段转而使用其他方法。
从需求和交付手段两方面对项目进行评估后确定了项目生命周期的最佳方法。
通过构建一个小的增量，然后对其进行测试和评估，团队可以在短时间内以低成本探索不确定性，降低风险，最大程度地实现商业价值的交付。
这种不确定性可能集中于适用性和需求（正在构建的产品是否正确？
）；
技术可行性和性能（产品是否可以采用这种方法构？
或过程和人员（这是否为团队工作的一种有效方式？
）。
以上三个特点（产品规格、生产能力和过程适用性）通常都具有高度不确定性因素。
不过，迭代和增量管理方法也有其应用局限性。
当技术和需求的不确定性都很高时（图2-5右上部分），项目就会极端复杂，陷入无序状态。
为了使项目尽可能可靠，需要遏制其一个变量（不确定性或分歧）。
3、生命周期选择
3.1项目生命周期的特征
特征Characteristice
特征
approach
需求
Requirements
活动
Activities
交付
Delivery
目标
Goal
预测型生命周期predictive
固定周期
Fixed
整个项目中只执行一次
Performedoncefortheentireproject
交付一次
singledelivery
管理成本
Managecost
迭代型生命周期iterativve
动态周期
Dynamic
重复，直到正确
Repeateduntilcorrect
解决方案的正确性
Correctnessofsolution
增量型生命周期incremental
对于给定的增量执行一次
Performedonceforagivenincrement
频繁的小交付
Frequentsmallerdeliveries
速度
Speed
敏捷生命周期
agile
通过频繁的交付和反馈为客户创造价值
Customervalueviafrequentdeliveriesandfeedback
图3-1生命周期的连续区间
没有哪个生命周期能够完美地适用于所有的项目。
相反，每个项目都能在连续区间中找到一个点，根据其背景特征，实现最佳平衡。
•预测型生命周期。
充分利用己知和己经证明的事物。
不确定性和复杂性的减少，允许项目团队将工作分解为一系列可预测的小组。
•迭代型生命周期。
允许对部分完成或未完成的工作进行反馈，从而对该工作进行改进和修改。
•增量型生命周期。
可向客户提供完成的可交付成果，让客户能够立即使用。
•敏捷生命周期。
它同时利用迭代属性和增量特征。
团队使用敏捷方法时，他们会对产品进行迭代，创建完成的可交付成果。
团队将获得早期的反馈，并能提供客户可见性、信心和对产品的控制。
由于团队可以提前发布产品，而团队将率先交付价值最高的工作，所以项目可以更早产生投资回报。
计划始终贯穿其中要记住的关键一点是，每种生命周期都有计划要素。
生命周期的不同之处。
在连续区间的预测一端，是计划驱动着工作。
有多少计划，就有多少提前执行的可能性。
尽可能详细地定义需求。
团队估算何时能够交付可交付成果，并全面开展采购工作。
在迭代方法中，也计划了原型和验证，但是输出的目的是修改一开始所创建的计划。
对未完成的工作的早期评审将有助于未来的项目工作。
与此同时，增量方法计划交付整个项目后续部分。
团队可以提前计划可交付成果的若干次连续交付，或者一次只计划交付一个。
可交付成果为未来的项目工作提供了相关信息。
敏捷项目也有计划。
主要区别在于，通过对频繁交付的可交付成果的评审，团队将能获得更多的信息，从而在此基础上进行计划和重新计划。
无论采用哪种项目生命周期，项目都需要计划。
3.1.1预测型生命周期的特征
预测型生命周期预计会从高确定性的明确的需求、稳定的团队和低风险中获益。
为了实现这种方法，团队需要详细的计划，了解要交付什么以及怎样交付。
团队领导的目标是尽可能减少预测型项目的变更。
团队在项目开始时创建详细的需求和计划时，他们可以阐明各种制约因素。
然后，团队可以利用这些制约因素管理风险和成本。
进而，团队在实施详细计划时，他们会监督并控制可能影响范围、进度计划或预算的变更。
预测型项目强调根据部门划分的、有效的、顺序的工作，并且通常不会在项目结束前交付商业价值。
如果遇到变更或需求分歧，或者技术解决方案变得不再简单明了，预测型项目就将产生意想不到的成本。
3.1.2迭代型生命周期的特征
迭代型生命周期通过连续的原型或概念验证来改进产品或成果。
每一个新的原型都能带来新的相关方新的反馈和团队见解。
然后，团队在下一周期重复一个或多个项目活动，在其中纳入新的信息。
团队可能会在长达数周时间的一个特定迭代中使用时间盒，集中各种见解，然后根据这些见解对活动进行返工。
这样，迭代有利于识别和减少项目的不确定性。
当项目复杂性高、变更频繁或当项目范围受到相关方对所需最终产品的不同观点的支配时，采用迭代型生命周期会有优势。
迭代型生命周期可能需要更长的时间，因为它是为学习而优化，而不是为交付速度而优化。
您是否并不确定新的商业服务在实践中怎样发挥作用？
用评估标准来创建一个概念验证，以此探讨期望的结果。
如果您怀疑需求将根据客户的反馈发生变更，请使用迭代方法。
您是否曾经参与过这样的项目，在项目过程中，需求似乎每天都在变化，您认为，“我们在交付企业批准的原型时就会了解需求。
”如果情况如此，那么，采用敏捷方法将有助于这个项目。
原型法鼓励反馈，并有助于更好地理解可纳入每个可交付成果的需求。
3.1.3增量型生命周期的特征
有些项目优化是为了加快交付速度。
许多企业和项目无法等待所有的事情全部完成；
这种情况下，客户愿意接受整个解决方案的一个部分。
这种少量可交付成果的频繁交付称为增量型生命周期（参见图3-4）。
与一次交付一个最终产品相比，增量型生命周期将经常优化为项目发起人或客户交付价值的工作。
在开始工作之前，团队就计划了最初的可交付成果，他们还会尽快开始第一次交付的工作。
某些敏捷项目在项目启动后几天内就开始交付价值。
有的项目可能需要更长的时间，从1周到几周时间不等。
随着项目的继续，团队可能会偏离最初的设想。
由于可以更快地交付价值，因而团队可以管理偏差。
与客户在项目结束时获得价值相比，确保客户能尽早获得价值，其变更和差异程度的重要性变得不那么重要。
完整性和交付是主观的。
团队可能需要获得关于原型的反馈，然后可能选择将最小可行性产品（MVP）交付给部分客户。
客户的反馈将帮助团队了解他们需要为随后交付的最终功能的完善提供些什么。
敏捷团队的一个重要差异化优势在于，他们会经常交付商业价值。
由于产品的功能得到增加，就能吸引更多的消费者，因而我们就可以说，它是增量交付的。
例如，在继续修建大楼的其余部分之前，施工人员可能希望先展示一间已完工的房间或一层楼。
这种情况下，在继续修建大楼的下一层前，他们可能会为己完工的楼层布置家具、刷漆等。
客户可以查看和批准有关样式、颜色和其他细节，以便在进一步投入时间和金钱之前做出相应的调整。
这样做将减少潜在的返工和/或客户的不满。
3.1.4敏捷生命周期的特征
在敏捷环境中，团队预料需求会发生变更。
迭代和增量方法能够提供反馈，以便改善项目下一部分的计划。
不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。
图3-5显示了实现增量交付的两种可能的方法，这样将便于项目与客户需求保持一致，并根据需要进行调整。
在基于迭代的敏捷中，团队以迭代（相等持续时间的时间盒）形式交付完整的功能。
团队可决定一次进行若干功能的开发工作，但团队不会同时完成所有的迭代工作（即团队不会在完成全部分析等工作后再解决所有需求）。
对于建立在流程基础上的敏捷方法，团队将根据自身能力，从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。
团队定义任务板各列的工作流，并管理各列的进行中的工作。
完成不同功能所花费的时间可能有所不同。
团队让进行中的工作的规模尽量小，以便尽早发现问题，并在需要变更时减少返工。
无需利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。
为了适应更频繁的变更，和更频繁地交付项目价值，敏捷生命周期结合了迭代和增量方法。
3.1.5敏捷适用性筛选器
有各种评估模型可用来帮助确定使用敏捷方法的适合性或差距。
这些模型评估项目和具有适应性和适用性的组织因素，然后提供分数表明一致性或潜在风险领域。
附件X3综合提供了各种流行的评估模型，它们可用作敏捷适用性筛选器。
3.1.6混合生命周期的特征
对于整个项目，没有必要使用单一的方法。
为达到特定的目标，项目经常要结合不同的生命周期要素。
预测、迭代、增量和/或敏捷方法的组合就是一种混合方法。
例如：
3.1.7结合了敏捷和预测的方法
另一种方法是在整个生命周期中结合使用敏捷方法和预测法。
图3-7同时结合使用敏捷和预测的方法
在图3-7中，在同一项目中结合使用了预测法和敏捷方法。
也许团队正在逐渐地向敏捷过渡，并使用一些方法，如短迭代、每日站会和回顾，但在项目的其他方面，如前期评估、工作分配和进度跟踪等，仍然遵循了预测法。
同时使用预测法和敏捷方法是一个常见的情况。
将这种方法称为敏捷方法是一种误导，因为它显然没有充分体现敏捷思维模式、价值观和原则。
不过，由于这是一种混合方法，所以称其为预测法也是不准确的
3.1.8以预测法为主、敏捷方法为辅的方法
图3-8所示为一个以预测法为主的项目中一个小的敏捷要素。
在这种情况下，以敏捷方法处理具有不确定性、复杂性或范围蔓延机会项目的一部分，而使用预测法管理项目的其余部分。
这种方法的一个例子是，某工程公司正在使用一个新的组件建造一个设施。
图3-8以预测法为主、敏捷方法为辅的方法
虽然大部分项目可能是常规的、可预测的，就像组织实施的许多其它的设施项目一样，但这个项目包含了一种新的屋顶材料。
承包商可能计划首先在地面上进行一些小规模的安装试验，以确定最佳的安装方法，并在有足够时间解决问题时尽早发现问题，随后通过试验和调整，增量地改进过程。
3.1.9以敏捷方法为主、预测法为辅的方法
图3-9描述了一个以敏捷方法为主、预测法为辅的方法。
当某个特定要素不可协商，或者使用敏捷方法不可执行时，可能会使用这种方法。
这种情况的例子包括，集成由不同供应商开发的外部组件，这些外部组件不能或不会以协作或增量方式合作。
在组件交付之后，需要单独集成。
图3-9以敏捷方法为主、预测法为辅的方法
3.1.10符合目的的混合生命周期
项目团队可能基于项目风险设计一个混合生命周期。
例如，某校园建设项目可能会有多个建筑需要改善和建设。
增量方法会将资源集中，使某些建筑比其他建筑更早完工，从而加快投资回报。
众所周知，每个建筑的独自交付都能得益于该建筑独自采用预测型生命周期。
项目管理的目标是在给定的当前环境下尽可能以最好的方式创造商业价值。
项目采用敏捷方法亦或预测法，都无关紧要。
要提出的问题是：
“我们怎样做才能最成功？
”
此处作者写错了，增量方法和迭代方法解释反了。
迭代是为了解决方案的正确性，即需要反馈，改进和修改后续方法；
增量是为了速度,交付成果；
敏捷是为了通过频繁的交付和反馈为客户创造价值，利用反馈，重新规划下一部分工作，化解风险。
当团队创造价值时，是否需要反馈？
如果需要，增量方法将会有所帮助。
在探讨各种想法时，是否需要管理风险？
如果需要，迭代方法或敏捷方法将会有所帮助。
当组织无法交付中间价值时，敏捷方法可能不是很有用。
这样没有问题，但为了敏捷而敏捷并不是目标。
关键在于，要选择一个对项目、风险和文化管理有用的生命周期或生命周期的组合。
敏捷关乎频繁向客户交付。
而这种交付要给团队带来反馈。
团队利用上述反馈规划并重新规划下一部分的工作。
3.1.11混合型生命周期作为过渡策略
许多团队无法在一夜之间切换到敏捷工作方式。
对于那些己经习惯于预测型环境、并在其中获得成功的人士，敏捷技术的观感截然不同。
组织越大，活动部件越多，转换需要的时间就越长。
因此，计划一个渐进的过渡是有意义的。
3.2混合敏捷方法
敏捷团队很少将其实践局限于一种敏捷方法。
每个项目背景都有其各自的独特性，比如
团队成员技能和背景的不同组合；
开发中的产品的各个组成部分；
以及工作环境中的年龄、
规模、关键性、复杂性和监管制约因素等。
敏捷框架并不是针对团队定制的。
为了定期交付价值，团队可能需要对实践进行裁剪。
通常，团队都会实践各自特殊的敏捷组合，即便他们使用一个特定的框架作为起点也不例外。
3.3影响裁剪的项目因素
有时，为了更好地配合，根据项目属性对方法进行裁剪。
表3-2列出一些要考虑的项目
因素和裁剪方案。
改进配合的裁剪方案
项目因数（ProjectFactor）
定制选项（TailoringOptions）
需求模式:
稳定或零星
许多团队发现使用一个节奏（以一个常规时间框的形式）可以帮助他们进行演示、回顾并开始新的工作。
此外，一些团队在接受更多工作时需要更灵活的灵活性。
团队可以使用基于流程的数据流，并结合两者的优点。
团队经验水平所要求的过程改进率
更频繁地回顾并选择改进之处
工作流程经常被各种延迟或障碍所打断
考虑使用看板使工作可见，并尝试对工作过程的各个领域进行限制，以改进流程。
产品质量增量差
考虑使用各种测试驱动的开发实践。
这个防错规则使得防御很难不被发现。
构建一个产品需要多个团队
要从一个敏捷团队扩展到多个敏捷团队，并尽可能减少干扰，首先要了解敏捷项目管理或正式的扩展框架。
然后，制定一个适合项目上下文的方法。
项目团队成员在使用敏捷方法方面缺乏经验
考虑从对团队成员进行敏捷思维和原则的基础培训开始。
如果团队决定使用特定的方法，比如Scrum或看板，提供一个关于该方法的研讨会，以便团队成员能够学习如何使用它。
关于影响裁剪的因素的更多指导，请参见附件X2“影响裁剪的属性”。
4、实施敏捷：
创建敏捷环境
4.1从敏捷思维模式开始
以下问题的答案将有助于制定实施策略：
•项目团队如何以敏捷方式行动？
•为了使下一交付周期受益，团队需要快速交付哪些成果并获得早期反馈？
•团队如何以一种透明的方式行动？
•为
升级会员 