2019-01-22 19:56:09 KamRoseLee 阅读数 222
  • SCRUM敏捷开发视频教程

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

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

软件开发遇到重要问题:

  • 学习  是软件开发中一大瓶颈
  • 如何让成员积极主动,负有责任感,能解决问题,并凝聚成一支高效的团队?

敏捷开发历史:

  • 敏捷开发并不现代   起源于20世纪30年代的一些项目(美国航天局水星计划)
  • 最早记载使用在20世纪70年代  最早的有记载的使用迭代和增量开发的主要项目之一,是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码,进行得非常成功。
  • 1976年,第一部阐述敏捷方法的书籍    Tom Gilb在他的著作《软件度量》(“Software Metrics”)一书中阐述了他的迭代和增量开发实践
  • 20世纪80年代正式定义迭代开发螺旋模型  20世纪80年代在1895年,巴里贝母(Barry Boehm)正式定义了使用迭代开发的螺旋模型
  • 20世纪90年代推荐使用迭代和增量开发的出版物和文献显著增加
  • 2001年二月敏捷开发宣言后形成敏捷联盟  一组由17位在DSDM,XP,Scrum,FSD等领域的专家组成的代表团齐聚美国犹他州,寻找这些方法的共同点。最终,这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟

敏捷开发介绍:

敏捷开发(agile development)

     是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,

但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发由几种轻量级的软件开发方法组成

   它们包括:极限编程(XP),Scrum,精益开发(Lean Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Cristal Clear)等等

敏捷开发原则和方法

1)迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

 

  1. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。
  2. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。
  3. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成, 有些项目则每天都在这么做。

5)开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

敏捷开发实践都基于一个简单的周期

  1. 测试先行开发1)写一个失败的测试2)编写代码让测试通过3)运行测试---通过了吗?4)如果测试仍然失败,回到步骤2
  2. 日常工作流程1)在每日的站立会议中,设置团队需要完成的任务2)执行这些任务3)第二条对任务的执行情况和遇到问题进行沟通4)总结经验教训,调整第二天的工作计划
  3. 测试驱动需求1)将需求转变为测试 2)进行软件开发 3)运行这些测试,如果测试通过,任务完成,如果没有回到2
  4. 迭代 1)设定一个 完成状态 2)找到一系列需求,构成迭代待办事项,并承诺完成3)一一解决待办事项4)迭代结束,一一检查每个事项是否达到,“完成状态”,如果是,标记完成,否则将他们放回待办事项中,以待日后处理。
  5. 演示 通常在迭代末进行演示,客户可以利用这个机会,验证针对预期需求的实现是否真正地解决了当前的问题 1)确定需求的业务价值  2)定义需求 3)实现需求 4)验证实现的功能是否满足业务需要
  6. 回顾1)确定团队的工作方法 2)在迭代中应用这方法 3)反思总结实践过程中的好坏方面 4)找到一些更加有效的方法,确定什么时间,谁负责实行
  7. 版本发布 1)创建该版本的远景,并设定需要达到的业务目标2)创建该版本的待办事项3)通过多次迭代来发布该版本4)为部署,并为下一个版本收集反馈信息
  8. Scrums的Scrum会议  会议来进行信息同步,通过沟通和讨论来展示自己的进度和解决遇到的问题,这能提高大家感知整个企业的变化,从而积极应变
  9. 管理检验 1)与那些产品所有者或者项目负责人一起,定义项目或者是某个版本的验收标准 2)在团队开发过程中,保证这些验收标准随时可见,使项目始终朝着期望的方向发展3)回忆会议中,一起评估标准4)让产品所有者或项目负责人和团队一起工作,保证在每一个迭代中针对这些验收标准进行检验

几种敏捷实践:

  1. 自组织团队  整个团队紧密合作,同心协力,主动承担责任,竭尽所能去完成工作,响应各种变化
  2. “联合驻扎”团队  团队成员在一起工作,经常进行小组讨论,随时可以听到各种谈话,潜移默化中就了解到发生的事情
  3. 跨职能团队  来自不同背景的人组成一个团队,自始至终地进行开发来解决一个问题。因为大家在一起紧密协作,各自的专长就会得到分享和传播
  4. 结对编程   两个人一起,齐心协力完成一些任务,这个是共享经验和专长的极致体现
  5. 信息辐射器  这种大幅图表存在的唯一目的就是把重要的信息传达给每一个人
  6. 唤醒式文档  为了更好的沟通,敏捷团队成员共同撰写文档,日后每次阅读这些文档,都可以唤起大家对讨论内容和相关背景的记忆。
  7. 站立会议 在敏捷团队中,大家每天都会彼此交流自己完成什么,遇到了什么问题,明天计划如何,这就保证了所以成员步调协调一致

敏捷实践的主要动力来源:

主要动力来源:带给客户价值

  1. 缩短上市时间
  2. 增加产品使用行(市场价值)
  3. 提高产品质量
  4. 提高灵活性
  5. 增强透明度
  6. 降低成本
  7. 延迟产品生命周期
2012-06-25 18:21:54 iteye_14109 阅读数 318
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 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),然后借鉴其他方法。

 

2017-03-01 16:56:54 zhyb0306 阅读数 6077
  • SCRUM敏捷开发视频教程

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

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

CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法?

黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我个人比较倾向于 Scrum。我理解的敏捷其实是一种思想,Scrum 是对让这个思想落地的一个参考。也就是说,我们大可不必完全拘泥于 Scrum 定义的规范,只需要参考它并结合自身的条件做适当调整即可。比如说,每日站会这个环节就非常重要,不管是放在每天上午,还是放在每天下午,总之最好要有固定的周期。此外,每次 Sprint(迭代)结束后除了有评审会以外,Scrum Master 不要忘记对本次 Sprint 做一个回顾与总结,哪些是本次迭代中做的好的地方,哪些是做的不好的,再对比上次迭代的的结论,哪些是有改进的,哪些是新的问题。

Scrum 提供了三类角色,分别是:Product Owner(一般由产品经理担任)、Scrum Master(一般由开发经理担任)、Scrum Team(包括开发与测试人员),其中,Scrum Master 的角色至关重要,对项目的成败起决定性作用。

阿里巴巴也在广泛使用 Scrum 敏捷开发模式,而且整个项目几十人都可以用 Scrum,只是首先需要将整个团队拆分成若干小团队,保证每个小团队按照 Scrum 进行操作,此外,再将每个小团队的 Scrum Master 召集在一起,再做一轮 Scrum,这就是所谓的 Scrum of Scrum。过程稍微复杂一点,但可以将敏捷用于更大的团队规模,并能保证敏捷的效果。

CSDN:你认为Scrum Master 的角色至关重要,对项目的成败起决定性作用。那敏捷开发中由产品经理担任Scrum Master会有什么问题?

黄勇:我个人不太建议由产品经理来担当Scrum Master,原因如下:

  1. Scrum Master 关注的是项目开发视角,而产品经理关注的是产品功能视角,两者关注的视角是不一样的。
  2. Scrum Master 需要有一定的技术开发功底,需要对开发工作量进行评估,也需要对技术实现进行评审,可能还会有一定的编码工作,而具有技术功底的产品经理毕竟太少了,即便有的话,可能对技术方面也不会太深入。
  3. 需要有一个人,他来对整个产品负责,这个人就是Product Owner,该角色最好由产品经理来担任。

CSDN:敏捷开发过程中测试团队的职责和产出是什么?

黄勇:在敏捷开发过程中,我认为测试团队的职责有以下几点:

  1. 根据产品需求,定义测试用例。
  2. 针对测试用例进行功能测试,并将测试的结果反馈给开发人员。
  3. 负责搭建系统运行所需的环境,包括软件安装、数据初始化等。

CSDN:除了Scrum,还有XP、CM、FDD、ASD、DSDM等敏捷开发方法,如何去选择一个合适的敏捷开发工具或者方法呢?

黄勇:敏捷开发方法有很多,不仅仅只有Scrum 一种,其实不妨相互借鉴,再结合自身的特点,定义一套适合自己的敏捷开发方法。例如XP 中所提倡的结对编程、持续集成、测试驱动等,这些都是很好的方法,值得借鉴。包括看板也是一个很不错的工具,可以结合Scrum 来工作。

CSDN:从博客上,你也研究过「使用看板进行敏捷开发」,能不能分享你的研究成果?

黄勇:敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

  • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。
  • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。
  • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!

那么 Kanban 到底是什么呢?我们先来看看这张表格吧:


下面我们来理解一下这个表格吧!

  • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)
  • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)
  • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

好!继续我们的 Kanban,有意思的事情即将发生!


产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了 然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!


CSDN:一个成功的项目,离不开每个人的努力,能够分享下你曾经的项目管理经验?

黄勇:给大家提出以下 10 点建议及其目标:

  1. Sprint 第一天,需要将目标定义清楚,并让团队所有人都知道「确保建立一致的目标并使之明确」;
  2. 若出现需求变更,则优先排到下次迭代,特殊情况需特殊处理「确保本次迭代可以按时完工」;
  3. Scrum Master 将迭代中的需求分解为任务,每个任务只能有一个任务负责人,且不超过一个人天「确保每日任务可评估」;
  4. 让 Product Owner 直接与相关开发人员确定需求,Scrum Master 需一同参与「确保需求与实现不会发生偏差」;
  5. 每日定时站会,时长不超过 15 分钟,规模不要太大「确保任务完成情况与计划保持一致」;
  6. 每日进行一次代码评审,由 Scrum Master 负责,并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」;
  7. 各个团队的 Scrum Master 保持每日沟通一次,时间不要超过 15 分钟「确保项目管理不会出现风险」;
  8. 每次迭代结束,让大家稍微放松一下,可提供一些团队活动,比如聚餐「确保团队能够更加凝聚」;
  9. Scrum Master 需要给团队一些承诺,比如项目奖金或特殊福利等「确保团队更加有激情」;
  10. 对于情绪异常的员工,Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」;

此外,作为项目管理者,需要不断在团队中加强以下 6 点文化:

  1. 方向一致
  2. 当面沟通
  3. 全情投入
  4. 充分信任
  5. 说到做到
文章节选自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315,如需阅读完整访谈内容,请移步大神博客。
2014-01-11 18:46:45 YHC2113 阅读数 747
  • SCRUM敏捷开发视频教程

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

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

开发工作中使用的敏捷开发模式

来现在的公司有一段时间了,现在主要用java开发采用敏捷的开发模式。因为以前工作中对敏捷的了解比较少所以觉得有必要进行梳理总结下。

敏捷开发的定义及解释说明这里就略过了,想要详细了解的朋友可以猛点这里(敏捷开发详解)。

谈敏捷开发先从流程讲起吧。首先,每天早上我们会有一个晨会( 站立会议 ),主要汇报昨天自己所做的工作及自己在工作的过程中所遇到的问题,然后叙述今天计划的工作,组内成员依次汇报组长做好笔录。如果组内成员有遇到自己不能解决的问题,晨会上提出来大家共同探讨,但如果估计讨论时间会比较长的时候就会安排会下协调处理,毕竟每个人的时间是宝贵的。这是一个高效的会议意在了解组内各成员的工作进度及状态。

会议结束后大家就得忙各自的Story去了,说到Stroy可能有朋友会问了,什么是Story?下面我们就一起来了解下,说白了敏捷里面Story就是项目启动前你的项目经理或组长将项目划分出来的一个独立的功能模块。然后根据组内成员的特长安排的开发任务,在迭代中(通常两个星期为一个迭代周期)开发完成。一般测试人员会在开发人员开发Story的期间完成测试用例的编写,便于开发完成Stroy后showCase(开发人员在本地环境运行story供测试人员测试)时进行验收。showCase通过后Story算是初步通过,因为迭代模式中的每个模块交付时都必须是独立可运行的也是集成可测试的,所以,功能代码在测试环境集成测试无误后该Story才算验收通过。

开发人员完成编码工作后并不意味着任务就结束了,这只是刚刚开始。是的,没说错,刚刚开始!测试人员会在测试环境对各个模块进行测试,如果发现问题会及时的在bug反馈系统中(用于跟踪问题的解决进度及完成情况)提出问题单进行跟踪,开发人员编码完成后最主要的工作估计就是和这个系统打交道了,需要及时的查看解决bug系统上面的问题单然后对问题单的状态进行变更,便于测试人员回归测试。

当然,让测试人员发现并反馈了很多的问题也是让我们开发人员比较苦恼的一件事情,毕竟不是什么好事儿。谁都希望自己交付的代码能够经得起考验,少出现或不出现问题(当然我们知道这是不可能的),那么怎么办呢?敏捷里面针对类似的情况也有合理的应对流程,确保高效、高质、高产按时的交付。那就是我们常说的结对编程,通俗的说就是A和B两个人划分为一个编程小组,有问题及时沟通反馈。甚至A看着B或B盯着A写代码也是一件比较常见的情况。A在提交自己的Stroy时必须先让B检视Review一下自己的代码,发现了问题应修复完成后才能让测试人员去测试。这样可以避免一些不必要的错误和疏忽出现,提高开发效率的同时提高编码质量。

还有一种防范问题发生的措施,那就是集体检视代码。

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

经过九九八十一难般的两个星期就这样循环反复中一闪而过,这时候我们可以暂时的小憩一会儿了。

这一会儿是多久呢,大概也就是一天左右的时间吧。因为一个迭代周期结束后,项目组成员会再次的坐在一起开一个即重要又轻松的会议--迭代回顾会议。大家吃着零食边谈论总结这个迭代中做的好的部分及需要改进的部分,“嘿,那个谁上次那个地方我说应该XX做样吧!”、"这个迭代中XX同学给予了我很大的帮助,感谢",大家你一言我一语就这样展开讨论开来...

回顾会议的第二天,开始了上面工作的第二次循环,直到整个项目交付......

原文链接:http://www.cnblogs.com/zzxbest/archive/2012/10/29/2745639.html


2018-10-09 17:08:50 u014526891 阅读数 828
  • SCRUM敏捷开发视频教程

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

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

上面一篇文章我们提过为什么分布式需要做前后端分离,今天这篇我们从开发模式来详解为什么互联网项目使用于敏捷开发?

因为笔主经历过瀑布开发模式和敏捷开发模式这两种开发模式,所以存在有一些自己的见解跟大家交流。

下面所以我们这边先来简单介绍下这两种模式:

瀑布开发模式:

瀑布开发模式是由W.W.Royce在1970年最初提出的软件开发模型,瀑布式开发是一种老旧的计算机软件开发方法。
瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行
步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。 总的来说,迭代周期长一些,一次性解决所有的任务,一次上线。

下面我们说说瀑布开发模式的几个特点

1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。

2.重视和强调过程文档,在开发的中后期才会看到软件原型,早起只能通过文档来了解系统的模样。在这种情况下,文档的重要性仿佛已经超过了代码的重要性。

3.瀑布模型每个阶段的人员只关心自己阶段的工作,不需要关注其他阶段的工作。

优点:

1、可以让开发人员能够更专注于本职工作,提高阶段效率

缺点:

1、在项目各个阶段之间极少有反馈,风险往往迟至后期才显露,失去及早纠正的机会。

2、项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂

3、测试人员最后才参与到项目中来,后期风险较大。

4、只有在项目生命周期的后期才能看到结果。

 

敏捷开发模式:

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不 尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织 型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。

在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。总的来说,拆分成多个小迭代,多次上线。

下面我们说说敏捷开发模式的几个特点

1、最核心的功能最先完成,容易出成果。

2、小步快跑,尽早交付,拆分各个小迭代(spring),一定的迭代周期内需要确保开发的完成,规避了一定的上线风险。

3、各组人员分迭代来有序工作,比如:设计人员出一个模块RP,开发人员完成这个模块编码,测试人员完成这个模块测试。

4、敏捷的管理是团队的自我管理和项目经理的服务式管理,项目经理需要根据当前开发资源确保每个迭代的的可完成性,团队成员需有良好的自我管理能力,来确保小迭代内功能的完善;项目经理需要对整体启到把控作用,迭代中可以根据开发进度进行各成员工作的微调,保证迭代进度的完成

优点:

1、容易出成果,可以快速提高软件发布周期,敏捷确实是项目进入实质开发迭代阶段,用户很快可以看到一个基线架构版的产品

2、测试人员能够尽早参与进项目中来,规避了一定的风险。​​​​

3、每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈​​​。

缺点:

1、迭代周期端,为了不影响迭代完整,需要项目中存在经验较强的人,要不大项目中容易遇到瓶颈问题,延误迭代进度。

2、敏捷开发要求各员工自我管理要强,所以对人员素质和稳定性的要求又更高。

 

那为什么互联网项目要用敏捷开发呢?

1、出成果(版本)快,互联网就是以快吃慢,一般都是迭代发布的,追求创新,说明了需要快速响应用户的变化,时间就是一切,需求不确定性高,这个在软件行业也很常见;关注用户行为,倡导以用户为中心的产品设计。很典型的例子微信,腾讯一个月开发出来的产品,根据用户体验和反馈,通过反复的小迭代来优化。

2、互联网项目中市场反响和客户体验尤为重要,需要有一个快速迭代来响应客户的需求,确保客户的满意度。如果是瀑布式开发,迭代慢,更改的成本也比较高。

3、随时应对变化,因为迭代周期的减小,使得项目的弹性更足,可以更好的适应互联网项目上更多的不确定性。

 

那如何从瀑布开发模式往敏捷开发模式切换?

任何开发模块的切换都是存在风险点的,包括我们前面介绍的前后端分离模式,那我们需要做什么来减少这些风险呢?

1、优先选择周期比较长的项目,资源较充足、素质较高的团队来试行。

2、需要制定一套较为完整的敏捷体系,从产品到开发到测试,选型敏捷工具

3、刚切换过来的迭代,可以适当减少迭代内容,切换过程需要缓冲时间,避免因为试行阶段出现的问题,从而团队的整个心态。

4、项目经理需要把控好任务进度,需要在迭代的中间,每天了解迭代运行情况,最好是每天团队可以有晨会。

 

 

敏捷开发

阅读数 2744

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