作为一名从未在敏捷公司工作的开发人员(但曾在TDD商店工作过),我看到运营敏捷商店的雇主拒绝聘请没有在敏捷工作的人.在过去的几年里,我已经碰到过几次了.这真的是哲学变革的根本吗？在TDD工作之后,我几乎可以争论不雇用从未做过TDD的人(在繁重的TDD环境中工作时).也许我不了解敏捷及其与TDD之间的区别.
我实际上喜欢在敏捷工作,但这似乎是你必须有经验才能获得经验的时期之一.当然,你可以自己做,但如果你问我这不符合条件.作为雇主,我不会真的称之为适用.
Jos*_*h E 20
敏捷不是严格意义上的工程哲学--TDD,Peer Programming等是敏捷使用的工程实践 - 而敏捷则是一种管理方法.因此,更重要的是,有人对敏捷要求的心态持开放态度,而不是之前他们实际上曾在敏捷商店工作过.是的,它确实是一种不同的软件开发理念和方法.在敏捷的环境中,那些期待所有事情并被告知他们需要做什么的人将非常不合适.
当我采访人们时,我确实问他们是否有任何敏捷经验或知识,但我真正想要的是以下一些方面:
这些是我认为有资格在敏捷环境中工作的一些品质.
了解敏捷的核心原则对于理解敏捷非常重要.TDD只是敏捷的一小部分,更具体地说是XP(极限编程).
首先,我要看一下敏捷宣言:
个人和流程与工具之间的互动
通过综合文档工作软件
合同谈判中的客户协作
响应遵循计划的变更
也就是说,虽然右边的项目有价值,但我们更重视左边的项目.
然后我会看看SCRUM流程(这也是敏捷的一小部分),看看那里涉及到什么.
当我采访开发人员时,我希望看到他们对敏捷有所了解以及需要什么,以便我可以确定敏捷环境/心态是否是他们喜欢的工作.
我已经多次聘请开发人员加入敏捷团队.我一点都不耐雇用没有敏捷经验的开发人员 - 他们会稍微便宜一些;-)
然而,有些问题我会问这样的候选人,并且有一些反应引起了警钟 - 让我知道这个人将要做太多的工作来重新训练.
例如,对他们的代码和设计非常珍贵 - 这肯定表明他们将成为scrums和代码审查中的一个主要内容.
敏捷是一种极端民主 - 每个人都是平等的,但这并不适合所有人.一些开发人员在专制(告诉我该做什么以及如何做),君主制(中层管理层)或官僚主义(规范和死记硬背)中看起来更开心 - 这些人只是不灵活.
一些开发人员对敏捷的想法感到非常高兴,而且无论他们之前是否具有敏捷性,这些人都可以被雇用.
我不担心不了解所有流程细节 - 优秀的开发人员阅读并了解他们使用的技术,而不是流程方法.既然每家公司都会定制他们的敏捷模型(如果他们不这样做,那么他们开始使用哪种变体并不重要).你应该知道一些术语,但最多需要在面试前阅读一天.