跳转至内容

敏捷开发框架下的软件工程/第一阶段/系统隐喻

来自维基教科书,开放的书籍,开放的世界
系统隐喻


通过参考熟悉的事物或概念来描述系统

2 小时

与客户第一次会议的笔记

注释笔记

与客户讨论

什么是隐喻?

[编辑 | 编辑源代码]

在第一阶段,功能需求领域涉及我们讨论对商业问题或机会的处理方式。我们通过系统隐喻来实现这一点。

隐喻是将两个看似无关的主题进行比较。它们在语言中被用来使语言生动,鼓励解释,并在没有直接术语或其他解释过于繁琐的情况下提供理解的工具。通过从另一个角度理解和体验某件事,我们可以在真正理解我们正在谈论的内容之前,提供一种探索概念的方法。

也许最著名的隐喻是莎士比亚的开场白

整个世界都是一个舞台

所有的男男女女都不过是演员

他们有自己的登场和退场

— 如你所愿 2/7

在日常对话中,我们说“振作起来”,“淹没在文件堆中”,“展开通往和平的路线图”和“我的记忆有点模糊”。我们用来形容某事物的隐喻可能非常有启发性。例如,我们用来描述商业的词语通常基于战争隐喻:“敌意收购”,“失地”等等,而这些反过来又会影响企业的管理。雷·杰克逊(引用自首席执行官论坛)在讨论商业实践时,借鉴了军事的经验教训

我认为它教会了我,世界永远是不完美的,你的知识库也是不完美的。在军事行动中,你从字面上讲,永远不会拥有“全部事实”。因此,它教会你在不完整的数据下进行操作:利用你掌握的数据,将其转化为信息,并弄清楚你需要做什么。我想我了解到,清晰比确定性更好:总会有一个时机,你会拥有足够的资料来继续前进。如果你等待确定性,它永远不会到来。军队让你适应不确定性。

我学到的另一件事是,不要拖延做决定,要果断。你学习了一个不断做出决定,然后根据新出现的更多信息来审查这些决定的过程。这在商业上非常有用。

军队还教会你仔细管理资源。例如,在海军任务中,你只有有限的燃料、有限的弹药等等。当然,你最重要的有限资源是你的员工,因此你需要照顾他们并培养他们——你不能让他们累死!军队教会你始终要非常注意你的资源以及如何才能最好地利用和节约它们。

我认为你也会学到很多关于领导力和沟通的知识。我喜欢“人们不希望被持续激励,他们只想了解他们应该做什么”这句话。

大多数军人都有高度竞争性,具有“我们来这里是为了胜利”的劲头,因此他们拥有这种坚韧和奉献精神。商业的某些方面就像战斗一样,因此这些态度可能会有用。

另一个有用的态度是设定你的目标,然后不顾一切地追求它们。当然,战争和商业的目标不同。战争是为了战胜敌人——这是一场零和游戏。另一方面,在商业中,你的目标可能是成为最赚钱的公司。这并不是一个像战胜敌人那样需要战胜敌人的目标——更像是实现你自己的目标。

(另请参阅营销的机动理论,它明确地——并且有争议地——使用了军事/商业隐喻:“军械库——竞争性营销人员的在线资源是“进攻艺术”的独家主机——如何攻击和驱逐更大的竞争对手”。)

拉科夫和约翰逊(1980)认为,我们通过隐喻生活。

软件开发:系统隐喻

[编辑 | 编辑源代码]

在软件开发中,系统隐喻被敏捷社区采纳为核心实践。极限编程解释的作者肯特·贝克将系统隐喻定义为

“一个每个人——客户、程序员和经理——都可以讲述系统如何运作的故事。”第 179 页。

Wake 认为,我们寻求系统隐喻有几个原因

共同愿景:使每个人都能就系统如何运作达成一致。隐喻表明了问题和解决方案的感知方式的关键结构。这可以使理解系统是什么以及它可能是什么变得更容易。

共享词汇:隐喻有助于为对象及其之间关系提供一个通用的命名系统。这可以成为一个最好的意义上的行话:一个强大的、专门的、专家使用的简写词汇。给某事物命名有助于你获得对它的控制权。

创造性:隐喻的类比可以为系统(包括问题和解决方案)提供新的想法。例如,隐喻“客户服务是一条装配线”。这表明了将问题从一个组传到另一个组以进行处理的想法,但它也提出了一个问题,“当问题到达生产线的末端时会发生什么——它会掉下来吗?”这可以揭示出可能隐藏和滋生的重要问题。

架构:隐喻通过识别关键对象并建议其接口的各个方面来塑造系统。它支持系统的静态和动态对象模型。

另一个好处是通用性。我们可以使用隐喻在开发之间进行移动:“就像生菜项目一样,但更像是一种灰水方法”是开发新项目时使用的真实句子。

选择隐喻需要付出努力。希望在达成关于适当隐喻的共识时,你会经历深刻而丰富的过程。这是过程中的重要部分,你应该尝试识别和捕捉这些想法。Jefferies(2001)在一个关于基于代理的信息检索系统的生动描述中,描述了“这个程序就像一个蜂巢,出去采集花粉并将其带回蜂巢”。虽然 Jefferies 没有描述它们,但他们很可能首先尝试了其他隐喻。也许“吸取所有知识的吸尘器?...不,有很多,而且信息是有结构的——不只是一个大灰尘球,也许是图书馆?不,那是庞大而静态的,我们想要的是选择性地收集信息的东西,就像车队回收卡车......”。

一些隐喻在软件开发中被反复使用。一些常见的方法

1. 电子表格隐喻

2. 脚本隐喻

3. 制造隐喻(例如 LinesStationsBinsParts 或 AssemblyLine)

4. 会计隐喻(双入账存档符号)

5. 购物车隐喻(电子商务)

6. 拍卖隐喻(电子商务)

7. 黑板隐喻(人工智能)

8. 文档处理器(桌面系统,其中“模型”被保存为文件)

9 虚拟空间隐喻(例如 VR)

10 桌面隐喻

11 工具和材料隐喻

12 按钮无处不在的隐喻

13 人 - 一个人被雇用做这份工作会怎么做?

(其他有时有用的隐喻:银行、法院、报纸、农场、路线图、警察人像识别)


在没有人能想到合适的隐喻(有或没有生动的意象)的情况下,方法是开发一个“朴素的隐喻”。这意味着你更直白地描述系统(学生管理系统将具有学生和注册对象等)。这样做的缺点是它实际上不是一个隐喻——你不会获得任何更深入的理解或见解,因为它植根于你已经知道的东西。尽量避免“接近计算”的隐喻——像 CD 架这样的概念过于接近计算,没有用处。

过程

[edit | edit source]

那么,我们如何使用这个系统隐喻呢?对于一些敏捷的支持者来说,系统隐喻构成了大部分编程的基础,隐喻的基调和主题直接转化为类和模式。

我们采取了一种更轻便的方法。系统隐喻主要是在这里讨论第一次迭代的功能需求的工具。它也可能有助于激发对第二次迭代交互设计的思考。

隐喻应该用简单的术语表达。正如 Ryan 所说:“系统是一家面包店”比“系统将文本解释为命令,并针对生成结果对象的构建器执行这些命令,并附加各种装饰器,通过管道和过滤器将它们排序到正确的箱子中;用户可以根据需要浏览和食用它们”更合适。(C2 2006)。

一旦你有了隐喻,诀窍就是探索它所有的特征,将它们写在纸上或白板上。这些想法将直接流向用户故事或功能需求。


案例研究 项目管理软件

小组:软件工程 2006


对于开发项目管理和团队协作工具的项目,冰箱门隐喻很有用


  • 总是存在(你无需打开它就能找到信息),
  • 家庭留言(彼此之间,电话留言)
  • 日历(今天,安排,即将发生的事件)
  • 购物清单
  • 安全带(防止偷吃巧克力的小偷)
  • 灵感(“你需要那块巧克力吗?”贴纸)
  • 进度图表(体重增加/减少)
  • 家庭清洁/烹饪轮班表
  • 当前工作(尤其适用于年轻人,已命名且有时标有日期的草图)
  • 文档库(音乐票,待付账单) - 有趣地分层!
  • 可重新配置(信息通过冰箱磁铁固定在一起)
  • 教学角色(字母介绍单词和信息给小孩子)。
  • 星图(孩子的行为管理,行为合同和奖励)。
  • 公共场所,
  • 中心位置:我们作为正常生活(工作)流程的一部分经过它(但不会跳出来打扰)
  • 成就(孩子的学校证书)
  • 家庭照片(自己和亲戚/婴儿照片)
  • 报纸剪报
  • 空间有限,必须管理信息以避免因杂乱无章而丢失(但这无需任何规则、设计或经理)(注意,我在这里写了“它这样做”,门本身当然除了充当静态存储库之外什么也不做,是家庭积极管理信息)。
  • 电话号码(家庭/朋友/医生等)
  • 比萨店菜单/电话号码

...并且在不影响真正工作的情况下完成所有这些事情(保持食物冷藏——我们的系统绝不能妨碍项目的进行)。这个项目的另一个隐喻是汽车仪表盘(见下文),另一个是图书馆。



对于另一个项目,一个面向冲浪者的社区冲浪报告系统,一个单一的系统隐喻难以捉摸。然而,这个过程非常有用。当我们探索可能的系统隐喻时——报纸;无线电雪报告;学校通讯——这些为什么不能有效地作为隐喻的原因有效地建立了我们系统特征的列表。

技巧

[edit | edit source]
W

hile 另一个隐喻可能更好,但隐喻不可能出错,尤其是当你将其用作探索工具时。如果你意识到另一个隐喻更好,那么很好,这意味着你在理解上取得了突破

最糟糕的结果不是“错误”,而是隐喻成为误解的原因。以下是 c2.com/xp wiki 中摘录的内容

问问自己,这个难题更像什么熟悉的事物?它真的像从豪华咖啡机里点咖啡吗?它真的主要像在湖上驾驶(迎风行驶)帆船吗?从多伦多开车去巴黎? (...不到 90 分钟的路程,因为巴黎就在布兰特福德的对面。-- RandyMacDonald) (只是为了避免加拿大文化假设)

你是说肯塔基州的巴黎,对吗?:) 也许是在寒冷的冬天走极地路线...

* 任何试图通过删除来清理它的人都没有解决根本问题,所以我把它放回去了。下一个 WikiGnome:澄清从多伦多到巴黎的驾驶问题,或者暂时保留原样。

不,最好保留!它非常漂亮地说明了细微的误解是如何产生的。开发者一号说:“这就像开车去巴黎”,意思是短途旅行。开发者二号脑海中浮现出从英国到法国穿过英吉利海峡隧道的景象,并考虑如何避开火车。开发者三号(在美国)思考着潜艇汽车。这里的误解突出了在讨论中,尤其是在关于系统隐喻这样至关重要的事情的讨论中,意义取决于上下文的重要性。-- BenLast

因此,我们必须小心,避免“错误的见解”。

在你放弃一个隐喻而选择另一个隐喻之前,一定要捕捉到第一个隐喻的所有特征——它们在规划游戏中仍然有用。此外,要记录导致你改变隐喻的事情。隐喻中的错误之处可以和正确的之处一样定义你的系统。

隐喻需要足够熟悉,以至于需要使用它的人群能够理解。说它是“一个针对碳排放的增值会计系统”可能对财务会计师来说是一个完美的隐喻,但如果程序员不理解这种会计方法,那么它将起到混淆而不是启迪的作用。

有时隐喻会限制理解。基于纸张的行和列的电子表格在电子表格的开发中是一个强大的模型(!),但从纸张到现代电子表格真正能力的概念飞跃非常大。这会导致引入“魔法”的风险:“它就像一个魔术白板”。虽然这有助于包含白板的所有基本功能,但系统的真正创新隐藏在“魔法”的外表之下。

我们还需要知道何时放弃隐喻。上面用冰箱门隐喻描述的项目管理开发也用汽车仪表盘描述过。这在早期阶段作为系统隐喻非常有效:不显眼但可以批判性地监控重要指标等,但在用作界面设计的基础时变得笨拙(表盘、带皮革装饰的转向盘等)。

隐喻只有在你有机会发挥作用时才能发挥最佳效果。一旦你开始回到描述计算事物特征(安全性、登录等),试着将你的思维提升到更抽象的隐喻。一种方法是考虑加强版的隐喻——超级 x 会是什么样子?但要小心,如上所述,你必须比“神奇的 x”更具体。




示例:仪表盘

[edit | edit source]
案例研究 仪表盘

小组:软件工程 2006


仪表盘隐喻在开发项目管理系统(实际上是支持敏捷开发框架的系统)方面很有用。使用汽车仪表盘提供关键信息的熟悉概念是思考项目组需要始终看到哪些信息的有用方式;哪些事件会提示警示灯等等。一些团队将隐喻延续到整个开发过程,它在尝试混合向下钻取以获取更多信息的概念(这不是汽车仪表盘通常的功能)时变得复杂。



案例研究 与达芬奇对话

小组:克里斯蒂·杰克逊和乔纳森·昂格,奥塔哥博物馆


达芬奇会说话的机器人头是一个有性格的交互式机器人。机器人可以接受语音并进行回应。它主要针对儿童设计,能够教育用户了解达芬奇的作品和生活。

当有人激活传感器时,达芬奇会向访客打招呼。他可以谈论四个主要主题:艺术、历史、机器和科学。这个项目与设计人员合作,他们正在制作实际的头部。



align="left"


对于这个项目,使用了演员隐喻

  • 向观众致敬。
  • 表演一个场景
  • 演员可以说话、唱歌、跳舞和使用手语
  • 将戏剧的想法和概念传达给客户
  • 展现幽默感
  • 时尚和风格的展现
  • 拥有具有不同情感的性格和角色
  • 与观众进行口头和非语言交流的技巧。
  • 他/她可以成为公众的道德榜样。
  • 反映生活现实给观众。
  • 观众也可以体验到其中涉及的不同情绪,
  • 比如恐惧、喜悦、平静、悲伤、焦虑、快乐。
  • 促进商业冒险。
  • 提供一种逃避/幻想的方式
  • 提供娱乐、知识和欣赏感
  • 提供信息以进行教育。
  • 演员可以代表名声。

这个隐喻有助于我们理解这个系统,因为它展示了我们在开发系统时需要考虑的特征。



商业机会的隐喻

[编辑 | 编辑源代码]

如果你真的卡住了,那么让一个简单的隐喻起作用的一种方法是考虑商业机会的隐喻(而不是信息系统本身的隐喻。这在商业机会本身难以理解时可能特别有用。

案例研究 eLivingCampus

小组:软件工程 2008


小组首先为整个项目开发了隐喻

  • 咖啡杯:好的内容、可回收、标志、励志名言、
  • 百科全书:存储信息、索引、图片、摘要、可搜索、定期更新、准确、在线和纸质版
  • 活生物体:动态的、输入/输出、条件、智能的、提供想法、
  • 路线图:信息根据需要一目了然地进行逻辑组织,还可以找到详细信息、图例和关键结构、移动、很好地转换为数字(移动 GPS 等)、可折叠(以突出显示感兴趣的区域)。
  • CD 架:可以容纳大量信息、可以由用户分类、可扩展、信息可以进行采样、

其中一些隐喻过于接近于计算。例如,百科全书和 CD 架并没有真正提供新的见解——它们描述了任何通用的计算机系统。

也许是因为 Living Campus 本身并不是学生以前遇到过的事情,所以我们改变了策略,开始思考 Living Campus 本身的隐喻。哪些熟悉业务(或机构或流程)的特征可以用来帮助思考 Living Campus——然后,这些隐喻的信息需求是什么?

align="left"

Living Campus 信息基础设施项目得益于对其他业务的信息需求的思考

  • 战时宣传:有选择地积极、组织良好、紧迫感、有针对性的信息、持续广播
  • 奥运会:复杂的网络、许多不同的需求、结果和其他媒体的即时整合、针对不同市场定制、自豪、竞争、不同级别的赞助商、嵌入整个的标志
  • 公司营销:标志、联系方式、客户描述、推荐信、展示创新、获得关注需要创新、案例研究
  • Count Calendar(新西兰长期运行的农业电视节目):与农业相关,但大多数观众不是农民,教育与娱乐相结合、叙事、更多信息、赞助、风格
  • 绿色和平组织:寻求头条新闻,但有证据支持、道德制高点、
  • 建筑开发:计划、许可证、“这里发生了什么?“、工程建模、效果图。
  • 博物馆:教育与娱乐相结合、展品、类别、必须正确(虽然要注意用户理解的重要性)、可能很无聊、漫游、混合观众、可变、风格、互动、乐于助人的工作人员
  • 美术馆:(博物馆+)、布局、精英化、活动、解说信息、数据库、目录、馆藏、开幕、存储、
  • 动物园:喂食时间、繁殖计划、动物和游客行为管理、学校旅行预订、礼品店、保护、筹款、天气、季节性
  • A&P 展览:以社区为导向的社会、得到其他社会支持、学校参与、竞赛、社区参与、户外(一些展览馆)、天气应急措施、活动、展示社区、动物和植物、商业摊位、适合所有人、营销、本地化但区域和国家结构、独特的人物、互动、委员会结构、



参考资料

[编辑 | 编辑源代码]

http://en.wikipedia.org/wiki/Metaphor http://c2.com/xp/SystemMetaphor.html 最后更新于 2006 年 2 月 15 日 2006 年 7 月 24 日 查看 Jackman, R. (2006) 商业是战争吗?军事事务能(不能)教给 CEO 什么 http://www.ceoforum.com.au/200206_ceoinsight.cfm 查看 2006 年 7 月 21 日 Jefferies, R. (2001) 什么是极限编程 http://www.xprogramming.com/xpmag/whatisxp.htm 查看 2006 年 7 月 21 日 Lakoff G. & Johnson, M. (1980) 我们所生活的隐喻 http://theliterarylink.com/metaphors.html Wake, W. (2000) 系统隐喻 http://www.xp123.com/xplor/xp0004/index.shtml 查看 2006 年 7 月 21 日 Wake, W. (2000) 经过验证的系统隐喻 http://c2.com/cgi/wiki?ProvenSystemMetaphors 查看 2006 年 7 月 21 日 http://knowgramming.com/ http://twoscenarios.typepad.com/maneuver_marketing_commun/2005/05/military_metaph.html

华夏公益教科书