【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

敏捷杂交 —— 新型实验还是“没弄明白”

  • 2012-01-13
  • 本文字数:3440 字

    阅读完需:约 11 分钟

引言

他们没弄明白。他们做错了。直到他们遵循了所有的准则和实践,他们才是真正的敏捷。”你之前有没有听过这类评论?随着敏捷世界中杂交的增长,对不纯粹的敏捷思维的鄙视也在增加。讽刺且自相矛盾的是,敏捷的主要成果就是让我们摆脱了瀑布过程一体适用的哲学。现在,敏捷中狂热的人们在犯同样的错误……把敏捷作为唯一的方法。本文将尝试展现,作为软件专业人员寻求持续创新和更好的方法时杂交不仅是必要的,甚至是我们的首选。

瀑布式开发不起作用

敏捷主义者以说这句话而闻名,事实上他们有大量支持他们观点的证据。但如果他们的雄辩言辞换种说法或许会更准确些:“敏捷往往对在特定类型的组织内使用特定类型技术的特定类型项目效果更好。”并不是说瀑布过程绝无效果,只是它并不是对所有项目都有效。你能找到许多业界老手,他们会告诉你他们用瀑布过程效果不错。他们在撒谎?他们在拒绝变化?

事实是这两种技术都能依赖于各种因素而发挥作用。我将在下面探讨其中一些因素,除此之外还有些其他因素。我强调这些是为了展示在软件开发投入的付出和被感知的过程中情境在其中有着怎样重要的作用:

1. 项目类型

这是个固定投入的软件产品还是个符合当前策略并将形成核心业务的软件产品?固定投入软件产品通常更适合于传统的瀑布过程,而史考特证券会发现使用敏捷会更有帮助。为什么呢?第一种情况下,项目被视作一种开支来管理、跟踪和监控。在史考特证券,他们的在线交易平台“就是”他们的业务。可以在我之前的一篇文章:为什么有些公司敏捷实施不成功?中找到对这一区别的更复杂的解释。

2. 使用的技术

与传统的复杂客户端应用程序相比,基于 web 的技术通常需要较少的开发时间。由于浏览器遵循(大部分)行业标准,因此基于 web 的技术更易于实现。它们是最适于应用敏捷方法论的技术。如果你正在部署一个复杂客户端产品,要安装在公司中 15 个部门的 16,000 台笔记本电脑、台式机上的各种操作系统(或虚拟机)上…你的开发过程将更具瀑布式特征。你或许仍会在以一定时长的迭代周期中进行开发,每两周一次把代码部署到测试环境中,但这一产品以两周为一个迭代交付一次是复杂且充满风险的。这需要更多的规划。每 30 天就安装些新东西到每个人的台式机上可不是个好主意。到第一次安装相关的问题都得到解决的时候,就要准备另一个 30 天的安装了。这个产品会处于持续的变动状态。功能性的交付非常重要,但稳定性、一致性和性能也同样重要,这需要在所用的各项技术和产品的定位间进行权衡。如果更多的变更和快速交付功能很重要,当前的技术组合是否能提供支持?如果想要的是一个稳定的、可信赖的几乎不会当机的系统,那么可能就不必重做整个软件交付过程了。

3. 项目复杂度

当项目是个新的社交媒体创业项目时,敏捷与之乃是天作之合。项目的复杂度很可能包含在开发者 / 创立者的脑海,并且他们对信息的需求的澄清就在附近(甚至可能就在同一个房间中)。他们的开发投入可能不需要任何集成的硬件。他们有自己的开发 / 发布周期,不会与公司其他部门打交道。他们可能不会把他们的软件与其他软件团队整合,并最终可能在能获得反馈和信息的业务过程改进上也没有任何投入。

将其与一个横跨公司六个部门的一个六西格玛黑带业务过程重组项目相比较。这一项目的软件开发部分也许只是全部投入的一小部分。他们对信息和需求的澄清的需要将由一个“指导委员会”决定,这个“指导委员会”可能一个月会谈不超过一次。可能还有其他外部软件需要他们提供接口并从中获取信息(或者发送信息给对方),因此对集成的谈判和时间的安排是很关键的。

有一点要弄清楚:项目的复杂度越高则更有可能需要更深入的规划…甚至是必须的。复杂度的情境给了我们机会停下来思考我们的方法。

4. 文化

公司是否易于接受新想法和新思维方式?他们是否想探索敏捷软件开发?他们通常如何适应变更?如果公司是保守的,那你对敏捷的引入也许不会有大量追随者,也许还会由此产生敌人。谨慎是必需的。更自由的组织很可能会把变更视作自由和授权。但另一方面,组织可能会过于狂热。在这种文化下,新的思维方式会快速流行起来,并在洞察力和深思有机会决定行止之前快速找到富饶的土地扎根下去。

第三条路

在敏捷和瀑布之间是实用主义。这就是一些车间,在其中把敏捷和瀑布的零部件拼凑在一起,成为自己的过程 / 行动。关注技术和结果,跳过教条和浮夸之词。

实用主义者通常被他们的敏捷同仁们奚落为“不愿意坚持到底”。相反,我总是会争辩道,他们所做的才正是最初敏捷创始人们所做的:在如何开发和构建系统上来试验新的想法。考虑到上面提到的情境,实用主义者明白,没有灵活性的教条的软件开发方法是注定要失败的。

的确,新想法来自实用主义者。

远不是“没弄明白”,他们正在寻找那些始终工作良好的甚至可能对所有项目都有效的部分。这种试验、调整和不随波逐流的意愿是创造力最纯粹的形式。这种意愿应该被鼓励和被照看。根据历史经验,这会孕育出某种变革。

下面有一些实用主义的方法,是我所看到和听到的似乎有些道理的:

1) 在棘手的问题 / 缺陷或关键架构系统上运用结对编程 —— 与其把这一项极限编程技术作为规范供起来,实用主义者更愿在需要时使用它。此外,我曾见到过一个团队,他们在一个房间里,一起讨论代码和关键集成部分以消除分歧,从结对编程演变成了群体编程。

2) 在 Scrum 方法之上附加更多的传统项目管理实践 —— 热切的敏捷人士会告诉你这从来都行不通。但以我的经验来看并非如此。例如,一个有着繁杂业务流程组件的项目中软件开发项目只是全部投入的一部分。你也许能用 scrum 来开发软件,但这样的 scrum 过程会需要与整个业务项目及它的实践、程序、时间表、风险和预算紧密地结合起来。多数企业不会选择 scrum 方法来进行一个业务流程项目。

另一个例子是一个采用离岸供应商的项目。由于时区不同和供应商有限的资源这类项目会很难以协调。另外,除了项目成本,供应商也许会要求你为每日的 15 分钟站立会议,迭代回顾时间和迭代规划时间付账。你不得不权衡额外的沟通是否值得在项目成本中增加额外费用。通常你能够通过每周的碰头会和详细定义的规范来达到同样的质量。此外,供应商通常有交付客户所求的合同义务。否则,就没人付款。这种情形下对“正确理解”的鼓励是非常高的,这也许使得瀑布方法更合意

3) 敏捷中的变更管理 —— 敏捷拥抱变化,但拥抱任何和所有变化会导致团队走向失败。我们都曾参与过这样的项目:客户在整个开发过程中频繁地改变主意,多次修订一组故事,甚至是修订在数个迭代之前就已经开发出来并测试通过的原始需求。这么做也许有很好的理由,但也会有很不好的理由:举棋不定的 product owner 注意不到或是考虑不到预算的问题并且觉得项目结束遥遥无期,或是需要“亲眼见证”后才会认可。在这些情形中的项目范围蔓延危害整个项目,也许使得领导层对敏捷产生怀疑。由 scrum master 或更传统些的项目经理精心安排的更强的变更管理技术越来越有必要,用于记录系统的进程、调整预算和进度偏差。

4) 用户故事经理 —— 敏捷方法就是团队和 product owner 在一个 sprint 规划期间把这些放在一起。然而,这常常导致故事写的不好,没有说明所有细节。敏捷需求误解是常见的问题。委任一个全职的用户故事撰写者对一个项目来说是昂贵的,也是值得的。清晰的用户故事会使得更容易编码、更好测试和最终更高的质量。

这仅仅是一些我看到过的事情。但是,我很希望能听听大家的经历。你们在敏捷和 scrum 中看到了什么创新?

总结

实用主义者不会把敏捷或是瀑布这两种方法看成‘要么接受要么放弃’的交易。我愿意把他们看作把世界视为想法超市的独立思考者。

“让我们召开每日站立会议吧,但我仍然需要甘特图来与其他部门结合在一起。”

“我喜欢每 30 天就向我们的客户展示我们的工作,但我需要一些强有力的变更管理,因为这个客户有些非常古怪的想法。”

敏捷杂交是好事。它会促进实践中的创新。没有敏捷杂交,我们无疑将重复犯前敏捷(pre-agile )世界中的错误。从某种意义上来说,极端敏捷人士是对的:实用主义者没有正确地遵循方法论。但,这不是坏事。

关于作者

Christopher R. Goldsbury是一名软件开发专业人员,在职业生涯中他担任过各种角色:开发人员、架构师、scrum master、开发经理、项目经理和质量保证经理。Chris 把他的经验和想法写在他的博客上。


给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2012-01-13 00:001778

评论

发布
暂无评论
发现更多内容

微服务框架相关技术整理

架构 微服务

重磅!京东云自研第四代云主机发布;曝国外物理学家开发出用于量子计算机的汇编语言

京东科技开发者

微软 开发者 量子计算机 谷歌

隧道建设手段结合科技能有多强大?盾构机可视化让工程化繁为简

一只数据鲸鱼

物联网 数据可视化 3D可视化 盾构机 隧道工程

跨云迁移过程中的数据同步及一致性校验实践(一)

UCloud技术

迁移 数据传输 数据库迁移 数据迁移

跨云迁移过程中的数据同步及一致性校验实践(二)

UCloud技术

迁移 数据传输 数据库迁移 数据迁移

ETL工具—Taskctl 如何搭建配置作业类型的管理

TASKCTL

大数据 kettle 运维自动化 海豚调度 ETL

连续两次入围Gartner魔力象限的Quick BI到底有何魔力?

【黑科技】爬虫也可以一键获取 [加载更多] 数据,无编码学爬虫之三。

梦想橡皮擦

Python 28天写作 3月日更

【LeetCode】二维区域和检索 - 矩阵不可变Java题解

Albert

算法 LeetCode 28天写作

话说 synchronized

木子的昼夜

Java

Spring中的事务使用注意事项

少平

spring

产品训练营-第五周作业

羽室

PingCode新成员Goals开放内测!

PingCode

项目管理 敏捷 敏捷开发 研发管理 研发效能

作为产品经理,如何分析和管理你的产品需求?

PingCode

敏捷开发 研发管理 需求管理 需求 研发工具

总结:近几年有哪些不错的scrum工具

PingCode

Scrum 敏捷 敏捷开发 研发管理 研发工具

华为AR&VR黑科技:以“自由视角”360度尽展舞台唯美

华为云开发者联盟

华为 算法 视频 AR&VR 全息显示

一场由fork引发的超时,让我们重新探讨了Redis的抖动问题

华为云开发者联盟

数据库 redis 华为云 GaussDB fork

重磅丨国资委下发通知,加快推进国有企业数字化转型

PingCode

团队管理 项目管理 研发管理 研发效能 研发工具

力扣(LeetCode)刷题,简单+中等题(第30期)

不脱发的程序猿

面试 程序人生 算法 LeetCode 28天写作

入选SIGMOD2021的时间序列多周期检测通用框架RobustPeriod如何支撑阿里业务场景?

阿里云大数据AI技术

人工智能 数据库 大数据

直流电源防反接电路设计

不脱发的程序猿

嵌入式 28天写作 硬件设计 直流电源 防反接电路设计

谷歌android!通宵都要看完这个Android关键技术点,威力加强版

欢喜学安卓

android 程序员 面试 移动开发

谷歌开发安卓系统!Android面试你必须要知道的那些知识,全网疯传

欢喜学安卓

android 程序员 面试 移动开发

在敏捷项目管理情境下,如何做多项目管理?

PingCode

敏捷 敏捷开发 研发管理 研发效能 研发工具

最新整理:Google/网易/腾讯/百度/华为面经(25个专题 1W字答案解析)

比伯

Java 编程 程序员 架构 面试

力扣 (LeetCode)-两数之和,有效的括号,两数相加

我是哪吒

面试 算法 LeetCode 28天写作

互联网公司的「敏捷开发」流程是怎么样的?典型的敏捷团队是什么样?

PingCode

敏捷 敏捷开发 研发管理 研发效能 研发工具

开工第一周,有哪些助你弯道超车的好书?

博文视点Broadview

公安合成作战系统!智慧警务情指行一体化建设解决方案

源中瑞-龙先生

公安合成作战系统开发 产品解决方案 情指行一体化 公安

腾讯音乐-全民K歌iOS面经

iOSer

ios 面试 腾讯大厂 金三银四跳槽

LeetCode题解:188. 买卖股票的最佳时机 IV,动态规划,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

敏捷杂交 —— 新型实验还是“没弄明白”_研发效能_Christopher R. Goldsbury_InfoQ精选文章