根据2013年Ambysoft的调查，敏捷项目成功率约为64%，但仍有大量项目未能达到预期。专家指出，企业软件开发中存在7个主要因素可能导致敏捷项目的失败。
敏捷项目管理方法
根据Ambysoft在2013年进行的一项调查，采用敏捷方法的项目成功率约为64％。 这比不上瀑布的惨淡数字（不到50％）要高，但这仍然意味着有很多项目应该是敏捷的，而最终却只是脆弱。 使敏捷失败的后果是什么？ 在企业软件开发领域的四位经验丰富的专业人员的建议下，有七个阻碍成功的障碍。
排名第一的瀑布…
性能测试经理Mark Yarbro描述了他认为大多数软件开发团队在声称自己在做敏捷时所做的事情 。 “在Scrum中，有一堆人围坐在一个会议上，从积压的工作中挑选东西，开始估算，开发人员只是在编造东西，而质量检查人员只是在复制开发人员的话。 经过大约一天的时间，所有事情都被指出了，所以他们都开始制定代码。 QA坐在那里，编写一些测试用例，但实际上正在等待代码交付。 因此，进入冲刺的一两个星期后，代码便开始提供给质量检查人员，他们开始进行测试，开发工作处于等待状态。 他们正在计划下一个冲刺，从待办事项中拉出更多东西，并弄清楚下一步将要做什么。 你知道那是什么吗？ 那是瀑布。 您正在做四个星期的瀑布。 那就是RAD（快速应用程序开发）。 这就是大多数人称之为敏捷的做法。”
＃2不应在适当时候提供反馈
在理想的环境中，最终用户或真正的客户将在第一次会议上就坐。 可悲的是，这种情况很少发生。 这意味着总会有一些假设。 Ideliver的创始人兼董事总经理Satyapal Chhabra强调了这个问题。 “如果您有连续的冲刺，那么真正的最终客户何时开始参与？ 大概冲刺18或19. 这种参与是敏捷的基本前提。 但这不会发生。” 马克表示同意，“他们应该从一开始就在那里。” 根据他的经验，团队最终会使用代理来代表客户，从而无法正确预测客户真正想要的功能。
企业敏捷教练Jay Packlick指出，如果已知缺乏信息，则敏捷必须做出调整以考虑到缺少的知识。 显然，客户参与的时间越晚，识别并满足其需求所需的时间就越长。 这是敏捷中成本和预算超支的常见原因。 “这是出问题的地方。 他们有这样一种情况，直到19冲刺之前客户都无法使用，但是他们无法解决“我该怎么做才能获得反馈？”的问题。 这是敏捷的核心原则之一的失败，那就是改变您的方法以解决您的问题。 您检查并调整。 您必须更换系统，否则它们将持续数月而失败。 我不在乎你在做什么。 如果它不起作用并且您不进行更改，那么它将失败。”
＃3敏捷文档几乎总是残酷的
根据在敏捷商店工作了多年的Mark所说，很容易被Scrum的忙碌和忙碌所取代，而不关注可持续性。 “在日常站立时，不应有任何状态更新。 没有“我一直在努力……”只是您已完成的工作，希望完成的工作以及完成该工作的任何障碍。 不断地完成工作是保持敏捷工作的动力。 否则，这很麻烦。 但这也是不做任何文档的借口。 企业需要考虑更大。 实际的发展只是冰山一角。 维护工作是在水下。” 他描述了组织遗忘症，这种遗忘症是在开发人员继续前进时留下的，没有人记得代码的细节。 必须加强问责制。 “ Pure Play Agile并没有考虑到完成的工作不是预期的事情，而是要检查的事情。”
＃4敏捷测试也经常发臭
不仅文档严重不足，而且整个项目中的测试经常会受到关注。 马克再次评论说：“敏捷需要更好的测试。 为了使一切正常，您需要质量检查人员，他们既是开发人员又是不怕测试的开发人员。” 质量管理专家Brian Bernknopf表示同意。 “只有敏捷开发，您才能让开发人员从事故事工作，而QA负责发布，您就无法拥有敏捷SDLC。 其他传统的质量检查职责可能会发生变化，但是您仍然需要管理。 在日常构建中，签入时将进行哪种类型的测试？ 您怎么知道这些是权利测试？”
不幸的是，许多团队在采用敏捷方法时并没有弄清楚如何使事情正常进行，而且质量检查经常会被搁置。 这意味着他们需要重新坐在桌子上的座位，即使它在另一把椅子上。 “这是一个不断变化的角色。 他们需要能够坐在Scrum内部并跳进去解决问题。 以类似的方式，开发人员需要能够帮助编写测试脚本。 在敏捷项目中，质量保证是一个角色，不一定是一个人。 您可以在这个职位上拥有质量检查心态的开发人员。”
＃5随着时间的流逝，关键利益相关者的参与度降低
敏捷并非所有人都免费。 它需要纪律。 FusePLM的联合创始人兼首席执行官Shreyas Batt发现了难题。 幸运的是，他的团队最近的项目没有失败，但是肯定比计划的时间要长，因为他们对遵循规则并不一致。 在这种特殊情况下，与离岸开发团队合作增加了后勤和时区问题。 “我们每周开会。 但是随着时间的流逝，项目经理或Scrum经理有时不可用。 那时只有一群开发人员，但是没有人来指导他们并使他们保持正确的状态。 在我们这边，我们并不了解内部计划。 您需要合适的人选。”
＃6演示变为可选而非强制
未能优先考虑敏捷结构并确保持续的反馈和沟通对于Batt团队也是一个错误。 “我们对发生的事情表示信服。 它没有给我们带来好印象。 我们不想进行微观管理，但希望对进度有所了解。 首先，我们每周都会有一个演示。 后来，我们执行得不够好。 他们告诉我们他们在做什么，但直到八周后才真正交付测试代码。 那时我们意识到他们不了解这些要求。 正确执行敏捷将真的有帮助。”
＃7敏捷的渴望模糊
杰伊（Jay）透露，他寻求帮助组织解决的第一个问题是弄清楚他们实际需要进行哪些更改。 大多数时候，与他交谈的人并不确定。 “这是第一个问题。 他们想做些事情，但不清楚他们真正想要什么结果。” 接下来是挑战，弄清楚是否真的可以进行敏捷方法的转变 。 “您必须确定谁是控制者或冠军。 有时，组织内没有人是拥护者，目前还不清楚，或者该人没有采取行动来领导这种变革。” 必须满足正确的变更条件，并且正确的人员必须具有适当的参与水平。 否则，尝试在传统的瀑布文化中进行敏捷项目根本行不通-该项目甚至在开始之前就被破坏了。
敏捷项目管理方法
扫一扫
517
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
