2019-06-09 22:41:01 Soinice 阅读数 168
  • SCRUM敏捷开发视频教程

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

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

目录

什么是敏捷开发 2.0

常用的 4 种开发模式

瀑布式开发

迭代式开发

螺旋式开发

敏捷软件开发

4 种开发模式总结

什么是 DevOps

精益管理的7个原则

DevOps的开发流程

提交

编译

单元测试

部署到测试环境中

预生产测试

部署到生产环境

敏捷开发 2.0 解决的问题

持续集成

持续交付

持续部署

总结


什么是敏捷开发 2.0

常用的 4 种开发模式

瀑布式开发

瀑布式开发是由 WW.Royce 在 1970 年提出的软件开发模型,是一种比较老的计算机软件开发模式, 也是典型的预见性的开发模式。在瀑布式开发中,开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行,步骤的成果作为衡量进度的方法,例如需求规格、设计文档、测试计划和代码审阅等。 瀑布式开发最早强调系统开发应有完整的周期,且 必须完整地经历每个周期内的每个开发阶段,井系统化地考量分析所涉及的技术、时间与资源投入等。
瀑布式开发的主要问题是它的严格分级导致自由度降低,项目早期即作出承诺会导致对后 期需求的变化难以调整且代价很大,这在需求不明晰并且在项目进行过程中可能有变化的情况 下基本上是不可行的。瀑布式开发如图所示:

迭代式开发

法代式开发也被称为迭代增量式开发,是一种与传统的瀑布式开发相反的软件开发过程, 它弥补了传统开发方式的一些弱点,有更高的成功率。在迭代式开发中,整个开发工作被组织 为一系列短小的、固定长度的小项目,每次选代都包括需求分析、设计、实现与测试。采用迭代式开发时, 工作可以在需求被完整地确定之前启动, 并在一次选代中完成系统的一部分功能 或业务,再通过客户的反馈来细化需求,并开始新一轮的迭代。迭代式开发如图所示:

代式开发有如下特点:

  • 每次只设计和实现产品的一部分;
  • 一步一步地完成;
  • 每次设计和实现一个阶段,这叫作一个迭代。

螺旋式开发

螺旋式开发是由巴利 · 玻姆在 1988 年正式发表的软件系统开发模型,它兼顾了快速原型的法代特征及瀑布模型的系统化和严格监控,其最大的特点是引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减少损失。 同时,在每个法 代阶段构建原型是螺旋模型用来减少风险的方法。 螺旋模型更适合大型的昂贵的系统级的软件开发, 一开始应用的规模很小,当项目被定义得更好、更稳定时逐渐展开。其核心在于不需要 在刚开始时就把所有事情都定义清楚,可以先定义最重要的功能去实现它,然后听取客户的意 见,再进入下一个阶段,如此不断循环、重复,直到得到满意的产品。螺旋模型在很大程度上 是一种风险驱动的方法体系,因为在每个阶段及经常发生的循环之前,都必须先进行风险评估。 螺旋式开发如图所示:

特点:

  1. 制定计划:确定软件目标,选定实施方案,弄清楚项目开发的限制条件。
  2. 风险分析: 分析、评估所选方案,考虑如何识别和消除风险。
  3. 实施工程:实施软件开发和验证。
  4. 客户评估:评价开发工作,提出修正建议,制定下一步计划。

敏捷软件开发

敏捷软件开发又被称为敏捷开发,是一种从 1990 年开始逐渐引起人们的广泛关注的新型软 件开发方式,具有应对快速变化的需求的软件开发能力。它的具体名称、理念、过程、 术语都 不尽相同,相对于非敏捷开发,更强调程序员团队与业务专家之间的紧密协作及面对面沟通, 比单纯通过书面文档沟通更有效,能更频繁地交付新的软件版本,使自我组织、自我约束的团 队能够更好地适应需求的变化,也更注重软件开发过程中人的作用。 如图所示: 

敏捷软件开发特点:

  • 首要任务是尽早地、持续地交付可评价的软件,以使客户满意。
  • 乐于接受需求变更,即使在开发后期也是如此。敏捷软件开发能够驾驭需求的变化,从 而为客户赢得竞争优势。
  • 频繁交付可使用的软件,交付的间隔越短越好,可以从几个月缩减到几个星期。
  • 在整个项目开发期间,业务人员和开发人员必须朝夕工作在一起。
  • 围绕那些有推动力的人们来构建项目,给予他们所需的环境和支持,并且相信他们能够把工作做好。
  • 开发团队及在开发团队内部进行最快速、有效的传递信息的方法是面对面交谈。
  • 可使用的软件是进度的主要衡量指标。
  •  提倡可持续发展。出资人、开发人员及使用者应该共同维持稳定的开发速度。
  • 为了增强敏捷能力,应持续关注技术上的杰出成果和良好的设计。
  • 简洁,最小化那些没有必要投入的工作量是至关重要的。
  • 最好的架构、需求和设计都源于自我组织的团队。
  • 团队定期反思如何变得更有战斗力,然后相应地转变井调整其行为。

4 种开发模式总结

瀑布式开发:

在从需求到设计、从设计到编码、从编码到测试、从测试到提交的每个开发阶段都要做到最好,特别是在前期阶段设计得越完美,提交后的损失就越少。然而现在的系统很复杂且多变,所以很难在现实中应用瀑布式开发。
迭代式开发:

不要求每个阶段的任务都做到最好,可以容忍一些不足,先不去完善它, 将主要功能先搭建起来,以最短的时间及最少的损失完成一个不完美的成果直至提交, 然后通过客户或用户的反馈信息,在这个不完美的成果上逐步进行完善。
螺旋开发:

在很大程度上是一种风险驱动的方法体系,因为在每个阶段及经常发生的循环之前,都必须先进行风险评估。

 敏捷开发:

和迭代式开发相比,两者都强调在较短的开发周期内提交软件,但是,敏捷开发的周期可能更短且更强调队伍中的高度协作。敏捷方法有时被误认为是无计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性,适应性的方法主要用于快速适应需求的变化。当项 目的需求有变化时,团队能够迅速应对新的需求。

在一般的公司里,采用敏捷开发和不断迭代开发的方式较多,而且效率高、效果明显。因 为之前做的系统业务单一、逻辑简单、用户量少,项目团队的规模一般在 10~30 人。现在的系 统要面对不同用户的定制化的推荐,互联网连接着人与人、人与物及物与物,业务也变得越来越复杂,功能越来越多,如果整个系统糯合在一起,则必定会牵一发而动全身,导致系统维护 起来相当困难,同时每个公司又面临着人员的频繁流动、系统文档的不完善或多次转手丢失等 情况,以至于新来的人员很难快速了解和熟悉系统。因而,人们开始思考如何更高效地解决复 杂的大型系统的开发模式,在此姑且称之为“敏捷开发 2.0",在介绍敏捷开发 2.0 的概念之前, 先介绍时下热门的 DevOps。

什么是 DevOps

目前对 DevOps 有太多的说法和定义,不过它们都有一个共同的思想:解决开发者与运维者之间曾经不可逾越的鸿沟,增强开发者与运维者之间的沟通和交流。
DevOps 是通过自动化的基本设施、自动化的工作流程和持续可测量的应用性能,来整合开 发团队和运维团队,以达到更高的合作效率和生产率。
然而笔者认为 DevOps 不仅仅局限在开发者和运维之间,更是一种文化的改变和鼓励沟通、 交流、合作的行动,目的在于更加快速稳定地构建高质量的应用系统,这恰好体现了精益管理 的原则。我们也可以把 DevOps 看作一种能力。

如何获得这种能力呢?

关键有两点:

一是全局观,要从软件交付的全局出发, 加强各角色之间的合作;

二是自动化,人机交互就意味着手工操作,应选择那些支持脚本化、无须人机交互界面的强大管理工具,比如各种受版本控制的脚本,以及类似于 Zabbix 这样的基础设施监控工具和类似于 SaltStack、 Ansible 这样的基础设施配置管理工具等。

DevOps 可以用一个公式表达:

文化观念的改变 + 自动化工具 = 不断适应快速变化的市场

其核心价值在于以下两点:

1.更快速的交付,响应市场的变化;

2.更多地关注业务的改进与提升;

精益管理的7个原则

  1. 消除浪费;
  2. 增强学习;
  3. 延迟决策;
  4. 快速交付;
  5. 团队授权;
  6. 内置完整性(完整性是为了让客户对产品的体验具备平滑性和一致性);
  7. 考虑全局;

DevOps的开发流程

提交

工程师将程序在本地测试后,提交到版本控制系统如Git等;

编译

持续整合系统(如 Jenkins CI),在检测到版本更新时,便自动从 Git 仓库里拉取 最新的程序,进行编译、构建。

单元测试

Jenkins 完成编译构建后,会自动执行指定的单元测试代码。

部署到测试环境中

在完成单元测试后, Jenkins 可将程序部署到与生产环境相近的测试环境中进行测试。

预生产测试

在预生产测试环境里,可以进行一些最后的自动化测试,例如 Selenium 测试及与实际情况类似的测试,可由开发人员或客户手动进行。

部署到生产环境

通过所有测试后,便可将最新的版本部署到实际生产环境里。

如图所示:

从流程中可以看到,借助 Jenkins 等工具,提交程序之后的步骤几乎都可以自动化完成, 这节省了工程师的大量手动操作时间。由于每次提交程序后都会自动进行编译与测试等流程, 所以一旦有问题就可以马上发现并处理 CJenkins 会自动通知),这样也保证了程序的质量。

上图有一个很重要的角色: SaltStack。 SaltStack 是一个架构管理系统,可以批量地修改 Server 的设定或执行指令,也可以通过配置管理使得开发环境、测试环境及应用环境最大可能 地保持一致。 SaltStack 使得管理大量 Server 变得更轻松,这方便了运维工作。 与 SaltStack 类似 的工具还有 Puppet、 Chef、 Ansible 等。

敏捷开发 2.0 解决的问题

敏捷开发 2.0 是相对于敏捷开发而言的,敏捷开发意味着让我们全面拥抱需求的变化, 但 是对于瞬息万变的市场反馈还远远不足以应对,因此为了更加快速地发现问题和得到市场的快 速反馈,引入了持续集成(Continuous Integration, CI)和持续交付(Continuous Delivery, CD), 来更加高效地进行敏捷开发,即敏捷开发 2.0。

持续集成

是一种软件开发实践,要求团队成员经常集成其工作,每个人至少每天集成 一次会导致每天有多个集成。 集成是通过自动化的构建进行验证的,这些构建运行回 归测试,以尽快检测集成中的错误。团队慢慢会发现,这种方法有利于集成问题的大 幅减少,更快地实现有凝聚力的软件开发方式。

持续交付

是在持续集成的基础上,将集成后的代码部署到更贴近真实的运行环境的预 生产环境中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环 境中进行测试。如果代码没有任何问题,则可以继续部署到生产环境中 。

持续部署

是持续交付的更高级阶段,即所有通过了自动化测试的改动都自动地部署到生产环境中。大多数公司如果没有受制度的约束或其他条件的影响,则都应该以持续部署为目标。 在很多业务场景里, 一种业务需要等待其他功能完成了才能上线, 这使得持续部署不可能实现。虽然可以使用功能转换解决很多这样的问题,但并不是每次都会这样。 所以,持续部署是否适合某个公司是基于该公司的业务需求的,而不是技术限制。

总结

DevOps 不能只关注开发及运维,还应该关注产品、开发、测试、运维, 甚至对客户的需求 也要有了解。而敏捷开发 2.0 要求将大而全的项目拆分成小的相对独立的服务, 从一开始就不 仅仅只关注自动化部署,还要关注整个项目是否具备自动化的、可快速扩展的、完善的容错机 制,以及零岩机和便捷的监控管理。为了实现敏捷开发 2.0, 我们需要采用持续部署、 微服务和 容器这三种技术方案。

  • 持续部署:能够持续自动反馈应用程序的提交状态,减少错误等; 同时为产品的交付提 供了质量保证,能快速投入市场。
  • 微服务:使技术选型、构架系统更自由:开发更快速、周期更短: 服务更容易扩展。
  • 容器: 使部署成百上千的微服务更加容易,系统更加稳定。

 

文章转载于:《分布式服务架构:原理、设计与实战》本文仅供参考,交流,学习,如侵联删
 

2017-04-06 09:28:40 huver2007 阅读数 510
  • SCRUM敏捷开发视频教程

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

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



如何理解敏捷开发?

没有参与过敏捷开发项目的人可能觉得敏捷开发抽象难懂。举个例子,敏捷开发像是在冲浪,一直处于动态、不断变化的环境中。在项目研发过程中出现的需求变化和挑战就是你在冲浪时要应对的海浪。他们从不停止而且永远在变化,这种情况下意味着需要快速地适应变化。

首先,敏捷开发是一种过程控制方法,通俗的说,就是一种做事情的方法。

1. 它主要适用于软件,在运维、服务等领域也有广泛应用,但在硬件领域还没有成熟的方法,因为硬件一般不允许需求变更。
2. 它适用于客户不知道自己要做什么的情况,其实,这样的客户占绝大多数。因为客户不知道要啥,所以你需要不断帮客户弄明白他到底想要啥。换句话说,你需要和客户沟通,合作,倾听反馈,持续改进。
3. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。
4. 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步的把汽车改成飞机,还能按时交付。
5. 它适用于小团队,一般5-9个人。这样能使敏捷中主要的沟通方式“Face to Face” 是可行的。

其次,敏捷开发是一套工具集,里面有形形色色的工具,你也可以将各种最佳实践提炼成敏捷实践。你可以不搞敏捷,但可以用其中几个来提高工作效率。

比如:

1. 站会:三个问题,简洁有效的小团队沟通方式
2. 看板:直观反映工作进度,反映流程遵守情况,反映流程缺陷
3. 演示,计划,反思会:适合于小团队的协作和优化反馈方式
4. 用户故事:站在用户的角度讲需求
5. 持续集成:随时高质量交付的基础,有利于应对变化剧烈的市场

最后,敏捷开发也是一种企业管理方式

1. Team可以是架构师,开发工程师,测试工程师,发挥了他的主观能动性,有利于创新和效率
2. 敏捷不专注于敏捷团队中个人的绩效考核,而更多的侧重于整个团队的绩效,更好的避免了KPI驱动模式。
3. 把大项目拆分成小项目去做(每个Sprint都是一个迭代,需要输出一个高质量的版本,相当于完成一个小项目),把bug的生存期控制在一个迭代以内,降低了风险,也减少了后期改bug的工作量。
4. 把数十人的大team 分成几个敏捷团队,这几个敏捷团队的SM/PO再组成一个更高一级的敏捷团队,利用站会,回顾会,看板等等敏捷元素,可以避免数十份邮件也不能解决一个小问题,大家互相踢皮球,沟通不畅的大企业病。
5. 老板可以是最大的PO,他给下面的高管讲idea(UserStory),定期检查Demo,把控产品用户体验,负责和外界的沟通合作。

综合各方观点,敏捷开发是:在高度协作的环境中,持续不断地快速输出可交付产品,通过反馈进行自我调整和完善的方法。

2013-07-11 11:43:14 Mask53 阅读数 861
  • SCRUM敏捷开发视频教程

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

    10409 人正在学习 去看看 CSDN讲师
敏捷开发的核心:应对需求的变化
 
诞生的原因:传统的开发模型如瀑布模型要在编码前完整并且准确的调查好用户需求,需要 耗费大量的时间,却达不到用户满意的效果。因为在实际生产过程中,用户的需求是多变的。
 
敏捷开发过程:在开发前罗列出用户最基本的需求,按需求的重要性、风险性设定不同的优先级。优先级高的需求先开发,及早开发出软件原型,与用户进行交流,让用户提出修改意见。在开发过程中,可以采用story card、story wall的方式,将每个需求做成story card张贴在story wall上,对于每个story card又可以分为小的story card迭代开发,指定专门的程序员负责该模块的开发,并设定该模块预期的开发时间。每天汇报该模块的开发进度,做到项目进度的可控,每个程序员的工作量也可控。
 
敏捷开发与持续集成的结合:在开发过程中,开发人员时时 上传Story card最新版本,测试人员时时下载最新版本进行测试。对每个story测试完后再进行完整的测试。  
敏捷开发环境搭建:SVN+jenkins配套工具,我将会在之后的博客中谈到SVN服务器的搭建和使用,常见问题的解决,jenkins持续集成工具的搭建和使用。

具体参考《敏捷开发环境搭建》。
 

敏捷开发简单流程:

1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)

2、召开产品backlog计划会议,预估每个backlog的时间,确定哪些backlog是需要在第一个sprint中完成的,即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)

3、把sprint的backlog写在纸条上贴在任务墙,让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上,这样大家都可以看得到任务的状态 )

4、举行每日站立会议,让大家在每日会议上总结昨天做的事情、遇到什么困难,今天开展什么任务。(每日站立会议,是在每天早上定时和大家在任务墙前站立讨论,时间控制在15分钟内)

5、绘制燃尽图,保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制,每天记录一下,可以看到每天还剩多少个任务,直到任务数为0 ,这个sprint就完成了)

6、sprint评审会议是在sprint完成时举行,要向客户演示自己完成的软件产品 。

7、最后是sprint总结会议,以轮流发言方式进行,每个人都要发言,总结上一次sprint中遇到的问题、改进和大家分享讨论。

2018-05-24 17:06:49 u013205623 阅读数 431
  • SCRUM敏捷开发视频教程

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

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

一,什么是敏捷开发

1,敏捷开发的概念

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

2,遵循的基本原则

个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值,但是我们认为左项具有更大的价值。

3,实际有效的建议

快速迭代
让测试人员和开发者参与需求讨论
编写可测试的需求文档
多沟通,尽量减少文档
做好产品原型
及早考虑测试


二,敏捷开发的具体实现形式

1,站会

每天工作开始前,小团队聚一起少时沟通。
确定每个人工作的大致情况,是否在预期的进度内;发现是否有异常情况,对异常情况进行管理,整理备用方案。一切都是为了按照预定进度进行,在适当的时间提供可用的版本。

2,看板

应用泳道图的样式,将任务的进度明显的展示出来。
应用及时的状态反馈,能够看到整体情况,也能够看到自己任务所处的状态,便于团队进度管控,以及适当的促进个人的工作效率。


三,敏捷开发的个人理解

1,敏捷开发的意义

敏捷开发通过各个形式,在不断的迭代,快速的提交可用软件的情况下,能够较好的适应用户需求,且整体进度的管控相对比较合理何时。
看板的应用也确实能够促进个人用户的工作激情,也能够便于管理人员掌控全体。

2,敏捷开发实现的误区规避

敏捷开发是一个理念,在具体执行时不能生搬硬套
(1)沟通因为参与人员多少,所消耗的成本区别,造成大团队不适用;
沟通进度及问题反馈,需要相关人员或者通才,或者更高层次的人才能理解与产生有效沟通,对于精于一个小方向或者一线执行人员,意义并不明确;
(2)在软件规模较小的时候,版本之间的修改影响面较广,而在软件较大的时候,版本升级次数过多,对于用户很不好,对于测试人员,为了保证产品质量的回归测试资源浪费明显;且版本修改内容过少时,版本更新的意义就失去;
(3)客户合作不合作不是最大的问题,最大的问题在于协同办公,甚至是异地协同办公,所以在没有有些数据收集与反馈渠道,客户合作再好也仍是解决不了新修改版本具体承载意义的反馈;在现在时时变化的社会潮流中,客户也很难把我自己真实的需求。若是你能够做好需求规划,满足客户,客户也是很满意的;若是客户自己定义需求,那就开始随着客户需求的变更整个团队无限轮转吧!若是用户能够很好的定义需求,那自己家的产品干嘛呢?!
不是不要求变化,而是在变化中,需要遵循自己的规则,有自己的重心。

看过一篇文章,描述传统的瀑布研发流程是火炮,敏捷开发是导弹。这个从某种意义上已经阐明了瀑布研发和敏捷研发的特点。在个人的认知中,应该结合两种方式,各取其长,构建属于每个公司自己的工作模式。
火炮的造价低,火力猛,在快速定位目标后,集火干掉目标;这里的关键在于目标的瞄准 和 弹道发射的速度。大目标的确定,这是最关键的问题,及时研发最初是导弹,直接瞄准目标,也比胡乱开一个目标,不断调整到目标来的更快,成本更低。若是发现目标发生重大偏离不管是什么模式,都是需要新投入,进行调整的。
市场的表现即是,若是新一项突破性的技术形成,整体的产品方向必须调整。

个人建议,在传统的瀑布模型上,增加产品的管控;在研发的过程中使用敏捷模式,快速的交付产品,验证产品的效益,及时调整。形成良性的循环,不断反思,不断试错,进行成长。


参考资料:

为什么我不推荐敏捷开发?

你大概走了假敏捷


要是在第一个产品版本中,只能有3个功能,你要选哪一个?书中给出的建议是,一定要有用户反馈和留言功能。因为,在一个产品的验证阶段和不成熟期时,用户的反馈永远是让产品朝正确方向迭代的重要决策依据。

2013-08-23 23:59:10 clever101 阅读数 2820
  • SCRUM敏捷开发视频教程

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

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

作者:朱金灿

来源:http://blog.csdn.net/clever101

 

       首先谈谈我对敏捷开发的理解。如果我的理解有不到位之处,请各位看官谅解并拍砖。应该说任何一种新的开发方式都是在如何解决旧的开发方式的弊端上产生的,敏捷开发也不例外。传统的瀑布式开发将开发分为需求分析、系统设计、系统开发、系统部署和系统维护等多个阶段,看上去很美好,却忽略一个简单的事实:冗长的开发周期敌不过用户的需求变化。首先需求分析就是一件很模糊的事,你问用户需要什么,大多数的用户估计会这样回答你:我需要一个功能强大、运行快速的系统,就算退一万步讲,就算用户把需求讲清楚了,难道用户的需求不会变化吗?比如用户看到互联网正成为潮流,估计那天他就要求系统要能联网,比如那天用户看到硬件已经是多核了,就要求系统支持多核并行计算。你能指责用户的反复无常吗?你不能。如果你不能适应用户的变化,就只能被无情的市场淘汰掉。这时你就明白了世界上一个朴素的真理:世界上不变的只有变化。

 

        敏捷开发就应适应用户需求变化而生的。敏捷开发是怎样做到迅速响应用户变化的呢?敏捷开发提出一个最高原则:可以交付用户使用的软件胜过一切。下面以一个具体例子说明传统的瀑布式开发和敏捷开发的区别。比如A软件公司要为B工厂开发一个管理系统,这个管理系统包括录入职工信息、查询职工信息、录入生产资料信息、查询生产资料信息、生成财务报表、打印财务报表等6个功能,采用传统的瀑布式开发是这样干的:

           后来A公司发现这套开发流程不能迅速响应用户的需求变化,采用了下面一种敏捷开发流程:

        


       从上图可以看出,敏捷开发实际上是将瀑布式开发中设计、开发和测试等阶段都分割到一个个敏捷开发周期中,强调通过不断通过交付可用版本给用户获取用户的反馈来积极响应变化。敏捷开发放弃开发前冗长的需求分析和系统设计,强调快速的迭代修改更能响应用户的需求变化。因此与敏捷开发需要和敏捷测试和敏捷设计配套。

 

     敏捷开发看上去很美好,是不是放之四海而皆准呢?在我看来,敏捷开发需要在一定的条件才能实施:

1.      开发团队需要比较高度的自主权,并单独负责一个项目或产品的开发。国内的现状是多数老板有项目就接,一个骨干往往承担多个项目的开发,一个项目定好的敏捷开发周期也会被其它项目的活动所打断,能搞敏捷开发吗?

2.      从上图可以看出,用户参与使用软件并积极反馈是敏捷开发的重要一环。如果你做的是国家单位的项目,就算你能交付可用的版本,但单位的大爷就是不用不反馈,这又怎称得上敏捷开发?

3.  实行敏捷开发需要一个高素质的开发团队。首先开发团队必须明白敏捷开发的意义所在,其次他们需要有比较强的沟通能力,因为敏捷开发需要团队之间以及开发人员和用户之间的充分沟通,而现实中开发人员闷头拉车的居多。最后开发人员的开发水平要适应敏捷开发的节奏,如果一个小功能的实现都超出一个敏捷开发周期,谈何敏捷?


        当然敏捷开发中强调团队之间的充分沟通,以及通过迅速交付可用版本来提高测试的频率等优点在软件研发实践还是应该予以吸收的。


 







敏捷开发

阅读数 36

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