In einem Interview echte Agilität von Modewort-Agilität verdrängen [geschlossen]

Ich habe in letzter Zeit für Kooperationen (bezahlte Praktika) interviewt, und eine große Anzahl der Unternehmen, mit denen ich interviewt habe, gaben an, dass sie Scrum oder eine andere agile Methode verwenden (wobei Scrum die beliebteste ist). Ich weiß, dass es wirklich agile Läden gibt und es Orte gibt, die sagen, dass sie eine agile Methodik verwenden, aber wirklich etwas anderes tun und Agile als Modewort verwenden.

Meine Frage ist, was sind einige Fragen, die ich in einem Interview stellen kann, die diese Geschäfte heraus trennen würden?

EDIT: Während ich ein Praktikum suche, habe ich das Gefühl, dass diese Fragen für alle relevant sind. Der Praktikumsteil ist Kontext.

Ich beginne immer mit dieser Frage:

Wie lange dauern Ihre Iterationen?

Bewerten Sie ihre Antwort:

1 Woche ist großartig, 2 Wochen sind großartig, 3 sind in Ordnung und 4 mittelmäßig. Länger als das zeigt an, dass sie kämpfen und mehr als 8 Wochen ist nur seltsam. Wenn es darauf ankommt , wissen Sie, dass sie überhaupt keine Ahnung haben.

Follow-up mit:

Wie oft lässt du los?

Hiermit überprüfen Sie die erste Frage. Die richtige Antwort ist täglich oder am Ende jedes Sprints . Ein Agilist würde wissen, dass es keinen technischen Unterschied zwischen einer internen und einer externen Version geben sollte.

Bitten Sie sie, agile Methoden zu verteidigen. Und dann bitten Sie sie, es zu widerlegen, indem Sie seine Schwächen darlegen. Bonuspunkte, wenn sie in diesem Kurs navigieren können, ohne ihn mit bedeutungslosen Schlagworten zu verunreinigen.

Fragen Sie sie, warum sie es benutzen .

Sie werden es sofort wissen.

Ich würde sie bitten, den Lebenszyklus der Softwareentwicklung unter Verwendung der Agile-Methodik zu beschreiben. Wenn sie damit vertraut sind, sollten sie in der Lage sein, jede Phase in der SDLC genau zu beschreiben.

EDIT : Mir ist gerade aufgefallen, dass Sie aus Sicht des Befragten fragten, nicht des Interviewers. In diesem Fall würde ich sie wahrscheinlich nach ihrem SDLC fragen und herausfinden, ob die Schritte, die sie angeblich unternehmen, dem entsprechen, was Agile wirklich ist.

Der Ansatz, den ich verfolge, hat wirklich wenig mit den agilen Schlagworten zu tun, aber er hat mit agilen Praktiken zu tun. Eine der Gemeinsamkeiten in allen agilen Teams ist die kurze Iteration. Die meisten Leute erhalten diesen Teil (es ist eines der 12 Prinzipien hinter agile auf der Website http://agilemanifesto.org ). Ziel der kurzen Iteration ist es, frühzeitig ein Feedback zur Qualität der entwickelten Software zu erhalten. Hier beginne ich.

1. Fragen Sie nach Unit-Tests. Die Antwort, die ich hier bekomme, war überwiegend: "Äh, wir haben das rausgeschnitten, weil wir nicht genug Zeit hatten."
2. Fragen Sie nach, wann und wie oft die Software getestet wurde. Hier können Antworten kreativ werden. Vor allem, wenn das Team "Agile" als Ausrede benutzt, um alle Prozesse beiseite zu werfen. Wenn die Antwort auf das Ende des Projekts oder etwas anderes als bei jeder Iteration ist, wissen sie nicht, was agil ist.

Bisher musste ich nicht weiter gehen, um zu wissen, dass die Person nicht weiß, was agil ist. Ich habe auch nur ein Interview mit einem Unternehmen geführt, das bereits über etablierte agile Prozesse verfügt.

Es gibt mehr als einen Weg, um agil zu sein, und die Prinzipien von agil sind mir wichtiger als eine bestimmte Marke oder ein Schlagwort.

Es gibt verschiedene Dinge, die diejenigen, die agil sind, von denen, die agil sind, unterscheiden:

• Fragen Sie nach kontinuierlicher Integration, wenn Sie CI nicht verwenden. Ziehen Sie einen Punkt ab. Fügen Sie einen Punkt hinzu, wenn dies der Fall ist. Extra Punkte:
  1. Fügen Sie 1 hinzu, wenn sie zwei Phasen-Commits verwenden (Code muss erfolgreich erstellt werden, bevor der Entwickler einchecken kann).
  2. Fügen Sie 1 hinzu, wenn das Build-Skript die Ausführung einer Testsuite umfasst
  3. Fügen Sie 1 hinzu, wenn die Erstellung fehlschlägt, wenn die Codeabdeckung unter einen bestimmten Schwellenwert fällt
  4. Fügen Sie 2 hinzu, wenn es möglich ist, die Anwendung so bereitzustellen, dass sie mit einem Klick ausgeführt werden kann
• Fragen Sie nach TDD (testgetriebene Entwicklung). Subtrahieren Sie 2 Punkte, wenn Sie TDD nicht verwenden. Fügen Sie 1 hinzu, wenn Sie dies tun.
• Fragen Sie nach Iterationen, wie lange sie dauern (subtrahieren Sie 2 Punkte, wenn sie keine iterative Entwicklung durchführen, subtrahieren Sie 1, wenn die Iteration länger als ein Monat oder kürzer als zwei Wochen ist, addieren Sie 1, wenn sie 2 Wochen dauert).
• Fragen Sie, wie die Schätzung durchgeführt wird. Fügen Sie 1 hinzu, wenn Sie Story Points verwenden. Fügen Sie 2 hinzu, wenn Sie Poker oder ähnliches planen. Subtrahieren Sie eine, wenn Sie absolute Zeitschätzungen verwenden. Subtrahieren Sie 2, wenn Entwickler nicht in den Schätzungsprozess involviert sind.
• Fragen Sie, wie Features aufgebaut sind, addieren Sie 1, wenn ein Entwickler für das Feature von oben nach unten verantwortlich ist (vertikaler Schnitt), subtrahieren Sie 1, wenn Entwickler für einen bestimmten Layer verantwortlich sind (horizontaler Schnitt).

Es gibt eine Reihe anderer Indikatoren, aber diese allein sollten Ihnen ein gutes Bild vermitteln, wenn das Team tatsächlich agil ist. Ein Team mit 5 oder mehr Punkten qualifiziert sich. Alles andere bedeutet, dass sie agil handeln. Bei Agile geht es nicht nur um Iterationen, sondern darum, dass sich das Team leicht an Veränderungen anpassen kann. Wenn Sie iterativ ungetesteten, verworrenen Code schreiben, der unter äußerem Druck geschrieben wurde, schreiben Sie einfach Mistcode in Iterationen. Beachten Sie, dass Sie viele Punkte nur durch die fortlaufende Integration erhalten können. Aber das allein reicht nicht aus, um dich über 5 zu bringen, wenn du nicht den anderen Praktiken folgst.

Wie bei all diesen Dingen fragen Sie nach realen Beispielen aus Projekten, an denen sie gearbeitet haben , nicht nach Theorie. Das Akzeptieren theoretischer Antworten ist der einfachste Weg, sich von jemandem täuschen zu lassen, der nicht wirklich dort war.

Sie möchten also mit den tatsächlichen Entwicklern sprechen und Fragen stellen wie:

• Also rede mit mir über dein aktuelles Projekt. Was war das ursprüngliche Endziel? Was enthielt der erste Sprint und was konnte die Software am Ende tun?
• Können Sie mir Beispiele für Funktionalität oder Design Ihres letzten Projekts geben, von dem Sie glauben, dass es anders ausgearbeitet hat als Sie es als Wasserfallprojekt getan hatten?
• Geben Sie mir ein Beispiel, wie ein großes Stück Funktionalität über mehrere Sprints aufgeteilt wurde? Zu welchen Ineffizienzen / Nacharbeiten führte dies? Und welche Verbesserungen oder Änderungen von dem, was ursprünglich ins Auge gefasst wurde.
• Als Sie anfingen, mit Agile zu arbeiten, welche Dinge, die Sie während der ersten Sprints taten, haben Sie während späterer Sprints (oder Projekte) geändert, als Sie sich mit der Methodik vertraut gemacht haben?

Bringen Sie sie immer wieder auf die tatsächlichen Projekte zurück - was wollten sie erreichen, Beispiele für die einzelnen Sprints, Beispiele für die Dinge, die in Besprechungen auftauchten, Beispiele für die Interaktion mit den Benutzern.

Akzeptiere keine Theorie, akzeptiere keine Projekte anderer Leute, nur Dinge, an denen sie selbst gearbeitet haben und über die sie aus erster Hand sprechen können.

Sie müssten ein erstaunlich guter Lügner sein, um Dinge im Wert von 10 bis 15 Minuten erfinden zu können, die an Ihnen vorbeigehen würden, wenn Sie sich auskennen.

Wenn Sie sie nicht defensiv machen möchten, wird mit der folgenden Frage ein Gespräch angestoßen, in dem Sie alle Informationen erhalten, die Sie benötigen, um festzustellen, ob sie tatsächlich einen agilen Ansatz verwenden oder nur ein Lippenbekenntnis abgeben:

Wer ist für das Schreiben von Anforderungen / Spezifikationen für Ihre Softwareprojekte verantwortlich?

Ich habe zahlreiche Unternehmen gesehen, die behaupteten, agil zu sein, und sogar wollten, dass eine Scrum-Master-Zertifizierung einen klassischen Big-Up-Front-Design-Prozess beschreibt, wenn Sie nach dem Prozess der Anforderungserfassung fragen.

Das, was mir auffällt, ist, dass Sie ein Praktikum suchen, und ich frage mich, wozu Sie diese Fragen stellen. Versuchen Sie, eine Frage zu Agile zu stellen, damit das Interview gut läuft, oder lehnen Sie ein Angebot eines Unternehmens ab, das Buzzword Agile verwendet? Wenn Sie wirklich auf der Suche nach einer agilen Umgebung sind, wählen Sie eine Frage aus (warum verwenden Sie agile, wie spät sind Ihre Stand-Ups, wie lange dauern die Iterationen, was auch immer), und stellen Sie sie per Telefon oder E-Mail, ohne Zeit zu verschwenden Interview. Wenn Sie auf der Suche nach einem Einkommen sind, warten Sie auf das Interview und stellen Sie Fragen, die Ihr Wissen / Ihre Begeisterung über agile Methoden zeigen (Erzählen Sie mir von Ihrem Softwareentwicklungs-Lebenszyklus), ohne den Interviewer in Verlegenheit zu bringen, wenn er einen semi-agilen Gräuel benutzt.

Ich bitte sie, eine typische Anfrage zu beschreiben, von der Gründung bis zur endgültigen Lieferung an den Kunden.

Ich frage auch, ob sie in der Regel den langfristigen Support für das Produkt übernehmen, das sie dem Kunden anbieten (da Teams, die dies tun, im Allgemeinen ein besseres Produkt entwickeln und wissen, dass sie es am Sonntag um 1 Uhr morgens am Labor Day-Wochenende reparieren werden).

Ich frage auch, wie das Management seine Rolle während des Prozesses sieht. Es ist ziemlich leicht zu erkennen, ob sie die Feuer-und-Vergessen-Einstellung (wir starten, Sie fliegen, wir fragen, ob Sie das Ziel treffen) oder die Einstellung "Wir helfen Ihnen, das Boot den Fluss hinauf zu rudern" haben.

Diese zeigen Ihnen im Allgemeinen, wie sie Dinge wirklich tun, nicht wie sie sie tun sollen oder wie sie behaupten, sie zu tun.

Ich habe festgestellt, dass jemand, der weiß, was er aus SDLC-Sicht tut, am besten fragt, wo er in der Vergangenheit Fehler gemacht hat und wie er das anders machen würde. Leute, die den Prozess ein paar Mal durchlaufen haben und zugeben werden, wo sie es vermasselt haben, und die sind im Allgemeinen ziemlich detailliert. Ihre Offenheit für Diskussionen zeigt ein gewisses Maß an Selbstvertrauen, weil sie zugeben, dass sie nicht perfekt sind. Es ist ein echtes Warnsignal, die Frage zu vermeiden, indem man sagt: "Sie machen es die ganze Zeit so ziemlich in Ordnung."

Wie oft werden sie für die Produktion freigegeben? Je länger die Zeit, desto weniger agil sind sie. Wie oft gibt es Reflexionsworkshops? Wenn sie wissen, wovon Sie sprechen, dann gut. Wie oft haben sie Teambesprechungen. Täglich ist toll, monatlich ist schlecht. Haben sie einen Continuous Integration Server? Dies ist kein Muss, gibt Ihnen aber eine Vorstellung von der Verwendung von Werkzeugen. Wie oft sitzen die Endbenutzer bei den Entwicklern. Bedeutet niemals, dass sie nicht agil sind.

• Geben Sie ihnen eine Situation und bitten Sie sie, sie agil zu lösen.
• Fragen Sie sie nach ihren bevorzugten agilen Praktiken (Planung von Poker, Pair Programming, Bdd / Tdd, Kanban).
• Fragen Sie sie, warum sie sich nicht für eine andere Methode entschieden haben (Wasserfall, Rupie usw.).
• Was sind die bekanntesten Leute in der Welt der agilen Methodik, die den Begriff geprägt haben und welche populärsten Bücher darüber geschrieben wurden?

Wenn sie Scrum verwenden, könnten Sie fragen, ob Sie den nächsten Stand-up sehen könnten. Wenn sie sie nicht haben, fragen Sie, warum nicht, da dies normalerweise Teil der Methodik wäre.

Es gibt einige Aspekte von Agile, die ebenfalls erwähnenswert sein könnten. Fragen Sie im Storyboard nach, wie groß der Backlog ist oder was einige der Höhepunkte in der letzten Retrospektive waren, für ein paar andere Ideen. Der Schlüssel dabei ist, zu etwas Greifbarem zu gelangen, das zeigt, was gerade passiert, im Vergleich zu nur flauschigen Wörtern, die nicht wirklich viel bedeuten.

Fragen Sie sie, wie sie mit Design umgehen. Wenn sie dir sagen, dass es kein Design in Agile gibt, bekommen sie es nicht.

Fragen Sie sie, wie sie mit sich ändernden Anforderungen umgehen. Wenn es so klingt, als hätte das Ändern von Anforderungen einen eigenen Prozess, werden sie ihn wahrscheinlich nicht verstehen.

Wenn sie behaupten, Scrum zu verwenden, schauen Sie, wie sie es schreiben. Geschäfte, die Scrum gut beherrschen, wissen in der Regel gut genug, wie man es schreibt. Hinweis: Es ist nicht SCRUM.

Das mag wie Pedanterie erscheinen, aber ich bin fest davon überzeugt, dass man die Philosophie und das "Warum" verstehen muss, um eine Prozessvorlage wie Scrum, RUP, XP oder was auch immer erfolgreich anzuwenden, damit man weiß, wie man sich anpasst das "was" zu Ihrer Organisation. In Scrum werden die meisten Leute, die ihre Hausaufgaben machen, auf diese kleinen Informationen stoßen. Leute, die nach Kochbuchrezepten für das Projektmanagement suchen, werden dieses Detail normalerweise vermissen.

Was für mich Sinn macht, ist, sie zu bitten, zu beschreiben, wie sie einen Teil des Agile-Prozesses handhaben. Im Moment ist mein Favorit der Beginn einer Iteration, aber Sie könnten Ihren eigenen Favoriten entwickeln.

Fragen Sie: "Wenn Sie zu Beginn des Sprints einen Stapel Tickets haben, beschreiben Sie hier Ihren Workflow."

Wichtige Punkte, auf die Sie hier achten sollten:

• Schätzen die Entwickler die Tickets?
• Behalten Sie die Geschwindigkeit im Auge?
• Was passiert, wenn Ihre Schätzungen über Ihrer Geschwindigkeit liegen?
• Was passiert, wenn Ihre Schätzungen zu einem bestimmten Zeitpunkt mehr als Ihre Geschwindigkeit erreichen? (Achten Sie hier auf Spin: Reduzieren sie die Komplexität oder priorisieren sie neu oder marschieren sie das Entwicklungsteam einfach tot?)

Keiner von ihnen ist für sich genommen ein Deal Breaker, aber wenn Sie sich bei der Beantwortung dieser Fragen wundern, interessieren sie sich vielleicht für agile Rituale , nicht für die tatsächliche agile Entwicklung .