【问题标题】：How to adapt agile to different companies? An MBA thesis [closed]如何让敏捷适应不同的公司？ MBA论文[关闭]
【发布时间】：2009-05-15 15:21:40
【问题描述】：

我的硕士论文是研究如何应用敏捷。

有大量的企业推销敏捷——许多管理顾问将他们的品牌推销为“最佳”。

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

我研究的是如何根据不同的组织要求调整敏捷。

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

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

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

带有签字和结构化步骤的流程文档将帮助其他团队跟踪项目。
统计指标（如速度）可以帮助非敏捷团队放心，流程在可控范围内。
固定迭代将有助于团队之间的协调。

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

我想知道的是您（编写软件的人，而不是敏捷顾问）对这个框架的看法。

你认为什么是准确的？你觉得哪里不对？你会改变什么？我错过了什么？

最重要的是：为什么？

我为此添加了赏金，以提供额外的动力来回答一个相当长的问题。赏金将颁发给从 SO 社区获得最多选票的人 - 我意识到没有唯一的正确答案，但我对最接近社区共识的内容感兴趣。

【问题讨论】：

我不得不承认我不确定这里关于作业问题的礼仪。尽管硕士论文比周一的作业更有价值，但我仍然在这里看到了关系。那个，以及这是一个调查问题的事实困扰着我。不足以投票结束，但如果有人有链接可以帮助我将来做出这些决定，我想知道。也许没有作业或硕士论文，但博士论文可能没问题。
这不是一个调查问题 - 它太开放了。这实际上是从我的结论中得出的——研究（基于学术和社区资源）是完整的，这个模型就是结果。我正在寻找的是社区反馈，以便批判性地反思我的模型。我认为同行反馈比我自己对自己结论的分析更有价值。
stackoverflow.com/faq 的第二部分：“避免提出主观、争论或需要扩展讨论的问题。这不是一个讨论区，这是一个可以回答问题的地方！”。 “寻找社区反馈”听起来很像“扩展讨论”。你已经为我澄清了，我投票以“不是一个真正的问题”结束，因为这不是一个“可以回答的问题”。
@John - 很公平，无论如何感谢您的反馈。我认为这样的开放性问题在 SO 上有一个位置。这里没有一个明确的答案，但所有的回答都有可能为（毕竟）与编程相关的问题增加价值。
@John - 我同意基思的观点。我还认为 Jeff A. 最终会同意我们社区最终拥有并决定什么是最好的。我发现这样的问题/讨论非常有价值。

标签： project-management agile

【解决方案1】：

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

流程文档应该是最少的、实时的和最新的。

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

理想情况下，开发人员应该靠近客户，没有专门的中间角色。仅当客户的专业化方式阻止开发人员同时成为用户时，才应使用其他角色。

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

开发人员应该能够轻松且定期地进行交流，但会议应该不频繁（每月和每周，而不是每天）。

结对编程只能用于培训和调查任务。

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

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

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

虽然让开发人员接近客户可以通过迭代过程得到改进，但您需要通过直接与开发人员联系以进行添加/更改/范围蔓延来保护开发人员免受绕过流程的业务的影响。业务仍然需要通过积压梳理/优先级等来遵循流程。

通过将发布迭代与开发迭代结合使用，您可以保持适合团队的灵活迭代计划。目前，我们进行 1 周的 sprint 迭代，每 3 到 4 周进行一次发布 sprint。

会议的类型应决定会议的频率。每日站立会议需要每天进行。他们为团队提供问责制和透明度，这对于拥有一个成功的团队至关重要。回顾需要在每次迭代结束时进行，并且频率取决于迭代的大小。其他会议（例如代码审查、演示）永远不应按时进行，而应根据需要和完成来决定。

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

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

【讨论】：

感谢 David 的反馈 - 我特别喜欢您关于防止功能蠕变和与 QA 等进行结对编程的观点。你估计有多少时间花在结对编程上？我同意编码标准，但是，在一个定期重构的小团队中，让这些标准在提交前强制执行真的值得吗？我的观点（可以更清楚地说明）是编码标准应该更少强制执行。
我自己我会说我大约 30% 的时间都在结对编程上担任技术主管。我有 2 个在我的团队中工作，花费大约 50 - 60% 的配对，所以这真的取决于具体情况。至于编码标准，我们如何处理它们更多地遵循指南。我们没有在预提交或构建中验证的任何措施/阈值。
我们在环境中使用指南/标准更多地是为了保持一致性/可读性/可管理性。我在代码中寻找的是遵循良好的干净代码实践，例如有意义的 cmets、意图揭示命名约定、正确的错误捕获/处理、尝试遵循 SRP。我同意小团队中的严格标准可能会在一定程度上造成阻碍，但我也认为无论团队规模/环境如何，都需要一些指南或标准来建立代码。
QA 和测试策略应该与系统的关键性相结合。更小、更不重要的系统，您不需要像严格和正式的测试计划。这并不意味着编写更难管理的代码。 QA 过程经常会造成不必要的瓶颈。一切都应该取决于产品和项目的类型......不是一成不变的。
如果有多个产品在使用，敏捷真的很糟糕。当一个“scrum”团队在一个产品上工作时，它的效果最好……即使它是在那个产品中的不同部分/项目上。 Scrum 意味着每个人都在朝着同一个方向努力，但是，当每个人都在做自己的事情时，这很难做到。

【解决方案2】：

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

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

【讨论】：

感谢您的反馈 - 我知道这些都是很有争议的观点。它们是 Scrum（每日站会）和 XP（结对编程）的关键特征。我根据现实世界的应用程序做出了这些断言：很少有组织广泛使用结对编程，微软和谷歌使用它的时间都不超过 5%（谷歌的信息来自 Yegge 在 SO 播客上的采访）。我真的会对一些现实世界中广泛使用结对编程（XP 之外）的引用非常感兴趣，这与为什么结对编程适用于他们而不是其他公司。
每日站立会议已被证明对某些公司非常有用，例如 Microsoft。在其他公司（如 37signals 和谷歌），他们被发现浪费了太多时间来获得潜在收益。我已将它们在我的论文中的使用与与其他团队和非敏捷部门的协调联系起来。
我不质疑结对编程和每日站立会议是否有效。我的研究目标是确定什么时候应该使用它们，什么时候不应该使用。
根据我的经验，我们使用结对编程在架构组件之间共享知识。一周广泛地在 UI 上工作，下周在后端工作是很常见的。每个组件都有一个首席开发人员，但他们也轮流到其他组件，以共享知识。程序员是人，可以缺勤，必须有人填补这一空白。结对编程是小型企业团队的绝佳资源。我喜欢学习各个方面，它有助于改善我的弱点（比如 UI）。
感谢您的澄清，我想我的问题实际上是：在您的组织中，结对编程在其他地方不起作用时，有什么不同之处可以为您工作？当您执行平凡的任务时，您仍然发现结对编程有效吗？

【解决方案3】：

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

例如，一些模式是：

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

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

希望这个新角度对您有所帮助。

【讨论】：

谢谢，这是进一步研究的有趣途径。

【解决方案4】：

哦，孩子。祝你好运。

我喜欢你的方法，尤其是从我们的咕噜声而不是金表幻灯片集那里获得输入。

我想说，任何此类方法都需要适应特定情况。没有人应该只做某事，因为别人说他们应该这样做。恕我直言，为自己着想应该始终处于最前沿。

我与斯隆商学院的 MBA 合作已经有一段时间了，但我清楚地感觉到，他们被教导要“管理”而不是“培养”程序员。我们是一种令人不快的商品，而不是完整的团队成员。我希望你有比这更好的体验。

【讨论】：

我同意你的观点（参见我的基本管理理论is.gd/AdID）——我认为敏捷始终是一个自下而上的演变过程。我的研究问题是你应该从什么开始？我的意思是 - 我的团队花了大约 4 年的时间从最初的 Scrum 模型发展到我们现在拥有的高度定制的模型，而且我不认为我们提出的变体是一刀切的。跨度>

【解决方案5】：

当软件可以在共享硬件环境中部署到生产环境时，我们在一家拥有高度集成的软件和预先确定的窗口的大公司中实践敏捷。

我们开发了一套由 SCRUM（项目管理）实践和 XP（工程）实践组成的敏捷实践。我们部署的许多系统都使用了传统的瀑布流程

关于你的框架我会一一回复：

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

如果您所说的编码和测试标准是指工程实践 (XP)，例如持续集成、结对编程、测试驱动开发、自动化功能和性能测试等。无论团队或项目的规模如何，我们都采用相同的实践.因此，我们经常发布在用户验收测试期间发现的零缺陷的软件。发布具有延展性的高质量软件（低缺陷）以实现可持续发展的持续发展推动了对工程实践的需求，而不是组织的规模。

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

如果您所说的流程文档是指敏捷流程文档，那么我们的所有内容都一目了然。我们展示了宣言，映射到 12 条原则，最后是我们员工的 21 项实践。它们贴在墙上并且非常醒目，这一事实使团队能够理解它们，更重要的是实际将它们付诸实践。

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

传统工作工件的完成百分比几乎没有价值。每两周向我们的产品所有者/业务合作伙伴演示工作软件是进度的最佳指标。跟踪实际速度（完成的故事卡单元）和缺陷率并在大的可见图表上显示数据非常有用。在向团队介绍某些实践时，显示进度很有用。比如学习TDD时在代码之前写的单元测试的数量。

“理想情况下，开发人员应该靠近客户，没有专门的中间角色。只有当客户的专业化方式使开发人员无法同时成为用户时，才应使用其他角色。”

如果可能，用户应在开放的工作区中与团队合作。如果用户不可能与团队在一起，那么用户代理是下一个最好的上线人。没有人能提供比实际使用该软件完成工作的人更好的反馈。

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

更重要的是，发布日期应该在团队之间保持一致。如果持续时间保持一致（我们每 2 周使用一次），迭代是最好的。一致的迭代长度与时间盒和用于提交到下一次迭代的故事卡的速度计算一致。

“开发人员应该能够轻松且定期地进行交流，但会议应该不频繁（每月和每周，而不是每天）。”

团队应参加每日站立会议，以及每次迭代的迭代计划会议、展示和说明会议、计划扑克会议和回顾会议。每次发布，团队都会参加发布计划会议。鉴于用户/业务合作伙伴与该线路一起工作，每天都可以就正在完成的工作进行对话。

“结对编程只能用于培训和调查任务。”

使用结对编程的第一个原因是消除缺陷。我写了一些关于结对编程的回复。总而言之，配对不太可能被阻止，不太可能参加电子邮件或网络假期，提供转移业务领域、应用程序领域和工程实践技能的机制，消除知识孤岛（大型组织中的关键）等。

“这些指南只是一个起点：应该使用持续改进来进一步根据具体情况调整敏捷变体。”

回顾，计划每次迭代或发生需要回顾的事件时，零缺陷的心态推动持续改进。员工 XP 工程实践使团队能够保持代码健康，从而可以无限期地轻松添加新功能。我们将瀑布项目的可交付成果视为约束。为了管理这些限制，我们要求这些团队提前做好工作，并使用模拟等工程技术来测试将与这些可交付成果集成的故事卡。

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

我们拥有生活在瀑布世界中的敏捷团队。我们邀请瀑布项目参加我们的发布和迭代计划会议（和回顾）。我们已经取得并将继续取得的成功继续为公司内的敏捷实践带来新的转变。

“带有签字和结构化步骤的流程文档将帮助其他团队跟踪项目。”

不同意。故事卡片墙、迭代计划和发布计划都是团队内部或团队外部人员所需要的。

“统计指标（如速度）可以帮助非敏捷团队放心，流程在可控范围内。”

同意。敏捷团队将使速度和缺陷率可见。预算将在 1% 或 2% 之内，并且发布将按计划进行，因为它们是有时间限制的。

“固定迭代将有助于团队之间的协调。”

在高度集成的大型环境中需要。还可以帮助团队根据速度制定迭代和发布计划。

【讨论】：

感谢凸轮的详细回复。该指南针对的是组织，而不是单个团队（我需要更清楚地说明），因此对于您的情况（即多个团队），我认为我们同意编码标准。我的观点是，如果你有一家小公司（例如初创公司），你可以对他们不那么严格。
我们是一家大公司。我们已经将敏捷从 3 年前的 0 个团队发展到目前的大约 20 个团队。无论规模大小，敏捷团队都不能失去的一件事是自我指导团队。领导层设定明确的目标，然后相信团队最了解如何完成工作。如果领导层正式签署，就会违反信任并减慢速度。请记住，自动化测试会强制执行要求。没有流程文档可以做得更好。 Stage Gates（正式签核），如在瀑布中使用的那样，会导致阻止程序而不是交付工作软件。

【解决方案6】：

崇高的事业，祝你好运。以上所有优点。我只会补充：

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

请参阅Agile Manifesto。

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

流程文档是反敏捷的

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

我不得不对此说一个大大的不。 文档将使敏捷脱离流程（更不用说开发人员的生命和精力了）。如果您想帮助其他团队跟踪项目，请在内网上发布迭代计划和速度。请不要浪费开发人员的时间和客户的金钱来编写流程文档，尤其是为了非利益相关者且没有风险的其他人的所谓利益。

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

【讨论】：

感谢第一点 - 我完全同意。这些指南的重点是在新情况下应用敏捷；如果你已经有一些有用的东西，这些都是无关紧要的。关于第二点，我有点同意你的看法，但我的敏捷经验全都在我自己的团队中——在许多公司中，其他团队的开发人员都是利益相关者。例如，您可能有一个 BDUF 团队生产大型服务器，而敏捷团队生产一个 Web UI。
我在我的研究中引用了宣言 - 问题是虽然各种品牌的作者都是签署者（例如 XP 的 Beck、Scrum 的 Schwaber、ASD 的 Highsmith 和 Crystal 的 Cockburn），但他们所有人都不同意实际做法。例如，与 XP 相比，Scrum 拥有相对大量的流程文档，但两者都声称是一刀切。
@[Keith]：Scrum 是一种流程管理方法，而不是一种开发方法。 Scrum 有点假设 XP 也被使用。如有疑问，请返回源头——贝克。
@[Keith]：根据您的示例，BDUF 团队是该场景中的客户（但不是唯一的客户），因此他们应该参与功能讨论和规划游戏。他们不公正地打破流程来满足文档迷恋;-)
@Steven A. Lowe - 有趣的点。我认为 XP 和 Scrum 之间的区别（即与整体敏捷的不同部分有关）是一种相对较新的适应。 Scrum 起源于制造业（在 Takeuchi 和 Nonaka 1986 年的一篇论文中），并与 XP 分开发展（至少一开始是这样）。作为利益相关者，我对 BDUF 的看法是（因为他们正在编写规范文档）他们不太可能对原型或不完整的功能感到满意，以此作为进展的标志。我并不是建议打破敏捷原则，只是使用更“重量级”的变体。

【解决方案7】：

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

“最小”是什么意思？是从总页数的意义上说还是从覆盖率的意义上说（v.gr.标准文档，配置管理手册，设计文档）。

当您假设团队中没有人员流动的项目时 - 在长期项目中这不是一个合理的假设，您需要一种有效的知识转移机制，而最有效的知识转移机制是文档。

我见过一些项目文档保持最少（在页数的意义上），因为开发文档太麻烦了。但是，如果您可以将文档从一个项目重用于另一个项目，而无需更改或更改很少（这对于编程标准、配置管理手册等文档是合理的），则没有文档开发负担。

流程文档应涵盖所有软件开发流程，否则您将面临流程中的步骤以不一致的方式执行的风险。敏捷团队拥有敏捷的软件流程。我所说的软件开发流程是指管理代码、控制版本、控制审查、签入代码、修复错误等的明确机制。

【讨论】：

我想我可以在那里做得更清楚 - 我描述的不止一件事：我看到的用户故事基本上是 10 页的规范文档和敏捷流程，每一步都有签署表格.我建议保留这两个方面 - 用户故事应该是一两段，并且似乎不需要大量流程文档。我想对这个过程的描述也有点过分——毫无疑问对新手很有用，但我认为做事优先。例如 StyleCop 会检查提交的代码，而不是纸上的编码风格指南。
是的，有些项目的流程文档过多。这取决于所描述内容的复杂性。具有大量规则的复杂流程需要长文档。您是否曾经尝试过描述如何计算制造厂的工资单？（太可怕了！）

【解决方案8】：

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

无论团队规模如何，持续测试都是非常宝贵的。应该改变的是基于项目成熟度和组件重要性的测试量。

对于新产品而言，定期演示非常有助于提高士气，并足以让管理层感受到进步。

对于成熟和交付的产品，主要功能的定期验收测试将跟踪产品的发布准备情况。

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

测试优先的开发对于繁重的代码片段来说是一个有价值的实验。如果您最宝贵的资产是您的技术，那么应该对它进行彻底的测试。

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

统计控制指标对于及早发现项目超限至关重要，但最好将它们永久留给“敏捷教练”或“Scrum Master”，或者直到整个团队纪律严明，准确地记录进度和延迟。

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

最后，客户（和/或管理层）决策的历史记录以及对这些决策的实际反应所花费的时间（天数）的核算将引导改进工程和业务流程。一张“泳道”或“甘特图”表示受阻的开发和所花费的时间将显示“但我们很敏捷”如何不是草率业务决策的借口。

理想情况下，开发人员应该靠近客户，没有专门的中间角色。仅当客户的专业化方式使开发人员无法同时成为用户时，才应使用其他角色。

这一次我同意！单独的开发和管理会议可以很好地分离关注点。

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

敏捷迭代是建立可连续发布产品的宝贵开发节奏。迭代的结束是可以实施功能决策并且可以进行源代码控制更改以分支不会成为目标的功能。

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

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

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

办公犬可以帮助人们在会议期间保持专注。几声吠叫总比打瞌睡或发短信要好。

结对编程只能用于培训和调查任务。

结对编程、单元测试、无情的重构和测试驱动的实践是团队最难采用的一些敏捷技能。结对编程的好处是提高意识和知识，并防止工作孤立地进行，错误的决策和假设可能会持续存在和级联。

【讨论】：

我想我需要更清楚地说明我的第一点——在一个大型团队或许多小型团队中，您可能拥有 FxCop、StyleCop、95% 的代码覆盖率和强制性代码审查，所有这些都在任何代码之前做出承诺。在一个小型团队中，您可能会拥有风格指南、80% 的代码覆盖率和更复杂功能的代码审查，所有这些都在方便时完成 - 通常在提交代码之后。
在天真的敏捷项目中我可以同意这一点。我认为目标是减少小错误对大量提交者的树开发头部的影响，以便它们不会级联成大错误。较大的项目和团队应在可行时尝试将开发拆分为子项目。为时已晚进行这种过渡是非常昂贵的。 1/2
小型团队/不成熟的项目可能会说“不要破坏构建”，而中型团队/已部署的项目可能会说“不要破坏已建立的测试”——当然有充分的理由违反两者暂时规定。与风险度量无关的代码/分支覆盖度量对其成本没有好处。 2/2

【解决方案9】：

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

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

流程文档应该是最少的、实时的和最新的。

同意。

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

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

理想情况下，开发人员应该靠近客户，没有专门的中间角色。仅当客户的专业化方式使开发人员无法同时成为用户时，才应使用其他角色。

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

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

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

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

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

结对编程只能用于培训和调查任务。

关于这个我没什么好说的。

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

没错！敏捷旨在适应组织的需求。不断调整对于完善流程至关重要。

祝你的论文好运。

【讨论】：