敏捷与Scrum-1-概念与历史


转载 https://blog.csdn.net/ry513705618/article/details/50755283
转载 https://www.scrumcn.com/agile/scrum-knowledge-library/agile-practices-timeline.html
转载 http://www.360doc.com/content/10/0313/18/532901_18630280.shtml
转载 https://zhuanlan.zhihu.com/p/98212370

软件交付危机

1970年至1990年是软件工程的基础理论和实践的爆发时期,当时的基本思路是将软件工程等同于物理工程,并尽可能在设计和构建过程中借鉴物理工程项目的管理理论与方法,最终产生了大家都熟悉的瀑布模型。这个过程完整定义了软件从需求到部署的全生命周期的各个阶段,之所以被称为瀑布是因为它要求团队在完成下一步骤之前必须已经完成了上一个步骤:在进行功能设计之前必须先完成需求分析,在详细设计之前必须先完成功能设计,以此类推。

这种方法给管理者带来了可以像控制制造业项目一样控制软件项目的错觉,那就是花在计划上的时间越多,花在编写代码上的时间就越少,并且代码越好。这增加了更多繁重的过程和方法,与交付可用软件相比,该方法更加注重计划和文档编制。并且这个过程大家忽略了一个关键的问题:在十年或更长时间里,机械或土木工程项目很少发生大的变化,例如您今天设计的桥梁很少会在一两年内发生大的变更,而软件项目则完全不一样。软件项目很少能具有和传统工程项目一样的稳定性,业务需求可能在一夜间发生很大变化,而我们完成一个软件的周期至少需要几个月甚至几年的时间,我们如何面对随时可能出现的变化呢?很明显软件工程需要一种不同以往的管理方法。

另一个问题是软件设计既是一个学科又是一门艺术,受人的因素的影响。人们可能根本不清楚如何能更好的定义软件,用户可以描述他们的工作流程,但不一定能清晰的告诉软件设计人员如何将这部分工作自动化及这些功能应该如何工作。我们必须接受一个事实:我们根本无法在构建产品之前精确定义所需的各种功能需求,这是软件工程与大多数其他工程项目的根本区别

到90年代初期,随着PC在企业中的逐渐普及,市场对定制化软件开发的需求越来越大,同时软件项目管理方法也遇到了前所未有的挑战,这种危机经常被称为”软件开发危机“,表现为软件系统交付的严重滞后。据当时的行业专家估计,一个软件项目从需求确定到软件交付需要经历大概三年左右的时间,这已经很难满足当时企业的快速发展需求,在三年里可能整个业务都发生了根本性变化,这意味着很多项目都不得不因为市场和业务的变化而被取消或延期,即使勉强交付了也可能已经无法满足企业的现实需求。

敏捷诞生

事实上,人们最初设想是如何可以更好的接受及处理变更决策,让瀑布模型具备退回到上一步的能力,并作出一些决策和期望的调整,然后实际上由于工期和预算的限制使这变得几乎不可能执行,团队必须坚持早期决策才能确保在预算和给定时间内完成工作,团队会条件反射一样拒绝变化

越来越多的行业领导者认为必须有更好的软件构建方法来改变这一切,他们期望能更快速构建可以工作的软件并将其交付最终用户,这会带来两个重要的好处:

  1. 它使用户能更快的获取软件带来的一些商业利益。
  2. 它可以让团队能够更早获得有关软件范围和方向的快速反馈,这在后来被看做敏捷的一个最关键特征。

最终2001年初在犹他州的Snowbird召开了那次重要的会议,会议小组成员包括Kern,极限编程先驱Kent Beck和Ward Cunningham,Arie van Bennekum,Alistair Cockburn以及其他十二个人,这些人在敏捷社区中是众所周知的明星。这次会议后他们发表了著名的敏捷宣言,随着敏捷宣言的发表,Agile这个词开始在全世界传播,其中最为大家熟知的敏捷方法应该就是Scrum和XP了,大多数声称实践敏捷方法的团队都说他们正在使用Scrum。

敏捷宣言 http://agilemanifesto.org/

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agile Manifesto
We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need,and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile is a set of values and principles
Reference Videos
https://www.bilibili.com/video/BV1oW41157UC/?spm_id_from=333.788.videocard.0
https://www.bilibili.com/video/BV1KW411T7Vw/?spm_id_from=333.788.videocard.8
https://www.bilibili.com/video/BV1xt411Y795?from=search&seid=15871455465957536348

Agile与Scrum的关系

Scrum是敏捷过程中的众多方法之一。您可以将敏捷视为一个涵盖其他过程的总称,例如极限编程、自适应系统开发、DSDM、功能驱动开发、看板、Crystal等等。

您可以自定义敏捷过程以更好地适应您的团队。例如,您可以选择主要使用Scrum,但同时也使用其他敏捷方法的一些功能。例如,许多使用Scrum的团队也采用测试驱动开发和结对编程,这两者都是极限编程的一部分。敏捷过程的灵活性是其吸引力的很大一部分。

Scrum 起源

Scrum含义
Scrum悠久的历史可以追溯到1986年《哈佛商业评论》中的一篇文章,题为“新型新产品开发策略”[ 编注:The New New Product Development Game,竹内弘高、野中郁次郎,1986。]。这篇文章描述了像本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的“蜂涌式”[ 编注:all-at-once product development,也称“一起上”,指齐心协力一起完成某项工作的集体行为。]开发世界一流的产品。文章同时强调了授权、自组织团队的重要性,并概要描述了管理在开发过程中发挥的作用。

这篇发表于1986年的文章产生了很大的影响,文章中提出的很多概念都促成了我们今天称为Scrum的方法。Scrum不是缩写,它借用的是橄榄球运动的术语。在橄榄球运动中,这个术语指的是在意外犯规或球出界后重新开始比赛。就算你不是球迷,也该见过争球,两个队的前锋在球前面围成一圈,彼此的胳膊架在一起,低头争夺球权。
在这里插入图片描述
视频 https://weibo.com/tv/show/1034:4512756804812806?from=old_pc_videoshow

Scrum首次应用于产品开发
1986年,竹内弘高和 野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发,他们指出:传统的“接力式”的开发模式已经不能满足快速灵活的市场需求,而整体或“橄榄球式”的方法——团队作为一个整体前进,在团队的内部传球并保持前进,这也许可以更好的满足当前激烈的市场竞争。

Scrum首次应用于软件开发
敏捷思想深受日本工业界最佳实践的影响,尤其是丰田和本田公司推行的精益原则,以及竹内弘高和 野中郁次郎开发的知识管理策略。受到以上思想的影响,以及对世界范围内软件项目的研究,

90年代初,Jeff Sutherland和Ken Schwaber在初构想了Scrum管理过程,
1995年, 对Scrum框架进行了梳理并发表了文章“ Scrum Software Development Process”,并在美国德克萨斯州奥斯汀举行的OOPSLA会议上完整介绍了这一框架。
2001年,敏捷宣言及原则发布、敏捷联盟成立,Scrum是其中一种敏捷方法。
2001年,Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。
2002年,Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。

Ken和Jeff从两位公认的管理思想家Takeuchi和Nonaka于1986年发表的论文“ The New New Product Development Game”中继承了“ Scrum”的叫法。Nonaka和Takeuchi用“ Scrum”一词强调团队的重要性以及橄榄球等团队运动与成功开发新产品之间的类比关系。他们的研究表明,当小型的,自组织的团队努力去满足目标而不是任务时,就可以在开发复杂的新产品方面取得出色的效果。最好的团队是那些有方向的团队,他们有自己的空间来制定自己的策略,以最佳的方法实现共同目标。团队需要自治才能实现卓越。而Scrum软件开发框架正是实现了用文中描述的理论来开发和维护复杂软件产品的原理和方法。

Scrum是一个Empirical Process(与DefinedProcess相对),在开发和使用早期版本的Scrum的过程中,Ken曾请求著名的过程控制研究工程师Babatunde A. Ogunnaike Tunde教授研究软件开发过程。Tunde研究了几种流行的商业软件开发方法,得出的结论是瀑布式和预测性过程并不适合软件开发工作。他证实了Scrum所倡导的经验性方法是首选的过程。经验主义多用于完成复杂的工作,由于大多情况下复杂工作中未知的事情多于已知的事情,并且变化和不确定性很高,这就使得预测的价值变得很小。

随着Scrum的发展,互联网上散布着各种有关Scrum的理论和主张,这使我想起盲人摸象的故事。Sutherland认为Scrum是一个框架,其中包含了过去五十多年人们所发明的各种最佳实践,能找到最适合你的那组实践才是事情的关键.

Ken曾经说过:“不加调整地盲目应用任何技术都是有害的”,并将Scrum与下棋做了一个很好的类比:“框架”一词的含义是没有指定太多细节,必须由使用框架的人员来决定如何做,我把Scrum等同于象棋游戏,您可以阅读国际象棋的官方规则手册,学习他们,然后您可以下棋,但是你离成为一个国际象棋大师还有很长的路要走。

自1995年首次发行至今,Scrum已被全球众多软件开发公司所采用。今天,它被认为是敏捷软件开发中应用最广泛的框架。在Scrum上已经出版了1000多本书,该方法也已经成功地应用于其他领域,例如:制造,营销,运营和教育

REF 1 - Agile编年史

https://www.scrumcn.com/agile/scrum-knowledge-library/agile-practices-timeline.html

REF 2 - Scrum编年简史

  • Scrum首先在Individual,Inc.,Fidelity Investments和IDX(现为GE Medical)中进行了尝试和完善。
  • 在2001年2月,Jeff和Ken参与“敏捷宣言”签署,是签署宣言的17位软件开发大师之一。发表敏捷宣言后,成立了敏捷联盟,Ken Schwaber担任第一任主席。
  • 2001年,受肯特·贝克(Kent Beck)的启发,肯·施瓦伯(Ken Schwaber)与迈克·比德尔(Mike Beedle)合著了第一本关于Scrum的书《Agile Software Development with Scrum》。
  • 2002年,Ken Schwaber与Mike Cohn和Esther Derby共同创立了Scrum联盟,由Ken主持该组织,在随后的几年中,创建并发布了非常成功的ScrumMaster认证体系及其衍生产品。
  • 2006年,Jeff Sutherland创立了自己的公司Scrum.inc,继续教授Scrum认证课程。
  • Ken在2009年秋天离开了Scrum联盟,并创立了Scrum.org,主要是通过Professional Scrum系列培训进一步提高了Scrum的质量和有效性。
  • Jeff和Ken在2010年首次发布《 Scrum指南》,并在2011年、2013年、2017年对其进行了逐步更新,从而建立了全球认可的Scrum知识体系。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值