Eliminando agile real de palabra de moda ágil en una entrevista [cerrado]

He estado entrevistando para cooperativas (pasantías pagas) últimamente y una gran cantidad de las empresas con las que he estado entrevistando han dicho que usan Scrum o alguna otra metodología ágil (scrum es el más popular). Sé que hay tiendas ágiles reales y hay lugares que dicen que usan una metodología ágil pero que realmente están haciendo otra cosa y están usando ágil como palabra de moda.

Mi pregunta es, ¿cuáles son algunas preguntas que puedo hacer en una entrevista que separarían estas tiendas?

EDITAR: Mientras estoy buscando una pasantía, siento que estas preguntas son relevantes para todos. La parte de pasantía es el contexto.

Siempre comienzo haciendo esta pregunta:

¿Cuál es la duración de tus iteraciones?

Califica su respuesta:

1 semana es increíble, 2 semanas es genial, 3 está bien y 4 mediocres. Más tiempo que eso indica que están luchando y más de 8 semanas es simplemente extraño. Si la respuesta es depende , sabes que no tienen idea alguna.

Ir a la par de:

¿Con qué frecuencia liberas?

Esto es para verificar la primera pregunta. La respuesta correcta es diaria o al final de cada sprint . Un agilista sabría que no debería haber diferencias técnicas entre una versión interna y externa.

Pídales que defiendan metodologías ágiles. Y luego pídales que lo refuten describiendo sus debilidades. Puntos de bonificación si pueden navegar este curso sin ensuciarlo con palabras de moda sin sentido.

Pregúnteles por qué lo usan .

Lo sabrás de inmediato.

Les pediría que describieran el ciclo de vida de desarrollo de software cuando usen la metodología Agile. Si están familiarizados con él, deberían poder describir cada fase del SDLC con precisión.

EDITAR : Acabo de darme cuenta de que estabas preguntando desde el punto de vista del entrevistado, no del entrevistador. En ese caso, probablemente les preguntaría sobre su SDLC y vería si los pasos que dicen que toman coinciden con lo que realmente es Agile.

El enfoque que tomo realmente tiene poco que ver con las palabras de moda ágiles, pero tiene que ver con las prácticas ágiles. Uno de los puntos en común en todos los equipos ágiles es la iteración corta, la mayoría de las personas obtienen esa parte (es uno de los 12 principios detrás de ágil en el sitio http://agilemanifesto.org ). El propósito de la iteración corta es obtener retroalimentación temprana sobre la calidad del software desarrollado. Aquí es donde empiezo.

1. Pregunte sobre las pruebas unitarias. De manera abrumadora, la respuesta que recibí aquí fue "uh, cortamos eso porque no teníamos suficiente tiempo" (nota: las primeras 2 banderas de advertencia: sin tiempo ni pruebas de unidad)
2. Pregunte cuándo se probó el software y con qué frecuencia. Las respuestas pueden ser creativas aquí. Particularmente si el equipo usa "Agile" como excusa para descartar todo el proceso. Si la respuesta es hacia el final del proyecto, o cualquier otra cosa que no sea con cada iteración, no saben qué es ágil.

Hasta ahora, no he tenido que ir más allá de esto para saber que la persona no sabe qué es ágil. También solo estuve en una entrevista con una empresa que ya tenía procesos ágiles bien establecidos.

Hay más de una forma de hacer ágil, y me importan más los principios de ágil que cualquier marca o palabra de moda en particular.

Hay varias cosas que separan a aquellos que están "haciendo" ágilmente de aquellos que son ágiles:

• Pregunte acerca de la integración continua si no están usando CI deducir un punto. Agrega un punto si lo son. Puntos extra:
  1. Agregue 1 si usan confirmaciones de dos fases (el código debe compilarse correctamente antes de que el desarrollador pueda registrarse).
  2. Agregue 1 si el script de compilación incluye ejecutar un conjunto de pruebas
  3. Agregue 1 si la compilación falla si la cobertura del código cae por debajo de un cierto umbral
  4. Agregue 2 si es posible implementar la aplicación para que esté lista para ejecutarse con un solo clic
• Pregunte sobre TDD (desarrollo basado en pruebas) reste 2 puntos si no usan TDD, agregue 1 si lo hacen.
• Pregunte acerca de las iteraciones, cuánto duran (reste 2 puntos si no realizan desarrollo iterativo, reste 1 si la iteración es más larga que un mes o menos de dos semanas, agregue 1 si son 2 semanas)
• Pregunte cómo se realiza la estimación, agregue 1 si usan puntos de historia, agregue 2 si planean póker o algo similar, reste uno si usan estimaciones de tiempo absoluto, reste 2 si los desarrolladores no están involucrados en el proceso de estimación.
• Pregunte cómo se crean las características, agregue 1 si un desarrollador es responsable de la característica de arriba a abajo (corte vertical) reste 1 si los desarrolladores son responsables de una capa específica (corte horizontal)

Hay una serie de otros indicadores, pero esos solo deberían darle una buena imagen si el equipo es realmente ágil. Un equipo con 5 puntos o más califica. Cualquier otra cosa significa que están "haciendo" ágilmente. Agile no se trata solo de iteraciones, se trata de permitir que el equipo se adapte a los cambios fácilmente. Si está escribiendo iterativamente código confuso, no probado, escrito bajo presiones externas, bueno, simplemente está escribiendo código basura en iteraciones. Tenga en cuenta que puede obtener muchos puntos solo con la viñeta de integración continua. Pero eso por sí solo no es suficiente para llevarte a más de 5 si no estás siguiendo las otras prácticas.

Al igual que con todas estas cosas, pides ejemplos del mundo real de proyectos en los que han trabajado , no teoría. Aceptar respuestas teóricas es la forma más fácil de ser engañado por alguien que realmente no ha estado allí.

Entonces pides hablar con desarrolladores reales y preguntas como:

• Así que háblame de tu proyecto actual. ¿Cuál fue el objetivo final inicial? ¿Qué contenía el primer sprint y qué podía hacer el software al final?
• ¿Me puede dar ejemplos de funcionalidad o diseño en su último proyecto que cree que funcionó de manera diferente a como lo había hecho como un proyecto en cascada?
• ¿Dame un ejemplo de cómo se desglosó una gran pieza de funcionalidad en varios sprints? ¿A qué ineficiencias / reprocesos condujo esto? Y qué mejoras o cambios de lo que inicialmente se previó.
• Cuando comenzaste a trabajar con Agile, ¿qué cosas que estabas haciendo durante los primeros sprints cambiaste durante los sprints (o proyectos) posteriores a medida que te acostumbraste a la metodología?

Continúe llevándolos a los proyectos reales : qué estaban tratando de lograr, ejemplos de lo que había en cada sprint, ejemplos de las cosas que surgieron en las reuniones, ejemplos de interacciones con los usuarios.

No acepte la teoría, no acepte proyectos de otras personas, solo cosas en las que ellos mismos han trabajado y de las que pueden hablar por experiencia de primera mano.

Tendrían que ser un mentiroso increíblemente bueno para poder inventar 10 a 15 minutos de cosas que te pasarían si supieras tus cosas.

Si no quiere ponerlos a la defensiva, he descubierto que la siguiente pregunta iniciará una conversación que le dirá todo lo que necesita saber sobre si realmente están utilizando un enfoque ágil o si simplemente le están pagando:

¿Quién es responsable de escribir los requisitos / especificaciones para sus proyectos de software?

He visto a numerosas compañías que afirmaban ser ágiles e incluso querían una certificación Scrum Master para describir un proceso clásico de diseño inicial grande cuando preguntas sobre el proceso de recopilación de requisitos.

Lo que me llama la atención es que estás buscando una pasantía, lo que me lleva a preguntarme cuál es tu propósito al hacer estas preguntas. ¿Estás tratando de hacer una pregunta sobre ágil para que la entrevista salga bien, o realmente rechazarías una oferta de una compañía que usa ágilmente la palabra de moda? Si realmente está buscando un entorno ágil, elija una pregunta (por qué usa ágil, a qué hora son sus standups, cuánto duran las iteraciones, lo que sea), y pregúntelo por teléfono o en un correo electrónico sin perder tiempo en un entrevista. Si está buscando ingresos, espere la entrevista y haga preguntas que muestren su conocimiento / entusiasmo acerca de las metodologías ágiles (Cuénteme sobre su ciclo de vida de desarrollo de software) sin avergonzar al entrevistador si está usando alguna abominación semi-ágil.

Les pido que describan una solicitud típica, desde el inicio hasta la entrega final al cliente.

También pregunto si normalmente manejan el soporte a largo plazo para el producto que proporcionan al cliente (porque los equipos que lo hacen generalmente construirán un mejor producto, sabiendo que serán los que lo arreglen a la 1AM del domingo durante el fin de semana del Día del Trabajo).

También pregunto cómo ve la gerencia su rol durante el proceso. Es bastante fácil ver si tienen la actitud de disparar y olvidar (lanzamos, usted vuela, le preguntamos si da en el blanco) o la actitud de "le ayudamos a remar el bote río arriba".

En general, esto le mostrará cómo realmente hacen las cosas, no cómo se supone que deben hacerlas o cómo afirman que las hacen.

La mejor manera que he encontrado para ver si alguien sabe lo que está haciendo desde una perspectiva SDLC es preguntarle dónde se equivocaron en el pasado y cómo lo harían de manera diferente. Las personas que han pasado por el proceso varias veces y admitirán por completo dónde se equivocaron, y en general son bastante detalladas. Su apertura para discutirlo muestra un nivel de confianza, porque admiten que no son perfectos. Evitar la pregunta diciendo "Casi siempre lo hacen bien", es una señal de advertencia real.

Con qué frecuencia se lanzan a producción. Cuanto más largo es el tiempo, menos ágiles son. Con qué frecuencia tienen talleres de reflexión. Si saben de lo que estás hablando, entonces bien. ¿Con qué frecuencia tienen reuniones de equipo para ponerse al día? Diario es genial, mensual es malo. ¿Tienen un servidor de integración continua? Esto no es imprescindible, pero le dará una idea sobre el uso de herramientas. ¿Con qué frecuencia los usuarios finales se sientan con los desarrolladores? Nunca significa que no son ágiles.

• Déles una situación y pídales que la resuelvan de manera ágil;
• Pregúnteles sobre sus prácticas ágiles favoritas (planificación de póker, programación de parejas, bdd / tdd, kanban);
• Pregúnteles por qué no eligieron o se mudaron de otro metodologías (cascada, ruptura, etc.)
• Cuáles son las personas más conocidas en el mundo de la metodología ágil, quienes acuñaron el término y qué libros más populares se escriben al respecto.

Si están usando Scrum, puedes preguntar si puedes ver el próximo stand-up. Si no los tienen, pregunte por qué no, ya que eso generalmente sería parte de la metodología.

Hay algunos aspectos de Agile que también merecen ser mencionados. Pida ver el guión gráfico, qué tan grande es el registro posterior o cuáles fueron algunos de los aspectos más destacados en la última retrospectiva, para algunas otras ideas. La clave aquí es llegar a algo tangible que muestre lo que está sucediendo en comparación con solo palabras esponjosas que realmente no significan mucho.

Pregúnteles cómo manejan el diseño. Si te dicen que no hay un diseño ágil, no lo están entendiendo.

Pregúnteles cómo manejan los requisitos cambiantes. Si parece que los requisitos cambiantes tienen su propio proceso, probablemente no lo estén obteniendo.

Si dicen usar Scrum, mira cómo lo escriben. Las tiendas que hacen bien Scrum tienden a saber bastante bien cómo escribirlo. Pista: no es SCRUM.

Puede parecer una pedantería, pero creo firmemente que para aplicar con éxito una plantilla de proceso como Scrum, RUP, XP o lo que sea, debe comprender la filosofía y el "por qué" para que sepa cómo adaptarse El "qué" para su organización. En Scrum, la mayoría de las personas que están haciendo su tarea se encontrarán con esa pequeña información. Las personas que buscan recetas de libros de cocina para la gestión de proyectos generalmente perderán ese detalle.

Lo que tiene sentido para mí es pedirles que describan cómo manejan parte del proceso ágil. En este momento, mi favorito es el comienzo de una iteración, pero podría desarrollar su propio favorito.

Pregunte: "dado un montón de tickets al comienzo del sprint, describa su flujo de trabajo desde aquí"

Puntos clave para escuchar aquí:

• ¿Los desarrolladores estiman las entradas?
• ¿Hace un seguimiento de la velocidad?
• ¿Qué sucede cuando sus estimaciones llegan a más de su velocidad?
• ¿Qué sucede cuando tus estimaciones llegan a más de tu velocidad cuando tienes una fecha límite? (Esté atento al giro aquí: ¿reducen la complejidad, o vuelven a priorizar, o simplemente marchan a muerte al equipo de desarrollo?)

Ninguno de estos es un factor decisivo por sí mismo, pero si sus respuestas a suficientes de estas preguntas te hacen preguntarte, entonces tal vez estén interesados ​​en rituales ágiles , no en un desarrollo ágil real .