获得即时访问
这个蓝图

应用程序图标

实施有效的敏捷实践

敏捷是一种文化转变. 不要只是敏捷,而是要敏捷.

  • 许多敏捷实现失败是因为缺乏经验和对敏捷的真正含义的理解, 以及它试图解决的问题. 当这些项目失败时,敏捷经常因此而受到指责.
  • 缺乏管理支持, 僵化的组织文化, 团队成员的阻力, 培训不足是导致敏捷实践失败的最大因素.

我们的建议

关键的见解

  • 敏捷首先是一种文化转变. 文化通常是敏捷实现的最大挑战. 不要认为这是敏捷失败的标志. 相反,把它看作是一个教训,提出改进的机会.
  • 敏捷思维必须在组织的每一层都建立起来. 自顶向下的敏捷实现方法常常会导致失败.
  • 不要让您的组织被围绕敏捷的宣传冲昏头脑. 由于敏捷原则和实践的不成熟实现和采用,大多数组织并没有实现敏捷的量化好处.

影响和结果

  • 教育和培训您的执行、管理和交付团队以正确的方式采用敏捷.
  • 评估您当前的软件开发生命周期(SDLC), 文化, 和环境来评估敏捷的适用性,并决定需要实施哪些变更.
  • 对敏捷进行结构化评估,以评估和认识敏捷在组织和团队中的好处.
  • 开发一种迭代方法,在您的组织中推出敏捷,以快速失败和快速恢复.

实施工作研究的敏捷实践 & 工具

1. 实现敏捷研究——一个循序渐进的文档,提供了如何采用敏捷文化的指导, 流程, 指标, 以及根据您当前开发环境的动态和结构的工具.

开发团队正承受着越来越大的压力,在保持与业务优先级一致的同时,用同样数量的资源在更短的时间内完成更多的工作. 他们希望敏捷能够帮助他们缓解这种压力,但却不知道从哪里开始. 这个蓝图将帮助您根据您的环境定制敏捷开发过程和指导方针,通过遵循我们的三阶段方法来促进您在组织的每一层学习敏捷, 评估并准备敏捷, 并通过结构化评估来实现敏捷.

2. 敏捷剧本模板——一个结构化的模板,允许开发团队记录SDLC和他们当前的状态评估. 它还确保团队和涉众在试点项目的目标方面处于相同的位置.

此模板包括定义您的团队和组织应该遵循的开发指南的区域, 讨论你的试点项目的SDLC和敏捷流程, 并定义试点项目的范围和角色, 风险, 和成本.

3. Scrum文档模板——这个模板允许开发团队使用Scrum流程记录他们项目的用户故事和Scrum委员会,以确保团队和涉众对项目的进展达成一致.

这个模板包括文档和计划你的产品和sprint待办事项列表, 记录你每天的积分消耗, 评估团队的速度.


会员推荐

在每一次信息技术体验之后, 我们要求我们的成员量化实时储蓄, 货币的影响, 和 我们的研究帮助他们实现了项目改进. 请参阅我们的顶级成员的经验为这个蓝图和 我们的客户想说什么.

8.3/10


总体影响

$51,433


平均美元救了

16


平均一天救了

客户端

经验

影响

美元了

天救了

BLG加拿大

指导实施

10/10

$25,000

10

韦尔奇的食品公司

车间

8/10

N/A

10

马克安东尼集团有限公司.

车间

10/10

$50,000

10

多伦多警方服务

指导实施

10/10

$50,000

50

加拿大审计长办公室

车间

9/10

N/A

N/A

非洲黑纤维

指导实施

9/10

$58,899

20

俄亥俄州-俄亥俄州发育障碍部门

指导实施

2/10

N/A

N/A

AgVantis公司

车间

7/10

N/A

N/A

犹他谷大学

指导实施

8/10

$123K

10

MHI加拿大航空航天公司.

指导实施

10/10

N/A

2

MUHC研究所

指导实施

8/10

N/A

20

步行者全球

指导实施

10/10

$3,719

5

加拿大就业和社会发展部

车间

10/10

$1M

50

Suddath公司

指导实施

10/10

$7,439

20

Aipso

指导实施

10/10

N/A

20

Suddath公司

指导实施

10/10

N/A

N/A

齐默Biomet

车间

9/10

$30,999

50

博地能源投资集团.

指导实施

10/10

N/A

N/A

维多利亚共同建筑协会

指导实施

9/10

N/A

5

阿拉斯加大学

指导实施

10/10

N/A

N/A

非洲黑纤维

指导实施

10/10

$11,305

14

佐佐木Associates Inc .)

车间

8/10

N/A

N/A

Westmorel和矿业有限责任公司

指导实施

8/10

N/A

2

通用动力任务系统公司

指导实施

9/10

$127K

10

派克宇航

车间

10/10

$44,567

29

加拿大皇家骑警

车间

8/10

N/A

N/A

杜邦美国专业产品有限公司

指导实施

8/10

N/A

N/A

约翰内斯堡大学

指导实施

9/10

N/A

10

卡尔加里公共图书馆

车间

8/10

N/A

N/A

就业及家庭服务

指导实施

9/10

$6,366

10


现场研讨会:实施有效的敏捷实践

现场研讨会提供了一种简单的方法来加速您的项目. 如果你不能自己做这个项目, 一个引导实现是不够的, 我们提供低成本的现场交付我们的项目车间. 我们将带您完成项目的每个阶段,并确保您有一个路线图,以成功地完成项目.

模块1:领导和管理敏捷

目的

  • 在组织的不同层中构建敏捷实践的知识和支持.
  • 在执行和管理团队中构建敏捷实践和概念的知识,以推动变革.

关键好处

  • 促进组织高管和管理层的学习.
  • 敏捷实践和原则.
  • 基线的敏捷实践.
  • 支持有效的敏捷实践的关键工具.

活动

输出

1.1

比较敏捷交付和瀑布交付.

1.2

解读敏捷:原则、术语和角色.

1.3

产品所有者和产品敏捷性.

  • 敏捷个人故事卡.
1.4

企业敏捷性和变更的价值.

  • 确定的业务价值来源.
1.5

领导、管理和管理敏捷团队.

  • 组织文化评估.
1.6

定义你的敏捷原则.

1.7

致力于敏捷.

模块2:敏捷和敏捷文化介绍

目的

  • 在实施敏捷以确保成功之前,确定组织当前环境和文化中的差距.

关键好处

  • 了解你的团队和组织的文化,以及这对采用敏捷实践的影响.
  • SWOT分析.

活动

输出

2.1

评估敏捷文化.

  • 评估团队和组织的文化是否适合敏捷.
2.2

SWOT分析.

  • 完成了SWOT分析.

模块3:评估当前状态并理解Scrum流程

目的

  • 评估您的团队和组织的当前环境,因为它与您的SDLC过程相关,以确定如何最好地实现敏捷.
  • 理解基线scrum过程,将其作为采用良好敏捷实践的起点.

关键好处

  • 完成SDLC阶段-关卡.
  • SDLC流程流.
  • SDLC中的痛点与敏捷相关.
  • 识别和评估业务价值定义.
  • 确定“准备好”和“完成”的定义.
  • 了解基线scrum方法和实践.

活动

输出

3.1

确定并描述SDLC的阶段门.

  • 完成SDLC阶段-关卡.
3.2

画电流SDLC.

  • SDLC流程流.
3.3

确定SDLC中的痛点.

  • SDLC中的痛点与敏捷相关.
3.4

识别和评估业务价值定义.

  • 完成的业务价值定义.
3.5

确定“准备好”和“完成”的定义.

  • 完成“准备好”和“完成”的定义.

实施有效的敏捷实践

敏捷是一种文化转变. 不要只是敏捷,而是要敏捷.

分析的角度

“敏捷并不是能神奇地解决组织问题的灵丹妙药. 一个敏捷人员如果没有意识到或不现实地认识到他们必须工作的组织的局限性,就会失败. 第一步是认清改变组织工作方式的每个方面所面临的挑战."

科尔Cioran,

高级主管,研究,应用交付和管理

信息技术研究小组

我们对问题的理解

本研究的目的是:

  • 需要评估敏捷实践对组织的潜在好处的主管.
  • 寻求优化开发实践的价值和效率的方法的应用程序开发经理.
  • 当前或未来的敏捷实践者和希望理解敏捷原则的热衷者, 方法, 和它的适应性.

这项研究将帮助你:

  • 了解敏捷实践以及如何成功地采用它们.
  • 评估您当前的环境,以确定敏捷可以适用于何处.
  • 为敏捷的结构化评估确定正确的试点.
  • 在您的敏捷转换过程中,确定相关的涉众并让他们参与进来.

本研究还将有助于:

  • 权衡与实现敏捷实践相关的利益和成本的cio.
  • 正在评估文化转变的管理者, 组织设计, 产品开发过程变更, 和客户的影响.

这项研究将帮助他们:

  • 确定采用敏捷的价值和好处.
  • 评估需要实现的变更,以帮助敏捷在其环境中获得成功.

执行概要

情况

  • Many organizations have heard of 敏捷 和 the benefits it promises to 软件 发展 practices; 然而, 他们没有看到这个行业对它所承诺的好处的大肆宣传.
  • 许多交付团队在“做”敏捷和“成为”敏捷方面都失败了,他们没有对什么是敏捷进行适当的培训和教育.

并发症

  • 许多敏捷实现失败是因为缺乏经验,不理解敏捷的真正含义和它试图解决的问题. 当这些项目失败时,敏捷经常因此而受到指责.
  • 缺乏管理支持, 僵化的组织文化, 团队成员的阻力, 培训不足是导致敏捷实践失败的最大因素.

决议

  • 教育和培训您的执行、管理和交付团队以正确的方式采用敏捷.
  • 评估您当前的软件开发生命周期(SDLC), 文化, 和环境来评估敏捷的适用性,并决定需要实施哪些变更.
  • 对敏捷进行结构化评估,以评估和认识敏捷在组织和团队中的好处.
  • 开发一种迭代方法,在您的组织中推出敏捷,以快速失败和快速恢复.

信息技术的见解

  1. 敏捷首先是一种文化转变. 文化通常是敏捷实现的最大挑战. 不要认为这是敏捷失败的标志. 相反,把它作为一个教训,提出改进的机会.
  2. 敏捷思维必须在组织的每一层都建立起来. 自顶向下的敏捷实现方法常常会导致失败.
  3. 不要让您的组织被围绕敏捷的宣传冲昏头脑. 由于敏捷原则和实践的不成熟实现和采用,大多数组织并没有实现敏捷的量化好处.

敏捷的四个核心价值

我们的价值. . .

这幅图展示了敏捷胜过规范的四个核心价值. 敏捷的价值观是:个人和互动, 工作软件, 客户协作, 应对变化. 规范性是:过程和工具, 全面的文档, 合同谈判, 和遵循计划

“虽然右边的东西有价值,但我们更看重左边的东西.” – 来源: 《澳博体育app下载》

敏捷不仅仅是组织做的事情……

模型显示了说明性、敏捷和敏捷的区别.

敏捷带来了团队方式的彻底转变, 项目经理, 而涉众传统上计划并执行开发项目.

“(‘实施’敏捷)只是一些例行公事,但没有重大的改变来支持端到端真正的敏捷方法, 业务集成, 价值的关注, 和团队授权.——Arie van Bennekum

理解构建最小可行产品(最有价值球员)的重要性

描述了两幅图. 上面的图表显示,在《澳博体育app》中,风险增加了,但收益却很少. 在底部的图表中,它显示了使用敏捷,可以更快地降低风险和识别价值.

大多数人将瀑布法与敏捷法相比较

“我相信这个概念,但上述的实施是有风险的,会招致失败." ——温斯顿·W. 罗伊斯

通过在更小的迭代中交付产品, 团队能更快地认识到价值并减少累积的风险. 两者都是在迭代进入验证测试和发布时实现的.

来源: 管理大型软件系统的开发

认识到敏捷是如何最小化累积的风险并更快地交付价值的

有一个图表显示了瀑布式开发与敏捷开发相比存在很大的风险.

通过在更小的迭代中交付产品, 团队减少了随时间积累的风险, 因为他们在每次迭代中验证准确性. 阴影区域表示当团队通过敏捷以较小的迭代交付时所降低的风险.

图中显示了在瀑布法中随着时间的推移而丢失的值,以及在敏捷中交付值的次数

在理想的世界里, 团队可以最大限度地增加所获得的价值, 用绿色虚线表示. 有了敏捷,团队可以缩短周期,并找到更多的交付价值的版本. 阴影区域代表的是随着时间的推移而失去的值.

理解敏捷提供的好处和成功实现的需求

你的交付方法的有效性将取决于你与业务的整合程度,以及你在执行方法时的自律程度.

模型的建立反映了学科整合与学科整合的关系.

来源: Ambysoft“2018项目成功调查结果”

评估如何开始使用敏捷SDLC

图片描述了一个关于如何开始使用敏捷的模型.

了解如何在短期内将敏捷注入SDLC

信息技术研究表明,在项目或运营团队的环境中,从小处开始敏捷是成功的关键. 一个混合的“水敏捷瀑布”是最好的开始.

图片描述了一个关于如何开始使用敏捷的模型. 它展示了瀑布法和敏捷之间的关系.

在项目生命周期中尽可能多地扩展迭代和敏捷实践,以最大化所创造的价值

首先,规划和设计.

然后,下游是部署和支持.

遵循Info-Tech的方法,在你的组织中学习和扩展敏捷

产品集中

过渡到产品交付

构建产品路线图 建立更好的Backlog

建立一个更好的产品负责人

交付集中

实施有效的敏捷实践

通过扩展敏捷实现组织范围内的协作

用卓越的敏捷中心传播最佳实践

发展重点

使用参数驱动的方法来组织你的DevOps采用

用五个步骤使开发团队更精简,并改进发布时间

无论您是一个“基于产品”的组织还是“基于项目”的组织,都要认识到敏捷是如何适应您的组织的

描述了一个模型来显示产品生命周期和项目生命周期之间的关系

项目产品

不管你认为自己是“以产品为基础”还是“以项目为基础”的商店, 同样的基本原则应该适用. 您要经历一个或多个类似项目的开发阶段,以构建应用程序或产品的版本. 在项目开发过程中,您还拥有并行服务, 哪个包含了更多的基于产品的观点. 这些服务范围从基本的支持和维护到成熟的战略团队或服务,如销售和市场. 所有的应用程序都可以被认为是产品,所有的产品都有项目.

并不是《澳博体育app下载》中的所有内容都应该被当作真理

不要把宣言太当真——它必须与项目团队的操作和工作流程一致,并且当意外情况发生时,不要增加项目失败的风险. 因此,要认识到宣言中的冗余、惯例和陈词滥调. 这里有5个重要的原则,不容忽视.

敏捷宣言的原则

  1. 我们的最高优先级是通过早期和持续的交付有价值的软件来满足客户.
  2. 欢迎变更需求,即使是在开发后期. 敏捷过程利用变更为客户提供竞争优势.
  3. 经常交付工作软件, 从几周到几个月, 优先选择较短的时间尺度.
  4. 业务人员和开发人员必须在整个项目中每天一起工作.
  5. 围绕有动力的个人构建项目. 给他们所需的环境和支持,相信他们能完成工作.
  6. 向开发团队传递信息的最有效的方法是面对面的交谈.
  7. 可工作的软件是进度的主要度量.
  8. 敏捷过程促进可持续开发. 发起人、开发人员和用户应该能够无限期地保持一个恒定的速度.
  9. 对技术卓越和良好设计的持续关注可以增强敏捷性.
  10. 简单——将未完成的工作量最大化的艺术——是至关重要的.
  11. 最好的架构、需求和设计来自自组织的团队.
  12. 定期, 团队思考如何变得更有效率, 然后相应地调整它的行为.

来源: “敏捷宣言”; 敏捷! 好的,炒作的和丑陋的

交付速度和生产力仍然是采用敏捷的主要驱动力

采用敏捷的好处

通过实施敏捷,受访者提到在以下方面看到了改进:

一个条形图显示了受访者引用的采用敏捷的改进.

改编自: “第12届年度敏捷状态报告”

敏捷的定量结果还远远没有定论

定性

敏捷咨询机构和工具供应商所做的每一项调查都显示,敏捷让人感觉更成功 比传统方法.

“基于我们最近敏捷质量研究的结果, 预计在大约三年内,敏捷软件质量将超过传统方法性能6 - 12%."

——《澳博体育app下载》

定量

一般的敏捷实践并不比瀑布法更有效率.

“……一些研究人员认为敏捷方法没有什么新东西……”

敏捷软件开发的实证研究:系统回顾

敏捷不一定更好. 参与到生产过程中感觉更好."

——《澳博体育app下载》

信息技术的见解

不要仅仅根据速度和生产力来衡量敏捷实现的成功. 优先考虑积极体验对人类的益处, 信任, 和弹性,成为你的业务需要的合作伙伴.

为什么组织采用敏捷?

传统工艺有其局限性

这幅图描述了六个盒子,它们解释了传统流程的局限性. 所描述的局限性是缺乏弹性的融资模式, 对软件交付的估计不佳, 缺乏业务互动, 无法管理更改, 被一种想法所谴责, 和平庸的产品

“尽管许多组织在开始他们的敏捷之旅时付出了努力,但敏捷失败现在似乎越来越突出."

——Stefan Wolpers,《组织中的敏捷失败模式.0”

那么问题从哪里开始呢?

“大多数IT资金依赖于一次性支出或资本-资金机制,这些机制基于基于20年或更长的预期寿命的建设-资金模型. 这样的模型不能提供现代IT投资所需的稳定性或灵活性."

-“将资讯科技的资助模式与科技变革的步伐相结合”

你现在如何资助项目?

描述了一个模型来展示如何通过财务、预算和投资组合来资助项目.

这些模型需要在整个项目生命周期中增加准确性,以管理实际数据和估算数据.

糟糕的评估会导致项目中的下游问题

在瀑布, 我们经常看到,在整个项目生命周期中,为了管理实际数据与估计数据,需要增加准确性的模型.

描述了一个模型来展示如何管理实际数据和. 估计.

“软件的平均粗略数量级估计误差高达 400%"

——《澳博体育app下载》

事实上,软件评估与其说是一门科学,不如说是一门黑暗艺术. 它不仅仅是实现或开发软件.

缺乏业务或IT涉众的参与会显著降低敏捷下游的成功

显示一个圆形图形,标记为78%

78%的IT专业人士认为业务“通常”或“总是”与项目需求不同步.


来源:《澳博体育app下载》

沟通 在整个开发周期中,业务并不是定期发生的,这导致最终产品交付不能满足业务和/或客户的期望. 这将导致进一步的返工,以试图满足预期,并在随后的上市交付时间上减慢.

有几个因素影响利益相关者参与的性质和影响. 根据以下因素来迎合不同利益相关者的策略:

图片显示了为迎合利益相关者的策略需要考虑的因素. 这些因素是:参与方式, 的关系, 沟通渠道, 可用性, 交互, 位置.
来源:“积极的利益相关者参与:敏捷的核心实践”

谈到业务敏捷性,变化是不可避免的

然而, 传统的交付过程是基于产品需求在整个SDLC中保持不变的假设. 这将导致延迟交付对维护积极的客户体验至关重要的产品改进.

无论如何,

图中显示一个圆形图,并高亮显示64%.

64%的IT专业人士采用敏捷来增强他们管理不断变化的优先级的能力.

来源:“第12届年度敏捷状态报告”

将显示圆形图并突出显示71%

71%的IT专业人士发现,在实施敏捷之后,他们管理不断变化的优先级的能力实际上有所提高.

来源:“第12届年度敏捷状态报告”

信息技术的见解

敏捷首先是一种文化转变,它采用了思维方式 拥抱变化. 因此,如果你成功了 敏捷, 你管理优先级变化的能力将是敏捷的自然副产品.

创造一种鼓励创新的文化

因为开发方法通常是在发布周期的开始阶段完成的, 没有创新的空间. 资源通常是预先建立的,几乎没有空间来加强团队,以鼓励团队成员的实验和创造性思维.

探索组织中阻碍创新的障碍, 目标是创造一个鼓励你的团队成员成为创新者的环境:

自由探索

人们可以自由地探索可能带来更好产品和体验的想法.

“现在”的偏见

领导者偏爱“现在”而不是“完美”.“我们能以5%的成本达到50%的成本吗?

好失败

这里存在一个创建原型的环境和对“良好失败”的偏好.“好的失败意味着快速、廉价和低影响.

原型到生产

将有价值的原型转化为生产解决方案的简单过程.

软件产品的接受程度和价值并不证明投资的资金是合理的

不支持解决方案的频繁和迭代部署的过程通常会产生落后于行业竞争对手的产品. 不能快速和频繁地发布解决方案来征求客户的反馈,通常会导致产品不具有行业领先性或对最终用户没有价值.

$1,000,000,000,000 每年都花在软件上吗.

38% 在IT员工身上花费的大部分都花在了软件岗位上.

来源: 信息技术人员调查

18% 运营成本的一半花费在软件许可上.

来源: 软件评论.com

33% 资本支出的大部分都花在了新软件上.

来源: 信息技术的预算调查


这些问题会导致软件交付中的大规模失败.

只有 34% 的软件被用户认为是重要和有效的.

来源: 信息技术的首席信息官业务愿景

软件开发、实现和维护的分发被误解了

描述了一个模型来显示开发的分布, 实现, 软件维护

源代码:“代码会腐烂吗? 评估来自变更管理数据的证据”

信息技术的见解

每个维护团队都开发新的代码, 增强现有的应用程序, 并维护和修复生产系统. 治理, 管理, 而且,衡量交付的能力是需要的,以做出关于投资什么活动来驱动价值的明智决定.

成功评估敏捷是有障碍的

敏捷不:

解决开发和沟通问题.

快…完成需求.

…意味着您不需要文档.

我们不建议在以下情况下评估敏捷:

如果人们对交付不负责.

如果你已经在瀑布式采购或合同环境中有一个正在进行中的项目.

如果一个大型项目已经通过了一个关键的设计审查阶段,并且没有机会重新审查设计.

如果所有的涉众不能同意采用敏捷实践来交付他们的项目.

如果项目有固定的范围.

如果项目涉及高度敏感、高风险、关键任务或遗留系统.

在您的敏捷转换之旅中,请考虑这些关键方面

组织在开始转型的每一步时,都需要考虑敏捷的各个方面,以避免缺乏纪律和集成给敏捷实践带来的挑战.

学习

敏捷是对人们工作和思考方式的根本性改变. 结构化, 在整个转变过程中,促进学习是必需的,以帮助领导者和实践者从实施敏捷到成为敏捷.

自动化

而敏捷在本质上是工具不可知的, 敏捷工作管理工具和DevOps启发了SDLC工具,它们已经成为敏捷实践的关键部分.

整合团队

而临时项目团队可以从敏捷中获得一些好处, 站, 跨业务的自组织团队, 交付, 和运维对于获得敏捷的全部好处是必不可少的.

指标和治理

成功的敏捷实现需要严格地使用交付和运营指标,以支持专注于开发更好团队的治理.

文化

敏捷团队认为,站立是创造价值的最佳方式, 自组织的跨职能团队,能够持续频繁地交付产品, 在领导者的指导下,通过挑战来实现短期的增量.

认识到将影响和影响您的敏捷转换的涉众

描述了一个模型来显示业务和IT之间高集成和低集成之间的关系.

通过Info-Tech的研究,了解如何通过敏捷转换之旅

一个模型展示了信息技术与敏捷的研究之旅, 以及这幅蓝图的意义所在.

使用信息技术的方法,通过便利的学习和结构化的评估,开始向敏捷的转变

阶段1 -促进敏捷学习

  • 一个培训模块,针对组织的执行人员和管理人员,他们将领导和管理敏捷转换.
  • 一个针对交付团队成员的培训模块,该团队将以试点计划的形式执行结构化的敏捷评估.

阶段2 -评估当前状态

  • 通过评估和识别业务驱动来评估您的团队和组织对敏捷的准备情况, 文化, 和SWOT.
  • 评估当前SDLC过程的状态,以发现差距和机会,并理解敏捷将如何改变当前的工作方式.

阶段3 -执行结构化评估

  • 理解基线scrum流程.
  • 制定一个项目干系人管理计划,让合适的干系人与你一起踏上敏捷之旅.
  • 评估并选择正确的敏捷试点.
  • 模拟scrum实践以供试点采用.

财富50强科技案例研究

案例研究

工业: 技术

来源: 信息技术研究小组

挑战:

该成员意识到公司需要提高其敏捷性, 上市时间, 以及适应变化的能力,以继续增长. 该公司的产品和服务越来越多地包含技术组件,并需要更快地交付解决方案. 除了, 这位成员想让公司成为一个对新员工和被收购公司更有吸引力的工作场所.

解决方案:

该成员与Info-Tech合作开发了一套全面的支持和服务,以指导其敏捷转换.

  • 执行领导能力一天的研讨会,接着是为期四天的关于敏捷的试点团队研讨会.
  • 专注的咨询和团队指导以确保成功.
  • 发展具有终端用户认证的在线学院.

结果:

  • 执行领导确定了提高敏捷性的文化和过程障碍,并制定了支持转换的路线图.
  • 敏捷团队指导帮助建立了敏捷和混合方法的共同基线.
  • 在四个地点完成了国际讲习班,培训了80多名参与者.
  • 该成员正在开发敏捷方法和资助模型,以支持不同的项目需求和业务单元.

该成员的敏捷转型遵循了Info-Tech的方法论.

信息技术提供各种级别的支持,以最适合您的需求

DIY工具包

“我们的团队已经将这个关键项目列为优先事项, 我们有时间和能力, 但在这一过程中,一些指导将会有所帮助."

指导实施

“我们的团队知道我们需要修复一个过程,但我们需要帮助来确定重点在哪里. 在这个过程中,一些签到会帮助我们保持在正轨上.”

车间

这个人说:“我们必须马上开始这个项目. 一旦我们有了一个框架和策略,我们的团队就有能力接手这个工作.”

咨询

“我们的团队没有时间或知识来接手这个项目. 我们整个项目都需要协助.”

在所有四个选项中都使用诊断和一致的框架.

实现工作项目概述的敏捷实践

显示了该蓝图的项目概述.

车间概述

联系您的帐户代表或电子邮件 研讨会@InfoTech.com 的更多信息.

在这个蓝图中对为期四天的研讨会进行了概述,概述了活动和可交付成果.

第一阶段

方便灵活的学习

第一阶段概述

打1号电话或发邮件 GuidedImplementations@InfoTech.com 的更多信息.

您可以自己完成这些步骤,或者请我们来完成指导实现. 指导实现是一系列2-3个咨询电话,帮助您执行项目的每个阶段. 他们被列入大多数顾问会员.

本文展示了阶段1的指导实施大纲,包括结果和见解.

步骤1.1:领导和管理敏捷

这一步将引导你完成以下活动:

  • 促进组织高管和管理层的学习.
  • 敏捷实践和原则.
  • 基线的敏捷实践.
  • 支持有效的敏捷实践的关键工具.

这一步骤涉及以下参与者:

  • CXOs
  • 开发经理/副总/总监
  • 项目/项目经理
  • 外部培训师/咨询师
  • 敏捷教练
  • 产品经理/产品负责人
  • Scrum Master
  • 敏捷团队(业务分析师、开发人员、测试人员、架构师、QA、UI/UX设计师等.)

这一步的结果

  • 在组织的不同层中构建敏捷实践的知识和支持.
  • 在执行和管理团队中构建敏捷实践和概念的知识,以推动变革.
  • 教育和支持敏捷团队,以确保成功采用敏捷实践.
  • 将组织对“敏捷”的理解标准化.”

首先,为组织中的领导者提供敏捷学习的便利

领导和管理敏捷

第一阶段.蓝图1

  • 参与者: 管理人员和管理.
  • 目的: 在执行和管理团队中构建敏捷实践和概念的知识,以推动变革.
  • 信息技术参与: 为期一天的高管介绍和培训.

评估敏捷

第一阶段.这个蓝图的2到3个

  • 参与者: 敏捷团队成员.
  • 目的: 教育和支持敏捷团队,以确保成功采用敏捷实践.
  • 信息技术参与: 四天现场学习. 持续的敏捷教练.

信息技术的见解

在组织的每一层建立敏捷思维. 的 move to 敏捷 can’t be a top-down decision; it must be a journey to changing the cultural 和 governance structure from the bottom up. 在引入敏捷的教育之旅中,第一步是从总体出发,回答这个问题:“它对我有什么好处??”

通过这些关键方面来实现您领导和管理敏捷的目标,以确保成功

比较瀑布式交付和敏捷交付: 探索瀑布方法的起源和神话,以及敏捷崛起背后的原因.

解读敏捷:原则、术语和角色: 介绍并解读敏捷原则, 敏捷特有的术语, 以及它所引入的角色.

产品所有者和产品敏捷性: 超越基于项目的敏捷,理解产品敏捷的好处和挑战.

企业敏捷性和变化的价值: 围绕产品和服务引入企业敏捷性以及业务和IT集成.

领导、管理和管理敏捷团队: 确定领导者和管理者需要拥抱的行为,以帮助人们成为敏捷.

定义你的敏捷原则: 定义你作为领导者和管理者所需要的使敏捷在你的组织中成功的原则.

致力于敏捷: 推动个人对这些原则的承诺,以确保领导者和管理者成为您组织的敏捷倡导者.

锻炼:是什么推动您的组织成为敏捷的? 完成你的个人敏捷故事卡

1.1.1

预计时间:15至30分钟

  1. 个人:完成你的个人敏捷故事卡片.
  2. 小组(12人或以下):
    • 与主持人和其他参与者分享你的个人敏捷故事卡片.
  3. 大群体(12人以上):
    • 表格组:与桌子上的其他参与者分享你的个人敏捷故事卡片.
    • 确定三个(3-4个表组)、两个(5-6个表组)或一个(7+个表组)优先级故事.
    • 与主持人和其他参与者分享你的优先级故事.
第1步给出了一个示例.1.1

Input

  • 参与者的个人期望

Output

  • 主要议题的清单或为将来讨论安排的时间表

材料

  • 敏捷故事卡片
  • 活动挂图或白板

参与者

  • 所有

探索瀑布方法的起源和神话,以及敏捷崛起背后的原因

图中列出了领导和管理敏捷的关键方面. 强调的第一步是:比较瀑布式交付和敏捷交付

《澳博体育app》从何而来?

图像中有七个方框并排显示,方框之间有箭头. 从左到右,它们被标记为:系统需求, 软件需求, 分析, 程序设计, 编码, 测试, 操作

管理大型软件系统的开发

  • Dr. W. R. 罗伊斯
  • IEEE WesCon 1970

W. R. 罗伊斯是一个:

  • 火箭科学家
  • 项目经理
  • 先锋
来源:“管理大型软件系统的开发”

罗伊斯对瀑布到底说了什么?

大多数人将瀑布法与敏捷法相比较

Dr. 温斯顿·W. 罗伊斯在1970年首次引入了瀑布法. 然而,他指出:

“我相信这个概念,但上述的实施是有风险的,会招致失败."

罗伊斯的5条成功法则

  1. 先完成程序设计.
  2. 保持文档的更新和完整.
  3. 在每个阶段中迭代,通常是重复的.
  4. 计划、控制和监控整个测试过程.
  5. 正式地、深入地、持续地让客户参与进来.
来源:“管理大型软件系统的开发”

理解在敏捷世界中事情将如何变化

传统的开发 敏捷开发
基本假定 系统是完全可指定的、可预测的,并且是通过细致和广泛的规划来构建的 高质量的自适应软件是由小团队使用基于快速反馈和变更的持续设计改进和测试原则开发的
管理风格 指挥和控制 领导和协作
知识管理 显式的 隐性
沟通 正式的 非正式的
发展模式 生命周期模型(瀑布型、螺旋型或其他变体) e卷utionary-交付模型
所需的组织形式和结构 机械化的(官僚主义,高度正规化),针对大型组织 有机(灵活和参与性鼓励社会合作行动), 针对中小型组织
质量控制 Heavy 规划 和 strict control; late, heavy 测试ing Continuous control of requirements, 设计, 和 solutions; continuous 测试ing
来源:“敏捷软件开发的实证研究:系统回顾”

练习:构建和实现软件与构建有什么不同?

1.1.2

预计时间:15分钟

  1. 个人:写下构建和实现软件不同于构建的三种方式.
  2. 小组(12人或以下):
    • 与主持人和其他参与者分享一个关键的例子.
  3. 大群体(12人以上):
    • 表格组:与表格上的人分享你的列表,并确定一个在你今天交付时产生挑战的项目.
    • 表组:指定表的一个成员,以共享您标识为组的一个或两个关键项.

Input

  • 对软件交付和您的组织的个人知识

Output

  • 关键的差异可能会在今天带来挑战

材料

  • 纸和笔
  • 白板或活动挂图

参与者

  • 所有

建设和软件

建设 软件
预计会持续几十年 可以只用一次吗
施工期间很难改变计划 施工中易于更改计划
基于完全定义的体系结构构建 在体系结构框架中演进
稳定一旦完成 完成后继续更改
劳动密集型的 技术密集型的
易于伸缩资源 资源规模不
技能是广泛的 技能短缺
专业知识是很常见的 专业知识是罕见的
完工的建筑往往会被使用 完成的软件可能永远不会被使用
完成很容易定义 “完成”很难定义
成本通常是资本 成本通常是可操作的
相对较少的利益相关者 许多利益相关者

那么问题从哪里开始呢?

“大多数IT资金依赖于一次性支出或资本-资金机制,这些机制基于基于20年或更长的预期寿命的建设-资金模型. 这样的模型不能提供现代IT投资所需的稳定性或灵活性."

-“将资讯科技的资助模式与科技变革的步伐相结合”

你现在如何资助项目?

描述了一个模型来展示如何通过财务、预算和投资组合来资助项目.

这些模型需要在整个项目生命周期中增加准确性,以管理实际数据和估算数据.

糟糕的评估会导致项目中的下游问题

在瀑布, 我们经常看到,在整个项目生命周期中,为了管理实际数据与估计数据,需要增加准确性的模型.

描述了一个模型来展示如何管理实际数据和. 估计.

“软件的平均粗略数量级估计误差高达 400%"

——《澳博体育app下载》

事实上,软件评估与其说是一门科学,不如说是一门黑暗艺术. 它不仅仅是实现或开发软件.

软件开发、实现和维护的分发被误解了

描述了一个模型来显示开发的分布, 实现, 软件维护

而开发或实现成本之间的确切平衡点因应用程序而异, 对整个, 软件成本的一半以上是实现的 它正在生产中.

信息技术的最佳实践

支持创新的资金模式, 学习, 持续的改进推动更好的评估和结果.

精益企业融资模型是一种不同方法的一个例子

展示了精益企业融资模型. 最上面是灵活资金池,中间是POCs、产品线和资金. 底部是公共软件、基础设施和服务基金.

A 灵活的资金池 类似于风险投资模型的维护,以支持创新的想法,并为产品和过程改进的概念证明提供资金.

每一个 产品线 是否为所有的改变和正在进行的操作和支持提供资金. pocc由常设创新团队或储备资源运营,而不是投入到现有产品中, 项目, 或服务.

团队不断得到资金支持,以便他们能够尽可能地学习和改进他们的实践.

考虑一下预算在敏捷环境中的不同之处

显示两种型号. 最上面的是传统预算模型,最下面的是敏捷预算模型.

信息技术的见解

传统预算将重点放在“成本中心”上,而敏捷预算则负责“价值流”.价值流是基于跨越成本中心的项目.

为什么组织采用敏捷?

传统工艺有其局限性

这幅图描述了六个盒子,它们解释了传统流程的局限性. 所描述的局限性是缺乏弹性的融资模式, 对软件交付的估计不佳, 缺乏业务互动, 无法管理更改, 被一种想法所谴责, 和平庸的产品

“尽管许多组织都做出了努力,但敏捷失败如今似乎越来越突出 成为敏捷."

——Stefan Wolpers,《组织中的敏捷失败模式.0"

探索瀑布方法的起源和神话,以及敏捷崛起背后的原因

图中列出了领导和管理敏捷的关键方面. 强调的第二步是:解读敏捷:原则、术语和角色.

我们正在通过实践和帮助他人来发现更好的软件开发方法. 通过这项工作,我们认识到:

本文给出了一个模型来比较敏捷和敏捷的四个价值. 被规定.

也就是说,虽然右边的项有价值,但我们更看重左边的项.

来源:《澳博体育app下载》

《澳博体育app下载》去掉了冗余、实践和陈词滥调

不要把宣言太当真——它必须与项目团队的操作和工作流程一致,并且当意外情况发生时,不要增加项目失败的风险. 然而,有五个原则是不能忽视的.

敏捷宣言的原则

  1. 我们的最高优先级是通过早期和持续的价值软件交付来满足客户.
  2. 欢迎变更需求,即使是在开发后期. 敏捷过程利用变更为客户提供竞争优势.
  3. 业务人员和开发人员必须在整个项目中每天一起工作.
  4. 敏捷过程促进可持续开发. 发起人、开发人员和用户应该能够无限期地保持一个恒定的速度.
  5. 最好的架构、需求和设计来自自组织的团队.
资料来源:《澳博体育app下载》; 敏捷! 好的,炒作的和丑陋的

采用敏捷以实现更大的业务一致性,并有效地对需求的变化做出反应

学习

敏捷是对人们工作和思考方式的根本性改变. 结构化, 在整个转变过程中,促进学习是必需的,以帮助领导者和实践者从实施敏捷到成为敏捷.

自动化

而敏捷在本质上是工具不可知的, 敏捷工作管理工具和DevOps启发了SDLC工具,它们已经成为敏捷实践的关键部分.

整合团队

而临时项目团队可以从敏捷中获得一些好处, 站, 跨业务的自组织团队, 交付, 和运维对于获得敏捷的全部好处是必不可少的.

指标和治理

成功的敏捷实现需要严格地使用交付和运营指标,以支持专注于开发更好团队的治理

文化

敏捷团队认为,站立是创造价值的最佳方式, 自组织的跨职能团队,能够持续频繁地交付产品, 在领导者的指导下,通过挑战来实现短期的增量.

采用敏捷并不是没有风险的

“我们在大型项目中看到的最大失败来源之一,是在需求定义不明确的背景下不成熟的敏捷实现.”

-“大型资讯科技项目-从噩梦到创造价值”

“对于项目结果来说,需求成熟度比方法更为重要.”

——“业务分析 基准:完整的报告”

成熟的敏捷实践将28%的时间花在分析和设计上.”

——《澳博体育app下载》

需求分析, 设计成熟, 和管理对于成功的敏捷转换是至关重要的.

所以哪种服务才是真正重要的?

商业领袖错误地判断了哪些服务对他们真正重要.

将显示一个模型,以显示高估和低估的服务与其报告的重要性和实际重要性之间的关系.

主要结论:

  • 除了应用程序本身,他们还低估了导致成功的关键因素.
  • 业务产品所有权仍然是关键.
  • 技术产品所有者、架构师和业务/系统分析师是关键.
  • 在哪些方面,他们缺乏项目和需求技能,可以用基于it的项目管理来补充.

信息技术的见解

Rethink your 优先级; invest in 服务s with the highest return on IT satisfaction. 项目、工作订单和创新领导驱动IT满意度.

资讯科技企业远景调查 N=21,367

适应从传统思维向敏捷思维的转变

敏捷带来了团队方式的彻底转变, 项目经理, 而涉众传统上计划并执行开发项目.

一个模型展示了从传统到敏捷思维的转变将会改变成本, time, 范围得到管理.
  • 与瀑布, 开发团队被期望完成一个固定范围的项目, 在确定的期限内,哪一种方法用于估算固定预算. 然而, 由于意料之外的变更和复杂性,团队通常无法满足这些承诺. 最后期限不被满足,并且经常被推迟,时间经常变得多变.
  • 在敏捷中,时间是有限的.e. 迭代),并且不断调整范围,以确保产品是有价值的, 成功的, 并在规定的期限内交付. 一个完整的敏捷产品可能比瀑布式产品包含更小的范围, 但是,提交的用户故事是稳定的,对涉众是有价值的.

请注意围绕敏捷的常见神话

敏捷不:

解决开发和沟通问题.

确保您将更快地完成需求.

…意味着您不需要文档.

尽管敏捷方法在全球分布式环境中越来越多地被采用, 成功没有万灵药."

——《在分布式敏捷开发中协商共同基础:案例研究视角.”

“如果没有适当的计划, 组织可以开始在工作上投入更多的资源,这就形成了经典的按时间表管理的瀑布式问题."

——OneShield Inc .助理执行架构师Kristen Morton.,信息技术面试

考虑信息技术公司的研究得出的其他关键观察结果

  1. 文化是敏捷实现的最大挑战.
  2. 混合开发方法可能比纯敏捷更适合.
  3. 不要让你的组织被成功冲昏了头脑.

从基线scrum实现开始

使用scrum作为你的敏捷实现的起点,因为它的流行和社区的支持.

为什么要从scrum开始?

简单性: Scrum的哲学和方法很简单, 说明性的, 而且,可用于帮助实施的现有资源是广泛的.

灵活性: Scrum是构建个性化敏捷过程策略的理想基础. 技术敏捷技术, 比如结对编程和持续集成, 容易注射.

成功: Scrum在应对需求变化方面取得了很多成功, 增加团队内部的协作和交流, 提高与利益相关者的透明度.

注意scrum的局限性:

  • 经营风险: 如果企业没有明确的方向,Scrum无法拯救产品的开发.
  • 分辨率无关: Scrum暴露了障碍和问题,但没有提供如何解决问题的见解.
  • 重新定义的角色: Scrum可以大大改变现有项目团队的角色和职责.

信息技术的见解

  • 使用众所周知的、照本宣本的scrum流程和工件来简化初始试点的推出. 随着您获得更多的经验,逐渐修改这些过程和工件以更好地适应您的环境.
  • 可能需要引入敏捷教练来帮助提供培训.
  • 没有指定的项目经理, 但领导者仍然需要挑战团队以提高.

理解scrum流程

scrum流程协调多个涉众来交付业务优先级.

一个模型展示了scrum流程中的4个步骤

注意:功能需求, 哪些是你的产品和sprint的待办事项列表, 通常是作为简短的用户故事编写的吗. 一旦这些用户场景“准备好”并为立即开发设定优先级,就会向它们添加额外的细节.

建立scrum角色和职责

产品负责人 Scrum Master 团队成员
负责任的
  • 在最终项目中识别产品特性及其重要性.
  • 为了根据业务重要性来确定哪些特性将在下一个sprint中交付,对待办事项列表进行细化和重新排序.
  • 为了增加阻滞剂和风险.
  • 用于领导scrum、回顾、sprint回顾和演示.
  • 用于团队建设和解决团队冲突.
  • 用于创建、测试、部署和支持可交付和有价值的特性.
  • 的自我管理. 没有项目经理给每个团队成员分配任务.
负责任的
  • 为涉众交付有价值的特性.
  • 确保开发过程中的交流.
  • 为产品负责人确保高质量的可交付成果.
咨询
  • 通过团队合作,而不是合同谈判.
  • 由产品负责人负责风险的解决.
  • 由团队提出改进建议.
  • 在sprint计划期间,由scrum负责人和产品负责人确定任务的复杂程度.
通知
  • 关于当前冲刺的进度.
  • 由团队在当前sprint期间完成的工作.
  • 业务方向和当前优先级.

看看传统的开发角色如何转化为scrum中的角色

在过渡到scrum时,开发角色可能会发生变化,但每个角色的价值将保持不变.

一个模型列出了传统角色,以及新的scrum角色如何包含传统角色.

信息技术的见解

  • 注意利益冲突 -没有正确的训练,传统的角色(如.g. 业务分析师和项目经理)可能会继续为您的试点项目带来传统的思维和优先级. 这将抵消您希望实现的目标,并与您的开发指南发生冲突.
  • Scrum master旋转 - Scrum管理员可以是任何人, 只要他们对开发动态有深刻的理解,对敏捷和scrum概念有深刻的理解.
  • 保持团队规模为5-9人 -这个尺寸有助于团队成员之间的任务协调和协作. 可以创建独立的团队来支持开发团队(例如.g. 安全, 架构师), 但是他们必须与开发团队积极沟通,并在关键的scrum活动中进行协作.

锻炼:我的团队的敏捷角色是什么?

1.1.3

预计时间:15分钟

  1. 个人:在记事本上列出团队当前的角色和最适合的角色:
    • E.g. 利益相关者、产品所有者、scrum管理员、团队成员.
    • 包括每个职位的主要职责.
    • 确定您所看到的团队当前角色和潜在敏捷角色之间的关键区别.
  2. 大型团体(12人以上):
    • 轮流讨论你的观察结果和主要差异.
    • 记下餐桌上出现的任何话题.
  3. Small group (<12 参与者):
    • 共享关键的主题.
标题/角色 主要职责
电流的作用 e.g. 业务分析师
  • 负责需求的提取和分析.
  • ...
敏捷的作用 e.g. 产品负责人
  • 负责定义和确定需求积压的优先级.
  • ...
差异

Input

  • 你对自己当前角色的了解
  • 今天的讨论

Output

  • 对您在敏捷中的角色有更深刻的理解

材料

  • 记事本

参与者

  • 所有

理解产品所有者在敏捷转换中的角色

图中列出了领导和管理敏捷的关键方面. 强调的第三个步骤是:产品所有者和产品敏捷性

Scrum引入了敏捷中为数不多的优秀理念之一——产品所有者."

Bertr和 Meyer, 敏捷! 好的,炒作的和丑陋的

理解以项目为中心和以产品为中心的组织之间的区别

产品交付需要在您完成开发工作和向涉众交付价值的方式上有重大转变. 做出有意义的改变.

项目 产品
基金变动及计划 资金 基金交叉功能团队
业务管理优先级 优先级 业务管理优先级与IT咨询
变更负责人和项目负责人 问责制 产品负责人及经理
管理产品的特定变更 项目及产品管理 管理产品族的成熟度和支持
工作人员分配 工作分配 向团队分配工作
项目经理管理产能和需求 容量和需求管理 团队管理能力和需求
在待办事项管理中咨询团队 待办事项列表管理 团队管理和推动Backlog管理
不一致和可变的特性和变更需求 产品需求 对功能和变化的稳定需求

了解产品负责人角色的重要性

正如《Scrum指南》中所描述的,scrum产品负责人负责将开发团队的工作成果转化为产品的价值最大化. 如何做到这一点可能会因组织、scrum团队和个人的不同而有很大差异.

产品负责人是唯一负责管理产品待办事项列表的人. 产品待办事项列表管理包括:

  • 沟通产品待定项.
  • 对产品待办事项进行排序,以最好地实现目标和任务.
  • 优化开发团队执行的工作的价值.
  • 确保产品待办事项列表可见, 透明的, 大家都很清楚, 展示了scrum团队下一步的工作内容.
  • 确保开发团队将产品待办事项列表中的项目理解到所需的水平.
  • 保持责任心,即使产品负责人可以让开发团队做上面的工作.

产品负责人是一个人,而不是一个委员会. 产品负责人可以在产品待办事项列表中代表委员会的愿望, 但是,那些想要更改产品待办事项列表项的优先级的人必须向产品所有者咨询.

图片显示了产品待办事项列表的一个例子,其中包括sprint 1-4

来源:“什么是产品负责人?”

信息技术的见解

为了产品负责人的成功,整个组织必须尊重他们的决定. 产品所有者的决策可以在产品待办事项列表的内容和顺序中看到. 不允许任何人告诉开发团队从不同的需求集开始工作, 开发团队不允许根据其他人的说法行事.

产品所有者和经理促进有效的决策制定和与交付团队的协调

产品交付需要所有角色和所有产品决策之间的集中协调, 以及一个开放的渠道,允许与利益相关者或他们的代理进行沟通. 没有适当的所有权, 您的交付团队可能无法有效地将有价值的产品发布与公司战略结合起来, 导致利益相关者不满. 产品所有权出现了两种角色:产品经理和产品所有者. 尽管在这些角色定义上缺乏行业标准,但许多组织都同意:

  • 产品经理拥有产品的战略规划、路线图和价值管理.
  • 产品负责人通过拥有战术计划和路线图来协调技术团队的交付和支持.

您可能不需要有单独的产品负责人和经理角色. 然而, 他们的责任, 岗位职责, 能力必须适应另一个合适的角色.

产品负责人和经理的一般职责

产品经理 (战略聚焦)

  • 理解市场问题/机会
  • 新产品创新/定义
  • 产品愿景和产品路线图
  • 释放的时机和焦点(i.e. 发布的主题)
  • 发布需求
  • 在开发周期内与工程协调
  • 产品策略、定位和信息传递
  • 定义定价和许可
  • 管理内部/外部发布支持
  • 持续优化产品相关的市场/销售活动
  • 竞争分析与定位
  • 赢/损失分析
  • 跨产品生命周期的跨职能沟通

产品负责人 (战术聚焦)

  • 总体待办事项管理:待办事项细化和优先级划分
  • 史诗/故事定义,与业务涉众一起细化
  • 与scrum管理员和其他利益相关者一起制定Sprint计划
  • 促进与sprint/故事实现相关的问题解决
  • 与scrum团队成员一起工作,尽量减少对scrum团队速度的干扰
  • 确保开发周期中业务团队和scrum团队之间的一致.g. 冲刺)
来源:《澳博体育app下载》

探索哪些现有角色可以顺利过渡到产品负责人和经理

产品所有者和经理促进业务和IT之间的讨论. 考虑到这些角色的重要性和可见性, 他们需要对商业关系和公司产品有丰富而深入的了解,并拥有丰富的技能. 在招聘新产品负责人之前,要在组织内部寻找潜在的合作伙伴和机会.

源前景 优势 缺点
业务分析师
  • 很强的分析能力
  • 良好的业务策略和运营理解
  • 涉众的接触
  • 可能没有决策权
  • 可能缺乏专业技术知识
业务主管
  • 有决策权和经验吗
  • 良好的业务策略和运营理解
  • 有其他的责任
  • 专注于单一业务线
  • 缺乏专业技术知识
  • 不太可能有良好的商业分析技能
项目经理
  • 有决策权和经验吗
  • 可能有良好的分析能力
  • 缺乏技术技能
  • 可能没有利益相关方联系人
  • 可能缺乏与交付团队的紧密关系
高级商务人士
  • 擅长单一业务
  • 有决策权和经验吗
  • 与企业的紧密联系
  • 有其他的责任
  • 可能对业务没有全面的了解
  • 缺乏技术技能或与IT涉众的联系
系统分析师
  • 较强的技术分析能力
  • 强大的专业技术
  • 提供全职
  • 可能与商业利益相关者没有很强的联系
来源: “产品所有者来自哪里?”

产品路线图是敏捷交付的关键

交付一个有价值的产品是一个“多方面的”过程, 复杂的学科很难掌握也很难掌握.这需要时间去学习、适应,并成为一名称职的产品经理或所有者. 采取战略性的方法来开发你的产品交付和管理能力.

来源:《澳博体育app下载》?”
显示产品路线图模型. 它展示了愿景和领导力之间的关系, 战略与市场研究, 产品生命周期管理, 和商业实践的一致性和财务.
改编自:“什么是产品管理?”

路线图将从想法到交付的解决方案的价值链联系在一起

展示了一个模型,以显示路线图如何将从想法到交付的解决方案的价值链联系起来

信息技术的见解

管理产品路线图的交付需要两个实践:

  1. 不关联不同工件类型的估计和跨团队使用的工件. 使用速度来推动团队的预测和持续改进.
  2. 使用对规模和复杂性的抽象度量,例如用户描述点, 功能点, 故事点可以让你测量你的交付速度.

根据你的情况,长期和详细的计划可能是有价值的,也可能是浪费的

路线图的理想场景的模型.

在理想的情况下, 详细说明的路线图, 承诺, 长期计划是非常有价值的,它可以使您的团队和涉众保持一致,并提高您满足项目成本的能力, 所需技能, 和交付日期.

路线图的现实场景的模型.

在现实中, 事情的变化. 您的战略意图是易变的, 特别是那些计划在未来时间的. 你在计划上的花费就越多, 如果这些计划改变了,你就越容易陷入效率低下和浪费的境地.

This is the fundamental problem true product roadmaps are 设计ed to solve; they 构建 in flexibility to h和le 改变. 然而,波动性并不是必然的,而且两者都有很长的时间线. 这将根据应用程序或产品的不同而有所不同. 您需要进行一些分析,以了解能够获得最大价值的最佳方法.

真正的问题是,你需要有多灵活?

待办事项说明了当前的需求,而路线图则说明了交付的结构

一个图表显示了路线图如何构造交付

“何时”:展示你何时能够交付以及交付之前的进展

里程碑

里程碑是时间轴上已建立的工件集完成时的点. 它们通常被指定一个日期,用来显示开发进度.

发布日期

发行版标志着打包在产品新版本中的一组工件的实际交付. 发布日期,无论是否确定,都允许涉众预测何时发布.

图表显示了里程碑和发布日期与进度和交付之间的关系.

信息技术的最佳实践

有些路线图甚至会更进一步,包括一个元素来可视化他们的冲刺周期. 这通常只在您构建更具战术性的路线图时被推荐. 在大多数情况下,理想的方法是将路线图保持在sprint级别之上.

考虑其他类型的里程碑或关键标志

学习的里程碑

一组用于验证业务机会和假设的工件的完成. 这些任务不在开发团队的范围内,而是集中在市场研究上. 这些可能发生在早期, 前发展, 建立你的产品策略, 或者在最有价值球员发布后评估用户的接受程度.

好处

  • 在产品构建之前,就产品策略与团队保持一致.
  • 花时间进行市场调查.
  • 尽早获得用户反馈.
  • 提供有关特性需求的信息.

Sprint零

通常在第一个sprint之前完成一组关键计划活动. 文物有助于建立建筑跑道(有关硬件和基础设施考虑的关键计划). 同时,建立和组建scrum团队. 这应该发生在开发之前,并且可以扩展到最初的几个sprint.

好处

  • 建立团队.
  • 建立关键计划.

市场策

你交付或销售产品的计划的完成. 这是你的产品团队的主要职责,也是你的产品战略的一个重要方面. 这发生在开发进行之后,但是在初始发行版之前有足够的时间.

好处

  • 提供关于调整其他里程碑或截止日期的信息.
  • 提供开发构件的其他信息.

理解使用里程碑的重要性

当我有sprint时,为什么要使用里程碑?

sprint是有时间限制的开发迭代,长度一致. 像里程碑, 它们对于管理开发非常有用, 跟踪吞吐量, 专注于商业价值. 但是它们通常并不代表对业务或其他特定涉众有意义的完整工件集合.

当我有发布时,为什么要使用里程碑?

发布是向客户交付某些东西的实际实例. 与里程碑一样,它们对于跟踪更大范围的工作的进展非常有用. 但是它们并不能代表那些没有以客户交付的形式出现的有意义的成就.

好处

  • 衡量交付的速度. 它们是进步的明显标志.
  • 当交付跟不上进度时,触发纠正措施.
  • 标记一个重要工作阶段的开始或结束.
  • 用于提供资源的目的(i.e. 不再需要有特定技能的个人).
  • 标记不同类型工件的顺序的重要点.

固定的时间和. 固定的基于功能的里程碑

定时的里程碑: 当建立的工件集在设定的日期交付时. 通常,一些工件或特性可以被视为独立的变量. 这在时间敏感性高的情况下更常用.

固定的特点: 当建立的工件完成时,才达到里程碑. 时间被视为自变量. 当创新是优先事项时,这种方法更常用, 并且给予开发团队高度的自主权和信任(适当的文化是先决条件).

灵活的里程碑: 单纯选择其中之一是不理想的. 估计的吞吐量速度可能是一个不可预测的因素. 设定固定的日期可能会迫使团队牺牲质量,无法实现里程碑的全部承诺. 相反,完全不设定日期实际上会保证交货延迟. 设定日期和特征采集为目标,并进行调整, 换换脑子, 并在发展过程中与业务部门进行沟通.

来源:“在项目管理中使用里程碑”

理解基于产品的视图如何应用于基于项目的交付,反之亦然

描述了一个模型来显示产品生命周期和项目生命周期之间的关系

产品中的项目

不管你认为自己是“以产品为基础”还是“以项目为基础”的商店, 同样的基本原则应该适用. 您要经历一个或多个类似项目的开发阶段,以构建应用程序或产品的版本. 在项目开发过程中,您还拥有并行服务, 哪个包含了更多的基于产品的观点. 这些服务范围从基本的支持和维护到成熟的战略团队或服务,如销售和市场. 所有的应用程序都可以被认为是产品,所有的产品都有项目.

在路线图中包含mvp是产品成功的关键

一个文本框显示了最有价值球员的定义,该定义有额外的解释.

构建-衡量-学习循环建议开发人员应该始终抓住一个想法并进行开发, 测试, 和验证, 因此,它可以利用所学到的经验教训和不断发展的想法来扩展产品. 从这个意义上说,最有价值球员只是循环中的第一个产品.

让你的最有价值球员代表一个里程碑(或此模型的任何组件)有助于团队, 业务, 客户也知道发展的重要时刻.

最低可销售产品(MMP) -将这个想法从一个学习工具扩展到“市场准备就绪”的最小产品.”

最低可销售功能(MMF) -是一个类似的概念,即在产品中添加面向市场的特性.

图像显示了构建-度量-学习循环模型

练习:如何支持产品负责人

1.1.4

预计时间:20分钟

  • 个人:在大的便利贴上确定你需要做的一到三件事来支持产品所有者(每个便利贴做一件事).
  • 轮流分享你的观察,并确定三个最关键的项目.
  • 轮流分享你最重要的东西.

Input

  • 今天的讨论

Output

  • 更清晰地理解产品所有者的需求

材料

  • 便利贴和记号笔

参与者

  • 所有

通过企业敏捷性认识到变更的价值

图中列出了领导和管理敏捷的关键方面. 强调的第四步是:企业敏捷性和变化的价值

技术已经成为一个组织的命脉的一部分. 任何业务流程都是由技术支持或支持技术交付的.

没有IT项目这回事.

最终, 我们的目标必须是创造卓越的客户服务,专注于尽早和持续地向客户交付价值. 这种价值是由我们的产品和服务带来的卓越客户体验所定义的.

许多供应商声称知道交付有价值的业务解决方案的正确方法

供应商标识被放置在一个图表上,并根据它们与四个类别的关系来放置:结构化的, 服务, 自适应, 和项目.
框架图片来源:“DevOps和用户体验在Concur”

怎样才能用你的产品和服务创造卓越的客户体验?

区分

组织

合作伙伴

的角度来看

图中有一个十字形状. 在顶部的标签是形状. 左臂是产品. 中间是积分. 在底部是交付. 右臂是服务.

清楚地了解你的产品和服务如何驱动客户和商业价值

业务价值定义必须来自业务,而不是IT. 他们是组织使命、愿景或授权的守护者. 让企业成为 权威的价值, 然后建立一种合作关系,在你的产品中定义这种价值. 列出定义产品和服务成功标准的业务价值来源. 请注意,这些驱动因素应该与您的整体业务战略相联系. 业务价值分为四类.

  • 利润一代- 从产品或业务能力中产生的收入.
  • 降低成本, 通过执行产品的业务能力来节省线下的运营成本.
  • 服务支持, 从增强的产品和能力中获得的内部业务操作的生产力和效率.
  • 客户和市场范围 度量在现有或新市场中提高的业务覆盖范围和洞察力的指标.
业务价值矩阵的模型

练习:确定您的业务价值来源

1.1.5

预计时间:1小时

  1. 扮演好产品、IT和业务涉众的角色. 这些人是组织管理机构中的关键战略伙伴.
  2. 使用挂图,绘制2x2业务价值矩阵.
  3. 头脑风暴一下你在便利贴上创造的不同类型的商业价值(每个便利贴一个项目). 从你的产品组合中举出例子.
  4. 筛选出对您的组织最重要的有价值的项目(每个象限两到三个).

给出了在练习1中将要创建的示例.1.5

Input

  • 理解利益相关者的优先次序和价值来源

Output

  • 业务价值来源来自组织所有领域的产品

材料

  • 活动挂图
  • 标记
  • 便签

参与者

  • 所有

成功地领导、管理和管理敏捷团队

图中列出了领导和管理敏捷的关键方面. 强调的第五个步骤是:解读敏捷:领导、管理和管理敏捷团队

让管理者焦虑的十大敏捷公理:

顾客法

  1. 公司通过不专注于赚钱来赚更多的钱.
  2. 没有内部客户.
  3. 没有B2B公司.
  4. 更好的产品往往赚不到钱.

小团队法则

  1. 忘记规模经济吧:你的市场只有一个人.
  2. 不要扩大规模:降低复杂性.
  3. 敏捷不是一个过程.
  4. 人才驱动战略,而不是反过来.

网络法则

  1. 通过放开控制来加强控制.
  2. 像园丁一样领导,而不是指挥官.
来源:《澳博体育app》

通过让IT参与进来来增加成功, 业务, 和客户在你的产品和服务路线图, 规划, 和交付

产品和服务管理和交付改善了IT之间的关系, 业务, 和客户, 推动业务满意度和客户价值.

协作

IT, 业务, 在产品生命周期的各个阶段,客户都在一起工作, 从市场调查到路线图和交付过程,再到维护和退役. 目标是确保在工作提交之前实现风险和依赖项.

沟通

优先考虑高价值的通信模式,以打破现有的藩篱,在各个功能之间建立共同的理解和协调. 这种方法增加了整个产品生命周期的透明度和可见性.

集成

探索集成工作流的方法, 业务决策和工具集, IT, 和客户. 其目标是对业务和客户期望的变化做出更积极的反应,并更积极地应对市场趋势.

在管理层的支持下,确保敏捷的长期成功推出

向敏捷的转变会被管理层视为失去控制. 帮助他们了解改善沟通、响应能力和成本控制的好处.

敏捷管理团队

提供持续的支持

而不是规定时间和范围, 管理层现在将通过帮助确定范围的优先级和解决相互冲突的需求来支持团队.

采取不干涉的方式

一旦确定了给定迭代的作用域, 在当前工作完成之前,管理层不会注入新的需求.

成为改变的催化剂

管理层应该鼓励将敏捷作为一种增加开发透明度的手段.

信息技术的见解

不要低估可能干扰敏捷实现的政治影响. 例如,在试点项目的后期转移资源,可能会破坏推出敏捷的尝试. 您将需要高层管理治理支持来解决这些问题.

治理应该关注风险和价值交付

理清治理和管理

治理机构将专注于确定方向, 投资组合, IT优先级与组织目标保持一致. 一旦定义了方向 治理机构将管理升级的异常 并根据目标监控绩效.

基于风险的治理

为了保持敏捷, 治理阈值/参与需要根据组织的风险来确定. IT领导层将需要被授权做出决策 在定义的风险阈值范围内,协同工作以推动成功.

在里程碑管理

治理主体应该使职责和议程与关键的战略决策和里程碑保持一致 不参与日常管理 工作是如何执行的.

衡量团队以推动改进

度量和报告IT的性能对于在新模型中建立信任至关重要 以及发现改进的机会. 治理主体都将具有一个性能度量元素,以推动持续改进.

执行原则和标准

为了推动组织的成功,it治理主体拥有强大的 专注于驱动纪律和监督对原则和标准的遵守.

练习:第1部分——你的领导和管理文化有多敏捷?

1.1.6

预计时间:30分钟

  1. 个人:确定你的组织中管理和领导文化的三到五个当前方面.
  2. 作为一个组,将它们映射到象限.
  3. 将象限作为敏捷成功的推动者/障碍进行汇报.

Input

  • 今天的讨论

Output

  • 更清晰地理解组织的文化和实施变革的障碍

材料

  • 便利贴和记号笔

参与者

  • 所有

练习:第二部分-描绘并讨论

1.1.6

预计时间:30分钟

4. 确定消除障碍的潜在行动.

第1部分第2部分的示例.1.6,象限和特征被显示.

Input

  • 今天的讨论

Output

  • 更清晰地理解组织的文化和实施变革的障碍

材料

  • 便利贴和记号笔

参与者

  • 所有

定义你的敏捷原则

图中列出了领导和管理敏捷的关键方面. 第六步是:定义你的敏捷原则.

敏捷的四个核心价值

我们的价值 . . .

这幅图展示了敏捷胜过规范的四个核心价值. 敏捷的价值观是:个人和互动, 工作软件, 客户协作, 应对变化. 规范性是:过程和工具, 全面的文档, 合同谈判, 和遵循计划

“...虽然右边的项有价值,但我们更看重左边的项.” ——来源: 《澳博体育app下载》

敏捷不仅仅是组织做的事情…….

敏捷带来了团队方式的彻底转变, 项目经理, 而涉众传统上计划并执行开发项目.

模型显示了说明性、敏捷和敏捷的区别.

“(‘实施’敏捷)只是一些例行公事,但没有重大的改变来支持端到端真正的敏捷方法, 业务集成, 价值的关注, 和团队授权.”

- Arie van Bennekum

并不是《澳博体育app下载》中的所有内容都应该被当作真理

不要把宣言太当真——它必须与项目团队的操作和工作流程一致,并且当意外情况发生时,不要增加项目失败的风险. 因此,要认识到宣言中的冗余、惯例和陈词滥调. 这里有5个重要的原则,不容忽视.

敏捷宣言的原则

  1. 我们的最高优先级是通过早期和持续的交付有价值的软件来满足客户.
  2. 欢迎变更需求,即使是在开发后期. 敏捷过程利用变更为客户提供竞争优势.
  3. 经常交付工作软件, 从几周到几个月, 优先选择较短的时间尺度.
  4. 业务人员和开发人员必须在整个项目中每天一起工作.
  5. 围绕有动力的个人构建项目. 给他们所需的环境和支持,相信他们能完成工作.
  6. 向开发团队传递信息的最有效的方法是面对面的交谈.
  7. 可工作的软件是进度的主要度量.
  8. 敏捷过程促进可持续开发. 发起人、开发人员和用户应该能够无限期地保持一个恒定的速度.
  9. 对技术卓越和良好设计的持续关注可以增强敏捷性.
  10. 简单——将未完成的工作量最大化的艺术——是至关重要的.
  11. 最好的架构、需求和设计来自自组织的团队.
  12. 定期, 团队思考如何变得更有效率, 然后相应地调整它的行为.
资料来源:《澳博体育app下载》; 敏捷! 好的,炒作的和丑陋的

锻炼:敏捷成功的原则

1.1.7

预计时间:30至40分钟

  1. 成功原则:名称和描述
    • 单独列出一到三件对领导和经理来说至关重要的事情,以推动敏捷在你的组织中取得成功.
    • 轮流与表组共享项目.
    • 作为一个团队,确定你们讨论过的最关键的项目.
    • 为你的活动挂图上的项目写一个简短的名字(3到5个单词).
    • 对这个项目做一个简短的描述(一句话).
    • 把你的姓名和描述提交给表格.
  2. 基本原理
    • 作为一个小组讨论这个原则将推动成功的原因.
    • 文件要点.
  3. 影响
    • 作为一个小组讨论这个原则将对组织产生的影响.
    • 文件要点.
  4. 现在
    • 每一桌将有一名志愿者介绍他们的原则.

Input

  • 你对公司的了解
  • 今天的讨论

Output

  • 成功的原则

材料

  • 活动挂图
  • 标记
  • 便签

参与者

  • 所有

致力于敏捷

图中列出了领导和管理敏捷的关键方面. 强调的第二步是:致力于敏捷

没有无痛的改变.

“就像第一次开一辆标准变速器的车, 改变一种根深蒂固的组织习惯是件伤脑筋的事。”

-《澳博体育app下载》

确保重点

人们必须能够专注于新的行为以使它们成为模式.

理解的期望

人们需要塑造自己的期望来做出改变.

开发实践

个人必须致力于并重复实践,这样才能使改变坚持下去.

步骤1.2:实现敏捷

这一步将引导你完成以下活动:

  • 促进交付团队的敏捷学习.
  • 敏捷实践和原则.
  • 基线的敏捷实践.
  • 识别并选择合适的敏捷试点人选.
  • Scrum模拟.

这一步骤涉及以下参与者:

  • 开发经理/副总/总监
  • 项目/项目经理
  • 外部培训师/咨询师
  • 敏捷教练
  • 产品经理/产品负责人
  • Scrum Master
  • 敏捷团队(业务分析师、开发人员、测试人员、架构师、QA、UI/UX设计师等.)

这一步的结果

  • 在组织的应用程序交付团队中构建敏捷实践的知识和理解.
  • 将组织对“敏捷”的理解标准化.”
  • 确定您组织当前的环境和采用敏捷的意愿.
  • 模拟基准scrum方法,进一步教育团队成功采用敏捷实践.

遵循结构化课程蓝图的其余部分,以促进敏捷团队成员的学习

领导和管理敏捷

第一阶段.蓝图1

参与者

管理人员和管理.

目的

在执行和管理团队中构建敏捷实践和概念的知识,以推动变革.

信息技术参与

为期一天的高管介绍和培训.

实施敏捷

第一阶段.这个蓝图的2到3个

参与者

敏捷团队成员.

目的

教育和支持敏捷团队,以确保成功采用敏捷实践.

信息技术参与

四天现场学习. 持续的敏捷教练.

如果你需要额外的支持, 作为信息技术研讨会的一部分,我们的分析师是否指导您度过这一阶段

与我们的信息技术分析师预订一场研讨会:

信息技术分析师的照片.
  • 为了加速这个项目, 让你的IT团队与信息技术分析师团队一起参加信息技术研讨会.
  • 信息技术分析师将在您所在的地点现场加入您和您的团队,或欢迎您到信息技术的多伦多办事处参加创新现场研讨会.
  • 联系你的客户经理.信息技术.com/account),或电子邮件 研讨会@InfoTech.com 的更多信息.

以下是信息技术分析师将与您的团队进行的活动示例:

活动1的截图.1.1

确定团队的敏捷角色

这个活动涉及到组织的领导者来确定和规划他们现有团队的角色和职责将如何与敏捷环境相一致. 这使得我们能够理解角色和责任是如何转变和发展以适应敏捷交付模型的.

活动1的截图.1.5

确定您的业务价值来源

此活动涉及业务和IT涉众,以确定组织的产品和服务如何驱动客户和业务价值. 它使我们能够理解企业的敏捷性以及敏捷实践所带来的变化的价值.

第二阶段

评估当前状态

第二阶段概述

电话1 - 或电子邮件 GuidedImplementations@InfoTech.com 的更多信息.

您可以自己完成这些步骤,或者请我们来完成指导实现. 指导实现是一系列2-3个咨询电话,帮助您执行项目的每个阶段. 他们被列入大多数顾问会员.

阶段2的指导实现. 包括列出这一阶段的结果和见解.

步骤2.1 .评估和准备你的团队

这一步将引导你完成以下活动:

  • 检查您的团队和组织的文化,以及它们如何影响采用敏捷实践.
  • SWOT分析.

这一步骤涉及以下参与者:

  • 开发经理/副总/总监
  • 项目/项目经理
  • 外部培训师/咨询师
  • 敏捷教练
  • 产品经理/产品负责人
  • Scrum Master
  • 敏捷团队(业务分析师、开发人员、测试人员、架构师、QA、UI/UX设计师等.)

这一步的结果

  • 一个完整的文化评估,以确定是否准备好并适合采用敏捷.
  • 一个完整的SWOT分析,以确定和确定优势, 弱点, 机会, 以及采用敏捷的威胁.

在实施敏捷之前确定您的差距,以确保成功

确保你的公司已经做好了交接的准备.

学习

敏捷是对人们工作和思考方式的根本性改变. 结构化, 在整个转变过程中,促进学习是必需的,以帮助领导者和实践者从实施敏捷到成为敏捷.

自动化

而敏捷在本质上是工具不可知的, 敏捷工作管理工具和DevOps启发了SDLC工具,它们已经成为敏捷实践的关键部分.

整合团队

而临时项目团队可以从敏捷中获得一些好处, 站, 跨业务的自组织团队, 交付, 和运维对于获得敏捷的全部好处是必不可少的.

指标和治理

成功的敏捷实现需要严格地使用交付和运营指标,以支持专注于开发更好团队的治理.

文化

敏捷团队认为,站立是创造价值的最佳方式, 自组织的跨职能团队,能够持续频繁地交付产品, 在领导者的指导下,通过挑战来实现短期的增量.

信息技术的见解

敏捷差距可能只会带来短期的、可感知的好处. 例如, 没有团队思维的编码可以让经验丰富的开发人员以最快的速度进入市场. 部署后的维护计划, 然而, 经常锁定单个开发人员,因为没有其他人了解所做决策的基本原理.

为成功的敏捷转换实现团队凝聚力

确保团队内部的沟通和高度的信任.

沟通

团队必须有某种沟通策略. 这可以分解为:

  • 规律: 每天有固定的时间来交流进展情况,并有固定的时间进行回顾.
  • 仪式: 给予奖励和不断强调价值的传递可以鼓励关系的建立和建设性的动机.
  • 升级: 表达任何担忧,并让人负责解决这些担忧.

接近

升级:表达任何担忧,并找人负责解决这些担忧.

  • 地点: 把团队布置得很近可以消除地理距离和时区差异的障碍.
  • 包含: 故意将远程团队成员拉进讨论和仪式中.
  • 通信工具: 拥有正确的技术.g. 视频会议)可以帮助团队更紧密地联系在一起.

信任

成员应该相信其他成员正在为项目做出贡献,并按时完成他们需要的任务. 信任可以通过以下方式发展和维持:

  • 问责制: 经常进行质量审查和反馈会议. 随着工作变得更加透明,人们变得更加负责.
  • 角色清晰: 对每个人的角色有一个清晰的定义.

信息技术的见解

为试点项目选择团队时, 包括高技能和高诚信的个人. 这些领导者有助于保持团队成员之间的沟通渠道畅通,并建立信任.

应该给你的敏捷团队足够的决策权

将决策过程下放给你的飞行员团队.

将您的业务涉众和主题专家聚集在一起,以确定潜在的高级风险.

与企业讨论他们愿意接受的风险水平.

定义项目团队在做出关键决策时的权限级别.

“尽可能把决策推到更低的层次, 直到sprint团队完全协调所有的集成, 发展, 和设计. 我把管理链条往上推就是冒险. (管理层)决定他们愿意承担多大程度的风险,(他们)通过你所做的决策来证明这一点."

-加拿大P高级经理&保险公司,信息技术访谈

让涉众和经理加入敏捷团队

  • 涉众反馈和管理支持是成功的敏捷试点的关键组成部分.
  • 涉众可以看到项目的进展,并在关键的里程碑上提供关于项目成功的关键反馈.
  • 管理通过信任团队,让他们在完成项目时将业务价值放在首位,并通过消除阻碍他们生产力的障碍,来帮助团队取得成功.
  • 敏捷将带来一种新的思维方式和大量的人员, 过程, 利益相关者和管理层可能不习惯的技术变化. 在试运行中处理这些问题可以使试运行后的演示更加平稳.
  • 领导参与的价值并没有改变,尽管责任会改变. 项目中的日常参与将会改变,但是持续的反馈将最终决定项目的成功或失败.
  • 管理将在确保敏捷的长期成功以及最终将其推广到组织的其他部分中扮演关键角色.

锻炼:敏捷是你的文化吗?

2.1.1

预计时间:1小时

  • 个人:确定组织文化的当前方面.
  • 作为一组将它们映射到象限.
  • 将象限作为敏捷成功的推动者/障碍进行汇报.

图像是练习2的一个例子.1.1

Input

  • 了解团队和组织的文化

Output

  • 影响协作、控制培养和影响能力的因素

材料

  • 便签
  • 标记

参与者

  • 所有

文档结果在信息技术 敏捷剧本模板.

使用有价值的工具和技术提高一致性并减少手工任务

敏捷的目标是提高响应能力, 但是,如果不充分的技术正在减缓沟通和流程,这就不可能发生.

建立可访问的、可扩展的和可靠的环境:

  • 强调 开发简单, 哪些对沟通有帮助.
  • 自动化 代码级测试以提高速度.
  • 启用 持续集成 具有自动构建功能.
  • 编写单元测试以增加可伸缩性 测试驱动开发.

利用适当的设计工具和软件:

  • 高层和详细的设计应该被用作沟通的载体 跨职能 开发、测试和运营团队.
  • 工具应该 可互操作的 因此,不同的开发领域可以在他们喜欢的工具中工作,并将开发和维护任务的可追溯性保持到业务需求.

信息技术的见解

组织正在利用应用程序生命周期管理(ALM)工具来提供开发任务的可跟踪性, 测试用例, 并支持机票回到业务需求. 这有助于确保每个活动都朝着业务价值的方向发展. 是指信息技术的 评估应用程序生命周期管理环境.

当你推出敏捷时,关注你的文化,确保每个人都有一个共同的基础

  • 你们多元化的团队提供了全面的产品. 当一个试点团队由不同技能的成员组成时, 意见, 和经验, 每个人都会带来不同的视角, 帮助最小化产品创建过程中的差距和缺陷.
  • 你的团队不害怕冒险. 当飞行员团队愿意冒险并且知道他们不会受到惩罚时, 他们会进一步推动自己的创造力,可能会想出别人不敢尝试的东西. 首先要建立信任.
  • 你的团队成员要对其他人负责. 当团队对其他人负责时,他们更容易在最后期限前完成任务,工作也更聪明,因为他们不想让团队失望.
  • 你的团队是价值驱动的. 他们在预期的时间内向终端用户交付高质量的产品. 实现这一目标需要一种特定的心态, 团队把失败当作学习的机会, 寻求持续改进敏捷过程,以在不损害涉众一致性的情况下提高吞吐量或生产率, 并快速回应反馈.

评估您的敏捷实现文化,以确保价值观是有基础的

敏捷失败的一个常见原因是组织文化过于政治化,并锁定在传统的思维模式中. 通过采用正确的价值观和创建适当的组织结构来避免这个问题.

建立敏捷文化, 你必须重视在整个组织中创造共同的价值观和愿景. 采取下列:

  • 欢迎并接受工作环境和项目需求的变化.
  • 强调交付给客户的高价值,而不是仅仅在最后期限.
  • 建立一个互动、协作和鼓舞人心的工作环境.

组织结构

严格的层次和结构是采用敏捷的重大挑战. 成功实施敏捷的组织有:

  • 具有明确角色和职责的合作性组织文化.
  • 高度重视面对面的沟通和透明的开发过程, 优先级, 和时间表.
  • 接受并鼓励敏捷实践和理念的业务和技术团队.

信息技术的见解

传统上强调“按时”和“按预算”的价值交付,在当前知识的基础上设想了一个巨大的前瞻性范围,这使得价值主张具有风险,几乎不可能实现. 意图是正确的,但执行是有缺陷的.

练习:进行SWOT分析,以揭示组织中的额外缺口

2.1.2

预计时间:2小时

  1. 使用便签, 写的优点, 弱点, 机会, 以及威胁(每个便利贴一个),因为它们属于您的开发环境的当前状态. 考虑人员、过程和技术元素.
  2. 用一块白板,把便利贴放在象限的适当位置上.
  3. 讨论敏捷如何减轻您的弱点, 产生的机会, 并威胁到你的敏捷部署.

练习2中要做的事情的例子.1.2

Input

  • 了解当前的开发环境
  • 对团队成员的理解

Output

  • 当前SDLC的SWOT分析

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

步骤2.2 .评估SDLC

这一步将引导你完成以下活动:

  • 确定并描述SDLC的阶段门.
  • 绘制当前SDLC流程.
  • 确定SDLC中的痛点.

这一步骤涉及以下参与者:

  • 开发经理/副总/总监
  • 项目/项目经理
  • 外部培训师/咨询师
  • 敏捷教练
  • 产品经理/产品负责人
  • Scrum Master
  • 敏捷团队(业务分析师、开发人员、测试人员、架构师、QA、UI/UX设计师等.)

这一步的结果

  • 完成SDLC阶段-关卡.
  • SDLC流程流.
  • SDLC中的痛点与敏捷相关.

评估SDLC的当前状态

SDLC识别核心构件, 角色, 以及交付有价值的特性所涉及的活动, 软件, 并对涉众进行修复, 无论你使用的是瀑布方法还是敏捷方法. 仔细看看SDLC的以下组件,以揭示任何可能对你的敏捷实现和试点项目构成风险的问题和挑战:

记住,敏捷只是一种执行SDLC的方法. 由于增加了透明度,使用敏捷将暴露现有的SDLC问题和效率低下. 在某些情况下,这些问题以前可能被掩盖或无关紧要. 主动识别和处理任何潜在的SDLC人员, 过程, 或者在产生冲突和破坏你的敏捷试点项目之前,避免技术风险.

SDLC服务和功能统称为SDLC实践. 因此, 你的团队的责任和责任, 通信流, 决策权必须清楚地支持这些能力, 团队中的角色必须胜任. 理解SDLC实践中需要的各种功能,以及支持它们的基本职责和责任.

SDLC功能

  • 软件编码 & 构建管理
  • 团队文化
  • 团队设计 & 治理
  • 资源分配 & 能力
  • 人的发展
  • 知识管理
  • 系统配置
  • 软件质量保证
  • 选择 & 采购
  • 需求收集 & 管理
  • 应用程序 & 产品组合管理
  • 释放 & 部署管理
  • 企业 & 应用程序体系结构
  • 测试管理
  • 应用程序支持
  • 用户体验
  • 业务关系管理
  • 维修管理
  • 供应商管理

练习:确定并描述你的SDLC阶段门

2.2.1

预计时间:30分钟

  1. 列出开发过程的主要阶段控制,并确定谁负责.
  2. 简要定义每个台阶门和所需的通过标准.
  3. 问自己以下问题:
阶段 签字的 定义和通过标准
初始化 比利·史密斯(企业利益相关者) 业务需求的高级定义,以及实现可执行/不执行决策的可行性分析.
  • 需求包括范围和驱动因素.
  • 可行性包括高级业务需求、成本和收益.

Input

  • 了解当前SDLC的阶段和交接点

Output

  • 舞台门的定义和通过标准

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

练习:画出当前的SDLC

2.2.2

估计时间:1.5个小时

  1. 使用SDLC舞台门作为起点, 将当前开发过程绘制为泳道图.
  2. 确定流程的每个步骤都涉及到谁,以及使用了什么工具和技术.
  3. 确定何时创建和验证SDLC构件. 如果工件没有被批准,这些验证点应该指示工作流.

Input

  • 工件列表
  • 开发角色
  • SDLC阶段-关卡

Output

  • SDLC接地工艺流程

材料

  • 白板
  • 标记

参与者

  • 开发团队

例子:

练习2例子.2.2

文档结果在信息技术 敏捷剧本模板.

运动:确定当前SDLC中的痛点

2.2.3

预计时间:1小时

  1. 用你的SWOT分析作为一个起点, 突出你当前SDLC中的痛点和挑战. 考虑以下挑战和痛点:
    • 角色、团队和涉众之间的工件传递很差.
    • 瓶颈是指花费了过多的时间来完成任务或团队正在等待相关任务的完成.
    • 缺乏涉众参与,导致应用程序质量低下.
    • 糟糕的开发实践,产生技术债务.
    • 缺少标准,导致不一致地遵循流程和结构.
  2. 通过问“为什么”来确定每个痛点和挑战的根本原因?“三次. 考虑下面的例子:

练习2例子.2.3

Input

  • 当前SDLC工艺流程

Output

  • SDLC痛点列表

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队

例子:

练习2的另一个例子.2.3

文档结果在信息技术 敏捷剧本模板.

瀑布式SDLC——在扩展的项目生命周期结束时交付的有价值的产品, 近年来频繁

就业务、开发和运营中交付的产品而言,瀑布式SDLC模型.
  • 业务与技术交付分离 it needs; only one third of product is actually valuable (ITRG, N=40,000).
  • 在《澳博体育app》中,一个团队是 特定学科的专家 移交生命周期的不同方面.
  • 需要签署文件 确保竖井(业务、开发和运营)与个人之间的集成.
  • 一个单独的变更请求过程覆盖整个生命周期 防止变更扰乱交付.
  • 通过部署工具支持特定的角色 (e.g. BA) ,很少集成 (通常是需求-测试).

Wagile/Agifall/WaterScrumFall SDLC -在多个版本中交付的有价值的产品

就商业交付的产品而言,Wagile/Agifall/WaterScrumFall SDLC模型, 发展, 和操作.
  • 业务是由业务产品负责人更紧密地集成起来的,他负责为用户每天交付价值.
  • 团队协作,发展跨职能技能 随着时间的推移,他们定义、设计、构建和测试代码.
  • 信号减少 但是文档仍然关注于满足项目交付和操作政策需求.
  • 变化是过程的一部分 使团队能够动态地响应变更.
  • 工具开始被集成以简化交付 (通常是需求和敏捷工作管理工具).

敏捷SDLC——迭代交付有价值的产品:频率取决于运维团队的能力

基于业务、开发和运营中交付的产品的敏捷SDLC模型.
  • 业务用户通过定期安排的演示(例如.g. 每两周).
  • 团队是完全跨职能和协作的计划, 定义, 设计, 构建, 并测试由专家支持的代码.
  • 变更被构建到过程中 允许团队动态地响应变更.
  • 探索应用程序开发的自动化 (e.g. 自动回归测试).

SDLC——高频率的迭代交付有价值的产品(例如,DevOps).g. 每两周)

在业务交付产品方面,使用DevOps的SDLC建立敏捷模型, 发展, 和操作.
  • 业务用户通过定期安排的演示紧密地集成在一起.
  • 开发和运营团队协作 计划、定义、设计、构建、测试和部署自动化支持的代码.
  • 文档 是否专注于支持用户、未来更改和操作支持.
  • 变更被构建到过程中 允许团队动态地响应变更.
  • 构建、测试和部署都是完全自动化的 (服务台仍分开).

DevOps SDLC -持续集成和交付

就业务、开发和运营中交付的产品而言,DevOps SDLC模型.
  • 业务用户通过定期安排的演示紧密地集成在一起.
  • 完全集成的DevOps团队协作 计划、定义、设计、构建、测试、部署和维护代码.
  • 文档 关注未来的开发和使用采用吗.
  • 变更被构建到过程中 允许团队动态地响应变更.
  • 完全集成的开发和操作工具链.

完全集成的产品SDLC -敏捷+ DevOps +按需持续交付有价值的产品

模型完全集成的产品SDLC
  • 业务用户与整个团队完全集成 专注的业务产品负责人.
  • 跨职能团队协作 贯穿产品的业务和技术生命周期.
  • 文档 支持内部和外部需求(业务、用户、运营).
  • 变更被构建到过程中 允许团队动态地响应变更.
  • 完全集成的工具链 (包括服务台).

如果你需要额外的支持, 作为信息技术研讨会的一部分,我们的分析师是否指导您度过这一阶段

与我们的信息技术分析师预订一场研讨会:

信息技术分析师的照片.

  • 为了加速这个项目, 让你的IT团队与信息技术分析师团队一起参加信息技术研讨会.
  • 信息技术分析师将在您所在的地点现场加入您和您的团队,或欢迎您到信息技术的多伦多办事处参加创新现场研讨会.
  • 联系你的客户经理.信息技术.com/account),或电子邮件 研讨会@InfoTech.com 的更多信息.

以下是信息技术分析师将与您的团队进行的活动示例:

步骤2的截图.2.1

SWOT分析

该活动涉及到交付团队和其他涉众,以确定和确定优势, 弱点, 机会, 以及在环境中成功采用和实施敏捷的威胁. 通过发现这些司机或路障, 团队了解如何利用他们的优势来减少威胁,并通过利用他们的机会来降低弱点.

步骤2的截图.2.2

记录SDLC过程

此活动涉及交付团队和其他涉众,以记录他们当前的SDLC过程及其痛点, 差距, 以及改进的机会. 这使我们能够进一步讨论SDLC过程将如何通过敏捷之旅变得成熟.

第三阶段

执行结构化评估

第三阶段概述

打1号电话或发邮件 GuidedImplementations@InfoTech.com 的更多信息.

您可以自己完成这些步骤,或者请我们来完成指导实现. 指导实现是一系列2-3个咨询电话,帮助您执行项目的每个阶段. 他们被列入大多数顾问会员.

指导第三阶段的实施. 包括列出这一阶段的结果和见解.

步骤3.1:理解Scrum

这一步将引导你完成以下活动:

  • 识别和评估业务价值定义.
  • 确定“准备好”和“完成”的定义.
  • 基线scrum方法和实践.

这一步骤涉及以下参与者:

  • 开发经理/副总/总监
  • 项目/项目经理
  • 外部培训师/咨询师
  • 敏捷教练
  • 产品经理/产品负责人
  • Scrum Master
  • 敏捷团队(业务分析师、开发人员、测试人员、架构师、QA、UI/UX设计师等.)

这一步的结果

  • 完成的业务价值定义.
  • 完成“准备好”和“完成”的定义.
  • 对scrum方法和采用这些实践的好处有更深的理解.

理解结构化评估对成功采用敏捷的重要性

研究表明, 敏捷 感觉 更好的 和很 适合软件开发 团队. 然而,并不是所有的组织都准备好或有能力转向敏捷. 你的 结构化的评估 帮助你 确定并测试运行敏捷实践 在受控和预设的环境下定义 采用敏捷的成功率 在你的组织. 而 一名飞行员团队 不能决定敏捷在整个组织中的成功, 它为你提供了一个平台 快速失败,快速恢复 从团队的错误中吸取教训,专注于 不断改善. 你的结构化评估允许你这样做 确定什么有效,什么无效 并以一个 迭代方法 在你的组织中引入敏捷.

结构化评估=试点项目/计划/团队

从基线scrum实现开始

使用scrum作为你的敏捷实现的起点,因为它的流行和社区的支持.

为什么要从scrum开始?

简单性: Scrum的哲学和方法很简单, 说明性的, 而且,可用于协助实施的现有资源也很广泛.

灵活性: Scrum是构建个性化敏捷过程策略的理想基础. 技术敏捷技术, 比如结对编程和持续集成, 容易注射.

成功: Scrum在应对需求变化方面取得了很多成功, 增加团队内部的协作和交流, 提高与利益相关者的透明度.

要意识到scrum的局限性

  • 经营风险: 如果企业没有明确的方向,Scrum无法拯救产品的开发.
  • 分辨率无关: Scrum暴露了障碍和问题,但没有提供如何解决问题的见解.
  • 重新定义的角色: Scrum可以大大改变现有项目团队的角色和职责.

信息技术的见解

  • 使用众所周知的、照本宣本的scrum流程和工件来简化初始试点的推出. 随着您获得更多的经验,逐渐修改这些过程和工件以更好地适应您的环境.
  • 可能需要引入敏捷教练来帮助提供培训.
  • 没有指定的项目经理, 但领导者仍然需要挑战团队以提高.

熟悉scrum中使用的关键术语

  • 用户故事, 从客户的角度对所需功能的简短描述. 用户描述提供了关于功能的足够信息, 谁将使用它, 以及它会给用户带来什么好处.
  • 仪式上, 开发团队和涉众聚在一起讨论的协作会议, 审查, 反思, 评估正在进行的工作, 最近的经历, 和经验教训. 在scrum方法中, 仪式包括发布计划, sprint计划, 脱口秀, 回顾, sprint审查, 和示威.
  • 史诗, 描述重要和大型开发计划的类似用户故事的集合.
  • 点- 敏捷团队用来评估完成用户故事、史诗或主题所需付出的努力的任意值. 团队的评估是基于他们的消费能力(i.e. 燃尽)点. 斐波那契数列或指数值是常用的点格式. 在某些情况下,点被用来评估和衡量业务价值的交付.
  • 主题- - - - - - 用于定义高级业务目标的类似史诗的集合.
  • 冲刺, 有时间限制的开发迭代,业务价值理想地在最后交付, 不管那是人为的(例如.g. 线框图设计)来审查或部署特性. 在一个项目中,冲刺的长度是一致的(平均两到四周).
  • 积压, 为开发团队列出了用户故事、史诗和/或主题的优先级列表.
  • 发布里程碑处, 开发过程中的一个重要阶段,在此阶段有一组一致同意的用户描述, 史诗, 主题将被传递给客户. 每个里程碑的范围被分解成相同大小的冲刺.

理解scrum流程

scrum流程协调多个涉众来交付业务优先级.

一个模型展示了scrum流程中的4个步骤

注意:功能需求, 哪些是你的产品和sprint的待办事项列表, 通常是作为简短的用户故事编写的吗. 一旦这些用户场景“准备好”并为立即开发设定优先级,就会向它们添加额外的细节.

理解scrum过程的仪式部分

scrum过程中仪式的模型

利用敏捷的促进工具来帮助编写敏捷工件的文档

3.1.1 Scrum文档模板

信息技术的见解

在你的第一个敏捷实现中,使用一块白板作为scrum board. 白板是一种理想的学习媒介,因为团队可以直观地看到用户故事是如何编写的, 移动, 和 burned down; how feedback 和 路障 can disrupt project progress; 和 how project 和 resource dependencies are managed. 从白板中学到的经验教训可以转化为敏捷的促进工具, 如信息技术的 Scrum文档模板.

使用信息技术的Scrum文档模板

记录您的用户故事, 任务, 点估计, 一旦你制定了发行和冲刺计划,就会有burndown, 脱口秀, 回顾已经结束. 蓝图将指示您应该何时向该模板添加信息.

目标:

  • 根据过去的表现生成团队的速度.
  • 基于过去sprint计划结果的基准估计.
  • 演示关键计划如何提高团队完成用户描述的能力.

Info-Tech的Sprint计划工具的截图

许多ALM供应商提供产品来帮助和增强敏捷开发的便利. 他们的虚拟scrum board是分布式团队成员和每个敏捷构件的理想选择.g. 用户故事、燃尽图)被自动记录和监控. 是指信息技术的 评估应用程序生命周期管理环境.

建立scrum角色和职责

产品负责人Scrum Master 团队成员
负责任的
  • 在最终项目中识别产品特性及其重要性.
  • 为了根据业务重要性来确定哪些特性将在下一个sprint中交付,对待办事项列表进行细化和重新排序.
  • 为了增加阻滞剂和风险.
  • 用于领导scrum、回顾、sprint回顾和演示.
  • 用于团队建设和解决团队冲突.
  • 用于创建、测试、部署和支持可交付和有价值的特性.
  • 的自我管理. 没有项目经理给每个团队成员分配任务.
负责任的
  • 为涉众交付有价值的特性.
  • 确保开发过程中的交流.
  • 为产品负责人确保高质量的可交付成果.
咨询
  • 通过团队合作,而不是合同谈判.
  • 由产品负责人负责风险的解决.
  • 由团队提出改进建议.
  • 在sprint计划期间,由scrum负责人和产品负责人确定任务的复杂程度.
通知
  • 关于当前冲刺的进度.
  • 由团队在当前sprint期间完成的工作.
  • 业务方向和当前优先级.

看看传统的开发角色如何转化为scrum中的角色

当过渡到scrum时,开发角色可能会发生转换, 但每个角色的价值将保持不变.

一个模型列出了传统角色,以及新的scrum角色如何包含传统角色.

信息技术的见解

  • 注意利益冲突——如果没有正确的训练,传统的角色(如.g. BAs和pm)可能会继续为您的试点项目带来传统的思维和优先级. 这将抵消您希望实现的目标,并与您的开发指南发生冲突.
  • 轮换scrum管理员——任何人都可以担任scrum管理员, 只要他们对开发动态有深刻的理解,对敏捷和scrum概念有深刻的理解.
  • 保持团队规模为5-9名成员——这种规模有助于简化团队成员之间的任务协调和协作. 可以创建独立的团队来支持开发团队(例如.g. 安全, 架构师), 但是他们必须与开发团队积极沟通,并在关键的scrum活动中进行协作.

在训练阶段和最初的冲刺阶段充分利用教练的专业知识

如果使用教练,他们应该:

  • 了解团队当前的情况 帮助您定制最适合您需求的敏捷过程和文化.
  • 在团队的第一个冲刺阶段与他们紧密合作 (e.g. 第一次规划会议, 第一组日常会议, 第一次回顾),然后随着团队获得更多经验,慢慢地停止. 当团队能够独立运行关键的敏捷仪式(阶段)时,教练最终会退出.
  • 请注意,没有两个团队会面临相同的挑战和障碍. 一些团队可能需要显著和快速的改变来弥补主要的差距, 而其他人可能只需要知识和说服力. 您的敏捷教练是否带领您的培训课程,使您的团队快速跟上进度,并让他们适应这些变化.
  • 鼓励其他团队的领导 促进相互回顾,以促进知识分享.

信息技术的见解

你的教练可以帮助你进行回顾. 它们可以帮助发现团队遇到的问题, 基于这些问题创建优化用户故事并对其进行优先级排序, 并协助确保这些故事被注入到团队的待办事项列表中.

在您的环境中定义业务价值,以定义敏捷试点的成功

我如何定义业务价值?

业务价值必须来自业务,而不是IT. 他们是组织使命、愿景和授权的守护者. 让企业成为 权威的价值, 然后建立一个伙伴关系,在您的敏捷试点环境中定义该价值.

要考虑的象限的模型,以帮助定义业务价值.

考虑您的敏捷试点可以创造价值的所有方式. 然后与企业合作,确定您的组织 独特的业务价值驱动因素 并根据组织的总体战略来权衡这些因素.

如何度量业务价值?

业务价值并不总是用货币来表示. 取一个 平衡的方法 通过权衡不同的价值来源和分配指标来衡量和跟踪您的飞行员的价值.

平衡方法的模型,以实现平衡的应用程序业务价值.

信息技术的见解

将情绪从评估中移除.

根据一组健壮的业务价值度量标准来评估您的敏捷试点项目,可以确保对试点项目的实际重要性有一个关键的理解, 减少每个人的偏见, 消除了“房间里声音最大”的决策风格.

活动:清楚地说明你对业务价值的定义

3.1.1

预计时间:30分钟

  1. 列出将对您的业务涉众定义项目可交付物价值的关键驱动因素. 讨论如何将这些驱动程序应用到以前的项目中.
    • 业务价值驱动因素可以是您的业务目标.
  2. 定义用于衡量每个驱动程序的指标.
  3. 确定如何定性和/或定量地测量这些驱动因素.

活动的例子3.1.1

Input

  • 了解组织的业务价值驱动因素
  • 业务目标

Output

  • 业务价值驱动的定义

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

确保开发的要求和需求已经准备就绪

明确定义它对需求的意义, 改变, 或维护请求,为开发做好准备. 这将有助于确保每个功能和变更的价值和范围是清晰的,并且在sprint开始之前,开发人员和涉众都能很好地理解. ready的定义应该有两个方面:准备好待办事项和准备好编码.

  1. 创建一个检查清单,指出开发待办事项列表中的需求或请求何时准备就绪. 考虑以下问题:
    • 要求或请求的格式是否正确?
    • 所需的功能或更改是否具有重要的业务价值?
    • 在当前环境下,需求或请求能否在定义的发布时间内合理地完成?
    • 开发团队是否同意预算和估算?
    • 是否从涉众或用户的角度理解了需求或请求的含义?
  2. 创建一个清单,指出需求或请求何时准备好进行开发. 考虑以下问题:
    • 需求和请求是否在待办事项列表中被划分了优先级?
    • 团队是否在如何完成所需的功能或更改方面进行了充分的合作?
    • 每个需求或请求中的任务是否包含足够的细节和开始开发的方向?
    • 需求或请求能被分解成更小的部分吗?

利用INVEST模型来确定用户故事何时可以进行开发

我们的目标是优化你的用户故事,使它们是:

独立: 理想情况下,你的用户故事可以按照任何顺序构建(i.e. 彼此独立). 这允许您根据价值进行优先级排序,而不会被打乱顺序和先决条件.

可转让: 正如纯粹的敏捷主义者会告诉您的那样,关注协作而不是合同. 您的用户情景旨在促进开发人员和业务人员之间的协作. 因此,它们的建立应使各方能够进行谈判.

有价值的: 这里没有最新进展. 用户描述需要声明该值,以便有效地对其进行优先级划分, 但也让开发人员知道他们正在构建什么.

可尊敬的: 而不是给予史诗更高级的近似, 用户故事的估计需要更准确,才能有效地划分优先级, 同时,团队也可以知道什么是适合sprint或发布计划的.

小: 用户故事应该足够小,以适应一个sprint. 然而,团队规模和速度将会影响到能够完成多少任务.

可测试性: 您的故事需要是可测试的,这意味着您需要满足质量保证标准.

来源:“敏捷新手? 投资好用户故事"

建立你对“完成”的定义

明确定义要做的特性或变更意味着什么. 这将有助于确保完成的特性或变更满足涉众的期望,并且对于下游活动是稳定的, 例如测试和部署. 已完成的定义应该包括两个方面:功能完整性和涉众对齐方面的完成.

  • 创建一个检查表,指出某个特性或更改在功能上何时完成. 考虑以下问题:
    • 特性或变更是否按照业务需求或请求中的描述执行?
    • 解决方案是充分的单位吗, 回归, 和集成测试,它在QA中是否稳定, 暂存, 和生产环境?
    • 解决方案是否使自己与现有的安全协议保持一致, 规定, 可用性需求, 以及其他非功能性需求?
  • 创建一个清单,指出什么时候根据涉众的期望完成了特性或变更. 考虑以下问题:
    • 项目涉众和最终用户是否可以接受已完成的特性或变更?
    • 它的部署是否会导致重大的业务中断?

完成:

当用户描述被产品所有者接受并准备发布时.

完成:完成

当用户场景交付给客户时.

完成完成完成:

当用户场景在生产中拥有支持它的必要文档时.

活动:清楚地说明你对“准备好”和“完成”的定义

3.1.2

预计时间:30分钟

  1. 回顾当前开发过程中的步骤和阶段门. 确定启动和完成给定任务所需的标准.
  2. 使用这个标准来定义您的准备和完成的标准.
  3. 创建一个清单,以帮助确保这些标准被一致地遵循.
定义 检查表
准备好了 用户故事和相关需求文档包含了对给定功能的期望的清晰描述. 业务价值被识别.
  • 识别技术和业务风险.
  • 发展方面有资源.
  • 业务价值被定义.
完成 已完成的工件是稳定的,并包含用于部署的环境需求.
  • 功能已经过测试.
  • 提供生产环境配置.

Input

  • 定义就绪和完成的标准
  • 了解敏捷中准备和完成的意义

Output

  • 为您的敏捷团队定义就绪和已完成的工作

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

理解在敏捷世界中需求是如何转换的

瀑布法中的业务需求并不等同于敏捷中的用户故事
瀑布 敏捷 的关系 定义
原始的想法 的想法 是由一个或多个… 一个有价值的, 但部分定义的目标或目标需要不同团队的进一步分析.
业务需求 史诗 是由一个或多个… 一种目标或目标的陈述,它可以被估计,并对组织具有明确的业务价值.
涉众需求 能力 是由一个或多个… 一种产品或服务,一个或多个涉众需要它来满足业务需求,对组织具有可衡量的价值.
功能性需求 功能 被一个或多个… 解决方案需要向涉众提供的功能和信息,以满足涉众的需求,并且对涉众具有指定的值.
N/A 用户故事 复制一段对话 用户情景是管理需求、设计、开发和测试的有用工具. 不要将它们与管理产品待办事项列表和路线图所需的需求混淆.
活动 任务 每个工件一个或多个… 交付团队为了满足需求必须做的事情.

不要忘记您的使能者,即为将来的功能提供手段的PBIs

An 推动者 是否需要任何支持活动来为将来的功能提供方法. 使能者构建产品的技术基础, 也被称为建筑跑道.

考虑粒度

再一次, 你的听众会决定你应该包含多少细节, 但根据经验,最好还是专注于功能层面.

敏捷 瀑布
推动者史诗 非功能子类型和需求子类型扮演这个角色(例如.g. 数据要求)
使能者功能
推动者的故事

考虑类型

探索

努力了解客户或用户的需求,并创造解决方案和替代方案. 探索使能者与学习里程碑密切相关.

建筑

构建体系结构组件的任何努力. 这些通常与交付团队联系在一起,而不是纯粹的开发团队.

基础设施

任何构建各种开发和测试环境的努力. 同样,这些是与其他交付团队相关的工件.

合规

在您的开发活动中,任何针对法规和遵从性需求的努力. 这些可以是内部的,也可以是外部的.

来源:“敏捷扩展框架”

步骤3.2:评估利益相关者的参与

这一步将引导你完成以下活动:

  • 确定利益相关者和团体.
  • 评估和优先考虑所有利益相关者和团体.
  • 确定和评估战略,使利益相关者和团体参与.

这一步骤涉及以下参与者:

  • 开发经理/副总/总监
  • 项目/项目经理
  • 外部培训师/咨询师
  • 敏捷教练
  • 产品经理/产品负责人
  • Scrum Master
  • 敏捷团队(业务分析师、开发人员、测试人员、架构师、QA、UI/UX设计师等.)

这一步的结果

  • 相关的涉众小组和他们的优先级,因为它与您的敏捷转换相关.
  • 根据利益相关者的优先顺序完成利益相关者参与策略.

理解涉众参与敏捷转换的重要性

利益相关者 组织中是否有一群人对你的产品有兴趣或有影响, 程序, 团队, 或项目, 从而影响你的敏捷转换.

涉众管理的挑战是什么?

  1. 组织政治
  2. 竞争,冲突的历史

  3. 偏差
  4. 优先级不一致,愿景和目标不一致

  5. 拍摄的信使
  6. 害怕拒绝利益相关者,这在过去是不会发生的, 害怕传达与预期不符的坏消息

  7. 利益相关者的变化
  8. 人员流动,可能需要从零开始建立关系

采用一个涉众管理过程来识别和评估将在您的过程中帮助您的涉众

模型中有四个正方形,中间有一个圆. 这个圆圈被标记为经常交流. 正方形被标记为:识别利益相关者, 评估的利益相关者, 优先考虑利益相关者, 并与利益相关者.

确定将与您一起踏上敏捷之旅的正确的涉众

并不是所有的利益相关者群体都是天生的明显的,也不是所有的利益相关者群体都将是您转型的推动者. 一些经常被忽视的团体包括分包商, 供应商, 竞争对手, 监管机构, 它行动, 和产品支持. 在识别阶段,把你的精力集中在从利益相关者群体中筛选出两类人,以确定他们是支持者还是反对者:

  • 他们影响敏捷计划的能力是什么?
  • 他们是主题专家吗? 他们能增强主动性吗?
  • 他们会减慢团队、项目或主动性吗?
  • 它们能在排除障碍方面起到指导作用吗?
  • 他们能领导意见吗??
  • 他们是否有能力促进由转换产生的变化?
  • 他们能发出理性的声音吗?

确定他们的影响和影响的性质将帮助您调整您的方法,使特定的利益相关者参与.

练习:将涉众群体确定为敏捷转换的一部分,并对他们进行分类

3.2.1

预计时间:30分钟

  1. 列出在敏捷转换过程中扮演重要角色的每一个涉众小组.
  2. 回顾上一张幻灯片中的列表,对每个利益相关者小组进行审查,以确定他们的影响力和影响水平.
  3. 基于团队的投入, 共同决定每个利益相关者群体(支持者或反对者)的分类.
  4. 确定他们参与的性质将影响你如何优先考虑他们,并最终在你的旅程中与他们合作.
利益相关者群体 他们影响敏捷计划的能力是什么? 他们是主题专家吗? 他们能增强主动性吗? 他们会减慢团队、项目或主动性吗? 分类
首席信息官 是的 不可能 支持者
监管机构X No 是的 N/A

Input

  • 利益相关者团体名单
  • 确定要分类的问题的范围

Output

  • 的利益相关者
  • 每个利益相关者群体的分类

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

使用CLAIM模型定义和评估敏捷转换中涉及的涉众

涉众反馈和管理支持是成功的敏捷转型的关键组成部分:

文化
  • 敏捷将带来一种新的思维方式和大量的人员, 过程, 利益相关者和管理层可能不习惯的技术变化. 在试运行中处理这些问题可以使试运行后的演示更加平稳.
  • 转换支持者(在团队和组织级别).
  • 转换阻力(在团队和组织级别).
学习
  • 持续改进.
  • 服务型领导(他们理解并推广敏捷吗?).
自动化
  • 自动化的调查. 他们会对自动化调查持开放和诚实的态度吗? 通过引入新的工作方式,提供改进团队SDLC过程的方法.
  • 涉众愿意接受自动化的结果吗?
整合团队
  • 管理通过信任团队,让他们在完成项目时将业务价值放在首位,并通过消除阻碍他们生产力的障碍,来帮助团队取得成功.
指标 & 治理
  • 领导参与的价值并没有改变,尽管责任会改变. 项目中的日常参与将会改变,但是持续的反馈将最终决定项目的成功或失败.
  • 涉众可以看到项目的进展,并在关键的里程碑上提供关于项目成功的关键反馈.

练习:作为敏捷转换的一部分,评估所有涉众组

3.2.2

预计时间:30分钟

  1. 对于前面确定的每个利益相关者组, 列出他们所拥有的影响索赔模型每个部分的特征和行为(积极的和消极的).
  2. 基于对每个利益相关者组的描述, 确定您在敏捷之旅中可能遇到的最大沟通挑战或障碍.
利益相关者群体 文化 学习 自动化 沟通的挑战
首席信息官
监管机构X

Input

  • 利益相关者团体名单
  • 确定要评估的问题范围

Output

  • 的利益相关者
  • 对每个利益相关者组进行索赔评估
  • 沟通方面的挑战

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

根据涉众的规程级别和与业务的集成,对其进行优先级排序

图像分为高低纪律、高低整合四个象限.

练习:作为敏捷转换的一部分,优先考虑所有涉众群体

3.2.3

预计时间:30分钟

  1. 请参阅前面生成的涉众组列表, 然后把每一组映射到下面四个象限中的一个.

练习示例3.2.3

Input

  • 利益相关者团体名单
  • 确定问题的优先级

Output

  • 的利益相关者
  • 每个利益相关者群体的优先级和映射

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

根据涉众对您的敏捷之旅的影响和影响的性质,确定让涉众参与的策略

模型显示为四个象限:监视器, 保持通知, 积极参与, 保持满意,以帮助确定参与利益相关者的策略

练习:确定让利益相关者参与的策略

3.2.4

预计时间:30分钟

  1. 对于前面确定的每个利益相关者组, 参考它们的分类,并将它们列在一起,如下所示.
  2. 考虑他们的行为, 沟通的挑战, 以及他们的影响程度, 影响, 和优先级, 确定它们是否需要高-, 中期, 或低努力水平积极参与或其他.
  3. 头脑风暴策略,根据团队所需的努力和关注程度,有效地吸引每个利益相关者群体.
  4. 确保在向试点团队和业务推广敏捷时使用这些信息
利益相关者群体 支持者或批评者? 沟通的挑战 优先级 需要付出的努力 参与策略
首席信息官 支持者 偶尔 冠军 积极参与 通过激励(如何)邀请所有的演示?)
监管机构X 低-保持消息灵通

Input

  • 利益相关者团体名单
  • 确定参与工作的问题范围

Output

  • 的利益相关者
  • 每个利益相关者群体的参与努力和策略

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

步骤3.3:选择正确的飞行员

这一步将引导你完成以下活动:

  • 确定结构化评估的业务目标和指导原则.
  • 评估试点项目的复杂性、持续时间、相关性和所有权.

这一步骤涉及以下参与者:

  • 开发经理/副总/总监
  • 项目/项目经理
  • 外部培训师/咨询师
  • 敏捷教练
  • 产品经理/产品负责人
  • Scrum Master
  • 敏捷团队(业务分析师、开发人员、测试人员、架构师、QA、UI/UX设计师等.)

这一步的结果

  • 完成试点项目和团队的业务目标和指导原则.
  • 飞行员候选人的短名单.

理解结构化评估的范围

蓝图的范围:与一到三个应用程序交付团队一起计划并执行对敏捷实践的结构化评估.

这三个应用程序交付团队蓝图范围的模型.

的范围. 指 通过扩展敏捷实现组织范围内的协作 此内容的蓝图.

选择一个试点项目,以获得可见性并为将来的实现买进

采用一组正确的实践和工具需要很大程度的改变,这需要从业务的所有级别买入. 利用一个试点项目:

  • 解决沟通、治理和技术问题 以前不重要或不被认为重要的.
  • 生成必要的指标 以说服管理层和涉众进一步采用敏捷.
  • 建立一群传道者和拥护者.

选择成功的敏捷飞行员的步骤

1. 定义业务目标

试点项目必须提供足够的业务价值,以使其获得批准,并不断获得资助和支持.

试点项目的所有计划都必须与业务目标保持一致, 不管这是不是一个新特性, 流程调整, 工具配置, 或资源.

2. 确立发展指导原则

团队具有适当的敏捷思维和行为,这对试点项目的成功至关重要.

每个原则至少与一个业务目标保持一致. 如果试点项目成功,这些原则就能得到更广泛的采纳.

3. 用正确的标准选择飞行员

理想的试点项目将收集关键的经验教训和度量标准,以评估其适用性,并且不会引入不必要的业务风险.

这个试点将根据四个标准进行选择:复杂性、持续时间、所有权和相关性.

使用CLAIM模型评估业务驱动因素

定义您采用敏捷的业务目标有助于将所有涉众置于正确的页面上. 定义“对我有什么好处”?在组织的每一层确保所有涉众都投入并承诺采用敏捷. 确定团队和组织中鼓励您开始敏捷之旅的一些差距.

文化
  • 敏捷将改变角色和职责的定义方式. 从传统思维到敏捷思维的文化转变将是敏捷推广的一部分.
  • 增加紧密相联的产品.
  • 跳槽到一家技术支持型公司.
  • 改变指挥和控制结构.
  • M&A.
学习
  • 克服传统瀑布方法的局限性.
  • 接受业务中不断变化的优先级.
自动化
  • 改进可追溯性可能需要技术投资, 协作, 以及自动化,以支持和跟踪持续变化的业务需求.
整合团队
  • 团队必须有足够的能力接受敏捷的方法和哲学,而不引入不必要的业务风险或违反法规.
指标 & 治理
  • 管理层必须愿意在他们的团队中灌输更高水平的信任和责任, 强调合作, 并促进持续的反馈,以帮助他们的团队顺利过渡到敏捷.
  • 模型对不断变化的市场需求反应缓慢.

练习:记录与敏捷开发相关的关键业务目标

3.3.1

预计时间:30分钟

  1. 在白板上,写下当前与敏捷开发相关的业务目标. 一些示例目标包括:
    • 提高客户满意度和参与度.
    • 降低企业运营成本.
    • 创造创新产品以保持市场竞争力.
  2. 定义每个目标要交付的业务价值.
  3. 确定每个目标的业务优先级.

例子:

属性 描述
客观的 提高网站产品投放市场的速度
价值 提高品牌认知度, 将组织作为潮流的引领者, 增加创收机会
优先级

Input

  • 理解当前的业务目标

Output

  • 与敏捷相关的业务目标的优先级列表

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

使用“敏捷宣言”为您的开发指导原则建立一个基础

开发指导原则(类似于宪章)有助于确保您的团队具有适当的心态, 动机, 和行为,以实现一个成功的敏捷试点. 从“敏捷宣言”开始,根据您认为合适的情况添加、删除或修改原则.

敏捷宣言的原则

  1. 我们的最高优先级是通过早期和持续的交付有价值的软件来满足客户.
  2. 欢迎变更需求,即使是在开发后期. 敏捷过程利用变更为客户提供竞争优势.
  3. 经常交付工作软件, 从几周到几个月, 优先选择较短的时间尺度.
  4. 业务人员和开发人员必须在整个项目中每天一起工作.
  5. 围绕有动力的个人构建项目. 给他们所需的环境和支持,相信他们能完成工作.
  6. 向开发团队传递信息的最有效的方法是面对面的交谈.
  7. 可工作的软件是进度的主要度量.
  8. 敏捷过程促进可持续开发. 发起人、开发人员和用户应该能够无限期地保持一个恒定的速度.
  9. 对技术卓越和良好设计的持续关注可以增强敏捷性.
  10. 简单——将未完成的工作量最大化的艺术——是至关重要的.
  11. 最好的架构、需求和设计来自自组织的团队.
  12. 定期, 团队思考如何变得更有效率, 然后相应地调整它的行为.
来源:《澳博体育app下载》

练习:建立您的敏捷试点的指导原则

3.3.2

预计时间:45分钟

  1. 讨论敏捷试点项目的开发指导原则. 你的指导原则应该包括“敏捷宣言”,并可以考虑以下几点:
    • 改进业务和开发团队之间的协作.
    • 提高资源利用率和生产力.
    • 使用敏捷提高产品的质量和接受度.
  2. 讨论您的敏捷试点如何实现和优化您的业务目标和开发指导原则之间的一致性. 使用下面的矩阵来记录你的讨论.

练习3的例子.3.2

Input

  • 涉众对敏捷实现的期望

Output

  • 开发指导原则和业务目标之间的一致性

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

选择您的敏捷试点项目

您的试点项目选择应该基于四个核心标准:

复杂性

项目应该有足够的复杂性,用相关的度量来证明敏捷的有效性, 但也不要太复杂,让团队无法专注于学习敏捷.

持续时间

可以是整个项目,也可以是几个可以在几个月内完成的项目里程碑, 以便收集足够的数据来衡量敏捷的适合度.

相关性

该项目将持续且频繁地向涉众交付业务价值,涉众将为改进提供建设性的反馈.

所有权

围绕业务需求的决策权力, 任务优先级, 流程优化是清晰和明确的.

选择一个低到中等复杂度的试点,这样就可以集中精力学习敏捷过程

将您的试点限制在软件开发领域. 如果一个项目合并了其他规程,它会稀释结果的真实性.

降低项目复杂性的技巧:

搭配的团队: 当团队在地理上分散时,就会增加沟通问题.

保持团队规模小: 大型试点团队将减少个人学习.

选择合适的团队: 选择有深度经验的领域专家,并能在试点完成后作为领军人物.

管理风险: 在试验期间不要与高风险的项目集成. 否则,这两个项目的失败都要归咎于敏捷.

了解底层技术: 复杂的技术可能会分散团队学习敏捷的注意力.

分解要求: 小而简洁的需求有助于消除大的模糊性, 高层次的需求通常会带来.

信息技术的见解

复杂性管理不是一次性的工作. 随着时间的推移,项目的复杂性自然会增加. 你需要与这种自然的势头作斗争. 随着试点的展开,不断努力降低复杂性,以提高成功的机会.

使用CLAIM模型定义您的IT试点计划

文化
  • 找到专门的团队或包含的项目人员.
  • 有正确态度的团队.
  • 与商业伙伴保持良好的关系.
  • 产品集中.
  • 产品的所有权.
  • 增量改进的机会.
学习
  • 敏捷飞行员信息技术研讨会.
  • 敏捷信息技术教练.
  • 敏捷的业务介绍.
自动化
  • 探索当前SDLC中可以从引入自动化工具中受益的领域.
整合团队
  • 专注于构建跨职能团队成员.
  • 一般化专家对于团队成员来说是一个需要理解的新概念,因为当团队成员学习新技能时,他们常常会被误解为在敏捷中做了“更多”的事情. 通过在团队成员中分解功能性和竖井式的工作方式,逐步培养泛化专家的思维方式.
指标 & 治理
  • 灵活资金或专用资金.
  • 是否与企业阶段闸相冲突.
  • 有限的企业发布周期.

练习:评估飞行员的复杂性

3.3.3

预计时间:30分钟

  1. 在下表的最上面一行列出试验项目候选项.
  2. 对于每个项目,回答以下关于其复杂性的问题(不同意,中立,同意).
问题 试点项目1 试点项目2 试点项目3
需求是不断变化的吗?
替代的大爆炸部署是否代表着一种商业风险?
团队成员已经配置好了吗?

Input

  • 了解试点项目候选人的范围

Output

  • 试验复杂性适合度评估

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

选择一个具有适当持续时间属性的试点项目,以获得敏捷适合性的真正评估

利益相关者和管理者应该寻找结果. 为几个迭代提供有形的度量.

确保足够时间的小贴士:

选择一个允许三到五次迭代的项目. 如果项目太短, 这会引起怀疑,因为人们会认为敏捷只能在短时间内成功, 简单的项目.

在整个试验过程中保持相同的开发团队,并首先关注如何使过程正确.

敏捷的好处在具备这些持续时间属性的飞行员身上表现得最好:

  • 将最后期限
  • 简单的决定花费的时间太长

信息技术的见解

在设置和审查试点项目的持续时间时,不要只关注试点项目的交付. 您还需要考虑向上和向下的活动,如计划和回顾. 注意任何挑战,并在管理支持下对其进行改进.

练习:评估你的飞行员的持续时间

3.3.4

预计时间:15分钟

  1. 在下表的最上面一行列出试验项目候选项.
  2. 对于每个项目,回答以下关于其持续时间的问题(不同意,中立,同意).
问题 试点项目1 试点项目2 试点项目3
最后期限不断变化吗??
简单的决定是否要花很长时间才能做出?

Input

  • 了解试点项目候选人的范围

Output

  • 试验持续时间适合度评估

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

选择一个与利益相关者相关的试点来培养支持

将敏捷的目标与涉众的关注点结合起来.

吸引利益相关者参与的建议:
看看有机会获得高商业回报的项目. 这些项目将对涉众有更高的可见性,并且如果它们具有高于或低于红线的可衡量的影响,将被认为是重要的.
选择一个试点项目,这个项目对商业决策制定既重要,又有一定的紧迫性.
一个相关的项目不需要是绿地. 遗留开发通常会消耗大量的时间和金钱,而敏捷可以帮助减少这些时间和金钱, 对业务运作有重大影响.

利用以下策略来处理棘手的涉众:

  • 让他们参与关键的讨论
  • 倾听,把关心的事情按优先顺序排好
  • 建立治理规则
  • 关注最终客户

信息技术的见解

有时候,选择一个失败但独立且高度相关的项目是合适的. 由于项目已经具有紧迫性和管理支持,这些都是加速敏捷试点的理想人选.

练习:评估项目的相关性

3.3.5

预计时间:15分钟

  1. 在下表的最上面一行列出试验项目候选项.
  2. 对于每个项目,回答以下有关其相关性的问题(不同意,中立,同意).
问题 飞行员1 试验2 飞行员3
试点对业务流程和操作重要吗?
是否会有适度数量的业务用户受到积极影响?
试点项目是否提供了一个构建敏捷能力的机会?

Input

  • 了解试点项目候选人的范围

Output

  • 试点相关度评估

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

选择一个具有适当所有权结构的试点项目,以确保持续的反馈

所有权建立了指导开发工作的责任

产品负责人应该与团队分享他们的愿景, 确保他们能够解决问题并提供指导. 这个角色可以防止团队猜测错误的方向.

  • 所有者必须为每个迭代设置优先级.
  • 作为透明沟通的一部分,开发人员应该能够访问最终用户(或代表).
  • 与产品负责人的回顾应该导致持续的改进.
  • 需求冲突的解决应该由所有者来完成,而不是诉诸于团队的政治.
  • 应该为每个优先级迭代传递清晰的接受标准.
  • 在某些情况下, 所有者需要接受新的需求将会出现,并且在下一次迭代之前不会被承诺.

信息技术的见解

转向敏捷并不意味着移除现有的所有权结构,并允许团队设定他们自己的优先级. 如果没有人能够对真正的业务优先级做出决定,缺乏问责将会破坏你的试点工作.

练习:评估你的飞行员的所有权结构

3.3.6

预计时间:15分钟

  1. 在下表的最上面一行列出试验项目候选项.
  2. 为每个项目, 请回答以下有关其所有权结构的问题(不同意, 中性, 同意).
问题 试点项目1 试点项目2 试点项目3
是否清楚地识别涉众?
所有者对项目的成功负责吗?
业主是否有权力作出决定和排除障碍?

根据你在前面练习中的回答, 选择您认为将从敏捷中获益最多的项目,并为将来在整个组织范围内的推广提供一个很好的概念证明.

Input

  • 了解试点项目候选人的范围

Output

  • 试点拥有权适合度评估
  • 试点项目选择

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

步骤3.4:模拟Scrum

这一步将引导你完成以下活动:

  • 确定关键的scrum角色.
  • 建立用户故事.
  • 细化积压.
  • 为用户情景构建开发任务.
  • 估计用户描述的点.
  • 确定团队速度并模拟冲刺计划.
  • 模拟日常.
  • 模拟冲刺评审和演示.
  • 确定团队的敏捷度量.
  • 模拟一次冲刺回顾.

这一步骤涉及以下参与者:

  • 开发经理/副总/总监
  • 项目/项目经理
  • 外部培训师/咨询师
  • 敏捷教练
  • 产品经理/产品负责人
  • Scrum Master
  • 敏捷团队(业务分析师、开发人员、测试人员、架构师、QA、UI/UX设计师等.)

这一步的结果

  • 理解和了解所有scrum实践和仪式.
  • 敏捷指标列表.

开始scrum模拟

这个模拟的目的是在您的试点项目的环境中按常规展示scrum,并衡量团队在采用敏捷实践方面的成功.

  1. 识别 scrum角色 自组织团队
  2. 用以下方法构建产品待办事项列表 用户故事 并介绍产品 积压细化
  3. 列出你的 开发任务 对于每个用户场景
  4. 估计 基于任务的用户描述的点
  5. 模拟 sprint计划 (为sprint提交用户故事)
  6. 进行一次 日常/ scrum
  7. 进行一次 冲刺评审 (演示sprint交付)
  8. 识别和跟踪 敏捷度量 评估你的成功
  9. 进行一次 回顾 并改进你的scrum和SDLC流程

活动:确定关键的scrum角色

3.4.1

30分钟

  1. 确定试点项目中应该涉及的关键scrum角色.
  2. 将现有SDLC角色映射到scrum角色,并确定所需的更改或培训.
  3. 根据技能和职责自组织团队成员并分配角色.
角色 的名字 责任
产品负责人 安娜贝尔
  • 负责任的 在最终项目中识别产品特性及其重要性.
  • 负责任的 为了根据重要性来确定哪些特性将在下一个sprint中交付,对待办事项列表进行细化和重新排序.
团队
  • 贾斯汀小
  • 孟Lao-shih
  • 负责任的 创建可交付的和有价值的特性.
  • 负责任的 的自我管理. 没有项目经理给每个团队成员分配任务.
Scrum Master 代表科菲Jalloh
  • 负责任的 为了增加阻滞剂和风险.
  • 负责任的 用于领导scrum、回顾、sprint回顾和演示.
  • 负责任的 用于团队建设和解决团队冲突.

Input

  • SDLC角色和职责
  • 敏捷团队成员列表

Output

  • scrum角色和职责列表

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 Scrum文档模板.

理解用户描述、需求和设计之间的关系

建立模型以显示用户描述、需求和设计之间的关系

创建产品待办事项列表,以便与开发团队沟通业务需求

使用待办事项列表来捕获预期的工作.

产品待办事项列表通过向您展示需要交付的需求来帮助创建项目的路线图.

产品负责人是如何参与进来的?

  • 产品负责人负责与最终客户保持密切联系,并将产品待办事项列表作为新想法进行适当的更改, 的见解, 和障碍产生.
  • 产品负责人应该与团队进行良好的沟通,根据技术困难和澄清需求对产品待办事项做出准确的更改.

如何创建产品待办事项列表?

  • 在用户描述中编写需求. 使用这种格式:“作为(用户角色),我希望(函数)以便(受益)”。.“确定最终用户并了解他们的需求.
  • 为每个需求分配优先级. 决定哪些需求是最需要交付的. 问问你自己哪个用户故事将创造最大的价值.

有哪些方法可以生成我的待办事项列表?

  • 团队头脑风暴-产品负责人, 团队, scrum管理员在一个或一系列的会议上共同编写用户描述,并对用户描述进行优先级排序.
  • 业务用例——产品所有者根据开发准备的定义将业务用例转换为用户用例.

史诗和主题

当你开始承担更大的项目时, 将你的用户故事按照以下顺序组织和分组可能是有益的:

  • 史诗是类似用户故事的集合,用于描述重要的和大型的开发计划.
  • 主题是类似史诗的集合,通常用于定义高级业务目标.

为了避免混淆,试点产品待办事项列表将只由用户故事组成.

例子:

经典史诗和主题的例子

了解待办事项列表细化在sprint计划中是如何发挥作用的

建模以理解待办事项细化 建立更好的Backlog

区分细化产品待办事项列表和. 计划冲刺本身

通常,待办事项的细化可以互换使用,或者被认为是sprint计划的一部分. 事实是它们非常相似, as the required participants 和 objectives are the same; 然而, 有一些关键的区别.

Backlog细化和冲刺计划的维恩图

更好的方法是“预先计划”和“计划”.”

在这个阶段,您的pbi应该是用户故事——使用INVEST模型

我们的目标是优化您的PBIs,使其为:

独立: 理想情况下,你的用户故事可以按照任何顺序构建(i.e. 彼此独立). 这允许您根据价值进行优先级排序,而不会被打乱顺序和先决条件.

可转让: 正如纯粹的敏捷主义者会告诉您的那样,关注协作而不是合同. 您的用户情景旨在促进开发人员和业务人员之间的协作. 因此,它们的建立应使各方能够进行谈判.

有价值的: 这里没有最新进展. 用户描述需要声明该值,以便有效地对其进行优先级划分, 但也让开发人员知道他们正在构建什么.

可尊敬的: 而不是给予史诗更高级的近似, 用户故事的估计需要更准确,才能有效地划分优先级, 同时,团队也可以知道什么是适合sprint或发布计划的.

小: 用户故事应该足够小,以适应一个sprint. 然而,团队规模和速度将会影响到能够完成多少任务.

可测试的 您的故事需要是可测试的,这意味着您需要满足您的质量保证标准.

来源:“敏捷新手? 投资好用户故事"

根据需要从史诗中创建、拆分和捆绑用户故事

下面的问题可以帮助我们从用户故事层面分析史诗. 同样的思路对于将多个小PBIs捆绑在一起也很有用.

从您的史诗中建模创建、拆分和捆绑用户故事

来源:“敏捷新手? 投资好用户故事"

理解用于构建用户故事的通用语言

文档(或缺少文档)有意地减少了用户故事的文档.

对如何构建用户描述进行建模

这并不是说用户故事不需要文档或更全面的信息. 与用户描述相关的信息存储在相应的描述中. 因此, 用户故事和史诗之间的可追溯性是真正的目标, 产品待办事项列表的核心职责.

在用户故事和史诗之间建立可追溯性模型

活动:构建用户描述

3.4.2

预计时间:1小时

  1. 您的产品负责人是否描述了试点项目的业务目标.
  2. 将关键业务需求写成用户情景.
  3. 如果特性或业务目标不明确或太大,分解用户故事.

场景:构建一个管理员工缺勤请求的人力资源系统.

为活动3构建用户描述的示例场景.4.2

Input

  • 选定试点项目的范围

Output

  • 用户故事

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队
  • 产品负责人
  • Scrum master

中记录这些用户描述 Scrum文档模板.

练习:细化待办事项

3.4.3

预计时间:30分钟

  1. 基于创建的用户描述, 产品所有者为每个用户描述分配一个优先级排名,以确定它们将以什么顺序完成.
  2. 您的团队是否回顾了用户描述并质疑其价值, 优先级, 目标, 这意味着更好地理解需求的需求.
  3. 通过为每个用户描述定义单独的接受标准来定义“完成”.

细化活动积压的示例场景3.4.3

Input

  • 用户故事

Output

  • 优先级评级

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队
  • 产品负责人
  • Scrum master

中记录这些用户描述 Scrum文档模板.

在sprint计划中,将用户故事分解为开发任务

你的冲刺计划必须已经包含了许多小的、功能性的工作. 当将用户场景分解为开发任务时, 考虑跨功能而不是技术边界进行分解.

对这两种分解用户故事的方法进行建模. 这两种方法是:水平分解和垂直分解.

information - tech建议采用垂直分解的方法!

单个任务本身并不能交付可工作的软件,并且在按技术需求分解任务时,您经常会遇到瓶颈. 这种方法也使得产品所有者很难对应该以线性方式完成的技术任务进行优先级排序.

来源:《澳博体育app下载》

理解垂直分解方法的常见策略

如何确定一个开发任务应该有多小?

短跑项目的大小并没有硬性规定. 这将取决于:

  • 冲刺的长度.
  • 应用程序或项目的大小.
  • 团队的经验和舒适程度.

团队的经验和舒适程度.

1. 工作流步骤?

用户执行哪些步骤?

所有的步骤现在都是必要的吗?

现在可以简化步骤吗?

订单流程中的步骤,如选择支付选项、送货方式).

2. 业务规则?

这个故事有什么规矩啊?

现在需要所有的业务规则吗?

更简单的规则就足够了吗?

订单流程规则(10美元以下无订单,美国以外无发货).

3. 快乐或不快乐流?

快乐/不快乐流是什么样子的?

所有不愉快的流程都是必要的吗(现在)?

不愉快的流程能被简化吗(现在)?

在网上商店订单过程中的失败和可能的恢复选项.

4. 输入选项?

支持哪些平台?

是否需要所有的平台(现在)?

是否有些平台比其他平台更难执行?

平板电脑、i电话、台式机、触摸屏.

5. 数据类型和参数?

支持哪些数据类型和相关的数据类型?

有哪些参数化的视图?

现在所有的参数都是相关的吗?

不同的搜索选项/策略或报告类型(例如.g. 表、图).

6. 操作?

这个故事需要什么操作?

所有的手术现在都需要吗?

分解CRUD(创建、读取、更新、删除).

7. 测试用例?

使用了哪些测试场景来验证这个故事?

此时所有的测试场景都是相关的吗?

一些测试场景可能非常复杂,但此时并不是高度相关的

8. 角色?

这个故事中涉及到哪些角色?

角色可以做什么? 现在所有的角色都是必要的吗?

客户可以创建订单,管理员可以管理订单等.

9. 浏览器兼容性?

需要支持哪些浏览器?

在这一点上,所有的浏览器都重要吗?

忽略对ie9的支持,因为只有一小部分用户使用.

10. 现在优化vs以后优化?

我们可以考虑哪些优化(UX/UI)?

现在所有的优化都是必要的吗?

实现地址自动补全,使用gps定位.

来源:《澳博体育app下载》

活动:在sprint计划待办事项中为用户描述构建开发任务(sprint计划活动)

3.4.4

预计时间:30分钟

  1. 请回顾从上一个活动构建的用户故事.
  2. 选择团队喜欢的垂直分解策略.
  3. 在sprint待办事项列表中,列出与每个用户描述相关的所有可能的开发任务.

为活动的sprint 待办事项列表中的用户故事构建开发任务的例子3.4.4

Input

  • 用户故事
  • 垂直分解策略

Output

  • 开发任务

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队
  • 产品负责人
  • Scrum master

中记录这些用户描述 Scrum文档模板.

用户故事估计

规划扑克: 这种方法使用德尔菲法(Delphi),由一组人共同估计PBI的大小, 或用户故事, 用按故事点数编号的卡片.

材料: 每个参与者都有一副牌,里面包含了斐波那契数列的数字.

典型的参与者: 产品负责人、scrum管理员(通常是推动者)、开发团队.

步骤:

  1. 主持人将选择一个用户描述.
  2. 产品负责人回答团队中关于用户描述的任何问题.
  3. 该小组进行了第一轮估算, 每个参与者分别选择一张牌, 同时显示所有的选择.
  4. 如果有共识, 协调人记录下这个估计,然后转到步骤1中去寻找另一个用户故事.
  5. 如果有差异, 参加者应说明其选择的理由, 特别是高或低离群值, 并引发一场建设性的辩论.
  6. 该小组还进行了一轮额外的评估, 步骤3-6在哪里完成,直到有一个合理的共识.
  7. 如果共识是用户故事太大(不适合sprint)或太不明确, 然后应该重写用户故事.
斐波那契数列的模型

百万美元问题 什么构成了一个故事点?

故事点是指一个相对体积的单位, 复杂性, 风险, 和不确定性, 因为这与开发PBI所需的累积时间有关.

如何为用户描述分配一个点值? 除了利用团队的经验,没有简单的答案. 大小是基于与其他PBIs或以前开发的项目的相对比较. 例子: 这个用户描述是3个点,因为它比1个点的用户描述多花了3倍的精力. 因此, 描述点的度量只能通过团队的经验来定义, 随着团队的成熟.

如何将一个点等同于一个时间单位? 首先,也是最重要的, 为了确定待办事项的优先级, 你不需要知道时间, 只是它相对于其他PBIs的大小. 但对于sprint计划来说, 发布计划, 或者任何时机是因素的情况, 故事点需要某种形式的基于时间的等效性, 团队之间会有哪些不同. 再一次,这归结为经验.

信息技术在用户故事层面衡量价值的方法

价值是一件棘手的事情. 决定应该花费多少时间和精力来衡量未来组件的价值也是如此, 特别是在不同粒度级别上多次评估PBI时.

信息技术的建议如下:

  • 初始摄入价值评估 应该是直观的,因此需要更少的时间和精力.
  • 史诗级别的价值评估 应该详细, 让各种涉众参与进来, 与产品愿景和组织价值驱动因素密切相关, 必须通过度量标准和一致的评分方法进行测量(这里最适合使用价值计算工具).
  • 用户描述级别的价值评估 在每个用户故事都应该被分配一个单独的值的意义上是详细的吗, 但每个PBI的估值应该不那么植根于彻底的测量和度量, 更重要的是与史诗的结盟, 哪一个是最好由产品所有者的直觉知识决定的.
建立每个PBI评估工作的严格性模型

活动:基于任务(sprint计划活动)估计用户描述的点

3.4.5

预计时间:30分钟

  1. 查看所有故事以确定它们的复杂程度(高、中、低).
  2. 把复杂的故事放在一起.
  3. 建立将使用的最小和最大斐波那契值.
  4. 选择复杂度最低的故事,并给它分配最小的斐波那契值.
  5. 选择复杂度最高的故事,并给它分配最大的斐波那契值.
  6. 将所有其他故事与值最低和最高的故事进行比较,以确定所有其他故事的值.

为任务3建模.4.5用于基于任务估计用户故事的点

Input

  • 用户故事
  • 开发任务
  • 评估技术

Output

  • 复杂性水平
  • 斐波那契的价值观

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队
  • 产品负责人
  • Scrum Master

中记录这些用户描述 Scrum文档模板.

有一个sprint计划会议来确定你即将到来的sprint的范围和评估

计划需要时间——不要匆忙.

  1. 产品所有者和团队审查产品待办事项列表和发布计划,并讨论为即将到来的里程碑必须完成的高优先级项目.
  2. 将用户描述分解为更小的独立任务. 使用右边的方案估计每个任务的点数. 分数应该被视为复杂性的指标,并随着时间的推移呈指数增长. 累积所有任务的点数,以计算用户故事大小.
    • 一些工具(e.g. 团队 Foundation Server)根据小时而不是分数来估计任务. 在这种情况下, 考虑以小时为单位估计任务,然后在用户故事级别将它们合并成点.
  3. 根据已确定的问题、风险和任务调整您的发布计划. 记住在你的计划中留下一点缓冲,以适应意想不到的障碍.
  4. 将你的里程碑分解成一到四周的冲刺阶段. 在给定的项目中,Sprint的长度应该是一致的. 确定可以在给定的sprint中完成的用户描述,并在必要时改变您的里程碑和发布计划. 这是你的冲刺计划.
    • 理想情况下,产品应该在sprint结束时交付. 如果这是不可行的,考虑使用您的开发工件(例如.g. UI设计、业务需求)在每个sprint结束时进行审查.
  5. 团队在每个冲刺阶段都有新的任务出现,这是很常见的. 一旦团队做出承诺, 除非产品负责人批准,否则添加和更改必须等到下一个sprint.

点估计方案

考虑以下方案对于新团队的点范式:1点~ 1小时,3点~ 0.5天,7分~ 1-2天,13分~ 3-4天. 必要时修改这个方案.

随着团队越来越习惯这种方法, 开始从天到点的转换到任务到点的转换.g. 在web UI上编写一个按钮代码= 3分).

使用燃尽图跟踪团队的表现,以实现项目进展的透明度

什么是燃尽图?

  • 它们显示了 工作 is 剩下的 在接下来的冲刺中.
  • 它们显示出你是否在 现实的 关于在给定的sprint中你能交付多少,并揭示你估算的准确性.

如何创建燃尽图?

  1. 计算当前冲刺的总得分.
  2. 画出你的“计划”燃尽线, 哪一个将被用作你的生产力基准,如右边的例子所示.
  3. 当用户描述完成时, 更新您的“实际”燃尽线,方法是从剩余未完成的总点数中减去已完成的用户故事点数.

显示了一个sprint燃尽图的图形.

信息技术的见解

对按时完成任务的团队给予奖励,并通过创造性的方式惩罚那些未能按期完成任务的团队. 例如,给表现最好的团队奖励,给表现不好的团队锻炼.

衡量和沟通成功,学习和建立动力

演示通过试点取得的持续的生产力增长.

  • 度量试点项目的性能指标是很重要的,因为涉众想知道他们是否更适合使用敏捷. 瀑布.
  • 高绩效团队是那些致力于提升自己的团队. 他们想要一种方法来衡量自己当前的表现,并在此基础上加以改进.
  • 传达成功还包括向涉众提供所面临挑战的回顾,以及敏捷过程和工件如何帮助团队解决这些挑战.

了解如何在试点期间管理积压. 它会影响你测量的准确性.

1. 计划 2. DO 3. 学习
团队应该在每个sprint中拿出5-10%的时间来细化他们的待办事项列表,以便能够准确地表示当前sprint中所承诺的任务. 在待办事项列表细化过程中, 团队应该评估每个需求的优先级,并重新评估每个需求完成所需的时间. 在scrum中,人们常常低估了应该花多少时间来细化产品待办事项列表. 与不准确的估计相比,付出的努力是值得的.

信息技术的见解

硬性指标可以帮助解释敏捷试点项目的成功. 来自团队成员的轶事证据也应该用于提供团队级别的证据.

为最初的项目速度设定现实的期望,以允许机构学习

慢慢开始,设定合理的期望.

  • 对于您的敏捷试点的第一次迭代,一般的共识是 利用三分之一的项目执行时间 作为评估团队速度的基线值. 这个数字允许会议、研究、假期、个人时间和行政职责.
  • 如果您正在估算理想的程序员时间,那么 考虑非项目时间 比如会议、邮件、设计、文档、返工、协作和研究.
  • 监控速度 在第一次迭代(sprint)中. 如果低估了,第一次迭代中的速度将随着新功能的加入而上升. 如果过高估计,速度将随着特征被删除而下降. 对于第二次迭代,scrum团队应该将第一次迭代作为指导方针.*

你必须知道以下几点才能做出初步估计:

  • 参与项目和下一次迭代的人数.
  • 在迭代的一段典型的时间内,任何一个人能够完成的最大工作量.
  • 迭代中的总工作日数.
*来源:“有效速度跟踪的最佳实践”

计算燃烧速度

燃尽速度计算步骤:

  1. 计算每一次冲刺的每日消耗速度,如下图所示. 取你的实际和计划燃尽速度的平均值.
  2. 确定你的燃尽速度与计划燃尽速度不同的区域. 确定这些差异发生的原因.
  3. 如果可行,调查为什么你的一些点没有完全烧毁.
如何计算燃尽速度的例子图表

测量冲刺消耗方差来帮助团队实现假设

评估您的burndown方差的根本原因,以消除未来的假设.

  • Burndown方差不应该被认为是一件坏事,因为它们为更好地理解实际事件(与预期事件相比)提供了基础.
  • 当处理减少的差异时,问“为什么”?,来找出方差的根本原因. 这将有助于加速流程的未来改进,并让涉众了解瓶颈.
  • 方差可以揭示团队对当前sprint的用户描述的承诺是否过高或过低. 如果一个团队已经超额承诺,那么发布计划可能会被修改(i.e. 将故事推到下一个sprint中),以更好地反映团队当前的能力. 如果一个团队承诺不足, 来自未来sprint的用户故事可以被引入到当前的sprint中,以保持团队的生产力.

差异的常见原因

  • 开发团队对任务的估计不佳.
  • 宽泛的项目范围定义,产生不准确的估计.
  • 不明确和不明确的需求,导致功能总是被涉众拒绝.
  • 参加没有什么价值的会议和其他仪式.
  • 冲刺中期注射没有在燃尽图中记录.

信息技术的见解

跟踪每一次冲刺的差异. 如果您使用传统的瀑布方法,那么任何增量都表示敏捷已经帮助您避免了潜在的风险. 跟踪任何团队和涉众的讨论,以改进任务评估. 这可能会对改进现有的非敏捷项目评估产生影响.

练习:确定团队的速度(冲刺计划活动)

3.4.6

预计时间:30分钟

1. 通过首先确定历史sprint中所承诺的总点数来确定团队的速度.

例如:

Sprint 1:承诺的总分数= 12

Sprint 2:提交的总分数= 9

Sprint 3:承诺的总得分= 9

平均承诺分数= 10(团队速度)

2. 回顾每个故事中的任务以及在之前的活动中分配给它们的点. 拉牌时累积的总值不能超过团队的总速度

Input

  • 用户故事
  • 团队速度

Output

  • 为sprint提交用户故事

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队
  • 产品负责人
  • Scrum master

中记录这些用户描述 Scrum文档模板.

在开发期间进行每日的scrum会议,以衡量进度

利用每日的scrum会议来解决任何阻碍完成承诺任务的障碍或风险.

Scrum规则

  • 一旦sprint开始,每天的scrum会议就开始了.
  • scrum应该大致是一个 15分钟的会议 每天在同一时间同一地点.
  • 会议 由scrum master领导 团队里的每个人都应该到场.
  • scrum管理员应该控制scrum的节奏,以确保每个人的时间都得到尊重,并将重点放在风险和阻碍因素上.
  • 应该保留讨论问题的日志,作为第二天继续讨论的要点.

Scrum主题

应该报告三件事 每个团队成员在scrum会议上:

  • 他们完成了什么 从上次scrum会议开始.
  • 他们目前正在做什么 以及他们将在下次会议前完成的工作.
  • 任何 阻滞剂、风险 or 障碍.

Scrum的目标

  • 透明度 在团队成员之间,这样就能迅速提出并解决阻碍团队完成用户描述的根本问题.
  • 更新 从scrum master那里了解阻碍和风险的解决方法. 这有助于在团队中建立诚信.
  • 没有产品所有者的干预. 有可能让产品负责人参加需求澄清的scrum会议,但他们不应该注入新的需求.

使用scrum板直观地显示项目进度

scrum board显示项目在给定的sprint期间的健康状况和进展情况. 用户故事在scrum板上从左(待办事项列表)移动到右(已完成).

  • 待办事项列表 包含可用于开发的用户描述.
  • 这个团队 提交 到下一个sprint的一组用户故事.
  • 当团队准备接受用户描述时,它被转移到 在进行中. 被阻塞的用户故事被清楚地标记出来.
  • 一旦用户场景完成,按照您对done的定义,它就会移动到 完成.
展示项目进度的scrum板模型

利用 Scrum文档模板 在sprint的每一天之后,跟踪任务和用户故事的完成情况.

活动:建立你的任务板,模拟日常站立

3.4.7

预计时间:30分钟

  1. 确定并选择团队scrum board的位置.
  2. 按垂直列设置团队scrum董事会,以便进行、进行中、测试和完成.
  3. 将你提交的用户描述以及他们的相关任务添加到scrum board中.
  4. 模拟一场日常的站立表演,由scrum管理员通过回答以下三个问题来促进:
    1. 我昨天做了什么?
    2. 我今天要做什么?
    3. 有路障吗?

展示项目进度的scrum板模型

Input

  • sprint 待办事项列表中的用户故事

Output

  • Scrum董事会

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队
  • 产品负责人
  • Scrum master

利用 Scrum文档模板 在sprint的每一天之后,跟踪任务和用户故事的完成情况.

举办冲刺回顾会议来再次确认期望

根据需要协作、检查和调整项目方向.

Sprint评审的目标: 获得许可,向涉众演示已完成的特性.

  • 一旦sprint完成,产品负责人就会进行一次sprint评审. 产品所有者接受最新的工件(例如.g. 构建、设计),并从风险的角度理解项目的走向.
  • 这个会议的另一个输出是为团队提供建议和反馈,以便将其纳入下一个产品改进sprint中.
  • 审查的准备工作应该很简短,因为团队只展示已经完成的工作.

对你的sprint的输出要现实

在某些情况下,sprint可能没有足够的时间来完成一个经过测试和可部署的构建. 考虑使用您的sprint评审会议来评审开发工件(例如.g. UI设计、业务需求文档),这些都是项目进展的关键.

大多数团队低估了对他们时间的所有其他需求,在第一个sprint中完成的任务更少."

Mike Cohn, 敏捷的成功:使用Scrum进行软件开发

通过演示确保与涉众的期望保持一致

通过让项目涉众和管理层参与到示范中来,他们的建设性反馈将确保项目朝着正确的方向发展. 目标是为每个演示提供一个最有价值球员.

向利益相关者展示您的最有价值球员,以获得关于改进或修改的反馈, 添加, 或者删除一些特性以满足新的业务需求.

  • 在您的发布计划中确定关键点,以安排与涉众的演示. 这些点(理想情况下, 在您的项目里程碑时)应该在您的解决方案中展示一些业务价值. 在演示的频率和涉众的可用性之间找到一个平衡点.
    • 专注于演示已经完成的功能. 如果你打算展示正在进行的工作, 确保您的涉众理解他们所看到的可能发生的变化.
  • 如果涉众或产品所有者不可用,可以利用代理. 确保代理与利益相关者的最新需求保持一致,并与利益相关者进行定期沟通.
  • 在增强方面与涉众合作 因此,可以根据产品待办事项列表注入更改并对其进行优先级排序. 评估并处理这些变更对发布和冲刺计划的影响.

活动:模拟冲刺评审和演示

3.4.8

预计时间:1小时

  1. 回顾每个团队在sprint中承诺的用户描述, 为验收标准准备一个线框来证明你已经完成了.
  2. 在你的团队中练习展示线框图,并将你的故事围绕一个现实的用户解决问题展开. 请记住,演示不仅要证明软件是有效的,还要证明它是有价值的.
  3. 团队轮流向其他干系人展示他们的演示,干系人根据演示选择一个选项:
    • 批准
    • 拒绝
    • 请求改变(进入未来的冲刺阶段)

Input

  • sprint 待办事项列表中的用户故事
  • 验收标准

Output

  • 用户故事的线框图
  • 了解和理解演示

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队
  • 产品负责人
  • Scrum master
  • 其他利益相关者

确保涉众理解敏捷在他们所欣赏的度量中的价值

点数对利益相关者几乎没有价值. 传统指标, 相关预算, 最后期限, 和范围, 是否仍然需要收集这些信息,以便有效地、清晰地传达敏捷的成功之处,以供进一步的涉众接受.

  • 在发布级别传达度量标准. 发布计划包含时间限制的里程碑,通常定义和设置范围和预算, 哪些与传统的报告方法相一致.
  • 避免在涉众报告中提及要点. 点的定义因团队和项目而异. 不要将涉众与只与团队相关的指标混为一谈.
在评估敏捷的价值时要考虑的其他指标的模型

练习:列出在您的敏捷试验期间将收集的度量

3.4.9

预计时间:30分钟

  1. 列出您将在敏捷试验期间收集的度量标准. 考虑用于评估SDLC的指标.
  2. 定义度量标准,并将它们映射到前面确定的适当的试点目标和指导原则. 集思广益收集这些指标的方法.
  3. 问自己以下问题:
    • 您的涉众是否理解您的度量标准的含义和解释?
    • 您的指标是否易于收集,但能够显示出显著的价值?
    • 你的团队将如何使用你的度量标准来持续改进?
度规 定义 相关的试验目标 收集的方法
开发团队完成承诺的用户场景的能力. 在与利益相关者讨论时,必须将要点转化为生产. 提高资源利用率和生产力. 通过scrum板绘制燃尽图表.
最终用户对产品的满意度 对最终用户的解决方案质量的感知价值. 使用敏捷提高产品的质量和接受度. 用户满意度调查.

Input

  • SDLC指标列表
  • 试验指导原则
  • 用户故事

Output

  • 敏捷试点指标列表

材料

  • 白板
  • 标记

参与者

  • 开发团队

文档结果在信息技术 敏捷剧本模板.

利用工具来帮助您跟踪度量,以便您可以专注于实现而不是管理

电子工具可以帮助简化报告指标的收集.

  • 跟踪指标可能成为一项耗时的活动. 使用电子工具可以让涉众了解项目,并节省用于测量性能的时间.
  • 工具允许分布式团队为跨多个团队的工作负载后分析贡献他们各自的度量.
  • 有些工具允许您跟踪团队成员之间的交流, 哪些可以帮助跟踪特定问题的进展.
  • 来自自动化工具的度量可以与下游工具联系起来,以分析整个项目生命周期的瓶颈和效率.

关于敏捷软件供应商的列表,请参考Info-Tech的 评估应用程序生命周期管理环境.

“高速项目需要一个自动化工具来跟踪跨团队和地域的状态. 最好的工具支持bug跟踪和一个系统中开发任务的状态,以避免开发人员在数据输入方面的额外工作."

——杰夫•萨瑟兰 Scrum手册

敏捷软件什么时候最有用?

  1. 当地理距离使团队成员无法集体参加scrum会议时.
  2. 当手工收集度量的开销过高时.
  3. 当已经对支持敏捷开发的工具进行了投资时.

举办一个sprint回顾会议来确定并记录需要解决的问题

从过去的错误和痛点中吸取教训,并将其应用到未来的冲刺中.

  • sprint回顾与sprint回顾不同,因为它不是面向项目的,但是 面向流程的.
  • 这一步对于改进scrum流程非常重要,因为每个团队成员都有机会发表意见 是什么工作什么不是.
  • scrum管理员可以扮演一个 主持人 对于这些会议.

回顾会议期间要问的问题

  • 就像 的冲刺?
  • 什么是你 缺乏 在sprint中?
  • 学习?
  • 你怎么 欲望 帮助改进流程?

信息技术的见解

把第一次冲刺看作一次测试. 在第一次冲刺之后, 团队成员应该更好地了解自己的能力,以及他们在一个sprint中能实际实现什么.

利用 Scrum文档模板 在每一天和冲刺后评估你的团队的表现. 看看哪些地方可以改进,以提高团队的效率和效率. 请在项目回顾表中注意这些.

选择团队一致同意的回顾方法

疯了,伤心,高兴 在回顾中,鼓励团队成员讨论sprint的情感方面是一种流行的技术吗. 它关注的是团队的感受,而不是sprint中的事件.

疯狂、悲伤、高兴的例子

帆船 这是定义团队愿景并确定沿途问题的流行技术吗. 请参考 在这里 有关方法的说明.

海星 从团队中收集数据以鼓励团队成员思考实践和团队从中获得的价值是一种流行的技术吗. 请参考 在这里 有关方法的说明.

海星模型的例子

信息技术的最佳实践

无论你采用何种方式进行回顾,它都应该包含以下两个部分:

  1. 来自当前冲刺的反馈来决定是否成功.
  2. 团队建设的组成部分.g. 改善沟通,提高对敏捷框架的认识,改善人际关系

活动:模拟冲刺回顾

3.4.10

预计时间:30分钟

  1. 确定团队一致同意并希望将其作为敏捷实践的一部分的回顾方法.
  2. 设置任何材料(如.g. 便利贴,钢笔),团队将需要模拟回顾.
  3. 在scrum master的协助下, 回顾当天您参与的活动,以理解敏捷实践.
  4. 记录团队可以如何改进的任何行动项目.

Input

  • 回顾技术列表

Output

  • 对回顾的理解
  • 改善的行动项目

材料

  • 白板
  • 标记
  • 便签

参与者

  • 开发团队

利用 Scrum文档模板 在每一天和冲刺后评估你的团队的表现. 看看哪些地方可以改进,以提高团队的效率和效率. 请在项目回顾表中注意这些.

要意识到,远离纯粹的或墨守成规的敏捷实践是很常见的

  • 敏捷应该被塑造, 调整, 而且符合你现在团队的技能, 工作动态, 围绕法规遵循和项目里程碑的企业标准. 一个团队或项目的敏捷实现可能与其他实现不同.
  • 敏捷需要在您的环境中对敏捷的价值和实践有一个共同的理解. 这将确保您的敏捷计划是协调的,并且都朝着同一个目标前进.

要明白敏捷是一个学习框架.

  • 持续改进是敏捷方法的核心部分:从错误中学习, 路障, 以及在未来减轻这些问题的定制解决方案和流程的障碍.
  • 随着您的成长和成熟,您的敏捷实现应该不断地演进. 随着项目中出现的新问题, 鼓励您的项目团队进行调整,以提高沟通和生产力,并使已完成的产品更好地与业务优先级保持一致.

你的敏捷转换路线图将取决于你的目标是什么

图片是扩展敏捷的转变路线图

采取全面的方法来实现以产品为中心的敏捷转换

为IT内部的敏捷转换建模

采取全面的方法来实现您的企业范围的敏捷转换

敏捷转换/变更管理计划的模型

如果你需要额外的支持, 作为信息技术研讨会的一部分,我们的分析师是否指导您度过这一阶段

与我们的信息技术分析师预订一场研讨会:

  • 为了加速这个项目, 让你的IT团队与信息技术分析师团队一起参加信息技术研讨会.
  • 信息技术分析师将在您所在的地点现场加入您和您的团队,或欢迎您到信息技术的多伦多办事处参加创新现场研讨会.
  • 联系你的客户经理.信息技术.com/account),或电子邮件 研讨会@InfoTech.com 的更多信息.

以下是信息技术分析师将与您的团队进行的活动示例:

活动的截图3.4.7

建立团队任务板和模拟日常站立

这个活动让敏捷试点团队成员了解如何构建一个任务板,作为他们日常站立仪式的一部分. 这使得团队成员能够向团队的其他成员和其他涉众可视化地表示他们的工作进度.

活动的截图3.4.9

列出衡量成功的敏捷指标

这个活动涉及到敏捷试点团队来识别和列出相关的度量标准,他们将负责跟踪和衡量敏捷试点的成功. 这使得团队成员能够在所有涉众群体中增加敏捷成功的透明度.

相关信息技术研究

通过扩展敏捷实现组织范围内的协作

执行有纪律的方法在组织中推广敏捷方法.

用卓越的敏捷中心传播最佳实践

通过一组目标服务产品,促进敏捷团队和业务之间的持续一致.

参考书目

敏捷建模. 积极的涉众参与:敏捷的核心实践.” 敏捷建模. n.d. 网络.

Ambler, Scott W. “产品所有者来自哪里?” LinkedIn. 11月21日. 2016. 网络.

Ambysoft. “2018年IT项目成功率调查结果.” Ambysoft. 2018. 网络.

贝克,肯特等人. 《澳博体育app下载》.” 敏捷manifesto.org. 2001. 网络.

软件系统蓝图. “从一开始,10种需求就可能破坏你的项目.” 软件系统蓝图. 2012. 网络.

布洛克、乔恩等人. 《澳博体育app》.” 波士顿咨询公司. 2015年5月20. 网络.

科恩,迈克. 敏捷的成功:使用Scrum进行软件开发. 添加ison - wesley. 2010. 网络.

丹宁,史蒂夫. “让管理者焦虑的十大敏捷公理”.” 《澳博体育app》. 2018年6月17日. 网络.

丹宁,史蒂夫. 《澳博体育app下载》.” 《澳博体育app》 11月4日. 2018. 网络.

Dyba, Tore和Torgeir Dingsøyr. 敏捷软件开发的实证研究:系统回顾.” 爱思唯尔,ScienceDirect. 1月24日. 2008. 网络.

EDUCAUSE. “将IT资金模式与技术变革的步伐相结合.” EDUCAUSE. 12月14日. 2015. 网络.

Eick,斯蒂芬. “代码衰变? 评估来自变更管理数据的证据.” IEEE软件工程汇刊, 卷. 27, no. 1月1日. 2001, pp. 1-12. 网络.

汉森,杰弗里·J. 有效速度跟踪的最佳实践.” IBM. 2012. 网络.

Harrin,伊丽莎白. 在项目管理中使用里程碑.” 平衡的职业. 11月5. 2018. 网络.

哈特曼,鲍勃. “新的敏捷? 投资于优秀的用户故事.” 敏捷为所有. 2009年5月14日. 网络.

IAG咨询. 商业分析基准:完整报告.” IAG咨询. n.d. 网络.

汗,赛义德. “让我们结束困惑:产品负责人不是产品经理.” Onproduct管理.org. 2017年7月14日. 网络.

迈耶,伯特兰. 敏捷!:好的,炒作的和丑陋的. 施普林格2014. 网络.

莫迪,苏尼拉等等. “探讨分布式敏捷开发中的共同基础:案例研究视角.” ICGSE. 9月30日. 2013. 网络.

Pichler,罗马. 什么是产品管理?” Romanpichler. 11月26日. 2014. 网络.

波格里布诺伊,康斯坦丁和奥尔加·亚茨维奇. CodeTiburon的软件项目评估实践.” Codetiburon. 2月28日. 2017. 网络.

赖夫,唐纳德J. 《澳博体育app》(2017):12个主要发现.” InfoQ, 8月10日. 2017. 网络.

Rock, David和Jeffrey Schwartz. 《澳博体育app下载》.” SCRIBD. 2006. 网络.

罗伊斯,博士. 温斯顿·W. 管理大型软件系统的开发.” 自洽场.南加州大学.edu. 1970. 网络.

按比例缩小的敏捷. 《澳博体育app下载》.“按比例缩小的敏捷. 2017. 网络. Scrum.org. 什么是产品负责人?” Scrum.org. n.d. 网络.

萨瑟兰,杰夫. Scrum手册. Scrum培训学院出版社. 2010. 网络.

VersionOne公司. “第12届年度敏捷报告.” VerisonOne. 2018. 网络.

Verwijs,克里斯蒂安•. 在Scrum中分解产品待办事项项的10个强大策略(带有备忘单).” 媒介.com. 4月1日. 2017. 网络.

Wolpers,斯蒂芬. 组织中的敏捷失败模式2.0.” 启动. 3月21日. 2018. 网络.

ZDNet. “在Concur上的DevOps和用户体验.” ZDNet. 1月31日. 2017. 网络.

关于信息技术

信息技术研究集团是世界上发展最快的信息技术研究和咨询公司, 为超过30人服务,000年IT专业人员.

我们提供公正和高度相关的研究,以帮助cio和IT领导者制定战略, 及时的, 和消息灵通的决策. 我们与IT团队紧密合作,为他们提供所需的一切, 从可操作的工具到分析师指导, 确保他们为组织提供可衡量的结果.

会员等级

8.3/10
总体影响

$51,433
平均美元救了

16
平均一天救了

在每一次信息技术体验之后, 我们要求我们的成员量化实时储蓄, 货币的影响, 我们的研究帮助他们实现了项目改进.

读一读我们的会员在说什么

什么是蓝图?

蓝图被设计成路线图, 包含解决IT问题所需的方法、工具和模板.

每个蓝图都可以附带一个指导实施,该实现可以让您访问我们的世界级分析师,以帮助您完成项目.

需要额外的帮助?
尝试我们的引导实现

在这个三个阶段的咨询过程中获得你需要的帮助. 您将获得与我们的研究人员的9个接触点,所有接触点都包含在您的会员名单中.

引导实施#1 -促进敏捷学习
  • 第1条建议——讨论如何促进组织执行和管理团队对敏捷的学习.
  • 呼叫#2 -与你的应用交付团队讨论如何促进学习敏捷.

指导实现#2 -评估当前状态
  • 呼叫#1——讨论您的团队和组织对敏捷的准备情况.
  • 第二点——讨论你的团队文化和不同的组件,它们可能是采用敏捷的驱动因素或障碍.
  • 调用#3——回顾SDLC过程,以识别任何因采用敏捷而受到影响的变更.

指导实现#3 -执行结构化评估
  • 讨论并理解scrum方法论是什么.
  • 电话#2 -讨论如何识别、评估、参与和沟通不同的利益相关者群体.
  • 呼叫#3 -讨论用于评估和确定正确的试点项目的标准.
  • 呼吁4 -了解采用scrum的不同实践和仪式.

作者(年代)

安德鲁Kum-Seun

负责人汉斯Eckman

访问我们的 COVID-19资源中心 和我们的 成本管理中心
超过100名分析师正等着接听您的电话: 1- x2019