是否有可能为平台开发制作敏捷工作？想象一组开发者，每个开发者负责平台的独特功能区域。现在，图2-4应用程序开发团队使用该平台为公众构建软件应用程序。你如何在这种情况下做出灵活的工作？
答案 0 :(得分：1)
我认为这取决于你如何定义敏捷。敏捷是一系列方法和实践的总称。
在Wikipedia中，它被定义为：
敏捷方法通常会促进 纪律严明的项目管理流程 鼓励经常检查 和适应，领导 鼓励团队合作的哲学， 自我组织和问责制 [...]。
我们在工作中采用敏捷方法，架构团队以非指定的敏捷方式工作，而功能团队使用Scrum。如果没有指定，我的意思是没有关于流程如何的严格规则，但我们使用了几个敏捷原则。最重要的是，开发不是以瀑布方式完成的，而是迭代地完成。
在整个核心软件开发部门，我们使用持续集成和大量自动化测试。根据定义，每日站立是功能团队使用的练习，有时也适用于平台团队，具体取决于具体情况。平台团队每周都会公开展示他们的所作所为。此外，用户故事不仅用于功能团队，有时也用于平台团队，当职责重叠并且产品要求变得更加普遍时，平台需求。
所以，是的，我认为只要环境（即管理和/或产品要求）允许，平台团队就可以实现敏捷。你使用什么以及如何使用它取决于你。
答案 1 :(得分：1)
敏捷可以在平台开发中工作，原因与它在应用程序开发中可以工作的原因相同，并且由于相同的基本原因，它可能在两种情况下都会失败。
根据定义，敏捷流程适应其环境。通常是使用该过程的人员对其进行调整，以便它仍然适合于正在应用的任务的目的。这种适应性使敏捷流程具有内在的稳健性，前提是工作环境中可以容忍流程适应性。
在平台开发中，发布计划通常比应用程序开发更加分散且更稳定。乍一看，这意味着提供功能增量不太有用，并且不会提供与向客户提供可用增量功能所获得的相同的反馈循环。仔细观察，只有当没有人在等待正在生成的功能，或者只有完整的可交付成果具有任何价值时，才会这样。
一方面环境更有利于成功;另一方面，缺少敏捷过程的基本机制之一。只要该过程可以适应以补偿缺失的机制 - 例如通过让测试人员或应用程序开发人员使用临时可交付成果 - 然后适应过程仍然适合目的。
在软件设计和构建方面，软件（包括规范）的编写方式大致相同：一次一行，或者大致相同的人：软件开发人员;在动机和注意力方面具有或多或少相同的特征。新功能的范围可能更大，目标定义为更长期的计划，但仍然必须分步实现，并且可以定义这些步骤以适应迭代，最后通过某种程度的演示来证明。发展经理通常会考虑里程碑和可交付成果，因此这可能只是当前实践的演变。
我已经看到了不同团队用于平台和应用程序开发的Scrum流程。团队根据他们的不同需求和对流程的不同理解以不同的方式实施流程，但主要的成功因素是团队（及其中的个人）的能力以及团队管理的能力。