李超实习调查报告.doc

敏捷现状调查报告小型公司通常在实现敏捷开发上没有太多困难。这不是一项太难的任务。大部分遇到问题的团队都是在更大型的组织级别中。这正是问题：您如何计划？如何管理您的利益相关者和高层支持者？您如何与敏捷开发团队所依赖的其他团队合作，确保成功交付最终的产品？当我们与客户交谈时，我们的意图是通过分享我们活动中实用、成熟的经验和实践来帮助人们，他们可应用这些经验和实践来解决其组织的转型问题。我们发现，大部分敏捷团队都在大型组织中，他们需要扩展一个敏捷项目，但面临着文化层面上的挑战。我们开展敏捷现状调查，是因为我们希望询问敏捷从业者，“您在实际中使用敏捷方法做什么？” 我们还想了解他们在使用敏捷时获得的收益类型（包括他们的组织所实现的收益）以及他们采用敏捷的过程中经历过（或目前正在经历）哪些阻碍。我们将调查范围限制到实际拥有敏捷经验的调查对象。我们的调查对象包括来自不同领域和不同组织的各种人群。许多人来自非常小的敏捷团队，但也有一些调查对象来自非常大的团队。例如，16% 的人来自拥有 21 个或更多成员的团队，其中很大比例的人来自拥有 100 多名成员的团队。这些信息类似于在传统软件开发组织中找到的统计数据。有趣的是，受调查者中只有 26% 位于同一个位置，也就是说，大部分人都以某种方式分散在不同地方。1/3 的受调查者表示需要空中旅行才能将整个团队集中在一起。这些细节很重要，因为敏捷社区可能会强调位于相同位置的重要性。但是从总体数据看，我们看到了大量分散的团队组织。在实践中使用敏捷方法我们的调查表明，人们正在监管形势和复杂技术形势下成功地使用敏捷，比如需要遵守标准和政府规定的项目。受调查者表明敏捷范围大小不一；但是，更大的团队必须修改所应用的一些实践。甚至通用实践（比如举行每日动员会议）也必须进行调整，以反映真实现状。团队需要采用真正规范、完整的生命周期方法，尤其是在解决跨组织实践时，比如 DevOps。这些结果支持着这样一种想法，敏捷项目应该受企业支配并在企业级实施。项目经理应该与企业架构师合作，遵循现有数据源的常用编码约定。一种成熟的敏捷实现方法会反映您自己所在组织的类型。敏捷收益我们调查分析了全部收益。4/5 的调查对象表明，由于他们使用了敏捷技术，他们的交付成果的总体质量得到了改进。同样有 4/5 的人表明最终改善了生产力，提高实用性。2/3 的人表明他们提高了 ROI 并改善了交付速度。而且，所有这些都是与利益相关者紧密合作、迭代式和增量式工作的直接结果，这意味着开发团队构建了利益相关者真正想要的东西，而不是他们指定的东西。有趣的是，1/3 的受调查者表明，与系统一起提供的文档得到了改进，一半的人表明，他们得到了相同质量水平的文档和系统。大约 80% 的人报告，拥有和以前使用方法得到的同样好或比之前更好质量的文档。您会问，这里的重点是什么？简单来讲，文档是敏捷社区批判了多年的一个东西，但事实上，敏捷文档实践似乎能够提供可靠的结果。当然，如果无法帮助企业自身变得更加敏捷，全世界的所有技术敏捷性都毫无意义。我们的调查表明，超过 90% 的调查对象表明他们对变化（包括商业环境和业务需求中的变化）做出反映的能力得到了改进。结果指向了这样一种趋势：软件开发实践的质量与企业的质量一致。频繁的利益相关者互动和紧密的团队协作可能是所有其他敏捷技术的核心。我们相信，如果团队更多地关注规划敏捷、布局利益相关者支持和促进这些收益的实现，利益相关者的满意度将显著提高。可能需要更多的培训，或许通过进一步熟悉在天平的较高一端添加的规范需求来实现，而不是在 Scrum 或 XP 方法中提供的基本培训。敏捷不仅是基本培训我们多年来一直在通过注重实效的敏捷、精益且快速的开发方法为客户提供帮助，但在最近两年，我们已将我们规范且可扩展的实践标准化为一种端到端方法，并帮助客户实现它。规范敏捷交付 (Disciplined Agile Delivery, DAD) 是一个流程框架，反映了组织在采用敏捷方法和尝试高效地应用敏捷方法时遇到的现状。DAD 支持比纯敏捷方法更加可靠的工作方法。因此，我们真正想要问的一个问题是，双向 Certified ScrumMaster (CSM) 课程是否是他们取得成功惟一所需的东西。不到 4% 的受调查者给出肯定的答案，所以我们得出的结论是：它是一个合理的开端，但培训不应该止于此处。基本的敏捷培训无疑必不可少，但它仅是您的成功必备要素中的冰山一角。当从一个成熟的、具有 DevOps 问题、需要改善的治理、企业级开发环境和企业架构的组织的全盘进行考虑时，您在开始采用可不断扩展来满足这些挑战的敏捷方法时会发现，您需要一个更加成熟、更加规范的方法。我们也注意到了挑战有时，好意的精英敏捷顾问会尝试通过他们的敏捷转型来帮助较大型的组织，但他们并不总是具备能力来解决正在发生转变的一些事情。我们的调查证实了这一观点，团队在尝试实现敏捷实践时会面临一些常见的阻碍。这些挑战包括衡量成功、IT 的财务治理与敏捷战略之间的脱节，以及与非敏捷团队合作。衡量成功过去 10 年来，IT 组织已与业务分离开，更多地关注成本削减，而不是为业务提供支持。但没有合理地协调业务和 IT，敏捷实践确实没有什么效益。当敏捷拥护者取得了能带来企业支持的进展时，实践本身就会开始提供这种端到端可视性，这意味着责任性，哪怕是在大型组织中也一样。拥有更好的衡量方法和可视性，团队会找到更多共同点来与他们的高管和支持者合作，有望再次将业务和 IT 联合起来。敏捷实践提供了一种机制来实现此目的。尽管许多人仅从项目级别来考虑它，但您确实有必要考虑组织级别并部署更高级的衡量指标。财务与敏捷的脱节几乎有一半受调查者表明，他们的 IT 财务治理方法（项目）与敏捷战略脱节。许多团队反映，他们仍被迫在验收项目时提供详细或准确的评估，老实说，甚至对于传统项目而言这就是一种非常糟糕的实践，更别说敏捷项目。这是公司需要克服的一个严重问题。一般而言，我们仍然会看到业务需求与高效的 IT 治理之间存在很大的脱节。提前索取详细的规范和详细或准确的评估，不是克服这一挑战的办法。在 IBM，我们开发出了一个名为 DIS Financial 交付的产品来帮助填补这一空白。DIS Financial 交付是一种流程框架，它反映了组织在采用敏捷和尝试高效应用敏捷方法时所面临的现状。非敏捷团队几乎 2/3 的调查对象表明，他们的敏捷团队受到了阻碍，因为他们所依赖的其他团队没有采用敏捷方式工作。例如，数据管理小组或质量保证小组采用了一种传统方法，减缓了这些流程并使一些任务变得更加困难。事实上，非敏捷团队为增加了大型组织面临的风险，而不仅仅是敏捷团队的成功所面临的风险，因为非敏捷实践会降低团队和个人的生产力。哪些最终参与多个团队的人，同时是因为他们拥有多个项目中都需要的某些专门技能，这实际上会成为开发团队的瓶颈。这些问题将可能随着时间逐渐消失，但一些组织仍将挣扎一段时间。最后的思考：IBM 和其他大型敏捷采用成就IBM 代表着世界上最大型的敏捷采用成就之一。我们不仅在自己的开发团队拥有敏捷方法（我们现在已编写了多部图书并参与过多项敏捷采用案例分析），我们还帮助数百家组织转型到敏捷方法。这是我们的关注重点。我们帮助组织理解敏捷战略和如何高效地采用它们。我们在 IBM 的许多团队的工作规模相当大，而且开发团队的很大部分人现在都在以敏捷方式工作。IBM Rational Team Concert 是一个由全球分布式敏捷团队为敏捷开发人员构建的一款产品。我们正在主动帮助客户理解 agilityscale。我们的 Rational 和 Global Business Services 敏捷产品为大规模敏捷开发提供了基础。如果您有机会，请访问 Agile Transformation 专区和 J，了解我们正在做的一些真正有趣的事情。对于正在尽力实现规范且大规模的敏捷项目的客户，请联系您的 IBM 代表，我们可以探讨您的具体挑战并定制一项适合您需求的服务活动。 结束