前车之鉴|盘点敏捷项目失败6种最常见原因

    2017-09-30 11:25  浏览次数:247

敏捷开发能加速初始业务价值的交付,好处是不言而喻的。但是不少开发团都都在敏捷了一段时间后发现自己陷入了“假敏捷”的怪圈,又或是敏捷失败。下文为大家盘点了6种最常见原因,希望能对大家有所启发。

一、不可持续的系统架构

《敏捷宣言》指出,“良好的设计和卓越的技术能提高敏捷”,并且人们一直在推动“适应性架构”。保持敏捷的诀窍在于提前做好足够的设计。但问题在于如何知道什么样的设计能被称为足够的设计。如果设计过程变更太少,且没有正式的设计过程,代码堆叠在旧代码之上,最终得到的会是一个不够灵活的设计。敏捷架构与传统的瀑布架构不同,瀑布架构中的系统架构在前期即被准确定义,开发是一次性活动,具有明确开始和结束日期。敏捷的软件架构则是一个持续的过程,它使开发人员能够持续地在必要时对架构进行更改。设计在sprint计划会议期间可能是连贯的,但它可能缺乏可以赋予其长期可持续性的正式架构模型。

二、难以扩大规模

敏捷是一种传统意义上受到中小型企业欢迎的方法,但最近在大型企业中它也已变得更加主流。小项目对于敏捷开发较为理想,因为大项目需要更多的协调。将敏捷应用于大项目遇到的一个特殊问题就是如何处理团队间的协调。大规模敏捷涉及与其它组织单位(如人力资源、营销、销售以及产品管理)间的沟通。因为敏捷方法很大程度上依赖于紧密的工作关系和大量的用户反馈,随着项目的增长,通信流也会呈指数倍增。另外,随着企业拓展到新的地域,或与其他组织合并,项目也会因此分散在不同地点的多个团队中。如果在不同的地点和协作工具之间没有一致的方法,人员不能看到分布在多个开发和测试团队中的测试周期的实时状态,那么可能会导致瓶颈,进而导致项目延迟和成本超支。

三、项目类型不对

传统方法(如瀑布)对于范围两端的项目最有效,即:1)已经建立了明确和固定要求的项目,或者2)之前没有可以提供有效反馈的用户群的新技术或方法。尽管事实上,长期的项目越来越不普遍。当今的业务环境具有VUCA性(不稳定性、不确定性、复杂性和模糊性),这意味着一个为期12个月的项目中60%以上的需求将会发生变化,所以几乎不存在一个“固定”的项目终点。当今的业务系统中已经没有“明确和固定的需求”这一说了。技术变化非常迅速,客户需求非常紧急,法律变化非常频繁。“只有看到了,我才知道要什么”(即IKIWISI  - 摘自1986年《快速应用开发》)才是用户需求的真正写照。项目经理必须评估项目,来判断少量开发人员独立工作的做法是否是介于1和2之间的项目是更合适和更具性价比的解决方案。与矩阵管理结构中的多个不同用户组进行对接的项目或许不适用敏捷方法。例如,使用金字塔结构时,通常一起工作的团队数量大于项目实际需要的数量。当这些团队成员被部分分配给项目时,问题变得更糟,因为投入度较低。

四、现有工具的局限性

敏捷方法常受到现有工具的限制。当今的企业应用程序生命周期管理(ALM)市场由整体式和企业内置的解决方案主导,由于这些方案是根据“瀑布”交付方式设计的,它们缺乏敏捷交付的关键要素。虽然软件开发行业已经在采用最佳的敏捷工具(如Jenkins、VersionOne和RallyDev),但这些工具并非针对企业IT组织的需求而设计。相反,它们设计的目的是被专业软件工程师使用,而不是业务用户。这些用户不愿意、不能、亦不应该被要求参加培训课程,以学习如何进行功能测试并提供反馈。另外,由于这些系统包含太多功能,而且这些功能拥有过高且不必要的硬件和计算要求,所以购买和维护它们也可能很昂贵。

五、因为协作问题陷入僵局

为了从敏捷方法中获得最大收益,软件开发团队成员需要每天看到、感觉到和听到用户身上发生的情况。但现在大多数项目的现实是,不同的团队成员距离较远,或者无法面对面沟通。依靠手动的电子邮件通信可能会减慢通信速度,并且容易出错。根据我自己在企业组织方面的经验,超过50%的组织正在使用Microsoft Office产品,如Word或Excel,有的组织甚至是通过纸和笔来管理应用交付的某一方面,比如测试。当来自不同地点、不同地域的团队开始使用通信工具来获取所有不同类型的信息并加快信息流动时,他们常常会得到过程的优化和最终结果的改进,从而使团队更强大、更高效。当一个测试组落后,或涉及用户验收测试的业务用户因休假而忘了运行程序时,工具可有效防止流程卡住。项目内部人员和与客户之间的沟通和协调常常由于物流、位置和时间安排变得很困难,所以建立方便敏捷团队协作的端到端通信框架对于帮助人们更有效地合作至关重要。

六、文化鸿沟

一些习惯了独立工作的开发人员可能会发现敏捷开发所需的所有协作均会减慢自己的速度。对许多人来说,如果习惯了大量的自由,他们就会反对改变工作方式以适应高度协作的方法。那些创造力强又聪明的人通常只希望你给他们想要的工具,然后让他们干自己最擅长的事。尽管最终,敏捷项目团队的每个人都需要变得更加灵活。据Gartner的《2016年度应用测试服务魔力象限》估计,到2020年,60%的测试人员将需要测试、应用开发、业务流程或行业技能的组合而不是某个单一的技能。考虑到当今项目发生变化的程度,“孤狼”开发人员单独坐在某处,不与别人交流的做法已经毫无意义,因为协作已然成为成功的一个关键因素。很多证据表明,更多样化的团队可以取得更好的成果,所以个人开发者是否应该“顺应潮流”并学习一些社交技能呢?


当敏捷开发有效的时候,组织能够发布高质量、迅速变更的软件,推动企业向前发展。但它并非任何时候都有效。要想成功,需要协作、透明度和实时了解项目风险和质量。

所以请保持交流的通畅,并将所有反馈的消息自动化,包括测试结果、变更单和重新测试,以便使一切流畅进行。同时请承认该方法论的局限性,如果你的专家坚持独立工作,而且矩阵管理过于臃肿使得所有的反馈线路难以管理,请不要羞于承认敏捷的局限性,回到瀑布方法吧,虽然它有些过时,但它毕竟是经过验证的方法论。

在文末我们谈谈几点最关键的启示:

· 敏捷需要自适应架构。如果没有正式的设计过程,代码会堆叠在旧的代码之上,最终得到一个不灵活的设计结果。

· 工具被创造时,软件和业务敏捷度并非完全相同,这两种敏捷需要单个工具来满足所有用户的需要。

· “孤狼”开发者的时代已经过去,证据表明,更多样化的团队通过协作能够产出更好的成果,协作已然成为成功关键的因素。

· 将大规模敏捷项目扩大涉及团队间的和更多的跨职能间的协作和可见性

· 因为当今的项目可能一开始时并没有明确固定的需求,所以项目经理必须计划设立一条持续的规划和反馈循环。


查看英文原文:Six Ways Agile Can Turn Static

感谢罗远航对本文的审校。

同时我们欢迎对敏捷开发感兴趣的朋友一起参与敏捷开发公开课,一起交流学习


近期公开课

官方微博 官方微博
官方微信 官方微信

联系我们

购买:sales@evgetedu.com

意见与建议: service@evgetedu.com

Tel:400-700-1020(免费)

023-66090381(重庆总部)

地址:重庆市高新区陈家坪帝豪名都31楼