`
leili
  • 浏览: 174732 次
社区版块
存档分类
最新评论

敏捷的坏态度

阅读更多
然所有软件开发的专业人士都会对这篇文章感兴趣,但是经理、CIO以及软件架构师会对它最感兴趣。这个话题可能会引起许多争议,但我写这篇文章是为了让你了解在敏捷运动中看起来正在日益增长的问题。

你为什么在这?敏捷不需要经理。

以前听过这种说法吗? 想象一下,如果你听到开发人员认为你这个职位根本就不应该存在,你会感到多么震惊,就好像是你特意为自己搞出经理这么个职位似的。这个话最常应用在项目经理第一次与将要和他一起工作的开发团队碰面的时候。的确,最初的敏捷宣言绝对没有提到项目管理,并且后来的敏捷理论家更进一步,建议调整项目经理的角色变成更多是教练或者支持的角色。

然而,这个观点忽略了现实情况。

的确,小的、非集成的、从属开发项目中可能不需要任何类型的管理,只要你拥有有资质、有经验并且能干的团队就好。然而,越是大规模的项目,越是高度集成的从属项目,越是开发集中度低的项目越是需要一位项目经理去协调、沟通和把握这个整体目标。一个开发部分只占总预算百分之十的项目,可以允许由一位scrum专家来领导开发,但也要向项目经理汇报。

再者,开发团队几乎根本不知道或者根本不擅于管理预算。软件开发需要的时间量让开发团队没有时间顾及其它事情。这使得一些开发人员产生了小盲点,似乎他们开始认为:他们所做的一切就是这个项目,其他任何人都是多余的。

这里的坏态度是指认识不到其他角色和职业的价值,并且严格遵守哲学解释,而意识不到现实需要灵活变通。如果走向极端,在它的陈述中通过把这种观点延伸到所有条件下的一切管理的话,这种态度就几乎能被理解为就是工会主义或者新共产主义。显然,接受这样包含一切的、大规模的企业文化削减以及组织结构扁平化的个人是极端分子。虽然他是对周围环境发出的观点,但是如果他恰恰是这样一个人(一位领导)他的观点能够起作用并且会使开发团队和管理部门之间的关系变得更糟那么就会使项目完成的目标变成管理部门与工人之间的阶级斗争。

是团队运作这个项目,而非经理......我们将决定该完成什么。

这种观点通常是不再需要管理角色这种观念的产物。这种观点是违反事实的:许多决定需要公司中的众多元素一起合作,而不仅仅是开发团队......这也包括软件设计和架构。

在另外的例子中,有这种观念的开发人员恰恰没有意识到项目有其它方面。甚至更糟糕的是,在某些可察觉的故障发生之前,被一次不愉快经历伤得很重的开发者会觉得需要控制这个项目。

无论如何,敏捷变成了这样一种态度的前文和基础,这种态度提出开发团队之上的大多数(即使不是全部的)管理结构都没有用,应该立即剔除掉。依据我的经验,如果让这种态度生根的话,那么通常会导致无休止的重组架构会议、应付预算超支、没有真正结束日期以及因自己使命的幻想破灭而精神分裂的团队。

在敏捷中不存在到期日或者时间表。

我们这些深入了解资本预算和公司财务的人会知道这是多么愚蠢。然而,如果你读过Ken Schwaber写的关于Scrum的书,就会看到那里面谈到为了燃尽图而抛弃甘特图。事实上,燃尽图是一个干净利落的、经过深思熟虑的创新,但有些人却认为这就意味着交付没有时间表......即钱永远花不完。

这对我来说是一次痛苦的经历。 我见过一位能力很强且富有领袖魅力的领导人(我们都向他汇报)带领的团队,为了给客户产出项目管理工作产品,而放弃了基本的时间目标。 任何时间界限都没有了,这个团队到处倾斜。 职业精神极大衰减,或者可以说是荡然无存了。 那些想让产品获得成功的人丧失了动力和干劲。 客户变得不知所措,为什么如此多的重点强加到各种技术架构之上,而特性和产品变更需求却不知所踪? 燃尽图让他们更迷惑。 他们只想知道的是:这个产品什么时候才能完成? 而这个团队却只回复说:我们没有时间表。 我们会一直开发,直到我们做完为止。

当有人尝试着设定现实目标时,他们会因反对敏捷而立即被打倒。 当这个团队被告知他们的项目无可救药地超过预算时,他们的双眼充满了困惑和不解。 他们正在做的事情、时间以及最终的花费之间的联系已经消失在那些他们用白板记录的抽象设计样式中了。

现实是......不论是明确的或者模糊的,总是有一个到期日和交付时间表。如果这个开发项目的观念是它永远都不会完成,那么就没有人会把钱投给它。更现实的是,我发现甘特图在协调深度集成或者非敏捷团队与敏捷团队之间非开发方面还是非常有用的。

这种没有时间表态度的产生,主要是因为敏捷技术提出了这样的观念:项目应该继续添加新特性直至把钱花光。这是不切实际的,并且忽略了当开发团队连预算内最低限度的功能都没有完成时会发生什么,此时描述这样的要求毫无益处。这种态度不好的方面是用(敏捷)这种新技术来追踪团队进程、问责并且把这种新技术扭曲成不对交付负有责任的原因。

敏捷编码是自动文档化的。它不需要需求、架构图或者技术规范。

如果你是一位软件架构师或者技术经理,这种态度通常会让你眉头紧锁。这种轻微的、隐藏的攻击是想质疑你的角色、经验以及有人来协调那带来百分之七十八公司收益的两千八百万行软件程序的技术设计的必要性。

当然,提出这种想法的通常是出于无知。可能开发人员构建的两千行web应用近期需要非常少的源码外的再加工,但那是因为规模的关系。你知道,你的管理部门也知道,但是这种不好的敏捷态度取代了你的角色,却不是为了像Scrum那样领先于开发技术。大多数的软件系统需要少数人来监督方向、协调技术愿景,而需要成百上千人来创造。

依据我自己的经验,说来颇具讽刺意味,这种态度来自于那些想成为架构人员的开发者。 通过评论、与技术领导争辩以及介绍他的敏捷技术知识,他感觉领导应该更加尊重他,应该给他那个他梦寐以求的职位。 然而,领导却把他当作令人讨厌的麻烦制造者。 此外,因为他缺少介绍敏捷概念的经验,从而让那些资深的技术领导一想起任何敏捷的事情就会不舒服。

敏捷快速地拥抱变化;所有变化。

我对这一态度的经历来自于一位经理而非一位开发者。原来他把快速拥抱变化解读成了各种各样的变化......而不仅仅是原来敏捷缔造者设想的业务需求。所以,基础的、架构的变更成为了家常便饭,不同开源技术间的不断改换被视作好事,即便这意味着把这个团队带离他们(熟悉)的技术,以及月复一月地推迟项目交付。组织结构方面的实验以及把人们快速放入某个角色并又被快速地从这个角色中拿出也变成了快速拥抱变化。最终的结果就是混乱。

显然,接受来自于客户的变更很重要,但是如果对那些变更没有系统的管理,那么你就是自找麻烦。你需要保存所有需求、变更的轨迹,以及他们对项目交付的影响,以便把这些信息传递给客户。这对于做出有效的项目决策是必须的。如果你不那样做,客户会不切实际地认为,他们要求的东西都会包含到产品中我们都知道这会导致什么样的情况。

所以,这里的坏态度是不加管理的接受变更。对所有事情都绝对自由只能导致虚幻的希望和无法达到的期望。变更是好的,但极端的变更只能是混乱。

敏捷使用的是通才;我们测我们自己的软件。这里不需要测试组。

又是这样,这种观点在哲学解释上是准确的,但我在这个问题上的经验是,特别是大型的软件开发项目,你需要第二双眼睛来盯着开发人员干了什么,干得怎么样。手艺人的自尊很重要,并且应该培养,但有时自尊会变成盲目的接受和防御。这第二双眼睛会让坚强的、很诚实的人认识到他们自己的局限并找出方法来减轻这些问题。

使用通才着重于确认你在一个由具备多种技能的个人组成的敏捷团体中。如果更深入地思考,你会发现这认可了软件开发更多的是手艺而非流水线作业。然而,作为软件开发的领导者,我们不能假设人力资源是完美的,并且忽略事实。我们最好能够看到风险并为此作好计划,历史也证明开发者不会找到他们自己所有的错误。

以我个人的经验,有这种观念的人不喜欢任何人测试他的代码,对建设性的批评也很敏感。 在特殊的情况下我们发现,这里潜在的原因是开发者真的不擅于编码。 我们给了他培训和指导,但经过几个月的努力后,却发现很显然他是入错了行。

所以,使用通才是好的,但如果因为喜欢哲学上的纯粹,而忽略了几十年来的实际情况的话,这种态度就会变得毫无新意。

总结

总之,这些问题在前敏捷世界中也能找到。但是根据我的经验,这些坏态度在这种新的技术中找到了避难所和辩护。而孤立地看,这种新技术可能从来没有打算在这样一个临时的演讲台上演讲。作为软件开发领导,我们在人们掌握敏捷的方法论之前演说这些观点是危险的,并且可能把一场好好的运动给搞糟。敏捷有一个重要的信息,那就是简单化,在产品开发的过程中让客户参与,取得所有权,并且保持联系。如果丢失了这个信息,那将是非常令人失望的事情。因此,你们怎么想的?这些态度在你们那存在吗?你们怎么评论这些态度?希望你们能告诉我。

关于作者

Christopher R. Goldsbury是一位软件开发专家,在他的职业生涯中,担任过的角色有:开发者、架构师、scrum专家、开发经理、项目经理以及质量保证经理。Chris把他的经历和想法都写在了他的博客上。

英文原文:Bad Attitudes of Agile

3
5
分享到:
评论
1 楼 zui4yi1 2012-08-15  
agile,新进的公司就是采用敏捷开发的。
了解AGILE,其实我更想知道怎样的人最适合这种开发,然后人就可以向那个方面发展。
像我这种偏懒的人,有种每天都被督促的感觉。

相关推荐

    敏捷软件测试:测试人员与敏捷团队的实践指南

    敏捷软件测试:测试人员与敏捷团队的实践指南 crispin和Gregorv定义了敏捷测试的概念,并通过来自现实敏捷团队的示例阐述测试人员的职责。她们讲述如何利用敏捷测试象限来识别需要哪些测试,谁来做,以及哪些工具有...

    敏捷开发 敏捷开发 敏捷开发 敏捷开发

    敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发敏捷开发

    敏捷是一种态度:敏捷建模与敏捷需求

    敏捷需求 敏捷建模 1、五级业务建模 2、L3流程建模 3、表单建模 4、规则建模 5、数据建模

    敏捷开发知识体系

    《敏捷开发知识体系》面向敏捷实践者学习敏捷知识和敏捷软件开发企业进行敏捷转型的需要,旨在帮助个人更快地掌握敏捷开发知识,帮助企业更好地实施敏捷转型。主要内容包括:敏捷开发的哲学理念、价值观、敏捷开发...

    敏捷开发的艺术

    本书为那些正在考虑应用敏捷开发来构建有价值软件的人们提供了实用的指导。现在已经有大量的书籍描述敏捷开发是什么或者为什么它能帮助软件项目成功,但很少有哪一本书能把针对开发者、管理者、测试者和客户的信息...

    敏捷方法 敏捷方法 敏捷方法

    系统的开发基于Ruby On Rails,在项目的开发过程中应用了敏捷开发方法

    敏捷软件开发敏捷软件开发

    敏捷软件开发敏捷软件开发敏捷软件开发敏捷软件开发敏捷软件开发敏捷软件开发敏捷软件开发敏捷软件开发

    敏捷与架构敏捷与架构

    敏捷与架构. doc敏捷与架构. doc敏捷与架构. doc敏捷与架构.doc

    软件项目管理论文:敏捷在软件开发中的应用

    本文从敏捷方法的定义,提出背景,实施方法等方面对敏捷方法进行描述,并与传统软件工程方法相对比,分析敏捷开发的优劣。通过实际软件开发的案例分析软件生产的价值观,得出敏捷方法在软件开发中的价值。关键词:...

    华为敏捷开发介绍

    为落实敏捷软件开发在我司的顺利推行,使广大软件开发管理者和开发人员深刻领会敏捷核心理念,熟练掌握敏捷实践方法,从而达到增强应对需求变化的能力、提高产品质量、提升开发效率和缩短交付周期等方面的目标。...

    敏捷软件测试:测试人员与敏捷团队的实践指南

    敏捷软件测试

    敏捷项目管理,敏捷项目管理

    敏捷项目管理敏捷项目管理敏捷项目管理敏捷项目管理敏捷项目管理敏捷项目管理敏捷项目管理

    我对敏捷开发的态度1

    2. 如上,如果没有员工提出离职,说明敏捷开发没有起到加快节奏、控制进度的效果 3. 能不敏捷,尽量别敏捷 4. 非要敏捷,先期的准备工作是跟老板暗示做完了要加

    敏捷开发中的敏捷测试《敏捷测试全攻略》

    关于敏捷测试的关于敏捷测试的关于敏捷测试的

    Scrum敏捷软件开发过程.pdf

    Scrum敏捷软件开发过程.pdfScrum敏捷软件开发过程.pdfScrum敏捷软件开发过程.pdfScrum敏捷软件开发过程.pdfScrum敏捷软件开发过程.pdfScrum敏捷软件开发过程.pdfScrum敏捷软件开发过程.pdfScrum敏捷软件开发过程....

    Scrum敏捷软件开发

    《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作,也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间,把自己近...

    敏捷论坛-姚元庆-这里敏捷“静悄悄”

    敏捷开发--记“春天工程”敏捷实践及大型金融企业敏捷推广策略分享

    敏捷成熟度评估-Agile Maturity Model(AMM)模型分享

    •AMM(敏捷成熟度模型) 全称Agile Maturity Model,是一套用来评估软件开发团队或者整个开发组织的当前敏捷状态和将来的目标状态的框架,评估的结果用来帮助团队识别改善点。 •可以评估一个IT组织的敏捷程度,其...

    敏捷开发中QA的职责之敏捷中的QA

    敏捷开发中QA的职责之敏捷中的QA!QA,通常指的是质量保证(QualityAssurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(QualityAnalyst),主要基于以下几个方面的原因:质量保证更偏向于工业说法,称参与软件...

Global site tag (gtag.js) - Google Analytics