浅谈敏捷开发及Scrum(一)

接触“敏捷”这个词有蛮久了,团队近半年也在实行敏捷开发,对于敏捷也有一些感触…

啥是“敏捷开发”

敏捷误解.itlao5.com

 

对于“敏捷开发”,网上有很多解释,可以查到一大堆相关文章,而且很多文章都有自己的不完全相同的解释;啥是“敏捷开发”,我也无法给出标准答案,这里只谈谈自己的看法:敏捷开发是以用户需求为导向,需求进化为核心,采用迭代、逐步完善的方式进行软件开发;其中的核心是“用户需求进化”与“迭代、逐步完善”!前者保证我们所做的工作于用户(包含终端用户、产品、领导、实施、研发等所有提出合理需求的人)而言是有意义的(或者说有商业价值的),后者保证需求开发的有序性、并在一定周期内的研发工作不会被打断。
另外,很多人以为敏捷开发就等于Scrum或者XP,但是,这些还是有所不同的,敏捷更多的是一种思想,而Scrum是敏捷开发的一种实践模式,也可以说是方法~(我是这样理解的,不知道有没有错误)

Scrum迭代

Scrum迭代.itlao5.com

 

“敏捷开发”实施其实说起来很简单,然而,我接触的实施“敏捷开发”的几个团队对敏捷开发的反响却不尽相同,有的团队觉得敏捷开发确实能让团队更有战斗力;有的团队认为敏捷开发拖慢了团队开发的节奏;也有的团队觉得敏捷不敏捷其实都一样。

这些团队对敏捷开发的实施方案都是“Scrum”迭代开发,那么,首先我们来了解下“Scrum”,“Scrum”是一种迭代式软件开发,包含SM,PO,TEAM三类角色:SM是指团队管理者,最主要的职责是维护团队的稳定性与不受外界干扰;PO即产品,主要职责是需求的整理、优先级排序、内部验收等;TEAM,指整个团队的开发人员,主要职责是研发与测试。

“Scrum”主张一切从简,少文档(一切皆文档,会议纪要、会议白板等都作为文档,而不必再另外整理标准文档)少会议,及时沟通;但是,它也主张几个必要的会议:1、启动会(需求评审、用时评估、故事分配、任务拆分、承诺完成时间)2、每日站会(前一日完成任务,今天计划完成任务,任务进度与面临的困难)3、评审会(团队迭代周期成功的展示与验收)4、迭代回顾会(迭代中的优缺点,改进方法,改进方法的实施);另外,还有一个非常必要的,决定迭代是否能正常进行的事件:产品梳理(PO梳理接下来1~2个迭代周期的任务)

“Scrum”主张公开,专注,勇气,承诺,尊重;我的理解是:信息沟通及时,无阻碍;三大角色职责分明;用于选择及领取开发任务;为任务作出合理的时间承诺并完成;团队内部无阶级区分。

“Scrum”的一些其他问题就先不说了,其实这些网上一大堆,上面只是我对自己认为比较重要的几点内容的理解。

再回到最初说到的不同团队实施敏捷开发后的看法;从上面,我们不难了解到,在“Scrum”中:PO对故事的优先级排序,提前准备,对迭代周期内故事的安排;SM对团队的保护;团队对任务的拆分,对承诺时间及内容的忠诚度;对迭代内问题的处理及时性;团队的稳定性等等……这些都会对其成功率产生很大的影响。以上问题,一般是在迭代中,某一项或几项出现了问题。

如何实施

遇到的困难

简书:ThinkinLiu 博客: IT老五

其实准备写“敏捷”已经很久了,但网上已经太多类似的文章,而且不尽相同,我也担心自己写错误导别人;但是,后来一想,也许有大牛能帮忙纠正呢,可以逐步加深理解。所以,就准备记录发布了,大家带着怀疑的精神看,有不同见解欢迎一起探讨…
ps: 先记录对敏捷和Scrum的一些基础理解,后续再补充“如何实施”与“遇到的困难”…



发表评论

必填项已用*标注

+ 78 = 79