导致你的敏捷开发项目失败的 5 个原因 已翻译 100%

oschina 投递于 2013/05/15 07:33 (共 12 段, 翻译完成于 05-16)
阅读 5382
收藏 72
3
加载中

太多的敏捷开发项目失败。这很难甚至精确地测量这么多的软件开发项目失败的次数,因为最终“完成”和发布,即便:

  • 他们花了足够长的时间来构建
  • 构建的质量很差
  • 构建的产品不是客户所期望的的
  • 构建的成本大大超出预期

多年来,我在多个不同的敏捷开发团队工作过,同时也为一些敏捷开发提供咨询和培训。在这期间,我发现5个共同的问题,如果这些问题不被解决,就很可能会导致项目失败。

等PM
等PM
翻译于 2013/05/15 16:40
1

1. 不是产品所有者

所有的事情,都可能会导致一个敏捷软件项目的失败,而不是一个正在开发的产品  的最终的决策者的人,是确保其(产品)消亡最快的方式。

如果你追随Scrum的,没关系,只管做你自己的Kanban style project 项目或者别的事;如果你想你的项目能取得成功,你需要能一个能多所开发的产品设定方向和做决定的人。

想想要改造一个厨房。如果你聘请了一堆的承建商进来,做各种各样的工作,如:管道,木工,地板等,但你没有一个人来决定实际完成的厨房看起来应该像什么样,最终你将会得到一个乱七八糟的厨房。

等PM
等PM
翻译于 2013/05/15 16:49
1

Agile development remodel

少有的几个承建商可能会足够的聪明的,能找到正确的人以询问应该做什么,但设计一个厨房需要的不仅仅是随意的决定橱柜放哪儿,而是需要更多。你需要的是有人能真正的提出符合实际的设计和愿景,并随着工程的不断推进能对愿景进行纠正,以避免问题的发生。

话费大量钱财重建你的厨房,看起来相当疯狂,但不想在设计成品或者雇佣人员上投资任何时间和努力,已完成该项工程。

当然,日复一日,我在软件项目中的确看到很多这样的行为。我看见很多公司在敏捷开发上花费了大量的金钱,但并不会委任任何人成为正在建设的项目的真正的主人,并为它设置愿景。

等PM
等PM
翻译于 2013/05/15 17:01
1

2.没有迭代

迭代是敏捷开发给软件开发世界带来的关键价值之一。

但什么是迭代呢?

你可能会认为,这意味着将你的项目分成两个短周期或者迭代周期。虽然这样做可以促进迭代开发,这并不意味着你是在使用迭代。

感到困惑了吧?下面就让我们揭秘吧:

迭代的关键是在时间范围内,一点点的开发一个产品。这将准确的,作为一个产品的演进来描述迭代过程中的商品。

无论你是否相信宏观进化,微进化,或适应性是否是一个成熟的概念。进化背后的想法是事情随着时间的推移逐渐被改变。由量变到质变。

试想一下,如果进化论是最“敏捷”软件内置的方式工作,这将是多么的愚蠢。

试想一下,如果你是一条在大洋中游动的鱼,并有一些自己的在出生时就有功能健全的腿的鱼宝宝。然后,那些有腿的鱼宝宝长大了,然后又有翅膀的鱼宝宝。

等PM
等PM
翻译于 2013/05/15 17:20
1

Agile development evolved fish

也许腿和翅膀并不会让鱼能活的更好,也没有被恰当的设计,因为腿和翅膀的出现,不是随着时间的推移因适应所做的改变,而是突然出现。

产品功能不应该以单一的短周期或迭代来建立。好比在单一的一代鱼的身上出现退一样愚蠢。

反之,功能应该随着时间的推移和进化。某种功能不应被放入到某种单一的短周期或迭代,然后去实现。一种功能应该从小规模开始,并随着时间的推移进行进化和开发收到反馈,客户或者产品所有者试图将其开发出来。

太多的时候,我看到敏捷开发的项目进行了错误迭代和迭代开发产品。

不要试图发送一次完成的功能,而是让它随着时间的推移来完成。

等PM
等PM
翻译于 2013/05/16 08:38
1

3.没有将事物分解的足够小

对于将事物分解成小的、易接受的块,我是坚定支持者。
为什么如此重要的一个主要原因,是这样做可以避免延期。

延期经常发生在当我们对大型的可能困难的任务感到畏惧的时候,或者我们不知道接下来该做什么的时候。
如果你能将大项目分成很多小块,这将使项目看起来很容易完成,并有一个明确进展步骤。

我经常看到,没有给之前的软件项目考虑足够的工作,人为的创造了积压工作或工作项目。

我创造了一个长期的积压类型:fatlogs。Fatlogs积压没有分解成足够小,并且经常对于要完成什么非常模糊。

等PM
等PM
翻译于 2013/05/16 09:06
1

当试着理解和解释他们的时候,Fatlogs是出了名的难以估算和浪费时间。关键是fatlogs被分解成更小的可操作的积压工作给敏捷开发团队或大量的时间将被浪费。

很多时候,我发现fatlog 的创造者可以很容易的将工作分成小的易于解释和理解的积压工作,即使对于软件开发知之甚少。

我时常建议敏捷开发团队,他们应该彻底拒绝fatlogs 并将其送回到某条链上。

如果你不能花足够的时间来清楚地说明你想要什么,那么它就没那么重要。
但这也不足以豁免开发团队。 开发团队应该将他们得到的任何积压工作分解成小块任务。
等PM
等PM
翻译于 2013/05/16 09:55
1

4.没有设置标准

当你订一块牛排的时候,服务生问你的第一件事是什么?

显而易见,他们问你你想如何完成它。

如果厨师不知道你想要完成的牛排的制作标准,厨师就必须决定他或她的制作标准是什么。

Agile development done steak

你可会得到一个完美的牛排,或者一个让你难以置信的牛排,或者介于两者之间,完全取决于为你烤制牛排的人。

这不是一个烤制牛排的好方式,同样也不是制作软件的好方式。

在大多数软件项目中,我经常遭遇到大量的在烤制时没有定义的牛排。积压工作当时间耗尽的时候,经常被“做”。

对于一个敏捷开发团队,做任何积压工作有一个明确的标准是相当重要的。

等PM
等PM
翻译于 2013/05/16 10:04
1

这意味着,产品所有者应该定义一些可接受性测试。测试是手动测试还是全自动测试没有关系,与团队指定的标准是否能达到其测试目标有关。

缺乏标准,好比父母对孩子所提的问题“我应该吃多少豆子?”时所做的回答:“吃饱就行”一样。

没有制定标准会导致负面情绪,并为什么在手指指向的方向没有做正确的事。

我发现,如果你详细的告诉某人你对他的期望是什么以及评判的标准是什么,你将会比仅仅分配给他们任务得到更好的结果,牵着他们的鼻子说,“好好干。”

等PM
等PM
翻译于 2013/05/16 10:12
1

5.不要为了团队而建立团队

团队是一个奇怪的组织,特别是敏捷团队。

有很多的变数,会影响到团队的行为和交互。有太多的方式组建一个健康的团队,亦有很多方式创建很烂的团队。

一个健康积极的团队具有协同作用,一个不健康的消极团队比其团队成员各干各的好不了多少。

关键是有一个健康的团队,能让每个团队成员都变得很自主。无论你的政见如何,你也许会同意以下观点,当一个国家入侵另一个国家,并建立了一个并非由公民选举的政府来管理人民,肯定有问题的。

等PM
等PM
翻译于 2013/05/16 10:26
2
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(16)

狂暴的大螃蟹
狂暴的大螃蟹
失败的原因,大部分来自本来就不清晰还要改来改去的需求
闪客
闪客
最讨厌看这类不实际的东西 太文艺了··· 来点实际的 比如 1天1000个表的crud 200个流程 50个界面 以及8小时的工作时间
闪客
闪客
最讨厌看这类不实际的东西 太文艺了··· 来点实际的 比如 1天1000个表的crud 200个流程 50个界面 以及8小时的工作时间
从来不登录
从来不登录
以我的切身体验来看,敏捷=快速迭代=发布周期短=天天加班
不知道起什么名字
不知道起什么名字
感觉我们的敏捷开发就是骗人的,自从公司由传统瀑布模型转到敏捷模型后加班更加严重、质量更差、文档缺失、维护成本上升。个人认为不是所有的项目都符合敏捷开发。
jQer
jQer
还是人家乔布斯说的做有用,那些只想着产品的人 ! 你怎么搭建团队又有什么关系
梅开源
梅开源
敏捷的根本问题是因为叫敏捷方法的原因是采用的开发过程本质不敏捷于是用相对敏捷的策略来修补
静虚
静虚
不要为了团队而建立团队
到处都这是这样的句子,不要为了XX而XX。有几个人能明白。全是在玩文字游戏。
开源中国党委书记
开源中国党委书记
好文章
ChappaKo
ChappaKo
读了一会我就软了,完全没了性致
返回顶部
顶部