关闭

对敏捷方法的一些简单认识

727人阅读 评论(0) 收藏 举报
分类:

前言

这两天做的事情,不能说没有用,至少了解了很多数据库的东西,不过大部分做的都是无用功这点是毋庸置疑的,也许这是调研和设计过程不可避免的事情,也罢。

正文

目前实习所在的项目处于测试阶段,负责测试的同学连着忙了个把月,天天加班,不断测出问题,搞的组内氛围...(咳咳...)再想到这几天做的无用功来回折腾等等,就现在组内遇到的这些情况,真是让我特别怀念之前实习公司的敏捷项目。有心想一想,对比对比,虽然我没有专门接触介绍敏捷方法的书,但真心觉得对敏捷开发的优势有了些许认识,也许有点肤浅。

刚开始接触敏捷,听的最多的就是极限编程。快速,基本就是在我耳里的敏捷代名词。当时开发的项目是公司首个敏捷项目,属于开荒性质。一期项目下来,发现相比其他组,我们的开发周期不仅比他们快得多,更可贵的是开发成果的质量也非常有保证,在跟其他组联调之前,大的Bug基本在最终测试前一一解决。一句话,敏捷没有因为快速而忽略质量。现在回想起来,我觉得我们的开荒是非常成功的。

说到敏捷方法,什么建立学习型组织,自我管理,有效沟通等等特点,我暂且不说。以下是我最近的几点认识:

其一、目标一致,特别重要

敏捷开发过程中会分为很多故事sprint,每个sprint的开发工作量多少由PO(Product Owner)和SM(Scrum Master)以及开发人员共同在sprint计划会议中决定。也就是说,基本一次计划会议下来,每个人都需要了解这一次sprint任务要做什么(当然,我们刚开始啥都不会,前期打了四五个sprint的酱油),然后在每个sprint中的任务点再细分到个人完成。总的来说,每个人都是在为当前Sprint计划会议中决定的目标向前跑。每到sprint结束评审会议,超了多少,落下多少工作量基本都有数据说话。不可能出现有人做当前sprint任务之外的事情。这一条,我特别感慨。比如说,现阶段既然属于测试阶段,然后就发现测试人员忙的半死,其他人打酱油,不想打酱油的也干等着,啥事干不了。个别人甚至被安排做超前的工作,我不觉得这会有什么效率,完全不是重心,怎么可能有效果。这不是浪费资源?

其二、Bug、问题集中爆发可能性小

传统开发,需求->设计->开发->测试。我觉得开发阶段是最容易忽悠的人的,开发代码还不简单?但写出来的东西得让人用,不出问题不出bug绝对不可能。等到测试了,测出bug首先不一定能找到责任人,因为代码是一起开发的,开发过程中就可能被多个人改过,给推卸责任落下理由;其次,测试阶段问题集中爆发,改一个又引出一堆,别说效率,就是工作心情也打击严重。相比于敏捷开发,每一次sprint结束就有一次评审。每次评审由PO决定接不接受sprint成果。相当于,就算判死刑,也是在萌芽状态,不至于拖延到最后。更不用说,每次sprint的任务点明确到个人,谁的故事点谁负责,非常容易定位。

其三、非常注重交流

一个敏捷团队交流非常多。。各种会议形式,团队氛围很浓。


另外,敏捷对成员要求还是比较高的。为什么这么说?如果基础稍差,故事点完成不了,基本是敏捷不起来的。所以,当时的敏捷项目对于我们这些新手来说都提供了四五个sprint的过渡期。还有,敏捷团队需要能力强的SM和PO角色,因为其负责整个项目的场景拆分,这些工作特别重要。开发成员负责干活,干活的不是重点,重点是场景拆分的合适性。除了能力方面,还有至少不适合性格孤僻,乐于单干的开发人员。敏捷特别注重交流。

敏捷的一大特点是会议多不假,这就要求PM需要强有力的执行力及组织力,不能将这些东西变为走过场及形式,这样就起不到应用作用。

暂时就这些吧,敏捷现在基本各大设备商都在采用,据说ZTE大小项目都开始采用这种开发方法了,形式主义貌似很严重。。。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    不忘初心,方得始终
    记录自己的学习点滴。
    个人资料
    • 访问:111167次
    • 积分:2058
    • 等级:
    • 排名:第19400名
    • 原创:91篇
    • 转载:9篇
    • 译文:0篇
    • 评论:39条
    博客专栏