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

敏捷开发宣言:

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

敏捷开发流程:

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