写点什么

敏捷建模:增强沟通和理解

第一部分

2012 年 4 月 19 日

我们都看过有关项目失败的统计信息 [1],也可能亲自遭遇过失败。大多数软件项目都逃脱不了失败的命运。思考一下,我们会发现导致项目失败的方式有(显然这个列表并不详尽!):

技术上的:

  • 解决方案不能满足项目需求(可伸缩性、性能、可靠性、成本等)
  • 由于一些技术难题,我们不停推迟最后期限(或者靠增加成本保证期限),直到项目发起人对项目失去信心并撤资

工作方式上的:

  • 团队不理解提供的需求
  • 提供的需求并不正确

如果我们把这个问题抽象到一个高层次的视图,可以发现理解问题并形成解决方案是有困难的。

不过这个视图过于简化。从问题得出解决方案,我们不应该把这个过程看成是信息的单向流动,也绝不能把它看成是一次性、瀑布式的过程。这种做法我们先前都见过,它的进展并不顺利。

那来更新一下视图,我们发现问题和解决方案之间互有信息流,而且需要迭代。

现在的认知已经清楚一些了,不过它仍然很简单。让我们更进一层。我们都需要认识到,开发是一项团队活动。我们会有多个利益相关者,负责设计、开发、部署和运营的人也不少。

这样我们对这种情形有了更为真实的认识。不过值得思考的空间还是很大。虽然我们力求有一个本地协作的团队,但事实上我们的工作是分布式、网络化的。

总结一下这个过程,会发现项目的成功受限于我们的如下能力:

1. 理解

  • a. 我们了解问题领域么?
  • b. 我们是否通晓解决方案领域?
  • c. 我们知不知道两个领域之间该怎样转换?

2. 沟通

  • a. 利益相关者能不能把需求传递给确定解决方案的那些人?
  • b. 确定解决方案的人在彼此沟通时能不能把解决方案的细节描述清楚?
  • c. 确定解决方案的人能把挑战和替代方案准确地告诉利益相关者么?

此外,还要认识到一个棘手的问题,就是我们需要处理地理和时间的问题(比如工作地点和时区)。

解决这些问题的方法有很多,它们也能增加项目成功的胜算。但我们应该从哪里开始呢?从敏捷的一些基本理念(宣言原则和部分常识)入手是个不错的主意。

与其把钱砸在一堆工具上(我敢肯定这种投入非常可观!),并试图采用命令方式和全方位的流程,还不如让我们用不同的方法。让我们更重视人、沟通、互动,来应对变化、交付软件。怎么才能用这种方法给人们提供最好的支持呢?

一种常被忽视、低估或误解的关键技术是建模的使用——尤其是我们开始采用敏捷方法之后。在反对重量级的流程和以工具为中心的开发过程时,建模也受到了牵连。让我们花几分钟时间来澄清一下……

我们先统一一下对建模的定义。简单说来,建模是对现实的简化。就是这样,不过如此。它并不意味着要用特定的符号、工具和流程。我们只是想研究复杂的东西,让其中的一些部分易于理解。正如他们所说,有时候你是见木不见林。不必要的细节反而会让情况更加难以理解。最好还是隐藏那些不必要的细节,只专注于具体情况的重要方面。

如果对建模的定义达成一致了,那我们就深入一步,考虑下敏捷建模吧。利用敏捷建模,我们可以用一种敏捷的方法去借助模型进行理解和沟通。很抱歉在这里进行了循环定义,但这很容易让我们提出问题:“使用模型的时候,我们怎么采用敏捷方法?”

和一般的敏捷开发一样,我们用一套价值观、原则和实践来进行指导,以便尽可能地敏捷。敏捷建模方法的重点有:

  1. 敏捷建模遵循敏捷宣言和原则。正因为如此,敏捷建模可以是一种实践,你可以把它添加到你的敏捷工具箱里。
  2. 模型能用来沟通和理解。
  3. 我们力争用简单的工具创建简单的模型。拥抱简单。
  4. 我们知道需求是变化的,因此我们在创建模型的时候要拥抱变化。
  5. 我们的重点是交付软件,而不是交付模型。模型能带来价值的时候,我们就使用它们。如果模型没有价值、不能加速软件的交付,那我们就不创建它们。
  6. 我们只保留需要的模型。如果模型完成了它的使命,我们就可以把它扔掉。这能让我们轻装上阵,而不会陷入繁忙的工作。
  7. 我们使用多种模型。我们使用模型时会考虑不同的角度和抽象层次,还有不同的读者。对于我们创建出来的所有模型,我们都知道它的读者是谁、要达成什么目标。要是我们还没理解目标,我们就不会创建模型。
  8. 根据具体情况、读者和目标的不同,我们会结合着用非正式和正式的模型。比如说,一个模型可以由多个简单形状组成,用来说明系统的隐喻,也可以用 UML 的类图。

总结

我们创建软件解决方案时,建模有助于我们进行沟通和理解。因为在交付软件解决方案的时候,沟通和理解是最关键的两个环节,所以不应该忽略建模这一有价值的工具。

消除对建模的误解吧,把它融汇到你的敏捷工作当中。敏捷建模遵循敏捷价值观和原则,应该成为敏捷工具箱里的实践之一。敏捷建模成为工具箱的一员后,会提高项目成功的胜算!

在这个系列的第二部分,让我们一起更深入地研究一下敏捷建模的价值观、原则和实践吧。

资源

AgileModeling.com :Scott Ambler 创建、维护的敏捷建模主页,里面的资源又好又详细。

敏捷建模的要点: 这个工作坊主要提供敏捷建模的基本技能。

规范敏捷交付(Disciplined Agile Delivery):提供敏捷交付规范方法的社区网站。

关于作者

Lee Ackerman是 The Emphasys Group 的产品副总裁和 CTO。Lee 多年来主要调查、评估新理念,设计、开发解决方案,其他人做这些事情的时候他也会伸出援手。他目前的工作重点是帮助一些组织,让他们借助自动化、重用和敏捷最佳实践去提升交付软件的能力。


[1]《IT 项目:超支400%,却只实现了25% 的收益》:这篇新闻研究了IT 项目风险和一些失败相关的惊人数据。

查看英文原文: Agile Modeling: Enhancing Communication and Understanding


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

2012 年 4 月 19 日 00:004096
用户头像

发布了 151 篇内容, 共 53.7 次阅读, 收获喜欢 16 次。

关注

评论

发布
暂无评论
  • 敏捷与 OKR 都是为了“拥抱变化”,两者如何无缝整合?

    敏捷一般应用于软件开发领域,而 OKR 可应用于任何领域,两者结合,值得尝试。

    2019 年 8 月 12 日

  • 章法在敏捷开发中的重要性

    敏捷软件开发,有时被认为是一种没有章法的工作方式。一些机构以此作为不采纳敏捷的理由; 而在另一些人看来,敏捷其实是一种比瀑布式开发更有章可循的软件开发方法。下面,我们就来考察章法在敏捷开发中的作用,以及为什么章法对成功实施敏捷如此重要。

  • 敏捷企业中的架构师生态系统

    很多企业架构师仍然在偷偷编写自己的“解决方案架构定义手册”,甚至想办法掩藏自己的真实意图。但现在,我们发现了一种新的趋势,越来越多的商业与企业架构团队开始携手合作,并共同参与到组织的业务优先级战略规划、项目组合管理、路线图优化、产品管理、以客户为中心型计划、敏捷项目调节以及制定面向业务的新型现代KPI等工作当中。

  • 结束语 | 所谓高手,就是跨过坑和大海!

    专栏虽已完结,但更新优化不止,你有什么建议或意见想和我说说吗?

    2019 年 12 月 2 日

  • 第 89 讲 | 刘俊强:做好一对一沟通的关键要素(下)

    本文将跟大家分享更多实践,包括如何在一对一会议中倾听对方需求并分享你的需求,如何评估会议结果并跟进完成情况等内容。

    2018 年 9 月 18 日

  • 敏捷架构应用

    敏捷有适应性。什么时候以及如何应用架构取决于环境。本文首先解释了为什么是这样,然后说明了在敏捷环境中怎么样才能仍然给予架构足够的重视。适应性和对话是基本要素。

  • 在 AWS 上设计多区域 SaaS 解决方案

    软件即服务 (SaaS) 组织不断发展,其全球业务覆盖范围也不断扩大,与此同时,他们必须考虑更广阔的地理覆盖范围会对其系统架构产生怎样的影响。

  • 大规模敏捷(Scaling Agile)方法分析

    在敏捷社区中,大规模敏捷(Scaling Agile)给大家带来很多困惑。大规模敏捷是什么意思?怎么才能做到大规模敏捷?有哪些框架和方法?采用大规模敏捷需要哪些技术改变?。对于那些想去尝试大规模敏捷的人会有这些疑问。对于另一部分人,大规模敏捷则是从小团队实施到整个组织架构实施的自然过渡。

  • 154|云开发:创建第一个云开发环境

    2020 年 12 月 24 日

  • DevOps 组织中应用架构师的新定位与实践

    DevOps组织的成功,很大程度上来自于聚焦培养强有力的DevOps团队。

  • 当 SOA 遇到形式化方法

    最近,WS-CDL规范的主要作者Steve Ross-Talbot发表了一篇博客,在其中论述了在保险服务业中如何使用基于CDL的方法论成功地开发和部署SOA,并且可以成功节省80%的工作时间。

  • 模型驱动开发:成功在何方?

    在上周的SPLC 2010会议上上,Jon Whittle发表了一场主题演讲,其中讲述的是他在使用基于模型的开发过程中所得到的经验。他提到,对于他发起的调查,其中83%的响应者“认为MDE是个好东西”。但是,业界仍然在寻找如何创建成功的模型驱动的方法。

  • 怎样平衡软件质量与时间成本范围的关系?

    根据“金三角”的三条边,找出来固定的一条或两条边,然后去调整剩下的边,达到平衡。

    2019 年 3 月 12 日

  • 敏捷开发到底是想解决什么问题?

    当你开发做决策的时候,遵守了敏捷开发的价值观和原则,不管你是不是用Scrum或者极限编程,那么都可以算是敏捷开发。

    2019 年 3 月 5 日

  • 敏捷 2012 大会议题:动态组织机构建模

    Catherine Louis和Raj Mudhar 与大家进行了一场题为“用乐高积木搭建你的公司——设计最佳的大型敏捷公司”的小型互动讨论会 。他们采用动态组织建模方法,利用LEGO积木,让参与者模拟并且可视化了组织的变化。有超过100人参加了这场为时半天的讨论会。

  • 如何使用 DDD 方法验证业务规则

    如果我们的目标是创建可以模拟领域专家行为的软件应用程序,那么挑战就是捕获并实现业务规则。相比原始的代码部分,业务规则更接近良好的知识管理。领域驱动设计的这些技术可以提供一个结构,用来在系统中有效验证和实现业务规则。

  • MoDisco:模型驱动的软件现代化框架

    对于大多数IT组织来说,软件现代化都是个严重的问题。 MoDisco是MIA软件和AtlanMod研究团队的合作项目,它提供了一种模型驱动的解决方案。Jordi Cabot和他的同事为这个Eclipse项目撰写了两页长的介绍。

  • 实现非软件 IT 项目的敏捷交付

    大多数组织都避免在不涉及软件交付的IT项目(比如,路线图计划和架构开发)中使用敏捷。这些项目提供了很高的价值,但常常也是所有项目中风险最高的,而高风险需要敏捷交付。本文将回归敏捷哲学的基本知识,探讨如何成功地采用敏捷交付这些项目。

  • 论软件生命周期集成

    对于许多组织而言,是否有综合性的软件交付实践会决定了项目的成败。这时,就应该将精益思想(Lean thinking)应用到软件交付的实践中,并创建和维护从构想到实现的软件流,消除断点,实现实时协作。此时还要创建一个端到端的软件交付实践的规范。该规范必须为连接软件交付实践提供必要的材料,为软件交付实践专业人员提供创建集成体系结构和测量方法,以使软件交付更迅速,并消除实践过程中不必要的麻烦。

发现更多内容

[翻译]The Go scheduler[Go调度]

卓丁

golang golang调度 Go scheduler

我的大厂面试经历

老大哥

Java 程序员 后端

indexOf原理,Java,javascript,python实现

叫练

算法

商业通识 : 商业从哪里来?

Walker

学习 得到 个人成长 商业

第13周 作业

Jaye

What's new in Dubbo-go v1.5.1

apache/dubbo-go

golang dubbo 服务端

面试官为什么会问你,如何设计一个高并发系统?

老大哥

Java 程序员 后端

市值做市机器人,操盘做市系统搭建

13823153121

架构师训练营作业(大数据与机器学习)

qihuajun

架构师训练营 - 第 8周命题作业

红了哟

Flink通过官网创建自己的工程-20

小知识点

scala 大数据 flink

第十三周作业

olderwei

极客大学架构师训练营

Java服务,内存OOM问题如何快速定位?

老大哥

Java 程序员 后端

阿里P8Java架构师呕心沥血整理出来的[史上最全Java面试题精选集锦]

Java成神之路

Java 编程 程序员 面试

筹备半年时间,四面阿里终于如愿拿到P7级offer【Java岗】。

Java成神之路

Java 编程 程序员 面试

“新基建”与“双循环”的二重奏:2020服贸会靠什么推动经济复苏

脑极体

从用户输入手机验证码开始

架构师修行之路

一步搞定任意圆角背景

mengxn

android xml 圆角

阿里P8忠告:这些技术,哪怕不用微服务架构,你也应该会

小Q

Docker 架构 微服务 springboot SpringCloud

大厂面试题:集群部署时的分布式 session 如何实现? 面试官心理分析

老大哥

Java 程序员 后端

Java架构师JVM启动流程和内存结构,程序员必看!

老大哥

Java 程序员 后端

甲方日常10

句子

工作 随笔杂谈 日常

工作好多年有可能还未真正了解接口和抽象类

架构师修行之路

接口 抽象

架构师第十三周作业

傻傻的帅

架构师

【真实面试经历】我和阿里面试官的一次“邂逅”

老大哥

关于二进制的补码,反码,正负数表示以及Java代码测试

Zexho

Java 补码 位运算 反码 计算机知识

架构师训练营第13周作业

[翻译]Go Concurrency Patterns[Go 并发模式]

卓丁

golang Rob Pike Go Concurrency Patterns Concurrency

用技术的“信条”,开启AI to B的产业位移

脑极体

没想到 Hash 冲突还能这么玩,你的服务中招了吗?

老大哥

Java 程序员 后端

架构师训练营第十三周作业

张明森

低代码的认知误区与落地实践

低代码的认知误区与落地实践

敏捷建模:增强沟通和理解-InfoQ