精华内容
参与话题
问答
  • 什么是敏捷开发

    千次阅读 2017-09-19 14:14:27
    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,...

    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...

     

    为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解;所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助。

     

     什么是敏捷开发?

    敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

    怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

     

    为什么说是以人为核心?

    我们大部分人都学过瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

     

    什么是迭代?

    迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

     

    关于Scrum和XP

    前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

     

    什么是Scrum?

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

    而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

     

    【Scrum开发流程中的三大角色】

    产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

     

    流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

     

    开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

     

     

    Scrum流程图

     

    //------------------------

    下面,我们开始讲具体实施流程,但是在讲之前,我还要对一个英文单词进行讲解。

    什么是Sprint?

    Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

     

    如何进行Scrum开发?

    1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

    3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

    6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

    7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

    8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

     

     

    下面是运用Scrum开发流程中的一些场景图:

    上图是一个 Product Backlog 的示例。

     

    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。



    任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。


     

    每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)

     

     

     上图可不是扑克牌,它是计划纸牌,它的作用是防止项目在开发过程中,被某些人所领导。

    怎么用的呢?比如A程序员开发一个功能,需要5个小时,B程序员认为只需要半小时,那他们各自取相应的牌,藏在手中,最后摊牌,如果时间差距很大,那么A和B就可以讨论A为什么要5个小时...

     

    敏捷开发的4句宣言

    个体与交互 胜过 过程与工具

    可以工作的软件 胜过 面面俱到的文挡

    客户协作 胜过 合同谈判

    响应变化 胜过 遵循计划


    转:http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html点击打开链接

    展开全文
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...

    今天你敏捷了没有?“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。

    我们使用 tapd 写 feature,流转、跟踪任务,言必谈敏捷,然而我们是否真的走对了敏捷?(注:tapd 是腾讯内部的敏捷项目管理系统) 。

    1.朋友,你听说过敏捷么?

    2.离开敏捷工具,我们怎么敏?

    3.设计也要介入敏捷流程?

    4.敏捷跟文档是对立的?

    5.我这有个几百亿的大项目,怎么敏?

    6.尽信书,不如无书。

    一、朋友,你听说过敏捷么?

    程序员说,要有敏捷

    从敏捷的滥觞看去,比起方法,这玩意貌似更像一个宗教(笑)。

    千禧之初,美国在计算机行业已经走了几十年,瀑布流、螺旋模型、快速迭代...各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善,但互联网的加速发展让传统方法显得笨重,难以快速适应变化。有十七个程序员(程序员改变世界)在美国犹他州的一个风景区开了个碰头会,找到了一个团队耦合度高,流程极其灵活的方法,他们把它称为agile program development。

    这十七个人如同开宗立派的长老,在会议之后给自己起了个名字“敏捷联盟”,他们不仅赋予了新方法名字,还有宣言,甚至纲领。

    盐湖城- snowbird(敏捷联盟成立地——雪鸟滑雪场)

    中文版的“敏捷宣言”。在建立于2002年3月的 《Manifesto for Agile Software Development》里你可以找到几十种语言的“敏捷宣言”。

    另外,长老们还制定了12原则,作为福音传播。

    显而易见,敏捷是绝对的结果导向,去文档化,去流程化,高效沟通和合作是究极奥义。

    看起来是个很不错的方法,文档不重要了,流程不重要了,大家聚在一起说一说就可以了不是吗?太棒了,感觉可以从繁重的文书工作中解脱出来了呢。

    失之东隅收之桑榆。一处的方便一定意味着另外什么地方以其他方式运行着简化掉的部分。

    去文档,敏捷管理者需要维护更为精细的需求池;去流程,口头沟通成为常态,对团队的耦合度要求更高。

    胖友,这里有一份教义,你要不要听一下。

    初识敏捷,有一些概念需要了解,如果你是老司机,跳过这部分,阿敏。

    agile:迅速,敏捷。这是敏捷的理念也是精髓:迅速响应需求,快速反馈结果。agile 的引入像一股活水冲击着老气横秋的瀑布流模型,速度上跑赢几条街。

    sprint:字面意思是短跑冲刺,一个开发阶段被认为是一次冲刺,一个个 sprint 首位相连,构成一个项目。

    Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。

    scrum 即为这样一种方式,大家一拥而上,团队是球员,球是产品目标,人员环环相扣,围绕着产品目标进行工作。这里面多少有点“统筹法”的影子,人员深入协作以达到最优化效果。

    Product Backlog:

    backlog 即需求池。待办事项列表。

    Backlog 里面写什么:

    1.待开发任务。

    2.任务优先级。

    敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人(一般是产品经理)对所有待开发事项有深入了解,并且能够把待开发事项分解成更为细致的任务(或者跟敏捷教练一起,后面我们会再次提到敏捷教练)

    story board:

    很多领域都有故事板的概念,交互领域里,用故事板表述用户场景、电影领域里故事板用来更具体地描述分镜。在开发领域,故事版是任务流转的可视化窗口,一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块,所有任务由任务操作者负责流转至于下一个步骤,这样任何一个人项目成员都能看到任务的完成情况。

    一个app使用情景故事版

    在开发中,故事板展现所有需求的工作流

    burn down chart:

    燃尽图

    一个 sprint 内,人/时是一个比较固定的值。在这个时间框架充分安排开发任务,每天进行时间结算,绘制时间燃尽图。项目成员通过燃尽图获知时间进展,若项目燃尽所用时间与预期时间契合,则需求时间预估和安排合理,若不契合则需要在下一个 sprint 进行调整。

    名词听起来都玄乎乎的,很符合开宗立派的气质。这些概念定义了敏捷各个环节的工作,这些流程和节点是敏捷开展的基础和保障。

    二、离开敏捷工具,我们怎么敏?

    一个误区:我们用了敏捷管理工具,就敏捷了

    随着敏捷在行业内的不断融入,各种工具产品层出不穷。国外jira、redmine,Axosoft ,国内的leangoo 、禅道,三大家则都有自研的工具,百度的icafe,阿里的aone,我鹅自研tapd。

    (数据来源:“2016中国开发者白皮书”)

    我们在 tapd 上建迭代,建需求,研发、测试等着收到需求流转的邮件之后开始干活...任务在测试和研发之间流转,bug 提给研发,研发解决 bug .....我们宣称:我们敏捷化了!

    我们习惯于敏捷软件的便利,拉群解决一切,然而却丧失了敏捷的初衷,scrum 的本意。

    Jira的名字来自于哥斯拉

    假设我们没有任何项目协同软件,敏捷怎么实施?

    设定一个环境,现在没有任何协同工具可用,但是所有人都坐在一起。有人站起来说,既然这样,我们不如敏捷吧!

    敏捷工具消失了

    敏捷路径里必须有一个项目持有者,制定规划并把握项目走向。这位产品汪我看你骨骼惊奇,你就担负起这个责任吧。

    另外还有一个关键人物 SM(别想歪)。SM 全称 scrum master,中文称敏捷教练。一般说来,SM 需要由对技术开发以及当前项目明晰的技术经理担任。

    虽然缺少线上工具,但至少要准备一些简单材料:一卷双面胶+白纸或一沓便利贴;笔,一面平坦的墙或一块黑板。

    如果还有电脑可用,excel 或者 word,甚至写字板都可以,没有电脑那就白纸好了,总之你得找个地方写下你的需求池(backlog)

    需求池示例(任务名称、平台、详细描述、优先级按照P0-PX逐渐递减)

    确定一个 sprint 周期的自然天。可以用月/旬/周等时间概念作为周期,我们选择一周(五个工作日)作为一个 sprint 周期。

    按照优先级,从需求池中拉出你认为应该加入你们一穷二白的第一个 sprint 里面去的需求,别太贪心,大概觉得差不多一周左右的开发量就够了。拉上SM桑单独开一次小会。

    当然不是让你俩傻站着,你俩要开会

    你们一起通览需求,SM 桑根据经验对需求先行分解一遍,比如某需求在开发层面需要分解为 ABC 三部分,这三部分就形成三个开发任务。

    分解完成后,你得到了一个比较详细的待开发列表。

    正式开始一个 sprint 开始之前,产品、研发、测试需要一同开一次 scrum 会议,共同讨论本次 sprint 的功能点。

    会上讨论什么:

    1.需求讨论或技术讨论;

    2.成员预估需求所需开发时间;

    3.需求是否match人力时间,需求排入sprint;

    4.交流一下感情。

    每个任务的预估时间在最后由敏捷教练综合判定

    scrum 会后你的工作:

    1.整理这个 sprint 内的需求列表;

    2.整理每个需求的预期开发时间;

    3.撰写故事版上的小纸条;

    4.把小纸条贴到故事版上;

    5.制作一个燃尽图。

    一个改良版的小纸条,写明开发者、任务描述、预估时间和每日燃尽时间

    故事版布局如下:

    一个标准的故事版:最开始所有的小纸条都在“待开发”一栏

    到此为止,你可以开始 run 起一个 sprint 。

    以为这就完事了?天真。

    接下来你必须来参加每日举行的项目短会。这个环节在 agile 中非常关键,是 agile 的日常修炼。为了缩减会议时间,我们一般站着开——所以也叫“站会”,早上上班后或晚上下班前,抽出十到十五分钟时间,完成它。

    每日站会

    站会都有什么人参加:

    1.你(项目持有者)

    2.SM

    3.其他 scrum 成员

    站会干什么:

    1.昨天大家分别做了什么事,遇到了什么问题,如何解决或寻求解决方案;

    2.昨天任务的完成状态,剩余多少时间,是否需要进行时间修正(增加时间或减少时间),把已完成的任务流转到下一环节(把纸条从一个item内撕下,贴到下一个item里去);

    任务进行中,小纸条的示例

    3.功能测试后是否有返工;

    4.交流一下感情。

    站会之后你的工作:

    绘制燃尽图。

    一个燃尽图的示例:正常的 sprint 的任务时间是随着 sprint 的进程逐渐减少的

    周而复始,完成了一个 sprint 后,你们开了第二次 scrum 会。这时议题多了一项:复盘上一个 sprint。

    任务未能燃尽;研发返工过多;测试需求淤积.....

    针对问题讨论解决方案,根据实际情况进行下一个 sprint 的任务安排。

    自此,我们在没有任何敏捷工具的帮助下,开始了敏捷的旅程。

    说起来agile developing 本来就是排斥文档的作业方式,为一个小轻快的方法制作一套严谨庞大的工具,基本也算违背了元老们的初衷了吧,科科。

    三、设计师在敏捷中如何介入?

    我们正在使用或者听过的一些流程方法——不单敏捷,瀑布流,迭代式,结对开发,精益开发....似乎都不关设计师什么事。既然开发团队抱团敏捷了,设计,这个在产品流程中必不可少而工作内容相对独立的角色,要怎么介入敏捷呢?

    一种思路是,设计拥有自己的敏捷流程。设计师作为一个 scrum 存在,以从上游获取的需求进行 sprint 。

    另一种思路,是把设计和测试完全纳入到团队中来,一起进行 scrum 的合作。

    这样的话,UI工作至少要比开发工作前移至少半个 sprint 。

    有请产品经理(项目持有者)出场。

    很好,我们有了一个设计师

    项目持有者将需求分为“ UI 支持”和“非 UI 支持”两类。我们将小纸条扩展一下。

    多出来 UI 前置部分的小纸条

    U I设计师参与到 scrum 会中。对于需要 UI 支持的需求,设计师给出一个 UI 制作的时间预估。项目持有者将这部分时间加到扩展小纸条上去。在一个 sprint 中,设计师的工作跟研发的工作分别进行。

    当设计师将某一需求完成时,将小纸条的 UI 部分撕下,汇入到“”待开发”中去。

    一个已经完成了 UI 设计的小纸条示例

    四、敏捷不需要文档吗?

    一切为快服务的敏捷特别适合初创团队使用。它能把团队人员紧密结合在一起,高效而有序地输出产能。而常规高效的版本输出往往是初创团队高速发展的第一要务。

    敏捷了一段时间之后,产品进入正轨,项目拿到拨款,公司拿到投资,你们要扩大团队规模,新入职的同事想了解下产品和技术细节,你告诉TA:

    你要不翻下 backlog 看看?这个实现你要不看一下代码?这个字段我也不记得有没有了....你抓包看下?

    新同事一脸懵逼,难道咱们没有文档吗?你自豪地指出:

    “我们是敏捷团队。”

    十几个人八九条枪的阶段之后,产品趋于稳定,团队逐步扩大。无论从内部协调还是外部沟通上对产品流程的正规化和文档化要求与日俱增。

    从短期收益上看,文档对于敏捷开发是非必须品,并且很有可能会拖慢进度。在一个 sprint 中,口头沟通显然效率更高,每个人都有精确到工时的任务,没人有等待文档更新的时间。强调文档就等于放弃灵活性。

    从长期和宏观上看,文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本,同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲,文档让后续的工作效率更高。

    一个以讹传讹的过程

    这样一个功在当代利在千秋的好事,当然要做。那么——

    谁来维护文档,怎么维护?

    我们挑选几个重要的文档:产品文档、概要设计、接口文档

    产品文档:不好意思内个产品经理你过来下。虽然你要维护 backlog 、跟 SM 分解需求、开 scrum 会、写小纸条、开站会、画燃尽图、还有什么外部沟通啊,写 PPT 啊,绞尽脑汁想规划啊......你还得认真把这个文档维护好。

    对又是你

    产品文档包括:

    1.需求;

    2.加入日期;

    3.开发版本;

    4.呈现和详细方案

    在非敏捷开发流程中,文档在评审会后完善并更新,形成一个给研发参考的实现目标。在敏捷中,需求本身在 sprint 周期内不断完善,你可以在一个 sprint 之后将文档补全。

    概要设计:敏捷的常规迭代中,概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。研发 leader 责无旁贷,这个落你身上了。

    接口文档:必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。一般来说约定之后由接口开发者更新文档,如果你们没有云端存储的能力,至少咱们人手一份,定期更新。

    长久来看,文档是提高效率的一大利器

    虽然《宣言》中明确地放低了文档的地位(“工作的软件大于详尽的文档”),敏捷强调互动和变化,以及对变化的及时响应。诚然文档恰恰做不到如此灵活。但敏捷真的完全排斥文档吗?

    文档的时效性和灵活性远低于口头沟通,但却有它实在的好处。

    1.空间上,文档传播范围更广。规范化和常规化的内容形成文档可以大大减少沟通成本。尤其在多个系统协作的情况下,跨 scrum 、跨团队甚至跨部门的沟通时有发生,文档的重要性和便捷性不言而喻。

    2.时间上,文档流传性更好。团队不是一成不变的,有人离开有人加入。更新换代中,新人快速了解系统,老兵传承研发理念;在更大的时间跨度上,团队可能成为忒修斯之船,文档的存在就是对产品历程的完整追溯,你将不用他人帮助就可以了解到产品的大部分面貌甚至全貌。

    五、大项目怎么引入敏捷?

    看起来敏捷方法特别适合产品常规迭代。有一种可能性是,你的产品需要插入一个巨无霸模块,与其说是模块倒不如说它几乎可以成为一个产品了。你想了想,这么大个项目怎么说产品、设计、研发、测试全情投入也得个一两个月。

    还能走敏捷吗?

    注意你的项目时间。有 deadline 的 scrum 是带着镣铐跳迪斯科,时间节点关乎 sprint 的大小。

    大项目敏捷之前,先得不敏捷几步。

    可能会发生一到多次需求讨论会。

    团队必须不厌其烦地理解需求或修正产品经理“天真的幻想”,产品经理使用不断完善的原型同团队进(tao)行( jia )沟( huan )通( jia )。在最后的产品评审之前,至少敲定产品框架和大部分细节。这次评审邀请项目成员和所有协同团队,除了敲定的产品功能,技术上需要得到一些初步结论(比如“能不能做”。事实上,产品经理应该在产品规划阶段就知会协同团队将要做什么)。接下来进行概要设计(新产品、重构、重大新功能必须进行概要设计)。技术评审邀请除设计以外的项目成员和协同团队参会。

    大项目敏捷中:

    1.将 deadline 之前的时间分解为多个 sprint 。(deadline 之前必须留出一定“出血时间”用以解决时间预估不足的任务、返工任务以及 bug )

    2.将所有需求分解成任务,开一次全局 scrum 会。预估时间之后,分散任务到各个 sprint 中。在时间较紧的情况下,sprint 的容量就要相应增加。

    一个需要加班的 sprint

    3.进入敏捷流程,常规 scrum 会、站会,燃尽图,故事版。未完成任务在 scrum 会上重新预估时间,滚入新 sprint 内,以此类推(按时完成 sprint 内的任务是目标。实在不行我们还有“出血时间”呢)

    4.别忘了文档。

    虽然被推崇备至,但敏捷并不是完美的开发方法。敏捷的最大的优势是灵活,而造成敏捷问题的根源也正是灵活。

    文末再总结本文重点:

    1.敏捷是一种流程、方法、理念,甚至信仰。

    2 用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作,线上的的流转如果削弱了这种配合性,反倒背离了敏捷的本意。实际上只要有白板纸张和笔,你的团队就能开始敏捷。

    4.我们敏捷了,不是不要文档了。在外部交流多、世代跨度长的情况下,文档的必要性显而易见。长期的面对面沟通最终会导致低效,这也是敏捷缺陷的根源。

    5.设计师可以完全介入到敏捷流程中,只需要做一些细心的安排。

    6.大项目开发中可以走敏捷,具体问题具体分析,需要根据项目特点制定敏捷计划。

    展开全文
  • 什么是敏捷开发

    万次阅读 多人点赞 2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...

    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。

    在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

    简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

    是谁这么厉害,提出了敏捷开发思想?是一位名叫 Martin Fowler 的美国大叔。

    大叔不但是敏捷开发的创始人之一,还在面向对象开发、设计模式、UML 建模领域做出了重要贡献。目前担任 ThoughtWorks 公司的首席科学家。

    敏捷开发模式的分类
    敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等。其中 SCRUM 与 XP 最为流行。

    同样是敏捷开发,XP 极限编程 更侧重于实践,并力求把实践做到极限。这一实践可以是测试先行,也可以是结对编程等,关键要看具体的应用场景。

    SCRUM 则是一种开发流程框架,也可以说是一种套路。SCRUM 框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作。在这里我们重点讨论的是 SCRUM。

    SCRUM 的工作流程

    学习 Scrum 之前,我们先要了解几个基本术语:

    Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
    User Story:用户的外在业务需求。拿银行系统来举例的话,一个 Story 可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
    Task:由 User Story 拆分成的具体开发任务。
    Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
    Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为 Scrum。
    Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
    Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
    Release:开发周期完成,项目发布新的可用版本。
    在这里插入图片描述
    如上图所示,在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份 Product Backlog,为项目做出整体排期。

    随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的 Sprint Backlog,再细化成一个个 Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行 Daily meeting,根据情况更新自己的 Task 状态,整个团队更新 Sprint burn down chart。

    当这一周期的 Sprint backlog 全部完成,团队会进行 Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的 Release,并且进行 Sprint 回顾会议(Sprint Retrospective Meeting)。

    那么,现实中的 Scrum 是什么样的情景呢?看看下面的照片就知道了:
    在这里插入图片描述
    敏捷开发与 DevOps
    DevOps 是 Development 和 Operations 的合成词,其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢?需要我们的项目做到持续集成、持续交付、持续部署。

    时下流行的 Jenkins、Bamboo,就是两款优秀的持续集成工具。而 Docker 容器则为 DevOps 提供了强大而有效的统一环境。
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 敏捷过程(小规模团队敏捷开发

    千次阅读 2018-05-10 09:31:13
    敏捷开发的价值观 敏捷开发应遵循的12条原则 敏捷开发的原则 敏捷团队运作机制 关键的团队角色 产品负责人(Product Owner) Scrum Master(流程主管) 关键的团队活动 敏捷团队的五个约定 约定1. 业务分析师...



    记录一些优秀的敏捷开发案例或经验:

    敏捷开发:项目管理的一些思考
    w_fsovereign:三个月(敏捷)项目收获
    RobinsonZhang:敏捷开发入门



    一、敏捷过程

    敏捷开发是一种以人为核心,以迭代方式循序渐进开发的方法,其软件开发的过程称为“敏捷过程”。
    在这一过程中,软件项目的构建被切分成多个子项目,各个子项目的成功都经过测试,具备集成和可运行的特征。
    在2001年年初,一些业界专家成立了敏捷联盟,起草了敏捷软件开发宣言。该宣言针对一些企业的现状,提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则,其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则。

    1.1 敏捷开发的价值观

    1. 个人和交互胜过过程和工具。
    2. 可以运行的软件胜过面面俱到的文档。
    3. 客户合作胜过合同谈判。
    4. 响应变化胜过遵循计划。

    1.2 敏捷开发应遵循的12条原则

    1. 通过尽早的、不断地提交有价值的软件来使客户满意。
    2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
    3. 以从几个星期到几个月为周期,尽快、不断地提交可运行的软件。
    4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    5. 以积极向上的员工为中心,建立项目组,给他们提供所需的环境和支持,并对他们的工作予以充分的信任。
    6. 在团队内部,最有效、效率最高的传递信息的方法,就是面对面的交流。
    7. 测量项目进展的首要依据是可运行软件。
    8. 敏捷过程提倡可持续的开发,责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
    9. 时刻关注技术上的精益求精和好的设计,以增强敏捷能力。
    10. 简单是最根本的。
    11. 最好的构架、需求和设计出于自组织的团队。
    12. 每隔一定时间,团队要反省如何才能更有效地工作,然后相应地调整自己的行为。

    敏捷组织提出的敏捷开发模型的整体框架主要有三个:
    Scrum、XP(eXtreme Programming)、OpenUP 这3个敏捷实践。



    二、敏捷开发的原则

    1. 凝聚人的力量,紧密协(合)作。包括业务负责人、开发团队、客户、管理者之间的关系,所有这些关系在以前都是造成项目危机的原因之一,那么,在敏捷时代,我们需要这些角色 紧密合作,最大限度的发挥各个角色的力量.
    2. 聚焦客户价值,消除浪费(如何聚焦用户价值,即频繁的交付用户可工作的软件,快速收到用户反馈)

    2.1 敏捷团队运作机制

    1. 一个团队有自己的代办事项,对代办事项进行拆小。
    2. 按客户价值进行优先级排序,产品经理负责价值排序。
    3. 小而稳定,跨职能团队。
    4. 多个团队松耦合(依赖性比较低),对齐迭代时间和战略目标。

    2.2 关键的团队角色

    • 产品负责人
    • Scrum主管(流程主管)
    • 开发团队

    2.3 产品负责人(Product Owner)

    • 负责管理产品backlog(代办事项)的唯一负责人
    • 代表客户/项目如责任人
    • 定义产品的所有特性
    • 负责产品的投入产出
    • 负责最大化产品和开发团队工作的价值

    2.4 Scrum Master(流程主管)

    • 起到教练的职责,领导团队完成Scrum的实践以及体现其价值。
    • 排除团队遇到的困难,使得团队紧密合作,使得团队个人具有多方面职能的工作能力。
    • 确保团队能胜任其工作,并保持高效的生产率。
    • 保护团队不受到外来无端影响

    2.5 关键的团队活动

    • 每日例会:每日5分钟左右的一个简单例会,尽可能多的开发人员参与进来对紧要问题的讨论。
    • 评审会:需要在迭代周期的最后一天召开,1个小时左右就可以了,需要客户出席,如果客户不能出席,则需要产品经理出席
    • 迭代回顾会:迭代回顾会是在每个迭代结束时进行,总结工作中的经验和教训,时间维持在30-60分钟内,整个团队都需要参加(Scrum Master、Product Owner、开发团队以及客户)。迭代回顾会包括两部分,第一部分是定量分析,第二部分是定性分析。其中定量分析又包含团队是否完成了迭代目标,收集并评审迭代度量指标(包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等)。定性分析包含哪些工作良好(应该继续保持),哪些做的不好(应该停止)?哪些可以改进(团队选出1-2条在下一个迭代实现)?

    敏捷开发
    作者:木可大大

    三、敏捷团队的五个约定

    3.1 约定1. 业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议

    我们的团队需要让客户频繁的得到可用的软件,客户的不断反馈会给软件的未来做出最正确的方向指引。

    如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需求上,
    不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。

    而我坚信“prevention is better than
    cure”(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力。

    为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。

    我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。

    如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了,开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

    所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。

    3.2 约定5. 测试人员们,那些敏捷实践对于我们也是有用的。

    如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性)。

    如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他,INVEST(独立,可协商,价值,可估算,短小,可测)。

    也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。

    我和敏捷团队的五个约定

    四、敏捷开发的前置条件

    4.1 比较固定的流程,文档,需求

    1. 需求是控制稳定性的根本,对于需求一定是整体可控的,并且是可以由迭代内进行调整的,而不是定死的
    2. 流程是指什么时间什么人该做什么事是高效的,明确的
    3. 文档是指每个流程阶段具有可交付或者可查阅参考文档,不是口头或者个人评定。

    4.2 可灵活调整,允许试错

    • 检查

    检查是指在每天的站会中检查每个人的工作状态,是否能完成自己的任务,存在什么问题,完成效果如何。另外就是保证整体在每天的进度,是否有有整体效果,如果没有完成今天的整体效果,需要检查是否符合整体迭代。

    • 调整

    调整是指检查发现迭代的进度或者外界环境发生变化时,及时调整当前迭代的开发任务,保证迭代最终产物的准确及时性变动。当然,这种变动是不允许太多的,一般情况下在需求没有做详细分析时,不接受;在当前有风险的情况下,撤销某些需求;其他情况不做描述。

    • 试错

    正是由于检查以及调整的策略,保证了迭代的灵活性,我们可以在敏捷团队中尝试一些较革新、新的功能点或者技术点,如果实验成功则可以对外拓展;如果不行,可以快速切换方案。

    4.3 问题场景&&错误认识

    • 一个团队闭关开发一个项目就是敏捷

    正确理解:敏捷不等于闭关,只是可能坐一起效率更高,其倡导的是何时都可以发生沟通,并准备一白板可以随时讨论方案;敏捷团队质量以及效率高于一般团队;敏捷团队开发的是以迭代为单位,不是项目;

    • 有了任务细分,开发白板,站会就是敏捷

    正确理解:任务细分、白板、站会都是其形式,关键还是其将迭代的内容进行细化,可执行化,用高频的沟通反馈提高开发、沟通、理解的效率。

    • 敏捷团队没有特殊前置条件

    正确理解:前面有讲到敏捷对团队,需求,文档,流程,调整等都有比较完整的规定。

    • 敏捷团队做的事情没有差别性

    正确理解:敏捷完成的任务具有明细化,分阶段性,可调整性。所以在开发相关任务时,也具有类似的特点。

    • 敏捷团队会完整完美的交付产物

    正确理解:敏捷在迭代结束只交付该阶段的可交付产物,很可能不完整不完美,对于可交付也有不同的理解。

    展开全文
  • 项目管理之敏捷开发总结

    万次阅读 2018-04-11 23:27:05
    瀑布模型:简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:18:20
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 嵌入式系统软件敏捷开发

    千次阅读 2012-09-17 20:32:59
    本文综述了嵌入式系统敏捷开发(Agile Development),敏捷宣言,敏捷的原则,很多的敏捷开发的实践习惯,敏捷开发与瀑布开发流程的区别,敏捷的任务stories划分,并行开发敏捷的时间安排,敏捷的通信交流方式等等。...
  • 敏捷开发实践(一)--谈谈我对敏捷开发的理解

    万次阅读 热门讨论 2015-05-31 08:16:30
    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 敏捷开发和迭代开发

    千次阅读 2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
  • 敏捷软件开发模型Scrum通俗讲义

    万次阅读 2011-08-11 15:14:07
    0、前言  之前或多或少都听过说有关...由于公司现在所采用的是Scrum开发流程--敏捷开发的一种,所以,特此作番学习与研究,我也力求文字通俗易懂,已不致让大家对它产生对会议感到厌倦一般的情绪。   1、什么是敏捷
  • 瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各...
  • 敏捷开发的起源在90年代末期,传统软件开发的方式因为其繁杂的过程,以及对文档的过于严格的要求,造成了很大程度上的效率下降,也就是人们所说的“重型化危机”。因为这一原因,人们开始反思传统方法的利弊,并对其...
  • 这是敏捷开发一千零一问系列的第十四篇。(在这里提问,之一,之二,之三,问题总目录)正逢周末,又是愚人节,群中有人正在加班,想起上次培训中间休息的时候,讨论起这个“敏捷开发加班吗”的问题,虽然后来没有...
  • 适合APP的开发模式——敏捷开发

    千次阅读 2016-08-29 15:22:41
    传统的软件开发模式需要经历问题评估、计划解决方案、设计系统架构、开发代码、测试、部署和使用系统、维护解决方案等过程,如下图↓ 采用传统软件开发模式的最大问题是开发周期过长,迭代速度慢。移动互联网行业...
  • 什么叫敏捷开发

    万次阅读 2015-04-19 14:49:58
     软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元,这与冰冷的机器是不可比的,所以在中国的历史上,管理人是最难的工作;“学而优则仕”的...
  • 敏捷开发

    千次阅读 多人点赞 2019-08-12 20:39:23
    敏捷开发前言迭代开发增量开发敏捷开发的好处早期交付降低风险如何进行每一次迭代敏捷开发的价值观十二条原则 前言    迭代开发   敏捷开发的核心是迭代开发(iterative development)。敏捷一定是采用迭代开发...
  • 敏捷开发每日一贴】:看板方法

    千次阅读 2017-04-10 09:19:00
    看板方法 看板(Kanban,来源于日语)最初是丰田汽车公司的大野耐一于20世纪50年代发明的,当时是从超级市场的运行机制中得到启示,将看板作为一种生产、运送指令的传递工具而被创造出来的。 ...
  • 联系信箱:feixiaoxing @163.com】 软件开发有很多的模式,一般认为有三种模式,分别是瀑布、迭代开发敏捷开发。瀑布模型是最基本的开发方式,它有严格的处理流程,分别是需求、设计、开发、测试、交付。瀑布...
  • 瀑布式开发敏捷开发区别

    万次阅读 2017-09-27 21:42:15
    1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下...
  • 敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式。  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了...

空空如也

1 2 3 4 5 ... 20
收藏数 136,628
精华内容 54,651
关键字:

开发 敏捷