背景：
2022年5月，践行敏捷已经有一年有余，自认为在Scrum这套框架下已经玩明白了。就老想着找个参照物来验证一下我们团队的敏捷成在什么水平，也找过类似AMM这样的框架来评估成熟度。但是整体得分不高，这让我在心中种下了一个疙瘩，评分不高如何改善？其他的公司敏捷是怎么做的？ 如何借鉴（抄作业）？机缘巧合下找到了这本《京东敏捷实践指南》 。由于在2022年5月的时候 ，我的敏捷知识还停留在 当时从Scrum联盟所学习的CSM认证体系课程。核心问题是一直是以Scrum Master的视角去建立3355的架构，没有深入 而这本书在一定程度上补全了我对敏捷的认知。
正文：
我们先来谈谈这本书讲了什么？
全书只有7个章节，总体来说算是短的，概况起来也很容易大致分为 敏捷基础 、 敏捷实践 、敏捷流程 三个部分。
第一部分：敏捷基础
1，第一章，为什么需要敏捷？
重点1.1：阐述 VUCA时代 。即： 动荡性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）、模糊性（Ambiguity）。
重点1.2：阐述瀑布与敏捷对比。包括：瀑布模式与敏捷的 价值交付对比、风险对比、铁三角对比。
重点1.3：敏捷带了的收益。包括：提升员工参与度、更快推向市场、提高生产力、消减缺陷。
2，第二章，敏捷是什么？
重点2.1： 敏捷历史，敏捷起源。杰夫·萨瑟兰 1995年发布Scrum框架，2001年17位大师共同签署《敏捷宣言》。
重点2.2：项目生命周期。
预测型：需要提前大量的计划工作，然后一次性去执行，执行是一个连续的过程。
迭代型：允许对未完成的工作进行反馈，从而进行修改该工作。
增量型：向客户提供多个已完成、可立即使用的可交付成果。
敏捷型：既有迭代也有增量、频繁交付便于根据反馈不断完善交付成果。
重点2.3：敏捷宣言
重点2.4：十二原则。
重点2.5： 主流敏捷框架。
|
方法 |
特点 |
|
Scrum框架 |
面对一个5~11人的小团队，关注管理实践，核心是迭代 |
|
看板方法 |
面对各级团队，关注管理实践，核心是采用看板、限制在制品及拉动式工作，通常搭配看板方法其他各种方法，如Scrum、XP等 |
|
XP |
极限编程，关注工程实践，通常各种方法都与之搭配，适合各种规模的组织。 |
|
SAFe |
规模化敏捷框架，面对成百上千人的组织，采用系统思维，自顶向下对整个组织进行设定，核心是将组织现有的各角色映射到预定义好的敏捷角色中，并逐步演进工作方式。 |
|
LeSS |
大规模Scum,面对成百上千人的组织，采用以少为多的原则，自底向上最大化自组织团队，核心是强调解耦并最小化团队，强调不要盲目扩展Scum规模。 |
|
DevOps |
开发运维一体化，除了采用敏捷文化、敏捷运作，核心是打通部门墙，再以工具链提升各方面协作效率。 |
第三章：敏捷转型的四步法。
第一步：培训。
1：自顶向下 VS 从底向上
2：内部教练 VS 外部咨询
3：传统模式 VS 敏捷模式
4：制度流程 VS 管理工具
第二步：调研&方案。
1，成立转型决策委员会
2，成立敏捷转型工作小组
3，健全需求管理机制
4，建立发布火车并设立准入标准。
5，推进持续集成。
6，推进自动化测试
7，调整工作环境
7，增加产品特性团队奖励机制。
8，建立基于度量的改进机制。
第三步：通过MoMoKo模型推进敏捷业务
1，影响地图：Why+Who+How+What
2，用户故事地图：用户+故事+功能集
3，看板：交付+透明+价值+拉动
第四步：通过复盘、回顾，持续改进。
第二部分：敏捷实践
第四章，敏捷转型案例
案例一：360评估项目交付（绩效考核项目）
痛点：项目周期短、时间紧、任务重、方案复杂、技术复杂等挑战因素。 如何在保质保量的前提下，更快速的交付项目，以及项目目标。
方案：使用Scrum框架，组建敏捷团队。对团队灌输敏捷价值观（承诺、勇气、专注、开放、尊重）。统一目标，追求团队目标一致性，打造团队愿景、使命、价值观。针对团队使用看板 管理日程事务做到 渗透式沟通。
关键词：
- Scrum：是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一。3个角色：PO、SM、DevTeam。三个工件：PB，SB，增量。5个事件：冲刺、计划会、每日站会、评审会、回顾会
- MVP（Minimum Viable Product）：用最小的成本和最有效的方式，把产品快速推向市场，然后基于市场的反馈快速迭代。
- DOR（Defintion of Ready）：准备好的定义。 对于什么样的情况才是准备好了，是做好方案是准备好了？还是做好计划算准备好了？形成团队共识。
- DOD（Definition of Done）：完成好的定义。对于什么样的情况算是完成了，是上线了算完成了吗？还是测试了算完成了？所有人形成统一认知。
- 发布计划：发布计划是指系统部署发布的排期计划。软件发布并非一迭代一个发布，发布也不与迭代强挂钩（发布计划>迭代计划）。
- 迭代计划：迭代计划是指规划当前迭代中所承载的目标、以及支持目标的任务、责任人、截止时间，计划工期等。
- 会议：迭代计划会、每日站会、迭代评审会、迭代回顾会。
- 自动化测试：频繁且快速的交付，对测试人员是一个极大的挑战。需要依靠自动化测试工具解放测试人员。
收益：通过使用敏捷项目管理模式，对产品进行滚动规划，利用MVP 持续获得用户反馈，不断优化用户体验，修复缺陷，及时调整产品方向对项目进行纠偏。对团队内部进行定期复盘，经验积累在早期，使得团队持续改进。最终获得了用户高度好评。
案例二：青龙看板实现高绩效（内部管理项目）-Kanban
痛点： 传统瀑布模式被诟病，主要体现在交付周期长、上线效果差、用户评价低，无法实现产品的持续交付与快速反馈。
方案：敏捷管理模式下使用看板（kanban），将从需求到产品全过程进行可视化管理。
- 从需求到产品4个阶段：IDEA（创意）、AGAIN（细化）、BACKLOG（方案）、NEXT（后续）
- 开发时期分为3个阶段：TODO（待办）、DOING（进行中） 、DONE（完成）
- 测试时期分为3个阶段：TODO（待测）、DOING（测试中）、DONE（完成）
- 上线时期分为3个阶段：DEPLOY(上线完成)、PENDING（挂起）、WASTE（垃圾站）
结合电子看板，可以清楚的看见流动时间、流动速度、流动效率，流动负载、流动分布。
收益： 完成需求个数提升69%，加班时间减少50%，团队通过持续交付。不断积累收获的喜悦，团队每个人都关系所负责的任务从想法到上线完成，再到运营以及用户的反馈。
案例三：京东ME打造移动快速交付能力实践（互联网项目）
痛点：传统的软件开发模式需要经历：需求调研、方案梳理、系统设计、开发、测试、部署、运维等过程。周期长、迭代速度慢。在面对移动办公应用行业快速发展，同时内部需求也非常 复杂，并且不断变化的场景下难以支撑。
方案：引入Scrum敏捷开发，解决需求频繁变动、开发周期越来越短的问题。
- 组建团队：以用户为中心组建特性团队。
- 制定团队精神团队工作协议：DoD、DoR。
- 产品敏捷：A，需求优先级（Pi）、验收标准（AC）
B，按照INVEST原则拆分需求： Idependent(独立的) 、Negotiable(便于沟通的)、Valuable(有价值的)、Estimable(可估计的)、Small(小的)、Testable(可测试的)
C，梳理明确的目标和愿景，并清晰的传递给团队。
- 业务敏捷：邀请业务方共同参与评审，向他们展示开发成果，并接收反馈。
- 工程敏捷：快速交付业务需求，工程敏捷实践包括：自动化测试、单元测试、TDD（测试驱动开发）、DDD（领域驱动开发）、持续集成。基于目标尽早发现问题，尽早解决问题。
收益：原先2个月才能交付的产品，并且不能保证符合用户需求。现在一周一个版本的交付，连续7个版本之后完成产品交付。有效提高了需求准确性、以及软件交付能力。
优化：1，规模化敏捷；
2，交付指标度量；
A：交付效率：需求交付周期、开发交付周期、交付吞吐量；
B：交付质量：线上缺陷密度、故障恢复时间、上线成功率；
C：交付能力：发布频率、发布前置时间。
案例四：京东购物APP千人敏捷案例（京东APP）
痛点：多团队协作，需求模块多，新需求多，单个需求上线时间要求短，版本时间间隔长。
方案：采用规模化敏捷，启动SAFe模型来管理产品，组建虚拟团队、建立发布系统、形成规则、开展方法论培训。
- 实践一：虚拟团队：跨越地域障碍组建产品、研发、测试、项目角色。形成标准化Scrum团队。
- 实践二：全员培训：
- SM培训：项目经理、部门领导，未来都有可能成为SM
- PO培训：团队的产品经理是PO的最佳人选。
- Scrum团队培训：全员参与培训，获得CSM认证。
- 实践三：需求拆解：
- 1，产品经理作为唯一入口接受需求。
- 2，按照不同场景分析问题和机会。
- 3，需求流转到业务开发部门进行分析和梳理。
- 4，对用户故事进行评估和计算，并梳理优先级。
- 实践四：多团队协作：各团队以版本发布为目标，打造团队节奏。进行关联需求的共同计划会，解决多个团队联调协作问题。（PI Planing）
- 实践五：版本列车（发布火车）：固定发布节奏，如同列车到点发车，赶不上就只能下一趟。
- 实践六：发布规范：《敏捷团队流程规范》
- 《角色及岗位职责》
- 《团队DoR&DoD标准》
- 《看板工作流标准》
- 《需求梳理会议流程标准》
- 《迭代计划会议流程标准》
- 《站立会议流程标准》
- 《回顾会议工作流程标准》
- 《评审会议工作流程标准》
- 缺：《项目立项标准流程》、《项目启动会标准流程》、《项目验收会标准流程》；另外组织还需要补充各个职能的流程规范（产品、项目、测试等）
- 实践七：迭代日历：团队事件（会议、发布等）形成公开日历，固定时间、固定地点，建立团队节奏感。
- 实践八：版本平台工具：
- 配置管理系统：实现系统配置和质量监督管理。（代码、文档）
- 打包管理系统：CI自动化打包平台，每日自动集成。提供完备的质量保证机制、研发预警机制。
- 灰度发布系统：实现系统灰度发布，与整体发布平台连接。
- 奔溃监控系统：数据监控实时报警，及时跟进效率，定义以邮件或IM方式自动通知。减少人工参与，减少资源使用。
收益：整体交付效率从1-1.5月发版一次，缩短2周一次的发版频率，项目交付效率提升41%，Bug减少58%，发布准确率达到100%。业务和版本完全解耦，质量得到保障，需求颗粒度更小，交付更快速。
经验：团队leader要经常反思，提防“假敏捷”的形式主义，不能提高效率，反而增加工作量。
案例五：企业信息化部SaaS化敏捷项目群实战（办公自动化项目）
痛点：IM、OA、ERP、HR多个产品线需要协同，业务复杂、需求多、利益相关者众多，沟通协调复杂、开销大、项目紧急任务重；
方案：明确解决方案、价值主张与定位；明确各系统之间的依赖关系，宣讲上下文；制定整体方案定位以及产品路线图；导入SAFe项目群管理模式，开展敏捷项目群管理，组织项目群增量计划会议（PI计划会）；
收益：通过价值风险管理（已解决、已承担、已接受、已减轻），大大降低了项目失败的风险，使得各阶段里程碑如期交付，并持续迭代刷新计划，各团队同步进度、问题和风险。
案例六：企业信息化部自动化测试实践
痛点：敏捷管理是采用小步快跑，分批发布必然需要依托强大的测试支撑，来保证产品质量。传统的手工测试，不足以满足业务需求。
方案：搭建自动化测试平台，解放测试资源
- TAAS自动化测试平台：专门为PC端和服务端打造的自动化测试平台。讲自动化测试用例、自动化场景执行、自动化测试报告发送串联，形成自动化回归闭环。
- JMAC移动云测平台：提供移动端测试完整的解决方案，按部署方式分为：服务端功能、客户端功能。包括：测试用例脚本维护、发布包管理、测试结果分析与发送、CI、远程真机
- JCPS性能压测平台：提供一个BS架构的轻量级压测平台简化压测流程，提升压测效率。
- SCAP代码扫码平台：基于静态代码检查提供的一套可行的解决方案，涉及：并发处理、流程控制、OOP规范、异常处理、性能、集合处理、命名规范、注释规范、复杂度及依赖检查
延伸：UI自动化测试、API自动化测试、自动化测试、自动化单元测试。
收益：获得指标中的问题管理与效率管理。单次运行节约人工测试50个时。
案例七：7FRESH技术研发中心持续集成实践（线下生鲜）
痛点：解决持续集成实验；包括：单个工程师的多代码之间集成；多个工程师之间的代码集成；应用与数据库以及中间件的集成；不同程序组装业务系统后的集成。
方案：通过建设CI/CD流水线，解决持续发布 与 持续集成问题包括：本地构建、集成构建、提测构建、发布构建。
|
构建类型 |
具体事件 |
需要的工具 |
|
本地构建 |
自动编译 |
通过Maven和JFrog 实现一键编译； |
|
单元测试 |
Junit单元测试框架实现对用例编写、用例执行和结果反馈。 Mockito模拟单元测试中的外部依赖，实现单元测试用例的独立 |
|
|
代码扫描 |
SonarLint、FindBugs、PMD等代码扫描插件支持本地扫描。 |
|
|
集成构建 |
事件触发 |
Git 或SVN 代码管理工具，通过设置WebHook能够在代码提交和等事件时通知集成服务器启动构建任务。 |
|
任务管理 |
使用Jenkins，来监听代码提交时间、构建任务管理和调度、构建结果反馈。 |
|
|
构建任务 |
自动编译和单元测试，同本地构建。 代码扫描，可以通过SonarQube这样的代码质量工具与Jenkins的集成来实现。 组件测试和单元测试一样，通过Uit和Mockito来支持 |
|
|
提测构建 |
事件触发 |
如果通过Jira 、禅道等工具来管理“送测”，可以由集成服务器来监听提测事件，从而触发提测构建。 |
|
构建任务 |
自动编译、单元测试和代码扫描通集成构建实现，任务管理通过Jenkins实现，该阶段自动化测试中的组件测试需要部暑并启动应用程序，因此以自动部署为前提（详见自动部署）：可以通过AP叫和GUI两种方式来测试单个服务组件或业务组件，API测试需要支持RPC协议和HTTP协议的自动化测试框架； |
|
|
自动部署 |
需要有配置文件、数据库脚木和部署脚本的集中管理工具。 采用Docker方式部署，则利用Dockerfile替代原来的部署脚本，并需要镜像管理工具的支持。 |
|
|
发布构建 |
事件触发 |
需要企业统一发布平台的“应用发布”事件通知集成服务器启动构建任务 |
|
构建任务 |
自动编译、单元测试、代码扫描、自动化测试（组件测试、集成测试和系统测试）都通过Jenkins等持续集成工具来实现任务调度和管理，该阶段执行的测试属于验收测试，需要部署并启动应用程序：集成测试是服务组件或业务组件通过业务或数据流程集成起来进行的测试：系统测试多通过GUI测试来实现，需要支持GUI测试的自动化测试框架（如支持WbUI的Selenium和支持Mobile UI的Appium等）。发布构建中的自动化测试步骤，除了被测系统外围依赖的服务需要应用Mock工具，其他依赖(如DB和中间件)都需要是实际存在的并且尽量与生 |
第三部分：敏捷流程
第五章，敏捷项目管理流程实例
5.1 概述
5.1.1 适用范围：本流程与规范适用于京东企业信息化部敏捷项目及与之类似的各种项目。
5.1.2 约定：重点介绍具有自身特点的敏捷实践流程与规范。
5.1.3 角色与职责
Scrum Master （SM）
- 内部推荐有影响力且对敏捷有热情的人员担任；
- 依据Scrum方法论，为取得更好的实施效果，不建议PO兼任SM；
- 负责辅导团队执行Scrum流程；
- 保护团队不受外部干扰；
产品负责人（Product Owner PO）
- 为产品规划远景；
- 为投资回报率（ROI）负责；
- 负责产品定义、编写PRD、设计原型、验收产品；
- 维护产品待办列表(Product Backlog）；
开发团队（Developers）
- 具有自组织、跨职能特点，包括：开发、测试、后端开发人员。
- 负责交付产品功能；
- 最适宜的规模：3~9人;
- 遵循 Definition of Done 来注入质量
项目经理（PM）
- 组织协调、推动解决项目问题，负责解决资源不足、外部依赖等问题。
- 定期向团队及利益干系人汇报项目进展、问题、风险。
- 对项目范围、成本、质量和价值进行监控。
- 推进及把控敏捷项目执行。
5.2 整体流程框架
5.3 流程描述
5.3.1 立项
|
目的： |
确定项目是否有实现的价值以及具备进入实施条件。 |
|
|
角色: |
业务方、Scrum团队以及评审专家组 |
|
|
输入: |
业务方原始需求、商业需求文档（BRD）、立项报告 |
|
|
输出： |
初步的产品待办列表、立项评审记录 |
|
|
执行： |
系统架构-->方案评审-->发布计划-->迭代计划-->Sprint0规划-->Product Backlog （优先级）-->立项评审 |
|
5.3.2 制定整体版本发布计划
|
目的： |
确立整体版本和迭代计划 |
|
角色： |
Scrum团队、业务方 |
|
输入： |
初步产品待办列表 |
|
输出： |
版本发布计划和迭代计划 |
|
时间： |
立项会结束后 |
|
执行： |
需求梳理-->用户故事地图-->业务流程图-->制定DoD |
5.3.3 项目执行（Scrum Guid）
|
事件 |
5.3.3.1 迭代计划会 |
5.3.3.2 每日站立会议 |
5.3.3.4 迭代开发 |
5.3.3.5需求梳理会 |
5.3.3.6 迭代评审会 |
5.3.3.7 迭代回顾会 |
|
目的 |
确定当轮迭代需要完成的任务及如何完成达成共识. |
同步信息，暴露问题和风险。 |
产生交付增量 |
为研发人员进行更为准确的任务拆分和迭代估算提供依据，为下一次迭代计划会议有效执行做好准备。 |
团队演示Sprint成果，获取业务方的反馈。 |
发现迭代过程中的问题，以持续改进。（总结经验教训） |
|
角色 |
Scrum 团队、 业务方代表 |
开发团队、SM |
Scrum 团队 |
Scrum 团队 |
Scrum 团队、项目经理、业务方、相关利益干系人。 |
Scrum 团队、项目经理 |
|
时间 |
每一轮迭代的第一天 |
每天固定时间 |
计划会议结束之后 |
推荐迭代中期进行（Any Time） |
迭代的最后一天 |
评审会后，下个迭代计划之前 |
|
输入 |
Product Backlog |
更新后的看板 |
Product Backlog、 Sprint Backlog |
调整前的Product Backlog、 新的需求信息 |
本轮迭代可以演示的成果。 |
改进建议 |
|
输出 |
Sprint Backlog |
待跟进实现 |
产品增量（潜在交付物、代码、文档、用户手册） |
经过更新的Product Backlog |
业务方、相关利益干系人和PO的反馈。 |
回顾会议纪要 改进计划（清单） |
|
执行 |
|
|
|
I think every User Story ，Must be have Ac。 |
|
|
5.3.4 结项
|
目的： |
按部门的规范结束项目 |
|
角色： |
项目经理、PO、业务方 |
|
输入： |
《项目总结报告》、《项目结申请》 |
|
输出： |
结项审批意见 |
|
时间： |
团队和业务方约定结项日期 |
|
执行： |
核心功能验证并通过->未完成、非核心、待优化项批准运维 或 新立项目方式进行开发-->按《结项管理规范》执行 |
5.4 需求管理
- 需求条目化： 每个用户故事需要有规范的格式
- 用户故事（US）：
- 三要素（角色、活动、价值），举例：作为一名<角色>，我想<功能or目标>，这样就可以<商业价值or收益>。
- 3C：卡片（Card）、对话（Conversation）、确认（Confirmation）
- 验收标准（AC）：假设/假定（Given）上下文、前置条件，当（When）执行某些事件、行动或操作，那么（Then）获得可观察到的结果。
- 维护产品待办列表：根据价值排列需求优先级，需要符合DEEP 原则。
- Detailed Appropriately （详略得当）
- Estimated （做过估算的）
- Emergent（涌现的）
- Prioritized （排列优先级的）
5.5 变更管理
为了保持迭代节奏，原则上是不允许在当前的迭代中加入额外需求，需求变更需要依据以下原则进行调整，同时遵守项目变更原则。
- 质量缺陷类的需求（线上bug）。
- 公司战略级紧急需求。
- 与系统运行效率相关的非紧急需求
- 与用户体验相关的非紧急需求
- 普通的新功能需求，调整至后续迭代（即：加入新功能的需求，优先级被修改，需要拿走同等故事点需求）
5.6 项目监控
- 早会：同步风险、问题、工作进展。
- 燃尽图：剩余工时、进度。
- Sprint Backlog： 任务状态
- 会议：定期举行利益者相关汇报会议。
- 项目经理监督：目标、范围、成本、质量、进度、风险
- 发布计划：持续交付、风险汇报。
- 流程：流程约束与监督 ，如：变更流程
- 看板：数据监控看板以及报表，进行团队状态播报与汇报
5.7 敏捷成熟度评估
成熟度模型： 有意识的（一级）< 有实践的（二级） < 熟练的（三级） < 可靠的（四级） < 优化的 （五级）
成熟度评估维度： 每个季度执行一次评估，自评，互评。
5.8 敏捷项目度量参考维度
过程维度（举例）：
- 所有需求录入项目管理系统的完整度（描述、优先级、验收标准）
- 各项会议前、中、后 的准备与跟踪。
- 用户故事的颗粒度合理拆分，建议3天
- 任务颗粒度颗粒拆分，建议8小时
- 日事日毕，每日更新任务状态
- 持续集成，代码扫描发现的问题，bug，以及评价修复时间
- 自动化测试比例、单元测试覆盖率
- 流程合规度，是否按时间盒执行，没有超时
- 团队迭代速度。
结果维度（举例）：
- 平均上线时间
- 需求平均前置时间
- 开发平均前置时间
- 项目目标达成度
- 上线后的问题缺陷数 或故障次数
- 上线问题平均修复时间
第六章 敏捷优秀实践
一、产品研发流程
|
阶段 |
创意漏斗 |
探索分析 |
产品规划 |
迭代交付 |
运营&体验优化 |
|
目的 |
过滤创意，确定战略方向，进行组合管理； |
价值探索，确保开发有价值的需求； |
从用户角度对需求条目进行描述（用户故事），规划最小可行产品（MVP）及多个迭代的发布计划； |
||
|
角色 |
业务部门利益相关者、业务代表、产品负责人 |
业务代表、真实用户、产品负责人、开发团队、Scrum Master； |
业务代表、真实用户、产品负责人、开发团队、Scrum Master； |
||
|
时间 |
进行周期性会议讨论和决策，如每周或每两周一次； |
1～2周； |
1周以内； |
||
|
输入 |
点子、用户需求、运维反馈、运营数据、业务部门战略规划； |
BRD |
产品愿景、产品路线图、产品特性清单； |
||
|
输出 |
战略主题、产品组合看板、BRD。 |
产品愿景、产品路线图、产品特性清单（FeatureList）。 |
用户故事、产品待办列表、部分详细用户故事的PRD、迭代计划、发布计划。 |
||
|
过程 |
|
|
|
|
|
|
说明 |
无论是ToB产品还是ToC产品，首先都会对众多创意进行过滤，确定高优先级、高价值的产品方向。如果涉及多个业务线，还需要规划在有限的可承担的成本和人力投入下，各业务线业务需求的投入百分比，进行组合管理。 |
利用同理心，站在用户的角度探索用户，挖掘用户的痛点和需求，考虑用户体验，构思解决方案，并对其进行验证。 |
将需求条目化，并从用户角度对条目进行描述（用户故事），按场景组织用户故事，规划最小可行产品（Minimum Viable Product，MVP）及多个迭代的发布计划。 |
以迭代的方式进行细粒度的迭代规划、开发、验证、用户体验测试，以及按业务需要正式上线。 |
运营推广，监控生产环境的实际运行效果，分析运营数据，根据用户反馈优化用户体验，持续打磨产品。 |
电梯演讲（Elevator Pitch）的格式描述愿景，具体如下：
为了［目标用户］，他们的［需要和机会］，这个［产品名称］，是一个［产品类型］，它可以［关键优点，使用理由］，而不像［同类竞争者］，我们的产品［差异化声明］
感悟：
对于《京东敏捷实践指南》一书我给出：⭐⭐⭐⭐⭐ 五颗星。
这本书基本把敏捷常见的流程、工具、框架都有介绍到位，是一本可以直接拿来实操的书，我所负责软件项目部一直把时间都花在了3355的建设上，但是3355只是Scrum框架最基础的模样，足够简单，但也不够完善。我们公司虽然将职能分成了 “产品设计部”、“软件项目部”、“软件研发部”、“软件质量部”、“IT运维部”这五个部门，但是花时间建设的一直是软件项目部，所有心思都变成了， 怎么开好四个会议：“计划会、每日站会、迭代评审会、回顾会”。所有的工作基本都是以项目经理视角，为了开好这几个会议而去工作。然后这是短视的，开篇有讲这本书在第一定程度上补全了我对敏捷的认知。我觉得至少在前段“产品设计部” 和 后段的“软件质量部” 给我打开了视野，也做出了改变。
1，产品经理的改变： 问题清单，用户故事，产品路线图，原型设计。
问题清单：
之前： 无论是产品经理，还是项目经理，又或者是软件的实施专员，只要收集到了用户提出的问题也好，需求也罢就登记在禅道中。禅道中的需求一直在积压，这里用户提出的有些是问题，要立即解决。有些是需求，需要经过评审。 但是到底是问题，还是需求我们就没有把这个规范给建立起来。
之后： 我们利用在线文档，建立了一个用户问题清单，所有提出的问题、需求、异常 都经过问题清单登记，然后经过产品经理与项经理评审之后再决定是问题 或 需求、Bug。再走对应的流程，这一份文件清单的建立，将于用户对接的需求替换成了问题 。而问题转换为需求，登记在问题清单的，不一定要做，也不一定知道怎么做。而登记在禅道的，就是一定要做，而且方案已经经过评审。
用户故事：
之前：一直以来我们并没有理解 用户故事的概念，传统的认为就是需求，而需求也没有统一的格式，长的可能连方案带图片 几百字，短的也有可能就一句话。 并且故事没有估算故事点。更没有根据故事点，计算团队速率。除此之外，还有一个问题是，需求从来只写了要做什么，却没有写上不要做什么， 导致一直以来迭代都有延期的情况。
之后：按照<角色>、<目标>、<价值> 固定格式来写用户故事，每次迭代中期有一次 故事点评估会议，根据故事点数，以及团队迭代速率限定每次迭代做多少用故事。另外以AC的模式写清楚验收标准，迭代延期得到一定程度的控制。
产品路线图：
之前：经常被用户告知某某需求需要紧急优先，导致插入临时任务造成迭代延期。
之后： 产品路线图根据用户故事（故事点），以及团队迭代速率。排期“迭代执行计划”每次评审会后与用户一道更新。使得团队保持固定节奏，同时也能用户明白“产能有限”插入需求就要移走需求的道理。并且，也可以让团队内部人员知晓要提前为哪些技术做预研。
原型设计：
之前：原型设计，没有形成统一设计语言、设计规范，甚至没有统一工具。
之后：统一工具，统一规范，每次原型变更需要经过内部评审，用户评审后，放在禅道需求当中，不在只设计当前迭代要开发的内容，让产品部可以独立工作。
2，项目经理的改变：DoD、项目日历、发布计划、迭代目标、会议纪要（邮件）
DoD：
之前：团队内部对完成的定义，并不一致。 开发人员任务开发完成就算完成了，测试人员任务发布就算完成了，项目经理任务迭代验收单签署了就算完了。
之后：形成团队DoD之后统一认为，一个需求发布了才算完成。
项目日历：
之前：多个项目团队的会议以及发布时间，信息不方便查询，组织内也没做到透明。
之后：建立项目日历，各个团队的信息，通过日历直接查询。作为项目部经理，我也可以选择时间参加任意团队的会议。
发布计划：
之前：没有制定发布计划，迭代结束日期就是发布日期，迭代与发布是强耦合。
之后：迭代与发布解耦，需求完成通过测试，即可发布。制定好发布计划，初期按“发布火车” 固定每周2、4发布。
迭代目标：
之前：只有项目目标，没有迭代目标。以致于这个迭代怎么算完成了，怎么样才能获得用户认可并没有统一认知，也没有形成团队默契。
之后：每个迭代必须制定迭代目标，每日站会强调，昨天我为目标搞定了什么，什么阻碍了迭代目标。
会议纪要（邮件）：
之前：有会议计划，但是没有将会议纪要转换成 待办清单，以及分发业务部门要承担的部分 和 IT要承担的部分。会议也没有共同签字，甚至都没有以邮件形式群发。
之后：迭代计划会，评审会。都有明确的会议纪要，形成待办清单，虽然没有会签但是 每次邮件都会发给项目干系人做为沟通管理。
3，开发人员的改变: 单元测试，CodeReView
单元测试：
之前：单元测试一直很薄弱，开发人员依赖测试做把关，测试人员有碍于对业务的理解，漏测时有发生。
之后：部分开发工程师，逐步建立单元测试的理念。
CodeReView：
之前： 代码审查，没有固定周期，也没有通过代码审查进行技能教练。
之后：逐步建立代码审查规范， 部分项目团队有固定周期。
4，测试人员的改变：自动化测试
自动化测试
之前：无自动化测试。依赖纯手工检测。
之后：建立测试用例评审制度，逐步引入DevOps测试工具。
5，运维人员的改变：无
《京东敏捷实践指南》作为我学习敏捷体系依赖，我认为最具可执行的一本书，作者理论知识很扎实，而且这些理论也付出了实际行动的验证。在此本书的阅读当中，如果让我再这本书选一初对我改变最大的地方，我想就是 故事点+产品路线图。 这个工具成功的让我后续一个项目中将混乱的一百多个需求，在三天内，规划清楚要跑多少迭代，哪些需求在哪几个迭代完成，能让我和用户在一个频道上沟通，成功的解除了那次项目危机（如图）。
惭愧的是虽然做出了如上改变，但是大约半年后续这些改变由于缺乏监督，取得的成果在逐步退滑，这也是管理没跟上的后果：僵化，优化，固化。
道阻且长，行则将至！至此，就写到这里。
标签：需求,读后感,迭代,用户,测试,敏捷,京东,团队 From： https://www.cnblogs.com/demon28/p/17579296.html