然所有软件开发的专业人士都会对这篇文章感兴趣,但是经理、CIO以及软件架构师会对它最感兴趣。这个话题可能会引起许多争议,但我写这篇文章是为了让你了解在敏捷运动中看起来正在日益增长的问题。
你为什么在这?敏捷不需要经理。
以前听过这种说法吗? 想象一下,如果你听到开发人员认为你这个职位根本就不应该存在,你会感到多么震惊,就好像是你特意为自己搞出经理这么个职位似的。这个话最常应用在项目经理第一次与将要和他一起工作的开发团队碰面的时候。的确,最初的敏捷宣言绝对没有提到项目管理,并且后来的敏捷理论家更进一步,建议调整项目经理的角色变成更多是教练或者支持的角色。
然而,这个观点忽略了现实情况。
的确,小的、非集成的、从属开发项目中可能不需要任何类型的管理,只要你拥有有资质、有经验并且能干的团队就好。然而,越是大规模的项目,越是高度集成的从属项目,越是开发集中度低的项目越是需要一位项目经理去协调、沟通和把握这个整体目标。一个开发部分只占总预算百分之十的项目,可以允许由一位scrum专家来领导开发,但也要向项目经理汇报。
再者,开发团队几乎根本不知道或者根本不擅于管理预算。软件开发需要的时间量让开发团队没有时间顾及其它事情。这使得一些开发人员产生了小盲点,似乎他们开始认为:他们所做的一切就是这个项目,其他任何人都是多余的。
这里的坏态度是指认识不到其他角色和职业的价值,并且严格遵守哲学解释,而意识不到现实需要灵活变通。如果走向极端,在它的陈述中通过把这种观点延伸到所有条件下的一切管理的话,这种态度就几乎能被理解为就是工会主义或者新共产主义。显然,接受这样包含一切的、大规模的企业文化削减以及组织结构扁平化的个人是极端分子。虽然他是对周围环境发出的观点,但是如果他恰恰是这样一个人(一位领导)他的观点能够起作用并且会使开发团队和管理部门之间的关系变得更糟那么就会使项目完成的目标变成管理部门与工人之间的阶级斗争。
是团队运作这个项目,而非经理......我们将决定该完成什么。
这种观点通常是不再需要管理角色这种观念的产物。这种观点是违反事实的:许多决定需要公司中的众多元素一起合作,而不仅仅是开发团队......这也包括软件设计和架构。
在另外的例子中,有这种观念的开发人员恰恰没有意识到项目有其它方面。甚至更糟糕的是,在某些可察觉的故障发生之前,被一次不愉快经历伤得很重的开发者会觉得需要控制这个项目。
无论如何,敏捷变成了这样一种态度的前文和基础,这种态度提出开发团队之上的大多数(即使不是全部的)管理结构都没有用,应该立即剔除掉。依据我的经验,如果让这种态度生根的话,那么通常会导致无休止的重组架构会议、应付预算超支、没有真正结束日期以及因自己使命的幻想破灭而精神分裂的团队。
在敏捷中不存在到期日或者时间表。
我们这些深入了解资本预算和公司财务的人会知道这是多么愚蠢。然而,如果你读过Ken Schwaber写的关于Scrum的书,就会看到那里面谈到为了燃尽图而抛弃甘特图。事实上,燃尽图是一个干净利落的、经过深思熟虑的创新,但有些人却认为这就意味着交付没有时间表......即钱永远花不完。
这对我来说是一次痛苦的经历。 我见过一位能力很强且富有领袖魅力的领导人(我们都向他汇报)带领的团队,为了给客户产出项目管理工作产品,而放弃了基本的时间目标。 任何时间界限都没有了,这个团队到处倾斜。 职业精神极大衰减,或者可以说是荡然无存了。 那些想让产品获得成功的人丧失了动力和干劲。 客户变得不知所措,为什么如此多的重点强加到各种技术架构之上,而特性和产品变更需求却不知所踪? 燃尽图让他们更迷惑。 他们只想知道的是:这个产品什么时候才能完成? 而这个团队却只回复说:我们没有时间表。 我们会一直开发,直到我们做完为止。
当有人尝试着设定现实目标时,他们会因反对敏捷而立即被打倒。 当这个团队被告知他们的项目无可救药地超过预算时,他们的双眼充满了困惑和不解。 他们正在做的事情、时间以及最终的花费之间的联系已经消失在那些他们用白板记录的抽象设计样式中了。
现实是......不论是明确的或者模糊的,总是有一个到期日和交付时间表。如果这个开发项目的观念是它永远都不会完成,那么就没有人会把钱投给它。更现实的是,我发现甘特图在协调深度集成或者非敏捷团队与敏捷团队之间非开发方面还是非常有用的。
这种没有时间表态度的产生,主要是因为敏捷技术提出了这样的观念:项目应该继续添加新特性直至把钱花光。这是不切实际的,并且忽略了当开发团队连预算内最低限度的功能都没有完成时会发生什么,此时描述这样的要求毫无益处。这种态度不好的方面是用(敏捷)这种新技术来追踪团队进程、问责并且把这种新技术扭曲成不对交付负有责任的原因。
敏捷编码是自动文档化的。它不需要需求、架构图或者技术规范。
如果你是一位软件架构师或者技术经理,这种态度通常会让你眉头紧锁。这种轻微的、隐藏的攻击是想质疑你的角色、经验以及有人来协调那带来百分之七十八公司收益的两千八百万行软件程序的技术设计的必要性。
当然,提出这种想法的通常是出于无知。可能开发人员构建的两千行web应用近期需要非常少的源码外的再加工,但那是因为规模的关系。你知道,你的管理部门也知道,但是这种不好的敏捷态度取代了你的角色,却不是为了像Scrum那样领先于开发技术。大多数的软件系统需要少数人来监督方向、协调技术愿景,而需要成百上千人来创造。
依据我自己的经验,说来颇具讽刺意味,这种态度来自于那些想成为架构人员的开发者。 通过评论、与技术领导争辩以及介绍他的敏捷技术知识,他感觉领导应该更加尊重他,应该给他那个他梦寐以求的职位。 然而,领导却把他当作令人讨厌的麻烦制造者。 此外,因为他缺少介绍敏捷概念的经验,从而让那些资深的技术领导一想起任何敏捷的事情就会不舒服。
敏捷快速地拥抱变化;所有变化。
我对这一态度的经历来自于一位经理而非一位开发者。原来他把快速拥抱变化解读成了各种各样的变化......而不仅仅是原来敏捷缔造者设想的业务需求。所以,基础的、架构的变更成为了家常便饭,不同开源技术间的不断改换被视作好事,即便这意味着把这个团队带离他们(熟悉)的技术,以及月复一月地推迟项目交付。组织结构方面的实验以及把人们快速放入某个角色并又被快速地从这个角色中拿出也变成了快速拥抱变化。最终的结果就是混乱。
显然,接受来自于客户的变更很重要,但是如果对那些变更没有系统的管理,那么你就是自找麻烦。你需要保存所有需求、变更的轨迹,以及他们对项目交付的影响,以便把这些信息传递给客户。这对于做出有效的项目决策是必须的。如果你不那样做,客户会不切实际地认为,他们要求的东西都会包含到产品中我们都知道这会导致什么样的情况。
所以,这里的坏态度是不加管理的接受变更。对所有事情都绝对自由只能导致虚幻的希望和无法达到的期望。变更是好的,但极端的变更只能是混乱。
敏捷使用的是通才;我们测我们自己的软件。这里不需要测试组。
又是这样,这种观点在哲学解释上是准确的,但我在这个问题上的经验是,特别是大型的软件开发项目,你需要第二双眼睛来盯着开发人员干了什么,干得怎么样。手艺人的自尊很重要,并且应该培养,但有时自尊会变成盲目的接受和防御。这第二双眼睛会让坚强的、很诚实的人认识到他们自己的局限并找出方法来减轻这些问题。
使用通才着重于确认你在一个由具备多种技能的个人组成的敏捷团体中。如果更深入地思考,你会发现这认可了软件开发更多的是手艺而非流水线作业。然而,作为软件开发的领导者,我们不能假设人力资源是完美的,并且忽略事实。我们最好能够看到风险并为此作好计划,历史也证明开发者不会找到他们自己所有的错误。
以我个人的经验,有这种观念的人不喜欢任何人测试他的代码,对建设性的批评也很敏感。 在特殊的情况下我们发现,这里潜在的原因是开发者真的不擅于编码。 我们给了他培训和指导,但经过几个月的努力后,却发现很显然他是入错了行。
所以,使用通才是好的,但如果因为喜欢哲学上的纯粹,而忽略了几十年来的实际情况的话,这种态度就会变得毫无新意。
总结
总之,这些问题在前敏捷世界中也能找到。但是根据我的经验,这些坏态度在这种新的技术中找到了避难所和辩护。而孤立地看,这种新技术可能从来没有打算在这样一个临时的演讲台上演讲。作为软件开发领导,我们在人们掌握敏捷的方法论之前演说这些观点是危险的,并且可能把一场好好的运动给搞糟。敏捷有一个重要的信息,那就是简单化,在产品开发的过程中让客户参与,取得所有权,并且保持联系。如果丢失了这个信息,那将是非常令人失望的事情。因此,你们怎么想的?这些态度在你们那存在吗?你们怎么评论这些态度?希望你们能告诉我。
关于作者
Christopher R. Goldsbury是一位软件开发专家,在他的职业生涯中,担任过的角色有:开发者、架构师、scrum专家、开发经理、项目经理以及质量保证经理。Chris把他的经历和想法都写在了他的博客上。
英文原文:Bad Attitudes of Agile
分享到:
相关推荐
人是生产过程中的关键因素,他们的技能、知识和态度直接影响生产效率和质量;材料是生产的物质基础,合理的物料管理和控制能确保生产的连续性;方法是指生产工艺和流程,优化方法可以提高生产效率;设备则是生产活动...
**解决方法**:采用敏捷开发方法,如Scrum或Kanban,以迭代方式推进项目,每次迭代后重新评估剩余工作量。预留缓冲时间,为未知挑战留出余地。保持灵活,适应变化,而不是固守最初的时间表。 #### 四、自大与争执:...
- **定义**:敏捷不仅仅是一种项目管理技巧或方法论,如Scrum,它更是一种积极应对变化的态度。 - **实践**:允许在发布的最后十分钟内进行更改,给予产品决策最大的自由度。然而,面对海量用户的复杂系统,实现敏捷...
10. 成绩稳定性:指出学习成绩波动的问题,提醒学生保持稳定的学习状态,避免时好时坏。 11. 课堂参与:鼓励学生积极举手发言,培养课堂参与意识,提升思维敏捷性和表达能力。 12. 态度决定一切:强调学习态度的...
2. 个性培养:对于每个学生,班主任能够根据其特点给予个性化评价,如活泼可爱、待人诚恳、思维敏捷等,鼓励学生发扬优点,改进不足。 3. 行为习惯:评价中多次提到学生上课注意力集中、做小动作、写字质量等问题,...
1. 学习态度:评价中的班主任强调了学生们的学习态度,如勤奋好学、思维敏捷,以及对学习的主动性。这表明在教育中,积极的学习态度是至关重要的,它能激发学生的创新思维,提升学习效果。 2. 自控能力:对学生自我...
14. **好**与**坏**:道德或品质的评价,好的是积极的,坏的是消极的。 15. **快**与**慢**:描述速度,快是迅速,慢是迟缓。 16. **近**与**远**:表示距离,近是靠近,远是远离。 这些词汇的近义词和反义词可以...
9. 性格的态度特征是性格结构中具有核心意义的成分,它反映个体对待事物的基本态度和行为方式。 10. 助人为乐、廉洁奉公反映的是性格的社会性特征,体现个体在社会交往中的道德品质。 11. 多血质的气质类型表现为...
他们需要反应敏捷,及时回应客户,同时遵守劳动纪律,不得擅自离岗。交接班时,要做好充分准备,快速完成交接,保持对业务变化和优惠政策的敏感性,并详实地记录交接内容。 第四章现场管理规范,关注工作环境的秩序...
4. **自我提升**:提醒学生改正缺点,如“经常讲‘悄悄话’、开小差”,并鼓励他们“丢掉这个坏朋友,再交上个好朋友”。 5. **全面能力**:关注学生的全面发展,包括艺术才能(“能歌善舞”)、兴趣广泛、知识全面...
通过对魏猷君分享内容的总结,我们可以看出成为一名优秀的程序员不仅仅需要扎实的技术基础,更重要的是具备良好的职业态度和个人品质。希望每一位程序员都能够不断提升自己,成为真正意义上的Good Coder。
而"小宝"的活泼、乐观、敏捷则更符合多血质。 9. 性格特征的核心地位:性格的看法特征往往处于核心,决定了个体对事物的基本态度和评价。 10. 意志特征:意志特征是指个体在面对困难时的决策能力和坚持度,如自觉...
14. 性格的核心地位是性格的看法特征,它反映了个体对世界的看法和态度。 15. “自信、顽强、勤奋”描述的是人的性格特征。 16. 气质类型在社会评价上没有好坏之分。 17. 社会自我基本成熟的时期在少年期。 18. ...
行走时要保持微笑,动作敏捷,手握托盘时要注意安全,避免碰撞客人或损坏餐具。 综上所述,酒店服务人员的仪容仪表是他们工作中的重要组成部分,直接影响到服务质量与酒店的整体形象。通过规范化的仪容仪表,服务...
在快速变化的商业环境中,公司需要更敏捷地预见变化,更快地采取行动,更具进取精神。目前,可能过于关注内部事务,对风险持保守态度。为了加速增长,必须打造一个一心追求胜利的组织。因此,风险管理成为关键,确保...
31. 性格无优劣之分:每种性格都有其独特价值,不宜简单地评价为好或坏。 32. 性格的意志特征:自觉调整自己,克服困难体现了性格的意志特征。 33. 巴甫洛夫高级神经活动类型的对应:强、平衡、不敏捷(宁静型)...
17. 注意力具有指向性和集中性,记忆力的好坏可以从敏捷性、持久性、准确性、准备性等方面衡量。 18. 思维过程包括分析与综合、比较与分类、具体化与系统化、抽象与概括。 19. 气质无好坏之分,主要由遗传决定,是...
4. “轻锐”是指轻装的精锐部队,即战斗力强、行动敏捷的士兵。 题目中涉及的文言词汇解释: - A项的“初一”解释为“刚刚开始”是正确的。 - B项的“发火”意为点燃船只,正确。 - C项的“大坏”表示彻底溃败,...
4. 气质的神经过程:多血质的人神经过程强、平衡且敏捷,表现出活泼好动的特征;而抑郁质的人则情感体验内向、深入长久,对细微事物敏感。 5. 核心人格成分:在人格特征中,性格通常被认为具有核心作用,它影响着...
9. 学习态度:“敏而好学,不耻下问”的含义是C,“思维敏捷的人不以问别人而感到可耻”,鼓励积极求知。 10. 安全隐患:家庭火灾隐患包括C,“插座老化了”,提醒注意生活中的安全细节。 【判断题知识点】 1. ...