我们希望客户聘请我们对他们实施敏捷进行培训，我们也希望我们的客户意识到实施敏捷时的各种陷阱以及错误的期望。
我正在考虑添加一些方案，以显示如果未正确实施敏捷，它可能会适得其反。
您是否经历过任何敏捷不能提高效率甚至没有障碍编码的情况？
#1 楼
Tl; DR：是的，如果您实践卓越的技术，就应该这样做。可悲的是通常情况并非如此。当前最受欢迎的敏捷框架Scrum主要关注流程质量和项目沟通。如果您让自己的项目经理过渡到Scrum Master，您会遇到麻烦，因为他们不了解内部或结构质量以及为什么这在敏捷产品生命周期中如此重要。
根据Scrum的说法，团队要提高产品质量：
在每次Sprint回顾期间，Scrum团队都计划提高方法
通过适当地调整“完成”的定义来提高产品质量。
在纸上听起来不错，但由于Scrum主要关注流程。技术产品质量可能会被忽略。越来越快，同时使代码越来越糟。盲目地信任开发人员以提高代码质量并掌握其技能，在时间压力下与质量抗争或执行质量实践，这是不正确的梦想。
因此，其他敏捷框架经常提到质量实践。最出名的是ExtremeProgramming中的规则：结对编程，TDD，重构等。
我喜欢LESS（大型Scrum）团队的说法：
组织敏捷性受技术敏捷性的约束
大多数以敏捷为起点的公司都忘记了技术部分。因此，必须实践敏捷宣言中描述的卓越技术。您的组织可以如此灵活，但是如果您的产品在代码级别上拒绝更改，是否值得？
持续关注技术卓越性和良好的设计可提高敏捷性
。
http://agilemanifesto.org/principles.html
宣言的签署者之一，即Robert C. Martin，正在努力提高开发人员的代码质量技能，他着有《清洁代码：敏捷软件技巧手册》，《清洁编码器和敏捷软件开发手册，原理，模式和实践》。我确实相信，敏捷教练有必要向开发团队讲授这些书中描述的技能，但是在现实世界中，我只遇到了少数几个真正理解这些做法的影响的人。他们常常信任开发人员知道的经验，即使他们认为确实不知道。
请确保找到一位敏捷的老师，教练，Scrum Master，他曾经是开发人员，前测试人员，或以技术卓越的团队工作。前项目经理可能是最糟糕的候选人，尽管他们在解决组织障碍方面可能会更好。首先，这可能是在一些较大的公司中开始使用敏捷的最大障碍。但是对于从敏捷开始的小型团队而言，专注于技术质量将使他们受益匪浅！
我之所以写这篇文章，是因为我已经看到多个成功的产品在不同的公司中取得了成功。最终结果是团队在向产品添加新功能时陷入停顿。修复一件事将意味着破坏其他事物。默认情况下，敏捷过程的性质不能提供良好的结构可维护和可扩展的产品，当然不是Scrum。如果你问我，这是最大的陷阱。
第二大陷阱是截止日期。即使团队在进行所有估算时都考虑到了良好的质量实践。大多数产品经理会向客户提交功能。使团队承受时间压力无助于交付高质量代码。即使大多数公司意识到自己不应该这样做，但仍然这样做。这是因为客户还需要内部调整以获取预算，从而制定路线图和期限。我认为我们应该重新审视敏捷销售策略。
评论
我本人打算自己写一个答案，但是您已经说了我将拥有的所有内容以及更多。敏捷本身不会提高代码质量，并且可能由于处理时间短而使它变得更糟！虽然也不能保证也要进行单元测试和TDD / BDD。另一本好书是Michael Feathers撰写的《有效地使用旧版代码》。它描述了如何将糟糕的代码逐步变为更好的代码，但是整个团队必须这样做才能使其正常工作。
– CJ Dennis
17 Mar 4 '17 at 12:51
我见过的最好的比较是节食。如果降低热量摄入并增加运动量，则绝对可以减轻体重。但是，如果您花时间测量卡路里并实际上没有降低摄入量，或者如果您不运动，那么您就不会减肥。您可能会感觉好些，因为您可以说自己在节食，但不会获得结果。因此，如果您每周有3次Scrum，但不进行回顾，或者让事情陷入冲刺，或者您将Scrum时间用作挑选表现不佳的人而不是找出障碍的方法，那您将陷入困境时间。
–corsiKa♦
17 Mar 4 '17 at 18:29
#2 楼
“敏捷”与代码质量之间确实没有任何联系。最终，您拥有由相同的程序员编写相同的代码。
Scrum或（精益或看板）与他们如何将其溢出，按什么顺序执行并报告进度有关。
我认为您应该写些什么增加增加代码质量的流程是一个挑战。 （单元测试，代码审查等）。灵活的方法中，同时始终专注于按时交付功能。
您可能会加大在平衡技术债务与功能交付，持续开发与计划的手动测试版本等方面的难度。
书中没有的那种东西，只有你的资深顾问来之不易的经验才能告诉你。
评论
敏捷宣言将代码质量与12条原则之一联系起来，即以下一条原则：“持续关注技术卓越和良好的设计可提高敏捷性。”，大多数敏捷框架定义了这意味着什么。
– Niels van Reijmersdal
17 Mar 4 '17 at 11:34
您的开头是一个大胆的声明。您对索赔有引用吗？
–corsiKa♦
17 Mar 4 '17 at 21:40
dl.acm.org/citation.cfm?id=2635922该研究表明，主要因素是团队规模和静态打字
–伊万
17 Mar 4 '17 at 21:52
遗憾的是这篇文章不是免费的，但是摘要指出它是关于“编程语言对软件质量有何影响？”而不是“（敏捷）流程对软件质量有何影响？”。我认为结果会大不相同。例如，静态类型似乎无关紧要。团队规模将对课程产生影响。
– Niels van Reijmersdal
17 Mar 6 '17 at 16:16
好。从研究结果中可以得出的是，与使用强类型语言相比，方法论对代码质量的影响微不足道。如果相反的话是正确的，那么在不考虑方法论的情况下，您将看不到键入的链接
–伊万
17 Mar 6 '17 at 16:20
#3 楼
我们确实希望客户在实施敏捷以及错误期望时意识到各种陷阱。
而不是将敏捷（名词）作为产品推销，销售最佳做法和持续改进，这将导致客户变得更加敏捷（形容词），使用业务目标或对客户/用户的需求和问题做出更快的响应。
首先使用TDD和自动测试避免问题。可以通过静态分析，对等审阅或结对编程来提高代码质量，包括在总体产品中适当的那些做法，但它们只是CI的一个方面，而这只是敏捷的一个方面。 >
YAGNI通过避免浪费精力来降低成本。 BDD促进了对有价值功能的关注；用切实的好处推销各种改进措施，注意使他们感兴趣的注意事项，并跟进这些改进。
#4 楼
我有一些有趣的故事要讲：对于我正在工作的一家公司，团队负责人（也是Scrum主管）会在早上的站立时要求提供非常详细的报告。我们的站起来通常需要1个小时才能完成。轮到我时，通常我会简短地描述我已经做过的事情，以及我打算做的事情。早上起床的全部目的不是要学习他人工作的每一个细节。当单边对话拖延太久时，大多数人会失去注意力，尤其是当您不感兴趣时（老实说，谁每天都想知道别人工作的所有细节？）。总而言之，早上起床应该是一个简短的会议，每个人都应该了解大局，它必须简短而简洁。 IMO，经过漫长的站立训练，实际上无法达到其目的。
机器人Scrum管理员。有一个专门的Scrum主持人主持早晨的站立表演。在加入我们后不久，这个人就被昵称为“机器人混乱大师”，因为他所做的只是说：“好，现在轮到您了。”每当做出决定时，他都会说：“我只是Scrum管理员，这不是我的工作。”总之，如果我们从敏捷教科书中删除角色，并严格按照书中的描述进行角色扮演，那么它也将无法很好地发挥作用。
我工作的一家公司具有回扣文化，人们彼此友好。但这会花很多钱。在回顾过程中，发现了问题，但以后未采取任何措施来纠正或阻止它们。
#5 楼
我认为这将取决于质量的定义，因为质量的定义来自企业让我尝试给出三个示例，答案可能是“否”，“是”和“也许”。
NASA-敏捷发现是否适合提前计划并编写具有非常严格和固定要求的高质量代码？
Uber-是否会不断地迭代设计并实现客户的反馈，从而提高代码质量？可能是。
Healthcare.gov-考虑到大量的监管要求以及从一开始就需要考虑数据交换标准，将在设计上进行迭代以提高代码质量。也许？不是吗？
评论
质量分为三种类型：过程，结构和功能。来自业务的质量是过程和功能，但是问题在于代码质量（即结构质量）。如果您问我，那应该由开发团队而不是企业来定义。 davidchappell.com/writing/white_papers/…
– Niels van Reijmersdal
17 Mar 4 '17 at 17:31
评论
“快速，良好，便宜：选择任意两个”。投票决定不提这个问题。尽管答案可能包含有力的观点，但问题是根据经验提出的。这里的经验不是观点，它们是现实生活中发生的事实。像大多数有关敏捷和测试的问题一样，您可以通过“取决于”来回答它，从而得出有趣的答案。
“实施敏捷通常会提高代码质量吗？” -不。敏捷与代码质量无关。我看到一些使用敏捷的公司质量很高，而有些质量很差。我看到有些公司在使用其他质量较高的方法，而有些质量较差。