敏捷开发误解_项目经理在敏捷开发中的作用敏捷开发 - CSDN
  • 敏捷开发方法的误解

    2011-06-08 12:36:39
    有的人对采用敏捷开发是否能真的有效提高效率并生产出成功的产品表示怀疑。他们认为,在敏捷方法中,由于没有经理的管理和约束,团队和项目必然是一团糟,仿佛越是上层越有这种想法。敏捷开发的理念是信任开发团队,...
    有的人对采用敏捷开发是否能真的有效提高效率并生产出成功的产品表示怀疑。他们认为,在敏捷方法中,由于没有经理的管理和约束,团队和项目必然是一团糟,仿佛越是上层越有这种想法。敏捷开发的理念是信任开发团队,信任每一个人。试想一下,如果你们这个团队对你们的项目充满激情,而老板又充分信任你们,那么你们必会将更多的时间花在如何有效地提高生产率、如何创新地完成某个功能等方面,而不是按老板的意思按部就班地工作了,这样还会节省很多时间并简化流程,例如开会、向老板报告、请示老板、等老板批准等。就像咱们刚才的那个游戏结果所揭示的那样,充分调动参与项目的人员的主动性,让他们自我组织、自我管理,由团队自身来掌握项目进度,比老板整天催促反而更有效率。
    当然,敏捷开发的团队也需要管理,但这些管理是非命令式的,很多时候是战略指导和服务性质的。在敏捷开发中,管理者对团队和项目的管理表现在挑选合适的人、为团队创造一个开放而自由的工作环境、经常性的反馈、为团队建立评估和奖励机制、当团队有方向性错误时能及早发现并纠正、容忍错误的发生等
    还有一种误解,认为敏捷开发就是完全不需要计划、文档和架构设计。这种看法也是不对的。敏捷开发也需要文档,也同样要计划。但我们要明白,计划赶不上变化,在这样一个不断变化的情况下要做出详细的计划是不可能的。因此敏捷方法认为不值得在这些因素上花费过多的资源,可工作的软件才是敏捷方法关注的重点。敏捷团队依靠变化来获取活力,他们更愿意使设计保持尽可能的干净、简单。基于以上的原因,采用敏捷方法的项目初始设计是比较粗略的,并需要使用许多测试手段作为辅助,这就保持了设计的灵活性和易于理解性。团队可以利用这种灵活性持续地改进设计,以便于每次迭代结束时的系统都具有最适合于那次迭代中需求的设计。摆脱一切对软件开发不合理的束缚就是敏捷。”
    敏捷联盟的发起人Martin Fowler 和Jim Highsmith 曾经这样解释过:敏捷开发所追求的是一种平衡——我们也建模,但不仅仅是画几个模型图存放在少人问津的项目文档库里;我们也需要文档,但从不浪费纸张去编造那些极少使用而又没有保存价值的大部头;我们也做计划,但我们同时也认识到在这纷繁复杂的环境中做计划是困难的
    但是,敏捷开发不是可以解决所有问题的银弹。在实际的项目中,受条件的限制,有些原则实施起来确实有困难,那该怎么办?要知道,敏捷并不要求你们一成不变地遵循这些条条框框,遇到困难时应该灵活地调整策略,这样才真正达到了敏捷的目的
    展开全文
  • 一、敏捷是“一个”过程 敏捷不是一个过程,是一类过程的统称,它们有一个共性,就是符合敏捷价值观,遵循敏捷的原则。 敏捷的价值观如下: 个体和交互 胜过 过程和工具   可以工作的软件 胜过 面面俱到...

    一、敏捷是“一个”过程

    敏捷不是一个过程,是一类过程的统称,它们有一个共性,就是符合敏捷价值观,遵循敏捷的原则。

    敏捷的价值观如下:

    个体和交互 胜过 过程和工具
      
    可以工作的软件 胜过 面面俱到的文档

    客户合作 胜过 合同谈判
      
    响应变化 胜过 遵循计划
      
    由价值观引出的12条敏捷原则:
      
    1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。  
    2、即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。  
    3、经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。  
    4、在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。  
    5、围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。  
    6、在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。  
    7、工作的软件是首要的进度度量标准。  
    8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。  
    9、不断地关注优秀的技能和好的设计会增强敏捷能力。  
    10、简单——使未完成的工作最大化的艺术——是根本的。  
    11、最好的构架、需求和设计出自于自组织的团队。  
    12、每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
      
    建立敏捷联盟的17位大师所创立的敏捷方法包括:极限编程,Scrum,特征驱动开发,动态系统开发方法,自适应软件开发,水晶方法,实用编程方法。这些方法统称为敏捷方法。
      
    其 实每个人都可以从敏捷宣言和原则出发,明确问题,找出一些解决方法,形成自己的过程。我觉得国内的软件环境这么复杂,程序员的自主精神又这么强,敏捷方法 应该是在中国首先提出才对,只是国人都有唯标准唯规范至上的心理定式,即使找出好办法,也觉得不规范,没有深入形成理论,无法提升高度,始终是跟着鬼子屁 股后面走,我想这也是国外软件行业不成熟的表现之一吧! 

    二、敏捷仅仅是一个软件过程

    如果仅仅从软件过程的角度去认识敏捷实施敏捷,效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上,正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。

    涉及到人的问题,就已经不再是过程所能覆盖的了,就到了企业管理的层面上了,包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍:

    1、把客户当作合作伙伴而不是对手,从客户角度出发去想问题,充分的跟客户沟通,而不是出了问题推诿责任。目标是让软件实现客户的价值,而不是收钱就完事儿。
    2、把人的能动性调动起来,给动力而不是给压力。
    3、要实用而不是要规范。让开发人员理解并实施,体验到敏捷的好处,而不是盲目机械地实施规范。

    没有绝对的权威,每个人都有可取之处。

    三、迭代就是敏捷,UP属于敏捷

    看到这么多人都把UP归入敏捷,我都开始怀疑是不是自己搞错了。但是在我的印象中:
      
    UP是重型的过程,虽然引入了迭代,但是其 原则和价值观与敏捷是不同的。敏捷注重的是反馈,迭代周期尽量的短,重在客户的参与,通过客户的参与,获取持续的反馈,不断调整使整个项目走在正确的方向 上。同时也给客户一个感受和思考的机会,因为对于大多数客户而言,目标是明确的(不排除有些客户目标也不明确),但是具体怎么做,开始时是没有想法的,只 有看到具体的东西的时候,才知道“噢,原来可以这样,那我想把这里调整一下”。

    四、敏捷是彻底革命的

    敏捷,特别是XP,让人有耳目一新的感觉,觉得以前的所有软件工程理论,设计方法都可以抛弃掉了,推翻一切,从头再来。抱着这种想法实施敏捷,那就 错了,敏捷不是“石头里蹦出个孙大圣”,以前的软件过程中也有敏捷的影子,只是没有像敏捷一样上升到价值观和原则的高度,比如快速原型法。敏捷是在对已有 的软件过程方法的改进,抛弃的是传统软件工程低效的外表,以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础,从敏捷宣言和原则 出发,利用敏捷的方法来改善过程。

    五、敏捷是反文档的

    文档只是为了达成目标的一种手段,如果这种手段是低效的,那就换一种手段。可是完全抛弃了文档,怎样解决沟通的问题?难道你想每次沟通都完全用手比划,用嘴说,跟不同的人重复表述同样的想法,那样更是低效的。
      
    应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识,知识具备两种形态,显性的和隐性的,传统的观念是尽量把隐性知识显性化,即文档化,而忽略了这其中的代价(特别是更新同步文档的代价)。
      
    因此,在实施敏捷的时候,需要在团队内明确哪些知识是必须显性的,这些知识可以通过文档交流。哪些知识是可以隐性的,这些知识则完全可以通过口头的方式进行交流,以达到沟通的最佳效率。
      
    文档不是目的,有效沟通才是目的。

    六、为了敏捷而敏捷

    “嗯,敏捷这么好,我们也敏捷吧”,可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录:
      
    Q:“我们现有的过程很好,不知道怎么用敏捷改进?”
      
    A:“既然很好,那就不要用敏捷”。
      
    做什么事情都要有明确目标的,敏捷虽好,得看你需不需要,能不能解决你现在头疼的问题,如果不是,那就不要给自己找麻烦了。

    七、敏捷是CMM的反义词

    在一些讨论中,很多人把CMM作为敏捷的反义词,我觉得这不是很合适。CMM只是一种衡量软件成熟度的标准,并非过程,和敏捷不是一类概念。如果要给敏捷找一个反义词,我觉得传统的瀑布式开发应该更合适一些。

    并且,我认为,如果CMM还能继续流行下去的话,应该会有公司可以用敏捷改善的过程通过CMM认证。

    八、敏捷是自由的,无约束的

    敏捷强调的是自组织团队,发挥人的能动性,以动力代替压力,让人有绝对自由的错觉。但是应该清楚,凡是都是要讲究一个平衡,人也是两面的,消极的一 面和积极的一面同时并存,绝对的自由会放纵人消极的一面。敏捷并非是绝对自由,无约束的。作为管理者,有一个职责,就是引导团队成员用自己积极的一面去压 制消极的一面,不能放任团队中出现搭便车的现象,否则将打击整个团队的士气。如果实在无效,那就只能将其排除出团队了,这个惩罚够有约束力吧?

    九、重做就是重构

    重做不等于重构,很多场合这两个概念是混淆的。但是在敏捷中,重构的一个特征是必须可控的。当对系统结构进行大的调整时,如果没有测试驱动辅助的话,那么可控性就会很差,这不能叫做重构。

    展开全文
  • 敏捷开发误解

    2010-08-17 15:49:00
    敏捷开发误解  误解一:敏捷对人的要求很高  很多人在尝试实施敏捷时说:敏捷对人的要求太高了,我们没有这样的条件,我们没有这样的人,因此我们没法敏捷。可是,敏捷对人的要求真的那么高么...

    对敏捷开发的误解

        误解一:敏捷对人的要求很高

        很多人在尝试实施敏捷时说:敏捷对人的要求太高了,我们没有这样的条件,我们没有这样的人,因此我们没法敏捷。可是,敏捷对人的要求真的那么高么?软件归根到底还是一种创造性活动,开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用,各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作,从而产生更高的生产力。不管用什么方法,开发人员的水平永远都是一个主要的因素。

        从另一个角度来看:过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员,敏捷方法和传统方法对他的帮助是差不多的,因此看不到显着的效果,甚至有些时候还有反效果;而随着开发人员技术水平的提高,敏捷方法能够解开对人的束缚,鼓励创新,效果也会越来越显着。

        敏捷对人的要求并不高,而且会帮助你培养各种所需的能力,当然前提是你处在真正敏捷的环境中。

        误解二:敏捷没有文档,也不做设计

        这个误解从XP开始就没有停止过,XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准,并不是所有的文档都不写。例如,用户手册是不是“必要且意义重大”?这取决于客户的要求,如果客户不需要,那就不用写,如果客户需要,就一定要写;再如,架构设计文档要不要写?复杂要写,不复杂不用写。通常架构设计只需要比较简单的文档,对于有些项目,一幅简单的UML图就够了。因此,写不写,怎么写,都要根据这个文档到底有多大意义,产出和投入的比例,以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定,尽量避免由某一个人(比如lead)来决定。

        至于设计,XP奉行的是持续设计,并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中,不断的设计、改善(重构),使得设计一直保持灵活可靠。至于编码前的预先设计,KentBeck等人确实实行着不做任何预先设计的开发方式,但是对于我们这些“非大师”级开发人员,必要的预先设计还是需要的,只是不要太多,不要太细,要有将来会彻底颠覆的准备。

        误解三:敏捷好,其他方法不好

        有些人一提到敏捷就大呼好,只要是敏捷的实践就什么都好,而提到CMMI等方法就大呼不好,不管是什么只要沾上边就哪里都不好,似乎敏捷和其他方法是完全对立的。牛顿说过,我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点,也是站在了巨人的肩膀上,敏捷依然保持了很多历史悠久的实践和原则,只是表现方式不同罢了。

        从另一个方面来看,方法本没有好环,好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境,在需求稳定、软件复杂度相对不高的时代,瀑布模型也可以工作的很好,而敏捷恰好适用于变化快风险高的项目-这恰恰是现在很多项目的共性。

        因此选择一个方法或过程,并不是根据它是否敏捷,而应根据它是否适合。而要了解一个东西是否适合,还是要尝试之后才知道,任何没有经过实践检验的东西都不可信。

        误解四:敏捷就是XP(极限编程),就是Scrum

        XP和Scrum只是众多敏捷方法中的两种,还有很多其他的敏捷方法。龙生九子各个不同,敏捷的这些方法看起来差别也是很大的,可是他们之所以被称为敏捷方法,就是因为他们背后的理念和原则都是相同的,这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践,还要理解实践后的原则,不仅要理解怎么做,还要理解为什么这么做,以及什么时候不要这么做。

        即使将XP或Scrum完全的应用的你的项目中,也未见得就能成功,适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点,但绝对不是终点,最适合你的方式还要由你自己在实际工作中探索和寻找。

        误解五:敏捷很好,因此我要制定标准,所有项目都要遵循着个标准

        没有哪两个项目是一样的,客户是不一样的,人员是不一样的,需求是不一样的,甚至没有什么可能是一样的。不一样的环境和问题,用同样的方法解决,是不可能解决的好的。方法是为人服务的,应该为项目团队找到最适合他们的方法,而不是先确定方法,再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

        同时,对于同一个团队,随着项目的进行,对需求理解的深入,对技术理解的深入,一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整,保证项目的质量和效率。敏捷是动态的,而非静止不变的,因为这个世界本身就是变化的,在变化的世界使用不变的方法,是不现实的。银弹从来就没有过,在有限的将来也不会存在。

    展开全文
  • 误解敏捷开发

    2016-11-29 17:22:45
    最近读了Bob大叔的《敏捷软件开发:原则、模式与实践》(下简称《敏捷》),有很多感悟,我觉得很多人对敏捷开发有一定的误解。   很多人推崇敏捷开发是因为他们觉得能提高开发速度。我觉得这是不正确的。敏捷开发...

    最近读了Bob大叔的《敏捷软件开发:原则、模式与实践》(下简称《敏捷》),有很多感悟,我觉得很多人对敏捷开发有一定的误解。

     

    很多人推崇敏捷开发是因为他们觉得能提高开发速度。我觉得这是不正确的。敏捷开发的敏捷是Agile,这个词的意思是灵活的; 灵巧的; 轻快的; 机敏的; 和速度快没有什么关系。正如很多游戏中Agility和Speed完全是两个属性. 然而国内很多人因为种种利益,将敏捷开发鼓吹成了提高开发速度的神器.作为偷懒,规避文档、需求分析的借口.

     

    正如科学上有许多守恒理论,例如能量守恒,元素守恒。软件开发其实也存在着类似的情况。在提高灵活性的情况下,开发速度应该是降低的。所以我觉得,敏捷开发会减缓开发速度。正如《敏捷》中的例子,为了完成功能,通常要编写大量的测试用例,并且敏捷开发也鼓励高频率的进行单元测试(可笑的是,有很多人将不正经八百的测试说成敏捷开发)。而且为了防止软件僵化,开发者通常需要不断思考,对已有代码进行调整。这些思考本身就需要花费大量的时间,而每次的调整又需要更多的测试,甚至需要改写测试用例。

     

    诚然,敏捷开发也有提高开发速度的主张,比如放弃使用大而笨重的工具,减少学习工具的成本。但是我觉得和上述原因相比,总体上还是减慢了速度。

    然而,我并不反对敏捷开发,我相信敏捷开发可以提升软件的灵活性与质量。但是这种提升大概率是提高开发成本的。想一想一个程序员说自己会把任务完成的又快又好的时候,大部分情况他是在吹牛,不是么。除了时间,另一项开发成本是开发人员的水平。敏捷开发其实有较高的门槛,为了保证灵活性,就需要你有较高的抽象能力;经常需要修改代码,就需要你有较高的重构能力。

     

    读了《敏捷》后,我深深被这些编程实践所吸引.但是联想到现实,我觉得在现阶段,大部分公司是没有人力物力去完全践行敏捷开发的.比如编写测试用例,可能要花费数倍于功能的编码时间.可能我悲观了,我觉得大部分人只能是吸收敏捷的思想.只要不太"笨重"已经很不容易了.

     

    别再轻易说自己是敏捷开发了.


    展开全文
  • 谈谈敏捷开发模型

    2019-08-01 23:36:56
    谈谈敏捷开发模型 我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的...

    谈谈敏捷开发模型
    我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司,被迫式的接触了许多“敏捷开发”,随着项目经历越来越多,慢慢的就开始有了更新的认识和想法。

    但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了一些应用,那个阶段我的主要做法是:

    1、项目中开始划分更短的制品交互周期,而不是以前那样等待产品开发完毕后发布各种测试版本。
    2、更充分与市场人员交流,在市场人员进行需求交底时,让更多的甚至全体成员参与会议,了解产品的原始业务及需求。并且在过程中有问题也及时的解答及沟通。
    3、加强沟通力度,开发测试都在一起每天都会开个小会,通报每日的工作成果,将自己的问题说出来。
    4、不同以往的发布频率,测试从项目开始便要切入到产品生产过程,而不是等到最后所有功能都完成后。从而大大减少变动对计划的影响。

    在做这些工作的时候我并不知道敏捷开发这个东西,直到在2010年进入一个公司非常提倡敏捷开发,已经有了迭代周期、backlog、站立会议、周例会等等,在这个团队中对开发过程有各种规章要求,完全是制度化的,这在我加入的初期非常的不适应。事实上回头想想,那种方式已经变的不敏捷了,完全是一种教条式的应用。

    后来自己有机会回到了老东家,开始自己带团队,很巧老东家被收购后开始推广敏捷开发,只不过因为不是总部,所以这次没有范本,完全由我自己来组织及控制。很高兴这个小团队几个月下来,个人觉得比较成功,当然后面也得到了公司的认可。

    下面就敏捷开发分享一些应该着重注意的点,解决这些问题我想对任何开发团队都会有很大的帮助。

    需求在开发中的重要性

    大量的开发过程告诉我,需求在软件开发过程中是极其重要的。传统的开发强调初期的需求调研及需要分析,这个过程对于一些正规的团队会产生大量的文档,而后交由开发展开产品生产。

    然而,事实却不是想象这么简单,无数的例子说明了一点,仅仅在需求调研过程中了解到的需求是无法保证的。数不清的例子告诉我们,需求是会变的,变的原因很多。在极端的情况下,有些客户签字的需求在开发完后,有需要变更也很正常。

    所以需求是影响软件开发的第一重要因素,需求来源于业务,我们开发的产品不就是因为这些业务才去做的吗?如何需求都无法把握好,还谈什么开发出好用的产品?

    然而如何做好需求呢?我想首先要确立需求的地位,然后只有通过不断的沟通、尝试、反馈向真实需求迈进。

    强调人与人的交流

    不管怎么样开发过程中主要还是靠人的,而且软件开发是个复杂的团体工程,一个小些的产品也会涉及到各类人:客户、业务分析、管理人员、程序员、测试员等等。这么多人在一起做事情,有一方没有处理好结果肯定就会有问题。

    有这样一个例子:客户提出了一个会员管理功能需求,需求人员了解后组织了解决方案,于是交付了开发实现。而经过二个月无尽的黑夜之后交付,需求一看有个模块做的有偏差,但是已经来不及修改了。交给客户看后,发现这不是他们要的会员管理功能相差较大,另外在功能开发的这一段时间,客户又有了新想法,要对原先需求做调整。

    这种例子可能大家经常经历吧?

    这种问题在敏捷开发方法中提出了解决方法,就是通过不断的交付可用的制品。看起来很抽象,其实很简单。同样是上面的例子:
    Ø 客户提出会员管理功能需求
    Ø 需求人员在了解需求后与开发负责人商量,确定一个快迭代的开发计划,每二周向客户演示一次,并将这个计划与客户确认
    Ø 确认后需求人员向全体成员讲解需求背景故事
    Ø 开发负责人组织并确定迭代计划内容,明确每个迭代提交的产品目标、开发任务安排、测试跟踪计划
    Ø 每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏
    Ø 后面就是每二周向客户演示一次产品,并获得客户的反馈
    Ø 根据客户的反馈调整下个迭代计划,并继续下一个迭代
    Ø 直到产品交付

    通过上面的步骤,就不至于在开发完成后才知道用户的真实想法,因为很多用户对软件开发是没有概念的,他只知道自己有某种需求,但最开始是没有一个完整的概念的。所以就要通过不断的让用户看到产品的模型,这个过程用户才会逐步的对产品产生概念。同样的在过程中客户的提出需求变更也是在一定的可控制范围之内,这样一来可以大大的减少软件返工的情况,自然就不会拖延计划了。

    而这个过程中,需求已经完成了一个真正的过渡,不再是一头重的情况了。他让需求从客户那快速的反馈到开发团队中。同样的,在开发不断的交付制品时,需求也更加及时的了解到产品的进度,把握开发人员开发的功能是否符合需求。
    当然这并不是一个标准做法,不同的团队可以有不同的处理方式。这里只是想强调需求需要更多的投入到开发过程中去,及时的与客户沟通交流,了解到客户的真实想法。

    强调文档的作用

    我觉得很多对敏捷开发的一个误解就是不需要文档,敏捷开发并未抛弃文档。只是更强调更有效的方式使用文档。在很多传统开发方法中,特别是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理,最痛苦的是不好维护,文档需要随着变化而变化,比如需求调整、技术架构升级、产品维护等等。如果要保证文档的一致性,太难了。特别是对于一些无法进行有效管理的开发团队就更加明显,经常是软件已经几个版本了,文档却是两年前的。

    但敏捷真的不需要文档吗?我想不是的,如何把文档做到好维护我想才是最重要的。文档到底指的指的什么?什么样的算文档?

    提出上面两个问题,我们先想想经常说的文档的作用是什么?不就是一个传播工具吗?可以用作记录、给他人看、用于以后查看。有很多方法可就解决了这个问题,比如wiki系统。维护一个wiki系统,可以随时写,随时维护,可以方便的查找。嗯,多方便。

    另外一个问题就是什么样的工作需要形成文档呢?

    记得在前一家公司,维护一个10多年的老系统修改一个公式计算的BUG,但是怎么也不知道这个复杂的公式是什么意思,问过了公司大部分的人也无人可解。这时想,如果当初有那么一份文档,谢天谢地。

    像这种关键的内容有份文档还是很重要的,否则随着时间推移,谁也不能保证能记得住当时为什么会这么干。

    记得多年前一次记笔记的经历,我看了一篇文章了解了DELPHI实现单实例模式的方法,这种方法很酷。于是整理成了笔记写在了wiki上,第二天就得到了回复,帮助到了别外产品开发组的同事。

    嗯,文档就是这样他具有传播性,你不可能跑去跟所有人说出你的想法,但是文档却更容易达成。他也有传承性,有些文档也许10多年后又起了重要作用。

    团队协作

    1、减少对开发人员的干扰

    曾经接手一个产品的开发,最初遇到一个很头痛的问题,原先写好的迭代计划,而且工作量也较大,大家都在忙着。即便在这样的状态下,客服人员却经常跑来找某个程序员A维护各种系统问题,程序员A在一次维护中竟然导致了系统数据出现大面积错误。程序员A心理上承受着巨大的压力,而每天的这些问题又不得不解决,加之新版本又有很重的开发任务无法完成,最终导致整个开发计划变更。

    我无法再忍受,找到了需求及客服的负责人,沟通后发现这些问题很多都是重复性的,主要是因为原先系统的不足。于是回去组织人员做了几个后台临时功能,并交付给了客服人员,之后就没有再来找过这位程序员A。后续我又找到了客服负责人,要求不能直接找开发人员解决这类问题,并与负责人约定了处理过程。

    这是个例子,在实际情况中还有很多这种事情,甚至有很多开发人员要直接面对客户。我想对于职能型团队来说,开发团队最好是减少这些方面的干忧。当然对于一个人包干的情况就不讨论了。

    大部分的人都不是超人,在一个时间段内处理超出自己负荷的工作是很难做好保质保量的。所以对于开发管理人员一定要考虑到这点,尽量让开发人员有比较好的工作进度环境,通过外界的方式来解决一些开发团队的干扰。

    我接触过的很多程序员都很反感这种干扰,虽然有些人在这种全面的工作强度下成长很快,但是并非所有人都适应,长期下来会有怨恨和不快,工作效率会下降。心情舒畅还是很重要的,记得有一次迭代总结时,有个程序员总结说:发现心情舒畅自己的工作效率很高。呵呵。我想你也有同感吧。

    2、不要忽略测试人员在开发阶段的作用

    曾经多少次在项目发布前加班到深夜2点的情景还历历在目,那种感觉即快乐又痛苦。由于和客户签定的合同的交付日期就要到了,产品却迟迟未集成完成,测试只能干等着上网聊QQ。就在下班前的一刻发布了,测试开始了紧张的测试,在屏幕闪动中,一个个的BUG提交,直到流程都无法都走不下去,测试无奈了。第二天就要发布,实施人员就等着制品第二天出差。只有不断的改,再发布,无尽的循环。直到大家都憔悴的看着老大,终于老大说:还剩下的这几个问题无关紧要,大家回去吧。

    几个月的开发过去后在总结会上,只能抱怨测试资源不足,时间太短,需求更改太多,需求更改后测试不知道。无数的问题一次一次的出现在同样的总结会议上。

    上面的这个例子很多人应该经历过,真的测试只有最后一刻才能体现价值吗?我想不是的。

    在后面的项目中我总结了这个问题的,针对每个开发任务要求进行测试验证。而测试如何验证呢?他需要知道这个开发任务的需求是如何,提前做好测试计划及测试用例,在接到开发制品后测试并提交BUG,这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量,可以大大减少后期集成的错误量。

    另外根据敏捷开发的思想,测试团队在开发过程中也需要加强与开发团队的交流,甚至有必要组成虚拟团队,位置调整到一起,这样可以及时快速的交流,参加开发团队的站立会议同样可以及时了解到开发的实际情况及进度,反过来把握测试计划及测试内容。

    特别是测试从另一个角度来审视需求,这样也可以一定程度上发现或者改善需求上的不足。

    3、发挥团队人员的潜力

    敏捷开发比较提倡开发任务由开发自己评估并认领工作任务,这样可以激发开发的潜在动力。

    之前在做一个新产品时,需要使用java,而我们团队是使用C#的,面临转型问题。而有一位同事很感兴趣,于是我就让他负责前期的框架探索与搭建。结果就是这位小伙工作效率很高,我最初给他的目标全部都完成了。最有意思的是后面产品开始研发时,这位小伙已经成为了团队的大牛,大家有问题都找他解决。也正是因为这个过程,这位小伙被全面激活,也在大家面前展示了能力。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队之前是因为被定为裁员的目标而调剂过来的呢!

    所以充分发挥好每个人员的特点,让人能够在自己感兴趣的工作中,效果会很多。减少指派方式的任务的分配,充分发挥个人的主动性,这个团队精神面貌也会好很多。

    4、管理者不要离团队太远

    作为团队的Leader要参与到团队的工作中去,比如一个开发主管一定要写写代码,参与架构等对项目有关的事情,而不是在那里分分任务。这样团队成员才会觉得这个Leader很亲近感。

    特别是有些开发主管在带队后离团队越来越远,有时对于开发进度不如意时就说:“这么个简单功能怎么会搞了这么久?”,其实每天都在加班的同事心里想着:“有本事你来?”,即使这个小组长有这个能力,但对于团队来说也不是一件好事,因为大家都抱有怨恨之心,还谈什么好好工作呢?这个小组长就是失职的。所以这种情况下应该主动去了解进度滞后的原因,并且自己要加入到解决问题的工作中去,而不是在边上抱怨别人。

    5、小组织不要搞太多的官

    中国几千年的文化,官本位一直影响着我们,大家都想坐在那指挥,自己啥事也不用干,想想都惬意。在我们这个行业是不是发现也很类似?大家都想着干几年当个小组长,然后升个部门经理,当上CTO迎娶白富美。

    团队的管理基本是事与人的管理,非常的伤脑和心。如果一个组织内,特别是小组织内“官”太多,协调就会非常的难,大家就会经常性的扯皮。

    结束

    与敏捷开发结缘也有几年,从开始的抵触到后面的认可经历了许多,这个过程并不是一蹴而就的,需要花时间花精力,特别是要去实践、总结。

    还有我觉得是不能太教条,很多事情都要有怀疑的心,然后去实践总结,找到合适自己团队的方式方法。

    展开全文
  • 敏捷误解

    2011-02-25 15:24:39
    1,敏捷开发意味着可以不需要文档,设计和计划 2,敏捷只是一些优秀实践,或者是优秀实践的结合 3,敏捷只适用于小项目 4,敏捷只会对研发产生改变 5,引入敏捷只需要按照既定的步骤去做就可以了 6,敏捷是CMMI的...
  • 敏捷开发-快速迭代

    2013-05-08 19:57:45
    今天跟大家分享的是“敏捷开发、快速迭代”。我们大都采用的是“瀑布开发模式”,有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理。经过YH系统的开发,也...
  • 敏捷开发,相对传统软件开发...一些公司,一年仅发布仅2~3 个版本,发布流程缓慢,它们仍采用瀑布开发模式,更严重的是对敏捷开发模式存在误解。    由一年发布 2 个版本转到一个月发布 2 个版本,这也不太可能。但
  • 接触“敏捷”这个词有蛮久了,团队近半年也在实行敏捷开发,对于敏捷也有一些感触… 啥是“敏捷开发” 敏捷误解.itlao5.com 对于“敏捷开发”,网上有很多解释,可以查到一大堆相关文章,而且很多文章都有...
  • 力软敏捷开发框架真正源码 从我所看到的情况来看,如今敏捷软件开发被广泛误解了。 许多人认为敏捷,他们只需要像scrum这样的过程即可定义sprint和迭代的框架。 他们会不断冲刺,直到精疲力尽,然后改变直至停滞。 ...
  • 当项目成员越多,我越不推荐敏捷开发,原因在于「当连自己要做什么事、为什么这样做、这样做为了解决什么问题」都搞不清楚前,就跳下去玩敏捷开发,那和比通灵还惨,通灵起码还有个目标物在前面,搞不清楚状况的人...
  • 1,敏捷开发 最大的误解:开发不需要知道所有的需求。从架构设计开发,敏捷开发,开发一定要知道所有需求的情况下去设计整个架构。不然前期的交付的代码不能支持后边的业务,前期交付的代码可拓展性不强,项目会几近...
  • 敏捷开发(Agile Development) 随着“敏捷”一词出现在越来越多的项目中,于是,敏捷开发本身也被赋与了越来越多的意义,而敏捷的真正内涵反而变得越来越模糊。如何迈出敏捷开发第一步?是按照敏捷宝典、操作指南...
  • 以前,当讲到我们团队采用敏捷开发进行APP迭代的时候,我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后,我觉得应该把这个引号给去掉。 本文...
  • 我曾经参与一个软件产品开发,高层管理者(兼系统分析员)每天都有新的Feature源源不断地交给开发...高层管理者说这是 敏捷开发。 因为产品每天都在“敏捷”地变化和前进。 真的是这样吗?拥抱变化是敏捷开发的特征,
  • 简单的说下敏捷开发的一些知识: 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成...
1 2 3 4 5 ... 20
收藏数 5,548
精华内容 2,219
关键字:

敏捷开发误解