Episode 188: Requirements in Agile Projects
01:00:01 Share

<context>第188集：敏捷项目中的需求 录音地点：伦敦帕丁顿 嘉宾：苏珊·罗伯逊和詹姆斯·罗伯逊，亚特兰大系统公会 IEEE软件的需求专栏编辑尼尔·梅登与亚特兰大系统公会的苏珊和詹姆斯·罗伯逊讨论了敏捷实践对需求工作的出现和影响。采访开始时探讨了敏捷实践如何……</context> <raw_text>0 这是软件工程广播，专业开发人员的播客。网址是 se-radio.net。SE Radio 每月至少为您带来相关且详细的软件工程主题讨论。SE Radio 由 IEEE 软件杂志提供支持。在线访问 computer.org/software。

所以，苏珊和詹姆斯，欢迎来到 IEEE 软件和 SE Radio。谢谢。谢谢你们邀请我们。首先，能否向听众介绍一下你们自己？我叫苏珊·罗伯逊，我是亚特兰大系统公会的负责人。这个组织已经存在多久了，詹姆斯？我想现在已经有 27 年了。我们有六个人。其中一位合伙人实际上是坐在我旁边的詹姆斯。

正如你们无疑已经了解到的，我也是亚特兰大系统公会的负责人。我希望我们在采访中能够传达一些这一点。很好。那么我们今天想讨论的是敏捷与需求之间的交集，敏捷已经存在了十多年，并且与需求的交集。

所以我想先问一下你们在需求工作中何时开始熟悉或意识到敏捷项目及其对需求工作的潜在影响。实际上大约是 10 年前。不是吗，当肯特·贝克写了关于极限编程的书时？我认为那可能早于这个时间。至少我认为肯特·贝克写的书早于这个时间，但不去...

查证的话就说是 10 年吧。好吧，我认为它可能进入了主流，你知道他写得很好，他有一些非常好的想法，吸引了很多人的注意，他们说，哦，太好了，这意味着我们可以在一个小组中工作，我们可以构建东西，实际上我认为人们犯的一个大错误是，贝克并不真的打算让他们这样做。

但人们犯的一个大错误是说，哦，如果我们与另一个人紧密合作，我们实际上不需要做任何需求工作，因为我们在这里，我们可以构建软件。这是非常以软件为中心的。这是我最早的记忆。你呢？我认为我最早的记忆是阅读《极限编程》，但还有，我不想用“歇斯底里”这个词，但...

围绕敏捷技术引入的极端狂热。这在软件工程中非常明显，一旦某种新范式出现，大家，不是每个人，但很多人都会跳上潮流，抛弃一切。

我们不做科学家所做的事情，即站在巨人的肩膀上。作为一个行业，我们倾向于抛弃一切，从头开始，而这种情况在我们工作的一生中，苏珊和我已经看到发生过四五次。敏捷的问题是...

我在这里谈论的是大A敏捷，遵循一种方法，无论是 XP、Scrum、Crystal 还是其他任何一种变体，问题在于，婴儿和洗澡水一起被扔掉了。问题被视为需求都是错误的，我们必须有这个巨大的需求文档，必须写好并完成，然后扔给开发团队。

这花了很长时间才有任何进展。需求被指出是问题的罪魁祸首。因此，早期的敏捷主义者抛弃了需求。我认为这是一个巨大的错误。我认为我们稍后会在很大程度上回到这一点。所以我早期的，如果你问我对敏捷的早期...

反应是，这生活得很危险，因为我们抛弃了非常有价值的东西，而实际上这里有两个方面的空间。我认为这将是我的... 你发现你的客户表达了这种观点，还是他们在开始转向敏捷时采取了更务实的中间道路？好吧，客户要么感到困惑，要么

遵循某种逐步的方法，或者有时受到对敏捷几乎没有了解的管理者的驱动。只是，如果你是敏捷的，那就意味着你可以更快地完成事情。因此，我与之合作的许多团队都面临着巨大的压力，要变得敏捷，而这实际上转化为更快地完成这项工作。

我认为更聪明的观点，更聪明的方法是，当人们说，等等，这实际上意味着什么？为什么这是个好主意？因为这是个好主意。这是个绝妙的主意。那么它是什么？然后你知道，你进行抽象思考，你会想，实际上你想要产生价值，但

你想要产生它，因为我们为人们构建系统，而系统，我在这里谈论的是广义的，不仅仅是软件，而是系统。我们希望能够产生这种价值，我们希望能够快速做到这一点，并且我们希望能够在商业变化时迅速调整，而商业变化的频率越来越高。

我认为真正理解敏捷是什么的人明白这一点。他们不会说，敏捷意味着你做 Scrum，或者敏捷意味着你不做需求，或者他们从拼凑的补丁中学到的任何东西。因此，理解敏捷的动机、理由，而不是它的机制。哦，绝对是。我认为这是我关于大A敏捷和小a敏捷的观点。我们非常支持小a敏捷。

我认为如果你过于盲目地遵循一种方法，无论这种方法是什么，都可能导致你走上错误的道路。这是我与早期采用者客户的经验。他们觉得如果他们只是做了大A敏捷方法所说的所有事情，他们的问题就会解决。

结果证明这并不起作用。事情并不是这样运作的。我们不能盲目地遵循一种方法，但如果我们灵活而不僵化，换句话说，小a敏捷，那么它确实带来了好处。好吧，如果人们理解小a敏捷是什么，那么他们可以选择适合特定情况的技术和

方法。例如，如果他们说，好吧，我们真正想要做的是尽快充分理解问题，以决定什么能给人们带来最大的价值。有时这意味着使用特定的技术或构建特定类型的模型。有时这意味着经历不同类型的周期，使用原型，使用模拟，所有我们知道的被视为有用的技术和方法。

但问题是，因为它是新的，并且因为它被呈现为一种技术或方法，这就是人们了解它的方式。因此，他们将其视为一种技术，而不是其背后的东西。这就是我们所说的小a敏捷。

是的，我现在的大多数客户正在远离大A敏捷，而小a敏捷则在他们获得更大价值的同时，更多地关注更好的思考。小a敏捷在今天的项目中如何表现？通过采用一些超出原始大A敏捷阵营的东西。例如，有些东西对我们来说非常重要的是

系统思维。这在大多数教科书中没有提到，但它是我们所做的非常重要的一部分。例如，创新，在我能找到的任何地方都没有提到，但如果我们要构建有用的东西，它绝对是至关重要的。我不知道是谁第一次说的，

用另一种方式来表达，你可以以任何你想要的方式构建某物。你可以以任何你想要的方式构建软件，但如果它没有做一些有用的事情，那么根据定义它就是完全无用的。在早期采用敏捷的过程中

强调的是快速完成事情。好吧，我还要说，你可以以你想要的速度构建某物，但如果它没有完成需要做的事情，那它就是完全无用的。因此，我认为客户或用户和软件构建者现在意识到，

花一点时间做好事情比按时、按预算构建完全无用的东西要好。是的，但我认为你看到的另一件事是，当人们真正理解小a敏捷时，他们并不是被任何僵化的过程驱动，根本不是。他们所寻找的是尽快掌握一个问题

以便他们可以就哪些部分做什么、哪些部分进一步深入做出一些决策。可能是一个团队以他们喜欢的特定方式工作，或者他们可能在尝试其他东西。但这并不是由任何过程或任何僵化的过程驱动的。我认为你经常听到的关于敏捷的事情是

要么利益相关者真的无法表达他们的需求，要么在他们能够表达这些需求时，需求已经改变。我们生活在如此动态的世界中，以至于以我们可能认为的传统方式记录需求几乎毫无意义。你对此有何看法？我认为需求变化的速度远比人们所说的要慢得多。

问题在于，需求在第一时间从未正确收集，因此当它们被呈现给用户时，用户会说，不，这不是我们所指的，这被视为变化的需求。好吧，这不是变化的需求。基本的业务需求仍然存在。只是它没有被正确表达。我注意到早期项目的一个方面

大A敏捷采用的重点是构建一些东西。让我们去构建一些软件。甚至还有关于迭代时间以小时甚至分钟计时的这种强硬态度，以便不断生产软件，不断生产这些东西。这是在生产一个解决方案，但不一定是解决正确问题的方案。

仅仅因为我们交付了一段软件并不意味着你在交付价值。关于持续交付客户价值的几乎是咒语般的重复是

软件不一定有价值。如果它没有完成所需的事情，那么它就是无用的。根本没有价值。因此，我现在看到越来越多的人从持续交付软件的状态中退回，转向更好地理解真正的问题。我认为这非常健康。好吧，还有你提到的另一件事，D 词，文档。嗯哼。

我认为人们对此也有很多误解。我认为人们认为如果你做需求，就意味着你必须在大型文档中生成大量正式书面文档，等等。但事实并非如此。实际上，你想要留下一个痕迹。如果你在一个共同办公的环境中...

没有什么可以阻止你在墙壁和翻转图表上留下你的痕迹。我们有摄像机，我们到处都有摄像机，每个人都有。我们有各种各样的技术可以帮助我们摆脱坐下来并说，现在是做文档的时候的束缚。我的意思是，只有在你需要进行翻译的情况下

才能进行翻译，以便你试图与之沟通的人能够理解它。因此，如果你在外包或类似的事情上，你可能需要在翻译上花费更多的预算，但如果你不需要，就不应该这样做。那么，传统需求技术的报告性消亡是否为时已晚？好吧，我不知道，因为我在想你所说的传统需求技术是什么意思。

以可衡量的方式记录需求，你有一个可以分析各种属性、完整性和正确性的规范。但我认为，你看，你可以在一个共同办公的团队中做到这一点，白墙上。我的意思是，我知道这很极端，但你可以做到。关键是，这是一个重要的关键，

区分形式和内容，内容是你试图传达的东西。现在，如果你有一个团队，例如，他们在讨论需求，假设他们说，“好吧，我们有 125 个需求。”如果他们没有共享的关于需求是什么的心理模型，

他们只会失去意义。因此，你必须有某种共享的心理模型，并且不必由其他人强加，只要那个团队理解这一点。如果你有这一点，那么你可以追踪需求，你可以使它们可衡量，你可以说你是否有这一部分需求，是否有理由，是否没有。它可能只是以不同的形式存在。因此，敏捷为我们带来了新的需求形式。

内容保持不变，但形式发生了变化。绝对是。我认为现在的需求，我们接受一些需求可以通过口头交流，可以在故事卡的背面草拟和涂鸦。对此没有任何问题。我认为

这部分回到了你所称的需求，当你说传统需求时，如果你认为传统需求是业务分析师去与客户交谈，记录他们所说的任何内容，将其翻译成某种形式以提供给开发人员，是的，这种情况已经存在很长时间了。

如果你将需求视为，让我称之为小r需求，实际上找出真正的问题并有某种方式进行沟通，无论是书面还是非书面，那么这就是我们今天看到的需求发展方向。确实有一些需求，你刚才提到文档，仍然需要文档。

我们从敏捷方法中学到的，记录一段软件的功能是完全无用的，因为代码是功能的最佳文档。然而，仅仅因为我们可以阅读代码来了解它在做什么，并不意味着记录这一点是重要的。记录某事存在的原因是非常重要的。

因为在五年后，当这段软件仍然存在时，让我们面对现实，软件的生命周期越来越长，我有时在我的需求课程中进行简短调查，发现有...

属于房间内组织的东西比房间内的学生还要老。因此，知道某事存在的原因是重要的。因此，这种类型的文档并没有消失，或者至少...

那些在没有保留这种文档的情况下开发软件的公司意识到他们确实需要它。某事背后的理由，这就是为什么我们在雪卡上始终记录某事背后的原因。我认为这回到了当你谈论需求或我们之前谈论需求变化时，如果你发现某个需求的理由，

或者甚至是用例的理由，或者一整项工作的理由，你会发现这集中大家的注意力在于真正的问题是什么。你会发现问题没有变化，但对该问题的建议解决方案确实会变化。因此，与其说是消亡，我更愿意说需求工作正在变化。

成一种不同的形式，强调理由、背后的推理，强调发现真正的工作，而不是传统上强调撰写大型文档。大型文档，是的。

话虽如此，如果你在外包，仍然需要大型文档，让我们面对现实，大多数组织今天都在外包。你需要编写完整的规范，因为当你将其发送到印度、俄罗斯、印尼或你发送到的任何地方时，他们确实需要完整的规范。很少有外包商会与你进行迭代工作。

我可以看到这如何适用于功能性需求。质量需求呢？可用性、可靠性？我见过它们被涂鸦在用户故事卡的背面等等。你认为这些在敏捷中需要以不同的方式记录吗？我认为是的。因为定性需求，我们称之为非功能性需求，往往存在于多个业务事件、用例、事件中，

跨越多个不同的事务，无论你想使用什么划分。因此，将它们附加到一张故事卡上可能不是最好的做法，因为如果有另一个类似的故事，他们可能不会提及相同的非功能性需求。因此，几乎可以说...

定性需求必须单独记录，因为它们是整个开发工作的一个总体要求，而不是其中的某一部分。是的，但它们也需要与相关的功能部分连接，并且还需要与真正理解该特定类型非功能性需求的人连接。因此，现在你有了从功能到非功能性需求到特定利益相关者的线程，他们是专家。

我们越来越多地看到，由于我们的系统可以做更多的事情并支持更多的非功能性需求，我们看到越来越多的内部咨询利益相关者，他们是可用性专家，专注于这种类型的需求，他们是专家。如果有某种正式的方式将这些东西写下来或...

以某种方式使其对人们可用。这意味着你开始打开重用的大门，真正打开重用的大门，因为你不必每次都去发现这些可用性需求并记录它们的测量。但这不会发生，除非你实际上在组织中建立了这种社会结构。好吧，所以...

以小a敏捷为基础，你认为你的咨询和需求实践在过去十年中发生了怎样的变化？你是如何修改 Valere 或改变你教授或培训人们的内容的？好吧，现在，因为人们开始意识到更广泛的图景。虽然不够，但他们正在开始...

他们开始意识到我们必须成为系统思考者。正因为如此，我们实际上可以让他们在进行一项工作之前就开始考虑需求。我真的意味着在开始之前，在你实际开始说，好吧，让我们去找出所有原子需求之前。为什么不识别出我们使用的那个非常简单的模型，范围、利益相关者和目标。如果你能使其可见...

作为最高级别的需求，但你实际上使它们可衡量。在这一点上，足够好地识别出这些部分以开始优先排序。这就是小A的地方。因为你越早开始优先排序这些部分...

你就能越敏捷，因为你可以说，哦，好吧，我们进行了快速分析。我们可以识别出这些部分，我们有 50 个部分，我们将进行快速优先排序，主要价值在哪里，困难、风险、成本在哪里，

但你可以很快做到这一点。这会是在草拟的需求上，需求并不是我们可能期望的那样完美形成？它与功能方面相连。非功能性方面与利益相关者相连。因此，即使你不知道所有的细节...

你确实知道你在高层次上谈论的是什么。换句话说，高层次并不意味着我真的不知道我在说什么，也许我会找到答案。高层次意味着我们理解我们现在认为的是什么，以便我们知道如果它发生变化。这样你就可以... 你可以非常敏捷。你可以说，好吧，我要处理这一部分，我们将交付某些东西，或者我们将处理这一部分，因为我们认为这是风险最大的一件事，如果我们不能做到这一点，我们不妨...

停止这个项目。这些事情人们可以用来变得更加敏捷。我认为我看到的变化是，大A敏捷的人们正在更加关注问题空间，如果你想谈论传统需求和传统敏捷如何结合在一起，那就是对问题空间的调查，以找出我们真正想要做的是什么，而我们想要做的不是构建一段软件，而是改善一个业务，这两者之间有一个微妙而重要的区别。另一个是

苏珊提到的优先排序，关注问题空间，随意切割，但将其切割成部分，然后优先排序这些部分，因为我们所做的很多事情并不重要。很多已经完成的事情并不重要。我们构建的软件执行的功能仅在每五年使用一次，或者并不重要，发生得很少，给软件的拥有者带来的价值很小，因此优先排序我认为是

促使人们更仔细地思考他们所做的事情，而不是开发太多软件，而是只为重要的事情开发。我们实际上能做到的最少是什么？这很有趣。这非常重要。你提到了系统思维。

对我来说，系统思维涉及某种建模或走过某些东西。但它涉及工件。这些模型和工件通常不是你与大A敏捷相关联的东西。他们倾向于避开这种建模，并将其视为文档。

你在你的方法中使用这些技术吗？哦，绝对是。非常重要。系统思维是极其重要的，因为无论你的方法是什么，不能构建图表的说法都是胡说八道，因为如果你试图在脑海中完成所有这些，或者在卡片的背面，这将行不通。

通常你确实需要某种模型来查看你所做的事情的效果。构建一段软件，所以让我稍微退后一步。我刚才谈到的问题空间，调查问题空间。这是我们看到越来越多的事情，人们在思考他们试图改善的工作领域，而不仅仅是软件。

早期的大A敏捷直接进入一段软件，根本不知道它是否能解决正确的问题，因为他们只关注这个非常狭窄的焦点。好吧，焦点正在扩大。我们在看一项工作，但系统思维说你必须考虑这项工作的变化会对进入的整个组织产生什么影响。如果这是一个简单的、简化的方法，

像游戏这样的软件，你并不关心周围发生了什么，因为人们会买这个游戏或不买。你不关心他们生活中的其他事情。如果你去为汽车制造商引入一个新的库存控制系统，你会非常关心这对制造、财务、人员和其他一切的影响。

如果我们不考虑所有这些其他事情，那么我们就有潜在的灾难。但这指向我看到的事情，人们现在越来越愿意...

回到过去证明有用的东西，并将其与迭代、敏捷、能够以良好的系统思考者的方式看待事物的想法联系起来。因此，例如，人们现在说，过程模型在某些情况下有效，但

数据模型有效，状态模型有效，系统流、动态模型有效，但他们也开始理解如何将这些连接起来，以便保持一致。

你可以选择在什么情况下使用哪些，但你可以将它们连接到你正在进行的项目的整体图景中。这回到了我之前说的事情，人们可以选择最适合他们所做事情的技术...

程序、可视化。但这确实依赖于一个非常重要的系统思维技能，我之前提到过，能够区分由于形式而存在的东西和由于内容而存在的东西。并不是说形式不好，而是能够理解哪一个是哪个。那么你现在是否看到你的角色部分是帮助人们

在项目中选择合适的技术和工具，以便在某种大型的挑选和混合的敏捷商店中使用。外面有很多选择。你可能会被选择淹没。你认为这是你们的角色吗？哦，我们确实。我们与人们做了很多这样的事情。显然，你必须先了解一些关于那个高层次分析的内容。然后从那里，因为我们见过很多人

使用的方法，我们可以告诉人们，为什么不从数据模型开始，例如，因为这是一个非常数据密集的问题，如果你从数据开始，你会更快获得更多的洞察力，而这些人可能从未

这样做过，因为他们习惯于担心过程或功能或他们习惯于开始的其他事情。因此，帮助人们摆脱“我们总是这样做”的思维方式也是一种解放。但也要让团队摆脱相信模型或技术是其目的的信念。目的在于做一些工作，以某种方式改善所有者的业务。

在技术或图表等方面进行争论，我发现自己所做的很多事情是告诉人们，你可以以任何你喜欢的方式构建数据模型，如果三个不同的人使用三种不同的符号，那也没关系，因为本质上他们都在谈论同一件事。

没有一个模型会明显优于另一个。事实上，如果你愿意，你可以以表格形式做到这一点。实际上并不重要。但让人们意识到这一点是困难的，如果他们没有很多经验，因为这确实依赖于进行过...

相当多的项目工作，以便你可以理解这些不同的抽象。我们一直在专注于帮助人们成为更好的抽象者，因为我认为每个人都可以在抽象方面做得更好，只是通常没有人教你这样做。

你被教导以特定的方式去做，而不是去理解其背后的东西。即使你被教导过，你也需要更多的经验，才能说，哦，这实际上与这个是一样的。哦，这现在会更好。因此，我们一直在开发一些模型。我的意思是，我们的棕色牛模型非常有用。

作为一种帮助人们看到你可以做的四种不同观点的方式。在业务分析中，传统上说的是现状和目标。好吧，这并不足够。你需要现状和它是如何完成的

和将要的以及它将如何，但你也需要了解其背后的原因，这实际上是关注目的和本质等方面，因此这是模型和我们帮助人们使用的东西，作为一个起点，帮助他们变得更加敏捷，因为如果你知道你可以从四个不同的有用视角出发，你可以从更多的视角出发，但四个有用的视角

那么无论你从哪里开始都无所谓。这就是让人们变得敏捷的原因。因此，抽象是能够独立于其实现看到某事的极其有用的能力之一。换句话说，背后的根本原因。我们通常称之为问题的本质。一旦你能看到本质，看到某事背后的原因，它确实...

极大地帮助你提出更好的实现。我之前对大A敏捷的批评是，他们急于进入实现，而没有关注潜在的问题，换句话说，根本没有进行任何抽象，只是简单地生产一段软件。抱怨需求变化是因为没有关注抽象，你构建了一段软件，它可能无法满足真正的需求。

因此，当对那段软件提出变更请求时，这被视为需求的变化。其实并不是。原始需求是一样的。如果人们花一点时间从实现中抽象出来，那么...

你就能看到真正的问题。我认为这极大地帮助了。但你看，如果你真的敏捷，假设你试图理解一个需求，而你遇到麻烦，人们也在告诉你，你就是不明白。

那么，构建某种模拟、构建原型，利用它作为尝试弄清楚你真正想做什么的方式，是一件聪明的事情。如果你能做到这一点，那么你真的在变得敏捷。你开始看到客户...

构建解决方案抽象，建模架构，因为这在早期的大A敏捷中似乎消失了，直接从用户故事转向代码。架构在哪里？这在项目中重新出现了吗？非常非常缓慢。出于我无法解释的原因，架构不受欢迎。

这是一个必要的事情，但没有人想谈论它。因此，架构，是的，它正在重新出现，人们理解其必要性等等。但同样，架构并没有因TOGAF 9等事物而为自己谋得任何好处，只有五个人能正确理解它。所以...

我在这里夸大其词，我急于补充，但将其包装在这种神秘的展示中并没有给它带来任何好处。因此，出于这个原因，它不受欢迎。好吧。让我们看看创新。你提到这是当今项目的驱动因素之一，以及我们为什么要开发软件。你认为创新与敏捷之间的关系如何？我可以看到敏捷的支持者可以争辩说它是响应性和动态的。

你的经历是什么？我们今天早些时候实际上对此进行了争论。我将呈现我的版本，这无疑是正确的版本。然后我会和你争论。最有价值的创新...

出现在项目的早期，而最有价值的创新是那些影响整个问题空间的创新。现在我急于补充，创新并不是想出一些新的技术小玩意，比如触摸敏感的玻璃屏幕或新的iPad或其他任何东西。创新是新鲜的思维，以不同的方式思考问题领域。

而最有价值的创新是由于某种创新的新鲜思维而改变整个问题的那些创新。一个我想到的例子，正好因为我现在正在做的是英国的第一直接银行。第一直接银行，新的银行，或者说大约五年前是一个全新的银行。

他们开始时说，让我们看看银行的整个问题，以及人们喜欢什么和不喜欢什么。因此，他们并没有从传统银行的角度来看待这个问题，而是说，我们想从客户的角度来看待银行，这实际上是相当创新的，因为大多数银行是从银行的角度来看待银行的。而

第一直接银行提出了一种完全无分行、无纸化的银行方式。所有操作都在互联网上或通过电话完成，重要的是，为了使这一切运作，因为任何人都可以实现这一点，为了使这一切运作，他们的新鲜思维或创新思维是

关于他们为银行雇佣的人，他们都来自服务行业。如果你曾在传统银行工作，你就不能为第一直接银行工作。你必须来自航空公司、酒店或与客户服务相关的行业，而这正是他们所销售的。他们说，银行不是关于金钱，而是关于客户服务。当你考虑到这一点时，这完全正确。但汤姆，我们之前讨论的概念是...

你说，啊，是的，敏捷并不意味着你会创新。好吧，我坚持认为，如果你稍微敏捷一点...

你正在发展和应用使你能够说，好的，这就是我们现在所处的位置的技能，以便其他人，快速，快速是这里的关键词，以便其他人能够理解你在说什么。然后如果你真的敏捷，你会说，我们不再往前走。我们将质疑所有这些事情。

我们将质疑谁在这里。啊，是的，但这可能是这样吗？我们将雇佣谁来做这个？我们为什么真的要这样做？现在，你必须有某种起点，因为如果人们只是疯狂地头脑风暴，最终的结果是他们有很多浮动的想法，而

就这样。但如果你真的敏捷，你可以快速找到一个起点，某种你可以在其上构建、反对、替换的东西。这就是我坚持认为小a敏捷，如果你真的、真的掌握了它，它会让你更具创新性。好吧，如果你考虑大A敏捷和一个时间限制的冲刺...

一次迭代，它实际上没有给你留出创新的时间，因为你已经承诺在给定的日期之前构建一段软件。这就是我们争论的核心，因为你在谈论大A不具创新性，而我在谈论小a是创新的，但我们只是在说敏捷。因此，我们不得不讨论它。

让我试着调解我面前的家庭争执，以防听众担心这次采访对你们的和谐的影响。我认为这个时间限制是一个有趣的问题。当然，我知道从创造力和创新的角度来看，孵化、思考想法、深入思考的过程是可能的，而这往往与需要做某事并被看到做某事的需求不太契合。

好吧，创新不是一个严格的过程。这是一个奇怪的事情，我们不知道它需要多长时间。我们不知道想法在实现之前会停留多久。iPad，最近历史上最成功的消费设备之一，花了相当多的时间。

因为它被反复推敲，它改变了，从一种东西变成另一种东西。iPad的一些想法被放入了首先开发的iPhone中，然后后来iPad本身出现。这些事情无法被定时。现在，就价值而言，iPad对苹果来说是极其有价值的。

顺便提一下，这也是没人知道他们想要的。这部分只是稍微偏离一下，让我说说大R需求。人们不知道他们想要什么。我敢打赌，听这个广播的没有人知道在看到iPad之前他们想要一个iPad。

在他们知道它的存在之前，如果问他们是否需要一个平板大小的设备来携带并仅用手指操作，没有键盘？答案会是“不”。但你在谈论一个发明。好吧，那是一个发明，是的。与创新相对。我用它作为一个例子，说明我们不知道我们想要什么。因此，依赖于...

传统的需求收集技术，坐下来问客户，坐下来问用户，你想要什么？这行不通。同样，在大A敏捷中，产品负责人的角色也行不通，因为来自业务的一个人不可能知道需要什么。他或她可能知道

模糊的他们认为可能是解决方案，但这被证明是有缺陷的。大多数客户正在远离拥有单一产品负责人的做法，仅仅因为我们不知道我们想要什么正在成为现实。利用更大范围的问题视角。你知道有任何敏捷项目的例子吗，这些项目在该业务或更广泛的范围内导致了创新？

导致创新的敏捷项目？是的，一个产生创新结果的敏捷项目。这是一个显而易见的问题，我觉得我应该问。

我认为来自桌子一侧的沉默表示没有，我们没有。好吧，我认为我们会邀请听众通过电子邮件或社交媒体对此发表评论。请随意，我知道... 在小的方面你可以看到，但我无法孤立出任何大的事情。在小的方面...

有人说，哦，你真的能做到吗？这并不被视为创新，但它确实是创新，因为否则不会发生。更方便的东西。使某人能够做更多工作的东西。我认为创新的问题在于我们总是期望它是来自蓝天或天堂或其他任何地方的闪电。你说闪电。牙买加，我想是它们的来源。好吧，所以...

让我们更广泛地看一下。与大A敏捷有很多关联，当然使用一些工具和技术，Kanban、用户故事卡等等。但如果你更广泛地看软件工程，你会看到对治理而非管理的关注。

关注重要的软技能。我现在也关注政治，理解政治在软件工程中的作用。你认为这些在敏捷项目中重要吗？

我认为它们在所有项目中都很重要。我不太确定你所说的政治是什么意思。你是指政府政治还是内部办公室政治？我更倾向于内部办公室政治。如果你寻求改变一个业务，目标领域中的政治角色不可避免地会以某种政治行为表现出来。是的，我认为这使得商业分析师特别需要成为更好的政治家，因为让某事被接受是最困难的事情。想出创新并不难。

在组织内销售创新并让人们接受它是迄今为止最困难的部分。我只是想起一些我的客户，他们说，好吧，我们想要敏捷，他们真的在努力成为小a敏捷。他们真的非常努力。问题是，有时组织是以孤岛的形式结构化的。

但商业分析师必须跨越这些孤岛工作。为了做到这一点，他们必须能够进行谈判，因为不同孤岛中的不同人有着非常不同的目的。因此，再次，商业分析师真的必须在心理学和政治等方面变得越来越好，而这些是...

天真的商业分析师没有意识到的，因为他们没有接受过这样的培训。他们认为写下需求、构建模型和成为大A敏捷是你应该做的事情。

这是一种非常不同的技能。好吧，最重要的商业分析师技能不幸的是没有被教授。政治非常重要。让我想起在肯辛顿和切尔西皇家区的人民优先部分的案例，这是一个非常创新的方法，展示了人们可以获得的东西及其有价值的用途。

不幸的是，人民优先的链接在皇家区网站的底部，很难看到，除非你滚动。但如果你去那里，你会看到这真是一个精彩的作品。

非常创新，非常非传统的地方政府。但他们必须奋斗。让这一切发生的人们必须真正，嗯，当我说奋斗时，他们必须说服组织不同部分的人接受他们在界面上如此不同是可以的。你可以称之为政治。

你可以称之为销售，你可以称之为外交，无论你想称之为什么。这是所需的。这是非常必要的。你认为敏捷对沟通和协作的依赖...

比起写东西，更加增加了分析师所需的那些软技能的重要性吗？我认为它提高了人们对这些技能必要性的意识。我认为它们一直非常非常重要，但人们并没有真正准备好承认这一点或意识到这一点。我认为这确实使人们更加意识到这一点。好吧，这将其公之于众，不是吗？

这很重要，因为在此之前，商业分析师能够躲在一个隔间里写东西，如果他们不准确，那么他或她总是可以指责其他人。好吧，现在随着沟通，口头沟通变得如此重要，如果你正在进行公开讨论，很难隐藏自己，我认为这是沟通带来的一个非常好的事情。

敏捷方法带来的一个相当不错的事情是它强调沟通。好吧，这意味着商业分析师的教育项目越来越意识到我们不仅需要技术方面，你多年前说过，社会技术视角，我们必须在社会和技术方面教育商业分析师。这是否意味着你正在改变分析师的培训，以给予他们更多的思考？

即兴思考的技能？因为在我看来，似乎有更多的即时... 哦，即兴思考。是的，我的商业分析课程中，我实际上教授演讲技巧，因为政治、外交、销售，无论你想称之为什么的一部分，是向人们展示想法，并且...

人们，观众更有可能接受一个想法，如果它被有效地呈现。如果你的演讲者站在那里，手足无措，喃喃自语，表现得很糟糕，那么这个想法就会和演讲者一起被抛弃。因此，所有这些倾听、交谈、展示的技能，

我甚至试图说服人们绘画是一项重要技能，如果你能画得稍微好一点，它将帮助你传达你的想法。这是一个非常非常难以推销的事情。不，不，因为例如，丹·罗温在他的网站上非常关注绘画，他真的说服了很多人，你实际上可以学会画得相当好。

即使你可能没有天赋，我上过他的一些课程，它们很好，任何人都可以画，只是他们相信自己可以画才能做到，这不必是伟大的艺术，你知道，当我谈论成为伟大的艺术家，成为另一个大卫·霍克尼时，这只是传达一个想法，给人们信心，我认为他们可以做到，就像那样，还有那个美妙的日本Kachuka？Kachuka？

Pecha Kucha。Pecha Kucha，让某人做一个演示，时间受到严格限制。20张幻灯片，每张幻灯片持续20秒，并自动推进。因此，你有3分钟40秒来传达任何内容。

所以你不能在要点上喃喃自语等等。它必须是一个简短的章节。这确实是人们可以做到的，他们并不认为自己可以做到。这是一个奇妙的... 这真是一个敏捷的想法。但也只是最终的时间限制。回到绘画或素描，或者如果我可以引入可视化。

因为如果你能向某人展示一个可视化你想法的图表，其他人更容易理解它，他们更有可能接受它。那么我们是从用户故事转向用户故事板吗？是的。

如果你愿意，是的，任何视觉图形展示，我认为都是重要的。我认为用户故事也很好，如果它们被智能地使用。这就像所有事情，你知道，只要你能将其与正在发生的其他事情联系起来，这真的是一个好主意。

但故事板本身，如果我们回到系统思维，如果你有故事板而不是故事卡，你会对正在发生的事情有更好、更广泛的视角。你更有可能看到你所做的任何事情的后果。但这不是更多的维度吗？这更多的维度和更好的可视化。

那么展望未来，你认为在接下来的几年中，敏捷和需求面临的重大挑战是什么？是否有新的趋势将带来挑战？我们还没有到达那里，我们仍然需要改进我们在大A或小a敏捷中所做的事情吗？我认为我最大的烦恼，你可能已经注意到了，就是商业分析师必须在系统思维方面变得更好，以便他们能够

接受新想法，而不是被它们驱动。系统思维已经存在很长时间了。只是我们还没有真正将这些东西结合在一起。我认为我们现在开始这样做。例如，艾玛·朗曼去年在BA会议上发表了演讲。她做了其中一个主题演讲。她专注于系统思维。她确实点亮了很多人的思维。还有约翰，他叫什么名字？

约翰·塞登也做了另一个关于这个的演讲。他们来自那个学科，但商业分析师说，哦，是的，这绝对与我们所做的事情有很大关系，如果我们能做得更好，那将对我们大有帮助。它是在冲刺零或冲刺负一中，还是系统思维贯穿于冲刺周期？贯穿始终。贯穿始终。虽然...

我想说，我认为最有价值的系统思维发生在冲刺负一或负二或某个地方，因为最有价值的系统思维，最有价值的创新，所有这些都发生在你开始构建软件之前。我们需要在所有冲刺之前进行马拉松。绝对如此。我们在这次采访中的后奥运主题。后奥运主题。

我看到的一个非常健康的事情是，敏捷的宗教性质正在减弱。人们想要敏捷，但他们越来越多地采用传统方法。

系统思维开始渗透到敏捷中。创新开始融入其中等等。因此，我认为这非常健康，因为敏捷中有很多好的东西，但也有很多好的东西并不是敏捷的传统部分，或者至少不是大A敏捷的一部分。 所以...

大A敏捷技术的采用，我认为正在瓦解，人们正在采用更务实的方法来开发软件。那么这就是未来吗？你认为这是未来的敏捷开发在接下来的五到十年中的样子吗？好吧，我希望如此。我说我希望如此，因为你永远不知道会发生什么。我们总是有另一个范式。你知道，弗雷德·布鲁克斯的银弹综合症。

我希望，我是一个乐观主义者，所以我希望人们开始建立在我们已经知道的基础上，而不是寻找另一个奇迹，这阻止我们在所做的事情上变得更好。我看到对快速完成事情的强调稍微减少了。现在，这永远不会消失。最大的问题是我们可以测量时间。

我们有日历，我们有时钟，所以这就是我们测量的内容。更难测量的是有效性以及某事的实际价值，某个变化的价值。这又回到了我认为我们在新版本的需求书中开篇提到的内容。如果你要构建软件，它必须对其所有者具有最佳价值。

这是关于拥有组织的价值观念，我认为这正在缓慢但不可避免地成为软件开发的一部分。我们是否真的在生产一些不仅仅是当前问题的快速解决方案，而是我们是否在生产一些真正有价值的东西，真正会在业务中产生差异？为了有价值，它可能必须是创新的。

如果没有创新，如果没有对当前状况的重大改变，很难想象任何东西是有价值的。因此，这正在发生。我看到这种情况越来越多。我认为越来越多的重视不仅在软件上，而是在商业分析本身上。我只是用这个词来描述，而不是商业分析师的角色，而是实际分析业务，找出真正的问题是什么，以及我们将如何使该业务更有价值。

以及如何确保我们需要做的事情与使用适当形式在该环境中进行的所有人之间的线索是一致的。

因此，如果我们将软件工程的工程部分视为工程业务，工程正在进行的工作，无论工作是什么。它可以是商业工作，可以是科学的，可以是学术的，可以是任何事情。它是工程工作，最终结果通常是一段软件。

但我们更倾向于将软件视为重新工程或工程工作几乎是偶然的副产品。这不是重新工程，而是工程。激动人心的时刻即将到来。苏珊·罗伯逊，詹姆斯·罗伯逊，非常感谢你们的时间。谢谢你，尼尔。这非常有趣。感谢你邀请我们。

感谢您收听SE Radio，这是由IEEE软件杂志带给您的教育节目。有关播客的更多信息，包括其他剧集，请访问我们的网站se-radio.net。要支持我们，您可以通过单击网站上的Dig、Reddit、Delicious或Slash That按钮来宣传SE Radio，或在Facebook、Twitter或您自己的博客上谈论我们。如果您对某一集有具体反馈，请使用网站上的评论功能，以便其他听众也能对您的评论作出回应。

本集及所有其他SE Radio剧集均根据Creative Commons 2.5许可证授权。有关详细信息，请参阅网站。再次感谢您的支持。