问如何使敏捷适应不同的公司？工商管理硕士论文

EN

• 更大、更分布式或更灵活的团队需要更严格的编码和测试标准，小型团队可以(而且应该)使用更少的代码和测试标准。
• 过程文档应该是最小的，实时的和最新的.
• 详细的统计控制指标是不必要的开销:早期发布不完整的软件可以更好地显示进展情况。
• 理想情况下，开发人员应该与客户关系密切，没有专门的中间角色。只有在客户专业化的情况下才应该使用额外的角色，这样才能阻止开发人员也成为用户。
• 迭代应该是灵活的，除非它有利于与其他部门或其他流程的版本协调。
• 开发人员应该能够轻松和定期地交流，但是会议应该是不频繁的(每月和每周，而不是每天)。
• 成对编程只用于培训和调查任务。
• 这些准则只是一个起点:应该使用持续改进来进一步调整敏捷变体以适应具体的情况。

无论团队的规模和分布如何，海事组织都需要执行编码/测试标准。有了编码/测试标准，就会产生更可管理/更稳定的代码。

我同意文件。通过使用一些清洁代码实践，如有意义的注释和意图，在您的代码中揭示命名约定，然后您将消除对代码本身的文档化的一些需求。文档应该是业务级别的，我更喜欢采用验收测试的形式。

虽然开发人员与客户关系密切，但随着迭代过程的进行，您需要通过直接向开发人员进行添加/更改/范围扩展来保护开发人员免受业务循环的影响。业务仍然需要通过待办事项整理/优先排序等过程来跟踪这个过程。

通过使用发布迭代和开发迭代，您可以维护对团队工作的迭代的灵活日程安排。目前，我们的工作是每3到4周发布一次短跑迭代，为期1周。

会议的类型应规定会议的频率。每天的停顿需要每天。他们提供问责和透明的团队，这是至关重要的一个成功的团队。回顾需要在每次迭代结束时发生，并且这种频率取决于迭代的大小。其他会议，如代码评审，演示不应被指定的时间，而是关于需求和完成。

对编程不应该被固定到特定的类型。我们与QA测试人员和BA团队进行配对编程，以便双方对UAT和故事有更好的理解。我们还为知识共享、原型开发、调查任务等做了配对编程。在我们的环境中，成对编程已经成为第二天性。

随着您学习修改敏捷的实践以满足您的业务需求，敏捷中的持续改进将成为被动的天性。只要你不偏离宣言，你的敏捷应该是成功的。

最后两点我有点小问题。每天的站立会议是非常有益的。它让我们回顾一下我们前一天所做的工作，以及我们打算在下一次会议(明天)之前进行的工作。重要的是要注意，每天的会议应该保持简短和切中要害。我们陷入了这样一种情况:有些人喜欢提出关于这个项目的各种问题，所以我们决定不问任何问题，只问生产力方面的问题。如果有问题，将与负责该部分的人员举行进一步的会议。

此外，配对编程不应仅用于培训和调查任务。对编程有许多好处，例如知识共享/转移和代码所有权。在一个问题上有两种想法可以提出许多有趣的观点，并有助于隔离潜在的设计缺陷。在我看来，结对编程被低估了，而且大多数自私的程序员不喜欢对编程。这是对项目和团队的好处，而不是对自己的好处。好的软件是由协作团队编写的，而不是一个书呆子。

作为PhD论文的一部分，您还应该考虑敏捷是如何在放置在全球不同部分的团队之间使用的。所以，如果你在东海岸有一个产品团队，在印度和俄罗斯有开发团队，在新加坡有QA团队等等。对我来说，这是一场完全不同的球赛，需要完全不同的模式。

例如，其中一些模式是：

1. 根据时区的不同，把世界上一个地方的早起者和另一个地方的深夜者配对，反之亦然。这并不完全是对编程，但您可以将其称为任意模式。
2. 重点必须是使代码尽可能可读性，而不是可写性。这意味着，我们可能必须强调统一的设计模式和流畅的喜欢命名。
3. 以这样的方式创建团队，让你拥有他们中的一个和我们中的一个。这意味着，您将俄罗斯开发人员与印度开发人员配对，他们一起工作在一个模块上。

随着时间的推移，发明自己的模式，使敏捷工作变得非常有趣，需要很大的耐心和努力。

希望这个新的角度能在某种程度上帮助你。