Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability [...].
We practice an agile approach where I work, where the architecture team works in a pretty non-specified agile way and the feature teams use Scrum. By non-specified I mean that there are no strict rules as to how the process is but we use several agile principles. Most importantly development is not done the waterfall way, but iteratively.
Throughout the core software development department we use continuous integration and a lot of automated testing. Daily stand-ups are by definition a practice used by the feature teams, but also sometimes for the platform team, depending on the situation. The platform team has an open weekly presentation of what they did. Also, user stories are not only used for the feature teams, but also sometimes for the platform team, when responsibilities overlap and a product requirement turns out to be a more general platform requirement.
So, yes, I think agile is possible for platform teams, as long as the circumstances (i.e. management and/or product requirements) allow it. What you use and how you use it is up to you.
Agile can work in platform development for the same reasons that it can work in application development, and it can fail in both cases for the same fundamental reasons.
Agile processes, by definition, adapt to their environment. Usually it is the people using the process who adapt it, in order that it remains fit for the purpose of the task that is is being applied to. This adaptability makes agile processes inherently robust, provided that process adaptability can be tolerated in the work environment.
In platform development the release schedules are often further apart and more stable than they are in application development. At first sight, this means that delivering increments of functionality is less useful, and does not provide the same feedback loop as you would get by delivering a usable increment of functionality to a customer. On closer inspection, this is only true if nobody is waiting for the functionality that is being produced, or if it is only the complete deliverable that is of any value.
On the one hand the environment is more conducive to success; on the other hand one of the essential mechanisms for an agile process is missing. As long as the process can be adapted to compensate for the missing mechanism - e.g. by having testers or application developers use the interim deliverables - then the adapted process should still be fit for purpose.
In terms of software design and construction, the software (including specifications) is written in more-or-less the same way: one line at a time, and by more-or-less the same sort of people: software developers; with more-or less the same characteristics in terms of motivation and attention span. The scope of the new functionality might be larger, and the goal defined with a longer term schedule, but it still has to be reached in steps, and those steps can be defined to fit into iterations with some sort of demonstration of progress at the end. Development managers often think in terms of milestones as well as deliverables, so this might only be an evolution from the current practice.
I have seen the Scrum process used by different teams for both platform and application development. The teams implement the process in different ways according to their different needs and different understandings of the process, however the main success factors are the capabilities of the teams (and the individuals within them) and the capabilities of the teams' management.
发布评论
评论（2）
我认为这取决于你如何定义敏捷。敏捷是一系列方法论和实践的总称。
在 Wikipedia 中，它的定义如下：
我们在我工作的地方实践了一种敏捷方法，架构团队以一种相当非指定的敏捷方式工作，而功能团队则使用 Scrum。我所说的“非指定”是指对于流程如何进行没有严格的规则，但我们使用了一些敏捷原则。最重要的是，开发不是瀑布式的，而是迭代式的。
在整个核心软件开发部门，我们使用持续集成和大量自动化测试。根据定义，每日站立会议是功能团队使用的一种做法，但有时也适用于平台团队，具体取决于具体情况。平台团队每周公开展示他们所做的事情。此外，用户故事不仅用于功能团队，有时也用于平台团队，当职责重叠并且产品需求变成更通用的平台需求时。
所以，是的，我认为敏捷对于平台团队来说是可能的，只要环境（即管理和/或产品要求）允许。您使用什么以及如何使用它取决于您。
I think it depends on how you define agile. Agile is an umbrella term for a bunch of methodologies and practices.
In Wikipedia it is defined as such:
We practice an agile approach where I work, where the architecture team works in a pretty non-specified agile way and the feature teams use Scrum. By non-specified I mean that there are no strict rules as to how the process is but we use several agile principles. Most importantly development is not done the waterfall way, but iteratively.
Throughout the core software development department we use continuous integration and a lot of automated testing. Daily stand-ups are by definition a practice used by the feature teams, but also sometimes for the platform team, depending on the situation. The platform team has an open weekly presentation of what they did. Also, user stories are not only used for the feature teams, but also sometimes for the platform team, when responsibilities overlap and a product requirement turns out to be a more general platform requirement.
So, yes, I think agile is possible for platform teams, as long as the circumstances (i.e. management and/or product requirements) allow it. What you use and how you use it is up to you.
敏捷可以在平台开发中发挥作用，其原因与它在应用程序开发中的作用相同，但由于相同的根本原因，它在这两种情况下都可能失败。
根据定义，敏捷流程适应其环境。通常是使用该流程的人对其进行调整，以便它仍然适合所应用的任务的目的。如果工作环境能够容忍流程适应性，那么这种适应性使得敏捷流程本质上是稳健的。
在平台开发中，发布时间表通常比在应用程序开发中间隔更远且更稳定。乍一看，这意味着提供功能增量的用处不大，并且无法提供与向客户提供可用的功能增量所获得的相同的反馈循环。经过仔细检查，只有当没有人等待正在生成的功能，或者只是具有任何价值的完整可交付成果时，这才是正确的。
一方面环境更有利于成功；另一方面，敏捷流程的一个基本机制缺失。只要可以调整流程来弥补缺失的机制（例如，通过让测试人员或应用程序开发人员使用临时可交付成果），那么调整后的流程仍应适合目的。
在软件设计和构建方面，软件（包括规范）的编写方式或多或少相同：一次一行，并且由或多或少相同类型的人编写：软件开发人员；在动机和注意力广度方面具有或多或少相同的特征。新功能的范围可能更大，并且用更长期的时间表定义目标，但仍然必须分步骤实现，并且可以定义这些步骤以适应迭代，并在最后进行某种进度演示。开发经理通常会考虑里程碑和可交付成果，因此这可能只是当前实践的演变。
我见过不同团队在平台和应用程序开发中使用 Scrum 流程。团队根据不同的需求和对流程的不同理解，以不同的方式实施流程，但主要的成功因素是团队（以及团队中的个人）的能力和团队管理的能力。
Agile can work in platform development for the same reasons that it can work in application development, and it can fail in both cases for the same fundamental reasons.
Agile processes, by definition, adapt to their environment. Usually it is the people using the process who adapt it, in order that it remains fit for the purpose of the task that is is being applied to. This adaptability makes agile processes inherently robust, provided that process adaptability can be tolerated in the work environment.
In platform development the release schedules are often further apart and more stable than they are in application development. At first sight, this means that delivering increments of functionality is less useful, and does not provide the same feedback loop as you would get by delivering a usable increment of functionality to a customer. On closer inspection, this is only true if nobody is waiting for the functionality that is being produced, or if it is only the complete deliverable that is of any value.
On the one hand the environment is more conducive to success; on the other hand one of the essential mechanisms for an agile process is missing. As long as the process can be adapted to compensate for the missing mechanism - e.g. by having testers or application developers use the interim deliverables - then the adapted process should still be fit for purpose.
In terms of software design and construction, the software (including specifications) is written in more-or-less the same way: one line at a time, and by more-or-less the same sort of people: software developers; with more-or less the same characteristics in terms of motivation and attention span. The scope of the new functionality might be larger, and the goal defined with a longer term schedule, but it still has to be reached in steps, and those steps can be defined to fit into iterations with some sort of demonstration of progress at the end. Development managers often think in terms of milestones as well as deliverables, so this might only be an evolution from the current practice.
I have seen the Scrum process used by different teams for both platform and application development. The teams implement the process in different ways according to their different needs and different understandings of the process, however the main success factors are the capabilities of the teams (and the individuals within them) and the capabilities of the teams' management.