理解敏捷方法之间的差异可能是一项艰巨的任务。一些人对大量的信息感到困惑，另一些人对缺乏清晰度感到失望。

理想的方法是对所有内容都一目了然，然后比较每个框架的优缺点。为了确保它足够简单，我们展示了一个简短而清晰的表格，列出了Scrum、看板和Scrumban之间的主要区别和相似之处。

 

原文：https://www.eylean.com/blog/2016/08/scrum-vs-kanban-vs-scrumban-whats-the-difference/

本文：

讨论：请加入知识星球或者微信圈子【首席架构师圈】或者小号【jiagoushi_pro】

不同组织的许多高管都接受这样一个事实，即敏捷方法，它是正确的框架，提供了很高的投资回报率，并且可以成为实施组织战略变革的竞争优势。

每个组织都不同;它具有不同的商业模式，产品和服务，在不同的市场中运作，具有高度低风险和不确定性，面临着不同的宏观和微观环境挑战。

你怎么知道敏捷适合你，我怎么能搞清楚？

要了解敏捷方法是否适合您的组织，可以使用不同的模型来定制我们的组织中的敏捷适用性。

其中一个模型被称为Stacey矩阵模型。

Ralph Stacey在2011年开发了这个模型，以帮助管理者和领导者在不同的情况下选择不同的决策和管理方法。

该模型是二维的，基于确定度和一致程度。

 

 

水平（X）轴，确定性程度与确定或定义原因和影响之间的联系有关。当确定原因和有效联系时，问题肯定很接近。

在这种情况下，人们可以利用过去的经验来计划未来行动的结果，并期望具有良好的确定性，积极的结果。

当问题或决策远未确定时，因果关系不明确，情况是新的或独特的。

垂直（Y）轴是团队，团队和组织之间就问题或决策达成一致的程度。

 在频谱的一端，如果在这个问题上存在高度的确定性和一致性，那么决策就很容易，这个领域被称为（理性或简单），传统方法（瀑布）和方法是最有效的。

 在另一个范围内，没有就该问题达成一致意见，也没有确定因果关系。在这个地区，计划通常是慷慨的，这是一个混乱和无政府状态盛行的地区。

 这是极端不稳定和稳定性不可逆转的极端，应该避免混沌区域。

 在频谱的两个极端之间存在称为复杂区的大区域。这里的传统方法并不是情感因为复杂区域中的系统是不可预测的。

 在此区域，您既不能提前指定产品详细信息，也不能在准确度方面就这些详细信息达成一致。这些条件需要用户和开发人员之间的协作环境。

 最佳使用方法是敏捷，因为它需要高度的创造力和创新才能产生解决方案。

 要准确应用此模型，必须了解组织内部的动态力量，其愿景，未来战略以及所在市场中的地位。

 该模型本身非常易于应用，并评估Agile是否适合您的组织。最重要的是，你做了一个非正式的决定，这正是这篇文章旨在存档的内容。

 

原文：https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba/

本文：http://pub.intelligentx.net/why-stacey-matrix-model-can-help-you-understand-applicability-agile-your-organisation

讨论：请加入知识星球或者小红圈【首席架构师圈】

stacey复杂性模型将任务分为四个不同的类别：简单，复杂，复杂和anarachy。然后，该模型为每个类别解释了解决这些任务的最佳方法。

你有没有听过“什么是敏捷？”这个问题，而且你的头顶没有正确的答案。或者有人告诉你，敏捷是来自软件开发世界的东西。然后我想向那些人解释并不容易，敏捷是一种工作方法，它不仅适用于软件开发部门。我想我有一个很好的图解释，对于哪种类型的任务，敏捷的工作方式是最好的。

几个星期前，我在LeaseWeb的公司参加了一次伟大的Scrum大师培训。议程上的第一个项目之一是Stacey复杂性模型，它可以帮助您了解项目中的不确定性。

好的，这就是 -  Stacey的复杂性模型

在此模型中，您有两个维度：

需求的不确定性：

这表明您的需求是确定的（或不确定的）以及需求在未来发生变化的可能性。基本上，这个维度说明了你必须做什么或建立什么的不确定性。

技术的不确定性：

第二个维度显示了您的方法或技术在完成任务（或构建应用程序）方面的不确定性。因此，它表明您构建项目的不确定程度。

我自己没有制作下面的图表，这些作品归于一个名叫Jurgen Appelo的荷兰人和他的博客（http://noop.nl/2008/08/simple-vs-complicated-vs-complex-vs-chaotic.html）。他是我现在读的一本好书的作者 - 管理3.0。

四类

在Stacey复杂性模型中，有四个类别：简单，复杂（complicated），复杂（complex）和无政府状态。让我们详细讨论每个类别：

简单的任务

简单的任务定义明确且易于解决 - 您确切地知道您必须做什么以及如何做到这一点。

此类任务的示例是“刷牙”或“骑自行车”。你每天都这样做（至少在荷兰），你不必考虑它。您为此类任务选择的方法是“Just do it！”。

复杂（complicated）的任务

复杂的任务不再简单（huhu  - 是的，真的！） - 就你必须做什么以及如何做而言，它们并不完全清楚。

该类别任务的一个示例是“计划您的假期到拉丁美洲”。这不再是直截了当的了。解决此类任务的方法是坐下来，想一想你想做什么以及如何做 - 所以你制定计划，当你的计划完成后你就会执行它。

无政府状态

让我们暂时跳过一个类别，让我们看看规模的另一端 - 无政府状态。在这里，我们无法预测任何事情，我们也不知道如何处理事情。

这里最好的例子是自然灾害，如海啸或火山喷发 - 我们不知道，将会发生什么，什么时候会发生以及它会产生什么影响，我们也没有任何线索如何防止它。

处理无政府状态类别的任务并不是一个好方法。如果你在日常工作中遇到这样的任务，那么我真的很抱歉，因为要么你有这么艰难的工作，要么你是悲观主义者。

复杂（complex）的任务

现在让我们来看看Stacey复杂模型中的大类：复杂的任务。他们在你必须做的事情以及你想做什么方面存在很大程度的不确定性。

有很多例子，例如软件项目通常属于这一类。这些要求从一开始就不明确，在软件构建过程中也会发生很大变化。此外，技术还没有完全清楚 - 你从一开始就不知道如何处理某些问题，事实上，你甚至不知道你将遇到什么问题。那么如何处理这类问题呢？你选择什么方法？

模型的简单性

我想，如果你要向那些与软件开发或敏捷无关的人解释这四个类别，然后问“你如何解决复杂类别的任务？”那么他或她就能想出来他/她自己的答案。这就是我从听到它的第一刻起就非常喜欢Stacey复杂性模型的原因。

答案很敏捷

显然，答案如下：您坐下来制定一个计划，了解您想要实现的目标以及您将如何实现目标。然后执行计划。一段时间后再次坐下来，重新检查您的计划是否仍然有效并相应地进行修改。当您调整计划，新的或变更的要求，更好地理解可能的解决方案，获得使用过的技术等知识时，您会考虑所有新的输入因素。然后执行适应的计划。之后，重复计划和执行阶段，直到项目完成（或者直到项目结果足够好，停止工作并继续另一个更重要的项目）。所以，基本上你在迭代中工作 - 为每个迭代创建一个新的计划，同时考虑新的和改变的输入因子，然后执行它。

解释敏捷是什么的好方法

不同意，这是一个很好的方式向另一个部门的利益相关者解释，他不了解敏捷，敏捷方法论的全部内容是什么？ - 应对变化！我向使用这个模型的两个非技术姐妹中的一个解释了它，我认为它非常好。至少她告诉我，她明白，但也可能是这样，她只是想让我闭嘴。

让我知道，如果Stacey复杂性模型帮助你向另一个人解释敏捷。或者给我留言，如果你认为这个模型根本没有帮助向你的奶奶解释敏捷。

 

原文：https://www.scrum-tips.com/2016/02/17/stacey-complexity-model/

本文：http://pub.intelligentx.net/why-agile-stacey-complexity-model

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

关键的要点

1. 许多组织都对敏捷感到厌倦
2. “敏捷工业综合体”是问题的一部分
3. 敏捷者必须回到宣言和12个原则的基础和简单
4. 敏捷和现代敏捷的核心是基本的、简单的框架
5. 敏捷者需要从社会科学中学习很多东西，比如积极心理学、欣赏式探究和解决方案聚焦

敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷。

一个咒语吗?不完全是，尽管它可能会引起意识状态的改变。

“生命、宇宙和一切终极问题的答案?”(道格拉斯·亚当斯，《银河系漫游指南》)。也许吧，这取决于你问谁。

 

这些都是同音异义词。看起来和听起来一样但意思不同的单词。就像这句语法正确的句子是由三个完全不同的单词组成的:“Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo Buffalo”(Dmitri Borgmann, Beyond Language: Adventures in Word and Thought)。

过度同音化的风险在于，单词开始意味着一切，直到它们变得毫无意义。这是一种被称为“语义饱和”的心理现象。由心理学家Leon James创造的“语义饱和”是一种精神疲劳:

叫做活性抑制:当一个脑细胞火灾、第二次火,需要更多的能量和更第三次,第四次,最后甚至不会回应,除非你等待几秒钟……如果你重复一个词,这个词的意义不断被重复,然后就耐火材料,或者更耐引发了一次又一次。

今天，“敏捷”意味着一切。渐渐地，它就毫无意义了。许多组织对“敏捷”感到厌倦和难以驾驭，或者抗拒“敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷。”

它变得更糟。“当话语失去意义时，人们就失去了自由”(孔子)。在一些组织中，“敏捷”已经成为“命令和控制管理”的意思。肯特·贝克(Kent Beck)道出了许多更了解情况的人的沮丧:

我在南非参加敏捷非洲时，有人找到我，对我说，‘我们想做软件开发，但我们实在无法忍受所有这些仪式和敏捷的东西。我们只是想写一些程序。“我热泪盈眶……怎么可能又回到了20年前的样子呢?”(私人信件，经允许引用)。

这是一个很重要的问题。并提出了其他重要的问题，比如“我们将何去何从?”“罗恩·杰弗里斯最近提出了一个非常现实的可能性:

是时候尝试一些新的东西了，这里是:开发人员应该放弃“敏捷”……我真的开始认为所有类型的软件开发人员都不应该坚持任何类型的“敏捷”方法。当这些方法在实践中表现出来时，它们通常是好的软件开发的敌人，而不是朋友。

无论我们从这里走到哪里，让我们首先承认，我们中的许多敏捷者是问题的一部分。正如Pogo对Porkypine说的一句名言:“我们遇到了敌人，他就是我们”(Walt Kelly, Pogo)。Martin Fowler在Agile Australia 2018大会上这样说:

敏捷工业综合体强加给人们的方法是完全的歪曲。我本想说“悲剧”，但我认为“歪曲”是更好的词，因为最终在软件开发中没有放之四海而皆准的标准。即使是敏捷的拥护者也不会说敏捷一定是在任何地方都能使用的最好方法。关键是，团队的工作决定了如何去做。这是敏捷的基本原则。这甚至意味着，如果团队不想以敏捷的方式工作，那么敏捷可能在这种情况下是不合适的，并且(不使用敏捷)是他们在某种奇怪的、扭曲的逻辑世界中能够做事情的最敏捷的方式。所以这就是第一个问题:敏捷的工业综合体和这种强加的一种最好的做事方式。这是我们必须反对的。

敏捷工业综合体。黑暗的敏捷。假的敏捷。僵尸敏捷。更糟糕的是。一位组织心理学家朋友这么说:

敏捷是一种病毒，在整个企业中蔓延。你不应该对不断增长的阻力感到惊讶。因为这是当抗原入侵时抗体的自然反应。(个人信件)

嗯?

这就是它的感觉:入侵。因为您的业务转换“专家”对组织动力学和变化心理学的了解少得惊人。一个明目张胆的例子:当你宣布某人为“大师”时，你意识到你会立刻在多个层面上制造多少阻力吗?特别是当他们唯一精通的是一个为期两天的训练活动!(出处同上)

哦。我不敢告诉她“教练”也是经过两天的训练后才宣布的。我最近听到其中一个“教练”问，“必须有一个非常好的项目经理才能使敏捷工作吗?”

“是的，一个一流的项目经理、迭代经理、Scrum Master，不管你怎么称呼他们，他说话温和，但手里拿着一根大棒!”

泪水涌上了我的眼睛。

我的一个客户在探索了广阔的认证领域后，创建了自己的认证。许多Scrum管理者和产品所有者都在他们的工作空间里自豪地展示着它:敏捷雅虎。

我们将何去何从?

 

内部政策——敏捷世界内部

国内政策是一个广泛而全面的战略，或者是一个具体的计划，甚至是一个管理国内事务的简单原则。

在敏捷扩展的时代——业务变革——让我们首先澄清一下“敏捷敏捷”的含义。

为了说明什么是显而易见的，这里有一个简单的原则:任何“敏捷”都必须明确或隐式地引用敏捷宣言的四个价值观和12个原则(https://agilemanifesto.org)。它必须包含敏捷的“线索”。

我们必须回到未来，回到根本，回到根本。敏捷需要重新启动。“敏捷”团队应该定期回顾宣言和12条原则:这意味着什么?我们做得怎么样?我们如何才能继续朝着这个方向前进?

它的部分含义是，如果我们自己的“敏捷”实践想要保持敏捷，就需要不断地修剪它们。“简单是必要的”(12条原则)是敏捷的“线索”，我们必须喝自己的Kool-Aid。

戴夫·托马斯说，其实很简单:

找出你在哪里。朝着你的目标迈出一小步。根据所学内容调整你的理解。重复。

类似地，Alistair Cockburn的敏捷核心是一种基于简单框架的不可知论方法:协作、交付、反映和改进。Joshua Kerievsky的现代敏捷基于四个简单的原则:让人变得优秀，把安全作为先决条件，快速地试验和学习，持续地交付价值。

外交政策——敏捷世界之外

外交政策是一项广泛而全面的战略，或者是一项具体的计划，甚至是一项处理国外事务的简单原则。

在敏捷扩展的时代——业务变革——让我们第二，阐明我们“敏捷敏捷敏捷”的意图。

当像敏捷者这样的群体扬帆远航到其他地方时，文化不可避免地会发生冲突。

早期敏捷探险的特点是炮艇外交。例如，我们对项目管理的征服已经接近完成。

现在，我们遇到了一些奇怪的新领域，比如人力资源，还遇到了一些被称为组织心理学家的人，他们的证书比我们还多。

我们的外交政策是什么?我们认为自己是掠夺者还是商人?

让我们警惕一种天真的、最终会自我毁灭的殖民主义，它假定我们是优越的，为了他们自己的利益和我们的利益，当地人需要被教化。

相反，让我们小心我们自己的同化，就像曾经可怕的维京人消失在传说的迷雾中。例如，我是世界各地不断增长的将敏捷与积极心理学、欣赏式探究和以解决方案为中心的简要疗法相结合的敏捷运动的一部分——参见我的关于以解决方案为中心的敏捷的文章(http://sfio.org/journal/inter- vol-10-no- 2-janu-2019/page-5/)。与此同时，越来越多的“敏捷者”完全放弃了“敏捷”，因为他们完全被其他世界同化了。

我们整个企业的外交政策不是朝着一个大熔炉，而是朝着一个混合沙拉的方向努力。

一个简单的冲突解决矩阵说明了这种方法(从这里改编)。我们的立场不是竞争(敏捷赢了)，也不是适应(敏捷输了)，而是合作(业务赢了)。

 

这是美第奇效应的一个例子。弗朗斯·约翰逊(Frans Johansson) 2006年的著作《美第奇效应》(The Medici Effect)对我的思维产生了革命性的影响。美第奇效应(The Medici Effect)以14世纪意大利一个家庭的名字命名，这个家庭引发了欧洲的文艺复兴。美第奇效应指的是在不同学科、文化和行业的交叉碰撞中产生的突破性思维和颠覆性创新。这个想法引起了我的共鸣，因为我从小就在做大爆炸实验。

美第奇效应回答了我偶尔被问到的一个问题:为什么我很少参加敏捷活动?敏捷社区很重要。但是美第奇效应促使我不断地超越我所知道的人和事的界限。我很快发现，对我来说，启迪和突破更多地是由与军官、宗教领袖、诗人、哲学家、生物学家和心理学家的互动所激发的。我一生的大部分工作都是将这些相关的，有时是不相关的学科之间的点连接起来，并尝试新的和不同的工作方式。

结论

跨学科研究、原则和实践是敏捷的未来。这使得我们与我们的根保持联系变得更加重要，只要我们继续使用“敏捷”这个名字。请不要再说“敏捷、敏捷、敏捷、等等”之类的话了。

 

本文：https://pub.intelligentx.net/node/808

讨论：请加入知识星球或者小红圈【首席架构师圈】或者飞聊【首席架构师智库】

 

软件（和产品）开发从来都不是一件简单的事。对于运行了几天并且只涉及少数人的项目，可能会保存。绝大多数项目很容易被认为是复杂的。 “复杂”是指：太多的变量和潜在的（紧急）交互，可靠地预测（近）未来。然而，我们似乎遭受了强大的认知偏见，这使得我们的折扣复杂性与诸如“它不能那么难”，“我们之前已经做过”以及“我们已经非常清楚要做什么”这样的陈述。我经常遇到那些觉得他们的'项目对Scrum来说不够复杂'的人。我坚信这些人是从对复杂性的非常有限的理解中推理出来的。在这篇长篇大论中，我提供了几个模型和框架（如Stacey和Cynefin）来帮助理解“复杂性”并更好地理解为什么Scrum（或其他迭代框架）确实是最好的方法。

扔掉你的计划？

大多数人仅仅通过“了解创造什么”来理解“复杂性”。以最近告诉我他的项目并不复杂的经理为例，因为它涉及重建现有（大型）应用程序。但“知道要创造什么”只是其中一个因素。在我们的专业Scrum硕士培训期间，我们总是要求参与者集思广益，尽可能多地影响项目成功的因素。我们只需几分钟就可以完成这项练习。即使在这种限制范围内，我们也总是设法快速填满整个活动挂图。我敢肯定，如果我们花一整天时间进行这项练习，我们可能会填满整个墙。

为了让您了解人们的想法（最重要的）：

1. 沟通风格和技巧
2. 组织内的授权和支持
3. 团队的技能水平
4. 明确的目标和/或愿景
5. 开发人员的技术技能
6. 涉及的人数
7. 组织文化
8. 知识共享
9. 处理
10. 股东和股东的可获得性
11. 参与客户和/或最终用户
12. 工具
13. 市场的波动性
14. 时间管理技巧
15. 流
16. 动机
17. 时间因素（如项目运行多长时间）
18. 现有代码库（质量，规模，知识）
19. 与重要组成部分供应商的关系

“通过让人们花费宝贵的时间来创造它们，阅读它们并使它们保持最新”，计划是仪式化过程浪费的重要来源。

这个清单上有一些巨大的因素。像组织文化，目标清晰度和技能。您如何能够预先预测这些因素在项目期间将如何表现，以及它们将如何相互作用？现实情况是，面对这种不可预测性，制定计划没有任何价值。通过让人们花费宝贵的时间来创造它们，阅读它们并使它们保持最新，计划是仪式化过程浪费的重要来源。这并不是说我们不应该花时间思考我们将要做什么。我们应该以符合复杂性的方式来做。正如艾森豪威尔所说：

“计划毫无用处，但计划是不可或缺的。” - 德怀特·艾森豪威尔

几个框架可以帮助我们确定哪种方法适合某种程度的复杂性。我将描述最知名的人; Stacey矩阵和Cynefin框架。

关于复杂程度的简短说明

我们将在下一段中谈论很多关于活动的内容。活动发生在不同的层面，从开发新产品（大型）到将列添加到表（小型）。这些活动属于不同的复杂领域。这意味着所有领域或复杂类型可以同时存在，但在不同层面上。这篇文章是在考虑产品或项目级活动的情况下编写的。

斯泰西矩阵

理解复杂性的一种方法是通过由Ralph D. Stacey（管理学教授）开发的Stacey矩阵。多年来，该模型已经以多种不同的形式呈现，但它主要表明复杂性是对所需内容（“什么”）达成一致程度的函数，以及我们如何达到目标的确定性（'怎么样'）。

Stacey Matrix的开发旨在帮助管理者确定其环境的复杂性并调整其决策风格。对于软件开发，Matrix通常沿不同的轴绘制; '要求'和'实施'（或'技术'）。前者取决于我们知道我们需要构建什么的显而易见性（如产品）以及要实现的功能（'什么？'），而后者则取决于实现目标所需的显而易见性。实施/技术条款（'如何？'）。应该指出的是，这种改编并不适合Stacey的原始Matrix。但它确实提供了一种类似的概念方法来理解软件开发环境中的复杂性，以及使用的方法：

简单：

当显而易见的需要以及如何到达时，活动是“简单的”。根据现有的传单或宣传册开发一个基本的1页网站。所需要的东西（'数字化传单'）和如何到达那里（'一些html / css来复制样式'）是显而易见的。最有效的方法最好总结为“只做它”。采取现有的“食谱”或“最佳实践”，应用它，你就完成了。不需要计划，也不需要像Scrum那样的经验框架;

复杂（Complicated）：

如果不清楚需要什么或如何到达那里，活动就很复杂。我经常使用网上商店的例子来购买新类型的产品。这里的实现非常明显，可以通过大量现有的网上商店模块（如Magento或WooCommerce）来回答。但如何最好地展示和推广产品将不那么明显。另一个例子是连接两个系统以交换特定类型的数据。这里显而易见的是（'连接系统'），但实现不太明显（'我们如何映射数据？我们使用什么机制？'）。对于复杂的环境，很难确定一种最佳方法。一些作者表示，计划的方法（分析，设计，执行）可以在这里工作。但根据我自己的经验，我会说迭代方法仍然优于计划方法。虽然复杂性在这里肯定是有限的（对于两个轴中的一个），但仍然有很多未知数。迭代方法提供了一个过程，可以帮助在需要时更快地发现它们并纠正过程;

复杂（Complex）：

当需要的东西和如何到达目的不明显时，活动被认为是复杂的。变量之间的相互作用变得过于复杂，无法准确预测，这使得详细的前期计划毫无意义。而不是试图预先控制和预测活动的流动，更有效的方法是使用“经验过程”。在这些不可预测的环境中，用于决策的最可靠信息是基于已经发生的事情（而不是我们预期会发生的事情）。因此，我们应该采取小的渐进步骤，使用每一步来确定我们是否已经接近解决问题或远离它。 Scrum是这种过程的一个很好的例子;

混乱：

右上角是为一切都在变化的活动保留的。在这些环境中，即使过去也不再为决策提供可靠的信息。如果是大型应用程序的服务台或托管环境的主要中断，这是一个很好的示例。这里最好的方法是“分诊”：优先处理问题，首先解决最紧急问题，然后从那里继续进行（冲洗和重复）。虽然迭代方法仍然是一种有效的方法，但步骤需要更短。认为短期冲刺的Scrum或具有低工作进度限制的看板;

通常添加到模型中的第三个轴（不是Stacy本人）是涉及的人数。这个想法是复杂性随着从事活动的人数的增加而增长。对于一个人来说简单的任务对于一个人来说可能非常复杂。选择要观看的电影很容易，但是对于一群朋友来说，它可能变得非常复杂。

Stacey矩阵的局限性

 

1. 有趣的是，Ralph D. Stacey已经放弃了矩阵作为理解复杂性的手段。他的主要原因是他现在认为所有活动在某种程度上都是复杂的。即使是最简单的活动也会因为纯粹的（坏的）运气而变得复杂。
2.  
3. 矩阵的第二个问题是，对矩阵的简单解读可以得出结论，即可以通过足够的智力来降低复杂性。如果我们只是花了足够的时间来讨论需要什么，以及如何实现目标，我们最终会将一个非常复杂的问题变成一个简单的问题。换句话说，Stacey矩阵可以用来推断我们只需要在复杂或复杂的环境中进行更广泛的规划和准备。但这与斯泰西试图用他的模型做出的观点相反。
4. 第三个问题是该模型仅将“协议”和“确定性”视为引入复杂性的因素。但是还有许多其他因素会引入复杂性，例如沟通，相关人员的技能，组织文化和纯粹的机会。

Cynefin框架

Cynefin是一个感觉制作框架，由Dave Snowden（IBM）于1999年开发，旨在帮助领导者和管理者了解他们所处的情况并采取行动。他后来用Cynthia Kurtz（2003年）对其进行了改进（2003年） ）。该模型后来被敏捷社区采用，以更好地理解和解释为什么敏捷和Scrum非常适合软件开发。虽然它看起来比Stacey Matrix更复杂，但它确实提供了一个概念上更强大的论点。

简单地说，Cynefin框架确定了五个复杂的领域，这两个领域是完全不同的。最简单的形式是，框架指出有四种方法可以理解“未知”。每个域都有自己的方式来理解这种情况，需要采用不同的方法来实现有效和不同的管理方式。虽然Cynefin框架通常以2x2模型的形式呈现，但象限下没有维度轴。

显而易见：

当问题得到充分理解并具有明确的既定解决方案时，活动就很明显。因此，诊断问题并找到解决方案不需要专业知识和技能。最好的方法是使用“最佳实践”：诊断情况（感知），将问题分类到正确的“桶”（分类）并应用与该桶相关的最佳实践（响应）。例如，遵循频繁执行部署的清单或使用调用脚本的呼叫中心。在这个领域最有效的管理方式是协调：确保人们知道该做什么以及如何做;

复杂（complicated)：

诊断问题时，活动很复杂，找到一个好的解决方案需要专业知识。需要专业知识和时间来提出正确的问题（“已知的未知数”）并得出问题的诊断结果。一旦知道，就需要专业知识来选择一组有限的解决方案。最好的方法是使用“良好实践”：诊断情况（意识），分析问题（分析）并确定和应用计划的行动（响应）。一个例子是解决应用程序中的错误或连接两个API。最适合此类活动的管理方式是合作：与专家合作;

复杂(complex)：

当问题和解决方案都是未知的时，活动很复杂。在这些情况下，即使找到要问的正确问题也很困难（“未知的未知数”）。理解问题和找到解决方案都需要积极的实验，直到模式开始出现。尽管可以预先预测总体方向，但实际解决方案在找到之前并不明显。最好的方法是积极发现模式（'紧急实践'）：尝试从环境中收集反馈（探测），分析反馈（感知）并回答另一个实验，直到您到达'复杂'域。最适合此类活动的管理方式是共同努力寻找最佳解决方案（协作）;

混乱：

当问题和解决方案都未知时，活动是混乱的。这是一个临时状态。随着时间的推移，约束和结构将自然出现（即使你没有强加主题）。这方面的一个例子是当一个大型网络农场发生故障或发生自然灾害时。几乎没有时间思考，所以专注于找到有效的东西而不是寻找最佳解决方案。最好的方法是应用“分类”：快速确定优先级并解决问题的一部分（行为），分析情况（分析）并继续下一个优先问题（响应）。最适合此类活动的管理方式是立即采取行动，提供清晰直接的沟通和恢复顺序，以将复杂性降低到“复杂”域。 ;

无序：

框架中心的域保留用于未知复杂域的活动。斯诺登添加了这个领域，强调我们必须首先理解环境，使用可用的数据和信息来确定复杂性的类型。如果没有这样的数据或者没有意义，活动仍然是“无序”。这里的首要任务是确定活动属于哪个域。然后使用适合该域中活动的方法。这也强调复杂性不是活动的某些“客观”属性;这是感觉制作过程的结果;

知识，界限以及Scrum适​​合的地方

Cynefin框架的一个关键因素是知识。我们对情况的理解有助于使问题和解决方案更加明显。对每个域使用推荐的方法（探测 - 响应 - 响应等），我们基本上帮助自己更好地理解问题。这有助于我们过渡到复杂的“低级”领域。

假设我们遇到的问题完全出现在“Chaotic”域中，就像以前没有发生过的大型企业应用程序的重大中断一样。我们没有时间坐下来思考最佳解决方案，因此我们必须对情况进行分类并确定要采取的第一步。优先级最高的第一个低工作级看板流程可以在这里提供帮助。这最终会将问题转移到“复杂”域中。

根据Snowden的说法，Scrum本质上是一种从“复杂”域转变为“复杂”域的方式。通过将一个大问题（如开发新产品）分解为许多较小的问题（短跑或甚至单个PBI），我们最终会降低较小比特的复杂性。

因此，通过调整我们的行为，我们可以增加对情况的理解。这有助于跨越边界转换问题（顺时针方向），从混沌到复杂，从复杂到复杂，甚至可能到简单。当知识丢失或未正确应用时，会发生相反的情况。一个例子是部署复杂的应用程序。手动完成后，活动很容易变得复杂甚至混乱。但是当部署大量自动化时，它可以成为一个简单的活动。底部的小“折叠”或“悬崖”代表了从“明显”直接回归到“混沌”的可能性。当现有的最佳实践过时但仍继续应用时，就会发生这种情况。或者，当负责维护关键应用程序的人员离开公司而不转移知识时。下一次重大问题发生时，人们将争先恐后地解决“混沌”问题。

从这些模型中得出的最重要的教训是，软件开发至少是“复杂的”，可能是“复杂的”，偶尔会在产品或项目层面上“混乱”。当对所需的最终状态（问题）没有明确的理解并且没有明显的方法（解决方案）时，需要一种迭代方法来帮助澄清问题和解决方案。无论我们用多少脑力来预测未来，影响我们工作成功的大量因素使得这些预测几乎毫无意义。因此，在非简单环境中使用计划方法很可能会导致您解决错误的问题或应用错误的解决方案。

在复杂的环境中，为我们的未来决策提供信息的最佳信息来源不在于对未来的预测，而在于已经发生的事情。这意味着需要一个经验的迭代过程。就像科学家如何测试科学理论一样，或者发明家如何通过渐进式原型逐步完成工作直到达到工作模型。需要经常检查不断变化的“当前状态” - 正在解决问题的各个方面 - 以增加我们对问题和解决方案的理解，并为我们未来需要的决策提供信息。通过将较大的问题分解为许多较小的问题（冲刺），我们基本上从“复杂”转变为“复杂”领域。

如果没有清楚地了解所需的最终状态（问题）并且没有明确的联系方式（解决方案），则必须采用迭代方法来澄清问题和解决方案。

那么Scrum呢？

实际上，Scrum是一个提供这种经验过程的框架。这正是Scrum不是“方法论”的原因。方法论是一套完整的原则，但Scrum（仅）为应用于软件开发的经验过程奠定了基础。这需要透明度，检查和适应性。 Scrum需要实施五个Scrum事件，以最大限度地提高透明度，允许检查并促进适应。未实施这五项活动中的一项严重限制了我们为未来做出决策所需的反馈质量。 Scrum绝不是唯一的选择。但它是一个非常受欢迎的选择，拥有大量的从业者社区。如果这篇文章说服你的项目可能需要经验方法，那么试试这个是一个很好的理由。

更新（2017年3月23日）：Dave Snowden回复了Twitter上的帖子。他强调Scrum有助于从复杂问题转变为许多复杂问题（将工作分解为冲刺，然后分解为PBI）。混沌域中的类似Triage的过程有助于将问题从“Chaotic”转换为“Complex”。我已相应更新帖子，感谢Dave的个人意见！

参考

• Snowden, D. J. & Boone, M. E. (November 2007). “A Leader’s Framework for Decision Making”. Harvard Business Review, 69–76. PMID 18159787;
• Snowden D. J., & Kurtz, C. (2003) “The new dynamics of strategy: Sense-making in a complex and complicated world”, IBM Systems Journal Vol 42 No 3, 2003;
• Stacey, R. (1996). “Complexity and Creativity in Organizations”. ISBN: 978–1881052890;

原文：https://medium.com/the-liberators/on-complexity-why-your-software-project-needs-scrum-13c36305c866

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

如今，几乎所有 IT 公司都存在敏捷项目管理。 2001 年，开创性的敏捷宣言 (agilemanifesto.org) 诞生了。在过去的 20 年里，这种思维方式发生了很大变化。是不是变得更好了？

根据项目管理协会 1 的数据，超过 70% 的公司采用了敏捷方法，敏捷项目的成功率比传统项目高 28%。大概，您还知道敏捷流行的原则，这些原则是由 Scrum 框架培养的。在做项目时，这种转变需要不同的方法。在本文中，我想重点关注根据 scrum 的细化，它是 sprint 中一个持续的过程。创建、完善和完善产品待办事项的过程。基于我作为前业务和系统分析师以及现在作为解决方案架构师的工作经验，我分享了我的知识，这些知识简单有效，并解释了一些有趣的观察结果。那么，细化在实践中意味着什么？ Scrum 建议如何符合现实？哪一方反映了这种体验——纯粹主义者还是实践者？如果您想知道答案并养成进行有效改进的习惯，请舒适地坐着并继续下一段:)。

在解释了这些先决条件之后，我们将继续前进。我即将从不同的角度来看待细化。对立的两个方面是技术方面>所以我们，技术人员如何在这个细化的基础上玩耍，另一方面，这确实是一种商业观点。

让我们从冲刺时间的观点开始。

一开始，作为一名架构师，我需要确保所有计划好的故事都被明确定义，并且对冲刺的分析已经完成。在两周的冲刺中，应该不会超过 2-3 天。与此同时，业务团队有时间在内部开会并集思广益，讨论即将到来的 sprint 的要求——在我的例子中，他们定义了用户故事和验收标准。然后，我组织了一个预先计划会议，在会议上，企业知道接下来 1-2​​ 个 sprint 的范围，我与产品负责人一起确定优先级和次序。通常，这次会议让我对应该交付的内容有一种高层次的感觉。

完成后，我可以专注于用户故事并将需求分解为更小的部分。有时它发生在同一次会议上，但很难集中注意力超过 90 分钟。这真的很耗费脑力，所以最好的主意是在第二天组织一次单独的会议。

当第一批需求准备就绪时，我与开发团队组织了第一次评估会议（记住——根据新的 scrum 指南，它是开发人员团队），持续时间最长为 60 分钟。细化的结果是估计会议的输入。这不仅给了我估计分数（我的案例中的故事点规则基准），而且我还征求了开发团队的第一批反馈——我忘记问的问题，业务应该澄清。在冲刺的中间，架构师应该处理在预计划会议中讨论的需求。理想情况下，在第一次评估会议的 2 天后，应该进行第二次评估会议。这足以让我准备另一块业务需求。

现在，我们正处于 sprint 的第 7-8 天。双周冲刺有 10 个工作日（包括 Scrum 仪式 1 天）。最后，我需要确保整个范围都已交付并经过良好测试。为了实现这一点，我一直与开发团队保持沟通，并对当前的目标和障碍做出反应——这是我在听每日 Scrum 仪式时的目标。然后，在 sprint 的最后一天，我帮助产品负责人选择范围并接受下一个 sprint 的计划，这样计划会议就容易一点。哪些需求是经过细化和估计的，哪些不是。有时，产品负责人坚持要求您就用户故事达成一致，但这些故事并未做好充分准备——但请记住，最终是开发团队在计划会议期间决定他们是否就 sprint 范围达成一致。平衡这一点至关重要，因为当企业做出决定时，我的意见非常重要。

上述时间表对于团队来说可能是一个很好的起点。我总是从遵循这些规则开始，然后根据环境调整计划。我永远不会忘记预先安排定期举行的会议，以便我和我的团队遵循相同的节奏。产品负责人的日历通常充满约会，因此它也有助于计划一周。

现在，当涉及到与 sprint 时间相关的主题时，我想深入探讨并作为与开发人员打交道的技术人员讨论上述改进。然后，我们将继续前进，我们将戴上与商务人士打交道的人的眼镜。

从团队开始，如果我知道团队不仅充满了自我管理的专家，而且还包括一名测试人员，我就放心了。如此简单，如此真实。一名质量保证人员应该能够测试最多 6-7 名开发人员的工作。在我的例子中，给定 6 名开发人员和 1 名测试人员的团队，当 QA 工程师从团队中移除时，整体 sprint 效率下降了 20%，因为需要其他人来接替他的职责。开发人员和产品负责人充当测试人员，通常没有足够的时间来做这件事，应用程序的质量立即下降。我只想指出，在一个削减成本的团队中，当客户开始认为减少团队可能是一个好的决定时，我付出了很多努力来说服他们不要这样做，因为这绝对是不会还清。感受到持续的压力也会影响团队在日常合作和改进中的行为。开发人员应该做他们的工作，测试人员应该做他们的工作，而我应该做我的工作。因为团队需要 Scrum Master 而将业务分析师转换为 Scrum Master 角色也不是一种选择。不幸的是，我看到这种情况发生了，士气很快就暴跌了——在团队感觉不那么投入并成为工人而不是被聘用的顾问之后不久。

在细化期间有一个小备份怎么样？好点子！你知道“tres amigos”吗？众所周知的实践“tres amigos”是分析的补充方法。它从三个不同的角度来看待需求——业务、测试和交付。它促进了对将要交付的未来增量的共同理解。简单地说，我们可以制造出质量更好的产品。但它不必仅限于三个人。如果我知道在讨论范围内至少有一个与用户界面相关的故事，我也会邀请一位前端开发人员。如果我知道我们将讨论业务逻辑，我还会将一位后端开发人员列入我的邀请名单。为什么？因为：

当然，也可以邀请任何其他人来加速改进过程——Scrum 旨在改进，因此任何事情都可以在回顾会上讨论并在下一个 sprint 中实施，看看另一种方法是否能产生更好的结果。然而，我始终记得将每个必要的观点包含在尽可能小的群体中。我的职责是使分析和架构保持最新。很难“即时”更新分析。我注意到所有必须做的事情。当然，我并不孤单。我将所有“待办事项”指向团队并就职责达成一致——这类似于明确角色分配的问题。例如：他们（业务）更新 JIRA 中的验收标准和需求描述，我更新分析、图表、用户界面和我们保持融合的所有其他内容。

JIRA 中的任务应该链接到汇合页面以便于导航——轻松访问技术、业务分析或用户界面线框非常有帮助。我在 Confluence 上保留了一个直观的页面树，以便有效地浏览内容。说到 JIRA，“IN REFINEMENT”、“REFINED”、“IN BACKLOG”等状态可能会使项目更易于管理和控制。对于团队成员来说，因为他们可以更透明地表达他们当前的状态并管理他们的日常任务，而对于利益相关者来说——因为图表和统计数据更加准确。

我遵循图纸比文字表达更多的原则。它不需要是普通的 UML，但它需要每个人都容易理解。我绘制序列图来显示流程的顺序和组件的职责。对于开发人员来说，当谈到新的集成点时，它是最有趣的工件。每个组件的通信顺序和输入/输出数据帮助我将分析质量保持在高水平。更重要的是，我绘制状态机/活动图以更好地表达需求。此外，我会在每个 sprint 之后更新架构组件图——我不是唯一使用它的人。重点是不要害怕绘图——它既是需求分析，也是未来系统的文档。企业很快就会开始理解所有图表，效率也会提高——值得一提的是实践本身（我真的很喜欢我工作的这一部分:)）。

当我提到架构时，我想问你一个问题——你知道我们为什么要设计反映业务需求的经过深思熟虑的系统架构吗？我们不这样做是因为架构师想要遵循最新的设计模式。有效工作的系统架构也不是最重要的因素。架构师应该设计最好的（对于给定的情况）可能的系统架构，以降低维护成本并使系统易于更改。所有工作组件都应该足够灵活，以适应世界要求的步伐。我们调整得越快，我们获得的竞争优势就越大。另一方面，系统的代码越多，改变其行为的难度就越大。这就是为什么应该在项目一开始就建立开发原则的原因，因为最初不可能注意到一个糟糕的设计。值得一提的是，每一个捷径和变通方法都会有麻烦。客户推动交付更多更快的产品是很常见的。在这种情况下，我会解释这个决定对项目意味着的所有后果，并确保企业理解它们。这并不容易，有时他们会在冲刺之间改变主意。这就是系统架构应该尽可能灵活的原因，因为变化是开发过程的内在特征。尽管如此，不要让系统的每一部分都可配置——它应该成为讨论的主题，了解全局有助于做出正确的决定。如果团队不知道接下来几个月的计划是什么，我会要求提供路线图或帮助进行准备。这是对做出更好的架构决策的巨大支持，这些决策将在未来符合其他系统组件。此外，开发团队了解上下文，这肯定会增加他们的参与度。

不仅上下文很重要，信任也很重要。当我给予自由并且团队成员实际上可以做出架构决策时，他们的动力就会增加。我也直言不讳地表达了我的观点，但我把最后的决定权留给了团队——它通常是有效的，而且决策就像我是一个决策者一样。信任使团队敬业。我永远不会忘记团队由专家组成。一个人不可能熟记系统的每一部分。他们的论点通常也是正确的。分享知识应该是一种日常实践。一个好的团队领导者可以发展团队并使其自给自足。当一切都像瑞士手表一样工作时，这是非常有益的。这也让我和团队的工作更加愉快:)。

在与开发者的合作反思之后，我想顺利地转移到商业环境中。

产品负责人是设定目标并接受评论中提出的增量的人。在更大的项目中，业务团队，除了产品负责人，由业务分析师、运营经理和其他人组成。他们都需要找到相同的节奏才能有效地合作——我也是。最好的办法是亲自与他们见面。我为定期出差做好了准备。如果不幸的是这是不可能的（原文如此！covid），请要求打开相机。在谈判过程中建立业务关系很有帮助。我的观点对企业绝对有影响，他们依赖于我的专业精神和经验。如果我真正关心和理解他人，决策会更准确。记住这非常重要的一句话：首先尝试理解，然后被理解。我的责任是让企业意识到后果。我从不让情绪变得更好——相反，我扮演专业人士的角色。此外，我解释了每个决策对应用程序级别的业务影响——只有这样他们才会知道如何适当地做出选择。我对任何问题和已确定的障碍完全透明。诚实很快就会得到赞赏——其他人会知道他们可以指望我。谁知道，也许多亏了这一点，我会避开即将到来的混蛋？

同样重要的是培养同理心并设身处地为用户着想。这有助于我提供尽可能好的前端。通常，利益相关者根据接口判断应用程序。如果我有足够的时间，我会准备不止一个用户界面线框图。显然，企业只需要选择一个，但我是一个积极主动、有爱心的团队成员。当每个人都看到草稿时，谈论功能会更容易。也许，我们会想出一个比最初计划的更好的想法。毫无疑问，可视化起着重要作用，尤其是在远程工作期间。

有效工作的另一个症状是在细化之前准备好用户故事。企业需要在亲自满足要求之前就要求进行内部会议。我并不是说头脑风暴不合适——确实如此！但是，让我们在单独的会议上这样做。我作为会议的主持人，遵守使细化更容易进行的规则。如果会议朝着错误的方向前进，我也会指导其他人。这就是为什么使用 scrum master 的知识和技术来培养良好实践的原因。当我创建会议时，我会提醒自己一个 GOAL 原则并在描述中写下：会议的目标——我想要实现的目标，目标——我想要如何实现目标以及议程——对会议参与者有用熟悉会议的细节和计划的长度。如果需要研究，我会使用尖峰，当我觉得讨论太长时，我也会使用时间框。应该准备好用户故事，这意味着应该写下验收标准并提供描述。这种方法给了我另一个机会——在会议之前发送与需求相关的主题和问题。这些提出的问题显示了分析中的差距并激发了讨论。如果会议结束并且问题仍然存在，我总是发送它们并推动答复。

我敢肯定，即使是分析中一个未回答的问题或差距也会在开发过程中反弹，我最终需要回答它。我试图让我的产品负责人养成定期审查验收标准的习惯——通常，产品积压是在项目一开始就创建的。当然，积压的项目也可能会发生变化，我的工作是确保所有项目都反映当前的业务需求。说到变化——如果在冲刺期间需求发生变化，我们应该如何行动？这是可能发生的最糟糕的事情，因为它会使开发人员的工作变得复杂。它影响了整个团队的士气——没有人愿意重复做同样的事情。如果发生这种情况是因为没有对某些事情进行足够的分析，我会吸取教训，在下一次会议上，我会更深入地研究这些故事。将故事拆分为更细化的部分可能会有所帮助。但是，如果发生这种情况是因为企业突然改变了决策——我会评估根据新协议交付某些东西所需的工作量。可以做一些小的调整，我表现出团队合作的迹象。然后，企业觉得我尽一切努力满足他们的需求。相反，他们感觉不到可以随时要求改变。如果某些事情已经完成，或者我需要牺牲其他故事来实施更改——我会要求创建另一个用户故事并在下一个 sprint 中进行计划。

当故事细粒度时，更容易避免此类事情。较小的故事也更容易测试。例如，我向业务部门展示了界面的第一个版本，以便他们可以验证他们在线框中看到的内容是否是已构建的。即使在开发过程中也可以测试算法——只需要求业务部门提供测试数据和预期输出——团队可以轻松地根据给定的输入运行算法。它节省了时间，我不需要手动测试所有场景。在时间紧迫的情况下——我建议更改范围。很高兴知道企业心目中的理想解决方案，但在这种情况下，我会验证哪些需求最有价值，哪些可能会被拆分并稍后交付。我写下所有协议，例如会议期间的笔记、错误报告程序等——它还可以节省时间。更重要的是，分析是未来文档的一部分。写得好在冲刺之后不需要任何更新。我把它写成最后的形式，这样我以后就不需要修复它了。

我认为是时候总结并得出结论了。

基本上，准备的用户故事越好，我花在改进上的时间就越少，这会遵循更精确的估计并意味着更容易的计划会议。花费在澄清上的时间更少，工作顺利进行。

很明显，我至少需要提前准备一个 sprint——我是计划会议的主持人。产品负责人只选择最终范围——我和团队正在详细规划工作。我尝试改进 2 个冲刺。为什么？它建立了团队的可预测性。这非常重要，因为它需要计划全年的功能——所以这提高了我在利益相关者眼中的质量。它还会影响团队的稳定性——团队的整体健康状况。

在规划会议期间，我也坚持要留出 15% 的 sprint 容量缓冲用于细化目的。据说它应该花费 - 或多或少 10% 的 sprint 时间，但复杂的项目需要更多时间。我所说的复杂是指当我们创建一个新产品时，一个新的流程或要求是不为人所知的并且被分解的。我们需要有足够的时间来讨论最底层的设计并澄清所有的歧义。这一次也帮助团队提高了团队技能的熟练度——他们互相学习:)。

拥有路线图或影响图显然非常有帮助。我平衡​​了我们在每个需求上使用了多少业务时间。没有必要专注于提前几周计划好的事情。我与业务和利益相关者沟通的方式也很重要——业务并不总是正确的。我应该有足够的勇气和技巧以友好的方式传达这一点。

有一个道理，一个正确答案怎么做细化？我想不是。没有结论——这个问题没有客观的解决方案。它应该是经验性的，基于团队的经验和利益相关者的情况。尝试实施你的想法——Scrum 旨在测试和调整！

原文：https://bluesoft.com/how-to-conduct-the-excellent-refinement/

本文：https://jiagoushi.pro/node/1839

挣扎是真的

为了在这个新的敏捷测试世界中生存和发展，必须全面了解敏捷的真正含义以及敏捷开发中不同的方法。这不是一件容易的事。敏捷不断发展，即使是最复杂的测试团队，它仍然很难跟上。

你将学到什么

了解哪些新兴的敏捷测试方法适合您的组织，以及测试团队如何通过使用这些新兴方法来应对通过BDD，TDD，ATDD，看板和Scrum的敏捷测试挑战而获益。

里面有什么

 

1. 定义敏捷测试的内容以及为什么它是敏捷方法的重要组成部分
2. 深入研究BDD，TDD，ATDD，看板和Scrum，探讨它们与瀑布式方法的不同之处
3. 使用BDD，TDD，ATDD，看板和Scrum方法的最佳实践
4. 敏捷测试运动的发展方向以及您需要了解的以保持领先地位
5. 转换到敏捷时需要考虑的十件事情

 

原文:https://www.qasymphony.com/landing-pages/agile-testing-methodology-ebook/

讨论请加 【数字化和智能转型】星球

我们正在进行的一系列关于敏捷方法的博客提供了对该方法及其对组织的影响的深入讨论。在本博客中，我们专注于敏捷团队中的协作。

大多数人在谈论敏捷内部的协作时会想到Scrum。 Scrum肯定是促成更有效协作的主要因素。请注意，我们将其称为一个促成因素; Scrum非常强调务实方面，而不是人为因素。在这篇博客中，我们的目标是突出敏捷中两个因素之间的联系。

Scrum

敏捷基于明确建立的时间框架内的迭代和协作软件开发的理念。这些迭代在Scrum中被称为“sprint”，这是最流行的敏捷方法。许多组织都应用Scrum框架，因为它相对简单，并且避免了开销。 Scrum组织的核心是一个多功能和自治的团队。每个团队成员都参与规划，暴露障碍和任务分配。 Scrum方法假设团队内部可以获得所有必需的知识，这反映在多功能和自治团队的想法中。通过这种方式，敏捷方法与传统的“瀑布式”方法完全不同，它们采用基于分工和“大设计前期”的线性，自上而下的方法。

敏捷软件开发发生在团队中，重点关注价值流。这与传统的项目管理方法（它们是IT失败的主要来源，与我们在另一篇博客中所论证的）完全不同。团队为每个sprint建立自己明确定义的目标，有时甚至是当天。目标是可以实现和现实的，因为团队成员自己将工作分成可管理的部分，并提供他们自己对这些任务需要多长时间的估计。由于固有的灵活性，务实的方法以及对任务的关注，团队成员共同努力实现共同目标。在每个Scrum团队中，都有一些定义明确的角色：产品所有者，Scrum主管和团队成员。

许多组织赞扬敏捷方法，因为他们的团队生产力提高了。如果方法在每个团队中正确应用，则情况确实如此。我们经常看到的是，许多应用该方法的组织很少关注团队中的人为因素，例如信任，动机，透明度，团队精神等。

根据Scrum的说法，任何关注计划，积压培训（优先考虑用户故事的会议），角色，职责，目标等的团队都将作为一个团队有效地协同工作。然而，一个重要的问题是，在缺乏相互信任的情况下，将很难取得进展。团队的成功不仅取决于方法的合理应用，还需要考虑人为因素。团队可以将Scrum的理性方面完美地执行，但最终，人类需要完成工作，因此关注这些人为因素同样重要。

人为因素

那么这些“人为因素”究竟是什么意思呢？考虑诚实，信任，团队成员的个性与作为一个整体的团队之间的平衡，勇气，勇气，领导力，发展，从错误中学习，变革管理，动力，同伴压力等等。从团队成员到团队成员，所有这些事情都会有不同的体验，并会对团队的成功产生影响。这些人为因素对于成功实施敏捷是绝对关键的。经验告诉我们，在敏捷框架内，关注和激发协作，建设性批评和持续改进至关重要，以确保从sprint到sprint的成功协作。

示例1：所需的空间和灵活性

敏捷团队通常由一些专业人员组成，他们从个人知识和技能的角度为最终结果做出贡献。预计这些专业人士将展现出一种开放和参与的参与，这自然意味着他们在团队合作中表现出色。每个专业人员都需要在结构化环境中拥有所需的空间和灵活性。当专业人员没有所需的空间时，他或她无法以最佳方式使用他或她的知识和能力。这反映了个人贡献者和贡献的可见性。许多团队成员/专业人员都在为此而努对许多敏捷团队来说，这是一个共同的挑战。

示例2：信任

在敏捷环境中，团队本身受到了很多关注。建立敏捷团队，并根据所需的知识，技能和经验将团队成员分配给团队。之后，工作将分配给各个团队和团队成员，以及具体目标。整个团队的建立和定义，但有时团队成员可能不会相互信任，因为误解，过去与同事的糟糕经历，焦虑等等。因此，团队成员可以作为个人而不是作为影响整个团队绩效的团队工作。通常，团队的结构受到很多关注，但对团队内部的情况没有那么多。就团队结构本身而言，这在成功和结果方面至少同样重要。

从这些示例中可以清楚地看出，成功的敏捷实现并不仅仅取决于建立正确的结构。人为因素也起着重要作用。 Scrum大师在改善人际互动和指导团队应用良好实践方面至关重要。他或她可以通过帮助团队制定一些黄金法则来实现这一目标。例如：敢于尽可能早地和频繁地分享。这是团队成员之间的合同，这将促进合作。此外，关于团队内部黄金法则的内部沟通非常重要。团队成员需要有空间来讨论他们在团队会议中的恐惧和错误。黄金规则是一种工具，可以帮助团队成员和Scrum管理员为这类会议提供便利。这是团队成员更好地熟悉Scrum方法的理想方式。

团队中的另一个关键任务是提供反馈，新成立的团队需要实践这一点。这将使团队成员有机会分享他们的个人故事和观点。创建一个开放和信任的环境，团队成员可以随时讨论改进问题。 Scrum主管可能还需要单独指导一些团队成员提供反馈。例如，当他们受到限制时，对同事给予反馈或过于批评。

敏捷方法比传统方法更需要合作，信任，承担责任和纪律。团队成员共同负责整体结果。作为个人成员，您不能简单地将结果的一部分扔到围栏上给另一个成员。因此，喜欢独自工作的开发人员可能在敏捷团队中表现不佳。逃避或孤独的行为对这样的团队来说是致命的。

这种开放和清晰沟通的需求是敏捷团队不能太大的原因之一。您需要个人交流，最适合最多7到10人的团队。 Scrum Master的作用是指导团队建立这样一个以团队为中心的文化。这是敏捷团队成功（或失败）的关键“软”因素之一，尤其是对于缺乏经验的团队。

在本博客的介绍中，我们重点介绍了Scrum方法如何为基于项目的团队提供结构和形状。成功的敏捷环境不仅取决于形式方面（计划，设定目标等），而且考虑团队中的人为因素也是关键。将软件开发中的正式方面和人为因素结合在一起将使组织能够以最佳方式运行敏捷。然而，在实践中，情况并非如此。

在本系列的未来博客中，我们希望讨论在具有复杂业务流程和系统环境的大型IT密集型组织环境中使用敏捷方法。在这样的背景下，项目组合管理，企业架构，业务流程设计和敏捷开发之间的关系变得越来越重要。然而，这些学科之间存在着各种紧张关系，一方面是在匹配他们不同的节奏和周期，另一方面，或许更重要的是，在他们的文化差异中。

请不要犹豫，分享您在敏捷团队中工作的经验和意见！

原文：https://bizzdesign.com/blog/efficient-collaboration-within-agile-methods/

本文：http://pub.intelligentx.net/efficient-collaboration-within-agile-methods

讨论：请加入知识星球或者小红圈【首席架构师圈】

许多圈子都赞扬了数据管理中的敏捷过程，因为它具有包容性，快速的方法，据称涉及企业的不同方面。然而，根据InfoAdvisors的Karen Lopez和Embarcadero的Ron Huizenga主持的2015年企业数据世界举办的题为“ER / Studio和数据建模特别兴趣小组”的特殊兴趣小组，这些圈子通常不包括专门从事数据建模的专业人士。

敏捷过程经常使数据建模的关键组件在其以多种关键方式产生的各种应用程序和数据库中变得复杂，包括：

• 排除：在各种开发人员，Scrum主人和业务分析师处于实际需要某些数据的阶段之前，数据建模者通常不会进入敏捷过程。更糟糕的是，正如洛佩兹所指出的那样，“因为我是一名顾问，通常我会参与一个敏捷的项目，这个项目是敏捷的，他们没有数据建模者，也没有数据架构师，他们已经构建了这个数据库而他们不能获取或输出数据或不执行数据。通常是一团糟。“
• 开发人员与建模者：开发人员和数据建模人员的目标，方法和需求之间存在许多区别，这些差异提供了各种冲突点。由于敏捷周期通常以开发人员开始和结束，他们的倾向会加剧建模人员的参与。
• 玩捉鬼：由于敏捷项目一开始就被排除在外，建模人员通常必须追赶一个理想情况下应该在冲刺之前工作的过程。许多建模者同时在几个不同的敏捷团队中工作并不罕见。

特殊利益集团坦诚地讨论了这些问题和其他问题，这些问题产生了大量关于数据建模必要性的解决方案和见解。

敏捷环境中的数据建模异同

从理论上讲，数据建模的基本原理在敏捷环境中的存在与在它们之外的情况相同。建模人员通常负责在概念，逻辑和物理层面实施数据，同时还要考虑企业数据模型。但是，在敏捷环境中，它们还必须适应可能存在关键差异的项目模型。故事取代了上述模型中提供的要求 - 这些要求往往缺乏前者的细节。洛佩兹提到：

“通常当我被引入时，我会在开发人员和DBA同时获得故事，开发人员就像'我的桌子在哪里'？而且我想，'我甚至没有读过这些故事'。顺便说一句，这些故事总是废话，因为他们说的话，“然后我们必须收取销售税”，这就是要求的程度，我知道销售税既复杂又疯狂。在一个真实的数据模型中，它需要大约70个表才能正确完成。“

很多时候，建模人员可以从业务分析师那里获得足够的要求，甚至可以使他们能够及时了解冲刺及其目标。 Huizenga观察到：

“我不是在抨击开发人员或程序员，但他们往往知道自己需要包含哪些内容，因此很短视。所以我发现如果我能与商业分析师合作，或者在那里与谁一起瞥见......我发现它很顺利。“

开发者现实

更重要的是，也许，建模者经常被拉入以开发者为中心的世界，在这两个群体之间存在许多误解，包括：

• 数据建模的概念：许多开发人员认为只有一种数据模型适用于敏捷项目，而实际上这种假设并不属实。根据Lopez的说法：“他们认为有一种数据模型，它与所有生产环境相匹配。然后，如果他们在他们的每台笔记本电脑上使用他们自己的开发环境，现在甚至是150。所以我无法比较他们一直在玩的开发环境，但我可以比较他们在QA中提出的建议。“
• 目标建模：许多开发人员经常没有意识到 - 或者关心 - 建模人员必须将数据建模定位到多个环境。这些包括开发人员，QA，预生产和生产。此外，这些不同的环境需要在不同时间点建模数据，这大大增加了敏捷过程中建模的复杂性。
• 敏捷性：一些建模者甚至遇到过敏捷性的灵活方面与重用设计模式的实际需求形成对比的情况。这种需求随着延迟参与而增加，并且项目建模者的潜在多样性可能正在发挥作用。

前期建模

前期建模的实践当然可以帮助数据建模人员跟上敏捷环境的快速性，这些专业人员负责的所有模型都会加剧这种速度。各种环境所需的模型乘以特定用户所需的特定模型。根据Lopez的说法：“无论它们是物理上独立的模型，还是快照或分支机构，我都在处理所有那些真正概念上相同模型的版本。我可能同时拥有15或20个。“利用前期建模和与建模相关的某些预先设想的模式可以帮助减少这么多模型的复杂性，同时还可以减少创建和实现它们的时间。 Lopez说，开发人员“有时候对此不太感兴趣，因为他们认为这是一个很大的前期建模。” “是的，这是预先的，但它认为已经完成 - 就像你的代码模式一样。”

分支

在时间密集的敏捷环境中进行数据建模的另一个方法是使用分支。在需要不同版本的模型和数据的其他方面的情境要求的情况下，分支通常是可取的。在这种情况下，建模者可以仅“分支”当前模型​​，然后最终合并回主模型，而不是在这种情况下创建完全独立的模型。另一种考虑敏捷流程创建的时间敏感环境的方法是让建模者直接在开发人员沙箱中工作 - 这有助于开发人员了解模型约束以及如何适应它们。这种策略有助于促进敏捷方法已知的交互性和协作。 Huizenga反思这种方法：

“我过去常常与开发人员合作开始说，'这就是我认为你需要'。我们会将它放入桌面上的开发人员沙箱中。我们会玩它，看看有什么可以使它工作。然后我会做一个比较并合并然后把它带回来然后说'好吧，那不行，但是，让我们以这种方式融合'，然后我们就会继续前进。“

打破构建并修复它

在敏捷环境中工作时，数据建模的现实面临巨大挑战，因为严格的期限通常会给所涉及的每个人带来时间限制。建模者可以帮助抵消一些主要存在的问题，这些问题主要是由于假设，误解以及开发人员在几个方面普遍无知。其中包括从业务部门获得有关要求的澄清，并征求其参与以扩大项目范围。除了直接在开发人员沙箱中工作外，它们还包括利用前期建模和分支，使开发人员了解数据建模标准。实际上，在开发人员沙箱中工作可以帮助创建理想的情况，在这种情况下，开发人员可以近乎实时地访问他们与建模需求的一致性。根据Huizenga的说法：

“在我救出的一个项目中，我们把它带到了我们有五个不同的团队前进的地步，一旦检查了一些东西，如果它打破了构建，我们实际上有红色闪烁的灯连接到计算机。基本上，每个人都知道这一切都是在甲板上找出错误，修复构建，继续使用，然后离开你。令人惊讶的是，合作水平将会提升。这只是让每个人都在一起工作。作为其中一部分的业务团队，他们只是喜欢它，这些东西是实时发生的，他们是对正在发生的事情的见证。“

 

原文：https://www.dataversity.net/fundamentals-of-data-modeling-in-agile-environments/

本文：https://pub.intelligentx.net/fundamentals-data-modeling-agile-environments

讨论：请加入知识星球或者小红圈【首席架构师圈】

我们让公司再次感到年轻，帮助他们更快地行动，更灵活，更有创意。许多因素都变成了“感觉年轻”，所有这些因素都在于改变商业和技术合作方式的力量关系。变化的规模和广度可能令人困惑，但仔细观察就会发现贯穿整个自治的共同主题。

大多数成熟公司都在努力有效地整理资源。他们行动缓慢，因为有抵抗力的变化。牛顿将惯性定义为对变化的抵抗。希格斯说，惯性是由太多的相互作用引起的。当依赖性阻碍变革时，粒子和人类都无法快速移动。我们如何在组织的各个层面消除依赖关系并拥抱自治权？

基础设施：

云和SaaS打破了我们对基础设施的依赖 - 购买硬件的大爆炸方法，等待供应商，构建数据中心已经蒸发 - 取而代之的是自助服务，随时随地付费，随着您的增长而扩展。到目前为止，在我们的基础设施中实现自治是非常明显的。

架构：

一个巨大的惯性来源是传统系统的意大利面结构，它导致组织谨慎行事，因为他们不知道会破坏什么。这是IT部门努力解决的难题，因为有两台计算机而不是一台。 API围绕，畜栏和控制依赖 - 在可能的情况下消除它们或使它们可见和可管理。 Bezo的Big Mandate是这种方法的宣言，也是微服务架构的先驱，采用热心的方法消除所有依赖关系。

团队：

敏捷宣言完全是关于自治 - 为我们的团队提供信任和资源，使他们能够做出快速，迭代和低风险的本地决策。小型，跨职能，双披萨团队是自治的典范。

组织：

成熟的公司已经拥有成功所需的所有资源 - 他们只是没有有效地使用它们。改变我们组织和利用资产的方式可以带来更大的自主权。平台是独立的自治单元，可以以不同的方式组成，以支持不同的业务需求。将平台视为您的银行或保险公司或公用事业的“操作系统”，作为“应用程序”的“应用程序商店”。平台增加了平台提供商和平台用户的自主权，使他们能够独立优化。

风险：

最大的依赖是需要获得许可。建立幸运国家显示我们淹没在自我制造的繁文缛节中。风险规避鼓励我们避免变更或将其外包给其他人（另一种形式的依赖）。精益企业思维促进了一种鼓励创新的文化，使我们能够以一种包含风险的方式“快速学习”，但通过持续衡量，轻量级治理和渐进式变革来降低其影响。

聪明的公司比竞争对手更好地使用技术。聪明的公司还鼓励在各个层面都拥抱和支持变革的文化。共同的要素是我们的系统，我们的团队和我们的员工的自主权。

敏捷已成为企业的关键能力。 正如谷歌和苹果公司现在所做的那样，客户需要改变的速度，新的法律和法规影响服务和引入流程，以及竞争对手可以轻松破坏您的业务，这会带来巨大的压力。 面临快速变化，采用新技术，促进增长，扩大规模或降低成本的压力。 因此，在许多组织中，敏捷与创新能力同等重要。 创新和敏捷性是可持续业务的必要能力。

敏捷开发已成为软件开发的标准。但真正的业务敏捷性需要的不仅仅是拥有一堆Scrum团队。此外，如果您只关注敏捷软件开发提供的小规模敏捷性，您可能看不到树林：为什么您希望像企业一样灵活，这需要什么？

在更大的规模上组织敏捷

企业不仅仅是小团队的一系列本地开发项目。这些团队工作的难题必须以某种方式结合在一起。希望有一个未来的愿景，一个企业和IT战略，一个组织旨在实现的目标。这就是企业架构的用武之地。

传统的企业架构具有相当自上而下的特性，您可以在实施之前制定广泛的计划。敏捷运动的重点在于适应变化和对“大型设计前沿”（BDUF）的抵制，恰恰相反。

两种方法都有其优点和缺点。传统的EA可能导致那些不知道如何与时俱进的缓慢而官僚的组织，而且只有一大群Scrum团队没有一些综合的，总体的方法可能会导致由敏捷孤岛组成的不连贯的IT环境。但是，如果我们利用这两种方法的优势，我们就可以创建一个整体运动的企业，而不需要一个能够扼杀地方发展和创新的中央，指挥和控制管理。

示例：Scaled Agile Framework

诸如Scaled Agile Framework（SAFe）和Disciplined Agile Delivery（DAD）等现代开发正朝着正确的方向发展。我们以SAFe为例，在下图中以简化形式描述。

SAFe使用分层迭代方法，我们在底层找到典型的敏捷团队。这些结果以2-3周的典型敏捷频率提供。在中间，这些团队的结果使用解决方案架构概念（如Architecture Runway和Agile Release Train）进行集成和发布，以确保这些概念相互配合。该层以团队层的几倍速度迭代，每2-3个月交付一次可交付的产品。在顶部，大型，长期的发展定位。这就是企业架构找到它的位置。业务战略提供给该层，并为大规模，高影响力的架构决策，优先级设置和预算分配提供上下文。

在这个顶层，已建立的企业架构方法如TOGAF找到了自己的位置。 TOGAF也有一个迭代结构，由其架构开发方法（ADM）熟悉的“麦田怪圈”图表示。但是，在敏捷环境中应用它需要进行一些调整。特别是企业架构需要变得更加外向，从而更加面向业务，最终客户和以结果为中心。业务成果可以是最终客户产品，其由服务，功能，可交付成果和工件描述，但也可以是实现新策略的业务转型。

再次关注TOGAF，TOGAF的实施治理（ADM中的阶段G）与实施项目和计划（即底层两层）的接口方式需要一些工作。特别是，敏捷方法强烈依赖于反馈循环，而TOGAF的治理本质上是前馈。 TOGAF的架构变更管理（阶段H）是此反馈的有用切入点。我们打算在未来的一个博客中解决这个问题。

此外，SAFe，DAD，TOGAF和相关方法仍然是以IT为中心的。据SAFe称，企业架构师的角色是“[......]推动整体技术实施[...]”。但真正的企业架构师并不仅仅关注技术。相反，业务架构是这个等式中越来越重要的一部分：战略映射，基于能力的规划，价值映射，业务流程管理，精益六西格玛和其他与业务相关的学科仍然缺失。真正敏捷的企业需要的不仅仅是敏捷的IT。

请继续关注Agile和EA的更多信息，同时告诉我们您对这些问题的看法。

原文：https://bizzdesign.com/blog/enterprise-architecture-and-agile-development-opposites-attract/

本文：http://pub.intelligentx.net/enterprise-architecture-and-agile-development-opposites-attract

讨论：请加入知识星球或者小红圈【首席架构师圈】

敏捷环境有效地弥合了产品和工程之间的沟通差距。 BDD是Agile QA发生的最好的事情;-)

测试的神话.

在大学里，我学到了软件测试的基本概念，但无法全面了解整个过程。所以我曾经认为测试是一个耗时的过程，有很多理论术语。但是当我在职业生涯中成长并开始全职为软件行业工作时，我意识到确保我们编写的软件质量的机制的真正需要。让我与您分享我的发现。

软件测试（定义）

软件测试是一系列旨在调查，评估和确定软件产品完整性和质量的过程。此过程通过验证和验证确保软件产品符合法规，业务，技术，功能和用户要求。

验证(Validation) - 我们是否正在构建正确的产品

验证(Verification) - 我们是否正确构建产品

V＆V信心 - 确保产品符合目的

在进入我们的主题之前，我假设您对以下概念图中的基本软件测试概念有所了解。

软件测试分类 - 今天的软件团队使用上述测试方法的组合来满足他们的测试目标。

传统测试

在传统的软件开发环境中，开发和测试是两个不同的阶段，大部分时间由两个不同的小组完成;

1. 编写程序和构建功能的开发人员
2. 测试书面软件的测试人员

质量保证 - 测试人员编写并执行全面的测试套件，以查找新开发的功能中的错误，同时验证新编写的代码未在已开发的功能中引起任何错误（回归测试）

走向敏捷

快速的软件开发和不断提供的新质量功能现在通常是我们开发的软件系统的最重要的要求。企业运营迅速，我们的软件产品需要快速发展，以反映不断变化的业务需求。但传统的测试方法无法确保以更快的速度获得预期的良好质量。为了跟上不同的发展节奏，需要一种确保软件质量的新方法。那就是敏捷！

敏捷方法的重点是减少软件过程中的开销，并能够快速响应不断变化的需求，而无需过多的返工。

敏捷宣言

敏捷方法总是致力于通过评估来发现构建软件的更好方法;

个人和互动 - 过程和工具

工作软件 - 综合文档

客户协作 - 通过合同谈判

响应变革 - 遵循计划

 

 

在敏捷中进行测试

敏捷方法通过引入测试自动化，协作测试，全生命周期测试，减少开销和最少文档等概念，避免了传统测试方法的低效率和开销。首先，我来介绍一些术语。

1. 测试驱动开发（TDD） - 在代码之前编写测试并通过测试是开发的关键驱动因素。
2. 验收测试驱动开发（ATDD） - 具有不同观点的团队成员（客户，业务分析师，测试人员，开发人员）在实施相应功能之前协作并编写验收测试。
3. 行为驱动开发（BDD） - 测试是用非技术语言编写的，每个人都可以理解（例如像Gherkin这样的特定于域的语言）。 BDD结合了TDD和ATDD的原理，并形成了一种方法，通过讨论示例来建立对要构建的软件类型的共享理解。

测试自动化

在敏捷中，几乎所有时间，我们都尝试以自动方式实现测试套件。由于现代计算机非常擅长快速运行重复性任务，因此自动化测试套件比使用手动测试更有效。每当向系统添加新功能时，都可以运行测试，并且可以立即捕获新代码引入的问题（这可以成功实现持续集成实践）。

行为驱动开发（BDD）

在敏捷环境中，BDD起着至关重要的作用，因为它强烈鼓励在开发和测试过程中使用敏捷方法。 BDD将软件产品的客户，最终用户，BA，QAs和SE集中到一个表中，以便有效地共享系统知识及其测试要求。

BDD由一系列要遵循的步骤组成。

1. 识别业务功能。
2. 确定所选功能下的方案。
3. 为每个方案定义步骤。
4. 运行功能并失败。
5. 编写代码以使步骤通过。
6. 重构代码，创建可重用的自动化库。
7. 运行功能并通过。
8. 生成测试报告。

 

写作特性

功能，方案和步骤一起形成行为测试。在大多数情况下，这些测试通常由业务分析师（BA）以商业可读，域特定语言（DSL）编写。小黄瓜是一种流行语言，用于编写叙述性用户故事。

使用Gherkin语法示例编写要素文件

在功能文件的最开头，我们将操作标题称为功能。然后，可以选择向该功能添加说明。它采用以下格式，

As [role]

I want [feature]

So that [benefit/business reason]

功能的验收标准是其中的方案。仅当该功能中的所有方案都成功时，才会成功通过功能。场景采用以下格式，

Given Exact context

When Action/Event

Then Outcomes

And/But More of the same…

Gherkin有更酷的选项，如示例，场景轮廓，背景和标签。因此，请务必仔细阅读Gherkin文档，以便更好地了解Gherkin的可能性。

如果您是一个试图编写出色功能的人，首先，您必须最大限度地减少功能气味（时间依赖性，相互依赖性，多场景场景，过度使用变量）

创建测试

在商务人员编写功能文件后，QA人员开始实施测试套件。对于编写BDD测试，使用BDD测试框架。为了自动化测试过程，Test Runner代码也使用jUnit（Java），TestNG（Java），Mocha（JavaScript）等技术实现。

热门BDD框架：

• Java — Cucumber, JBehave
• Ruby — Cucumber
• PHP — Behat
• JavaScript — cucumber.js, jasmine

完整的测试周期

 

总之，BDD涉及上述活动的周期，需要跨职能团队的参与和协作，该团队由客户/客户，BA，QAs，测试人员，UI和UX设计人员以及软件开发人员组成。 这是一种精心开发的方法，同时牢记敏捷宣言的原则。

 

BDD的优点

行为测试的最大优点可能是它们以非常具体和直接的方式描述了用户期望从系统中获得的一组函数。这些行为的总和基本上记录了与用户/客户的合同。如果任何测试失败，则不支持此合同。

虽然为现有代码编写单元测试可能非常困难，但可以在任何时间为系统编写行为测试：开发之前，期间或之后。首先编写测试的情况称为行为驱动开发。

单元测试套件提供每个组件仍在工作的持续反馈。单元测试作为不能过时的文档，不像单独的文档，这可以并经常做。当测试通过并重构生产代码以删除重复时，很明显代码已完成，开发人员可以继续进行新的测试。

测试驱动的开发迫使进行关键分析和设计，因为开发人员无法在不真正了解所需结果以及如何测试的情况下创建生产代码。该软件往往设计得更好，即松散耦合且易于维护，因为开发人员可以随时自由地做出设计决策和重构，并确信软件仍在工作。通过运行测试可以获得这种信心。可能会出现对设计模式的需求，并且可以在那时更改代码。

测试套件充当了错误的回归安全网：如果发现错误，开发人员应该创建一个测试来揭示错误，然后修改生产代码，以便bug消失，所有其他测试仍然通过。在每次连续的测试运行中，都会验证以前的所有错误修复。它还减少了调试时间。

下一步

为了完全理解BDD，让我们在下一个教程中创建一个示例项目，用Cucumber，jUnit / TestNG，Java和Selenium来测试BDD风格的Web应用程序。

推荐阅读

• BDD in Action: Behavior-Driven Development for the whole software lifecycle — by John Ferguson Smart
• https://johnfergusonsmart.com/feature-mapping-a-simpler-path-from-stories-to-executable-acceptance-criteria/
• https://www.toptal.com/freelance/your-boss-won-t-appreciate-tdd-try-bdd

参考

• https://www.toadworld.com/platforms/oracle/b/weblog/archive/2017/03/23/testing-in-an-agile-development-environment-tdd-vs-bdd
• http://istqbexamcertification.com/what-are-the-different-agile-testing-methodology-test-driven-development-behavior-driven-development/
• https://dzone.com/articles/a-day-or-a-sprint-in-the-life-of-a-bdd-team

Image Sources: https://www.safaribooksonline.com/library/view/bdd-in-action/9781617291654/, https://jovanamiljanovic.com/wp-content/uploads/2017/03/testirovshhiki-razrabotchiki-vzaimodeystvie.png, http://2.bp.blogspot.com/-SIWC4Nb2VQo/VzFfyjkAckI/AAAAAAAAAR4/XQGIel6Q_LorBWXSo55S3CRQmviXqxaYgCK4B/s1600/bdd.png

Tools in images: http://serenity-bdd.info, http://serenity-js.org

 

原文：https://medium.com/agile-vision/behavior-driven-development-bdd-software-testing-in-agile-environments-d5327c0f9e2d

本文：http://pub.intelligentx.net/node/511

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

关键要点

 

1. 人们普遍认为，我们创建的任何软件都必须经过测试，以确保其满足功能要求，但我们还必须测试非功能性需求，如安全性，可用性和 - 关键性 - 可维护性。
2. 测试驱动开发（TDD）是一种成熟的技术，可以随着时间的推移更快速，更可持续地提供更好的软件。
3. TDD基于一个简单的想法：在编写生产代码之前编写失败的测试。然而，这种“简单”的想法需要技巧和判断才能做得好。
4. TDD实际上是一种设计技术。 TDD的基础重点是使用小型测试以紧急方式从头开始设计系统，并在建立系统信心的同时快速获得价值。这种技术的更好名称可能真的是测试驱动设计。
5. 通常，为特定问题开发解决方案的第一步，无论其复杂程度如何，都要分析它，然后将其分解为更小的组件。这些组件可以通过一系列步骤实现，其中输入场景与下一步的输出应该一起考虑。

我们需要进行软件测试，以确保软件满足要求，正确响应输入（输入验证），在可接受的时间内执行（性能测试），用户可以安装和运行它（部署测试），以及它符合利益相关者的目标。这些目标可能是业务结果或功能，如安全性，可用性，可维护性和其他类型的功能。

测试类型包括：

1. 烟雾和健康测试检查软件是否以基本形式运行。
2. 连续测试在每次迭代中运行，例如我们运行Maven时。
3. 当我们添加新的编程代码或更改现有代码时，我们使用回归测试。我们希望确保其他代码继续有效。
4. 性能测试测量运行软件所需的时间。
5. 验收测试检查利益相关者是否对软件感到满意并且他们是否愿意支付账单。

单元测试是一组测试中最小的构建块。编程代码中的每个类都有一个伴随单元测试类。通过模拟方法调用将测试与其他类隔离。

集成测试更容易实现。我们将测试一个包含所有依赖项的类。在这里，我们可以确保通过软件的路径正常工作，但是当它失败时，我们不知道哪个类失败了。系统测试检查整个系统，包括硬件操作系统，Web服务等。

测试应该是可读的，因为非程序员应该能够阅读或更改测试。在敏捷团队中，程序员与测试人员和分析人员一起工作，测试和规范是共同点，因此每个人都应该能够阅读测试，甚至在必要时更改测试。

TDD：关于设计和生产力

测试驱动开发（TDD）是一种可持续交付更好软件的成熟技术。 TDD基于一个简单的想法：在编写生产代码之前编写失败的测试。需要新的行为？写一个失败的测试。然而，这个看似简单的想法需要技巧和判断才能做好。

TDD实际上是一种设计技术。 TDD的基础是使用小型测试以紧急方式自下而上设计，并在建立系统信心的同时快速达到某种价值。更好的名称可能是测试驱动的设计。

作为一种设计方法，它的重点和简洁性。目标是防止开发人员编写多余的代码，这些代码对于交付价值是不必要的。它是关于编写解决问题所需的最少量代码。

许多文章都夸耀了TDD的所有优点，许多技术会议的谈话告诉我们做测试以及它们做得多酷。他们是对的（不一定是关于酷的部分，但关于有用的部分）。测试是必须的！ TDD典型列出的优势是真实的：

1. 你写的软件更好。
2. 你避免过度工程。
3. 在引入新功能时，您可以防止破坏世界。
4. 您的软件是自我记录的。

即使我总是同意这些优点，也有一段时间我认为我不需要TDD来编写好的和可维护的软件。当然，现在，我知道我错了，但为什么我有这个想法尽管闪亮的神奇好处？成本！

TDD成本很高！如果我们不进行测试，任何人都认为成本更高是正确的，但这些成本来自不同的时间。如果我们做TDD，我们会立即付费。如果我们不做TDD，我们的成本将在未来出现。

完成任务的最有效方法是尽可能自然地完成。人们的本性是懒惰（软件开发人员可能是这方面表现最好的）并且贪婪，所以我们必须找到一种降低成本的方法。这很容易说，但很难做到！

围绕TDD有许多理论，维度和观点，但我更倾向于展示我们如何在实践中进行TDD。最后，我们将从我们开始和前进的位置看到我们将要拥有的最后一件艺术品，这将仅通过使用TDD来实现。

以下是我的演示文稿“单元测试和TDD概念与最佳实践指南”的链接，其中包含以下主题：

1. 为什么我们需要测试，
2. 测试类型，
3. 如何以及何时使用每种类型，
4. 按测试级别覆盖，
5. 测试策略，和
6. TDD在实践中。

它还包括指导和最佳实践，以指导在测试时做什么和不做什么。

“实践中的TDD”部分和引入的概念通常适用于任何语言，但我使用Java进行演示。我们的目标是展示我们在设计和创作令人兴奋的艺术时应该如何思考，而不仅仅是编写代码。

 

分析问题

解决任何问题而不管其复杂性的第一步是分析它，然后将其分解为小的连续和完整的步骤，考虑输入场景和输出应该是什么。我们审查这些步骤，以确保我们在没有深入了解实施细节的情况下，从业务角度来看，相对于原始要求没有差距 - 不多也不少。

这是关键的一步;其中一个最重要的步骤是能够识别手头上给定问题的所有要求，以简化即将到来的实施阶段。通过这些较小的步骤，我们将拥有一个干净，易于实现，可测试的代码。

TDD是开发和维护此类步骤的关键，直到我们涵盖手头问题的所有案例。

让我们想象一下，我们被要求开发一个转换工具库，将任何罗马数字转换为其等效的阿拉伯数字。作为开发人员，我将执行以下操作：

1. 创建一个库项目。
2. 创建类。
3. 可能潜入创建转换方法。
4. 想一想可能存在的问题场景以及可以做些什么。
5. 为这个任务编写一个测试用例，以确保我已经编写了无聊的测试用例（这往往导致不编写任何测试用例），而几乎已经像往常一样在main方法中测试了该任务。

这种发展很糟糕。

为了在开发代码时正确启动流程并将TDD付诸实践，请按照这些实际步骤成功完成最终项目，并提供一套测试案例，以保护未来开发的时间和成本。

可以从我的GitHub存储库克隆此示例的代码。启动终端，指向您喜欢的位置，然后运行以下命令：

$ git clone https://github.com/mohamed-taman/TDD.git

我已经管理了项目，以便为每个TTD红色/绿色/蓝色更改提交，因此在导航提交时，我们可以注意到最终项目要求的更改和重构。

我正在使用Maven构建工具，Java SE 12和JUnit 5。

TDD在实践中

为了开发我们的转换器，我们的第一步是使用一个测试用例将Roman I转换为阿拉伯数字1。

让我们创建转换器类和方法实现，以使测试用例满足我们的第一个要求。

但是等等，等等！稍等一下！作为实用建议，最好从这个规则入手：首先不要创建源代码，而是从测试用例中创建类和方法开始。这被称为意图编程，这意味着命名新类和将要使用它的新方法将迫使我们考虑使用我们正在编写的代码片段以及如何使用它，这绝对是导致更好，更清洁的API设计。

步骤1

首先创建一个测试包，类，方法和测试实现：

包装：rs.com.tm.siriusxi.tdd.roman

类：RomanConverterTest

方法：convertI（）

实现：assertEquals（1，new RomanConverter（）。convertRomanToArabicNumber（“I”））;

第2步

这里没有失败的测试用例：这是一个编译错误。因此，让我们首先使用IDE提示在Java源文件夹中创建包，类和方法。

包装：rs.com.tm.siriusxi.tdd.roman

类：RomanConverter

方法：public int convertRomanToArabicNumber（String roman）

第3步（红色状态）

我们需要确保我们指定的类和方法是正确的并且测试用例运行。

通过实现convertRomanToArabicNumber方法来抛出IllegalArgumentException，我们确信我们已经达到了红色状态。

public int convertRomanToArabicNumber（String roman）{

        抛出新的IllegalArgumentException（）;

 }

运行测试用例。我们应该看到红条。

第4步（绿色状态）

在这一步中，我们需要再次运行测试用例，但这次要看绿色条。我们将用最少量的代码实现该方法以满足测试用例的绿色。所以，该方法应该返回1。

public int convertRomanToArabicNumber（String roman）{

        返回1;

 }

运行测试用例。我们应该看到绿色的酒吧。

第5步（重构状态）

现在是重构的时候了（如果有的话）。我想强调的是，重构过程不仅涉及生产代码，还涉及测试代码。

从测试类中删除未使用的导入。

再次运行测试用例以查看蓝色条。呵呵呵 - 我在开玩笑，没有蓝条。如果重构后一切仍然按预期工作，我们应该再次看到绿色条。

删除未使用的代码是主要的简单重构方法之一，它可以提高代码的可读性和类的大小，从而提高项目的大小。

第6步

从这一点开始，我们将遵循从红色到绿色到蓝色的一致过程。我们通过编写新的需求或问题的一个步骤作为失败的测试用例来传递TDD的第一个点，即红色状态，然后继续直到我们完成整个功能。

请注意，我们从基本要求或步骤开始，然后一步一步地继续，直到我们完成所需的功能。这样，我们就有了明确的步骤，从最简单到复杂。

最好这样做而不是跳过去，花费大量时间一次性考虑整个实施，这可能会导致我们过度思考和覆盖我们甚至不需要的案例。这引入了过度编码。而且效率低下。

我们的下一步是将II转换为2。

在同一个测试类中，我们创建了一个新的测试方法及其实现，如下所示：

方法：convertII（）

当我们运行测试用例时，它会转到红色条，因为convertII（）方法失败了。 convertI（）方法保持绿色，这很好。

 

第7步

现在我们需要运行测试用例并生成一个绿色测试栏。让我们实现一种方法来满足这两种情况。我们可以使用简单的if / else if / else检查来处理这两种情况，在其他情况下，我们抛出IllegalArgumentException。

public int convertRomanToArabicNumber（String roman）{

        if（roman.equals（“I”））{

            返回1;

        } else if（roman.equals（“II”））{

            返回2;

        }

        抛出新的IllegalArgumentException（）;

    }

这里要避免的一个问题是从一行代码（例如roman.equals（“I”））上升的空指针异常。要修复它，只需将相等转换为“I”.equals（罗马）。

再次运行测试用例，我们应该看到所有情况下的绿色栏。

第8步

现在，我们有机会寻找重构案例，这里有代码味道。在重构中，我们通常会以下列形式查找代码异味：

方法很长，

重复的代码，

很多if / else代码，

开关盒恶魔，

逻辑简化，和

设计问题。

这里的代码味道（你找到了吗？）是if / else语句和许多返回。

也许我们应该通过引入一个sum变量来重构这里，并使用for循环来遍历罗马字符的字符数组。如果一个字符是I，它将为sum加1，然后返回总和。

但我喜欢防御性编程，所以我会将throw子句移动到if语句的else语句中，以便覆盖任何无效字符。

public int convertRomanToArabicNumber（String roman）{

        int sum = 0;

        for（char ch：roman.toCharArray（））{

            if（ch =='I'）{

                sum + = 1;

            } else {

                抛出新的IllegalArgumentException（）;

            }

        }

        返回0;

    }

在Java 10及更高版本中，我们可以使用var来定义变量，给出var sum = 0;而不是int sum = 0;。

我们再次运行测试以确保我们的重构不会改变任何代码功能。

哎哟 - 我们看到一个红色的酒吧。哦!所有测试用例都返回0，我们错误地返回0而不是sum。

我们解决这个问题，现在看到美丽的绿色。

这表明无论改变多么微不足道，我们都需要在它之后运行测试。在重构时总是有机会引入错误，我们的帮助程序是测试用例，我们运行它来捕获错误。这显示了回归测试的力量。

再看一下代码，还有另一种气味（你看到了吗？）。这里的例外不是描述性的，因此我们必须提供有意义的错误

非法罗马字符％s，ch。的消息

抛出新的IllegalArgumentException（String.format（“非法罗马字符％s”，ch））;

再次运行测试用例，我们应该看到所有情况下的绿色栏。

第9步

我们添加另一个测试用例。让我们将III转换为3。

在同一个测试类中，我们创建了一个新的测试方法及其实现：

方法：convertIII（）

再次运行测试用例，我们看到所有情况下的绿色条。我们的实现处理这种情况。

 

第10步

现在我们需要将V转换为5。

在同一个测试类中，我们创建了一个新的测试方法及其实现：

方法：convertV（）

运行测试用例会转到红色条，因为convertV（）失败而其他是绿色。

通过将else / if添加到main if语句来实现该方法，并检查如果char ='v'则sum + = 5;。

for（char ch：roman.toCharArray（））{

            if（ch =='I'）{

                sum + = 1;

            } else if（ch =='V'）{

                总和+ = 5;

            } else {

                抛出新的IllegalArgumentException（String.format（“非法罗马字符％s”，ch））;

  }}

我们有机会在这里重构，但我们不会在这一步中采取它。在实施阶段，我们唯一的目标是让测试通过并给我们一个绿色条。我们目前没有注意简单的设计，重构或具有良好的代码。当代码通过时，我们可以回来重构。

在重构状态下，我们只专注于重构。一次只关注一件事，以避免分心变得不那么富有成效。

测试用例应该进入绿色状态。

我们有时需要一串if / else语句;为了优化它，从最常访问的案例到最少访问的案例来命令if语句测试用例。如果适用，更好的是更改为switch-case语句以避免测试案例并直接达到案例。

第11步

我们处于绿色状态，我们处于重构阶段。回到方法，我们可以做一些我不喜欢的if / else。

或许不使用if if / else，我们可以引入查找表并将罗马字符存储为键，将阿拉伯语等值存储为值。

让我们删除if语句并写入sum + = symbols.get（chr）;在它的位置。右键单击灯泡，然后单击以引入实例变量。

private final Hashtable <Character，Integer> romanSymbols = new Hashtable <Character，Integer>（）{

        {

            放（'我'，1）;

            put（'V'，5）;

        }

    };

我们需要像以前一样检查无效符号，因此我们让代码确定romanSymbols是否包含特定键，如果不包含，则抛出异常。

    public int convertRomanToArabicNumber（String roman）{

        int sum = 0;

        for（char ch：roman.toCharArray（））{

            if（romanSymbols.containsKey（ch））{

                sum + = romanSymbols.get（ch）;

            } else {

                抛出新的IllegalArgumentException（

                        String.format（“非法罗马字符％s”，ch））;

            }

        }

        回报;

    }

运行测试用例，它应该进入绿色状态。

这是另一种代码味道，但对于设计，性能和干净的代码。最好使用HashMap而不是Hashtable，因为与Hashtable相比，HashMap实现是不同步的。对这种方法的大量调用会损害性能。

设计提示始终使用通用接口作为目标类型，因为这是更容易维护的更干净的代码。在不影响代码使用的情况下，可以轻松更改细节的实现。在我们的例子中，我们将使用Map。

private static Map <Character，Integer> romanSymbols = new HashMap <Character，Integer>（）{

        private static final long serialVersionUID = 1L;

        {

            放（'我'，1）;

            put（'V'，5）;

        }

    };

如果使用Java 9+，则可以使用新的HashMap <>（）替换新的HashMap <Character，Integer>（），因为菱形运算符与Java 9中的匿名内部类一起使用。

或者你可以使用更简单的Map.of（）。

Map <Character，Integer> romanSymbols = Map.of（'I'，1，'V'，5，'X'，10，'L'，50，'C'，100，'D'，500，'M '，1000）;

java.util.Vector和java.util.Hashtable已过时。虽然仍然受支持，但这些类已被JDK 1.2集合类淘汰，并且可能不应该用于新开发。

在重构之后，我们需要检查一切是否正常，以及我们没有破坏任何东西。雅虎，代码是绿色的！

第12步

让我们添加一些更有趣的值来转换。我们回到我们的测试类来实现将Roman VI转换为6。

方法：convertVI（）

我们运行测试用例并看到它通过。看起来我们放入的逻辑允许我们自动覆盖这种情况。我们再次免费获得这个，没有实现。

 

第13步

现在我们需要将IV转换为4，它可能不会像VI到6那样顺利。

方法：convertIV（）

我们运行测试用例，结果是预期的红色。

我们需要让它通过我们的测试用例。我们认识到，在罗马表示中，较小值的字符（例如I）预先附加到较大值的字符（例如V）会减少总数值 -  IV等于4而VI等于6。

我们已经构建了我们的代码以总是对值进行求和，但是为了通过测试，我们需要创建减法。我们应该有一个条件做出决定：如果前一个字符的值大于或等于当前字符的值，那么它是一个求和，否则它是减法。

编写满足问题的逻辑，而不必担心变量的声明，这是很有成效的。只需完成逻辑，然后创建满足您的实现的变量。正如我之前所描述的那样，这是按意图编程。这样，我们将始终以更快的方式引入最少的代码，而无需预先考虑所有事情 -  MVP概念。

我们目前的实施是：

public int convertRomanToArabicNumber（String roman）{

        roman = roman.toUpperCase（）;

        int sum = 0;

        for（char chr：roman.toCharArray（））{

            if（romanSymbols.containsKey（chr））

                sum + = romanSymbols.get（chr）;

            其他

                 抛出新的IllegalArgumentException（

                        String.format（“无效的罗马字符％s”，chr））;

        }

        回报;

    }

在检查罗马字符有效性时，我们开始新的逻辑。我们正常编写逻辑，然后在IDE提示的帮助下创建一个局部变量。此外，我们对它们应该是什么类型的变量有一种感觉：它们要么是方法的本地变量，要么是实例/类变量。

        int sum = 0，current = 0，previous = 0;

        for（char chr：roman.toCharArray（））{

            if（romanSymbols.containsKey（chr））{

                if（previous> = current）{

                    sum + = current;

                } else {

                    sum  -  = previous;

                    sum + =（当前 - 上一个）;

                }

            } else {

                抛出新的IllegalArgumentException（

                        String.format（“无效的罗马字符％s”，chr））;

            }

现在我们需要将for循环更改为基于索引以访问当前和先前的变量，因此我们更改实现以满足新的更改，以便正常编译。

for（int index = 0; index <roman.length（）; index ++）{

            if（romanSymbols.containsKey（roman.charAt（index）））{

                  current = romanSymbols.get（roman.charAt（index））;

                  previous = index == 0？ 0：romanSymbols.get（roman.charAt（index-1））;

                if（previous> = current）{

                    sum + = current;

                } else {

                    sum  -  = previous;

                    sum + =（当前 - 上一个）;

                }} else {

                抛出新的IllegalArgumentException（

                        String.format（“无效的罗马字符％s”，roman.charAt（index）））;

            }

现在我们在添加这个新功能后运行测试用例，然后变绿。完善。

第14步

在绿色状态下，我们已准备好进行重构。我们将尝试一个更有趣的重构。

我们的重构策略是始终寻求简化代码。我们在这里可以看到romanSymbols.get（roman.charAt（index））的行出现两次。

让我们将重复的代码提取到这里要使用的方法或类，以便将来的任何更改都集中在一个地方。

突出显示代码，右键单击并选择NetBeans重构工具> introduction>方法。将其命名为getSymbolValue并将其保留为私有方法，然后单击“确定”。

此时，我们需要运行测试用例，看看我们的小型重构没有引入任何错误，我们的代码没有破坏。我们发现它仍处于绿色状态。

第15步

我们将进行更多的重构。声明条件romanSymbols.containsKey（roman.charAt（index））很难阅读，并且要弄清楚它应该测试什么来传递if语句并不容易。让我们简化代码，使其更具可读性。

虽然我们理解现在这行代码是什么，但我保证在六个月内很难理解它正在尝试做什么。

可读性是我们应该在TDD中不断提高的核心代码质量之一，因为在敏捷中我们经常快速地更改代码 - 为了快速更改，代码必须是可读的。任何改变都应该是可测试的。

让我们将这行代码提取到一个方法中，该方法的名称为doesSymbolsContainsRomanCharacter，它描述了它的作用。我们将像以前一样在NetBeans重构工具的帮助下完成这项工作。

这样做可以使我们的代码更好。条件是：如果符号包含罗马字符，则执行逻辑，否则抛出无效字符的非法参数异常。

我们再次重新运行所有测试并找不到新的错误。

请注意，一旦我引入任何小的重构更改，我会经常运行测试。我不等到我完成所有我打算做的重构，然后再次运行所有测试用例。这在TDD中至关重要。我们需要快速反馈并运行我们的测试用例是我们的反馈循环。它允许我们尽可能早地以小步骤检测任何错误，而不是长时间检测。

因为每个重构步骤都可能引入新的错误，代码更改和代码测试之间的持续时间越短，我们就能越快地分析代码并修复任何新错误。

如果我们重构了一百行代码然后运行失败的测试用例，我们必须花时间进行调试，以便准确检测出问题所在。在筛选一百行时，比查看五行或十行代码更改时更难找到引入错误的代码行。

第16步

我们在引入的两个私有方法和异常消息中有重复的代码，这个重复的行是roman.charAt（index），因此我们将使用名称为getCharValue的NetBeans将其重构为一个新方法（String roman，int index） 。

我们重新运行所有测试，一切都保持绿色。

第17步

现在让我们做一些重构来优化我们的代码并提高性能。我们可以简化转换方法的计算逻辑，目前是：

int convertRomanToArabicNumber（String roman）{

        roman = roman.toUpperCase（）;

        int sum = 0，current = 0，previous = 0;

        for（int index = 0; index <roman.length（）; index ++）{

            if（doesSymbolsContainsRomanCharacter（roman，index））{

                current = getSymboleValue（roman，index）;

                previous = index == 0？ 0：getSymboleValue（roman，index  -  1）;

                if（previous> = current）{

                    sum + = current;

                } else {

                    sum  -  = previous;

                    sum + =（当前 - 上一个）;

                }

            } else {

                抛出新的IllegalArgumentException（

                        String.format（“无效的罗马字符％s”，

                                getCharValue（roman，index）））;

            }

        }

        回报;

    }

通过改进这一行，我们可以节省几个无用的CPU周期：

 previous = index == 0？ 0：getSymboleValue（roman，index  -  1）;

我们不必获取前一个字符，因为前一个字符只是for循环结束时的当前字符。我们可以删除这一行并将其替换为previous = current;在其他条件结束后计算。

运行测试用例应该为我们带来绿色。

现在我们将简化计算以丢弃另外几个无用的计算周期。我将还原if语句测试用例的计算，并反转for循环。最终的代码应该是：

for（int index = roman.length（） -  1; index> = 0; index--）{

            if（doesSymbolsContainsRomanCharacter（roman，index））{

                current = getSymboleValue（roman，index）;

                 if（当前<上一个）{

                    sum  -  = current;

                } else {

                    sum + = current;

                }

                previous = current;

            } else {

                抛出新的IllegalArgumentException（

                        String.format（“无效的罗马字符％s”，

                                getCharValue（roman，index）））;

            }

运行测试用例，该测试用例应该再次为绿色。

由于该方法不会更改任何对象状态，因此我们可以将其设置为静态方法。此外，该类是一个实用程序类，因此应该关闭它以进行继承。虽然所有方法都是静态的，但我们不应该允许实例化类。通过添加私有默认构造函数来修复此问题，并将该类标记为final。

现在我们将在测试类中出现编译错误。一旦我们解决了这个问题，运行所有测试用例应该会再次让我们变绿。

第18步

最后一步是添加更多测试用例，以确保我们的代码涵盖所有要求。

1. 添加一个convertX（）测试用例，它应该返回10作为X = 10.如果我们运行测试，它将失败并返回IllegalArgumentException，直到我们将X = 10添加到符号映射。再次运行测试，我们将变绿。这里没有重构。
2. 添加convertIX（）测试用例，它应该返回9，因为IX = 9.测试将通过。
3. 添加到符号映射这些值：L = 50，C = 100，D = 500，M = 1000。
4. 添加一个convertXXXVI（）测试用例，它应该返回36作为XXXVI = 36.运行测试，它将通过。这里没有重构。
5. 添加一个convertMMXII（）测试用例，它应该返回2012，运行测试，它将通过。这里没有重构。
6. 添加convertMCMXCVI（）测试用例，它应该返回1996.运行它将通过的测试。这里没有重构。
7. 添加一个convertInvalidRomanValue（）测试用例，它应该抛出IllegalArgumentException。运行测试，它将通过。这里没有重构。
8. 添加一个convertVII（）测试用例，它应该返回7作为VII = 7.但是当我们用小写的vii尝试它时，测试它将失败并带有IllegalArgumentException，因为我们只处理大写字母。要解决这个问题，我们添加了一行roman = roman.toUpperCase（）;在方法的开头。再次运行测试用例，它将为绿色。这里没有重构。
9. 在这一点上，我们完成了我们的艺术（实施）。考虑到TDD，我们需要最少的代码更改来传递所有测试用例并通过重构满足所有要求，从而确保我们具有出色的代码质量（性能，可读性和设计）。

我希望你和我一样喜欢这个，并鼓励你在下一个项目甚至手头的任务中开始使用TDD。请通过分享，喜欢文章，并在GitHub上的代码中添加星号来帮助传播这个词。

 

关于作者

Mohamed Taman是高级企业架构师@Comtrade数字服务，Java冠军，Oracle开创性大使，采用Java SE.next（），JakartaEE.next（），JCP成员，JCP执行委员会成员，JSR 354,363＆ 373专家组成员，EGJUG领导者，Oracle埃及建筑师俱乐部董事会成员，讲Java，热爱移动，大数据，云，区块链，DevOps。 国际演讲者，书籍和视频作者“JavaFX essentials”，“清洁代码入门，Java SE 9”和“动手实践Java 10编程与JShell”，以及一本新书“Java冠军的秘密”， 赢得Duke的2015年，2014年奖项和JCP杰出的采用参与者2013年奖项。

 

原文:https://www.infoq.com/articles/test-driven-design-java

讨论: 知识星球【数字化和智能转型】

在软件工程中，行为驱动开发（BDD）是一种敏捷软件开发过程，它鼓励开发人员，QA和软件项目中的非技术或业务参与者之间的协作。[1] [2] [3]它鼓励团队使用对话和具体的例子来形式化对应用程序应该如何表现的共同理解。[4]它来自于测试驱动开发（TDD）。[1] [2] [5] [6] [模糊] [7]行为驱动开发将TDD的一般技术和原理与域驱动设计和对象的思想相结合面向分析和设计，为软件开发和管理团队提供共享工具和共享流程，以协作进行软件开发。[2] [7]

虽然BDD主要是关于如何通过商业利益和技术洞察来管理软件开发的想法，但BDD的做法确实假设使用专门的软件工具来支持开发过程。[5]虽然这些工具通常专门用于BDD项目，但它们可以被视为支持测试驱动开发的工具的专用形式。这些工具用于为无处不在的语言添加自动化，这是BDD的核心主题。

通过使用可以表达行为和预期结果的自然语言构造（例如，类似英语的句子）的简单领域特定语言（DSL），BDD在很大程度上得到了促进。测试脚本长期以来一直是DSL的流行应用，具有不同程度的复杂性。 BDD被认为是一种有效的技术实践，尤其是当要解决的业务问题的“问题空间”很复杂时。

历史

行为驱动的开发是测试驱动开发的扩展：[9]开发利用了一种简单的，特定于域的脚本语言。这些DSL将结构化自然语言语句转换为可执行测试。结果是与给定函数的验收标准和用于验证该功能的测试的关系更密切。因此，它通常是TDD测试的自然延伸。

BDD专注于：

1. 从哪里开始
2. 测试什么和不测试什么
3. 一次性测试多少钱
4. 怎么称呼测试
5. 如何理解测试失败的原因

从本质上讲，BDD正在重新思考单元测试和验收测试的方法，以避免自然产生的问题。例如，BDD建议单元测试名称是以条件动词开头的整个句子（例如英语中的“should”），并且应按商业价值的顺序编写。验收测试应该使用用户故事的标准敏捷框架编写：“作为[角色]我想要[特征]以便[好处]”。接受标准应根据情景编写并作为类实现：给定[初始上下文]，[事件发生]，然后[确保一些结果]。

从这一点开始，许多人在几年内开发了BDD框架，最终将其构建为开发人员，QA以及软件项目中的非技术或业务参与者的通信和协作框架。[10]在2009年11月伦敦的“敏捷规范，BDD和测试交换”期间，Dan North [11]对BDD进行了以下描述：

BDD是第二代，从外到内，基于拉动，多利益相关方，多规模，高自动化，敏捷的方法。它描述了与明确定义的输出相互作用的循环，从而提供了重要的可运行的，经过测试的软件。

在2013年GOTO会议上与Dan North的访谈中，Liz Keogh [12]将BDD定义为：

它使用示例来讨论应用程序的行为方式......以及有关这些示例的对话。 [13]

Dan North创建了一个BDD框架，JBehave，然后是Ruby的故事级BDD框架，名为RBehave [14]，后来被整合到RSpec项目中。[15]他还与David Chelimsky，AslakHellesøy和其他人合作开发了RSpec，并撰写了“RSpec书籍：RSpec，Cucumber和Friends的行为驱动开发”。 RSpec的第一个基于故事的框架后来被主要由AslakHellesøy开发的Cucumber取代。 Capybara是Cucumber测试框架的一部分，是一种基于Web的测试自动化软件。

BDD的原则

测试驱动开发是一种软件开发方法，它基本上表明对于每个软件单元，软件开发人员必须：

1. 首先为单位定义一个测试集;
2. 使测试失败;
3. 然后实施该单位;
4. 最后验证单元的实现是否使测试成功。

该定义非常具体，因为它允许根据高级软件需求，低级技术细节或其间的任何内容进行测试。因此，看待BDD的一种方式是TDD的持续发展，它比TDD做出更具体的选择。

行为驱动的开发规定，任何软件单元的测试都应根据单元的期望行为来规定。[5] [7] [1]借助敏捷软件开发，在这种情况下，“期望的行为”包括业务设定的要求 - 即，对正在建设的软件单元委托的任何实体具有商业价值的期望行为。[5] [1]在BDD实践中，这被称为BDD是一种“从外到内”的活动。[16]

行为规范

根据这一基本选择，BDD做出的第二个选择涉及如何指定所需的行为。在这一领域，BDD选择使用半正式格式进行行为规范，这种格式借鉴了面向对象分析和设计领域的用户故事规范。这种格式的场景方面可以被视为Hoare逻辑应用于使用情境的域语言的软件单元的行为规范。

BDD指定业务分析师和开发人员应该在这个领域进行协作，并且应该根据用户故事指定行为，每个用户故事都明确记录在专用文档中。[1] [16]每个用户故事都应该以某种方式遵循以下结构：[5] [16]

标题：故事应该有清晰明确的标题。

叙述

一个简短的介绍部分，详细说明

• 谁（who):(哪个企业或项目角色）是故事的驱动者或主要利益相关者（从故事中获得商业利益的演员）
• 什么(how)：影响利益相关者想要的故事
• 原因(why)：利益相关者的商业价值将来自这种效应

验收标准或方案

对叙述的每个具体情况的描述。这种情况具有以下结构：

• 它首先指定在场景开始时假定为true的初始条件。这可能包含一个或多个子句。
• 然后它会说明哪个事件触发了场景的开始。
• 最后，它在一个或多个条款中陈述了预期的结果。

BDD对于如何写下这些用户故事没有任何正式要求，但它确实坚持使用BDD的每个团队都提出了一种简单，标准化的格式来记录用户故事，其中包括上面列出的元素。[5 ] [16]然而，2007年Dan North提出了一个文本格式的模板，该模板在不同的BDD软件工具中得到了广泛的应用。[16]这种格式的一个非常简短的例子可能如下所示：

故事：返回库存

作为店主

为了跟踪库存

我想在退货时将商品添加回库存。

场景1：退款项目应退回库存

鉴于客户以前从我那里买过一件黑色毛衣

并且 我有三件黑色毛衣。

当他们退回黑色毛衣退款

然后我应该有四件黑色毛衣。

场景2：替换项目应返回库存

鉴于客户以前从我那里买过蓝色服装

并且我有两件蓝色服装库存

并且还有三件黑色服装现货。

当他们将蓝色衣服换回黑色替换件时

然后我应该有三件蓝色服装库存

并且还有两件黑色服装现货。

理想情况下，这些场景是以声明方式而非命令性方式表达的 - 在商业语言中，没有引用交互发生的UI元素。[17]

此格式称为Gherkin语言，其语法类似于上面的示例。然而，Gherkin这个术语特定于Cucumber，JBehave，behave和Behat软件工具。[18] [19] [20] [21]

规范作为普遍存在的语言

行为驱动的开发借用了域驱动设计中普遍存在的语言的概念。[5] [7]无处不在的语言是一种（半）正式语言，由软件开发团队的所有成员共享 - 软件开发人员和非技术人员。[22]所讨论的语言都是由所有团队成员使用和开发的，作为讨论相关软件领域的常用手段。[22]通过这种方式，BDD成为软件项目中所有不同角色之间进行通信的工具。[5] [23]

软件开发的一个共同风险包括开发人员和业务利益相关者之间的沟通中断。[24] BDD使用所需行为的规范作为项目团队成员的普遍使用的语言。这就是BDD坚持使用半正式语言进行行为规范的原因：一些形式是成为普遍存在的语言的必要条件。[5]此外，拥有这样一种无处不在的语言会创建一个规范的域模型，因此可以正式推理出规范。[25]此模型也是可用的不同BDD支持软件工具的基础。

上面给出的示例为正在开发的软件系统建立用户故事。此用户故事标识了利益相关者，业务效果和业务价值。它还描述了几种情景，每种情景都有前提条件，触发条件和预期结果。这些部分中的每一部分都由语言的更正式部分确定（例如，术语Given可能被视为关键字），因此可以通过理解普遍存在的语言的正式部分的工具以某种方式处理。

大多数BDD应用程序使用基于文本的DSL和规范方法。然而，集成场景的图形建模也已成功应用于实践中，例如用于测试目的。 [26]

 

专业的工具支持

与测试驱动的设计实践非常相似，行为驱动的开发假定在项目中使用专门的支持工具。尽管BDD在很多方面都是更具体的TDD版本，但BDD的工具类似于TDD的工具，但对开发人员的要求比基本的TDD工具要多。[需要澄清] [引证需要]

工具原理

原则上，BDD支持工具是软件的测试框架，非常类似于支持TDD的工具。但是，在允许指定测试的TDD工具往往是完全自由格式的情况下，BDD工具与前面讨论的普遍存在的语言的定义相关联。

正如所讨论的，无处不在的语言允许业务分析师以开发人员也能理解的方式写下行为需求。 BDD支持工具的原理是使这些相同的需求文档可以直接作为一组测试来执行。如果由于与能够执行规范的技术工具相关的原因而无法实现这一点，那么必须改变编写行为要求的风格或者必须改变工具。[27]行为要求的确切实现因工具而异，但敏捷实践提出了以下一般过程：

1. 工具读取规范文档。
2. 工具直接理解普遍存在的语言的完整形式部分（例如上面例子中的Given关键字）。基于此，该工具将每个场景分解为有意义的子句。
3. 场景中的每个单独子句都转换为某种参数，用于测试用户素材。这部分需要软件开发人员针对特定项目的工作。
4. 然后，框架使用该场景中的参数为每个场景执行测试。

Dan North开发了许多支持BDD的框架（包括JBehave和RBehave），其操作基于他建议用于记录用户故事的模板。[5]这些工具使用了用例的文本描述，其他几个工具（如CBehave）也遵循了这些描述。但是，此格式不是必需的，因此还有其他工具也使用其他格式。例如，Fitnesse（围绕决策表构建）也被用于推出BDD。[28]

 

工具示例

对于不同的平台和编程语言，当今的项目中使用了几种不同的BDD软件工具示例。

可能最着名的是JBehave，它由Dan North，Elizabeth Keogh和其他几位人员开发。[29]以下是该项目的一个例子：[19]

考虑一下生命游戏的实现。域专家（或业务分析师）可能希望指定当某人设置游戏网格的起始配置时应该发生什么。要做到这一点，他可能想举例说明切换单元格的人采取的一些步骤。跳过叙述部分，他可以通过将以下场景写入纯文本文档（这是JBehave读取的输入文档的类型）来完成此操作：

Given a 5 by 5 game

When I toggle the cell at (3, 2)

Then the grid should look like

.....

.....

.....

..X..

.....

When I toggle the cell at (3, 1)

Then the grid should look like

.....

.....

.....

..X..

..X..

When I toggle the cell at (3, 2)

Then the grid should look like

.....

.....

.....

.....

..X..

粗体字不是输入的一部分;它包括在这里，以显示哪些单词被识别为正式语言。 JBehave识别术语Given（作为定义场景开始的前提条件），When（作为事件触发器）和Then（作为后置条件，必须验证为触发后的动作的结果）。基于此，JBehave能够读取包含场景的文本文件并将其解析为子句（设置子句，然后是具有可验证条件的三个事件触发器）。然后JBehave接受这些子句并将它们传递给能够设置测试，响应事件触发器和验证结果的代码。此代码必须由项目团队中的开发人员编写（在Java中，因为这是JBehave所基于的平台）。在这种情况下，代码可能如下所示：

private Game game;
private StringRenderer renderer;

@Given("a $width by $height game")
public void theGameIsRunning(int width, int height) {
    game = new Game(width, height);
    renderer = new StringRenderer();
    game.setObserver(renderer);
}
    
@When("I toggle the cell at ($column, $row)")
public void iToggleTheCellAt(int column, int row) {
    game.toggleCellAt(column, row);
}

@Then("the grid should look like $grid")
public void theGridShouldLookLike(String grid) {
    assertThat(renderer.asString(), equalTo(grid));
}

代码具有针对场景中每种类型的子句的方法。 JBehave将通过使用注释来识别哪个方法与哪个子句一起使用，并在运行场景时按顺序调用每个方法。场景中每个子句中的文本应该与该子句的代码中给出的模板文本相匹配（例如，场景中的给定后面应该是“X by Y游戏”形式的子句） 。 JBehave支持将子句与模板匹配，并内置支持从模板中挑选术语并将它们作为参数传递给测试代码中的方法。测试代码为场景中的每个子句类型提供实现，该场景与正在测试的代码交互并基于场景执行测试。在这种情况下：

1. theGameIsRunning方法通过设置初始游戏网格对Given子句做出反应。
2. iToggleTheCellAt方法通过触发子句中描述的toggle事件来响应When子句。
3. theGridShouldLookLike方法通过将游戏网格的状态与场景中的预期状态进行比较来对Then子句做出反应。

此代码的主要功能是成为具有故事的文本文件和正在测试的代码之间的桥梁。请注意，测试代码可以访问正在测试的代码（在本例中是Game的实例），并且本质上非常简单。测试代码必须简单，否则开发人员最终不得不为他的测试编写测试。

最后，为了运行测试，JBehave需要一些管道代码来识别包含场景的文本文件，并将依赖项（如Game的实例）注入测试代码。此管道代码未在此处说明，因为它是JBehave的技术要求，并不直接与BDD样式测试的原理相关。

 

故事与规范

行为驱动开发的单独子类由使用规范作为输入语言而非用户故事的工具形成。这种风格的一个例子是RSpec工具，它最初也是由Dan North开发的。规范工具不将用户故事用作测试场景的输入格式，而是使用正在测试的单元的功能规范。这些规范通常比用户故事具有更多的技术性质，与用户故事相比，与业务人员的沟通通常不太方便。[5] [30]堆栈规范的示例可能如下所示：

Specification: Stack

When a new stack is created
Then it is empty

When an element is added to the stack
Then that element is at the top of the stack

When a stack has N elements 
And element E is on top of the stack
Then a pop operation returns E
And the new size of the stack is N-1

这样的规范可以准确地指定被测试组件的行为，但对业务用户来说意义不大。因此，基于规范的测试在BDD实践中被视为基于故事的测试的补充，并且在较低级别上运行。规范测试通常被视为自由格式单元测试的替代品。[30]

RSpec和JDave等规范测试工具在性质上与JBehave等工具略有不同。由于它们被视为JUnit等基本单元测试工具的替代品，因此这些工具倾向于放弃故事和测试代码的分离，而更喜欢将规范直接嵌入到测试代码中。例如，散列表的RSpec测试可能如下所示：[31]

describe Hash do
  let(:hash) { Hash[:hello, 'world'] }

  it { expect(Hash.new).to eq({}) }

  it "hashes the correct information in a key" do
    expect(hash[:hello]).to eq('world')
  end

  it 'includes key' do
    hash.keys.include?(:hello).should be true
  end
end

此示例显示嵌入可执行代码中的可读语言的规范。在这种情况下，工具的选择是通过添加名为it和should的方法将规范语言形式化为测试代码的语言。还有一个规范前提条件的概念 - 前一节确定了规范所基于的前提条件。

测试结果将是：

 Hash
   should eq {}
   includes key
   hashes the correct information in a key

 

三个朋友

Three Amigos，也称为“规范研讨会”，是产品负责人以QA和开发团队等不同利益相关者的形式通过实例讨论要求的会议。这次讨论的关键目标是触发对话并认真识别任何缺失。讨论还为QA，开发团队和产品所有者提供了一个平台，汇集和听取彼此的观点，以丰富需求，并确保我们是否正在构建正确的产品。软件工程中的三个Amigos一词是由George Dinwiddie创造的[32]

The three Amigos are

• Business
• Development
• Testing

示例映射

示例映射由Matt Wynne介绍。[33]他创造了一种技术，可以在30分钟内引导对话分解任何产品积压物品。主要目标是从故事中获取规则，并为每个规则提取不同的情景。[34]

SHE QC

SHE QC修饰[35]是另一种将复杂的用户故事整理成场景的技巧。整理结构经过优化，可以在团队成员之间进行正确且集中的对话，包括业务，运营，开发和QA。这个过程涉及头脑风暴的双钻石规则[36]，本次会议的结果是一套未回答的问题和故事场景。这种做法的结构和时间安排，有助于团队每天不断改进故事。[37]

See also[edit]

• Specification by Example
• Behat (PHP framework)
• Cynefin framework
• Concordion (Java framework)
• Cucumber (originally a Ruby framework, also available for Java, JavaScript and other languages)
• Gauge (software)
• Jasmine (JavaScript testing framework)
• Squish GUI Tester (BDD GUI Testing Tool for JavaScript, Python, Perl, Ruby and Tcl)
• Use case

原文：https://en.wikipedia.org/wiki/Behavior-driven_development

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

在当今最先进的测试团队中，行为驱动的开发正在快速发展。尽管百分比仍然相对较小，但研究表明，BDD团队的数量几乎翻了一番，仅在一年内达到16％。

以下成熟度模型旨在帮助您评估团队在BDD成熟历程中的进展。本指南将为您提供一个框架，帮助您了解您的团队现在正在走向BDD成熟的道路，并帮助您制定直接课程，将其提升到新的水平。向BDD过渡往往会带来重大障碍，但根据我们的经验，这是值得的。具有成熟BDD实践的团队报告了跨职能部门的更高级别的协作，并且在他们的DevOps发布流程中往往更加先进。通过将测试留给BDD，这些团队在不牺牲质量的情况下提供更快的速度。

通过下载此电子书，您将学习：

 

• 五个BDD成熟度级别基于我们在用户群和整个行业中看到的采用模式
• 在QA团队内外实现BDD所需的重大流程变更的策略
• 您的团队今天所处的位置以及将使您达到BDD成熟度的下一个级别的里程碑

原文:https://www.qasymphony.com/landing-pages/bdd-maturity-model/

讨论请加入知识星球：【数字化和智能转型】

Evosoft Hungary Kft的产品专家CsabaSzökőcs表示，基于风险的测试可以提高交付故事的质量，并帮助系统测试人员成为Scrum团队的一员。在TestCon Moscow 2019，他解释了他们如何通过将其作为sprint计划和完成定义的一部分来适应经典的基于风险的测试以适应他们的敏捷实现。

Szökőcs介绍了他如何支持团队将测试活动从迭代结束到开始。几年前，当他们转向Scrum时，他们的开发团队并不真正知道如何提供经过全面测试的用户故事，并且不知道“潜在可交付”的含义。他们习惯于每年发布一次或两次，以及需要几个月的“系统测试”阶段（也就是“bug修复”）。现在有了Scrum，他们试图提供没有错误的故事，因此他们在新成立的Scrum团队中引入了更多的测试活动。

由于团队的测试经验较少，他们尝试使用已知的方法：在sprint开始时创建一个小设计，实现它，完成后测试它。 Szökőcs解释说，它是冲刺内部的迷你瀑布模型，与普通的瀑布模型具有相同的问题。

如果我们在测试期间发现了一个更大的问题，通常已经为时已经太晚了，无法正确修复它，我们不得不承担后果：接受错误并在以后修复它，减少故事的范围或引入快速解决方案。技术债务成本。这些都不好。

Szökőcs提到他已经在一个架构研讨会上学习了基于风险的测试，并且认为它可以对他们的Scrum团队有用。他们通过收集每个用户故事的风险进行尝试，然后再计划进入冲刺阶段。这有助于他们在故事实施之前考虑测试活动，并避免许多问题而不是对它们做出反应。他们很早就参与了系统测试员的同事，以便从他们的经验中受益。

Szökőcs说，基于风险的测试极大地改变了冲刺期间故事的处理方式，并提高了交付故事的质量。此外，对于系统测试人员来说，这也非常具有动力，因为他们能够影响故事的最终实现方式，他说。许多这些系统测试人员现在都是Scrum团队的一员。

“我们在一些Scrum团队中使用基于风险的测试，但不是在所有地方;一些团队已经尝试过，他们已经使用了很长时间，有些团队不是”，Szökőcs说。他提到他们已经将经典的基于风险的测试应用于他们的Scrum流程，以便更好地适应他们的敏捷实施。

Szökőcs说，通常基于风险的测试是在测试团队中完成的，以便在他们只有很短的测试时间时找到最有价值的测试。在Scrum团队中，他们正在针对几乎每个用户故事或史诗进行单独且独立的基于风险的测试;这是故事定义的一部分，故事的风险被收集和优先考虑。作为改进的一部分，他们正在收集风险，涉及特定主题的一些专家（系统测试人员，建筑师，产品所有者）。他们说，有时他们也会在系统中发现一些已经存在的错误，有时候他们也需要改变用户的故事，用一些特殊情况扩展验收标准，或者分割出非常棘手的方案。

收集风险后，两位同事根据风险的概率和损害优先排序，给每个人一个1到5之间的数字。乘以这些数字将提供风险暴露; Szökőcs说，所有高风险的风险都必须以某种方式处理。

他还提到，另外，经验丰富的测试人员会估算每种风险的测试有效性，并回答通过测试来处理这种风险有多容易？这也在1到5的范围内指定，其中1是不可能测试的，5是显而易见的。将这些数字乘以曝光将产生测试优先级编号（范围为1到125）。数字越大表示风险影响越大且易于测试，因此它具有最大的价值。 Szökőcs认为，较低的数字表示难以测试的低影响风险，因此最好忽略它，因为它没有实际价值。

优先排序有助于团队创建一个测试策略，其中包含针对具有最大影响的风险的有价值测试，而不是仅测试快乐的一天场景。 Szökőcs说，他们可以利用优先级来决定他们将测试特定风险的级别。

InfoQ在2017年莫斯科TestCon会谈后与CsabaSzökőcs进行了交谈。

InfoQ：您从Evosoft优先考虑风险的方式中学到了什么？

CsabaSzökőcs：首先，优先顺序是可选的。如果我们完全跳过它，那么收集风险仍然非常有价值。有些团队正在以这种方式工作，他们对此很满意。

其次，不要过度思考优先顺序。我们通常这样做：尝试找到数字最小的风险并给它一个1，然后是最高数字的风险并给它一个5.所有其他风险可以在很短的时间内迅速优先考虑。

第三，测试优先级确实有助于团队找到最有价值的故事测试，这可以提高所交付用户故事的整体质量。

InfoQ：你如何收集风险？

Szökőcs：我们通过回答“这个故事中可能出现什么问题？”的问题，在用户故事的背景下收集风险。

此外，我们试图想象新功能已经在运行并考虑不同的场景;如何使用或滥用。我们尝试将新功能与其他现有功能相结合 - 它能以某种方式出错吗？

还可以检查不同的非功能性要求，如性能，可用性和安全性;如果他们受到影响，他们会在这个故事中出错吗？如果系统负载很高，会出现什么问题？如果系统以某种方式变得不一致怎么办？

为了找到有价值的风险（不仅仅是不可能的情况），我们通常邀请该特定领域的专家：系统测试人员，或其他团队的架构师或产品所有者。这也是对他们的激励，因为他们也可以在团队实施任何事情之前对故事产生影响。

值得一提的是，我们并未收集项目风险，例如当团队中的某人生病或我们的预算不足时会发生什么。另外，我们不收集测试用例;我们可以只用一个测试用例来覆盖几个风险，或者我们只需要对一个风险进行多次测试。测试用例来自最重要的风险。

InfoQ：您进行基于风险的测试有哪些提示？

Szökőcs：试一试; 从简单开始，逐步改进。

一开始，如果您在每个用户故事中收集一些风险作为优化过程的一部分就足够了，并将它们记录在一个简单的列表中。 这将有助于团队感受故事的痛点并专注于他们。

之后，尝试邀请一些经验丰富的同事参加那次会议，收集风险。

如果您已经习惯了这一点，也可以尝试优先级。 看看这是否有助于团队定义更好或更有价值的测试用例。

不要将风险收集会议强制性或太长时间 - 团队可能已经超负荷召开会议; 他们不需要另一个。 与感兴趣的团队成员一起做，并让其他人完全跳过这个; 他们可以稍后查看结果。

最后：保持简单。 最有价值的是关于风险的讨论; 别忘了。

 

工作中的人渴望上下文，渴望知道他们所做的事情有助于更大的整体。

-Daniel Pink

 

愿景

愿景描述了正在开发的解决方案的未来状态。它反映了客户和利益相关方的需求，以及为满足这些需求而提出的功能和功能。

愿景既有抱负又有可实现，为开发中的解决方案提供了更广泛的背景 - 概述和目的。它描述了市场，客户群和用户需求。它为新功能，非功能需求（NFR）和其他工作设置了边界和上下文。

该愿景适用于任何级别的SAFe，这解释了为什么它在Spanning Palette上。虽然其重点通常放在解决方案上，但投资组合愿景也很明显，反映了价值流如何合作以实现企业目标。敏捷发布列车（ART）和敏捷团队也可以有自己的愿景来沟通他们在开发解决方案中的作用。

细节

很少有人质疑Lean-Agile关注近期可交付成果和快速价值交付的好处，这有利于将决策推迟到最后的责任时刻并限制在制品（WIP）。它还避免了Big Design Upfront（BDUF），面向未来的架构以及过于详细的计划。行动的偏见是无可替代的。 （“让我们建立它，然后我们就会知道。”）

但是，在大型解决方案的背景下，每个贡献者都会做出许多决定。因此，不断开发，维护和沟通愿景对于创建对计划目标的共同理解至关重要，尤其是当这些想法因不断变化的市场需求和业务驱动因素而发展时。

组合愿景

投资组合愿景以实用和鼓舞人心的方式为近期决策设定了长期背景。 （“这是值得做的事情。”）了解长期视图有助于敏捷团队在短期和长期内对功能开发做出更明智的选择。

Portfolio Canvas是开发投资组合愿景的关键输入。画布的主要用途之一是记录投资组合的当前状态。当前状态画布表示组合的现状，使组织在结构，目的和状态上保持一致。下一步是设想未来状态，这有助于确定投资组合的愿景。

精益敏捷领导者负责制定公司的战略方向，并为实施该战略的团队建立使命。 Switch将此视图称为“目标明信片”，如图1所示[1]。

图1.投资组合愿景是企业级的“未来明信片”。

投资组合愿景具有以下特征：

•     有抱负的，现实的和可实现的 - 它必须具有吸引力且有些未来感，但实用性足以在一段有意义的时间范围内可行
•     激励他人参与旅程 - 愿景必须与战略主题以及个人团队的目标保持一致

业务所有者（或C级管理人员）通常在计划增量（PI）计划活动期间提供此长期视图和业务环境。这些领导者可以激励和调整团队，增加他们的参与度并培养他们的创造力，以达到最佳效果。

解决方案愿景

产品和解决方案管理部门负责将产品组合愿景转化为解决方案愿景，指出所选解决方案背后的原因和方向。这样做需要询问和回答具体问题：

1.     这个新解决方案会做什么？
2.     它会解决什么问题？
3.     它将提供哪些功能和好处？
4.     它会为谁提供？
5.     它将提供哪些非功能性要求？

解决方案愿景的输入

产品和解决方案管理直接与业主和其他利益相关者合作，综合所有输入并将其整合为整体和凝聚力的愿景，如图2所示。这些输入包括以下资源：

图2.解决方案视觉输入源

•     客户 - 客户提供快速反馈，并对所需内容有深入了解
•     战略主题 - 战略主题提供指导并作为决策过滤器
•     投资组合画布 - 投资组合画布提供投资组合的当前状态和所需的未来状态
•     解决方案上下文 - 解决方案上下文指示解决方案如何与客户的上下文交互
•     解决方案积压 - 解决方案积压为愿景提供方向和指导
•     解决方案意图 - 解决方案意图包含一些愿景，并且是新元素的目标
•     架构师/工程师 - 系统和解决方案架构师/工程师支持Architectural Runway的不断发展，支持当前和近期功能
•     敏捷团队 - 最后，不要忘记显而易见的，该领域最重要的专家通常是敏捷团队本身
•     产品所有者 - 产品所有者不断将新出现的需求和机会传达回项目愿景。

在解决方案意图中捕捉愿景

鉴于SAF基于节奏的面对面PI计划的实践，视觉文献（其中的各种形式可以在[2]，[3]和[4]中找到）通过滚动来增强并有时被替换 - 波视觉简报。这些为团队提供了短期和长期愿景的例行定期演示。在PI规划期间，大型解决方案级别的利益相关者（如解决方案管理）描述当前的整体解决方案愿景，而产品管理则提供特定的敏捷发布培训（ART）背景和愿景。

在解决方案意图中捕获了愿景的相关元素以及系统的当前和特定行为的细节。

计划愿景

当使用完全SAFe或大型解决方案SAFe时，每个ART都可能有自己的愿景，详细说明它产生的特定功能或子系统的方向。该愿景应与其支持的解决方案愿景紧密结合。

路线图视图

有方向感对规划和参与至关重要。但除非有一些关于团队如何实现愿景的现实计划，否则人们实际上不会知道他们必须做什么。路线图填补了这一目的。图3提供了一个示例。

图3.路线图是愿景的一部分

PI规划愿景 - 十大特色

路线图确实很有帮助。但是对于行动和执行，必须立即采取措施。产品和解决方案管理部门有责任为后续步骤提供指导。在SAFe上下文中，这转换为一系列递增步骤，一次一个PI，一次一个特征，如图4所示。

图4.通过“前十大特征”，一次实现一个PI

下一个PI“

为实现此目的，产品管理使用加权最短作业优先（WSJF）不断更新功能优先级。然后，在PI计划期间，他们向团队展示前10名。团队不会对新列表感到惊讶，因为他们已经看到视觉随着时间的推移而发展，并且意识到了新的功能。此外，计划看板用于探索特征的范围，其利益假设和验收标准，因此当特征到达此边界时，它们的形成和检查相当完善。建筑师/工程部已经对它们进行了审查，并且已经实施了各种启动器。

但是，每个人都理解前十名是输入，而不是计划过程的输出，下一个PI可以实现的目标是容量限制，依赖关系，规划期间出现的知识等等。只有团队才能规划并致力于行动方案，这一方案在PI目标中进行了总结。

但这些功能已准备好实施。该功能以功能为特色，向前迈进，实现愿景。

解决方案管理在Pre-PI Planning期间提供类似的前10个功能列表，以便在解决方案培训中对齐ART。

学到更多

 

1. [1] Heath，Chip和Dan Heath。开关：变革困难时如何改变事物。百老汇书籍，2010年。
2. [2] Leffingwell，Dean。敏捷软件要求：团队，计划和企业的精益需求实践。 Addison-Wesley，2011年。
3. [3] Leffingwell，Dean。扩展软件敏捷性：大型企业的最佳实践。艾迪生 - 韦斯利，2007年。
4. [4] Leffingwell，Dean和Don Widrig。管理软件要求。 Addison-Wesley，2001年。

 

原文：https://www.scaledagileframework.com/vision/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

语境是关键 - 从中可以理解一切。

-Kenneth Noland

解决方案背景

解决方案上下文确定解决方案的操作环境的关键方面。它提供了对解决方案本身的要求，使用，安装，操作和支持的基本理解。解决方案环境严重影响按需释放的机会和约束。

了解解决方案背景对于价值交付至关重要它影响开发优先级，解决方案意图，功能，功能和非功能需求（NFR）。它为Continuous Delivery Pipeline和其他解决方案级别的按需发布活动提供了机会，限制和约束。

解决方案环境通常由开发解决方案的组织控制之外的因素驱动。解决方案与其上下文之间的耦合程度通常代表架构和业务挑战，即在灵活性与环境之间紧密耦合的交互之间找到适当的平衡 - 通常跨越内部，供应商和客户组织边界的交互。

细节

很少有系统专为自己使用而建造;相反，它们是为其他人构建的，无论它们是内部运营的价值流还是外部客户。这意味着没有任何一个人通常控制或完全理解系统部署和使用的完整上下文。相反，系统在与开发系统不同的环境中运输，部署，安装和维护。即使在内部IT系统的情况下，新开发的系统通常由IT维护和运营团队托管。在这种情况下，由于许多原因，生产环境可能与开发环境不同（请参阅DevOps文章）。因此，了解解决方案背景对于降低风险和实现目标适用性至关重要。

了解解决方案和解决方案意图并使其与解决方案环境保持一致需要经常与客户进行交互。客户了解愿景，并在解决方案背景方面拥有必要的决策权。如图1所示，需要协作。

图1.解决方案意图和上下文相互通知

协作水平在很大程度上取决于解决方案与其环境之间的耦合程度。

为确保这种一致性，客户应尽可能频繁地参与计划增量（PI）计划（以及适用的PI前后规划）和解决方案演示。客户应定期将解决方案集成到其上下文中。这种定期的交互和集成节奏允许基于正确的假设构建解决方案增量，并在客户环境中提供结果验证。双方都在调整背景以实现最佳经济效益方面发挥作用（见“经济框架”文章）。

解决方案上下文驱动解决方案意图

客户的上下文推动了需求，并对设计和实施决策施加了限制。许多这些上下文要求是不可协商的（通常由合规性问题驱动），如果不包括在内，可能会使解决方案无法使用。这些要求属于解决方案意图的固定类别。解决方案上下文的许多方面表现为非功能需求（NFR），并且需要作为解决方案增量的“完成定义”的一部分包含在内。

解决方案上下文还可以规定解决方案意图必须解决的特定内容。在系统的分层系统中，系统意图也可以是分层相关的（参见解决方案意图中的“系统意图系统”部分）。系统上下文定义了如何组织，打包和集成解决方案意图以供客户使用以满足任何合规性，认证和其他目标。

固定与演进解决方案背景

一些解决方案环境是建立的客户环境，解决方案必须简单地适应（例如，“这是我们的系统工作的方式;你必须适应这里”）。在这种情况下，通过解决方案意图对解决方案强加所有解决方案上下文要求。

但是，在许多情况下，新的解决方案可能需要客户部署环境的发展，需要跟踪这些更改。在这种情况下，主动跟踪这些更改非常重要，因为系统和部署环境都必须演变为通用状态。在后一种情况下，固定与变量思维以及通过多个可能可行的解决方案上下文保留选项（请参阅解决方案意图中的“从变量转换为固定解决方案意图”部分）是管理风险的工具。简而言之，更加可变和不断发展的解决方案环境需要更多持续协作。

 

解决方案上下文的类型

了解客户的解决方案上下文有助于确定其系统在其最终操作环境中的打包和部署方式。解决方案上下文的示例可能包括以下环境：

•     系统系统（例如航空电子系统作为飞机的一部分），产品套件（例如，文字处理器作为办公套件的一部分）
•     IT部署环境（例如，部署解决方案的云环境）
•     在不同使用模式中使用的单一解决方案（例如，可以经济地飞行国内和国际航线的单个客机）

系统的系统的解决方案背景

大型系统系统环境中的供应商与客户之间的关系解决方案是一个独特的，层叠的问题，如图2所示。

图2.解决方案上下文包含在系统系统中

供应链中的每个组织都会根据客户的上下文提供解决方案，该解决方案指定了解决方案的打包，部署和集成方式。反过来，该客户为其客户提供上下文解决方案，等等。例如，在图2中，车辆导航系统供应商首先在信息娱乐供应商的上下文中操作，然后在车辆制造商的上下文中操作，最后在消费者的上下文中操作。所有这些上下文都会影响解决方案的可行性，因此必须了解完整的端到端价值链。

IT部署环境的解决方案上下文

在开发供内部使用的软件解决方案时，客户可能是内部的，但是将解决方案提供给生产环境仍然需要上下文。部署必须考虑特定接口，部署的操作系统，防火墙，API到其他应用程序，托管或云基础架构等，如图3所示。

图3.内部IT部署的解决方案上下文

尽可能将部署作为例程是DevOps和持续交付管道的主要目的。

在此示例中，新的客户关系管理（CRM）系统应反映所需的接口，以及如何在最终环境中打包，发布，托管和管理应用程序。

解决方案背景包括投资组合级别的问题

最后一个考虑因素。通常，企业的产品和服务必须协同工作才能实现解决方案的更大目标。因此，大多数解决方案并不孤立;它们也是投资组合层面的关注点。因此，新兴计划（通常以投资组合Epics的形式）也会推动解决方案意图并影响解决方案的开发和部署。

对于内部托管系统，通常还需要与其他解决方案的互操作性，从而进一步扩展解决方案环境。例如，较大的操作价值流（参见Value Streams文章）通常使用来自多个开发价值流的解决方案，如图4所示。

图4.解决方案协同工作以支持完整的运营价值流

每个主题解决方案都必须与其他解决方案协作并集成，以便为运营价值流提供无缝的端到端解决方案。

持续协作确保可部署性

确保解决方案在其上下文和部署环境中正常运行需要持续的反馈（请参阅持续交付管道文章）。基于Cadence的开发经常集成整个系统系统解决方案，以展示顶级环境的里程碑和发布承诺的进展。持续协作有助于确保可以在最终客户的环境中部署解决方案：

•     客户在PI规划和解决方案演示期间提出并讨论了上下文问题
•     解决方案管理和客户不断确保愿景，解决方案意图，路线图和解决方案Backlog与解决方案环境保持一致
•     在客户的上下文中发现的问题通过解决方案看板系统进行影响和解决
•     了解和共享相关的解决方案上下文知识，环境和基础架构，例如界面模型，测试和集成环境以及测试和部署脚本
•     解决方案架构师/工程师确保与解决方案上下文接口，约束等技术一致。

因此，开发团队与客户组织内的各种角色之间存在许多协作点。如图5所示，几个SAFe角色与其客户同行一起承担这一责任。

图5. SAFe与客户角色之间的协作

因此，客户和SAFe角色之间的有效协作有助于确保系统满足客户在其上下文中的需求。

原文：https://www.scaledagileframework.com/solution-context/

本文：https://pub.intelligentx.net/safe-solution-context

讨论：请加入知识星球或者小红圈【首席架构师圈】

重点应该放在我们为什么要工作上。

- w。爱德华兹•戴明

 

程序和解决方案积压

计划Backlog是即将发布的特性的保留区域，这些特性旨在满足用户需求，并为单个敏捷发布培训(ART)交付业务收益。它还包含构建架构跑道所需的启用器特性。

解决方案待办事项列表是即将到来的功能和启用程序的保留区域，每个功能和启用程序都可以跨越多种艺术，旨在推进解决方案并构建其体系结构跑道。

产品管理负责计划Backlog，而解决方案管理负责解决方案Backlog。这些积压的项目来自于研究活动和与各种利益相关者的积极合作——客户、业务所有者、产品管理、产品所有者、系统和解决方案架构师/工程等等，这些都是持续探索过程的一部分。

待办事项项通过各自的程序和解决方案看板系统进行管理。工作经过“漏斗”和“分析”的状态，以及经过充分阐述和批准的最高优先级的特性和功能，移动到“backlog”状态。然后，相对于其他待办事项列表，对它们进行优先级排序，等待实现。

使用加权最短作业优先(WSJF)有效地识别、细化、确定优先级和排序待办事项项是解决方案经济成功的关键。由于backlog包含了新的业务功能和扩展架构跑道所必需的支持工作，所以使用“容量分配”来帮助确保快速和长期的价值交付，并保证质量。

细节

程序和解决方案积压是所有影响解决方案行为的即将进行的工作的存储库。产品和解决方案管理分别开发、维护和优先处理计划和解决方案积压。积压是通过各自看板系统并已批准实现的特性和功能的短期存储区域。计划安排项是用故事点来估计的，如图1所示。

图1所示。项目待办事项列表的分解视图，带有对故事点大小的估计

细化积压

敏捷发布培训和解决方案培训运行一个稳定的8-12周的计划增量(PI)节奏，包括计划、执行、演示、检查和调整(I&A)。这种有规律的节奏也是驱动backlog准备工作的心跳。出现在PI前期计划或PI计划中而没有详细的backlog，会给即将到来的PI增加不可接受的风险。

PI计划事件之间的时间是产品和解决方案管理的繁忙时间，因为它们总是在为下一个PI计划细化积压的过程中。使这个过程可见，并为即将到来的PI实现backlog准备就绪，是程序和解决方案看板的主要目的之一。

Backlog改进通常包括:

• 审查和更新待办事项项定义，制定验收标准和效益假设
• 与团队合作，建立技术可行性和范围评估
• 分析将待办事项项分割为增量值的小块的方法
• 确定支持新特性和功能所需的启用程序，并确定它们的容量分配

 

优先的积压

对程序和解决方案积压进行优先排序是解决方案的关键经济驱动力。为此，产品和解决方案管理使用WSJF优先级方法进行作业排序。回顾一下，WSJF最终转换为一个简单的公式，如图2所示。

图2。一个计算WSJF的公式

准备PI计划

PI计划的前一两周是一个关键时刻。产品和解决方案管理做最后的backlog准备，更新远景简报，并在活动之前与产品所有者合作进一步社会化backlog。系统和解决方案架构师/工程更新启用器定义和模型，并经常开发用例来说明功能和功能如何协同工作以交付最终用户价值。

通过容量分配优化价值和解决方案的完整性

每一个艺术和解决方案培训面临的一个挑战是如何平衡积压的业务特性和功能需要不断投资于建筑的跑道,为探索提供时间需求和设计未来π和创建原型和模型增强可视性问题区域。为了避免降低速度，并推迟由于技术过时而大规模替换组件的需要，ARTs必须不断投资于实现解决方案的推动者。这增加了工作优先级的难度，因为不同的人可以将团队拉向不同的方向，如图3所示。

图3。业务与启用待办事项项之间的两难境地

为了解决这个问题，ARTs应用了容量分配，在这里，他们决定为即将到来的PI的每种类型的活动可以使用多少总工作量。此外，它们还建立了一个协议来确定如何为每种活动类型执行工作。这也可以包括持续维持的特别储备金以及减少可能累积的任何技术债务。图4和表1给出了结果的示例。

图4。单个PI的容量分配示例

在每一个PI边界上，我们都同意将资源的百分比用于新特性或功能与启用程序之间的比较。

我们同意系统和解决方案架构师/工程有权优先考虑使能工作。

我们同意产品和解决方案管理有权优先处理业务待办事项。

我们同意在经济基础上共同确定工作重点。

我们同意以最大化客户价值的方式在排序工作上进行合作。

表1。管理启用器和特性容量分配的示例策略

虽然商定的策略可以持续一段时间，但分配的容量应该根据上下文定期变化。在艺术的上下文中，这个决策可以作为为每一个PI计划做准备的backlog细化的一部分重新访问，而解决方案管理和解决方案架构师/工程在pre-PI计划之前对整个解决方案做出类似的选择。

关于积压、队列、Little 's Law和等待时间

重要的是，我们应该把时间放在一边，讨论一下积压、等待时间和流程之间的关系。原则#6，可视化和限制WIP，减少批处理大小和管理队列长度，详细解释了这种关系。然而，在这里总结一下这个讨论是很重要的，因为程序和解决方案积压可能对交付时间和吞吐量产生最显著的影响。

这里有一个总结:

• Little定律说明，队列中某项的平均等待时间等于队列的平均长度除以队列中某项的平均处理速度。队列越长，等待时间越长，变异性越大。

图5。小定律

想想星巴克的排队情况:如果你前面的十个人每人都点了一杯大杯咖啡，你几分钟内就会离开那里。如果每个人都买了一杯特热的香草拿铁和一个加热的百吉饼，你可能会迟到，而且这不是你能控制的。

• 排长队都是不好的，导致动机降低、质量差、循环时间更长、变异性更高(想想星巴克)，以及风险[2]增加，如图6所示。

图6。排长队不好

您的程序和解决方案积压不是队列，因为项目可以跳过其他项目以获得更快的交付速度，而且您总是可以选择不为积压中的所有内容提供服务。(注意，这两种方法在星巴克都行不通。)

然而，如果您的backlog中的所有项都提交给涉众，那么您的backlog就像一个队列，队列越长，涉众等待服务的时间就越长。如果他们不得不等太久，他们会找到另一家咖啡店，因为你的店不能满足他们快速变化的市场需求。

因此，团队和艺术必须积极地管理他们的积压，并保持它们简短，以便快速响应。他们还必须限制对长期工作的承诺，因为可能会出现一些比先前的承诺更重要的其他事项。如果一个ART在backlog中有太多固定的和提交的需求，不管它有多高效，它都不能快速响应。

只有当团队和ARTs积极地管理backlog并保持其简短时，它们才能同时可靠和快速。

了解更多

• [1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
• [2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

 

原文：https://www.scaledagileframework.com/program-and-solution-backlogs/

本文：https://pub.intelligentx.net/safeprogram-and-solution-backlogs

讨论：请加入知识星球或者小红圈【首席架构师圈】

最短的可持续交付时间，为人民和社会提供最好的质量和价值。

—House of Lean

 

价值流

价值流表示组织用于构建解决方案的一系列步骤，这些解决方案向客户提供连续的价值流。一个安全的投资组合由一组开发价值流组成，每个开发价值流构建并支持一个或多个解决方案。

安全投资组合的主要作用是为一系列发展价值流提供资金和培育。这些价值流要么直接交付最终用户价值，要么支持内部业务流程。

围绕价值流组织为组织提供了实质性的好处，包括更快的学习、更短的上市时间、更高的质量、更高的生产力和更精简的预算机制。在SAFe中，围绕价值进行组织是通过首先理解价值流，然后启动敏捷发布培训或解决方案培训来实现它们。通过火车实现价值流是安全的“艺术”和科学。

此外，价值流映射可用于识别和处理延迟和非增值活动，以实现精益敏捷的目标，即最短的可持续交付时间。

细节

精益敏捷方法高度关注持续的价值交付，只有当最终用户、客户或内部业务流程获得某些新解决方案或功能的业务利益时，才能实现价值。在精益中，识别和理解各种价值流是最关键的一步——实际上，也是提高企业整体绩效的起点。毕竟，如果企业不清楚它交付了什么以及如何交付，那么是否有可能进行改进呢?这一简单的背景促使SAFe围绕称为价值流的价值流组织开发组合。

价值流是一系列用于交付价值的长期步骤，从概念或客户订单到为客户交付有形结果。图1说明了价值流的结构。

图1所示。价值流的剖析

重大事件触发价值流，可能是客户购买订单或新功能请求。当交付了一些值(发货、客户购买或解决方案部署)时，它就结束了。中间的步骤是企业用来完成此任务的活动。价值流包括从事该工作的人员、他们开发或操作的系统以及信息流和物料流。从触发器到值交付的时间是前置时间。缩短交货时间缩短了产品上市的时间。这就是重点。

价值流的类型

在SAFe上下文中，企业中通常存在两种类型的价值流，如图2所示:

• 操作价值流——用于向客户提供商品或服务的步骤，无论是内部的还是外部的。[2]中国英语学习网这家公司就是这样赚钱的。
• 开发价值流——用于开发新产品、系统或服务功能的步骤。

图2。开发价值流构建操作价值流用于交付价值的系统

有时，操作流和开发流是相同的，比如解决方案提供者开发一个产品用于销售并直接提供分发(例如，一个小型SaaS公司)。在这种情况下，只有一个价值流——因为开发和操作价值流是相同的。

然而，特别是在大型IT企业的上下文中，理解这两种类型的价值流是至关重要的，因为开发价值流提供操作价值流，如图2所示。

虽然SAFe的主要目的是指导构建系统的人员，但首先必须了解价值的总体流程，以便团队能够开发和优化解决方案，以加速业务结果。此外，开发价值流的许多关键需求不仅是功能，而且是解决方案和企业架构，它们直接由操作价值流驱动。

定义值流

识别价值流和艺术是实现安全的第一步，在识别价值流和艺术文章中进行了描述。此外，一旦选择了价值流，就需要进行一些额外的分析来进一步定义开发价值流边界、人员、可交付成果、潜在的艺术和其他参数。图3提供了一个价值流画布，涉众可以使用这个简单的工具来捕获他们对[1]的理解。

图3。价值流画布

开发价值流的精益预算

识别价值流并理解组织中的价值流是改进价值交付的重要步骤。它还提供了实施精益预算的机会，这可以大大减少开销和摩擦，并进一步加快流程。

为了支持这一点，SAFe中的每个投资组合都包含一组开发价值流，每个价值流都有一个预算。精益项目组合管理(LPM)帮助按照精益-敏捷预算原则管理每个价值流的预算。随着时间的推移，LPM根据不断变化的业务条件调整每个价值流的预算。精益预算文章描述了动态预算。图4显示了不同开发价值流的独立预算。

图4。LPM为每个开发价值流分配预算

价值流kpi

精益预算流程可以大大简化财务治理，授权分散的决策，并增加企业的价值流。从资助项目到将预算分配到价值流，这是一个大胆的举措。很自然，这种新方法提出了一个问题，企业如何知道它的巨额投资获得了适当的回报?

为此，每个价值流定义一组标准或关键绩效指标(kpi)，可用于评估正在进行的投资。所考虑的价值流类型驱动业务所需的kpi，例如:

• 一些价值流产生收入，或者直接产生终端用户价值，在这种情况下，收入可能是一个合适的衡量标准。其他指标，如市场份额或解决方案使用情况，可能提供额外的见解。
• 其他价值流或价值流的元素正在创建紧急的新产品。在这种情况下，潜在投资回报(ROI)是一个滞后的经济指标。相反，使用非金融、创新的会计kpi来获得快速反馈可能是更好的选择。
• 一些开发价值流仅仅是成本中心，它们服务于内部的运营价值流，而不是独立的货币化。在这种情况下，客户满意度、净推广者评分、团队/艺术自我评估和功能周期时间等指标可能更相关。
• 在最重要的范围内，价值流可以建立更广泛的度量，例如那些由样本精益敏捷投资组合度量表示的度量。

价值流的协调

价值流通常需要两种类型的协调活动:

• 在一个投资组合中协调多个价值流——根据设计，价值流应该尽可能独立。然而，可能需要进行一些协调，以确保企业按照企业目标的步调推进每个价值流。价值流协调是本文的主题。
• 在价值流中协调多个艺术——通常，在大多数大型价值流中，艺术之间存在一些依赖关系。企业如何协调这些活动来创建单个的、整体的解决方案集?这可能需要广泛的合作。例如:
  • 使用由解决方案管理管理的公共解决方案Backlog实现新的横切功能。
  • 在系统和解决方案架构师/工程师的帮助下，协作定义跨艺术连接解决方案的技术和体系结构。
  • 与完整和部分解决方案演示的附加解决方案集成。
  • 解决方案培训工程师推动的pi前期和后期计划活动的特别考虑。
  • 不同程度和类型的DevOps和连续交付管道的支持和协作。

协调价值流中的多种艺术是更重要的精益敏捷企业的主要挑战之一，也是解决方案培训文章的整个主题，这是大型解决方案级别的一部分。

通过价值流映射减少上市时间

最后，识别价值流并围绕它们组织发布培训还有一个重要的好处。每个价值流为客户提供一个可识别和可度量的价值流。因此，可以使用价值流映射[2]系统地改进它，以提高交付速度和质量。价值流映射将在“维持和改进”一文中进一步描述。

了解更多

• [1]感谢SPCT Mark Richards对价值流画布概念的贡献。
• [2]马丁，凯伦和迈克·奥斯特林。价值流程图。麦格劳希尔,2014。
• [3] Poppendieck, Mary和Tom。实施精益软件开发:从概念到现金。addison - wesley, 2007年。
• [4]病房,艾伦。精益产品和过程开发。精益企业研究所，2014。

 

原文：https://www.scaledagileframework.com/value-streams/

本文：https://pub.intelligentx.net/safe-value-stream

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

一个战略转折点是技术创新，市场发展和客户感知的某种结合需要公司彻底改变或消亡的时刻。

-Andy Grove，只有偏执狂的生存

企业

企业代表每个SAFe投资组合所属的业务实体。

每个SAFe产品组合都包含一个或多个价值流，每个价值流都致力于构建，部署和支持企业完成其业务使命所需的一套解决方案。在中小型企业中，一个SAFe产品组合通常可以管理整个技术解决方案集。在大型企业中 - 通常是那些拥有超过500到1,000名技术从业者的企业 - 可以有多个SAFe组合，通常每个业务线一个，或者围绕业务组织和资金模型构建。

在任何一种情况下，投资组合都不是整个业务。因此，对于企业和投资组合利益相关者来说，确保每个投资组合解决方案集的发展都能满足更广泛的业务需求至关重要。这是精益企业的关键能力。

细节

企业战略推动投资组合战略

对于许多公司来说，他们开展业务的方式大多超出了SAFe的范围。但是，企业战略直接与特定SAFe解决方案组合的战略相关联是一个关键的交叉点。制定业务战略并决定投资多少能够实现该战略的解决方案是关键问题。组合利益相关者直接参与。

SAFe提供了两种将企业战略与投资组合联系起来的主要机制：

•     投资组合预算是为投资组合提供的用于开发，运营和资本支出的总资金。然后通过精益投资组合管理（LPM）将其分配给各个价值流。
•     企业高管和投资组合利益相关者共同合作，建立了一套战略主题。这些是具体的，差异化的业务目标，它们将战略意图的各个方面从企业传达到投资组合。

此外，投资组合背景（如下所述）提供持续的反馈，以支持治理并为正在进行的企业战略发展提供信息。

小企业可能拥有单一的SAFe投资组合

如上所述，单个组合（SAFe的单个实例）可能足以为整个组织提供一组解决方案。解决方案组合通过战略主题和预算与业务战略相关联，如图1所示。

图1.单个SAFe产品组合的企业视图

大型企业将拥有多个投资组合

许多世界上最大的企业都使用SAFe。这些企业拥有数千甚至数万名IT，系统，应用程序和解决方案开发从业者。当然，并非所有这些从业者都在研究相同的解决方案或在相同的价值流中。最有可能的是，IT和开发组织起来支持各种业务线，内部部门，客户群或其他业务功能。企业将拥有多个SAFe组合，以实现这一更大的目标。每个都有自己的预算和战略主题，反映了该部门的业务战略部分，如图2所示。

图2.多个SAFe组合的企业视图

 

在这种情况下，每个SAFe组合都存在于这个更广泛的企业环境中，这是它必须解决的业务战略的来源。该企业还为所有投资组合提供更多的一般资金和治理。

 

企业战略制定

企业战略推动每个投资组合预算。在科技领域，许多哲学和当前趋势影响着战略的制定，包括Geoffrey Moore的系列丛书[1]和精益创业[2]。还有各种更具体的战略方法，包括Business Model Canvas [3]和Lean Canvas [4]。 （注意：商业模型画布是SAFe投资组合画布中使用的模型。）Jim Collins [5]在Beyond Entrepreneurship中描述了一种广义策略制定模型。图3突出显示了该方法的主要方面，适用于SAFe上下文。

图3.企业组合战略制定模型，显示企业战略如何推动SAFe解决方案组合战略主题和预算

 

以下各节将简要讨论每个输入：

1.     企业预算总额 - 作为组织总运营预算的一部分，人员和其他资源被分配用于所有SAFe组合的技术解决方案。这可能包括人员，资本和运营支出的指导原则（参见CapEx和OpEx指导文章）。
2.     企业业务驱动因素 - 企业业务驱动因素反映了更大的行业主题和运营问题，为不断发展的战典型的例子包括业务驱动因素，例如“将新收购的功能集成到套件中”（一家安全公司）和“将应用程序移至云端”。
3.     财务目标 - 无论是衡量收入，盈利能力，市场份额还是其他指标，财务绩效目标都应该明确。这些与投资组合利益相关者相关。
4.     使命，愿景和核心价值观 - 明确，统一的使命，愿景和一系列核心价值观提供了定义和指导战略的目的和目标。
5.     投资组合背景 - 在完整的投资组合环境中开发最有效的策略。大部分背景都是由投资组合画布的当前和未来状态捕获的。关键绩效指标（KPI），优势，劣势，机会，威胁（SWOT）分析等提供了背景知识。然而，战略差异化是企业提供竞争优势的基础。正是文化和技术DNA为企业带来了当前的成功。
6.     竞争环境 - 竞争分析有助于识别最重要的威胁和机会领域。

正如我们所指出的，从SAFe的角度来看，有两个主要输出：

•     投资组合预算 - 为一组投资组合解决方案的开发提供资金，为每个投资组合分配预算。
•     战略主题 - 通常每年更新的战略主题是将项目组合与企业战略联系起来的差异化特定业务目标。它们为决策提供业务背景，并作为愿景，预算和积压的输入。

 

投资组合背景通知企业战略

然而，即使任何策略都具有很大程度上集中的属性，但有些元素根本无法集中或预先知道。当前解决方案集和当地市场条件中存在的挑战和机遇为企业战略提供了信息。为此，战略制定需要持续的协作，沟通以及与下游投资组合的一致性。换句话说，它要求完全了解投资组合背景。这可能包括：

1.     关键绩效指标（KPI） - 投资组合负责提供有关分配的投资支出的反馈。这可以包括定量和财务指标，例如投资回报率（ROI），市场份额，客户净推动者得分和创新会计。
2.     定性数据 - 这通常包括SWOT分析，最重要的是，包括投资组合利益相关者的累积解决方案，市场和业务知识。
3.     精益预算护栏 - 每个投资组合还包含一套护栏，描述特定投资组合的预算和支出政策和做法。这些可以由业务战略的元素驱动，并且是业务战略元素的驱动因素。

战略制定大规模集中;投资组合执行是分散的

根据SAFe原则＃9，分散决策权，形成业务战略的责任主要集中在一起，但也是协作的。业务主管和基本投资组合利益相关者发挥着至关重然而，执行解决方案策略是分散到投资组合中的。在透明度，持续反馈，KPI和适当的投资组合指标的支持下，只有这些人拥有定义，发展和预算价值流所必需的本地知识。他们处于建立相关经济框架和管理必要解决方案发展的最佳位置，以满足不断变化的客户需求和新的市场机遇。

学到更多

 

• [1]摩尔，杰弗里。穿越峡谷（1991年，2014年），龙卷风内部（1995年，2004年）和逃逸速度（2011年）。 Harper Business Essentials。
• [2]里斯，埃里克。精益创业：今天的企业家如何利用持续创新创造极其成功的企业。兰登书屋，2011。
• [3]奥斯特瓦尔德，亚历山大; Pigneur，Yves。商业模式生成：有远见者，游戏改变者和挑战者的手册。威利。 Kindle版。
• [4] Maurya，Ash。运行精益：从计划A迭代到可行的计划。 O'Reilly Media，2012。
• [5]柯林斯，吉姆和威廉拉齐尔。超越企业家精神：将您的业务转变为一个伟大而持久的公司。 Prentice Hall，1992。

讨论：请加入知识星球或者小红圈【首席架构师圈】

检验不能提高质量，也不能保证质量。检查太迟了。产品的质量，无论好坏，都已经存在。产品或服务的质量不能检验;它必须融入其中。”

- w。爱德华兹•戴明

内置的质量

内置的质量实践确保每个解决方案元素在每个增量中都符合整个开发过程中的适当质量标准。

企业能否以最短的可持续交付时间交付新功能，并适应快速变化的业务环境，取决于解决方案的质量。因此，内置的质量是安全的核心价值之一，也是敏捷宣言“持续关注技术卓越性和良好的设计增强敏捷性”的原则之一，这一点也不奇怪。内置的质量也是精益敏捷思维的核心原则，有助于避免与召回、返工和修复缺陷相关的延迟成本(CoDs)。外管局的内在品质理念，运用系统思维，优化整个系统，确保整个价值流的快速流动，让品质成为每个人的工作。

软件和硬件共享内置质量的目标和原则。然而，硬件的工作物理和经济学有些不同。本文将讨论这两个问题。

细节

企业必须不断地对市场变化作出反应。建立在稳定技术基础上的软件和系统更容易更改和适应。对于大型解决方案，这甚至更为关键，因为即使是小缺陷和错误假设的累积效应也可能产生不可接受的结果。

构建高质量的系统是一项严肃的工作，需要持续的培训和承诺，但业务利益需要投资:

• 更高的客户满意度
• 提高了速度和交付的可预测性
• 更好的系统性能
• 改进了创新、扩展和满足法规遵循需求的能力

图1说明了内置质量的五个维度。首先，流说明了一个事实，即内置质量是实现连续值流状态的必要条件。另外四个描述了应用于系统本身的质量。下面将讨论每个维度。

图1所示。内置质量的五个维度

通过连续的输送管道和测试优先来实现流程

内置的质量使安全的连续输送管道和能力释放的需求。图2演示了SAFe的DevOps雷达的持续集成部分，并展示了如何在进入生产之前跨多个环境测试内建组件的更改。通过用更快的代理(如内存中的数据库代理)替换慢速或昂贵的组件(如企业数据库)，“测试加倍”速度测试。

图2。连续的输送管道确保了产品出厂前的质量

为了支持管道的测试需求，组织必须在开发周期的早期将测试左移。作为规范的一部分，每个系统行为—故事、特性、功能、非功能需求(NFR)—都包括自动化测试。这种测试优先的方法允许团队尽早并持续地应用质量实践，以及为管道创建一组丰富的测试。

本文的其余部分将讨论内置质量体系结构和设计、代码、系统和发布的其他四个维度。

实现架构和设计质量

内置质量从体系结构和设计开始，这最终决定了系统能够多好地支持当前和未来的业务需求。体系结构和设计中的质量使未来的需求更容易实现，系统更容易测试，并有助于满足NFRs。

支持未来的业务需求

随着需求基于市场变化、开发发现和其他原因的发展，架构和设计也必须发展。传统过程迫使早期的决策常常导致两个糟糕的选择，要么重新工作以更改决策，要么忍受次优决策的低效。确定最佳决策需要通过实验、建模、仿真、原型化和其他学习活动获得知识。它还需要一种基于集的设计方法来评估多个备选方案，以获得最佳决策。一旦确定了，开发人员就使用架构跑道来实现最终的决策。敏捷架构为团队间的设计和实现同步提供了有意的指导。

几个设计特性是良好质量的预测器，确保工件是可理解和可维护的，包括高内聚和低耦合、良好的抽象和封装、可读性和关注点分离。坚实的[2]原则创造了这些特点的设计。

架构和设计以简化测试

体系结构和设计也决定了系统的可测试性。通过定义良好的接口进行通信的模块组件包含seam[3]，它允许测试人员和开发人员用测试替身替换昂贵或缓慢的组件。例如，图3显示了一个速度控制器组件，需要从GPS位置组件获得当前车辆位置来调整其速度。测试带有GPS定位的速度控制器需要相关的GPS硬件和信号发生器来复制GPS卫星。将这种复杂性替换为测试加倍，可以减少开发和测试速度控制器或任何与GPS定位接口的其他组件的时间和精力。

图3。模块组件创建接缝以简化测试

将设计质量应用于网络物理系统

这些设计原则也适用于网络物理系统。许多学科的工程师使用建模和仿真来获得设计知识。例如，集成电路(IC)设计技术(VHDL, Verilog)是类似软件的，并且从这些设计特性和坚实的原理[4]中共享相同的好处。硬件设计还应用了通过模拟和模型进行测试的概念，或者在切割金属之前提供木材原型。

这通常需要改变心态。和软件一样，硬件也会发生变化。通过构建质量来规划未来的变化，而不是根据当前的需求进行优化来完成设计，从而提供更好的长期结果。

实现代码质量

所有系统功能最终都由系统的代码(或组件)执行。添加新功能的速度和容易程度取决于开发人员修改新功能的速度和可靠程度。受极限编程(XP)[5]的启发，这里列出了一些实践。

单元测试和测试驱动开发

单元测试实践将代码分解为多个部分，并确保每个部分都有自动化测试来执行它。这些测试在每次更改后自动运行，允许开发人员快速地进行更改，并确信修改不会破坏系统的其他部分。测试还充当文档，并且是与组件接口交互的可执行示例，以显示应该如何使用该组件。

测试驱动开发(TDD)通过在创建变更之前指定变更的测试来指导单元测试的创建。这迫使开发人员更广泛地考虑问题，包括实现之前的边界用例和边界条件。更好的理解导致更快的开发，更少的错误和更少的返工。

结伴工作

结对让两个开发人员在同一工作站上进行相同的更改。一个充当编写代码的驱动程序，另一个充当提供实时评审和反馈的导航器。开发人员频繁地转换角色。结对创建并维护质量，因为代码将包含来自每个成员的共享知识、观点和最佳实践。当队友们互相学习时，它也能提高和扩大整个团队的技能。

集体所有权和编码标准

集体所有权减少了团队之间的依赖关系，并确保任何一个开发人员或团队都不会阻碍快速的价值交付流。作为更改的一部分，“任何开发人员都可以更改任何代码行来添加功能、修复bug、改进设计或重构。因为代码不是由一个团队或个人拥有的，所以支持编码标准可以促进一致性，这样每个人都可以理解并维护每个组件的质量。

在网络物理系统中应用代码质量

虽然并非所有硬件设计都有“代码”，但物理构件的创建是一个协作过程，可以从这些实践中获益。用于硬件开发的计算机辅助设计(CAD)工具以断言的形式为电子设计提供“单元测试”，然后在机械设计中进行模拟和分析。切分、集体所有权和编码标准可以产生类似的好处，从而创建更容易维护和修改的设计。

一些硬件设计技术非常类似于代码(例如VHDL)，具有明确定义的输入和输出，非常适合TDD[4]之类的实践。

实现系统质量

虽然代码和设计质量确保可以轻松理解和更改系统构件，但是系统质量确认系统按预期工作，并且每个人都对要做的更改保持一致。下面重点介绍实现系统质量的技巧。

创建对齐以实现快速流

对齐和共享理解减少了开发人员的延迟和返工，从而支持快速流。行为驱动开发(BDD)定义了一种协作实践，在这种实践中，产品所有者和开发团队就故事或特性的精确行为达成一致。应用BDD可以帮助开发人员在第一时间构建正确的行为，并减少返工和错误。基于模型的系统工程(MBSE)将这种对齐扩展到整个系统。通过一个分析和综合过程，MBSE提供了一个高层次的、完整的视图，展示了系统的所有建议功能，以及系统设计如何实现这些功能。

持续集成端到端解决方案

如图2所示，持续集成(CI)和持续部署(CD)为开发人员提供了对更改的快速反馈。每个变更都是快速构建的，然后在多个级别进行集成和测试，包括在部署环境中。CI/CD自动将更改移动到各个阶段，并在测试失败时做出响应。NFRs的质量测试也是自动化的。当CI/CD努力使所有测试自动化时，一些功能性(探索性)和NFR(可用性)测试只能手工执行。

将系统质量应用于网络物理系统

网络物理系统还可以支持快速流、CI/CD方法——即使物理部件的交付时间很长。如前所述，仿真、模型、以前的硬件版本和其他代理可以替代最终的系统组件。图4展示了一个系统团队，该团队提供了一个可演示的平台，通过连接这些组件代理来测试增量行为。随着每个组件的成熟(通过增加红色来显示)，端到端集成平台也会成熟。使用这种方法，组件团队将负责支持其最终解决方案的一部分，以及成熟的增量端到端测试平台。

图4。网络物理系统的持续集成(CI)

实现发布质量

发布允许业务度量特性的效益假设的有效性。一个组织发布得越快，它学习得就越快，提供的价值也就越多。定义组件间标准接口的模块化体系结构允许独立地发布较小的组件级更改。较小的更改允许更快、更频繁、风险更小的版本，但是需要一个自动化的管道(如图2所示)来确保质量。

与传统的服务器基础设施不同，“不可变的基础设施”不允许手动或直接对生产服务器进行更改。相反，更改应用于服务器映像，经过验证，然后启动，以替换当前运行的服务器。这种方法创建了更一致、更可预测的版本。它还允许自动恢复。如果操作环境检测到一个生产错误，它可以通过简单地启动前一个映像来替换错误的映像来回滚发布。

支持合规

对于必须为遵从性或审计证明客观证据的系统，发布还有其他条件。这些组织必须证明该系统符合其预期目的，并且没有意外的、有害的后果。如法规遵循文章所述，精益质量管理系统(QMS)定义了经过批准的实践、策略和过程，这些实践、策略和过程支持精益敏捷的、基于流程的、持续的集成部署发布过程。

完成的可伸缩定义

“已完成”的定义是保证增值能够被认为是完整的重要方法。增量系统功能的持续开发需要对已完成的工作进行缩放定义，以确保在正确的时间完成正确的工作，有些是早期的，有些只是为了发布。表1显示了一个示例，但是每个团队、培训和企业都应该构建自己的定义。虽然对于每个艺术或团队来说这些可能是不同的，但它们通常共享一组核心项目。

表1。示例安全可伸缩的完成定义

在网络物理系统中实现发布质量

对于发布质量的看法是不要让变更闲置，等待集成。相反，要快速且频繁地通过系统的较大部分集成更改，直到更改到达验证环境为止。一些网络物理系统可以在客户环境中验证(例如，车辆的空中更新)。其他人使用一个或多个模型代理该环境，这些模型努力获得早期反馈，如图4所示。端到端平台会随着时间的推移而成熟，提供更高的保真度，从而支持更早的验证和验证(V&V)以及遵从性工作。对于许多系统，早期的V&V和遵从性反馈对于理解发布能力是至关重要的。

了解更多

• 敏捷软件开发的[1]宣言。www.AgileManifesto.org。
• [2] Robert Martin，《OOD的原则》，http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• Michael， [3] Feathers，《使用遗留代码进行有效测试》，Prentice Hall, 2005。
• 《VHDL的有效编码原理与最佳实践》，麻省理工学院出版社，2016年。
• 《极限编程解释:拥抱变化》，Addison-Wesley, 1999。
• [6]www.extremeprogramming.org/rules/collective.html

 

原文：https://www.scaledagileframework.com/built-in-quality/

本文：https://pub.intelligentx.net/safe-built-quality

讨论：请加入知识星球或者小红圈【首席架构师圈】

没有什么能打败敏捷团队。

--SAFe的咒语

敏捷团队

 

安全敏捷团队是一个由5到11人组成的跨功能团队，他们负责定义、构建、测试和在适当的地方部署一些解决方案价值的元素——所有这些都在一个短的迭代时间框中完成。具体来说，安全敏捷团队包括开发团队、Scrum Master和产品负责人角色。

正如SAFe的团队和技术敏捷能力中所描述的，敏捷团队为敏捷发布培训(ART)提供动力，并最终为整个企业提供动力。艺术负责交付更大的解决方案价值。没有队伍，就没有火车。所有的团队都在一个火车上，为它的愿景和路线图做出贡献，与其他团队合作，并参与艺术活动。此外，他们主要负责构建持续交付管道和ART DevOps功能。

团队和火车是不可分割的;整体大于部分之和。

细节

敏捷运动[1]代表了软件和系统开发方式的一个主要转折点。SAFe通过将敏捷团队授权为创建和交付价值的构建块，构建在此变更之上。如果没有有效的敏捷团队(由授权的和积极的个人组成)，组织就无法实现精益敏捷开发的更大的业务利益。

总之，敏捷团队拥有在短时间内开发增值所需的所有技能:

• 定义-详细说明和设计功能和组件
• 构建-实现特性和组件
• 测试—运行测试用例来验证特性或组件
• 部署—将特性移到“登台”和“生产”环境中

当在艺术的上下文中运行时，团队被授权、自组织和自管理。他们负责交付满足客户需求和期望的结果。团队开发软件、硬件、固件或某些组合。但最重要的是，团队代表了交付特性或组件所必需的跨功能规程的协作。

通过将工作转移到团队和培训中，而不是将人员带到工作中，企业可以在很大程度上消除工作的“项目模型”(参见精益预算)，取而代之的是创建团队，以及团队中的团队，这些团队是长期存在的，致力于不懈地提高交付解决方案的能力。这就是SAFe与传统方法的不同之处，传统方法是由管理人员引导个人进行活动。安全的团队——而不是他们的管理者——决定他们可以在迭代中构建什么特性和组件，以及如何构建它们。精益敏捷领导者提供了培养和提升高效团队所必需的愿景、领导力和自主性。由于团队在很大程度上是自组织和自管理的，因此不再需要将工作分配给单个团队成员。这使得分散决策能够一直进行到单个贡献者的级别。精益敏捷领导者的主要职责就是指导和指导敏捷团队。

SAFe团队通常混合了敏捷方法

安全团队使用敏捷实践，主要基于Scrum、看板和极限编程(XP)。大多数安全的团队都将Scrum和XP(参见安全ScrumXP)作为基本框架。产品负责人管理团队Backlog。Scrum Master帮助团队实现其交付目标，并帮助建立一个高效且自我管理的团队。

团队应用精益UX特性开发和内置的质量实践来驱动有纪律的开发和质量。这些实践——包括集体所有权、结对工作、编码标准、测试优先和持续集成——通过将质量和操作效率直接嵌入到流程中，帮助保持精益。敏捷架构完成了高质量解决方案开发的蓝图。

然而，由于SAFe是一个基于流的系统，大多数团队还应用看板来可视化他们的工作，建立过程中的工作(WIP)限制，并使用累积流图(CFDs)来说明提高吞吐量的瓶颈和关键机会。一些团队——特别是维护团队和系统团队——经常将看板作为他们的基本实践。这是因为Scrum的计划和承诺元素可能不适用于基于活动和需求、优先级变化更频繁的工作负载。

责任

SAFe有助于摆脱传统的分阶段开发模型，在这种模型中，用户价值是在长生命周期结束时交付的，输入来自不同的功能竖井(需求、设计、测试、部署)。相反，敏捷团队执行所有这些功能，同时在每次迭代中交付价值。敏捷团队负责管理他们的工作，并在从持续探索到持续集成、持续部署到随需发布的整个生命周期中产生价值。为了做到这一点，团队:

• 估计工作的规模和复杂性
• 在体系结构指南中确定他们所关注领域的技术设计
• 提交到它可以在迭代或程序增量(PI)时间框中完成的工作
• 实现了功能
• 测试的功能
• 将该功能部署到登台和生产
• 支持和/或构建构建连续交付管道所需的自动化
• 持续改进他们的过程

此外，在任何可能的情况下，敏捷团队都具有构建和管理持续交付管道的技能和职责，并尽可能独立地发布其元素(特性、组件、子系统或产品)。

合作和文化

敏捷团队的动力来自于一个共同的愿景，以及他们向客户交付价值的承诺。每个团队成员都全身心地投入到一个单独的团队中，并投入到激烈的工作中。团队成员持续并积极地与其他团队合作，以管理依赖关系并解决障碍。团队内部的关系基于信任，由共同的任务、迭代目标和团队PI目标促进。通过在学习周期中构建有规则的反馈循环，协作将不断得到改进。每一个有形的价值交付都能鼓励信任，减少不确定性和风险，并建立信心。

团队只有通过持续的沟通和协作，以及快速、有效和授权的决策才能履行其职责。如果可能的话，团队的配置是为了方便每小时和每天的沟通。标准的团队会议在某种程度上依赖于所选择的方法，但是它们通常包括每日站立会议、迭代计划、迭代评审、backlog细化和迭代回顾。

敏捷团队就在火车上

安全的敏捷团队并不独立运作;它们通过协作和构建越来越有价值的工作解决方案增量来为艺术提供动力。所有团队都在一个管理和指导培训的共同框架内工作。他们一起计划，一起集成和演示，一起部署和发布，一起学习，如图1所示。

图1所示。敏捷团队一起计划，一起集成和演示，一起发布和部署，一起学习

一起计划

所有团队都参加PI计划，在那里他们一起计划并承诺一组PI目标。他们为一个共同的愿景和路线图而工作，并就实现目标的方法进行协作。清晰的内容权威角色有助于规划和执行过程。产品负责人是更大的产品管理团队的一部分。团队的单个团队积压部分是由计划积压驱动的。

此外，作为艺术的一部分，并根据经济框架，所有敏捷团队都参与到评估工作的公共方法中。这为帮助决策当局根据经济学指导行动进程提供了一种有意义的方法。

集成和演示在一起

交付复杂、高质量的系统需要紧密的团队间合作和协作。为了支持这一点，团队使用一个公共的艺术节奏，并在每个迭代的开始发布和交流迭代目标。它们还在ART同步期间更新其他团队，并通过与来自其他团队的团队成员交互来积极管理依赖关系。

当然，目标并不是简单地让团队朝着目标“冲刺”。相反，我们的目标是让系统在基于质量的、可度量的增量中快速前进。为了支持这一点，团队应用内置的质量，并进行持续的探索、持续的集成和持续的部署。这发生在团队内部和整个培训过程中——同时一起工作，在每次迭代结束时完成一个聚合的系统演示。

一起部署和发布

敏捷团队通过整个持续交付管道来驱动价值。他们围绕持续的探索与产品管理协作，他们不断地集成，他们不断地将他们的工作部署到登台和生产环境中。

敏捷团队通过早期和频繁地部署到生产环境中来帮助验证特性假设。他们设计自己的系统的方式能够将解决方案与发布解耦，并能够按需发布。

一起学习

所有安全的团队都在不断地改进(参见精益敏捷思维文章的第4支柱)。除了迭代回顾和特别的过程改进之外，团队还参加ART Inspect and Adapt (I&A)会议，在会议上，他们确定并优先化被纳入到以下PI计划会议中的改进待办事项。这就关闭了循环，因为团队和ART一次只前进一个迭代和PI。当然，学习并不局限于回顾。学习是不断发生的，实践社区(cop)也为学习提供了便利，它的成立是为了帮助个人和团队提高他们的功能和跨功能技能。

了解更多

• 敏捷软件开发的[1]宣言。http://agilemanifesto.org/。
• [2]Leffingwell,院长。扩展软件敏捷性:大型企业的最佳实践。addison - wesley, 2007年。
• [3]Lencioni,帕特里克。团队的五大功能障碍:一个领导寓言。2002年?。

 

原文：https://www.scaledagileframework.com/agile-teams/

本文：https://pub.intelligentx.net/safe-agile-teams

讨论：请加入知识星球或者小红圈【首席架构师圈】

虽然我们必须承认在设计和系统开发中出现了问题，但是少量的规划可以避免大量的浪费。

-James Coplien，精益架构

架构跑道

Architectural Runway包含实现近期功能所需的现有代码，组件和技术基础架构，无需过多的重新设计和延迟。

Architectural Runway通过持续交付管道支持持续的价值流，为开发业务计划和实施新功能和/或功能提供必要的技术基础。架构跑道是用于实施框架敏捷架构战略的主要工具之一。

由于新功能和功能的开发消耗了架构跑道，因此必须通过实施启动器来进行持续投资以扩展它。一些使能器解决了当前解决方案的缺点，例如改善性能或用户体验。其他提供将用于支持未来功能的基础功能。

细节

敏捷开发避免了大型设计前期（BDUF），并以简单的信念取而代之，“最好的架构，要求和设计来自自组织团队[3]。”这产生了紧急设计的实践 - 仅在必要时发现和扩展体系结构，以实现和验证下一个功能增量。

但是，组织必须通过需要一些意向性和规划的大规模架构计划同时应对新的业务挑战。因此，单独的紧急设计无法处理大规模系统开发的复杂性，并且开始出现以下问题：

•     过度的重新设计和延迟会降低速度
•     系统变得难以集成，验证和维护
•     系统质量下降，称为非功能需求（NFR）
•     减少团队之间的协作和同步
•     公共组件的低重用和解决方案元素的冗余

所有这些问题都可能导致解决方案性能不佳，经济性差，并缩短产品上市时间。

策划的架构支持更大的图画

所有团队都无法预测可能在其环境之外发生的变化。个别团队也不能完全理解整个系统，避免产生冗余和/或冲突的设计和实现。简而言之，大型企业中的任何一个团队都无法看到整体情况，也无法合理地预测所有变化的方向 - 其中很多都是在本地控制之外。

出于这个原因，团队需要一些有意的架构 - 一组有目的的，有计划的架构指南，在同步实施的同时增强解决方案设计，性能和可用性以及跨团队设计的方向。

有意识的架构和紧急设计共同应用，使敏捷发布列车（ART）能够创建和维护大规模解决方案。紧急设计可实现快速的本地控制，以便团队能够针对不断变化的需求做出适当的反应，而无需过多地尝试未来的系统验证。有意架构提供了确保整个系统具有概念完整性并且适合其目的所需的指导。实现紧急设计与有意结构的正确平衡是有效开发大规模系统的关键。

通过架构实现持续交付和按需发布

架构师在设计能够为用户提供持续价值流的系统方面发挥着关键作用。 Enterprise Architects在Portfolio Level上定义启动器，而System and Solution Architects / Engineering通常在Program和Large Solution级别定义它们。定义启动器的架构师帮助引导他们通过看板系统，提供分析，估计和实施它们所需的指导。此支持确保受影响的元素 - 子系​​统，组件，功能，协议，内部系统功能 - 具有支持路线图中近期特性和功能所必需的体系结构。

为了避免BDUF方法，企业承诺逐步实现体系结构。这意味着必须将启用器史诗分成启用器功能和/或功能，这些功能和/或功能最终由各个ART实现。每个启用程序功能必须在程序增量（PI）中完成，以确保系统始终运行 - 这意味着它可以部署，即使在开发过程中也是如此。

架构是持续交付管道（CDP）的关键推动因素，架构跑道与构建CDP有关。有效的CDP通过持续集成和持续部署为团队提供即时质量反馈。它还通过直接的用户反馈和经过验证的学习为持续探索和按需发布提供支持（参见Lean UX。结果是一种适应性和适用性的高质量产品。

建造架构跑道

当新平台特别具有创新性，或者在全新开发的情况下，系统或解决方案架构师/工程师在定义和构建跑道方面发挥作用是很常见的。通常，新的基础架构最初只需要几个敏捷团队就位 - 有时在最初的几次迭代期间，架构师/工程师担任产品负责人，如图1所示。

图1.启动架构跑道

建立跑道的规则既简单又敏捷：

•     构建跑道的团队像程序中的其他敏捷团队一样迭代。
•     归功于工作解决方案，而不是模型和设计。
•     时间就是生命。实现和证明新架构应该只需要几次迭代。
•     之后很快，该程序扩展为添加一些功能团队，他们使用初始的可消耗功能测试新架构，如图2所示。

图2.在新跑道上实施一些新功能

与此同时，团队建立了额外的架构跑道，如图3所示。

图3.构建架构跑道的进展

为了支持稳定的速度，架构跑道需要不断维护和扩展。容量分配（参见计划和解决方案积压）用于确保对启动器的持续投资 - 扩展跑道所需的活动。

产品/解决方案管理和架构师/工程师与受影响的团队合作，定义了许多这些促成因素。但实施是ART的责任。在支持成功的近期交付的同时，架构跑道不应过度限制开发的远程技术承诺。只需要适量的架构跑道：

•     太多了，体系结构限制了团队，并且与当前的上下文断开连接
•     太少了，团队将难以制定并履行他们的近期承诺

消费架构跑道

有了新的架构，并且已经部署了有价值的功能，所有这些都很好。然而，这种初步成功可能是暂时的，因为随着时间的推移，许多自然力量将倾向于消耗架构：

•     敏捷团队很快 - 他们拥有无与伦比的专注力和能力来提供新功能，从而消耗现有的跑道
•     产品所有者和产品/解决方案管理人员不耐烦 - 他们在内部系统功能上投入了一些时间，他们会快速将积压优先级转移到用户愿意支付的功能上
•     架构本身很脆弱，需要不断发展 - 技术变化迅速，过时
•     客户需求快速变化 - 在当今快节奏的数字经济中，机遇和威胁迅速出现，客户需求不断发展

除非敏捷团队确实参与其游戏，否则结果将如图4所示。

图4.使用架构跑道

延伸架构跑道

团队如何避免在他们开始的地方回来？通过认识到投资架构不能是一次性或罕见的事件。毕竟，ART使用各种看板系统在连续流程中运行。因此，团队必须致力于不断详细阐述，分析和实施推动因素。此外，架构师/工程师和敏捷团队需要掌握将启动器分成小片的技能，这些技巧可以在每次迭代和PI期间实施，从而不断为客户提供价值（参见系统和解决方案架构师/工程部和敏捷软件需求，第20章和第21章[2]，用于增量实施策略）。

大型解决方案中的架构跑道

在构建非常大的系统时，架构跑道扮演着更为关键的角色，因为多个ART作为解决方案培训的一部分为同一解决方案做出了贡献。 Business Solutions和Lean Systems的文章描述了构建大型解决方案的八种实践，其中有几种与架构跑道密切相关：

•     在解决方案意图中不断细化系统规范 - 解决方案Intent以非功能需求（NFR）的形式定义了许多约束。许多NFR都是跨领域的问题，可以通过有意为其实施和测试构建架构支持来解决和简化。解决方案中的更改意图可能会创建额外的工作来构建更多的体系结构跑道或使现有跑道无效。
•     应用多个规划视野 - 在大型解决方案中，基础功能可能需要较长时间才能实施。这些系统需要更长的架构跑道，通常在程序和/或解决方案看板系统中使用Enabler Epics实现。
•     规模，模块化，可发布性和可维护性的架构师 - 在大型解决方案中实现这些目标需要有意的架构来实施有效的持续交付管道，并通过应用程序遥测确保简化的操作和强大的反馈。
•     持续解决合规问题 - 精益合规方法可以自动化合规数据的测试和生成，从而提供更有效和可预测的结果。此目标通常要求尽早与合规审计人员和当局商定，以就可接受的方法达成一致，然后通过架构跑道创建功能，以确保一致性并消除重大的合规风险。

架构跑道的背景故事

术语“架构跑道”起初是一个类比，同时观察PI级烧毁图表。通常，当团队启动PI时没有足够的架构跑道时，任何依赖于新架构的功能都是高风险。

ART不能总是“降落那些PI”（在PI结束时将燃尽降至零）。在这种情况下，它们不符合PI目标。像飞机一样，PI需要足够的跑道才能安全降落。

在SAFe Big Picture中，随着时间的推移，架构跑道线会上下移动，因为团队会建立一些跑道，然后使用一些跑道，建造更多跑道，然后再使用它。简而言之，任何时候都必须有恰当的数量。

为了延长跑道比喻，飞机（系统）越大，飞行速度（速度）越快，安全降落PI所需的跑道越多。在Agile Architecture中进一步解释了Architectural Runway。

 
学到更多

 

• [1] Leffingwell，Dean。扩展软件敏捷性：大型企业的最佳实践。艾迪生 - 韦斯利，2007年。
• [2] Leffingwell，Dean。敏捷软件要求：团队，计划和企业的精益需求实践。 Addison-Wesley，2011年。
• [3]敏捷软件开发宣言。 http://www.agilemanifesto.org。

 

讨论：请加入知识星球【首席架构师圈】

Linux有创新。我为一些非常好的技术特性感到骄傲。Linux中有一些其他操作系统所没有的功能。

—Linus Torvalds, creator of Linux



 

特性和功能

特性是满足涉众需求的服务。每个特性都包含一个收益假设和验收标准，并且根据需要由一个敏捷发布培训(ART)在一个程序增量(PI)中交付。

能力是一种更高级的解决方案行为，通常跨越多种艺术。功能的大小被划分为多个特性，以便于在一个PI中实现它们。

特性也适用于精益UX流程模型，该模型包括最小可销售特性(MMF)的定义、收益假设和接受标准。MMF有助于限制范围和投资，增强灵活性，并提供快速的反馈。功能的行为方式与功能相同。但是，它们处于更高的抽象级别，并且支持大型解决方案的定义和开发。

细节

特性和功能是安全需求模型的核心。它们对于定义、规划和实现解决方案价值至关重要。图1为这些工作项提供了更广泛的上下文:

图1所示。安全上下文中的特性

图1显示了使用特性开发的解决方案。每一个都反映了系统提供的服务，它满足了涉众的一些重要需求。它们被保存在计划Backlog中，并被调整成适合PI的大小，以便每个都交付新的值。特性可以来自于艺术的本地上下文，也可以来自于分离的史诗或功能。

程序和解决方案看板系统支持特性和功能流，它们通过漏斗、分析、积压、实现、验证、部署和发布状态进行处理。这个过程为增量实现提供了合理的经济分析、技术影响和策略。

产品管理和系统架构师/工程分别拥有特性和启用器。非功能需求(NFRs)定义系统属性，如安全性、可靠性、性能、可维护性、可伸缩性和可用性。NFRs作为跨不同积压的系统设计的约束或限制。使用加权最短作业优先(WSJF)对特性进行优先级排序，并在PI边界处进行规划和评审。它们被分解为故事，并随着功能的可用而实现、集成、测试和演示。

描述的功能

功能是使用功能和好处(FAB)矩阵定义的:

• 特征-提供名称和上下文的短短语
• 利益假设——对最终用户或企业提出的可衡量的利益

避免使用旨在支持一个用户角色的“用户故事语音”格式定义功能;特性通常为多个用户角色提供功能。此外，使用相同的方法来描述用户故事和特性可能会让业务人员感到困惑，特别是因为他们通常不熟悉故事。

图2展示了一个具有四个不同特性的FAB示例:

图2。特征与利益矩阵

创建和管理特性

产品经理与产品所有者和其他主要涉众协作，在艺术的本地上下文中定义特性。有些是史诗分裂的结果。

系统架构师通常创建启用器特性。程序backlog用于在业务特性的同时维护启用程序。推动者为架构铺平道路并支持探索，或者可能提供开发、测试和集成计划所需的基础设施。

就像业务特性一样，使能特性可能来自于史诗，也可能出现在本地的艺术级别。通过看板系统的启用程序将受制于计划安排中的容量分配，以确保对进一步解决方案和扩展体系结构跑道给予足够的重视。在每一个PI边界上，分配给新特性(或功能)的资源与启用程序的百分比被估计为指导培训。

排序功能

WSJF优先级模型用于根据产品开发流程的经济性对作业(例如特性、功能)进行排序。由于按照正确的顺序实施正确的工作可以产生最大的经济效益，因此很难高估这个关键过程的重要性。

产品和解决方案管理有权对特性进行优先级划分，而系统和解决方案架构师和工程人员有权对启用特性进行优先级划分。

评估功能

特征估计支持预测价值交付，应用WSJF优先级，并通过将史诗划分为特征并将其单独的估计相加来对史诗进行分级。特性估计通常发生在程序看板的分析状态中，并且依赖于标准化的估计技术，类似于敏捷团队使用的方法(有关详细信息，请参阅迭代计划文章)。在分析过程中，从艺术领域中选择从事探索活动和初步定量化的学科专家。在分析状态期间，调整特性的大小不需要将它们分解为故事或者包含所有可能开发它们的团队。

接受功能

验收标准用于确定实现是否正确并交付业务利益。图3提供了一个例子:

图3。带有验收标准的特性

验收标准降低了实现风险，并使收益假设能够得到早期验证。此外，验收标准通常是各种故事和功能测试的来源，功能测试是开发和自动化的，以支持重构和回归测试。虽然通常应用于事例，但是行为驱动开发(BDD)为特性创建了更好的一致性和详细的验收测试。

产品管理负责接受产品特性。他们使用验收标准来确定功能是否得到了正确的实现，以及是否满足了非功能需求。

功能

本文的大部分内容致力于描述特性的定义和实现，因为它们是对系统行为最常见的描述。功能与特性具有相同的特性和实践。例如,他们:

• 是用短语和利益假说来描述的吗
• 尺寸是否适合一个圆周率，然而，他们往往采取多种艺术实现
• 使用解决方案看板进行推理和批准。解决方案Backlog拥有已批准的功能
• 相关的推动者是否描述并使所有支持有效开发和交付业务功能所需的技术工作可见
• 是否为解决方案管理人员所接受，他们使用接受标准来确定功能是否适合用于目的

功能可能起源于解决方案的本地上下文，也可能是跨多个价值流的投资组合史诗的拆分的结果。另一个潜在的功能来源是解决方案上下文，其中环境的某些方面可能需要新的解决方案功能。

分割特性和功能

功能必须分解为要实现的特性。反过来，它们又被分解为可由团队在迭代中使用的故事。SAFe提供了10种用于分割工作的模式，如Leffingwell[1]第6章所述。

• 工作流步骤
• 业务规则的变化
• 主要工作
• 简单和复杂
• 数据的变化
• 数据的方法
• 推迟系统质量
• 操作
• 用例场景
• 拔尖

图4演示了将功能划分为特性。

图4。将功能划分为多个特性

了解更多

• [1]Leffingwell,院长。敏捷软件需求:团队、程序和企业的精益需求实践。addison - wesley, 2011年。

 

原文：https://www.scaledagileframework.com/features-and-capabilities/

本文：https://pub.intelligentx.net/safe-features-and-capabilities

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

工程是一项伟大的职业。 通过科学的帮助看到想象力的形象出现在纸上的计划是令人满意的。 然后它转向石头，金属或能源的实现。 然后它为男人或女人带来了家园。 然后它提高了生活水平，增加了生活的舒适。 这是工程师的高级特权。

-Herbert Hoover

系统和解决方案架构师/工程

 

系统架构师/工程师负责定义和传达敏捷发布系列（ART）的共享技术和架构愿景，以帮助确保正在开发的系统或解决方案符合其预期目的。

解决方案架构师/工程师负责定义和交流跨多个ART的共享技术和架构愿景，以帮助确保正在开发的系统或解决方案适合其预期目的。

系统和解决方案架构师描述解决方案上下文和解决方案意图，分析技术权衡，确定主要组件和子系统，识别它们之间的接口和协作，定义非功能需求（NFR），通过解决方案看板引导启动器，以及使用客户和供应商帮助确保适用性。

他们在使敏捷发布培训（ART）和解决方案培训团队与共享技术方向保持一致，并与这些团队合作，共同阐述解决方案及其界面，验证技术假设，评估实施方案以及创建持续性方面发挥关键作用。交货管道。在不属于解决方案培训的ART中，System Architects还执行Solution Architects的许多活动。

本文描述了System Architect / Engineering和Solution Architect / Engineering在SAFe中所扮演的角色。虽然角色在大多数方面都相似，但它们可以管理不同程度的关注。在某些情况下，解决方案培训的敏捷发布培训（ART）或解决方案架构师有多个系统架构师，因此这些角色可以由个人或小团队实现。

细节

架构师/工程人员和团队通过提供，沟通和发展解决方案的更广泛的技术和架构视图来支持解决方案开发。

架构师/工程团队同时在计划和大解决方案级别进行。系统架构师/工程师主要在ART的背景下运作，他们与敏捷团队合作，并为ART的子系统和能力领域提供技术支持。解决方案架构师/工程团队为整个解决方案的不断发展的架构功能提供技术领导。

两者都涉及与业务利益相关者，团队，客户，供应商和第三方利益相关者的密切合作，以定义技术基础架构，分解为组件和子系统，以及定义子系统之间以及解决方案和解决方案上下文之间的接口。

在提供解决方案体系结构的一般视图的同时，架构师/工程师通过授权他们做出本地决策来实现价值，从而实现更快的工作流程和更好的经济效益。

一种设计和构建系统的敏捷方法

在精益企业中担任架构师/工程师角色通常需要在人们如何处理工作方面采用新的思维方式和习惯。这种方法改变了架构师应用他们的技术专长和系统思维方式的方式。这些新习惯分为四个方面，如下所述。有关以敏捷方式设计系统和解决方案的更完整视图，请参阅敏捷架构。

•  分散决策 - 在传统方法中，架构师/工程师在解决方案开发中相对较早地做出关键设计决策，期望在不同组件上工作的团队遵循他们的设计。然而，在敏捷方法中，许多技术细节都是基于学习而随着时间的推移而发展的。决定在生命周期基于集合的设计中稍后完成。因此，团队可以信赖制定适应不断变化的需求的本地设计决策，而无需等待架构师制作新设计。
• 启用持续交付管道和DevOps  - 面对不断变化或未知的需求做出有效决策，需要敏捷团队获得有关解决方案有效性的快速反馈。架构师/工程师通过倡导和指导持续交付管道的开发和改进，以及帮助架构师实现按需发布来支持这一需求。
•  拥抱领导角色 - 架构师/工程师是精益敏捷领导者，他们倾向于通过影响而不是精益企业的权威来运作。它们通过教学，指导和帮助提高敏捷团队​​的有效性而产生最大的影响，而不是直接指定解决方案设计。他们为愿景和路线图做出了贡献，以便为解决方案制定课程。
• 充当变革推动者 - 架构师/工程师也在人类系统上采取更多行动，创造技术以创造更大的灵活性和有效性。作为精益敏捷领导者，架构师/工程师通过作为精益敏捷卓越中心（LACE）的成员参与，确保组织有效运作。为价值流图制作研讨会，培训和辅导工程师提供技术敏捷性。

系统/架构师工程的职责

架构师/工程团队是精益敏捷领导者，他们通常负有以下责任：

•     参与解决方案的规划，定义和高级设计，并探索解决方案的替代方案
•     通过适当的设计指南和投资倡导，实现持续交付管道
•     积极参与持续探索流程，作为持续交付管道的一部分，特别是与启动器Epics一起
•     定义子系统及其接口，为子系统分配职责，了解解决方案部署，并与解决方案上下文交互需求
•     与客户，利益相关者和供应商合作，建立高级解决方案意图，以及解决方案意图信息模型和文档要求
•     在解决方案级别建立关键NFR，参与其他人的定义
•     在经济框架内运作，以验证设计决策的经济影响
•     与投资组合利益相关者（尤其是企业架构师）合作，开发，分析，分离和实现启动器史诗的实现
•     参与计划增量（PI）计划以及PI前后规划，系统和解决方案演示，以及检查和调整事件
•     定义，探索和支持ART和解决方案培训促进者的实施，以发展解决方案意图，直接与敏捷团队合作实施
•     规划和开发架构跑道，以支持新的业务特点和功能
•     使用产品和解决方案管理来确定启用工作的容量分配
•     支持计划和解决方案看板的技术/工程方面
•     提供监督并培养内置质量，团队和技术敏捷性

 

系统架构师/工程师参与大价值流

以上部分重点介绍了系统架构师/工程师在ART背景下的作用。对于需要多个ART的大型解决方案，系统架构师/工程师可以在多个ART之间进行协调，包括：

•     与解决方案架构师/工程师协作 - 系统架构师/工程师与解决方案架构师/工程师合作，了解他们的解决方案如何适应并支持整体解决方案的更大功能和方向。这涉及参与解决方案积压优化和优先级排序，定义功能启动器和NFR，以及为各种组件和子系统分配架构职责。
•     参与PI规划前和规划后 - 系统架构师/工程师参与Pre-PI规划会议，与解决方案培训利益相关方合作，为即将到来的PI规划会议定义架构方法，能力路线图和高级目标。在PI后计划会议中，系统架构师/工程师帮助将结果汇总到商定的解决方案PI目标集中，并验证各种ART技术方向的一致性。
•     参与架构同步 - 系统架构师/工程师参与架构同步，以确保在整个解决方案培训中管理新兴设计和权衡的一致性，从而允许频繁的机会引导实施方法，而不会成为延迟的来源。
•     参与解决方案演示 - 系统架构师/工程师参与解决方案演示，经常展示他们的ART贡献的功能，并审查其他ART的贡献，采用系统视图，着眼于适用性。
•     与发布管理协作 - 在大型系统中，发布管理也发挥着重要作用。系统架构师/工程师与产品管理和关键利益相关者就解决方案元素的进度，预算，发布策略和可释放性进行协作。
•     跨越ART的协调技术方法 - 系统架构师/工程师与敏捷团队积极合作，确保在了解整体解决方案的同时做出紧急设计选择，并最大限度地降低技术复杂性并避免不必要的功能重复。

解决方案架构师/工程师的职责

解决方案架构师/工程师在系统架构师/工程师方面扮演着类似的角色，但在大型解决方案层面，他们专注于为完整的解决方案创建技术一致性，而不是关注特定组件。职责包括与投资组合利益相关者，客户，供应商，ART和解决方案列车合作，使架构方向与解决方案意图保持一致。他们在解决方案愿景，解决方案路线图，解决方案看板，非功能要求，启动器功能和解决方案演示活动方面也有类似的职责。

解决方案架构师/工程师在PI前后规划以及大型解决方案级别I＆A研讨会中发挥着至关重要的作用。他们还与供应商合作，确保了解供应商交付能力的技术特征，并协助这些问题的架构整合。

解决方案架构师/工程师与解决方案管理和解决方案培训工程师一起工作，作为三人组的一部分，他们分担了解决方案培训成功的大部分责任。

学到更多

 

• [1]国际系统工程理事会。 “什么是系统工程？”https://www.incose.org/systems-engineering。
• [2] Leffingwell，Dean。敏捷软件要求：团队，计划和企业的精益需求实践。 Addison-Wesley，2011年。
• [3] Kim，Gene和Jez Humble，Patrick Debois，John Willis。 DevOps手册：如何在技术组织中创建世界级的敏捷性，可靠性和安全性。 IT革命出版社。 Kindle版。

 

原文：https://www.scaledagileframework.com/system-and-solution-architect-engineering/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

整体大于部分之和。

——亚里士多德

系统团队

系统团队是一个专门的敏捷团队，它帮助构建和支持敏捷开发环境，通常包括支持连续交付管道的工具链的开发和维护。系统团队还可能支持来自敏捷团队的资产集成，在必要时执行端到端解决方案测试，并协助按需部署和发布。

在SAFe中，敏捷团队不是独立的单元。相反，它们是敏捷发布培训(ART)的一部分，共同负责交付更大的系统和解决方案价值。在向敏捷的过渡期间，通常需要额外的基础设施工作来更频繁地集成解决方案资产。为了实现这一点，通常会组建一个或多个专门的系统团队。它们帮助构建环境，并帮助进行系统和解决方案集成。它们还帮助演示解决方案的发展过程。

一旦基础设施成熟，系统团队有时就会从一门艺术中消失，而开发团队则负责维护和使用系统。在更大的解决方案中，专业知识更有可能保留在一个或多个系统团队中，其中集中某些人员、技能和技术资产可以带来最佳的经济价值。

细节

系统团队在构建和使用敏捷开发环境基础结构(包括持续交付管道工具链)以及集成敏捷团队的资产和执行端到端解决方案测试方面提供了一种或多种技术支持。他们通常在每次迭代结束时参与系统演示，并在每次程序增量(PI)结束时参与解决方案演示，或者根据情况更频繁地参与。演示通过提供关于端到端解决方案的适用性和完整性的快速反馈来支持团队和其他涉众。系统团队还可以协助发布和协调大型价值流的解决方案培训。

然而，系统团队和敏捷团队共同承担这一责任。否则，系统团队将成为瓶颈，敏捷团队将无法完全胜任或对完整的端到端价值交付负责。

解决方案中的系统团队

对于需要构建解决方案序列的大型、多艺术的价值流，系统团队对于支持更大规模的集成挑战尤其有用。根据价值流的范围和复杂性，有三种构建系统团队的主要模式:

• 每个ART都有一个系统团队，在没有额外帮助的情况下协调解决方案集成和验证
• 有一个只针对解决方案培训的系统团队，它可以为它的每种艺术履行这些职责
• 艺术和解决方案培训都有系统团队

关于使用哪种模式的决定取决于价值流的特定上下文。因素包括价值流中的ART结构(围绕功能或组件构建)、解决方案体系结构、跨ART的分支和集成策略、系统可测试性和开发基础设施。

责任

系统团队的主要职责是构建开发基础设施、解决方案集成、端到端测试、系统和解决方案演示以及发布。下面几节将描述这些职责。

建设发展基础设施

良好的基础设施支持高ART velocity，因此系统团队可以:

• 创建和维护持续交付管道工具链，包括持续集成、自动化构建、自动化构建验证测试和自动化部署
• 为解决方案演示和用户验收测试创建平台和环境
• 促进与第三方合作的技术方面，如数据或服务提供商和托管设施

解决方案的集成

复杂的解决方案还需要系统团队做以下工作:

• 参与项目导入计划，以及大型解决方案级别的项目导入前和项目导入后计划会议，并对待办事项进行细化，以定义集成和测试待办事项项
• 为适当的主干和分支模型确定并帮助维护决策和策略
• 运行解决方案级别的集成脚本，或者在还不可能实现自动化的地方手工集成
• 参与其他团队的日常活动

端到端测试

系统团队还可能执行一些必要的测试任务，以支持敏捷团队:

• 创建新的自动化测试场景
• 将测试场景扩展到更接近生产的数据集
• 将各个团队设计的测试用例组织到有序的套件中
• 为新特性执行手工测试并运行自动化测试
• 优先考虑耗时的测试、重构和运行减少的测试套件
• 帮助团队创建可独立运行的简化测试套件
• 根据非功能需求(NFRs)测试解决方案性能，并协助系统和解决方案工程确定系统不足和瓶颈

系统和解决方案演示

在每个迭代的适当时间，ART向系统演示中的涉众展示当前的整个系统。同样，解决方案培训必须在解决方案演示中集成并显示进度。系统团队通常帮助准备技术环境，因此他们能够充分且可靠地演示新的解决方案功能。

Release

系统团队通常具有与不断发展的解决方案相关的独特技能和经验。它可能包括QA和运维人员，系统架构师/工程师通常是这个团队的成员。他们已经在多个迭代中看到了解决方案，这意味着他们理解它是什么，它做什么，以及它如何满足所有预期的需求。从这个角度来看，系统团队可能直接参与支持PI。作为DevOps和连续交付管道活动的一部分，他们将做任何必要的工作来帮助ART或解决方案培训准备、打包并将解决方案部署到目标环境中。

平衡解决方案集成和测试工作

然而，系统团队永远不能成为管道工具和集成挑战的完整解决方案。敏捷团队还必须对他们正在创建的东西有一个更大的愿景。否则，即使是本地优秀的敏捷团队也不会带来好的经济效益。有效的解决方案开发需要共享最佳实践。例如，如果只是系统团队在测试NFRs，而单个团队甚至不执行轻量级性能测试，那么通过这些关键质量测试所需的返工将会降低整个ART速度。类似地，如果敏捷团队没有持续集成(至少没有集成与之交互的即时组件)，那么系统团队的工作将是一个漫长而痛苦的过程。最大化ART速度需要敏捷团队和系统团队之间的平衡感，如图1所示。随着成熟度和自动化，集成职责的最佳点向左移动。

图1所示。敏捷团队和系统团队之间集成工作的最佳平衡

原文：https://www.scaledagileframework.com/system-team/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

细节决定成败。

-Common谚语

非功能性要求

非功能需求（NFR）定义系统属性，例如安全性，可靠性，性能，可维护性，可伸缩性和可用性。它们作为跨越不同积压的系统设计的约束或限制。

也称为系统质量，非功能性需求与功能性Epics，Capabilities，Features和Stories一样重要。它们确保整个系统的可用性和有效性。未能满足其中任何一个可能导致系统无法满足内部业务，用户或市场需求，或者不符合监管机构或标准机构强制要求的系统。

NFR是持久性质量和约束，与功能要求不同，它们通常作为每个迭代，程序增量（PI）或发布的完成定义（DoD）的一部分重新访问。 NFR存在于所有积压中：团队，计划，解决方案和投资组合。

NFR的正确定义和实施至关重要。过度指定它们，解决方案可能成本太高而无法生存;指定不足或低于它们，系统将不适合其预期用途。探索，定义和实施NFR的自适应和增量方法是敏捷团队的一项重要技能。

细节

考虑影响解决方案整体适应性的所有类型需求的一种方法是管理要求[5]中描述的“FURPS”分类：功能，可用性，可靠性，性能和可支持性

功能需求主要表现在用户故事以及功能和功能中。这是大多数工作发生的地方。团队构建了为用户提供价值的系统，解决方案开发的大部分时间和精力都致力于此。

FURPS是非功能需求的占位符。虽然它们可能有点微妙，但NFR对系统成功同样重要。 NFR可以被认为是对新开发的限制，因为每个NFR都为构建系统的人消除了一定程度的设计自由度。例如，基于SAML的单点登录（SSO）是套件中所有产品的要求。 （SSO是功能要求，而SAML是约束。）

NFR可以涵盖广泛的业务关键问题，这些问题通常很难通过功能要求来解决。作为对系统设计人员的提醒，[1]中描述了这种潜在NFR的综合列表。

NFR发生在所有级别

NFR与SAFe各级的积压相关，如图1所示。

图1. NFR发生在所有级别

由于NFR是敏捷发布系列（ART）和价值流创建的解决方案的重要属性，因此它们最明显的表现形式是程序和大型解决方案级别。系统和解决方案架构师和工程师通常负责定义和完善这些NFR。

所有团队都必须了解他们为系统创建的特殊属性。加速NFR测试，而不是推迟测试，有助于培养内置质量实践。团队将相关的NFR纳入其国防部，将其用作本地设计和实施决策的约束，并自行负责某些级别的NFR测试。否则，该解决方案可能不满足关键NFR，并且在该过程的后期发生的校正成本可能非常高。

此外，团队积压NFR也很重要，因为它们会对出现的功能和子系统产生约束和性能要求。

投资组合积压可能也需要NFR。这通常是跨系统质量的情况，例如单点登录情况。其他示例包括对开源使用，安全要求和监管标准的限制。如果尚未实现特定的投资组合级别NFR，则可能需要启动器实施它。 NFR在“史诗假设陈述”中定义，用于描述商业和推动者史诗。

NFR作为Backlog约束

NFR在框架中被建模为积压约束，如图2所示。

图2.积压受NFR限制

此外，SAFe需求模型指定NFR可以约束零，一些或许多积压项目。此外，为了知道系统符合约束，大多数NFR需要一个或多个系统质量测试，如图3所示。

图3.积压项目，NFR和系统质量测试之间的关系

许多NFR都是需要解决的推动因素。之后，他们会限制系统和所有新的积压项目。

NFRs对解决方案开发的影响

非功能性需求可能对解决方案开发和测试产生重大影响。 NFR很难指定;太容易过火了。例如，像“99.999％可用性”这样的声明可能会比“99.98％的可用性”以指数方式增加开发工作量。有时这是必要的，有时则不是。但是那些定义要求的人必须很好地理解NFR的影响。类似地，如果没有给予足够的考虑，诸如重量，体积或电压的物理约束可能导致解决方案过于复杂和昂贵。

解决方案的经济框架应包含评估NFR的标准。应在与成本和其他考虑因素进行权衡的背景下看待NFR。 NFR也影响供应商，因为它们不正确地宣布它们，或者没有经济框架的完全权衡后果，可能导致不必要的复杂和昂贵的系统和组件。

定期重新评估NFR也很重要。与其他要求不同，NFR是积压的持久约束，而不是积压项本身。因此，在PI Planning期间，它们可能并不总是出现。但NFR在开发过程中确实会发生变化，因此确保它们得到解决非常重要。

NFR和解决方案意图

解决方案Intent是解决方案的唯一真实来源。因此，它包括NFR以及功能要求。它还包括NFR之间的链接，它们影响的要求以及用于验证它们的测试。 NFR在理解固定与可变解决方案意图的经济学方面发挥着关键作用。

图4.解决方案意图

在早期，一些功能尚不清楚，需要在开发期间与客户进行测试和协商。 NFR也是如此。有些是固定的，事先众所周知;其他人将随着解决方案而发展。

通过施加约束，NFR可能影响广泛的系统功能。因此，在以下情况下，它们是需要考虑的重要因素：

•     分析业务史诗，功能和功能
•     规划和建造建筑跑道
•     重构以更好地反映不断增加的解决方案领域知识
•     对制造，部署，支持，安装，可维护性等施加DevOps限制

用于帮助开发解决方案意图的工具提供了一些机制来建立定义和实施NFR的经济方法：

•     合规性 - 这证明系统或解决方案符合法规，行业和其他相关标准和准则
•     基于模型的系统工程（MBSE） -  MBSE可用于模拟NFR的影响，并可链接到验证它们的测试
•     基于集合的设计（SBD） -  SBD为实现NFR提供了不同的选项，可以指导一系列边缘案例测试以支持设计决策

详细说明NFR

与所有其他要求一样，必须对NFR进行量化，以确保每个人都能清楚地理解利益相关者的愿望。 [3]中的图5量化了NFR要求。第1步定义NFR的质量，包括其名称，规模和测量方法。第2步量化NFR的可测量值，包括当前测量值（基线），要达到的值（目标），变得不可接受的值（约束）。图5中的示例显示了自动驾驶车辆速度限制检测的可测量效率。平均而言，用户当前手动设置每英里的速度.1时间，从而覆盖自动化解决方案。新系统功能将提高到每英里0.01倍，但在实施过程中不应低于每英里.15次。

图5.定义NFR质量

考虑以下标准有助于定义NFR：

•     有界 - 当他们缺乏有限的背景时，一些NFR是无关紧要的（甚至是有害的）。例如，性能考虑因素对于主应用程序而言可能是至关重要的，但对于管理和支持应用程
•     独立 -  NFR应相互独立，以便在不考虑或影响其他系统质量的情况下对其进行评估和测试。
•     可协商 - 了解NFR业务驱动因素和有限的上下文要求可转让性。
•     可测试 -  NFR必须以客观，可测量和可测试的标准陈述，因为如果您无法测试，则无法发货。

实施方法

许多NFR规定必须进行一些额外的工作 - 无论是现在还是将来 - 以满足它们。有时NFR必须一次全部实施;其他时候，团队可以采取更多的增量方法。经济框架中描述的权衡取决于实施方法。实施应该以允许几个学习周期来确定NFR的正确水平的方式进行。

•     一下子 - 一些NFR似乎是新的问题，需要立即实施。例如，衍生品交易的新监管规则，如果不立即适应，可能会使公司完全退出市场或导致监管违规。
•     逐步增加的故事路径 - 在其他时候，团队可以选择。例如，如图6所示，可以随着时间的推移处理对显着改善的性能的需求，一次一个故事。

图6. NFR的增量实现

NFR的实施也受到ART组织方式的影响。围绕建筑层构建的ART将发现完整地实施和测试NFR具有挑战性。然而，围绕能力组织的火车将更容易实施，测试和维护系统性NFR。

使用Agile Architecture支持NFR的开发，并在需求发展时帮助保持灵活性。

测试非功能需求

当然，要知道系统符合NFR，必须对其进行测试。敏捷测试象限的象限4，'系统质量测试'是大多数NFR测试的基础。由于其范围和重要性，NFR测试通常需要系统团队和敏捷团队之间的协作。为了防止技术债务，团队应尽可能自动化，以便这些测试可以连续运行，或至少按需运行。

然而，随着时间的推移，即使在自动化的情况下，越来越多的回归测试可能会消耗太多的处理时间和太多的资源。更糟糕的是，它可能意味着NFR测试可能仅在某些情况下或仅与专业资源或人员一起实用。为了确保实用性和持续使用，团队通常需要创建简化的测试套件和测试数据，如图7所示。

图7.与系统团队和敏捷团队的协作，以创建更实用的NFR测试策略

虽然部分测试听起来不太理想，但它有助于提高系统质量：

•     当团队可以在本地应用简化的测试套件时，他们可能会发现测试数据或测试方法的不一致
•     团队可以创建新的和独特的测试，其中一些可以被系统团队采用以帮助构建更大的集合
•     测试基础架构和配置可能会持续改进
•     团队对NFR的影响有了实际的了解，这有助于改进业务和启动器功能的估算

即便如此，在某些情况下，可能无法每天获得可以测试NFR的环境（例如，车辆引导软件的现场测试）。在这些情况下，可以使用以下方法[4]：

    使用虚拟化硬件

    创建模拟器

    创建类似的环境

在所有情况下，有效地测试NFR需要一些思考和创造力。另一方面，缺乏NFR测试可能会增加大量技术债务或更糟糕的系统故障的风险。

 

学到更多

 

• [1] https://en.wikipedia.org/wiki/Non-functional_requirement
• [2] Leffingwell，Dean。敏捷软件要求：团队，计划和企业的精益需求实践。 Addison-Wesley，2011年。
• [3] Leffingwell，Dean和Ryan Shriver，非功能性要求（系统质量）敏捷风格，敏捷2010。
• [4] Larman，Craig和Bas Vodde。扩展精益和敏捷开发的实践：大规模Scrum的大型，多站点和离岸产品开发。 Addison-Wesley，2010年。
• [5] Leffingwell，Dean和Don Widrig。管理软件需求：用例方法（第二版）。艾迪生 - 韦斯利，2003年。

 

原文：https://www.scaledagileframework.com/nonfunctional-requirements/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

 

敏捷架构是一组价值观，实践和协作，支持系统的主动，进化设计和架构。这种方法包含DevOps思维模式，允许系统架构随着时间的推移不断发展，同时支持当前用户的需求。它避免了与启动 - 停止 - 启动性质相关的开销和延迟，以及相位门过程和Big Up Front Design（BUFD）固有的大规模重新设计。

敏捷架构通过协作，紧急设计，有意架构和简单设计支持敏捷开发实践。与敏捷开发实践一样，敏捷架构也可以设计可测试性，可部署性和可发布性。快速原型设计，领域建模和分散式创新进一步支持了它。

细节

系统的体系结构可以加速或阻碍为业务提供频繁，独立的发布以实现其目标的能力。敏捷架构师通过优化架构来支持业务一致性，以支持端到端的价值流。这使企业能够实现在最短的可持续交付周期内持续提供“价值”的目标。敏捷架构师通过支持“足够”的架构跑道来支持不断变化的业务需求，从而引领这一过程。他们不断投资于传统的现代化计划，并知道在哪里重构以消除瓶颈。他们以明确的业务术语传达对这些持续技术目标的需求。

为了通过持续交付管道支持持续的价值流，敏捷架构：

1.     随着时间的推移不断发展，同时支持当前用户的需要
2.     避免与相位门和BUFD方法相关的开销和延迟
3.     确保'系统始终运行'
4.     突出紧急设计和意向性
5.     采用整个价值流的系统视图

SAFe的精益敏捷原则为敏捷架构实践提供了信息。虽然都适用，但有三个与建筑特别相关。在进行特定设计之前，敏捷架构师使用快速学习周期（原理＃4）来探索替代方案（原则＃3）并获得最佳解决方案。他们还通过定义和传达架构愿景和战略，然后与构建它的团队协作和指导，为分散决策（原则＃9）创造环境。

角色和合作

SAFe定义了三个架构师角色：企业，解决方案和系统架构师，它们在各自的级别（程序，解决方案和产品组合）中解决这些问题。他们定期在各级别之间进行协作，以确保协调一致并解决出现的问题和疑虑。如图1所示，角色需要所有必要的架构技能来做出技术决策。因此，角色可以由不止一个人填补，以确保足够的知识并防止瓶颈团队的架构决策。

图1. SAFe架构角色跨越架构域

架构也是与其他SAFe角色的合作。在Agile Release Train中，System Architects通过Architectural Runway，非功能需求以及Continuous Delivery Pipeline（CD管道）的设计和支持来传达技术路径。架构还可以实现内置质量。系统团队通过构建支持基础架构来实现架构愿景，使敏捷团队能够设计，实施，测试和交付价值。 System Architects与企业和解决方案架构师协调，以确保他们的解决方案与更大的愿景保持一致。最后，任何角色的架构师都是精益敏捷领导者，负责指导团队并提高贡献者的整体能力。

平衡意图和新兴设计

传统的架构方法导致了广泛的早期架构工作。这可以创建丰富的文档和未经验证的决策。设计架构以更好地符合业务需求的另一种方法是意向性和紧急设计的结合，其中架构从开发人员创建系统以查看哪些有效。敏捷架构平衡了意图和出现：

1.     故意架构 - 定义一组有目的的，有计划的架构策略和计划，这些策略和计划可增强解决方案设计，性能和可用性，并为团队间设计和实现同步提供指导。
2.     紧急设计 - 为完全演化和增量实施方法提供技术基础。这有助于开发人员和设计人员响应即时用户需求，从而允许设计随着系统的构建和部署而发展。

通过这种平衡，Agile架构是一种精益敏捷方法，可以解决构建企业解决方案的复杂性。它支持当前用户的需求，同时发展系统以满足近期的未来需求。一起使用，紧急设计和意向性不断建立和扩展建筑跑道，为未来的商业价值生产提供技术基础。

构建DevOps和按需发布

敏捷架构通过确保解决方案的架构以实现持续交付来促进DevOps文化。建筑师参与CD管道的设计和执行，并传播和举例说明SAFe的CALMR原则。它们允许通过定义最小可行（“恰好足够”）体系结构来确定决策，确保系统元素之间的松散耦合，支持接口的创建和发展，以及通过公共注释，属性和命名约定将体系结构作为代码培养。敏捷架构还通过自动化架构合规性检查来提高质量。

为了支持持续部署，Agile架构将部署与发布分离。功能部分持续部署到生产环境中，但只能按需提供给最终用户。频繁部署可在CD管道中建立信任，并减少由更传统的治理实践（例如，发布管理）引起的延迟。这种信任使各个团队和敏捷发布列车（ART）能够在真实的生产环境中独立探索和测试想法。

CD管道以值假设开始和结束，在Continuous Exploration中定义它并最终在按需发布中对其进行测量。系统架构提供必要的遥测来衡量假设，以支持团队和ART的创新会计和其他使用数据，以验证他们的假设。敏捷体系结构还支持CD管道，将其他系统因素视为一流的体系结构问题，例如测试体系结构和测试数据管理。

使架构与商业价值保持一致

在数字时代，企业依靠技术为客户创造价值。随着业务战略的变化，提供该战略的技术，系统和业务应用程序必须随之改变。图2显示了客户订单和产品交付的示例操作值流。操作步骤以绿色显示，系统和应用程序支持以下步骤。支持应用程序和系统的人员可以实现对客户体验的任何业务变更。架构师与业主和产品经理密切合作，以确保这些系统能够实现当前和未来的业务目标。

图2.支持客户订单放置和交付的系统。

战略主题，投资组合画布和投资组合愿景影响架构并推动架构跑道。它们为投资组合中的技术投资提供约束，方向和总体背景。从更广泛的角度来看，架构还必须考虑更大的企业战略，包括跨组合的意识，尤其是企业架构师。

开发解决方案愿景，解决方案意图，路线图

使架构与业务战略保持一致可以加速业务目标的实现。建筑师通过将战略从战略主题转化为解决方案来实现业务目标。这些解决方案由其愿景，解决方案背景和解决方案意图来定义。解决方案意图是一个知识的生存库，代表系统在需求，设计，结构，行为和所有其他架构问题上的单一事实来源。解决方案意图包括决策，模式，模型和其他技术信息，以作为最低限度的文档。解决方案意图捕获系统约束，包括非功能需求（NFR）。与所有其他要求一样，NFR通过自动化测试不断验证，以确保质量和合规性。

路线图定义了实现解决方案的计划。架构师和团队在路线图中协作定义推动因素，探索技术选项并构建架构跑道，提供实现这些里程碑的早期反馈。团队提供有关架构决策的反馈，因为他们在其上构建功能，平衡意图和出现。

该路线图推动了Backlog，它定义了ART的所有工作。架构师与产品管理部门合作，确定新功能与技术工作的优先级和平衡。他们预计技术债务会受到流量和建筑跑道需求的影响，并提倡优先排序。

为程序增量规划准备架构

每个增量，团队构建最高优先级的功能和启动器。架构师与产品管理部门合作，定义这些近期工作项目并确定其优先级。它们提供了可行性见解，有助于定义和确定当前功能及其验收标准。他们还会考虑未来的功能，并在积压中定义启动器，以便团队探索并获取确保未来功能可行性的知识。

建筑师还考虑其ART之外的技术依赖性，或者与解决方案培训中的其他ART或企业中的其他ART一起考虑，作为这些协调活动中的关键合作者。他们与团队协作以减少PI Planning期间的发现，并帮助确保团队在PI Planning期间做出必要的决策。

通过PI Planning协调架构

在PI Planning期间，架构师支持团队创建下一个增量计划。他们将建筑简报作为规划议程的一部分。随着团队在突破期间制定计划，建筑师在房间内漫游，以确保团队正确规划技术工作并确保他们正确地考虑到Program Enabler的工作。他们解决任何问题和疑虑。

建筑师支持管理评审，以解决潜在调整的架构和技术问题。他们还与业主一起参与，因为他们为团队的PI目标分配价值。从业务角度讲，他们解释了推动者和其他技术工作如何支持他们的总体目标，并游说他们的需求和重要性。

通过PI执行支持持续交付

建筑师在启动器中拥有计划/解决方案级别的技术和勘探工作，因此，指导团队的执行进度。他们可以参加这些团队的Sprint计划和/或Sprint演示活动，以跟踪进度，解决问题并调整方向。它们通常也可供团队使用，用于指导和指导，并确保快速解决问题和问题，以便架构不成为瓶颈。

每个增量，架构师都可以确保团队演示启动器工作的结果，包括新知识，架构跑道添加以及对Continuous Delivery Pipeline的任何添加。对于大型解决方案，Architect Sync事件可确保架构师保持一致并在大型解决方案级别共享进度，架构师定期在架构同步中会面，如图3所示。

图3.解决方案训练PI执行环境中的架构同步

支持新的战略主题和价值流

架构必须不断发展以满足不断变化的业务需求和机遇。否则，技术成为业务执行的瓶颈。业务战略的变化反映在新的或经过修改的战略主题中，尽管投资组合画布将其转化为新的或修改过的解决方案和/或价值流。 Enterprise Architects通过提供输入，参与价值流图制作研讨会以及设定对技术可行性的期望来支持和影响此过程。一旦制定了新方向，Enterprise Architects将与系统和解决方案架构师合作，以实现新的业务方向。他们传达新战略并展示其如何改变解决方案愿景，意图和路线图。

Enterprise Architects还协调整个产品组合中的架构工作，确保跨解决方案和价值流的一致性。它们为技术和平台的长期发展以及组合解决方案集的更大的非功能性需求（安全性，合规性，性能等）提供技术指导。他们经常担任投资组合级别推动者的史诗所有者，以确保技术的大幅度转变与业务战略保持一致。

引领精益敏捷转型

由于他们的知识和经验，建筑师经常受到开发社区的尊重和高度重视。因此，建筑师在任何SAFe转型中都发挥着关键作用。建筑师是精益敏捷的领导者，因此，模型更精简的思维和操作方式，以便开发人员从他们的榜样，指导和鼓励中学习。它们实现了自主权并鼓励掌握增长开发社区的知识库和技能。 SAFe架构师体现了新的工作方式，参与创建组织的（实施）路线图，并有助于加速作为精益敏捷领导者的采用。

Learn More

[1] Manifesto for Agile Software Development. http://agilemanifesto.org/.

[2] Crispin, Lisa and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009.

[3] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[4] Gregory, Janet, and Lisa Crispin, More Agile Testing: Learning Journeys for the Whole Team, Addison-Wesley, 2015.

 

讨论：请加入知识星球【首席架构师圈】

“我们的问题不同”的印象是一种困扰全世界管理的常见疾病。 当然，它们是不同的，但有助于提高产品和服务质量的原则具有普遍性。

-W。 爱德华兹戴明

SAFe基于九个不可变的潜在精益敏捷原则。 这些原则和经济概念激发并传达了SAFe的作用和实践。

图1. SAFe精益敏捷原则

为什么要关注原则？

构建企业级软件和网络物理系统是我们行业当前面临的最复杂挑战之一。例如：

•     构建此类软件和系统需要数百万行软件
•     它结合了复杂的硬件和软件交互
•     它跨越多个并发平台
•     它必须满足苛刻和无情的非功能性要求（NFR）

当然，构建这些系统的企业也越来越复杂。它们比以往更大，更分散。兼并和收购，分布式跨国（和多语言）发展，离岸外包和快速增长都是解决方案的一部分。但它们也是问题的一部分。

幸运的是，我们拥有可以提供帮助的惊人且不断增长的知识体系。它包括敏捷原则和方法，精益和系统思考，产品开发流程实践和精益流程。思想领袖们走在我们面前的这条道路上，留下了数百本书和引用的书。

SAFe的目标是综合这一知识体系，以及从数百个部署中吸取的经验教训。这创建了一个集成的，经过验证的实践系统，可以提高员工敬业度，上市时间，解决方案质量和团队生产力。然而，鉴于前面讨论的复杂性，对于每个企业面临的独特挑战，没有现成的解决方案。可能需要进行一些定制和定制，因为并非每个SAFe建议的做法都适用于所有情况。这就是我们努力确保SAFe实践基于基本稳定原则的原因。这样我们就可以确信它们适用于大多数情况。

如果这些做法不尽如人意，那么基本原则将指导团队确保他们不断前进到精益之家的目标：“最短的可持续交付时间，为人们和社会提供最好的质量和价值“这也有价值。

SAFe实践基于九个概念，这些概念是从敏捷原则和方法，精益产品开发，系统思考和成功企业观察发展而来的。每个都在该原则名称的文章中详细描述。此外，原则的实施例在整个框架中出现。它们在以下部分中进行了总结，每个部分都有一个完整的文章。

＃1  - 从经济角度出发

在最短的可持续交付周期内为人们和社会提供最佳价值和质量需要对建筑系统的经济学有基本的了解。在适当的经济环境中做出日常决策至关重要。主要方面包括制定和传播增量价值交付战略，建立预算和护栏，以及为解决方案开发创建经济框架。

＃2  - 应用系统思考

戴明指出，工作场所面临的问题需要了解工人使用的系统。而且，系统很复杂。它有许多相互关联的组件（人员和流程），它们具有已定义的共享目标。为了改进，每个人都必须理解并致力于系统的目的。优化一个组件并不能优化整体。在SAFe中，系统思考应用于构建系统的组织以及正在开发的系统。系统思考也承认该系统如何在其最终用户环境中运行。

＃3  - 假设可变性;保留选项

传统的设计和生命周期实践鼓励在开发过程的早期选择单一的设计和需求选项。不幸的是，如果这个起点被证明是错误的选择，那么未来的调整需要太长时间，并且可能导致次优的长期设计。更好的方法是在开发周期中保持更长时间的多个需求和设计选项。然后使用经验数据来缩小焦点，从而产生能够产生更好经济效果的设计。

＃4  - 通过快速，集成的学习周期逐步构建

在一系列短迭代中逐步开发解决方案。每次迭代都会导致工作系统的集成增量。后续迭代建立在之前的迭代之上。增量允许快速的客户反馈和风险缓解。它们也可能成为市场测试和验证的最小可行产品（MVP）或原型。此外，这些早期的快速反馈点有助于确定何时“必要时”转向另一种行动方案。

＃5  - 关于工作系统客观评估的基本里程碑

企业主，开发商和客户共同负责确保对新解决方案的投资将带来经济效益。连续的阶段门开发模型旨在应对这一挑战，但经验表明，它并未按预期降低风险。在精益敏捷开发中，集成点提供了客观的里程碑，可以在整个开发生命周期中频繁地评估解决方案。这种定期评估提供了所需的财务，技术和适用性治理，以确保持续投资能够产生相应的回报。

＃6  - 可视化和限制WIP，减少批量大小和管理队列长度

精益企业努力实现持续流动，新系统能力从概念到现金快速，明显地发展。实现流程有三个关键：

1. 可视化并限制在制品（WIP）的数量，以限制对实际容量的需求。
2. 减少批量工作，以便快速可靠地流过系统。
3. 管理队列长度以减少新功能的等待时间

＃7  - 应用节奏，与跨域规划同步

Cadence创造了可预测性并为发展提供了节奏。同步导致可以同时理解，解决和集成多个透视图。应用开发节奏和同步以及定期跨域规划，提供了在产品开发中固有的不确定性存在的情况下有效运行所需的工具。

＃8  - 释放知识工作者的内在动力

精益敏捷领导者理解，知识工作者的构思，创新和参与通常不能通过个人激励薪酬来激励。毕竟，个人目标导致内部竞争并破坏实现系统更大目标所必需的合作。提供自主权和目的 - 同时最大限度地减少约束 - 可以提高员工敬业度，从而为客户和企业带来更好的结果。

＃9  - 分散决策权

实现快速价值交付需要快速，分散的决策。这样可以减少延迟，改善产品开发流程，实现更快的反馈，并创建更接近当地知识的创新解决方案。但是，有些决策具有战略性，全球性，并具有规模经济，可以证明集中决策的合理性。由于发生了两种类型的决策，创建可靠的决策框架是确保快速价值流动的关键步骤。

 

讨论：请加入知识星球【首席架构师圈】

专家就是对越来越少的东西知道得越来越多的人。

—William J. Mayo

共享服务

共享服务代表了敏捷发布培训(ART)或解决方案培训(Solution Train)成功所需的专业角色、人员和服务，但不能是全职的。

由于这些资源是专门化的(通常是单一来源的，而且通常非常繁忙)，每个ART和解决方案培训都必须计划在需要共享服务人员时使用这些人员。

细节

集中所有必要的技能和能力来交付价值，这是艺术的特征，并通过扩展，解决方案培训。然而，在许多情况下，不可能把一些特殊的功能用于一种艺术。可能缺乏某种特定的技能。此外，艺术品的需求可能会波动，使全职供应变得不切实际。为了解决这个问题，共享服务通过将专业知识快速集中到需要独特知识和技能的系统或解决方案领域来支持开发。

在某些情况下，工作必须先于敏捷团队(例如，安全性、信息体系结构)进行，以便它可以直接为支持新特性或能力开发的体系结构跑道做出贡献。在其他情况下，资源可以稍微跟踪核心开发(例如，客户培训、本地化)。在某些情况下，仅仅是支持和快速反应就足够了。

在这两种情况下，如果没有及时的支持和同步，程序将难以实现它们的目标。虽然不是专门为火车服务的，但共享服务必须与之同行，因为火车也必须运载一些货物。

总结角色描述

共享服务的潜在成员通常包括具有以下专业技能的人:

• 敏捷和软件/系统工程教练
• 应用程序/门户网站管理
• 配置管理
• 数据建模、数据工程和数据库支持
• 桌面支持
• 最终用户培训
• 企业架构
• 信息架构
• 基础设施和工具管理
• 国际化和本地化支持
• IT服务管理(ITSM)和部署操作
• 安全专家(信息安全)
• 系统质量保证和探索性测试
• 技术作家

责任

共享服务人员从事下列活动:

• 参与项目增量(PI)计划以及项目前期和后期计划。
• 在必要时驱动需求，添加解决方案意图，并拥有它们的部分相关待办事项项的所有权。
• 与敏捷团队合作，完成PI执行过程中的依赖关系。
• 参与系统演示和解决方案演示，并在适当的时候检查和调整(I&A)研讨会，因为许多改进待办事项可能反映了专业技能和依赖关系可用性方面的挑战。

有时，共享服务的成员可能选择作为一个单独的团队进行操作。在这种情况下，他们将以与ARTs相同的节奏迭代，并像其他敏捷团队一样工作。

保持专业的培训

由于共享的技术资源是高度专门化的(相对于敏捷团队的泛化专家)，因此必须不断改进它们的技能，以跟上各自领域的进步。共享服务应该在ART启动期间接受敏捷团队的培训。

定期嵌入到敏捷团队中

支持敏捷团队需要持续的或过渡性的专业知识。共享服务人员可能在短时间内暂时成为敏捷团队的一部分。在这种情况下，他们可以体验敏捷的动态，以及对开发速度和产品质量的理解。它还加速了更大的敏捷团队的动态，只有通过共同行动，它们才能交付企业价值。而且，嵌入时间短，可以实现知识转移，减少艺术对专业技能的依赖。

了解更多

• [1]Leffingwell,院长。敏捷软件需求:团队、程序和企业的精益需求实践。addison - wesley, 2011年。

 

原文：https://www.scaledagileframework.com/shared-services/

本文：https://pub.intelligentx.net/safe-shared-services

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

质量始于意图。

-W。 爱德华兹戴明

Quality begins with the intent.

—W. Edwards Deming, Out of the Crisis [1]



 

解决方案意图

解决方案Intent是用于存储，管理和传达当前和预期解决方案行为的知识的存储库。如果需要，这包括固定和可变规格和设计;参考适用的标准，系统模型，功能和非功能测试;和可追溯性。

构建大型软件和网络物理系统是当今业界最复杂和最具挑战性的工作之一。这需要在两个核心问题上保持一致：

1.     我们正在建造什么？
2.     我们如何构建它？

更重要的是，这两个问题是相互关联的，并且相互影响。如果您不知道如何以经济或技术可行的方式构建某些东西，则必须在“如何”的背景下重新考虑正在构建的“什么”.SAFe将此关键知识库标记为解决方案意图 - 基本了解当前和不断发展的需求，设计和意图 - 即解决方案的更大目的。

某些解决方案意图是固定的，对于它必须做或已经做的事情具有不可协商的要求。一些解决方案意图是可变的，需要进一步讨论和探索，因为事实表面。理解和导航这些差异，并允许可变性（甚至在时间轴的后期），是解开大规模解决方案开发灵活性的关键。

细节

在构建具有不可接受的高成本故障的系统时，需要更严格的定义和系统行为验证是敏捷采用的重大障碍。虽然许多从业者对“敏捷宣言”[1]的价值陈述产生了共鸣，即“工作软件优于综合文档”，但这一概念可能会为需要两者的企业产生相互冲突的优先级。

工程复杂且高度可靠的解决方案需要并创建大量技术信息。其中大部分反映了解决方案要求和设计 - 功能和功能，故事，非功能需求（NFR），系统架构，域级模型和设计（例如电气和机械），系统接口，客户规范，测试和测试结果，以及可追溯性。其他相关信息记录了系统的一些关键决策和发现。这可能包括来自贸易研究的信息，实验结果，设计选择的推理以及其他项目。在许多情况下，无论是必要性还是法规，这些信息都必须成为官方记录的一部分。

在解决方案意图中捕获知识

解决方案意图是一个关键的知识库，用于存储，管理和交流“正在构建的内容”和“如何构建它”。它有多种用途：

•     提供有关解决方案的预期和实际行为的单一事实来源
•     记录并传达需求，设计和系统架构决策
•     促进进一步的勘探和分析活动
•     使客户，开发团队和供应商与共同的使命和目标保持一致
•     支持合规和合同义务

 

未来和当前的解决方案意图

图1说明了解决方案意图的复杂性：

•     当前和未来的状态 - 复杂系统的开发人员必须经常知道两件事：当前系统究竟做了什么，以及未来状态的变化
•     规格，设计和测试 - 只要包含三个主要元素：规范（系统行为的文档定义），设计和测试，就可以以任何合适的形式捕获当前和未来状态的知识。

图1.解决方案意图的剖析

当构建必须完全符合预期的系统时 - 包括生命关键，关键任务和其他受法规标准约束的系统 - 可追溯性有助于确认系统将按预期运行。它将解决方案意图的元素彼此连接，并连接到实现其完整行为的系统组件。解决方案意图本身是协作创建的，并且基于学习而发展，如图1所示。

解决方案意图的特定元素可以以多种形式实现：从文档，电子表格和白板会话到形式要求和建模工具，如基于模型的系统工程（MBSE）中所述。但是解决方案意图是构建解决方案的一种手段，因此捕获它的方法不应该产生不必要的开销和浪费（参见下面的充分讨论）。

使解决方案意图动态化

传统上，一组详细的，前期的，固定的需求充当解决方案意图的代理。但SAFe原则＃3，假设可变性;保留选项，告诉我们在前期过于紧密地定义需求和设计会导致不太成功的结果。需要一种不同的方法，一种支持理解已知的方法，但允许在开发过程中出现未知的方法。

解决方案意图不是静态的一次性声明：它必须支持整个开发过程并继续发展。图2将传统的早期固定需求分解与精益敏捷方法进行了对比，在这种方法中，执行工作的人员在适当的时间进行分解。

图2.解决方案Intent随着解决方案开发的所有步骤而发展并支持它们

解决方案意图作为未来系统的愿景，使这些团队及其积压工作保持一致。它提供了建立当前愿景所需的详细信息，但允许团队灵活地探索构建解决方案的未知因素。由此产生的知识（我们能否建立未来的系统，以及我们从探索中学到了什么？）提供了有关未来系统的反馈和适应的机会。

使用固定和可变解决方案意图保持选项打开

解决方案意图有多种用途。但是，它们都没有要求预先创建完全定义的“点解决方案”规范。这些早期决策限制了对更好的经济替代方案的探索，并经常导致浪费和返工。 [2]为了防止这种情况，SAFe描述了解决方案意图的两个要素，固定和可变，支持一般的自适应要求和创造最佳经济结果的设计理念。

固定意图代表'知识'。它们可能是不可谈判的，或者它们可能在开发过程中出现。例子包括：

•     某些性能规格（“起搏器波形必须如下”）
•     合规标准（“符合所有PCI合规信用卡要求”）
•     定义解决方案的核心能力（“Baja Adventure Ride拥有四名成年骑手”）

可变意图代表了允许探索可满足需求的要求和设计备选方案的经济权衡的要素。一旦建立起来，这些新的见解最终将成为固定的要求。

从变量到固定需要获得知识来做出决策。启动者是SAFe探索未知因素并记录解决方案意图中的知识和决策的工具。遵循基于设定的设计实践，团队探索替代方案以达成最佳经济决策。这些决策可以在路线图中开发下游功能（图3）。

图3.从变量移动到固定解决方案意图

在每个计划增量（PI）中，团队同时构建我们所知道的内容，同时探索我们尚不了解的内容。

固定知识不会从零开始，因为即使在图3的左端，也知道很多。例如，重用以前开发的系统中的元素。然后，通过开发过程，随着迭代，PI和解决方案演示显示系统的功能，可以更快地了解更多信息。通过这种方式，可变意图随着时间的推移变得固定，并且对系统的作用和需要做的事情有了充分的了解。

协同开发解决方案意图

解决方案意图是团队和项目领导之间的协作。产品和解决方案管理以及解决方案架构师和系统工程负责最高级别的系统范围决策（系统分解，接口以及对各种子系统和功能的需求分配）。他们还建立了解决方案意图的组织结构，以支持未来的分析和合规性需求。解决方案意图有助于推动团队积压中的本地化决策，如图4所示。

图4.解决方案Intent通过协作发展

由此产生的工作向计划领导提供有关进展和方向的反馈。

如图5所示，积压项定义填充解决方案意图的工作，将变量假设移向固定决策。

图5.开发解决方案意图

解决方案的意图始于Vision，它描述了解决方案的目的和关键功能，以及系统的非功能需求。这些知识以及新兴的路线图和关键里程碑指导团队创建积压和规划他们的工作。但路线图和解决方案意图充满了假设。 SAFe对持续交付的指导通过最小可行产品（MVP）验证假设，这些产品通过频繁，可量化的实验提供经过验证的学习。注意：解决方案意图中经过验证的学习主要是技术性的，但Build-Measure-Learn和Pivot或Persevere的以业务为中心的精益创业原则仍然适用。

在整个供应链中连接解决方​​案意图

系统的解决方案意图不一定是孤立的。许多解决方案是参与更高级别系统系统的系统。在这种情况下，其他系统以及供应商提供了加速开发的独特知识和解决方案元素。例如，供应商通常会为其子系统或功能提供单独且独立的要求，设计和其他规范。从他们的角度来看，这是他们的解决方案意图因此，最终（顶级）解决方案意图必须包括沟通决策，促进探索，协调团队和支持合规性所需的相关供应商知识和信息。这种“菊花链”需求会在系统层次结构中上下移动设计决策，如图6所示。

图6.解决方案Intent层次结构

创建最小但足够的文档

解决方案意图是达到目的的手段 - 它是指导，促进和沟通决策以及证明合规性的工具。规划解决方案意图的内容，组织和文档策略应从这些目的开始。但更多不一定更好。在记录需求，设计和架构时，精益敏捷社区建议保持清晰[5]。最佳做法包括：

•     偏好文档模型 - 持续变化的环境挑战以文档为中心的方法来组织和管理解决方案意图。如果应用得当，模型（包括由现代实践产生的模型，如设计思维和以用户为中心的设计）可以提供更容易维护的管理方式，如MBSE中进一步讨论的那样。
•     保持解决方案意图协作 - 没有垄断创新，解决方案意图不是产品和解决方案经理，架构师和工程师的专有领域。许多团队成员参与解决方案意图信息的创建，反馈和改进。
•     保持选择开放 - 将决策推迟到当地关注的问题，并尽可能晚地做出决定。只要经济上可行，对需求和设计的自适应方法就可以保持有希望的选择。基于集合的设计实践有助于避免过早地承诺设计和要求。
•     仅在一个地方记录项目 - 在一个地方记录任何要求和设计决策，一个单一的事实来源，作为每个人和所有事物的记录存储库。
•     保持高水平 - 尽可能高地进行沟通，并且不要过度指定。提供一系列可接受的行为。用意图描述解决方案行为，而不是特异性。分散要求和设计决策权。
•     保持简单 - 只记录需要的内容。解决方案意图是在遵守合同和合同义务的同时构建产品的方法。少即是多。

 

学到更多

 

• [1] Agilemanifesto.org。
• [2] Ward，Allen和Durward Sobek。精益产品和流程开发。精益企业研究所，2014年。
• [3] Reinertsen，Don。产品开发流程原则：第二代精益产品开发。 Celeritas Publishing，2009。
• [4] Leffingwell，Dean和Don Widrig。管理软件需求：用例方法。艾迪生 - 韦斯利，2003年。
• [5] Ambler，Scott。 “敏捷架构：扩展敏捷开发的策略。”敏捷建模，2012。http://agilemodeling.com/essays/agileArchitecture.htm。

 

讨论：请加入知识星球【首席架构师圈】

在2000年秋季，当工作首次开始于将成为敏捷建模（AM）方法时，我们专注于定义一系列价值，原则和实践，用于软件开发项目的建模和文档编制。这些原则和实践相当精细，描述了您在建模和文档操作过程中所做的工作。虽然很有价值，但许多人发现这些原则和实践太难以理解，因为它们的粒度，但也因为它们的模糊性。然后在2003年，敏捷模型驱动开发（AMDD）生命周期开始合并，以描述何时在项目（或视情况而定的程序）上进行建模，例如在项目开始时设想的架构构想和需求，或者模型上的模型。整个项目的即时（JIT）基础。这反过来又揭示了更高级别的AMDD“最佳实践”，在图1的模式语言图中进行了概述。

图1.敏捷建模的最佳实践。

AMDD的核心实践是：

1. 积极的利益相关者参与。利益相关者应及时提供信息，及时做出决策，并通过使用包容性工具和技术积极参与开发过程。
2. 架构构想。在敏捷项目开始时，您需要进行一些初始的高级架构建模，以确定适合您的解决方案的可行技术策略。
3. 持续文件。在整个生命周期中编写可交付文档，与创建其余解决方案并行。
4. 延迟文件。尽可能晚地编写可交付文档，避免可能改变的有利于稳定信息的推测性想法。
5. 可执行规范。以可执行的“客户测试”的形式指定需求，并将您的设计指定为可执行的开发人员测试，而不是非可执行的“静态”文档。
6. 迭代建模。在每次迭代开始时，您将进行一些建模，作为迭代计划活动的一部分。
7. 仅仅是足够好的(JBGE)工件。模型或文档需要足以应对手头的情况而不再需要。
8. 向前建模。有时，接近优先级堆栈顶部的需求相当复杂，这促使您在将它们从工作项堆栈的顶部弹出之前投入一些精力来探索它们，以降低整体风险。
9. 模型风暴。在整个迭代过程中，您将在即时（JIT）基础上对风暴建模几分钟，以探索需求背后的细节或思考设计问题。
10. 多种模式。每种类型的模型都有它的优点和缺点。一个有效的开发人员需要在他们的智能工具包中使用一系列模型，使他们能够以最适合的方式应用正确的模型来应对当前的情况。
11. 优先要求。敏捷团队按照利益相关方的定义按优先级顺序实施需求，以便尽可能提供最大的投资回报（ROI）。
12. 要求展望。在敏捷项目开始时，您需要花一些时间来确定项目的范围并创建初始优先级需求堆栈。
13. 单一来源信息。努力在一个地方和一个地方捕获信息。
14. 测试驱动设计（TDD）。在需求或设计级别编写单个测试，然后只需要足够的代码来完成该测试。 TDD是详细的需求规范和测试验证方法的JIT方法。

 

原文：http://www.agilemodeling.com/essays/bestPractices.htm

本文：https://pub.intelligentx.net/node/700

讨论：请加入知识星球或者小红圈【首席架构师圈】

敏捷建模（AM）是一种基于实践的方法，用于有效建模和记录基于软件的系统。 简而言之，敏捷建模（AM）是用于建模软件的价值，原理和实践的集合，可以以有效和轻量级的方式应用于软件开发项目。 正如您在图1中看到的那样，AM旨在针对其他完整的方法（如XP或RUP）进行定制，使您能够开发真正满足您需求的软件过程。 实际上，这种剪裁工作已经以Disciplined Agile Delivery（DAD）流程框架的形式为您完成。

图1. AM增强了其他软件过程。

 

采用和扩展极限编程v1的AM的值是通信，简单，反馈，勇气和谦逊。建模成功的关键是在所有项目利益相关者之间进行有效沟通，努力开发最简单的解决方案，满足您的所有需求，经常及早地获得有关您的努力的反馈，有勇气制作并坚持您的决定，并且谦虚地承认你可能不知道所有事情，其他人有价值添加到你的项目工作中。

AM基于一系列原则，例如在您建模时假设简单性以及在工作时采用变更的重要性，因为需求会随着时间的推移而变化。您应该认识到，随着时间的推移，系统的增量变化可以实现敏捷性，并且您应该努力获得对工作的快速反馈，以确保它准确地反映项目利益相关者的需求。您应该有目的地建模，如果您不知道为什么要处理某些事情，或者您不知道模型/文档的受众实际需要什么，那么您就不应该对其进行处理。此外，您需要在智力工具包中使用多个模型才能有效。一个关键的概念是，模型不一定是文档，这种实现可以让您在完成其目的后丢弃大多数模型，从而轻松实现旅行。敏捷建模者认为内容比表示更重要，有许多方法可以对同一个概念进行建模，但仍然可以正确运行。要成为一名有效的建模者，您需要认识到开放和诚实的沟通往往是确保有效团队合作的最佳政策。最后，关注质量工作很重要，因为没有人喜欢制作草率的工作，而且AM的本地化适应性以满足您环境的确切需求非常重要。

要以敏捷方式进行建模，您将适当地应用AM的实践。基本实践包括并行创建多个模型，为情况应用正确的工件，并迭代到另一个工件以继续以稳定的速度向前移动。以小增量进行建模，而不是试图从象牙塔中创建神奇的“全方位模型”，这也是您作为敏捷建模者成功的基础。因为模型只是软件的抽象表示，抽象可能不准确，所以您应该努力用代码证明它，以表明您的想法实际上在实践中工作而不仅仅是理论上积极的利益相关者参与对于您的建模工作的成功至关重要因为您的项目利益相关者知道他们想要什么，并可以为您提供所需的反馈。假设简单性的原则得到了创建简单内容的实践的支持，只关注您需要建模的方面，而不是尝试创建高度详细的模型，仅通过使用简单的符号描述模型，并使用最简单的工具创建你的模型。您可以通过单一采购信息轻松旅行，丢弃临时模型并仅在受伤时更新模型。通过在墙上或内部网站上公开显示模型，通过项目工件的集体所有权，应用建模标准以及与其他人建模来实现通信。轻轻应用图案时，您的开发工作将大大增强。因为您经常需要与其他系统集成，包括遗留数据库以及基于Web的服务，您会发现需要与这些系统的所有者形式化合同模型。阅读本文，以便更好地了解AM的实践如何融合在一起。敏捷建模

我认为AM是一种灵活的建模方法，其核心AM只是一系列实践，反映了许多有经验的软件开发人员共享的原则和价值观。使用敏捷模型驱动开发（AMDD）（参见图2）方法，您通常在项目开始时进行足够的高级建模，以了解系统的范围和潜在架构，然后在开发迭代期间进行建模。迭代计划活动的一部分，然后采用即时（JIT）模型风暴方法，您可以在几分钟内建模，作为几个小时编码的前提。

图2.敏捷模型驱动开发（AMDD）。

另一种看待敏捷建模的方法是作为核心实践的集合，如图3所示。

图3.敏捷建模的最佳实践。

我的经验是，这些实践可以应用于大多数软件开发项目，您不必在敏捷软件过程（如XP）之后处理项目，以利用AM描述的方法，尽管AM之一 目标是解释在遵循XP方法时如何建模。 项目团队不需要应用AM的所有实践，原则和价值来从中受益 - 我一直坚信您应该定制您的软件流程以反映您环境的独特需求 -  虽然我认为像XP一样，如果你采用全部AM，你更有可能成功。

 

原文：http://www.agilemodeling.com/essays/introductionToAM.htm

本文：https://pub.intelligentx.net/agilemodeling-introduction-agile-modeling

讨论：请加入知识星球或者小红圈【首席架构师圈】

敏捷者希望开发高质量和高价值的软件，而开发高价值软件最简单的方法就是首先实现最高优先级的需求。这使他们能够最大化涉众的ROI。因为需求经常变化，您需要一个精简的、灵活的方法来进行需求变更管理:简而言之，敏捷者努力真正地管理变更，而不是阻止变更。这一做法有三个版本:

• 产品待办事项列表(Scrum)
• 工作项目列表(有纪律的敏捷)
• 选择池(精益)

1. 产品待办事项列表:简单

图1概述了Scrum管理需求的方法，其中您的软件开发团队有一堆需要处理的优先级和估计需求(Scrum将这个优先级堆栈称为“产品backlog”)。有几个要点需要理解:

• 新需求由项目涉众确定优先级，并添加到堆栈的适当位置。
• 从根本上说，当涉及到需求优先级时，一个人需要成为最终的权威。在Scrum和纪律严明的敏捷交付(DAD)中，这个角色来自Scrum，这个人被称为产品负责人。
• 尽管经常有许多项目涉众，包括最终用户、经理、架构师、运营人员，但仅举几个例子，产品所有者负责代表他们所有人。
• 堆栈/待办事项列表最初是由您在项目开始时设想的需求所填充的(在Scrum中，他们称之为“填充待办事项列表”)。
• 每次迭代(Scrum术语中的“sprint”)，您的团队都将迭代的工作价值从栈顶提取出来，并承诺在迭代结束时实现它。
• 您的项目涉众有权定义新的需求，改变他们对现有需求的想法，甚至根据他们认为合适的情况重新排列需求的优先级。
• 利益相关者负责及时做出决策并提供信息。在一些项目中，业务分析师(通常扮演产品负责人的角色)可能会承担此职责。无论谁担任这个角色，都需要与其他利益相关者合作，确保每个人都得到公平的代表，这通常是一项艰巨的任务。
• 非需求工作项目的优先级要么由团队与涉众协商，要么作为计划中空闲时间的一部分处理。许多Scrum团队现在不仅仅把需求(比如缺陷)放在他们的backlog上。

图1所示。Scrum需求管理。

2. 工作项目列表:有纪律的敏捷

图1中描述的方法非常简单，反映了我认为敏捷构建级别的思想。图2概述了一种更规范的方法，它扩展了上面描述的管理工作项的方法。这种方法是有纪律的敏捷交付(DAD)所建议的默认方法，两者都反映了敏捷交付团队所面临的现实世界。你应该考虑以下几个有趣的改进:

超越功能需求。我们知道我们做的不仅仅是在每次迭代中实现新的需求，我们经常做与需求无关的工作，比如接受培训，检查其他团队的产品，处理缺陷(我认为缺陷只是另一种类型的需求)等等。重点是，不仅仅需要将需求放在堆栈上，我们还需要工作项。

• 采用风险价值方法。纪律严明的敏捷团队认识到开发团队面临着一些共同的风险，他们希望尽快解决这些风险。这些风险包括在项目早期达成涉众一致意见的需要，可以通过需求设想，或者开发一个共享的远景或者项目章程来解决这个风险。另一个常见的风险是需要证明您的体系结构策略(通过体系结构设想标识)确实有效。最有效的方法是通过为您的系统构建一个端到端框架(或钢框架)来使用工作代码证明您的体系结构，该框架解决了您的团队所面临的主要技术风险。有纪律的敏捷交付(DAD)团队将在项目的早期查看他们的工作项堆栈，通常是在项目的初始阶段/“迭代0”/“sprint 0”部分，以确定哪些需求展示了这些技术上有风险的特性。如果这些要求没有堆栈的顶部,他们常常因为风险和回报(值)倾向于使相互,然后他们用产品所有者讨论这个问题,看看他们能激励人(负责优先级)将这些需求转移到堆栈的顶部。如果一个高风险的需求目前接近于栈底，那么您应该质疑这个需求是否真的是需要的，因为很有可能您永远不会真正抽出时间来处理它，因为优先级更高的工作总是会成为先例。
• 提前一点建模。因为我们知道所有的需求，更不用说一般的工作项，都不是平等创建的，所以我们不应该天真地假设我们应该在迭代开始的时候等待从堆栈顶部取出迭代的工作值。如果一个工作项非常复杂，需要比迭代计划会话中通常发生的更多的思考，该怎么办?纪律严明的敏捷团队将采用前瞻性建模实践，对工作项堆栈进行一两次迭代，并投入时间研究即将到来的复杂工作项，以降低总体项目风险。提前建模在Scrum中称为backlog梳理，揭示了Scrum实践中一些不必要的概念耦合。

 

图2。有纪律的敏捷工作管理流程。

3.选择池:精益

图3描述了一种在看板团队中常见的需求管理精益方法。需求/工作管理的敏捷方法和精益方法之间有几个关键的区别:

• 选项。工作项被视为解决方案中要处理的潜在选项，而不是必需的工作项。顺便提一下，IT中的术语“需求”一直以来都是有问题的(如果某个东西是一个需求，那么如何将它的一部分或全部从您的交付范围中删除呢?)
• 选项被管理为一个池。敏捷团队将工作项管理为优先级队列，精益团队将选项管理为一个池，当他们有能力执行相应的工作时，他们将从这个池中与涉众一起选择最有价值的工作。实际上，优先级是在团队涉众的准时(JIT)基础上完成的。这可能很复杂，因为单个涉众将有不同的优先级，因此需要进行权衡，而且团队可能支持不同的服务类别。当然，纪律严明的敏捷策略所描述的风险缓解问题也应该考虑接下来选择哪个选项。
• 选项可能被组织到服务类中。并不是所有的选项都是相同的。在《看板》一书中，David J. Anderson描述了您的团队可能考虑的几种潜在的选项类别(Anderson将其称为服务类)。许多工作项属于“标准”类，它们的优先级主要基于它们对组织的业务价值。有些工作项目有固定的交付日期，这对于政府立法或与外部客户签订的合同所产生的需求来说是很常见的。您还可能有少量(希望如此)的加急工作项，比如针对生产问题的关键修复或高优先级的客户需求。最后，你可能有一些低优先级的“无形”工作项目，你知道在将来的某个时候你需要处理它们，你决定在团队认为合适的时候处理它们(也许是为了简化其他工作，从更具挑战性的工作中休息一下，……)。需要注意的是，这里描述的类别并不是一成不变的，您的团队可能会识别出不同的类别，或者根本不需要进行分类。此外，在上面描述的敏捷策略中，服务类可以被支持为多个队列。
• 目标是限制正在进行的工作(WIP)。当敏捷团队努力选择一个固定数量的功能，刚好足够他们在一次迭代中实现时，精益团队选择产生一个连续的功能流，当他们有能力这样做时，将工作拉入他们的“交付系统”。限制WIP可以提高团队的交付可预测性，提高质量(由于反馈周期较短)，并提高生产力。
• 淘汰旧的工作项。精益团队通常会努力确定老化规则,如果一个工作项池中超过一定的时间,从池中移除的假设下,如果它已经很长时间没有重要到可以选择从池中就可能永远不会。如果工作项确实被证明是需要的，那么它总是可以在将来的某个日期添加到池中。请注意，老化规则在不同的团队之间会有所不同，一个团队可能需要3个月，而另一个团队可能需要5个月。此外，此策略可以应用于前面描述的产品backlog或工作项列表方法。

 

图3。精益工作管理流程。

利益相关者可以通过以下几种方式添加选项:

• 当团队最初形成时，通过需求想象会话。
• 以利益相关者认为的即兴方式。
• 当选项池接近空时，通过有目的的建模会话。
• 通过使用现有的生产系统来识别增强请求或缺陷报告。

4. 哪种策略适合你?

没有一种策略在所有情况下都是最好的，你需要确定并选择最适合你的策略。表1比较了这些策略。

表1。比较的策略。

Strategy	Advantages	Disadvantages	When to Use It
Product Backlog	Simple	Overhead associated with keeping the stack prioritized as priorities change Requires multiple stacks, or a more complex prioritization scheme, to support classes of service Typically requires teams to have an "overhead fudge factor", sometimes upwards to 30%, to account for non-requirements work each iteration	Simple situations (typically co-located agile teams developing fairly straightforward software)
Work Item List	Easily supports different types of work items "Overhead fudge factor" required is much smaller or non-existent compared with product backlog approach	Overhead associated with keeping the stack prioritized as priorities change Requires multiple stacks, or a more complex prioritization scheme, to support classes of service	For agile teams in not-so-simple situations, particularly teams in scaling situations (see The Software Development Context Framework (SDCF) )
Options Collection	Works for both agile and non-agile teams No overhead of managing a prioritized queue The overhead of the "planning game" at the beginning of each iteration goes away	Requires stakeholders who are sophisticated enough to prioritize the work on a JIT basis	Lean teams (e.g. Kanban) will adopt a variant of this strategy

 

原文：http://agilemodeling.com/essays/prioritizedRequirements.htm

本文：https://pub.intelligentx.net/node/709

讨论：请加入知识星球或者小红圈【首席架构师圈】

使用测试驱动开发(TDD)方法，即整体敏捷模型驱动开发(AMDD)方法的一部分，您的测试有效地成为基于即时(JIT)创建的详细规范。不管喜欢与否，大多数程序员都不阅读系统的书面文档，相反，他们更喜欢使用代码。这没什么不对的。当试图理解一个类或操作时，大多数程序员首先会寻找已经调用它的示例代码。编写良好的单元/开发人员测试正是这样做的—它们提供了功能代码的工作规范—因此单元测试有效地成为技术文档的重要部分。类似地，验收测试可以成为需求文档的重要部分。当你停下来思考的时候，这是很有意义的。您的验收测试准确地定义了涉众对您的系统的期望，因此它们指定了您的关键需求。

测试驱动的开发(TDD)

图1的UML活动图中概述了测试优先开发(test first development, TFD)的步骤。第一步是快速添加一个测试，基本上只需要足够的代码就可以失败。接下来运行您的测试，通常是完整的测试套件，尽管出于速度的考虑，您可能决定只运行一个子集，以确保新测试确实失败。然后更新函数代码，使其通过新的测试。第四步是再次运行测试。如果它们失败了，您需要更新您的功能代码并重新测试。一旦测试通过，下一步就是重新开始。

图1所示。测试优先的开发(TFD)。

我喜欢用这个简单的公式来描述TDD:

TDD =重构+ TFD。

TDD彻底改变了传统开发。当您第一次实现一个新特性时，您要问的第一个问题是，现有的设计是否是使您能够实现该功能的最佳设计。如果是，则通过TFD方法进行。如果没有，则在本地重构它，以更改受新特性影响的设计部分，使您能够尽可能轻松地添加该特性。因此，您将始终提高您的设计质量，从而使它更容易在未来的工作。

与其先编写函数代码，然后再编写测试代码，如果您真的编写了测试代码，那么您应该在编写函数代码之前编写测试代码。此外，您可以通过非常小的步骤来完成—一次测试和少量对应的函数代码。采用TDD方法的程序员拒绝编写新函数，直到第一个测试失败，因为该函数不存在。事实上，在对代码进行测试之前，他们甚至拒绝添加任何一行代码。一旦测试就绪，他们就会执行确保测试套件现在通过所需的工作(您的新代码可能会破坏几个现有的测试以及新的测试)。这在原则上听起来很简单，但是当您第一次学习使用TDD方法时，它需要严格的规程，因为不首先编写新的测试，很容易“滑倒”并编写功能代码。

测试作为需求

图2描述了一个客户验收测试描述(为了简洁起见，它被缩短了，需要使用更多的步骤来扩展，以真正验证所描述的功能)。正如您所期望的，测试有设置和运行它的说明。此外，还显示了描述、测试ID(可选)和预期结果。验收测试应该是完全自动化的，这样您就可以将它们作为应用程序的回归测试套件的一部分来运行。FITNesse测试框架是这样做的一个流行选择。

图2。用于验证业务规则的验收测试。

ID	T0014
Description	Checking accounts have an overdraft limit of $500. As long as there are sufficient funds (e.g. -$500 or greater) within a checking account after a withdrawal has been made the withdrawal will be allowed.
Setup	Create account 12345 with an initial balance of $50 Create account 67890 with an initial balance of $0
Instructions	Withdraw $200 from account #12345 Withdraw $350 from account #67890 Deposit $100 into account #12345 Withdraw $200 from account #67890 Withdraw $150 from account #67890 Withdraw $200 from account #12345 Deposit $50 into account #67890 Withdraw $100 from account #67890
Expected Results	Account #12345: Ending balance = -$250 $200 Withdrawal transaction posted against it $100 Deposit transaction posted against it $200 Withdrawal transaction posted against it Account #67890: Ending balance = -$500 $350 Withdrawal transaction posted against it $150 Withdrawal transaction posted against it $50 Deposit transaction posted against it Errors logged: Insufficient funds in Account #67890 (balance -$350) for $200 Withdrawal Insufficient funds in Account #67890 (balance -$450) for $100 Withdrawal

设计规格测试

类似地，开发人员测试可以构成详细设计规范的大部分。开发人员测试通常使用xUnit开源工具家族编写，如JUnit或VBUnit。这些测试可用于指定应用程序代码和数据库模式。

测试是否有足够的文档?

很可能不会，但它们确实构成了其中重要的一部分。例如，您可能会发现仍然需要用户、系统概述、操作和支持文档。您甚至可能发现，您需要摘要文档来查看系统支持的业务流程。当您以开放的心态处理文档时，我怀疑您会发现这两种类型的测试涵盖了开发人员和业务涉众对文档的大部分需求。此外，它们是AM的单一源信息实践的一个很好的例子，也是您在文档方面保持尽可能敏捷的整体努力的一个重要部分。

 

原文：http://agilemodeling.com/essays/executableSpecifications.htm

本文：

讨论；请加入知识星球或者小红圈【首席架构师圈】

敏捷建模中一个比较有争议的概念是，敏捷模型和敏捷文档对于手头的任务来说已经足够了，或者就像我喜欢说的那样，它们还不够好(JBGE)。在本文中，我提出了以下关于模型或文档(工件)不够好的关键点:

• 这实际上是最有效的
• 它是情景
• 这并不意味着低质量
• 它会随着时间变化
• 它来得比你想象的要快

1. 仅仅足够好实际上是最有效的

出于某种原因，人们认为JBGE暗示了工件不是很好，而实际上没有什么比这更偏离事实的了。当您停下来思考它时，如果一个工件是JBGE，那么根据定义，它可能处于最有效的位置。图1是一个收益递减图，它总结了一个勉强足够好的工件的价值曲线。价值是指工件的净收益，它将被计算为收益-成本。虚线位于工件为JBGE的位置:线左边的任何地方都暗示您还有工作要做，右边的任何地方都暗示您已经做了太多的工作。当您在做某件事情时，它还不够，那么您仍然可以在它上面投入更多的精力，并从中获得好处(当然，假设您确实做了使工件更接近其预期目的的工作)。然而，如果工件已经是JBGE(或者更好)，那么对它进行更多的工作显然是一种浪费:一旦工件实现了预期的目的，那么对它的任何更多的投资都只是繁忙的工作。这个图有点天真，因为很明显，在工件变得不够好之前，值很可能是负数，尽管为了便于讨论，我将假设您从一开始就做得很好。

图1所示。成本分析刚刚好。

理想情况下，您的所有工件都应该是JBGE，如图所示。不幸的是，这并不是一个理想的世界。您经常会在一个工件上投入太多的精力，在您处理它时无意中超出了目标。例如，我真的需要图1中值曲线最右边的箭头吗?如果没有，那么这个图表就已经足够好了。敏捷建模者只是人，他们并不总是能把工作做得完美无缺，所以实际上，一些构件将远远不够好。秘诀是学会如何检测你什么时候达到了刚刚好到可以停止工作的程度。说起来容易做起来难。

2. 仅仅足够好是环境形成的

JBGE的基本挑战是情境性的。例如，我经常在白板上绘制UML序列图来探索复杂的逻辑，然后在完成之后丢弃它。在这种情况下，白板图很好，因为它帮助我解决了我正在思考的问题，无论我和谁一起工作。但是，如果我们以后需要更新这个逻辑，并且希望通过关系图而不是源代码来实现，又该怎么办呢?显然，在这种情况下，手绘草图还不够好，我们将使用复杂的case工具创建详细的图表。我们仍然会创建一个敏捷模型，尽管它比草图复杂得多，因为JBGE反映了情况的需求(记住，敏捷建模者建模是有目的的)。

要确定一个工件是否是JBGE，您必须积极地与该工件的直接受众一起工作。对于系统概述文档，它是维护程序员;对于用户手册，它是最终用户;对于草图序列图，它是实现相应代码的程序员。如果不知道用户想要什么，您就不能实际地创建JBGE，从而使您处于这样一种情况，即您有动机在工件上投入比需要多得多的精力。这常常被证明是浪费精力，因为很有可能工件会成为他们不打算读它(TAGRI)原则的牺牲品。为了确保您知道工件的受众想要什么，您需要确保与他们良好的沟通，并且更好地争取积极的涉众参与。

3.仅仅足够好并不意味着低质量

有些人似乎认为JBGE的工件质量很低。事实是，他们的素质足以胜任手头的工作。这并不是做一个低质量工作的借口，因为质量在观察者的眼中:工件的受众决定它是否足够，而不是它的创造者。如果您的涉众需要一个优秀的、详细的工件，那么当它达到优秀和详细的程度时，它就是JBGE。

4. 仅仅足够好随时间推移

工件可以在其生命周期的两个方向上沿着这个值曲线移动。您的需求可能会改变，变得更复杂或者更简单，因此您可以选择相应地更新您的工件。如果工件变得不够好，那么您将需要考虑更新它。

如果一个工件已经足够好了，你应该重新制作它吗?除非它损害了你在其他方面的努力。例如，对于图1来说，手绘图表已经足够了，尽管在我绘制它的时候，我没有方便地访问任何书写材料(例如纸张或白板)，所以我使用Microsoft Visio。后来，当我有机会接触到这样的材料时，我没有费心去替换图表，因为那也将是无用的繁忙工作。是的，我在创建图表时投入了太多的精力，因为用Visio绘制图表花费了我近15分钟的时间，但我本可以在白板上绘制这个图表，拍下它的照片，然后用软件在不到5分钟的时间内清理干净。但是，再花五分钟来改变图表的格式是没有任何意义的。

对于第二个例子，假设我不喜欢当前沿着X轴的标题，并且相信支出会更好。将启动Visio的努力,是值得阅读的文档,更新它,生成GIF,将图片上传到我的ISP,编辑这个页面的HTML返工文本匹配图,上传HTML,打开浏览器看看本文以确保我做得很对,做任何必要的补丁和随后的上传,然后提交更改版本控制?听起来至少5到10分钟的努力几乎没有任何价值。敏捷建模器只在受到伤害时才进行更新，而当前的X轴标题还不足以保证进行这种投资(实际上，我认为当前标题是有意义的)。事实上，这种更新实际上会降低本文的价值，因为成本大于收益。

5. 它来得比你想象的要快

图2描述了图1中所示的理想图的更现实的版本，具体到建模。它显示了两条数值曲线，虚线表示的是传统/重法建模的理论值，实线我认为是实际的数值曲线。传统主义者似乎认为，随着时间的推移，对建模和相应规范的重大投资将继续增加价值。然而，实践表明，建模的价值来自于改进的沟通和思考问题的能力，并且这种价值会很快达到峰值。例如，对于初始的预先建模，这通常发生在几天或几周之后(对于高风险的项目，您可能需要在初始建模上投入更多的时间)。即使对于企业架构或企业业务建模，您仍然只需要在初始建模上花费几周的时间。对于迭代建模，它甚至更短，通常只有几个小时，对于以分钟为单位的模型风暴来说。

敏捷建模

图2。建模的价值。

 

原文：http://agilemodeling.com/essays/barelyGoodEnough.html

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

在敏捷软件开发中，您希望尽可能轻松地旅行，最简单的方法是选择最好的工件来记录信息。我使用术语“工件”来指代在软件开发项目中创建的任何模型、文档、源代码、计划等等。此外，您希望尽可能少地记录信息，最好只记录一次。例如，如果您在用例中描述业务规则，然后在业务规则规范中详细描述它，然后在代码中实现它，那么您需要维护相同业务规则的三个版本。最好只记录一次业务规则，最好是人类可读但可实现的代码，然后根据需要从任何其他工件引用它。

为什么要记录一个概念一次?三个原因:

1. 减少维护负担。维护的表示越多，维护的负担就越大，因为您希望保持每个版本之间的同步。图1描述了传统软件开发构件的典型方法。每个工件中的字母表示其中存储的一条信息。例如，信息A(可能是我们上面提到的业务规则)在需求文档、测试模型和源代码中被捕获。
2. 减少可跟踪性的负担。使用多个副本，您的可跟踪性需求就会更大，因为您需要将每个版本与其替代表示相关联，否则在发生更改时，您将永远无法保持它们的同步。是的，AM建议你只在感到疼痛的时候才更新，但是你拥有的副本越多，它越有可能在更早的时候开始疼痛。
3. 增加的一致性。您拥有的副本越多，您拥有不一致信息的可能性就越大，因为您很可能无法保持版本的同步。

图1所示。传统的软件开发构件。

有趣的是，传统流程通常促进技术信息的记录，比如用三种不同的方式表示业务规则。与此同时，他们还将规定一些设计概念，如标准化和内聚，这将引导您开发一个只实现一次概念的设计。例如，数据规范化规则促使您将数据存储在一个地方，并且只存储在一个地方。类似地，在面向对象和基于组件的设计中，您希望构建只实现一个目标的内聚项(组件、类、方法等等)。如果这对于您的系统设计是可以的，那么对于您的软件开发构件也应该是可以的吗?我们显然需要重新考虑我们的方法。

视图,而不是复制

很明显，您应该将系统信息存储在一个地方，并且只存储在一个地方，最好是在最有效的地方。从软件开发的角度来看，这一概念被称为标准化，在编程界这是读写编程的一个重要方面，在技术文档界这被称为单一来源。单一来源的想法是只记录一次技术信息，然后根据需要从该信息生成各种文档视图。在上面的业务规则示例中，它将使用某种业务规则定义语言进行记录。一个人类可读的视图将为你生成需求文档(顺便说一下,这是说起来容易做起来难,但为了参数假设这是可能的)和一个实现视图生成将由您的业务规则引擎或编译应用程序源代码。

图2描述了一种策略，用于单次获取图1中包含的所有信息，然后通过使用生成器自动生成图1的原始构件。视图是根据需要从最新的源信息生成的，确保它们在生成时是最新的。

图2。单一来源信息的理想方法。

 

图2的一个重要含义是，尽管信息存储在一个地方，但是它可以以多种方式呈现给不同的受众。这称为引用文档本地化原则。例如，最终用户将需要以与程序员不同的格式查看信息。有些人喜欢看图表，而另一些人喜欢文本形式的信息。仅仅因为信息需要以多种方式查看和处理，并不意味着它需要存储多次。正如您从您的源代码库构建可工作的软件一样，您将从您的单源信息库“构建”您的文档视图。

图3描述了一种更加实际的方法。尽管您希望将信息存储在一个地方，而且只存储在一个地方，但事实是您的工具集可能不允许您这样做。此外，因为你只是人类，你会犯错误，并记录相同的信息两次。此外，图3还显示了软件开发中的一种常见情况:尽管许多文档可以用源代码表示，例如使用Java中的JavaDoc注释，但是一些关键信息仍然存储为外部文档。例如，敏捷人员通常拥有简洁的系统概述文档、发布说明和用户指南。

敏捷建模

图3。单一资源信息的现实方法。

 

传统单一的来源

要使传统的单一资源远景工作，您需要一种通用的方法来记录信息。达尔文信息类型化体系结构(DITA)是一种基于xml的格式，它被推广用于单源技术文档。没有什么可以阻止您创建自己的存储策略:通常采用自顶向下的方式处理单个源，文档的数据结构通常在项目的早期定义。传统单一来源的主要挑战是，它需要相当复杂的技术文档方法。这非常好，但是不幸的是，许多组织还不能实现这个愿景，并且发现他们需要远离这种方法。这并不意味着您需要把婴儿和洗澡水一起扔掉:您仍然应该努力使您所有的软件开发工件正常化。

敏捷的单一来源

您没有理由不采取一种更敏捷的方法，使您的系统构件的结构随着时间的推移而出现。这就是AM实践单源信息的来源。当您建模时，您应该总是问这样的问题:“我需要永久地保留这些信息吗?”，“如果是，那么存储这些信息的最佳位置在哪里?”以及“这些信息是否已经在其他地方捕获，我可以简单地引用它们?”有时候，存储信息的最佳位置是在敏捷文档中，通常是在源代码中。

有几个AM原则和实践支持敏捷的单一资源。它们是:

1. 可执行的规范。这是最容易理解的单一来源信息的方法之一，通常也是最有成效的方法之一。通过在需求级别上采用测试驱动开发(TDD)方法，您的客户验收测试不仅是测试，而且是需求规范。类似地，在设计级别使用TDD，开发人员测试将构成详细设计规范的大部分。
2. 应用正确的工件。应该使用最合适的工件捕获技术信息，包括手绘草图、详细的数据模型、用例规范或源代码。
3. 有目的的建模。您应该知道为什么要创建一个工件，知道它是为谁创建的，以及他们将如何使用它。如果你不了解这三个因素，那么出于对某人、某个地方、某个时间可能需要它的恐惧，你很可能会记录下比你需要的更多的信息。这不仅会导致文档过多，而且很可能会无意中多次捕获相同的信息。
4. 支持集体所有制。只有当每个人都可以访问一个共享的工件集合时，才有可能一次又一次地在正确的位置捕获信息。如果有些人没有完全的访问权限，那么他们就会有动力获取自己版本的信息。
5. 建立泛化专家团队。当团队由只知道如何处理工件子集的专家组成时，您经常会在几个地方捕获相同的信息。例如，如果您的团队中有专家业务分析师、专家程序员和专家测试人员，那么这些团队中的每一个都将使用他们自己的方法来捕获业务规则——可能作为UML活动图、源代码和测试规范。当人们泛化具有一个或多个专长的专家，以及对完整软件生命周期的一般理解时，他们可以使用范围广泛的工件，从而减少了在多个地方捕获相同信息的需求。
6. 模型与他人。有效的软件开发团队以合作和协作的方式一起工作。当人们单独工作时，他们将捕获他们自己的技术信息版本，这个版本可能与他们的同事维护的版本略有不同。通过与他人建模，您不仅可以一起开发模型或文档，还可以在整个团队中传播技能和知识，从而提高模型和文档保持一致和规范化的机会。
7. 涉众的ROI最大化。开发团队中的每个人都应该确保涉众的钱被明智地使用。这不仅是一件好事，还增加了您的涉众将来希望继续与您合作的机会。多次捕获相同的信息、增加维护负担和增加可跟踪性需求真的有效吗?我不这么想。

其他支持单一来源的敏捷技术(至少在详细设计级别上)是代码重构和数据库重构。通过代码重构，您可以对源代码进行一些小的更改，以改进其设计;类似地，在进行数据库重构时，您可以对数据库模式进行一些小的更改，以改进其设计。许多重构，例如提取方法或引入查找表，分别显式地提高了系统底层对象或数据模式的规范化程度。

有趣的是，当一个敏捷团队由泛化的专家组成时，或者至少是由努力成为泛化专家的人组成时，当他们积极地尝试尽可能地做好工作时，存储信息的最佳位置往往是您的源代码。这正是许多极端程序员所声称的，尽管在我看来，他们一直在努力以传统IT专业人员能够接受的方式传达这一信息。许多传统主义者声称，如果您的文档在源代码中，那么它实际上就丢失了。他们真正想说的是，对于那些无法阅读源代码的人，或者至少对于那些没有工具(比如JavaDoc)的人来说，这些工具可以从源代码中提取关键信息，并以另一种格式显示出来，这些信息是丢失的。

正如找到一个完全规范化的关系数据库是极其罕见的一样，我怀疑您永远也不可能真正地完全单一地提供所有软件构件的源代码。在数据库性能方面的考虑，以及项目团队所犯的设计错误，都会导致模式不太正常。类似地，并非每个人都能够使用所有类型的工件——期望业务涉众能够阅读程序源代码是不现实的，支持这一愿景所需的超级工具将继续躲避我们(很可能永远如此)。

原文：http://agilemodeling.com/essays/singleSourceInformation.htm

本文：https://pub.intelligentx.net/agilemodelingsingle-source-information-agile-core-practice-effective-documentation

讨论：请加入知识星球或者小红圈【首席架构师圈】

要想有效，多模型原则告诉我们，敏捷建模人员应该知道各种各样的建模技术，这样他们就有了技能和知识来为当前的情况应用正确的工件。不幸的是，说起来容易做起来难。此页面链接到各种建模构件的摘要描述。每个页面都描述了工件，提供了一两个例子，并提供了到建议资源的链接。

您可能想在软件开发项目上创建的一些(但不是所有)潜在模型包括:

• Acceptance Test
• Business Rule (Template)
• Change Case (Template)
• Class Responsibility Collaborator (CRC) model
• Constraint
• Contract model (Template)
• Data Flow Diagram (DFD)
• Domain Model
• Essential/Abstract Use Case (Template)
• Essential/Abstract User Interface Prototype
• Feature
• Free-Form Diagrams
• Flow Chart
• Glossary
• Logical Data Model (LDM)
• Mind Map
• Network Diagram
• Object Role Model (ORM) Diagram
• Personas
• Physical Data Model (PDM)
• Robustness Diagram
• Security Threat Model
• System Use Case (Template)
• Technical Requirement
• UML Activity Diagram
• UML Class Diagram
• UML Communication/Collaboration Diagram
• UML Component Diagram
• UML Composite Structure Diagram
• UML Deployment Diagram
• UML Interaction Overview Diagram
• UML Object Diagram
• UML Package Diagram
• UML Sequence Diagram
• UML State Machine Diagram
• UML Timing Diagram
• UML Use Case Diagram
• Usage Scenario
• User Interface Flow Diagram (Storyboard)
• User Interface Prototype
• User Story
• Value Stream Map

 

原文：http://agilemodeling.com/artifacts/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

一种常见的敏捷实践是尽可能推迟所有可交付文档的创建，在实际交付之前创建它们。例如，最好在发行版开发结束时编写系统概览，因为您知道自己实际构建了什么。同样，大多数用户和支持文档也最好在生命周期的末尾编写。图1比较了传统的和敏捷的文档方法，显示了在整个SDLC中创建和维护文档所投入的相对总工作量。从根本上说，这种策略是等到信息稳定之后再在文档中捕获它。

注意，在生命周期的早期捕获投机性信息(例如需求或设计细节)通常是有风险的，因为这些细节可能会发生变化。这些类型的工件通常不包括在您的可交付文档中，除非在涉及到法规问题的情况下，所以在它们的创建和维护上投入大量精力没有多大意义。

图1所示。贯穿软件开发生命周期的文档。

值得注意的是这两种策略的不同之处:

• 敏捷人员在项目的早期进行建模和计划，但是他们不编写详细的文档。敏捷人员将在项目开始时投入一些时间来设想初始需求和初始体系结构。他们这样做是因为人们会问这样的问题，比如你要做什么，要花多少钱，要花多长时间，以及你要如何建造它。这意味着您需要进行一些高级需求和体系结构建模，但这并不意味着您需要编写大量详细的规范。从建模中获得价值，即不需要花费不必要的文档来考虑问题。敏捷人员还将创建一个高级计划，显示预计的交付日期、主要依赖项等等。
• 敏捷人员仍然创建详细的规范。敏捷人员以即时(just-in-time, JIT)为基础，而不是预先捕获细节。他们还喜欢以测试的形式编写可执行规范，而不是静态文档。当您采用测试驱动开发(TDD)方法时，这很容易实现。最后，敏捷者通常比传统主义者做更多的规范，但是我们用不同的方式来做。
• Agilists仍然编写支持文档。支持文档，如用户手册、操作手册和支持手册，是任何系统开发项目的重要交付物。敏捷主义者和传统主义者一样，一旦系统稳定下来，就会在生命周期的末尾编写这些文档。然而，由于敏捷人员将文档视为一种需求，所以我们将评估编写文档的工作量，并要求涉众将其与所有其他需求一起按优先级排列。由于利益相关者的参与和控制水平更高，当涉及到这类文档时，敏捷者往往比传统主义者更有效率(当你给人们在如何投资方面变得非常聪明、非常迅速的事情贴上可见的价格标签时)。
• 敏捷人员仍然编写系统概述文档。仍然需要为需要维护系统的人员提供高级概览文档。但是，由于敏捷人员编写的代码比传统人员编写的代码质量更高，并且他们的代码有一个回归测试套件(实际上是系统的详细规范)，您将发现您只需要一个主要由关键的高层图组成的简要概述。敏捷人员更强的纪律性，以及由此产生的更高的质量水平，导致对详细文档的需求更少(无论如何，这些文档总是过时的，进一步加剧了传统项目的质量挑战)。
• 敏捷者的成本曲线更低。图1中的敏捷曲线不仅较低，而且不那么陡峭。通过在生命周期的早期编写文档，传统主义者在整个生命周期中增加了文档维护成本。

这种做法的风险概况

一旦信息稳定下来，等待文档化可以降低成本和与文档化相关的几个风险:

• 财务风险。降低了成本，因为您不会浪费时间记录更改的信息，这反过来又会促使您更新文档。如果您编写的文档包含的信息还没有稳定下来，那么一旦信息发生更改，您就有重新编写文档的风险。换句话说，您不希望在项目的早期花费大量时间记录投机性的想法，比如需求或设计。相反，等到生命周期的后期，当信息已经稳定下来，并且您知道哪些信息实际上对您有用时，才可以使用它。这意味着您的文档工作可能是软件开发工作背后的几个迭代。
• 准确的风险。准确性会提高，因为你关注的是你实际构建和做了什么，而不是你猜测你将要做什么。在生命周期早期编写文档的一个挑战是在整个生命周期中不能很好地维护它——很容易假设您将在下一次迭代中进行适当的更新。

 

然而，这并不意味着所有的文档都应该留到最后，因为有些风险会增加:

• 交付的风险。由于缺乏资源(财务、时间)，您可能无法完成所需的文档。为了抵消这种风险，创建这些文档时要明确需求，应该像其他需求一样对这些需求进行优先级排序和评估。
• 准确的风险。你可能会忘记一些信息。为了抵消这种风险，您可能仍然希望在整个开发过程中为这类文档做笔记，这样您就不会丢失关键信息。这些注释可能只是点格式的信息，因为在最终交付之前不需要“润色”文档。

我的团队不应该不断地进行文档记录吗?

处理敏捷项目文档的另一种不同策略是持续地进行文档编制。基本思想是在整个项目中编写可交付的文档，并在更新软件时更新文档。这一战略支持敏捷哲学总是产生一个解决方案(自律敏捷交付团队认识到有更多比创造伟大的软件,你真正生产是一个很好的解决方案,包括软件、硬件、支持文档,更改业务流程,并有可能改变组织结构)是潜在的可交付。要做到这一点，你确实需要不断地记录，但在这样做的过程中，你开始加重旅行的负担，从而承担与之相关的风险。所以，真正的问题是你愿意做出什么样的权衡?

 

原文：http://agilemodeling.com/essays/documentLate.htm

本文：

讨论；请加入知识星球或者小红圈【首席架构师圈】

如果你的目标是每个冲刺的潜在的可交付软件,他们说,在Scrum中,或者更好的是一个潜在的解决方案每次迭代中我们说纪律敏捷交付(爸爸),那么你需要保持你的交付文档同步与您的软件/解决方案——换句话说,写在整个项目中持续交付文档。图1中概述了该策略。您的另一种选择是将可交付文档的最后定稿留到项目的末尾，以便稍后进行文档化。

图1所示。通过SDLC -文档持续策略编制文档。

我一直在使用术语“可交付文档”，但这意味着什么呢?可交付文档是作为整体解决方案的一部分交付给涉众的文档。当然，这在不同的项目中会有所不同，但是可交付的文档通常包括用户手册、培训材料、操作手册、支持手册和系统概述。它通常不包括需求规范或设计规范，当然，除非在法规情况下需要这样的文档，或者在合同谈判中需要作为合同的一部分。当然，对于所有这些工件，我强烈建议遵循敏捷文档的最佳实践。

下面是一些很好的启发式方法，可以有效地持续记录:

1. 等待信息稳定下来。在您完成大部分开发工作之后编写文档，换句话说，在迭代的末尾。如果您记录的信息还不稳定，就会冒着必须重新编写文档的风险。
2. 在长迭代的迭代过程中编写文档。对于“长”迭代，比如四周或更长时间，您有足够的时间来稳定信息，从而在迭代期间捕获信息。
3. 用短迭代编写以下迭代的文档。对于“短”迭代，即两周或更短的迭代，信息不太可能及时稳定下来，以便您完成文档。为了尽可能保持效率，您应该考虑在迭代N+1期间为迭代N编写可交付的文档。对于中等长度的迭代(两到四周)，您将需要进行试验，以确定哪种方法更适合您。

注意，使用这种实践，许多团队将在迭代的done定义中包含关于更新可交付文档的标准。换句话说，文档成为确定工作项(例如用户故事或缺陷报告)是否已完全实现的验收标准的一部分。这反映了在软件之上解决方案的有纪律的敏捷交付(DAD)哲学。

这种做法的风险概况

通过在整个项目中不断编写可交付的文档，您可以解决以下风险:

1. 交付的风险。通过与解决方案的其余部分同步编写文档，您知道您有足够的文档来支持到目前为止构建的内容。这意味着您的解决方案实际上可能在每次迭代结束时交付。
2. 准确的风险。因为完成工作和记录工作之间的反馈周期很短，所以更有可能记住需要捕捉的关键细节。

然而，这种做法可能增加三种风险:

1. 财务风险。因为需求可能在整个项目中不断发展，所以您需要更新可交付的文档来反映这些变化。从敏捷的角度来看，通过不断地记录文档，您实际上是在“长途旅行”。
2. 进度风险。编写和维护这个文档需要花费时间和精力，并且由于需求的不断变化而导致的文档的任何返工都会影响您的进度，因为需要返工。
3. 准确的风险。遗憾的是，不断地编写文档要比不断地编写文档容易得多。通常情况下，敏捷团队会推迟编写文档，直到他们有时间这样做，实际上是向文档后期实践而不是这个实践迈进。

原文：http://agilemodeling.com/essays/documentContinuously.htm

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

是利益相关者的积极参与是一个扩张的做法极限编程(XP)的年代描述需要现场客户现场访问的人,通常用户或他们的代表,他们的权力和能力提供信息系统的构建和有关要求,相关和及时决策和优先级。虽然这种程度的参与是使您的软件开发工作有效所必需的，但在许多组织中，尤其是在那些政治而非理性成为家常便饭的组织中，这种参与常常是不够的。项目成功通常需要项目干系人更多地参与:域和技术专家应该积极参与建模(是的,创建实际模型,不仅给modeler)信息,高级管理层需要公开和私人项目支持,操作和支持人员必须积极处理你的项目团队对生产环境让你准备接受你的系统,其他系统集成工作团队必须与你的支持,维护开发人员必须努力熟悉系统使用的技术和技术。本文的重点是探讨如何成功地促进敏捷交付团队中积极的涉众参与。

内容

• 谁是利益相关者?
• 为什么利益相关者的参与很重要?
• 合作策略
• 获得与涉众的联系
• 影响利益相关者参与的因素
• 项目团队实际上在做什么?
• 权利和责任

1. 谁是利益相关者?

我定义项目的利益相关者是谁直接用户,间接用户,用户的经理、高级经理、操作人员、基金项目的“金老板”,支持(服务台)工作人员,审计人员,程序/投资组合经理,开发人员在其他系统集成或与一个正在开发,或维护人员可能影响软件项目的开发和部署。

从这个定义可以看出，业务人员(如直接用户及其经理)并不是项目的唯一涉众。正如您所知道的，有很多人可能受到新系统的影响，因此，要成功，您必须理解他们的需求，然后将他们的需求综合成一个有凝聚力的远景。这是使软件开发变得困难的原因之一:每个项目涉众都有自己的需求、自己的愿景和自己的优先级。但它也使软件开发变得有趣。

在这个定义中，我选择了排除正在开发项目的开发人员。乍一看，这似乎有些奇怪，因为开发人员在他们所从事的项目中显然有着重要的利害关系。是的，开发人员绝对是项目涉众。为什么我要继续区分开发人员和项目涉众?因为我想要方便的术语来区分它们，所以我真的不喜欢“开发人员涉众”和“非开发人员涉众”，而且因为它们在项目中扮演不同的角色。

我对项目涉众和开发人员的定义可能与您的不同，或者您更喜欢使用不同的术语。例如，XP讨论的是客户和程序员的概念，而不是项目涉众和开发人员的概念，并且定义略有不同，因为他们使用的术语与AM不同。另一方面，Scrum讨论的是敏捷团队成员(而不是开发人员)和产品所有者(而不是客户或更准确地说是利益相关者代表)。最复杂的利益相关者的定义,我见过在敏捷社区来自由外向内的软件开发,因为它显式地表明,有一个广泛的利益相关者,甚至将它们组织成四类:主体(的人买你的软件),最终用户(与它的人),合作伙伴(那些会使你的软件工作在生产),和业内人士(组织内部的人影响你的团队是如何工作的。软件开发的外部

2. 为什么利益相关者的参与很重要?

人们不太擅长定义他们想要什么，尤其是在细节上。然而，人们很擅长指出他们认为自己想要什么，然后当一个选项呈现给他们时，他们喜欢什么，不喜欢什么。换句话说，我们需要与涉众合作，确定他们认为自己想要什么，生成反映这种理解的东西，从涉众那里得到反馈，然后更新我们的解决方案，以反映我们改进的理解。其含义是，如果我们要提供反映涉众实际需求的解决方案，我们就需要以一种更加进化和协作的方式工作，而且要做到这一点，我们必须与涉众密切和定期地合作。

传统的软件开发方法基于在项目早期定义详细的需求规范，称为“大需求预先(big requirements up - front, BRUF)”策略，在实践中证明是非常危险的。传统的项目团队，即使是“成功的”项目团队，在努力生成反映规范的解决方案时，通常也不会产生理想的结果。是的，团队可能会产生一些符合规范的东西，但是它可能不是涉众真正想要的，而是他们在过去某个时候认为他们需要的东西。我认为，一个有纪律的敏捷交付项目团队的目标应该是为他们的涉众提供一个解决方案，该解决方案在给定条件下尽可能有效地满足他们当前对涉众意图的理解，而不是构建符合规范的东西。

3.合作策略

很明显，为了取得成功，所有项目涉众都必须积极地与您的团队合作来实现这些目标。这种做法有几个含义:

• 及时决策。涉众必须准备好与团队共享业务知识，并就项目范围和需求优先级做出相关和及时的决策。
• 包容的建模。您需要采用基于以用户为中心的设计(UCD)和参与性设计原则的包容性建模技术，涉众可以轻松地学习和采用这些技术。
• 管理需要IT技能和知识。对于高级经理来说，要有效地支持您的项目，他们必须首先了解您的团队正在使用的技术和技术，了解团队使用这些技术的原因，以及使用这些技术的含义。有了这些知识，他们在组织的政治舞台上的努力更有可能在正确的时间以正确的方式有效。高级经理不可能仅仅通过阅读每周的项目状态报告或参加每月的项目指导会议来获得这些必要的知识。相反，他们需要投入必要的时间来学习他们管理的东西，他们需要积极地参与系统的开发。
• 生产人员从一开始就参与其中。您的运营和支持组织必须投入必要的资源来理解您的系统和它所使用的技术。您的支持人员必须花时间了解系统的细微差别，这意味着他们需要在系统开发时使用您的系统，并且/或者您的团队需要为他们提供培训。此外，您的操作人员必须精通系统的安装和操作。您可以选择在您的开发团队中包括一名或两名运维工程师，或者再次根据需要投资项目资源来培训运维人员。无论采用哪种方法，您的运营和支持组织都需要积极地参与到项目团队中。
• 从企业的角度来看。如果您的系统需要与其他系统集成，则需要与其他项目团队合作。例如，您的系统可能需要访问遗留数据库、与在线系统交互、处理由外部系统生成的数据文件，或者为其他系统提供XML数据提取。如果没有这些开发人员的积极参与，集成常常是困难的，甚至是不可能的:想象一下，如果大型遗留数据库的所有者拒绝提供关于该数据库的任何信息，那么访问包含在该数据库中的信息将是多么困难。一些初始的体系结构设想将有助于推动这一点。
• 不要直接交给维护团队。维护开发人员需要与您一起学习您的系统。当目的是部分或完全的传递系统的维护和其他开发人员,通常引入软件专业人员熟练的在维护和增强现有系统释放原始开发团队的成员,那么你的团队必须与这些人的工作,这样他们就可以接管您的系统。即使一些最初的团队成员仍然参与其中，也必须努力将知识转移给团队的新成员。

4. 获得与利益相关者真正接触的策略

我从未参与过IT项目，无论是敏捷项目还是其他项目，在这些项目中，我无法定期、直接地访问关键的涉众或他们的代表。从事过金融(包括经纪)、零售、电信、电子商务、软件产品开发、政府(包括军队)等项目。然而，我曾经参与过许多项目，在这些项目中，人们为自己找不到利益相关者提供借口(没有一个理由是站不住脚的)。常见的理由包括:

1. 理解涉众参与的重要性。首先，您需要理解为什么积极的涉众参与是重要的，以及如果没有它，对您的项目将会产生什么影响。在许多组织中，您将被要求证明为什么涉众需要积极参与IT项目，并且您越了解为什么IT项目很重要，您就越有能力为它辩护。
2. 从利益相关者那里获得支持。您的一些涉众可能会喜欢积极地参与到您的项目中，并且更多人可能会很容易地相信他们应该参与进来。
3. 高级管理教育。在许多组织中，高级管理人员需要确定并支持涉众的参与程度。为了做出这个决定，他们需要了解每一种选择和权衡。
4. 是灵活的。尽管您希望与涉众共享位置，并能够立即访问他们，但并不总是这样。你可能一天只能和他们交流几个小时，或者一周只能交流几小时。更多的访问通常是更好的，但是正如您在下面看到的，有几个原因可以解释为什么很难连续地访问它们。
5. 准备好与利益相关者代表合作。不管您可能听过什么空洞的花言巧语，您最终几乎总是要与代表更广泛的利益相关者社区的人一起工作(这对于产品所有者来说当然是正确的)。
6. 为它而战。积极的涉众参与对项目的成功至关重要，因为没有它，您将不知道涉众实际上需要什么。
7. 继续为之奋斗。在整个项目中，将会有压力将涉众从项目中转移出来，这样他们就可以专注于他们正常的“日常工作”。您可能需要保持定期的沟通流，感谢涉众的参与(无论如何，这始终是一件礼貌的事情)，并提醒他们他们对工作的积极影响。

获得利益相关者的参与，更不用说获得他们的积极参与，可能很难，原因有以下几点:

1. 我们培训了利益相关者以“放手”的方式工作。几十年来我们对利益相关者遵循传统串行/ IT项目方法——我们会做一些初始需求收集,我们经常要求他们签署的需求和项目计划,我们会给他们定期更新的项目,然后几个月有时几年后让他们参与验收测试。换句话说，要有短的、明确的介入时间，而在这段时间内几乎不介入。使用现代方法，比如敏捷，我们现在要求他们在整个项目中持续参与。
2. 许多利益相关者不信任我们。从涉众的角度来看，传统的解决方案交付方法在实践中并没有很好地发挥作用。根据2008年IT项目成功调查，传统策略在交付涉众积极想要的功能方面不是很有效，这一点得到了Standish Group的Chaos报告的支持(有关详细信息，请参阅BRUF文章)。
3. 这不是他们工作的一部分。许多涉众认为他们不需要积极地参与IT项目——IT工作毕竟是IT部门的工作。这可能是一个难以克服的文化问题。
4. 他们认为这太难了。许多传统主义者将使用复杂的图表，这些图表使用的符号是涉众不习惯看到的，也不是所有人都有兴趣学习的。敏捷主义者更喜欢使用包容性的工具，比如简单的旧白板(POWs)和纸张，以及草图来与涉众建模。
5. 他们认为正常的“日常工作”更重要。从利益相关者的角度来看，这是公平的，但从您的组织的角度来看，很可能不是。每当我遇到有人告诉我利益相关者太忙或他们的时间太宝贵的情况时，我就会质疑这种逻辑。如果这是真的，那么他们告诉你的是，他们日常工作的组织价值大于IT项目的价值。如果这是实际情况，那么投入到项目中的资源应该真正用于帮助涉众完成他们的日常工作。
6. 他们真的不是一直都有空。组织的正常活动仍然需要与IT项目并行进行。一些利益相关者可能无法在正常的工作时间。例如，我在经纪公司工作过，我们不能在交易时间与交易员互动，但在其他时间可以。一些涉众可能只有部分时间，也许一天中只有一两个小时。

5. 影响利益相关者参与的因素

有几个因素将影响涉众如何参与解决方案交付团队的性质和质量。表1总结了这些因素。

表1。影响涉众参与IT项目的因素。

Factor	Range	Potential Impact(s)
Participation style	Reactive <=> Proactive	Stakeholders who proactively participate with IT project may have a political agenda which they are trying to further. Stakeholders who are reactive to requests for information may slow the project because the team must wait for responses (minimally, the product owner will need to guess at the answer, increasing the chance of potential rework in the future) Reactive stakeholders may be a sign that the stakeholder community has a poor relationship with the IT department
Relationship	Negative <=> Positive	When the relationship between IT and stakeholders is negative the stakeholders will likely participate less frequently and to a lesser extent
Communication channels	Formal <=> Informal	Formal communication, such as written documentation in a specific format, can increase the bureaucratic overhead on the team, increase cost to the project, and increase the time it takes to deliver the solution. Communication will increase in formality in regulatory compliance situations. Informal communication strategies, such as face-to-face communication and sketching, lowers overall complexity and cost and often improves time to market.
Availability	Irregular <=> Continuous	When stakeholders aren't regularly involved with a project team the chance that the team will build the wrong thing increases. With continuous stakeholder participation the feedback cycle is reduced, improving overall chances of project success.
Interaction	Facilitated <=> Active	When interaction with stakeholders needs to be facilitated (someone needs to act as a go between to help the development team and stakeholders to communicate) you run the risk of miscommunication and increasing the team's time to delivery (the facilitator becomes a potential bottleneck).
Location	Co-located <=> Global	When the team is co-located with stakeholders it is much easier for them to interact regularly and actively with the development team. As the team becomes more geographically distributed, the chances of project success decrease (see the 2008 IT Project Success Survey for some figures).

6. 团队实际上在做什么?

到目前为止，我所描述的一切都很好，但是敏捷团队实际上在实践中在做什么呢?幸运的是，我的一些IT调查提供了一些见解。图1总结了2013年的一个问题的结果:您有多敏捷?调查列出了与涉众合作的几种策略，以及自称敏捷的团队中这些策略的采用率。正如您所看到的，有几个迹象表明敏捷团队正在与他们的涉众紧密合作:

1. 超过60%的公司定期与股东进行讨论
2. 一半的人花时间来确定他们的利益相关者是谁以及他们的目标是什么
3. 60%将可用性问题考虑在内(这需要与涉众紧密合作)
4. 超过一半的人正在积极尝试改进业务流程，这也需要积极的涉众参与

图1所示。为利益相关者创造价值的潜在策略。

图2还描述了2013年的结果:您有多敏捷?调查，在本例中探索敏捷团队如何验证他们的工作。在迭代演示中，团队向主要涉众展示了他们所做的迭代工作，几乎占到了60%。验收测试驱动开发(TDD)也是一项需要涉众积极参与的活动，占18%，而面向更广泛的涉众群体的“全手演示”占28%。

图2。敏捷的标准:验证。

在建模方面，2013年的项目启动调查发现，超过90%的人预先进行了某种类型的需求建模，这显然需要涉众的参与。图3显示了2008年建模和文档调查的结果，显示了使用包括白板和纸张在内的建模工具是非常普遍的，无论开发范式如何。

图3。主要建模策略。

7. 权利和责任

我曾经谈论过项目涉众的权利和责任，这是我从Karl Wiegers的优秀著作《软件需求》中采用的一个概念。不幸的是，我最近发现，敏捷建模中所描述的这些权利和职责并不像我最初认为的那样清晰，甚至可能产生分歧。因此，在对AM邮件列表进行了相当多的讨论之后，我决定从项目中每个人的角度重新定义权利和责任，而不仅仅是从涉众的角度。

人人的权利:

1. 被尊重。
2. 根据项目标准和原则，随时生产和接收高质量的产品。
3. 评估你积极参与的活动，并让其他人尊重这些评估。
4. 被提供足够的资源(时间、金钱等)来做要求你做的工作。
5. 来决定你的资源将如何投资。对于为项目提供资金的人来说，资金将如何使用，对于为项目工作的人来说(例如，投资时间)，他们选择从事什么任务。
6. 有机会获得与项目成功相关的知识。业务人员可能需要了解基础技术和技术人员来了解业务。
7. 及时作出决定。
8. 及时提供诚信的信息。有时这只是当时“最好的猜测”，完全没有关系。这包括但不限于业务信息，如优先级需求和详细的领域概念，以及技术信息，如设计和详细的技术概念。
9. 拥有组织的软件流程，在需要时跟踪并积极改进这些流程。

每个人的责任:

1. 在你愿意投入的资源范围内，创造一个最能满足你需求的系统。
2. 愿意与他人合作，尤其是那些你所选择专业以外的人。
3. 分享所有信息，包括“正在进行中的工作”。
4. 积极扩展你的知识和技能。

 

原文：http://agilemodeling.com/essays/activeStakeholderParticipation.htm

本文：https://pub.intelligentx.net/agilemodeling-active-stakeholder-participation-agile-core-practice

讨论：请加入知识星球或者小红圈【首席架构师圈】

一个常见的敏捷实践是在项目的早期执行一些高层次的需求设想，以帮助对您想要完成的范围达成一个共同的理解。此时的目标是为工作确定业务目标，开发一个共同的远景，并在高层快速地确定系统的初始需求。此时，您不需要编写大量的文档，相反，您将在稍后的模型风暴会议和通过TDD确定开发周期中的细节。通常，这种初始需求建模工作是以小时或天为顺序的，而不是像我们在传统项目中看到的周或月。本文解决了几个关键问题:

• 什么时候应该进行最初的敏捷需求设想?
• 为什么要进行一些最初的敏捷需求设想?
• 您最初应该建模什么?
• 您应该使用什么建模工具?
• 您实际需要进行多少初始需求设想?
• 你为什么不把细节先写出来呢?
• 什么时候进行大量的需求设想是有意义的?
• 人们真的在这么做吗?

1. 什么时候应该进行最初的敏捷需求建模?

敏捷模型驱动开发(AMDD)，见图1，显式地包含了敏捷项目迭代0期间的初始需求设想工作(一些流程可能称之为预热、初始阶段或初始阶段)。初始需求设想对于将敏捷软件开发技术扩展到更大、更复杂或全球分布式开发(GDD)工作中尤为重要。高层的目标是了解需求,它不是创建一个详细的需求规范在生命周期的早期,传统的做法称为“大需求预先”(BRUF)证明在实践中是非常危险的(传统理论认为BRUF是一个最佳实践,但经验表明否则)。

图1所示。AMDD生命周期:项目视图。

2. 为什么要进行一些最初的敏捷需求设想?

有些人会告诉您，您根本不需要进行任何初始需求建模。然而，我的经验是，以敏捷的方式进行一些初始需求建模有以下几个好处:

1. 你可以回答基本的商业问题。不管你喜不喜欢，人们总是会问你，你的愿景是什么(范围是什么)，你认为它将花费多长时间(计划)，以及它将花费多少钱(预期预算)。您通常不需要详细地回答这些问题，但是您需要说服为您的项目提供资金和支持的人员，让他们相信您了解您的项目团队将要解决的基本业务问题。
2. 提高的生产力。您可以识别和考虑项目面临的一些关键业务问题。
3. 降低业务风险。您的团队获得了拥有指导业务远景的优势，而没有与BRUF相关的缺点。在统一过程中，初始阶段的主要目标是驱动范围与涉众的一致性，从而降低业务风险，而实现这一点的方法是通过初始需求的设想。您不仅确定了工作的范围，还帮助相关的涉众意识到您的系统(而不仅仅是他们的系统)正在满足一系列的需求，而且他们有时将不得不做出妥协。
4. 扩展敏捷软件开发。初始需求模型将是一个关键工作产品任何大规模“敏捷”的努力,因为它提供了你所需的业务方向他们最初的建筑构思总体架构团队的努力(通常在与初始需求建模)和团队成员定义在整个项目和指导他们的努力。

3.您最初应该建模什么?

对于系统的第一个版本，您需要花费几天的时间来确定一些高级需求以及版本的范围(您认为系统应该做什么)。我们的目标是让你对这个项目有一个良好的直觉。我的经验是，你需要一些形式的:

• 使用模型
• 域模型
• 用户界面模型()

3.1使用模型

使用模型使您能够探索用户将如何使用您的系统，如果您想了解他们需要什么，这是绝对关键的。您的使用模型可能是Rational Unified Process (RUP)项目上的一组基本用例或系统用例，一组用于功能驱动开发(FDD)项目的功能，或者一组用于极限编程(XP)项目的用户故事。我通常更喜欢用户故事或者用例，尽管我在实践中的实际选择将由团队所遵循的软件过程(RUP, FDD，…)驱动。

在项目开始时，用例名称列表可能就足够了，尽管通常您需要更详细地介绍。图2描述了我将考虑为一个高级用例考虑的细节级别。它指示名称(在本例中是注册研习班)和用例所涵盖的基本逻辑。我可能会将这类信息写在索引卡或便利贴上(如图7所示，这种基于纸张的建模在敏捷项目中很常见)。我甚至可能决定使用电子工具(如文字处理程序或电子表格)来捕获它，尽管此时，这样的工具可能会阻碍我的建模工作，而不是提供帮助。

 

图2。作为高级用例注册研讨会。

• 参加研习班
• 学生选择参加一个研讨会
• 系统检查学生是否可以报名参加研习班
• 系统计算费用
• 学生支付费用并被录取

关于图2的用例，需要注意的一件有趣的事情是，它没有捕获很多细节。例如,它只有一个高度概括的逻辑当事情解决好(行动的基础课程),但它不捕获备选过程如当学生没有资格参加,或没有房间在研讨会上,或者它不适合的计划,或他们不能支付费用,等等。如图1所示，可以通过模型风暴在即时(just-in-time, JIT)的基础上捕获细节。现在的目标是获得对范围的高级理解，而不是编写文档，也就是我们对需要构建的内容的理解。

图2的用例对应的用户故事是:

• 作为一名学生，我搜索研讨会，所以我可以注册他们
• 作为一名学生，我报名参加一个研讨会，这样我就可以参加了
• 作为一名学生，我要交学费，这样我就可以入学了

尽管它们对开发人员来说是相对无用的，但是您经常会发现您想要创建一个UML用例图来概述您所构建的东西的使用需求。图3给出了这类图的一个例子在白板上,虽然你常常会发现,您需要使用一个电子绘图工具如Visio甚至CASE工具,例如Rational System Architect (RSA)“漂亮”图展示等高级管理层和重要利益相关者的“金老板”的项目。尽管如此，我经常在管理演示中使用白板草图的数码照片，如图3所示。他们是成年人，他们明白你有更重要的事情要做(比如构建可运行的软件)，而不是把信息转录成更复杂的工具。

图3。UML用例图的白板草图。

3.2域模型

您最初的建模工作的一部分，特别是对于业务应用程序，可能包括概念域模型的开发。这个模型应该非常精简，捕获主要业务实体及其之间的关系。正如您在图4中所看到的，您的模型并不需要是完整的，它只需要包含足够的信息，使您能够适应主要的业务概念。我会在白板上画一个这样的模型作为开始，并且很可能在整个项目中都把它放在白板上。我的经验是,一个苗条的域模型这样的项目团队是一个有价值的资产,应该非常容易视图(你应该只需要从你的办公桌并查看共享白板在你的工作空间),创建(白板非常包容),和修改。

图4。初始域模型。

域模型标识基本业务实体类型以及它们之间的关系。域模型可以描述为类责任协作者(CRC)卡的集合、瘦UML类图，甚至瘦数据模型。此时，您的域模型将包含足够的信息来理解业务实体的“全景”。图4应用了一个基于UML的数据建模符号(您可以使用任何您喜欢的符号来进行敏捷数据建模，我更喜欢UML)。您的初始域模型将用于帮助指导物理数据模型和类设计。

3.3用户界面模型

用户界面(UI)是用户直接与之交互的软件的一部分。对于大多数涉众来说，UI就是系统，因此确保您理解涉众对UI的期望对于项目的初始成功是至关重要的。探索UI需求的一种方法是创建所谓的基本UI原型，也称为抽象原型或纸上原型。基本UI原型以独立于技术的方式表示用户界面需求，就像基本用例模型对行为需求所做的那样。图5描述了一个基本的UI原型，用于让学生参加研讨会。学生姓名便利贴是一个包含四个活动元素的容器:名字、姓氏、中间和标题。另一个便利贴是学生参加过或正在参加的研讨会的列表。请注意，每个便利贴都有一个描述其用途的名称，但没有说明它是如何实现的。你可以看看便利贴，马上就知道它是怎么用的。

图5。注册研讨会的基本UI原型。

尽管基本UI原型是一项伟大的技术，但许多涉众发现它们太抽象，反而更喜欢屏幕草图和工作软件。图6表示图5的屏幕示意图版本。在这种情况下，有两个屏幕而不是一个屏幕来处理聚合问题——我更喜欢实现单一目的的屏幕，在这种情况下，分别捕获基本的学生信息和让学生参加研讨会。这可以说是一个设计问题(在需求/分析和设计之间有一条很细的线，您将一直跨越这条线)。草图提供最终的详细程度比纸上原型,它是更容易了解如何实现屏幕比从图5中,尽管草图不灵活的,因为很难小部件从一个图的一部分转移到另一个而纸很容易。

图6。屏幕上的草图。

一个相关的模型是一个UI流程图，通常称为UI故事板，如图7所示。然而，UI流图绘制可以说是一个UI体系结构问题，可以通过并行的初始体系结构设想工作来解决。最重要的是，模型的分类并不重要，重要的是，当它有意义时，你就去做。

图7。UI流程图。

有些项目甚至可能需要开发一个具体的用户界面原型，如图8所示。您通常至少会为UI的一个关键子集这样做，以便在项目开始时研究可用性问题，但不针对整个系统(即BRUF)。

图8。具体的UI原型(HTML页面)。

4. 您应该使用什么建模工具?

敏捷建模者将使用最简单的工具来完成工作。正如您在图3和图6中所看到的，我发现白板图通常足以满足初始需求模型。您的目标是在生命周期的这一点考虑关键的业务问题，而不是创建漂亮的图表。使用更复杂的绘图工具并没有什么错，正如您在图4中所看到的，只要确保您投入的努力是值得的。这完全取决于你所处的环境。此外，基于纸张的工具也很常见。例如，我很想首先在索引卡上捕获图2的用例，然后在适当的时候使用电子工具捕获信息。

5. 您应该进行多少初始需求设想?

快速的答案比“极端敏捷者”告诉你的要多一点，但比专业建模者相信的要少很多。请记住，此时您的目标是了解范围和远景，而不是详细记录人们对他们想要什么的猜测。重要的是要认识到你不需要细节，你只需要足够的信息来回答你被问到的业务问题。如果要点列表足够好，可以让您对实现用例的相对工作量做出合理的猜测，那么现在只捕获这些信息。如果您需要这些细节，可以在项目期间或迭代建模期间通过模型风暴以准时(JIT)的方式收集它们。试图在项目的早期捕获需求背后的细节被称为“前面的大需求(BRUF)”。BRUF在理论上看起来是一个好主意，但在实践中证明是相当危险的，因为它所激发的浪费水平很高。

您的初始需求建模工作有几个潜在的最终产品:

1. 初始需求堆栈。敏捷人员必须来自某个地方的初始“优先级需求堆栈”，而这个地方就是您的初始需求建模工作。
2. 最初的项目远景。为了减少项目上的总体业务风险，您应该考虑开发一个初始的项目远景，一个Rational统一过程(RUP)和项目管理协会(PMI)已经推广了十多年的想法。一个好的项目愿景可以是简单的几个要点或一段话，不应该超过一页。传统的组织，特别是那些错误地以一种沉重的方式实例化RUP，或者以一种沉重的方式引用PMI的建议的组织，经常会在远景声明上投入太多的时间。一个很好的经验法则是，如果您的项目远景超过一页，那么您已经在编写它上投入了太多的精力。
3. 概述图。因为您可能需要向查看项目的主要项目涉众进行演示，所以您可能需要创建几个描述业务的范围图。UML用例图或传统的业务流程模型通常非常擅长于此。如果你花了几个小时在白板上画这些图表，然后把它们抄写到一个工具上美化它们，那你就做得太过分了。

图9描述了建模的价值，显示了当模型还不够好时，它们达到了它们的最大价值，对于大多数项目来说，当涉及到初始需求时，通常在几天或一周左右之后才想到这一点。许多人最初震惊这一说法,但当你回想起你曾经的所有项目上,有多少,如果你允许,你能确定初始范围内一两个星期把几人理解域在一起在一个房间里的白板?我问过几千人这个问题，但只被告知少数几个项目不是这样的。周围许多人的故事无法让人们同意,向我显示,你应该考虑做这个项目完全或尝试一些与一个较小的范围,不能获得利益相关者(一个物流的问题,你可以选择克服如果项目实际上是足够重要的),或者他们根本不知道他们想要什么(现在明确表示不做项目)。这些都是借口，但是它们不是通过做太多初始建模来增加项目风险的好理由。

图9。建模的价值。

6. 为什么您不需要，也不想预先了解细节

有几个原因可以解释为什么在开发项目的开始就提出详细的需求在实践中是一个非常糟糕的想法:

1. 它导致了大量的浪费。研究表明，当项目团队采用平均45%的交付功能从未被使用的BRUF方法时，实际上能够将软件交付到生产中。在我看来，45%的浪费是不可思议的。遗憾的是，在项目开始时，经常采用BRUF方法来获取“准确”估计所需的信息，这是财务人员在减少财务风险的错误尝试中所需要的。考虑到由此产生的浪费，很明显，这种方法似乎会增加项目的财务风险，而不是降低它。
2. 它减少了您发现您正在构建错误的东西的机会。详细的需求规范可以为您提供一种错误的安全感，使您能够理解涉众的需求。这反过来又会使您在项目进展过程中失去探索和重新思考需求的动力，从而降低您认识到并处理与涉众实际需要的任何偏差的可能性。
3. 人们不擅长预先定义他们想要什么。这是我们几十年前就知道的，它激发了20世纪80年代的螺旋/RAD运动，以及UI社区中的原型实践。
4. 它会促使糟糕的决策。项目开始时，您对问题域的了解最少，而涉众对解决方案域的了解最少(您还没有生成任何可用的软件来显示它们)。然而，传统的教条是将您所有有限的并且很可能改变对需求的理解写在纸上，这样您就可以开始制定重要的计划和预算决策。然后，在项目的后期，我们惊奇地发现，我们在项目早期所做的决策，特别是我们的评估，证明是相当糟糕的。记住GIGO的格言:垃圾进，垃圾出。
5. 它增加了沟通的风险。几十年来，我们也知道，至少心理学界知道，向某人提供文档是向他们传达信息的最糟糕的方式。对于人们彼此之间的沟通，还有更好的策略，在需求引出的情况下，积极的涉众参与的AM实践将显著降低沟通风险。
6. 一旦需求稳定下来，您总是可以记录下来。如果需要编写需求文档，那么在需求稳定之后，在生命周期中尽可能晚地编写文档会更有效。这并不一定意味着您必须在项目结束时编写文档，需求规范可以而且应该是随时间变化的活文档。此外，大多数敏捷人员更喜欢在客户验收测试(可执行规范的一种形式)中获取详细的需求信息。

许多传统主义者会告诉你，你需要预先对每件事进行详细的建模。他们错误地相信这一点有以下几个原因:

1. 这是他们所知道的。大型预先建模(BMUF)是他们所接受的培训，也是他们在整个IT职业生涯中一直在做的事情，他们被告知，否则工作是无效的。传统的教条是做BMUF，当你已经被这种教条束缚了几十年，你需要几年的时间来打破它。
2. 他们是专家。许多人选择专攻建模活动，结果他们就这样做了，因为这是他们唯一可行的选择。专家不仅倾向于执行他们的专业活动(这并不奇怪)，不管是否需要，他们还会有一个表面上看起来一致的理由，说明为什么这是一件重要的事情。不幸的是，他们的推理通常只关注感知到的好处，而不考虑实际的风险。
3. 传统的项目管理思想激发了糟糕的建模策略。传统主义者常常被迫创建详细的、预先的评估和计划，这是一种错误的尝试，目的是减少项目风险(这种策略不可避免地增加了项目风险，因为它激发了大量可疑的开发活动)。
4. 他们低估了自己的日程安排能力。传统主义者常常认为他们无法在整个项目中接触到涉众，这是一个自我实现的预言，因为多年来，传统主义者一直在培训涉众，认为他们只在需求和用户验收测试阶段才需要。在实践中，获得与涉众的联系通常是非常容易的。
5. 他们已经放弃了希望。许多传统主义者，也许是大多数人，并不真正相信BRUF是一个好主意，而是被组织中的其他人强迫接受的。有趣的是，当你把所有的主要决策者聚集在一个房间里时，人们很快就会得出这样的结论:没有人真正想做BRUF，但他们认为其他人都需要这样做。

7. 什么时候进行大量的需求设想是有意义的?

您需要花费比我前面描述的更多的时间来进行需求想象的原因有几个。这些原因是:

1. 你在一个未知的问题空间中工作。您正在处理的问题空间对您的组织来说可能是全新的，因此您可能需要进行更多的初始需求设想，以便更好地理解该空间。在这种情况下，您可能会发现需要在敏捷生命周期的早期创建用户界面原型，这是一个迭代工作，可能需要几周甚至几个月的时间。但是，要认识到您对问题空间的理解仍然需要在整个项目中不断发展。
2. 你在做一个商业产品。很难获得对最终用户的常规访问，这增加了项目的风险。处理这种风险的一种方法是在生命周期的早期与潜在客户保持焦点小组，以便更好地理解他们的需求。由于持有焦点小组的费用，请记住，软件开发是一项经济活动，您的动机是尽可能少地持有。这反过来又促使您比通常情况下提前进行更多的需求建模。但是，这并不意味着您只需要预先执行此操作。明智的产品负责人/经理将与关键的终端用户/客户(或潜在客户)保持联系，并在整个项目中从他们那里获得反馈。
3. 您的治理框架是串行的。许多IT治理框架(尽管它们声称不知道流程)都包含一系列里程碑，这使得软件开发团队很难真正从敏捷方法中获益。好消息是，可以采用支持敏捷方法的精益治理。坏消息是，治理人员通常似乎具有命令和控制的文化心态，使得精益治理所提倡的协作方法对他们来说是一个陌生的概念。遗憾的是，在实践中似乎很难找到合适的IT治理。
4. 你在做系统工程。在系统工程项目中，使用硬件的限制，特别是在开发硬件的时候，会促使您提前进行更多的需求探索，因为如果您的硬件需求出现错误，那么在生命周期的后期修复这个问题的代价将非常昂贵。我强烈建议您阅读实时敏捷，如果您正在这个领域工作。
5. 你的合同要求这么做。许多IT项目涉及将工作外包给其他组织。尽管采用敏捷方法进行外包是可能的，但不幸的是，许多合同采购人员仍然没有理解敏捷，仍然采用串行方法进行开发。这意味着他们编写的契约通常需要使用BRUF方法，即使契约也可能指定开发团队采用敏捷方法进行开发。在这种情况下，我能给出的最好的建议就是尽你所能，与你的合同人员紧密合作，这样他们就能理解他们在合同中所写的含义。
6. 你的组织文化促进了它。许多人仍然在具有串行文化的组织中工作，其结果之一是开发团队将需要预先做太多的建模工作。解决办法是帮助改变文化，这说起来容易做起来难。

请认识到，在敏捷生命周期的早期，很少需要进行大量的需求建模，这些原因可能在不到10%的时间内适用。此外，请记住，与BRUF相关的风险不会在这些情况下消失——您所做的是接受一些风险来降低其他风险。它总是一个权衡的集合。

8. 人们真的在这么做吗?

是的!在我2007年3月的敏捷采用率调查中，我提出的一个问题是，最初的敏捷需求建模在敏捷团队中有多有效。结果如图10的直方图所示。正如你所看到的，敏捷者实际上在实践中做模型。78%的受访者说,他们的组织在做敏捷表示,那些团队也做最初的高级敏捷需求建模,和85%的团队发现的努力值得的(他们给它的评级3或更多的5)。同样的,2008年以电脑建模和文档的调查发现,素描是最常见的主要建模方法(参见图11)。2013年Ambysoft敏捷项目启动调查(直接调查了敏捷社区)发现，超过90%的受访者表示他们的敏捷团队进行了某种形式的预先需求建模。

图10。敏捷团队建模的采用率。

总之，在敏捷软件开发项目的开始阶段进行足够的初始高级需求建模。您不需要很多细节，也不需要很多文档，但是您需要对范围有一个初步的了解。通过对将要构建的内容构建一个初步的远景，并通过处理围绕成本和收益的基本业务问题，您将快速地将您的项目置于坚实的基础之上。

 

原文：http://agilemodeling.com/essays/initialRequirementsModeling.htm

本文：https://pub.intelligentx.net/agilemodeling-requirements-envisioning-agile-core-practice

讨论：请加入知识星球或者小红圈【首席架构师圈】

当我最初开始研究敏捷建模（AM）时，我想只关注有效建模的原则和实践，但很快发现这个范围还不够，我还需要考虑如何在创建时有效的问题。维护文档也是如此。一些敏捷模型将“演变”为官方系统文档，尽管绝大多数都不会，因此讨论如何敏捷这样做是相关的。本文探讨了IT组织内部文档的敏捷和精益理念。

在本文中，我将讨论以下主题：

• 关键点
• 模型，文档和源代码
• 为什么人们记录？
• 文档和项目成功之间的关系是什么？
• 模型什么时候成为永久性的？
• 与文档相关的问题是什么？
• 轻装旅行意味着什么？
• 什么时候文件敏捷？
• 你需要什么类型的文件？
• 敏捷专家是否真的在创建文档并且它有用吗？
• 什么时候应该创建文档？
• 什么时候应该更新文档？
• 有效的交接
• 模板有帮助吗？
• 如何减少文档CRUFT？
• 文档何时是最佳选择？
• 提高文档敏捷性的最佳实践

1.关键点

 

1. 根本问题是沟通，而不是文件。
2. 如果这是实现相关目标的最佳方式，敏捷专家会编写文档，但通常证明比编写静态文档更好的方法来实现这些目标。
3. 记录稳定的东西，而不是投机的东西。
4. 采用渐进的方法进行文档编制，寻求并定期对反馈采取行动。
5. 优先考虑可执行的工作产品，例如客户测试和开发人员测试，而不是静态工作产品，例如普通旧文档（POD）。
6. 您应该了解文档的总体拥有成本（TCO），并且必须明确选择进行该投资。
7. 编写良好的文档可以有效地支持组织内存，但在项目期间进行通信的方式很差。
8. 文档应简明扼要：概述/路线图通常比详细文档更受欢迎。
9. 通过高质量的源代码和备份测试套件，您需要的系统文档要少得多。
10. 尽可能轻装上阵
11. 文档应该刚刚好。
12. 综合文档并不能确保项目成功，事实上，它会增加失败的可能性。
13. 模型不一定是文档，文档不一定是模型。
14. 文档与源代码一样是系统的一部分。
15. 您的团队的主要目标是开发软件，其次要目标是实现您的下一步工作。
16. 拥有文档的好处必须大于创建和维护文档的成本。
17. 开发人员很少信任文档，特别是详细的文档，因为它通常与代码不同步。
18. 每个系统都有自己独特的文档需求，一个大小并不适合所有。
19. 询问您是否需要文档，而不是您是否想要它。
20. 对系统文档的投资是业务决策，而不是技术决策。
21. 只有在生命周期中的适当位置需要时才创建文档。
22. 仅在受伤时更新文档。

2.模型，文档和源代码

让我们首先理解模型，文档，源代码和文档之间的关系，如图1所示。从AM的角度来看，文档是源代码外部的任何工件，其目的是以持久的方式传递信息。这与模型的概念不同，模型是描述问题的一个或多个方面或解决问题的潜在解决方案的抽象。有些模型将成为文档，或作为其中的一部分包含在内，尽管在完成其目的后，更多的模型将被丢弃。一些模型将用于推动源代码的开发，尽管某些模型可能仅仅用于推动其他模型的开发。源代码是一系列指令，包括描述这些指令的注释，用于计算机系统。虽然源代码显然是一个抽象，尽管是一个详细的抽象，但在AM的范围内，它不会被视为模型，因为我想区分这两个概念。此外，为了便于讨论，术语文档包括源代码中的文档和注释。

敏捷建模

图1.模型，文档，源代码和文档之间的关系。

3.为什么人们会记录？

敏捷开发人员认识到文档是任何系统的固有部分，其创建和维护对某些人来说是“必要的邪恶”，对于其他人来说是一项令人愉快的任务，软件开发的一个方面可以在您选择这样做时变得敏捷。 。创建文档有几个正当理由：

1. 您的项目利益相关者需要它创建文档基本上是一项业务决策，您正在将项目利益相关者的资源投入到文档的开发中，因此他们应该最终决定他们的资金是用这种方式而不是技术方式。如果您的项目利益相关者可能会根据您的建议请求您提供的文档，并了解所涉及的权衡（稍后将详细介绍），那么您必须创建该文档。值得注意的是，eXtreme Programming（XP）非常明确地将文档作为业务决策。您应该只在项目利益相关者要求时创建文档？你说的荒谬！嗯，我的经验是，这不是荒谬的。您的项目利益相关者包括各种各样的人，包括您系统的所有客户，因此他们应该有一个相当不错的想法。维护开发人员或代表他们的人（如果他们尚未到位）将请求系统概述文档。用户及其管理层可能会要求用户提供文档。操作人员将要求操作文档。是的，您需要与他们密切合作以确定他们实际需要什么，有人将不得不决定为文档的开发和后续维护付费，您甚至可能需要解释所请求内容的含义，但这是可行的。
2. 定义合同模型。合同模型定义了您的系统和外部系统如何相互交互，一些交互是双向的，而另一些是单向的，使得交互明确地涉及到每个人。当外部组控制系统所需的信息资源（例如数据库，遗留应用程序或信息服务）时，通常需要合同模型。 AM实践正式化合同模型表明，合同模型是双方应在必要时双方同意，记录和变更的内容。重要的是要理解合同模型的开发仍应由您的项目利益相关者进行验证 - 这是您花费的资金，如果他们选择冒险并且没有合同模型，那么这就是他们的选择。
3. 支持与外部组的通信。并不总是能够共同定位开发团队，并且总是不可能让项目利益相关者（或者至少是当时需要的人）可用。当您需要与外部人员一起工作时，您需要找到与他们沟通的方式，共享文档通常是解决方案的一部分，并与偶尔的面对面讨论，电话会议，电子邮件和协作工具相结合。使用文档作为主要的沟通方式是错误的，因为它很容易误解已编写的内容，但它是一种很好的支持机制。在这种情况下考虑文档的好方法是，它是您最后的选择。请注意，这实际上是将模型传达到文档领域的扩展。
4. 支持组织记忆。敏捷建模的原则之一是启用下一个努力是您的次要目标，这意味着作为主要目标的原则工作软件的平衡。一个重要的含义是我们不仅需要开发软件，而且我们还需要开发随着时间的推移使用，操作，支持和维护软件所需的支持文档。
5. 用于审计目的。我曾在我们开发生命关键系统的组织工作，这些系统属于美国食品和药物管理局（FDA）审计指南的主持。我还曾在Sarbanes-Oxley（SOX或Sarbox）和/或BASEL-II适用的组织工作过。共同的主题是我们必须遵循已定义的流程并捕获我们这样做的证据，从而产生比我们通常编写的更多的文档。在这些情况下，您仍然希望创建足够的文档来完成工作。我看到的一个常见错误就是官僚们跳过“我们可能会被某某人审核，因此我们需要制作以下文件......”。我的建议是自己阅读适当的指导原则，因为它们很少需要官僚认为需要的指导原则。善于遵守法规。
6. 想清楚某事。许多人编写文档，要么是为了亲自验证他们刚刚参与的一些团队工作，要么只是为了增加自己的理解。写作的过程，把你的想法写在纸上，可以帮助你巩固它们，发现你思维中的问题。一旦你试图详细地描述它，你脑海中出现的清晰而直接的东西往往会被证明是非常复杂的，而且你通常可以从先把它写下来中获益。正是出于这个原因，我建议人们在编写代码之前先写注释，这是我多年来一直遵循的做法。

您的涉众必须理解文档的总体拥有成本(TCO)，并且您的涉众必须明确决定对该文档进行投资。

 

这很可能与您以前的做法不同，这是有道理的，因为我在谈论如何在您的文档方法中变得更加敏捷。为什么这会有所不同，为什么它更敏捷？我的经验是，非敏捷环境中的开发人员往往被迫以不太理想的理由创建文档，通常基于政治原因，有时由于纯粹的无知，因此可能不会被允许尽可能有效。能够。创建文档以及如何打击文档的可疑原因包括：

1. 希望看到请求者处于控制之中。人们将要求他们签署的文件，例如规范和详细的架构文档，并说“是的，继续并为我们建立其中一个。”每当我发现自己处于这种情况时，我会要求提供文件的个人是否也希望被视为对项目失败负责，因为开发团队太忙于关注不必要的文档而不是构建软件。然后，我建议他们不应该请求文档，而应该请求访问软件本身，即使它只是软件的内部版本，因​​此他们可以提供有关它的建设性反馈。他们仍然可以被视为项目的积极参与者，并且可以以富有成效的方式这样做。
2. 请求者错误地认为文档与项目成功有关。没有东西会离事实很远。
3. 请求者想证明他们存在的合理性。这种情况通常发生在那些“死木”的人迫切希望看到做某事的时候。这是一个阴险的问题，因为请求者通常表面上看起来是请求文档的一个很好的理由，这是他们多年来一直在做的事情，管理层通常认为这是必要的。为了解决这个问题，我会问请求者他们打算对文档做什么，他们为什么需要它，为什么为他们创建文档比我的团队需要做的其他工作更重要，等等，试图确定实际他们正在做的事情的价值。这些是有待提出的有效问题，虽然对于那些对开发工作没有太大价值的人来说是不舒服的。
4. 请求者不知道更好。许多人一直在多年来一直关注非敏捷流程的组织中工作，可能以文档为中心的流程，在整个流程中生成大量文档以供审阅的流程，最后是软件。这是他们习惯的，所以他们只是在问你过去曾经得过的东西。您可以在项目早期生成软件的想法，这是您的主要目标，对许多人来说是新的，而且往往是激进的。
5. 您的流程说创建文档。虽然这不是敏捷软件过程的问题，但它肯定可以与规范的软件过程一起使用。造成这一问题的最常见原因包括人们想要证明其存在（见上文），人们不了解软件开发过程或至少是他们所要求的含义，以及主要目标是花费数小时反对的情况有效地开发软件。再一次，解决这个问题的最佳策略是探索文档的创建是否真正为您的工作提供了价值。
6. 有人想要保证一切都好。您的项目利益相关者正在为您的项目团队投入大量资源，他们会对您承担风险，并且他们希望知道他们的投资得到了充分利用。为了得到这种保证，他们可能会要求您提供文档，状态报告或概述文档，而不是理解您需要花时间远离您开发软件的真正目标，而不是意识到更好的请求是查看软件本身（如前所述，他们不知道更好）。您需要认识到您的项目利益相关者何时寻求保证，如果他们不信任您的团队，则在项目开始时常见，并找到提供该保证的替代方法。
7. 您正在为另一个组指定工作。虽然我已经将这种情况确定为AM可能不合适的情况，但它仍然是证明创建大量文档的合理证据。文档是一种沟通方式，但它不是最好的方式。尝试寻找替代方法，例如偶尔与其他小组会面或使用协作工具，以减少对文档的依赖。
8. 您的开发合同通常会重新竞争。这个问题在为政府机构工作的公司中普遍存在，尽管如果他们不履行，企业通常会威胁他们的承包商再次投标。所以呢？如果您的主要目标是开发软件，那么请专注于这样做，并且您更有可能充分履行合同。在这种情况下，直接客户经常在误导的情况下运作，即如果您不执行，他们可以将您生成的文档提供给下一个将从那里开始的承包商。在我看来，这与妄想有关。如果你做的那么糟糕，以至于你失去了合同的机会非常好，你也做了不好的文件，因此下一个承包商将需要重做它。即使您已经完成了文档的完美工作，但仍然失去了合同，下一个承包商很可能会拥有不同技能和足够时间的人，他们无论如何都需要重新审视这些要求。无论你怎么看，下一个承包商都不太可能利用你制作的文档。

我不相信圣诞老人，也不相信程序员会保持最新的外部文档。四十年的经验表明，这种特殊的教条充其量只是幻想。

4.文档与项目成功之间的关系是什么？

项目成功与编写综合文档之间没有牢固的关系，事实上，您编写的文档越多，项目失败的可能性就越大。您是否曾见过项目团队撰写全面的需求文档，让您的利益相关者签署该文档，只是让开发人员构建其他内容？或者团队实际建立规范，只是让你的利益相关者说这不是他们想要的？或者团队提供延迟或超预算，即使项目的大部分内容都很好看？你有没有见过一个团队创建一个全面的架构模型，让它被真正聪明的人审查和接受，只是看到架构在实践中失败了？或者开发人员只是忽略模型，然后以他们想要的方式构建它？您是否已经在管理层监督的幌子下看到了所有这一切，没有管理层意识到发生了什么直到它发生很久？图2取自我的文章“检查前线的大要求（BRUF）方法”，它探讨了写作的有效性项目生命周期早期的详细需求规范。正如您所看到的，似乎传统的需求方法似乎会使您的项目面临风险，至少在考虑投资回报率（ROI）的情况下。

敏捷文档

图2：串行方法对需求的有效性。

 

为什么人们错误地认为文档是软件开发的关键成功因素？我的理论是，在20世纪70年代和80年代，许多组织将他们的IT部门从“代码和修复”黑客心态转移到文档密集的串行瀑布流程。当他们这样做时，他们的成功率实际上提高了我们今天甚至用CMM / CMMI看到了这一点 - 当您从代码移动并将CMM（I）级别1修改为级别2或3时，即使您添加了更多文档开发，您实际上也看到了生产力的提高到你的过程。他们“学会”文档改进了软件开发工作，并对答案感到满意。那真是太不幸了。

CMM（I）的支持者，或其他不可避免地最终导致文档沉重的策略似乎从未提出过是否有更好的工作方式的问题。不会把精力集中在编写高质量的软件（例如测试驱动的开发实际上产生可执行的规范）上提供比编写文档更大的回报吗？难道找不到保持高质量代码（例如重构）的方法比编写文档提供更大的回报吗？文档的真正价值不在于增加对问题域的理解，还是在架构/设计的情况下增加对解决方案域的理解，而不是文档本身？如果是这样，也许只关注建模工作（例如敏捷模型驱动开发）而不是编写文档是一个更好的策略？

5.模型何时成为永久性的？

从表面上看，敏捷模型的生命周期非常简单 - 图3描绘了模型的高级UML状态机器图。模型将从一个想法开始 - “我们需要了解我们将如何构建这个”，“用户如何希望这样做”，或者“我们需要展示我们将要提供的内容” - 你要么选择建模要么放弃（为了我们的讨论，你选择执行的任何活动而不是建模都算作放弃）。该模型开始是暂时的，一旦它实现了它的直接目的，你打算抛弃它，这是敏捷开发人员创建的绝大多数模型的典型命运。这些模型通常是手绘草图，一旦将想法传达给目标受众，就会丢弃这些草图。您可以根据需要自然更新临时模型，经常创建它们，处理它们，然后在短时间内丢弃它们：许多敏捷模型在几分钟内创建为两三个人，以促进他们的讨论，而其他敏捷模型是在几个小时的时间内在几个人的建模会话中创建的。图3中描述的有趣转换是当您决定保留一个临时模型，使其永久化时，使其成为项目团队的官方文档之一。当满足以下所有条件时，临时模型将成为“守护者”：

1. 将其永久化是一个明确而有价值的理由。
2. 有模型提供价值的观众。
3. 您的项目利益相关者愿意投入将其纳入文档。

图3.敏捷模型的生命周期。

点＃1和＃2由原则模型驱动有目的：您应该有一个有效的理由来创建模型，但您的文档也应该有明确的目的。您应该知道您为谁创建文档 - 可能是您的开发团队的子组，您的用户，或者在您发布系统后将维护和操作系统的团队 - 以及他们从该文档中需要的内容。基本思想是文档的创建和维护是开发团队的负担，如果您想增加某人的负担，您应该能够证明原因。这很简单。文档是一种负担，当人们认识到这个简单的事实时，他们会把自己放在一个明显更好的位置来适当地考虑它。是的，有效的文档可以为您的项目团队和项目利益相关者带来显着的好处，并且最大化利益相关者ROI的原则告诉您，好处应该超过团队负担的增加。重要的是要注意，除了经历成本的人之外，其他人有时会收到这些好处，例如，您的开发团队会受到维护开发人员受益的创建系统文档的成本的影响。这意味着，当您考虑文档的成本和收益时，您需要查看整个图片，其权衡取决于与文档相关的问题是什么？部分。第3点也是由最大化利益相关者投资回报率的原则和这样一个概念所驱动的，因为正是您所投资的项目利益相关者的资源应该是指导这些资源投资的方式，无论好坏。

正如您在图3中看到的那样，您可以重新考虑关于使模型永久化的决定，通常是因为您意识到模型提供的好处远远低于维护模型的负担。当这种情况发生时，模型要么被彻底丢弃，要么更常见的是该模型的所有者只是停止更新它并开始“聚集尘埃”。有时，如果系统被重写，开发团队，维护团队或“重新开发团队”会在数月或数年后恢复这些模型。这些停滞的模型经常被审查，被认为是显着过时的，然后被丢弃或用作模板，从中创建模型的新版本。理想情况下，这个新版本比原始版本更精简，因为如果原始模型没有为您的工作提供正面价值，那么遵循相同方法的更新版本可能也不会提供价值。在提高文档敏捷性的策略部分中讨论了这样做的技巧。

6.与文档相关的问题是什么？

敏捷开发人员认识到有效的文档是一种平衡行为，目标是在恰当的时间为恰当的受众提供足够的文档。为此，您必须解决以下问题：

1. 软件开发与文档开发。这是您需要解决的基本问题 - 创建文档所花费的时间是花费时间而不是为用户开发新功能。一方面是没有编写任何文档的项目，而另一方面根本没有编写任何软件，也没有极端可能适合您的情况。请记住，您的主要目标是制作可运行的软件 - 您希望支持您的用户业务活动，您希望为您的组织创造收入，您希望收到有关您工作的反馈，您希望向您的用户证明您可以生产 - 但是你需要用你的次要目标来抵消这一点，这是为了实现下一步的努力。因此，您仍然需要编写一些文档（用户手册，操作手册，系统概述......）。
2. 可执行规范提供的价值远远超过静态文档。可执行规范，例如指定大部分需求的客户测试套件，或指定详细设计的开发人员测试套件，为开发人员提供了重要价值，因为他们不仅指定了您的系统，还有助于验证它。由于这些工件增加了价值，因此开发人员保持最新状态的可能性要大得多。是的，您仍然需要一些静态文档，因为测试肯定不能满足您的整个文档需求，但您可以在哪里开发可执行的规范。
3. 软件开发人员有知识，技术作家有技能。喜欢与否，很少有技术人员具有良好的写作技巧，只是因为他们没有花时间去获得他们的简单原因。问题是，适合编写文档的最佳人选是知道正在编写的主题的人，在本例中是系统的开发人员。许多团队只需将系统或其中的一部分交给技术作家，并要求他们“弄清楚”。这样做的好处是可以最大限度地减少开发人员的工作量，但会增加技术作者所需的工作量并增加他们弄错的可能性。更好的方法是让开发人员编写初始版本的文档，然后将其交给技术作者进行清理。这样做的好处是它可能更有效，开发人员进行“知识转储”，技术作者重构材料以有效地呈现它，但缺点是开发人员可能不知道如何开始甚至写什么关于。第三种方法，在我看来最好的方法是让技术作者和开发人员一起编写文档，在他们这样做时相互学习。
4. 开发过程中所需要的通常与开发后所需的不同。在开发过程中，您有不同于开发后的需求 - 为了讨论开发后的活动，包括将发布版本转换为生产版本以及发布版本投入生产时的过渡期和生产阶段。企业统一流程。在开发过程中，您正在探索问题和解决方案空间，尝试了解您需要构建什么以及如何协同工作。在开发后，您希望了解构建的内容，为何以这种方式构建，以及如何操作它。此外，在开发过程中，您更愿意容忍粗略的草稿，草图和更大的不一致 - 毕竟这是您自己的工作 - 而在开发后您通常需要更正式的文档。最后，在开发过程中，您可能需要更少的文档，您更喜欢轻松旅行，而不是在开发后期间。
5. 你在工作或完成时记录了吗？一个极端是与开发软件并行编写所有文档。优点是您在进步时捕获相关信息，但缺点是随着软件的发展，在重构时，您还需要重新编写文档。这不仅会降低您的开发工作速度，还会导致浪费精力 - 您昨天编写的文档需要在今天重写或丢弃，实际上这种方法不再适用于您。当您的需求尚未稳定时，当您采用迭代方法进行开发时，过多的文档可能会变得非常昂贵，因为您不断更新它以反映更改。另一个极端是等到你完成然后编写文档，主要的好处是你正在写一个已知的和稳定的东西（你刚刚构建的软件的发布）。这种方法显然有几个缺点。您可能已经忘记了您做出的决定背后的一些原因，您可能没有合适的人来编写文档，您可能没有资金来完成工作，或者编写文档的意愿可能不再存在。一个有效的中间立场是在整个项目稳定时捕获信息。
6. 你能等到信息稳定下来吗？如果您编写的文档包含尚未稳定的信息，那么一旦信息发生变化，您就有可能需要重新编写文档。换句话说，您不希望投入大量时间来记录项目早期的需求或设计等推测性想法。相反，等到生命周期的后期，当信息稳定并且您知道哪些信息对您有用时。这意味着您的文档工作可能会在您的软件开发工作背后进行一些迭代。
7. 代码文档与外部文档。您是否将所有文档放在代码中，是否编写了“自我记录”代码，或者将所有文档放在外部工件中？再次，你需要找到一个有效的中间立场。当您的受众是开发人员时，放置大部分文档的最佳位置是源代码。是的，您可能还需要一个针对该组的系统概述文档，但实际情况是这些人不会信任，更不用说阅读代码之外的文档 - 如果他们真的很聪明他们就不会信任代码中的文档。但是，文档的受众比开发人员要广泛得多。您可能需要为无法访问源代码的人员编写文档，或者至少无法理解它，例如用户，高级管理人员和操作人员。这些受众需要编写外部文档以满足其确切需求。 AM实践单一来源信息表明，您努力在尽可能最好的地方捕获一次信息。这通常在源代码或验收测试中。简而言之，努力使用尽可能最好的方法捕获和传递信息。
8. 项目级与企业级文档。并非您编写的所有文档都将专门针对您的项目团队，或者是团队接管您的系统，其中一些可能需要在企业级别提供。您应该利用现有工件，包括但不限于组织内的系统文档和模型。这可能包括业务规则的现有定义，遗留系统的现有接口及其文档（有效的现有合同模型），描述整个公司数据资源的企业元数据存储库或企业业务模型。这些资源来自哪里？源信息来自其他项目团队，例如您的项目团队，可能由专家团队管理。是的，这显然是一种可能会促使不必要的官僚机构仍然可能变得敏捷的情况 - 集中管理团队需要找到一种有效地与您合作的方式。在开发过程中，他们应该提供您需要的现有模型和元数据等资源，并在需要帮助理解和使用这些资源时充当顾问。开发后，它们应该帮助您捕获相关信息以反馈到共享企业资源中，例如，将系统转换为生产的过程的一部分可能是确保对公司业务规则和元数据存储库进行更新。集中管理团队需要以客户为中心，真正实现敏捷，必须为他们的工作提供真正的商业价值，并积极努力了解他们管理的资源如何以及为何被客户使用。
9. 数量与质量。基本的权衡是让文件违背你对其准确性的信任的“安全性”。您更愿意拥有2000页的系统文档，其中可能存在大量错误，但重要细节还是20页的高级概述？大文档很可能拥有维护和增强系统所需的大部分信息，但您是否相信其中包含的信息？较短的文档很可能不会包含您需要的详细信息，但它会提供您可以深入了解源代码或其他文档的地图，以获取详细信息。您更有可能信任这个文档，因为它更短，最糟糕的情况是您可以轻松更新或只是重写它，如果您发现它非常不准确，并且因为它处理高级概念，如您的系统架构将改变比较大的文件中包含的详细细节更慢。重要的是要理解我并不是说较大的文档质量自动低于较短的文档，但我说它很可能被认为是这样，直到证明不是这样。

记录稳定的东西，

不是投机的东西。

7.旅行灯意味着什么？

人们对旅行灯概念的最大误解之一就是它意味着你不会创造任何文件。现实是，没有什么能比真相更进一步。至少在上下文中，行车灯的意思是，您可以创建足够的模型和足够的文档来获取。在极少数情况下，这可能意味着您无需创建任何模型，可能是在一个非常小的项目上，甚至是没有文档，也许是在一个非常小的项目上。但是对于绝大多数项目，您需要创建一些模型和一些文档。

你怎么能确保自己轻装上阵？一个好的经验法则是你不应该在你真正需要它之前创建一个模型或文档 - 过早创建任何一个东西会让你有浪费时间去做你实际上不需要的东西的风险。我曾经在一个商业软件系统上工作，一个组织可以购买和安装开箱即用，或者更典型的是购买，然后让我工作的公司修改它以满足他们的确切需求。有一天，我们的销售人员在一家想要我们系统的公司上取得了新的领先优势，但这家公司还处于一个我们还没有经验的新领域。我们认为我们将要进行此次销售，我们最终确实得到了它，所以在我们自己与客户见面之前，其他几个人开始对我们认为需要做出的预期变化进行建模。经过几天的建模会议，我们得出的结论是变化很容易，毕竟我们的系统很棒，而且我们支持这个新客户端也没有问题。然后我们与他们交谈。在我们发现的七十多个新要求中，我们已经得到了大约一半的正确，不错，考虑到我们不知道我们在谈论什么，但我们已经错过了其他几百个。当然，我们基于我们错误要求的模型价值不大，我们不得不抛弃它们并重新开始，因为我们需要将我们的思维方式从我们原来的方法转移开来。更糟糕的是，我们以骄傲的态度参加了第一次会议，因为我们认为我们知道这一切，如果不是因为我们的销售人员的花哨操作，这种态度会让我们失去客户。最重要的是，我们在创建模型时并不需要模型，而是在与客户交谈并确保销售后，我们应该等待创建模型。

另一个例子是，RUP建议您创建一个软件体系结构描述（SAD）文档来定义您的体系结构。是的，定义您的系统架构是非常好的事情，正如我在敏捷架构中讨论的那样，但您是否需要在项目早期创建文档？有时是，有时没有。几年前，我在一个关键任务系统上工作，我们在一个普通的旧白板（POW）上开发了我们的架构模型，我们遵循公开展示模型，作为自由格式图的集合。因为这个过程告诉我们创建一个SAD，所以我们这样做了，尽管大多数开发人员都使用白板草图。因为RUP产品为SAD提供了相当不错的Microsoft Word模板，所以我们使用它作为工作的基础。一些开发人员从SAD文档打印出图表，我们已将我们的草图转录到Microsoft Visio中，以便粘贴到他们的隔间墙上，因为他们无法轻易地看到他们坐在哪里的图表。每次白板草图发生充分变化时，我们都必须更新图表的电子版本以及SAD文档中的相应部分。获得SAD文档的好处在于它提供了我们正在构建的内容的描述，这是我们分发给管理层的文档，并且可供组织内任何感兴趣的人使用。据我所知，缺点是没有人有效地使用SAD文件。我不确定经理们是否曾经看过它，如果他们这样做，那最多只是粗略的检查，因为我们从未收到任何来自他们的反馈。需要图表副本的开发人员可以轻松地拍摄草图的数字快照，或者创建共享的架构网页，或者只是打印出来。这也可能是一个SAD文档，尽管形式不同，根据原则内容比表示更重要，因为它仍然会描述我们的架构（这是SAD文档的基本目的）。同样的推理我们的白板草图也是一个SAD文档，虽然一个不是永久性的，一个固定在永久位置的。在我看来，我们犯了三个基本错误，因此比我们需要的更重：我们选择了错误的文档格式，我们过早记录，并且我们创建了太多的文档。将SAD作为Word文档维护的额外开销减缓了我们的速度，因为我们在多个位置实际拥有了这些信息 - 我们正在处理的白板，几乎是多余的Word文档，以及我们的代码本身。此外，我们本来可以开发软件而不是文档，更糟糕的是更新工作占用了我们的一位高级开发人员的大部分时间，所以他无法帮助指导和指导初级开发人员。当然，在项目结束时将此文档作为我们向维护团队提供的可交付成果之一是有用的，但我们在开发过程中肯定不需要它，这显然对项目团队造成了更大的伤害。

旅行灯需要你思考你在做什么。在项目开始时，根据项目的性质，问问自己您认为自己需要什么。与静态HTML页面制作的网站开发相比，开发空中交通管制系统可能需要更多的文档。随着项目的进展，您会发现您对文档的初始估计需要根据经验进行更改，或许您需要更多或更少。 Highsmith喜欢使用徒步旅行的类比，他是登山者 - 包装太轻或太重都会导致灾难，最糟糕的是它会杀死你，最多会迫使你回头重新思考你的策略。想象一下，穿越沙漠的水不足，你旅行太轻，或者试图穿过绑在背上的100磅重的沙漠，现在你旅行太重了。现在想象一下，构建一个关键任务电子商务应用程序而不提供任何描述如何操作它的文档，您的项目实际上会失败，因为您的行程太轻了。现在想象一下，构建包含数千页文档的相同系统，每次更改系统时都必须更新和验证，然后再次失败，因为您的行程非常繁重，无法快速响应市场变化。行车灯意味着足够的模型和文档，太少或太多会让您处于危险之中。

8.什么是文档敏捷？

无论有些人会告诉你什么，文档实际上可以非常有效。什么时候文件敏捷？满足以下条件时：

1. 敏捷文档最大化利益相关者的ROI。敏捷文档提供的好处大于其创建和维护的投资，理想情况下，该文档中的投资是这些资源的最佳选择。换句话说，文档必须至少提供正值，并且理想情况下提供最佳价值。例如，如果创建用户文档提供50％的投资回报，但为用户提供培训课程可提供100％的回报，那么您最好选择培训，因为这是一项更好的投资。
2. 利益相关者知道文件的总体拥有成本。利益相关者必须了解文档的总体拥有成本（TCO），并愿意投资于该文档的创建和维护。
3. 敏捷文档“精益充沛”。敏捷文档包含足够的信息来实现其目的，换句话说，它尽可能简单。例如，敏捷文档的某些部分可以用点式而不是散文来编写 - 您仍然可以捕获关键信息而无需花费时间使其看起来漂亮，这符合内容比表示更重要的原则。敏捷文档通常会提供对其他信息源的引用，例如，描述外部系统接口的合同模型可能表明正在使用SOAP 1.1协议，并提供对定义XML文档的XML DTD和模式定义的引用在系统之间传输。编写敏捷文档时，请记住Assume Simplicity的原则，即最简单的文档就足够了，并尽可能遵循“创建简单内容”的做法。
4. 敏捷文档实现了目的。敏捷文档具有凝聚力，它们实现了一个明确的目的。如果您不知道创建文档的原因，或者创建文档的目的是否有问题（参见前面的内容），那么您应该停下来重新考虑您正在做什么。
5. 敏捷文档描述了“要知道的好事”。敏捷文档捕获关键信息，不易明显的信息，如设计原理，要求，使用程序或操作程序。敏捷文档不会捕获明显的信息。例如，指示CUSTOMER表的F_NAME列捕获客户名字的文档确实没有为我提供很多价值。指示客户表不包含居住在加拿大育空地区的客户的数据的文档，因为监管原因该数据存储在另一个系统上的ASCII平面文件中，这可能是很好的信息。
6. 敏捷文档具有特定客户并促进该客户的工作。系统文档通常是为维护开发人员编写的，提供了系统体系结构的概述，并可能总结了关键需求和设计决策。用户文档通常包括使用用户理解的语言编写的系统的教程，而操作文档描述如何运行系统，并使用操作人员可以理解的语言编写。不同的客户，不同类型的文件，以及很可能不同的写作风格。如果您想要创建实际满足其需求的东西，您必须与客户或潜在客户密切合作以获取文档。例如，我会谨慎地为维护开发人员编写系统文档而不涉及其中的一些工作。是的，有时您无法让这些人参与进来（您目前可能没有工作人员），或者您可能无法确定维护组织中谁将成为您系统的最终“所有者”。当您没有涉及客户时，您将面临创建过多文档或不必要的文档的风险，从而变得不那么灵活。您经常会发现，当您让客户参与时，他们通常非常了解他们实际需要什么，并且经常可以提供适合他们和不适合的示例。
7. 敏捷文档足够准确，一致且详细。您是否曾使用过描述该软件以前版本的书籍来学习如何使用新软件？你成功了吗？有可能。这是一个完美的情况吗？可能不是。它是否涵盖了该软件的所有新功能？当然不是，但它仍然让你运行软件包。您是否愿意花30美元购买最新版本的书？可能不是，因为它不值得你。敏捷文档不需要是完美的，它们只需要足够好。

但是，说了这些之后，您需要采取敏捷文档需要足够好的建议。如果您正在编写核电站软件系统的操作手册，那么我强烈建议您做对！但是，很少有系统真的那么重要，因此投入所需的努力来完善文档是不合适的。在编写文档时，您需要进行判断调用，关键问题是确定文档客户可以接受多少模糊性并且仍然可以有效地完成工作。

9.您应该创建哪些类型的文档？

您需要在项目中创建文档，即使是最“极端”的XP项目也是如此，更不用说RUP项目了。 但是您可能需要创建哪些类型的文档？ 表1列出了您可能决定在开发工作中创建的一些最常见的文档，这些文档将作为整个系统的一部分提供。 表1不包括管理工件，例如项目进度表，软件可交付成果（如源代码和测试套件）或临时工作产品（如临时模型）。

表1.开发团队要创建的潜在文档。

Potential Document	Audience	Description	Advice	Valuable Deliverable?
Contract models	Other Teams	A document describing the technical interface to a system or portion of a system.	See Introduction to Contract Models	Yes
Design decisions	Developers, Maintenance Developers, Project Managers	A summary of critical decisions pertaining to design and architecture that the team made throughout development	Question the need for most of this information. Are people really going to care several years from now why you did something? Focus on decisions that are not obvious, which had other reasonable alternatives, or ones where you explored what initially looked like a reasonable alternative that in the end proved insufficient for your needs. The goal of this effort is to avoid needless refactoring at some point in the future or rehashing a previously made decision. Design decisions are often documented throughout other artifacts, such as system overviews and source code, although you may choose to have a separate document when appropriate to the situation.	Perhaps
Executive Overview/Vision Statement	Senior Management, User Management, Project Management	A definition of the vision for the system and a summary of the current cost estimates, predicted benefits, risks, staffing estimates, and scheduled milestones. Advanced: Consider including listing of major stakeholder groups, their representatives (if any), and their primary goals.	This document is typically used to gain funding and support for your project as well as provide status updates to important project stakeholders who may not be actively involved with your project on a day-to-day basis. Keep it short, ideally a few pages, and consider writing it in point form. Have the courage to make this publicly available to everyone that should have access to it, even when it contains bad news, according to the principle Open and Honest Communication.	Valuable interim document
Operations documentation	Operations Staff	This documentation typically includes an indication of the dependencies that your system is involved with; the nature of its interaction with other systems, databases, and files; references to backup procedures; a list of contact points for your system and how to reach them; a summary of the availability/reliability requirements for your system; an indication of the expected load profile of your system; and troubleshooting guidelines.	Your operations department often has a standard format for this type of documentation or at least may have good examples from other systems that they can provide you to base your document(s) on.	Yes
Project overview	Developers, Managers, Maintenance Developers, Operations Staff	A summary of critical information such as the vision for the system, primary user contacts, technologies and tools used to build the system, and the critical operating processes (some applicable to development, such as how to build the system and some applicable to production, such as how to back up data storage). Also provides references to critical project artifacts such as the source code (the project name in the source code control system is often sufficient), where the permanent models pertaining to the system (if any) are, and where other documents (if any) are.	I typically create and maintain this document during development. Keep it short and to the point, I don't ever remember one getting beyond ten printed pages and most are less than five.   This document serves as a starting point for anyone new to the team, including maintenance developers, because it answers fundamental questions that they are likely to have. Whenever you first share this document with anyone ask them to keep track of major issues that they were not able to easily resolve using this document, or any misinformation they discover, to provide insight into potential updates for the document. I often call this a "Good Things to Know" document.	Yes
Requirements document	Developers, Maintenance Developers,Users, User Managers	This document defines what the system does, summarizing or composed of requirements artifacts such as business rule definitions, use cases, user stories, or essential user interface prototypes (to name a few).	Writing a requirements specification early in the life cycle should be seen as a very large risk. XP projects typically favor inclusive requirements techniques such as user stories and CRC cards. RUP projects tend towards more formal requirements artifacts and documentation. Disciplined agile teams capture the majority of their requirements as executable specifications. As a result these teams only need brief overviews of the scope which would be part of the system documentation.	In scaling situations, particularly when regulatory compliance, large teams, or geographically distributed teams are an issue
Support documentation	Support Staff	This documentation includes training materials specific to support staff; all user documentation to use as reference when solving problems; a trouble-shooting guide; escalation procedures for handling difficult problems; and a list of contact points within the maintenance team.	You will find that your support department often has a standard escalation procedure in place, therefore you will not need to write one, and like the operations department may have standard templates or examples that you can work from.	Yes
System documentation	Maintenance Developers, Developers	The purpose of this document is to provide an overview of the system and to help people understand the system.Common information in this document includes an overview of the technical architecture, the business architecture, and the high-level requirements for the system. Detailed architecture and design models, or references to them, may also be included where appropriate.	System documentation helps to reduce perceived risk on the project by providing "truck insurance", the assurance that if the development team leaves, or gets hit by a truck[1], that critical information about the project is left behind. Unfortunately this is typically false insurance-if you lose someone(s) then no matter how good the documentation is you have a serious problem on your hands because new people still need to be identified, assigned to your system, and need to learn the system. You're much better off increasing your project's "truck number", the minimum number of people that if you lost them would put your project at risk, by supporting knowledge sharing practices such as Active Stakeholder Participation, Collective Ownership, and Model With Others.	Yes
User documentation	Users, User Managers	Your users may require a reference manual, a usage guide, a support guide, and even training materials. It's important that you distinguish between these different types of documents because the way that each one is used varies: one is for quick lookups, one is for discovering about how to work with the system, one is for how to obtain additional help, and one is for training.	.I typically base my usage guide and training materials on the use cases for the system -the use cases describe how the actors work with the system, therefore they should be a very good foundation on which to base both of these documents. .User documentation should be considered part of the user interface for your system and therefore should undergo usability testing.	Yes

观察：有时不敏捷能够实现敏捷。敏捷软件开发对许多组织来说都是新的，因此对其可行性存在极大的恐惧和不确定性，虽然有时令人沮丧但这实际上是一件好事，因为这意味着人们关心。由于这种担心，您的项目利益相关者可能会要求您创建无关的文档以帮助他们放心，特别是对于过去可能被其他新技术和技术焚烧的高级管理人员而言。通常，单个文档的创建（可能是执行概述）将为您的项目利益相关者提供足够的关于项目的“温暖和模糊的感觉”，以允许您以您选择的方式工作（例如以敏捷方式）。

10. Agilists是否真的创建文档并且它是否有用？

问题第一部分的答案肯定是肯定的。 DDJ的2008年建模和文档调查发现，敏捷团队与传统团队一样可以编写可交付文档，如用户手册，操作文档等。图4总结了与可交付文档有关的调查结果。重要的是，这项调查应该有助于浪费人们在敏捷软件开发和文档方面遇到的一些误解。

图4.可交付文档创建。

问题的第二部分的答案可能是。 在DDJ 2009年9月的IT联盟状态中，我们探讨了开发团队按照各种范例生成的可交付文档的质量，其结果如图5所示。您可以看到敏捷团队生成的文档的报告质量 与传统团队处于同一水平，尽管迭代团队似乎比两者都更有效。 图5的有趣之处在于，在文档质量方面发现了所有开发范例（它们都具有负分数，因此直方图上的所有条形都朝左）。

图5.“可交付文档”的质量。

11.何时应创建文档？

让我们从一些基本建议开始（在本文的其他地方详细描述）：

1. 优先于静态规范的可执行规范（文档）
2. 单一来源信息
3. 记录稳定的概念，而不是推测性概念，从而在生命周期中尽可能晚地记录
4. 文档是最不有效的沟通方式

现在让我们考虑在软件开发生命周期（SDLC）中何时编写文档是有意义的。图6描绘了传统和敏捷开发文档的典型策略，曲线表示迄今为止在编写文档时投入的总工作量。在这种情况下，文档包括临时工作产品，例如项目计划和规范，您可能不会决定在项目结束时保留这些产品（一些团队会这样做，一些团队不会）。该图还指出了在给定时间点可能创建的文档类型，尽管此列表并不是详尽无遗的。图6实际上描述了文档后期最佳实践的策略。

图6.通过SDLC的文档 - 文档延迟策略。

另一种更有纪律的方法是随时记录支持，操作，系统概述和用户文档。图7中概述了该策略。该想法是，如果系统在每次迭代结束时可能是可交付的，那么也包括可交付文档。挑战在于，您编写的任何文档都需要随着时间的推移与您的代码同步发展，这可能很痛苦（请参阅下一节）。如果采用此策略，则需要考虑三种启发式方法：

1. 对于四周或更长时间的长迭代，请在迭代中编写文档，以便开发相应的功能。
2. 对于两周或更短的短迭代，考虑在下面的迭代中编写文档（尽管努力将其写为迭代）。
3. 无论迭代长度如何，您都需要尝试两种方法来找出最适合您的方法。最后，这两种策略通常最终会有所不同，因为通过长时间的迭代，您将倾向于将文档编写到迭代的最后。

图7.通过SDLC的文档 - 文档连续策略。

随着文档的不断接近，许多团队将在其迭代完成定义中包含有关更新可交付文档的标准。

12.何时应更新文档？

在这方面文件就像模型一样，我的建议是遵循练习更新时只有它会受伤。像敏捷模型这样的敏捷文档就足够了。很多时候文档可能已经过时而且并不重要。例如，当我编写本文的第一个版本时，我正在使用早期版本的JDK v1.3.1但我经常使用参考手册JDK 1.2.x-这不是一个完美的情况，但我没有太多的悲伤，因为我使用的手册仍然足够好。Java v1.0.x的手册是否足够？可能没有，因为自那次发布以来发生了重大变化，我的生产力损失将远远大于新手册的成本。

除了项目利益相关者授权投入完成工作所需资源的基本要求之外，您还应该使用以下启发式方法来决定何时更新文档：

1. 更新合同模型并在发布模型描述的项目之前进行理想的重新发布，并且最低限度地并行发布。
2. 作为系统一部分的文档（例如操作和用户手册）应在系统本身之前或与系统本身一起更新和发布。
3. 文档的客户受到了极大的伤害，包括显着的生产力损失，因为文档没有更新（例如，它会受到伤害）。

是的，如果模型和文档不完全准确或彼此不完全一致，则会令人沮丧。这种挫败感被行驶灯固有的生产率提高所抵消，不需要不断地使文档和模型保持最新并且彼此一致。你想写软件还是写文档？

13.有效的文档切换

当一个团体或个人向另一个团体或个人提供文档时，会发生文档切换。敏捷开发人员拼命试图避免文档切换，因为它们不是人们沟通的好方法。遗憾的是，在某些情况下，文档切换是现实的 - 您的开发团队是如此之大，以至于无法共存，可能是另一家公司正在创建子系统（意味着需要合同模型），也许重要的项目利益相关者是您的团队无法随时使用，或许您所在行业或组织的法规要求生成某些文档，或者您的团队可能由专家组成，而不是概括专家。以下策略有助于提高文档切换的有效性：

1. 避免文档切换。当您迁移到敏捷软件开发过程时，您将不断遇到那些不那么灵活的人，他们认为文档切换没有任何问题。指出有更好的沟通方式 - 面对面对话，视频会议，电话会议 - 在编写文档之前应该考虑，并尽可能尝试找到满足您需求的更好方法。
2. 支持与其他通信方式的切换。如果您无法避免向其他人提供文档，您至少应该努力通过面对面交流或其他方法来支持切换。这可以使您编写更少的文档，从而使您可以专注于其他活动，并将帮助您避免文档的一些常见缺点，例如误解材料。
3. 避免文档切换。你正在与之交往的人不喜欢写作和接收文档的机会很好 - 至少它不会有问题。
4. 编写敏捷文档。请参阅“提高文档敏捷性的策略”一节。
5. 避免文档切换。我不能强调这一点。

14.模板可以帮助吗？

是的，不是。我的经验是，专注于捕获文档中所需的最小，关键信息的简单模板非常有用。遗憾的是，许多模板与此完全相反，并尝试捕获您在任何情况下可能需要的所有信息。由于以下几个原因，这些模板被证明是无效的：

1. 该模板耗时且创建成本高。创建综合模板需要付出巨大努力。
2. 人们实际上会把它们填满。综合模板将包含不适用于给定项目的字段。有些人会看到该字段并试图填写它，浪费他们的时间并降低文档的价值，因为它现在包含不必要的信息，可能会在以后混淆用户。其他人会选择表明该字段不是必需的，这也需要时间。
3. 评论需要更长时间现在有更多的信息需要审查，有些信息可能是上面提到的不必要的信息。审查通常会在遇到表明不需要的字段时放慢速度，因为人们经常会质疑该决定。
4. 总体拥有成本（TCO）增加。您编写的文档越多，您旅行的文件就越重，减慢速度并提高文档的总体TCO。

15.如何减少文件损失？

“Cruft”是一个俚语，指的是设计糟糕，实施不当或多余的东西。重要的是要注意，cruft部分基于这样的感觉：除了该工件的实际质量之外，某人还具有工件。关于文档，当包含过时，冗余，范围外或写得不好的信息时，就会发生错误。表2概述了减少文档中的瑕疵的策略。该文件的CRUFT评级，100％是一件坏事，使用以下公式计算：100％ -  C * R * U * F * T，其中以下因素以百分比衡量：

• C =当前“正确”的文档的百分比。
• R =目标受众阅读文档的可能性。
• U =目标受众实际理解的文档百分比。
• F =将遵循文档中包含的材料的可能性。
• T =文档可信任的可能性。

表2：减少文件损失的策略。

Factor	Improvement Strategy
C = How correct is the document?	Minimize the information contained in the document Single source information by capturing it in one place only Have more than one person work on the document together (i.e. pair write the document and thereby do inspections in progress) Have shared ownership of all documentation so that multiple people will work on it Document stable, not speculative concepts
R = Will the document be read?	Work closely with the audience of the document so that you know what they actually require of it
U = Will the document be understood?	Take an evolutionary (iterative and incremental) approach to its development so that you gain feedback as to its actual value
F = Will the document be followed?	Prefer executable specifications, such as customer tests and developer tests, over static specifications such as traditional requirements and design documents. By doing so the specification actually provides value to the audience Capture high-level information in documentation, not details. When you specify details of how to do something and then hand the document to someone for them to follow, you effectively take all of the joy out of the activity for that person because you've done the thinking for them. What would the motivation be for an intellectual worker, such as an IT professional, to follow detailed instructions?
T = Will the document be trusted?	Work closely with the audience of the document Take an evolutionary approach

16.文档什么时候是最佳选择？

很少。让我们考虑一下您考虑编写文档时的情况：

1. 在开发过程中传达信息。传统的软件开发理论要求在整个软件开发生命周期中创建详细的文档。虽然这在理论上听起来是一个很好的策略，但在实践中它证明会增加您的总体成本和项目风险。原因是文档实际上是一种非常糟糕的通信方式，如图8所示。这个图表的含义是，您应该根据当前情况选择最适合您的通信选项。文档选项，特别是“纸张规格”是您最不希望的选择，而不是最理想的选择。
2. 指定一些东西。敏捷专家已经证明，通过采用测试驱动开发（TDD）方法，您可以在即时（JIT）基础上有效地创建详细的可执行规范。为了扩展TDD，我们采用敏捷模型驱动开发（AMDD）方法来解决以测试形式无法轻易捕获的高级问题。因此，一些高级规范可能有助于支持您的其他通信工作。
3. 永久记录信息。这是文档开始有意义的地方。您仍然希望以最佳方式为您的受众捕获信息，例如，维护程序员显然更喜欢高质量的源代码，完整的测试套件以及高度详细的系统文档的一些概述文档。您仍然需要编写支持文档，操作文档和用户文档，但传统团队编写的许多技术文档在实践中似乎很少有效。
4. 符合规定。无论喜欢与否，我们都生活在监管世界中。萨班斯 - 奥克斯利法案和食品药品管理局（FDA）指南等行业法规通常会激励人们编写比平常更多的文档，这通常是件好事。然而，在阅读了这些监管指南中的一些之后，我还没有看到一个人说要写一堆无用的文件，或者说你的钱非常浪费。然而，在实践中，许多组织选择这样做。我的建议是阅读法规，然后找到满足要求的有效方法。如果你让我们当中的官僚解释这些规定，那么当你最终采用官僚主义的方法时，不要感到惊讶。

图8.比较各种通信模式的有效性。

17.提高文档敏捷性的最佳实践

如果你不能避免写文档，你怎么能以敏捷的方式写它？ 以下核心实践应该有所帮助：

1. 优先于静态文档的可执行规范
2. 记录稳定的概念，而不是投机的想法
3. 生成系统文档
4. 保持文档足够简单，但不是太简单
5. 写出最少重叠的文档
6. 将信息放在最合适的地方
7. 公开显示信息
8. 有目的的文件
9. 关注文档的实际客户的需求
10. 客户确定充足
11. 迭代，迭代，迭代
12. 找到更好的沟通方式
13. 从实际保持最新的模型开始
14. 仅在疼痛时更新
15. 像处理要求一样对待文档
16. 要求人们证明文档请求的合理性
17. 认识到你需要一些文档
18. 找一个有写作经验的人

 

原文：http://agilemodeling.com/essays/agileDocumentation.htm

本文：https://pub.intelligentx.net/node/698

讨论：请加入知识星球或者小红圈【首席架构师圈】

本文概述了敏捷软件开发团队的设计策略。 这些策略对于扩展敏捷软件开发以满足现代IT组织的实际需求至关重要。 敏捷的设计方法与传统方法截然不同，显然也更有效。 重要的是要了解：

• 敏捷设计实践
• 敏捷设计理念
• 整个敏捷生命周期的设计

1.敏捷设计实践

从高级架构实践到低级编程实践，有一系列敏捷设计实践，参见图1。 这些实践中的每一个都很重要，如果您的团队要在敏捷设计方面有效，则每个实践都是必需的。

图1.敏捷设计实践。

2.敏捷设计理念

 

1. 敏捷设计是紧急的，它们不是预先定义的。随着时间的推移，您的整体系统设计将不断涌现，不断发展以满足新的需求并酌情利用新技术。虽然在“迭代0”期间您经常会在项目的最初阶段进行一些初始架构建模，但这足以让您的团队继续前进。在您开始编码之前，敏捷者不需要获得完整记录的模型集（尽管有时，有时候，您可能需要执行前瞻性建模）。
2. 您的单元测试构成了大部分详细的设计文档。使用测试驱动开发（TDD）开发方法，您可以编写测试，然后编写足够的域代码来完成测试。这种方法的一个重要副作用是，您的单元测试不仅验证您的代码，它们还以可执行规范的形式构成您的大部分设计文档。 TDD是AMDD的补充，实际上是由AMDD扩展的。
3. 设计模型需要勉强够用。您不需要对模型中的每个细节进行建模，模型不需要完美，并且它们当然不需要完整。还记得你最后一次从设计规范编码（如果你曾经做过）？你真的看过所有细粒度的细节吗？不，因为你有足够的能力自己处理细节。
4. 多种型号。有效的开发人员意识到每种类型的模型都有其优点和缺点，因此他们需要为手头的工作应用正确的模型。由于软件开发很复杂，因此您很快意识到需要了解各种模型才能有效。本新闻稿中提到的所有模型等都在Agile Models Distilled页面中进行了描述。
5. 您通常只需要模型的子集。虽然您可以使用许多建模技术，但事实是任何给定的项目团队只需要一个子集。可以这样想：在家里的工具箱里，你有各种各样的螺丝刀，扳手，钳子等等。对于任何给定的维修工作，您将只使用一些工具。不同的工作，不同的工具。您永远不需要同时使用所有工具，但随着时间的推移，您将以各种方式使用它们。
6. 每种型号都可用于各种用途。 UML类图可用于描述高级域模型或低级设计，更不用说介于两者之间的事物了。用例可用于模拟流程的基本性质或详细的系统使用描述，其中考虑了架构决策。永远不要低估模型的灵活性。
7. 设计师也应该编码。每当模型被移交给其他人进行编码时，程序员就不会理解模型，会遗漏一些细微差别，甚至可能完全忽略模型以支持他们自己的方法。此外，即使交接成功，您也会发现模型中需要的细节远远多于您自己编写的细节。简而言之，将设计与编程分离是一个风险和昂贵的主张。在团队中推广可以设计和编码的专家是更有效的。
8. 用代码证明它。永远不要假设你的设计有效相反，通过编写代码来确定它是否确实有效，从而获得具体的反馈。
9. 反馈是你的朋友。永远不要忘记你和你团队中的其他人一样只是凡人。期待收到反馈 - 我建议您积极寻求 - 关于您的工作，并准备好考虑并采取相应行动。您的系统不仅会更好，您还可以在此过程中学到一些东西。
10. 有时最简单的工具是复杂的CASE工具。在需求方面，我更喜欢纸和白板等包容性工具，但在设计方面，我倾向于使用复杂的工具（重新）为我生成代码。就像我的祖父总是说的那样，你应该使用合适的工具来完成工作。
11. 迭代，迭代，迭代。使用迭代的开发方法，您可以根据需求进行一些工作，进行一些分析，进行一些设计，一些编码，一些测试，并根据需要在这些活动之间进行迭代。您还将在处理各种工件之间来回迭代，在正确的时间处理正确的工件。
12. 设计非常重要，你应该每天都这样做。在构建之前，仔细思考如何构建某些东西，实际设计它是至关重要的。您的设计工作可以采用白板上的草图形式，使用复杂建模工具创建的详细模型，或者在编写业务代码之前编写的简单测试。敏捷开发人员意识到设计是如此重要以至于他们每天都在做，设计不仅仅是您在完成编写源代码的“实际工作”之前在项目早期所做的一个阶段。
13. 明智地为您的实施环境设计。利用您的实施环境的功能，但要聪明一点。权衡是正常的，但要了解其影响并管理所涉及的风险。每次使用产品（例如数据库，操作系统或中间件工具）中的独特性能增强功能时，您可能会将系统与该产品耦合，从而降低其可移植性。为了最大限度地降低实施环境对系统的影响，您可以对软件进行分层并包装特定功能，使其对用户显得通用。
14. 记录复杂的事情。如果它很复杂，那就彻底记录下来。更好的是，花时间设计它，这很简单。记住AM练习创建简单内容。
15. 不要过度记录。您需要记录您的设计，但不应该过度记录。请记住，用户付钱给您构建系统，而不是记录它们。在记录和文档之间有一个细微的界限，只有通过经验才能找到它。在文档方面尽量保持敏捷。
16. 不要被数据社区所牵制。不幸的是，数据社区中的许多人认为您需要采用串行方法进行设计，尤其是涉及数据库时。这种信念是由于不了解进化发展或某种被误导的需要来确定“一个真理高于一切”。诸如敏捷数据建模，数据库重构和数据库回归测试等进化数据库设计技术在实践中工作得非常好。
17. 记住用户体验（UX）。对于最终用户，用户界面（UI）是系统。这意味着您的设计的一个重要方面是UX。有关更多信息，请参阅敏捷可用性简介以及如何将设计集成到敏捷过程中。

3.整个生命周期的设计

图2描绘了通用敏捷软件开发生命周期。为了便于讨论，需要注意的重要一点是，传统主义者不熟悉设计阶段，也没有需求阶段。敏捷开发人员将在迭代0期间进行一些高级架构建模，也称为预热阶段，在开发迭代期间甚至在最终游戏期间（如果需要）进行详细设计。

图2. Agile SDLC（单击以展开）。

图3描绘了敏捷模型驱动开发（AMDD）生命周期，其重点是建模如何适应整个敏捷软件开发生命周期。 在项目早期，您至少需要了解如何构建系统。 它是大型机COBOL应用程序吗？ 一个.Net应用程序？J2EE？ 别的什么？ 在迭代0期间，项目的开发人员将聚集在一个房间，通常围绕白板，讨论，然后勾勒出系统的潜在架构。 这种架构可能会随着时间的推移而发展，它不会非常详细（它现在只需要足够好），并且需要编写很少的文档（如果有的话）。 目标是确定架构策略，而不是编写大量文档。

图3. AMDD生命周期。

当开发人员有新的实施要求时，他们会问自己是否理解要求的内容。如果没有，那么他们会做一些即时（JIT）“模型风暴”来确定实施要求的策略。这种模型风暴通常在迭代开始时在迭代的详细规划工作期间完成，或者在迭代期间的某个时间如果他们意识到他们需要进一步探索需求。这种建模工作的一部分将是对需求的分析以及解决方案的设计，这通常会在几分钟的时间内发生。在极限编程（XP）中，他们将此称为“快速设计会话”。

如果团队采用测试驱动开发（TDD）方法，则详细设计被有效地指定为开发人员测试，而不是详细模型。因为在编写足够的生产代码来完成测试之前编写测试，实际上在编写测试时会考虑生产代码的设计。您不是创建必然会过时的静态设计文档，而是编写一个可执行规范，开发人员可以通过该规范来保持最新，因为它实际上为它们提供了价值。该策略是单一采购信息的AM实践的一个示例，其中信息被捕获一次并用于多种目的。在这种情况下，详细规范和确认测试。

当你停下来思考它时，特别是在图2中，TDD有点用词不当。虽然您的开发人员测试正在“推动”代码的设计，但您的敏捷模型正在推动您的整体思考。

 

原文：http://agilemodeling.com/essays/agileDesign.htm

本文：https://pub.intelligentx.net/agilemodeling-agile-design

讨论：请加入知识星球或者小红圈【首席架构师圈】

您在A Vision中了解到敏捷数据方法，敏捷方法（如极限编程（XP）和纪律敏捷交付（DAD））采用迭代和增量方法进行软件开发。 XP和DSDM项目的应用程序开发人员通常放弃大型设计（BDUF）方法，转而采用紧急方法，系统设计在整个项目生命周期中不断发展。在敏捷开发项目中，在应用程序准备好发布之前，通常不知道最终设计。对于许多有经验的IT专业人员来说，这是一种非常不同的工作方

这意味着，预先创建（几乎）完整的逻辑和物理数据模型集的传统方法不会起作用。传统方法的主要优点是它使数据库管理员（DBA）的工作变得更加容易 - 数据模式很早就实现了，而这正是人们使用的。然而，有几个缺点。首先，它要求设计人员尽早完成，迫使您在项目早期确定大多数要求，从而迫使您的项目团队采用连续的方法进行开发。其次，它不容易支持变化。随着项目的进展，您的项目利益相关者了解他们的需求将会发展，从而激励他们发展自己的需求。在您的项目中，业务环境也会发生变化，再次激励您的利益相关者发展他们的需求。简而言之，传统的工作方式在敏捷环境中不能很好地工作。如果敏捷DBA将继续工作并支持遵循敏捷方法的项目团队，那么他们需要找到支持迭代和增量工作的技术。我的经验是，一种关键技术是数据库重构。

目录

• 重构
• 数据库重构
• 为什么数据库重构？
• 保留语义
• 什么数据库重构不是
• 为什么数据库重构很难
• 如何重构数据库
• 第1步：从您的开发沙箱开始
• 第2步：在集成沙箱中实施
• 第3步：安装到生产中
• 在您的组织内采用数据库重构
• 数据库重构最佳实践
• 现实世界中的数据库重构
• 数据库重构目录（发布为另一页）

 

1.重构

Martin Fowler（1999）描述了一种称为重构的编程技术，这是一种重构代码的规范方法。基本思想是您对代码进行少量更改以改进设计，使其更易于理解和修改。重构使您可以随着时间的推移缓慢地发展代码，采用迭代和增量方法进行编程。 Martin的重构网站www.refactoring.com是一个很好的在线资源。

重构的一个关键方面是它保留了代码的行为语义，至少从黑盒的角度来看。例如，有一个名为Rename Method的非常简单的重构，可能是从getPersons（）到getPeople（）。虽然表面上的这种更改看起来很简单，但您需要做的不仅仅是进行单一更改，还必须在所有应用程序代码中更改此操作的每次调用以调用新名称。一旦你做了这些改变，你可以说你已经真正重构了你的代码，因为它仍然可以像以前一样再次运行。

重要的是要了解在重构时不添加功能。当您重构改进现有代码时，在添加功能时，您将添加新代码。是的，您可能需要重构现有代码才能添加新功能。是的，稍后您可能会发现需要重构刚刚添加的新代码。要点是重构和添加新功能是两个不同但互补的任务。

2.数据库重构

在2002年2月的软件开发期间，我描述了一种我称之为数据重构的技术。本文描述了我的初步经验，应该更恰当地称之为事后数据库重构。因此新名称。从这一点开始，我将使用术语代码重构来引用Fowler所描述的传统重构，以区别于数据库重构。

让我们从一些定义开始。数据库重构是对数据库模式的简单更改，可以改进其设计，同时保留其行为和信息语义。为了便于讨论，数据库模式包括结构方面（如表和视图定义）以及功能方面（如存储过程和触发器）。有趣的是，数据库重构在概念上比代码重构更难。代码重构只需要维护行为语义，而数据库重构也必须维护信息语义。

有一个名为Split Column的数据库重构，它是A Database of Database Refactorings中描述的众多数据库之一，您可以用两个或多个其他列替换单个表列。例如，您正在处理数据库中的Person表，并发现FirstDate列用于两个不同的目的 - 当该人是客户时，此列存储他们的出生日期，当该人员是雇员时，它存储他们的雇用日期。您的应用程序现在需要支持既可以成为客户又可以成为员工的人，这样您就会遇到问题。在实现此新要求之前，您需要通过将BirthDate列替换为BirthDate和HireDate列来修复数据库模式。要维护数据库模式的行为语义，您需要更新访问FirstDate列的所有源代码，以便现在使用这两个新列。要维护信息语义，您需要编写一个遍历表的迁移脚本，确定类型，然后将现有日期复制到相应的列中。虽然这听起来很简单，有时也是如此，但我的经验是，在考虑文化问题时，数据库重构在实践中是非常困难的（稍后将详细介绍）。

 

2.1为什么要重构数据库？

您应该对数据库重构感兴趣的原因有两个：

• 安全地修复现有的旧数据库。底线是遗留数据库不会自行修复，从技术角度来看，数据库重构是一种安全，简单的方法，可以随着时间的推移改善数据和数据库的质量。多年来，我对数据质量的各种调查一直表明，组织遭受数据质量问题，但在许多情况下，没有一个现实的战略来解决这些问题。
• 支持进化发展。现代软件开发过程，如DAD，XP和Scrum，都以渐进的方式工作。数据专业人员需要采用包括这一技术在内的技术，使他们能够以这种方式工作。
• 调整数据库。部分调优工作可能包括模式的（反）规范化。

2.2保留语义

信息语义是指从该信息的用户的角度来看数据库内的信息的含义。保留信息语义意味着当您更改存储在列中的数据的值时，该信息的客户端不应受到改进的影响。类似地，关于行为语义，目标是使黑盒功能保持相同 - 必须重新设计与数据库模式的已更改方面一起使用的任何源代码，以实现与以前相同的功能。

2.3什么数据库重构不是什么

对模式进行小规模转换以扩展它，例如添加新列或表，不是数据库重构，因为更改扩展了您的设计。同时应用于数据库模式的大量小更改（例如重命名十列）不会被视为数据库重构，因为这不是一个小的更改。数据库重构是对数据库模式的微小更改，可以在保留行为和信息语义的同时改进其设计。而已。我毫不怀疑你可以对你的模式进行那些更改，你甚至可以遵循类似的过程，但它们不是数据库重构。

3.为什么数据库重构很难

耦合。正如您在关系数据库101中所了解到的那样，耦合度是两个项目之间依赖程度的度量 - 两个事物之间的耦合程度越高，一个变化需要另一个变化的可能性就越大。在进行数据库重构时，耦合是“万恶之源”，数据库模式与重构更加困难的事情就越多。不幸的是，您在关系数据库101中了解到关系数据库模式可能与各种各样的事物耦合：

• 您的应用程序源代码
• 其他应用程序源代码
• 数据加载源代码
• 数据提取源代码
• 持久性框架/层
• 您的数据库架构（通过模型或脚本捕获）
• 数据迁移脚本
• 测试代码
• 模型和/或文档

图1描述了数据库重构的最佳情况 - 只有您的应用程序代码与数据库模式相关联。图2描绘了数据库重构工作的最坏情况，其中各种各样的软件系统与您的数据库模式耦合，这种情况在现有生产数据库中很常见。

图1.最佳情况。

 

如您所见，在数据库重构方面，耦合是一个严重的问题。为简单起见，在本文的其余部分中，术语“应用程序”将指代与数据库耦合的所有外部系统，数据库，应用程序，程序，测试套件。

4.如何重构数据库

在我描述重构数据库的步骤之前，我需要解决一个关键问题 - 图1所示的简单情况是否意味着你会做出与图2中高度耦合的情况不同的事情？是的，不是。基本过程本身保持不变，尽管随着数据库耦合的增加，实现单个数据库重构的难度也会大大增加。如果您发现自己处于简单的情况，那么您将不需要执行下面描述的过渡期工作，您可以简单地并行重构数据库模式和应用程序代码并同时部署它们。发现自己处于更复杂局面的人没有这种奢侈品。

本节的编写假设您的技术和文化环境是有组织的，以支持数据库重构。虽然这听起来像是一个很大的假设，但是，我会描述你需要做些什么才能达到这些环境实际到位的程度。少一点是不合适的。

我喜欢将数据库重构视为一个三步过程：

1. 从您的开发沙箱开始
2. 在集成沙箱中实现
3. 安装到生产中

4.1第1步：在您的开发沙箱中开始

您的开发沙箱是一个技术环境，您的软件（包括应用程序代码和数据库模式）是开发和单元测试的。重构数据库模式的需求通常由尝试实现新需求或正在修复缺陷的应用程序开发人员识别。例如，开发人员可能需要扩展其应用程序以接受除美国地址之外的加拿大邮寄地址。主要区别在于加拿大地址有邮政编码，如R2D 2C3而不是邮政编码，如90210-1234。不幸的是，SurfaceAddress表的ZipCode列是数字的，因此目前不支持加拿大邮政编码。应用程序开发人员描述了对其项目中的一个Agile DBA所需的更改以及数据库重构工作的开始。

如图3所示，Agile DBA和应用程序开发人员通常会通过以下部分或全部步骤来实现重构：

• 验证是否需要重构数据库
• 选择最合适的数据库重构
• 弃用原始架构
• 写单元测试
• 修改数据库架构
• 迁移源数据
• 更新外部访问程序
• 更新数据迁移脚本
• 运行回归测试
• 宣布重构
• 版本控制你的工作

图3.数据库重构的过程。

4.1.1验证是否需要数据库重构

敏捷DBA所做的第一件事是他们将尝试确定数据库重构是否需要发生以及是否是正确的重构。敏捷DBA所做的第二件事是在内部评估实际需要变更的可能性。这通常是基于Agile DBA之前与应用程序开发人员的经验的“直接调用”。 Agile DBA接下来要做的就是评估重构的整体影响。在图1的瘦腿情况下，这是相当简单的，因为敏捷DBA应该了解应用程序如何耦合到数据库的这一部分。如果不是这种情况，他们需要与应用程序开发人员合作。在图2的复杂情况下，Agile DBA需要了解组织内的整体技术基础架构以及其他应用程序如何与数据库耦合。这是他们需要通过与企业架构师，企业管理员，应用程序开发人员甚至其他敏捷DBA合作来建立的知识。当敏捷DBA不确定其影响时，他们要么需要决定当时做出决定并且有他们的直觉，或者决定建议应用程序开发人员在他们与合适的人交谈时等待。这项工作的目标是确保您尝试进行无法完成的数据库重构 - 如果您需要更新，测试和重新部署其他20个应用程序以进行此重构，那么你可能继续下去是不可行的。

4.1.2选择最合适的数据库重构

敏捷DBA需要的一项重要技能是理解您通常有多种选择来在数据库中实现新的数据结构和新逻辑。

4.1.3编写单元测试

与代码重构一样，数据库重构由于存在全面的测试套件而启用 - 您知道如果您可以轻松验证数据库在更改后仍然有效，则可以安全地更改数据库模式。这是我的建议：

您的主要目标是确保测试存在。

您应该尝试在应用程序级别或数据库级别执行一次每个测试，但不能同时执行两者。

一些单元测试将在应用程序级别，一些在数据库级别，这没关系。

寻求最低的共同点 - 如果数据库被多个应用程序访问，那么任何与数据相关的测试都应该出现在您的数据库测试套件中，这有助于确保它们经过一次测试。

如果您有选择，请在具有最佳测试工具的级别（通常在应用程序级别）实施测试。测试工具在工具文章中讨论。

文章数据库回归测试详细描述了数据库测试。

4.1.4弃用原始架构

Pramod Sadalage和Peter Schuh（2002）推广的一种有效技术是弃用期，尽管过渡期是一个更好的术语，对于你正在改变的模式的原始部分。他们发现您不能简单地立即对数据库模式进行更改，而是需要并行处理旧模式和新模式一段时间，以便为其他应用程序团队提供重构和重新部署系统的时间。图4显示了当我们将替换列数据库重构应用于ZipCode时，这个想法是如何工作的（这个例子是在2003年创建的，因此在2007年是一个删除日期 - 稍后将详细介绍）。请注意过渡期间原始模式和模式之间的更改。 PostCode已添加为列，正如您所期望的那样。 ZipCode列已被标记为已弃用 - 您知道这一点，因为已使用UML命名变量为其分配了删除日期。还引入了一个触发器来保持两列中包含的值同步，假设新的应用程序代码将与PostCode一起使用，但不应期望ZipCode保持最新，并且旧的应用程序代码尚未重构为使用新架构将不知道如何使PostCode保持最新。此触发器是数据库脚手架代码的示例，是保持数据库“粘合在一起”所需的简单和通用代码。此代码已分配与ZipCode相同的删除日期。

图4.重构Address表。

关于图4的一个有趣的事情是将Country列添加到Address。等一下，目录中没有添加列数据库重构。我们发现了一种新型的数据库重构吗？不。数据库重构是对数据库模式的小改动，它们改进了他们的设计，而不仅仅是改变设计。添加新列是对模式的转换，但不是对它的设计改进。虽然这显然是一个非常小的细微差别我相信它是一个重要的。

要了解如何实现数据库重构的代码，请阅读重命名列数据库重构。

图5描绘了数据库重构的生命周期。首先在项目范围内实现它，如果成功，最终将其部署到生产环境中。在过渡期间，原始模式和新模式都存在，具有足够的脚手架代码以确保正确支持任何更新。在过渡期间，一些应用程序将与PostCode和其他具有ZipCode的应用程序一起使用，但不能同时使用。无论它们使用哪个列，应用程序都应该正常运行。弃用期限到期后，将删除原始架构和任何脚手架代码，并重新测试数据库。在这个时间点，假设所有应用程序都使用PostCode。

图5.数据库重构的生命周期。

在图5的顶部，我们将来自Disciplined Agile（DA）的3C模式应用于生命周期。这是一个三步模式：

坐标。实施重构，与组织级别的适当人员（可能是您的数据管理组）协调，以确保它进入整个变更流程。

合作。整个组织中的团队共同努力改变与数据库相关的任何变化（参见图2）。

得出结论。删除原始模式和脚手架代码，有效地完成重构。

4.1.5修改数据库模式

应用程序开发人员和Agile DBA一起在开发沙箱中进行更改。策略是简单地开始每个重构，首先通过在开发沙箱中执行重构，您实际上将自己置于图1中描述的情况中。

为此，您需要更新两个日志（假设您没有自动执行此操作的数据库重构工具）：

• 数据库更改日志。这是在整个项目过程中应用它们的顺序实现所有数据库模式更改的源代码。在实施数据库重构时，只包括此日志中的即时更改。在应用替换列数据库重构时，我们将包括用于添加PostCode列的DDL和用于实现触发器的数据定义语言（DDL），以在过渡期间维护PostCode和ZipCode列之间的值。
• 更新日志。此日志包含将在数据库重构的过渡期之后运行的数据库模式的未来更改的源代码。在我们的示例中，这将是删除ZipCode列和我们引入的触发器所需的源代码。

4.1.6迁移数据

许多重构要求您将旧版本的架构迁移或复制数据到新架构。您的数据迁移日志包含数据操作语言（DML），用于在整个项目过程中重新格式化或清理源数据。在我们的示例中，这将包括任何用于提高ZipCode列中值的质量的代码。

4.1.7更新外部程序

访问要重构的数据库模式部分的程序必须更新才能使用新版本的数据库模式。所有这些程序都必须重构，然后在过渡期到期之前部署到生产中，如图5所示。

4.1.8运行回归测试

一旦对应用程序代码和数据库模式进行了更改，您就需要运行回归测试套件。因为成功的测试会发现问题，所以在你做对之前需要重做工作。数据库重构的一个重要优点是，如果您的测试确实打破了，那么您可以很好地了解问题所在 - 在您刚刚更改的应用程序代码和数据库架构中。您的更改越大，追踪问题就越困难，因此您的开发工作就越慢，效率也就越低。你会发现，在小的渐进步骤中进行开发在实践中非常有效。

4.1.9宣布您所做的更改

因为您的数据库是一个共享资源，所以如果不是由多个应用程序团队在应用程序开发团队中共享它，那么Agile DBA需要传达已经发生的更改。如果您还没有这样做，则应更新数据库的物理数据模型（PDM）。我个人倾向于在PDM工具（如ERWin）中对新模式进行建模，然后生成初始DDL，然后我将修改并包含在我的数据库更改脚本中。

4.1.10版本控制你的工作

敏捷开发人员的一项关键技能是将所有工作都置于配置管理（CM）控制之下，通过将其检入版本控制工具。在数据库重构的情况下，这包括您创建的任何DDL，更改脚本，数据迁移脚本，测试数据，测试用例，测试数据生成代码，文档和模型。这是您通常会修改的面向应用程序的工件的补充 - 对待面向数据库的工件与处理其他开发工件的方式完全相同，您应该没问题。

4.2第2步：在集成沙箱中实施

几天过后，您将准备好在项目集成沙箱中实现数据库重构。您需要等待的原因是为了让您的队友有时间重构自己的代码以使用新架构。

选择通过使用持久性框架封装对数据库的访问权限的团队将发现更容易对数据库模式更改做出反应，因此可能会发现他们可以加强在开发沙箱和项目中实现数据库重构之间的时间间隔集成沙箱。这是因为数据库模式在元数据中表示，因此许多数据库模式更改只需要更新元数据而不需要更新实际的源代码。

要部署到每个沙箱中，您需要构建应用程序并运行数据库管理脚本（Autopatch等工具可以提供帮助）。下一步是重新运行回归测试以确保您的系统仍然有效 - 如果不是，您将需要在开发环境中进行修复，重新部署和重新测试。项目集成沙箱中的目标是验证团队中每个人的工作在组合时的功能，而您在Test / QA沙箱中的目标是验证您的系统是否适用于组织内的其他系统。

通信是将数据库重构部署到Test / QA沙箱中的关键部分，我现在使用复数，因为您通常会在此环境中同时引入多个数据库更改（重构）。在更改数据库模式之前，您需要与访问数据库的所有其他应用程序的所有者进行通信并协商更改。您的企业管理员将参与此次谈判，他们甚至可以促进工作，以确保满足您组织的整体需求。幸运的是，您在开发沙箱中遵循的过程使数据库重构的这一方面变得更加容易：

• Agile DBA只允许实际实现的数据库重构 - 如果另一个应用程序团队无法重新编写代码来访问新模式，那么就无法进行更改。
• Agile DBA编写的文档，即使只是每个更改的简要描述，也很重要，因为它提供了即将部署的更改的概述。
• 随着数据库重构的实施而更新的新版本物理数据模型（PDM）成为与其他团队进行谈判的焦点。敏捷建模（AM）会认为PDM是您的团队与其他应用团队之间的“合同模型”，他们可以指望这些模型是准确的，并且他们可以指望积极参与协商变更。

4.3第3步：安装到生产中

安装到生产环境是数据库重构中最难的部分，特别是在图2的复杂情况下。您通常不会自己部署数据库重构，而是将它们部署为一个或多个系统的整体部署的一部分。当您有一个应用程序和一个要更新的数据库时，部署是最简单的，并且这种情况确实在实践中发生，但实际上我们需要考虑您一次部署多个系统和多个数据源的情况。图6概述了将重构部署到生产环境中的步骤。

图6.部署数据库重构的步骤。

图7描述了如何安排应用程序预定义部署窗口的部署，如绿色所示。 部署窗口（通常称为发布窗口）是允许将系统部署到生产中的特定时间点。 您的操作人员很可能对应用程序团队何时部署系统有严格的规定。 图7显示了两个项目团队如何安排将更改（包括数据库重构）部署到可用的部署窗口中。 有时没有什么可以部署，有时一个团队有变化，有时两个团队都有架构变化要部署。

图7.将重构调度到部署窗口中。

您自然需要与在同一部署窗口中部署的任何其他团队进行协调。这种协调将在您部署之前很久发生，坦率地说，您的预生产测试环境存在的主要原因是提供一个沙箱，您可以在其中解决多系统问题。无论将多少数据库重构应用于您的生产数据库，或者这些重构是由多少团队开发的，它们都将首先在您的预生产测试环境中进行测试，然后再应用于生产。

5.在您的组织内采用数据库重构

虽然采用有效的工具是实现数据库重构的重要部分，但它只是冰山一角 - 数据库重构需要在组织内进行重大的文化变革。由于数据库重构是敏捷数据方法的一种支持技术，因此采用数据库重构的许多文化问题与采用敏捷数据方法时面临的问题相同。这些文化问题包括许多数据专业人员的一系列思维方式，对变革的抵制以及政治惰性。以下方法可以帮助您克服这些挑战：

1. 从简单开始。在新应用程序访问新数据库的绿地环境中，数据库重构最容易，下一个最简单的情况是单个应用程序访问旧数据库时。这两种情况都以图1为代表。通过简单的开始，您可以为自己提供一个可以学习基础知识的环境，一旦您了解了基础知识，您就可以更好地解决图2所示的情况。
2. 接受迭代和增量开发是常态。现代软件开发方法采用迭代和增量方法进行软件开发。尽管串行开发通常是许多数据专业人员的首选方法，但遗憾的是它并未反映应用程序开发人员当前的工作方式。是时候改变了。
3. 接受没有神奇的解决方案让你摆脱现有的混乱局面。您的数据质量问题并没有自行创建，也无法自行修复。人们创造了问题，人们需要解决问题。数据库重构是您可以从数据技术债务中挖掘出来的最安全，最直接的策略。
4. 采用100％数据库回归测试策略。要使数据库重构工作，并且通常要使迭代和增量开发工作，您需要在回归测试中有效。要在数据库重构方面取得成功，您不仅需要对数据库本身进行回归测试，还需要对与数据库耦合的任何应用程序进行回归测试。这意味着您需要为每个应用程序提供回归测试套件，这是您很可能没有的。所以开始写它们。
5. 探索技术。首先在简单的情况下尝试数据库重构，以学习技术并获得一些经验。然后开始重构更复杂的事情。所以，开始简单吧。

数据库重构在实践中起作用，它不仅仅是另一种学术理论。对于绝大多数组织而言，这是一种新的“前沿”技术。

6.数据库重构最佳实践

Fowler（1999）提出了一系列代码重构的最佳实践，我在下面重新构建了数据库重构的实践：

1. 重构以简化模式的添加。
2. 确保测试套件到位。
3. 迈出小步。
4. 人民计划。
5. 不要过早发布数据模型。
6. 对文件的需求反映了重构的必要性。
7. 经常测试。

7.现实世界中的数据库重构

数据库重构支持数据库模式演变的渐进方法，这是三个基本策略之一（您可以放弃，采取“大爆炸”方法，采取增量方法）。每种策略都有其独特的优点和缺点。我怀疑许多组织，或许是因为一种连续的思维方式，要么尝试过大爆炸的方法，要么已经太害怕了，现在已经放弃了。它不一定是这样的。是的，您的组织可能需要花费大量精力来制定文化和技术来支持整个企业的数据库重构，但从长远来看，这可能比您的其他选择更加可口。

请参阅数据库重构目录（http://www.agiledata.org/essays/databaseRefactoringCatalog.html）。

无论您的策略如何，数据库的演变都很难，当您的数据库与其他事物高度耦合时，尤其如此。数据库重构不是一个可以神奇地解决所有数据库问题的灵丹妙药。本文介绍了如何在简单的瘦腿环境中成功实现数据库重构。

 

原文：http://agiledata.org/essays/databaseRefactoring.html

本文：https://pub.intelligentx.net/agiledata-process-database-refactoring-strategies-improving-database-quality

讨论：请加入知识星球或者小红圈【首席架构师圈】

数据库重构是对数据库模式的一个小改动，它改进了它的设计而不改变其语义。 此目录分为几类数据库重构：

1. 结构。 对数据库模式的表结构的更改。
2. 数据质量。 一种改进，它改进和/或确保数据库中存储的值的一致性和使用。
3. 参照完整性。 一种更改，用于确保引用的行存在于另一个表中和/或确保适当地删除不再需要的行。
4. 架构。 一种改进，它改善了外部程序与数据库交互的整体方式。
5. 方法。 一种改进，可以提高存储过程，存储函数或触发器的质量。
6. 非重构转换。 通过向其添加新元素或通过修改现有元素来更改数据库模式语义的更改。

Category	Database Refactorings
Structural Refactorings	Drop Column Drop Table Drop View Introduce Calculated Column Introduce Surrogate Key Merge Columns Merge Tables Move Column Rename Column Rename Table Rename View Replace LOB With Table Replace Column Replace One-to-Many With Associative Table Replace Surrogate Key with Natural Key Split Column Split Table
Data Quality Refactorings	Add Lookup Table Apply Standard Codes Apply Standard Type Consolidate Key Strategy Drop Column Constraint Drop Default Value Drop Non-Nullable Constraint Introduce Column Constraint Introduce Common Format Introduce Default Value Make Column Non-Nullable Move Data Replace Type Code With Property Flags
Referential Integrity Refactorings	Add Foreign Key Constraint Add Trigger for Calculated Column Drop Foreign Key Constraint Introduce Cascading Delete Introduce Hard Delete Introduce Soft Delete Introduce Trigger for History
Architectural Refactorings	Add CRUD Methods Add Mirror Table Add Read Method Encapsulate Table With View Introduce Calculation Method Introduce Index Introduce Read Only Table Migrate Method From Database Migrate Method to Database Replace Method(s) With View Replace View With Method(s) Use Official Data Source
Method Refactorings	Add Parameter Consolidate Conditional Expression Decompose Conditional Extract Method Introduce Variable Parameterize Methods Remove Control Flag Remove Middleman Remove Parameter Rename Method Reorder Parameters Replace Literal With Table Lookup Replace Nested Expression With Guard Clauses Replace Parameter With Specific Methods Split Temporary Variable Substitute Algorithm
Non-Refactoring Transformations	Insert Data Introduce New Column Introduce New Table Introduce View Update Data

 

原文：http://www.agiledata.org/essays/databaseRefactoringCatalog.html

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

测试驱动开发(TDD) (Beck 2003;，是一种渐进的开发方法，它结合了测试优先的开发，即在编写足够的产品代码以完成测试和重构之前编写测试。TDD的主要目标是什么?一个观点是TDD的目标是规范而不是验证(Martin, Newkirk，和Kess 2003)。换句话说，这是在编写功能代码之前考虑需求或设计的一种方法(这意味着TDD是一种重要的敏捷需求和敏捷设计技术)。另一种观点认为TDD是一种编程技术。正如Ron Jeffries喜欢说的，TDD的目标是编写有效的干净代码。我认为这两种观点都是有价值的，尽管我倾向于规范的观点，但是我把它留给您来决定。

表的内容

• TDD是什么?
• TDD和传统测试
• TDD和文档
• 测试驱动的数据库开发
• 通过敏捷模型驱动开发(AMDD)扩展TDD
• 为什么TDD ?
• 神话和误解
• 到底是谁在做这件事?
• 总结
• 工具

1. TDD是什么?

图1的UML活动图中概述了测试优先开发(test first development, TFD)的步骤。第一步是快速添加一个测试，基本上只需要足够的代码就可以失败。接下来运行您的测试，通常是完整的测试套件，尽管出于速度的考虑，您可能决定只运行一个子集，以确保新测试确实失败。然后更新函数代码，使其通过新的测试。第四步是再次运行测试。如果它们失败了，您需要更新您的功能代码并重新测试。一旦测试通过，下一步就是重新开始(您可能首先需要根据需要重构设计中的任何重复，将TFD转换为TDD)。

图1所示。测试优先开发(TFD)的步骤。

我喜欢用这个简单的公式来描述TDD:

TDD =重构+ TFD。

TDD彻底改变了传统开发。当您第一次实现一个新特性时，您要问的第一个问题是，现有的设计是否是使您能够实现该功能的最佳设计。如果是，则通过TFD方法进行。如果没有，则在本地重构它，以更改受新特性影响的设计部分，使您能够尽可能轻松地添加该特性。因此，您将始终提高您的设计质量，从而使它更容易在未来的工作。

与其先编写函数代码，然后再编写测试代码，如果您真的编写了测试代码，那么您应该在编写函数代码之前编写测试代码。此外，您可以通过非常小的步骤来完成—一次测试和少量对应的函数代码。采用TDD方法的程序员拒绝编写新函数，直到第一个测试失败，因为该函数不存在。事实上，在对代码进行测试之前，他们甚至拒绝添加任何一行代码。一旦测试就绪，他们就会执行确保测试套件现在通过所需的工作(您的新代码可能会破坏几个现有的测试以及新的测试)。这在原则上听起来很简单，但是当您第一次学习使用TDD方法时，它需要严格的规程，因为不首先编写新的测试，很容易“滑倒”并编写功能代码。结对编程的一个优点是，结对可以帮助您保持在正确的轨道上。

TDDSpecification by example有两个级别的TDD:

1. 验收测试驱动开发(ATDD)。使用ATDD，您可以编写一个验收测试，或者根据您喜欢的术语编写行为规范，然后编写足够的产品功能/代码来完成该测试。ATDD的目标是在准时(JIT)的基础上为您的解决方案指定详细的、可执行的需求。ATDD也被称为行为驱动开发(BDD)。
2. 开发人员TDD。使用开发人员TDD，您可以编写单个开发人员测试，有时不准确地称为单元测试，然后编写足够的生产代码来完成该测试。开发人员TDD的目标是在JIT的基础上为您的解决方案指定一个详细的、可执行的设计。开发人员TDD通常简单地称为TDD。

图2描述了一个UML活动图，展示了ATDD和开发人员TDD是如何结合在一起的。理想情况下，您将编写一个验收测试，然后使用开发人员TDD方法实现实现该测试所需的生产代码。这反过来要求您迭代多次，通过编写测试、编写生产代码，使其在开发人员TDD级别上工作。

图2。验收TDD和开发人员TDD如何协同工作。

请注意，图2假设您同时做这两件事，尽管可以不做任何一件事。事实上，有些团队会在不使用ATDD的情况下使用开发人员TDD，请参阅下面的调查结果，尽管如果您正在使用ATDD，那么几乎可以肯定您也在使用开发人员TDD。挑战在于，这两种形式的TDD都要求从业者具有技术测试技能，而许多需求专家通常没有这些技能(这也是为什么泛化专家比专家更可取的另一个原因)。

TDD的一个基本假设是您有一个可用的测试框架。对于可接受的TDD，人们将使用Fitnesse或RSpec等工具，对于开发人员TDD，敏捷软件开发人员通常使用xUnit系列的开源工具，如JUnit或VBUnit，尽管商业工具也是可行的选择。没有这些工具，TDD实际上是不可能的。图3展示了一个UML状态图，展示了人们通常如何使用这些工具。这个图表是Keith Ray向我提出的。

图3。通过xUnit框架进行测试。

kent Beck在eXtreme Programming (XP) (Beck 2000)中推广了TDD，他为TDD定义了两个简单的规则(Beck 2003)。首先，只有在自动化测试失败时，才应该编写新的业务代码。其次，您应该消除发现的任何重复。Beck解释了这两条简单的规则是如何产生复杂的个人和群体行为的:

• 您的开发是有机的，运行中的代码在决策之间提供反馈。
• 您编写自己的测试，因为您不能每天等待20次别人为您编写测试。
• 您的开发环境必须对小的变化提供快速的响应(e。你需要一个快速的编译器和回归测试套件)。
• 您的设计必须由高度内聚、松散耦合的组件(例如，您的设计高度规范化)组成，以使测试更容易(这也使系统的演化和维护更容易)。

对于开发人员来说，这意味着他们需要学习如何编写有效的单元测试。Beck的经验是好的单元测试:

• 跑得快(他们有短的设置，运行时间和故障)。
• 单独运行(应该能够重新排序)。
• 使用易于阅读和理解的数据。
• 在需要时使用真实数据(例如生产数据的副本)。
• 代表向你的总体目标迈出的一步。

2. TDD和传统测试

精益敏捷atdd tdd主要是一种规范技术，它的副作用是确保您的源代码在验证级别得到彻底的测试。然而，还有比这更多的测试。特别是在规模上，您仍然需要考虑其他敏捷测试技术，如生产前集成测试和调查性测试。如果您选择这样做(您应该这样做)，那么大部分测试也可以在项目的早期完成。

使用传统的测试，成功的测试会发现一个或多个缺陷。TDD也是如此;当测试失败时，您已经取得了进展，因为您现在知道需要解决问题。更重要的是，当测试不再失败时，您可以清楚地度量成功。TDD增加了您的信心，您的系统实际上满足为它定义的需求，您的系统实际上工作，因此您可以满怀信心地继续。

与传统测试一样，系统的风险概要越大，您的测试就需要越全面。对于传统的测试和TDD，您并不追求完美，而是测试系统的重要性。套用敏捷建模(Agile Modeling, AM)的说法，您应该“有目的地进行测试”，并且知道您为什么要进行测试，以及需要测试到什么级别。TDD的一个有趣的副作用是，您可以实现100%的覆盖率测试—每一行代码都经过测试—这是传统测试无法保证的(尽管它推荐这样做)。总的来说，我认为可以相当肯定地说，尽管TDD是一种规范技术，但是它有一个有价值的副作用，那就是它比传统技术的代码测试结果要好得多。

如果值得构建，就值得测试。

如果不值得测试，为什么要浪费时间在上面呢?

3.TDD和文档

不管喜欢与否，大多数程序员都不阅读系统的书面文档，相反，他们更喜欢使用代码。这没什么不对的。当试图理解一个类或操作时，大多数程序员首先会寻找已经调用它的示例代码。编写良好的单元测试正是这样做的——提供功能代码的工作规范——因此单元测试有效地成为技术文档的重要部分。这意味着支持文档的人群的期望需要反映这一现实。类似地，验收测试可以成为需求文档的重要部分。当你停下来思考的时候，这是很有意义的。您的验收测试准确地定义了涉众对您的系统的期望，因此它们指定了您的关键需求。您的回归测试套件，特别是使用测试优先的方法，有效地成为详细的可执行规范。

测试是否有足够的文档?很可能不会，但它们确实构成了其中重要的一部分。例如，您可能会发现仍然需要用户、系统概述、操作和支持文档。您甚至可能发现，您需要摘要文档来查看系统支持的业务流程。当您以开放的心态处理文档时，我怀疑您会发现这两种类型的测试涵盖了开发人员和业务涉众对文档的大部分需求。此外，它们是AM的单一源信息实践的一个很好的例子，也是您在文档方面保持尽可能敏捷的整体努力的一个重要部分。

4. 测试驱动的数据库开发

在撰写本文时，敏捷社区中提出的一个重要问题是“TDD可以用于面向数据的开发吗?”“当您查看图1中描述的流程时，需要注意的是没有一个步骤指定对象编程语言，比如Java或c#，即使这些是通常使用TDD的环境。为什么不能在更改数据库模式之前编写测试?为什么不能根据需要进行更改、运行测试和重构模式呢?在我看来，你只需要选择这样做。

我的猜测是，在短期内，数据库TDD，或者测试驱动数据库设计(TDDD)，将不会像应用程序TDD那样工作得那么顺利。第一个挑战是工具支持。尽管诸如DBUnit之类的单元测试工具现在已经可用，但在撰写本文时，它们仍然是一种新兴的技术。一些dba正在改进他们所做的测试的质量，但是我还没有看到任何人采用TDD方法进行数据库开发。一个挑战是单元测试工具在数据社区中仍然没有被很好地接受，尽管这正在发生变化，所以我的预期是在未来几年数据库TDD将会增长。其次，对许多数据专业人员来说，演进开发的概念是新的，因此采用TDD方法的动机尚未形成。这个问题影响了数据专业人员可用的工具的性质——因为在传统的数据社区中，串行思维仍然占主导地位，大多数工具不支持渐进开发。我希望工具供应商能够跟上这种范式的转变，但是我的期望是我们需要开发开源工具。第三，我的经验是，大多数从事数据导向工作的人似乎更喜欢模型驱动的方法，而不是测试驱动的方法。其中一个原因可能是因为测试驱动方法直到现在才被广泛考虑，另一个原因可能是许多数据专业人员可能是视觉思考者，因此更喜欢模型驱动方法。

5. 通过敏捷模型驱动开发(AMDD)扩展TDD

TDD非常擅长于详细的规范和验证，但不擅长考虑更大的问题，比如总体设计、人们将如何使用系统或UI设计(例如)。建模，或者更接近于敏捷模型驱动开发(AMDD)(图4中捕捉到的生命周期)更适合于此。AMDD解决了TDD没有解决的敏捷扩展问题。

图4。敏捷模型驱动开发(AMDD)生命周期。

比较TDD和AMDD:

• TDD缩短了编程反馈循环，AMDD缩短了建模反馈循环。
• TDD提供了详细的规范(测试)，而AMDD更适合考虑更大的问题。
• TDD促进高质量代码的开发，而AMDD促进与涉众和其他开发人员的高质量通信。
• TDD提供了软件工作的具体证据，而AMDD支持您的团队(包括涉众)朝着共同的理解努力。
• TDD与程序员“交谈”，而AMDD与业务分析师、涉众和数据专业人员交谈。
• TDD提供了非常细粒度的关于分钟顺序的具体反馈，而AMDD支持关于分钟顺序的口头反馈(具体的反馈要求开发人员按照实践用代码证明它，因此依赖于非am技术)。
• 通过关注可调用和可测试操作的创建，TDD有助于确保您的设计是干净的，而AMDD提供了在编写代码之前考虑更大的设计/体系结构问题的机会。
• TDD是非面向视觉的，而AMDD是面向视觉的。
• 这两种技术对传统开发人员来说都是新技术，因此可能对他们构成威胁。
• 这两种技术都支持进化开发。

你应该采取哪种方法?答案取决于你和你的队友的认知偏好。有些人主要是“视觉思考者”，也被称为空间思考者，他们可能更喜欢通过绘画来思考问题。其他人主要是面向文本、非视觉或非空间的思考者，他们不能很好地处理绘图，因此他们可能更喜欢TDD方法。当然，大多数人都处于这两个极端的中间，因此他们更喜欢在最有意义的时候使用每种技术。简而言之，答案是将这两种技术结合起来使用，从而获得两者的优势。

如何将这两种方法结合起来?应该使用AMDD与项目涉众一起创建模型，以帮助研究他们的需求，然后在体系结构和设计模型(通常是简单的草图)中充分地研究这些需求。TDD应该作为构建工作的关键部分来使用，以确保开发干净的、可工作的代码。最终的结果是，您将拥有一个高质量的、能够满足项目涉众实际需求的工作系统。

6. 为什么TDD ?

TDD的一个显著优势是，它允许您在编写软件时采取一些小步骤。这是我多年来一直提倡的一种实践，因为它比尝试以大步骤编写代码的效率高得多。例如，假设您添加了一些新的函数代码，编译并测试它。您的测试很可能会被新代码中存在的缺陷破坏。如果您已经编写了两行代码，那么查找并修复这些缺陷要比编写两千行代码容易得多。这意味着，编译器和回归测试套件运行得越快，就越有吸引力进行越来越小的步骤。在重新编译和重新运行测试之前，我通常更喜欢添加几行新的函数代码，通常少于10行。

我认为Bob Martin说得很好:“编写单元测试的行为更多的是一种设计行为，而不是验证行为。它也更多的是一种文件化的行为，而不是验证的行为。编写单元测试的行为关闭了大量的反馈循环，其中最少的是与功能验证相关的循环。

许多人对敏捷技术的第一反应是，对于小型项目，比如几个月来只涉及少数人的项目，他们是可以接受的，但是对于更大的“真正的”项目，他们就不会工作了。这根本不是真的。Beck(2003)报告了在Smalltalk系统上使用完全测试驱动的方法，该方法花费了4年和40个人的时间，产生了25万行功能代码和25万行测试代码。在20分钟内运行4000个测试，整个套件每天运行几次。虽然有更大的系统，但我个人曾在涉及几百年工作经验的系统中工作过，很明显TDD适用于大型系统。

7. 神话和误解

关于TDD，有几个常见的神话和误解，如果可能的话，我想澄清一下。表1列出了这些神话并描述了现实。

表1。解决围绕TDD的神话和误解。

神话	现实
您创建了一个100%回归测试套件	虽然这听起来是个不错的目标，但不幸的是，这并不现实，原因如下: 我可能有一些可重用的组件/框架/…我下载或购买的软件没有附带测试套件，甚至可能没有源代码。虽然我可以创建黑盒测试来验证组件的接口，但这些测试不会完全验证组件。 用户界面真的很难测试。尽管用户界面测试工具确实存在，但并不是每个人都拥有它们，有时它们很难使用。一个常见的策略是不自动化用户界面测试，而是希望用户测试工作涵盖系统的这个重要方面。这不是一种理想的方法，但仍然是一种常见的方法。 团队中的一些开发人员可能没有足够的测试技能。 数据库回归测试是一个相当新的概念，还没有得到工具的很好支持。 我可能正在处理遗留系统，可能还没有抽出时间为一些遗留功能编写测试。
单元测试构成您的设计规范的100%	刚接触敏捷软件开发的人，或者自称敏捷但实际上并不敏捷的人，或者可能从未参与过实际敏捷项目的人，有时会这么说。实际情况是，单元测试形成了设计规范的一部分，类似的验收测试形成了需求规范的一部分，但是还有更多。正如图4所示，敏捷者实际上会建模(并为此编写文档)，只是我们在如何做这件事上非常聪明。因为在编写产品代码之前要考虑生产代码，所以可以有效地执行详细设计，因为我强烈建议阅读我的单一源代码信息:有效文档的敏捷实践文章。
您只需要进行单元测试	对于除最简单的系统外的所有系统，这都是完全错误的。敏捷社区非常清楚需要大量其他测试技术。
TDD足以进行测试	TDD，在单元/开发人员测试以及客户测试级别，只是您整体测试工作的一部分。它最多包含您的验证性测试工作，但是如图5所示，您还必须关注超出此范围的独立测试工作。有关敏捷测试策略的详细信息，请参阅敏捷测试和质量策略:事实胜于雄辩。
TDD不能扩展	这在一定程度上是正确的，尽管很容易克服。TDD可伸缩性问题包括:   您的测试套件运行时间太长。这是一个具有相同解决方案的常见问题。首先，将您的测试套件分成两个或更多的组件。一个测试套件包含您当前正在处理的新功能的测试，另一个测试套件包含所有测试。您将定期运行第一个测试套件，并将针对生产代码的成熟部分的旧测试迁移到整个测试套件中。整个测试套件在后台运行，通常在单独的机器上运行，并且/或者在晚上运行。在scale上，我看到了几个级别的测试套件——开发沙箱测试在5分钟或更短的时间内运行，项目集成测试在几个小时或更短的时间内运行，测试套件在很多小时甚至几天内运行，但运行的频率更低。在一个项目中，我看到了一个运行了几个月的测试套件(重点是负载/压力测试和可用性)。其次，在这个问题上投入一些硬件。 并不是所有的开发人员都知道如何测试。这通常是正确的，所以让他们接受一些适当的培训，并让他们与具有单元测试技能的人合作。任何经常抱怨这个问题的人似乎都在寻找不采用TDD的借口。 并非每个人都采用TDD方法。采用TDD方法进行开发是团队中的每个人都需要同意做的事情。如果有些人不这样做，那么按照优先顺序:他们需要开始，他们需要离开团队，或者您的团队应该放弃TDD。

图5。敏捷项目团队测试概述。

8. 到底是谁在做这件事?

不幸的是，TDD的采用率没有我希望的那么高。图6总结了2010年的结果:您有多敏捷?提供了关于声称敏捷的团队正在遵循哪些验证策略的洞察。我怀疑开发人员TDD和验收TDD的采用率(分别为53%和44%)比我在2008年测试驱动开发(Test Driven Development, TDD)调查中报告的采用率要实际得多。

图6。敏捷团队如何验证他们自己的工作。

9. 总结

测试驱动开发(TDD)是一种开发技术，在编写新的功能代码之前，必须先编写一个失败的测试。TDD正在被敏捷软件开发人员迅速采用，用于开发应用程序源代码，甚至被敏捷dba用于数据库开发。TDD应该被看作是敏捷模型驱动开发(AMDD)方法的补充，并且这两者可以并且应该一起使用。TDD并没有取代传统的测试，相反，它定义了一种经过验证的方法来确保有效的单元测试。TDD的一个副作用是，生成的测试是用于调用代码的工作示例，从而为代码提供了一个工作规范。我的经验是，TDD在实践中工作得非常好，所有软件开发人员都应该考虑采用TDD。

10. 工具

下面是您可以使用的TDD工具的代表性列表。请给我发电子邮件提出建议。我还维护了一个敏捷数据库开发工具列表。

• cpputest
• csUnit (.Net)
• CUnit
• DUnit (Delphi)
• DBFit
• DBUnit
• DocTest (Python)
• Googletest
• HTMLUnit
• HTTPUnit
• JMock
• JUnit
• Moq
• NDbUnit
• NUnit
• OUnit
• PHPUnit
• PyUnit (Python)
• SimpleTest
• TestNG
• TestOoB (Python)
• Test::Unit (Ruby)
• VBUnit
• XTUnit
• xUnit.net

.Net developers may find this comparison of .Net TDD tools interesting.

 

原文：http://agiledata.org/essays/tdd.html

本文：https://pub.intelligentx.net/node/710

讨论：请加入知识星球或者小红圈【首席架构师圈】

目录

 

1. 概观
2. 构想
   1. 最初的敏捷需求建模
   2. 最初的敏捷架构建模
3. 迭代建模
4. 模型风暴
5. 通过TDD执行的规范
6. 评测
7. AMDD有何不同？
8. 为什么这样做？
9. AMDD的方法

1.概述

顾名思义，AMDD是模型驱动开发（MDD）的敏捷版本。 MDD是一种软件开发方法，在编写源代码之前会创建大量模型。 MDD的一个主要示例是对象管理组（OMG）的模型驱动架构（MDA）标准。使用MDD经常采用连续的开发方法，MDD在传统主义者中很受欢迎，尽管RUP / EUP显示可以采用MDD的迭代方法。与AMDD的不同之处在于，不是在编写源代码之前创建大量模型，而是创建敏捷模型，这些模型只是勉强足以推动整体开发工作。 AMDD是一种关键的策略，用于扩展敏捷软件开发，而不是我们在敏捷采用的第一阶段看到的小型，共址的团队方法。

图1描绘了AMDD用于发布系统的高级生命周期。首先，让我们从如何阅读图表开始。每个框表示一个开发活动。设想包括两个主要的子活动，初始要求设想和初始架构设想。这些是在Inception期间完成的，迭代是循环或sprint的另一个术语。 “迭代0或初始化”是开始进行开发迭代之前第一次迭代的常用术语，它是迭代一次（对于该版本）。其他活动 - 迭代建模，模型风暴，评论和实现 - 可能在任何迭代期间发生，包括Inception。每个方框中指示的时间表示平均会话的长度：也许您将建模几分钟然后代码几个小时。我将在下面更详细地讨论时序问题。

图1. AMDD生命周期：在项目的整个生命周期中建模活动。

图2描述了AMDD活动如何适应敏捷软件开发生命周期的各种迭代。 这只是表明敏捷项目从一些初始建模开始的另一种方式，并且建模仍然发生在每个构造迭代中。

图2.通过敏捷开发生命周期的AMDD。

2.构想

预想工作通常在项目的第一周执行，其目标是确定系统的范围以及解决它的可能架构。为此，您将执行高级需求建模和高级体系结构建模。我们的目标不是编写详细的规范，在实践中证明风险非常大，而是探索需求并为您的项目制定总体战略。对于短期项目（可能持续数周），您可以在最初的几个小时内完成这项工作，对于长期项目（可能是12个月或更长时间），您可能决定投入两周时间。我强烈建议不要投入更多的时间，因为你冒着过度建模和建模包含太多问题的东西的危险（在我看来，两周没有实施提供的具体反馈是很长时间的风险） 。

通过初始的高级建模，您可以获得指导项目所需的知识，但选择等待对其采取行动。

2.1初始需求建模

对于系统的第一个版本，您需要花费几天时间来确定一些高级需求以及发布的范围（您认为系统应该做什么）。目标是获得一个良好的直觉，感受项目的全部内容。对于您的初始需求模型，我的经验是您需要某种形式的使用模型来探索用户如何使用您的系统，初始域模型识别基本业务实体类型以及当时之间的关系，以及探索的初始用户界面模型用户界面和可用性问题。

我不能这么说：你的目标是建立一个共同的理解，它不是写详细的文档。一个关键的成功因素是使用包容性建模技术，使利益相关者积极参与。

2.2初始架构建模

初始架构建模工作的目标是尝试识别具有良好工作机会的架构。这使您能够为项目设置（希望）可行的技术方向，并提供足够的信息来围绕您的架构组织您的团队（对于大型或分布式团队而言，这一点尤为重要）。

在体系结构方面，我经常会创建自由形式的图表，探索技术基础架构，初始域模型以探索主要业务实体及其关系，并可选择更改案例以探索系统可能需要的潜在架构级需求支持一天。在以后的迭代中，您的初始需求和初始架构师模型都需要随着您了解更多而发展，但目前的目标是获得一些不够好的东西，以便您的团队可以开始工作。在随后的版本中，您可以决定将Inception缩短为几天，几个小时，甚至根据您的情况完全删除它。秘诀是保持简单。您不需要为很多细节建模，只需要足够的模型。如果您正在编写用例，这可能意味着点状注释足够好。如果您正在建模白板草图或CRC卡集合可能已经足够好了。对于您的体系结构，白板草图概述了系统如何端到端构建，这已经足够了。

许多传统开发人员都会采用灵活的初始建模方法，因为多年来他们被告知需要在项目早期定义综合模型。敏捷软件开发不是连续的，它是迭代的和渐进的（进化的）。通过演化方法，在模型存储会话的开发迭代期间，及时（JIT）完成详细建模。

3.迭代建模：思考你将要做什么这个迭代

在每次构建迭代开始时，团队必须计划他们将执行该迭代的工作。 Mike Cohn计划扑克中经常被忽视的一面是该技术所暗示的必要建模活动。敏捷团队按优先级顺序实现需求，请参见图3，将迭代的工作量从堆栈顶部移除。要成功完成此任务，您必须能够准确估计每个需求所需的工作，然后根据您之前的迭代速度（衡量您完成的工作量），从堆栈中选择那么多工作。例如，如果最后一次迭代你完成了15分的工作，那么假设所有事情都是平等的，那么你将能够在这次迭代中完成那么多工作。此活动通常被称为“计划游戏”或简称迭代计划。敏捷建模

图3.敏捷需求变更管理流程。

 

要准确地估计每个需求，您必须了解实现它所需的工作，这就是建模的用武之地。您将讨论如何实现每个需求，在适当的位置建模以探索或交流想法。这种建模实际上是对迭代实现的需求的分析和设计。

通过初始迭代建模，您可以探索构建所需的内容，以便有效地估计和规划迭代的工作。

4.模型风暴：及时（JIT）建模

我的经验是，绝大多数建模会话都涉及一些人，通常只有两三个人，他们在纸上或白板上草绘时讨论问题。这些“模型风暴会议”通常是即兴事件，一个项目团队成员会要求另一个人与他们一起建模，通常持续5到10分钟（风暴模型超过30分钟很少见）。人们聚在一起，聚集在一个共享的建模工具（例如白板）周围，探索问题直到他们对他们理解它们感到满意，然后他们继续（经常编码）。模型风暴即时（JIT）建模：您确定了需要解决的问题，您可以快速抓住一些可以帮助您的团队成员，小组探讨问题，然后每个人都像以前一样继续。极端程序员（XPers）会称模拟风暴会议直立式设计会议或客户问答会议。

5.通过测试驱动开发（TDD）的可执行规范

在开发过程中，将风暴模型设置为几分钟，然后按照常见的敏捷实践（例如测试优先设计（TFD）和重构）进行编码几个小时甚至几天，以实现您刚刚建模的内容是很常见的。 。为了便于讨论，测试驱动设计（TDD）是TFD和重构的结合。这是你的团队将花费大部分时间的地方，遗憾的是，图1不能很好地沟通。敏捷团队以可执行规范（通常是客户测试或开发测试）的形式完成大部分详细建模。为什么这样做？因为您的模型攻击工作使您能够思考更大的跨实体问题，而使用TDD，您可以通过非常集中的问题来思考，这些问题通常与单个实体一致。通过重构，您可以通过小步骤改进设计，以确保您的工作保持高质量。

TDD促进您的应用程序代码的验证测试和该代码的详细规范。客户测试（也称为敏捷验收测试）可以被视为详细需求和开发人员测试的一种形式，作为详细设计。像这样做“双重职责”的测试是单一来源信息的完美例子，这种做法使开发人员能够轻松地减少整体文档。但是，详细的规范只是整体情况的一部分 - 高级规范对于您的成功也是至关重要的。这就是我们需要超越TDD考虑AMDD的原因。

您甚至可能希望使用诸如Rational Software Architect（RSA）之类的复杂建模工具进行“可视化编程”。这种方法需要比大多数开发人员通常更多的建模技能组，尽管当您拥有由具有这些技能的人组成的团队时，您会发现使用正确的建模工具可以提高工作效率。

6.评论

您可以选择保留模型评论甚至代码检查，但正如我在模型评论中写的：最佳实践或过程气味？这些质量保证（QA）技术似乎在敏捷软件开发中似乎已经过时，至少在小型软件开发中是这样。在较大的团队或非常复杂的情况下，评论可以增加价值，因为当他们做得好时，他们会为您的IT治理工作提供出色的反馈。

7. AMDD有何不同？

从设计的角度来看，图1的AMDD方法与传统开发方法非常不同，在传统开发方法中，您首先创建设计模型然后从中编写代码。使用AMDD，您可以进行一些建模，然后进行大量编码，并在需要时进行迭代。您的设计工作现在分散在您的建模和编码活动之间，大多数设计都是作为实施工作的一部分完成的 - 在许多方面，对于许多传统项目来说也是如此，开发人员通常会做的事情与在设计模型中，设计师经常责怪开发人员，而不是质疑他们过于连续的流程。

AMDD与诸如特征驱动开发（FDD）或EUP和敏捷统一过程（AUP）的用例驱动开发（UCDD）样式之类的技术不同，因为它没有指定要创建的模型的类型。所有AMDD建议你应用正确的工件，但它并不坚持该工件是什么。例如，FDD坚持认为特征是您的主要要求，而UCDD坚持认为用例是。 AMDD适用于FDD或UCDD方法，因为消息类似 - 所有三种方法都说在编码之前建模是个好主意。

图1的一个有趣的含义是让那些只是在您的开发团队中建模专家的人没有任何意义。他们要做什么，模拟几分钟然后坐一小时或几天直到他们再次需要？真正需要的是我称之为概括专家，在整个生命周期中具有一个或多个专业知识以及一般技能的人，他们既可以编码，也可以在他们需要建模时使用。

8.为什么这样做？

AMDD的工作原因有以下几点：

1. 您仍然可以满足您的“项目计划需求”。通过尽早确定高级需求，并通过尽早识别潜在架构，您可以获得足够的信息来生成初始成本估算和计划。
2. 您管理技术风险。您最初的架构建模工作使您能够在项目早期识别技术风险的主要区域，而不会承担过度建模系统的风险。这是建筑建模的实用“中间道路”方法。
3. 你最大限度地减少浪费。 JIT的建模方法使您可以专注于您实际要构建的系统的各个方面。使用串行方法，您通常可以模拟系统中没有人真正想要的方面。
4. 你问更好的问题。等待风暴需求的时间越长，您对域名的了解就越多，因此您就可以提出更加智能的问题。
5. 利益相关者提供更好的答案。同样，您的利益相关者将更好地了解您正在构建的系统，因为您将定期交付工作软件，从而为他们提供具体的反馈。

9. AMDD的方法

在项目中应用AMDD有三种基本方法：

1. 手册。使用简单的工具（如白板和纸张）和包容性模型进行建模。这可能是所有业务应用程序建模工作的70-80％。
2. 设计工具。包容性模型用于探索利益相关者的需求，并分析这些需求。然后，开发人员使用复杂的建模工具进行详细设计，（重新）从模型中生成源代码。这可能是所有业务应用程序建模工作的20-30％。
3. 敏捷MDA。非常复杂的基于MDA的建模工具，用于创建生成工作软件的大量模型。最好，这种方法将用于5-10％的业务应用程序建模工作。

 

原文：http://www.agilemodeling.com/essays/amdd.htm

本文：https://pub.intelligentx.net/agile-model-driven-development-amdd-key-scaling-agile-software-development

讨论：请加入知识星球或者小红圈【首席架构师圈】

敏捷数据（AD）方法定义了一系列策略，IT专业人员可以在各种情况下应用这些策略，以便在软件系统的数据方面有效地协同工作。 这并不是说AD是“一刀切”的方法。 相反，将AD视为一系列技术和理念，使您的组织内的IT专业人员能够在基于软件的系统的数据方面有效地协同工作。

现代软件开发过程 - 例如纪律敏捷交付（DAD），极限编程（XP），Scrum和团队软件过程（TSP） - 本质上都是迭代和增量（演化）。他们中的每一个。一些现代方法，特别是XP和Scrum，本质上是敏捷的（为了简单起见，我们将敏捷软件开发定义为高度协作和进化的方法）。然而，面向数据的软件开发方面的传统方法往往是连续的，而不是进化的，当然也不是敏捷的。这是一个严重的问题。

数据一直是我构建的每个业务应用程序的一个重要方面。然后，业务规则，用户界面，网络和一系列其他问题也是如此。我的经验是，留给他们自己的设备软件开发人员通常很难正确地获取数据，并且通常会从企业数据的角度做出可疑的决策。我的经验也是许多数据专业人员难以使用，通常是因为他们陷入了“串行方式”，而且因为他们在现代软件开发技术之后几乎没有经验。这两个观察结果反映了两组之间的文化阻抗不匹配，这个问题经常被两组工作的两种技术（基于对象和关系）之间的技术阻抗不匹配所掩盖。

概观

我认为我们需要找到有效合作的方法，并且IT组织必须承担五项基本任务：

1. 采用新的哲学基础。敏捷数据方法和支持敏捷数据库技术描述了一种有成功机会的方法，因为它描述了人们实际工作的方式。这不仅仅是一个听起来很棒的学术理论集合。敏捷数据方法的核心在于其理念和作用。这些哲学听起来很简单但在实践中对你采取行动有重大意义：我的经验是，重新思考你的软件开发方法，重新组织你的组织文化，以便在软件开发游戏中取得成功，这在实践中将证明是困难的。
2. 帮助开发人员和数据专业人员采用渐进式（如果不是敏捷的）数据库技术。这包括敏捷数据建模，数据库重构，数据库回归测试，测试驱动开发（TDD）以及适当地封装数据库访问。我们都必须认识到我们需要变得更敏捷，我们可以采用灵活的方法来建模和记录，数据模型不会驱动对象模型（反之亦然），我们需要新的工具，我们应该在我们的独立开发沙箱。采用通用的敏捷数据库最佳实践也是一个非常好的主意。
3. 帮助开发人员学习基础数据技术这包括数据建模，将对象映射到RDB（O / R映射）以及使用遗留数据。开发人员还应该了解如何为表，关系数据库基础，XML，参照完整性和共享业务逻辑选择主键策略，如何从RDB检索对象，如何实现报表，安全访问控制，事务控制和并发控制。
4. 帮助数据专业人员学习基本的开发技术。这包括学习面向对象的基础知识和统一建模语言（UML）以及如何使用UML进行数据建模。
5. 采用敏捷方法进行企业工作。您的企业架构和企业管理（包括运营数据管理）小组需要变得更加灵活，才能在现代IT环境中取得成功。我们不仅可以采用敏捷的企业方法，我相信它比传统的传统技术更可取，因为它可以更好地响应组织的实际需求。

其他重要链接：

• About This Site
• Adopting Agile Database Techniques
• Agile Databases Mailing List
• Architecture and Architectural Modeling Techniques 
• Choosing the Right Software Method for the Job
• Case Studies and Experience Reports
• Help Page
• Links Page
• Join the Discussion Forum
• References
• Site Map
• Suggested Books

 

原文：http://agiledata.org/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

一种常见的敏捷实践是在生命周期的早期执行一些高级架构建模。这有助于在团队内部和关键利益相关者之间形成关于您的技术战略的共同点。此时的目标是确定架构策略，而不是编写大量文档。您将在开发周期后期通过JIT模型存储会话和TDD处理设计细节。本文讨论了几个关键问题：

• 什么时候应该进行初步的敏捷架构建模？
• 为什么要进行一些初始敏捷架构建模？
• 你最初应该建模什么？
• 你应该使用什么建模工具？
• 你真的需要做多少建模？
• 为什么你需要做的初始架构建模比你想象的要少？
• 人们真的这样做吗？
• 分开的想法

1.您应该何时进行初始敏捷架构建模？

敏捷模型驱动开发（AMDD），参见图1，明确包括敏捷项目的迭代0期间的初始架构建模工作（某些进程可能称之为预热，启动或启动阶段）。初始体系结构建模对于将敏捷软件开发技术扩展到大型，复杂或全球分布式开发（GDD）工作尤为重要。

图1. AMDD生命周期：项目视点。

2.为什么要进行一些初步的敏捷架构建模？

有些人会告诉你，根本不需要进行任何初始架构建模。但是，我的经验是，以敏捷方式进行一些初始架构建模可以带来以下好处：

• 提高生产力。您可以考虑项目所面临的一些关键技术问题，并可能避免失去无用的技术路径。
• 降低技术风险。您的团队可以获得具有指导性愿景的优势，而不必过度构建您的系统 - 仅仅因为您已经建模它并不意味着您必须构建它。
• 缩短开发时间。最初的敏捷架构建模使您能够为项目提供更好的成本和时间估算，这是管理层需要的两条信息。
• 改善沟通。拥有高级架构模型可以帮助您沟通您认为自己将要构建的内容以及您认为构建它的方式，这是管理层所需的两个更重要的信息。
• 扩展敏捷软件开发。您的初始架构模型将成为任何“大规模敏捷”工作中的关键工作产品，因为它提供了子团队在整个项目中定义和指导其工作所需的技术指导。
• 改善团队组织。围绕建筑或业务线组织有效的团队，而不是围绕工作职能。当您扩展到更大的和/或分布式团队时，子团队应该分别负责一个或多个子系统 - 您不希望围绕工作职能组织您的子团队（例如，架构团队，开发团队） ，测试团队，......）因为这需要您增加文档和官僚机构的开销，从而增加风险，成本和价值实现时间。

3.企业架构实用指南

你最初应该建模什么？

在项目早期，您至少需要了解如何构建系统。它是大型机COBOL应用程序吗？一个.Net应用程序？ J2EE？别的什么？为此，项目的开发人员将聚集在一个房间，通常围绕白板，讨论，然后勾画出系统的潜在架构。此建模工作基于您的初始高级需求建模工作，并与之并行执行。您的架构将随着时间的推移而发展，因此它不需要非常详细（它现在只需要足够好），并且需要编写很少的文档（如果有的话）。

当我进行初始架构建模时，我通常会关注高级自由格式图表，这些图表概述了我们如何构建系统。我通常会关注：

• 技术图
• 用户界面（UI）流程
• 领域模型
• 改变案例

 

3.1技术图

通常某种形式的技术堆栈图（图2）或部署图都可以（图3）。 这些图非常有用，因为它们描述了主要的软件和硬件组件以及它们如何在高级别上进行交互。 这包括遗留资产，包括遗留数据库和遗留系统，可能需要在项目后期更详细地进行分析。 现在，您的目标应该是识别这些资产，并讨论它们作为系统功能和/或数据来源的可行性。

图2.技术堆栈图

图3. UML部署图。

您还将在此时确定技术限制。 例如，尽管您希望使用最新版本的DB2，但遗憾的是您的企业数据库标准是Oracle（如图2所示），因此您在该架构选择中受到限制。

3.2用户界面流模型

要创建的另一个常见图表是用户界面（UI）导航或UI流程图，请参见图4，以探索如何通过探索主要UI元素（包括屏幕/页面和报告）之间的流程来构建系统的UI。 这对您的系统的成功至关重要，因为用户界面是您的利益相关者的系统。 不是技术。 不是数据。 你正在使用的框架并不是很酷。 如果您没有有效地构建用户界面，那么您将面临构建利益相关者不感兴趣的系统的风险。

图4. UI流程图。

3.3域模型

初始架构建模工作的一部分，特别是业务应用程序，可能包括高级域模型的开发，如图5所示。此模型应该非常小，捕获主要业务实体及其之间的关系。有些人认为这种类型的模型是初始需求模型而不是初始架构模型 - 它并不重要，因为正如您在图1中看到的那样，这两个初始建模工作无论如何都是并行执行的。图5描绘了使用UML数据建模符号的示例（您可以使用您在敏捷数据建模时喜欢的任何符号，我更喜欢UML）。初始域模型将用于帮助指导物理数据模型以及类设计，可能通过UML类图捕获。我最初会使用白板创建这种类型的图表，然后如果这样做的努力提供了足够的价值，我可能会将其转移到绘图工具中。

图5.初始域模型。

3.4变更案例

最后，我有时会考虑捕获的另一种常见架构模型是更改案例，这些更改案例是系统可能需要支持的潜在架构级别要求。图6提供了两个变更案例的示例，描述了潜在的技术变化，第二个变更了潜在的业务变化。更改案例允许您测试架构的长期可行性，而无需过度构建系统，因为您可以考虑可能的更改的影响，以确保您的系统仍然可以工作。

图6.两个更改案例。

• 变更案例：注册将完全通过互联网进行。
• 可能性：中等可能性在两到三年内，很可能在十年内。
• 影响：未知。虽然注册将于9月开始在线提供，但我们目前预计今年将通过互联网进行不到四分之一的注册。在高峰使用期间，响应时间将是一个问题，这是在每个学期开课前两周，以及课程的第一周。

-------------------------------------------------- -------------------------------------------------- --------

• 改变案例：大学将开设一个新校区。
• 可能性：确定。据宣布，新校区将在两年内开放。
• 影响：大。学生可以在任一校区的课程中注册。一些教师将在两个校区任教。一些部门，如计算机科学和哲学，计划将他们的整个课程搬到新校区。大多数学生只想在两个校区之一安排课程的可能性很大，所以我们需要让这个很容易支持。

•  

4.您应该使用哪些建模工具？

敏捷建模者将使用最简单的工具来完成工作。正如您在图2和图4中所看到的，我发现白板图通常足以满足初始架构模型的需要。您的目标是在生命周期的这一点思考关键技术问题，而不是创建漂亮的图表。使用更复杂的绘图工具没有任何问题，如图3和图5所示，只需确保您投入的投资是值得的。这一切都取决于你工作的情况。此外，纸质工具也很常见。例如，我很想在索引卡上捕获图6的更改案例，并且只在适当时使用更复杂的工具捕获它们。

5.你应该做多少初步的建筑模型？

让我们考虑一下项目团队可能会遇到的几种常见情况，然后再考虑在这种情况下多少架构建模。这些情况是：

• 您的团队正在使用之前已经使用过的已知技术。这是你可以找到的最简单的情况，最多我怀疑你需要创建一个单一的白板草图，以确保每个人都在努力达到同样的愿景，坦率地说，你可能甚至不需要这样。例如，如果这是您的团队使用Websphere和DB2构建的第十个基于Web的应用程序，那么您真正需要做多少架构建模？
• 您对这些技术几乎没有经验。传统主义者经常告诉你，为了降低你应该详细模拟一切的风险，但是如果你退后一步思考它，这实际上会增加你的风险。当你不知道自己在做什么时，做很多详细的建模真的有意义吗？不，所有可能实现的是你浪费了大量时间，写了很多文档，开发人员可能会忽略这些文档，因为他们很快就会知道你不知道你在说什么，它给你错误的信心，你知道你在做什么，这可能会给管理层一种错误的信心，即团队有一个坚实的架构计划。你真正想做的是做一些建模，以帮助你识别你不知道的东西，如果可能的话，你想邀请那些有你缺席经验的团队成员。然后，您需要通过建筑原型设计/尖峰技术获得实际技术本身的实践经验，然后基于该经验发展您的建筑模型，以便它们反映实际工作的内容。换句话说，让您的架构在整个项目中出现。
• 在中间的某个地方。这是您通常会发现自己的地方：也许您有一些但不是所有技术的经验，或许您的团队对这些技术有经验，但根本没有将它们全部一起使用。在诸如此类的中间情况下，最初（甚至几天）进行更多建模是有意义的，以便识别潜在风险和可能的减轻风险的策略。在这种情况下，建模是有意义的，因为它使您能够在团队中定义共享的技术愿景，并可能通过重大问题进行思考。换句话说，一些初始架构建模将为您的团队提供价值。

图7描绘了建模的价值，表明模型在它们几乎不够好时达到它们的最大值点，并且对于初始架构设想，这通常是在几天或一周左右之后。很多人最初对这种说法感到震惊，但是当你回想起你曾经参与过的所有项目时，如果你被允许的话，有多少项目，你可以在一周之内建立一个非常好的初始架构策略把几个聪明的人放在一个有很多白板的房间里？我现在已经问了几千人的这个问题，只被告知了一些不真实的项目。很多人认为他们有例子没有成功，但他们的问题几乎总是围绕着无法让那些知道自己在做什么的人或者让人们聚集在一起的后勤问题。需要超过一周的人员处于团队分布的情况下，因此他们需要投入更多时间来识别子系统/组件及其接口，以便他们可以围绕实施这些子系统或子组件来组织子团队（a实践称为API First或Conway's Law）。或者他们正在研究生命关键系统（或者在几个军事项目中的死亡关键系统），或者处于需要对软件或硬件进行大量投资的情况下。

图7.建模的价值。

6.为什么你需要做比传统主义者更少的初始建模？

传统建模者假设需要在项目开始时详细建模问题和解决方案域。我将此称为“大型建模前端（BMUF）”，其中包含“前期大需求（BRUF）”，您可以在生命周期的早期创建详细的需求规范，并在此处“大型设计预先（BDUF）”在生命周期的早期创建详细的需求规范。当你是一名建模专家时，这些做法是有意义的，而且确实有足够的传统建模者似乎总是有理由说明BMUF为什么是理想的。表1总结了在项目早期进行详细架构模型的常见论据，并论证了为什么它们是错误的。

表1.建筑BMUF的论点和反驳论据。

争论	相反的观点
我们可以预先考虑技术细节	对于非常简单的系统可能也是如此，但对于即使是中等复杂的系统，由于每种技术的各种细微差别，组件的使用模式不断变化以及技术本身的变化，我们也无法通过细节进行思考。 看起来您的建筑模型中的所有内容都可以正常工作，但在您使用代码证明它之前，然后根据您所学到的内容采取行动，您将永远无法确定。 最好的架构随着时间的推移而发展，它们不是预先定义的。
我们需要确定最佳技术战略	是的，您需要确定一个好的策略，但这并不意味着您需要编写大量详细的文档。 使用BDUF方法时，如果您对问题域的了解最少，则会要求您做出严肃的技术决策，从而增加选择错误路径的可能性。 精益/敏捷方法建议您在最后可能的时刻做出这些决定，而不是在开始时。
我们需要首先建立技术基础	您需要一个技术愿景来努力实现团队成员之间的良好沟通/协作。 详细的架构/设计会激励您过度构建系统 - 它在设计中，因此无论利益相关者是否真的需要，您都可以更好地构建它。 有多少次你看到项目团队在项目的前六个月花费了大量的框架来构建支持所有未来需求的框架，却发现根本不需要很多框架？ 除非你完全正确地完成设计，这在实践中很难做到，否则你最终的建设将远远超出你的需求。
我们需要为编码器指定设计	编码员真的很聪明。 他们可能需要一些指导和领导，但他们很可能不需要详细说明该做什么。 事实上，当您向编码员提供详细的架构时，您会将项目置于风险之中。 一些程序员可能会选择不遵循设计，因为他们相信他们知道的更好（也许他们知道）。 更糟糕的是，您所做的建模和文档越多，由于您在工作中所做的投资，您将承诺采用文档化方法的可能性就越大。 即使已知设计存在问题，也会发生这种情况，因为一旦您开始沿着特定路径重新设计方法，通常会花费太多精力。
架构软件就像构建桥梁一样	桥梁类比通常是这样的：“构建桥梁是一件非常复杂的事情，就像构建软件一样。桥梁构建者预先创建复杂的蓝图然后为这些计划工作，因此我们也应该做同样的事情。” 如果某人没有建立桥梁和构建软件的直接经验，那么我们不应该质疑他们的假设吗？ 我认识一些物理建筑师，他们的工作方式比你想象的更具创造性和进化性。 为了看到一位世界级的建筑师在行动，我强烈建议观看纪录片“Frank Gehry的草图”。 我可以非常安全地说Gehry是一个敏捷的建模者，而不是传统的建模师。 所以，也许桥梁类比确实存在，但不是传统主义者的想法。
应根据需求详细定义体系结构	当您在家中装修房间时，您是否曾尝试完全指定您的设计？无论你付出多少努力，你总会发现沙发处于错误的角度，墙壁艺术不适用于地毯，等等。你总是需要调整你的设计，有时甚至做出重大改变。如果你不能做一些简单的事情，比如预先指定一个房间的装饰，那么你认为你可以为一个更复杂的数量级的系统做同样的事情吗？人们不知道他们想要什么;他们至多可以理解他们的目标/意图。人们非常善于说出他们不喜欢的东西，并提供可能改进的建议。这意味着需要采用渐进的方法来定期获得反馈，而不是基于文档的连续方法。当然，这假设您实际上想要建立一个反映其利益相关者需求的系统。底线是需求在整个项目中发生变化，您需要接受并相应地采取行动。
详细的文档和模型增加了价值	这个论点可能部分正确，尽管在生命周期的早期编写全面的文档是错误的时间。 敏捷建模建议您仅在捕获的信息已稳定且有人理解并愿意承担该文档的总体拥有成本（TCO）时才编写文档。 您不希望记录投机性事物，并且在生命周期的早期记录需求和建议的设计显然是推测性的，因为投机性事物倾向于改变，从而提高该文档的TCO。
没有证据表明进化技术是有效的	实际上，是的。 当人们要求“无可辩驳的证据”时，他们经常说的是他们不想偏离他们偏好的工作方式。 采用传统方法的证据远远少于我们今天支持进化方法的证据，而且我认为传统的记录不言自明 - 如果你愿意接受它，证据就明确指出了BMUF。

 

Think big but act small.

 

7.人们实际上是这样做的吗？

是!以下是我多年来所做的几项调查的一些证据：

初始架构建模有效。在2007年3月的DDJ Agile Adoption Rate调查中，我问的一个问题是敏捷团队的初始敏捷架构建模有多么有效。结果总结在图8的直方图中。正如您所看到的，敏捷实际上确实在实践中进行了模型化。 77％的受访者表示他们的组织正在使用敏捷，这表明这些团队也在进行初步的高级敏捷架构建模，并且88％的团队认为这些努力是值得的（他们给出的评级为3或更高） 5）。

大多数敏捷团队正在进行初始架构建模。图8显示77％的敏捷团队正在执行初始架构建模。表2总结了2009年敏捷项目启动调查的结果，显示83％的受访者表示他们在最近的敏捷项目中进行了某种形式的架构建模。它还表明，一些团队正在利用企业模型，希望他们能够与敏捷的企业架构团队进行交互，有时甚至是行业模型。

正在应用各种策略。 DDJ 2008建模和文档调查发现，草图绘制是最常见的主要建模方法（参见图9）。它还发现，敏捷主义者比传统主义者更有可能在软件开发项目上进行建模。最后，它发现一些敏捷团队正在使用基于软件的建模工具（SBMT），也称为计算机辅助软件工程（CASE）工具。

基于Internet的开发很常见。许多开源系统和其他共享源环境采用一种方法，在他们开始工作时，就如何构建某些内容以及一些工作代码达成一致意见。

图8.敏捷团队建模的采用率。

表2.敏捷项目团队初始架构策略的采用率（2009年敏捷项目启动调查）。

Rate	Strategy	Discussion
70%	高级初始架构建模	我很惊讶这个数字并不高，尽管暗示正在进行详细的初始架构建模的团队很可能也在进行高级初始架构建模是合理的。 如下所示，76％的团队进行某种初始架构建模。
25%	详细的初始架构建模	我很惊讶这个数字很高，也许这表明组织尚未完全从传统战略过渡到敏捷战略。
12%	最初的架构模型提供给团队	不幸的是，我没有问为什么会发生这种情况。 可能的原因是这是由于瀑布驱动的合同，例如 在外包情况下，客户为系统开发IT架构并将其提供给服务提供商，或者组织仍然具有瀑布驱动的治理策略，其中架构工作由不同于开发系统的团队执行。
14%	使用企业模型作为参考	显然，一些敏捷团队实际上采用了严谨的开发方法，他们利用企业模型，更好地与敏捷的企业架构师密切合作。
12%	使用行业模型作为参考	在某些行业，例如保险业或电信行业，有行业联盟或大型供应商（例如IBM），它们产生“行业标准”架构模型。 这些模型的目标是它们应该有助于推动开发项目的一些业务架构。 行业联盟模型的一个例子是ACORD保险数据标准，供应商提供的模型的一个例子是IBM保险应用程序架构。
76%	做某种形式的初始架构建模（高级或详细）	超过四分之三的敏捷团队进行某种初始架构建模。 这个速率非常接近DDJ Agile Adoption Rate调查发现的初始敏捷架构建模的77％。
83%	进行某种形式的初始架构建模（高级或详细）或提供初始架构模型	8个敏捷团队中有近7个基于某种初始架构模型开展工作。
86%	进行某种形式的初始架构建模，或提供初始模型，或利用可用模型（企业或行业）	绝大多数团队采用模型驱动的架构方法。 然而，这并不意味着他们创建了巨大的建筑大纲（正如您所看到的，只有少数敏捷团队似乎这样做，而大多数人采取轻量级，高级别的方法）。

Figure 9. Primary approaches to modeling.

8.分手思考

您应该努力为手头的情况做足够的建模，而不是更多。这意味着每个项目团队将做多少建模没有一个正确的答案，相反，它会因团队而异。我的理念是，可重复的结果，在这种情况下，在团队中具有共享的架构愿景，远比遵循可重复的流程更重要，该流程确保每个团队每次都进行相同数量的建模。

在以后的迭代中，您的初始需求和初始架构师模型都需要随着您了解更多而发展，但目前的目标是获得一些不够好的东西，以便您的团队可以开始工作。在后续版本中，您可以决定将迭代0缩短到几天，几个小时，甚至可以根据您的情况完全删除它。秘诀是保持简单。您不需要为很多细节建模，只需要足够的模型。如果您正在编写用例，这可能意味着点状注释足够好。如果您正在建模白板草图或CRC卡集合可能已经足够好了。对于您的体系结构，白板草图概述了系统如何端到端构建，这已经足够了。我不能这么说：你的目标是建立一个共同的理解，它不是写详细的文档。一个关键的成功因素是使用包容性建模技术，使利益相关者积极参与。

许多传统开发人员都会采用灵活的初始建模方法，因为多年来他们被告知需要在项目早期定义综合模型。敏捷软件开发不是连续的，它是迭代的和渐进的（进化的）。通过演化方法，在模型存储会话的开发迭代期间，及时（JIT）完成详细建模。

 

原文：http://agilemodeling.com/essays/initialArchitectureModeling.htm

本文：https://pub.intelligentx.net/architecture-envisioning-agile-core-practice

讨论：加入知识星球或者小红圈【首席架构师圈】

 

数据建模是探索面向数据的结构的行为。与其他建模工件一样，数据模型可用于各种目的，从高级概念模型到物理数据模型（PDM）。物理数据建模在概念上类似于设计类建模，目标是设计数据库的内部模式，描述数据表，这些表的数据列以及表之间的关系。

图1显示了该大学的部分PDM  - 您知道，由于Seminar表包含未显示的表的外键，并且坦率地说很多领域概念，例如课程和教授，这一事实并不完整。显然没有建模。除了其中一个框之外的所有框都代表表，一个例外是UniversityDB，它列出了在数据库中实现的存储过程。因为图中给出了构造型物理数据模型，所以您知道类框表示表，没有图构造型，我需要在每个表上使用构造型表。表之间的关系使用标准UML表示法建模，尽管在示例中未示出，但是对表之间的组合和继承关系进行建模是合理的。通过使用密钥实现关系（更多内容见下文）。

图1.大学的部分PDM。

在进行物理数据建模时，以迭代方式执行以下任务：

1. 识别表格。表是数据库的等价类;数据存储在物理表中。如图1所示，大学有一个学生表来存储学生数据，一个课程表来存储课程数据，等等。图1使用基于UML的表示法（这是一个公开定义的配置文件，任何人都可以提供输入）。如果你有一个类模型，一个好的开始就是将类与数据表进行一对一的映射，这种方法在“绿地”环境中运行良好，你可以从头开始设计数据库模式。 。因为这在实践中很少发生，所以您需要准备好受一个或多个遗留数据库模式的约束，然后您需要将类映射到。在这些情况下，您不太可能需要进行大量数据建模，您只需要学会使用现有数据源，但您需要能够阅读和理解现有模型。在某些情况下，您可能需要先执行旧数据分析并对现有模式进行建模，然后才能开始使用它。
2. 规范化表格。数据规范化是一个过程，在这个过程中，数据模型中的数据属性被组织起来，以增加表的内聚力并减少表之间的耦合。基本目标是确保数据存储在一个且只有一个地方。这是应用程序开发人员的一个重要考虑因素，因为如果数据属性存储在多个位置，将对象存储在关系数据库中是非常困难的。图1中的表格为第三范式（3NF）。
3. 识别列。列是数据库的等效属性，每个表都有一列或多列。例如，Student表具有FirstName和StudentNumber等属性。与类中的属性（可以是基本类型或其他对象）不同，列可以只是基本类型，例如char（字符串），int（整数）或float。
4. 识别存储过程。存储过程在概念上类似于由数据库实现的全局方法。在图1中，您可以看到，诸如averageMark（）和studentsEnrolled（）之类的存储过程被建模为UniversityDB类的操作。这些存储过程实现了与数据库中存储的数据一起使用的代码，在这种情况下，它们计算学生的平均分数并分别计算在给定研讨会中注册的学生数。虽然这些存储过程中的一些明确地对单个表中包含的数据起作用，但它们不是作为表的一部分建模的（沿着作为类的一部分的方法的行）。相反，因为存储过程是整个数据库的一部分而不是单个表，所以它们被建模为具有数据库名称的类的一部分。
5. 应用命名约定。您的组织应该有适用于数据建模的标准和指南，如果没有，您应该游说实施一些。与往常一样，您应该遵循AM的应用建模标准的做法。
6. 确定关系。表之间存在关系，就像类之间存在关系一样。 UML类图中的建议关系适用。
7. 应用数据模型模式。一些数据建模者将应用通用数据模型模式，David Hay（1996）的书“数据模型模式”是该主题的最佳参考。数据模型模式在概念上最接近分析模式，因为它们描述了常见域问题的解决方案。 Hay的书对于参与分析级建模的任何人来说都是一个非常好的参考，即使你采用对象方法而不是数据方法，因为他的模式模拟了来自各种业务领域的业务结构。
8. 分配键。键是一个或多个数据属性，用于唯一标识表中的行。两个或多个属性的键称为复合键。主键是实体类型的首选键，而备用键（也称为辅助键）是访问表中行的替代方法。在物理数据库中，密钥将由一个或多个表列组成，其值唯一地标识关系表中的行。主键使用<< PK >>构造型和外键通过<< FK >>表示。在此处阅读有关密钥的更多信息

尽管使用了类似的符号，但有趣的是注意到图21的PDM与基于ti的UML类图之间的差异：

1. 键。通常的做法是不在类模型上建模脚手架属性，通常建模键（脚手架的数据等价）。
2. 能见度。列的可见性未建模，因为它们都是公开的。但是，由于大多数数据库都支持访问控制权限，因此您可能希望使用UML约束，UML注释或业务规则对其进行建模。类似地，存储过程也是公共的，因此它们也不是建模的。
3. 没有多对多的联想。与对象不同，关系数据库本身不支持多对多关联，因此您需要通过添加关联表来解决它们。与关联表最接近的是WaitList，它是为了解决类图中描述的等待列表中的多对多关联而引入的。纯关联表由两个表的主键列组成，它维护两者之间的关系，在本例中是Student的StudentNumber和Seminar的SeminarOID。请注意，在WaitList中，这些列同时具有PK和FK构造型，因为它们构成WaitList的主键，同时是其他两个表的外键。 WaitList不是真正的关联表，因为它包含非键列，在这种情况下是添加列，用于确保等待列表中的第一个人是在座位可用时有机会注册的人。如果WaitList是一个纯关联表，我会将关联表构造型应用于它。

剩下的敏捷

我经常使用CASE工具来创建物理数据模型。我需要数据建模工具的两个特性是能够生成创建数据库模式所需的数据定义语言（DDL）代码，以及从现有数据库模式反向工程数据模型的能力。实际上，目前市场上的所有数据建模工具都支持这些功能。

资源

此工件描述摘自“对象入门第3版：使用UML 2的敏捷模型驱动开发”的第12章。

This artifact description is excerpted from Chapter 12 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

 

原文：http://www.agilemodeling.com/artifacts/physicalDataModel.htm

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

过程反模式是一种常见的策略，在理论上听起来不错，但在实践中证明是有害的，即使不是彻头彻尾的灾难。 本文概述了与IT组织内的企业架构工作相关的反模式集合。 这些反模式是：

• 30,000英尺和攀登
• 出血边缘
• 脑信托停车场
• 流行语驱动的架构
• 详细的企业建模
• 企业停车场
• 镀金
• 象牙塔架构
• 建模的清醒建模
• 一个真理高于一切
• 真实的断开连接
• 力求完美
• 被困在杂草丛中
• 技术首先
• 明天会遭受今天的困扰
• 未来的未来
• 昨天的企业模型

反模式	问题	方案
30,000英尺和攀登	企业模型是如此高级，以至于它对应用程序团队来说是有限的或没有实际用途。	开发参考体系结构，提供体系结构各个方面的工作示例。 卷起袖子，积极参与开发团队。 根据开发团队的反馈来制定您的模型。
出血边缘	架构师在成熟或足够稳定以便有效部署之前，不断尝试新技术和新技术。	接受旧技术确实能够很好地工作的事实; 您的大多数业务可能仍然是在IBM大型机上运行的批量COBOL，而这实际上是这些系统的最佳平台。
智囊团停车场	您的企业建模组由许多非常聪明的人组成，他们在IT中的任何其他地方都不适合，但您不想失去他们的知识。	找到一种方法使它们对现有项目团队有用，可能作为业务领域的建模指导者或主题专家（SME）。 认识到如果他们现在无法在您的组织内提供价值，那么他们就不太可能这样做。 激励他们在其他地方找到工作。
流行语驱动的架构 -要么- 基于杂志的架构	您的企业架构模型描绘了一系列技术，当有人读到“真正酷”的新技术时，其中许多技术被添加到模型中。	认识到您的首要任务是满足您实际需求的架构，而不是您可以在高尔夫球场上向您的朋友吹嘘的架构。 添加新技术的决定应该由具有专业知识并且花时间证明其有效的人员做出。 这不应该是一个政治决定。
详细的企业模型	企业模型过于详细，通常是为了全面定义企业的行为（或应该做什么）。	认识到人们很少阅读细节，通常是因为他们对这些细节不感兴趣，或者因为他们不相信它们是准确的。 通常需要的是对所需内容的可靠概述和愿景。 有目的的模型，了解您的模型的受众，使您能够建立足够的模型。 与您的观众合作开发模型：他们是他们需要的最佳评判者，而不是您。
企业停车场	一个组织形成一个企业建模或企业架构组，并在那里“停放”很多非常聪明的人，因为他们不想失去人，但同时却找不到实际的位置。	认识到仅仅因为某人真的很聪明，这并不意味着他们已经为企业集团做好了准备，或者永远都是。 为您的企业集团配备可以实际完成工作的人员。 适当资助您的企业集团。
镀金	架构师过度构建体系结构以实现您在某些时候可能需要的非常酷的功能，但是这些功能今天不会增加价值（并且可能永远不会增加）。	通过做一些初步构想来考虑大局，但也要相信你明天解决明天问题的能力。 如果您现在有能力解决问题，那么您是否也有能力及时解决（JIT）何时以及是否需要？
象牙塔架构	您的企业架构模型反映了一个如意，完美的世界场景，而不是您实际环境的现实。	查看30,000英尺和攀登的解决方案。
建模的清醒建模	有人认为开发一个企业模型是一个好主意，但没有具体的计划如何在实践中使用它。 开发团队能够使用该模型进行指导的模糊想法是不够的。	首先获得对企业建模的支持，然后只有足够的模型来为您的IT组织增加直接和明显的价值。
一个真理高于一切	“一个真理”的哲学说，希望对数据元素或业务术语有一个单一的定义，对于主参考数据甚至可能是您的主要业务实体应该有一个共同的共享定义。 当这种哲学走向极端并且你试图了解环境中所有数据实体和数据元素的真相时，就会出现“一个真理高于一切”的反模式。	认识到真正的目标是提供商业价值，而不是完美的数据。 要求和优先级发生变化，因此您无论如何都必须愿意改进数据库。 灵活定义数据的语义。
真实世界断开连接	企业模型反映了建模者的愿景和误解，但并未反映您的业务利益相关者实际需要的内容。	认识到仅仅因为20年前在域中工作的人并不意味着他们仍然了解当今业务中发生的事情。 让实际执行业务流程的人员参与并在建模过程中获得他们的观点。
力求完美	架构师总是在进行原型设计和修补，但实际上从未实际推出任何东西，因为它并不“完美”。	接受这样一个事实，即您的架构需要不断发展，然后开发出“现在足够好”的架构。 今天开发人员宁愿提出不完善的建议，而不仅仅是等待企业架构师准备就绪的请求。
被困在杂草丛中	您对细节太过深入，试图为应用程序团队完成所有工作。	架构中的导师开发人员与他们一起作为开发团队的平等合作伙伴，并在他们开始之后，专注于为他们提供所需的指导和建议。
技术首先	架构师使技术成为业务驱动因素而非业务推动因素。	将您的企业架构建立在利益相关者定义的实际需求上。 其他任何东西都会“乱砍大片”。
明天会遭受今天的困扰	在尝试改进业务流程时，常见的错误是在不探究如何完成任务的情况下描述当前的工作方式。	探索新的可能性，同时牢记今天的现实。 考虑一种独立于技术的模型方法，可能使用基本/抽象用例，使您能够在不探索解决方案空间的情况下探索业务。
未来的未来	企业模型反映了您组织近乎完美的“乌托邦式”未来，但没有为未来提供明确的途径。	认识到您受到组织文化，人类不完善和资源限制的约束。 在尝试改进之前，调查并了解当前的情况。 虽然目前的流程可能不是最优的，但可能有理由说明事情是按照原样完成的。 了解这些原因将有助于制定切合实际的流程。
昨天的企业模型	您的企业模型已声明完成并放在架子上。 由于环境的变化，“完成的模型”很快就会过时，从而降低了模型的价值。	随着业务的变化，定期更新您的企业模型。

推荐资源

• 15 Agile Strategies for Enterprise Architecture
• Agile Enterprise Architecture
• Agile Modeling Core Practices
• Software Development Context Framework (SDCF)
• Agile Strategies for Enterprise Architecture (in Enterprise Architecture Trends 2007, Cutter Consortium)
• Core Practices for Agile/Lean Documentation
•  
• Big Modeling Up Front (BMUF) Anti-Pattern
•  
• Enterprise Architecture Anti-Patterns (Soumen Chatterjee)
•  
• EUP Enterprise Architecture Discipline
•  
• EUP Enterprise Business Modeling Discipline
•  
• Initial High-Level Architectural Envisioning
•  
• Initial High-Level Requirements Envisioning
•  
• The "One Truth Above All Else" Anti-Pattern
•  

1. 15企业架构敏捷策略
2. 敏捷企业架构
3. 敏捷建模核心实践
4. 软件开发上下文框架（SDCF）
5. 企业架构的敏捷策略（2007年企业架构趋势，Cutter Consortium）
6. 敏捷/精益文档的核心实践
7. 大模型前方（BMUF）反模式
8. 企业架构反模式（Soumen Chatterjee）
9. EUP企业架构学科
10. EUP企业商业建模学科
11. 最初的高层架构构想
12. 最初的高级要求展望
13. “一个真理高于一切”的反模式

 

原文：http://agilemodeling.com/essays/enterpriseModelingAntiPatterns.htm

本文：https://pub.intelligentx.net/agilemodeling-enterprise-modeling-anti-patterns

讨论：请加入知识星球或者小红圈【首席架构师圈】

与传统软件开发人员一样，敏捷软件开发人员也会执行分析活动。与传统开发人员不同，敏捷专家以高度协作的方式进行分析，并在即时（JIT）基础上进行分析。分析对我们来说非常重要，我们每天都会这样做。在本文中，我将讨论：

• 什么是分析？
• 什么是敏捷分析？
• 通过敏捷生命周期进行分析
• 潜在的分析模型
• 重新思考分析师的角色
• 结论

1.什么是分析？

分析的目的是了解将要构建什么，为什么要构建，构建（估计）可能花费多少，以及构建它的顺序（优先级）。>这类似于需求获取，其目的是确定用户想要构建的内容。主要区别在于需求收集的重点是了解用户及其对系统的潜在用途，而分析的重点则转移到了解系统本身和探索问题域的细节。另一种分析方法是，它代表了需求和设计之间的中间环节，即思维模式从需要构建的过程转变为构建方式的过程。

2.什么是敏捷分析？

让我们首先描述敏捷分析不是：

• 它不是项目生命周期中的一个阶段
• 这不是您项目进度的任务
• 它本身并不是一种手段

什么是敏捷分析？从前面关于敏捷业务系统分析师所做的讨论开始，您的敏捷分析工作应该具有以下特征：

• 敏捷分析应该是沟通丰富。敏捷开发人员更喜欢温暖的通信技术，如面对面讨论和视频会议，而不是文档和电子邮件等冷技术，如“通信”文章中所述。敏捷开发人员倾向于尽可能密切地与项目利益相关者合作，尽可能遵循AM的积极利益相关者参与实践。
• 敏捷分析是高度迭代的。正如Martin（2002）指出的那样，分析和设计活动都是相互依赖的：估算是分析的一部分，但依赖于某些设计被执行以确定如何实现某些东西，而您的设计工作依赖于执行足够的分析来定义什么需要建立。因此，分析是迭代的。
• 敏捷分析是渐进式的。> Martin（2002）也正确地指出敏捷分析是渐进式的，您不需要一次性构建系统。这种理念支持通用敏捷软件过程所支持的增量方法，其中工作被分解为小的，可实现的“功能块”。这些块应该在很短的时间内实现，通常只需要几小时或几天。
• 敏捷分析探索并阐明了问题空间。您的主要目标是识别和了解项目利益相关者对您系统的需求。此外，需要将此信息传达给参与项目的每个人，包括开发人员和利益相关者。这有助于理解并同意项目的整体愿景。
• 敏捷分析包括对需求的估计和优先级排序。在对需求进行估算和优先排序时，软件开发对项目利益相关者来说变得“真实”。很容易说你想要的东西，但很难同意它的价格，更不用说交换它对你来说更重要的东西。
• 敏捷分析会产生足够好的工件。如果敏捷分析的结果是创建任何工件（您将遵循AM练习，毕竟丢弃临时模型），它们应该是敏捷模型或敏捷文档。这些文物通常远非完美，它们只是勉强实现其目的而已。

以下是我对敏捷分析的定义：

敏捷分析是高度渐进和协作的过程，开发人员和项目利益相关者积极地在即时（JIT）基础上协同工作，以了解域，识别需要构建的内容，估计功能，确定功能的优先级，并且在此过程中可选地产生几乎不够好的工件。

3.通过生命周期分析

图1描绘了敏捷模型驱动开发（AMDD）的生命周期。 在“迭代0”中，敏捷项目的第一次迭代，您需要使项目井井有条并朝着正确的方向前进。 这项工作的一部分是初步设想需求和架构，以便您能够回答有关项目范围，成本，进度和技术策略的关键问题。 在迭代期间通过在每次迭代开始时的初始迭代建模或通过在整个迭代中进行模拟计划，在实时（JIT）基础上识别关于业务域的细节。 分析对于敏捷专家来说非常重要，我们每天都会这样做。

图1.软件项目的敏捷模型驱动开发（AMDD）生命周期。

4.一些潜在的分析模型

创建的工件是否采用敏捷方法进行分析，而不是传统分析结果所创建的方法？ 在某种程度上他们是。 它们实际上是相同类型的工件，用例图毕竟是一个用例图，但它们的创建方式是不同的。 这些工件是按照AM的原理和实践创建的，它们几乎不够好，经常被丢弃以便轻装上阵。

表1列出了分析建模过程中使用的常见工件，并提出了一个简单的工具，您可以使用该工具创建此类工件。 值得注意的是，此列表具有代表性，在敏捷建模工件和敏捷建模一书中提供了更全面的列表。

表1.用于分析建模的候选工件。

Artifact	Simple Tool	Description
Activity Diagram	Whiteboard	UML activity diagrams are used during analysis modeling to explore the logic of a usage scenario (see below), system use case, or the flow of logic of a business process. In many ways activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs).
Class Diagram	Whiteboard	Class diagrams show the classes of the system, their inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. During analysis you can use class diagrams to represent your conceptual model which depict your detailed understanding of the problem space for your system.
Constraint definition	Index card	A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements for your project.
CRC model	Index cards	A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class. Like class diagrams, CRC models are used during analysis modeling for conceptual modeling.
Data flow diagram (DFD)	Whiteboard	A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores. When analysis modeling a DFD can be used to model the existing and/or proposed business processes that your system will support.
Entity/Relationship (E/R) diagram (data diagram)	Whiteboard	E/R diagrams show the main entities, their data attributes, and the relationships between those entities. Like class diagrams E/R diagrams can be used for conceptual modeling, in many ways E/R diagrams can be thought of as a subset of class diagrams.
Flow chart	Whiteboard	Flow charts are used in a similar manner to activity diagrams.
Robustness diagrams	Whiteboard	Robustness diagrams can be used to analyze usage scenarios to identify candidate classes and major user interface elements (screens, reports, ...).
Sequence diagram	Whiteboard	Sequence diagrams are used to model the logic of usage scenarios. Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both explore and validate your logic.
State chart diagram	Whiteboard	State chart diagrams depict the various states, and the transitions between those states, that an entity exhibits. During analysis modeling state chart diagrams are used to explore the lifecycle of an entity that exhibits complex behavior.
System use case	Paper	A use case is a sequence of actions that provide a measurable value to an actor. A system use case includes high-level implementation decisions in it. For example, a system use case will refer to specific user interface components - such as screens, HTML pages, or reports. System use cases will also reflect fundamental architectural decisions, such as the use of ATMs versus cell phones to access your bank account.
UI prototype	Whiteboard	A user interface (UI) prototype models the user interface of your system. As a part of analysis modeling it enables you to explore the problem space that your system addresses in a manner that your project stakeholders understand. Remember, the user interface is the system to most people.
Usage scenario	Index card	A usage scenario is exactly what its name indicates - the description of a potential way that your system is used.
Use case diagram	Whiteboard	The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box. When analysis modeling a use case diagram can be used to depict the business functionality, at a high-level, that your system will support. It can also be used to depict the scope of the various releases of your system via the use of color or system boundary boxes.

5.重新思考分析师的作用

无论范例如何，分析都是任何软件开发项目的一项非常重要的活动。这是一个组织设计决策，用于定义您将拥有的角色以及这些角色将执行的操作。在传统开发中，通常有人担任分析师角色，有些组织甚至选择区分分析师类型，并且会有系统分析员（SA），业务分析师（BA），业务系统分析师（BSA），数据分析师，流程分析师等。在敏捷开发中，我们做出不同的组织设计决策。因此，虽然我们仍在执行分析，但我们还没有决定让某人担任该特定角色。

• 如果您是现有的BA，那么在转向敏捷软件开发时，您可能需要考虑以下几种策略：
• 认识到敏捷团队由推广专家而不是专家（如分析师）组成。您的分析技能很有价值，显然是一个良好的开端，但您需要能够做得更多。准备好与其他团队成员密切合作，帮助他们将技能转移给他们并从中获取新技能。
• 业务分析师，尤其是业务分析师，可以在敏捷项目中扮演利益相关者/客户/产品所有者的角色，代表整个项目中的利益相关者社区（参见图2）。它们也可能导致在迭代0期间设想工作的初始要求。
• 有关更多详细信息，请参阅文章重新思考业务分析师的角色。

协作要求

图2. BSA作为产品负责人。

六，结论

分析的性质已经改变。几十年前，分析被视为一系列项目生命周期中的转型过程。随着20世纪80年代和90年代面向对象的日益普及，分析很快被视为迭代和渐进过程的一部分，并且在新的千年中，分析的本质再次发生变化。今天，分析更好地被设想为涉及开发人员和利益相关者的高度协作，迭代和渐进的努力。>分析过程的演变需要业务系统分析员（BSA）工作方式的演变，并且在许多情况下这个角色可以说是对于推广专家的开发人员而言，这种做法有所消失。

7.致谢

我要感谢以下人员对Agile Modeling邮件列表的输入：James Bielak，Adam Geras，Ron Jeffries，Kent J. McDonald，Les Munday，Paul Oldfield，Stephen Palmer，Tom Pardee，Dave Rooney，Gabriel Tanase和Paul Tiseo。

 

原文：http://agilemodeling.com/essays/agileAnalysis.htm

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

与流行的看法相反，架构是敏捷软件开发工作的一个重要方面，就像传统的工作一样，并且是扩展敏捷方法以满足现代组织的现实需求的关键部分。但是，敏捷专家的架构方式与传统主义者的方式略有不同。本文讨论以下问题：

1. 迈向敏捷架构
2. 整个生命周期中的架构
3. 谁负责架构？
4. 拥有“架构所有者”的角色
5. 大规模的敏捷架构
6. 根据需求建立您的架构
7. 为您的架构建模
8. 考虑几种选择
9. 记住企业约束
10. 旅行灯
11. 用工作代码证明你的架构
12. 沟通您的架构
13. 想想未来，等待行动（推迟承诺）
14. 采取多视图方法
15. 这是如何运作的？
16. 解决敏捷和架构周围的神话

1.迈向敏捷架构

体系结构提供了构建系统的基础，体系结构模型定义了体系结构所基于的愿景。架构的范围可以是单个应用程序，应用程序系列，组织，或许多组织共享的Internet等基础架构。无论范围如何，我的经验是您可以采用敏捷的架构建模，开发和发展方法。

 

以下是一些让您思考的想法：

• 架构没什么特别的。异端你说！绝对不。敏捷建模的谦逊价值表明每个人对项目都有同等的价值，因此任何担任架构师和他们努力的人都同样重要，但不会比其他人的努力更重要。是的，优秀的架构师拥有适合手头任务的专业技能，应具备有效应用这些技能的经验。然而，完全相同的事情可以说是优秀的开发人员，优秀的教练，优秀的高级管理人员等等。谦虚是您架构工作的重要成功因素，因为您需要避免象牙塔式架构的发展并避免您的队友的敌意。架构师的角色对大多数项目都是有效的，它不应该是由基座上的某个人完成的角色。
• 你应该提防象牙塔式架构。象牙塔式架构通常由架构师或架构团队开发，与项目团队的日常开发活动相对隔离。强大的架构专家会开发并开发一个或多个模型描述了团队中的仆从为架构师建立的最佳体系结构。象牙塔架构通常是美丽的东西，通常有很多花哨的图表和精彩的视觉陈述，宣称它们是你的救赎。理论上，这通常是您的架构师的工作基础，象牙塔式架构完美地运作。然而，经验表明象牙塔架构存在重大问题。首先，“minion开发者”不太可能接受这种架构，因为他们在开发过程中没有发言权。其次，象牙塔式架构通常是未经证实的，象牙塔式架构师很少会弄脏他们编写代码的手，因此在您知道他们实际通过技术原型提供的具体反馈之前，您的项目将面临重大风险。第三，如果架构师除了模型之外什么也不做，因为你无法思考系统所需的一切，象牙塔架构将是不完整的。第四，象牙塔式架构促进了软件的过度建设，因为它们通常反映了任何系统所需的每个功能。架构师曾经参与其中，而不仅仅是您的系统实际需要的功能。
• 每个系统都有一个架构。但是，它可能不一定具有描述该架构的架构模型。例如，一个小团队采用XP方法在同一个房间里一起工作可能没有必要对他们的系统架构进行建模，因为团队中的每个人都非常了解模型并不能为他们提供足够的价值。或者，如果存在架构模型，则通常会有一些简单的旧白板（POW）草图可能由定义的项目隐喻支持。这是因为XP的通信方面，包括结对编程和集体所有权，否定了需要在整个项目中开发和维护的架构模型的需要。其他团队 - 不遵循XP的团队，更大的团队，人员不在同一地点的团队 - 将发现他们的环境中固有的更大的沟通挑战要求他们超越口碑架构。这些团队将选择创建架构模型，以便为开发人员提供有关如何构建软件的指导。从根本上说，您执行体系结构建模的原因是为了解决开发团队成员无法实现共同愿景的风险。
• 架构规模敏捷。传统技术也是如此。为项目制定可行且可接受的架构策略对于您的成功至关重要，尤其是在敏捷团队大规模发现的复杂情况下。扩展问题包括团队规模，法规遵从性，分布式团队，技术复杂性等（有关详细信息，请参阅软件开发上下文框架（SDCF））。一种有效的体系结构方法使您能够解决这些扩展问题。

2.整个生命周期的架构

图1描绘了敏捷模型驱动开发（AMDD）的生命周期。在“迭代0”（Disciplined Agile Delivery（DAD）中的初始阶段），您需要使项目井井有条并朝着正确的方向前进。这项工作的一部分是初步要求设想和架构设想，以便您能够回答有关项目的范围，成本，进度和技术策略的关键问题。从架构的角度来看，在迭代0期间，目标是确定您的团队的潜在技术方向以及您可能面临的任何技术风险（应通过代码证明风险来解决）。此时您不需要详细的架构规范，事实上在软件开发项目开始时创建这样的规范是一个非常大的风险。相反，在迭代期间通过在每次迭代开始时的初始迭代建模或通过在整个迭代中进行模拟计划，在实时（JIT）基础上识别细节。最终的结果是，体系结构随着时间的推移逐渐出现，最初由于更需要设置项目的基础而更快，但是随着时间的推移仍在不断发展，以反映对开发团队的更多理解和了解。这遵循小增量中的实践模型并降低项目的技术风险 - 您始终拥有一个坚实且经过验证的基础，可以从中工作。换句话说，你想要考虑未来，但等待采取行动。

图1.软件项目的敏捷模型驱动开发（AMDD）生命周期。

图2描述了Disciplined Agile Delivery（DAD）工具包描述的敏捷/基本生命周期。 DAD工具包具有本文中描述的所有体系结构策略.DAD是一种混合体，它采用来自各种来源的策略，包括敏捷建模，Scrum，XP，敏捷数据等等。 实际上，DAD在处理方面做了“繁重的工作”，因为它捕获了来自这些不同方法的想法如何组合在一起。 因为DAD不是规定性的，所以它支持几个生命周期。 图2的生命周期是DAD基于Scrum或“基本”的敏捷交付生命周期，但它也支持精益/看板类型的生命周期和持续交付生命周期。 我们的想法是，您的团队应该采用对您所面临的情况最有意义的生命周期。

图2. DAD Agile生命周期（单击以展开）。

这种轻量级初始体系结构建模方法的替代方法是尝试在实现开始之前完全定义您的体系结构。这种极端通常被称为预先设计（BDUF）。这种方法背后的动机通常是项目管理不希望任何人前进，直到就方法或“一个数据真相”达成共识。不幸的是，这种方法通常导致没有人向前推进很长一段时间，象牙塔式架构往往在实践中证明是脆弱的，这种架构对于你实际需要的东西来说是过度的，和/或开发子团队在他们的拥有，因为他们不能等待架构师完成他们的工作。这种方法通常是所涉人员的一种思维方式的结果，是瀑布式软件开发时代（20世纪70年代和80年代，当今许多管理人员都是软件开发人员）的遗留思维过程。现实情况是，架构的发展非常艰难，这是您成功的关键，也是您从一开始就无法做到的。进化（迭代和增量）方法通过一次开发一次，并且只在您需要它时，解决了架构不充分或不适当的风险。

3.谁对架构负责？

这个问题比你想象的要复杂得多。答案很简单，适用于小型敏捷团队（绝大多数），团队中的每个人都负责架构。实践模型与其他人告诉你，你真的不想独自工作，坦率地说，架构是非常重要的，无论他们多么聪明，都不能留在一个人的手中，因此架构应该是一个团队的努力。在一个小型项目团队中，比如十五人或更少，我更愿意包括所有开发人员，因为它允许所有参与者在体系结构中发表意见。这增加了每个人对体系结构的理解和接受，因为他们一起工作一个团队。当架构证明不足时，它也增加了开发人员愿意改变架构方面的机会，也许它不像你最初想象的那样扩展，因为它是集团的架构而不仅仅是他们的架构。当一个人开发某些东西时，它就变成了“他们的宝贝”而且没有人喜欢听到他们的宝宝是丑陋的 - 当你发现他们的架构有问题时，他们可能会抵制任何批评。当整个团队开发一个架构时，人们通常更愿意重新考虑他们的方法，因为这是团队问题，而不是个人问题。

但是，“每个人都拥有架构”战略存在两个基本问题：

• 有时人们不同意。当团队未达成一致时，此策略可能会大幅崩溃，因此您需要具有架构所有者角色的人员来促进协议。
• 它不会扩展。当您的团队规模较大或地理位置分散时，在软件开发上下文框架（SDCF）中调出的八个缩放因子中的两个，您将组织您的团队成为一个子团队。在这种情况下，大规模的架构需要协调机构。

4.拥有“架构所有者”

对于任何相当复杂的系统，您需要花一些时间来构建它。您将做一些前期架构设想，让您开始朝着正确的方向前进，然后架构将需要从那里发展。许多敏捷团队发现他们需要扮演“架构所有者”角色的人，有时称为敏捷解决方案架构师。这个人通常是团队中技术最有经验的人，负责促进架构建模和演变工作。就像Scrum的产品所有者角色负责团队的要求一样，架构所有者负责团队的架构。架构所有者是Disciplined Agile（DA）工具包中的主要角色之一。

架构所有者不同于架构师的传统角色。在过去，架构师通常会成为架构的主要创造者，并且是少数参与其中的人之一。他们经常开发架构，然后“开发”它，或者更准确地强制它开发团队。架构所有者与团队协作以开发和发展架构。虽然在架构方面他们是最终决策权的人，但这些决策应该与团队以协作的方式进行。有效的架构所有者是在组织正在使用的技术方面经验丰富的开发人员，并且能够使用架构峰值来探索新策略。他们还应该对业务领域有很好的理解，并具备将架构传达给开发人员和其他项目利益相关者的必要技能。

5.规模敏捷架构

在大型敏捷团队，地理位置分散的敏捷团队或企业范围的架构工作中，您将需要架构所有者团队或企业架构团队（在敏捷建模中，我最初将其称为核心架构团队，这是我从未真正喜欢过的术语）。 大型敏捷团队通常被组织成较小的子团队，如图3所示。每个子团队的架构所有者都是架构所有者团队的成员，这有助于增加每个子团队理解并遵循整体架构的机会。 以及增加整体架构策略满足整体解决方案的全部需求的可能性。 将有一个整体的首席架构所有者，这可能是一个轮流角色，负责促进团队。

图3.大规模的敏捷团队被组织成子团队的集合。

大规模组织敏捷团队有四种基本策略：

• 架构驱动的方法。使用此策略，您可以围绕架构中调出的子系统/组件组织子团队。当您的架构具有高质量（松散耦合且高度内聚）并且在子团队真正开始之前已经识别出子系统的接口时，这种策略很有效（接口会随着时间的推移而发展，但您希望获得良好的开端）在他们最初）。该策略面临的挑战是，它需要以反映架构的方式捕获您的需求。例如，如果您的体系结构基于大型业务域组件，那么一个需求应尽可能专注于单个业务域。如果您的体系结构基于技术层 - 例如具有用户界面（UI），业务和数据层的3层体系结构 - 那么如果可能，需求应该集中在单个层上。
• 特征驱动的方法。通过这种策略，每个子团队一次实现一个功能，这个功能对于利益相关者来说是一个有意义的功能块。我会将这种策略应用于架构展示了大量耦合的情况，并且您可以使用复杂的开发实践。这种方法的挑战在于子团队通常需要访问各种源代码来实现该功能，从而冒着与其他子团队发生冲突的风险。因此，这些团队进行了复杂的变更管理，持续集成，甚至可能是并行的独立测试策略（仅举几例）。
• 开源方法。使用此策略，一个或多个子系统/组件以开源方式开发，即使它是针对单个组织（这称为内部开源）。此策略通常用于许多团队广泛重用的子系统/组件，例如安全框架，并且必须快速发展以满足访问/使用它们的其他系统的不断变化的需求。此策略要求您采用支持开源方法的工具和流程。
• 其组合。大多数敏捷团队将适当地结合前三种策略。

图4描绘了大规模敏捷项目的体系结构活动过程。您通常会看到在大型项目（通常称为程序），地理位置分散的项目，复杂（域或技术）项目或企业级（通常支持敏捷企业架构）上采用这种方法。这种方法有四个重要方面：

• 设想初始架构。最小的架构所有者团队负责初始架构设想，然后将其带到子团队以获得反馈和后续演变。对于大型项目/项目，通常还有其他敏捷团队成员参与此初始建模工作，包括产品所有者甚至是关键项目利益相关者。预计工作的架构可以持续数天，对于非常大或复杂的项目，可以持续数周。对于企业架构工作，企业架构团队通常会在项目初始建模工作中包括项目级应用程序/解决方案架构师，并且通常包括执行利益相
• 与开发团队合作。在大型项目/程序中，如图3所示，架构所有者团队的成员将在项目的各个子团队中扮演积极的角色，将架构传递给子团队并与他们合作以通过具体的方式证明部分架构实验。对于企业架构工作，企业架构师将最低限度地充当顾问，他们的专业知识是企业架构，但更好的是他们将成为关键项目团队的活跃成员，承担架构所有者在这些团队中的角色。由于敏捷开发的协作性质，架构所有者只需简单地进行初始架构设想，或者通过偶尔审查他们的工作来“支持”项目团队，但他们必须“卷起袖子”并成为活跃成员项目团队。这将有助于他们避免创建“象牙塔式架构”，这在纸上听起来不错但在现实世界中证明是不切实际的。它还有助于增加项目团队实际利用架构的机会。
• 将架构传达给架构利益相关者。对于项目团队，架构利益相关者包括与敏捷交付团队，关键项目利益相关者以及开发团队其他成员合作的产品所有者。这些人需要了解架构愿景，已经取得的权衡以及实施架构的当前状态。
• 更新架构作品。架构所有者团队将发现他们需要偶尔聚集在一起，随着项目的进展改进架构，协商架构的更改并根据需要更新架构模型（如果有的话）。这些会议将在项目开始时经常举行，随着架构的巩固，需要越来越少。对于可能不是核心架构团队成员的开发子团队成员来说，参加一些会议以提供信息，或许他们参与了一些技术原型设计并与调查结果分享，这将是常见的。最好的会议很短，通常不超过一个小时，并经常站在白板周围 - 每个人都应该为会议做好准备，愿意出席和讨论他们的问题，以及作为一个团队一起工作。很快得出决议。

图4.大规模的敏捷架构流程

 

6.需求驱动的架构

您的架构必须基于要求，否则您就是黑客攻击，就这么简单。在识别架构需求时，主动利益相关者参与的实践对您的成功至关重要 - 请记住，需求来自项目利益相关者，而不是开发人员。技术架构要求的良好来源将包括您的用户及其直接管理，因为他们通常会对技术要求和约束有所了解。操作人员肯定会对您的部署体系结构有所要求。面向业务的需求的最佳来源正是您期望的 - 您的用户，他们的经理。您组织内的高级管理人员将获得可能导致系统潜在变更案例的见解。

正如您所期望的那样，实践应用正确的工件和并行创建多个模型适用于您的架构需求工作。当您处理架构的技术方面时，您将希望基于技术要求，约束和可能的更改案例。同样，当您处理体系结构的业务方面，可能识别软件子系统或业务组件时，您可能需要关注描述关键使用要求的基本用例或用户故事，以及可能适用于您的系统的关键业务规则。

架构团队（或架构所有者的小型项目）将犯的一个常见错误是忽略现有的和相关的工件，例如描述组织现有技术基础架构的网络或部署图，企业级业务模型（用例模型，流程）图表，工作流程图，公司业务规则等），或您的系统应符合的公司部署标准（适用于工作站，分支机构等）。是的，现有工件可能已过时或根本不适用于您的工作，但您至少应该努力检查它们并尽可能利用现有工作。与合适的人进行一些阅读或讨论可能会为您节省大量精力。换句话说，不要忘记尽可能重用现有的工件。

理解架构建模的一个重要概念是，尽管它通常在项目的早期发生，但它永远不会首先出现。从根本上说，您总是会花时间确定一些要求。其他任何东西都是黑客攻击，黑客肯定不敏捷。

7.建模你的架构

架构建模的主要目标应该是就您打算如何构建系统达成共识或理解。换句话说，你将建模以理解。我的经验是，99.999％的软件项目团队需要花一些时间来建模他们系统的架构，即使是依赖于隐喻来指导他们的开发工作的Scrum / XP团队也是如此。虽然你的XP团队正在识别你的系统的比喻，你和你的队友在开发你的初始版本时会想到好几周，但你经常会画出你认为你的系统如何工作的草图。在AM的练习放弃临时模型之后，您可能不会保留这些草图，这通常是因为它们是无法解决的想法，或者仅仅是因为您正在建模以了解问题，所以一旦您这样做，图表就不再对您有价值了。话虽如此，XP团队开发架构模型并没有错。这些模型可能就像你在公众可见的白板上留下的草图一样简单，因为虽然隐喻可以是非常有效的东西，但架构模型通常会提供团队所需的更多细节。正如您所期望的，Disciplined Agile Delivery（DAD）团队也将进行一些架构建模。

您如何以敏捷的方式为您的架构建模？我通常会努力创建一个或多个导航图，图表显示系统“景观”的概述。就像路线图概述了城镇的组织一样，您的导航图概述了系统的组织结构。导航图是系统架构视图的实例。当您阅读有关架构建模的书籍和论文时，作者提出的一个共同主题是需要各种架构观点，每位作者都会展示他或她自己的关键视图集合，您需要考虑这些观点。我的经验是，没有一套架构视图适合每个项目，而项目的性质将有助于定义您应该考虑创建的视图类型。这意味着您创建的导航图类型取决于您正在构建的系统的性质。这在概念上与AM的实践一致应用正确的工件，它告诉您应该使用正确的建模技术来完成手头的任务。例如，使用基于J2EE的技术构建复杂业务应用程序的团队可能会发现UML组件图和工作流图适合用作体系结构导航图。但是，构建企业数据仓库的团队可能倾向于使用基于其体系结构的数据模型和UML部署图。不同的项目，不同的架构视图，因此不同类型的导航图。有趣的是，两个项目都需要两个导航图，符合多模型原则。您需要灵活处理您的方法，因为一种尺寸并不适合所有情况。

组织将犯的一个常见错误是将其架构工作建立在其组织结构上。例如，具有强大数据组的组织可能希望将数据模型作为其体系结构的主要工件，而不管系统的实际性质如何。当你有锤子专家时，每个问题看起来都像钉子一样。当您使用新技术或尝试开发组织几乎没有经验的新系统时，这个问题非常普遍 - 过去运行良好的组织结构在您的新环境中可能不再适合您。有关架构和组织结构的含义的更多信息，请参阅Conway定律的组织模式。

要创建导航图，建模工作的主要驱动力应该是假设简单。创建简单内容的做法表明您应该努力识别可能的最简单的体系结构方法 - 您的体系结构越复杂，个体开发人员不会理解它的可能性就越大，错误和崩溃的机会就越大。此外，您的架构模型应包含正确级别的信息，显示系统的各个方面如何协同工作，而不是细节（这就是设计的全部内容）遵循实践描述模型简单。您还应该使用最简单的工具来完成这项工作，很多时候，您需要使用白板草图来模拟架构的关键方面。绘图工具可以使用CASE工具。普通旧白板（POW）可以使​​用绘图工具。当纸张和便利贴可以使用时，请勿使用POW。

重要的一点是，当您的所有通信都是面对面的时，导航图通常足以描述您的架构。如果不是这种情况，当您的架构所有者无法与开发人员密切合作时（可能某些开发人员位于远程位置），那么您需要使用文档补充图表。

当您进行架构建模时，您应该考虑利用可用的丰富架构模式，但您应该以有效的方式进行。 “模式系统：面向模式的软件体系结构”这本书是开始学习常见体系结构模式的好地方，例如图层，管道和过滤器，代理，模型 - 视图 - 控制器和Blackboard。与分析和设计模式一样，应该按照惯例轻轻地应用模式 - 只有在明确需要时才将它们引入您的架构中。在此之前，如果您怀疑架构模式可能是合适的，那么您可能认为您将拥有需要代理的多个关键服务来源，然后对您的架构进行建模，以便在实际情况出现时应用此模式。请记住，您正在逐步开发系统，遵循小增量中的练习模型，并且您不需要在第一天就建立正确的体系结构（即使您愿意，也无法实现此目标）。

您应该认识到，您的架构模型将揭示您的系统对其他系统的依赖性或它们对您的依赖性。例如，您的系统可以通过Internet与信用卡处理服务交互，从遗留关系数据库访问数据，或为另一个内部应用程序生成XML数据结构。网络图和UML部署图对于识别这些依赖性非常有用，面向过程的模型（如工作流程图，UML活动图和数据流图）也非常有用。这意味着这些依赖关系表明可能需要遵循这样的做法：在您的团队与您共享依赖关系的系统的所有者之间正式化合同模型。理想情况下，许多这些模型已经到位，信用卡处理器可能具有您必须遵循的严格定义的协议，并且遗留数据库可能具有为其定义的物理数据模型，尽管诸如XML数据结构之类的新功能将需要足够的定义。有时，如果没有准确的文档，您需要对旧系统的现有接口进行分析，有时需要设计新的接口。在这两种情况下，都需要由您的团队，其他团队或合适的联合开发相应的合同模型。

您应该如何组织架构建模工作？在项目开始时，我将典型地将架构团队聚集在一个单独的房间中进行初步构想。理想情况下，这个会议将持续不超过几个小时，但在一些较大的项目上，它可能持续几天甚至几周（我会认真地质疑任何超过两周的努力）。与往常一样，建模会话越长，由于缺乏反馈而偏离航线的可能性就越大。这个建模会议的目标是就我们正在建立的系统的格局达成初步协议，或许不是达成共识，而是足够的协议，因此我们可以开始作为一个团队向前迈进。

8.考虑几种替代方案

正如精益软件开发告诉我们的那样，我们不应该尽早采取架构策略，而应该考虑几种替代方案，并且只要它们仍然可行，就让这些替代方案对我们“开放”。这意味着，当您在项目早期构想架构时，您应该真正设想出几种可能的架构。公平地说，这种策略并不是新的，事实上，这种策略已经在IT架构社区中推广了几十年，尽管并不总是如此。

9.记住企业约束

除最新组织外，所有组织都拥有现有的技术基础设施。更成熟的组织可能有：

• 他们正在努力实现的技术基础设施的“前景”愿景
• 企业级标准和指南 - 用于开发，数据，用户界面，安全性等 - 项目团队应遵循的标准和指南
• 用于降低总体开发和运营成本的战略性重用策略
• 企业架构，战略重用和/或类似的团队，负责发展和推广这些事物
• 运营和支持组织，有时也称为系统管理组织，负责在生产中运行组织的系统

关键是这些企业级考虑因素为开发团队提供了挑战和机遇。虽然每次构建一个新系统时从一个干净的架构板开始会很棒，但实际情况是在绝大多数情况下策略都是不合适的。多年来我见过几个敏捷项目团队因为他们选择重新开始，声称他们的架构随着时间的推移而出现，他们有勇气担心明天明天的问题，他们制作了潜在的可交付软件。定期，并基本上嘲弄任何其他敏捷的言论，他们认为这些言论证明了他们的愚弄。训练有素的团队构建系统，其架构出现在他们工作的组织环境中。他们谦虚地认识到他们无法做出他们想要的所有技术决策，而是受到现有基础设施和愿景的限制。此外，他们还生产可在组织生态系统中使用的可消耗解决方案。

幸运的是，企业关注的焦点也很多。通过利用现有的基础架构团队，可以更快地提供，因为他们的构建更少。通过使用现有技术，或者至少通过使用企业愿景中提到的新技术（对您的组织来说是新的），他们通过帮助最小化运营成本来降低系统的总体拥有成本（TCO）。通过遵循公司发展准则，它们有助于提高工作的一致性和质量，增加其可维护性，以便将来负责发展和维护工作。顺便说一句，软件开发上下文框架（SDCF）的企业规程扩展因子是八个中唯一的扩展因子，这使得开发团队可能更容易实现，因为这个因素远离项目级别的重点（ “容易”的情况）到企业层面的焦点（“硬”情况）。

那你怎么做的？最低限度，企业架构师，运营团队等企业集团是重要的利益相关者，应由您的产品所有者代表。对于您的企业体系结构组，其中一个或多个可能成为您的开发团队的活跃成员，具有架构所有者的角色。对于其他组，产品所有者可以根据需要和适当的即兴基础选择让他们作为域或技术专家参与您的团队。

10.轻装上阵

您的架构工作的一个目标应该是轻装上阵，尽可能灵活。当一个五页的文档可以做时，不要创建一个五十页的文档。当图表执行时，不要创建一个五页的文档。当隐喻可以做时，不要创建图表。记住“他们不会读它（TAGRI）”的原则。

不确定如何创建文档？错误的是因为你可以随时回到白板，但是你浪费了创建你不需要的工件或者为工件添加不必要的细节的时间已经一去不复返了。您的目标应该是考虑项目团队（或组织甚至行业所面临的关键问题，具体取决于您的范围），不应该创建大量的文档。最大化股东投资回报率的原则告诉您要专注于高价值的活动，例如作为一个团队解决困难问题并达成共同愿景。同样，它告诉您要避免低价值的活动，例如撰写详细的文档或开发分数漂亮的图表。这些活动往往令人感到欣慰，因为它们提供了进步的幻觉，如果你试图避免处理棘手的问题，就会为你提供一个离题的来源，但实际上很少像你想象的那样有效，因为其他人很少看到比作者。原则软件是您的主要目标意味着您应该对您的架构进行建模，直到您认为自己有可行的策略为止，此时您应该继续开始开发软件而不是文档。

您何时想撰写架构文档？在我看来，有两个例子让它变得“敏捷”。首先，当您拥有分布式开发团队并且无法找到更有效的沟通方式（例如面对面交谈）时，文档就是一种选择。其次，在项目结束时，您希望留下足够的文档，以便其他人可以在以后了解您的方法。现实情况是，对于相当复杂的系统来说，记录代码中的所有内容是非常困难的，如果不是不可能的，当然也不可取。有时，描述您的体系结构的最佳位置是简要的概述文档。本文档应侧重于解释您的架构的关键方面，可能由您的导航图捕获，它可能包括关键架构要求的摘要，以及对您所做的“可疑”方面背后的关键决策的解释。与往常一样，如果您要创建一个架构文档，那么它应该增加正值，理想情况下应该以最有效的方式执行。

很多人在发现架构没有“记录良好”时会感到担心，无论这意味着什么。我并不是很担心这个问题，但我担心的是架构是否真实，以及开发人员是否理解并接受它。如果您要优先考虑您的体系结构文档，拥有可行的体系结构，让开发人员理解该体系结构，并让所有开发人员都能使用它，那么我怀疑文档将在该列表中排在最后。想一想。

11.证明你的架构

实践证明它与代码指出模型只是一个抽象，一个看似非常好的模型在实践中可能实际上并非如此，你可以肯定知道的唯一方法是通过实现验证你的模型。这意味着你应该证明你的架构是有效的，XP称之为尖峰，RUP称为架构原型。当您的架构呼唤一些对您来说不熟悉的东西时，也许您是第一次使用两个或更多产品，您应该花时间来探索这种方法是否能够如何工作以及它是如何工作的原则快速反馈。记住要获得项目利益相关者的许可才能完成这项工作，因为这是他们花的钱。有时您会通过努力发现原始方法不起作用，我希望尽早发现，有时您会发现您的方法实际上是如何工作的（而不是您认为它的工作方式）。架构尖峰/原型的开发有助于降低项目风险，因为您可以快速发现您的方法是否可行，您还没有简单地制作象牙塔架构。

图5概述了优先需求“最佳实践”的敏捷方法。通过对交付生命周期的风险价值方法，Scrum价值驱动生命周期的扩展，您将确定解决项目主要技术风险的少数需求。例如，如果您的要求表明您的系统必须能够在10小时内每秒处理4,000个事务，那么这将是一个明确包含某些技术风险的要求。这是您希望在项目早期实现的一种要求，以确保您的体系结构真正起作用。我的一般规则是，当你进入为期6个月的项目仅18天而不是在“6个月项目”的8个月点结束时，最好发现你的架构策略需要重新考虑。这意味着，如果技术风险要求不在积压的首位，那么您需要与产品所有者密切合作，以说服他们重新确定优先级不高的要求。但是，如果您无法说服您的产品所有者这样做（我在实践中从未遇到过这个问题，但认识到可能会发生这种情况），那么您需要尊重他们的决定并接受以后证明您的架构的风险生命周期。

图5.工作积压。

 

12.传达您的架构

有两个主要受众，您的架构的沟通很重要：您的开发团队和项目利益相关者。为了促进您的开发团队之间的沟通，我坚信您应该遵循公开展示模型的所有架构图，因为一个严密保密的架构不是一个架构，它只是一个徒劳无益的自我锻炼。我参与了几个项目，我们成功地维护了一个专门用于架构图表的白板，让它们公开显示给项目中的每个开发人员以及偶然走过的任何其他人。我们还允许任何想要在图表中添加评论或建议的人，按照开放和诚实的沟通原则以及集体所有权的实践，因为我们希望他们对我们的工作有所反馈。我们没有什么可隐瞒和信任的，其他人愿意帮助我们（他们确实）。

在项目开始时，在整个项目中不那么频繁，您经常会发现需要使图表“看起来很漂亮”，这样您就可以将它们呈现给您的项目利益相关者。您的利益相关者希望了解什么是什么您打算采取的方法来确定您是否明智地投入资源，这意味着您需要建立模型来沟通和定位您的某些模型，以便其他人可以理解它们。这可能意味着您需要花时间来清理模型以使其可呈现以及为它们编写概述文档。为了保持尽可能灵活，有目的的模型原则告诉您，您应该确切地知道您正在为谁开发模型以及他们将使用它们，以便您可以专注于所需的最小努力。向重要的项目利益相关者进行演示，这些工作往往令开发人员烦恼和分散注意力，这对项目的成功至关重要，因为它们为您提供了获得项目支持和获取所需资源的机会。此外，您可以提升让您可以积极参与项目的利益相关者的重要性（如果您没有可用的利益相关者，则无法遵循主动利益相关方参与的做法）。

准备好在演示文稿中传达您的架构，没有理由不能保持演示文稿的敏捷性。

13.考虑未来，但不要过度建设（推迟承诺）

我怀疑关于敏捷架构建模的最具争议性的概念是你应该考虑未来的变化，但在你真正需要之前不要采取行动。换句话说，不要过度构建你的系统，但同时要聪明一点。 XP社区对于过度构建软件的概念相当直率，他们相信“你无论如何都不需要它”（YAGNI）。基本思想是你无法准确预测未来[1]，因此不应该为未来的可能性而努力。相反，您今天应该专注于构建您现在需要的东西并干净地构建它，以便您的软件在需要时易于更改。明天，当您发现需要更改软件以满足新要求时，请更改它。当您过度构建软件以更加通用时，为了满足未来的潜在需求，您实际上正在做出非常严肃的权衡：

• 很难估计你正在生产的实际价值。您并不专注于满足当今的需求，导致您不会为您的用户带来直接的价值。我参与了几个项目，前几个月，在少数情况下，前几个季度，我们的工作重点是开发通用基础架构（持久性框架，消息传递框架等）。技术上有趣的东西，我们肯定有很多乐趣构建它们，但对我们的用户没有任何价值。
• 你在猜。你真的不知道你是否甚至需要你正在建造的任何东西 - 当一辆大众汽车足够时你可能正在建造一辆保时捷。
• 你增加了维护负担。您今天过度建造的任何东西都需要在项目的整个生命周期中进行测试和维护，这违反了Travel Light的原则。
• 目前尚不清楚它需要在多大程度上进行测试。当你过度建造某些东西时，唯一可以准确验证它的方法就是通过虚构的反馈 - 没有人要求你过度建造任何东西，所以没有人可以去验证你的工作。此外，大多数开发团队都会测试风险，但如果您猜测需求，那么您也会猜测风险级别。

所以你怎么能对这一切都很聪明？虽然您不希望根据未来/神话要求过度构建系统，但考虑未来并没有任何问题。这是一个两阶段战略：

• 初始建模。做一些初步的架构，设想思考问题，探索关键概念，从而让你朝着正确的方向前进。这并不意味着您需要创建大量的架构文档，尽管您可能会进行一些建模，是的，egads！，甚至可以创建足够的架构文档来满足您的需求。
• 推迟设计决策。精益软件开发的原则之一是推迟对您需要做出决定的最后可能时刻的承诺，从而提高您的灵活性并提高您的成功机会。

一个有趣的策略是变更案例建模。变更案例用于描述系统的新潜在要求或对现有要求的修改。变更案例是您未来可能需要或可能不需要支持的要求，但您今天绝对不需要支持。变更案例通常是与项目利益相关者进行头脑风暴的结果，其中诸如“业务如何变化？”等问题。 “什么立法可以改变？” “你的竞争对手在做什么？”和“还有谁可能会使用该系统以及如何使用？”在技​​术方面，开发人员经常会提出诸如“什么技术可以改变？”等基本问题。和“我们需要与哪些系统进行交互？”这将导致识别变更案例。变更案例应该是现实的，例如“我们为银行进入保险业务”或“我们需要支持我们系统中的[INSERT FLASHY NEW TECHNOLOGY]”是合理的变更案例，但“我们的销售人员被不明飞行物绑架” “T。此外，变更案例通常描述的要求与您当前正在处理的要求相当不同，这些要求可能会导致重大的返工。通过识别变更案例，您现在可以智能地选择看起来与架构或设计决策相同的内容。当您的当前要求不足以帮助您在备选方案之间进行选择时，您应该只将相关的变更案例纳入决策过程。另一个优点是你现在可以向你的项目利益相关者解释为什么你选择一种方法而不是另一种方法，因为我想说你有一个故事要讲。但是，我不能强调改变案例不应该被用作为你的系统镀金的借口。保持敏捷，不要过度构建系统。那么当你认为你有一个你真正相信现在需要实施的变革案例时，你会怎么做？简单 - 与项目利益相关者讨论。询问他们是否立即要求变更案例，如果是，则相应地采取行动。如果这不是一个直接的要求，那么接受这个事实并继续前进。永远不要忘记项目利益相关者有责任确定需求的优先级，而不是您的需求。

未来的建模是否会受到损害？这是一个滑坡，因为我怀疑如果你建模它然后你更有可能建立它。我相信，这需要严格的纪律，不要过度建造，因为一旦你把它作为一系列气泡和线条捕获，就很容易让自己相信过度建造一次就没有坏处。已经说过，在讨论变更案例的时候绘制一些丢弃的草图并没有什么不妥，只是不要过度建模你打算保留的任何模型。

14.采用多视图方法

敏捷建模的多模型原则建议您认识到，因为现代系统很复杂，您需要考虑架构中的一系列视图。虽然它们采用不同的方法，但多视图策略是现代架构框架中的基本概念，例如Zachman框架，TOGAF，4 + 1等。这些框架中的每一个都有很好的理由来选择视图，它们在实践中似乎都运行良好，它们都可以灵活地进行处理，所以我的建议是检查您的选项并选择最能反映出来的架构框架。您组织的文化。我的目标不是提出另一个架构框架，而是让您了解它们及其基本概念。图6概述了软件/系统架构师需要关注的视图和关注点（通常称为服务质量要求）。

图6.架构视图和关注点。

视图/视点被捕获为图表和文本描述（例如用例，技术规范或散文）的组合。潜在的问题，可能是您自己的观点，您的架构应该解决的观点包括：

• 用法/业务流程
• 用户界面
• 系统界面
• 网络
• 部署
• 硬件
• 数据存储
• 数据传输
• 活动
• 代码/组件分发
• 功能/逻辑/服务

借用面向方面编程（AOP）的语言，您的架构也可能需要考虑“横切关注点”。这些问题/观点也应该通过您的架构视图来解决，在某些情况下可能是您自己的特定视图。这些担忧包括：

• 分层/分区
• 重用
• 质量和验证
• 准确性和及时性
• 可靠性，可用性，可维护性和性能
• 环境（绿色计算问题）
• 定制点
• 可消耗性（包括（de）安装的简易性，支持级别，可用性，......）
• 并发
• 安全
• 国际化
• 条例
• 维护，操作和支持问题

这意味着，任何担任架构师角色的人都需要拥有广泛的技能才能发挥作用，他们需要摆脱过度专业化的传统哲学，更多地是一个普遍化的专家。最低限度的是，他们应该从简单的数据架构师，安全架构师或网络架构师转变为架构师。仅仅是一名架构师也可能过于专业化，但这取决于具体情况。真正的专业人士力求拥有广泛的技能以及一个或多个专业。

15.这是如何工作的？

我所描述的架构方法与许多组织目前正在做的事情明显不同。表1比较并对比了许多组织中常见的架构实践与敏捷对应的架构实践。显然，这有很大的不同。敏捷方法之所以有效，是因为它专注于团队合作的人员。敏捷建模认识到人们是错误的，他们不太可能从一开始就获得正确的架构，因此需要有机会根据实施工作的反馈行事。当敏捷架构师是开发团队的高效成员，并且当开发团队参与开始的架构工作时，他们不需要全面的文档，导航图就足够了（授予，当这不是案件文件，希望最小，可能是必需的）。不需要架构评论，因为架构是通过架构原型设计/峰值的具体反馈来证明的，因为人们可以看到架构发展，因为您的模型公开展示供所有人查看。敏捷架构师有勇气专注于解决当今的问题并相信他们明天可以解决明天的问题（Beck，2000），以及认识到他们无法准确预测未来并因此选择不过度构建他们的架构的谦虚。

表1.比较常见和敏捷架构实践。

共同的实践	敏捷实践
架构师受到高度重视，经常被置于基座上，甚至更糟糕	敏捷的架构师谦虚地承认他们不会走水
架构师太忙了，不能随便开发	敏捷架构师是开发团队的活跃成员，在适当的情况下开发软件并充当团队的架构顾问
架构模型非常强大，可以满足未来的需求	敏捷架构师谦虚地承认他们无法预测未来，而是有勇气相信他们明天可以解决明天的问题
目标是在项目早期开发全面的架构	您可以逐步和迭代地改进您的体系结构，使其随着时间的推移而出现
需要记录良好的架构模型	轻装上阵，专注于概述您的建筑的导航图，记录足以与您的目标受众进行沟通
架构模型只有在“适合公众消费”时才会传达	架构模型即使在进行中也会公开展示，以促进其他人的反馈
在投入使用之前，将进行架构评审以验证您的模型	通过具体实验证明了架构

16.解决敏捷和架构周围的神话

我想通过解决一些与世界各地的组织合作时仍然遇到的常见神话来结束这篇文章。

• 敏捷者不做架构。我的希望是，这篇文章将把这个神话牢牢地放在一边。
• 您需要进行详细的前期架构建模。您应该进行一些前期架构建模，以确定您的一般技术策略，识别您可能遇到的潜在技术挑战，并帮助您在团队中围绕技术方向达成共识。关键是你不需要很多细节来实现这些目标。采用“大型模型预测（BMUF）”方法是一种选择，这种方法在理论上听起来很棒，特别是如果你是一名专业建模师，但在实践中通常被证明是一个相当差的人。 BMUF战略导致糟糕的决策和解决方案不太可能满足利益相关者的实际需求，降低您支持不断变化的需求的能力，并导致士气低落。
• 架构师负责架构。虽然许多组织选择支持主要负责架构活动的专业架构师，但事实证明这在实践中是一个相当糟糕的选择，因为开发人员可能会将架构师视为“象牙塔”并且经常会选择忽略它们。正如您在本文中看到的那样，有效的架构策略本质上是协作的，而不是独裁的。

17.致谢

我要感谢Birol Aygun，Jesper Rugard Jensen，Ashely McNeile和Paul Oldfield对更新本文的观察。

 

原文：http://agilemodeling.com/essays/agileArchitecture.htm

本文：https://pub.intelligentx.net/agile-architecture-strategies-scaling-agile-development

讨论：请加入知识星球或者小红圈【首席架构师圈】

许多传统项目团队在尝试预先定义所有需求时遇到麻烦，通常是由于误导的想法导致开发人员实际阅读并遵循需求文档包含的内容。现实情况是，需求文档通常是不够的，无论付出多少努力，需求都会发生变化，开发人员最终最终会直接向利益相关者寻求信息（或者只是猜测他们的利益相关者的意思）。敏捷专家知道，如果他们能够预先获得详细的要求，那么他们也可以在他们真正需要信息时也这样做。他们还知道，当需求不可避免地发生变化时，项目早期对详细文档的任何投资都将被浪费。敏捷者选择不在项目早期浪费时间编写详细的需求文档，因为他们知道这是一种非常糟糕的工作方式。

目录

 

• 简而言之，敏捷需求建模
  • 初步要求设想
  • 迭代建模
  • JIT模型风暴
• 验收测试驱动开发（ATDD）
• 要求来自哪里？
• 核心实践
• 要求的类型
• 潜在要求的工件
• 引出需求的技术
• 共同要求建模挑战
• 敏捷需求改变了管理

1.坚果壳中的敏捷需求建模

图1描绘了敏捷模型驱动开发（AMDD）生命周期，描述了敏捷软件开发团队如何应用敏捷建模（AM）。我们现在关注的关键方面是初始需求建模，迭代建模，模型风暴和验收测试驱动开发（ATDD）。基本的想法是，您在项目开始时只进行了足够的建模，以便在高层次上了解系统的要求，然后根据实际需要（JIT）收集详细信息。

图1. AMDD生命周期。

1.1初始需求建模

在项目开始时，您需要花费几天时间来设想高级需求并了解发布的范围（您认为系统应该做什么）。您的目标是深入了解项目的内容，而不是详细记录您认为系统应该执行的操作：如果您确实需要，可以在以后提供文档。对于您的初始需求模型，我的经验是您需要某种形式：

使用模式。顾名思义，使用模型可以让您探索用户如何使用您的系统。这可能是统一过程（UP）项目的基本用例集合，功能驱动开发（FDD）项目的功能集合，或极限编程（XP）项目的用户故事集合，或任何以上是一个训练有素的敏捷团队。

初始域模型。域模型标识基本业务实体类型以及之间的关系。域模型可以被描述为类责任合作者（CRC）卡的集合，细长的UML类图，或甚至是细长的数据模型。该域模型将包含足够的信息：主域实体，它们的主要属性以及这些实体之间的关系。您的模型不需要完整，只需要提供足够的信息以使您熟悉主域概念。

用户界面模型。对于用户界面密集型项目，您应该考虑开发一些屏幕草图甚至是用户界面原型。

你真正需要什么程度的细节？我的经验是，你需要的工件只是勉强足以让你理解而不再需要。例如，图2描绘了一个简单的点形式用例。这个用例很可能已经写在索引卡，一张活动挂图纸或白板上。它包含足够的信息，让您了解用例的作用，实际上它可能包含生命周期中这一点的太多信息，因为只有用例的名称可能足以让您的利益相关者理解其基本原理。你是什​​么意思。另一方面，图3描绘了一个完整记录的正式用例。这是一个记录良好的用例的一个很好的例子，但它比你现在可能需要的更详细。如果你真的需要这个级别的细节，并且在实践中你很少这样做，你可以在实际需要的时候捕获它，然后通过模型进行攻击。如果没有工作软件的具体反馈，项目团队的工作时间越长，您对不能反映利益相关者真正需要的事物进行建模的危险就越大。

编写需求文档的冲动应转变为强烈要求与利益相关者密切合作，然后根据他们告诉您的内容创建工作软件。

图2.一个点状用例。

• 姓名：参加研讨会
• 基本行动方针：
  • 学生输入她的姓名和学号
  • 系统验证学生是否有资格参加研讨会。如果没有资格，则通知学生并结束用例。
  • 系统显示可用研讨会的列表。
  • 学生选择研讨会或决定不参加。
  • 系统验证学生是否有资格参加所选的研讨会。如果没有资格，则要求学生选择另一个。
  • 系统验证研讨会是否符合学生的日程安排。
  • 系统计算并显示费用
  • 学生验证费用，并表明她想要注册。
  • 系统将学生注册到研讨会并为其收费。
  • 系统打印登记收据。

图3.详细的用例。

• 姓名：
  • 参加研讨会
• 标识符：
  • UC 17
• 描述：
  • 在现有学生参加她有资格参加的研讨会。
• 前提条件：
  • 学生在大学注册。
• 后置条件：
  • 如果学生有资格并且房间可用，学生将参加她想要的课程。

基本行动方针：

1. 用例从学生想要参加研讨会开始。
2. 学生通过UI23安全登录屏幕将她的姓名和学号输入系统。
3. 系统根据业务规则BR129确定注册资格，验证学生是否有资格参加大学的研讨会。 [Alt Course A]
4. 系统显示UI32研讨会选择屏幕，其中显示可用研讨会的列表。
5. 学生指出她想要参加的研讨会。 [Alt Course B：学生决定不参加]
6. 系统根据业务规则BR130确定学生参加研讨会的资格，验证学生是否有资格参加研讨会。 [Alt Course C]
7. 系统根据业务规则BR143验证学生研讨会时间表验证研讨会是否符合学生的现有时间表。
8. 系统根据课程目录中公布的费用，适用的学生费用和适用的税费计算研讨会的费用。应用商业规则BR 180计算学生费用和BR45为研讨会计算税收。
9. 系统通过UI33显示研讨会费用屏幕显示费用。
10. 系统询问学生是否仍想参加研讨会。
11. 学生表示她想参加研讨会。
12. 系统让学生参加研讨会。
13. 系统通过UI88研讨会注册摘要屏幕通知学生注册成功。
14. 根据商业规则BR100 Bill Student for Seminar，系统向学生开账单。
15. 系统询问学生是否需要打印注册声明。
16. 这名学生表示她想要一份印刷声明。
17. 系统打印注册声明UI89注册摘要报告。
18. 当学生接受印刷的陈述时，用例结束。

替代课程A：学生不符合参加研讨会的资格。

• A.3。注册商确定学生没有资格参加研讨会。
• A.4。注册商通知学生他没有资格注册。
• A.5。用例结束。

 

替代课程B：学生决定不参加可用的研讨会

• B.5。学生查看研讨会列表，但没有看到他想参加的研讨会。
• B.6。用例结束。

替代课程C：学生没有先决条件

• C.6。注册商确定学生没有资格参加他选择的研讨会。
• C.7。注册员通知学生他没有先决条件。
• C.8。注册员通知学生他需要的先决条件。
• C.9。用例在基本操作过程的第4步继续。

1.2迭代建模

迭代建模是在迭代开始时执行的整体迭代计划工作的一部分。您经常需要比最初更详细的层次探索需求，建模得足以规划满足给定需求所需的工作。

1.3模型风暴

引出了详细的要求，或者可能更好的方式来考虑它是在恰当的时间基础上分析高级要求。当开发人员有新的要求来实施时，也许是图2中的“参加研讨会”用例，他们会问自己是否了解要求的内容。在这种情况下，目前尚不清楚利益相关者想要什么，例如我们没有任何迹象表明屏幕应该是什么样子。他们还会问自己这个要求是否小到足以在不到一天或两天内实施，如果没有，那么将其重组为一个较小的部分集合，他们一次解决一个。较小的东西比较大的东西更容易实现。

为了发现需求背后的细节，开发人员（或采用成对编程方法的项目团队的开发人员）请他们的利益相关者解释他们的意思。这通常通过与利益相关者在纸上或白板上绘制草图来完成。这些“模型风暴会议”通常是即兴事件，通常持续5到10分钟（由于需求块很小，因此很少将风暴建模超过30分钟）。人们聚在一起，聚集在一个共享的建模工具（例如白板）周围，探索问题，直到他们满意他们理解它，然后他们继续（经常编码）。极端程序员（XPers）会将需求建模称为风暴会议“客户问答会议”。

在识别屏幕外观的示例中，与您的利益相关者一起绘制想要屏幕的样子，绘制几个示例，直到您对需要构建的内容达成共识。这样的草图是包容性模型，因为您使用的是简单的工具和建模技术，这使敏捷利益相关者参与的敏捷建模（AM）实践成为可能。建模需求的最佳人选是利益相关者，因为他们是领域专家，而不是您。

敏捷建模

有关如何进行需求建模的详细示例，请阅读文章Agile Requirements Modeling Example。

1.4验收测试驱动开发（ATDD）

测试驱动开发（TDD）（Beck 2003; Astels 2003）是一种进化的开发方法，需要大量的学科和技能（以及良好的工具）。第一步是快速添加测试，基本上只有足够的代码才能失败。接下来，您运行测试，通常是完整的测试套件，但为了提高速度，您可能决定只运行一个子集，以确保新测试确实失败。然后，您更新功能代码以使其通过新测试。第四步是再次运行测试。如果它们失败，您需要更新功能代码并重新测试。一旦测试通过，下一步就是重新开始（您可能首先需要根据需要重构设计中的任何重复）。如图4所示，TDD有两个级别：

• 验收TDD（ATDD）。使用ATDD，您可以根据自己喜欢的术语编写单个验收测试或行为规范，然后使用足够的生产功能/代码来完成该测试。 ATDD的目标是在即时（JIT）的基础上为您的解决方案指定详细的可执行要求。 ATDD也称为行为驱动开发（BDD）。
• 开发者TDD。使用开发人员TDD，您可以编写单个开发人员测试，有时不准确地称为单元测试，然后只需要足够的生产代码来完成该测试。开发人员TDD的目标是在JIT基础上为您的解决方案指定详细的可执行设计。开发人员TDD通常简称为TDD。

图4. ATDD和开发人员TDD如何组合在一起。

使用ATDD，您不需要采用开发人员TDD方法来实现生产代码，尽管绝大多数执行ATDD的团队也会使用开发人员TDD。如图4所示，当您组合ATDD和开发人员TDD时，单个验收测试的创建反过来要求您通过编写测试，编写生产代码，在开发人员TDD级别获得工作周期来多次迭代。显然，要使TDD工作，您需要拥有一个或多个测试框架。对于接受TDD人们将使用Fitnesse或RSpec等工具，对于开发人员TDD敏捷软件开发人员经常使用xUnit系列开源工具，如JUnit或VBUnit。商业测试工具也是可行的选择。没有这样的工具，TDD几乎是不可能的。

ATDD有几个重要的好处。首先，测试不仅验证您在确认级别的工作，它们也是以实时（JIT）方式编写的可执行规范。通过改变您的测试工作顺序，实现双重任务。其次，从详细要求到测试的可追溯性是自动的，因为验收测试是您的详细要求（如果您需要做这样的事情，则会减少可追溯性维护工作）。第三，这适用于所有类型的需求 - 尽管敏捷社区中关于ATDD的大部分讨论都集中在为用户故事编写测试，但事实是这适用于用例，使用场景，业务规则和许多其他类型需求建模工件。

采用ATDD的最大挑战是现有需求从业者缺乏技能，而另一个原因是推动组织内部的专家通过狭隘专注的专家进行推广。

TDDS规范示例

2.需求来自哪里？

您的项目利益相关者 - 直接或间接用户，经理，高级经理，运营人员，支持（服务台）工作人员，测试人员，开发人员以及与您和维护专业人员集成或互动的其他系统 - 是唯一的官方来源要求（是的，开发人员可以提出SUGGEST要求，但利益相关者需要采纳建议）。事实上，项目利益相关者有责任提供，澄清，指定和确定需求的优先顺序。此外，项目利益相关者有权利开发人员花时间来识别和理解这些需求。这个概念对于您作为敏捷建模者的成功至关重要 - 项目利益相关者的角色是提供需求，开发人员的角色是理解和实施它们。

这是否意味着你坐在昏迷中等待你的项目利益相关者告诉你他们想要什么？不，当然不。您可以提出问题来探索他们已经告诉您的内容，可以说是分析活动，激励他们更详细地说明他们想要什么，甚至可以重新思考和修改他们的原始要求。您可以向他们提出新的要求，关键词是SUGGEST，他们应该考虑并接受（可能有修改）或拒绝作为官方要求。为了确定潜在需求，您还可以在项目利益相关方的帮助下，通过现有文档（如公司政策手册，现有遗留系统或公共资源，如网站上的信息，书籍，杂志文章或产品）进行工作。和竞争对手的服务。再一次，您的项目利益相关者是最终的需求来源，这是他们的决定，而不是您的决定。我不能更加强调这一点。

您的项目利益相关者从哪里获得想法？他们经常会对现有的环境感到烦恼，“我真的希望我们能做到这一点。”，会看到他们的竞争对手可以做的事情，他们不能做，可能想要避免他们过去经历过的问题其他系统，或者可能只是对新功能有一个愿景。一些项目利益相关者，特别是运营人员和高级IT管理人员，可能需要根据需要与现有或即将存在的系统或IT战略激励的需求集成，例如减少组织内的计算平台数量。要点是您的项目利益相关者应该根据广泛的输入来制定需求，您可能希望通过提出问题来确保这些需求。

我经常发现，对于我正在构建的系统中涉及具有相关专业知识的人来说，有很大的价值，以帮助确定我的系统的潜在需求。例如，就电子商务系统而言，我可能希望引进具有国际设计经验，税法专业知识或物流专业知识的人员。当您的组织构建包含其不熟悉的方面的系统时，这种方法尤其有用，也许您的电子商务系统是您首次尝试为国际客户提供服务。我会经常带外部专家一两天，并且有几个项目利益相关者“挑选他们的大脑”来解决由于我们缺乏经验而可能缺少的相关问题。这是确保我们覆盖基地的好方法，特别是在我们确定项目的初始范围时，以及让项目利益相关者超越当前环境时的思考。但是，要认识到这种方法存在危险 - 您的外部专家可能会建议听起来不错但现在实际上并不需要的想法。换句话说，你仍然需要像对待任何其他人一样，通过外部专家的建议。

3.核心实践

有几个“最佳实践”可以帮助您通过需求建模工作变得更加灵活：

1. 利益相关者积极参与
2. 采用包容性模式
3. 采取广度优先的方法
4. 模型风暴细节及时（JIT）
5. 优先考虑静态文档的可执行规范
6. 您的目标是实现需求，而不是记录它们
7. 创建独立于平台的要求
8. 越小越好
9. 问题可追溯性
10. 解释技巧
11. 采用利益相关者术语
12. 保持乐趣
13. 获得管理支持
14. 将利益相关者转变为开
15. 像处理优先级堆栈一样处理需求

4.要求类型

我坚信将需求分为两类：

• 行为的。行为要求描述了用户如何与系统交互（用户界面问题），某人如何使用系统（使用）或系统如何履行业务功能（业务规则）。这些通常被称为功能要求。
• 非行为。非行为要求描述了系统的技术特征，其特征通常与可用性，安全性，性能，互操作性，可靠性和可靠性有关。由于IEEE做出错误的命名决定，非行为要求通常被称为“非功能性”要求（据我所知，非功能意味着它不起作用）。

重要的是要理解行为和非行为要求之间的区别是模糊的 - 描述数据访问的预期速度的性能要求本质上是技术性的，但也会反映在影响可用性和潜力的用户界面的响应时间中。用法。访问控制问题，例如允许谁访问特定信息，显然是行为要求，尽管它们通常被认为是属于非行为类别的安全问题。放松一点，不要让自己挂在这样的问题上。如果您对真正关心的要求进行错误分类，关键是识别并理解给定的要求？

5.潜在要求人工品

因为有几种不同类型的需求，其中一些或全部可能适用于您的项目，并且因为每个建模工件都有它的优点和缺点，所以您需要在智能工具包中有几个需求建模工件才能生效。 表1总结了建模需求的常见工件，这些工件在文章“敏捷建模工件”中有更详细的描述。 指示工件通常用于建模的要求类型以及可用于创建工件的潜在“简单”工具（使用简单工具的重要性在前面的“一些哲学”一节中讨论过）。

表1.建模要求的候选工件。

Artifact	Type	Simple Tool	Description
Acceptance Test	Either	FITNesse	Describes an observable feature of a system which is of interest to one or more project stakeholders.
Business rule definition	Behavioral	Index card	A business rule is an operating principle or policy that your software must satisfy.
Change case	Either	Index card	Change cases are used to describe new potential requirements for a system or modifications to existing requirements.
CRC model	Either, Usually Behavioral	Index cards	A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class. A class represents a collection of similar objects, a responsibility is something that a class knows or does, and a collaborator is another class that a class interacts with to fulfill its responsibilities. CRC models are used, during requirements modeling, for conceptual modeling which explores domain concepts and high-level relationships between them.
Constraint definition	Either	Index card	A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements for your project.
Data flow diagram (DFD)	Behavioral	Whiteboard drawing	A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores. When modeling requirements a DFD can be used to model the context of your system, indicating the major external entities that your system interacts with.
Essential UI prototype	Either	Post It notes and flip chart paper	An essential user interface (UI) prototype is a low-fidelity model, or prototype, of the UI for your system - it represents the general ideas behind the UI but not the exact details.
Essential use case	Behavioral	Paper	A use case is a sequence of actions that provide a measurable value to an actor. An essential use-case is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner.
Feature	Either, Usually Behavioral	Index card	A feature is a "small, useful result in the eyes of the client". A feature is a tiny building block for planning, reporting, and tracking. It's understandable, measurable, and do-able (along with several other features) within a two-week increment (Palmer & Felsing 2002).
Technical requirement	Non-Behavioral	Index card	A technical requirement pertains to a non-functional aspect of your system, such as a performance-related issue, a reliability issue, or technical environment issue.
Usage scenario	Behavioral	Index card	A usage scenario describes a single path of logic through one or more use cases or user stories. A use-case scenario could represent the basic course of action, the happy path, through a single use case, a combination of portions of the happy path replaced by the steps of one or more alternate paths through a single use case, or a path spanning several use cases or user stories.
Use case diagram	Behavioral	Whiteboard sketch	The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box. When modeling requirements a use case diagram can be used to model the context of your system, indicating the major external entities that your system interacts with.
User story	Either	Index card	A user story is a reminder to have a conversation with your project stakeholders. User stories capture high-level requirements, including behavioral requirements, business rules, constraints, and technical requirements.

需要记住的一件重要事情是，虽然有几个工件可以用于需求收集，但这并不意味着您需要在任何给定项目中使用所有这些工件。您应该了解何时适合使用每个工件，这些知识使您能够遵循练习将正确的工件应用于您手头的情况。

基础过程通常会激发工件选择。在主页上，我指出AM与另一个软件进程结合使用，例如eXtreme Programming（XP）或Unified Process（UP），其范围是整个生命周期。在XP用户故事和UP用例的情况下，基础流程通常更喜欢某些主要需求工件，这是在需求建模时必须考虑的问题。有关详细信息，请参阅文章AM和XP以及AM和UP。

6.引出要求的技巧

表2总结了几种引出需求的技术。每种技术都有权衡，这意味着如果你想要擅长引出需求，你需要学习几种技术，并且每种技术都可以应用于敏捷和非敏捷方式（我建议你尽可能保持敏捷）。

表2.需求启发技术。

Technique	Description	Strength(s)	Weakness(es)	Staying Agile
Active Stakeholder Participation	Extends On-Site Customer to also have stakeholders (customers) actively involved with the modeling of their requirements.	Highly collaborative technique The people with the domain knowledge define the requirements Information is provided to the team in a timely manner Decisions are made in a timely manner	Many stakeholders need to learn modeling skills Stakeholders often aren't available 100% of the time Airs your dirty laundry to stakeholders	It doesn't get more agile than this
Electronic Interviews	You interview a person over the phone, through video conferencing, or via email.	Supports environments with dispersed stakeholders Provides a permanent record of the conversation	Restricted interaction technique Limited information can be conveyed electronically Risky when it is your only means of communication	Ideally used to support other techniques, not as your primary means of elicitation Face-to-face interviews should be preferred over electronic ones
Face-to-Face Interviews	You meet with someone to discuss their requirements. Although interviews are sometimes impromptu events, it is more common to schedule a specific time and place to meet and to provide at least an informal agenda to the interviewee. It is also common to provide a copy of your interview notes to the interviewee, along with some follow up questions, for their review afterward. One danger of interviews is that you'll be told how the person ideally wants to work, not how they actually work. You should temper interviews with actual observation.	Collaborative technique You can elicit a lot of information quickly from a single person People will tell you things privately that they wouldn't publicly	Interviews must be scheduled in advance Interviewing skills are difficult to learn	Be prepared to follow-up Hold the interview at a whiteboard, so that you can sketch as you talk, turning the interview into a model storming session Actively listen to what they're saying
Focus Groups	You invite a group of actual and/or potential end users to review the current system, if one exists, and to brain storm requirements for the new one.	Collaborative technique Significant amounts of information can be gathered quickly Works well with dispersed stakeholders Works well when actual users do not yet exist	Must be planned in advance Lots of unimportant information will be conveyed It's difficult to identify the right people Focus groups can be diverted by a single strong-willed individual	Hold it in a room with whiteboards or flip chart paper so people can drawn as they talk
Joint Application Design (JAD)	A JAD is a facilitated and highly structured meeting that has specific roles of facilitator, participant, scribe, and observer. JADs have defined rules of behavior including when to speak, and typically use a U-shaped table. It is common practice to distribute a well-defined agenda and an information package which everyone is expected to read before a JAD. Official meeting minutes are written and distributed after a JAD, including a list of action items assigned during the JAD that the facilitator is responsible for ensuring are actually performed.	Facilitator can keep the group focused Significant amounts of information can be gathered quickly Works well with dispersed stakeholders	Restricted interaction technique Facilitation requires great skill JADs must be planned in advance	Loosen the rules about when people can talk Hold it in a room with whiteboards or flip chart paper so people can drawn as they talk
Legacy Code Analysis	You work through the code, and sometimes data sources, of an existing application to determine what it does.	Identifies what has been actually implemented	Restricted interaction technique The actual requirements usually differ from what you currently have It can be very difficult to extract requirements from legacy code, even with good tools	Must be tempered with more interactive techniques such as interviews and active stakeholder participation.
Observation	You sit and watch end users do their daily work to see what actually happens in practice, instead of the often idealistic view which they tell you in interviews or JADs. You should take notes and then ask questions after an observation session to discover why the end users were doing what they were doing at the time.	Helps to identify what people actually do Provides significant insight to developers regarding their stakeholder environments	Restricted interaction technique It is hard to merely observe, you also want to interact Seems like a waste of time because you're "just sitting there" Can be difficult to get permission	Observation is best done passively
On-Site Customer	In XP the customer role is filled by one or more people who are readily available to provide domain-related information to the team and to make requirements-related decisions in a timely manner.	Collaborative technique Information is provided to the team in a timely manner Decisions are made in a timely manner	Airs your dirty laundry to stakeholders Stakeholders need to be educated in their role	Get your stakeholders involved with development by evolving towards an active stakeholder participation approach
Reading	There is often a wealth of written information available to you from which you can discern potential requirements or even just to understand your stakeholders better. Internally you may have existing (albeit out of date) system documentation and vision documents written by your project management office (PMO) to justify your project. Externally there may be web sites describing similar systems, perhaps the sites of your competitors, or even text books describing the domain in which you're currently working.	Opportunity to learn the fundamentals of the domain before interacting with stakeholders	Restricted interaction technique Practice usually differs from what is written down There are limits to how much you can read, and comprehend, and a single sitting	Read details in a just-in-time (JIT) manner

7.共同需求建模挑战

为了敏捷地进行需求建模，您需要处于可能成功的情况，对于许多项目团队而言，不幸的是情况并非如此。通常，需求建模工作会受到您的环境的破坏 - 通常会发现组织的文化不利于有效的软件开发工作，或者项目利益相关者不了解其决策的含义。在本节中，我将确定许多开发团队在需求建模和讨论处理这些问题的潜在解决方案时面临的常见问题。这些常见的挑战（按照链接找出如何克服它们）是：

1. 项目利益相关者访问受限
2. 地理上分散的项目利益相关者
3. 项目利益相关者不知道他们想要什么
4. 项目利益相关者改变主意
5. 优先事项冲突
6. 太多的项目利益相关者希望参与
7. 项目利益相关者规定技术解决方
8. 项目利益相关者无法超越当前的情况
9. 项目利益相关者害怕被压制
10. 项目利益相关者不了解建模工件
11. 开发人员不了解问题域
12. 项目利益相关者过分关注一种类型的需求
13. 项目利益相关者需要有关要求的重要手续
14. 开发人员不了解这些要求

8.敏捷需求变更管理

敏捷软件开发团队接受变革，接受需求将在整个项目中发展的想法。敏捷专家了解，因为需求随着时间的推移不断变化，所以任何对详细文档的早期投资都将被浪费掉。相反，敏捷专家会做足够的初始建模，以确定他们的项目范围，并制定高水平的时间表和估计;这就是你在项目早期真正需要的所有内容，所以你应该做的就是这样。在开发过程中，他们将以及时的方式对风暴进行建模，以便在必要的细节中探索每个需求。

由于需求经常变化，因此需要一种简化，灵活的需求变更管理方法。敏捷专家希望开发高质量和高价值的软件，开发高价值软件的最简单方法是首先实现最高优先级的要求。敏捷主义者努力真正地管理变革，而不是阻止变革，使他们能够最大化利益相关者的投资回报率。您的软件开发团队有一堆需要实施的优先级要求 -  XPers实际上会在索引卡上编写一堆用户故事。团队从堆栈顶部获取最高优先级要求，他们认为这些要求可以在当前迭代中实现。 Scrum建议您冻结当前迭代的要求，以便为开发人员提供一定程度的稳定性。如果您这样做，那么您当前正在实施的要求的任何更改都应被视为另一个新要求。

图5概述了管理团队可能需要完成的工作项的敏捷方法（您实际上可能没有足够的时间或资源来完成所有项目）。该策略反映了Disciplined Agile Delivery（DAD）流程框架所倡导的风险价值方法。这种工作管理方法是对Scrum方法的产品Backlog方法进行需求管理的扩展。在Scrum处理优先级堆栈等需求的地方，DAD更进一步认识到，您不仅要将要求作为日常工作的一部分，而且还要进行非需求相关的工作，例如参加其他团队的培训和审查工作产品。新的工作项（包括作为用户测试活动的一部分确定的缺陷）由项目利益相关者确定优先级，并在适当的位置添加到堆栈中。您的项目利益相关者有权定义新需求，改变他们对现有需求的看法，甚至可以根据需要重新确定需求的优先级。但是，利益相关者还必须负责及时做出决策和提供信息。

图5.敏捷需求变更管理流程。

 

开发人员负责估算实施他们将要处理的要求所需的工作量。 虽然你可能担心开发人员没有必要的估算技能，而且一开始就是这样，事实是人们很快就会很好地估计当他们知道他们会去 必须不辜负这些估计。 有关更多信息，请阅读敏捷变更需求管理。

 

原文：http://agilemodeling.com/essays/agileRequirements.htm

本文：https://pub.intelligentx.net/node/696

讨论：请加入知识星球或者小红圈【首席架构师圈】