2020-01-03 09:07:56 yulizi0215 阅读数 20
  • SCRUM敏捷开发视频教程

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

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

敏捷开发
敏捷开发大大提高了我们部门的开发效率,开发人员各自关注自己负责的功能模块,并且通过高效的沟通,在保证产品质量的前提下,实现了产品的快速迭代!

需要掌握的知识点

Sprint :冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要2-6周时间。
User Story:用户的外在业务需求。拿银行系统来举例的话,一个Story可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
Task :由User Story 拆分成的具体开发任务。
Backlog :需求列表,可以看成是小目标的清单。分为Sprint Backlog和Product Backlog。
Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为Scrum。
Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
Rlease :开发周期完成,项目发布新的可用版本。

在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份Product Backlog,为项目做出整体排期。
随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的Sprint Backlog,再细化成一个个Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行Daily meeting,根据情况更新自己的Task状态,整个团队更新Sprint burn down chart。

当这一周期的Sprint backlog全部完成,团队会进行Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的Release,并且进行Sprint回顾会议(Sprint Retrospective Meeting)。

Devops是Development和Operations的合成词,其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢?需要我们的项目做到持续集成、持续交付、持续部署。
时下流行的Jenkins、Bamboo,就是两款优秀的持续集成工具。而Docker容器则为Devops提供了强大而有效的统一环境。

工具使用:
SCRUM 是一个用于开发和维持复杂产品的框架
Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。
SCRUM框架包括3个角色、3个工件、5个活动、5个价值
3个角色

  1. 产品负责人(Product Owner)
  2. Scrum Master
  3. Scrum团队
    3个工件
  4. 产品Backlog(Product Backlog)
  5. SprintBacklog
  6. 燃尽图(Burn-down Chart)
    5个活动
  7. Sprint计划会议(Sprint Planning Meeting)
  8. 每日站会(Daily Scrum Meeting)
  9. Sprint评审会议(Sprint Review Meeting)
  10. Sprint回顾会议(Sprint Retrospective Meeting)
  11. 产品Backlog梳理会议( Product Backlog Refinement)
    5个价值
  12. 承诺 – 愿意对目标做出承诺
  13. 专注– 把你的心思和能力都用到你承诺的工作上去
  14. 开放– Scrum 把项目中的一切开放给每个人看
  15. 尊重– 每个人都有他独特的背景和经验
  16. 勇气– 有勇气做出承诺,履行承诺,接受别人的尊重
    SCRUM理论基础
    Scrum以经验性过程控制理论(经验主义)做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum的三大支柱
Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下:
第一:透明性(Transparency)
透明度是指,在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面,而且必须理解他们看到的内容。也就是说,当某个人在检验一个过程,并确信某一个任务已经完成时,这个完成必须等同于他们对完成的定义。
第二:检验(Inspection)
开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差。在确定检验频率时,需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度,那么就会出现问题。幸运的是,软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
第三:适应(Adaptation)
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应:每日例会检验Sprint目标的进展,做出调整,从而优化次日的工作价值;Sprint评审和计划会议检验发布目标的进展,做出调整,从而优化下一个Sprint的工作价值;Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意,并且工作更快乐。

2018-11-25 23:46:06 weixin_39911085 阅读数 178
  • SCRUM敏捷开发视频教程

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

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

什么是敏捷开发

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方式,它并不是一门技术,而是一种开发方式,一种软件开发流程。指导我们用规定的环节一步一步去完成项目的开发,区别于软件的传统的开发模式(瀑布模式:需求分析到详细设计,从编码到测试,测试完成后再交付这么一个流程),而敏捷开发则是不要求非常完美的需求分析、设计、文档,而是在最短的一个时间内完成一个框架,然后不断迭代、测试,直至交付--------不指某种具体的过程或框架,而是一组价值观和原则,是应对快速变化的需求的一种软件开发能力。

敏捷开发的原则

敏捷开发的12条原则:

  1. 我们最重要的目标,是通过持续不段的及早交付有价值的软件使客户满意(价值大于一切)。
  2. 欣然面对需求变化,即使在开发后期也一样,为了客户的竞争优势,敏捷过程掌握变化。
  3. 经常交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目当中的每一天都不例外(沟通)。
  5. 激发个体的斗志,以他们为核心搭建项目;提供所需的环境和支援,辅以信任,从而达成目标。
  6. 不论团队内外,传递消息效果最好效率也最高的方式是面对面的交谈,即face to face。
  7. 可工作的软件是进度的首要度要标准。
  8. 敏捷过程倡导可持续开发(即迭代),责任人、开发人员和用户要共同维持其步调稳定延续。
  9. 坚持不懈的追求卓越技术和良好设计,敏捷能力由此增强。
  10. 以简洁之本,它是极力减少不必要工作量的艺术。
  11. 最好的架构、需求和设计出自组织团队(整个team一起商量出来的结果)。
  12. 团队需要定期的反思如何提高成效,并依此调整自身的举止表现/

多种敏捷开发的方法

常见的敏捷开发方法:

  • 软件开发节奏,SoftWare Development Rhythmns
  • 敏捷数据库技术,AD/Agile Database Techniques
  • 敏捷建模,AM/Agile Modeling
  • 自适应软件开发模式,ASD/Adaptive Sofatware Development
  • 水晶方法,Crytal
  • 特性驱动方法,FDD/Feature Driven Development
  • 动态系统开发方法,DSDM/Dynamic Systems Development Method
  • Scrum
  • 极限编程
  • 探索性测试

一个敏捷团队

大致9~12人规模,开发4名,其余各一名;

  • PM: Project Manager, 项目经理
  • BA: Business Analystt, 业务分析师
  • TL: Technical Leader 技术领导
  • QA: Quilty Assurance 测试人员
  • UX: User Experience 用户体验设计师
  • DEV:Developer, 开发人员
  • DevOps : 运维人员

敏捷开发中常用的术语

  • IPM : Iteration Plan Meeting ,迭代计划会
  • Standup: 站会
  • Story: 用户故事/需求,体现为看板上的卡片
  • Story KickOff :启动卡的开发
  • Pair : 结对编程
  • TDD : Test Driven Development ,测试驱动开发
  • Code Review : 代码检查
  • ShowCase : 演示已经完成迭代的功能
  • AC : Acceptance Criteria ,验收条件
  • CI : Continious Integration,持续集成
  • Retro : 回顾会议(即每个迭代的项目总结)
  • TB : Team Building ,团队建设

迭代的典型流程

在这里插入图片描述

致谢

最后要感谢项目得晓峰老师得分享,让我具体了解敏捷开发的概念以及敏捷开发具体怎么实现的,thank you.

2012-04-05 12:27:12 iteye_4001 阅读数 14
  • SCRUM敏捷开发视频教程

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

    10421 人正在学习 去看看 CSDN讲师
敏捷开发的目的是在保证开发质量的前提下提高开发效率。敏捷开发需要有两个前提,团队人员对所应用的技术有比较全面深入的了解;开发及测试人员对软件的业务逻辑有全面深入的了解。换句话说,一个项目或者一个产品发展到一定阶段之后,可以根据实际情况逐步过渡敏捷开发的方法上来。
一般来说,敏捷开发有以下特征:
1、团队规模比较小,10人左右是比较合适的。
2、团队内部强调沟通,包括经常性的standup meeting和就某个技术、需求问题的讨论,讨论方式包括面对面、电话和邮件。
3、文档特别是开发人员撰写的文档大幅减少,如果只是在现有技术框架下添加一个新的业务功能,甚至不需要标准的设计文档和功能描述文档,当然详细的使用手册或者online help还是需要的。
4、单元测试以及UI自动测试的应用,可以显著增强软件质量。特别是对于开发周期比较长的软件来说,自动测试可以大大减轻QA人员进行回归测试的工作量。
2006-07-18 21:47:00 software_apprentice 阅读数 891
  • SCRUM敏捷开发视频教程

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

    10421 人正在学习 去看看 CSDN讲师
     再谈了需求(甚至可以说是complains)之后,就可以切入正体了,并且我将以我的一个项目经验来阐述敏捷开发?
      首先什么是敏捷开发?这个问题网上会有许多解释,事实上从技术的角度讲,就是将设计,编码,测试等传统软件工程学上的不同阶段混在一起。从开发哲学讲,就是以人为本!你可能会觉得诧异,将这些阶段混在一起不是进入了最初的混沌阶段了吗?当然不是,所以才有了许多敏捷开发方法学,包括XP Programming,TDD(Test-Driven Development)等。至于敏捷开发是谁提出的,我想许多人都会认为是Martin Fowler于01年发表的《敏捷开发宣言》那时候开始的吧。其实不然,敏捷开发是许多位优秀的开发人员,在实际的开发过程中,发生了诸如我上篇提到的诸多抱怨后,认真总结,不约而同的悟出的,真的是悟出的!这里举个例子, 在我离开kst的前几天,曾经参加了金碟中间件的apusic的宣传会,当时,金碟的cto,中国java的diyiren,JCP的中国代表袁红岗先生也出席了(对此人比较崇拜,所以用了许多头衔)。他在会上说,在01年之前,他觉得他在软件业没有什么特别成就感,虽然也写了中国第一个windows平台财务软件,卖了10多个亿(牛人...)。01年之后,他对他过去的开发经验做了一些,总结,并悟出了一套方法学,并在以后的开发工作中加以应用(包括领导开发了同Websphere,Weblogic同一级别,同样获得Sun J2EE规范认证的application server:APUSIC),这才有了一定的成就感。之后,Martin Fowler来了中国,袁红岗也参加了见面会,在和Martin Fowler交流之后,他才觉得,原来世界上有这么多人想法和他一样(汗...)。不错,他悟出的那套方法论就是敏捷开发!
      事实上我对这其中的许多方法学感受不深,不过我下面会谈到我参与过的一个算是用了半个敏捷开发的项目吧。不过我首先想提出的做为一个程序员,如果要开发一个项目,你第一件事想到的是什么?是设计吗?不,是代码!想马上写一段代码试试看?这在传统软件工程学中,是要被BS的。但敏捷开发不同,以人为本吗。事实上仔细想想,你实际上是在用代码做设计,而不是传统软件工程学中所说的编码过程!以人为本,所以这里不需要你有严格规范的设计文档,不一定非要用建模工具,但是有一点还是需要的,你写的代码,或者说你设计的框架,别人一定要看懂!怎么看懂?随你了,你可以用UML建模工具将代码做成UML模型(事实上我认为UML真正的用途在于程序员之间的交流,而非建模本身),可以写简单的设计文档,甚至,真正优秀的代码只通过注释就可以在程序员之间进行没有任何障碍的交流。当然了,这是需要用极高的代码质量保证的。袁红岗就说,他从不用任何建模工具,他就是考代码建模的,如果有任何人读不懂他的代码,就说明没写好,就要重写!
       下面要说的是测试驱动(tdd),什么是测试驱动?就是现有测试,再有代码!这听起来觉得匪夷所思,但如果你是从客户的角度取考虑问题,那自然是理所当然的了。你最终要呈现给客户或者说是其他调用你的代码模块的东西就是,一些输入和期望的输出,而就进有无期望的输出就是通过测试完成的!于是这又是一个以人为本的体现!再者,事实上tdd能尽量的把测试工作再编码阶段就完成,这样做的莫大好处在于补救bug的代价变小了,在软件工程学中有这样一个说法就是,bug发现的越完,补救的代价越大?如果你完全的依靠传统软件工程学中的测试步骤,以及测试人员的话,那补救bug的代价将会非常之大,开发人员甚至已经忘了这段代码的作用了。而如果采用测试驱动的方法学,将大大的缩短最终的集成测试的时间,使尽量多的bug在编码阶段就已经得到了解决!
       之后我就要结合一下我所做过的一个算得上使半个敏捷开发的项目的经验吧。之所以说半个使因为他用到了tdd方法,可又不完全是tdd。因为当时对我们的要求是写完一个方法就要做Junit或Dbunit单元测试。一开始是比较反感的,因为觉得要花费额外的时间去完成一个功能。但是最终的结果却是项目整体时间的大大缩短,最后的集成测试花了2天不到就完成了。(事实上不仅如此,在开发过程中往往会调用别人负责的模块,由于每个功能的完成都有单元测试的保证,碰到这种情况时,几乎也没有因为别人代码的问题而耽搁过)。当然了tdd的方法学还需要有工具的支持才能事倍功半。当时我们用了一个日构件系统,做到了每日集成,每日测试,每天这个系统都会在半夜自动把cvs上的代码下载下来,把所有的测试案例跑一遍,第二天开发人员来到公司之后所要做的就是登录这个日构件系统,看看每个人负责的测试案例有没有都通过,代码覆盖率时多少。事实上这又是另一个敏捷开发的方法,XP Programming。
      所有网上的文章都在描述敏捷开发所带来的效率和以人为本。不过我想在中国敏捷开发能够未我们带来的最重要的东西却是真正对程序员的尊重!敏捷开发的方法学是要开发人员以对开发工作的热情和开发人员之间的协作,良性竞争为基础的。这在中国目前的以外包业为主的软件业中是很少见的,我们目前的软件业所需要的似乎只是循规蹈矩的按照传统工程学的工序一步步走下来的,编写无数重复代码的廉价劳动力!而中国却还一直在叫嚣缺乏高级软件人才!事实上正是所谓的有了高级,低级,软件蓝领,软件白领之分,才导致了优秀人才的缺乏!正是由于这些对程序员的不尊重,才导致了中国软件业落后的局面!程序员就是程序员,既不是做简单重复脑动的所谓软件蓝领,也不是制定一些往往事与愿违的开发计划,管理管理手下的经理人员。那是什么呢?程序员是能够改变世界的工程师!是把现实问题,转换成计算机描述并加以解决的技术人员!是为这个世界变得更简单而出力的劳动者!最重要的是,他们是在感受世界的人!
     最后还是用这句话来结束这篇blog:开发以人为本!
 
2019-03-31 11:41:01 gang544043963 阅读数 843
  • SCRUM敏捷开发视频教程

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

    10421 人正在学习 去看看 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等。具体方法不赘述了,网上有很多介绍。这些方法都是为了落实上面的观点:我们处在什么状态,我们有什么,如何做下个状态会比现在的好。。。

 

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

 

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

敏捷开发学习笔记

阅读数 187

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