一、引言
敏捷软件开发一词由美国国际知名软件项目管理专家库克伯恩(AlistairCockburn)于2008年正式以书的形式向大众推广,而该概念的来源则是敏捷开发一词。在2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者的聚会上,他们共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述:
人和交互 重于 过程和工具。
可以工作的软件 重于 求全责备的文档。
客户协作 重于 合同谈判。
随时应对变化 重于 循规蹈矩。
其中位于右边的内容虽然也有其价值,但是左边的内容最为重要。
除此之外,宣言中还包括以下原则:
对我们而言,最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。经常交付可以工作的软件,从几星期到几个月,时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准。敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。简单--尽可能减少工作量的艺术至关重要。最好的架构、需求和设计都源自自我组织的团队。每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。
二、传统软件工程(瀑布模型)
瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。
瀑布模型有以下优点:
1)为项目提供了按阶段划分的检
查点。
2)当前一阶段完成后,您只需要去关注后续阶段。
3)可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4)它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型有以下缺点
1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4)瀑布模型的突出缺点是不适应用户需求的变化。
三、敏捷开发价值观
敏捷开发(敏捷建模)的价值观与极限编程的价值观十分相似,包括极限编程的四个价值观:沟通、简单、反馈、勇气。同时又扩展了第五个价值观:谦逊。
沟通:建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。
简单:画一两张图表来代替几十甚至几百行的代码,通过这种方法,建模成为简化软件和软件(开发)过程的关键。这一点对开发人员而言非常重要——它简单,容易发现出新的想法,随着你(对软件)的理解的加深,也能够很容易的改进。
反馈:Kent Beck在Extreme Programming Explained中有句话讲得非常好:“过度自信是编程的职业病,反馈则是其处方。”通过图表来交流你的想法,你可以快速获得反馈,并能够按照建议行事。
谦逊:最优秀的开发人员都拥有谦逊的美德,他们总能认识到自己并不是无所不知的。事实上,无论是开发人员还是客户,甚至所有的 project stakeholder,都有他们自己的专业领域,都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值,都应该被尊重。
四、敏捷软件开发四条原则
1、递增,而不是连续的:如果开发实践是真正的敏捷精神,那么交付的工作软件是一小部分一部分递增的。不必等到一个阶段完全完成后才开始另一个,工作也不是向大的发布日期而努力。完成的工作,但并不是业务最终期限,驱动着敏捷交付。但敏捷精神也承认业务操纵着最后截止日期。
2、避免不必要的开销:如果实践仍然是真正的敏捷精神,那么团队就致力于尽可能多地减的项目计划和文档。与其讨论要做什么,然后再写下来,不如赶紧动手云做。否则,就是在浪费时间在工作的工作上。在工作对工作中,敏捷精神有利于于实际的工——作交付工作软件。而且它也值面对面的交流通过邮件和其他书面文件。
3、协作:根据需求,团队成员一直与其它人进行交互,以及一些外部利益相关者。在敏捷教练世界中,整个团队的负责人Lisa Crispin能够解决所有问题,在问题出现之前 。真正的敏捷精神团队是自助的。他们分配需要做的工作。虽然每个成员承担的任务都在他们的专业技能范围内,他们还是需要与团队协作的。没有人的工作孤立的,也没有团队本身是独立工作的。没有业务利益相关者,以及诸如用户体验方面的外部专家的重大投入,团队就不可能使项目向前发展,
4、说真话:为保证真正的敏捷,团队探讨的与项目相关的一切都要是真实的。在一些至关重要的专业领域,如冲刺测试的编码技能,他们承认存在差距。关于实际生产力,他们的要讲事实;这也就是说,在y时间内,团队是否有能力做x。他们承认错误。说真话是一项挑战,因为我们害怕承认缺点会让我们显得很弱。但敏捷精神知道说出事实需要勇气。承认问题需要信心,然后快速地去解决问题。
五、敏捷软件开发常用工具
1、Visual Studio Team Foundation Server
TFS,即团队基础服务器是微软应用程序生命周期管理服务器,用于帮助团队在Visual Studio的协作开发。最近,它进有了升级包括工作项目执行改进、富文本编辑器的改进,以及富文本编辑器中改善的超链接体验。 TFS中的Kanban面板也做了改善,提升了可以录入和跟踪的项目数量,该服务器现在有一个“利益相关者”许可,来规范服务器的访问权限。
2、Atlassian Jira
Atlassian的是一个很流行的工具,主要用于跟踪产品开发、帮助团队整理问题、安排工具,以及记录团队行为。它Jira Agile插件使开发人员更容易部署关键敏捷策略,这包括用户故事开发、冲刺模块构建,以及可视化的团队活动。
3、Axosoft
Axosoft以前被称为Axosoft OnTime Scrum,这一软件套件有四个功能模块:Scrum、Bug追踪器、帮助台和Wiki。它是基于HTML5构建的,帮助开发团队管理待办事项列表、发布和冲刺,带有燃尽图功能,有一个 管理仪表板用于跟踪编码和修改BUG的时间。
4、LeanKit
使用 LeanKit的团队可以看到工作负载的分布并导出历史数据。最近 LeanKit 进行了一次升级,包含单点登录功能 和附加报告功能,从而提供更细粒度的数据详细信息。
5、Planbox
Planbox 敏捷管理工具通过燃尽图跟踪进程,集成客户反馈,它的目标人群很广泛。最近它对应用的前端和后端都做的升级,添加了更强大的报告功能和新仪表盘,来提升项目速度。时间跟踪特性和工具允许用户得到所有他们在Planbox产生的数据。
六、敏捷软件开发与传统软件工程(瀑布式开发)的优劣
可以说,敏捷软件开发将用户的需求作为核心,通过不断的完成一个个较小的、可用的功能并交付给用户来提高产品开发效率并提高产品开发过程中的适用性。敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。与传统软件工程(瀑布式开发)相比,敏捷方法在几周或者几个月的时间内完成相对较小的功能,强调的是能将尽早将尽量小的可用的功能交付使用,并在整个项目周期中持续改善和增强从而降低可能存在的开发风险并对有可能不断改变的用户需求进行应对。而瀑布式软件开发,则是严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。当然,两者之间也并不是完全互斥的,在使用敏捷软件开发的过程中,人们可以在小规模的范围内的每次迭代中使用瀑布式方法进行项目开发。
七、参考资料:
1、敏捷开发_百度百科 http://baike.baidu.com/view/309926.htm#4
2、敏捷软件开发_百度百科 http://baike.baidu.com/view/1124394.htm#11
3、瀑布模型_百度百科 http://baike.baidu.com/view/551037.htm
4、敏捷软件开发_必应网典 http://www.bing.com/knows/search?q=%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91&mkt=zh-cn&FORM=BKACAI