太多的敏捷开发项目失败了。 即使如此，由于许多软件开发项目最终都“完成”并交付使用，因此即使准确地衡量故障数量也非常困难，即使：
- 他们花了太长时间才建造
- 我们建造的建筑质量 很差
- 建造的不是客户想要的
- 开发成本 超出了应有的水平
多年以来，我曾在许多不同的敏捷团队中工作，并就敏捷开发向许多团队提供咨询和培训。 这一次， 我发现了5个常见问题，如果不解决，很可能导致项目失败。
1.没有产品负责人
在可能导致敏捷软件项目失败的所有事情中，没有一个最终要开发产品的决策者的人是确保其消亡的最快方法。
无论您是关注Scrum，进行自己的看板风格项目还是其他事情，都无关紧要。 如果您希望您的项目成功，那么就需要可以设定方向并就所开发产品做出决策的人员。
考虑改造厨房。 如果您雇用了一堆承包商来从事各种工作，例如：水暖； 木工 地板 等等，但是您没有人来决定实际的成品厨房应该是什么样子，那么您将陷入混乱。
一些熟练的承包商可能会足够聪明，以找到合适的人去问应该怎么做，但是这不仅仅是对橱柜应该放在哪里设计厨房做出任意决定。 您需要有人实际提出一个真实的设计和构想，并能够随着项目的进行和不可避免地出现问题而适当地修改构想。
花大量的钱来改造厨房似乎很疯狂，但不想花任何时间或精力在设计成品或雇用某人做这件事上。
然而，日复一日，我在软件项目中看到了这种确切的行为。 我看到公司在敏捷开发中投入了大量现金，但没有任命任何人成为正在构建的产品的真正所有者，也没有为它设定愿景。
2.不迭代
敏捷开发带给软件开发世界的关键价值之一是迭代。 什么是迭代？
您可能认为这意味着将您的项目分成2个星期的冲刺或迭代。 尽管这样做可以促进迭代开发，但这并不意味着您实际上在迭代。 困惑？ 让我解释。
迭代的关键是及时开发产品。 将产品的迭代过程描述为产品的演变是准确的。
无论您是否相信宏进化，微进化或适应都是一个行之有效的概念。 进化背后的想法是随着时间的推移事物会逐渐变化。 这些小的变化加起来导致了巨大的变化。
想象一下，如果采用大多数“敏捷”软件的构建方式进行进化，那将是多么愚蠢。
想象一下，如果愿意的话，一条鱼在海洋中游泳，并且有一些小婴儿，它们的双腿功能齐全。 然后，那些有腿的鱼宝宝长大了，并且有带翅膀的鱼宝宝。
腿和翅膀可能对鱼没有多大好处，也无法适当设计，因为它们没有随时间适应和变化，而是突然出现。
不应在单个sprint或迭代中构建功能。 就像一条腿出现在一条鱼上一样愚蠢。
相反， 功能应该随着时间的推移而发展和增长。 不应将功能推入单个sprint或迭代中，然后再完成。 功能应从小规模开始，并随着收到反馈以及客户或产品所有者对其进行尝试而逐渐发展。
太多次了，我看到敏捷开发项目在实际迭代产品开发过程中会出现迭代错误。
不要试图一次发布完整的功能，而要随着时间的推移而发展。
3.没有把事情分解得足够小
如此重要的主要原因是因为它可以防止拖延症。 拖延通常发生在我们害怕一些很难完成的大任务或者不知道下一步该怎么做的时候。
如果您可以将一个大项目分解为几个小部分，那么看起来似乎更容易实现，并且有明确的进度。
我经常看到在软件项目中，创建积压或工作项目的人员在将工作交给团队之前没有充分考虑工作。
我为这类积压创造了一个术语： Fatlog 。 Fatlog是积压的，积压得不够细，通常在需要完成的事情上含糊不清。
众所周知，肥胖日志很难估计，并且在尝试解释和理解它们时会浪费时间。 至关重要的是，将胖日志分解成较小的可行积压，然后再交给敏捷开发团队，否则会浪费大量时间。
我发现很多时候，fatlog的创建者可以很轻松地将其代表的工作分解为几个较小的积压，即使不了解软件开发知识，也更容易解释和理解。
我经常向敏捷开发团队建议，他们完全拒绝肥胖日志，并将其发送回链中。
“如果您没有足够的时间清楚地说明自己想要的东西，那一定不会那么重要。”
这也不能成为开发团队的借口。 开发团队也应该分解他们完成小任务的所有积压工作。
4.未设置完成标准
当您订购牛排时，服务员首先问您什么？
是的，他们问您您想如何完成。
如果厨师不知道您的牛排的完成标准是什么，那么厨师将不得不决定自己认为牛排的完成标准是什么。
您可能会取回做得好的牛排，稀有的牛排或介于两者之间的牛排，具体取决于烹调肉的人的个人喜好。
这不是烹饪牛排的好方法，也不是烹饪软件的好方法。
在许多软件项目中，我经常会遇到很多牛排需要煮熟的情况，但是没有人定义何时完成。 当时间用完时，积压的订单往往最终被“完成”。
对于敏捷开发团队正在处理的任何积压工作，有明确明确的完成标准非常重要。
这意味着产品所有者应定义某种程度的验收测试。 测试是手动测试还是全自动测试（BAT）都没有关系，重要的是定义了一些标准，团队可以根据这些标准评估他们是否实现了目标。
缺乏这一标准就像父母在孩子问“我还要再吃多少豌豆？”时回答“足够” 。
没有完成标准会令人沮丧，并导致无法正确构建东西的指责游戏。
我发现，如果您准确地告诉某人对他们的期望和判断标准，您得到的结果将比仅仅把他们扔进圈里，拍打他们的背然后说“做得好。 ”
5.不要让团队成为团队
团队是奇怪的生物 ，尤其是敏捷团队。
有很多动态因素会影响团队的行为和互动方式。 建立健康团队的方法有很多，而建立不健康团队的方法也很多。
一个健康，积极进取的团队具有协同作用，一个不健康的，ga弱的团队可能比其所有成员都没有效率。
拥有一支积极向上的团队的关键在于让他们保持自主。 无论您的政治说服力如何，您都可能会同意，当一个国家入侵另一个国家并建立一个未当选的政府来监督人民时，就会出现问题。
敏捷开发中也会发生同样的事情。
我并不是说团队不应该承担责任。 但是，如果您想以敏捷的方式运行软件项目，则必须让团队在一定程度上进行自我组织和自我管理。
当老大哥一直在注视和干涉时，团队的动力就变得非常不同。 自然地，团队通常会发展自己的节奏，领导力和角色（ 这称为规范） 。但是， 当外部力量直接干扰团队做事的方式，而他们无权决定自己的命运时，团队成员就会开始意识到他们需要照顾自己。
其他敏捷开发资源
我发现很难找到有关这些主题的好资源，但是我发现了一些有用的书籍，可以解决我在上面描述的一些问题。
- 敏捷的成功：使用Scrum进行软件开发 –本书着重于Scrum，但它也适用于许多不同类型的敏捷项目。 迈克·科恩（Mike Cohn）和我通常在大多数敏捷问题上都同意。
- 敏捷回顾 –我发现这本书对于了解团队回顾的好主意很有用，这可以真正帮助打破一些障碍并帮助团队学习解决问题。
- Scrumban ， Kanban和Scrum –这两本书都提供了有关结合Scrum和Kanban的出色信息，并且为解决我上面描述的一些问题提供了很好的解决方案。
你怎么看？ 我是否错过了任何主要的敏捷项目杀手？ 有什么有用的技巧可以解决这些问题吗？
440
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
