BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Lee Ackerman 关注 0 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2012年4月20日. 估计阅读时间: 7 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

我们都看过有关项目失败的统计信息[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)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

建模的内涵可能会更广一些 by 冉 双全

建模是对现实的简化. 我觉得建模的内涵应该会更广,比如建立与现实一致的模型;建立现实不存在的模型...
不过很赞同模型利于多方沟通;但细想模型的来源---可能是来源于某些特殊的需求或普适的需求。对需求的建模和对需求的解决方案建模是两个不同的维度。希望作者也能发表一下观点。

Re: 建模的内涵可能会更广一些 by 鲜于 海平

不可能有与现实一致的模型的。
哪怕是以现实为基础的模型,也是只抽取关心的部分属性集合……

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT