使用敏捷导航产品开发的复杂性

已发表: 2020-10-01

最后更新:2021 年 3 月 12 日

承认敏捷的必要性与不承认敏捷之间的明显区别在于流行病的爆发。 COVID-19 带来的一系列新变化不可逆转地扰乱了现有系统,并使公司在新现实中的敏捷性(或缺乏敏捷性)成为人们关注的焦点。

“然而,在这个复杂的世界中,不确定性与现实密不可分,为了使事件成为偶然事件,将表现不佳的替罪羊不仅是徒劳的,而且是鲁莽的。”

尽管规模巨大,但 Covid-19 危机是企业必须应对的众多不确定性中的另一个。

采用一套灵活的原则并根据需要进行调整,为企业创造了内在的灵活性,以抵御和预防即将到来的不确定性的冲击。

软件开发的文化、人员和流程中的敏捷性是官僚主义结、狭隘视野孤岛、真空操作和永久延迟的解毒剂。

成为您的组织需要的敏捷产品领导者:

领导者需要认识到并成为第一个通过采用敏捷的工作方式来发出变革信号的人,并通过他们不断演变的公共行为来传达相同的信息。

“优秀的领导者,敏捷的领导者,以服务为目的的领导者。”

他们倡导信任、透明度、问责制、协作的价值观,并通过实现反复试验的承诺,专注于增强软件开发团队的能力并消除推动价值的障碍。 在培养仆人式领导的过程中,敏捷领导者放弃对最小细节的微观管理,开发新的开放式沟通方式来与组织互动,并赋予跨职能团队自主权。

最有效的敏捷领导者是那些模仿他们的新行为以反映敏捷工作方式的人; 在决策、日常沟通和发展战略方面。 因此,敏捷软件开发团队和公司在为尊贵的客户提供有效服务方面走了很长一段路。

用协作敏捷开发取代运营中的真空

在筒仓中工作; 在办公桌前敲敲打打,孤立地执行预先决定的任务使一个人成为一个有远见的人。 敏捷产品开发标志着从信息孤岛的转变,通过创建跨职能团队专注于凝聚力协作。

这些团队由少数人组成,他们能够适应挑战,定期整合反馈以不断改进,并通过即时问题解决来巩固势头。

这些团队的特征嵌入在员工行使所有权和分担工作责任的必要性中,而不是被他们严格定义的工作角色和零散的信息所束缚。

敏捷-1

通过引入一种能够实现透明度、端到端问责、专注于执行和对抗阻力的交叉协作文化,内部复杂性被缩小了。 敏捷软件开发消除了排队延迟、返工,并在最短的时间内促进了交付。

复制敏捷机制会根除团队的敏捷性。 敏捷的关键原则赋予了技术以生命和意义。

将自由沟通、客户满意度和协作排除在流程之外,并推动 sprint、scrum 和 timeboxes。 敏捷性使团队能够交付价值。

借助 DevOps 实现量子飞跃:敏捷实践领先一步

获得正确的敏捷性有望在公司的发展中取得天文数字的进步。 利用这一承诺的是 DevOps,采用它是一个关键的加速器,可以加强敏捷软件开发过程,以实现更快、可靠、安全和迭代的发布周期。

许多公司通过在自动化测试、持续软件开发和发布等地方添加一些元素,获得了 DevOps 的好处的一半。 然而,被动的方法和不愿进行整体更改是获取 DevOps 包罗万象的好处的障碍。

控制和治理、业务部门和运营模式的宪法性变化是开始和推进 DevOps 的先决条件。

在 DevOps 范式中,曾经服务于公司目的但现在已经过时和减速操作的无关软件控制被调整,以解决业务需求的可变性。

DevOps要想找到它的节奏,就必须在软件开发、治理调整、不同部门之间的兼容等同步运行模式上形成交响乐。 它应该针对一个简单的目的,即在不考虑任何可靠性或质量问题的情况下缩小软件规划和发布之间的距离。

为了让公司从 DevOps 中获得最佳收益,他们必须采用和引入自动化来实现健康的持续交付管道,从而实现快速的软件发布和迭代改进。

“亚马逊在 2010 年成功过渡到敏捷 DevOps,显着减少了中断次数,从而节省了数百万美元。 它利用了由名为 Apollo 的内部系统管理的持续部署过程的好处,该系统使他们的开发人员能够随时在任何服务器上部署代码。 一年之内,亚马逊平均每 11.6 秒就将新软件部署到生产服务器。”

借助 DevOps 实现质的飞跃是一个有组织的、渐进的过程,从将其逐步引入现有系统开始。 通过试点项目建立数字能力,然后采用 DevOps 实践有助于转化为决定和采用一套工具和技术机制。

非常明显的好处包括:

  • 最大化测试覆盖率
  • 可靠、更快地大规模交付软件
  • 改善协作
  • 更低的返工成本带来成倍的收入

组织迟早必须适应竞争对手采用 DevOps 实践设定的基准。

敏捷产品开发实践中的标准包容性

敏捷是一项永恒的追求。 正确获得敏捷性的最佳测试是始终坚持其最重要的原则:

1. 迭代:

敏捷意味着认识、接受和为不确定性做好准备。 这是所有陈词滥调的总和。 从头到尾执行,不考虑瞬息万变的市场生态系统、客户期望和业务需求,是注定要失败的。

相反,将任务分解为可识别的较小块并重复执行以降低风险,同时考虑到对外部因素的依赖因素,有助于保持灵活性。 迭代为敏捷开发过程增添了活力。

2. 交付价值:

通过持续优先考虑关键要素和技术卓越来持续关注交付快速价值是敏捷性的关键。 将迭代学习集成到下一次迭代中,敏捷的重点是在流程的每个小步骤中交付价值。

巩固组织快速行动、获得项目成果的可见性以及相应地纠正路线的能力,这些只是敏捷实践带来的一些优势。 与构建乐高玩具非常相似,每个积木都增加了一个价值,与一致的目的相一致。

3.增量:

敏捷通过将项目需求分解为可消化的部分并以恒定的速度增量交付价值元素来推动可持续发展。 摆脱传统的线性和顺序模型,敏捷性与刚性相反。 它为组织提供了所需的灵活性,以持续评估积压工作、确定项目需求、将其划分为单独的块并持续交付。

4. 跨职能团队:

敏捷性需要由积极进取的个人组成的跨职能团队在一个有利于协作、面对面对话、信任、集体所有权和共同愿景的生态系统中运作。 没有另一个就不可能发生。 如果环境不支持参与,来自多个学科的成员就不能专门从事关键任务活​​动。 同样,只有在缺乏来自多学科领域的不同观点和专业知识的代表的情况下,有利的环境才能发挥如此大的作用。

5. 客户至上:

对于企业而言,识别客户、将客户放在首位、解决问题并成为数字化推动者至关重要。 翻译之间失去了太多的洞察力; 从客户未满足的需求到编码人员。 敏捷专注于成为客户代表,并在决策过程的每一个小步骤中,优先考虑他们的需求、观点、动机和问题。


组织必须以这些基本原则为导向,并使用敏捷软件开发的通用语言来推动渐进和巨大的转变。

不应该遵循的做法

敏捷-3

敏捷性是一个统一执行的实践和原则系统。 对于几家正在过渡到敏捷之旅的公司来说,由于以下因素,几乎没有结果:

1. 樱桃采摘:

大多数公司都在寻求敏捷,但最终选择了他们认为便于实施的元素。 敏捷性一开始让人不舒服,因为它意味着摆脱专业人士逐渐习惯的等级制度、孤岛和不负责任的态度。

敏捷产品开发的实践伴随着痛苦和快乐。 理解和吸收本质,不断从中学习,建立一个灵活的组织是至关重要的。

2. 复制粘贴敏捷:

类似于“摘樱桃”的影响是复制和粘贴敏捷。 对于许多公司来说,“敏捷”只是一个流行词,在观察到其他人跟随并受益于敏捷之后,他们也随波逐流。 敏捷的原则是相同的,但是,对“Spotify”有用的东西是否也适用于其他任何人并不明显。

在不了解自治方面或其轨迹的情况下将您的团队组成小队、部落和章节是一种失败的努力。 实施敏捷,但要根据企业的需求、结构和规模对其进行定制。

3. 在纸上:

将自己标榜为敏捷但不愿对敏捷开发原则进行任何基本转变的公司已经陷入了采用敏捷“纸上谈兵”的弊端。 这些公司厌恶基本需求和文化。

对于组织而言,向敏捷的转变是一场地震和改变结构的练习。 公司必须事后进行计划、准备和执​​行,才能正确实施敏捷实践。

让毫无准备的、不确定性及其变量相形见绌是一种常态。 进入敏捷开发过程或与那些在日常工作中根深蒂固的实践的人合作是克服这些变量的即时性和后果的唯一途径。