敏捷是关于原则，而不是过程。

Question

我的硕士论文是关于如何应用敏捷。

很多企业都在销售敏捷 - 很多管理顾问都把自己的品牌卖得“最好”。

我不感兴趣XP，Scrum，Crystal Clear，Agile-CMMI，Six Sigma或任何其他品牌/变体是否最佳。我对真正的，活跃的开发人员（即你们）真正适用于敏捷感兴趣。

我所研究的是如何根据不同的组织要求定制敏捷。

通过对不同组织如何应用敏捷的研究，我制定了以下指南 - 应该在什么情况下应用敏捷变体的方法：

更大，更分散或更灵活的团队需要更严格的编码和测试标准，小团队可以（并且应该）使用更少的。
流程文档应该是最小的，实时的和最新的。
详细的统计控制指标是不必要的开销：不完整软件的早期发布是进步的更好指示。
理想情况下，开发人员应该与客户关系密切，没有专门的中间角色。只有当客户专注于阻止开发人员成为用户的方式时，才应使用其他角色。
迭代应该是灵活的，除非它有助于与其他部门或其他流程协调发布。
开发人员应该能够轻松，定期地进行沟通，但会议应该不常见（每月和每周，而不是每天）。
结对编程只应用于培训和研究任务。
这些指南只是一个起点：应该使用持续改进来进一步根据具体情况定制敏捷变体。

这些因素在应用于具有现有传统（即BDUF或waterfall）模型的组织时会发生变化，其中敏捷团队必须与使用非敏捷方法的团队共存或改编：

带有注销和结构化步骤的流程文档将帮助其他团队跟踪项目。
统计指标（如速度）可以帮助非敏捷团队确保流程得到控制。
固定迭代将有助于团队之间的协调。

这些附加指南将有助于敏捷与传统模型共存，但它们会带来额外的开销和限制。

我想知道的是你 - 编写软件的人，而不是敏捷的顾问 - 想到这个框架。

您认为准确的是什么？你觉得怎么了？你会改变什么？我错过了什么？

最重要的是：为什么？

我为此添加了一笔赏金，以提供额外的奖励来回答这个相当长的问题。赏金将归于SO社区获得最多选票的人 - 我意识到没有单一的正确答案，但我对最接近社群共识的内容感兴趣。

Answer 1

更大，更分散或更灵活的团队需要更严格的编码和测试标准，小团队可以（并且应该）使用更少的。

流程文档应该是最小的，实时的和最新的。

详细的统计控制指标是不必要的开销：不完整软件的早期发布是进步的更好指示。

理想情况下，开发人员应该与客户关系密切，没有专门的中间角色。只有在客户专注于阻止开发人员成为用户的方式时，才应使用其他角色。

迭代应该是灵活的，除非它有助于与其他部门或其他流程协调发布。

开发人员应该能够轻松，定期地进行沟通，但会议应该很少（每月和每周，而不是每天）。

结对编程应仅用于培训和研究任务。

这些指南仅是一个起点：应该使用持续改进来进一步根据具体情况定制敏捷变体。

编码/测试标准无论团队的规模和分布如何，都需要实施IMO。拥有编码/测试标准会带来更多可管理/稳定的代码。

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

虽然通过迭代过程让开发人员与客户关系得到改善，但您需要通过直接向开发人员添加/更改/范围蔓延来保护开发人员免受业务干扰。企业仍然需要通过积压整理/优先排序等来跟踪流程。

通过使用发布迭代和开发迭代，您可以维护适用于团队的灵活的迭代计划。目前，我们每3到4周进行1周冲刺迭代，发布冲刺。

会议的类型应决定会议的频率。每日站立时间需要每天进行。它们为团队提供了可靠性和透明度，这对于拥有一支成功的团队至关重要。回顾需要在每次迭代结束时发生，并且该频率由迭代的大小决定。其他会议，例如代码审查，演示，不应该按时，而是根据需要和完成情况来决定。

对编程永远不应该固定到特定类型。我们将我们的QA测试人员与我们的BA团队进行编程，以便双方更好地了解UAT和故事。我们还为知识共享，原型设计，研究任务等配对编程。在我们的环境中，编程已成为第二天性。

当您学习如何根据业务需求修改敏捷实践时，敏捷的持续改进将成为二手产品。只要你不偏离宣言，你的敏捷就应该成功。

Answer 2

最后两点我遇到了一个小问题。每日站立会议非常有益。它让我们可以回顾前一天我们的工作，以及我们打算在下一次会议（明天）之前继续工作的内容。值得注意的是，每日站立会议应该保持简短和重要。我们陷入了一种情况，有些人喜欢提出有关该项目的各种问题，所以我们决定不问任何问题，只有生产力声明。如果有问题，请与负责该组件的人员安排进一步的会议。

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

Answer 3

作为博士论文的一部分，您还应该考虑如何在遍布全球各地的团队中使用敏捷。所以，如果你在东海岸有一个产品团队，在印度和俄罗斯有开发团队，在新加坡有QA团队等等。这对我来说是一个完全不同的球类游戏，需要完全不同的模式。

例如，一些模式是：

根据时区，将世界某一地区的早起者与另一部分的晚期起居者配对，反之亦然。这不是完全对编程，但你可以称之为你想要的任何模式。
强调必须使代码尽可能可读，而不是可写。这意味着我们可能必须强调统一的设计模式和流畅的命名。
以这样的方式创建团队，让您拥有其中一个和我们中的一个。这意味着你将Russsian开发人员与印度开发人员配对，他们就模块一起工作。

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

希望这个新角度能够以某种方式帮助你。

Answer 4

哦，伙计。祝你好运。

我喜欢你的方法，尤其是从我们那里得到的咕噜声，而不是金表的亮点。

我想说任何这种方法都需要适应具体情况。没有人应该只做，因为有人说他们应该这样做。对于自己的思考应始终站在最前沿，恕我直言。

自从我与斯隆学校的MBA学位合作以来已经有一段时间了，但我清楚地意识到他们被教导程序员要“管理”，而不是“培养”。我们是一种不愉快的商品，而不是完整的团队成员。我希望你有比这更好的经历。

Answer 5

一个崇高的事业，祝你好运。以上所有优点也是如此。我只想补充一下：

敏捷是关于原则，而不是过程。

请参阅Agile Manifesto。

改变公司行为是目标，而不是改变一个经过验证的过程“与一个破碎的组织合作”，因此强调每个实践背后的原则。然后不要改变做法。如果原则不适用，则放弃反映原则的实践。改变做法会破坏原则并使其目的失效。这种“适应”的最终结果很可能是同样已经被使用的有缺陷的过程，现在包含在敏捷术语中，但缺乏使其有效的原则。

流程文档是抗敏捷

"Process documentation with sign off and structured steps 
 will help other teams track the project"

我不得不对此说一个大胖子。 文档将把敏捷带出流程（更不用说开发人员的生命和精力）。如果您想帮助其他团队跟踪项目，请在Intranet上发布迭代计划和速度。请不要浪费开发人员的时间 - 以及客户的资金 - 编写流程文档，特别是对于其他非利益相关者并且没有风险的人所谓的利益。

当然，如果没有至少一个Dilbert参考，没有MBA候选人可以逃脱程序员线程：
_{（来源：dilbert.com）}

Answer 6

“流程文档应该是最小的，实时的和最新的。”

“最小”是什么意思？它是指页数或覆盖意义上的总和（v.gr. standards doc，configuration management manual，design doc）。

当你假设一个团队中没有营业额的项目时 - 在长项目中这不是一个合理的假设，你需要一个有效的知识转移机制，而知识转移最有效的机制就是文档。

我已经看到了文档保持最小化（从页数意义上讲）的项目，因为开发文档太麻烦了。但是，如果您可以重复使用从一个项目到另一个项目的文档而无需更改或进行最小的更改（这对于编程标准，配置管理手册等文档来说是合理的），则不会产生文档开发负担。

流程文档应涵盖所有软件开发过程，否则您将面临以不一致的方式执行的流程的风险。敏捷团队拥有敏捷的软件流程。通过软件开发流程，我指的是管理代码，控制版本，控制评论，检查代码，修复错误等的清晰机制。

Answer 7

更大，更分散或更灵活的团队需要更严格的编码和测试标准，小团队可以（并且应该）使用更少的。

无论团队规模如何，都应该存在编码和测试标准。它们提高了代码的可维护性，并使新资源更容易上手。

流程文档应该是最小的，实时的和最新的。

同意。

详细的统计控制指标是不必要的开销：不完整软件的早期发布是进步的更好指示。

软件开发的统计控制指标并不多，这些指标始终具有价值。我会寻找时间和预算的差异，测试和生产中的缺陷率，以及估计的方差。

理想情况下，开发人员应该与客户关系密切，没有专门的中间角色。只有当客户专注于阻止开发人员成为用户的方式时，才应使用其他角色。

所以经常这是不切实际或不可能的。客户在自己的工作中有很多工作要做，以至于他们很少有时间与开发人员进行过多的交流。业务分析师具备整合业务问题所需的技能，并能更有效地获得明确的答案。如果您的发布周期足够短，客户将有充分的反馈机会。

迭代应该是灵活的，除非它有助于与其他部门或其他流程协调发布。

应该有一些灵活性，但并不多。敏捷方法的一个好处是它迫使团队将范围限制在最有价值的要求。增加迭代时序的灵活性会增加范围蔓延的风险。

开发人员应该能够轻松，定期地进行沟通，但会议应该不常见（每月和每周，而不是每天）。

每日会议对大型团队有效。他们使人们保持正轨并增加协作。它们有助于防止团队成员在没有寻求帮助的情况下陷入困境。它们还有助于保持对迭代的控制，考虑到缺少其他可用控件，这非常有用。

结对编程只应用于培训和研究任务。

我对这个问题没什么好说的。

这些指南仅是一个起点：应该使用持续改进来进一步根据具体情况定制敏捷变体。**

EXACTLY！敏捷旨在满足组织的需求。不断调整对于完善这一过程至关重要。

祝你好运。

Answer 8

更大，更分散或更灵活的团队需要更严格的编码和测试标准，小团队可以（并且应该）使用更少的。

无论团队规模如何，持续测试都是非常宝贵的。应根据项目成熟度和组件关键性进行测试的数量应有所不同。

对于新产品，定期演示非常适合士气，并且足以为管理层带来进步感。

对于成熟和运输产品，对主要功能的最低定期验收测试将跟踪产品是否准备好发布。

对于主要系统接口，单元测试是说明性的，有助于避免意外。在使用签约子项目时，单元测试比文档更好，对于避免指责延迟至关重要。

测试优先开发是重型代码的有价值的实验。如果您最有价值的资产是您的技术，那么它应该经过彻底的测试。

详细的统计控制指标是不必要的开销：不完整软件的早期发布是进步的更好指示。

统计控制指标对于早期识别项目超限至关重要，但它们最好永久地留在“敏捷教练”或“Scrum Master”手中，或者直到整个团队在准确计算进度和延迟。

如果有效应用，敏捷开发实践应该产生足够小的故事和任务，以便在数小时到数天内完成。有效管理“计划游戏”和导致个别任务超支的反馈可以最大限度地减少估算和收集进度数据的开销。

最后，客户（和/或管理）决策的历史记录以及对这些决策实际花费时间（天）的会计将导致改进工程和业务流程的方法。阻碍发展和花费时间的“泳道”或“甘特图”将显示“但我们敏捷”并不是轻率商业决策的借口。

理想情况下，开发人员应该与客户关系密切，没有专门的中间角色。只有当客户专注于阻止开发人员成为用户的方式时，才应使用其他角色。

一次我同意！单独的开发和管理会议可以很好地解决问题。

迭代应该是灵活的，除非它有助于与其他部门或其他流程协调发布。

敏捷迭代是建立持续可释放产品的宝贵发展节奏。迭代的结束是当可以实现特征决策并且可以进行源控制更改以分支不会成为目标的特征。

但是，当迭代不能满足业务需求时，团队可能难以实施这种做法。应根据演示和促销等业务需求安排迭代。

开发人员应该能够轻松，定期地进行沟通，但会议应该不常见（每月和每周，而不是每天）。

周一/周四的站立会议是个好主意。然而，它需要15-30分钟的硬帽。根据需要拆分会议以减少时间。分开关注以避免浪费开发人员时间。

办公室的狗可以帮助人们在会议期间保持专注。一些树皮比点头或发短信的人要好。

结对编程只应用于培训和研究任务。

结对编程，单元测试，无情重构和测试驱动实践是团队采用的最难的敏捷技能。结对编程的好处是提高意识和知识，防止在错误的决策和假设可以延续和级联的情况下孤立地完成工作。

如何使敏捷适应不同的公司？ MBA论文

9 个答案:

敏捷是关于原则，而不是过程。

流程文档是抗敏捷