Windows讨论区

找论坛
淺笑那段情533
Lv4 太平洋舰队中尉
太平洋舰队中尉 贡献398,距离下一级还需302贡献
楼主
2019-11-15 15:20 0 0 只看楼主
电梯直达 

?做软件开发的同鞋可能都或多或少的听说过敏捷开发,但是实际采用这种开发模式的项目场景可能就比较少了,今天针对敏捷开发能实际解决的问题做一个基本的介绍,让有兴趣的小伙伴能对敏捷开发的内涵有个基本的认识。
评论
软件开发存在些什么问题?
硬体世界的突破与发展速度逐渐趋缓,软体世界的需求扶摇直上,面对环境的瞬息万变,再加上对各类软件质与量上的快速需求,以往有时间慢慢处理的问题,越来越难以即时处置,例如:
.客户连需求都讲不清楚,分析师只好也不清不楚的混过
.客户的需求一变再变,设计也只好一改再改
.开发时程的估计有两种方法:掷茭 & 闭着眼睛喊
.项目准时关闭?你求神保佑吧…
.加班是必需的,伤肝是正常的,谁叫你入错行
.我们PM的全名是Post Man,把客户的邮件转寄工程师,再把工程师的邮件回寄客户
.那个谁谁谁呢?唉!人又被其他项目拉走了…
.交付给客户的每个版本,开发周期越来越长,却依然觉得时间紧迫
.无法依据原始规划,如期产出最终成品
.版本交付时,仍存在明显缺陷,双方都不满意
.开发时间很长,过程中需求不断变化,致使初始规划显得很不正确
.规划赶不上变化,新的需求很难加入原始规划中
.为能如期达交,往往开发人员会牺牲质量
.极重的开发压力,让所有人员心情沉重,士气受创
为何要导入敏捷开发?
原有的设计流程通常是预测性(Predictive)或称顺序式(Sequential)的设计流程,它启动时的假设情境是—已建立完整的愿景,愿景中所有的需求均已定义清楚,同时已策划出实现愿景的详细计划(战术),换言之,原有的设计流程是基于下列假设条件而进行规划的:
需求不会变更,而且已被完全理解,所以设计初期就应明确所有需求。
项目开始前,即可确认预计要采用的「技术」,该技术是足够的且能发挥正常功效以完成整个设计。
“人”可以像机器一样可预测并且能够可靠工作。
只有计划能以“精准并且保持需求不变”的情境为前提,开发前期用于计划的投入才有价值。
评论
可惜的是,某些设计项目,在期初通常只有大方向,客户往往也难以清楚表示“需求”,随着开发的进程,客户越懂越多,以前没想到的需求往往就会随时浮现。同时,新的技术层出不穷,可能真正要开发时,该项软体技术已经过时。再加上开发人员的认知、技术、传达、构思方式不仅人人不同,甚者,不同时间也会出现差异。这些林林总总的噪音加进来,让过往著重初始规划,与规划完成后才进行分工设计的模式,不仅在开发前期投资很高,也感觉初始规划显得很不正确。
敏捷开发适用于实体产品的开发吗?
在项目开发过程中,有几个主要的情况,是难以采用敏捷开发的,包含:
在价格竞争的环境下,若试运行或塑模(Modeling)成本过高,我们是难以取得此项成本。
敏捷开发主要的精神在于较短的开发循环(建立在反复式开发方式上)以及渐进式开发与交付。若试运转的时间过长或取得运作结果的时效过慢,发现问题时可能机会已然失去。
顾客对产品缺陷的容忍度极低。如果今天你买了一辆汽车,每半年叫你回原厂做一次调整,你愿意吗?但观察近年上市的软件,都是初版发行后,会不断的调适(debug)与升级,这也不知道是我们使用者真的拥有较大的容忍度,还是已被厂商洗脑而认为这是正常的。
所以敏捷开发较适用软件开发,又称为敏捷软体开发。对于其他开发,虽然无法一体适用,但敏捷开发中所推荐的一些观念与工具,仍可引用在其他类型的开发项目上,增进开发的绩效。
评论
敏捷开发的发展
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的开发与验证。每个迭代都具有跨功能的团队,包含了规划、分析、设计、程序编码、单元测试和验收测试。在迭代结束时,将工作产品向利益相关者展示。透过上述方式让整体风险分散与降低,并使产品能够快速获得反馈与适应变化。
迭代的方式,可能不会一次增加足够的功能来保证可立即发布使用,但是目标是在每次迭代结束时,有一个可用的发行版(最小化程序缺点)。
完整产品的发布或新功能可能需要多次迭代。
评论
敏捷开发的框架
如同我们所熟知改善活动有许多不一样的手法,如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做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。
评论
持续集成(Continuous Integration)与客户参与(Customer Engagement):敏捷开发中提倡持续集成,短时间(一天之内十几次甚至几十次)的集成,由于集成很频繁,每一次集成的改变也很少,开发过程中有什么问题或者产品经过一轮迭代后,能够以最快速度得到客户的反馈,即使集成失败也容易定位错误。
小版本发布(Frequent Releases):在敏捷开发中,希望而是尽量多的产品发布频率,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。
较少的文档(Minimal Documentation):简单可读的代码才是好的代码,我们的理想为,所写的东西别人一看就能够看懂。故而很少需要对代码进行补充注释。
公开与合作(Collaborative Focus),在敏捷开发中,每个人都有权力获得系统任何一部分的代码,基于互信与合作原则对系统进行优化。这样每个人都能熟悉系统的代码,即使团队的人员变动,风险也低。
自动化测试(Automated Testing):由于需要频繁的迭代与验证回馈,测试的时间与成本势必增加, QA人员则需要有自动化测试的开发能耐。
最后,奉上案例:learun.cn
原文:windy

您需要登录后才可以发帖 登录 | 立即注册

其他登录方式:

常用表情
太平洋电脑网论坛帖子仅代表作者本人意见,不代表网站立场。请勿轻信特价、汇款、中奖等信息,
请勿轻易透露个人资料,因此产生的一切后果,PConline不承担任何责任
回复 发新帖 找论坛 反馈 回顶部