敏捷开发的管理方法与模型
敏捷开发的管理方法与模型
管理方法分两种：
- KanBan
- Scrum
KanBan（以下称看板）
看板是丰田公司提出的一个概念，用于制造业生产。
本质
后道工序需要时，通过看板(可视化卡片)向前道工序发出信号，前道工序只有收到信号时，才会进行工作，生产信号由下游控制，下游拉动上游，因为最下游是业务，所以也可以理解业务拉动生产。
特点
- 控制库存
- 灵活响应
- 加速流动
- 促进改善
运用至软件工程
首先建立看板满足这个要求：
- 可视化价值流动(业务增量可视化)
- 显示化流程规则(直观地展现流程规则)
- 控制在制品数量 其次运作看板需要满足一下两个要求：
- 管理工作项流动
- 建立反馈，持续改进 以下是各项实践
可视化价值流动
要建立起团队的工作流，并将其分解成关键的几个状态，看板中的每一列都要与之匹配，当工作开启时，每一项工作分解成一个蓝色的卡片，每张卡片对应绑定一个工作者，并给予其对应的状态，将其放到对应列中，卡片流动方向从左到右。 在这一实践中，每一项卡片代表一个增量，卡片的流动使得工作流可见，团队可以观察工作流，以及谁在处理什么，以及可从途中看见卡片流通过程的瓶颈和问题，
显示化流程规则
这一实践是指明确增量流转和团队协作的规则并达成共识。也就是规定在什么条件下卡片进入下一环节，何种类型的工作使用何种颜色的卡片，进入哪个泳道，采用什么样的优先级，以及以什么样的节奏接受新的工作、更新看板以及对外发布。这些构成团队改进的一个基线。
控制在制品数量
在制品数量是指每个状态(泳道)下，正在进行的卡片数量，控制在制品数量就是控制每个状态下卡片数量必须小于这数量，只有这个条件满足，才可以从上游拉入新一个卡片。 在制品数量的控制在于控制每个状态并行的工作数量，确保在保证数量的同时保证效率，有效加速了业务增量的流动，对产品开发的敏捷性至关重要。
管理工作项流动
包含三个实践：
- 就绪队列填充活动
- 看板站会
- 发布评审 第一个实践就是开始前的卡片规划与整理，第二个实践是每日的工作总结以及工作内容发布，重点关注增量流通时发生的问题和阻碍，并优先解决这些问题或提出相应的跟踪方案。最后一个实践是决定上线或者发布那些需求，以及相关发布策略等增量发布实践。
建立反馈，持续改进
实践注重两点：
- 流动是否顺畅
- 质量问题 针对这两点制作改进方案，并且持续跟踪。
不同角色在此工作流的看法
- PM以上的角色 关注每天的需求交付和交付数量、总体的吞吐量，增量交付是否平滑以及控制需求的导入节奏
- Leader 关注增量的流动、流动过程中的阻塞和瓶颈以及解决方案
- 团队个各成员 关注如何指定计划、更新增量状态以及标识阻塞和风险
分层架构
基于产品研发可将看板分解成产品看板和团队看板，产品看板可直观看出各个团队的工作状态，管理产品的流动。
度量指标以及度量方法
主要指标：
- 交付时间
- 吞吐量
- FE流动效率
- 准时交付率
- 流动性&波动性 主要方法：
- 价值流图
- 累积流图
- 控制图
- 直方图
Scrum
本质
以小团队合作的方式去应对当下的业务快速迭代的问题，所以其重点也是放在迭代上面。
特点
- 关注当下
- 放权(自组织，自管理)
- 面对面沟通，提高沟通效率
整体流程
- 将需求放到产品迭代清单
- 选择适合的需求从产品迭代清单转移至迭代待办列表
- 然后开始2-4周的迭代开发
- 开发其中的每一天进行每日站会
- 迭代结束之后提交一个潜在的可交付增量
框架结构
- 角色
- 产品负责人
- Master
- 开发团队
- 要素
- 产品待办列表
- 需求待办列表
- 增量
- 事件
- 需求开发
- 需求计划会议
- 每日站会
- 增量评审
- 开发回顾
- 价值观
- 承诺
- 勇气
- 专注
- 开放
- 尊重
角色
产品负责人
该职位只能由一人担任，负责管理产品待办表并保证客户和团队保持透明，对产品待办列表事项进行优先级排序。与团队估算工作量，对于项目负有总体责任
Master
监督团队遵守总体规定以及价值观，帮助团队使用以及理解规定与价值观，保护团队不受外界干扰，消除团队在工作时的障碍，辅助产品负责人，在这些基础上不要管理团队。
团队
团队大小：5-9人 多功能团队，且保证全体人员加入整体开发工作，团队成员自我管理且没有职位之分，不组建子团队，成员更替只在迭代之间进行，最佳方式在发布之间进行。
要素
产品待办列表
产品需求变更的唯一来源，需要持续更新，每项按照优先级排序，排序越高越具体，每个产品对应一个且与团队数量无关。
需求待办列表
是产品待办列表的子集，显示要完成事项的具体细节，根据实际情况增加或者移除
增量
这个类似与一张总结，用于回顾整个开发流程中所产生的增量开发，其记录的是已完成且可用的开发增量。
开发流程
首先组建迭代计划会议，决定整体的开发任务以及开发过程中的一些规定，然后将其形成一个迭代合约，开始迭代时，每天要进行站会，总结和沟通任务进度并回顾之前的开发过程的缺陷，迭代完成之后交由评审全体参与，包括客户。整个迭代结束。