在采访中从流行语敏捷中淘汰真正的敏捷[关闭]

我最近一直在面试合作社（带薪实习），而我面试过的许多公司都说他们使用Scrum或其他敏捷方法（scrum是最受欢迎的）。我知道那里有真正的敏捷商店，有些地方说他们使用敏捷方法论，但实际上是在做其他事情，并以敏捷作为流行语。

我的问题是，在面试中我会问哪些问题将这些商店分开？

编辑：当我在寻找实习机会时，我觉得这些问题与每个人都息息相关。实习部分是情境。

我总是从问这个问题开始：

您的迭代持续时间是多长？

评价他们的答案：

1周很棒，2周很棒，3周还可以，4周平庸。比这更长的时间表明他们正在苦苦挣扎，而超过8周的时间简直太不可思议了。如果答案是取决于，您将知道他们毫无头绪。

跟进：

您多久释放一次？

这是为了验证第一个问题。正确的答案是每天或每次冲刺结束。一位敏捷专家知道，内部版本和外部版本之间应该没有技术上的区别。

要求他们捍卫敏捷方法论。然后要求他们通过概述它的弱点来反驳它。奖励积分，如果他们可以导航此课程而不会用毫无意义的流行语乱扔它。

问问他们为什么使用它。

您将立即知道。

我想请他们描述使用敏捷方法论时的软件开发生命周期。如果他们熟悉它，他们应该能够准确地描述SDLC中的每个阶段。

编辑：我只是意识到您是从受访者而不是采访者的角度询问。在那种情况下，我可能会问他们有关他们的SDLC的信息，看看他们说的采取的措施是否符合敏捷的实际要求。

我采用的方法实际上与敏捷流行语无关，但与敏捷实践有关。所有敏捷团队的共同点之一是短暂的迭代，大多数人都可以做到这一点（这是http://agilemanifesto.org网站上敏捷背后的12条原则之一）。简短迭代的目的是尽早获得有关所开发软件质量的反馈。这是我的起点。

1. 询问单元测试。绝大多数情况下，我得到的答案是“呃，我们因为没有足够的时间而将其删除了”（注意：前两个警告标志-没有时间，也没有单元测试）
2. 询问软件何时进行测试以及测试频率。答案可以在这里发挥创意。特别是如果团队以“敏捷”为借口将所有过程抛在一边。如果答案接近项目的结尾，或者每次迭代都没有，他们就不知道敏捷是什么。

到目前为止，我不需要做更多的事情就可以知道该人不知道敏捷是什么。我也只接受过一家已经建立了敏捷流程的公司的一次采访。

敏捷的方法不只一种，而且我更关心敏捷的原理，而不是任何特定的品牌或流行语。

有几件事将“做”敏捷的人和敏捷的人分开：

• 询问持续集成是否未使用CI扣分。如果存在，请添加一个点。加分：
  1. 如果他们使用两个阶段提交，则添加1（开发人员可以检入之前必须成功构建代码）。
  2. 如果构建脚本包括运行测试套件，则添加1
  3. 如果代码覆盖率低于特定阈值，则构建失败，则添加1
  4. 如果可以部署应用程序，则只需添加2，即可一键运行
• 询问有关TDD（测试驱动的开发）的问题，如果他们不使用TDD，则减去2分，如果使用，则加1。
• 询问迭代的时间长短（如果不进行迭代开发，则减去2分；如果迭代时间超过一个月或少于两周，则减去1；如果迭代时间超过2周，则减去1）。
• 询问如何进行估算，如果他们使用故事点，则加1；如果他们计划扑克或类似项目，则加2；如果他们使用绝对时间估算，则减1；如果开发人员不参与估算过程，则减2。
• 询问如何构建功能部件，如果开发人员从上至下（垂直切片）负责功能，则加1；如果开发人员负责特定层（水平切片），则加1。

还有许多其他指标，但是如果团队实际上是敏捷的，那么仅凭这些指标就可以为您提供良好的印象。得分为5分或以上的团队。其他任何事情都意味着他们正在“做”敏捷。敏捷不仅涉及迭代，还在于使团队能够轻松适应变化。如果您要反复编写未经测试的，混乱的代码，是在外部压力下编写的，那么您只是在迭代中编写废话代码。请注意，您可以从持续集成项目符号中获得很多要点。但是，如果您不遵循其他做法，仅凭这一点还不足以让您超过5岁。

与所有这些事情一样，您需要从他们从事的项目中获得真实的例子，而不是理论上的例子。接受理论上的答案是最简单的方法，可以让尚未真正去过那里的人欺骗。

因此，您要求与实际的开发人员交谈并提出类似的要求：

• 所以说说我当前的项目。最初的最终目标是什么？第一个Sprint包含什么内容，软件在结尾处可以做什么？
• 您能为我提供上一个您认为与瀑布项目不同的功能或设计示例吗？
• 给我一个例子，说明如何在多个sprint中分解大量功能？这导致了什么效率低下/返工？以及对最初设想的改进或更改。
• 当您开始使用敏捷时，随着方法论的掌握，您在早期sprint中所做的事情在后来的sprint（或项目）中发生了什么变化？

不断将它们带回实际项目 -他们试图实现的目标，每个冲刺中的示例，会议中出现的各种示例，与用户进行交互的示例。

不接受理论，不接受他人的项目，只有他们自己已经从事的事情，并可以从第一手的经验中谈起。

他们必须是一个非常出色的骗子，才能整理出价值10到15分钟的东西，如果您知道自己的东西的话，它们就会过去。

如果您不想让他们防御，我发现以下问题将引发对话，该对话将告诉您您需要了解的所有信息：他们实际上是在使用敏捷方法还是只是口口相传：

谁负责为您的软件项目编写需求/规范？

我见过无数声称自称敏捷的公司，甚至当您询问其需求收集过程时，他们甚至都希望获得Scrum Master认证来描述一个经典的大型前期设计过程。

对我而言突出的是您正在寻找实习机会，这使我想知道您问这些问题的目的是什么。您是否正在尝试提出有关敏捷的问题，以使面试顺利进行，还是您实际上会拒绝使用流行语“敏捷”的公司的报价？如果您确实在寻找敏捷环境，请选择一个问题（为什么要使用敏捷，什么时候站得住脚，迭代需要多长时间等等），然后通过电话或电子邮件询问，而不会浪费时间在面试 如果您正在寻找收入，请等待面试，并提出问题以表明您对敏捷方法的了解/兴奋（告诉我有关您的软件开发生命周期的信息），而又不会让面试官感到尴尬，如果他们使用某种半敏捷的可憎性。

我要求他们描述一个典型的请求，从开始到最终交付给客户。

我还问他们是否通常会为他们提供给客户的产品提供长期支持（因为通常情况下，团队会制作出更好的产品，因为他们知道他们将在劳动节周末的周日凌晨1点进行修复）。

我还问管理层在此过程中如何看待其角色。很容易看出他们是否具有“一劳永逸”的态度（我们发射，飞行，询问是否击中目标）或“我们帮助您在河上划船”的态度。

这些通常会向您显示他们是如何实际做的，而不是应该如何做的，或者他们是如何宣称要做的。

我发现从SDLC的角度看某人是否知道自己在做什么的最好方法是问他们过去弄糟的地方，以及他们将如何做不同的事情。经历过几次这个过程的人会完全承认他们搞砸了，通常情况会很详细。他们开放讨论的态度表明了自己的信心，因为他们承认自己并不完美。通过说“他们几乎一直都可以做到”来避免这个问题，这是一个真正的警告信号。

他们多久发布一次产品。时间越长，敏捷就越少。他们多久举行一次反思研讨会。如果他们知道您在说什么，那很好。他们多久举行一次团队“补习”会议。每日好，每月坏。他们有连续集成服务器吗？这不是必须的，但可以让您了解其使用工具的方式。最终用户多久与开发人员坐一次。永远不要说他们不敏捷。

• 给他们一个情况，并要求他们以敏捷的方式解决它；
• 向他们询问他们最喜欢的敏捷实践（计划扑克，结对编程，bdd / tdd，看板）；
• 询问他们为什么不选择其他方法（瀑布，卢比等）或从其他方法中移开
• 敏捷方法论领域中最有名的人是谁创造了该术语以及有关该术语的最受欢迎书籍。

如果他们使用Scrum，则可以询问是否可以观看下一个站立姿势。如果他们没有它们，请问为什么不这样做，因为那通常是方法论的一部分。

敏捷的某些方面也可能值得一提。要求查看故事板，未完成订单有多大，或在上次回顾中的主要亮点是什么，还有其他一些想法。此处的关键是要获得能显示出正在发生的事情的东西，而不是仅仅起什么作用的松散的话。

询问他们如何处理设计。如果他们告诉您敏捷中没有设计，那么他们就没有实现。

询问他们如何管理不断变化的需求。如果听起来好像变更需求有其自己的流程，那么他们很可能无法理解。

如果他们声称使用Scrum，请看看他们是如何编写的。精通Scrum的商店往往对如何编写Scrum有足够的了解。提示：不是SCRUM。

这看起来似乎很繁琐，但是我坚信，为了成功应用Scrum，RUP，XP等流程模板，您需要了解其原理和“为什么”，以便知道如何适应组织的“内容”。在Scrum中，大多数正在做家庭作业的人都会碰到一点点信息。寻找项目管理食谱的人们通常会错过这个细节。

对我来说有意义的是请他们描述他们如何处理敏捷过程的一部分。现在，我的最爱是迭代的开始，但是您可以开发自己的最爱。

问：“在冲刺开始时给了很多票，请从这里描述您的工作流程”

这里要注意的重点：

• 开发人员会估算门票吗？
• 您是否跟踪速度？
• 当您的估计超出速度时会发生什么？
• 如果您有一个截止日期，而您的估计超过速度，会发生什么？（请注意此处的旋转：它们是否会降低复杂性，重新确定优先级，或者只是消亡开发团队？）

这些都不是破坏交易本身的东西，但是如果他们对这些问题的回答让您感到疑惑，那么也许他们对敏捷仪式感兴趣，而不是实际的敏捷开发。