敏捷开发流程的8个步骤 敏捷开发什么意思


笔者根据自己对敏捷开发Scrum的理解,总结了敏捷开发从开始到结束的流程以及其适用的场景 。
一、敏捷开发到底是什么 很难用一两句话说清楚敏捷到底是什么,也许因为它只是一套松散的框架,有原则却无具体方法,1000个项目可能有1000种敏捷的工作方式 。敏捷只有在实践中才有意义,一旦脱离实际去学习就变得近乎玄幻 。
最常被讨论的敏捷框架有3套:Scrum、Agile、看板 。涉及到软件开发,尤其是面向C端Scrum和Agile更常见,看板方法擅长把繁杂琐碎的工作一目了然,例如客户支持这类事务性工作 。
谈论Scrum不得不提到PDCA循环(如下图),这是一种擅长探索和创造的工作 方式,我认为Scrum正是围绕PDCA循环方式衍生出来的的一系列理念、原则和实践(如backlog、sprint、user story) 。它不是方法论,更不是公式,也有一些方法体系,但可供参考却不该照搬,不同的项目可能需要非常不同但都可称为Scrum的工作流程 。
(PDCA循环)
如果只用一句话描述Scrum,我认为是:充分接纳前景的不确定性,采取探索式前进,以为客户实现价值为最终目的的开发方法 。重探索轻预测,这是和线性开发方式的本质区别 。
Scrum步骤由一个接一个Sprin(迭代)组成,因此新手想要快速上手Scrum的话,也许最该学习的是一个Sprint(迭代)从哪里开始和结束,如下:
1. 拟定和评估待办事项清单 待办事项即backlog,我的团队叫需求列表/需求池,指可能要开发的功能列表 。待办事项有时来自需求方,但更应该来自产品经理的远见和洞察 。所有被提出的事项(无论是否看起来有价值)都不妨先放入清单,再进行维护 。维护包括:
①评估需求价值、工期和紧急程度,去伪存真
②值得做的真需求排定优先级
③追踪处理进度 。
如何维护一个健康的backlog涉及细节很多,不妨参阅我的另一篇文章《如何维护健康的需求池》
虽然我的团队习惯把待办事项称为“需求”,但我自己更喜欢《Scrum精髓》中的叫法——”价值“或者“特性” 。”需求”在团队沟通中多指运营方而非用户的需求,暗示产品对运营负责,而且暗示了团队能预测产品的成功,这更符合瀑布式而非敏捷式方法;“价值”的叫法突出了敏捷的价值导向,为实现用户价值每个角色都负有不可推卸的的责任 。“特性”的叫法则突出了敏捷的探索精神,承认当前在做的未必是用户真正需要的,只有检测后才有定论 。“价值”和“特性”都更能体现敏捷原则 。
2. 冲刺启动会 在上一步厘清需求优先级后,团队所有人(至少所有角色)坐下来规划下个迭代要做的需求,也就是消化需求表里优先级最高的需求 。实际工作中,一些优先级不太高但是简单易做的需求也会见缝插针安排到下个迭代中,以求达到最大工作量 。

猜你喜欢