2018-10-23 10:10:39 dongjinkun 阅读数 560
  • SCRUM敏捷开发视频教程

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

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

在备战软考做题的过程中,发现敏捷软件开发方法考的还算比较多,而自己也一直没弄明白!

敏捷开发方法

极限编程XP 是一种轻量级,高效,低风险,不能使编码速度加快
水晶法 每个不同的项目都要一套不同的开发策略,约定和方法论
并列争球法 运用了“迭代”的方法,把每段时间(例如30天)一次的迭代成为一个冲刺,并按需求的优先级别来实现产品,有多个自治组织和自治小组并行的递增来实现产品。
自适应软件开发  

 

 

 

2012-03-30 17:17:02 adm12300 阅读数 9
  • SCRUM敏捷开发视频教程

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

    10426 人正在学习 去看看 CSDN讲师
在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
可以工作的软件是进度的主要度量标准。
对卓越技术与良好设计的不断追求将有助于提高敏捷性。
简单——尽可能减少工作量的艺术至关重要。
每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。
2013-06-18 14:26:37 GOALSTAR 阅读数 4401
  • SCRUM敏捷开发视频教程

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

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

部门采用敏捷开发了3个月,这3个月利用敏捷的思想在部门实施了敏捷开发的大部分实践和尝试,这里总结一下这3个月实施敏捷开发的一些工作状况。

一、敏捷开发的具体工作;

1. 整体人员进行敏捷开发培训,在部门内选择不同的人员担任产品负责人(PO)、ScrumMaster;

2. 敏捷团队的人员架构:敏捷团队到底是1个组(20人)好,还是分为多个开发小组(每个组5-8人)好,网上敏捷实施教练各说各的好,没有统一答案,我们尝试过、根据功能模块分为三个小组进行第一期开发、然后第一期开发完成后进行缺陷修复的时候,把团队分为1个大团队;

3. 敏捷开发的周期的时间,尝试过2周和1周一个Sprint周期;

4. 敏捷开发项目管理软件:Excel、RTC 、ScrumWorks 、禅道、白板。最终选定禅道来进行项目管理;

5. 利用Product BackLogs方式进行需求管理,采用故事叙述的方式进行需求描写;

6. 每日早会、工作估算

7. 其他等等

二、敏捷开发中的不足之处:

1. 实施敏捷的范围太大:错误的低估了敏捷开发的管理难度,当时我们认为相对与整个公司来说,部门20几个人实施敏捷开发已经是很小的一部分,我们没有敏捷教练、公司没有敏捷实施经验的人、所有的尝试都是摸着石头过河,导致实施敏捷过程中很多没有做到位,对整个过程来说效果不好,最直接的影响就是缺陷比较多、加班比较多等;

2. 团队磨合不足:部门刚成立,团队成员彼此之间的相互了解程度与整体磨合还不够,在分为多个小组进行开发时,小组之间的衔接不够好,开发、测试、需求之间的衔接做得不好,以往都是通过详细的需求文档、评审、设计文档进行沟通,忽然之间这些东西都弱化了,导致开发没有按照需求的设计开发、需求变更或通知不及时、需求没有验证开发产品、测试摸不着路。

3. 个人素质:敏捷开发要求人员的素质非常高,假如团队内有10个人,9个人很努力,但是有1个不努力然后又拿着同样的待遇,这个团队的生产效率绝对不会是90%,团队目前的大部分成员都没有达到敏捷开发所需要的素质;

4. 绩效管理:在实施敏捷开发中,个人绩效怎样和团队贡献结合,缺少针对团队绩效考核机制和细则,对团队考核机制实施的经验不足,带来的激励也不足。

5. 需求的管理:需求缺少一个总体的产品负责人对整个产品的需求从版本、整体需求管理进行把控,组内需求人员不足,更多的是UI人员充当需求的角色,出现的问题主要是在沟通的环节,需求的变更不能有效的通知到开发等我难题。

6. 开发:开发过程中首先犯的一个错误就是完美主义,开发这边在架构上花费的时间较多,导致很多重复工作,我们的架构尽量的简单,应该尽早进入开发,尽早的交付工作成果、通过不断的重构进行完善架构,我们想先把架构做得完美,做了很多现在还用不着的。

三、敏捷开发中较好的地方:

1. 敏捷开发中,发现了能够适合敏捷开发人员,这些人都能积极的沟通、发现问题、主动帮助部门成员。

2. 原型工作方式、在这3个月之中,我们不断的尝试怎样利用较好的原型方式加快开发和减少沟通的成本。

3. 部门内部的气氛较好,相互之间的沟通、帮助比之前好了非常多。

4. 沟通意识的提高、例如每日晨会(5-10分钟)的方式,这个习惯一直保持,养成了在团队内部能够快速响应,现在慢慢养成了一种比较好的快速沟通方式。

5. 部门内核心人员的素质提高、虽然敏捷开发过程中遇到了非常多的困难,但是部门核心人员之间能够主动提出问题、一起讨论和沟通、及时把偏差的问题纠正,在政民通第一期结束后,发现缺陷和问题较多,马上根据数据进行问题总结,提出解决了方案。

四、是否适合用敏捷:

1. 绩效考核:目前公司的绩效制度与敏捷开发的有一定冲突,公司的考核制度更注重考核个人,并不是说用来敏捷开发就不考核个人,而是选择了敏捷开发,就意味着需要选择比考核个人更有效的提升绩效的方法敏捷开发更注重考核团队,敏捷开发对于提升绩效的主要机制:不是依靠一个有强大控制能力的领导或一个固定的流程,而是一种能自我适应和改进的机制,进而让团队进入自组织状态,以自己的方法解决问题。

2. 激励机制:移动互联网人员工作需要很多外部的激励,如:工作成就感、晋升机会、较好的工作环境、他们天生需要很好的激励机制,但是对于我们公司目前的状况和所做开发的项目对于开发人员来说成就感不高,所以我们需要在做我们自己的项目之余努力寻找能够找到一些公众项目,然后利用20%的资源进行开发,建立更为有效的激励措施和机制实行。

3. 从前2个月来看,不适应全范围内实施敏捷开发,可以精选少部分人员进行创新型新产品开发(1-3个月的产品),如我们后期要做的几个项目;

4. 后期的社区类产品的开发,不能走敏捷开发的老路, 需要把CMMI和敏开发结合,敏捷开发中确实有一部分能够加快开发效率,比如原型工作方式、晨会、Sprint周期等。可以把CMMI进行裁剪适合移动应用开发的流程模式

2007-04-18 16:21:00 jepher 阅读数 4347
  • SCRUM敏捷开发视频教程

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

    10426 人正在学习 去看看 CSDN讲师
 
       如何使得程序员发挥最大的潜力,如何使用户最大程度上的满意。讲一下我们公司的这种开发管理模式――敏捷开发流程。
       就目前某一项目而言,该项目小组有5人,PL会在每周周四制定下一周的工作计划让程序员分别选择自己最有把握的部分来开发,并且让他们自己估计最好和最坏的时间。这样调动他们的积极性,发挥他们最大的能力,提高工作效率,会提前完成任务,而且有时间准备下周的咚咚。因为有冗余的时间,engineers会很高兴,效率高,从而形成良性循环。不过有些程序员可能会选择他们感兴趣的而不是最有把握的――措施――要承担到时候你做不出来的后果:别人都陪你加班;所以程序员会选择自己有把握的来做,而自己会用冗余的时间来做自己感兴趣的咚咚^_^
       同时每周的计划会被整理到trac上,让客户来确定优先级(major或者minor),对于被确认为minor的功能,将会被滞后,因为用户都已认为那是可有可无的。(不过我个人认为这个可能会有隐患,对minor的理解可能会造成某些方面的歧义)。用户选择好了优先级,而且这些咚咚都是你可以确保你的程序员可以完成的咚咚。每周工作结束的时候,你还会有最新版本的release note提交给用户。作为用户,他很清楚你这一周在干什么,而且你做的咚咚是经过他们认可的,最后他们也能看到你的成果,如果有和需求不一致的、不满意的地方他们也会及时的提交出来,而不是等到最后关头来解决。这样其实就是相互educate的过程,你的用户将会知道什么是可行的,你也会清楚的知道用户想要的是什么。而不会出现到了项目末尾由于不能在客户指定的时间内出某个版本而造成不愉快,或者说是你作出来的咚咚根本不是客户想要的。这样互相educate,最后就能实现所谓的双赢。
       对于有明确客户的项目来说,这确实是一套不错的敏捷开发方法,而对于没有明确客户的项目(就是那种自己做东西,然后等着被别人看上的)将如何处理那?其实有时候客户明确了,客户也不一定清楚自己想要要什么,即使有了明确的客户,你也会发现客户会不断的修改和增加他们的需求。但对于没有明确客户的项目来说,你的客户就是定位市场的研发人员,他们的职责就是发现客户的需求,或者说可以刺激客户的新需求,让用户发现原来这样会更好。
 
2016-07-31 07:18:48 lijian1975 阅读数 780
  • SCRUM敏捷开发视频教程

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

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

         由于团队最近计划执行不顺利,项目经理在知道我经历过敏捷开发的流程后,让我给团队内部的各个小组分享SCRUM敏捷开发相关的知识,并负责推动团队敏捷开发计划的建设。

          scrum 是一种迭代增量软件开发方法,通过该方法,你可以量化工作量,并且可以把每个任务量化成具体时间,得出最后一个项目的总时间(一般估算到小时)。能让管理者看清楚项目进度,把握项目进程的各种问题。scrum简单易用,但是简单的东西要掌握就容易犯错,大家可以在尝试中掌握这种项目管理方法,以下是我做内部培训个人写的教程,抛砖引玉,希望能普及该方法。

         什么是Sprint??

        Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

        在scrum里面,有3种角色,分别是product owner(产品负责人)scrum master(团队负责人)scrum team (开发团队):


  Product owner:是需求方,提出需求,能对功能流程,业务流程拍板的人。


  Scrum master :团队负责人,一般是product manager,负责解决团队问题,领导项目。


  Scrum team:项目执行人员,开发项目一般包括,前端后端开发,ui等。


        scrum的流程如下:

      Scrum 步骤一:

  头脑风暴,如果product owner 对产品需求非常清楚,就可以省略这个步骤,开发一个原则“先紧后松”, 必须先把需求了解清楚,这里product owner可以召集技术团队/用户群体对其需求进行公开征求意见,最后输出一个产品建议表。

  Scrum 步骤二:

  product owner 对产品建议表进行筛选,做减法提炼最核心的需求。在确定了需求后,这个时候由scrum master 进行输出prd (product requirement document) , 这里就和传统的瀑布流一样了,该有的文档都必须有了,必须由scrum master 和product owner 确定好需求,包括业务逻辑,功能流程等。

      

     Scrum 步骤三:

  原型,ui设计都不是在步骤二完成的,把任务量化,包括,原型,logo设计,ui设计,前端开发等。

  尽量把每个工作分解到最小任务量,最小任务量标准为工作小时不能超过8小时。准备估算总体项目时间吧!

  把每个任务都贴在任务看板上面,看板上分为四部分:

  (1)to do待完成

  (2)doing 正在做的

  (3)done 已完成的

       (4)Cancel  推迟的

       

     如何估算时间:玩扑克游戏这个方法估算出来的工作时间比较准,参与扑克游戏的最好有专家和开发涉及到的人员。

  扑克游戏玩法:

  (1)每个人发一部扑克牌,使用扑克牌来进行打分,扑克牌的面值分数有1分、2分、3分、5分和8分,1分代表1小时的工作量。

  (2)同时展示该项目完成时间,肯定存在最大最小的工作时间,最大最小两个人请你们辩论吧,为什么要那么长时间完成,或者那么短时间完成,其他人可以提出疑问,在一定程度上达成认可。

  (3)进行再次私下对该任务写时间,再公示,再辩论,这样下去,大家写出来的该任务的时间越来越接近了。

  (4)最后达成一个共同认可的时间,这个就是该任务的工作时间!

  

   Scrum 步骤四:

  经过大家纠结讨论了好久,终于把任务量化到具体多少时间完成了!接下来,把n个任务按照开发的重要度,组合成n个sprint( 冲刺),每次执行一个sprint。


       每个sprint 都是独立的,一般先做主要功能,再到次要功能,再到小功能,最后的sprint 一般是修复bugs。

       因为任务都被量化了,每天工作了多少小时,完成了多少任务量,通过每天例会scrum master非常清楚,并且在时间燃尽图进行表示。我们就可以直观看到任务的进度了,而且是具体到多少小时!


         通过时间燃尽图可以可视化任务的时间进度,大家可以看下图,day1 是整个任务的总共时间,每天按照任务完成度更新剩余时间,或者增加时间(例如发现一个技术难点,团队成员请假等要增加开发时间)。


         Scrum 步骤五:

        需要进行 每日站立会议,每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 时间燃尽图。

      

       Scrum 步骤六:

      当一个Story完成,也就表示一次Sprint完成,这时,我们要进行演示会议,也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);最后就是 回顾会议,也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

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