管理协作
TechExcel 的 Jeff Johnstone 解释了为什么需要一种新的应用生命周期管理 (ALM) 方法，以更好地反映业务需求和开发团队面临的挑战。
MIKE Vizard： 大家好，欢迎收听另一期 cast 高级版，主持人是 Mike Vizard。本期 Queuecast 高级版由 TechExcel 赞助播出，TechExcel 是领先的工具提供商，致力于弥合产品开发与服务和支持之间的差距。今天，我们将与销售高级总监 Jeff Johnstone 先生对话。Jeff，欢迎来到节目。
JEFF Johnstone 欢迎 —— 很高兴来到这里。
Vizard： 关于 ALM，我印象深刻的一点是，这个概念已经存在一段时间了，但在过去，当开发人员有点像他们公司的高级女祭司，他们进入公司并做自己的事情时。ALM 的含义是一种，但今天，感觉开发人员更像是与业务其他部门紧密相连的服务，并且总是有隐藏的利益相关者。那么，随着业务和技术变得紧密相连，ALM 的方法需要如何改变？
Johnstone 这是一个很好的问题。我认为，从根本上来说，开发被认为，已经变得更像是一个业务流程，而不仅仅是一组工具。在过去，就像您所说，开发人员和开发组织有点独立自主。他们相当自主，他们会做适合流程每个部分的事情，并且他们会采用在技术和工具层面合适的的技术，但他们并没有真正将自己视为任何更高业务流程的组成部分。我认为这种情况正在发生变化，而且我认为，随着开发本身变得更具战略性、更具动态性、与业务目标和业务流程更加紧密地联系在一起，历史上用于管理开发的工具实际上不足以应用一些更业务流程方法和公司其他领域的集成要求。
我认为，需要一种新型的产品来解决这个问题，而这正是 TechExcel 的关注重点。
Vizard： 那么，如果我想将类似的东西引入我的公司，我该如何构建它呢？
Johnstone 实际上，最重要的一点是每个组织都要了解他们的目标是什么，他们的流程应该是什么，以及他们的优先事项是什么，但是如果我们采用业务流程方法进行开发，那么业务流程管理的基本第一步是理解您试图实施工具的基础流程本身。因此，组织需要了解他们的客户支持部门如何需要与开发部门沟通，无论是为客户分发错误还是功能请求。营销和销售部门如何需要向开发部门提供未来版本、即将发布的版本、优先处理问题的反馈。开发组织本身如何需要定义即将发布的版本、功能、优先级以及可能的增强功能和功能列表，对于大多数系统或产品来说，通常是无穷无尽的，关键是您要掌握您通常承诺的内容。
因此，组织首先需要从客户支持、销售、营销、开发本身等方面了解自己在组织中的角色，然后您只需将这些业务流程要求应用于像 TechExcel 这样的工具套件，这使您能够管理从需求、规范、计划、实施、质量保证测试、错误跟踪等所有事情，但不是从工具的角度来看，而是更多地从业务流程集成的角度以及我们为这些组织提供的配置流程的能力非常直观。因此，您不必创建自己的代码来实施流程。您只需将流程绘制到我们的工具中，或者您正在配置工作流程选项，或者您正在选择您想要在客户支持和开发之间实现的自动化类型，但基本结构、架构和框架是为您内置的。
因此，映射您的需求的过程非常容易。在某些情况下，实际上可能在大多数情况下，最困难的部分是理解您的需求，达到您确切知道您要实现的目标的程度。
Vizard： 这是否意味着我必须更改我作为开发人员的流程以适应框架，或者框架是否足够可扩展以适应任何数量的流程本身？
Johnstone 是的。DevSuite 框架专门设计用于允许每个开发组织采用他们自己的方法和框架。您可以是一个完全敏捷的开发商店。您可以拥有自己的自定义流程。它可能是部分瀑布模型，部分敏捷，迭代开发 —— 这些方法的任何组合或您提出的完全新的方法 —— 这与 DevSuite 无关。DevSuite 旨在促进几乎任何流程，无论是受控的线性流程还是动态的迭代敏捷流程，工具都不应该也不能驱动您如何运营业务。
您的业务必须驱动您如何使用工具。这就是 DevSuite 从一开始就设计的方式。
Vizard： 现在大多数组织真的必须想要改变才能实现改变。这有点像心理学中的那个老笑话。你如何让一群开发人员，或者引诱或激励一群开发人员想要改变他们做事的方式，以采用一种感觉几乎像是对左脑活动的右脑结构化方法？
Johnstone 是的，这是一个很好的问题。现实情况是您不必这样做。关心流程的人以及关心这种集成、沟通和协作的人是管理职位的人和经理、主管、副总裁等等。这些人确实需要担心这个。他们被雇佣来担心这个，以及他们如何提高效率，他们如何与其他团队协作等等？但这并不意味着开发人员本身需要担心它，甚至不必在开发层面意识到它。
实际上，开发人员可能完全在 IDE（集成开发环境）中工作，无论是 Perforce、Accurev 还是 Team Foundation Server —— 无论他们的开发环境是什么 —— 开发人员可能永远不会离开那里。我们拥有工具和集成模块，允许在这些工具中所做的更改自动反映 DevTrack 中的问题，并将适当的源代码、控制文件与 DevTrack 问题关联起来。
因此，现实情况是，如果您做得对，那么流程对开发人员来说是透明的。他们编写他们需要编写的代码。但是，开发人员清楚地沟通并了解目标仍然很重要。您不能在不知道您要完成什么的情况下就开始编码。
这就是协作优势真正发挥作用的地方，通过拥有这套以流程驱动的工具来优先处理需求和指定版本，并通过审批流程来确保功能集和增强功能、错误修复列表在管理层面获得批准并获得所有人的同意。分配到这些任务的人员可以在必要时访问该信息。因此，他们可以说，好的，我被要求实施这个新的打印引擎。我想知道他们在说什么。触手可及的是所有这些历史记录的列表，上面写着，哦，我看到销售部门希望我这样做，而营销部门想要其他东西，并且三个客户提出了请求，工程副总裁还有其他想法，当他们开始处理这个问题时，他们可以触手可及地看到这些，但他们的日常工作从根本上没有改变。
他们仍然在他们的 IDE 中编写代码，但是集成层促进了部门经理真正关心的沟通、协作和流程管理。
Vizard： 您刚刚触及了我们一直存在的热点问题之一，但对我来说，最终客户或业务人员提出了关于他们希望软件如何工作的理想场景。然后他们将此交给业务分析师，业务分析师尽力起草一份开发人员可以阅读的文档，开发人员根据他们最好的理解来编写代码，然后将其发回给业务分析师，然后再发回给最终客户，并且 80% 的情况下，最终客户不满意，这就是为什么我们的应用程序有如此高的失败率。
这个流程可以改进整个质量保证流程吗，我想暂时称之为质量保证流程，人们将对流程中发生的事情有更好的了解，并且它将更具迭代性，因此当最终应用程序最终返回给最终用户时，我们将减少组织排斥反应吗？
Johnstone 是的，绝对可以。这让我想起了一个精彩的旧漫画，其中有这个完整的产品开发周期，将这个秋千做得越来越复杂，直到最后一帧，客户真正想要的是一把摇椅或一个轮胎秋千或一些与设计和交付完全不同的东西。
DevSpec 的整个概念，这是我们最新的产品，是确保来自客户的需求正在经历审查和批准以及沟通的过程，并一直流向开发、质量保证，以确保您发布的是计划好的，计划好的是期望的。DevSpec 实际上对需求管理采取了一种全新的方法。在过去，典型的需求管理工具是关于版本控制，关于检入、检出文档，并且可能具有这些文档的状态，并且它们将有一个您要实施的需求列表。
我们采取的方法是，需求管理是一个动态的、活生生的过程，涉及更广泛的人员。因此，DevSpec 允许您将需求作为来自客户、营销、技术支持、工程部门的建议提交，任何来源都可以提交此需求，并且需求会经历一个生命周期。一个可定义的流程，包括审查、批准、所有者和状态更改，这对于您的公司来说是合适的。它不必非常复杂。它可以非常简单，但需求会经历一个流程，最终这些需求会被编译成一组规范，而规范随后会成为我们所说的概念产品，这是一个非常重要的概念，因为概念产品是动态的，并且随着时间的推移而变化。因此，如果您处于敏捷开发环境中，您可能会每两周更改一次您的规范，因为您正在经历软件的不同迭代，您正在调整事物。
但是，随着这些事情的变化，所有相关人员都会保持联系。您可以配置系统以通知从这些需求的提交者到支持团队、质量保证经理的每个人。每个需求或每个规范都将具有链接、实施、开发工作项、链接的质量保证测试用例、链接的文档工作，并且每当这些规范发生变化时，在非常动态的环境中，这可能是每天或每周，拥有所有其他相关周期方面的人员都将自动收到这些更改的通知，并且记录会被标记，以便需要审查测试上周定义的功能的测试用例，因为该功能现在已被修订。
而正在处理五个不同代码片段以实施一项功能的开发人员，这些开发领域中的每个工作项都会被标记，因为其下的规范已更改。
我们还有更多的协作、业务流程工具，例如投票，您可能会收到来自曾经参与贵公司的每个人的 500 个功能需求列表，而您只有资源实施其中的 100 个。因此，我们有投票，您可以在其中分配可能 500 点给开发副总裁，100 点给产品经理，100 点给销售人员，他们都可以将他们的点数分配给不同的需求，您可以立即看到，啊哈，基于每个参与者分配他们的一组点数。我可以根据这些投票点的汇总看到我们必须实施的前 50 个功能，然后您可以开始管理其余的功能。
我们还具有动态的假设情景。因此，您可以查看这些需求规范的多种组合，并查看资源影响、不同选项的投票总数、不同选项的时间线影响。因此，开发您的概念产品的整个过程，即所有这些规范的当前动态状态，旨在引入许多不同的人员，并让他们在事情发生变化时保持知情。
在以前的系统中，您检入需求，没有人知道。质量保证人员已经在根据针对先前版本的功能设计的测试用例来测试最新的版本，而这甚至不是您现在想要完成的事情。因此，DevSuite 与 DevSpec 的这种新的需求管理方法的重点是扩大团队的范围，使其在流程中涉及的人员超出开发人员本身，确保每个人都在沟通，每个人都对该系统具有适当的可见性和访问权限以及输入，但每个单独的工作人员，无论是开发人员还是质量保证测试人员，还是文档编写人员还是经理或架构师，所有这些人仍然对他们正在处理的工作有一个非常有限的看法，他们的生活并没有改变那么多。
他们只是在编写代码，编写测试用例，编写文档，但是发送给他们的是什么，输入到他们分配的任务队列中的是什么是明确定义的，并且在其中嵌入了一个动态链接，他们将始终能够看到该功能的概念定义的当前版本，因为它在不断修订。
Vizard： 这是否有助于创建人们可以遵循的关于某事物是如何开发的审计跟踪，这可能有助于合规性，但更重要的是，它有助于公司捕获投入到应用程序中的知识资本。
Johnstone 绝对是。这有两个方面。一方面是某事发生了变化。有人更改了优先级。有人移动了计划表并将其从列表中删除，现在我们的 5.0 版本已经发布了，有人告诉我将要在这里但现在消失的功能发生了什么？因此，肯定有一个关于谁做了什么、何时做的审计跟踪。谁做了更改，谁做了决定。
如果这是定义的业务流程的一部分，我们甚至可以阻止在没有某些级别的批准的情况下进行这些更改。
另一方面是，对于有意识地同意继续进行的事情，您下次不会丢失它们。它们仍在队列中等待。因此，当您到达 5.1 版本时，您会拥有一个队列，其中包含所有有意从 5.0 版本中推迟的事情，以及所有仍在这个需求存储桶中的东西，我们需要再次投票并确保我们不会忘记。
这些需求的生命周期不会随着版本的发布而结束。它们从一个版本到另一个版本都在存活，直到您将它们移动到完全取消或项目状态。它们将与整个历史记录一起保留在该队列中，以确保您不会因为碰巧没有将其放入给定版本而丢失想法和信息。
Vizard： 设置类似这样的东西有多复杂？我需要 10 个穿实验服的人吗？感觉它触及了业务的多个部分，并且有不同的层次。
Johnstone 是的。它出奇地容易。困难的部分在开始时，并且是理解您试图实现的业务流程以及如何启发团队协同工作。但是，即使您没有完全定义它，我们的管理应用程序的架构也是如此，它为您提供了一个框架。它本质上引导您完成您考虑的各个方面，您想要跟踪的需求、规范、错误与测试用例的数据字段结构。您想要报告的种类。
什么样的流程 —— 这些领域中的每一个都有自己的流程。您希望它是完全灵活和自由形式的吗，它只是打开和关闭？您想拥有一些强制执行的工作流程吗？这些都只是您选择的选项，但管理员允许您浏览我们嵌入的框架，并将其用作思考您的业务的指南。
最终，您仍然需要从业务角度提出您的需求，但我们自己的管理员框架通常是允许公司这样做的好工具。
一旦他们在脑海中清楚地了解了这一点，实际配置就非常容易了，因为它都是通过点击式管理应用程序完成的。没有编程。没有脚本。没有数据库工作。您只需通过选择一些选项并输入一些标签并在工作流程状态之间绘制一些连接线，即可在框架内提供的选项中启用您的流程。
Vizard： 由于每个人都对购置成本有点敏感，那么设置这个东西需要多少钱，许可结构如何？
Johnstone 许可是基于用户的，DevSuite 有五个不同的产品。有 DevSpec，这是需求管理部分。Knowledgewise 是底层知识库结构。DevTrack —— 对不起，DevPlan，这是项目计划部分，它将从 DevSpec 中流出。DevTrack，这是开发管理实施、错误跟踪。然后是 DevTest，这是质量保证测试。根据您选择的模块，您可以实施合适的模块，价格范围从每人大约 500 美元到 1,000 美元不等，具体取决于您选择的模块。
对于一些团队，小型公司，我们实际上有一个小型公司，员工人数少于 100 人，我们有一个折扣价，我们必须与任何想要与我们一起追求小型公司的人讨论。
Vizard： 您能否举例说明有人正在使用这种方法，以及他们可能如何在信封背面的计算中衡量他们的投资回报率，或者什么是 —— 他们如何向企业证明其合理性？
Johnstone 是的。我们有很多客户拥有超过一千名用户，显然，团队规模越大，对底线的影响就越大。如果您有两个人在客厅里编写代码，您将不会产生 1,000 人团队的影响。
但是，我们从我们最大的客户那里看到的真正是效率、沟通和协作、跟踪和分析的改进感，这真正将从定义您的版本、实施质量保证测试和发布整个流程联系在一起。就真正的投资回报率而言，我们听到的数字是从 10% 到 40% 的底线改进，但当涉及到这类事情时，投资回报率是一个真正的非科学计算。这实际上是关于您如何确保您将按计划发布您打算发布的内容，以及您如何确保您打算发布的内容是市场根据您的销售输入、客户输入所需要的。因此，这是无形的。
在正确的时间将正确的产品推向市场，就纯粹的效率而言，就人们不重复努力以及事情在正确的时间通过正确的流程而言，几乎具有无限的价值，您将在那里获得 10% 到 30% 的底线效率改进。
Vizard： 那么，我想最后一个问题，鉴于您在客户方面的所有经验，您对试图找出更结构化的创新方法的组织的最佳建议是什么？
Johnstone 我首先会查看您组织的目标，并说，您是否以产品为中心？版本的发布、可靠的发布，无论是时间、质量还是内容，对您的业务至关重要吗？这将决定像这样的系统有多重要。如果您正在开发低优先级且非时间关键的系统，那么这些事情变得越来越不重要。因此，对于版本、内容、时间和质量至关重要的组织，对于任何设计产品的产品公司来说，情况肯定是这样，您真的必须关注组织。
客户支持是否正在与开发部门高效合作以解决错误？营销和销售组织是否正在有效地与项目管理、产品管理部门沟通，以定义未来的版本？我们是否始终如一地开发和交付满足我们定义的定义和范围的版本？如果所有这些的答案都是肯定的，一切都很高效，每个人都在协同工作，一切都按时进行，那么太好了，继续做您正在做的任何事情。
如果您提出这些问题，您会说，你知道吗，我们真的可以改进并且需要改进沟通和协作以及我们可以保证和承诺的质量和计划，那时您需要说，好的，实现这一目标的唯一方法是通过某种集成的产品套件，该套件允许我拥有从销售、营销支持到产品管理的需求、计划实施和测试的端到端解决方案，如果您拥有像这样的产品套件，使您可以轻松地实施您自己的业务需求并将您的需求和管理风格应用于此套件，您将更加高效，并最终更快地将更好的产品推向市场。
Vizard： 这里是主持人的特权，但我再问一个问题。鉴于 ALM 已经存在这么长时间了，如果您必须概括一下，TechExcel 与他们领域中的其他所有人有何不同？
Johnstone 我想有几件事。首先，我们大约在 10 年前首次开发了 DevTrack，因此，在 1996 年、1997 年，我们发布了 DevTrack 的第一个版本，而 DevTrack 从一开始就是一个以工作流程为中心、以流程为中心的工具，最初它是一个错误跟踪工具。但紧随其后，我们发布了 ServiceWise，这是我们的客户支持应用程序。因此，几乎从一开始，我们就从业务流程的角度以及架构的角度来看待将错误跟踪与客户支持集成在一起。因此，我们在过去 10 年中所做的一切，都是从以下角度出发的：如何通过可定义的业务流程，将多个团队与一个共同的核心数据集集成在一起？并且随着我们将我们的服务产品套件从客户支持和销售管理扩展到 IT 服务管理，并将 DevTrack 扩展到完整的 DevSuite，我们始终以来的观点是如何使多个团队能够在易于定义的流程中协同工作？
我认为，该领域中的大多数其他供应商都是从工具的角度出发的，他们拥有一组工具，一组点解决方案，其中许多是非常非常好的工具，但他们不是从业务流程的角度出发的，当然几乎没有人从集成客户支持开发的角度出发，而这正是我们 10 年前所处的地位。我认为，最初的观点确实给了我们一种独特的方法，即使在 DevSuite 中，我们如何管理多个团队，以及我们如何有效地允许我们的客户定义他们独特的需求。
Vizard： 好的，这是另一期 cast 高级版。本期节目由 TechExcel 赞助。您可以在 www.TechExcel.com 上找到更多关于它的信息。他们是领先的工具提供商，致力于弥合产品开发与服务和支持之间的差距。作为您的主持人 Mike Vizard，我想感谢 Jeff 分享他的知识，我们祝他一切顺利。
Johnstone 好的，谢谢！
最初发表于 Queue 第 5 卷，第 4 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
虽然密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。密码哈希存在许多由各种安全要求驱动的标准，但在非密码方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来为商业和社会服务，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚的反复无常的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的行之有效的解决方案。用例于 1986 年首次引入，并在后来普及，是这些行之有效的解决方案之一。
© 保留所有权利。