敏捷开发方法学及应用
简介
本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也适用于团队领导人,项目经理,产品经理,开发经理,测试人员,质量保证经理,质量保证工程师,技术作者,用户体验设计者,以及任何与制做发布软件相关的人员。本文着重于技术团队怎么很好的合作去计划,开发并发布软件。本文不着重于编码,技术细节或微软工具。希望本文能改善你的专业生活和团队效率。
背景
无论项目有多大有多复杂,有两个关键的步骤常用于所有的计算机程序开发:1) 分析 2) 编码。
接下来,Winston Royce介绍了最重要的五步:
第一步:程序设计
第二步:撰写设计文档
第三步:重复两次
第四步:计划,控制,监控测试
第五步:让客户参与
- 每一阶段都应该迭代式地传递到下一阶段。
- 软件发布前对软件整体流程实践两次。
- 简单单一的阶段传递会造成项目失败。
敏捷软件开发宣言
- 个人与交互 高于 流程和工具
- 可用软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
也就是说,上面右侧(蓝色字体)内容有其价值,但我们更重视左侧(红色字体)产生的价值。
敏捷宣言的十二条原则
- 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
- 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
- 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
- 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
- 以简洁为本,它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效,并依此调整自身的举止表现。
DSDM
- 用户参与
- 迭代和递增开发
- 提高了发布频率
- 集成测式于每一阶段
- 已发布产品的可接受程度直接取决于需求的实现
FDD
Lean
七大Lean软件开发原则:
- 估算浪费
- 构建质量
- 创建知识
- 延迟承诺
- 快速交付
- 尊重人
- 优化整体
Plan(译外话:指瀑布式开发Waterfall Development)
Plan VS Agile
- 都提供了操作流程,操作工具和操作技术。
- 都需要严格的有条不紊的方法进行软件开发。
- 都各自有优缺点。
- 敏捷开发适合的情况,计划驱动模型不一定适应。
- 敏捷开发强调流程上的不同。
- 计划驱动模型强调正式的沟通与控制。
- 敏捷开发强调连续的沟通和处理变化的能力
- 计划驱动模型是关卡式控制质量,敏捷开发是高迭代式开发确保质量。
- 计划驱动模型仅在产品最终完成后进检查,敏捷开发每完成一小块工作就进行检查。
- 计划驱动模型以预估什么将被交付为起点,敏捷开发以完成一个需求为目标做为起点
强调人和互动要高于强调流程和工具。
可用软件频繁的被交付使用(按周交付高于按月交付)
业务人员和开发者保持近距离的,日常的协作。
持续关注出色的技术和设计。
适应易变情况。
需求中较晚的改动也受欢迎。
善于使用计划驱动模型的管理团队同样也能够善于使用敏捷开发方法。
缺乏能力使用计划驱动模型的管理团队也没有能力使用敏捷开发方法。
敏捷开发Agile
敏捷软件开发的原理和价值用于帮助团队打破流程循环膨胀,着重于用简单的技术去实现目标。目标?什么是目标?
每一个软件开发者,开发团队的主要目标是为老板和客户制造尽可能高的价值。
- 改善的质量
- 在项目过程中有更多的机会做出修改更正
- 提高客户或商业满意度
- 使业务和IT更好的组合在一起
- 更优化的面向市场的时间
敏捷开发使用者从来不会害怕变化。他们把需求变化看作是好事,因为这些变化意味着团队又收获了更多关于怎样满足客户的经验。敏捷开发团队成员一起协作项目的方方面面。每一个成员都允许为项目整体提出意见或做贡献。没有一个团队成员是单一的负责架构或者需求或者测试。团队分享这些责任,同时每个成员都会对它们产生影响。
我们有很多的敏捷开发流程:Scrum,crystal,BDD(Behavior-Driven Development行为驱动开发),TDD(Test-Driven Development测试驱动开发),FDD(Feature-Driven Development功能驱动开发),ADP(Adaptive Software Development自适应软件开发),XP(Extreme Programming极限编程),等等等等。然而,大量成功的敏捷开发团队从所有这些方法中吸取经验与知识,进而调整生成他们自己特有的敏捷开发方式。这些改编后的方法通常与SCRUM还有XP组合在一起,SCRUM实践用来管理使用极限编程XP的团队。
极限编程XP
作为开发者,我们需要记住极限编程并不是城里唯一的游戏。
极限编程强调团队合作(经理,客户,开发者)。它从五个关键点改善软件项目:沟通,简明,反馈,尊重,还有勇气
维基百科对极限编程的定义:极限编程XP是一种软件开发方法,它的意图是提搞软件质量及对用户需求变化的响应能力。作为一种敏捷软件开发方法,它提倡在短开发周期中频繁地发布,从而提高软件生产力并提出新客户需求能够被采纳的检查点。
极限编程是一系列嵌入到敏捷开发中的简易并坚实的实践。极限编程是一个非常好的通用软件开发方法。许多项目团队都采用它,同时更多的团队通过添加或修改实践来把它变得更适用。
- 它是大多数敏捷开发方法的始祖
- 在90年代末期和21世纪初期,Kent Beck提出了热门的话题
- 协调流程与实践
- 采取已关注过的有效团队实践
- 迫使它们走向极端
出色的实践 | 迫使它走向极端 |
---|---|
代码复查 | 结对编程 |
测试 | TDD测试驱动开发和常数回归 |
软件设计 | 不停地重构 |
简单 | 最简单的事会有意想不到的效果 |
集成测试 | 不断的集成/整合 |
短迭代 | 把制定计划当作游戏 |
在所有敏捷开发方法当中,极限编程是唯一的一种方法为开发者的日常工作提供深度的,意义深远的开发准则。在这些准则中,测试驱动开发是最革命性的。下图中都是一些出色的极限编程实践。
Scrum
- 1986年,Scrum第一次被定义成一个灵活的全面的产品开发策略。--Hirotaka Takeuchi,Ikujiro Nonaka
- 1995年,Sutherland和Schwaber共同地发表了一篇关于Scrum方法学的论文。
Scrum角色
- 产品持有人 Product Owner
- 开发团队 Development Team
- Scrum领导人 ScrumMaster
产品持有人 Product Owner
- 产品持有人代表着公司或股东的权益并传递客户的声音。
- 专门负责确保商业价值
- 制定以客户为中心的一些工作条目,排序后放到产品待处理列表(Product backlog)中。
- Scrum团队应该有一个产品持有人,他/她也可以是开发团队中的一员。
- 产品持有人不是Scrum领导者(ScrumMaster)。
开发团队 Development Team
- 在每一个Sprint周期结束后,负责交付将来需要发布的产品的模块。
- 由3到9人组成并拥有各种所需技能(分析,设计,开发,测试,技术沟通,文档,等等)。
- 自我组织,有可能需要与更高级的项目管理部门交流。
Scrum领导人 ScrumMaster
- 专门负责扫清团队在交付Sprint目标或产品中遇到的障碍。
- 不是团队领导人,但是扮演着团队与可能分散团队注意力的影响之间的缓冲区。
- 确保Scrum流程的使用在计划中。
- 规则强制执行人。团队保护者,以保持团队专注于他们手中的工作。
- 也会被看作一个人民公仆去加强这些双重观点。
- 不同于一个项目经理,没有与ScrumMaster不相关的人员管理职责
- 没有任何额外的员工责任。
Backlog未完成项列表
产品的待完成项列表是一个需求的排列列表,我们维护这个列表是为了更好的开发产品。它的组成有功能,BUG修复,非功能需求等任何为了成功发布可用软件系统的所必须的内容。在Scrum中,开始一个项目不必先开发一个冗长文档去记录所有的需求。这个敏捷产品backlog对于第一个Sprint足够了。当有更多产品需求时和客户需求时,Scrum产品backlog允许变更和增加。
Sprint backlog是开发团队下个Sprint需要处理的工作列表。这个列表是产品backlog最上面的需求项衍生出来的,直到开发团队在这个Sprint中有足够的工作去做。开发团队通过问一些问题来完成backlog的选择,如“我们是不是也能做这个?”。
敏捷开发调查
谁知道敏捷开发?
敏捷开发失败原因
进一步使用敏捷开发的障碍物
使用敏捷开发最大的担心
总结
"In preparing for battle I have always found that plans are useless, but planning is indispensable." - General Dwight David Eisenhower
局限于别人的方法世界里不是可取的,因为公司需求,公司情况,项目都有可能一直在变化着。如果你想你的项目成功,你一定要灵活地应用这些现成的方法去管理项目。 任何单一的方法都不是一把尚方宝剑,因此关键是看哪种方法适合你并能协调你的方法去满足你的个人需求。
记住,Scrum和Agile不是一个死产品 ,它是在持续改进的基础上不断进行中的一门哲学。
翻译:http://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t