当前位置：首页 > news >正文

东莞网站建设-南城石佳环保主题静态网站模板下载

news 2025/11/15 2:23:08

东莞网站建设-南城石佳,环保主题静态网站模板下载,关键词搜索推广排行榜,重庆水舟科技做网站电子工业出版社 Publishing House Of Electronics Industry 北京BeiJing 版次#xff1a;2018年10月第1版印次#xff1a;2023年2月第22次印刷定价#xff1a;68元声明作为项目管理协会#xff08;PMI#xff09;的标准和指南#xff0c;本指南是通过相关人员的…电子工业出版社 Publishing House Of Electronics Industry 北京·BeiJing 版次2018年10月第1版印次2023年2月第22次印刷定价68元声明作为项目管理协会PMI的标准和指南本指南是通过相关人员的自愿参与和共同协商而开发的。其开发过程汇集了一批志愿者并广泛收集了对本指南内容感兴趣的人士的观点。PMI管理该开发过程并制定规则以促进协商的公平性但并没有直接参与写作也没有独立测试、评估或核实本指南所含任何信息的准确性、完整性或本指南所含任何判断的有效性。因本指南或对本指南的应用或依赖而直接或间接造成的任何人身伤害、财产或其他损失PMI不承担任何责任无论特殊、间接、因果还是补偿性的责任。PMI不明示或暗示地保证或担保本指南所含信息的准确性与完整性也不保证本指南所含信息能满足你的特殊目的或需要。PMI不为任何使用本标准或指南的制造商或供应商的产品或服务提供担保。 PMI出版和发行本指南既不代表向任何个人或团队提供专业或其他服务也不为任何个人或团队履行对他人的任何义务。在处理任何具体情况时本指南的使用者都应依据自身的独立判断或在必要时向资深专业人士寻求建议。与本指南议题相关的的信息或标准亦可从其他途径获得。读者可以从这些途径获取本指南未包含的观点或信息。PMI无权也不会监督或强迫他人遵循本指南的内容不会为安全或健康原因对产品、设计或安装进行认证、测试或检查。本指南中关于符合健康或安全要求的任何证明或声明都不是PMI做出的而应由认证者或声明者承担全部责任。序言项目管理协会和敏捷联盟特许编写本实践指南目的是在社区内建立对敏捷方法的更深入的理解。本实践指南的愿景是为项目团队提供相关工具、针对不同情景的的指导方针、对目前敏捷技术和方法的理解以获得更好的项目成果。在软件开发之外的各行各业中不同项目团队都在使用敏捷方法。我们两个组织都认识到在将产品和可交付成果推向市场时敏捷方法的发展要求我们需要有一种通用的语言、开放的思维和灵活运用的愿望。此外我们两个组织还认识到实现成功交付的方法多种多样。目前存在大量工具、技术和框架为达成期望的成果各团队可选择适合其项目和组织文化的不同方法和实践。《敏捷实践指南》核心委员会的成员们有着不同的背景并且使用不同的方法。有些委员会成员身为顾问有些则在组织内工作。他们都已经在工作中使用敏捷方法很多年。 1.引论欢迎阅读《敏捷实践指南》本指南是项目管理协会PMI和敏捷联盟携手努力的成果。负责编写本实践指南的核心创作团队成员分别来自这两个组织他们广泛汲取了当前拥有不同背景、信仰和文化的广大从业者和领导者的专业知识。本实践指南为项目领导者和项目团队成员提供实践指导帮助他们在项目规划和执行过程中适应敏捷方法。我们的核心创作团队发现目前人们坚定支持预测法而对转变为敏捷思维模式、价值观和原则的热情却不高本实践指南涵盖了项目敏捷性的实践方法。本实践指南就是一座桥梁可以帮助理解从预测法转向敏捷方法的途径。实际上二者之间也存在一些类似的活动例如规划尽管处理方式不同但两种情况下都会发生。我们的核心创作团队使用了敏捷思维模式来合作并管理本实践指南第一版的编写。随着技术和文化的的发展变化未来对本实践指南的更新和改进将反映现行的方法。与项目管理协会的标准写作风格相比在编写本实践指南时我们核心团队采用了一种更为轻松的、通俗易懂的写作风格。为了更好地阐明有关要点和概念本指南纳入新元素如提示、侧栏和案例研究。我们实际上变更的原因是为了加强本实践指南的可读性方便用户使用。本实践指南并不仅仅是为了帮助计算机软件开发行业解决敏捷方法应用问题因为敏捷方法的应用已经扩展到各种非软件开发环境中。制造、教育、医疗保健等其他行业日益向不同的敏捷程度发展这种超出软件行业的敏捷应用也属于本实践指南的范围。敏捷型学习除软件开发外教育业也为敏捷实践的扩展提供了良好的环境。世界各地的初中、高中和大学教师都开始使用敏捷方法营造一种学习文化。人们利用敏捷技术来为重要工作排优先级。面对面的交流、有意义的学习、自组织团队以及利用想象力的增量型学习和/或迭代型学习都是敏捷原则这些原则可能改变人们在课堂上的思维模式促进教育目标的实现。那么为何要编写《敏捷实践指南》又为何要现在编写呢项目团队使用各种形式的敏捷技术和方法至少已经长达几十年。伴随着敏捷方法迅猛的应用势头《敏捷宣言》明确阐述敏捷方法的价值观和原则。如今项目领导者和项目团队发现自己正处于一个日新月异的环境中技术进步呈现指数级增长客户对价值交付的要求日趋紧迫。敏捷技术和敏捷方法将有效地管理各种颠覆性技术。此外敏捷第一原则将客户满意视为最高要求而这也是交付让客户满意的产品和服务的关键。随着社交媒体的广泛使用快速而透明的客户反馈循环唾手可得。因此为保持竞争优势与时俱进各组织不能只关注内部而是要放眼外部世界关注客户体验。各种颠覆性技术正在通过降低进入门槛来迅速改变竞争环境。越来越多的成熟组织日趋复杂创新能力发展迟缓在为客户提供新的解决方案方面滞后。在竞争中这些组织发现小型组织和初创公司能够更快地生产出满足客户需求的产品。形势的不断变化将继续促使大型组织采用敏捷思维模式以保持竞争力和现有的市场份额。《敏捷实践指南》关注项目解决项目生命周期选择、实施敏捷方法和组织对敏捷项目的考虑因素。组织变革管理OCM对于实践的实施和变革必不可少但是由于它本身就是一门学科因而已经超出本实践指南的范围。希望了解组织变革管理有关指导方针的读者可参阅《组织变革管理实践指南》。颠覆性技术向云计算的过渡尤其促进了颠覆性技术的应用。全球各地的公司都在利用这种模式迅速廉价获取计算资源以进入传统市场。云计算要求减少预付款但会基于即付即用或按需付费的机制通过订阅服务随时付款。更新的应用程序、基础设施和平台以一种迭代的增量方式发布到云端与技术进步和不断变化的客户需求保持同步。范围内的事项范围外的事项在项目或团队层面实施敏捷方法在整个组织或创建敏捷项目集时实施敏捷方法涵盖行业调查中最流行的敏捷方法涵盖利基方法、特定公司的方法或不完整的生命周期技术在选择敏捷方法和/或实践时要考虑的适应性因素推荐或支持一个特定的方法/实践将敏捷与《PMBOK指南》的过程和知识领域对应起来变更或修改《PMBOK指南》的过程和/或知识领域讨论将敏捷应用扩展到软件开发以外消除软件开发行业对敏捷方法的影响请注意尽管敏捷方法在软件行业以外的其他许多行业的应用日益增多但本实践指南中包括软件业在项目或组织中实施敏捷方法时需要考虑的指导、技术和方法在项目或组织中如何实施敏捷方法的规范性分步说明通用术语的定义新术语和/或新定义本实践指南适用于对于预测法和敏捷方法难以取舍的项目团队、试图解决快速创新和复杂性问题的项目团队以及致力于团队改进的项目团队。本实践指南将提供有益的指导方针它们将有助于项目取得成功帮助项目团队顺利交付商业价值满足客户的期望和需求。 2.敏捷概述 2.1可确定的工作与高度不确定的工作项目工作包括可确定的工作和高度不确定的工作。可确定的工作项目具有明确流程他们在以往类似的项目中被证明是行之有效的。在完成设计后制造汽车、电器、建造住宅这些都是可确定的工作的例子其所设计的生产领域和过程通常都很好理解并且执行的不确定性和风险通常较低。新的设计、解决问题和之前做过的工作都是探索性的。它要求主题专家携手合作解决问题并创建解决方案。遭遇高度不确定的工作的人员包括软件系统工程师、产品设计师、医生、教师、律师、许多解决问题的工程师等。随着可确定的工作日益实现自动化项目团队也越来越多地从事高度不确定的工作从事这些工作就需要使用本实践指南所述的有关技术高度不确定的项目变化速度快复杂性和风险也高。这些特点可能会给传统预测法带来问题传统预测法旨在预先确定大部分需求并通过变更请求过程控制变更。而敏捷方法的出现是为了在短时间内探讨可行性根据评估和反馈快速进行。 2.2《敏捷宣言》及思维模式 2001年软件业思想领袖共同发表《敏捷宣言》正式宣告敏捷开发运动的开始《敏捷宣言》四大价值观我们正在通过亲自开发和帮助他人开发发现开发软件的更好方法。通过这项工作我们开始更重视个体以及互动而不是过程和工具可用的软件而不是完整的文档客户合作而不是合同谈判应对变更而不是遵循计划也就是说右栏中的项目固然有价值但我们更重视左栏中的项目源自这些价值观的十二大原则我们的最高目标是通过尽早持续交付有价值的软件来满足客户的需求欢迎对需求提出变更即使在项目开发后期也不例外。敏捷过程要善于利用需求变更帮助客户获得竞争优势要经常交付可用的软件周期从几周到几个月不等且越短越好项目实施过程中业务人员与开发人员必须始终通力协作要善于激励项目人员给予他们所需的环境和支持并相信他们能够完成任务无论是对开发团队还是团队内部信息传达最有效的方法都是面对面交谈可用的软件是衡量进度的首要衡量标准敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该能够始终保持步调稳定对技术的精益求精以及对设计的不断完善将提高敏捷性越了解交付的越快简洁即尽最大可能减少不必要的工作这是一门艺术最佳的架构、需求、设计将出自于自组织团队自觉团队要定期反省怎样做才能有效并相应地调整团队的行为敏捷思维模式四大价值观、十二大原则、实践敏捷思维模式由“价值观”定义以“原则”为指导并在许多不同的实践中体现敏捷实践者根据自身需求选择不同的实践在艾哈迈德·西德基 Ahmed Sidky 启发下出的模式将敏捷明确表述为一种思维模式它由《敏捷宣言》的价值观界定受《敏捷宣言》原则指导并通过各种实践实现。值得关注的是虽然术语“敏捷”在《敏捷宣言》发表后流行起来但今天项目团队所使用的方法和技术却在《敏捷宣言》发表前已经使用多年有些已经使用了几十年之久。 “敏捷”是一种方法、手段、实践、技术还是框架根据具体情况上述词语均适用。除非使用其他词语明显更为合适否则本实践指南使用“方法”一词。 “敏捷方法”是一个囊括了各种框架和方法的涵盖性术语。图2-4结合上下文将敏捷定位为一个总称它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段、实践。图2-4还将敏捷方法和看板方法视为精益方法的子集。这样做的原因是他们都是精益思想的具体实例都反映了诸如以下概念“关注价值”、“小批量”、“消除浪费” 精益看板敏捷 ScrumBanAup水晶FddDsdm和Fdd有借鉴Scrum和xp有借鉴Xp 一般而言可通过两种策略践行敏捷价值观和原则采用正规的敏捷方法它们为特意设计经证明可达成期望的成果。那么在变更和裁剪之前就需要花时间学习和理解敏捷方法。不成熟和随意的裁剪会让敏捷方法的效果大打折扣从而限制了收益。参见附录X2中的“建议”以一种适合项目背景的方式对项目实践进行变更以便在核心价值观或原则方面取得进展。使用时间盒创建功能或者使用特定技术迭代优化功能。在适用于特定项目背景下考虑将一个大项目划分为几部分发布。实现有助于项目成功的变更这些变更不必是组织的正式实践的组成部分。最终目标不是为了敏捷而敏捷而是为了客户持续交付价值流并达成更好的商业成果。 2.3 精益与看板方法看待精益、敏捷、看板方法三者之间关系的一种思路是将敏捷和看板方法视为精益思想的衍生物。换言之精益思想是一个超集与敏捷和看板方法拥有共性。这种共性非常相似重点在于交付价值、尊重人、减少浪费、透明化、适应变更、持续改善等方面。项目团队有时会发现将各种方法结合起来使用更为有用只要是对组织或团队有效的方法无论来源如何都应该采纳。无论使用什么方法目标都是为了实现最佳结果。看板方法受到最初的精益制造体系的启发专门用知识型工作。它在2000年代中期出现是当时非常盛行的敏捷方法的一种替代方法。看板方法不如某些敏捷方法规范破坏性也较小原因在于它是原始的“原地出发”方法。在有必要或适当的情况下项目团队可以相对轻松地应用看板方法并向其他敏捷方法发展。关于看板方法的更多信息请参见“附录A3敏捷和精益框架概述”。案例围绕看板方法以及其是否属于精益或敏捷运动可能总是会有大量讨论。看板从精益制造构思出来也围绕精益制造但更广泛地应用于敏捷环境中。 2.4 不确定性、风险、生命周期选择(stacy矩阵) 有些项目在项目需求以及如何使用现有知识和技术满足这些需求方面具有很大的不确定性。这些不确定因素可能导致大量变更和项目复杂性的提高。上述特点如图2-5所示随着项目不确定性的增加返工的风险和使用不同方法的需求也会增加。为了减轻这些风险的影响团队选择的生性周期要能够通过较少的工作增量解决项目的大量不确定性问题团队可以利用较少的工作增量验证自身的工作并且可以对接下来的工作做出相应变更。与静态书面规范相比当团队交付小的增量时他们能够更快更准确地理解真正的客户需求团队可以用明确稳定的管理要求规划并管理项目轻松解决各种技术挑战。但是随着项目不确定性的增加变更、做无用功和返工的可能性也会随之增加试错程度而这不仅代价高昂而且耗费时间。有些团队让项目生命周期发生演变以便使用迭代和增量方法。许多团队发现在探讨需求、更频繁地交付增量时团队会更容易适应变更。由于团队获得反馈这些迭代和增量方法减少了浪费和返工。这些方法应用了非常短的反馈循环频繁地调整过程重新进行优先级排序定期更新计划频繁交付要点简单项目、繁杂项目、复杂项目分别意味着什么考虑一些大型的项目比如波士顿“大开挖”隧道工程项目。表面上该项目似乎相当简单将高架公路移到地下。对需求也有高度的共识参见图2-5 Y轴。在项目开始之前项目继续推进的不确定性很低。而且像许多大型项目一样该项目在进行过程中也遇到了一些意外在从事一个几乎没有中间可交付成果或者几乎没有机会进行原型开发的项目时团队最有可能会使用预测型生命周期进行项目管理。团队可以根据其发现的情况做出调整但却无法使用敏捷方法管理新增迭代需求或增量交付成果进而获得反馈。 “大开挖”项目无论如何都不是一个简单的项目。但是许多项目一开始处于斯泰西复杂性模型的左下部分并无真正的手段转而使用其他方法。从需求和交付手段两方面对项目进行评估后确定了项目生命周期的最佳方法。对于涉及新颖的工具、技术、材料、应用领域的项目这些迭代、增量、敏捷方法非常有效参见第3章“生命周期选择”它们也适用于具有以下特点的项目需要研究和开发变更速度极快具有不明确或未知的需求、不确定性风险最终目标难以描述通过构建一个小的增量然后对其进行测试和评估团队可以在短时间内以低成本探索不确定性降低风险最大程度地实现商业价值的交付。这种不确定性可能集中于适用性和需求正在构建的产品是否正确、技术可行性和性能产品是否可以采用这种方法构建、过程和人员这是否为团队工作的一种有效方式。以上三个特点产品规格、生产能力、过程适用性通常都具有高度不确定的因素。不过迭代和增量管理方法也有其应用局限性。当技术和需求的不确定性都很高时图2-5 右上部分项目就会极端复杂陷入无序状态。为了使项目尽可能可靠需要遏制其中一个不确定性变量 3 生命周期选择项目有多种形式也有多种实施方式。项目团队需要认识到相关特征和方案以选择最可能使项目成功的方法本实践指南涉及四种生命周期分别定义如下预测型生命周期这是一种更为传统的方法提前进行大量的计划工作然后一次性执行执行是一个连续的过程迭代行生命周期这种方法允许对未完成的工作进行反馈从而改进和修改该工作增量型生命周期这种方法向客户提供各个已完成的、可能立即使用的交付成果敏捷生命周期这种方法既有迭代也有增量便于完善工作频繁交付非敏捷方法应该如何称呼并没有一个通用的术语用于描述非敏捷方法。起初本实践指南用术语“计划驱动型”描述强调提前计划然后再实施该计划。有些人更喜欢用术语“瀑布式”或“系列式”描述这种生命周期。最终我们选定使用术语“预测型”因为预测型在《项目管理知识体系指南》PMBOK指南和《项目管理只是体系指南PMBOK指南第5版--软件分册》中也曾用到许多组织都不曾遇到过这两种极端的情况而只遇到过某些中间情况。这是很正常的但我们仍然需要一种方法来讨论这两个极端。如果敏捷是其中一个极端我们将另一个极端称为预测型 3.1 项目生命周期的特征 4 种生命周期的特征方法需求活动交付目标预测型固定整个项目仅执行一次一次交付管理成本迭代型动态反复执行直至修正一次交付解决方案的正确性增量型动态对给定增量执行一次频繁更小规模交付速度敏捷型动态反复执行直至修正频繁小规模交付通过频繁小规模交付和反馈实现的客户价值需要注意的是所有的项目都具有这些特征没有一个项目能够完全不考虑需求、交付、变更、目标这些因素。项目的固有特征决定了其适合采用哪种生命周期另一种理解不同项目生命周期的方法是使用一个连续区间从一端的预测型生命周期到另一端的敏捷型生命周期连续区间中间还有更多的迭代型周期或增量型周期第六版《PMBOK指南》附录X3图X3-1将连续区间显示为一条直线。该图强调了从线的一端到另一端项目特征的变化情况。另一种形象化的方法是用一个二维正方形表示这个连续区间如图3-1所示没有哪个生命周期能够完美的适用于所有项目。相反每个项目都能在连续区间中找到一个点根据其背景特征实现最佳平衡预测型生命周期充分利用已知和已经证明的事物。不确定性和复杂性的减少允许项目团队将工作分解为一系列可预测的小组迭代型生命周期允许对部分完成或未完成的工作进行反馈从而对该工作改进和修改增量型生命周期可向客户提供完成的可交付成果让客户能够立即使用敏捷型生命周期它同时利用迭代属性和增量特征。团队使用敏捷方法时他们会对产品进行迭代创建完成的可交付成果。团队将获得早期的反馈并能提供客户可见性、信心、对产品的控制。由于团队可以提前发布产品而团队将率先交付价值最高的工作所以项目可以更早产生投资回报。 3.1.1 预测型生命周期的特征计划始终贯穿其中要记住的关键一点是每种生命周都有计划要素。生命周期的不同之处并非在于计划是否完成而在于完成了多少计划以及何时完成在连续区间的预测一端是计划驱动着工作。有多少计划就有多少提前执行的可能性。尽可能详细地定义需求。团队估算何时能够交付可交付成果并全面开展采购工作在迭代方法中也计划了原型和验证但是输出的目的是修改一开始所创建的计划。对未完成的工作的早期评审将有助于未来的项目工作与此同时增量方法计划交付整个项目后续部分。团队可以提前计划可交付成果的若干次连续交付或者一次只计划交付一个。可交付成果为未来的项目工作提供了相关信息敏捷项目也有计划。主要区别在于通过对频繁交付的可交付成果的评审团队将能获得更多的信息从而在此基础上进行计划和重新计划。无论采用哪种项目生命周期项目都需要计划。预测型生命周期预计会从高确定性的明确的需求、稳定的团队和低风险中获益。因此项目活动通常以顺序方式执行如图3-2所示为了实现这种方法团队需要详细的计划了解要交付什么以及怎样交付。当其他潜在变更收到限制时这些项目就会成功例如需求变更项目团队成员修改团队交付的成果。团队领导的目标是尽可能减少预测型项目的变更‘。团队在项目开始时创建详细的需求和计划时他们可以阐明各种制约因素。然后团队可以利用这些制约因素管理风险和成本。进而团队在实施详细计划时他们会监督并控制可能影响范围、进度计划或预算的变更。预测型项目强调根据部门划分的、有效的、顺序的工作并且通常不会在项目结束前交付商业价值。如果遇到变更或需求分歧或者技术解决方案变得不再简单明了预测型项目就将产生意想不到的成本。 3.1.2 迭代型生命周期的特征迭代型生命周期通过连续的原型或概念验证来改进产品或成果。每一个新的原型都能带来新的相关方新的反馈和团队见解。然后团队在下一周期重复一个或多个项目活动在其中纳入新的信息。团队可能会在长达数周时间的一个特定迭代中使用时间盒集中各种见解然后根据这些见解对活动进行返工。这样迭代有利于识别和减少项目的不确定性当项目复杂性高、变更频繁或当项目范围受到相关方对所需最终产品的不同观点的支配时采用迭代型生命周期会有优势。迭代型生命周期可能需要更长的时间因为它是为学习而优化而不是为交付速度而优化。增量是为了速度而交付 3.1.3 增量型生命周期的特征您是否曾经参与过这样的项目在项目过程中需求似乎每天都在变化您认为“我们在交付企业批准的原型时就会了解需求。”如果情况如此那么采用敏捷方法将有助于这个项目。原型法鼓励反馈并有助于更好地理解可纳入每个可交付成果的需求。有些项目优化是为了加快交付速度。许多企业和项目无法等待所有的事情全部完成这种情况下客户愿意接受整个解决方案的一个部分。这种少量可交付成果的频繁交付称为“增量型生命周期” 完整性和交付是主观的。团队可能需要获得关于原型的反馈然后可能选择将最小可行性产品(MVP)交付给部分客户。客户的反馈将帮助团队了解他们需要为随后交付的最终功能的完善提供些什么。敏捷团队的一个重要差异化优势在于他们会经常交付商业价值。由于产品的功能得到增加就能吸引更多的消费者因而我们就可以说它是增量交付的。与一次交付一个最终产品迭代型相比增量型生命周期将经常优化为项目发起人或客户交付价值的工作。在开始工作之前团队就计划了最初的的可交付成果他们还会尽快开始第一次交付的工作。某些敏捷项目在项目启动后几天内就开始交付价值。有的项目可能需要更长的时间从1周到几周时间不等。随着项目的继续团队可能会偏离最初的设想。由于可以更快地交付价值因而团队可以管理偏差。与客户在项目结束时获得价值相比确保客户能尽早获得价值其变更和差异程度的重要性变得不那么重要。因为可以频繁交付所以变更和差异可以更快得到纠正采用增量方法的一个例子是为客户提供一个单一功能或是交付一项完成的工作例如在继续修建大楼的其他部分之前施工人员可能希望先展示一间已完工的房间或一层楼。这种情况下在继续修建大楼的下一层前他们可能会为已完工的楼层布置家具、刷漆等。客户可以查看和批准有关样式、颜色和其他细节以便在进一步投入时间和金钱之前做出相应的调整。这样做将减少潜在的返工和 / 客户的不满。 3.1.4 敏捷生命周期的特征在敏捷环境中团队预料需求会发生变更。迭代和增量方法能够提供反馈以便改善项目下一部分的计划不过在敏捷项目中增量交付会发现隐藏或误解的需求。图3-5显示了实现增量交付的两种可能的方法这样将便于项目与客户需求保持一致并根据需要进行调整在基于迭代的敏捷中一次交付、各时间盒相等团队以迭代相等持续时间的时间盒形式交付完整的功能。团队集中于最重要的功能作为一个团队合作完成其工作。然后团队再集中于下一项最重要的功能并合作完成其工作。团队可决定一次进行若干功能的开发工作但团队不会同时完成所有的迭代工作即团队不会在完成全部分析等工作后再解决所有需求在基于流程的敏捷中多次交付、各时间盒不等由功能决定团队将根据自身能力从待办事项列表中提取若干功能开始工作而不是按照基于迭代的进度计划开始工作。团队定义任务板各列的工作流并管理各列的进行中的工作。完成不同功能所花费的时间可能有所不同。团队让进行中的工作的规模尽量小以便尽早发现问题并在需要变更时减少返工。无需利用迭代定义计划和审核点而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。敏捷生命周期是符合《敏捷宣言》原则的周期。特别是客户满意度将随着价值产品的早期交付和持续交付不断提升。此外功能性的、提供价值的增量可交付成果是衡量进展的主要尺度。为了适应更频繁的变更和更频繁地交付项目价值敏捷生命周期结合了迭代和增量方法。 3.1.5 敏捷适用性筛选器有各种评估模型可用来帮助确定使用敏捷方法的适合性或差距。这些模型评估项目和具有适应性和适用性的组织因素然后提供分数表明一致性或潜在风险领域。附录X3综合提供了各种流行的模型它们可用作敏捷适用性筛选器 3.1.6 混合生命周期的特征混合生命周期项目示例医药行业关系到人命所以对药物、对治疗的任何过程都需要做到精细某制药公司进入旷日持久的美国食品药品管理局FDA审批过程该过程一直延续到开发过程结束及整个生命周期如图3-6所示。当项目团队以一种敏捷的方式进行药物试验时为执行FDA的审批过程他们必须将药物展示给一个外部团队。一位顾问帮助将FDA的审批过程部分集成到敏捷开发过程中以创建一种更加合理的混合方法。先交付一部分可行性产品对外找受试群体进行试验本质与软件行业的灰度测试一致都是先找部分群体进行实验看产品有没有缺陷如果没重大缺陷就开始全量如果没问题就开始批量生产这个故事的简短版本是因为FDA的审批过程需要在开发过程结束时完成或者在发生任何变更之后重复执行这包括即使发生了最微小的变更后所以这个过程必须在开发过程结束后作为一个单独的阶段而存在。使用迭代过程集成并不成功因为迭代型只交付一次。药物需要多次交付以便进行多次试验来保障药物的安全、稳定。不过这位顾问创造了一些有用的快速入门指南和测试协议它们缩短了最终的FDA审批过程。 3.1.7 结合了敏捷和预测的方法另一种方法是在整个生命周期中结合使用敏捷方法和预测法在图3-7中在同一项目中结合使用了预测法和敏捷法。也许团队正在逐渐地向敏捷过渡并使用一些方法如短迭代、每日站会、回顾会但在项目的其他方面如前期评估、工作分配、进度跟踪等仍然遵循了预测法同时使用预测法和敏捷法是一个常见的情况。将这种方法称为“敏捷方法”是一种误导因为他显然没有充分体现敏捷思维模式、价值观、原则。不过由于这是一种混合方法所以称其为“预测法”也是不准确的 3.1.8 以预测法为主、敏捷方法为辅的方法图3-8所示为一个以预测法为主的项目中一个小的敏捷要素。在这种情况下以敏捷方法处理具有不确定性、复杂性、范围蔓延机会项目的一部分而使用预测法管理项目的其余部分。这种方法的一个例子是某工程公司正在使用一个新的组件建造一个设施。虽然大部分项目可能是常规的、可预测的就像组织实施的许多其他的设施项目一样但这个项目包含了一种新的屋顶材料。承包商可能计划首先在地面上进行一些小规模的安装试验以确定最佳的安装方法并在有足够时间解决问题时尽早发现问题随后通过试验和调整增量地改进过程 3.1.9 以敏捷方法为主、预测法为辅的方法图3-9描述了一个以敏捷方法为主、预测方法为辅的方法。当某个特定要素不可协商需求非常确定、技术非常确定或者使用敏捷方法不可执行时可能会使用这种方法。这种情况的例子包括集成由不同供应商开发的外部组件这些外部组件不能或不会以协作或增量方式合作。在组件交付后需要单独集成。 3.1.10 符合目的的混合生命周期某政府部门有一个信贷保险申请开发项目。这个多年期项目使用新的、响应能力更强的用户界面和系统集成来取代其过时的保险体系。项目的大部分使用敏捷方法实施并伴有持续的业务输入。保险费率根据经济合作与发展组织OECD下发的一个200页的规范进行计算。计算步骤解释非常清楚几乎不会有混淆机会也几乎没有中间结果需要企业确认并且计算步骤的编码由一个独立团队完成。两个团队合作计算所需的输入变量以及如何使用和显示输出值但除此之外计算团队在很大程度上以预测的方法工作。在计算团队的工作完成时屏幕和报告中就会显示保险费率计算的输出。随后企业用户提供关于外观和信息使用的反馈。这两个团队的工作同时进行但几乎不需要进行交互。让两个团队彼此空间上的靠近可以更容易地检查开发进度但它们主要还是独立的子项目项目团队可能基于项目风险设计一个混合生命周期。例如某校园建设项目可能会有很多个建筑需要改善和建设。增量方法会将资源集中使某些建筑比其他建筑更早完工从而加快投资回报。众所周知每个建筑的独自交付都能得益于该建筑独自采用预测型生命周期。项目管理的目标是在给定的当前环境下尽可能以最好的方式创造商业价值。项目采用敏捷方法抑或预测方法都无关紧要。要提出的问题是我们怎样做才能最成功当团队创造价值时是否需要反馈如果需要增量方法将会有所帮助。在探讨各种想法时。是否需要管理风险如果需要迭代方法或敏捷方法将会有所帮助。当组织无法交付中间价值时敏捷方法可能不是很有用。这样没有问题但为了敏捷而敏捷并不是目标。关键在于要选择一个对项目、风险、文化管理有用的生命周期或生命周期的组合。敏捷关乎频繁向客户交付。而这种交付要给团队带来反馈。团队利用上述反馈规划并重新规划下一部分的工作。 3.1.11 混合生命周期作为过渡战略许多团队无法在一夜之间切换到敏捷工作方式。对于那些已经习惯于预测型环境、并在其中获得成功的人士敏捷技术的观感截然不同。组织越大活动部件越多转换需要的时间就越长。因此计划一个渐进的过渡是有意义的渐进的过渡涉及要增加更多的迭代技术以便改进学习加强团队和相关方的一致性。之后还要考虑增加更多的增量技术以加快发起人的价值和投资回报。迭代为了学习而改进增量为了速度和投资回报/商业价值而改进上述各种方法的组合被视为一种混合方法可以先在一个风险不大、具有中低程度不确定性的项目中尝试这些技术。在组织成功地使用混合方法后再尝试更复杂的项目这些项目需要增加更多的技术。这是一种根据组织的情况、特定的风险以及团队适应并接受变革的就绪情况而调整的渐进混合过渡 3.2 混合敏捷方法敏捷团队很少将其实践局限于一种敏捷方法。每个项目背景都有各自的独特性比如团队成员技能和背景的不同组合开发中的产品的各个组成部分工作环境中的年龄、规模、关键性、复杂性、监管制约因素等敏捷框架并不是针对团队定制的。为了定期交付价值团队可能需要对实践进行裁剪。通常团队都会实践各自特殊的敏捷组合即便他们使用一个特定的框架作为起点也不例外协调方法裁剪敏捷框架的一个例子是一个广泛使用的常见协调方法涉及到协调使用Scrum框架、看板方法、极限编程XP方法的要素。 Scrum为产品待办事项列表、产品负责人、Scrum主管、跨职能开发团队的使用提供指导包括冲刺计划Sprint、每日例会、冲刺Sprint评审、冲刺Sprint回顾会议看板面板帮助团队进一步提高效率方法是将工作流可视化、使障碍更容易被察觉通过调整在制品WIP限制来实现流程管理受极限编程XP启发的工程实践如使用故事卡、持续集成、重构、自动化测试、测试驱动开发将进一步提高敏捷团队的效力总之与孤立采用各种实践相比协调这些不同来源的实践将产生更好的协同效果 3.3 影响裁剪的项目因素有时为了更好地配合根据项目属性对方法进行裁剪表中列出了一些要考虑的项目因素和裁剪方案关于影响裁剪的因素的更多指导请参见附录X2“影响裁剪的属性” 项目因素裁剪方案需求模型稳定型或偶发型许多团队发现使用节奏以定期时间盒的形式能帮助他们演示、回顾、理解新任务此外有些团队在接受更多任务时需要更多的灵活性团队可使用基于流的敏捷方法利用节奏实现两全其美团队经验水平所要求的过程改进速度更频繁地回顾并选择改进措施工作流往往被各种延误或障碍打断考虑利用看板面板让工作可见对工作过程的不同领域尝试限制从而改进工作流产品增量的质量不佳考虑利用各种测试驱动开发的实践这种防错机制使缺陷难以不被发现创建某个产品需要不止一个团队从一个敏捷团队扩展到数个敏捷团队同时只有轻微干扰首先要了解敏捷项目集管理或者正规扩展框架其次要精心制定一种适合项目背景的方法项目团队成员缺乏使用敏捷方法的经验考虑从培训成员敏捷思维模式和敏捷原则的基本原理开始如果团队决定使用特定的方法如Scrum 或看板kanban则要针对上述方法举办研讨会让团队成员学习如何使用 4 实施敏捷创建敏捷环境 4.1 从敏捷思维模式开始使用敏捷方法管理项目要求项目团队采用敏捷思维模式。以下问题的答案将有助于制定实施策略项目团队如何以敏捷方式行动为了使下一交付周期受益团队需要快速交付哪些成果并获得早起反馈团队如何以一种透明的方式行动为了专注于高优先级的项目可以避免哪些工作仆人式领导对团队达成目标有何益处 4.2 仆人式领导为团队赋权敏捷方法强调仆人式领导是一种为团队赋权的方法仆人式领导是通过对团队服务来领导团队的实践仆人式领导注重理解和关注团队成员的需要和发展旨在使团队尽可能达到最高绩效仆人式领导的作用是促进团队发展和定义敏捷仆人式领导实践并传播敏捷仆人式领导按照以下顺序从事项目工作目的与团队一起定义“为什么” 或目的以便他们能围绕项目目标进行合作互动。整个团队在项目层面而不是在人员层面优化各尽所能。因才分工每个人做自己最拿手的工作人员目标确立后鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献过程不要计划遵循“完美”的敏捷过程而要注重结果。如果跨职能团队能够常常交付完成的价值并反思产品和过程团队就是敏捷的。团队将其过程称作什么并不重要以下仆人式领导的特征让项目领导变得更加敏捷促进团队成功提升自我意识倾听为团队服务帮助他人成长引导与控制促进安全、尊重、信任促进他人精力和才智提升仆人式领导并不是敏捷所独有的。但经过实践仆人式领导通常能了解到仆人式领导是怎样融入敏捷思维模式和价值观的领导在发展自身仆人式领导或促进技巧后他们就更愿意成为敏捷践行者。因此仆人式领导可以帮助他们的团队通过合作更快地交付价值成功的敏捷团队信奉成长思维模式团队成员自己能够学到新技能。如果团队和仆人式领导都相信自己能够学习那么所有人的能力都能得到提高 4.2.1 仆人式领导的职责仆人式领导通过管理关系在团队内和组织中建立沟通与协作。这些关系可以帮助领导在组织中得心应手地为团队提供支持。这种支持有助于消除障碍促进团队理顺过程。由于仆人式领导了解敏捷在应用具体方法时践行敏捷因而他们能帮助满足团队的需要 4.2.1.1 仆人式领导的促进作用项目经理成为仆人式领导时工作重点从“管理协调”转向“促进合作”。促进者将帮助每个人各尽所能地思考和工作。促进者鼓励团队参与、理解、并对团队输出共同承担责任。促进者帮助团队创建可接受的解决方案仆人式领导促进团队内部和团队之间的合作与对话。例如仆人式领导在团队内部和团队之间帮助发现瓶颈问题并进行相应沟通。然后团队将解决这些瓶颈问题此外促进者还鼓励大家通过交互式会议、非正式对话、知识共享展开写作。仆人式领导要通过成为公正的搭桥者和教练来做到这一点而不是代替其他责任人做出决策 4.2.1.2 仆人式领导消除组织障碍《敏捷宣言》的第一个价值观关乎个人与过程和工具的交互。对仆人式领导而言更好的职责是认真审视那些阻碍团队敏捷或组织敏捷的过程并努力使其合理化。例如如果一个部门需要大量文档仆人式领导的角色就能发挥作用他们可以与部门合作审查所需的文档就敏捷交付如何满足这些需求达成共识提供协助并对所需的文档数量进行评估从而使团队能够将时间更多地用于提供有价值的产品而不是创建详尽的文档仆人式领导还应该关注其他冗长的过程这些过程往往造成瓶颈问题阻碍团队或组织的敏捷性。可能需要处理的过程或部门的例子包括财务部门、变更控制委员会、审计部门。仆人式领导可以与他人携手合作共同质疑和审核他们的过程为敏捷团队和领导提供支持。例如对团队而言每两周交付一个工作产品仅仅是为了让产品进入队列或过程而冗长的发布过程却可能需要6周或更长时间这样做有什么好处呢太多的组织都有这些“瓶颈”过程正是它们阻碍了团队快速交付有价值的产品或服务。仆人式领导有能力改变或消除这些组织障碍为交付团队提供支持 4.2.1.3 仆人式领导为他人贡献铺路在敏捷中团队管理其工作过程及其工作产品。自我管理和自我组织适用于所有为组织和项目提供支持的人。仆人式领导为满足团队、项目、组织的需求而工作。仆人式领导可以在团队工作场所与团队一起工作与管理层一起工作使团队能够一次专注于一个项目或者与产品负责人合作与团队共同开发故事。有些仆人式领导与审计人员合作改善监管环境中所需的过程有些仆人式领导与财务部门合作帮助组织向增量预算过渡。仆人式领导注重为团队铺路让团队尽其所能。仆人式领导影响项目鼓励组织以不同方式思考 4.2.1.4 考虑这些仆人式领导的职责仆人式领导可能有很多头衔但最重要的还是他们所做的工作。以下是一些仆人式领导的职责示例教育相关方使其了解为什么要敏捷以及如何敏捷。根据优先级说明商业价值的好处对被赋权团队加强问责提高工作效率并通过更频繁的评审改进质量通过指导、鼓励、帮助为团队提供支持。倡导团队成员的培训和职业发展。“我们通过支持的方式领导团队“这句话说的是领导在发展团队成员时所扮演的角色。通过支持、鼓励和专业发展团队成员将获得信心承担更多的职责并在组织中做出更大的贡献。仆人式领导的一个关键作用是培养和发展团队成员帮助他们超越自身当前的角色即使团队将失去他们也在所不惜通过技术项目管理活动如量化风险分析来帮助团队。有时团队成员可能并不具备在某些角色或功能方面的知识或经验。对相关技能有更多接触或接受过相关培训的仆人式领导可以通过提供培训或开展这些活动来为团队提供支持庆祝团队的成功为团队与外部团队合作提供支持并起到桥梁作用。创造相互欣赏的积极氛围建立加强合作的良好意愿人际关系技能与专业技能除仆人式领导外团队成员还要重视自身的人际关系技能和情商技能而不仅仅是专业技能。团队中的每一个人都要努力展示更多的主动性、正直、情商、诚实、合作态度、谦逊、以不同方式沟通的意愿才能促进整个团队的携手共进团队需要上述技能才能对项目方向的变化和技术产品的变更做出积极应对。只有每个人都能适应工作并彼此适应整个团队才更有可能迈向成功 4.2.2 项目经理在敏捷环境中的角色项目经理-产品负责人-敏捷教练-开发团队跨职能的自组织团队其实不需要项目经理开发产品和产品负责人足以很好地完成工作项目经理在敏捷项目中的角色有些是未知的原因是许多敏捷框架和方法都不涉及项目经理的角色。一些敏捷实践者认为并不需要项目经理的角色因为自组织团队承担了项目经理之前的职责。不过务实的敏捷实践者和组织认识到在许多情况下项目经理都能够创造重要的价值。关键的区别在于他们的角色和职责看起来有些不同 4.2.3 项目经理应用仆人式领导第六版《PMBOK指南》将项目经理定义为“由执行组织委派领导团队实现项目目标的个人” 许多项目经理已经习惯于作为项目的协调中心负责跟踪团队的状态并向组织中的其他成员反映。当项目被分解为孤立的功能时。这种方法没有问题。然而对于高不确定性项目项目的复杂性是一个人所无法管理的。而跨职能团队既能协调自身的工作还能与业务代表产品负责人开展合作从事敏捷项目工作时项目经理的角色就会从 “团队的中心” 转变成 “为团队和管理人员提供服务”。在敏捷环境中项目经理充当仆人式领导其工作重点转变为“引导需要帮助的人促进团队的合作保持与相关的需要一致”作为仆人式领导项目经理要鼓励将责任分配给团队成员分配给那些掌握完成任务所需知识的人。 4.3 团队构成《敏捷宣言》的价值观和原则的一个核心宗旨是“强调个人和交互的重要性”。敏捷优化了价值流强调了向客户快速交付功能而不是怎样“用”人团队在考虑如何优化价值流时以下好处是显而易见的人员更有可能合作团队更快地完成有价值的工作由于不从事多任务也不必重新建立环境团队减少了时间浪费 4.3.1 敏捷团队敏捷团队注重快速开发产品以便能获得反馈。在实践中最有效的敏捷团队往往由 3 到 9 个成员组成。理想情况下敏捷团队应该集中在一个团队工作场所工作集中式面对面工作团队成员100%为专职成员只专注当下工作。敏捷团队鼓励自我管理团队由团队成员决定谁执行下一阶段定义的范围内的工作。敏捷团队与仆人式领导一起茁壮成长。领导支持团队的工作方法跨职能敏捷团队频繁创造功能性增量。这是因为团队集体对工作负责并共同拥有完成工作所需的所有必要技能。无论整体的敏捷方法是什么团队越是限制其在制品团队成员就越有可能通过合作来加快整个团队的工作倡导专注当前工作不要多任务。在成功的敏捷团队中团队成员在工作中以各种方式开展合作如结对、群集、群体开发因而他们会协同工作而不会落入迷你瀑布的陷阱中。团队在给定时间解决所有的需求然后试图完成所有的设计继而又去完成所有的构建就会发生迷你瀑布的情况中间缺失了反馈。使用这个场景在构建中或构建后测试中的某一时刻团队可能会意识到原先的假设已经不再有效。这种情况下团队解决所有的需求根本是在浪费时间。相反当团队成员合作打造全部功能中的少量功能时随着工作的推进和交付少量已完成的功能他们也在不断学习敏捷项目得益于项目团队结构这种结构能改善团队内部和团队之间的合作。下表展示了团队成员如何通过合作提高工作效率和促进创造性地解决问题成功敏捷团队的属性属性目标 1. 专门人员专心致志提高工作效率少于 10 人39人 2. 跨职能团队成员频繁开发与交付作为一个独立团队交付完成的价值为完成任务整合所有工作活动从团队内部和外部如产品负责人提供反馈 3. 集中办公或有能力应对办公地点不同带来的任何挑战改善沟通提高团队动力知识共享降低学习成本能够致力于相互合作 4. 由通才和专家组成的混合团队专家提供专门技能通才提供从事工作的灵活性团队具有专业能力往往成为通才型专家他们既有专长又有多种技能经验 5. 稳定的工作环境彼此依赖实现交付。成员基本不发生变动对工作方法相互认同简化团队成本核算运转率知识资本的保有和发展 4.3.2 敏捷的角色敏捷团队中有三种常见的角色跨职能团队成员产品负责人团队促进者敏捷团队角色角色描述跨职能团队成员跨职能团队成员包括具有生产可行性产品所需的各种必要技能的团队成员在软件开发中跨职能团队通常包括设计人员、开发人员、测试人员、其他所需的角色跨职能开发团队包括能够以常规节奏交付潜在可发布产品的专业人员跨职能团队至关重要原因是他们能够在尽可能短的时间内交付已完成的、高质量的、无外部依赖关系的任务产品负责人PO 产品负责人指导产品的开发方向产品负责人根据商业价值对任务进行排序产品度责任与团队开展日常合作提供产品反馈为将要开发/交付的下一个功能设定方向这意味着产品负责人的任务不大往往能一张索引卡就能描述产品负责人与相关方、客户、团队合作定义产品开发方向通常产品度责任拥有相关工作背景会为决策提供丰富的专业知识技能有时产品负责人需要请求有关人员提供帮助如具有丰富的专业领域知识的架构师或具有丰富客户经验的产品经理产品负责人需要关于如何组织和管理整个团队工作流的培训敏捷开发中产品负责人将为团队创建待办事项列表或者与团队共同创建待办事项列表帮助团队了解怎样在不产生浪费的情况下交付最大的价值敏捷团队的一个关键成功因素是强烈的产品责任感如果不重视为客户创造最大价值敏捷团队就可能创造一些不被理解的功能、或者价值不高的功能因而会浪费精力团队促进者敏捷团队常见的第三个角色通常为团队促进者也是一种仆人式领导上述角色也称为项目经理Scrum主管、项目团队领导、团队教练、团队促进者所有敏捷团队在团队中都需要有仆人式领导人员需要时间来建立自己的仆人式领导技能包括引导、指导、消除障碍技能起初在内部培训能力不足时很多组织会邀请外部敏捷教练提供帮助外部教练拥有经验优势但缺点是在客户组织关系中关系薄弱另一方面内部教练虽然可能在本组织中拥有强大的人际关系但他们却可能缺乏足够的经验让自己的工作卓有成效 4.3.3 通才型专家 “I”型人才和 “T”型人才有些人在一个领域非常专业但是在这个领域之外他却很少做出贡献。在敏捷领域这种人才被称为“I”型人才。就像字母“I”一样这种人有深度但却缺乏广度。 “T”型人才能够通过支持在一个领域补充自身的专业知识他们在相关领域的技能虽有所欠缺但拥有良好的合作技能。例如一个人能够测试一些领域的产品还能开发其他不同领域的产品他就被认为是一个“T”型人才 T型人才有一个明确的、公认的专业化的主要角色同时还具有必要时与人协作、帮助他人的技能、多种才能及能力。这种协作减少了移交工作以及只有一个人能够完成特定工作所带来的制约因素敏捷团队是跨职能的但其人员往往不会一开始就做到这样。不过许多成功的敏捷团队都由通才型专家组成他们也称为“T”型人才这意味着这些团队成员在具备一项擅长的专业化技能的同时还拥有多种技能的工作经验而不是单一的专业化。由于密切协作和自我组织敏捷团队成员才能够敏捷开发并迅速完成工作而这就需要使互相帮助成为常态。敏捷团队成员都要致力于培养这样的特质一个人的能力大小无关紧要。如果给团队其他成员带来瓶颈问题集中于某一个人的能力甚至是有害的。团队的目的是优化已完成的工作并获得反馈如果客户希望获得好的结果如快速交付功能并且质量优良那么团队就不能仅仅为了尽可能有效利用资源而构建专门的角色。团队的目标是提高过程效率优化整个团队的产能。团队规模小会促进团队的合作。产品负责人的工作是确保团队从事最高价值的工作 4.3.4 团队结构许多行业的团队都会采用敏捷原则和实践。他们将人员组织到跨职能团队中迭代开发工作产品案例编写本实践指南的核心团队拥有不同的的背景他们有些人代表项目管理协会有些人代表敏捷联盟。他们是自组织团队以增量方式来完成了这项工作。项目管理协会召集一个主题专家小组来检查工作这使得团队能够在开发过程中纳入反馈并改进产品。然而该核心团队并不代表典型的敏捷团队因为其成员并不是100%专职从事这项工作。有些组织已经能够建立集中办公的跨职能团队还有组织有不同的情况。有些组织并不是所有团队成员都为集中办公而是拥有分布式或分散式团队。分布式团队可以在不同地点拥有多个跨职能团队。分散式团队可能会让各团队成员分别在不同的地点工作或在办公室或在家里。鉴于通信成本的增加这些安排并非理想但它们仍然是可行的案例美国一家大型金融机构有一个项目设有一组团队其团队成员分别在美国东海岸和印度的几个地点工作。一开始团队是一个大型分散式团队用户体验设计人员、分析师、开发人员、测试人员他们从事“追逐太阳”追逐太阳的开发过程是一种每天结束时将工作移交给下一工作地点可能相差很多时区的方法旨在为加快产品的开发的开发实践团队成员有些工作时间彼此重叠以便进行工作交接。团队成员一起召开每日例会利用网络摄像头让所有团队成员都能参加会议。在美国工作的关键角色分析师、产品负责人、用户体验设计人员、开发人员会先开始回答其印度团队成员的问题帮助他们消除障碍随着产品规模越来越大投入资金也越来越多他们决定分成5个小团队。为此他们决定在不同的地点建立有组织的、分布式团队。他们决定在各个地点建立由开发人员和测试人员组成的的、相互协作的跨职能团队他们也有一组核心分析师在美国的两个地点工作。他们与其他在美国工作的产品经理和产品负责人合作然后再分别与各个团队合作。尽管他们安排了一些结构将产品评审作为一个完整的项目进行但是大多数其他活动都是在团队层面进行的这对于每个团队而言是最有效的因为他们能够自组织 4.3.5 专职小组成员如果团队成员并非100%为团队专职工作会有什么情况发生遗憾的是这种情况虽然并不理想但有时却无法避免让一个人在团队中只投入25% 或 50%的能力这带来的关键问题是他们会进行多任务处理和任务切换。多任务处理会降低团队工作的产出并影响团队预测交付能力的一致性任务切换时人员工作效率的损失在20%到40%之间。随着任务数量的增加效率损失会呈指数级增长当一个人在两个项目之间进行多任务切换时他投入到每个项目上的精力并非各占 50% 。相反由于存在任务切换成本他在每个项目上的投入降低到20%到40%之间人们在一心多用的的时候更容易犯错误。任务切换消耗工作记忆人们在多任务处理时不太可能记住相应工作的背景当团队中所有的人都被分配到一个项目时他们能够作为一个团队持续协作从而使每个人的工作更加有效关于在敏捷环境中团队工作的更多提示请参见表A1-1“项目管理过程组与知识领域”请特别关注“项目资源管理”知识领域的有关过程要点多任务处理减缓了整个团队的进展因为团队成员要浪费时间切换环境和/或互相等待完成其他工作。当人员100%为团队专职工作时团队最有可能最快地产出不是所有团队都拥有自身需要的所有角色。例如有些团队需要获得数据库管理员或研究分析师的支持。当一个团队临时委派专家时重要的是确保每个人对此要有相同的期望。这位专家是100%专职分配给团队的吗分配多长时间对每个人专家和团队设定期望阐明团队承诺交付的水平。分配兼职人员会给项目带来风险因为兼职不能100%投入案例由于编写本实践指南的核心团队成员无法100%全力投入团队的工作他们的产出要比他们分工协作专职投入项目低得多。然而从经济角度而言协作是划算的。但是即便他们分散工作并将全部产能的一小部分投入项目让他们集中并全力协作也是不可行的。因此团队将分散工作识别为潜在的风险。团队通过使用协作工具来跟踪和监督他们的工作进度并根据个人的能力来调整工作分配 4.3.6 团队工作场所团队需要一个工作场所他们可以一起工作了解他们作为团队的状态并进行协作。有些敏捷团队的所有成员都集中在一个房间里工作。有些团队拥有一个团队工作场所用于开例会以及张贴各种图表但团队成员分别在各自的小隔间或办公室里独立工作随着各公司迈向开放、协作的工作环境组织也必须为需要不间断时间来思考和工作的员工创造安静的空间。因此各公司纷纷设计各自的办公室以平衡公共和社交区域有时被称为“公共区”与个人工作不被打扰的安静区域或私人区域拥有在不同地点工作的成员时团队会决定他们各自的工作场所有多少是虚拟的多少是实际的。诸如文档共享、视频会议、其他虚拟协作工具等技术可以帮助人员实现远程协作在不同地点工作的团队需要虚拟的工作空间。另外要考虑让团队成员定期聚集一堂以便建立信任学习怎样开展合作。分散式团队管理沟通的一些技术包括鱼缸窗口和远程结对通过在团队分布的各个地点之间建立长期视频会议链接创建一个鱼缸窗口。每天工作开始时人们打开链接工作结束时关闭连接。通过这种方式人员可以自然地看到彼此并进行互动减少了身处不同地点所固有的协作滞后问题通过使用虚拟会议工具来共享屏幕包括语音和视频链接建立远程结对。只要考虑了时区差异因素这种方法几乎和面对面的结对一样有效要点来自不同职能部门、拥有不同技能的人员共同组成团队。培养管理者和领导的敏捷思维模式在敏捷开发早期就让他们参与其中 4.3.7 客服组织孤岛组建敏捷团队的最好开端是构建一个拥有基本信任和安全的工作环境以此确保所有团队成员都有平等的话语权他们的意见都能被听到并的到考虑。这一点再加上构建敏捷思维模式都是潜在的成功因素在此基础上所有其他挑战和风险都能够化解孤岛组织往往给跨职能敏捷团队的组建带来重重障碍。需要构建跨职能团队的团队成员通常需要向不同的管理人员报告管理人员会采用不同的标准衡量他们的绩效。管理人员需要关注的不是资源利用效率而是过程效率和基于团队的指标为克服组织孤岛问题就要与团队成员的不同管理者合作让他们为跨职能团队安排必要的专职人员。这样不仅能建立团队协调而且能让组织看到怎样用人才能优化正在进行中的项目和产品有关团队的更多信息请参见附录X2影响裁剪的属性要点作为敏捷项目领导首先要把重点放在如何组建跨职能团队让所有团队成员100%投入团队工作。即使这只是意味着关键团队成员如开发人员和测试人员每天一起工作和交流但也是迈向正确敏捷方向的一步 5 实施敏捷在敏捷环境中交付 5.1 项目章程和团队章程每个项目都需要一个项目章程这样项目团队就能了解项目之所以重要的原因、团队的前进方向、项目的目标。不过对于团队而言仅有项目章程还不够。敏捷团队需要有团队规范以及对一起工作方式的理解。这种情况下团队可能需要一个团队章程制定章程的过程能帮助团队学习如何一起工作怎样围绕项目协作对于敏捷项目而言团队至少需要项目愿景和目标以及一组清晰的工作协议。敏捷项目章程要回答一下问题我们为什么要做这个项目这是项目愿景谁会从中受益如何受益这可能是项目愿景和/或项目目标的一部分对此项目而言达到哪些条件才意味着项目完成这些是项目的发布标准我们将怎样合作这说明预期的工作流仆人式领导可以促进章程的制定过程。团队可以通过一起工作实现协作而制定项目章程是一种很好的开始工作的方式。此外团队成员可能希望通过协作了解他们将如何一起工作只要团队知道如何一起工作制定章程就不需要一个正式的过程有些团队可以从团队制定章程的过程中受益。下面是对团队成员制定章程的一些建议可以将其作为制定团队社会契约的基础团队价值观例如可持续的开发速度和核心工作时间工作协议例如“就绪”如何定义这是团队可以接受工作的前提“完成”如何定义这样团队才能一致地判断完整性考虑时间盒使用工作过程限制基本规则例如有关一个人在会议上发言的规定团队规范例如团队如何对待会议时间仆人式领导可以与团队一起决定处理其他行为请记住团队的社会契约即团队章程将规定团队成员之间彼此互动的方式。团队章程的目标是创建一个敏捷的环境在这个环境中团队成员可以发挥他们作为团队的最大能力 5.2 常见敏捷实践 5.2.1 5.2.8 节描述了一些最常见的敏捷项目实践 5.2.1 回顾回顾是最重要的一个实践原因是回顾让团队学习、改进、调整其过程回归可以帮助团队从之前的产品开发工作及其过程中学习。《敏捷宣言》背后的原则之一是团队要定期反省如何能够做到更加有效并相应地调整团队行为。许多团队使用迭代尤其是为期两周的迭代因为迭代在最后会提示进行演示和回顾。不过团队回顾并不需要迭代。团队成员可以决定在这些关键时刻进行回顾当团队完成一个发布或者加入一些功能时。这不一定是一个巨大的增量。它可以是任何发布无论它有多小自上次回顾以来又过了几周时间当团队出现问题时以及团队协作完成工作不顺畅时候当团队达到任何里程碑时团队可以通过分配足够的时间学习受益无论无论是在项目中间回顾还是在项目结束时回顾。团队需要了解他们的工作产品和工作过程。例如有些团队在完成工作时遇到困难。团队可以计划用充足的时间组织回顾以此收集数据、处理数据、再决定之后要尝试的实验做法首要的是回顾并不是责备回顾是让团队从以前的工作中学习并做出小的改进回顾针对定性的人的感觉和定量的衡量指标数据然后利用这些数据找到根源设计对策并制订行动计划。项目团队可以采取许多行动事项来消除障碍考虑限制行动事项的数量使团队在即将进行的迭代或工作期间有能力改进。尝试一次改进太多的事情却没有完成其中任何一件比计划完成较少的事情并成功完成要糟糕得多。然后在时间允许的情况下团队可以进行列表中的下一个改进。团队选择改进时要决定如何衡量结果。然后在下一段时间内要衡量结果以验证每个改进成功与否来自团队的一位促进者引导团队通过一个活动对所有改进事项的重要性进行排序。完成改进事项的排序后团队下一次迭代选择合适的数量或者在流程基础上增加工作 5.2.2 待办事项列表编制待办事项列表是所有工作的有序列表它以故事形式呈现给团队。工作开始之前不需要为整个项目创建所有的故事只需要了解第一个发布的主要内容正确即可然后就可以为下一个迭代开发足够的项目产品负责人或者产品负责人价值团队包括产品经理和产品领域的相关产品负责人可能会制作一个产品路线图以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规划路线图关于路线图的示例请参见附录X3“敏捷适用性筛选工具” 5.2.3 待办事项列表的细化在基于迭代的敏捷中产品负责人往往在迭代中期的一次或多次会议中与团队合作为了获得反馈以便做出准确的交付成果为即将进行的迭代准备一些故事。这些会议的目的是细化足够的故事让团队了解故事内容以及故事之间的相互关系至于细化过程应该有多长时间还没有达成共识。有一个连续区间基于流程的敏捷的即时细化。团队将下一张卡片从待办事项列表中拿出来讨论许多基于迭代的敏捷团队在两周的迭代中用1小时的时间盒讨论。团队选择一个迭代持续时间为他们提供足够频繁的反馈基于迭代的敏捷团队的多次细化讨论。团队可以在陌生的产品、产品领域或问题领域使用这一技巧细化会议上产品负责人可以向团队介绍故事的创意让团队了解故事中潜在的挑战或问题。如果产品负责人不确定依赖关系还可以请求团队对相应功能进行刺探以了解风险产品负责人有很多方法处理待办事项列表的细化准备与会议其中包括鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作一起讨论和撰写故事把整个故事的概念呈现给团队。团队进行讨论并根据需要将其细化为许多故事与团队一起寻找各种方法探索和撰写故事确保所有的故事都足够小以便团队能源源不断地交付完成的工作。考虑每天至少完成一个故事团队通常有一个目标就是每周用不超过1小时的时间来为下一批工作细化故事。团队希望把时间尽可能花在工作上而不是计划上。如果团队需要每周花1小时以上的时间来细化故事那么产品负责人可能会过度准备或者团队可能缺乏评估和细化工作所需的一些关键技能 5.2.4 每日站会团队成员利用每日站会对彼此做出小的承诺发现问题并确保团队工作顺利进行为每日站会规定时间盒不超过15分钟。团队以某种方式“过一下”看板或任务板而团队中的任何人都可以主持站会在基于迭代的敏捷中每个人都轮流回答下列问题基于迭代的敏捷每日站会关注反馈上次站会以来我都完成了什么从现在到下一次站会我计划完成什么我的障碍或风险或问题是什么从这样的问题得出的答案能够让团队自我组织并让团队成员为完成之前和整个迭代中承诺完成的工作承担彼此的责任基于流程的敏捷有一种不同的方法可以将注意力集中在团队的产出上。团队从右到左越往右越接近最终成果对看板进行评估。每日站会的问题包括基于增量的敏捷每日站会关注可交付成果和开发速度我们还需做些什么来推进这一工作有人在做看板上所没有的事情吗作为一个团队我们需要完成什么工作流程是否存在瓶颈和障碍站会常见的一个反模式是站会变成状态报告会议。传统上在预测环境中工作的团队可能倾向于采用这种反模式状态报告会议因为他们习惯于报告状态。另一个典型的反模式是当问题变得明显时团队才开始解决问题。站会是为了发现存在的问题而不是解决它们。将问题条件到停车场区然后创建另一个会议它可以在站会之后立即召开并在会上解决问题团队可以举办自己的站会。只要提现了团队工作需要的密切合作进行顺利站会变回非常有用。要针对团队何时需要站会、站会是否有效等问题有意识地做出决定要点要鼓励团队成员主持会议而不是由项目经理或领导主持以确保每日站会不会变成状态报告会议而是作为团队进行自我管理和相互承诺的会议 5.2.5 展示/评审当团队以用户故事的形式完成待定功能时团队会定期展示工作产品。看过展示后产品负责人接受或拒绝故事在基于迭代的敏姐中团队在迭代结束时展示所有已经完成的工作项。在基于流程的敏捷中基于增量团队在需要时展示完成的工作通常是当完成的功能累积到足以构成一个连贯组合时。团队包括产品负责人在内都需要反馈来决定何时需要产品反馈一般的指导方针是每两周至少展示一次团队的工作产品。这种频率对于大多数团队来说是足够的这样团队成员就可以得到反馈防止他们朝着错误的方向前进。这种频繁也足够频繁让团队可以保持产品开发足够清晰按照自己希望或需要的频率构建一个完整的产品使项目敏捷的一个基本要素是频繁地交付产品。一个没有展示或发布的团队其学习的速度不会快并且很可能并未采用敏捷技术。团队可能需要额外的引导来保证频繁的交付 5.2.6 规划基于迭代的敏捷不同团队的能力各不相同。不同产品负责人的典型故事大小也各不相同。团队应考虑自身故事大小避免提交更多的故事而超出团队在一个迭代中工作的能力产品负责人了解当人员不可用时例如公共假期、度假期间、阻止人员参加下一组工作的任何事情团队能力降低。团队将无法完成与前一期相同的工作量。在能力降低的情况下团队只会计划相应能力能够完成的工作团队估算能够完成的工作这也是一种能力的衡量示例参见4.10节。团队不能100%确定自己能交付什么因为他们无法知道意外情况。当产品负责人拆分故事使其变小时团队看到的是产品的完成进度团队就会知道他们将来能够做什么敏捷团队在一个工作块中不会只计划一次。相反敏捷团队会开始计划一点交付、学习然后在一个持续的循环中重新规划更多的东西。要点将团队的注意力吸引到反模式并帮助团队发现如何改进站会 5.2.7 帮助团队交付价值的执行实践如果团队不重视质量很快就会无法快速发布任何东西一直在修bug、或者产品不受市场喜欢被迫停止下面的技术实践中很多都来自于极限编程他们可以帮助团队以最快的速度交付【持续集成】无论产品如何都要频繁地将工作集成到整体中然后再进行重新测试以确定整个产品仍然按照预期工作【在不同层面测试】对端到端信息使用系统级测试对构建块使用单元测试在两者之间了解是否需要进行集成测试以及在何处进行测试团队发现冒烟测试有助于测试工作产品是否良好团队发现决定何时以及对哪些产品运行回归测试可以帮助他们在维护产品质量的同时良好地构建性能敏捷团队非常偏爱自动化测试因此他们借此构建和保持交付的势头【验收测试驱动开发 ATDD Acceptance Test Driven Development】在ATDD中整个团队聚集一堂讨论工作产品的验收标准。然后团队创建测试这让团队能够编写足够的代码进行自动化测试满足标准要求。对于非软件项目要考虑怎样在团队完成大量价值时对工作进行测试【测试驱动开发TDDTest Driven Development、行为驱动开发BDDBehavior-Driven Development】在编写/创建产品之前编写自动化测试实际上可以帮助人员设计产品防范产品错误。对于非软件项目要考虑如何通过“测试驱动”团队的设计。硬件和机械类项目经常使用模拟进行设计的中间测试【刺探时间盒研究或实验】刺探对学习很有用可以在诸如评估、验收标准定义、通过产品了解用户行为的流程中使用在团队需要学习一些关键技术或功能要素时刺探会很有帮助 5.2.8 迭代和增量如何帮助交付工作产品迭代可以帮助团队为交付和多种反馈创建一个节奏。团队会为交付和反馈创建增量交付的第一部分是一次演示。团队会收到关于产品的外观和运行方式的反馈团队成员回顾如何检查和调整有关过程以取得成功演示或评审是敏捷项目流程的必要组成部分。为团队的交付节奏安排适当的演示 5.3 解决敏捷项目的挑战出于解决具有高变化率、不确定性、复杂性、的项目相关问题的需要敏捷方法应运而生。由于这些原因敏捷方法包含了各种各样的工具和技术用于处理预测法中出现的问题。要点团队应该经常为反馈进行演示并展示进度。鼓励PMO项目管理办公室和其他感兴趣的人观看演示以便决定项目组合的人能够看到实际的进展。敏捷的痛点和解决痛点的可能性痛点解决痛点的可能性团队目标或任务不明确敏捷章程中关于目标的部分愿景、使命、使命测试团队工作协议不明确敏捷章程中关于一致性的部分价值观、原则、工作协议团队环境不明确敏捷章程中关于环境的部分边界、承诺资产、前瞻性分析需求不明确帮助发起人和相关方制定产品愿景考虑使用实例化需求、用户故事地图、影响地图来构建产品路线图让团队和产品负责人一起来明确需求的期望和价值逐步将路线图分解为具有更少具体需求的待办事项列表用户体验不佳开大团队的用户体验设计实践应在早期就让用户经常参与估算不准确通过分解故事来让故事变小让整个团队使用相对估算进行估算考虑通过敏捷建模或刺探来理解故事工作分配、工作进展不明确帮助团队认识到自我管理工作考虑用看板面板查看工作流程考虑利用每日站会根据看板面板查看工作进展团队面临障碍仆人式领导能帮助消除这些障碍如果团队不知道他们都有哪些可选方案就要考虑聘请教练有时团队或仆人式领导无法消除障碍团队就需要上报故事由于产品待办事项列表不够完善导致工作延误 / 超时产品负责人和团队一起研讨故事为故事创建一个准备就绪的定义考虑分拆故事以使用更小的故事缺陷考虑对特定环境有效的技术实践它们可能是结对工作、产品集体负责制、普适测试测试驱动方法、自动化测试方法、稳健的完成的定义工作未完成团队确定故事完成的定义包括验收标准在内为项目补充发布标准技术债务代码质量降级重构、敏捷建模、普适测试、自动化代码质量分析、完成的定义产品复杂性过高无论是软件项目还是非软件项目都要常常鼓励团队思考最简单的有效方法是什么并应用“简洁尽最大可能减少不必要的工作这是一门艺术”的敏捷原则这样做将有助于降低复杂性团队合作过程进展缓慢或没有改善在每次回顾中选择的改进项目不要超过三个让仆人式领导帮助团队学习怎样整合这些待改进项前期工作过多导致返工不要做过多的前期工作而要考虑让团队通过刺探来学习另外在项目开始时衡量在制品WIP看看哪些部分团队并不需要设计只需要交付价值缩短迭代并创建一个稳健的完成的定义错误的开始前功尽弃让产品负责人成为团队不可分割的一部分产品待办事项列表杂乱无序按价值排序并考虑延迟成本按持续时间CD3和其他价值模型划分仓促 / 等待不均匀的工作流程计划要对应团队的能力而不是超出能力所及要求人员停止多任务为一个团队专注工作请团队利用结对、群集、群体开发、等等方法平衡整个团队的能力相关方要求无法满足仆人式领导与这个相关方可能是产品负责人一起工作意想不到或不可预见的延误让团队更频繁地检查使用看板面板检查工作流和在制品WIP限制了解需求对团队或产品的影响在障碍板上跟踪障碍和障碍消除情况孤立的团队而不是跨职能团队让项目人员作为跨职能团队自我组织使用仆人式领导技巧帮助管理人员理解为什么敏捷需要跨职能团队 5.4 敏捷项目的衡量指标过渡到敏捷意味着要是用不同的衡量指标使用敏捷意味着要对审视团队和管理层都很重要的新指标这些衡量指标很重要因为它们关注的是客户价值状态报告的一个问题是团队预测完成或使用交通灯来描述项目的能力。例如项目领导将项目描述为“90%完成”。此时团队正试图将一个个片段集成到一个产品中。团队发现有缺少的需求或者意外的出现或是产品没有按照他们的想法集成项目只是完成了一半而交通灯状态报告并未反映项目真实状态。项目团队往往认识到他们还需要同样长的时间才能完成项目的剩余部分。太多的项目存在这种情况由于发现了问题团队才认识到自己最多只完成了10%的工作预测型衡量指标的问题在于它们往往并不反映真实的情况。往往直到发布日期前1个月项目状态绿灯一直是亮的这种项目有时被称为“西瓜项目外面绿里面红”。项目状态灯经常会变成红色似乎没有任何警告因为直到发布日期前1个月才会得到关于项目的经验数据敏捷项目的衡量指标包含有意义的信息这些信息提供了历史记录因为敏捷项目要定期交付价值完成的工作。项目团队可以利用这些数据改进预测和决策替代衡量指标如完成百分比不如经验指标如完成的工作更有用。有关价值管理的更多信息请参见4.10节。敏捷帮助团队发现问题和难题以便团队能够诊断和解决问题除了定量指标之外团队还可以考虑收集定性衡量指标。其中一些定性衡量指标侧重于团队选择的实践评估团队使用这些实践的情况例如对交付功能的业务满意度、团队的士气、团队希望跟踪的任何东西等都是定性衡量指标 5.4.1 敏捷团队的衡量结果敏捷倾向于使用基于经验和价值的衡量指标而不是预测型衡量指标。敏捷衡量团队所交付的成果而不是团队预测将交付的成果对于一个习惯于掌握项目基准、估算的挣值、投资回报率ROI 的团队可能会对实施一个项目而不是管理一个基准感到茫然。敏捷是基于对客户有可见价值的工作产品基准通常是尝试预测的产物。在敏捷中团队的估算最多限于未来几周时间即只估算下一个迭代的工作。在敏捷中如果团队工作的可变性不高如果团队成员没有从事多任务则团队的能力就会变得稳定。这样才能对未来几周做出更好的预测完成迭代或流程中的工作后团队就可以进行重新规划。敏捷并不能创造出更多的工作能力。然而有证据表明工作量越少人员就越有可能交付与其他知识型工作一样软件产品开发关乎在交付价值的同时进行学习。在项目的设计部分硬件开发和机械开发是相似的。学习的过程是通过实验来实现的项目设计能交付微小的价值增量并获得对目前已完成工作的反馈。其他许多产品的开发项目也包括学习项目发起人通常想知道项目什么时候能够完成。一旦团队建立了稳定的速度每个迭代的故事或故事点的平均数量或平均周期时间团队就能够预测项目将花费多长时间举例来说如果团队平均每个迭代有50个故事点而团队估算还剩下大约500个点于是团队估算还剩下大约10个迭代。随着产品负责人对剩余的故事进行细化团队对估算进行细化项目估算虽然可能有升有降但团队却能提供一个估算。如果团队平均完成每个故事的周期为3天还有30个故事要完成那么团队将需要90个剩余工作日大约4-5个月用飓风图反映估算的可变性也可使用发起人能够理解的其他一些可变性衡量方法由于学习是项目的重要组成部分因而团队需要在平衡不确定性的同时为客户提供价值。团队要规划项目要完成的下一个小部分。团队报告经验数据并重新规划其他小的的增量以此管理项目的不确定性。基于迭代的敏捷团队的衡量标准某些基于迭代的项目使用燃尽图查看项目随时间的进展情况。图5-1显示了一个燃尽图的例子其中团队计划交付37个故事点。故事点怼需求或故事的相关工作、风险、复杂性进行评估。许多敏捷团队使用故事点估算工作量。燃尽图中的虚线表示计划。图5-1中团队可以看到在第3天他们面临交付的风险某些项目团队更喜欢用燃起图显示已完成的工作。如图5-2所示的燃起图中的数据与图5-1相同图5-1和图5-2都是基于相同的数据但分别以两种不同的方式显示。团队可以选择如何查看他们的数据看到在迭代中尚未完成的工作时团队可能会变得沮丧并且可能因为急于完成工作而不满足验收标准。不过团队可能有很多理由不按预期完成工作。燃尽图显示了团队成员的多任务处理、过于庞大的故事或团队成员缺勤的效果特别是对新建的敏捷团队燃起图将显示迭代过程中范围内的变化。利用燃起图团队能查看他们已经完成的工作这将有助于团队进行下一项工作无论使用燃尽图还是燃起图团队都能看到在迭代过程中完成的的工作。在迭代结束时他们可能会根据自己在这个迭代中完成工作的能力多少故事或故事点来建立他们下一个迭代的能力衡量指标。这样产品负责人与团队一起重新规划团队就更有可能在下一个迭代中成功交付速度即本次迭代中实际完成功能的故事点大小的总和让团队得以通过观察历史表现来更准确地规划下阶段的能力要点团队可能会发现可能需要四到八次迭代才能达到稳定的速度。团队需要从每个迭代中获得反馈了解他们的工作量情况以及该如何改进基于流程的敏捷团队的衡量指标基于流程增量流程最后一环是交付的敏捷团队使用不同的衡量指标交付周期交付一个工作项目花费的总时间从项目添加到看板直至项目完成、周期时间处理一个工作项目所需的时间、响应时间一个工作项目等待工作开始的时间。团队通过衡量周期时间发现瓶颈和延迟问题问题不仅限于团队内部看板面板的好处任务直接在面板上显示可以清晰的看出瓶颈和问题。因为增量式敏捷开发是多次交付最小可行产品所以需要时刻关注任务的各种情况和状态看板面板更加适合燃尽图、燃起图因为没有任务显示所以只能看出来已完成任务的多少。由于迭代型敏捷开发只交付一次所以只需要关注任务剩余量距离全部完成的剩余时间。燃起图、燃尽图信息比较少的图表更加适合看板面板示例如图5-3所示就绪此列有限制可以随时将一些内容换成其他内容周期时间从开始任务到完成任务的时间交付给客户交付周期从写在看板上直至交付的时间由于就绪一列中各项的顺序可以变更因而这是不可预测的交付周期有助于理解从第一次查看特定功能到向客户发布该功能所需的周期时间。在制品WIP限制位于各列顶部此处在框中显示让团队了解如何从看板上提取工作。达到WIP限制后团队就不能将工作从左边提取到下一列。此时团队就要从最右边的列中提取工作并提出问题“作为一个团队我们应该怎样做才能将这项工作移到下一列中” 每个功能都是独一无二的所以每个功能的生命周期时间也是独一无二的。不过产品负责人可能会注意到较小的功能周期时间也较短。产品负责人希望看到产出因此产品负责人创建较小的功能或者与团队合作创建燃起图、燃尽图能力衡量指标和交付周期、周期时间可预测的衡量指标对于实时测量非常有用。它们可帮助团队了解他们共有多少工作以及团队是否能按时完成工作故事点衡量与已完成的故事燃起图故事点的衡量或功能的衡量增量-看板有所不同。有些团队试图在没有完成实际功能或故事的情况下衡量故事点。团队仅衡量故事点时衡量的是能力而不是已完成的工作这违背了“可用的软件或者如果不是软件则是其他的产品是衡量进度的主要指标”的原则每个团队都有自己的能力。在使用故事点燃起图、燃尽图时团队要认识到在给定时间内能够完成的故事点数量对一个团队而言是唯一的每个人的完成时间不一样所以这里说“唯一” 要点当团队依赖于外部人员或团队时衡量周期时间可了解团队完成工作所需的时间。团队完成工作之后衡量交付时间可了解外部依赖关系。团队还可以测量反应时间响应时间从准备就绪到第一列的时间了解平均需要多长时间才能对新请求做出响应根据自身的指标单位进行衡量团队就能更好地评估和估算自己的工作并最终交付。相对估算的缺点是无法比较各个团队或者在团队之间增加速度因为每个团队成员的能力是不一样的所以相对估算时与其他成员的指标比较是无意义的相对估算比较适合与自身的指标进行比较团队可以在一个功能燃起图 / 燃尽图和一个产品待办事项列表中衡量已完成的工作。这些图表提供了随时间变化的完成趋势。如图5-4所示功能燃起图 / 燃尽图可显示项目期间需求的发展。【完成的功能数量线】显示团队以正常速度完成功能。【功能总数】显示了项目的总功能随时间的变化。【剩余的功能数量线】显示功能完成速度的变化每次在项目中添加功能时燃尽线都会有改变在敏捷中的挣值是基于已完成的功能如图5-5所示。产品待办事项列表燃起图显示已完成的工作与区间里程碑或迭代中的预期工作总量的比较一个团队一次只能完成一个故事。为了完成一个包含多个故事的大功能团队会有待完成的剩余故事并且除非拥有更多的时间否则可能无法完成整个功能。团队可以用一个产品待办事项列表燃起图来显示已完成的价值如图5-5所示如果一个团队需要衡量挣值可以考虑使用燃起图以图5-6为例请注意左边y轴代表了故事点的范围右边y轴代表项目的支出传统的挣值管理EVM 衡量指标如进度绩效指标SPI 和成本绩效指标CPI可以很容易地转换为敏捷术语。例如如果团队计划在一次迭代中完成30个故事点但是只完成了25个那么SPI进度绩效指标是25/30 或者 0.83该团队的工作速度只有计划的83%。同样CPI是迄今为止的劳动价值已完成的功能值除以实际的成本如图5-6所示$2.2M / $2.8M 0.79这就意味着与计划相比仅能得到79美分的结果当然这假定了预测仍然正确图5-7中所示的累积流图显示了看板上进行中的工作。如果一个团队有许多等待测试的故事测试团队将会扩大。累计工作可一目了然团队在处理累积工作方面有困难团队有进行中的工作而不是已完成的工作。如果团队有大量进行中的工作就会延迟整体功能的交付。团队的交付时间越长在相同时间内有更多功能团队的压力就越大 6 关于项目敏捷性的组织考虑因素如果组织能够做出相应调整则可以提高项目敏捷性的效率和适应性每个项目都存在于组织环境下。文化、结构、政策可能会影响到所有项目的方向和成果。这些动态变化可能会对项目领导提出挑战项目领导可能无法根据自己的意愿来改变组织动态文化但可以有技巧地引导这些动态变化本章探讨了组织以及在某些情况下项目环境影响项目的方式。领导可以通过探讨变革方案来提高项目成功率 6.1 组织变革管理组织变革管理一节涵盖了会影响敏捷应用情况的技能和技术 PMI出版物《组织变革管理实践指南》介绍了成功引入有意义变革的全面整体性方法。该指南提供的建议包括说明变革动态变化的模型实现变革的框架项目、项目集、项目组合层面的变革管理实践的应用 6.1.1、6.1.2节探讨了特定敏捷环境中变革管理的考虑事项图6-1显示了“敏捷方法、变革管理”这两个主题之间的关系 6.1.1 变革管理驱动因素所有项目都涉及到变革。但是有两种主要因素会进一步激励敏捷环境中变革管理实践的应用【与加快交付相关的变革】敏捷方法强调频繁并尽早交付项目输出。但是接收组织可能尚未做好加速纳入这些输出的充分准备。加速交付将会考验组织适应该交付的能力。成功发现和交付项目功能是不够的。如果组织抗拒项目输出则会延迟目标投资回报。客户接受并支持项目输出在敏捷环境中日益盛行【与敏捷方法相关的变革】组织在刚开始采用敏捷方法时也会经历更高程度的变革。高级别协作可能需要团队、部门、供应商之间更频繁地交流。将工作分解到迭代原型时会涉及到不利的返工。领导应考虑利用变革管理技术来解决过渡到敏捷方法时所遇到的阻碍 6.1.2 变革就绪情况组织在开始采用敏捷方法时应了解这些方法与其当前方法之间的相对兼容性。某些组织的特征可能更容易支持跨部门协作、持续学习、内部过程演变等敏捷原则。这些变革友好型特征的示例包括 1.管理层的变革意愿管理层支持才容易落实变革2.组织在员工认知、审核、评估方式上做出改变的意愿组织自身支持变革也要组织员工积极参与到变革中3.集中或分散项目、项目集、项目组合管理职能集中或分散主要目的是为了让敏捷尽快得到适应4.专注于短期预算和指标而不是长期目标因为敏捷的原则是频繁地尽早交付最小可行性产品5.人才管理成熟度和能力相反还有一些机构特征可能会成为实现组织敏捷性相关变革的障碍。这些特征示例包括 1.工作被分解为部门孤岛从而创造出阻碍加快交付的依赖关系而不是构建在能力中心指导下的跨职能团队能力中心指导下的跨职能团队说明是团队的核心说明产出被重视说明跨职能的互动比较多2.采购策略基于短期定价策略而不是长期能力敏捷价值观和原则是可用的软件3.奖励领导的依据是本地效率而不是端到端项目交付或整体优化情况就组织而言4.员工属于特定领域人才实现技能多元化的工具或激励有限不重视培养 T型专家人才5.分散化项目组合使员工同时分配到过多的项目而无法专注于单个项目组织审查和修改这些实践的意愿程度将决定采用敏捷方法的速度和效率。但是为了解决这些敏捷组织障碍项目领导可以尝试多种方法来加速文化兼容性 1.积极明确的管理层支持2.变革管理实践包括沟通和引导3.逐个项目应用敏捷实践4.向团队增量地引入敏捷实践5.通过采取适用的敏捷技术和实践示范引导 6.2 组织文化组织文化就是组织的DNA -- 组织的核心标识文化始终影响敏捷方法的使用组织文化一直在连续运转从高预测型计划到一切皆为实验的精益创业阶段均有体现。尽管敏捷方法与精益创业文化相当吻合高预测型组织可以鼓励实证的衡量指标、小型试验和不断学习以便向敏捷方向转变 “文化能把战略当早餐吃” Culture eats strategy for breakfast.【彼得·德鲁克Peter Drucker】这句名言强调了人的承诺和热情对于一份事业的重要性。无论您在团队中实施何种策略或计划其成功与否将会受到实施该计划的人员的控制。如果推动策略的人员对变革没有热情甚至漠视工作和组织则您可能没有机会实施变革吃下去的战略是什么文化就容易是什么。 6.2.1 创建安全环境组织文化难以改变但组织中最重要的文化规范 -- 愿意尝试任何新方法或技术 -- 将有利于构建安全的工作环境只有在安全、诚实、透明的环境中团队成员和领导才可以真正反思其成功确保项目持续进步或者应用从失败项目中所吸取到的教训不再重蹈覆辙 6.2.2 评估文化每个项目都会遇到相关方意愿相左的棘手情况。团队如何在不影响质量的情况下取得快速进展团队如何在保留灵活性的同时确保时效性更重要的是团队如何满足客户需求项目领导可能感觉其职责就是满足各个相关方的期望但是在面对选择时通常需要根据组织业务环境的文化和要求来确定优先级。例如移动电信项目偏重于速度而政府项目可能偏重于大众化和稳定性要引导这些动态变化项目领导应花费时间去评估组织通常所关注的重点。图6-2显示了有关如何评估的示例。在例子中项目领导发起了与相关方、团队成员、高层管理的对话以讨论组织优先级。这些优先级根据滑动标尺在这两个极端之间的位置来进行记录然后再利用该结果去找到最适合这些优先级的敏捷技术有一些模型可用于评估这些动态变化但是采取何种模型或方法并不重要关键是让项目领导了解其环境的驱动因素。了解某组织需要满足的组织与行业需求后才能选择合适的对话、权衡尤其是技术 6.3 采购和合同如本实践指南中前面所述《敏捷宣言》认为“客户协作高于合同协商”。许多项目失败源于客户供应商关系破裂。如果合同相关方怀有非赢即输的想法通常会给项目带来更多的风险。心态要好要积极拥抱变化积极复盘成功和失败思考原因并制定可借鉴和需优化的方向并严格落实执行。共担风险共享奖励形成迭代精进协作方法提倡共担项目风险和共享项目奖励的关系同甘共苦实现所有方共赢。设计这种动态特性的合同签署技术包括 1.【多层结构】除了在单层文档中正式说明整个合同关系项目方可以通过在不同文档中说明不同方面来提高灵活性。通常固定项目如担保、仲裁可以锁定在主协议中。同时所有方将可能会变更的其他项目如服务价格、产品说明列在服务明细表中。合同主要服务协议中注明这些服务参考。这样做的目的也可以帮助动态修改时方便最后范围、进度计划、预算等更多动态变化项目可以列在轻量级说明书中。通过将合同中的更多变化因素隔离到单独的文档中将会简化修改工作并提高灵活性2.【强调价值交付】许多供应商关系是由专注于中间人为因素的固定里程碑或 “阶段关口” 控制的而不是由增量业务价值的完全可交付成果控制的。通常这些控制会限制利用反馈来改进产品与之相反的是里程碑和支付项目可以根据价值驱动可交付成果来构建以增强项目敏捷性3.【总价增量】项目可以将范围分解为总价微型可交付成果如用户故事而不是将整个项目范围和预算锁定在单个协议中。对于客户而言这可以更好地控制资金流向。对于供应商而言这可以限制对单个功能或可交付成果的过多承诺所带来的财务风险。4.【固定时间和材料】客户在采用传统的时间和材料方法时会产生不必要的风险。一种替代方法是将整体预算限制为固定数量。这就允许客户在最初未计划的项目中纳入新的观点和创新。固定预算倒逼选择最有价值的内容进行开发。如果客户需要纳入新的观点则必须管理给定能力用新的工作来替代原有工作。应密切监控工作防止所分配的时间超过其限制。此外在认为有用的情况下还可以在最大预算中规划额外应急时间5.【累进的时间和材料】另一种替代方法是共担财务风险法。在敏捷方法中质量标准是已完成工作的一部分。因此如果在合同期限之前交付则可对供应商的高效率进行奖励。相反如果供应商延迟交付则将扣除一定费用6.【提前取消方案】如果敏捷供应商在仅完成一半范围时便可交付足够的价值且客户不再需要另外一半范围则不必支付这部分费用。但合同中可以规定客户应为项目剩余部分支付一定的取消费用。因为不再需要这些服务客户可以限制预算敞口而供应商也可获得可观的的收入。刺探开发甲方先付全款如果供应商交付的部分成果可以满足全部价值则后面的开发就不需要了供应商支付甲方合同内约定的款项7.【动态范围方案】对于具有固定预算的合同供应商可为客户提供在项目特定点改变项目范围的方案。客户可调整功能以适应该能力。这样客户便可利用创新机会同时限制供应商的过度承诺风险8.【团队扩充】大多数协作合同方法是将供应商服务直接嵌入客户组织中。通过资助团队而不是特定范围可以保留客户自行确定需要完成工作这方面策略的权力。比如人力外包9.【支持全方位供应商】为了分化风险客户可能需要采取多供应商策略。但是这样签署合同的结果是每家供应商只能负责一项工作这就会产生许多依赖关系阻碍可行服务或产品的交付。关系越多越复杂相反要强调提供全面价值的合约这与已完成独立功能集中的观点相符可以创建敏捷合同。敏捷是在协作和信任的共同基础上建立的。如果有供应商能够尽早频繁地交付价值则有助于实现这一点。如果客户能够提供及时反馈则有助于实现这一点要点文化 VS 结构有些人坚持在开始各种文化转型前构建新的组织结构。还有些人持相反意见认为新型组织结构只是表面的调整只有集体文化朝着有意义的方向转变才是根本。实际上任何一方都孤掌难鸣。如果要实现敏捷项目领导应同时考虑其组织中这两个方面的当前和未来状态 6.4 商业实践在需求生产时组织创建新能力的意愿和能力即组织敏捷性的标志有创新意愿还要有实现意愿的能力。动起来。对于关注敏捷及敏捷所提供结果的组织而言这些不必是颠覆性的变革破坏性较小。透明和开放协作至关重要在跨职能团队交付价值时团队和个人可能会遇到组织多种支持职能方面的问题如果团队定期交付价值财务部门可能有机会以不同的方式获得产品收益。如果团队与其他组织签署了合同采购部门可能需要变更这些合同以帮助其他组织频繁地交付价值并与团队保持同步即不需要等合同上的日期压着已交付的价值。可以通过修改合同让其他组织可以尽早的参与团队开始以团结协作的方式展开工作后将会对内部管理策略提出挑战。人力资源可能注意到个人激励不足而经理可能会在自组织员工的绩效评估方面绞尽脑汁。在各种情况下都有机会评审现有实践对敏捷工作方式的支持程度集思广益。当组织发展到更高敏捷阶段时其他业务部门将有必要更改其交互方式并履行自己的职责。现在应拥护对组织其他领域有益的变更以此来提高整个组织的效率 6.5 多团队协作和依赖关系扩展多个项目之间会产生依赖关系即使不在给定项目集中进行管理。因此有必要了解敏捷工作在现有项目集和项目组合管理环境下的工作方式 6.5.1 框架大多数流行敏捷方法如 Scrum、XP极限编程的指导关注于单个小型且通常是集中办公的跨职能团队活动。这对于需要单个团队的工作非常有用但对于需要在一个项目集或项目组合中进行多个敏捷团队协作的举措却显得捉襟见肘目前已出现许多框架如大规模敏捷框架、大规模敏捷开发和规范敏捷和方法例如 Scrum of Scrums来应对这种情况。有关这些框架和方法的更多详细信息请参见附录A3 6.5.2 考虑事项有多种扩展工作的方式。团队可能需要将多个敏捷项目工作扩展到单个敏捷项目集中。或者组织可以设计出支持整个项目组合中不同敏捷方法的结构例如可以从小项目着手然后尽快了解组织环境中比较适合的方式。即使一切还未完全转换到敏捷方法团队仍可获得成功无论采用哪种方法关键成功因素是健康的敏捷团队。如果单个团队采取敏捷方法无法获得成功则勿尝试将其扩展到更大范围而要先行解决阻止团队敏捷工作的组织障碍大规模敏捷项目的目标是协调不同团队的工作以便为客户提供价值。这有多种实现方式。团队可以采用正式的框架或应用敏捷思维调整现有项目集管理实践 6.6 敏捷和项目管理办公室PMO 设立 PMO项目管理办公室 product manager office 的目的是引导组织实现商业价值。可以通过帮助实现项目目标来做到这一点。PMO有时还会提供团队教育或安排培训、项目支持。PMO 项目管理办公室还会针对给定项目或项目集提供相关商业价值方面的管理建议由于敏捷会带来文化变更随着时间的推移组织可能也需要变更包括 PMO。例如经历会决定资助的项目及其时间团队会决定培训或建议需求 6.6.1 敏捷PMO 为价值驱动型所有项目都应在合适的时间为合适的受众提供合适的价值 PMO 项目管理办公室的目标是帮助促进这个目标的实现。基于敏捷的PMO项目管理办公室方法以客户协作思维为基础并存在于所有PMO项目集中。在许多情况下这意味着PMO的运营方式类似于咨询企业帮助敏捷团队实现商业价值想办法、出主意需要根据给定项目的特定需求来定制其工作。有些项目可能需要工具和模版还有些项目可能会从管理层引导中获益。PMO项目管理办公室应努力按需交付并紧跟客户需求确保了解并适应他们的需求。这种内部创业方法专注于能为所支持的项目提供最大价值的PMO活动 6.6.2 敏捷PMO 为面向创新型为了在基于价值的章程下加速发展PMO项目管理办公室可能需要强制执行某些解决方案或方法例如保持所有人行动的一致性以快速获得成功。但需要确保员工的参与意愿才能提高效率。只邀请感兴趣的人员参与PMO服务即可实现这一点。PMO实践的参与度越高便更容易提高这些实践的“粘合力”。如果PMO为其客户提供了价值则客户很可能会要求这种服务并采用其实践 6.6.3 敏捷PMO 为多学科型为了支持特定项目需求PMO 项目管理办公室还需要熟悉项目管理本身以外的其他一些能力因为不同的项目要求不同的能力。例如一个项目可能需要组织设计来解决人员配备挑战而另一个项目可能需要组织变革管理技术来确保相关方参与或获得独特的业务模型以支持客户目标某些组织已将其PMO转换为卓越敏捷中心以提供以下服务 1.【制定和实施标准】提供用户故事、测试案例、累积流图等模板提供敏捷工具并培训支持小组了解迭代开发概念2.【通过培训和指导发展人才】协调敏捷培训课程、教练、导师以帮助员工过渡到敏捷思维模式并升级其技能。鼓励和支持员工参与本地敏捷活动3.【多项目管理】通过不同项目交流协调敏捷团队。考虑分享进度、问题、回顾性发现和改进实验等内容。借助适当的框架帮助管理项目层的主要客户发布和项目组合层的投资问题4.【促进组织学习】收集项目进度信息并获取、存储、记录回顾性发现成果5.【管理相关方】提供产品负责人培训指导验收测试以及评估方法并提供系统反馈。宣扬主题专家SME对项目的重要性6.【招聘、筛选、评估项目领导】制定敏捷实践者访谈指南7.【执行专业化项目任务】培训和提升回顾的促进者与敏捷项目问题解决者订立协议并提供导师和教练 6.7 组织结构组织结构会严重影响其转向新信息或转变市场需求的能力。下面列出了主要特征 1.【地理】地理分散的项目组织可能会在各种项目中发现阻碍工作进展的一些挑战。项目领导和区域经理可能持有不同或相反的目标。此外文化差异、语言障碍、低可视化可能会降低工作效率。幸运的是采用敏捷方法可以鼓励更好的协作并提高信心。在这些环境下项目领导应鼓励团队和管理层对话定制该环境所需的技术并管理对工作的期望2.【职能结构】有些组织按照高度项目型、矩阵型、高度职能型的方式构建。具有高度职能结构的项目可能会在组织内部协作方面遇到很大阻力3.【项目可交付成果的大小】缩小项目可交付成果将会激励部门之间更频繁的交流由此带来更频繁的交互以及组织内部更快速的价值流动4.【项目人员分配】另一种方法是在各个部门中抽出一个人将其临时完全分配到最高优先级项目5.【重采购型组织】有些组织选择主要供应商实施项目。尽管项目目标可能非常明确供应商也有责任监管自己的财务状况。但是供应商完成其义务并退出合约后相关项目知识也将随之带走。这就会限制持续灵活性和速度所需的内部能力。如果在供应商还参与时采用敏捷技术例如回顾和跟踪可能改进的领域保持长期记录则可帮助缓解产品知识缺失的情况 6.8 组织演变应对单个挑战领域或实施新的混合或敏捷方法时建议以累积方式承接工作。常用实践是将变更过程视为一个敏捷项目团队可以根据自己的价值观或其他考虑事项引入自己的变更待办事项列表并确定其优先级。每个变更可以被视为一个实验将进行短时间测试以确定每个变更的适应性以及进一步细化/考虑需求使用看板面板跟踪进度显示已作为 “已完成”使用的新方法、被视为“进行中”的方法以及在等待被引入“待办事项”的方法。请参见图6-3 以了解具有待办事项列表排序的初始面板。图6-4 显示了面板工作进度的示例通过使用这些工具来组织和管理变更实施将可提供进度的可视化并对正在实施的方法进行建模。以透明和吸引人的方式部署变更将可以提高成功可能性 7 行动呼吁自2001年首次发布《敏捷宣言》之后敏捷及其项目管理方法的采用率已有大幅提高。敏捷思维模式的理念和实践不再局限于特定规模的组织或一些仅专注于信息技术的组织。该思维模式应用广泛并已在许多环境中获得了成功如今“敏捷”呼声前所未有地高涨起来。由于业内对敏捷的最佳途径还存在争议围绕该主题的讨论仍甚嚣尘上并且不断涌现出更多的创新。有一个真理永恒不变那就是检查、适应、透明度是成功交付价值的关键因素。该实践指南可能无法提供您所期待的一切信息。我们的核心团队意识到您可能对我们选择呈现并热衷的一些元素或方法持有不同意见。我们希望您能继续积极参与这方面的对话并改进该实践指南的下一次迭代。您需要进行学习、实验、获取反馈、再实验的过程然后帮助我们回顾提供指南的相关反馈并参与制定该实践指南的未来版本。无论怎样没有适应的检查的只是浪费精力。有了归属感才会坚定的走下去才有希望越来越精彩、越来越好最后我们期待您能参与更广泛的项目管理和敏捷社区推动这些主题的对话。通过会议结识PMI和敏捷联盟的代表并参与讨论。使用社交媒体发表您的观点和意见您可以在名称为“敏捷实践”的博客中提供有关实践指南内容的反馈并参与对话网址 https://www.projectmanagement.com/blogs/347350/Agile-in-Practicehttps://www.projectmanagement.com/blogs/347350/Agile-in-Practice

查看全文

http://www.zqtcl.cn/news/612718/