问有没有可能让敏捷为平台开发工作？

EN

我认为这取决于你如何定义敏捷。敏捷是一系列方法和实践的总称。

在Wikipedia中是这样定义的：

敏捷方法通常促进一个有纪律的项目管理过程，鼓励频繁的检查和适应，一种鼓励团队合作，自组织和责任的领导哲学。

我们在我工作的地方实践敏捷方法，架构团队以一种非常不明确的敏捷方式工作，功能团队使用Scrum。所谓未指定，我的意思是，对于流程如何，没有严格的规则，但我们使用了几个敏捷原则。最重要的是，开发不是以瀑布的方式完成的，而是以迭代的方式进行的。

在整个核心软件开发部门，我们使用持续集成和大量自动化测试。根据定义，每日站立表演是功能团队使用的一种实践，但有时也适用于平台团队，具体取决于情况。platform团队每周都会公开展示他们所做的事情。此外，用户故事不仅用于功能团队，有时也用于平台团队，当职责重叠，产品需求变成更一般的平台需求时。

所以，是的，我认为敏捷对于平台团队是可能的，只要环境(即管理和/或产品需求)允许。您使用什么以及如何使用它由您决定。

由于相同的原因，敏捷可以在平台开发中工作，也可以在应用程序开发中工作，但由于相同的基本原因，它在这两种情况下都可能失败。

根据定义，敏捷流程要适应其环境。通常是使用过程的人对其进行调整，以便它仍然适合正在应用的任务的目的。这种适应性使敏捷过程具有内在的健壮性，前提是在工作环境中可以容忍过程适应性。

在平台开发中，发布时间表通常比在应用程序开发中更远，更稳定。乍一看，这意味着交付增量功能的用处较小，并且不会提供与向客户交付可用增量功能所获得的反馈循环相同的反馈。仔细观察，只有当没有人在等待正在生产的功能，或者只有完整的可交付件具有任何价值时，这才是正确的。

一方面，环境更有利于成功；另一方面，敏捷过程的一个基本机制缺失。只要流程可以调整以弥补缺失的机制-例如，通过让测试人员或应用程序开发人员使用临时可交付成果-那么调整后的流程应该仍然适合于目的。

在软件设计和构建方面，软件(包括规范)的编写方式大同小异:一次一行，并且由或多或少相同类型的人编写:软件开发人员；在动机和注意力持续时间方面具有或多或少相同的特征。新功能的范围可能更大，并且目标是用更长期的时间表定义的，但它仍然必须在步骤中实现，并且这些步骤可以定义为适合迭代，并在结束时进行某种进度演示。开发经理经常从里程碑和可交付内容的角度来考虑，所以这可能只是当前实践的一种演变。

我见过不同团队在平台和应用程序开发中使用的Scrum过程。团队根据他们不同的需求和对过程的不同理解，以不同的方式实施过程，但主要的成功因素是团队(以及团队中的个人)的能力和团队管理的能力。