2006-06-23 09:19:00 LightTempler 阅读数 1034
  • SCRUM敏捷开发视频教程

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

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

敏捷开发的精髓在于快速响应。

响应什么?相应变化。

谁的变化?需求的变化。

 

如果我们能够每隔一秒钟就从用户那里重新获得需求,然后进行分析、设计、编码、测试,那么我们就不会抱怨用户的需求总是变化了。因为在这一秒钟的时间段里,用户的需求没有任何变化。但是显然,这不可能。

 

不可能的地方有两个,一是我们不能每一秒钟就重新获得一次需求。二是我们不可能每次都对用户的需求重新分析、设计。

 

但是我们可以找到一个相对平衡的时间段和需求块,尽管不是完美的平衡。时间段有多长?取决于用户需求变化的速率。需求变化得越快,那么获取的频率应该越高。每次对多少需求进行分析和设计?这取决于我们拥有多少时间以及我们的工作效率。(对这句话我还不是特别肯定)。

 

为什么需要重构?因为它会使代码更灵活,拥有更好的反应能力。

为什么要拒绝腐化的代码?因为死人是永远不会做出响应的。

2012-01-19 20:38:19 mqbtjcyts 阅读数 1020
  • SCRUM敏捷开发视频教程

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

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

工作一年多了,所在的公司采用敏捷开发。作为小团队里一名普通的开发者, 既体会到了敏捷的优点,也收获了很多经验教训。在此记录一下自己地感悟,如果有朝一日自己去领导一个敏捷开发团队,要尽量想办法避免和解决这些问题。

背景介绍:

公司的开发进度是大概每5-7周发布一个小版本,这里面包括了1周的各种测试时间和1周的上过渡服务器的时间,所以实际上code freeze一般是每个开发周期开始后的3-5周。本人所在的小团队大约有5到6名开发,其中包括一名Team Leader,4名QA。 团队也有一名PM, 但是远在美国,一年见面沟通时间不足一个月。公司采用JIRA作为项目管理和追踪的系统。每个开发周期会有很多Feature, 通常是每个Feature由一名开发负责coding,一名QA负责测试,而每名开发和QA会负责多个Feature. 某些非常大的Feature, 会由多名开发和QA组成一个更小的团队共同开发。

Feature的复杂度和开发时间评估

在我加入公司的前半年,正好团队在进行人事调整,除了Team Leader外,其他开发人员对每个Feature几乎都没有背景知识,更无从评估复杂度和所需时间, 所以所有Feature的评估几乎都依赖于Team Leader一人。Team Leader经常性地估少了Feature所需时间(或者高估了开发的能力),过分乐观的结果是开发和测试人员经常性地加班或者赶工,背负了过多的压力。另一方面,因为开发时间的仓促,也导致了Feature质量不高。

在后半年,由于Team Leader管理能力地提升,团队成员逐渐了解自己负责的各个模块,加上团队成员对之前评估不准确的种种抱怨,在Feature评估上有了一些改善。在每个开发周期开始前的例会上,Team Leader会和开发人员一个个地过这些Feature, 开发人员如果认为评估时间不准确,会给出自己的意见,然后Team Leader再跟高层管理者沟通,进行Feature的调整。个人认为,这件事情说明高质量高效率的敏捷开发对Team Leader和团队成员的个人能力要求很高,并不是一个低门槛的开发方式。

与PM的沟通

团队的PO (Product Owner) 职责主要由 PM 来担任。我记得以前在看敏捷开发的一些成功经验时,其中很重要的一条是说PO要和团队天天在一起工作。但公司的情况是,PM都在美国,虽然会通过邮件甚至skype来联络,但是总有时间上的延迟以及沟通上的误会和信息的缺失。对于一些小Feature还没有太大的影响,但是本人亲身经历了2个需求复杂,工程量和时间跨度巨大的Feature, 无法和PM在一起工作就带来了各种个样的问题。有一次,按照需求文档花了2周时间做完的部分,在和PM电话讨论时被告知文档写错了,因而对底层代码又花了1周时间进行了大换血,浪费了宝贵的时间。更经常的场景是,因为无法实时地面对面地与PM沟通,当Feature大体完工后,PM会对各种细节给出超过20个修改意见,又是本可避免的巨大的时间开销。 个人曾经非常希望在做其中一个大型Feature的时候去美国与PM一起工作,不过公司似乎完全没有考虑过,所以只能咬牙坚持。不过如果以后自己做事情的话,一定会尽量避免这种“异地”问题。

团队激励与士气

这是所在团队最严重的问题之一。管理者没有做出足够的努力去了解每个团队成员,很少进行team building之类的活动(一年好像只有2次),更没有采用任何有效的激励方式,直接造成了一些成员没有积极性、情绪低落,甚至对工作完全失去兴趣。所表现出来的就是产品质量低、效率差、不稳定。如果我是管理者,哪怕自己掏钱,也要隔一小段时间就带其他成员去吃饭喝酒谈心,去了解他们的想法和情绪,然后在工作中做出适当调整。如果有条件,更会给予优秀者丰厚的激励,给非常不上进的人严厉地处罚,保持团队士气向上。

个人英雄主义完全不可取?

几乎每个公司都在说要注重团队合作,杜绝个人英雄主义,但本人的实践感悟是,普通情况下团队合作是对的,但是在一些时间紧、项目大的场景,个人英雄主义可能更能带来更好的结果。从最后一个季度,我主要做了两个大项目。第一个用时一个开发周期,只有我一个人负责。第二个用时3个周期,第一个周期主要我一个人,第二个周期4个开发人员,第三个开发周期还在进行中。因为第一个项目和第二个项目的第一个周期基本上就我一人,所以不存在什么‘不同意见’的情况,都是我自己思考和做决定。虽然也会犯错误,但是都能保证在最短的时间完成最多的Feature,同时保证系统的performance和stability维持在一个高标准上。

问题就出在第二个项目的第二个开发周期,这时候其他几位成员陆续进入共同开发,本以为能为我分担很多工作,让我更专心攻坚一些框架上的问题。结果由于大家在一些问题上的见解非常不一致,同时因为我没有任何权力和资历去做任何决定,所以造成了在很多问题上无休止地争吵,以及一些实现上地互相妥协和返工,完全打乱了我自己的计划和节奏。就个人标准而言,对第二阶段的产品非常不满意,在accuracy, performance, stability上都远没有达到我的预期。思考良久,觉得如果当初让我主做这个项目时,赋予我一票决定权、一票否定权,然后给每个人的工作职责一个非常明确的划分,不允许大家越界干扰其他人的工作,只可以定义‘接口‘来沟通,相信会比现在有一个更好的结果。

一言堂固然不可取,但过度Team Work有时带来的更是负面作用,不仅耽误了时间和进度,同时使产品因为各人不同的理念而变得四不像。其实敏捷开发很像打仗,因为要在有限时间和资源下攻取一个个阵地。这时,如果要派人带兵去作战,就一定要赋予这个人兵权,否则如果因大家意见不同而不听命,互相扯皮,甚至互相拖后腿的话,会陷入很尴尬的境地。


2010-08-05 14:58:00 ws715 阅读数 3049
  • SCRUM敏捷开发视频教程

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

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

一  引言
  
      近来,在BOSS系统团队敏捷开发熏陶和感染下,对敏捷开发求知是蠢蠢欲动. 心动不如行动. 咱也不能被动接受挨打吧. 这几天向战斗在BOSS一线具体参入人员问了卷,
实施敏捷开发大哥们们请教. 感觉是个好东西.它是对传统的以瀑布模式为主的项目管理一次抽取精华和改进(个人认为,PMB项目管理的理念,敏捷开发中具体方法都有它的影子,只是浓缩精华).但觉得脑子里只是一些零散的概念,没有对敏捷开发系统理解。没有整体把握,底气不足,作为敏捷开发中注重以人为主,团队自管的思想, 咱也提不出好的改进意见 . 不利于敏捷持续发展. 于是利用中午和晚上时间在网上下载一些敏捷开发文档学习 , 赶快来武装自己。与时俱进,落后就要挨打哦!
 
   系统学习了敏捷中两个方法(极限编程和Scrum),结合以前学习的pmb以传统的过程为主,强调文档:一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。
有点像工厂流水线作业. 这一综合,思想就有点火化了。感触敏捷开发体现了一些我们平常生活、人生哲理。就不再太罗嗦,言归正卷了。
 
    
二  敏捷开发所体现的哲理
 
    1、与时俱进,不断改进,不断完善理想
 
       敏捷开发中一个重要的思想就是要在具体项目中不断改进。主张要不断完善,发现问题,勇于针对具体的问题,引起敏捷方法实践
     勇于重构代码。这些理念在我们生活中也同样受用。古人云:知错就改,人无完人。也是要求我们要勇于承认自己的不足,只要我们有勇气
     发现问题,分析问题,勇于改进。这样我们才能够前进。哲学上讲矛盾的原理也是一样的。
 
    2、集中力量解决重点问题,小步前进,稳扎稳打,步步为营
      
      敏捷开发注重迭代开发,增量的进行工作,小步前进,不停的思考、反省和总结,不停地进行自我调整、完善、改进. 这种方法很明显是能够
    及时发现问题、总结问题,降低项目中的需求风险和开发进度风险(需求列表排了优先级,前期就可以把客户确认的重点需求投入精力做好,
    后面迭代sprint周期能够根据前一个周期srpint情况来及时调整和改进).
 
    3、注重以人为本的思想,注重参入、沟通、反馈
 
        敏捷开发中的极限编程方法论中实践原理中很多体现了这些理念。如:让客户编写user Story,让客户参入具体的功能需求编写过程中;sprint周期
    中定期加强为客户的沟通;客户与开发人员尽量在一起办公;开发人员集中办公,及时沟通;结对编程;隐喻(一些好的规范,专业术语提前在团队
    中集成共识) ,代码共用,晨会等.
        
         这些方法在我们实际生活同样实用.毕竟任何东西还是要由人来做的。因此在各个场合都会存在调动人的积极因素来影响环境和事物。
 
     4、简单原则
 
          极限编程体现跟踪客户的需求变化,既然需求是变化的,所以对于目前的需求就不必过多地考虑扩展性的开发,讲求简单设计,
     实现目前需求即可。简单设计的本身也为短期迭代提供了方便,若开发者考虑“通用”因素较多,增加了软件的复杂度,开发的

     迭代周期就会加长。简单设计包括四方面含义:

                  1、通过测试。2、避免重复代码。3、明确表达每步编码的目的,代码可读性强。

 

       简单哲理在我们生活中也是无处不见,感觉最明显是我们穿的衣服更简朴和舒适,更适合我们个性展示;还有大家经常说复杂问题简单化,简单生活,

    快乐生活等都体现对人生豁达、快乐的态度.

 

     ......

 

三  建议

 

    1、民主参入度有待加强

      

       这几天我问了近十几位一线参入BOSS和CRM敏捷开发人员(大部分是合作方)。主要涉及对敏捷的认知,参入度,参入角色等。发现大家基本还是认同敏捷,

      但是对一些具体的实践方法还是存在模糊的认识,甚至抵触心理。比如:结队编程 (实际上结队编程在运用时是要根据实际情况而定,有一定边界条件。

      像对新员工,对核心关健业务,对sprint迭代检查过程中发现大家编程问题等,这时可以实施结队编程).其次有就是对敏捷基本都没有一个完整的概念。如:

      敏捷中的基本思想,敏捷中几个主要方法,敏捷每个方法用途和使用的条件等。最后,就是参入访问的人基本都没有接触过敏捷开发软件,对一些天天写在墙上的

      “燃尽图”都不知道,缺少参入意识(写这个时,徐志明发Mingle的使用知会,希望大家在使用这个软件时对敏捷起到加深理解作用。应早该一点发给我们啊!) 。

 

        a  敏捷开发人员是以人为本,着重的实施还是得靠大家,需要大家共同的参入、支持和理解。希望领导在具体实施过程中让更多的人参与进入。

             参入过程中要加强PL的职责和引导大家作用。让更多一线工作人员,特别是合作方,有一个认同感,尊重感。调动他们的积极性和主动性

        b  加强团队组织建设,落实负责人责任制。现在感觉BOSS团队上层参入讨论敏捷很活跃,根据实际的项目运用了敏捷开发中权限编程、Scrum和传统方法结合,

           政策和方向都是正确的,但是到下面pl下一级具体落实下,需要pl对敏捷开发能够灵活运用,引导本组人员进行敏捷开发学习,讨论、参入.

 

    2、 每日晨报内容要根据具体的情况而定

 

       我们进行的晨报大家现在都认可了,大实现中也取得一定效果。但是感觉有些组还是基于它所表现的三种基本的形式(今天做了什么,明天做什么,所遇到困难).

       个人觉得晨报的内容要根据项目、各个小组具体的情况而定,不可一概而定,基于形式。

 

          a、 根据sprint周期后总结中发现问题,针对性在下一阶段的sprint周期中引入晨报内容。如:在sprint周期总结中发现大家编程不规范,在Daily Scrum meeting

              注重检查编码规范问题;如:上次CRM团队检查代码质量时发现一些问题,在下几个Daily Scrum meeting中注重检查代码质量问题,至到问题解决为至。

         

          b、 根据项目开发不同阶段制定Daily Scrum meeting;

 

         个人认为引为这个东东,还是为了解决问题。在过程中不断改进。

 

    3、 技术专家人员支持、重视有待加强

 

         来华为两年了,感觉这边是很重视业务的,不注重技术。毕竟BOSS业务比较复杂,业务重要是不言而遇。但是在实际的BOSS维护中,发现很多的二线问题、bug单

       都是由技术引起。而一些有经验的老员工,管理人员很少参入到技术当中把关。以至BOSS一些问题单每月每天循环出现。虽然现在引入了测试驱动开发、持久集成等

       方法,但是一些核心业务还是需要技术专家来监督。

 

       a 、 对一些核心代码,关键业务,除了要进行测试外,更重要是专家技术人家承担起负责,对其功能指导、监督、检查,

            必要时可结队编程;

       b、  在团队内部要形成一种气氛和文化,技术和业务都重要。甚至在待遇方面要落实;

 

    .............

 

     看见BOSS团队根据我们实际出发引入敏捷开发,甚感高兴,有喜的事,现在已取一定成果。愿我以上的感悟对我们团队有所帮助和启发

2018-07-15 10:10:45 wer0735 阅读数 703
  • SCRUM敏捷开发视频教程

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

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

敏捷开发的主旨

  一:个体及交互比流程与工具更具价值
  二:可用的软件比冗长的文档更有价值
  三:与客户的协作比合同谈判更有价值
  四:对变化的响应比遵循计划更有价值

直接聊宗旨有些抽象了,举些栗子就会发现这个宗旨极恰当。

以下内容为转载:http://www.lanceyan.com/category/tech/agile

我们技术团队人员是这样的配置:1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作,能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师,参与新项目开发时间大概有80%。高级工程师要预留项目学习时间,参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目,但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命,属于机动部队。

现在总共有六个老项目在维护,两个新项目需要开发。六个项目的维护总共需要每周4人天时间(人天指需要花1个人4天的时间完成一个事情)。其中一个新项目“项目1”大概估计120人天的开发时间,需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间,需要2周开发完成。而现在的人力按照能够投入的时间算一下,总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天,6个老项目每周需要4人天,一个月4周,需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天,而总共需要120 + 40 = 160天,足足少了44人天,这看起来是一个不可完成的任务。

不过到最后,我们还是使用敏捷开发完成了这两个项目,也没有影响老项目的维护。我们是怎么操作的?最开始我们两个开发,这个时候只要两个人就能够很好的合作把产品开发出来,不需要什么模式。随着人员的扩充,团队间如何协作按时按质按量完成任务就需要好好思考下了。

尝试一,传统软件开发模式。整个过程为 需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式,不过套用在我们公司时我们是这么操作的。

由于公司创业,老板有一个想法,但并不能很好的描述需求,所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成,后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成,资深工程师进行把关,再到测试人员测试,最后再交付用户验收、技术维护。看起来很好的模式,开发了几个产品最终有的延时有的产品离用户的期望差距甚远,参与项目团队的人信心受挫。

为什么会失败呢?后来思考了这些问题:

1、技术总监不是产品经理,不能够承担产品设计的责任。老板是信任技术总监能做好产品,就交给他做。但这里搞混了一个概念,产品经理和项目经理,技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好,责任所在。说到底,就是机制没有把产品设计和项目经理区分开,不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

2、需求不稳定,变化后改动代价大。由于创业,需求为了适应市场会经常调整,但是一但调整,很多开发计划就会受到相应的调整。如果部分功能已经正在开发,调整需求后很多工作要重新开始,严重影响了技术同事积极性。业务不调整需求是不可能的,他们是为了满足用户的要求,用户满意了才能给企业带来价值。不过如果调整,代价太大,很多代码要重写,大家就会责怪技术总监或者项目负责人没有把握好需求。

3、团队经常加班,但战斗力不强。 核心团队疲于应对需求、技术开发、老系统维护,没时间指导新同事技术学习,而新同事技能暂时还没有发挥出来干活效率低,任务经常延期,没有成就感。核心团队事情很多,没有时间整理项目文档,新员工没有文档上手慢。大家每天很多事情,需要加班才能完成,比较疲惫。每个人除了工作还有很多事情需要做,比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作,他能同意,他家人也不一定同意。让大家愉悦的开发,比疲惫的上班效率要高很多。

4、交付软件质量差,离用户期望差距大。创业时大家的想法都是好的,大干一番,做一个所有人都爱使用的产品。现实是残酷的,大家辛辛苦苦做出来的东西,老板不满意、用户不埋单,付出的努力没有人认可。交付的软件没时间自测试,或者自测试不充分,交给测试又是一大堆问题。有些公司还没有测试,直接出去给用户,相当危险。这样交出去的公司不仅仅影响了用户的使用,还影响了整个公司的口碑。

不是说传统软件开发模式不好,只是不太适合我们这种创业公司。开始尝试其他模式,如果没有一个很好的体制就不能把大家的最大生产力发挥出来。

尝试二,敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本,专注于交付对客户有价值的软件。在高度协作的开环境中,使用迭代式的方式进行增量开发,经常使用反馈进行思考、反省和总结,不停的进行自我调整和完善。

敏捷开发的主旨:(这个时候再看看就感觉很有意义了)

一:个体及交互比流程与工具更具价值
二:可用的软件比冗长的文档更有价值
三:与客户的协作比合同谈判更有价值
四:对变化的响应比遵循计划更有价值

而我们之前的问题,交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试,先看一张敏捷开发的流程图。


创业公司敏捷开发敏捷流程化

敏捷开发简单流程

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中遇到的问题、改进和大家分享讨论。

我们怎么结合敏捷开发解决现有项目的问题,要记得任何措施都是为了保证按时按质按量把软件交付给用户,不要为了敏捷而教条实施敏捷,公司不能产生商业价值,任何先进的理念或者技术都是无意义的。我们做了这些措施:

1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的,才能被认可。

  • 首先培养测试小妹学习敏捷开发,后续让她承担部分产品责任人和敏捷指导者的角色,原因有:
    a、测试要验收功能,必须理解业务需求。
    b、测试也是QA质量体系的一块,学习好了对于软件质量有个更深的认识。
    c、团队大部分是男生,女生推广更有亲和力一些。
  • 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下,怎么给大家说更有效,更容易接受。她要讲解一定要自己非常清楚敏捷开发,并且准备充分知识点。开会时先指出我们现在问题,让大家看看有什么想法解决问题吗?现在我们做的产品,客户不认可、老板不满意、自己很累没有成就感,有什么办法解决。在大家讨论后,抛出敏捷开发的优势,一般情况下大家都会认可的。大家可能会问到如何执行、落地,可以尝试找一个项目试点,如果实施成功就可以让大家全面推广,不成功也只影响了部分项目。

2、搭建敏捷开发环境。大家要实施敏捷开发,需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件:nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》

3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说,目的是完成这个项目,需要进行这几步:

  • 先根据各自的能力和意向聚集一批完成这个目标的勇士,不管技术和非技术。如果聚集的人不够,技术总监可以根据总体项目的投入机动调整资源以支持,不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试,除去大家做其他事情的时间,总共可以算作4个人。
  • 充分调动客户(老板和业务同事)参与进项目,他们的参与直接决定了项目成功与否。结合之前的经验,如果他们参与不够,最终做出来的东西就不是他们要的,或者离他们要的差距很大。他们刚开始加入的时候,很迷茫有时会表现的比较抗拒,这个时候一定要耐心坚持让大家把第一个sprint开发成功,使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化,如果有需求变化,就添加任务到任务墙,大家可以对所有任务的时间有个全面了解,如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
  • 技术总监安排和客户沟通,客户这里指老板和业务。测试小妹负责和客户沟通记录,技术总监辅助。多次沟通后,尝试让测试把需求原型用最简单的工具绘制出来,技术总监审核通过后和客户沟通确认,反复迭代,直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行,但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题,过度技术设计产品。
  • 产品设计出来后,召集项目成员分解任务,确定每个任务的时间,可以使用敏捷扑克牌来估计。任务分解尽量控制在1-2天的粒度,这样大家1-2天就可以做出一个能测试的原型,尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周,不能太长,也不能太短。太长会出现疲劳,太短的sprint会让大家觉得工作太多,做完一个又一个。“项目1”估算结果为120人天,总共投入4个人,需要30天4周时间,我们切成了4个sprint,差不多1个月时间完成,满足业务的时间要求。
  • 分阶段实施sprint,绘制任务墙,划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙,贴到未开始的地方。
  • 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务,统一管理起来。强调的是一个团体,如果有同事请假,其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题,对于当前的任务有什么建议,尽量控制在15分钟内,有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果,而是团队驱动,每天大家做的事情都反映在墙上,谁出现了什么状况,大家都会帮他想办法,保证整个项目能够成功。每一个任务完成,由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
  • 软件开发过程。认领任务后,怎么保证大家开发有质量的代码?团队有资深点的工程师,不需要太多指导,直接可以参与项目的开发。而学习型工程师,需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务,他负责开发团队的概要设计审核,没有审核通过的设计不能开发,并指导大家分析和设计系统。大家都知道,系统思路有了,剩下就是技术实现的过程,只要技能掌握熟练实现基本难度不大。大家可能会问,敏捷开发不是强调软件开发的产品是软件,而不是文档吗?我们这里也不是像传统开发软件一样为了文档而文档,只是让大家把自己的设计思路写下来,只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论,这样的文档是不欢迎的,受欢迎的文档只需写出用例分析,表设计,复杂的逻辑需要画出流程序列图。
  • 结对编程。之前这个编程模式被无数人调侃过,其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时,会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时,很多时候都会结对,比如指导新同事、讨论设计模块,而之前这些都没有算在我们的开发工作量里。
  • 项目演示和总结会议。在项目结束后,让所有参与项目的成员都参加,一起演示给客户展示,并解答客户的问题,充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享,并为下一个sprint做准备。

经过敏捷实施后,我们的生产力提高了很多,员工的积极性提高了,业务的参与使整体需求把控也很好,大家沟通多了,30天的任务提前了5天完成。我们多出来的时间,让大家每周有一天或者半天研究自己感兴趣的领域,但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术,最后做完需要写个ppt给大家分享下。既能让大家做自己想做的事情,也给大家创造了一个互相学习的氛围。

ps:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。

2007-10-27 22:01:00 softart 阅读数 703
  • SCRUM敏捷开发视频教程

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

    10406 人正在学习 去看看 CSDN讲师
2007年04月15日 23:37:00

Author:袁琳
MSN:testwin@sohu.com

什么是勇气?

三名海军上将谈论起什么是真正的勇气。
德国将军说:"我告诉你们什么是勇气。"说完他召来一名水手。
"你看见那根100米高的旗杆了吗?我希望你爬到顶端,举手敬礼,然后跳下来!"
德国水手立即跑到旗杆前,迅速爬上顶端,漂亮地敬个礼,然后跳了下来。
"呵,真出色!"美国将军称赞说。接着他叫来一名美国水兵命令道:"看见那根200米高的旗杆了吗?我要你爬到顶端,敬礼两次,然后跳下来!"美国水兵出色地执行了命令。
"啊,先生们,这真是一次难忘的表演。"英国将军说,"但是我现在要告诉你们,我们皇家海军对勇气的理解。"
他命令一名水手:"我要你攀上那根300米高的旗杆顶端,敬礼三次,然后跳下来!"
"什么,要我去干这种事?先生你一定神经错乱了!"英国水兵瞪大眼睛叫了起来。
"瞧,先生们,"英国将军得意地说,"这才是真正的勇气!"

勇气源于什么?

勇气并非源于内心对某种事物的恐惧,而是源于自信、知识、情绪、环境等各种因素的综合评估决策。

有勇气的人

愿意提出自己的观点,哪怕这些观点并不受人欢迎。不会为了规避冲突而屈服于压力或他人的观点。能够坚持自己认为是正确的东西。能够根据现实的状况,对自己的想法与思考方式做出改进。能够承认自己所犯的错误,愿意对自己的行为与想法承担责任,并对此错误进行深入的探讨。

敏捷 & 勇气

1、有勇气主动挑战工作,并承担责任。

2、有勇气只进行简单的设计,并相信它能够满足客户需求。

3、有勇气编写测试代码,并相信测试代码能够满足需求。

4、有勇气拥抱变化,积极适应变化,响应客户需求。

5、有勇气在需求变化时重构代码。

6、有勇气不断采用新的开发技术或方法,不断改进,以提高用户满意度。

7、有勇气对自己的阶段工作进行回顾,总结自己错误的行为并及时纠正。

8、有勇气面对各种困难和风险,鼓励并带领伙伴一起齐心协力、克服困难、渡过难关。

9、有勇气向客户承诺并达到它。

10、有勇气对用户说"不"。尊重用户价值,对用户负责,不欺瞒用户。

11、有勇气挑战权威,表达自己正确的见解并用实践证明。

12、有勇气接受任何成员的好建议并改进之。

... ...



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1565871


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