InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

失败的敏捷项目

作者 Mark Levison 译者 郑柯 发布于 2008年7月13日

领域
架构 & 设计,
过程 & 实践
主题
企业级敏捷 ,
敏捷 ,
客户及需求
标签
业务/IT整合

作为敏捷专家,我们热衷于谈论在项目上取得的成就,却很难做到对失败直言不讳。Robin Dymond在“一个失败的敏捷项目”这篇文章中谈到了有关失败的话题。

Robin的文章中谈到一个替换内部现有流程的例子,从任何角度看这个项目都应该成功:

  • 实施基于现有的商业软件(COTS, Commercial Off The Shelf Software)
  • 产品负责人对现有流程有着深入的了解
  • 团队成员具有在商业和敏捷项目实施上的成功经验
  • 资深敏捷教练曾与该组织有过广泛的合作
  • 3个大型的咨询公司为团队成员提供产品方面的知识

第二个迭代结束时,事情开始变坏。产品负责人怀疑COTS工具能否完成任务。在第三次迭代过程中,业务用户试用软件的反馈普遍都是负面的。因为不具备长远的眼光,产品负责人被撤销了。Elizabeth Hendrickson曾说过“在第三次迭代中,如果所有用户的反馈都是负面的,应该取消这个项目或者重新仔细规划。”

Rpbin认为,在项目开始之前,这次失败就已埋下了伏笔:

立项:项目由IT总监和运营总监一起推动。现有的业务并没有成为驱动这个项目的动力,其流程也不需要进行改进。

平台选择:选择新平台的驱动力在于,大家确信基础设施需要从原有的定制系统转向商用软件。……应用系统在项目开始之前就已经选定了,没有人试过它是否能满足需求。而且,团队开始使用这个应用系统时,才发现它的能力非常有限,业务用户们使用起来也非常痛苦。而总监拒绝承认这些数据。

Allan Shalloway认为这个项目的问题在于:“没有真正的用户认可,只是业务负责人说要这么做”。在Allan和团队建议取消这个项目数月之后,他谈到这个项目的失败原因:

根据我的经验,许多Scrum项目并没有真正按照Scrum的要求实施。每当我们去帮助或训练这些团队时,他们都会说自己已经有多少个月的Scrum实施经验。一旦问到他们真正在做什么,就会发现这些并不符合Scrum的要求。

此后Allan指出,他看到很多团队都对Scrum的原则缺乏清晰的理解:

    • 一次只着眼于一个产品
    • 让团队把关注点集中在业务价值上
    • 拥有强有力的业务出资人支持
    • 让团队的工作针对故事进行
    • 清晰定义“完成”对于团队的含义
    • ……

最后Robin描述了他登山的经验,他谈到加拿大的阿尔卑斯俱乐部有一本刊物——《阿尔卑斯意外事故月刊》。这本杂志记录了登山发生的意外事故,可以让其他的登山者们认识到什么地方出了问题,如何摆脱危险,以及事故发生的经过。Robin认为我们也需要这样的月刊:“每天都有数十亿的资金耗在这上面,跟其它行业相比,软件项目存在惊人的高失败率,难道我们不应该正式地记录和分析这些失败吗?”

查看英文原文:Failures in Agile Develoment

InfoQ的读者Joakim Holmbäck在评论中认为:

识别项目中的失败之处并从中吸取教训,是改进流程的关键。我也同意我们应该(更多地)讨论失败的敏捷项目,但是文中的例子并不恰当。

文中的敏捷过程显然起到了作用。在第一个迭代中,COTS软件就被证明是不合格的了,产品负责人被替换也证明了这一点。项目失败的唯一原因,是管理层不能听从项目团队的建议。

不管使用什么样的项目管理技术,发生类似的事情总是会失败的。

读者Julian Browne提到:

在深水潜水社区中,有一个常用的时间:任何发生的小事故都会被公布出来,防止再度发生。British Sub Aqua Club会发布年度报告,供大家认真研读。

不考虑故事中的敏捷因素,我觉得其中缺少了解决问题——而不是实施解决方案——的上佳实践,记录并共享失败项目的教训就是其中之一。

不幸的是,很多(绝大多数)失败的信息都被限制在商业组织之内,而且这样的信息很少能被泄露出来。我们只能自己进行项目实施后的复查,这个主意不错,但是通常都执行不好。

针对文末的问题,Mark Levison公布说他开始准备收集整理《敏捷与Scrum失败月刊》,并希望大家提供素材,网址是:http://www.notesfromatooluser.com/2008/07/journal-of-agilescrum-failure.html。针对Joakim的说法,他认为:

还能有什么其他失败的原因么?Jerry Weinberg说过:“总是人的问题。”我想所有失败的项目到最后都能归结到人和沟通的问题上去。我倒想看看有没有能够证明我错误的例子。

针对Julian的问题,Mark认为,既然现在市场上有如此多的教练和培训师,从他们那里一定能够得到很多失败的例子。

而InfoQ资深编辑Deborah Hartmann对Mark的做法表示赞赏,同时她也向读者征求失败的案例,供未来的“理解”练习和研究使用,其网址为http://www.m3p.co.uk/blog/2008/04/14/what-is-going-on-out-there-a-narrative-inquiry-project/。

面对Mark的质疑,读者Joakim这样回应:

虽然总是可以归结到人的问题上,Scrum项目的任务失败还是会有N多种原因。上文中提到的失败,主要是由于管理问题:产品负责人被去掉了,而且团队的看法也没有人注意。(一个敏捷项目具备成功的所有要素,还是会失败;这看起来还是挺有意思的。)

Scrum团队失败的其他原因:

-依赖其他Scrum团队(scrum构成的scrum不能正常运作,每个scrum的日程不同)
-“完成”的定义没有正确使用
-故事太大太长
-团队不具备完成手上任务的技术能力
-团队的故事组织有问题,每个成员处理自己的故事,但是故事之间互相依赖
-团队不愿意做正确的回顾活动,因此很难进行改进

译者 郑柯 InfoQ中文站总编。做过开发,当过PM,干过销售,搞过市场,最终还是回到媒体。实用的理想主义者,相信:每天改变一点点,这个世界会更好。

项目管理的本质 发表人 源头 西水 发表于
Re: 项目管理的本质 发表人 小刀 凉粉 发表于
Re: 项目管理的本质 发表人 徐 绪雄 发表于
Re: 项目管理的本质 发表人 熊 小 发表于
Re: 项目管理的本质 发表人 小刀 凉粉 发表于
  1. 返回顶部

    项目管理的本质

    发表人 源头 西水

    项目管理的本质就是避免做错误的事情,可见《敏捷与Scrum失败月刊》之必要性

  2. 返回顶部

    Re: 项目管理的本质

    发表人 小刀 凉粉

    项目管理的本质难道就只是避免做错误的事情么?

  3. 返回顶部

    Re: 项目管理的本质

    发表人 徐 绪雄

    正与文中所提到的,所有失败的原因都可以归结为人和沟通的问题,成功的项目在这两方面必然是下足了功夫,不成功的项目总会以不同理由来回避这两方面的问题。需求总是在变的,人也是在变的,沟通的方式在发生变化,管理的实质也许只在于用适当的方式,让适当的人,做适当的事,得到适当的结果。

  4. 返回顶部

    Re: 项目管理的本质

    发表人 熊 小

    对于本质的简单认识并不难,难点在于如何具体解决一个又一个问题。做到adaptive才是王道。。。。。。 在理解原则的基础上,只有不断实践,并持续改进,才能做到真正的敏捷

  5. 返回顶部

    Re: 项目管理的本质

    发表人 小刀 凉粉

    在解决问题之前,要先能认识到问题。并能处理好首要矛盾和次要矛盾之间的关系。

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。