敏捷开发落地新范式(MOMOKO)
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
敏捷开发宣言:
- 个体和交互胜过过程和工具
- 可工作的软件胜过面面俱到的文档
- 客户协作胜过合同谈判
- 响应变化胜过遵循计划
敏捷开发流程:
作者提出一种落地范式:影响地图->故事地图->看板
2.影响地图
为什么
- 业务职能与开发职能之间交流决策的隔阂
- 业务目标与功能之间映射关系的模糊和不一致
具体内容
- WHY - 就是要实现的业务目标或要解决客户的核心问题是什么
- SMART(具体、可衡量、可达成、相关性、时间性),如”增加付费用户的比例” => “三个月内付费用户比例从1%增加到1.5%”
- WHO - 就是可以通过影响谁的行为来实现目标,或消除实现目标的阻碍
- 主要用户(产品的直接使用者)
- 次要用户(安装和维护人员)
- 产品关系人(采购的决策者、竞争对手)
- HOW - 就是怎样影响角色的行为,来达成目标;这里既包含产生促进目标实现的正面行为,也包含消除阻碍目标实现的负面行为
-
WHAT - 就是要交付什么产品功能或服务产生希望的影响。它决定了产品的范围
- 功能假设 - 假设通过设想的功能能对角色产生期望的影响
- 影响假设 - 假设对角色产生这样的影响会促进目标的实现
举例
3.故事地图
- 根据影响地图确定要开发的业务流
- 确定优先级
- 并按照优先级的顺序,整理成为一个个的迭代
- 然后把一个个的迭代拆成一个个可验收的故事卡
需求拆分为故事卡的原则是:
- 故事卡是可以独立验收的场景
- 故事卡包含的点数应该尽量小,如果超过了应该重新拆分该故事卡
4.看板
MASTER把当前Sprint中所有的故事卡贴到故事墙上,等待开发人员的开发。故事墙的模板为:
- 分析 - 起始点
- 等待开发 - 开发人员和SE确认了需求,明确了做什么以及怎么做以后,把故事卡从分析阶段移到等待开发
- 开发中 - 开发人员一次只开发一张故事卡,把相应开发的那张卡移植到开发中
- 阻塞 - 如果开发过程中,由于配合的原因,导致故事卡无法继续走下去,则把该卡移动到阻塞阶段
- 开发完成 - 如果开发完成,并向MASTER SHOW CASE以后,开发人员吧故事卡移植到等待测试
- 等待测试 - 测试人员看到等待测试中有卡以后,对故事卡进行测试,测试完成以后把卡移到测试完成阶段,如果测试有问题,则移出该卡到开发中阶段
- 测试完成 - 本张卡的生命周期结束
当然,每个Sprint都有一个总结会议,回顾本次开发过程、梳理好与不好的点,并针对不好的点提出解决方案,以便在下一个Sprint改进.
5.综述
敏捷是一柄双刃剑,用的好能极大的提升开发效率,适应需求的变化; 用的不好则会导致项目的混乱。
敏捷开发提倡一个迭代80%以上的时间都在编程,几乎没有设计的阶段,因为我们必须保证我们的代码的质量。因此在整个迭代过程中我们要持续做到以下几个方面: