learun666 阅读(101) 评论(0)

 

​做软件开发的同鞋可能都或多或少的听说过敏捷开发,但是实际采用这种开发模式的项目场景可能就比较少了,今天针对敏捷开发能实际解决的问题做一个基本的介绍,让有兴趣的小伙伴能对敏捷开发的内涵有个基本的认识。

http://img1.mukewang.com/5dce11f20001580306400427.jpg

软件开发存在些什么问题?

硬体世界的突破与发展速度逐渐趋缓,软体世界的需求扶摇直上,面对环境的瞬息万变,再加上对各类软件质与量上的快速需求,以往有时间慢慢处理的问题,越来越难以即时处置,例如:

.客户连需求都讲不清楚,分析师只好也不清不楚的混过

.客户的需求一变再变,设计也只好一改再改

.开发时程的估计有两种方法:掷茭 & 闭着眼睛喊

.项目准时关闭?你求神保佑吧…

.加班是必需的,伤肝是正常的,谁叫你入错行

.我们PM的全名是Post Man,把客户的邮件转寄工程师,再把工程师的邮件回寄客户

.那个谁谁谁呢?唉!人又被其他项目拉走了…

.交付给客户的每个版本,开发周期越来越长,却依然觉得时间紧迫

.无法依据原始规划,如期产出最终成品

.版本交付时,仍存在明显缺陷,双方都不满意

.开发时间很长,过程中需求不断变化,致使初始规划显得很不正确

.规划赶不上变化,新的需求很难加入原始规划中

.为能如期达交,往往开发人员会牺牲质量

.极重的开发压力,让所有人员心情沉重,士气受创

为何要导入敏捷开发?

原有的设计流程通常是预测性(Predictive)或称顺序式(Sequential)的设计流程,它启动时的假设情境是—已建立完整的愿景,愿景中所有的需求均已定义清楚,同时已策划出实现愿景的详细计划(战术),换言之,原有的设计流程是基于下列假设条件而进行规划的:

需求不会变更,而且已被完全理解,所以设计初期就应明确所有需求。

项目开始前,即可确认预计要采用的「技术」,该技术是足够的且能发挥正常功效以完成整个设计。

“人”可以像机器一样可预测并且能够可靠工作。

只有计划能以“精准并且保持需求不变”的情境为前提,开发前期用于计划的投入才有价值。

http://img2.mukewang.com/5dce11fd00017d8506400427.jpg

可惜的是,某些设计项目,在期初通常只有大方向,客户往往也难以清楚表示“需求”,随着开发的进程,客户越懂越多,以前没想到的需求往往就会随时浮现。同时,新的技术层出不穷,可能真正要开发时,该项软体技术已经过时。再加上开发人员的认知、技术、传达、构思方式不仅人人不同,甚者,不同时间也会出现差异。这些林林总总的噪音加进来,让过往著重初始规划,与规划完成后才进行分工设计的模式,不仅在开发前期投资很高,也感觉初始规划显得很不正确。

敏捷开发适用于实体产品的开发吗?

在项目开发过程中,有几个主要的情况,是难以采用敏捷开发的,包含:

在价格竞争的环境下,若试运行或塑模(Modeling)成本过高,我们是难以取得此项成本。

敏捷开发主要的精神在于较短的开发循环(建立在反复式开发方式上)以及渐进式开发与交付。若试运转的时间过长或取得运作结果的时效过慢,发现问题时可能机会已然失去。

顾客对产品缺陷的容忍度极低。如果今天你买了一辆汽车,每半年叫你回原厂做一次调整,你愿意吗?但观察近年上市的软件,都是初版发行后,会不断的调适(debug)与升级,这也不知道是我们使用者真的拥有较大的容忍度,还是已被厂商洗脑而认为这是正常的。

所以敏捷开发较适用软件开发,又称为敏捷软体开发。对于其他开发,虽然无法一体适用,但敏捷开发中所推荐的一些观念与工具,仍可引用在其他类型的开发项目上,增进开发的绩效。

http://img1.mukewang.com/5dce1208000152df06400427.jpg

敏捷开发的发展

2001年,十七名软件开发人员聚会(因在美国犹他州的雪鸟度假村,俗称雪鸟会议)讨论1957~1997年间的一些让开发不那么沈重的方法与框架,并由Jeff Sutherland,Ken Schwaber和Alistair Cockburn起草,一同发布了「敏捷软件开发宣言」。

2005年,由Alistair Cockburn和Jim Highsmith领导的小组编写了一份项目管理原则的附录,即「相互依存声明」,以便根据敏捷软件开发方法来指导软件项目管理。

2009年,Robert C Martin编写了软件开发原则的扩展,即软件工艺宣言(Software Craftsmanship Manifesto),根据职业行为和掌握程度来指导敏捷软件开发。

2011年,敏捷联盟建立了敏捷实践指南、敏捷实践、术语和元素工作定义的演化开放式汇编,以及来自敏捷从业者社群的经验指南。

2016年,将敏捷实践指南进行调适并更名为「敏捷词汇」

敏捷开发的基本精神

将产品开发工作细分微小化,因此大大的减少了前期规划和设计的数量。

运用迭代(冲刺)这种短时间(1周~1月)的运作的模式来进行1至数个Story的开发与验证。每个迭代都具有跨功能的团队,包含了规划、分析、设计、程序编码、单元测试和验收测试。在迭代结束时,将工作产品向利益相关者展示。透过上述方式让整体风险分散与降低,并使产品能够快速获得反馈与适应变化。

迭代的方式,可能不会一次增加足够的功能来保证可立即发布使用,但是目标是在每次迭代结束时,有一个可用的发行版(最小化程序缺点)。

完整产品的发布或新功能可能需要多次迭代。

http://img.mukewang.com/5dce12100001019919200922.jpg

敏捷开发的框架

如同我们所熟知改善活动有许多不一样的手法,如QC Story、8D、VA/VE、Lean、DMAIC、DMADV‧‧‧等多种不同类型的框架,敏捷软件开发的框架也因派别与视角的差异而有持续的发展,例如:自适应软件开发(Adaptive software development,ASD)、敏捷建模(Agile modeling)、终极程序设计(eXtreme Programming :XP)、迅速应用程序开发、统一处理程序与动态系统开发法(DSDM)、Scrum法、看板(Kanban)法、水晶清透法(Crystal)、功能驱动开发(Feature Driven Development: FDD) ‧‧‧,其中Scrum法是目前看到最广泛被使用的敏捷开发框架。

敏捷开发的几个重要作法

每个框架的发展都有其自成系统的工具与之搭配,真的是族繁不及备载,此处仅列出几个在Scrum中较具特色的管理方法(此处不涉及软体设计的专业技术):

迭代和增量式软件开发:此为相对于传统「瀑布式开发」的对立作法,瀑布式开发认为初期应有明确的需求与目的,故先做好完整的规划,将总体目标分拆给不同的群体,各自群体努力工作,完成子系统,然后汇总进行测试。我借用一本书(敏捷开发的逆袭) 的作者Teddy Chen 的比喻来描述两种不同的模式:切一块蛋糕给人享用,应是纵切的,每块蛋糕都有鲜奶油层、蛋糕层、水果层、布丁层‧‧‧(敏捷开发推荐运用基本版本+多次的迭代版本的发布方式,让顾客拿到的每个版本都是可以实际使用的)。而不应该横切,单吃奶油或单吃布丁层,没人会觉得吃到的是成品蛋糕。不幸的是,在很多时候,我们的开发设计,往往采用横切法:需求定义>设计规划>概念设计>各自分工从事细部设计>模型建置>汇整测试>设计修正>原型测试>放行。

非常短的返馈回路和适应周期:敏捷的 Stand up(站立会议)或日常scrum作法,运用简短的会议,让团队成员相互报告他们前一天(或阶段)对于团队的迭代(或阶段)目标与成果、今天(或阶段)打算做的目标以及他们可以看到的任何障碍或阻碍,进行资源调配与设计对应方案。频繁的讨论与分享,一有问题大家就会知道,也有可能获得回馈,人员也不致觉得太孤单。

测试引导开发与结对编程(Pair-Programming):对由业务需求进行分析,分解为不同的Story。然后两个人同时对某一Story进行运作,经过讨论取得共识后,先由一人建构测试代码,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。Pair做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。

http://img.mukewang.com/5dce121800017a1e15550839.jpg

持续集成(Continuous Integration)与客户参与(Customer Engagement):敏捷开发中提倡持续集成,短时间(一天之内十几次甚至几十次)的集成,由于集成很频繁,每一次集成的改变也很少,开发过程中有什么问题或者产品经过一轮迭代后,能够以最快速度得到客户的反馈,即使集成失败也容易定位错误。

小版本发布(Frequent Releases):在敏捷开发中,希望而是尽量多的产品发布频率,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。

较少的文档(Minimal Documentation):简单可读的代码才是好的代码,我们的理想为,所写的东西别人一看就能够看懂。故而很少需要对代码进行补充注释。

公开与合作(Collaborative Focus),在敏捷开发中,每个人都有权力获得系统任何一部分的代码,基于互信与合作原则对系统进行优化。这样每个人都能熟悉系统的代码,即使团队的人员变动,风险也低。

自动化测试(Automated Testing):由于需要频繁的迭代与验证回馈,测试的时间与成本势必增加, QA人员则需要有自动化测试的开发能耐。

最后,奉上案例:learun.cn

原文:windy


发表评论
切换编辑模式