本文里会以一个功能π的开发流程为例，展示公司内一个敏捷团队的软件开发实践。

项目背景

客户R是澳洲最大的在线房地产广告平台。公司团队是协助R客户创建一个针对中国市场的房产信息广告平台，用来展示澳洲以及其他海外房产，方便国内投资者。

作为一个全功能的交付团队，整个团队的人员一共11人，成员包括TL * 1、BA * 1、UX * 1、QA * 1、Ops * 1、Dev * 6。客户方面Delivery Lead * 1 和 Product Owner * 1, 两人均在澳洲。

客户负责提供项目的Roadmap，优先级以及初步的需求。后续由公司开发团队完成从需求分析、交互设计、功能设计、实现、测试、以及部署上线的全生命周期的工作。

功能π的敏捷之旅

下面以一个功能π的开发流程为例，展示笔者所在项目的开发实践。

计划

项目的路线图Roadmap是由Trello来管理的。Epic需求会由客户PO记录在Trello中。Trello board中设置的有不同的列，如Backlog, Planned, Next, In progress, Completed等。每列中卡片由上而下代表优先级的递减。Trello board作为项目high level需求的管理工具，可以很直观的了解项目整体的进展状况。

每两周全团队会进行一次计划会议，类似IPM，但是主要是根据Roadmap上的优先级，确定近期的开发计划。
最终的输出是一个具体的task列表。其中会包括:

• 当前进行中的任务
• 新加入的功能π
• 需要fix的bug
• 技术卡

计划会议上会把上述列表中的任务逐个讨论，目的是团队对于近期的优先级有一致的认识，以及对每个任务的内容做澄清。

团队JIRA作为需求管理工具，并同时使用物理Kanban墙以方便站会时讨论。计划会议中计划的任务会在JIRA kanban board中挪至Selected for Dev列。

对于新功能π而言，PO首先会在Trello上创建卡，并设置优先级。开发团队会按照优先级将功能π计划到后续的开发中。

需求来了

功能π开发的第一步就是由BA对客户提供的需求进行进一步的分析、细化、澄清和确认。如果功能π还涉及到用户交互，UX也会参与到这一步。UX会基于BA的分析，对信息流进行梳理，完成用户界面和交互设计。最终的输出结果为Jira上的用户故事。

用户故事一般遵从As…I want…so that的格式。在用户故事的内容上，一般会包含下面信息：

• 描述信息： 关于功能π的描述，提供更多的上下文信息
• 验收标准(Acceptance Criteria)
• 完成定义(Definition of Done)
• UI相关设计文档

另外一些信息会在后续环节持续补充上去，如分解的子任务，受影响的模块，需要部署的模块等。
分析完成的用户故事卡片会被挪至Ready for Dev列，后续会有开发着手开发。

Story Kickoff

开发人员在开始一个新的任务前，会首先进行story kickoff。这个环节主要目标是大家对功能有正确的认识，同时避免技术坑，简言之就是确保在以正确的方式做正确的事情。kickoff环节会有QA，Dev, BA, UX以及TL共同参与。在kickoff中，Dev会首先介绍当前自己对这个功能的理解，用户如何与系统进行交互，如何验证功能完成、以及技术实现。如果是一对Pair在kickoff，一般会有经验较少的Dev来进行介绍。

Story kickoff成功后，Dev会对功能π进行任务分解，并按照优先级以及依赖关系排列子任务开发顺序。任务分解的结果也会更新到用户故事中，一般会在用户故事卡下建立子任务，方便追踪进度。

结对编程

团队一般采用结对编程(Pair programming)的方式进行开发。结对编程的优点在于快速的知识传递，无论是对于刚进入团队的新人，还是刚接触某个模块的老鸟，业务知识还是编程技能。

Pair

在功能π的开放中，这对Pair中的两个Dev会以TDD的方式，合作完成业务代码和测试代码的实现。测试部分包括单元测试和自动化验收测试两部分。对于验收测试的部分，Dev有时也会和QA一起pair完成验收测试脚本的编写。

团队中也会周期性的轮换pair，这样每个人都有机会接触到不同的模块，使得业务知识在团队内更好的传递。

每日站会

团队每天会使用Always On Video和客户一起进行站会，更新项目的进展。

持续集成

在站会中，每个人/Pair会更新一下三个方面的内容：

• 上一个工作日的工作内容
• 遇到哪些技术挑战，有没有风险？
• 今天的工作计划

同时，团队会更新Kanban物理墙上功能π的状态。

持续集成

持续集成目前应该已经是软件开发的标配实践了，什么？你的团队还没？

持续集成

功能π的新代码每天都会多次提交到git, 持续集成工具会自动检测代码提交，并触发构建流水线。流水线中的验证环节会自动执行测试，验证系统功能正常与否，将构建物发布到软件仓库, 并最终将最新版本软件部署至测试环境。

持续集成

Code Review

每个工作日的5点至6点是code review时间。这个环节所有的Dev会集中在大屏幕前，集中review当天提交到git的代码。code review可以审查代码中的瑕疵，从基本的编码规范、代码坏味、明显的逻辑错误、以及功能实现上的疏漏等。同时，code review也是很好的knowledge transfer的方式。

持续集成

Story Signoff

Dev完成功能π的开发后，会邀请BA，QA，UX和TL进行story signoff。Dev会在本地或者测试环境中准备好测试数据，向参与Signoff的各位同事演示功能。期间，QA会要求Dev按照多个测试场景进行多次演示，以确保功能基本完整。UX也会按照设计Mockup对功能实现进行比对，确保在各个屏幕尺寸下显示符合设计。
Signoff通过后，Dev会更新kanban墙上功能π对应的故事卡的状态至 Ready for QA。

QA

QA会从看板墙的Ready for QA列中将功能π对应的故事卡更新至 In QA, 并在测试环境中按照设计的测试用例进行验证。

如果发现功能问题，会记录至功能π的故事卡，并交由Dev修复，并再次Signoff后，继续QA环节。
验证无误的话，功能π会被部署到预生产环境（Staging环境）。这样客户可以在预生产环境对功能进行review。

最终，π的故事卡会被挪至Ready for Release，并在下次上线时部署至生产环境。

部署上线

团队的持续集成流水线中包含了部署上线的阶段。如前所述，每次构建成功，都会将最新的软件版本部署至测试环境。发布到预生产环境和生产环境会按照项目和业务要求，手动触发。

对于暂时不需要发布上线的功能，如需要等待销售或市场部门配合，团队会使用功能开关(Feature Toggle)，将新版本部署至生成环境，但并不上线新功能。

feature toggle

另外，在部署流水线中，也集成了一部分的自动测试。当新版本在预生产环境和生产环境部署完成，但并未正式切换前，这些自动测试会被执行，以确保系统功能正常。

持续集成

至此，功能π就完成了它的敏捷之旅，成功上线！