2019-04-12 22:52:55 y_279611480 阅读数 558
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

SCRUM 是什么?

Scrum是敏捷开发中的名词。

敏捷开发是什么?

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

简单的说的话:

  1. 它只是一种开发思想,而不是开发技术;
  2. 其次,需要明白,通过敏捷开发的项目,包含的诸多子项目,都会带有,已经测试结束,具备了集合和可运行的特征;
  3. 敏捷开发,初始,并不追求完美的设计以及编码,而是,尽可能快的先开发出产品的核心功能,以及发布可用版本。之后,才会在多余的生产周期内,根据需求,不断的完善升级与迭代产品。

eg:对于Java全栈式开发工程师来讲,拿到需求,了解之后,第一件事,并不是先去完善后台代码,而是迅速的先将需求页面(网站),先实现。而后,才开始根据需求一步步实现功能。

以人为核心是什么意思?

一句话概括来讲的话,便是:

不似瀑布开发的思想,往往开发完后,写了一堆的开发文档进行开发、
而是,尽量的少写开发文档,只写一些必要性的文档,因为敏捷开发注重的是人与人面对面之间的交流。所以说它是以人为核心。

迭代 是什么意思?

类似与 单体开发 与 微服务、分布式开发的区别。
一个是,将所有的功能实现后,方可测试与后续操作。
另一个是,将所有的功能分为一个个服务或小功能,完成一个便可开发,测试,上线一个小功能。慢慢的完成总体。

循序渐进自然,也可由上明白。

SCRUM 与 敏捷开发思想有什么关系?

Scrum是敏捷开发之后的方法的一种。

敏捷开发的模式分类(摘抄至互联网):

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

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

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:开发周期完成,项目发布新的可用版本。

开发模型:
流程图

流程:

  1. 由产品的负责人,按照需求的优先级,优先取出一部分Backlog(需求清单)。
  2. 在每个Sprint(冲刺周期),开发团队根据计划,确定好每个周期的需求清单(Backlog)。既,在每段时间内需要完成的工作任务是什么。
  3. 对团队成员进行任务的分配开发。每天,团队都会开启Daily meeting(每天的站会)【既,明白自己之前完成了什么】。
    而后团队成员调整自己的Task状态【既,每个小任务的完成时间又该控制在什么时间内】,整个团队便更新自己的Sprint burn down(冲刺燃尽图)。
  4. 当这份Backlog(需求清单)完成之后,便会开启团队的Sprint Review meeting:(冲刺评审会议)。没问题的话,便会发布出发此阶段产品的发型版本(Release),且进行Sprint review meeting(回顾会议)

写在最后,PS:此文内容,部分摘抄至互联网,如若,原文博主介意,可私聊。谢谢。
自然,此文并不完善,欢迎各位点评。

2018-08-15 11:43:58 Ffffatass 阅读数 243
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

敏捷开发流派有很多,但是万变不离其宗。

  • 个体与交互           胜过     过程与工具
  • 可以工作的软件   胜过     面面俱到的文档
  • 客户协作              胜过     合同谈判
  • 响应变化              胜过     遵循计划

敏捷开发是一种思想,是一种紧紧跟随其价值观的思想。敏捷有很多流派,有很多落地的方案,但是这些都是基于思想上的思考。思考是可以有不同的,但是思想是不变的。所有敏捷开发的唯一重点就是紧跟其核心思想,不要被形式束缚。

2019-10-15 11:39:11 qq_37899132 阅读数 58
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

团队最近在进行传统开发向敏捷开发的过渡,谈谈我对敏捷开发的认识。

1、敏捷开发定义

敏捷开发的定义:其实敏捷开发就是以用户需求为导向,需求进化为核心,采用迭代、逐步完善的方式进行软件开发,其中的核心思想就是用户需求的进化与迭代并逐步完善,前者保证我们所做的项目开发对于用户是有意义的(包括终端用户、产品、领导者、开发人员、运维人员等提出的合理需求),后者保证了开发的有序性,并在一定的周期内产出成果,并不断优化。

另外,敏捷开发只是一种开发思想,其具体的实现方法有很多,在实际的开发过程中经常用到的就是Scrum迭代。下面说一下什么是Scrum迭代。

2、Scrum迭代定义

Scrum迭代的定义:Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程。在这个框架中整个开发周期包括若干个小的迭代周期,每个小的迭代周期成为一个Spring,每个Spring建议长度为2到4周。

在Scrum中,使用Product Backlog来管理产品或项目的需求,Product Backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为User Story.

3、Scrum迭代在敏捷开发方法中的应用

Scrum的开发团队总是先开发对客户价值较高的需求,在需求分析会议上通过分析、讨论和估算得到需要开发的需求列表,在每个迭代结束时,Scrum团队将交付潜在可交付的产品增量。

另外Scrum迭代式软件开发方法,包含SM(项目经理)、PO(产品经理)、TEAM(开发人员)。职责分工如下:SM-维护团队的稳定性确保其不受外界干扰,PO-需求的整理、优先级排序、内部验收等,TEAM-整个团队的开发人员,主要负责研发与测试。

Scrum的开发方法主张一切从简,少文档、少会议、多沟通;但Scrum有几个必要的会议是不能省略的:1、项目启动会(需求评审、用时评估、故事分配、任务拆分、承诺完成时间)2、每日站会(昨天完成任务,今日计划完成任务,任务进度与困难)3、评审会(团队迭代周期成功的展示及验收)4、经验总结会(对迭代过程中优缺点,改进方法等)

4、更多精彩内容欢迎关注微信公众号

2010-06-15 20:31:00 lanwilliam 阅读数 437
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

极限编程坚持只为今天的需求设计以及编码,而不用考虑明天。这颇有一些“做一天和尚撞一天钟”的意味。

这个原则带来一个问题,那就是我们还需要设计吗?

我们强调设计,其目的就在于设计出合理、优雅的结构,以提供具有良好复用性与可扩展性的系统,这是一种未雨绸缪,为未来考虑。而现在,我们若要遵循KISS原则,就是不再考虑明天的需求。显然,这两者的观点是相悖的。于是,矛盾出现:一方面我们需要保持设计简单,不做无谓的功能预测;另一方面,我们又需要拥抱变化,在尽可能少的改变结构与代码的情况之下,满足未来的需求。

如何解决这个矛盾。让我们先看看提出简单原则的初衷。在《敏捷开发思想之拥抱变化》一篇中,我提到需求的变化是不可避免的。即使是最优秀的需求分析师和架构设计师都不可能在项目之初穷尽所有客户要求的功能,作出最完美的分析与设计,即做到“增之一分则太多,减之一分则太少”。我们需要把握分析和设计的“度”。但事实却是,我们总喜欢越俎代庖,利用自己的经验帮助客户提出需求,而事后证明这些需求往往是多余的。我们总是在重复做着“吃力不讨好”的事情,与其如此,还不如在事先偷懒取巧。因为需求的变化总是不可控的,根据“利益趋避原则”,自然应选择对自己更有利的一个趋向。

但这种简单并不是“简陋”,即使我们不需要考虑明天的需求,一些好的重用原则与可扩展原则仍然需要遵循。例如,我们应尽量保证对象是高内聚、低耦合的;我们应遵循“面向接口编程”原则。一言以蔽之,我们需要做到:
1、减少依赖;

2、合理抽象;

3、功能最简。

简单设计还需要重构来保证设计的质量。我们之所以敢于奢谈“简单”,正是因为重构的保障。即使设计过于粗陋,合理利用重构也能够亡羊补牢。在重构过程中,我们仍然需要遵循简单原则,仅为当前的需求对系统结构进行重构。例如,我们在最初的需求分析中,只有一个功能要求发送电子邮件。那么,我们可以编写一个方法来封装发送电子邮件的实现,这个方法甚至可以放在业务对象的私有方法中。随着需求的逐步演进,新增的几个功能同样需要发送电子邮件,此时就有必要利用重构技术,将原来发送电子邮件的方法独立到单独的类中。但是,基于简单原则,我们没有必要完善所有功能,例如增加发送Meet Request的功能。因为目前的需求并不需要。

“简单”并不只限于设计。在敏捷开发过程中,我们还需要保证项目计划的简单,以及文档的简单,乃至于过程的简单。项目计划的简单可以由小步行进的迭代周期来保证,通过对项目阶段的分解,简化项目计划。至于文档的简单,我们完全可以抛弃复杂标准的文档模板,转而书写仅仅是自己需要关注的内容。至少,项目内部的文档完全可以言之有物,而不需要注重形式。我们还可以通过对项目过程进行裁剪,来保障过程的简单性。事实上,在极限编程中,很多原则和实践都是为了实现简单而提出的。例如计划游戏、小版本、简单设计,包括持续集成和代码所有权,都是为了提高开发过程的效率,这实际上也是简单的一种体现。

敏捷开发思想中“简单最好”是一种心态,更是一条原则。

2009-06-20 15:25:23 weixin_33882452 阅读数 14
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10426 人正在学习 去看看 CSDN讲师

秉承敏捷宣言的精神(个体与交付重于过程和工具;可用的软件重于完备的文档;客户协作重于合同谈判;响应变化重于遵循计划),我认为,敏捷开发大致应该体现如下的思想:拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。

1、拥抱变化

 

 Kent Beck和Martin Fowler在介绍极限编程(eXtreme Programming)时,最先提到的就是要拥抱变化。这基本上代表了敏捷阵营对于变化的一种态度,那就是不拒绝,而且还要主动求变。有一句经典的论断说得好:“在软件开发领域中,唯一的不变就是变化。”其实,不仅仅是软件开发领域,世间万事万物都处在永恒的变化之中,这是宇宙的基本规律。奥巴马在竞选美国总统的时候,提出的口号就是“变化”。变化才是真正的常态。

传统的软件开发过程由于过分强调文档的完整,重视与客户的谈判与签订合同。所以,开发团队最希望的一件事情是冻结需求规格说明书。只要双方签字,需求就确定下来,不可更改。若要更改,必须经过需求变更委员会,走非常严格的需求变更流程。如果软件开发真能如此,倒也算是我们开发人员的幸事。但现实总是残酷的,需求总是会变化。变化的原因有以下几种:
1)业务发生了变化;
2)客户对业务的理解发生了变化;
3)需求分析人员对需求的理解出现了偏差,需要修正。

对于第一点,或许我们还能够根据合同与客户讨价还价,而对于后两点,尤其是第三点,我们显然是不可拒绝的。而敏捷方法则要求团队随时响应客户的需求,针对变化给出相应的解决方案。

如何拥抱变化呢?我想可以通过如下方式来实现:
1)现场客户

很多开发团队并不喜欢客户对他们指手画脚,甚至认为他们不停提出的需求变化让他们疲于应对。但现场客户给团队开发带来的益处还是要远远超过他带来的坏处。无论团队中聚集了多么权威的领域专家,但真正了解客户需求的还是客户自己。也许他们很难用语言来表述自己的想法,但有了和现场客户的及时沟通,我们才能够在发生变化的初始就能够获得第一手的资讯。如果事情总要发生,早解决绝对比晚解决要好,而且要好得多。

如果在开发中,没有办法让客户成为团队的一员,那么我们也应该指定一位客户代表,退而求其次,也应该在团队中指定一位业务专家负责业务事宜,也就是Scrum中Product Owner的角色。总之,我们需要在项目开发中,能够让开发人员在对需求理解发生困惑时,能够明确地知道由谁来负责。而一旦需求发生变化,也必须有专门的角色负责向整个团队或者相关人士传达。至于业务功能的优先级和重要程度排定,也必须由这个角色指定。

2)定期迭代和小版本交付

不仅要定期迭代,而且要尽可能地让迭代周期短,并及时交付可以工作的小版本发布。XP的迭代周期通常为一周,而发布一个小版本大约是一个月。而Scrum则将迭代称之为Sprint,持续时间推荐为一个月。Sprint结束就需要向客户展示当前迭代完成的版本。

敏捷方法绝对不可闭门造车,因为需求总是可能存在二义性,且需求总是处于不断的变化中。若能定期交付一个可以工作的小版本,一方面可以给与开发团队和客户以信心,另一方面也有助于我们及时获得客户的反馈。而衍生带来的还有一个好处是我们可以免费找到最优秀的测试人员了,那就是我们的客户。如果没有现场客户,则小版本的交付则显得尤为重要,因为它给了我们及早修订错误的机会。

3)持续改进

开发过程总是会出现错误,无论是开发方法、技能,还是团队管理与团队合作。持续地改进我们的开发方法、管理方法与开发过程,才能够及时而有效地解决错误,避免重蹈覆辙。一个能够持续改进的团队是一个成长的团队,同时必然会是一个拥抱变化的团队。

在Scrum中,每个Sprint完成并结束了评审会议之后,都会召开一个回顾会议,即使总结优秀经验,检讨错误与教训,团队方能够从错误中成长起来。此外,回顾会议还能够帮助团队正确地认识自己,帮助团队成员进行交流与沟通。作为“鸡”角色的客户若能参加回顾会议,可以让客户更直观地了解团队,比提出自己的看法,有助于在后面的开发过程改善合作的质量。

敬请期待第二篇《敏捷开发思想之自我组织》

没有更多推荐了,返回首页