3 天交付新需求？

极狐GitLab APP 「极限编程 XP」实践

极限编程（XP）是一个中小规模团队在面对模糊或者快速变化需求时，开发软件使用的轻量级方法论。

XP 由 KentBeck 在 1996 年提出，是敏捷软件开发中富有成效的几种方法学之一，它能够让客户满意度更高，更好地维护团队关系，更灵活且适配性更高。

XP 由一系列简单却互相依赖的实践组成。接下来，我们以软件开发的流程为主线，逐个讨论实用而具体的 12 个核心实践。

| 实践一：用户故事

用户故事主要解决需求澄清的问题。客户在提出需求之后，作为产品经理，需要对客户需求进行描述，形成相应的用户故事。

用户故事需要用户价值视角出发，是最小价值交付单位，例如手机号登录功能，对用户而言是有价值的；而如果描述为 “接口”，则是开发侧的任务。

| 实践二：计划游戏

计划游戏是研发团队与利益相关者举行的计划会议，包括两个层级：发布计划和迭代计划。客户以及团队中的所有开发人员都要参与到游戏中，实现合力。

• 发布计划：团队和利益相关者/客户，基于用户故事共同决定在生产中交付的需求和功能以及时间。
• 迭代计划： 团队将从列表中挑选最有价值的需求，并将其分解为任务，然后进行估计和承诺，在迭代结束时交付。

| 实践三：频繁发布

频繁发布（小发布，指需求很小）是指做完一个需求立刻发布，可以以最快的速度得到真正的市场价值，如果发现有问题也可以更快速度纠正；跟瀑布模式有着本质区别。

实践频繁发布，需要在开发的过程中，始终保持与客户的双向沟通，及时处理用户的反馈，长期去影响并且使得客户获取真正的商业价值，形成一个正向循环，实现成就客户。

| 实践四：简单设计

简单设计即不要超前设计，以能够满足需求的最简单的设计来完成任务；不要有重复的功能。

我们平时会碰到一些比较复杂的场景，在这些场景下，在极限编程中也有 Spike（探针，一个用来探索/寻找潜在解决问题的方法） 方式；后续有改动怎么办呢？还有重构与 TDD 来解决。

| 实践五：重构

重构是根据需要来重构，而不是根据猜测来重构，更不要在重构时变更外部行为。

同时，我们在实现产品的时候，有最小可行性产品（MVP）的概念，如果现阶段我们还不知道产品是否可行，那么，重构是一个实现最小可行性产品的具体技术方法。

| 实践六：测试驱动

测试驱动开发（TDD）指先写测试用例再写开发，确保后续的开发都可以以最快的速度形成反馈，并且得到极高的覆盖率（后端 90% 以上，前端 70% 以上）；并且是开发来写单元测试用例。

包括 4 步：写测试用例 → 确保测试用例失败 → 写代码确保测试用例成功 → 有必要时重构。

| 实践七：结对编程

结对编程由指所有的源代码都是两个开发人员在同一台电脑上编程的，可以形成实时的 Code Review。两个开发人员其中一人是编程的角色、另一人是策略角色。并且定时进行角色互换。

| 实践八：持续集成

持续集成是指每次提交之后在服务器构建，并且在提交到主干之后，再在主干进行集成构建。

主干合并使用极狐GitLab 预合并分支功能，这样可以提前做一些预合并，防止对主干造成问题。持续集成的优点显而易见：可以快速发现问题，避免合并地狱，并且实现快速发布。

| 实践九：现场客户

现场客户即客户是团队的一员，参与团队开发，快速反馈需求，时刻跟进进展。

| 更多实践：代码集体所有制、代码标准、可持续发展

1. 代码集体所有制：团队中每个人都拥有 check out 任何模块并对其进行修改的权力，每个人并不是独立的，都不会被限制在自己的专业领域。

2. 代码标准：在 XP 中，团队开发人员都遵循着相对统一的编码标准，强调通过制定严格的代码规范来进行沟通，尽可能减少不必要的文档。

3. 可持续发展：软件开发不是百米短跑，而是一场马拉松。要以结果为导向，团队成员必须以一种有节奏的可持续的速度前进。

极狐GitLab APP 是极狐GitLab 团队在 2022 年底启动的项目，通过外包，全远程开发，实现了 90% 以上的代码测试覆盖率，目前已经在 Apple Store 上架。这个项目应用了极限编程在内的诸多相关实践。我们重点分享其中 6 项：

| 计划游戏

首先，我们用了极限编程的计划游戏。极狐(GitLab) 作为客户，通过每日站会，每周迭代计划会以及需求梳理会，与外包供应商保持沟通。

除了实时同步沟通还有异步沟通，异步沟通使用极狐GitLab 中的议题看板，根据需求挪动需求状态。同时，我们注意到，看板上的所有项目，其 label 可以自定义而且互斥，这样可以更好地对需求进行更新。

| 用户故事实践

我们将极狐GitLab APP 关键需求形成用户故事，启动 3C 公式、DoD、AC、故事点。

1. 3C 公式：卡片（Card）、交谈（Conversation）、确认（Confirmation）；

2. DoD（Definition of Done） ：明确 Done 的标准；

3. AC（Acceptance Criteria )：明确制定验收标准；

4. 故事点：预估每一个用户故事的大小，更准确算出团队的吞吐量。

| 简单设计 + 按需重构实践

如下图，有一个把 RESTful 改成 GraphQL 来提升速度的提交。这在最开始阶段是不需要的，最开始需要把 MVP 做出来，当后期性能不足时，在进行性能提升。

这里使用了极狐GitLab 推送规则功能，让每一条提交都讲明白它是做什么事情，以及它的 issue 号是什么，使得整个提交都非常干净。

另外，项目还使用了极狐GitLab 自动化流水线，实现自动检查、自动打包（包括安卓和苹果制品包）与每天超过十次以上的构建。

| 测试驱动实践

极狐GitLab APP 也使用了 TDD 测试驱动实践，每次都是先写测试用例，再写开发，测试覆盖率是在 93% 左右。这不仅仅是一个数据，最主要的是我们可以在不影响老需求下，更快地将新的需求上线。

同时我们使用了极狐GitLab 合并请求批准功能，限制了用户不能随意提交只有功能没有测试的代码，强制执行 TDD。

最后，从价值度分析可以看出来，交付时间是非常快，一个需求从提出到上线只需要 3.1 天，即可投入到市场，提供商业价值。

以上就是今天的分享，谢谢大家！