理解敏捷开发
UNDERSTAND AGILE DEVELOPMENT
量潮科技
/引领定量分析时代潮流/
前言
这篇文章以我们目前的软件系统（内部对整套系统的称呼为“量潮应用系统”，英文代号为QtApp）的研发管理经验为例，为大家讲解什么是“敏捷项目管理”。
我们使用的DevOps平台是腾讯云的Coding（CODING - 一站式软件研发管理平台），这里使用的具体功能是Coding的项目协同的敏捷模式（CODING 敏捷开发 | 助力敏捷开发实践）。由于这篇文章不是对Coding平台使用方法的介绍，所以不详细介绍如何操作，而是直接呈现结果。
这篇文章主要分为几个部分：
1.介绍项目背景和目前的进展，为后续介绍敏捷举例提供便利。
2.通过一系列基于实际软件工程背景的提问，引入“史诗”、“迭代”、“需求”这几个关键概念。
3.总结梳理基于敏捷的完整项目规划步骤。
作为一个还在发展业务、探索业务、探索组织方式的早期初创团队，我们确实还有很多方面做不到位，在敏捷方面的经验也还不是很充分。欢迎大家批评指正，也希望可以帮助到有类似困难的同伴，比如我们所接触到的初创公司和大学生创业团队。
Quanttide
01
项目背景
Project context
向上滑动阅览
量潮应用系统（QtApp）是我们对于我们内部软件系统的统称，目前这个系统刚刚完成规划架构，还在初步实现MVP，因此还是一个很早期的项目。由于这是一个关联度相对比较高的复杂项目，因此在工程上我们做了统一管理。在技术选型方面，客户端根据应用需求以Flutter或者微信小程序/小程序跨端为主、服务端选择Django作为主要框架、Python云函数为辅，以腾讯云云开发（云开发CloudBase - Serverless 云原生一体化产品方案）为主要部署服务的平台，以Coding为主要的DevOps平台。
主要包括以下几个部分：
1.量潮课堂APP。这是一个为高校学生和互联网新人提供的开发者入门课程，目前计划的主要课程有“Python&编程入门”、“Python X 云计算系列”、“Python X 数据分析”、“云原生架构系列”等课程。这是一个打算在Android、iOS、Web、Windows、macOS、Linux全平台覆盖上架的“重型”APP，因此客户端选择Flutter作为主要开发框架。围绕着文字和视频课程，我们计划为用户提供一系列帮助他们练习和答疑的机制，因此这个客户端的最终成品会十分复杂、工程量十分庞大、工程周期也会很长。对于这个APP业务思路的出发点，在此不再赘述，欢迎大家关注我们后续的文章。
2.量潮数据服务APP。我们一直以来为我们周围的老师和研究生提供科研数据的采集和处理服务，而项目进度的管理和数据的交付一直以来困扰着我们。这个平台希望可以规范和管理从客户需求收集到数据交付的服务全流程。实际上此产品的技术实现难度很低，而主要的问题集中在产品逻辑的梳理、也不需要覆盖太多客户端，因此我们采用微信小程序作为客户端，后续根据项目进展考虑演进到小程序和Web的跨端方案。
3.量潮企业后台。主要是为以上APP提供内部的管理入口，以及补充企业微信的能力二次开发。这些应用主要以企业微信应用和Web应用的方式存在，因此主要是选可开发Web的框架（不排除Flutter）并做企业微信兼容。
为以上前后台应用，我们计划通过一系列中台服务支持。其中，数据中台和算法中台还在规划中，等到业务上线以后分析需求逐步明确再推进，技术中台大多数已经使用腾讯云云开发等云服务提供的能力消化，因此我们主要规划业务中台的设计，目前主要包括：
1.用户中台。主要是为所有其他服务提供用户认证服务，提供了登录注册接口、查询用户资料接口等。
2.支付中台。主要是为业务提供支付功能，根据业务场景划分为数个类型的接口（基于领域驱动设计，DDD），每个领域主要包括商品和订单两个主要模块。
3.设备标签中台。主要为Flutter、微信、内部定义的客户端设备提供统一的转化标签，主要是为了适应跨平台的多端统一，为后续数据分析环节的渠道分析和其他可能环节提供便利。
4.日志中台。主要记录客户端和服务端各个应用和服务的操作记录，方便后续数据分析环节精细化分析用户行为，此外还用以监控系统健康、提供运维和安全方面的支持。
其他业务中台根据需要会进一步规划。
我们目前有三个组分别在不同的方向上推进项目。
其中，一个小组负责数据服务APP的设计和开发，数据服务的业务方为平台方提供必要的支持；一个小组负责课程APP的开发，并且协助中台服务的完善；我直接负责中台的设计和开发。
在过去的三个月里，我们主要把原来的大型单体项目拆分为了一个个微服务，把原先前后端不分离的项目进行了前后端分离，把服务和应用部署到了云开发和Coding上，对团队内部的工作流程进行了重新梳理，并根据康威定律对组织架构进行了调整，最终初步形成了一套云原生的生产模式。下面的文章就基于这样的背景讨论敏捷项目管理。
02
敏捷的主要概念
The main concepts
of Agile
向上滑动阅览
史诗
经过了单体架构拆分微服务的架构重新设计以后，我们的业务中台被根据功能划分为了用户中台、支付中台、设备标签中台、日志中台等部分，每个中台具体实现是一个Django项目，部署在一个云开发的云托管（App Engine）上。那么，实现一个用户服务是一个很大的功能点，在敏捷项目管理中我们叫做“史诗”。
史诗是一个较大的功能或特性，可以分解为许多较小的事项。它通常需要进行多次迭代才能完全交付。敏捷史诗的范围是灵活的，基于客户反馈和团队开发节奏灵活调整其下需求和任务。您可将史诗分解为粒度较小的需求和任务，并将它们安排到迭代中去完成。
Coding操作史诗的方法详见：史诗管理 - CODING 帮助中心。
我们通过以上文档的指示创建一个“史诗”，这里我对史诗的定义是“上线稳定的用户中台”，我这里的具体含义是在现有设计思路下不再需要大的迭代进行升级（不排除未来需求发生变化的可能），功能已经基本稳定、只需要定期和不定期修正Bug即可。另外一个关于设备标签中台的史诗同理。
由于有多个史诗，Roadmap功能（实际上是甘特图）就可以用上了。由于我设置了开始时间，每个史诗会从开始时间这里显示一个长条到结束时间。这里我没有设置结束时间，因为现在还没办法预测。如果对开始时间和结束时间做准确的、符合自己的规划的设置，则可以在Roadmap上清晰地看到一段一段时间需要干什么。
这样，基于“史诗”这个概念，CEO等非技术方向的管理层，和CTO、技术总监、架构师等技术方面的管理层，则可以根据史诗和Roadmap对于“接下来很长一段时间技术团队到底要干啥“形成一个相对可视化的共识。（PS：当然，如果设的马马虎虎，最后看着还是一团糟，这个功能也会形同虚设，所以每条一定要做的仔细。）
需求
史诗是不可以被一下子做完的，所以我们还需要明确每个阶段具体要做什么事情。我们最常看到的一个概念叫做”需求“，通常就是指一个可在一个时期（通常是我们后面说的迭代）完成的特性或者功能。
Coding操作需求的说明详见：需求 - CODING 帮助中心。
我在拆分微服务项目的过程中，除了需要处理微服务对代码逻辑带来的改变，还顺便把原来在项目中留下的TODO说明整理到了Coding上，然后把Coding事项的链接附在TODO上。一个Coding事项往往会在多个TODO出现，因为需要修改这一系列的位置留下的未完成才可以实现这个需求。这些未完成且未经规划进迭代的事项，被Coding放在了一个Backlog的位置，如图：
比如#279添加对邮箱登录的支持，在我的代码内部对应的就是多个位置，包括验证码增加邮箱支持、登录注册支持用户名字段是邮箱，我按照上面的操作进行了处理。这里只是一部分事项，还有很多事项还没有被梳理明确并整理起来。（PS：项目并没有特别复杂，但一项一项管理起来是工作量十分庞大的事情，还十分费脑子费心力。）
对于每条事项，左边依次是事项类型（需求/任务/缺陷）、编号和名字，右边依次是所属史诗、优先级（绿色为低、黄色为中、橙色为高、红色为紧急）、负责人、故事点（一个和迭代有关的概念，暂时不管）。可以拖动Backlog内的事项顺序来大概地排出一个顺序，方便后续规划迭代。
迭代
好了，我们终于进入了敏捷最关键的一步：迭代。什么是迭代呢？简单地说，就是完成一系列需求、任务、缺陷以后所完成的一个阶段性的特性或者功能的改进。所以迭代是增量的。通过一系列迭代我们可以干啥呢？比如我们想画一幅蒙娜丽莎，我们首先做的事情不是先把她的耳朵画好，而是先把人的轮廓勾勒出来，然后一步一步填色、修改等等。这样的过程就是“敏捷”的一个一个“迭代”。一般来说，常见的迭代的交付物（给需求方的产物）是一个“版本”，在使用Git的情况下做版本管理十分简单，这里暂时不再延伸。
关于迭代的更多介绍：快速开始 Scrum 敏捷协同模式。
关于Coding操作迭代：迭代管理 - CODING 帮助中心。
以实现用户服务为例，我们因此可以规划一个迭代，如图：
我们设置迭代的名称、主要目标（不显示）、起止日期，并且管理状态（未开始、进行中、已完成等），同样也可以设置故事点。在图中可以看到，我们可以在迭代下面创建事项，或者把刚才的Backlog的事项拖动到这个迭代里。这就是对迭代的主要管理，十分简单。
迭代周期应当设置多久呢？目前互联网行业的一般规范是两周。因此，迭代目标不宜规划的过大，可以以两周以内实现为标准。我们内部的建议是一周，因为使用的框架开发效率大多是传统框架的数倍，我们又是以周为单位管理团队，也是引导团队成员尽可能把目标放在眼下的小事情，防止在大目标里迷失。
下面我们来尝试管理迭代。在我们的Backlog里，有哪些事情应当属于“基本用户服务开发环境的最小可用版本”？仔细思考以后，我发现他们中的一个都不属于。因此我把他们丢在Backlog里，等待以后的迭代再规划。实际上，应该放在这个迭代里的是我现在手头上在做的重构，但由于时效性很高，也很难界定一个需求/任务/缺陷的边界，所以我暂时打算在整理完代码以后再把明确的事情放进去。
03
明年工作计划
Organize the Agile practice process
向上滑动阅览
由于核心的流程是规划迭代，因此各位开发者和技术团队只需要在这一步相对标准即可，其他的根据自己团队及项目的特点和阶段，这里只是一种建议。
1.非技术决策者和技术负责人坐在一起共同决定“史诗”，并形成一个相对稳定的Roadmap。这一步的主要工作是明确技术架构、划分团队内部多个组的职责，把每一个明确的独立的软件单元作为一个史诗，比如“用户服务”、“课堂APP（包括前后端）”、“数据服务APP”等。特别注意，史诗的划分要以团队的组织架构为边界，比如如果APP的前后端是两个组，则可以安排两个史诗；如果在一个产品组，则可以划分一个。
2.具体负责项目的成员坐在一起头脑风暴，把所有可能要做的事情都列成“需求”、“任务”、“缺陷”。注意，组织整理的环节在规划迭代，所以这一步列举的越详细越全面越好。（PS：这是一个来自GTD工作法的实践经验。）对于每一件事项，明确地定义目标、优先级、起止时间、实现方式等必要的信息，放在同一个事项的资料下。
3.在敏捷教练（就是很懂敏捷的人）的帮助下项目负责人规划迭代、制定迭代目标，所有参与人员都明确自己负责的事情和迭代的起止日期。这是敏捷实施的最关键的一步，一定要严格地去做。
4.项目负责人及其汇报人及时跟踪迭代内事项进展。具体的形式有多种多样，比如，互联网公司通常使用日报的形式交流沟通每天的进展；敏捷的标准方案建议通过“站会”的形式，大概就是早上一起站着开15分钟会。我们由于整个团队在线上工作、且团队成员主要是在校生，所以我们的主要形式是建议每天工作前大概说一下今天的计划、团队和项目的Master提出指导意见，用这个机制代替站会；我们要求每次的提交尽可能小，每次工作以后都提交一次讨论，这样只要有人有进展，都会被及时讨论；通过查收日报收到每天的进展并交流讨论怎么解决问题。（PS：把目光聚焦到结果上，可以让团队及成员的时间事项更弹性灵活，比较适合我们的情况。）特别注意，规划迭代不是真正决定项目成败和质量的关键，及时跟进并处理问题才是。
04
下一步关注的问题
The next question
to focus on
向上滑动阅览
在使用敏捷的过程中，我们发现了很多我们还没有能力解决的问题。
比如，早期项目往往还在频繁的变更架构和具体实现，“需求”可能说变就变，十分不稳定，不管理他们会混乱，而管理起来又费时费力，怎么把握好这个度，让敏捷的方法论成为助力而不是阻碍，我们还不是很清楚。我的一个小组负责人也提出了同样的疑惑，事实上我们对这个问题还没有一个很清晰的答案。目前我的阶段性观点是，这个困难是早期项目本身的不确定决定的，和项目管理无关。
此外，对于“故事点”/“里程碑”这个敏捷里另外一个用来管理工期的关键概念我暂时还理解的不太透彻，不知道怎么应用起来，如果后续有研究会写一篇新的文章来讨论。
我们发出这篇文章，希望可以和同行们一起讨论敏捷项目管理，互相帮助、提高研发效率。欢迎建议！
知乎链接：
https://www.zhihu.com/question/19645396/answer/1801401325
欢迎关注知乎机构号！
