Tech Lead 的需求分析

原文链接：Analyzing Requirements as a Tech Lead

在过去的几个月里，我一直作为 Tech Lead 协调一个软件项目。从公共关系的角度来看，我们称这个职位为 Tech Lead，但实际上，我承担着架构师的角色。

从头开始创建一些东西很有趣。有时它并不好玩，因为黑暗中的决定有时看起来很可怕，但作为 Scrum 团队的一部分，我们总是在那里纠正路线。我周围也有很多伟大的人，每当我忽视某件事时，他们就会抓住我。

随着我在企业界积累了大量的经验，我开始了解企业是如何运作的，有董事和副总裁的九层企业结构是什么样的，我也开始领悟到达到顶峰需要哪些技能的本质。本文将重点讨论在需求分析和软件设计环境中 Tech Lead 的角色。

Tech Lead 角色

一个项目的技术主管可以做很多事情来帮助项目向前发展。这包括

• 做出架构决策，
• 解决技术争议，
• 监督功能和非功能需求，
• 设置代码库、项目结构，
• 驱动架构和详细的软件设计，
• 帮助团队将应用程序部署到云上，
• 建立持续的集成管道，
• 还有惊喜，甚至是编码。

Tech Lead 是一个角色，而不是一个职位。你可能是一个项目的Tech Lead ，在另一个项目中可能扮演完全不同的角色。

Tech Lead 是有原因的主管。在团队成员高度自治的环境中，团队成员向技术主管寻求建议。高度自治意味着，任何负责某项任务的人都有权做出决定。Tech Lead 只是在那里提供指导，稳定团队。

有一些象牙塔的 Tech Lead 和架构师在那里从来没有编码。同样，您可以在大多数组织中遇到一些了解一些非常高级概念的经理，但他们不知道如何用信息帮助另一个团队，因为他们与自己的领域没有那么深的联系。他们委派并保持很高的水平。一些经理和董事承认这些漏洞，并指出了正确的人选。其他人玩游戏，如果他们不知道什么，他们害怕承认。与后一种类型的经理和主管类似，象牙塔架构师通常是团队的负担，因为这种类型的人将自己与现实世界隔离开来。太多了，以至于他会耽误团队而不是帮助他们。

最糟糕的象牙塔建筑师可能会做一些所谓的生产性拖延。它们通过专注于错误的事情，用别人不关心的请求分散整个团队的注意力，看起来很有成效。 另一方面，Tech Lead 能够解决任何挑战，甚至可能比大多数团队成员都要好一点。由于在其他地方增加了更多的价值，实际的 Tech Lead 代码量低于平均值。

领导是责任。在所有层面上，领导意味着服务。那些想在聚光灯下崭露头角的人，应该立即转向演艺事业。在今天的世界里，你甚至不需要守门人，因为你只需要学习一些表演技巧，就可以建立一个 YouTube 频道。然后你可能会说服那些不太懂技术的观众，他们在你的课程中投入几个月的努力后，每小时可以赚 100 美元。这样每小时能赚 100 美元吗？对。有可能吗？不，尤其是当你的听众对基础数学有困难时。

技术主管在需求工程中做了什么？

在整个软件开发生命周期中，技术主管是有帮助的。 在需求分析期间，技术主管帮助阐明需求的以下方面：

• 功能要求，
• 非功能性要求。

功能需求描述了我们正在构建的软件。

非功能性需求描述了我们构建的系统的质量。 这包括最大容许停机时间（可用性），数据保护问题，可扩展性等的规范。

功能要求可能意味着非功能性要求。功能和非功能需求都会推动架构决策。

因此，技术主管应该通过提出正确的问题来参与探索需求。

发现功能需求

功能需求描述了我们正在构建的软件。 这包括：

• 了解用户是谁，
• 了解用户想要解决的问题，
• 了解用户想要解决问题的原因。

指定软件验收标准的一个好方法是 Gherkin。在结构中看到谁，什么，为什么的作用：

S AN Advertiser
I WANT TO set up Advertising Campaigns
SO THAT I market my product

有不同的工具来捕获需求。如果不了解用户（也称为参与者），与每个角色分解的用户相关联的工作流程，以及我们系统运行的上下文，我们开发的软件将不太可能解决客户端的痛点。

在瀑布项目中，整个项目的范围是预先确定的，这意味着到这个阶段结束时，要求或多或少都是一成不变的。例如，如果您订购房屋，您必须提前澄清您想要的房屋类型。当建筑师开始为您订购的建筑物制定建筑计划时，您很少会改变主意，表示您希望在建筑物顶部添加第二层。

在敏捷项目中，需求通常会发生变化。我们倾向于接受变更。我们仍尽最大努力尽早收集所有要求，但我们希望改变发生。

敏捷不应该成为不尽力满足要求的借口。无论如何都要求需求会改变，所以为什么创造需求，被称为无知，而不是敏捷。

要进行校正，我们需要明确的方向。该方向由功能要求提供。

例如，想象一下软件系统，技术主管选择用 PHP、MySQL 和 JavaScript 编写单片应用程序，忽略了他们的客户将存储 5TB 数据的事实，并且 MySQL 很难处理这个数量的几个百分点。尽管扩展是非功能性要求，但可以通过检查功能要求来检测所涉及的数据量。

同样，实时，每小时和每日更新的数据之间存在很大差异。在那些日子里，我是日常数据库存交易应用程序的技术主管和架构师。我们每天从澳大利亚数据提供商处导入一次数据。我们的客户想要实时更新，所以我们必须彻底改变我们获取数据的方法。

一个 Tech Lead 应该监控需求，因为在他们收到正确的问题之前，客户通常不会完全知道他们想要什么。

我看到了包含逻辑矛盾的需求文档。 人类通常很难通过使用连接和分离来描述它们的含义。 许多非技术人员混淆了 and 或 or 。当他们写 or，他们通常意味着 xor。

我看到用户故事没有给客户带来任何价值，同时他们大大增加了解决方案的复杂性。一个好的 Tech Lead 应该通过识别它们，或者通过委托和监督对专家的技术要求分析来指出这些问题。

在发现功能需求时，可能需要对数据进行高级分析以了解系统正在执行的操作。 这可能包括：

• 一个上下文详细说明了系统及其数据流边界
• 确定系统内部进程如何转换数据的数据流
• 实体关系模型，它充当建架构的基础，因为数据库模式和业务逻辑都依赖于它。

我们需要注意哪些非功能性要求？

再一次，非功能性需求描述了我们构建的系统的质量。质量是通过一些需要明确定义的指标来衡量的，以推动架构决策。

如果您正在设计一个人类生命或数万亿美元的关键任务应用程序，我假设您不需要本文，因此，我将重点关注我们在项目中关注的典型非功能性需求：

• 可用性指标
• 性能指标
• 可扩展性
• 合规
• 安全
• 可维护性

让我们逐一探讨这些非功能性需求的作用。

可用性描述系统根据规范运行的百分比。想想你的网上银行软件。如果它在凌晨 1 点到凌晨 3 点之间发生了什么？不多。无论如何银行转账都不是直播，如遇紧急情况，有电话接线员可以处理您的请求。在其他情况下，只需一分钟的停机时间就会威胁到人们的生命，或造成数十亿美元的经济损失。可用性通常用 9 来衡量。

在电信行业，99.999％ 是通常的可用性指标。这究竟是什么意思？每天 0.864 秒，或一年只需 5 分钟。设计具有如此高可用性的系统需要比具有 99％ 可用性的系统更多的资源和容错能力，我们的系统每年可以停机 3.65 天。

性能指标通常与响应请求的时间量相关联。在企业应用程序中，执行团队成员的报告可能需要几分钟才能编译。将此与日间交易者进行比较，他们相互竞争，减少从办公室到证券交易所中心的延迟时间。它们还可以通过算法交易软件最大限度地缩短响应时间，该软件会在必要条件得到识别后立即执行。与此同时，有些人仍然认为即使你手工操作，日间交易也很容易。

性能指标可能使得无法使用某些技术，因为存在大量数据，MySQL 数据库永远不会响应。在其他情况下，您可以选择阻塞 I/O（PHP）和非阻塞 I/O （node.js服务器）。您可能还必须考虑客户端的计算机以采取适当的客户端决策。

可伸缩性是一种度量标准，可随着用户群的增长确定软件的未来性能需求。该指标与我的文章 “微服务简介” 松散相关。您可以创建一个单一的应用程序来验证您的想法作为MVP（最小可行产品）。然后，您可以通过从中提取微服务来扩展性能瓶颈。

合规性是一项重要指标，因为您的应用程序可能受到法律环境的限制。数据保护的法律标准，或在线游戏公司的许可是两个可能对公司构成存在风险的强制性要素。另一个例子是政府招标，其中所有形式要素必须与所需要素相匹配。

安全性是一个重要的指标，通常与合规性相关联。例如，数据被盗是由系统中的安全漏洞引起的。虽然小型创业公司除了宣布赏金计划并奖励，具有某些加密货币的道德黑客之外不会做太多事情，但公司通常有义务审核他们的系统，并维护一个负责所有软件解决方案的安全团队。该团队执行渗透测试，以确保软件解决方案不包含严重的安全漏洞。需求分析应根据相关风险处理这些安全问题，这意味着某些非功能需求由安全需求决定。例如，认证和授权系统可能受到安全要求的约束。

可维护性意味着软件的生命周期。我们是否正在建立一个 MVP 来验证一些想法？开发速度比可维护性更重要吗？可维护性就像一个金融账户。当牺牲软件的质量时，就像借钱一样。这笔钱必须在晚些时候以利息偿还。如果借了太多钱，我们可能永远无法偿还单身而且我们会破产。在软件方面，我们不借钱。我们创造技术债务。除非申请被破产，否则必须偿还这笔债务以避免破坏申请。例如，MVP 可能被完全抛弃，因为其主要目的是验证商业理念。MVP 应该快速开发，通常不考虑可维护性。另一方面，自动化组织的所有业务流程的复杂系统必须是可维护的，否则有一天我们意识到功能开发比以前花费更多的时间。

可扩展性是可维护性的一个方面。它通常由功能需求所暗示。例如，您的任务可能是为一个特殊的客户机构建一个 MVP，但是您应该以最小的定制为行业中的任何客户机准备系统。

始终考虑开箱即用，因为没有清单可以提取涵盖所有情况的所有非功能性要求。

非功能性要求也可能来自您组织批准的黄金路径。较大的组织倾向于标准化工具，编程语言、框架、库、云提供商以及与软件开发相关的几乎所有内容。在您的架构中进行过多创新之前，请考虑这一点。

许多其他考虑可能会导致非功能性需求，包括开发团队的能力和内部政治。

软技能作为非功能性要求

您必须了解项目的利益相关者。

例如，由于自动化，系统的用户不再利用漏洞来获得经济收益。这意味着他们不会与您合作，因为他们的兴趣是继续利用系统，而不是帮助您改进流程。

例如，如果疾病诊断系统自动为症状开出最好的药物，那么医生将无法被营利者贿赂一种有利但非次优的药物，这样他们就能得到更多的处方药。

摘要

Tech Lead 在整个软件开发生命周期中协调架构和工程决策，并领导他或她的团队。

在本文中，我们通过分析需求发现了 Tech Lead 的作用。 要求可以是功能性的或非功能性的。 所有要求都为建筑选择奠定了基础。