关于敏捷开发:Liga-译文-一文讲清敏捷路线图不再掉入瀑布陷阱

114次阅读

共计 3288 个字符,预计需要花费 9 分钟才能阅读完成。

只管许多组织和团队宣称本人十分麻利,但他们仍在应用瀑布的形式布局产品。为什么会这样?咱们该如何扭转这种「谬误麻利」?

原则上,践行麻利开发很简略:构建一个增量 测试这个增量 理解须要扭转的信息 将信息反馈到第一步中,并反复步骤

整个过程能够从两个方面,将麻利开发与瀑布开发彻底辨别开:第一,尽早且频繁地交付小批量的可工作的产品 第二,依据(一)失去的新变动和信息,对产品进行失当的调整。

如下图所示的麻利路线图很常见。时长一年的甘特图上堆满了性能,并提前完成了任务分配。研发团队只能在一个个不间断的迭代中,实现所有的性能;他们还没有机会总结已交付的工作并作出调整,就必须立即进入下一个性能开发。

如果前两个产品性能交付后被证实是谬误的(这十分有可能产生),难道咱们还要按原打算迭代上来吗?持续遵循下面的甘特图,可能会一错到底。因为打算好的路线图无奈帮忙咱们评估交付成果,辨认问题并及时调整。

麻利开发刻意只关注下一次迭代的即时打算,但许多团队构建了一年甚至更长时间的甘特图,并且列举了无数个待开发性能和实现截止日期。这样怎么会麻利呢?

01 前瞻性打算:麻利刻意疏忽的局部

除了以后迭代正在构建的产品外,麻利方法论不太关注前瞻性的打算。因为只有这样能力做到 「实时打算」 ——咱们应该看到什么是可行 / 不可行的,并依据反馈的数据决定下一步该怎么做。

麻利意味着「可能疾速轻松地口头」,而麻利开发须要被继续疏导,逐渐提供价值,再依据市场反馈的状况疾速调整策略和方向。 这是一个建设在洞察与反馈简直同步的疾速反馈周期,而不是基于后期的大打算。

然而,组织(尤其是大型或传统组织)通常不喜爱没有打算地工作。没有打算的组织会陷入「打算缺失焦虑症」;更精确地说,组织的领导者会很焦虑。因而,他们会制订一个性能列表,提前做好调配,以确保每个人都能按预约的形式有序地工作。

麻利的组织该当侧面解决打算缺失的焦虑,但许多团队没有这样做。反而是领导者们认为,过来路线图和甘特图很有用,那就应该持续应用它们。缓缓地,麻利就变造成「Water-Scrum-Fall」,就像下图这样。

可怜的是,麻利的外围——灵便自在地依据新信息进行调整——被齐全疏忽了。许多团队实际的麻利并不是真的麻利,而过来的瀑布式工作列表也演变成了「用户故事」列表。

02 SAFe:麻利适配器

麻利框架没有提供任何以后迭代以外的具体布局倡议,而扩大框架正填补了这一空白。SAFe 有一个长处:作为从后期瀑布式大打算到团队麻利执行的适配器,它能够很容易地被了解。

应用 SAFe(或其余扩大框架),产品治理团队提出性能,设计团队绘制 UI 模型,再发送给管理层审批。当工程师开始编写代码时,管理层会很释怀。因为他们曾经做好了充沛的打算,而成千盈百名程序员都会尽职尽责地工作。

通过麻利扩大框架,管理人员能够看到所有打算中的性能,而开发人员能够在迭代中专一地写代码。这也是麻利扩大框架受欢迎的起因:它们将领导者相熟的大型打算,转换为研发团队可执行的麻利迭代。在一些高级管理者看来,这就是最重要的。

事实上,工程团队已沦为「性能工厂」,他们简直失去了所有学习、疾速调整和扭转的能力。管理者却真诚地置信,团队曾经实现「麻利转型」。

03 敏捷性须要空间来操作

回到后面提到的两个决定性麻利特色:尽早且频繁地交付小批量的可工作的产品 依据(一)失去的新变动和信息,对产品进行失当的调整。

第一点比拟好了解,简直所有材料也都集中在这下面;可能正确把握第二点的人要少很多。如果团队没有从晚期部署的迭代中学习,也没有将洞察力融入后续的迭代优化,那么就没有正确地践行麻利——这其实只是「增量瀑布」

正确的麻利要求组织屡次公布和从新公布雷同的性能,并且每次都要从晚期的教训中吸取教训,使该性能更易于应用、更弱小、性能更好或在某些方面更好。 这须要工夫,而且这些工夫无奈在后期被充沛预计和事后承诺。

因而,要想胜利地洞悉变动,实现迭代优化,团队须要在打算中做到以下三点。

  1. 打算实现的门路必须是可塑的。 定义一个愿景或最终目标,但容许具体的性能和内容在执行时能够有所变动。 咱们无奈精确预测一个性能会如何运行,所以须要测试它。麻利团队要容许每个性能能被重复加工、打磨或扩大几次,直到真正实现它。
  1. 打算须要为调整和优化留出弹性空间。 如果工夫曾经全副按计划调配完,就须要删掉一些货色。正确的策略是在一开始就不要填满所有工夫,让它放弃凋谢状态;能够为新想法整顿一个新队列,直到工夫容许,再进入迭代调配。后文的「Now-Next-Later」也会具体解说这一办法。
  1. 领导的反对。 这通常是三点中最难实现的。

04 领导力是敏捷性的要害

最具影响力的胜利因素是组织展现和激励的领导范式。 —— Agile 2

很多领导层都认为麻利是团队外部的事件。这种假如必定是谬误的,而 领导们也须要以麻利的形式行事。在我的项目过程中,如果要为团队提供调整的空间,领导者就要承受长期的打算。「可塑性强的门路」和「容许调整的弹性空间」印证了这点。

管理者要有足够的勇气和信心,能力对团队说:“咱们不打算在这个迭代将你们的工作填满;你们须要跟着数据走,看看本人的工作成绩。”

如果领导者要真正拥抱麻利,他们就须要做出根本性的扭转。这遵循精益守业的精力:建设一个我的项目、测试它、从数据中学习、并将这些教训间接反馈到后续的我的项目中

同时,领导者也要有勇气,承受这些事实:团队不会在内部烦扰下提前确定工作,也不会一轮接一轮无缝地进行性能开发。团队须要更多实验性、创造性和跨职能的工作。

这同样意味着,领导者须要疾速响应、批准通过更多碎片化的需要变更。他们要摸索出更灵便地工作办法,以便为团队提供及时审批。这无疑会突破官僚主义的桎梏,而由领导者们组成的小团队则能更快、更独立地监督和批准本人团队的工作。

05 Now-Next-Later 模型

更罕用的麻利路线图工具是 「Now-Next-Later」模型。甘特图中层层叠叠的功能集能够演绎总结为三个模块。

  • Now:咱们正在踊跃工作的事件。
  • Next:「Now」实现后,行将开始的工作。
  • Later:其余所有未调配和未承诺的性能。

将新的需要、性能和工作按模块布局好,比挤进拥挤的甘特图要容易得多。咱们能够很轻松地在每个模块中留出弹性容量空间,以便后续依据最新信息做出调整。

能够看到,「Now」中的我的项目定义得比「Next」更加具体,「Later」是定义和形容起码的 。每个模块的时间跨度能够自在决定,但最好跨度大一些,尽量笼罩多个迭代和优化周期; 倡议的工夫周期是每个模块 6 周或者一个季度

正确地应用「Now-Next-Later」,既能让咱们适应短期变动,为后续工作和 Bug 修复留出空间,也能适应长期变动,扭转咱们对哪些性能要从模块中取出的想法。

但它不会打消干系人要求尽快交付性能的压力。这也是为什么领导者须要本人拥抱麻利,能力让团队胜利。领导者须要通过本人的致力,提倡麻利的工作形式,并以同样的规范要求本人。

06 论断

许多自称麻利的组织,他们提前打算了大量性能列表——通常提前一整年——并通知团队要以小批量的形式交付。这不是麻利,这是增量瀑布。

麻利开发的外围特色是小批量地交付可工作的产品,从晚期迭代中取得洞察力,并在后续迭代中进一步欠缺和优化雷同的性能。 其中的关键在于咱们无奈预知和确定什么是可行的,什么是行不通的;这须要洞察和跟踪数据。打造一款优良的产品,咱们要一边走,一边制订打算。这与一年长的甘特图齐全不同。

「Now-Next-Later」只有与团队自主权相结合时才有意义。这样能力使团队发现打算的调整空间,及时做出应答。

想要灵便地工作,在做打算时要留神 建设高度灵便的路线图 留出短缺的弹性空间用于响应调整 ,以及 取得领导层的积极支持。利用好这三点,就能够继续地疏导我的项目,而不是在后期就将它固定下来。这就是麻利真正的意义所在。


原文作者:Raj Nagappan
文章出处:Medium

理解更多麻利开发、项目管理、行业动态等音讯,关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台,在线申请体验咱们的产品。

正文完
 0