什么是敏捷?
敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。
什么敏捷软件开发?
敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。
自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。
敏捷开发简史
20世纪90年代初,一些轻量级的软件开发方法越来越受到公众的关注,这些方法包括:
1991, Rapid Application Development(RAD)
1994 Dynamic systems development method (DSDM)
1995, Scrum
1996, Crystal Clear ,Extreme Programming (XP)
1997, Feature-driven development(FDD)
这些方法论强调了开发团队和业务干系人之间的密切合作;商业价值频繁交付;紧密合作的自组织团队,以及代码匠艺、验证和交付代码的巧妙方法。
2001年,17位软件开发人员聚集在犹他州的Snowbird,讨论他们的共同想法和各种软件开发方法。经过讨论他们达成了在价值观和原则的共识,并共同发布了敏捷软件开发宣言和相应的十二条原则,宣告了敏捷开发运动的开始。
会议之后,敏捷联盟成立,鼓励业界从业者进一步探索和分享想法和经验。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法,身体力行,同时也帮助他人。由此我们建立了如下价值观:
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
敏捷开发十二原则
我们遵循以下原则:
- 我们最重要的目标,是通过及早和持续不断地交付有价值的软件使客户满意。
- 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
- 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
- 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
- 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
- 以简洁为本,它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
-
敏捷书单
敏捷管理实践系列
敏捷革命:提升个人创造力与企业效率的全新协作模式 – Scrum: The Art of Doing Twice the Work in Half the Time (作者:杰夫.萨瑟兰 Jeff Sutherland )
硝烟中的Scrum和XP – Scrum and XP from the Trenches (作者: Henrik Kniberg)
Scrum敏捷软件开发 – Succeeding with Agile (作者: 迈克.科恩 Mike Cohn)
Scrum敏捷项目管理 – Agile Project Management with Scrum (作者: 肯.施瓦布 Ken Schwaber)
Scrum精髓 – Essential Scrum (作者: 肯.罗宾 Ken Rubin)
用户故事与敏捷方法 – User Stories Applied (作者: 迈克.科恩 Mike Cohn)
用户故事地图 – User Story Mapping(作者:Jeff Patton)
精益和敏捷开发大型应用指南 – Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (作者: Craig Larman, Bas Odde)
解析极限编程 – Extreme Programming Explained: Embrace Change (作者: 肯特.贝克 Kent Beck, 辛西娅.安德烈斯 Cynthia Andres)
敏捷教练 – Agile Coaching (作者: 瑞秋·戴维斯 Rachel Davies, 丽姿·塞得利 Liz Sedley)
敏捷回顾 – Agile Retrospectives (作者: 埃斯特•德比 Esther Derby, 黛安娜•拉森 Diana Larsen)
如何构建敏捷项目管理团队 – Coaching Agile Teams (作者:丽萨•阿金斯 Lyssa Adkins)
敏捷软件开发工具-精益开发方法 – Lean Software Development : An Agile Toolkit (作者: 玛丽.玻朋蒂克 Mary Poppendieck, 汤姆.玻朋蒂克 Tom Poppendieck)
精益创业 – Lean Startup (作者:埃里克·莱斯 Eric Ries)
精益创业实战(作者:Ash Maurya)
影响地图 – Impact Mapping (作者: Gojko Adzic)
启示录:打造用户喜爱的产品 第二版 Inspired: How To Create Products Customers Love 2nd Edition (作者: 马蒂.卡根 Marty Cagan)
看板方法 – Kanban: Successful Evolutionary Change for Your Technology Business (作者: 大卫.安德森 David Anderson)敏捷技术实践系列
测试驱动开发 – Test-Driven Development (作者: 肯特·贝克 Kent beck)
敏捷软件开发:原则、模式与实践 – Agile Software Development (作者: 罗伯特.马丁 Robert Martin)
重构:改善既有代码的设计 – Refactoring: Improving the Design of Existing Code (作者: 马丁•福勒 Martin Fowler)
持续集成:软件质量改进和风险降低之道 (作者: 杜瓦尔,迈耶斯)
持续交付—Continuous Delivery(作者:Jez Humble DavidFarley)
敏捷测试 – Agile Testing (作者: 克里斯平 Lisa Crispin, 格雷戈里 Janet Gregory)
修改代码的艺术 – Working with Legacy Code (作者:Michael Feathers)
整洁代码 – Clean Code (作者: 罗伯特.马丁 Robert Martin)
实例化需求 – Specification by Example (作者: Gojko Adzic)
程序员修炼之道 – The Pragmatic Programmer: From Journeyman to Master (作者: 亨特 Andrew Hunt, 托马斯 David Thomas)
有效的单元测试 – Effective Unit Testing (作者: 科斯凯拉 Lasse Koskela)什么是SCRUM
Scrum 是用于开发、交付和持续支持复杂产品的一个框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是一至四周。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。Scrum 目前已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营,以及几乎我们(作为个体和群体)日常生活中所使用的一切。
Scrum流程如下图:
Scrum的历史
1986年,竹内弘高和野中郁次郎阐述了一种新的整体性的方法 ,该方法能够提高商业新产品开发的速度和灵活性:
- 他们将这种新的整体性方法与橄榄球相比较,前者各阶段相互重叠,并且由一个跨职能团队在不同的阶段完成整个过程,而团队“作为一个整体前进,把球传来传去”。
- 他们对来自汽车,照片机器,计算机和打印机等产业的案例进行了研究。
- 1991年,DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一书中将这种方法称为scrum,在竹内弘高和野中郁次郎的文章中提到的橄榄球术语。
- 1990年代初,Ken Schwaber在其公司使用了一种方法Advanced Development Methods(先进开发方法),这种方法后来发展为Scrum。
- 1993,Jeff Sutherland 在Easel公司开发了一种类似的方法,并首次称之为Scrum。
- 1995年,在奥斯汀举办的OOPSLA ’95上,Jeff Sutherland 和Ken Schwaber联合发表了论文首次提出了Scrum概念。Ken Schwaber和Jeff Sutherland 在接下的几年里合作,将上述的文章,他们的经验,以及业界的最佳实践融合起来,形成我们现在所知的Scrum。
- 2001年,Ken Schwaber与Mike Beedle合著了《敏捷软件开发-使用Scrum过程》一书,介绍了Scrum方法。
- 2001年,Jeff Sutherland和Ken Schwaber参与了犹他州的17人聚会,参与发布了《敏捷宣言和十二原则》。
- 2002年,Ken Schwaber和Mike Cohn创办了Scrum Alliance。
SCRUM框架
Scrum框架包括3个角色、3个工件、5个事件、5个价值:
3个角色
- 产品负责人(Product Owner):
- Scrum Master
- 开发团队
3个工件
- 产品Backlog(Product Backlog)
- SprintBacklog
- 产品增量(Increment)
5个事件
- Sprint(Sprint本身是一个事件,包括了如下4个事件)
- Sprint计划会议(Sprint Planning Meeting)
- 每日站会(Daily Scrum Meeting)
- Sprint评审会议(Sprint Review Meeting)
- Sprint回顾会议(Sprint Retrospective Meeting)
5个价值
- 承诺 – 愿意对目标做出承诺
- 专注– 把你的心思和能力都用到你承诺的工作上去
- 开放– Scrum 把项目中的一切开放给每个人看
- 尊重– 每个人都有他独特的背景和经验
- 勇气– 有勇气做出承诺,履行承诺,接受别人的尊重
SCRUM理论基础
Scrum以经验性过程控制理论(经验主义)做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下:
第一:透明性(Transparency)
透明度是指,在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面,而且必须理解他们看到的内容。也就是说,当某个人在检验一个过程,并确信某一个任务已经完成时,这个完成必须等同于他们对完成的定义。
第二:检验(Inspection)
开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差。在确定检验频率时,需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度,那么就会出现问题。幸运的是,软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
第三:适应(Adaptation)
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应:每日例会检验Sprint目标的进展,做出调整,从而优化次日的工作价值;Sprint评审和计划会议检验发布目标的进展,做出调整,从而优化下一个Sprint的工作价值;Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意,并且工作更快乐。