前端开发和运营那个好_开发和运营中的好与坏模式

前端开发和运营那个好

作为我在新公司中的职位的一部分，我被要求提供有关构建Dev＆Ops的反馈，以及什么样的事情有效和无效。 我当然没有声称能得到所有答案，但是我看到了一些功能非常强大且功能异常的组织。 我花了很多时间思考什么有效以及为什么。

以下是我发送给CEO的邮件的清理版本，该邮件要求我对有效和无效的想法。 这旨在作为进一步讨论的基础，因此我没有深入探讨。 如果您想了解任何特定区域的更多详细信息，只需在此处添加一些评论即可。

我意识到并不是所有这些问题对很多人来说都是黑白的–有灰色区域。 我的目标是推动对话。 我认为这可能是许多人的评论，但也许会对某人有所帮助。 首先，所有这些项目符号都朝着一些非常简单的目标迈进，而且它们在某种程度上是SaaS公司所独有的：

• 随着代码的逐步推出，客户应不断从开发人员那里获得价值
• 开发人员应通过启用供客户测试的功能来获得客户对变更的早期反馈。
• 我们可以快速地-通常在几个小时内为客户解决问题
• 我们可以非常深入地检查和了解客户的行为，收集有关客户如何使用服务的详细信息。
• 我们可以交换组件并在客户不知情的情况下大幅更改底层软件（如果我们做对的话）
• 我们可以根据行为和反馈来衡量客户对变化的满意程度

以下列表是我认为使之成为可能的（良好）和抑制它的原因（不良）：

文化与传播

好：

• 站起来。
• 回顾展
• 小而自组的团队（让人们在他们的激情领域工作）
• 尽可能使用信息辐射器（看板，大型显示器上的统计信息等）
• 团队做出决定，领导者促进共识
• 发现不起作用的地方是找到正确解决方案的一部分，而不是要担心的事情。
• Hackathons允许开发人员做他们热衷的事情
• 聘请个性和团队契合度第一，技术能力第二
• 以数据为依据的决策，力求有事实来支持决策。
• 使正确的行为成为最容易的事情–建立低阻力的路径来做正确的事情。

坏：

• 自上而下的决策
• 严格的角色分配和筒仓
• 担心第一次没做好
• 招聘技术思维能力强的团队将在以后
• 出于恐惧而创建流程，这使得做正确的事情变得困难。

消除手工流程

好：

• 持续部署/交付
• 全自动测试
• 测试驱动开发
• 全自动系统监控，配置和配置
• 单独的部署和发布（功能切换）
• 从主服务器部署，不分支（强制特定行为）

坏：

• 质量检查团队进行手动测试-有时是必要的，但应避免
• 部署分支机构，减慢速度并允许其他不良行为
• 编写代码后编写测试，但编写代码时并未考虑到测试
• 开发人员依靠其他团队来执行可以自动化的任务。
• 流程是恐惧的结果，而不是必要的业务流程。

如果移动，则对其进行测量

好：

• 收集有关所有可能内容的高分辨率指标
• 开发人员可以通过推送新代码来添加新指标，而不依赖其他团队的其他配置。
• 任何人都可以看到图形和指标-开发人员应该依靠这些图形和指标。
• 应该有对数据可视化和分析充满热情的个人或团队。
• 开发团队依靠这些指标制定决策，帮助确定哪些指标很重要
• 开发人员在推送新代码后观察指标，观察趋势变化（开发人员负责可用性）

坏：

• 开发人员添加了对新指标的支持后，操作部门必须配置新指标（手动）
• 运营部门监控指标并在发现问题时询问开发团队
• 除非引起注意，否则开发人员不会查看指标
• 代码只有在其他人要求时才公开指标

这是所有内容的加长版…

＃1文化与传播

我认为最重要的是这些。 我认为，只要您在这些领域中做得好，就可以解决该领域其他大多数问题。 到目前为止，Rally一直是我在该领域看到的非常成功的模型的最好例子。 它们不是唯一的-还有其他公司具有相似的模式和相似的成功。

要点

• 站起来 。 迄今为止，最有效的工具可以使每个人保持联系。 随着团队的成长，您必须将它们分解开，因此您将获得第二次站立，团队可以将跨团队的项目共享。
• 项目由相对较小的，通常是自组队组成 。 让对某个领域的工作感兴趣的个人团结起来，他们互相分享彼此的激情。
• 进行回顾 。 这使个人和小组能够以促进解决的方式表达疑虑。 有一种促进这一点的艺术，但是如果做得正确，它会很好地工作。 它还可以识别做得好的事情。
• 使用开放式信息辐射器 –通过查看某处的状态与必须要求状态，参加会议等比较容易看出正在发生的事情。看板可以很好地做到这一点。
• 领导者的存在是为了促进和帮助达成共识，但决策很大程度上是由团队而非领导者做出的。 这使成为领导者变得更加困难，但也使团队更有能力。
• 接受可能无法解决的问题，并且在无法解决问题时团队和公司将进行调整。 这使得尝试新事物变得容易，并且人们在认为不起作用时也很容易发声。 如果很难更改流程，那么人们会更乐于尝试新事物。 这可以追溯到对事情进行检查的回顾。 在这方面也很重要的是明确设计用来探索可能性的“突击”或有时间限制的工作。
• 给开发人员一些时间来为公司从事自己的项目 。 Hackathons带来了许多很棒的功能，开发人员在此花费自己的时间来构建自己热衷的东西。
• 雇用适合个性的人 。 我已经看到很多很棒的人在公司中找到了特殊的利基，因为他们已经成长为您无法雇用的角色，但使之成为可能的是，他们与团队作为一个人合作得很好。 雇用技术技能也意味着您在该人离开时会失去该技能，我更希望拥有跨职能的团队。
• 数据驱动的决策 。 这有助于将情绪和“我认为xyz”排除在讨论之外，并专注于我们拥有和没有的数据。 如果我们没有数据，我们要么获得更多信息，要么承认我们可能没有做出正确的决定，但我们将继续前进。
• 使正确的事情最容易 。 我已经看到太多的公司在那里进行流程，这使“正确的事情”变得非常困难，因此被绕开了。 正确的事情应该是完成任务的快速火车–阻力很小，很容易做到。 当您开始想以不同的方式做事时，它会变得更加困难，更加痛苦。

同样， 每个人都拥有服务的质量。 这包括可用性，性能，用户体验，交付成本等。在我的上一家公司中，运营，工程和产品（以及跨工程团队）之间在服务的各个方面都进行了出色的协作，并且有着强烈的共享文化所有权和很少的指责。

如果您想了解有关Rally的更多详细信息，我写了一篇博客文章，提供了更多信息： Blog Post

＃2强迫性地消除手工过程–让计算机去做自己擅长的事情。

这样做非常容易。 在为客户增加价值（编写代码）与代码投入生产之间，开发人员应该尽可能少地进行手工处理。 可能会有业务流程来控制何时为客户启用该功能-但是，手动流程不应阻止部署和测试该代码的行为。 我指的是将“部署”与“发布”分开-这是两件事。

测试仅应是手动的，以使假设无效，而验证假设应是自动的。当我们假设如果x为真，则y将会发生，则应该进行测试以验证其为真。 测试人员不应手动验证这类事情，除非没有办法使它们自动化（稀有）。 测试人员对于使假设无效无效 。 测试人员应该研究开发人员所做的假设，并帮助确定那些可能并不总是正确的假设。

太多的组织依赖手动测试，因为它比较“容易”，但是它有一些严重的缺点：

• 您只能像团队可以手动测试一样快地更改系统-这非常慢。
• 您的测试是由犯错误且行为无法预期的人员完成的，因此您将获得不准确的结果。
• 测试的数量只会随着时间的推移而增长，需要更多的人或更多的时间，或两者都需要。 它无法缩放。

随着时间的流逝，软件质量会降低，需要更长的时间进行测试，并且测试结果的可靠性也会降低。 对于许多公司来说，这是一个死亡螺旋，他们最终由于恐惧和对测试的信心不足而很难进行更改。

要避免这种情况，开发人员需要花更多时间在编写自动化测试上。 这意味着开发人员可能花费60-70％的时间来开发测试而不是编写代码-如果您想生产高质量的软件，这就是开展业务的成本。

这看似过多，但需要权衡取舍：

• 更高的代码质量始终保持很高（这些测试始终运行，因此捕获了重新引入的错误（回归））
• 测试是开发人员上的最快速度，它描述了代码应如何表现并充当文档。
• 重构代码变得更加容易，因为您知道测试描述了它应该做什么。
• 对代码库的每次提交均经过全面测试，如果正确完成，则几乎可以立即将其部署到生产中。
• 使其成为产品的问题会反馈到更多测试中，并不断提高代码质量。

开发测试的大部分时间都花在思考如何解决问题上，但是您也在编写代码以使其可测试。 当开发人员知道需要通过测试与有人手动进行测试时，代码通常会用不同的方式编写。 以后再来为现有代码编写测试要困难得多。

您会听到我谈论持续部署和持续集成–我认为这些做法对于推动上述“良好”行为极为重要。 如果您为持续部署而努力，那么其他所有事情都会落到一起，而无需太多分歧，因为必须那样做。 除了上面列出的以外，它还有很多好处：

• 价值可以在几天或几小时内交付给客户，而不是数周或数月
• 开发人员可以立即获得有关其生产变更的反馈
• 新功能可以在开发人员脑海中重新调整和调整
• 不管缺陷的可预测性如何，您都可以专注于快速解决缺陷，而不是尝试预测所有可能出问题的方式。
• 支持持续部署的大多数工具和行为都可以扩展到非常大型的团队和非常频繁的部署。 亚马逊就是一个很好的例子，大约每11秒在某处部署一个东西。 许多拥有30至100名工程师的公司谈论每天部署数十次。
• 这也会影响您聘用质量检查/测试人员的方式。 这是一个较长的讨论，但是您想雇用可以在测试计划阶段提供帮助并可以帮助开发人员编写更好的测试的人员。 理想情况下，您的测试人员也是开发人员，并且以类似于运营的方式工作，从而帮助您的开发人员更好地完成工作。

＃3如果移动，则对其进行测量

我在上面提到，SaaS组织的两个主要优点是可以了解客户如何使用产品的数量以及快速更改产品的能力。 这两种方法都需要对所有发生的事情进行强迫性测量，以便您了解情况是好是坏。 其中一些指标与用户行为和体验有关，以了解服务的使用方式。 其他指标与系统性能和行为有关。

能够使您的部分客户群使用新功能并衡量其反馈的能力是巨大的。 许多公司已经完善了A / B测试的技巧，但其核心是衡量行为的能力。 与测试类似，必须以允许测量此行为的方式构建软件。

同样，系统性能需要大量的工具来识别趋势的变化，识别应用程序中的问题区域并验证何时更改可以真正改善情况。

我去过太多公司，他们根本不知道今天的系统与上周相比表现如何，以了解情况是好是坏。 在上一家公司，我看到了一种更为成熟的测量方法，虽然效果很好，但需要投资。 他们有两个人完全致力于绩效分析和客户行为分析。

参考： Operation Bootstrap博客中的JCG合作伙伴 Aaron Nichols提供的开发和运营中的好与坏模式 。

翻译自: https://www.javacodegeeks.com/2013/01/good-bad-patterns-in-development-and-operations.html

前端开发和运营那个好