敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

敏捷开发宣言:

  • 个体和交互胜过过程和工具
  • 可工作的软件胜过面面俱到的文档
  • 客户协作胜过合同谈判
  • 响应变化胜过遵循计划

敏捷开发流程:

image

作者提出一种落地范式:影响地图->故事地图->看板 image

2.影响地图

为什么

  • 业务职能与开发职能之间交流决策的隔阂 image
  • 业务目标与功能之间映射关系的模糊和不一致

image

具体内容

image

  • WHY - 就是要实现的业务目标或要解决客户的核心问题是什么
    • SMART(具体、可衡量、可达成、相关性、时间性),如”增加付费用户的比例” => “三个月内付费用户比例从1%增加到1.5%”
  • WHO － 就是可以通过影响谁的行为来实现目标，或消除实现目标的阻碍
    • 主要用户（产品的直接使用者）
    • 次要用户（安装和维护人员）
    • 产品关系人(采购的决策者、竞争对手)
  • HOW - 就是怎样影响角色的行为，来达成目标；这里既包含产生促进目标实现的正面行为，也包含消除阻碍目标实现的负面行为

  • WHAT - 就是要交付什么产品功能或服务产生希望的影响。它决定了产品的范围

  • 功能假设 - 假设通过设想的功能能对角色产生期望的影响
  • 影响假设 - 假设对角色产生这样的影响会促进目标的实现

举例

image

3.故事地图

  • 根据影响地图确定要开发的业务流
  • 确定优先级
  • 并按照优先级的顺序，整理成为一个个的迭代
  • 然后把一个个的迭代拆成一个个可验收的故事卡

需求拆分为故事卡的原则是:

  • 故事卡是可以独立验收的场景
  • 故事卡包含的点数应该尽量小,如果超过了应该重新拆分该故事卡

4.看板

MASTER把当前Sprint中所有的故事卡贴到故事墙上，等待开发人员的开发。故事墙的模板为: image

  • 分析 － 起始点
  • 等待开发 - 开发人员和SE确认了需求，明确了做什么以及怎么做以后，把故事卡从分析阶段移到等待开发
  • 开发中 - 开发人员一次只开发一张故事卡，把相应开发的那张卡移植到开发中
  • 阻塞 - 如果开发过程中，由于配合的原因，导致故事卡无法继续走下去，则把该卡移动到阻塞阶段
  • 开发完成 - 如果开发完成，并向MASTER SHOW CASE以后，开发人员吧故事卡移植到等待测试
  • 等待测试 - 测试人员看到等待测试中有卡以后，对故事卡进行测试，测试完成以后把卡移到测试完成阶段，如果测试有问题，则移出该卡到开发中阶段
  • 测试完成 - 本张卡的生命周期结束

当然，每个Sprint都有一个总结会议，回顾本次开发过程、梳理好与不好的点，并针对不好的点提出解决方案，以便在下一个Sprint改进.

5.综述

敏捷是一柄双刃剑，用的好能极大的提升开发效率，适应需求的变化; 用的不好则会导致项目的混乱。 敏捷开发提倡一个迭代80%以上的时间都在编程，几乎没有设计的阶段，因为我们必须保证我们的代码的质量。因此在整个迭代过程中我们要持续做到以下几个方面: image