敏捷开发和迭代开发是一回事么

笔记2024-02-113 人已阅来源:网络

敏捷开发和迭代开发是一回事么?

理论脱离实践,生搬硬套书本上的概念,没有亲身体验过是无法深刻理解一种管理思维的。

所以,有过从0到1做产品,而且团队就是敏捷开发模式的人来回答这个问题,能更接地气。

敏捷开发的精髓,就在于:快速响应 + 快速上线 + 快速更新;

而迭代开发,其实也有与敏捷类似的思想在里面,但不够突出,内核没有敏捷开发那种“再快一点”的节奏感。

敏捷开发的内核

BAT里被公认产品做得最好的腾讯,就一直强调“小步快跑,快速迭代”。

万法归一,大道至简。敏捷开发的诞生与生存土壤,其实与其是一致的。精炼一下,就是:

1、不要全想好了再做。

建一个网站平台,等所有产品细节都想好了,已经过去2个月了(更别说是否真的想清楚了),再开发、测试,周期拉得太长。

2、有想法,快速上线。

51%成熟了就去做。去试错。错了,快速迭代修改;对了,你就是先抓住第一批用户了。当年腾讯内部做微信产品的有3个团队,最后就是最快做出来的QQ邮箱团队胜出了。

3、不怕错,就怕慢。

互联网产品和企业越来越多,初始的流量红利占有时间也越来越短。错了没关系,有诚意够新意,用户还是记得你,怕就怕你想做共享单车,但小红和小黄已经遍地都是这两家的了。敏捷开发的成员

敏捷开发的成员,往往人数都不会太多。

通常,敏捷模式的迭代称之为sprint。一个sprint,就是一个迭代。

团队里会有产品、前端、开发、测试组成,交互和视觉资源一般以共享为主(重大项目除外)。这个团队间的成员,沟通方式应该以结果为导向,快速响应,避免冗长的邮件、会议形式导致拖慢工作效率。能一句话敲定的,就不需要一个会。

整个团队里面,会有一个PO,即产品负责人,这个岗位一般有程序员的天敌——产品经理担任。对,就是老改需求的那个。

此外,还会有一个master,负责研发进度的整体把控与技术难题拍板。人选通常以候选人的眼镜片厚度来决定。。。不不不,是通常让有经验的开发人员担任,比如研发经理。当然,从长远考虑,在整个团队磨合的较好之后,可以有其他开发或测试人员担当master,起到一个锻炼的作用,作为人员储备。

敏捷开发的节奏

一般敏捷迭代以2周为主,这样一个月会有2次迭代。

迭代开始,会有一个技术评审会。这个会有2个重点,一个是产品和技术间对需求实现的确认,另一个就是开发和测试对需求的工时预估。工时预估是非常重要的一环,一方面对每个需求的开发成本有一个认知,另一个就是多少需求能排进当前迭代就以此决定了。如果周一开始一个新迭代的话,通常下周四发布。

然后,每天早上不超过15分钟的站立会。每个小组的成员轮流当做主持人,会上需要大家把昨天的工作进展和问题描述一下,做到全组成员信息对称。然后,会看一下燃尽图,该图的重点就是直观反应剩余的工作量。

等到开发新迭代拉分支之后,测试可以根据实际情况,开始测试工作,并不需要等到开发都完成后再介入。

敏捷开发的总结

综上,敏捷开发更适合小团队、新产品的项目组。

不怕试错,快速调整。能把想法快速的转化为上线内容,后续再进一步优化。

PS:由于迭代时间短,产品经理当前迭代“忍痛”留下的bug或需求,2周后新迭代就有希望加入。从而减少了产品与程序猿的互相伤害。(当然,他们的战争不会熄灭,永远都在继续。。。)

有思考,阅读才有价值。

有碰撞,思考才会沉淀!