现代信号分析和处理 pdf_现代开发人员第1部分：规划和分析

现代信号分析和处理 pdf

在产品开发方面，代码是第一件事吗？ 何时定义功能并评估风险？ 关于部署，应该在软件完成之前还是之后进行计划？

这些以及其他类似的问题揭示了产品开发中所涉及流程的复杂性。 您对每个阶段所涉及的内容的理解越好，您就越能交付预期的结果。

在本系列中，我们将涵盖整个软件开发过程，从计划开始，以维护结束。 重点将是流程是什么，涉及的人（某些步骤不需要开发人员）以及作为初级或中级开发人员应期望/做的事情。

该系列的第一部分将探索前两个步骤：计划和分析。 我们的目标是定义每个步骤的目的，确定参与方并确定您作为初级或中级开发人员的角色。 自然，这个过程因公司而异，因此我们将为不同规模的团队解决一些常见的情况。

规划

为了明确起见，“计划”在这里指的是软件产品：将要构建的内容和构建过程，而不是特定功能的实现。

构建软件很复杂。 开发人员需要编写添加功能，没有很多错误，易于阅读和调试，易于维护且易于更改，遵循约定等的代码。

此外，系统必须具有99.99％的正常运行时间，同时要进行安全，保护和良好的优化，必须有可靠的数据备份，并且用户体验应该令人愉悦。 如果要使软件产品成功，则必须从业务角度规划和研究系统的功能。

不幸的是，规划功能和过程是开发产品时最容易被忽视的方面之一，即使它决定了整个项目的目标和验收标准。 无法准确地决定要建造什么，以及无法选择正确的工作流程，最终会花费大量时间和金钱。

关键是要建造什么 ； 关注最终目标，而不是目标。 从纸面上看，一切都很便宜且易于构建，但实际上并非如此。 重要的是要牢记将要处理该项目的团队的吞吐量。

时刻注意团队

您不能现实地构建一个只有两个人就能与当前引擎竞争的游戏引擎。 但是，如果一个项目不够雄心勃勃，则可能不值得建设。 如果以启动场景为例，安全项目并不是赚大钱的项目—实际上，它们很少能幸免于最初的三到九个月。

选择正确数量的关键业务功能（使产品成功）和使产品失败（这是因为开发团队无法交付质量合格的产品）之间的界限很窄。

如您所见，规划非常棘手。 由于过程的这一部分主要是关于产品开发人员的，因此要求软件开发人员提供他们的输入通常非常有限。 不幸的是，随着时间的推移，对于新项目和功能，许多经验丰富的开发人员（就公司而言）将变得不那么雄心勃勃，更加保守。

为什么发生这种情况是一个很长的讨论。 要点是，有些人不想使当前的工作复杂化，有些人会随着时间的流逝而变得懒惰，最后有些人看到了雄心勃勃的项目在过去如何导致许多无偿加班和压力 ，并且不热衷于经历这个过程再次出现。

其他功能和因素

根据公司的规模和结构，将由不同的人来进行计划，但是除了功能之外，还必须确定几个因素：

• 发展的艰难时期。 应该释放多少时间？
• “完成”的定义。 预计将作为最终产品交付。
• 建立它的团队。 在大公司中，仅此过程就可以组建全新的团队。
• 风险评估。 应该考虑某些风险，通常是最关键的风险。

您在计划过程中的角色

对于大公司，通常不会将开发人员带入计划或设计中，因为计划是非技术性的。 对于小型公司而言，很可能会公开或公开讨论许多信息。

作为初级开发人员，大多数时候您不会知道计划的内容。 如果公司是透明的，并且可以向您提供有关可能项目的信息，那么您最好的办法就是专注于当前的任务，为公司带来尽可能多的价值。

即使四处询问和提出建议可能很诱人，但这超出了您的范围，而硬道理是，作为一个大三学生，您的想法几乎肯定会浪费其他人的时间。

我去过那里好几次了，回首过去，我能理解为什么人们对我很矮。 让企业弄清楚什么能赚钱。 这是他们的责任，最适合他们，如果失败，应该责怪他们。

专注于您当前的任务。 不要通过假想的方式改变您的时间和精力来破坏当前的项目。 大多数项目（想法）在开发之前就被废弃了。 通常，存在太多风险或所需资源导致可疑的投资回报。

如果您是经验更丰富的开发人员，则应首先确保您的任务不落伍。 如果项目的计划变得越来越认真，则可能需要对某些技术进行一些研究，这些技术可以在您构建项目时为您提供帮助。 例如，市场上已经存在哪些技术，它们将使用什么？

即使通常由架构师来设计系统，经验丰富的开发人员的意见也总是会在优秀的公司中珍惜。

公司的规模通常会决定流程的形式，通常会决定透明度。 通常，公司越大，人们对各种知识的掌握就会越严格，因此在很多情况下，当您在大公司工作时，您将不会真正知道幕后情况和正在发生的事情。计划。

这不一定是一件坏事。 这更多是一项政策，而不是有意地使人们陷入困境。 并不是知道公司的未来项目会帮助您更快地完成当前的工作，而且如果即将到来的项目很无聊，甚至会激励人们。

务实，先做好您的工作，然后再在其他地方做贡献。

完成计划流程

通常要确定的最后一件事是支持软件：错误跟踪器，Wiki，以及诸如冲刺持续时间之类的某些流程。

对于支持软件来说，帮助团队而不是浪费他们的时间很重要。 人们通常会选择复杂的支持软件，这些软件具有较高的学习曲线，需要大量时间让开发人员习惯，并且最终会损害产品而不是提供帮助。

现在，对于应该构建什么以及如何将其货币化有了一个完整的想法，我们需要在技术上和非技术上全面评估该产品。

分析

到目前为止，我们正在构建的产品总结可能听起来像：

“我们将为X的本地聚会建立平台。 我们将通过与当地企业（主要是餐馆和咖啡馆）的合作伙伴计划提供住宿，因此聚会可以得到特别优惠，并且本地企业可以吸引新客户。 使用Scrum并每两周进行一次冲刺，将有大约10 *人参与该项目。”

（* 10是一个粗略的估计。在分析阶段之后，或多或少的人可能必须工作。）

需要尽可能全面地定义功能，以便可以进行相应的设计。 我们是人类，我们会犯错误。 某些功能会随着时间的推移进行更改和更改是正常的，但是每次更改都会增加构建产品所需的时间和成本。

使用用户故事定义功能

用户故事是开始定义功能的最常见方法之一。 用户故事是描述一个或多个用户操作的图表，图形，有时甚至是文本。 这些动作通常是首先构建的功能。 即使您每秒可以处理10,000个请求，但是如果您的用户无法使用该软件也无关紧要。

让我们回到本地会议系统的示例。 这些聚会需要以某种方式进行组织。

让我们写一些用户故事，看看我们可以衍生出哪些功能！

用户登录系统。 他创建了一个聚会，并向他的一些朋友发送邀请。

如您所见，该用户故事解释了用户的操作，但是如果我们必须在此基础上设计或实现系统，它并不是特别有用。

想一想。 用户将如何登录？ 他们在系统中有注册吗？ 如果是这样，是用户名还是电子邮件？ 那么Facebook或Google登录名呢。 支持那些吗？ 我们所知道的是系统有用户。 我们已经有了所有这些问题，并且只在用户故事的第一句话中。

这里应该做的是仔细考虑系统应支持的注册类型。 这是一个复杂的过程，因为要考虑很多因素。 目标用户群是否使用这些平台中的任何一个？ 使用它合法吗？ 如果我们用于身份验证的平台决定不使用它，将会发生什么？

假设我们已经完成了研究，并且仅会使用Facebook登录名。 然后，我们可以将用户故事重写为：

用户通过Facebook登录系统...

如果我们支持多种登录方式：

用户通过Facebook / Google /我们自己的登录名登录系统...

您可以在此处添加任意数量的详细信息，只要用户故事描述了用户的行为而非系统行为。 一个不好的用户故事的例子是：

用户通过Facebook登录到系统。请求被发送到我们的系统后端，从而开始新的会话。

关于应如何详细的用户故事，有两种主要观点：

• 尽可能少
• 尽可能详细

使用适合您的方式。 就个人而言，我更喜欢详细信息，但我理解这样的论点，即必须阅读一些充满细节的句子有时会令人生畏并且令人生厌，尤其是如果您想全面了解用户可以做什么而不是如何做做吧。

完成分析过程

分析过程通常在以下情况下结束：为大多数用户操作创建了用户故事，并且在研究和分析之后做出了大多数高风险决策。

尽管大多数公司的流程通常是相同的，但是从事工作的人员可以是一个团队，几个团队或一个人。 用户故事可以是pdf格式，也可以是用软件绘制的，白板上的图片，甚至是便利贴。

工件不是那么重要。 重要的是要确定功能，以便可以正确完成系统的体系结构。

从我在大型和小型公司中所看到的来看，区别通常在于工件的形式上。 公司规模越大，需要更多的人来查看和批准这些人工制品，因此，如果一切看起来都很好，那就更好了。 在一家只有几个人的创业公司中，几张照片和几张纸就足够了。

当您将用户故事视为开发人员时，无论您的经验如何，最好问自己尽可能多的问题，以确保没有任何可能导致项目延迟的主要未知因素。

您必须这样做，这不仅是因为您是一名优秀的员工，还因为如果您留下了一些重大失误，那么加班就不会完全是管理层的错。 这是最常见，最关键的错误，可能导致焦虑 。 为大家着想，尽最大努力避免这种情况。 不要误会我的意思，事实证明，估算并不是一门精确的科学，但是由于可以避免的错误而与​​家人和亲人失去时间是最令人毛骨悚然的事情之一。

跳过这些步骤的成本

没有适当的计划和彻底的需求分析，该项目必然会失败。 如果这些步骤的工件是格式良好的pdf或几张纸，则没有什么价值。

重要的是要花费足够的时间并让足够多的人来获得精确的流程，用户故事和需求，以便可以在给定的时间内以可接受的质量设计，开发和部署该软件。

请记住，计划和分析是通常由公司业务部门（分析师，业务开发人员等）进行的流程。 他们的工作是找到问题和解决方案，找到市场并评估风险。 尽管参与该过程可能很诱人，但是最好的方法是将精力集中在当前的任务上，并在计划，分析和风险评估结束时提出任何疑虑和建议。

构建软件时将使用的支持软件和流程必须帮助相关人员。 如果某个过程或工具对其用户造成压力，则应进行更改。

翻译自: https://www.javacodegeeks.com/2019/09/the-modern-developer-part-1-planning-and-analysis.html

现代信号分析和处理 pdf