作为一名从未在敏捷公司工作的开发人员（但曾在TDD商店工作过），我看到运营敏捷商店的雇主拒绝聘请没有在敏捷工作的人。在过去的几年里，我已经碰到过几次了。 这真的是哲学变革的根本吗？在TDD工作之后，我几乎可以争论不雇用从未做过TDD的人（在繁重的TDD环境中工作时）。也许我不了解敏捷及其与TDD之间的区别。
我实际上喜欢在敏捷工作，但这似乎是您必须有经验才能获得体验的时刻之一。当然，你可以自己做，但如果你问我这不符合条件。作为雇主，我不会真的称之为适用。
答案 0 :(得分：20)
严格意义上的敏捷不是一种工程哲学--TDD，Peer Programming等是敏捷使用的工程实践 - 而敏捷则是一种管理方法。因此，更重要的是，有人对敏捷要求的心态持开放态度，而不是之前他们实际上曾在敏捷商店工作过。是的，它确实是一种不同的软件开发理念和方法。那些期待所有事情并被告知他们需要做什么的人在敏捷环境中将会非常不合适。
当我采访人们时，我确实问他们是否有任何敏捷经验或知识，但我真正想要的是以下一些：
这些是我认为有资格在敏捷环境中工作的一些品质。
答案 1 :(得分：7)
了解敏捷的核心原则对于理解敏捷非常重要。 TDD只是敏捷的一小部分，更具体地说是XP（极限编程）。
首先我要看一下敏捷宣言：
有关流程和工具的个人和互动
工作软件，而不是全面的文档
客户协作超过合同谈判
响应变更而不是遵循计划
也就是说，虽然物品上有价值 在右边，我们更重视左边的项目。
然后我会看看SCRUM流程（这也是敏捷的一小部分），看看那里涉及到什么。
当我采访开发人员时，我希望看到他们对敏捷有所了解以及需要什么，以便我可以确定敏捷环境/心态是否是他们喜欢的工作。
答案 2 :(得分：6)
我已经多次聘请开发人员加入敏捷团队。我一点也不耐心聘请没有敏捷经验的开发人员 - 他们会稍微便宜一些; - ）
然而，有些问题我会问这样的候选人，并且有一些回应引起了警钟 - 让我知道这个人将要做太多的工作来重新训练。
例如，对于他们的代码和设计非常珍贵 - 这肯定表明他们将成为scrums和代码评论中的主要内容。
敏捷是一种极端民主 - 每个人都是平等的，但这并不适合所有人。一些开发人员在专制（告诉我该做什么以及如何做），君主制（中层管理层）或官僚主义（规范和死记硬背）中看起来更开心 - 这些人只是不灵活。
一些开发人员对敏捷的想法感到非常满意，无论他们之前是否具有敏捷性，这些人都可以被雇用。
我不担心不了解所有流程细节 - 优秀的开发人员会阅读并了解他们使用的技术，而不是流程方法。既然每家公司都会定制他们的敏捷模型（如果他们不这样做，那么他们开始使用哪种变体并不重要）。你应该知道一些术语，但最多需要在面试前阅读一天。
答案 3 :(得分：2)
我们使用的敏捷品牌由SCRUM定义的项目管理实践和XP定义的工程实践组成。如果我们要开始一个新的团队，我们将寻找关键角色作为团队的嵌入式教练（迭代经理/ Scrum主教练，分析师教练，技术教练和测试教练）。对于现有团队，鉴于我们使用配对，我们对与其他人合作的开发人员比对超级程序员更有兴趣。
由于我们使用配对，新开发人员将在一个月内通过敏捷工程实践以及业务和应用程序域提高工作效率。如果强大的程序员加入团队但无法有效配对，它为团队提供的价值很小。
当我们采访时，我们要求候选人与几个团队成员配对。通过配对，我们了解开发人员是否与其他人合作良好。此外，我们深入了解开发人员的技术技能。因为候选人分成几组，我们得到了许多团队成员的观点。
我们所有的敏捷团队都非常有效，他们的项目也很成功。我们培训了更多的团队成员，使他们在敏捷方面变得有效，而不是聘请经验丰富的敏捷人员。
答案 4 :(得分：1)
我认为这是一种过度坚持特定技能的典型案例。就像那些不希望有人在使用BEA作为应用程序服务器时知道JBoss的雇主一样。
一个好的雇主会认识到某人是否适应敏捷方法。现在，如果他们面前有两个相同的候选人，也许这有点不同。
答案 5 :(得分：1)
这肯定是解释可能在决策中扮演更重要角色的其他原因的一种方便方法。
答案 6 :(得分：1)
我理解你的挫败感，但事实是，如果你从未在敏捷环境中工作，你很可能会以反向敏捷的方式行事（可以这么说），你可能甚至不明白你是什么做错了。
既然敏捷是关于工作哲学的，那么你不仅仅是通过读书就能学到东西，你需要深入了解非敏捷企业的运作方式，导致的问题，敏捷如何改变，以及你如何打击熵（外部世界试图将非敏捷性引入其中）。
我的建议是，您首先要阅读更多关于敏捷的内容，并从Agility / non-Agility的角度开始分析您目前从事的任何公司的行为和行为。一旦你能够辨别出模式，你就可以开始尝试从内部改变你的公司。当你失败的时候，去一家敏捷公司，他们会雇用你，我保证。
答案 7 :(得分：1)
通过实践指导SDLC而不是最适合当前项目/情况的任何公司或机会已经显示出其局限性的迹象，并且您可能更好地继续求职。
答案 8 :(得分：1)
绝对是
在敏捷方面，特别是在极端编程方面，有很多团队合作和信任你的同行。你需要知道其他人正在编写体面的测试，而不是破坏你的代码。优秀的XP开发人员不希望团队中的人员更加努力地工作。
作为一名初学者，或者某个团队新手，没有错 - 但是建立信任的元素就像你在开源中获得提交者权利一样。
现在每个人都说他们很敏捷，如果你提供足够的钱，几乎所有拥有最少技术技能的人都会申请这份工作......所以希望人们为你完成一对编程面试
通常我们需要知道：
这将有助于您在敏捷商店中受雇：
答案 9 :(得分：0)
在您目前的工作中，您是否可以实施某种形式的敏捷开发以表明您感兴趣，已经研究过它并且实际上有一些经验？您可以找到一些非开发人员与您合作。高级用户可以在编码期间与您坐在一起。我确信没有人会妨碍使用一些敏捷文档（sprint日志，刻录图表）。
答案 10 :(得分：0)
我可能会提出这个问题：在你的职业生涯中，你到目前为止使用了哪些开发方法？他们中的任何一个都包含了敏捷理想的精神吗？
如果你是一个喜欢通过瀑布发展的人，并认为它对你的发展世界来说绝对是完美的，那么走向敏捷就像从驾驶汽车到飞机或船只。这是一个根本性的差异，因为你不一定知道你要去哪里和处理变化的方式与瀑布风格完全不同，每个阶段都按顺序进行，并且没有任何重新优先权而不会危及整个过程。
答案 11 :(得分：0)
当一家公司在招聘时使用“敏捷”这一总称，而不是更具体（例如，通过要求XP或Scrum经验），它通常是他们正在寻找的其他东西的占位符。他们可能想要“开发人员配对程序”或“开发人员不会在他们开始之前就没有需求和设计文档”或“开发人员连续数周不会进入黑暗角落” ”。诀窍是找出它们的含义。
从狭隘的硅谷招聘角度来看，熟悉敏捷实践（例如，知道XP是什么）的候选人已经完成了其中一些（例如，结对编程和TDD），以及谁想要在敏捷中工作环境越过了这个障碍。
答案 12 :(得分：0)
雇主最有可能坚持雇用敏捷而不是敏捷的人，因为敏捷方法要求几乎每个团队成员都知道每个敏捷方法（SCRUM，Crystal，XP）所需的流程。例如，SCRUM要求所有团队成员（包括管理层）理解并遵循自组织的概念。他们需要明白，他们不会受到当前表现的影响：他们需要公开地解决他们的问题（或者通常在每日SCRUM上发生的事情）。如果你让团队成员不熟悉敏捷，他们可能会立即认为，由于这种方法文档很少，他们可以运行并进行代码和修复来构建项目。但是，敏捷方法是流程繁重的，而不是文档繁重的。
答案 13 :(得分：-1)
也许他们采取Mos Eisley cantina酒吧的心态（转述）：
我们不希望你的好意。