我们要解决的问题

缺少已定义的流程会减少理解，增加效率，并使团队之间的依赖和期望变得复杂。

概述

以下是WMF产品开发流程的草稿。它描述了主要的阶段和参与者，以及整个产品发布周期(例如，一个特性如何从alpha到“生产”/一般可用性)。

还有很多张需要填写，请作为草稿处理

产品阶段和玩家

注:

“功能”指现有产品区域内的功能(产品区域=编辑、移动Web、移动阅读器、移动应用程序、协作等)。有一个单独的过程来决定哪个产品领域得到优先级(稍后描述，但大致符合WMF产品和工程采用的年度和季度计划过程)。这个过程假设已经做出了决定。

此图主要描述了“原有”状态，虚线表示需要进一步定义的组(例如，涉众、分析)。

介绍和概念

在这个阶段产生和选择新的想法。任何人(例如，产品负责人、设计师、工程师、社区联络员、用户)都可以提出一个功能想法，但产品负责人决定构建哪些功能。虽然这个决定是与团队的其他成员协作做出的，但产品负责人是做出最终决定的人。

(以下3个阶段在如何跨团队实现方面有所不同。有些团队在阶段之间有相对明确的边界，而其他团队有更容易渗透的边界。)

发现和设计

功能是从想法到用户界面和提供给最终用户的功能的第一步。技术发现和设计还用于分析实现该特性的不同技术方法。在用户体验和技术设计和发现中，经常会考虑多种方法，权衡利弊，然后决定如何继续。

开发

功能是由工程人员构建的。工程师(在技术领导的指导下)负责与用户体验设计和产品合作构建功能。

原型和审查

特性的早期版本(通常在下面描述的分段环境中)由最终用户测试。早期的反馈会被整合到后续的特性设计中。

评价

评估用户反馈和/或定量分析，并基于此分析细化特征。下面的部分将对这个阶段进行扩展。

生产启动

一旦该特性在测试阶段(如下所述)完成了所需的努力，就会开始逐步推出。团队使用各种方法进行渐进的推出(例如，按阶段分批地推出项目，首先登录用户，向初始百分比的用户发布，然后随着时间的推移增加百分比)。

对此特性的性能指标的持续监视发生在渐进推出期间。还可以监视对整个系统的任何不可预见的影响。

评价

在100%展示之后，将评估该特性是否达到预期效果。这种评估包括定量和定性分析，并使用短期(如天/周)和长期(月/年)时间框架。关于该特性的后续决策(例如，进一步增强、重新考虑该特性、取消该特性)都是基于此评估做出的。

成熟和支持

一旦投入生产，特性就需要持续的支持(例如，修复bug，与志愿者社区成员一起解决各种问题，等等)。

产品发布周期

Alpha 阶段

alpha阶段和alpha环境的目的是为开发人员提供快速原型化和测试特性以获得反馈的能力。Alpha环境主要是供产品团队原型化和测试的，并且很少与终端用户接触(如果有的话)。

从测试版毕业的标准因团队而异。一般来说，从Alpha毕业的门槛应该很低(例如，不拖垮其他服务，不破坏用户数据)，以确保功能能够尽快呈现在最终用户面前。

示例:WMFLabs、开发人员的本地机器、Android Alpha构建、移动Web Alpha(“实验模式”)。

Beta阶段

各种测试版程序为产品团队提供了一种方法，可以在一个环境中推出新软件，在这个环境中，许多终端用户可以使用这些特性，并提供反馈以帮助改进这些特性。团队的目标是尽可能快地让特性进入Beta测试，这样他们就可以收到来自真实环境中的真实用户的反馈。

我们的测试程序可以覆盖成千上万的用户(例如，大型项目中BetaFeatures的某些特性)到数十万用户(移动网络测试)

在这一阶段，评估方法包括定性用户测试(如当面用户测试、远程用户测试、调查等)和定量分析(如A/B测试、漏斗分析、基线对比等)。这些评估方法将在后面详细描述。

例如:Android Beta版，BetaFeatures(桌面版)，移动Web Beta版

逐步推出

一旦某个特性在测试版中满足了成功标准(成功标准稍后将被扩展)，产品团队就会进行下一步的逐步推出。渐进式的推出首先要向100%可用性迈出第一步(这本身还需要进一步定义，例如，一些特性只对登录用户可用)。这可以是对1%的用户发布，对一个小项目(或一组小项目)发布，仅对登录用户发布，等等。如果进展顺利，将继续分阶段推出，直到100%可用性达到。推出策略应该足够灵活，以便在出现错误时团队可以轻松地回滚。

例如:按项目、按项目组、仅登录、x%用户、最初选择进入→选择退出等。一个用于逐步发布的工具包，稍后将详细介绍。