Éliminer le vrai agile de buzzword agile dans une interview [fermé]

J'ai récemment interviewé des coopératives (stages rémunérés) et un grand nombre des entreprises avec lesquelles j'ai interviewé ont dit qu'elles utilisent Scrum ou une autre méthodologie agile (Scrum étant la plus populaire). Je sais qu'il y a de vrais magasins agiles et il y a des endroits qui disent qu'ils utilisent une méthodologie agile mais font vraiment autre chose et utilisent agile comme mot à la mode.

Ma question est, quelles sont les questions que je peux poser dans une interview qui séparerait ces magasins?

EDIT: Pendant que je recherche un stage, je pense que ces questions sont pertinentes pour tout le monde. La partie stage est contextuelle.

Je commence toujours par poser cette question:

Quelle est la durée de vos itérations?

Évaluez leur réponse:

1 semaine est génial, 2 semaines est super, 3 est ok et 4 médiocres. Plus longtemps que cela indique qu'ils ont du mal et plus de 8 semaines, c'est juste bizarre. Si la réponse est que cela dépend , vous savez qu'ils n'ont absolument aucune idée.

Suivi avec:

À quelle fréquence sortez-vous?

C'est pour vérifier la première question. La bonne réponse est quotidienne ou à la fin de chaque sprint . Un agiliste saurait qu'il ne devrait pas y avoir de différence technique entre une version interne et externe.

Demandez-leur de défendre les méthodologies agiles. Et puis demandez-leur de le réfuter en soulignant ses faiblesses. Des points bonus s'ils peuvent naviguer sur ce cours sans le salir de mots à la mode insignifiants.

Demandez-leur pourquoi ils l'utilisent .

Vous le saurez immédiatement.

Je leur demanderais de décrire le cycle de vie du développement logiciel lors de l'utilisation de la méthodologie Agile. S'ils le connaissent, ils devraient être en mesure de décrire avec précision chaque phase du SDLC.

EDIT : Je viens de réaliser que vous posiez la question du point de vue de la personne interrogée, pas de l'intervieweur. Dans ce cas, je les interrogerais probablement sur leur SDLC et verrais si les étapes qu'ils disent prendre correspondent à ce qu'est vraiment Agile.

L'approche que je prends n'a vraiment pas grand-chose à voir avec les mots à la mode agiles, mais elle a à voir avec les pratiques agiles. L'une des similitudes dans toutes les équipes agiles est la courte itération, la plupart des gens obtiennent cette partie (c'est l'un des 12 principes derrière l'agile sur le site http://agilemanifesto.org ). Le but de la courte itération est d'obtenir un retour précoce sur la qualité du logiciel développé. C'est là que je commence.

1. Renseignez-vous sur les tests unitaires. La très grande majorité des réponses que j'ai reçues ici ont été "euh, nous avons supprimé cela parce que nous n'avions pas assez de temps" (note: 2 premiers drapeaux d'avertissement - pas de temps et pas de tests unitaires)
2. Demandez quand le logiciel a été testé et à quelle fréquence. Les réponses peuvent devenir créatives ici. Surtout si l'équipe utilise "Agile" comme excuse pour mettre de côté tout processus. Si la réponse est vers la fin du projet, ou autre chose qu'à chaque itération, ils ne savent pas ce qu'est l'agilité.

Jusqu'à présent, je n'ai pas eu à aller plus loin pour savoir que la personne ne sait pas ce qu'est l'agilité. Je n'ai également participé qu'à un seul entretien avec une entreprise qui disposait déjà de processus agiles bien établis.

Il y a plus d'une façon de faire de l'agile, et je me soucie plus des principes de l'agilité que de n'importe quelle marque ou mot à la mode.

Il y a plusieurs choses qui séparent ceux qui "agissent" de ceux qui sont agiles:

• Renseignez-vous sur l'intégration continue s'ils n'utilisent pas CI, déduisez un point. Ajoutez un point s'ils le sont. Points bonus:
  1. Ajoutez 1 s'ils utilisent des validations en deux phases (le code doit être généré avec succès avant que le développeur puisse s'enregistrer).
  2. Ajoutez 1 si le script de construction inclut l'exécution d'une suite de tests
  3. Ajoutez 1 si la construction échoue si la couverture du code tombe en dessous d'un certain seuil
  4. Ajoutez 2 s'il est possible de déployer l'application pour qu'elle soit prête à fonctionner en un clic
• Renseignez-vous sur TDD (développement piloté par les tests) soustrayez 2 points s'ils n'utilisent pas TDD ajoutez 1 s'ils le font.
• Renseignez-vous sur les itérations, combien de temps sont-elles (soustrayez 2 points s'ils ne font pas de développement itératif, soustrayez 1 si l'itération dure plus d'un mois ou moins de deux semaines, ajoutez 1 si ses 2 semaines)
• Demandez comment l'estimation est faite, ajoutez 1 s'ils utilisent des points d'histoire, ajoutez 2 s'ils planifient le poker ou quelque chose de similaire, soustrayez-en un s'ils utilisent des estimations de temps absolu, soustrayez 2 si les développeurs ne sont pas impliqués dans le processus d'estimation.
• Demander comment les fonctionnalités sont construites ajouter 1 si un développeur est responsable de la fonctionnalité de haut en bas (tranche verticale) soustraire 1 si les développeurs sont responsables d'une couche spécifique (tranche horizontale)

Il existe un certain nombre d'autres indicateurs, mais ceux-ci à eux seuls devraient vous donner une bonne image si l'équipe est réellement agile. Une équipe avec 5 points ou plus se qualifie. Tout le reste signifie qu'ils "agissent" de manière agile. L'agilité ne se limite pas aux itérations, elle permet à l'équipe de s'adapter facilement au changement. Si vous écrivez de manière itérative du code non testé et confus, écrit sous des pressions externes, eh bien, vous écrivez simplement du code de merde dans les itérations. Notez que vous pouvez obtenir beaucoup de points uniquement à partir de la puce d'intégration continue. Mais cela ne suffit pas à vous ramener à plus de 5 si vous ne suivez pas les autres pratiques.

Comme pour toutes ces choses, vous demandez des exemples concrets de projets sur lesquels ils ont travaillé , pas de la théorie. Accepter des réponses théoriques est le moyen le plus simple d'être dupé par quelqu'un qui n'y a pas été.

Donc, vous demandez à parler aux développeurs réels et demandez des choses comme:

• Parlez-moi donc de votre projet actuel. Quel était l'objectif final initial? Que contenait le premier sprint et que pouvait faire le logiciel à la fin?
• Pouvez-vous me donner des exemples de fonctionnalités ou de conception sur votre dernier projet qui, selon vous, ont fonctionné différemment que si vous l'aviez fait en tant que projet en cascade?
• Donnez-moi un exemple de la façon dont un gros morceau de fonctionnalité a été décomposé sur plusieurs sprints? À quelles inefficacités / retouches cela a-t-il conduit? Et quelles améliorations ou changements par rapport à ce qui était initialement prévu.
• Lorsque vous avez commencé à travailler avec Agile, quelles choses que vous faisiez au cours des premiers sprints avez-vous changé au cours des sprints (ou projets) ultérieurs au fur et à mesure que vous vous familiarisiez avec la méthodologie?

Continuez à les ramener aux projets réels - qu'essayaient-ils de réaliser, des exemples de ce qui était dans chaque sprint, des exemples du genre de choses qui ont surgi lors des réunions, des exemples d'interactions avec les utilisateurs.

N'acceptez pas la théorie, n'acceptez pas les projets des autres, seules les choses sur lesquelles ils ont eux-mêmes travaillé et dont ils peuvent parler par expérience directe.

Ils devraient être un menteur incroyablement bon pour pouvoir rattraper 10 à 15 minutes de choses qui vous dépasseraient si vous les connaissiez.

Si vous ne voulez pas les rendre défensifs, j'ai trouvé que la question suivante amorcera une conversation qui vous dira tout ce que vous devez savoir s'ils utilisent réellement une approche Agile ou se contentent de le payer du bout des lèvres:

Qui est responsable de la rédaction des exigences / spécifications pour vos projets logiciels?

J'ai vu de nombreuses entreprises qui prétendaient être agiles et voulaient même une certification Scrum Master décrire un grand processus de conception classique lorsque vous posez des questions sur leur processus de collecte des exigences.

Ce qui me frappe, c'est que vous recherchez un stage, ce qui m'amène à me demander quel est votre objectif en posant ces questions. Essayez-vous de poser une question sur l'agile pour que l'entretien se déroule bien ou refuseriez-vous réellement une offre d'une entreprise utilisant buzzword agile? Si vous cherchez vraiment un environnement agile, choisissez une question (pourquoi utilisez-vous agile, quelle heure sont vos standups, combien de temps sont les itérations, peu importe), et posez-la par téléphone ou dans un e-mail sans perdre de temps sur un entretien. Si vous recherchez un revenu, attendez l'entretien et posez des questions qui montrent vos connaissances / votre enthousiasme sur les méthodologies agiles (parlez-moi de votre cycle de vie de développement logiciel) sans embarrasser l'intervieweur s'il utilise une abomination semi-agile.

Je leur demande de décrire une demande type, de la création à la livraison finale au client.

Je demande également s'ils gèrent généralement le support à long terme pour le produit qu'ils fournissent au client (parce que les équipes qui fabriquent généralement un meilleur produit, sachant qu'elles seront celles qui le répareront à 1 h du matin le dimanche pendant le week-end de la fête du Travail).

Je demande également comment la direction voit son rôle au cours du processus. Il est assez facile de voir s'ils ont l'attitude de feu et d'oubli (nous lançons, vous volez, nous vous demandons si vous atteignez la cible) ou l'attitude "nous vous aidons à ramer le bateau en amont de la rivière".

Ceux-ci vous montreront généralement comment ils font vraiment les choses, pas comment ils sont censés les faire, ou comment ils prétendent les faire.

Le meilleur moyen que j'ai trouvé pour voir si quelqu'un sait ce qu'il fait du point de vue de SDLC est de lui demander où il a foiré dans le passé et comment il procéderait différemment. Les gens qui ont traversé le processus plusieurs fois et qui admettront pleinement où ils ont foiré, et sont généralement assez détaillés. Ils sont ouverts à en discuter et témoignent d'un certain niveau de confiance, car ils admettent qu'ils ne sont pas parfaits. Éviter la question en disant "Ils le font à peu près tout le temps", est un vrai signe d'avertissement.

Combien de fois ils sortent en production. Plus le temps est long, moins ils sont Agiles. Combien de fois ils ont des ateliers de réflexion. S'ils savent de quoi vous parlez, tant mieux. À quelle fréquence ont-ils des réunions de «rattrapage» d'équipe? Chaque jour est super, chaque mois est mauvais. Ont-ils un serveur d'intégration continue. Ce n'est pas un must have mais vous donnera une idée de leur utilisation des outils. À quelle fréquence les utilisateurs finaux s'assoient-ils avec les développeurs? Cela ne signifie jamais qu'ils ne sont pas agiles.

• Donnez-leur une situation et demandez-leur de la résoudre de manière agile;
• Demandez-leur quelles sont leurs pratiques agiles préférées (planification de poker, programmation de paires, bdd / tdd, kanban);
• Demandez-leur pourquoi ils n'ont pas choisi ou abandonné d' autres méthodologies (cascade, rup, etc.)
• Quelles sont les personnes les plus connues dans le monde de la méthodologie agile, qui ont inventé le terme et quels livres les plus populaires sont écrits à ce sujet.

S'ils utilisent Scrum, vous pouvez demander si vous pouvez regarder le prochain stand-up. S'ils ne les ont pas, demandez-leur pourquoi, car cela ferait généralement partie de la méthodologie.

Il y a certains aspects d'Agile qui méritent également d'être mentionnés. Demandez à voir le story-board, quelle est la taille du journal de bord, ou quels ont été certains des faits saillants de la dernière rétrospective, pour quelques autres idées. La clé ici est d'arriver à quelque chose de tangible qui montre ce qui se passe par rapport à des mots tout simplement moelleux qui ne signifient pas vraiment grand-chose.

Demandez-leur comment ils gèrent le design. S'ils vous disent qu'il n'y a pas de design en agile, ils ne l'obtiennent pas.

Demandez-leur comment ils gèrent l'évolution des exigences. S'il semble que la modification des exigences a son propre processus, ils ne l'obtiennent probablement pas.

S'ils prétendent utiliser Scrum, regardez comment ils l'écrivent. Les magasins qui font bien Scrum ont tendance à savoir assez bien comment l'écrire. Indice: ce n'est pas SCRUM.

Cela peut sembler du pédantisme, mais je suis fermement convaincu que pour appliquer avec succès un modèle de processus comme Scrum, RUP, XP ou autre, vous devez comprendre la philosophie et le «pourquoi» afin de savoir comment vous adapter. le «quoi» à votre organisation. Dans Scrum, la plupart des gens qui font leurs devoirs trouveront ce petit renseignement. Les gens qui recherchent des recettes de livres de cuisine pour la gestion de projet manqueront généralement ce détail.

Ce qui est logique pour moi, c'est de leur demander de décrire comment ils gèrent une partie du processus Agile. En ce moment, mon préféré est le début d'une itération, mais vous pouvez développer votre propre favori.

Demandez: "compte tenu d'une pile de billets au début du sprint, décrivez votre flux de travail à partir d'ici"

Points clés à écouter ici:

• Les développeurs estiment-ils les billets?
• Gardez-vous une trace de la vitesse?
• Que se passe-t-il lorsque vos estimations dépassent votre vitesse?
• Que se passe-t-il lorsque vos estimations dépassent votre vitesse lorsque vous avez un délai? (Faites attention à la rotation ici: réduisent-ils la complexité, ou redéfinissent-ils les priorités, ou simplement mettent-ils à mort l'équipe de développement?)

Aucun de ceux-ci n'est un facteur de rupture en soi, mais si leurs réponses à suffisamment de ces questions vous font vous demander, alors peut-être qu'ils sont intéressés par les rituels agiles , pas par le développement agile réel .