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

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

    10424 人正在学习 去看看 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中遇到的问题、改进和大家分享讨论。

2016-08-12 10:56:54 Hampton_Chen 阅读数 2623
  • SCRUM敏捷开发视频教程

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

    10424 人正在学习 去看看 CSDN讲师
 最近实习的公司采用的是敏捷开发Scrum模式,在经历敏捷开发培训后,写写一些自己学到的东西。

一、什么是敏捷开发

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。
除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。
敏捷开发现已成为绝大多数IT企业采用的项目管理方法。
下图为美国IT企业主要采用的项目管理方法学2015年调查报告。

这里写图片描述

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。
敏捷精神(The spirit of agile):**透明、沟通、协作**

二、什么是Scrum

  • Scrum 是一个框架,在这个框架中人们可以解决复杂的自适应问题,同时也能 高效并有创造性地交付尽可能高价值的产品。
  • Scrum 是:轻量级的、容易理解的 、难以精通的
  • Scrum 不是开发产品的一种流程或一项技术,而是一个框架,在这个框架里可以应用各种流程和技术。 Scrum
    能使产品管理和开发实践的相对功效(relative efficacy) 显现出来, 以便进行改进。
  • Scrum 框架由 Scrum 团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的, 对Scrum
    的成功实施和运用都至关重要。
  • Scrum 基于经验型流程控制理论, 或者称为经验主义。经验主义主张知识源于经验, 而决策基于已知的事物。Scrum
    采用迭代增量式的方法来优化可预测性和管理风险。
  • 透明性、检视、调整是经验型流程的三大支柱,支撑起每个经验型控制流程的实施。

三、Scrum组成人员

这里写图片描述
Product Owner –产品负责人(PO/PM)
职责

  • ROI-产品负责人最大的职责是为产品的投入产出比(ROI)负责,即最大化团队的投入产出比。在Scrum当中,由于Sprint是时间盒(即时间是固定的),且成本(软件开发中人力成本是最大的成本,其他忽略不计)也是固定的,那么最大化投入产出比就是如何做出最有价值的产品增量。
  • 创建产品愿景(Vision)
  • 创建与维护产品 (Mange Prod/Sprint Backlog)
  • 主持产品Backlog优化会(增加、删除、修改或细化用户故事,并根据需要进行排序)(Mange Prod/Sprint Backlog)
  • 协调干系人与开发团队之间的沟通 (Communicate)
  • 参加团队的Scrum会议
  • 在Sprint计划会上和团队一起决定当前Sprint的开发内容
  • 接受或拒绝团队的产品增量 (PO Review-Decisive)
  • 决定何时发布 – 需要团队的承诺 (Decisive)
  • 有空解答团队问题 (Available)

Scrum Master
职责

  • Scrum权威(Role model of scrum value)
    ScrumMaster是团队中最熟悉和了解Scrum框架的,并可以根据实际情况对团队进行指导。
  • 辅导团队和产品负责人(Coach/Facilitation)
    如果产品负责人或团队不知道该怎么办,ScrumMaster需要提供相应的辅导、培训或支持。
  • 保护团队 (Project Team)
    在一个Sprint中,ScrumMaster要保护团队不受打扰,可以专注于Sprint目标和承诺。
  • 移除障碍 (Remove Impediment)
    ScrumMaster要善于发现障碍,并可以帮助团队移除障碍,包含但不限于个人障碍,团队障碍以及组织级的障碍。
  • 变革大师 (Agent of change)
    ScrumMaster不仅要在团队内实行Scrum,还要能够影响并促进组织或整个公司内的变革。
  • No Authority /Servant Leader

Dev Team-开发团队
开发团队在Sprint中主要负责以下工作:

  • 每日检视与调整 – 每天开发团队成员都需要参与每日例会。在会上大家一起检视和调整团队的进展。

  • 产品列表梳理 –
    每个Sprint中团队都要花一些时间来为下一个迭代做准备工作(即产品列表梳理活动),包括产品列表条目的创建、细化、估算、排序等工作。每个Sprint最多分配10%的时间来协助产品负责人完成这些工作。

  • Sprint计划会 – 在Sprint计划会团队一起决定Sprint内要完成哪些故事,并进行任务分解和估算。检视和调整产品与过程 –
    即参加Sprint评审会(检视调整产品)和Sprint回顾会(检视调整过程)。

四、Scrum流程

这里写图片描述

Artifacts-工件

  • Product Backlog (产品backlog)
  • Sprint Backlog(冲刺/迭代backlog)
  • Increments (产品增量/可交付成果)

Ceremonies-会议

  • Sprint 迭代
  • Planning/Grooming Meeting 计划会议
  • Daily Standup 每日例会
  • Reviewing Meeting 评审会议
  • Retrospective Meeting 回顾会议
2015-03-31 11:39:57 lxl584685501 阅读数 398
  • SCRUM敏捷开发视频教程

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

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

对敏捷开发的一点理解

今天有人问到我,对敏捷开发是怎么理解的?一时不知道从何说起了,先来思考下面的问题。//转自:refer:http://www.cnblogs.com/jetlian/p/4213663.html//作者:george.hu 胡乔治

问题:为什么会出现敏捷开发?

我刚开始工作的时候采用的瀑布模型,将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

瀑布模型

这种方式有什么缺点?

  1. 不适应用户需求变化,软件开发中用户需求发生变化真的太多了。
  2. 项目有风险,由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果。
  3. 一个项目周期太长,就会不适应市场变化。

上面的缺点其实就是:开发出一个项目周期太长,不能跟上用户需求的变化。

在这个信息快速更替的时代,如果一个项目从策划到使用要一年的时间,估计当时提出的需求早变了。

如果你是给政府部门做项目做个一两年算正常情况,如果是做互联网产品,一年时间市场早就可能出现其他类似的产品。互联网要求的就是反应速度快,最先抢占市场。

敏捷开发是针对瀑布开发模式的弊端而产生的一种新的开发模式,迎合了用户需求经常变化,采取迭代开发、循序渐进的开发原则,目标是提高开发效率和响应速度。

敏捷开发主张简单,拥抱变化。不怕用户需求发生变化,第一个Sprint先开发用户核心模块,开发完成后马上拿给用户看,当用户看到可运行的软件就会知道是不是自己想要的,然后用户又会提出新的需求,第二个Sprint继续开发新功能。就这样一个Sprint一个Sprint的迭代开发,每个Sprint结束后用户进行确认,最终完成整个项目。

敏捷开发强调

  1. 开发团队与业务专家的紧密协作。
  2. 构建自组织团队和跨职能团队。
  3. 面对面的沟通胜过书面文档。
  4. 编写能够很好地适应需求变化的代码。
  5. 持续交付新版本软件。
2010-07-24 17:14:28 iteye_15018 阅读数 10
  • SCRUM敏捷开发视频教程

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

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

今天把《高效程序员的45个习惯:敏捷开发修炼之道》翻了一遍,讲的基本是敏捷开发的一些原则,虽然没有焕然大悟的感觉,但定期来出来提醒自己一遍也不错,这些道理虽然简单易懂,但真正要在项目中实施起来还是很有挑战性的,一些成功的项目总结经验起来也无非出于这么些简单的原则:

   1. 做事 
 2. 欲速则不达 
 3. 对事不对人 
 4. 排除万难,奋勇前进 
 5. 跟踪变化 
 6. 对团队投资 
 7. 懂得丢弃 
 8. 打破砂锅问到底 
 9. 把握开发节奏 
 10. 让客户做决定 
 11. 让设计指导而不是操纵开发 
 12. 合理地使用技术 
 13. 保持可以发布 
 14. 提早集成,频繁集成 
 15. 提早实现自动化部署 
 16. 使用演示获得频繁反馈 
 17. 使用短迭代,增量发布 
 18. 固定的价格就意味着背叛承诺 
 19. 守护天使 
 20. 先用它再实现它 
 21. 不同环境,就有不同问题 
 22. 自动验收测试 
 23. 度量真实的进度 
 24. 倾听用户的声音 
 25. 代码要清晰地表达意图 
 26. 用代码沟通 
 27. 动态评估取舍 
 28. 增量式编程 
 29. 保持简单 
 30. 编写内聚的代码 
 31. 告知,不要询问 
 32. 根据契约进行替换 
 33. 记录问题解决日志 
 34. 警告就是错误 
 35. 对问题各个击破 
 36. 报告所有的异常 
 37. 提供有用的错误信息 
 38. 定期安排会面时间 
 39. 架构师必须写代码 
 40. 实行代码集体所有制 
 41. 成为指导者 
 42. 允许大家自己想办法 
 43. 准备好后再共享代码 
 44. 做代码复查 
 45. 及时通报进展与问题 

 

2017-09-19 21:18:49 williamyi96 阅读数 549
  • SCRUM敏捷开发视频教程

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

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

一段时间以来,由于学习的需要,涉及到了很多软件系统分析与设计以及软件体系结构相关的问题。而软件系统开发流程中,不得不提到的,便是敏捷开发。

接下来,将由浅入深地来分析分析敏捷开发的基本概念,然后说明一下敏捷开发的代表–XP(极限编程)与Srcum过程。

敏捷开发概念与价值观

敏捷开发运动历史相对于整个软件开发而言算是较为悠久的,其真正开始的标志是01年2月提出的”敏捷宣言(Agile Manifesto)”,这项宣言由17位当时称之为“轻量级方法学家”所编写签署的,他们的核心价值观是:

这里写图片描述

以上来自于敏捷宣言的官方网站,敏捷宣言作为指导敏捷开发的核心思想,下面简单地解释一下其内容的基本含义。

  • 个体和互动高于流程和工具。往往勤于沟通合作,目标明确的个人优秀的团队比那些使用最高级工具的团队做得更好,因为软件产品是人完成的,中间有太多的不确定性,因此互动与个人能力对变化的适应性就显得尤为重要;

  • 工作的软件高于详尽的文档。能够让软件能够顺利给用户交付使用是最终的目的,并不在乎将项目开发的过程文档写得多么漂亮,由于敏捷开发注重效率,而如此耗时的工作在后期并没有很好的效益。

  • 客户合作高于合作谈判。让客户参与到软件开发的过程中,能够更好地了解客户的需求。

  • 响应变化高于遵循计划。软件开发的过程中,往往会有诸如需求,设计等的改变,对于传统的瀑布模型将软件开发定义地过于死板,不具有对变化的适应性,开发出来的产品很可能并不是满足需求的“高质量”产品。

敏捷开发特征总结

关于敏捷开发的特征问题,网上已经有相当多的介绍资源,以下仅仅按照个人的体会针对一些与传统开发方式差异较大的部分进行总结。

  • 以瀑布模型为代表的开发方式有着严格的过程化,没有较强的响应变化的能力,不利于了解用户变化的真正需求。而敏捷开发实际上是测试驱动的。了解了用户的需求之后设计测试用例,编写测试代码,如果产品能够通过所有测试,那么其就是一个可以release的版本。

  • 敏捷开发的主要文档是测试文档。传统的开发过程中特别看中需求分析,设计与实现等部分的文档,而敏捷开发则更为注重测试文档。其本质原因是因为敏捷开发的过程中,伴随着极其快的软件版本迭代,如果注重实现等的文档,很容易产生代码修改不一致的问题。而如果以测试文档为主要文档,则便于项目的管理。同时也可以减轻团队成员调整带来的学习成本。

  • 敏捷开发以合作为中心,也就是实现代码共享。敏捷开发过程的代码不是为一人所有,任何人都有权利看到所有代码并原则上允许修改所有代码,并不需要征得原作者同意。这在很大程度上就降低了人员调动所带来的风险。

  • 敏捷开发要求开发人员的水平基本相当,一般而言,较高。由于敏捷开发的代码共享性以及代码的高需求适应性,其对开发人员的整体水平要求较高,同时开发人员之间的水平基本相当。

敏捷开发典型代表

当下用得比较多的,有两类敏捷开发的方法。一类是XP(极限编程),另外一类是Scrum。由于两者都是基于敏捷开发价值观的具体实现,因此下面简单地谈谈两者之间的差异。

区别之一: 迭代长度的不同

XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队收到干扰。

区别之三: 在迭代中,User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是: 如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.

区别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量

Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证,但XP对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, …等等”

不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束。

一般建议, 在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)

总结

通过对敏捷开发相关理念以及突出特点的了解,个人觉得其思想是一种很不错的范式。后续承担的某项目本人将尝试使用敏捷开发。

参考文献

  1. 敏捷软件开发宣言
  2. 敏捷开发 From MBALib
  3. Differences Between Scrum and Extreme Programming
  4. 敏捷方法之极限编程(XP)和 Scrum区别

关于敏捷开发

阅读数 236

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