2.价值探索环
【共创分析方法】1.量化式影响地图 2.用户旅行地图
【精炼工作原则】1.分解并快速试错 2.一次只验证一点 3.允许失败
【共创与精炼常用方案】1.装饰窗方法 2.最小可行特性法 3.特区法 4.定向探索法 5.稻草人法 6.最小可行产品法
【注意事项】：1.多角色参与探索 2.存在往复过程 3.风险不是等价的 4.上帝视角 5.唯数字论 6.蛇行效应
3.快速验证环
【工作原则】1.质量内建 2.消除等待 3.重复事物自动化 4.监测一切
4.组织文化
【安全、信任与持续改善】1.失败是安全的 2.相互信任 3.持续改善
【文化塑造】【行动原则】【度量原则】【持续改进】
5.软件系统架构
【持续交付架构要求】
为测试而设计<br>
为部署而设计<br>
为监控而设计<br>
为扩展而设计<br>
为失效而设计
【系统拆分原则】
作为系统的一部分
高内聚、低耦合
整个系统易于构建与测试
使团队成员之间的沟通协作更顺畅
架构改造实施模式
拆迁者模式：一次性重写所有代码
绞杀者模式：不改变或少改变原有遗留系统，通过增加新的服务来不断替代遗留系统功能
修缮者模式：通过迭代，对原有遗留系统进行逐步改造
6.业务需求协作管理
产品生命周期
概念阶段：清楚回答市场机会，客户需求的紧迫性、企业自身的竞争优势、产品的可行性以及自身产品团队能力等问题
孵化阶段：考察产品核心功能的完善度、满足典型目标用户的核心诉求程度
验证阶段：关注最小核心功能集的用户体验、早期用户的反馈、盈利模式、以及产研核心团队稳定性与加大资源投入的可行性
运营阶段：关注市场环境变化、客户泛化需求的存在性，以及投入产出比
业务退市阶段：不满足企业预期
每个周期分为准备期、交付期
准备期
1.目标阐述与理解
2.业务领域角色与流程识别，以及解决方案的探索
3.重大风险识别与验证
4.精炼并达成最小可行方案公示
5.评估与计划
需求拆分
收益
1.建立共识、协调工作
2.小批量交付、加速价值流动
3.低成本拥抱变化
4.多次集成、及时反馈质量
5.鼓舞团队士气
需求来源
1.业务人员提出的业务功能需求
2.为了保障业务需求的实现与运行而必须满足的非业务功能需求
3.符合安全合规性而产生的安全开发需求
1.从原始需求列表中选出的带实现需求
2.需求细化过程中新发现的需求
3.已知且需要修复的线上生产系统缺陷
4.线上技术运营需求
5.前期预研需求
6.技术债需求
7.辅助测试需求
拆分方法
1.路径拆分法（功能路径）
2.按接触点拆分（页面显示或操作点）
3.按数据类型或格式拆分（垂直功能）
4.按规则拆分（先基础/后完善性）
5.按探索路径拆分
需求管理工具
1.用户故事地图
2.用户故事树
3.依赖关系图
4.数字化平台
团队管理方法/工具
1.团队共享日历
2.团队回顾
3.可视化故事墙
4.明确“完成”的定义
5.持续集成
6.故事验证
8.利于集成的分支策略
分类
1.集中式版本控制系统（SVN）
2.分布式版本控制系统（GIT）
基本概念
代码仓库（codebase）、分支（branch）、主干（master）、<br>版本号（revision）、标签（tag）、头（head）、合入（merge）、冲突（conflict）
常见分支开发模式
1.主干开发、主干发布
2.主干开发、分支发布
3.分支开发、主干发布
分支模式
1.“三驾马车”分支模式
开发分支、预发布分支、发布分支
2.Gitflow分支模式
1.Master分支是正式版本的发布分支
2.Release分支是用于质量打磨的预发布分支。质量达标就可以合入Master分支和Develop分支
3.Develop分支是新功能进行集成的分支
4.Feature分支是为了开发某一功能特性。来自Develop分支，合入Develop分支
5.Hotfix分支是严重缺陷分支，来自Master分支，合入Master、Develop分支
3.GitHubFlow分支模式步骤<br>
1)从Master上创建一个新的分支，以特性或缺陷的编号命名改分支<br>2)开发在新建的分支上提交代码<br>3)功能开发完成，并自测通过，创建Pull Request（简称PR）<br>4)其他开发人员对这个PR进行审查，确认质量合格后合入Master
版本发布模式
1.项目制发布模式：预先确定某一版本所需包含的功能特性数量（没有明确时间）
2.发布火车模式：为每条产品线都制订好每个发布周期（有严格时间）
3.城际快线模式：固定三要素中的两个时间和质量维度，且时间周期相对较短。
本书提倡的策略：“主干开发”或高频的GitHubFlow分支模式
原则：<br>1.分支越少越好，最好只有一条主干<br>2.分支生产周期越短越好，最好在3天以内<br>3.在业务允许的前提下，发布周期越短越好
