如果你的团队在用敏捷，教你7招，轻松干掉敏捷

敏捷项目管理

“成功有许多父亲，而失败是一个孤儿”，这是有思想的企业领导人经常引用的一句话。但是，当涉及失败的敏捷计划时，旧的观点可能会更新为：“成功是团队的努力，而失败只是每个人的错。”

没有新的敏捷计划旨在失败。然而，一个缺乏准备，信息不灵通的团队，将目光投向不切实际的目标，通常会从一开始就注定了项目失败。

是否要确保您的敏捷计划会崩溃成一堆扭曲的希望和梦想？好了，这里有七个简单的步骤足以干掉敏捷：

敏捷规划

1.宽松而混乱地计划

围绕敏捷性的伟大神话之一是规划和结构并不是必不可少的。但这不是真的。“敏捷不是混乱或没有管理的借口，”提供项目管理和敏捷服务的公司Project Management Essentials的创始负责人Alan Zucker说。

“规划本质上是您的执行策略，” Creative Chaos的首席创新和技术官Umair Aziz指出。CreativeChaos是提供媒体制作，演员和活动设计服务的敏捷采用者。“该策略常常含糊不清-太高而无法执行工程师-但使用可以分解为检查清单的框架可以确保一致性，并能不断提醒您使给定项目保持进度。”

敏捷发布培训（ART）是一种基本的计划工具，可以使各个团队适应共同的业务和技术任务。技术咨询公司PSC Group的高级顾问兼业务经理Rod Cortez说：“高级管理层选择的项目将为公司带来最高的成本/收益。” 然后，敏捷团队会评估这些功能，并在sprint中计划（在一定时间内必须完成特定工作并准备进行审查）。Cortez说：“有效地使用敏捷开发方法的公司可以提前三到十二个月计划功能和项目，并且成功率很高。”

不合作的团队

2.组建一支不稳定且选拔不佳的团队

团队协作是成功实施敏捷计划的关键。阿齐兹说：“如果你们有一起工作的人，并且了解彼此的长处和短处，那么与一群陌生人相比，您将拥有领先优势。” “如果要组建一支崭新的团队，请引进对您的工作有明确兴趣和激情的人。”

 

敏捷管理平台供应商AgileCraft的首席执行官Steve Elliott说，人力资源和传统团队结构可能是一个棘手的问题，但是团队之间的依赖关系是最终的敏捷杀手。他指出：“有数十种方法可以使团队保持一致并分解工作以减少依赖关系，因此，为使团队对团队的依赖关系降到最低，值得我们付出很大的努力。” “战略应用程序生命周期管理（ALM）工具可以帮助确定并提出优化团队以减少依赖性的方法。”

祖克（Zucker）认为，所有敏捷团队都应自给自足。他说：“换句话说，他们不需要依靠其他专业团队来完成他们的工作。” 他建议寻找通才的团队候选人。扎克说：“新的行业术语是'T形'或'E形'资源。” “ T形资源具有专业知识或深度的领域，但也可以在其他技术领域工作。” 另一方面，E形资源拥有多个专业。

沟通障碍

3.尽可能少地进行秘密沟通

沟通属性差的敏捷团队通常不会成功。扎克说：“敏捷更喜欢在交流和信息流持续不断的地方的团队。” “敏捷希望与产品负责人以及团队内部进行定期沟通。”

站起来和冲刺回顾之类的日常仪式提供了正确的最佳方法。阿齐兹说：“如果没有迭代的路线修正，团队将永远不会变得更好。” “确保障碍已得到注册并得到了妥善解决；确保在整个公司中共享所汲取的教训。”

让所有团队成员和整个企业中的敏捷团队进行相同波长的交流也很重要。埃利奥特说：“将许多小组聚集在一起时，通常会以多种方式使用术语。” 为了使敏捷项目成功定位，企业中的术语应统一。Elliott说：“敏捷是首字母缩略词，对于刚开始接受有限的敏捷培训的商务人士来说是一个困惑。” “如果这些团体不使用通用术语，那么这一挑战将会更加突出。”

项目

4.不完全了解项目的范围或重点

与大多数传统项目不同，敏捷计划的范围不是一成不变的。扎克说：“对于敏捷项目，产品负责人设定了愿景和路线图。” “愿景和路线图指导了开发过程。”

Zucker解释说，该路线图将分解为一系列增量构建，每个构建都为客户提供价值。敏捷团队要开发的项目保存在产品待办事项列表中，该列表是要交付的东西的优先列表。每增加一次，团队就会从列表的顶部拉出项目以交付给客户。

从一开始，敏捷项目就必须将企业的总体战略（任务，愿景，价值和目标）与实际完成的工作联系起来。Elliott说：“这确保了交付的工作与战略主题相关，如果没有，那么您可以迅速进行调整。” “使用可预测性分析和速度将有助于计划经理适当地确定计划增量计划的范围。”

测试

5.测试不善而随意

软件顾问Tom Brusehaver说，测试绝对至关重要。他说：“进行单元测试将使开发人员更轻松地更改代码。” “功能测试还可以帮助开发人员知道，当事物发生变化时会产生影响，也许更改需要调整，或者测试需要更改。” 集成测试也很关键。Brusehaver说：“通过较小的sprint-length增量，每个人都应该能够放心，潜在的可交付产品将执行产品所有者/客户希望的操作。”

许多敏捷团队使用测试驱动的开发实践，其中测试用例在代码之前编写。“他们还使用自动化工具来最大化可以在代码上运行的测试的数量，”扎克·天说道。“敏捷还希望与产品负责人紧密合作，使团队能够准确交付预期的成果。”

不支持

6.无法赢得管理和员工支持

敏捷的好处是显而易见的，但是假设所有各方（尤其是企业领导者）将从一开始就加入董事会是错误的。埃利奥特说：“转型非常昂贵，这给即时结果带来了压力。” “重要的是，在开始真正的敏捷转型之前，请确保组织高层支持它，可以赢得政治斗争，并可以一遍又一遍地向团队重复“为什么”。”

赢得支持的最佳方法是证明敏捷实际上会增加成功交付产品的几率。金融安全咨询公司Finserv Experts的常务董事Areiel Wolanow说：“已经在某些条件下对它进行了实证检验，但绝不应该将其视为理所当然。” “要获得对敏捷的支持，您需要说服利益相关者，对于特定程序而言，敏捷成功的关键因素是正确的。”

解决员工和经理的担忧也很重要，他们担心敏捷可能会对他们的职业产生负面影响。埃利奥特说：“人们之所以要敏捷，是因为他们凭直觉知道如果不是的话，那它们就是遗物，但是对他们而言，这样做必须是安全的。”

扎克同意。他说：“员工需要知道管理层会'放手'并允许他们进行自我管理。” “他们还需要看到他们可以小失败而不受到惩罚。”

障碍

7.忽略客户反馈

客户反馈是敏捷交付过程不可或缺的一部分。Wolanow说：“敏捷学科和传统交付方法之间的主要区别之一是，敏捷计划希望整个项目中都能获得反馈，而不仅仅是在授权的控制门上。”

客户反馈对于确保任何敏捷团队的建设将是有用的至关重要。“在没有客户反馈的情况下，要优先确定要关注的领域非常困难，团队最终可能会把所有事情都视为重要，这与什么都没有一样重要，”阿齐兹说。

埃利奥特说：“敏捷使客户融入了流程，这是流程起作用的关键。” “使客户参与计划和开发的各个方面，您赢得市场的可能性将成倍增长。”

要记住的另一个重要点是，敏捷团队在迭代结束时进行回顾时将使用并依靠客户反馈。扎克说：“在回顾中，团队分析了在增加建造量方面取得了哪些进展以及哪些方面可以改进。” “然后在下一个构建周期中实现对内部流程的更改。”