敏捷开发框架下的软件工程/第一阶段/系统隐喻
系统隐喻 |
在第一阶段,功能需求领域涉及我们讨论对商业问题或机会的处理方式。我们通过系统隐喻来实现这一点。
隐喻是将两个看似无关的主题进行比较。它们在语言中被用来使语言生动,鼓励解释,并在没有直接术语或其他解释过于繁琐的情况下提供理解的工具。通过从另一个角度理解和体验某件事,我们可以在真正理解我们正在谈论的内容之前,提供一种探索概念的方法。
也许最著名的隐喻是莎士比亚的开场白
“ | 整个世界都是一个舞台 所有的男男女女都不过是演员 他们有自己的登场和退场 |
” |
— 如你所愿 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)。
一旦你有了隐喻,诀窍就是探索它所有的特征,将它们写在纸上或白板上。这些想法将直接流向用户故事或功能需求。
对于另一个项目,一个面向冲浪者的社区冲浪报告系统,一个单一的系统隐喻难以捉摸。然而,这个过程非常有用。当我们探索可能的系统隐喻时——报纸;无线电雪报告;学校通讯——这些为什么不能有效地作为隐喻的原因有效地建立了我们系统特征的列表。
技巧
[edit | edit source]hile 另一个隐喻可能更好,但隐喻不可能出错,尤其是当你将其用作探索工具时。如果你意识到另一个隐喻更好,那么很好,这意味着你在理解上取得了突破。
最糟糕的结果不是“错误”,而是隐喻成为误解的原因。以下是 c2.com/xp wiki 中摘录的内容
问问自己,这个难题更像什么熟悉的事物?它真的像从豪华咖啡机里点咖啡吗?它真的主要像在湖上驾驶(迎风行驶)帆船吗?从多伦多开车去巴黎? (...不到 90 分钟的路程,因为巴黎就在布兰特福德的对面。-- RandyMacDonald) (只是为了避免加拿大文化假设)
你是说肯塔基州的巴黎,对吗?:) 也许是在寒冷的冬天走极地路线...
* 任何试图通过删除来清理它的人都没有解决根本问题,所以我把它放回去了。下一个 WikiGnome:澄清从多伦多到巴黎的驾驶问题,或者暂时保留原样。
不,最好保留!它非常漂亮地说明了细微的误解是如何产生的。开发者一号说:“这就像开车去巴黎”,意思是短途旅行。开发者二号脑海中浮现出从英国到法国穿过英吉利海峡隧道的景象,并考虑如何避开火车。开发者三号(在美国)思考着潜艇汽车。这里的误解突出了在讨论中,尤其是在关于系统隐喻这样至关重要的事情的讨论中,意义取决于上下文的重要性。-- BenLast
因此,我们必须小心,避免“错误的见解”。
在你放弃一个隐喻而选择另一个隐喻之前,一定要捕捉到第一个隐喻的所有特征——它们在规划游戏中仍然有用。此外,要记录导致你改变隐喻的事情。隐喻中的错误之处可以和正确的之处一样定义你的系统。
隐喻需要足够熟悉,以至于需要使用它的人群能够理解。说它是“一个针对碳排放的增值会计系统”可能对财务会计师来说是一个完美的隐喻,但如果程序员不理解这种会计方法,那么它将起到混淆而不是启迪的作用。
有时隐喻会限制理解。基于纸张的行和列的电子表格在电子表格的开发中是一个强大的模型(!),但从纸张到现代电子表格真正能力的概念飞跃非常大。这会导致引入“魔法”的风险:“它就像一个魔术白板”。虽然这有助于包含白板的所有基本功能,但系统的真正创新隐藏在“魔法”的外表之下。
我们还需要知道何时放弃隐喻。上面用冰箱门隐喻描述的项目管理开发也用汽车仪表盘描述过。这在早期阶段作为系统隐喻非常有效:不显眼但可以批判性地监控重要指标等,但在用作界面设计的基础时变得笨拙(表盘、带皮革装饰的转向盘等)。
隐喻只有在你有机会发挥作用时才能发挥最佳效果。一旦你开始回到描述计算事物特征(安全性、登录等),试着将你的思维提升到更抽象的隐喻。一种方法是考虑加强版的隐喻——超级 x 会是什么样子?但要小心,如上所述,你必须比“神奇的 x”更具体。
示例:仪表盘
[edit | edit source]案例研究 仪表盘 |
小组:软件工程 2006
仪表盘隐喻在开发项目管理系统(实际上是支持敏捷开发框架的系统)方面很有用。使用汽车仪表盘提供关键信息的熟悉概念是思考项目组需要始终看到哪些信息的有用方式;哪些事件会提示警示灯等等。一些团队将隐喻延续到整个开发过程,它在尝试混合向下钻取以获取更多信息的概念(这不是汽车仪表盘通常的功能)时变得复杂。
|
如果你真的卡住了,那么让一个简单的隐喻起作用的一种方法是考虑商业机会的隐喻(而不是信息系统本身的隐喻。这在商业机会本身难以理解时可能特别有用。
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