敏捷开发,什么是敏捷原则?

《敏捷宣言》概述了12种敏捷原则 ,此外还有4种敏捷价值。敏捷软件开发的这12条原则有助于确立敏捷思维方式的宗旨。它们不是一套用于实践敏捷的规则,而是一些有助于灌输敏捷思想的原则。

下面,我们将回顾12条敏捷原则中的每条原则,并描述如何实践。

没有什么方法可以保证团队一定能开发出完美的软件,敏捷的团队也是同样地,所以,有一系列的原则来帮助敏捷团队。

最优先要做的是尽早、持续地交付有价值的软件,让客户满意。
欣然面对需求变化,即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。
频繁地交付可工作的软件,从数周到数月,交付周期越短越好。
在团队内外,面对面交谈是最有效,也是最高效的沟通方式。
在整个项目过程中,业务人员必须和开发人员每天都在一起工作。
以受激励的个体为核心构建项目。为他们提供所需的环境和支持,相信他们可以把工作做好。
可工作的软件是衡量进度的首要标准。
敏捷过程倡导可持续开发。
坚持不懈的追求技术卓越和良好的设计,以此增强敏捷的能力。
简单是尽最大可能减少不必要工作的艺术,是敏捷的根本。
最好的架构、需求和设计来自自组织的团队。
团队定期反思如何提升效率,并依此调整自己的行为。

敏捷开发,什么是敏捷原则

敏捷原则1

“我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。”
确保您在不断交付有价值的软件的同时让客户满意的最佳方法是尽早交付,频繁迭代并持续聆听您的市场。

与众所周知的开发周期长的传统产品开发方法不同,敏捷原则鼓励最大限度地缩短构思和发布之间的时间。我们的想法是尽快将有效的产品交付客户。成功做到这一点意味着产品经理能够迅速将最低限度的可行产品(MVP)推向世界,并使用它来获得真实客户的反馈。然后,此反馈将反馈到产品开发过程中,并用于通知将来的版本。

实际情况:

产品团队使用最少的可行产品和快速实验来检验假设并验证想法。
频繁发布有助于推动客户和产品之间不断的反馈周期。
发货和完成不是一回事。迭代并没有发布“成品”产品,而是继续根据客户和市场反馈对产品进行增量改进。

敏捷原则2

“欢迎不断变化的需求,即使在开发后期也是如此。敏捷流程利用变更来获得客户的竞争优势。”
在我们周围的世界中,变化是唯一不变的。敏捷的原则和价值观支持对这些变化的响应,而不是尽管有所进步。以前的产品开发方法经常会带来不利影响;在开发开始之前就制定了详细,有据可查的计划,无论新发现如何,这些计划都是一成不变的。敏捷原则支持观察不断变化的市场,客户需求和竞争威胁,并在必要时改变路线。

实际情况:

产品团队受高层战略目标甚至可能低于这些目标的主题的指导。产品部门的成功是根据实现这些战略目标的进度来衡量的,而不是通过交付预定义的功能集来衡量的。
产品始终立足于地面,监视市场,客户反馈以及其他可能影响产品方向的因素。当发现可行的见解时,将对计划进行调整,以更好地满足客户和业务需求。
产品策略和战术计划会定期进行审查,调整和共享,以反映变化和新发现。因此,产品需要适当地管理高管利益相关者的期望,并确保他们了解变更背后的原因。

敏捷原则3

“经常交付工作软件,从几周到几个月不等,而更倾向于缩短时间。”
敏捷哲学主张将产品开发分成更小的组件,并经常“运输”这些组件。因此,使用敏捷方法(并以更频繁的方式发布产品的迷你版本)可以加快产品的整体开发速度。

这种敏捷的方法具有较短的产品小部分开发周期,从而可以减少花费在草拟和研究瀑布式产品开发的大量文档上的时间。更重要的是,这种频繁发布的方法为您和您的团队创造了更多机会,可以从看到每个新版本的合格选民那里验证您的产品构想和策略。

实际情况:

敏捷开发周期(通常称为“冲刺”或“迭代”)将产品计划分解为较小的块,可以在指定的时间范围内完成。如果您考虑瀑布团队经常遵循的类似于马拉松的开发周期,那么这个时间段通常在2到4周之间,这确实是一个冲刺。
敏捷冲刺的另一个流行替代方法是持续部署。这种运输软件的方法通常在预定的时间范围内工作较少,而在简单地决定要做什么和执行该工作方面却更多。

敏捷原则4

“业务人员和开发人员必须在整个项目中每天一起工作。”
交流是任何项目或团队成功的关键,而敏捷原则从本质上要求它是日常活动。他们说要养一个孩子需要一个村庄,这也适用于产品。

成功的产品需要组织业务和技术方面的洞察力,只有这两个团队始终如一地合作才能实现。商界人士与开发人员之间的定期沟通通过建立信任和透明性,有助于改善整个组织的一致性。

实际情况:

跨职能敏捷产品开发团队包括产品人员。这意味着产品在开发团队中具有代表性,并弥合了产品在技术和业务方面的差距。
日常更新会议或站立会议是许多敏捷商店用来实践该原理并使每个人保持联系的一种技术。

敏捷原则5

“围绕有上进心的个人建立项目。为他们提供所需的环境和支持,并相信他们能够完成工作。”
敏捷哲学的关键部分是通过信任和自治来增强个人和团队的能力。需要精心构建敏捷团队,以包括合适的人员和技能来完成工作,并且在项目开始之前需要明确定义职责。但是,一旦工作开始,就没有地方进行敏捷的微管理或手持。

实际情况:

产品必须明确确保工程人员在开发开始之前就了解策略和要求。这意味着不仅要与跨职能团队共享用户故事,而且还要在产品路线图中概述更大的前景。
产品不负责解释应如何构建内容。他们需要分享什么以及为什么,但是确定如何做是交付团队的工作。此外,在sprint期间,产品不会对结果进行微观管理,而是让他们自己回答问题并根据需要提供支持。

敏捷原则6

“向开发团队内部传达信息的最有效方法是面对面的交谈。”
如今,随着如此众多的分布式或远程开发团队的到来,这一原则引起了一些批评。但从根本上讲,与开发人员进行有效的交流意味着摆脱Slack和电子邮件中的这些对话,并支持更多的人机交互(即使是通过视频电话会议完成)。该原则背后的总体目标是鼓励产品人员和开发人员真正实时地就产品,需求和推动这些事情的高级策略进行交流。

实际情况:

每日站立会议
协作积压培训会议
冲刺计划会议
频繁演示
配对编程

敏捷原则7

“工作软件是进度的主要衡量标准。”
支持敏捷哲学的人很快就提醒我们,我们从事构建软件业务,这就是我们应该花费的时间。完善,详细的文档是工作软件的附属文件。这种心态推动将产品迅速推向市场,而不是让文档或“直到完美”才成为瓶颈。成功的最终标准是客户喜欢的工作产品。

实际情况:

设计和发布“最小可行功能”而不是全面开发的功能集意味着首先要考虑的是我们可以交付的最小的东西,以便在继续开发软件时开始获得客户反馈并进行验证。
快速失败的心态意味着即使在不确定的时期也要前进并迅速检验想法。
经常发布软件:现在有用的产品要比后来的完美产品要好。

敏捷原则8

“敏捷过程促进了可持续发展。赞助者,开发者和用户应该能够无限期地保持恒定的速度。”
跟上苛刻的快速发布时间表可能会对团队造成负担。尤其是当期望值过高时。敏捷原则鼓励我们注意这一点,并设定现实,明确的期望。这样做的目的是保持士气高涨并改善工作与生活之间的平衡,以防止跨职能团队的成员倦怠和更替。

实际情况:

在每次冲刺之前,都要仔细考虑可以承担的工作量。开发团队不会过度承诺自己可以提供和不能提供的产品。估算工作量是为开发团队设定产出期望的一种常见做法。
每个人都同意在冲刺阶段将完成的工作。冲刺开始后,除非极少数情况,否则无需添加其他任务。
产品经理应充当守门员,以减少其他利益相关者的干扰,并避免在正在进行的冲刺期间挤压其他计划外的工作。
产品人员应在促进跨职能团队的心理安全感中发挥自己的作用,该团队鼓励开放式沟通和自由流动的反馈。

敏捷原则9

“持续关注技术卓越性和良好的设计可增强敏捷性。”
敏捷哲学鼓励缩短周期和频繁发布,同时也强调保持事物整洁的重要性,以免将来出现问题。产品经理常常会忘记开发的这一方面,因为他们大部分时间都不会花时间在产品的代码库中,但是这对他们仍然是最重要的。

实际情况:

团队需要了解技术债务以及积压中添加的任何新功能或计划对技术债务的影响。开发人员和产品需要共同努力,以了解是否以及何时可以接受技术债务。
产品需要定期分配开发资源以进行重构。重构不能是事后的想法,它需要不断进行考虑。

敏捷原则10

“简单性-最大化未完成工作量的艺术-是必不可少的。”
您可能听说过80/20规则,即通常只需20%的工作即可获得预期结果的80%的概念。敏捷原则鼓励以这种方式思考。做最有影响力的事情。在产品管理环境中,这意味着将注意力集中在组织目标上,并做出一些苛刻的优先级决策。敏捷原则通过强调具有战略意义和有目的的建设的重要性而仅仅为了进行建设而阻止建设。

实际情况:

产品经理需要做出非常有针对性的产品决策,并使产品战略与组织目标紧密结合,同时要对用户故事和功能的实际使用表现出极大的挑剔。使用优先级排序技术通过努力和预期影响对优先级进行优先级排序是产品团队可以将此敏捷原则应用于产品开发的一种方法。
敏捷性的短距离冲刺的特点是为快速测试和实验提供了许多机会,这些机会可以帮助减少有关举措是否真正具有预期影响的不确定性。在通过实验进行验证之前,先验证其想法,然后再进行筛选,这是清除坏主意并确定好主意的好方法。

敏捷原则11

“最好的架构,需求和设计来自自组织团队。”
在传统的软件开发方法中,您经常会看到金字塔形的团队,其中管理层为贡献者做出关键决策。敏捷原则建议使用自组织团队,这些团队采用更“扁平”的管理风格工作,在这种团队中,决策是由一个团队而不是由单个经理或管理团队来制定的。该概念与团队的敏捷价值以及流程和工具上的交互联系在一起,其目的是使团队能够根据需要进行协作。

实际情况:

自组织团队是组织中的自治团体,负责对其各自项目的控制和责任,并拥有这些领域的所有权。不同的组织会以不同的方式实践此原则。例如,Spotify使用“产品小队”进行练习。

敏捷原则12

“团队定期检查如何提高效率,然后相应地调整和调整其行为。”
如果您真正地按照敏捷原则生活,那么“我们无法改变,因为我们一直都这样来做”,这是没有地方的。就像我们一直在学习有关客户和市场的新事物一样,我们也在从用于学习这些事物的过程中学习。敏捷不是要针对每个sprint和发行版遵循严格定义的过程,而是要不断改进。持续的改进还必须扩展到流程和团队。

实际情况:

实验和测试不仅限于产品。鼓励敏捷团队尝试其流程。您可能会认为您已经做得很好,只是尝试使用该过程的修订版并发现一种更有效的方法。试验您的流程和团队与试验您所构建的软件一样重要。
定期进行回顾是团队讨论成功之处,失败之处以及将来可以改进流程的地方的机会。它们是产品经理和产品所有者了解与开发人员进行有效沟通并为他们提供冲刺之前,之中和之后所需支持的绝佳场所。
关于此敏捷原则的另一个考虑因素是,为了有效地实践该敏捷原则,您需要建立一种信任和透明的文化,以鼓励开放性和频繁地共享反馈。

分享不易,请支持本站其他资源

全球手机话费充值:http://www.globalrecharge.cn/
新版axureshop产品原型网:http://www.axureshops.com
AxureShop商城:http://axure.amynik.com/
情趣商城:http://sex.chanpindashi.com/
Axure工具集下载:http://www.chanpindashi.com/2019/12/02/1997.html
产品大师:http://www.chanpindashi.com/
源码商城:http://mall.amynik.com/list/1
axureshop产品原型网(旧版停止更新):http://axureshop.amynik.com/
产品经理论坛:http://bbs.amynik.com
淘宝优惠券:http://taobao.chanpindashi.com/
京东优惠券:http://jd.chanpindashi.com/?chanpindashi.com
艾美图纸网:http://tuzhi.amynik.com/

最后编辑:2020年07月07日 ©著作权归作者所有

发表评论

×