产品开发方法

要查看 PDF 版本（仅包含本页面内容），请单击此处。

目前，MicroStrategy 的技术团队遵循敏捷产品开发方法。构成该技术团队的群组如下：Scrum 精干团队、产品负责人、产品管理、软件工程、软件质量、用户体验设计、内容、本地化和开发运营。

Scrum 精干团队与其可交付成果紧密关联，他们工作中的迭代/冲刺周期为两周，每个周期会以关键事件（例如某一具体迭代期间软件交付量增加）的发生而完成。“执行计划”被定义为包含本季度工程和质量可交付成果的 6 次迭代。MicroStrategy 产品的开发包括软件架构、设计原则以及软件的持续验证和部署。在产品开发过程中，产品组合功能（以下简称为“功能”）会分解为其组成要素。然后，对与这些功能相关的增量值进行分配，并相应地分派资源来执行任务。

MicroStrategy 设有跨全球技术中心的中心源控制、版本控制、分支和代码管理系统。这些系统针对开发流程、代码覆盖和企业软件交付的其他基本原则（如静态代码分析）提供治理、签入控制、代码评审执行，以及富有实用价值的分析洞见。

MicroStrategy 维护着一个集中式系统，用于捕获产品开发和质量管理各个方面的信息。质量管理中包含的“QA 计划”是预定义的自动和手动测试用例，用于代表一系列用户工作流程。集中式系统通过用户故事、任务和缺陷来捕获所有计划和功能中的工作项目。计划和功能以点为单位度量，而任务以小时为单位度量。

中心系统与源代码存储库、构建流程和分析集成，为团队处理的内容、工作项目的状态和源代码提交项的规模和性质提供透明度。此外，它通过软件设计、代码、自动化和集成测试帮助确保满足可跟踪性要求。所有这些均可持续集成、持续交付和持续部署。该中心系统由产品管理、产品负责人、架构师、工程师、开发者、质量分析师、用户体验、内容、文档和执行角色使用。

发布方法

MicroStrategy 产品版本包含面向移动应用程序和桌面应用程序的月度版本。这些版本根据创新和客户反馈增加了新功能并进行了产品改进。此外，MicroStrategy 每个季度都会在最新的平台版本上发布累积更新。例如，2022 年的发布计划包括第一季度的 Update 5 (11.3.5)、第二季度的 Update 6、第三季度的 Update 7 和第四季度的 Update 8。此前，MicroStrategy 平台版本会每年发布一次，通常会发布重要的新功能和创新并进行产品增量改进；而 MicroStrategy 更新则致力于针对部分客户报告的产品、安全、性能和可扩展性问题进行改进。随着速度的提升和对开发实践的改进，MicroStrategy 能够在每个季度的更新中提供相同类型的范围，但版本之间的增量较小。此外，还会根据客户问题的优先级、严重性、影响程度和普遍性，继续对系统记录中的软件质量度量确定的问题进行更新。MicroStrategy 典型更新周期包括六次迭代，其中平台的各个方面围绕环境、角色驱动用例、功能、性能、稳定性、安全性、可扩展性、国际化、兼容性、升级、可访问性和其他发布标准进行验证。产品质量各个方面的严格验收标准已经过审查和验证

MicroStrategy 还提供一个上报流程，客户可以通过客户主管和客户支持联络人上报关键问题。除定期更新外，MicroStrategy 会经常审查上报的问题，并可能会相应发布软件补丁版本。MicroStrategy 补丁版本通常会以累积形式附加到下一个可用的 MicroStrategy 更新和下一个 MicroStrategy Platform 版本中。

质量计划

功能中规定的验收标准通常会考虑功能、性能、可靠性、安全性、可扩展性、国际化、兼容性、升级和/或可访问性。在批准将功能应用于执行计划之前，应检查定义、工程设计、持续集成/单元测试、架构、UX 工作流程和/或质量测试计划。这种方法先严格执行再编写代码，并帮助消除歧义，以及将用户体验设计、工程、架构和测试计划统一为清晰的目标。

这些计划有助于确保在整个迭代过程中定期检查工作项目，以确保符合规定的验收标准。按照传统，总体测试计划会考虑用于持续集成测试的自动化测试方法，并基于这些测试自动批准/拒绝提交到中央版本化源代码存储库的任何建议代码。

MicroStrategy Platform 构建版本通过企业发布标准体系执行了大量系统测试，利用代码质量扫描和分析以确保构建版本发布给 Scrum 精干团队之前的完整性。目前 MicroStrategy 构建版本发布在 Windows、Linux、Amazon Linux、Red Hat Enterprise Linux、MicroStrategy on AWS、MicroStrategy on Azure、iOS、OSX 和 Android 操作系统上。构建版本发布给 QA 后，Scrum 精干团队会将已发布 Intelligent Enterprise 地图上由关键 MicroStrategy 角色驱动的端到端测试用例用作验证流程的一部分。

MicroStrategy 对安全漏洞进行定期的源代码安全扫描、二进制代码安全扫描、内部渗透测试和第三方独立渗透测试。测试的漏洞类型由 OWASP Top 10和 SANS Top 25指定，但不限于此。

MicroStrategy 开发并维护其软件平台的中心部署。对于每一次迭代，这些系统都会升级，数据经过验证，相关的性能基准和容量指南经过衡量，并与先前的验证点进行比较。这些系统都是在我们与客户和合作伙伴的战略关系基础上建立的。这被称为“客户验证计划”。

MicroStrategy 利用自己跨内部系统部署的平台对组织执行任务关键型分析。这些内部系统上的关键利益相关者会定期签核构建版本，并将此作为发布周期的一部分。

“质量计划”存在的目的是确保客户问题上报给技术团队时，能得到评估、分配、计划并及时解决。高级技术领导定期与技术支持部门和销售部门会面，确保组织获得的最新信息一致。在这些会议中，通常会审查与工作项相关的关键指标，包括年限、优先级、严重性、影响程度、第一次响应的时间和结束的时间。这次会议中涉及的项目要进行根本原因分析 (RCA)，从而发现上报问题的根本原因，纠正问题，解决任何工程或质量流程缺陷，并将这些会议中的项目添加到记录系统，实现产品开发改进。

质量计划与企业支持计划配合，确保员工定期与我们的客户合作。可以通过升级计划、与 MicroStrategy 的咨询部门合作等形式，来获得客户用例体验，或者通过与客户召开 UX 设计会议，在开发周期早期提供设计意见。

MicroStrategy 拥有强大的机制，可以通过其现场组织从客户那里获取反馈，为路线图提供指导并提前了解技术战略方向。这同样适用于许多战略客户路线图审查。平台路线图上的许多当前项目都直接源于这些会议的反馈、企业支持和 UX 互动，以及客户情报（来自支持部门以及协同合作代表客户进行宣传的客户团队）。

产品开发检查点

下表包含了 MicroStrategy 产品开发生命周期中的关键敏捷检查点和输出内容。

检查	描述
发布计划	透明和包容的同步计划事件，可以让利益相关者和相关团队了解目标、确保可交付成果与企业愿景一致，并努力交付高质量的产品以保障客户成功。
发布就绪	通过工程架构、用户体验、客户工作项目、功能、性能、可扩展性、安全性、国际化、升级、兼容性、可访问性等方面的反映情况，对组织范围内的验收标准进行检查并实现产品开发关键绩效指标。CXO 级会议确保可交付成果的透明度。
分类缺陷	团队的日常活动，可审查传入且未解决的缺陷，了解其的影响，分析其模式，并制定优先级和计划。应当优先审查客户缺陷，以确保彻底进行评估，以及通过技术支持和 QA 流程与客户进行交流。
更改管理	计划完成后，“更改管理”事件能够密切控制进入或退出发布的范围，从而维持发布焦点、质量和交付可预测性。对于每次更改，都要针对关键 KPI 执行全面的影响分析，包括交付执行计划所需的价值、成本和量化调整。
迭代计划	一个集合点，Scrum 精干团队在此处提交迭代内可交付的工作。产品负责人应阐明产品积压项目及其各自验收标准的详细信息，以便交付团队了解要求并明确履行承诺所需完成的工作和所需付出的努力。
每日站会	每日定期举行的事件，Scrum 精干团队在这段时间评估其迭代的状态和流程。团队成员简要交流前一天完成的工作、当天计划的工作以及强调会出现的风险，以便产品负责人和 Scrum 精干团队带头人可以采取必要的措施以降低风险。
Scrum 中的 Scrum	Scrum 精干团队带头人、产品负责人和产品经理每日定期举行的事件，旨在审查迭代和发布进度、强调和解决依赖关系，以及为需要跨团队合作的任何功能安排工作计划。
积压项目简化	定期举行的事件，整个 Scrum 精干团队在这段时间内协调、了解和分解将在未来迭代中引入的工作项目。产品负责人向团队展示排列好的积压项目，并通过对工作项目加以描述来帮助团队了解要求、价值主张和验收标准。产品负责人向团队成员征集关于依赖关系、风险、假设、验收标准和概括性估算的意见，以帮助在迭代计划事件之前简化工作项目。
迭代审查	迭代最后一天的事件，Scrum 精干团队会向其他团队和利益相关者展示完成的产品功能。这有助于团队直接从利益相关者处收集反馈，以便对未来迭代进行调整，使计划与利益相关者的要求和优先级保持一致。
迭代回顾	迭代的最后一次 Scrum 事件，Scrum 精干团队会回顾迭代过程中的性能。团队讨论迭代的重点，并针对下一次迭代就改进计划达成共识。