2016-08-29 15:22:41 myhead756 阅读数 5444
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

最适合App的开发模式——敏捷开发

 

传统的软件开发模式需要经历问题评估、计划解决方案、设计系统架构、开发代码、测试、部署和使用系统、维护解决方案等过程,如下图




采用传统软件开发模式的最大问题是开发周期过长,迭代速度慢。移动互联网行业发展速度快,需求不断变化,产品更新迭代的频率高,基于移动互联网的以上特点,就引入了Scrum这个敏捷开发框架。

 

Scrum简介:Scrum是一个敏捷开发框架,是一个增量的,迭代的开发过程。在这个框架中,整个开发周期包括若干个小的迭代周期,每个小的迭代周期成为一个Sprint,每个Sprint的周期建议为2~4周。在Scrum中,使用产品Backlog来管理产品或项目的需求,产品Backlog是一个按照商业价值排序的需求列表。在每个迭代过程中开发团队从产品Backlog挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint会议上的分析、讨论和估算得到一个Sprint的任务列表,称为Sprint Backlog

 

Scrum的流程如下图↓

 

Sprint 计划会议

Sprint计划会议前,产品经理所要实现的产品需求(产品Backlog)以用户故事(即从用户的角度去描述用户所需的功能)的形式确定下来,并画出原型图,UI根据原型图完成设计稿。产品经理同时确定各个产品需求的优先级。

Sprint计划会议期间(一般为2天),开发团队的成员不应该做任何开发工作,要将全部精力放在把产品需求分解成一个个开发任务,并估算开发时间。

估算开发时间需要注意以下几点。

1、对于所需要使用的新技术,要估算学习和调研的时间。

2、根据统计,每个程序员每天的有效工作时间是5个 小时左右,其他时间都被沟通、喝水、休息、上洗手间等琐事占据,如果某个任务估算超过5个小时,那就代表了这个任务完成需要超过一天的时间。

3、开发人员对于开发任务的估算尽可能精细,一般来说,每个任务的估算时间不应该超过5个小时,如果超过5个小时,就应该把这个任务再细分为多个更小的任务。只要尽可能精细地估算任务,总体估算时间是大概精确的,因为有的任务估算的时间比实际完成的多,有的比实际完成的少。

最后根据产品经理的优先级和开发人员的估算时间,确定这个迭代周期最终的开发任务和其对应的优先级,即完成Sprint Backlog

 

日常开发

 

App开发中,App通过APIApp后台交互,后台人员可以先设计好相关的API并让API返回假数据。

开发过程中遇到任何问题,必须及时找相关人员沟通。为了保证沟通的效果,可以采用下面的方法。

1、如果不是非常紧急的问题,可以等相关人员休息的时候再沟通。

2、解决一个问题,先梳理好情绪,沟通的时候对事不对人。

Scrum中有个关键的职位“Scrum master”,Scrum master一般有技术总监担任,团队和外部的沟通必须统一通过Scrum masterScrum master的最大作用是屏蔽外部对开发团队的影响,使开发的进度和开发的效率得到保证。

在开发的过程中需要注意:一个Sprint Backlog中,需求不能变更,UI确定后原则上只能做小修改。产品有新需求,下一个Sprint Backlog再考虑。

 

每日例会

 

每日例会前,团队成员应该整理各自的任务列表,包括:

1、昨天完成了哪些任务,每个任务使用了多少时间,没完成的任务估算还要多少时间。

2、剩余的开发时间

例会中产品经理和开发团队的成员都要参加,如果可以的话,让运营人员和市场人员也参与进来,这样可以使团队每个成员都对公司的产品有个整体的了解。

每个人在例会上报告一下3方面的事情。

1、昨天做了哪些工作?

2、今天准备做哪些工作?

3、有什么工作需要其他同事配合?

注意避免在会议上讨论问题,如果真的需要讨论,请在会议后和同事讨论,不要浪费整个团队的时间。

 

测试和修复BUG

 

产品开发完成就进入测试和修复BUG的阶段。

测试人员把测试得到的问题提交到BUG管理软件,每个BUG应该包含3个部分。

1、问题描述和重新步骤

2、测试人员

3、负责解决这个问题的人员,如果测试人员不知道具体负责人,把这个问题提交给技术总监,由技术总监指定解决问题的研发人员。

 

评审会议

 

在测试和修复BUG完成后全体人员开评审会议。相关开发人员在评审会议中向全体人员演示APP的功能。

 

回顾会议

 

研发完成后开回顾会议,每个成员都在会议中提两点。

1、这轮迭代过程中做得好的地方。

2、这轮迭代过程中做得不好的地方。

这个过程走两轮,即每个成员都要提两点做得好和不好的地方。注意当一个成员提出自己的意见时,其他成员不做任何的评论。

 

及时反馈

 

可以通过建立相关QQ群收集意见,在APP中可以增加一个意见反馈的功能。

 

总结

 

敏捷开发不是万能的,敏捷开发更适用于需求多变,开发周期端的项目。


2016-08-29 07:26:45 Aweijun360 阅读数 6041
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师
在信息技术高速发展的今天,有很多的开发任何要求开发人员增量交付,迭代式开发,能够持续集成。很显然传统的瀑布开发模式已经不能满足需要了,于是,敏捷开发这种模式就出现了。


  接触过敏捷开发的朋友可能会知道,敏捷开发有如下的价值观:


  个体与互动 胜于 过程与工具,可工作软件 胜于 复杂文档


  用户协作 胜于 合同谈判,响应变化 胜于 遵循计划


  下面新霸哥将会用一个真实的案例的给大家讲讲敏捷开发。


  每天早晨上班前一项重要的任务那就是晨会(由于时间很短,所以大家都是站立开会的),主要就是回报一下昨天自己的工作情况,在工作过程中遇到的问题,有没有解决,需要谁来帮助,同时还要讲讲自己今天将要计划做的事情。对于提出的问题大家共同讨论,如果能够及时解决的就现场解决,不能解决的就会后协调处理,因为每个人的时间是宝贵的,这个高效的会议的目的就是了解组内成员的工作进度和工作态度,同时也能锻炼自己的沟通和表达能力。


  会议结束后,大家各自忙自己的任务了。由于在开发的过程中采用的是项目中划分出很多的独立模块,每个人负责的模块都是不一样的。因为迭代模式中的每个模块交付时都必须是独立可运行的也是集成可测试的,所以,功能代码这一块在测试环境集成测试无误后该模块才算验收通过。


  开发人员编码工作完成后就没有事情做了吗?其实不是这样的,因为测试人员会在测试环境对各个模块进行测试,如果发现问题会及时的在bug反馈系统中,开发人员看到有自己相关的bug要及时的反馈,这样才能保证系统正常运行。




  迭代开发中一个星期后,相关的团队成员的编码工作基本上完成了或完成了大半。这时候项目经理会组织一个开发人员会议,就是开发人员坐到一个会议室里面瞪着大眼在投影仪上找bug或编码规范问题。因为团队的力量还是巨大的,没过一会,一个功能模块可能就给你揪出了十几个bug,大家一起发现的问题会议结束后会形成一个bug列表,按责任人给依次分配下去解决。相当于集体重构了一次代码,让系统更加的健壮、稳定。


  改过了上次的bug后,团队成员可以小休息一会了。一个迭代周期结束后,项目组成员会再次的坐在一起开一个即重要又轻松的会议--迭代回顾会议。项目中遇到的问题总结,下一次在遇到同样的问题该怎么对付。其实直到项目交付,期间还会有很多次的迭代的。


  当然,敏捷开发有十二原则,在这里新霸哥就不重复了,如果有需要对敏捷开发有更深的了解欢迎和新霸哥交流。如今,敏捷的思想算是深入人心了,后面的具体方法就是教会我们如何实施敏捷。新霸哥发现有了这些思想,整个世界都开始美好了。
2019-11-15 13:45:51 qq_38435382 阅读数 9
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

 

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

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

2012-06-25 18:21:54 iteye_14109 阅读数 319
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

     软件开发方法一直处在不断发展过程中。在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。那么,敏捷开发有什么好处呢?

 

    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业中,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然,其最大的推动力是采用这种方法所能带来的受益。相关统计表明,敏捷开发可以将效率提高3~10倍,软件的质量也有更加可靠的保证; 同时,还给团队内的每个成员提供了良好的发展机会,技术和合作水平都能得到相应提高。当然,敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。
 
    敏捷开发由几种轻量级的软件开发方法组成,包括极限编程、Scrum、精益开发(Lean Development)、动态系统开发方法、特征驱动开发(Feature Driver Development)、水晶开发(Cristal Clear)等等。所有这些方法都具有以下共同特征,它们也是敏捷开发的原则:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期持续的时间一般较短,通常为1到6周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。有些是在每个迭代周期结束的时候集成, 有些则每天都在这么做。

    5. 开发团队自我管理。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。
 
    敏捷开发的优势:

    满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异,但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。
 
    敏捷开发方式能给企业和用户带来以下好处:

    1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。

    2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

    3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。

    4. 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。

    5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
 
    主要的敏捷方法:

    敏捷开发方法是一组开发方法的统称,主要包括以下几种:

    极限编程其主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致,结对编程(pair-programming)就是其中比较知名的方法之一。除此之外, 其核心做法还有小规模、频繁的版本发布、短迭代周期、测试驱动开发、持续集成、每日站立会议、共同拥有代码、系统隐喻等。

    Scrum Scrum是一个敏捷开发框架,它由一个开发过程、几种角色以及一套规范的实施方法组成。在Scrum中,产品需求被定义为产品需求积压(product backlogs)。所有的产品需求积压都是从一个简单的想法开始,并逐步被细化,直到可以被开发的程度。Scrum将开发过程分为多个Sprint周期,每个Sprint代表一个2~4周的开发周期,有固定的时间长度。

    精益开发精益开发的核心思想是查明和消除浪费。在软件开发过程中bug、没用的功能、等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明,然后设法消除。精益开发的其他原则包括强调学习、在最后时刻做决定、用最快的速度交付用户等。

    其他敏捷方法还包括动态系统开发方法(DSDM)、特征驱动开发(FDD)、Crystal Clear等,各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷开发,并且了解更多的最佳应用。
 
 
如何选择一种敏捷方法:

    选择一种合适的软件开发方法取决于多种因素。在做出决定之前,我们需要充分考虑以下这些方面:

    1. 方法的复杂度。确保你的团队或组织能够应付这种复杂度。

    2. 社区和业界支持。有较多的社区及行业支持可以使你受益匪浅。

    3. 实用工具。一个良好的软件工具可以帮助团队有效地处理日常工作,促进团队协作,并减少管理成本。

    4. 对敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

    5. 你的团队规模。较小规模的团队最好从简单的方式入手。

    6. 你不需要只遵从一种方法。你可以为团队选择一个主要的方法(如Scrum),然后借鉴其他方法。

 

2019-03-31 11:41:01 gang544043963 阅读数 846
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

「齐齐兽」公众号授权转载
  原文连接:原文连接

今天来篇正经的,从软件工程的角度来聊一聊敏捷开发模式,文章分两部分:

第一部分通过举例和对标其他行业聊聊软件开发模型的发展演进。

第二部分聊聊敏捷的核心思想。

敏捷开发是互联网界比较流行的软件开发模式,产品、技术、项目管理、运营、美术和测试等各岗位对其理解后都大有益处,运用得当可以事半功倍。现在信息爆炸、良莠不齐,网上很多讲敏捷的文章,Scrum词意没理解到位。去年看了敏捷革命的原版《Scrum: The Art of Doing Twice the Work in Half the Time》,结合大学所学的软件工程聊一聊这个话题,here we go~

 第一部分

瀑布模型

先上定义:瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作软件概念,主要分为需求分析,架构设计,详细设计,实现,单元测试,集成部署,系统测试,运营维护。瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠。

为什么会有瀑布模型?

如果一个人接项目,他也许不需要这么麻烦,但规模稍微大一些,就需要多人协作,这时候就需要有标准有规范。最开始的时候,大家用了建筑工程领域的模型来对标软件工程。是盖住宅还是盖工厂,或是商厦或是办公楼或是博物馆,需要有严谨的建筑设计图,水电管道布线甚至装修方案,才开始施工。瀑布模型就是这个思维,所以瀑布模型对软件架构师的要求很高,在瀑布模型下,如果把开发软件作为盖栋建筑的话,coder只需要“搬砖”就可以了(在敏捷开发过程中,对研发团队人员的要求会较高,瀑布重视流程、文档,敏捷强调团队内人员能力,特别是cross-functional,要有跨领域的能力。也有人把瀑布模型折叠起来,变成了V字型,目的是每个阶段都有要去验证的东西,看起来是有迹可循的,前后阶段是对应的。个人觉得瀑布模型最重要的是给大家树立了软件工程的基本观念:

1.前期做足功课很重要;

2.编码只是软件工程中的一部分。

「V字模型」

瀑布模型有什么问题?

慢慢大家发现,瀑布模型有很多限制和问题,最主要的是不能拥抱变化盖大楼毕竟跟开发软件不一样,软件的需求往往是不断变化的,瀑布模型往往会导致牵一发而动全身,这就导致绝大多数瀑布模型是延期的,而且出来的东西也不是用户最初想要的。客户想要一把瑞士军刀,最终只出来一把螺丝刀,甚至只是一根小木棍儿。。。人们逐渐想办法克服了这个问题,这就是统一软件开发过程(RUP:Rational Unified Process)

统一软件开发过程

RUP是瀑布模型的改进,可以这样理解,这个模型把软件开发过程的类比从建筑行业改到了汽车行业。主要认清了两点:

1.软件是不断迭代的;

2.软件应该是面向对象的;

当然,还有很多其他方面的改进细节,就不展开了。一个车型可以是系列的,舒适版、技术版、豪华版,不同年份还不一样,是不断迭代更新的。要想造一辆车,团队可以分头行动,简化一下比如要做一个四只脚的木凳,甲可以先去做凳子面,乙去做凳子腿,前提是两个人定义好怎样连接(接口),用什么样的螺丝,多大的孔,在什么位置连接,凳子腿多高等等,也可以有个专门的丙(项目经理)去协调这些事情。这样凳子腿可以在这个基础上自由地涂些花纹,加个皮套,做些镂空等等。

「改进后的瀑布模型」

这个模型已经具备了高内聚低耦合的思想,但还是有个问题,客户或领导通常想看到一些进展,也许一辆车从设计到出厂需要两年,但每几个月大家可以看到一些实实在在的东西,以上面做凳子为例,我们是可以看到凳子腿和凳子面的,也可以想象它们连接起来的样子。而软件不一样,只要各个模块还没有效的连接起来,那基本上啥都没有,特别是对于大多数没有计算机知识的人,基本上是一个“黑盒”过程。这个模型同样面临着延期超预算的风险,同时做出来的也不一定是客户想要的。

 

随着互联网的发展,对软件的变化需求越来越高,就产生了大家最熟悉的迭代模型,inception,elaboration,construction,transition,四个阶段形成闭环,不断循环往复,其核心理念是软件是增量开发的每次迭代都能看到些进展。敏捷开发就是在这个生命周期模型下演变而来。

「迭代模型」

螺旋模型

接着就有了螺旋模型,螺旋模型并不是推翻了瀑布和RUP,是一种改进,从某种角度来说螺旋也是遵循瀑布模型的,每一次螺旋迭代都要有清晰的目标,明确的需求,规划实现,交付条件等,这个循环也是迭代模型的迭代周期演变。比如说要做一辆汽车,我们可以先做一个自行车,再逐渐地在自行车上加个铃铛,加上发动机,变成4个轮子,加个篷,车把变成方向盘。。。在各方面持续地螺旋迭代下去,最终会出来一个跟汽车差不多的东西。这个例子有一些原型法的味道,螺旋模型往往是较大较复杂的系统使用,目的是减小风险,每一次投入能看到一些东西的产出,希望把整个过程“白盒化”。

「螺旋模型」

总结

以上是关于软件工程的三个主要生命周期模型,逐渐地又出现了极限编程、原型开发、敏捷开发等模型。严格来讲,瀑布模型、迭代模型是生命周期层面的模型(当然,通常也包含了一系列开发层面的工具集),敏捷开发是基于迭代模型发展起来的一整套软件开发指导原则。个人观点是在实际操作中应重视指导原则,弱化方法论。迭代模型在学术上很早就有人提出,敏捷开发的作者之所以能从不同的视角去看待软件开发,并有独特的思维和管理方法,这跟他的个人经历有很大关系,因为他不是做计算机出身为了理解他的思想,我特意购买了《敏捷革命》的英文原版《Scrum,The Art of Doing Twice the work in Half the Time》来阅读,下面部分分享其核心观点。


第二部分

我们可以看看《Scrum》的作者杰夫·萨瑟兰的经历,他之所以能以全新的视角来认识和理解软件工程这件事情,很重要的原因在于他不是做这个行业出身。

 

作者的经历

杰夫·萨瑟兰毕业于著名的西点军校,他以战斗机飞行员的身份去参加越南战争,在他的队伍里50%的飞行员会被击落,一些会被营救,一些再也回不来。在这个环境里他构建了自己的行动模型,即OODA(Observe,Orient,Decide,Act)执行任务的每时每刻都在重复着这个循环,犹豫就会死。这个行为模式在他的著作里能感受到已经深入骨髓。

 

参加完越南战争后,他去斯坦福进修了统计学硕士学位。后来边在空军学院做数学教授,边读了一个生物统计学博士,研究细胞、癌症相关的一些东西,学习了系统论方面的东西。在研究细胞的时候,他会不断考虑一个问题:whether the new state is better than the old one 现在这个状态是不是比上一个好。《敏捷革命》原文中多次提到state这个词,这也是作者非常重要的一种思考方式。

 

其离开大学的第一份工作是做美国的ATM,这个时候他把自己在战争和研究细胞中的方法应用于IT领域,后通过大量实践(其中有为FBI构建犯罪嫌疑人数据库,著作中的重要案例)逐步总结发展出了敏捷模型理论。另外,Scrum不是作者的首创,作者是根据日本两个教授的理论发展总结而来。在学术界,日本的两个教授质疑瀑布,他们认为最好的团队应该像打橄榄球一样,球在队伍中间穿梭,队伍整体快速向目标移动(这才是Scrum想要表达的意思),日本的大企业最开始用这种指导思想(细算一下正是日本IT大发展的时代)。理论早就有了,但很少有美国人这样去实践,作者为了理解日本人的Scrum思想,练习了多年合气道,并用合气道来类比Scrum,并再次用到了“state”思维方式来解释。

Scrum&Cross-functional

说到Scrum,我们来聊聊cross-functional。橄榄球大家可能不熟,我们来聊聊篮球。球队里最吃香的是哪种人,当然是那种什么位置都能打且都打得好的,俗称万金油。勒布朗·詹姆斯号称可以从1号位打到5号位,这种人可以体会到在各个位置的人的“不容易”,从而更有利于团队发展。奥尼尔给人篮下巨无霸的印象,但其实他有灵活的运球技巧和出色的娱乐表演天赋,这些综合到一起才成为球迷心中大鲨鱼的人设。NBA里那些最受人崇拜的顶级后卫,基本都会多种绝学,乔丹科比韦德等人,控球、得分、突破、抢板、分球等各项技能均能登堂入室,有些方面甚至前无古人。有一项技能特别突出基本就可以独步武林,但想成为顶级选手,一定是cross-functional的而作为球队老板,希望在有限的资源下,尽可能多地把这种选手招致麾下,才有可能对拉里·奥布莱恩杯发起冲击。勇士的“死亡五小”更是将这种理念发挥到了极致,场上队员几乎都能快攻、投篮和抢板。

 

回头来看,软件开发也是,cross-functional是对团队人员素质要求的提高,正所谓不会写代码的产品不是好美术。软件开发也是个跨兵种共同协作的同时不断面临变化的事情,从这个角度来看,跟打篮球和橄榄球是相同的,还记得NBA赛场上暂停时大家是怎么解决问题的么,结合上面说的场景“球在队伍中间穿梭,队伍整体快速向目标移动”,这是Scrum中非常重要的理念。

敏捷作者的一些核心观点(为保原汁原味,摘抄部分原文)

 

传统的瀑布模型其实是由一大堆图表构成,作者表达了对图表的一些观点:

 

  • Planning is useful. Blindly following Plans is stupid;计划是有用的,但盲目的按计划走是愚蠢的。这跟作者的从军经历有关,其执行任务的时候都是随机应变,也应了中国的那句老话“计划没有变化快”。

  • Every project involves discovery of problems and bursts of inspiration,scrum embraces uncertainty and creativity.任何一个项目都包含了未发现的问题以及随着项目进行的灵感爆发,图表会限制这些,Scrum“拥抱”这些不确定性和创造性。

  • Stop doing what you’re doing ,review what you’ve done;放下手中的事情,想一想我们在干啥。

 

作者对“敏捷”的一些观点:

MVP                    

Minimum viable products to get immediate feedback from consumers,rather waiting until a project is finished;最小化可行产品Minimum viable products,也简称MVP(搜索这个短语会有大量方法论)。用最小化的可行产品来从用户那里快速获得回馈,而不是一直等项目完成。我们通常说的“小步快跑”;

 

Inspect and Adapt cycle

上面说的OODA行动模型的抽象,“观察—适应”,这两个过程不断循环。这里面作者提到了一个常用的方法5W2H,在每一个阶段(state)都问自己:

  • What;我们要做的是什么,有什么意义,现在是什么状态;

  • Why;我们为什么要做这个,可不可不做,有替代方案么;

  • When;什么时候做,deadline是什么;

  • Where;在哪做,哪里要用;

  • Who;谁来做,谁对此负责;

  • How;怎么来做,如何配合;

  • How much;多少、程度,多大开销,做到什么程度;

 

敏捷革命可以应用在各行各业,作者已经在汽车制造、开洗衣店、学生培训、制造宇宙飞创、婚礼策划等领域展开实践,所以说Scrum模型不只是一套软件开发工具集,是具有普世性的价值观

Agile Manifesto, It declared the following values:people over process;products that actually work over documenting what that product is suposed to do;collaborating with customers over negotiating with them;and responding to change over following a plan,Scrum is the framework I built to put those values into practice.There is no methodology.这就是敏捷宣言的所有原文,后来被各种媒体放大和解读,其实它非常简洁。敏捷宣言,它强调了以下价值观:

                       重于    过程;

产品真正好用    重于    文档里的设计;

跟用户合作        重于    跟他们谈判;

对变化做回应    重于    按计划去做; 

我建立Scrum模型就是为了把以上价值观揉进一套工具集以方便更好地实践,敏捷模型没有方法论;(没有方法论,没有方法论,没有方法论,这是作者的原话啊,啪啪啪打脸有木有);

 

总结

Scrum原著以案例来表达了他对图表、文档、对计划、对团队、对过程管理的一些观点,而Scrum正是这一系列价值观的合集,这才是Scrum的精髓所在,为了快速实践和方便理解这些价值观,作者提供了一些方法比如每日立会、sprint、backlog等。具体方法不赘述了,网上有很多介绍。这些方法都是为了落实上面的观点:我们处在什么状态,我们有什么,如何做下个状态会比现在的好。。。

 

相比于拿过来方法直接使用,理解好上面的观点再根据实际情况选择方法是更有效的思路。

 

友情推荐:此文转载于朋友的公众号「齐齐兽」,每周一篇高质量文章。如果你是程序员或产品经理,微信扫描底下二维码,必有收获!

敏捷开发

阅读数 749

敏捷开发初识

阅读数 1220

没有更多推荐了,返回首页