浅谈对敏捷的认识-京东云开发者社区

### 1 前言

不知不觉敏捷已经在部门团队中发展一年多了，在这一年多，从我作为团队成员初识敏捷到所在团队获得敏捷三级、再到团队获得敏捷四级，在团队的共同引领下，我也见证了自己对敏捷的理解，或者说有了对如何看待敏捷的相关思考。在这一年多，作为团队成员从初识敏捷到所在团队获得敏捷三级、再到团队获得敏捷四级，在团队的共同引领下，激发了我对对捷的好奇，或者说自我有了对如何看待敏捷的相关思考。

### 2 敏捷的前世今生

敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者的聚会，17位软件开发者齐聚在美国的犹他州的雪鸟(snowbird)，讨论上述轻量级的软件开发方法，并写下了敏捷软件开发宣言。

### 3 敏捷的价值观

1. 个体与互动重于流程和工具
2. 工作的软件重于详尽的文档
3. 客户协作重于合同谈判
4. 响应变化重于遵循计划

针对以上4条敏捷价值观：我的理解是敏捷中我们更加重视人在团队中的作用，而不拘泥传统项目流程的刻板，注重软件的结果，与客户之间的关系也更倾向于合作共赢，并且敏捷倡导要欣然接受变化，响应变化，为客户带来更重要的价值与收益。用五个词语来形容敏捷：勇气、承诺、尊重、专注、开放。

### 4 敏捷的原则

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
2. 欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化
3. 经常地交付可工作的软件，相隔几个星期或一两个月，倾向于采取较短的周期
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外
5. 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而达成目标
6. 不论团队内外，传递信息效果最好效率也是最高的方式是面对面的交谈
7. 可以工作的软件进度的首要度量标准
8. 敏捷过程提倡可持续开发，责任人、开发人员和用户要能够共同维持其步调稳定延续
9. 坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强
10. 以简洁为本，它是极力减少不必要工作量的艺术
11. 最好的架构、需求和设计出自自组织团队
12. 团队定期地反思如何能够提高成效，并依此调整自身的举止表现

### 5 敏捷的活动

敏捷中的活动主要包含：3种角色、3种工件、五种仪式；

#### 5.1 三种角色：主要包括PO、SM、开发团队

##### 产品负责人（PO）：

- 清晰地表达产品待办列表项
- 对产品待办列表项进行排序，最好地实现目标和使命
- 优化开发团队所执行工作的价值
- 确保产品待办列表对所有人可见、透明、清晰，并且显示Scrum 团队的下一步工作
- 确保开发团队对产品待办列表项有足够的理解

![](//img1.jcloudcs.com/developer.jdcloud.com/ad03450a-9c12-473b-a63d-3c730a9daa9620220506144437.png)

##### Scrum Master：

负责确保所有人都能正确地理解并实施Scrum。因此，Scrum Master 要确保Scrum 团队遵循Scrum 的理论、实践和规则；Scrum Master 是Scrum 团队中的服务型领导。

这里强调一下：与传统的项目经理有相似但是很不同在于敏捷中的SM是注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。

![](//img1.jcloudcs.com/developer.jdcloud.com/b1483bbb-e3d6-45a3-ad44-ac10d584440620220506144501.png)

开发团队：有自主权选择如何最好地满足目标，并且为之负责，在这里我们也可以感受到我们敏捷的价值观：开放、承诺、勇气等

#### 5.2 三种工件

Scrum 的工件以不同的方式表现工作任务和价值，可以用来提供透明性以及检视和调
整的机会。Scrum 中的工件就是为了最大化关键信息的透明性，因此每个人都需要有相同的理解。

##### 产品待办列表（Product Backlog）

- 产品需求列表；
- 产品负责人对该列表进行优先级排序；
- 待办事项列表中的条目以用户故事的形式呈现；

##### Sprint 待办列表（Sprint Backlog）

- 是产品待办列表的子表，只记录当前迭代的工作；
- 将用户故事拆分成任务，团队成员主动领取任务；
- 团队成员可以添加、删减或者更改迭代中的任务。

##### 产品增量（PSPI：Potentially Shippable Product Increment）

- 团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付。
- 每次交付的用户故事必须符合验收条件。

![](//img1.jcloudcs.com/developer.jdcloud.com/24739b27-0ed1-4776-8451-b9b67a5331ad20220506144913.png)

#### 5.3 五种仪式

![](//img1.jcloudcs.com/developer.jdcloud.com/86313dae-250d-4cca-8a9a-0558007afb2920220506144934.png)

1. 需求梳理会：主要是产品对待办需求进行向团队成员进行需求讲解，保证全员信息共享，名确需求内容，从技术角度考虑产品需求的可行性。
2. 迭代计划会：主要是将迭代中已经明确的需求，团队成员进行自主领取任务，自主评估故事点以及做出承诺。
3. 每日站会：需要PO、SM以及所有团队成员进行参与，会议主要表达：昨日做了什么，今日计划做什么？目前是否存在困难，需要谁来协助？
4. 回顾会：主要是针对上个迭代中存在的问题或者不足，进行复盘梳理，并且提出的建议或者方案一定要进行落实行动。

### 6 敏捷中的团队管理

敏捷中的团队管理是：自主式、去中心化、更注重团队精力管理、效率管理、情绪管理等方面来提升团队成员的自驱力，以小步快跑，不断调整执行，快速执行来获取用户的真实反馈。这也是我们PDCA计划、执行、调整、行动的体现。

### 7 团队实践案例

**项目：**报价审批线上化
**背景：**区域提报网格站报价都是线下邮件提报，总部线下审核，效率低，流程慢
**解决方案：**可以实现线上审核，移动端、PC端批量审核

**敏捷的实现过程：**
确定项目的最小核心交付单元MVP，实现报价提报、报价审核、报价确认；

对于其他的需求比如：报价变更、报价邮件提醒等功能我们都按照kano模型来制定项目的优先级，进行后续的迭代优化；在敏捷过程中，识别项目的最小mvp是很关键的一点，我们通过最小成本来获取用户反馈，然后进行不断改进。

另外项目敏捷中：团队成员一起参与故事点评估，进行打分，同时对于迭代中的风险以及困难会在每日站会进行传达和反馈，对于重要的事项会由早会主持人进行整理早会会议纪要，可以对重要的事项进行追溯和整理；但是唯一与敏捷知识中，我们团队目前尚未执行SPRINT评审会，但是我们是通过产品进行UAT验收通过后，再发起邮件邀请业务进行UAT验收，业务UAT验收通过后，项目才安排上线；基本上也是做了完整的验收过程。

对于回顾会，团队成员会在回顾会空间畅所欲言，表达上个迭代过程中的不足，对于不足，团队成员进行一起讨论解决方案，达成一致可以进行落实行动，通过回顾会，加强了团队成员的复盘、反省、梳理的自驱力，让团队更加进步。

目前短链报价线上化项目已经顺利交付3期，未来还会新增优化功能，让业务更加便捷，给业务降本提效。这或许就是敏捷的魅力所在，在不断变化中，快速响应业务，不断创造价值。

### 8 总结

敏捷管理最吸引我的地方，是它的机制目标-------是通过建立一个高效运转的自适应系统，来提升团队成员的效率，保证项目高效，正确的运转。弱化了团队成员个人英雄主义，突出了管理体系，规则对团队效率的影响力。团队整体效率的提高，远比个人英雄主义式的运转机制效率要高很多。每个人都是特定环境制度下的产物，scrum承认和接受这个现实，进而审视导致失败的制度，最后着力改良制度。

------------

###### 自猿其说Tech-JDL京东物流技术与数据智能部
###### 作者：赵朦朦（攀登者小组）