如何理解敏捷开发

2018-06-28 15:02:00
日事清软件
转贴:
简书
165

为什么要敏捷开发

“没有人喜欢敏捷,但我们不得不敏捷。就像没有人喜欢工作,但你必须工作。”这是我经常用来调侃敏捷的一句话。

试想一下,拿到一份完整详尽的需求文档,逐个功能Coding,测试部署上线。不需要再次确认需求,不会有人打断思路。没有需求更改,只要自己不犯错,不存在推倒重来这才是大部分开发人员最舒服的工作方式吧,简直太完美了。但它很像瀑布,一点都不敏捷。

既然我们喜欢的工作方式是传统的、瀑布的,为什么要敏捷?这还不都是市场环境逼的。今天的市场向我们提出了三个问题:

01如何做出真正满足用户需求的产品?

我不确定这世上是否有人可以做到,他所做出的全部决定都是对的。但绝大多数人是无法一次性做出真正满足用户需求的产品的。我们无法预测未来,我们必须通过一次次的测试,去寻找用户需要的产品是什么?想要更快地获得好的产品,必须迅速将产品推向市场,快速试验,避免走弯路。

02如何满足不断变化的用户需求?

今天所有的事情的都在快速变化,用户的需求也在变化。毫不夸张地说,我们正在全力开发的一些功能,当它们上线的时候,我们的用户已经不再需要了。我们没有办法让一切不变,我们只能选择去拥抱变化。

03如何同时满足不同层次用户的需求?

过去我们的产品会遵循产品生命周期,早期追求新奇的尝鲜者,中期普通大众,后期落后者。今天,产品的生命周期变化非常地快,我们可能会同时面对尝鲜者、普通大众、落后者,不同的用户类型的需求是不一样的,你如何满足他们?我们必须快速响应,没法快速响应,就没法留住用户,没有用户就没有一切。

迅速将产品推向市场,拥抱变化、快速响应。今天的市场向所有的从业者提出了一个要求:拥有应对快速变化的需求的软件开发能力。而敏捷就是赋予团队应对快速变化的需求的软件开发能力的方法,而这就是敏捷流行的原因。

什么是敏捷开发

敏捷绝非某一种特定的开发方法,它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。敏捷相信,只要符合这两份文档的开发方法,就能让开发团队拥有应对快速变化需求的能力,这样的开发方法都叫做敏捷开发方法。

最流行的敏捷开发方式是什么

敏捷开发的方法有很多:ASD、AUP、DSDM、XP、FDD、Kanban、RAD、Scrum。目前国内最流行的应属Scrum。

Scrum本意是指橄榄球运动中的“带球过人”,它可以解决非常复杂的项目,并且能高效并创造性地交付高价值的产品。Scrum包含3个角色、3个工件、5个价值观、5个事件(详情https://www.scrum.org/)。

相比其他敏捷方法,Scrum既不简单又不复杂。它有完善的指南,你可以按照指南,轻易在团队内推广尝试。但想要实践好Scrum,又需要很好的技巧。这种易上手难精通的方法,特别适合培训机构。所以近几年,关于Scrum的培训机构遍地都是。可以说,在Scrum流行这件事上,这些培训机构做了很大的贡献。

如何实施Scrum

在团队中实施敏捷开发是一个很有挑战性的工作,尤其是Scrum这种描述比较详细、有很多规则的方法。

如果你打算把所有人召集到一起,宣布我们要实施敏捷开发Scrum,然后就照着Scrum的描述开发方法直接实施,那么,你离失败不远了。想要实施好Scrum,你必须一步步来,一点一点改变团队的习惯,当一项新制度已经变成本能之后,再推行下一项制度。

>>>>第一步,先把团队的开发任务可视化。

你可以用一块白板,让团队成员把所有的开发任务都用便签写好放上去,也可以找一个专业的看板工具。硬广,我推荐日事清,因为这是我做的产品(www.rishiqing.com)。当所有任务都在看板上,尽收眼底,那种感觉还是很棒的。团队中每个人的工作都会被所有人看到,会形成一种无形的监督。

>>>>第二步,引入站会制度。

当团队所有人的任务都在看板后,这些任务的状态是需要有人更新的。无论是专人更新,还是每个人自己更新,都会出现忘记更新,更新不及时的情况。这时,就可以顺势引入站会制度了。每天上班的时候,或者每天下班的时候,所有人站到一起,花15分钟,说一下自己做了什么,准备做什么,所有人一起把看板更新了。

>>>>第三步,引入回顾会议

当站会制度成熟后,就可以挑一个版本发布的日子。等版本发布后,把团队成员叫到一起,开一个回顾会。让团队成员对这个版本开发的情况做个总结,同时可以让大家用便签把这个开发版本遇到的问题、不满写下来。针对这些问题不满,大家一起讨论一些改进方案。

>>>>第四步,引入计划会议

如果再开回顾会的时候,有人提出需求不清,拆解不够细致,工时估算不准之类的问题,那你真是太幸运了。碰到这种情况,你顺势提出这个制度:每个版本开发前,产品经理要和团队人员开个会,一起逐条对需求。产品经理要向团队解释每个需求,并且对团队提出的疑问进行解释和澄清。开发团队要将需求分解成任务,估算工时,最终形成一个开发清单。

>>>>第五步,引入评审会议

当计划会成功开过几次之后,就可以考虑引入评审会了。你可以在某个重大功能发布的时候,把所有项目相关的人员召集起来,向大家展示团队做了哪些了不起的功能,也可以和大家讨论讨论还可以做哪些优化。

>>>>第六步,宣布引入Scrum

当整个流程都跑顺以后,就可以在某次全体会议上,提出我们要实施Scrum了。你需要任命PO、SM,对团队培训Scrum知识,讲解Scrum的价值观。

实施敏捷开发会面临怎样的挑战

1.团队成员对变化的恐惧

实施Scrum最大的挑战来自内部,来自团队对变化的恐惧。每个团队在运营一段时间后都会形成固有的默契和习惯,引入Scrum必然会打破这种习惯。这会让团队很不舒服,团队也会抵制,甚至是反抗。

而且实施敏捷的过程,一定不是一帆风顺的,尤其是实施敏捷的早期阶段,不仅不会对团队产生太大的价值,反而会引起混乱。所以,在实施敏捷的过程中,千万要小心,每次只改变一点点,敏捷地完成敏捷。

2.组织人员的专业化水平

敏捷并不会直接提高团队的专业化水平,反而对团队专业化水平有一定的要求。必要的专业分工、合适的专业能力是必须的。敏捷会让开发整个流程持续运转,当某一个环节专业化能力出现问题的时候,会极大地导致整个流程运转停滞。

平时团队中的问题会在敏捷中快速暴露。一旦出现专业水平问题,要及时解决,补充人员,或者帮助其提高能力。即使问题并不严重,也要在最短的时间解决,否则会影响团队对敏捷的信心。

3.产品经理这个组织Bug

国内在实施Scrum的时候经常会碰到的问题就是团队中会有产品经理这个角色。

一般的处理方法是产品经理当PO,但PO是需要领导开发团队的。国内的产品经理往往不是技术出身,领导开发团队会出很多问题,所以产品经理并不适合当PO。

另一种做法是产品经理做利益相关者,这种做法更不靠谱,利益相关者离团队太远,会出现无法及时响应的问题,时间长了也会导致产品和开发之间关系冷漠,出现隔阂。

我们目前的做法是尝试是引入一个非官方版本的Scrum(Scrum 3.0),他将PO拆分成了业务拥有者(BO)和团队队长(TC)。产品经理担任BO,开发经理担任TC,目前看效果还不错


文章分类
联系我们
联系人: 郑女士
Email: zhengqiaoyin@cnezsoft.com
QQ: 2987868987