Eliminación real ágil de buzzword ágile en una entrevista

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 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 ninguna pista.

Seguimiento con:

  

¿Con qué frecuencia sueltas?

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

Pídales que defiendan metodologías ágiles. Y luego pídales que lo refuten al describir 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 inmediatamente.

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

EDIT : Me di cuenta de que estaba preguntando desde el punto de vista del entrevistado, no del entrevistador. En ese caso, probablemente les pregunte acerca de su SDLC y vean 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. Una de las características comunes en todos los equipos ágiles es la iteración corta, la mayoría de la gente obtiene esa parte (es uno de los 12 principios detrás de ágil en El sitio enlace ). 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 acerca de las pruebas unitarias. De manera abrumadora, la respuesta que recibí aquí fue "eh, lo eliminamos porque no tuvimos 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 desechar 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 lejos para saber que la persona no sabe qué es ágil. También he estado solo en una entrevista con una compañía que ya tenía establecidos procesos ágiles 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" ágil de aquellos que son ágiles:

• Pregunte acerca de la integración continua si no están usando el CI deduce un punto. Añade un punto si lo son. Puntos extra:
  1. Agregue 1 si usan dos confirmaciones de fase (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 guiado por pruebas) reste 2 puntos si no usan TDD, agregue 1 si lo hacen.
• Pregunte acerca de las iteraciones, ¿cuánto tiempo duran (reste 2 puntos si no hacen el 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 planifican póquer o algo similar, reste uno si usan estimaciones de tiempo absolutas, reste 2 si los desarrolladores no están involucrados en el proceso de estimación.
• Pregunte cómo se construyen las funciones agregue 1 si un desarrollador es responsable de la función de arriba a abajo (rebanada vertical) reste 1 si los desarrolladores son responsables de una capa específica (rebanada horizontal)

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

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

Por lo tanto, pide hablar con los desarrolladores reales y pregunta cosas como:

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

Sigue trayéndolos de vuelta a los proyectos reales : ¿qué intentaban lograr, ejemplos de lo que había en cada carrera, ejemplos del tipo de cosas que surgieron en las reuniones, ejemplos de interacciones con Los usuarios.

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

Tendrían que ser un mentiroso asombrosamente bueno para poder ganar entre 10 y 15 minutos de cosas que podrían superarte si sabes tus cosas.

Si no quiere que estén a la defensiva, encontré que la siguiente pregunta iniciará una conversación que le dirá todo lo que necesita saber sobre si en realidad están usando un enfoque ágil o simplemente están pagando el servicio:

  

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

He visto a numerosas compañías que decían ser ágiles e incluso querían que una certificación Scrum Master describiera un proceso de diseño clásico por adelantado cuando preguntas acerca del proceso de recopilación de requisitos.

Lo que más me llama la atención es que está buscando una pasantía, lo que me lleva a preguntarme cuál es su propósito al hacer estas preguntas. ¿Está tratando de hacer una pregunta sobre agile para que la entrevista salga bien, o en realidad rechazaría una oferta de una empresa que usa buzzword agile? Si realmente estás buscando un entorno ágil, elige una pregunta (¿por qué usas ágil, a qué hora son tus standups, cuánto tiempo son las iteraciones, lo que sea) y pregúntalo por teléfono o en un correo electrónico sin perder tiempo en una entrevista. Si está buscando ingresos, espere la entrevista y haga preguntas que muestren su conocimiento / entusiasmo por las metodologías ágiles (Hábleme de 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 generalmente manejan el soporte a largo plazo para el producto que le brindan al cliente (porque los equipos que lo hacen generalmente construirán un mejor producto, sabiendo que serán los que lo arreglarán a la 1AM el domingo durante el Día del Trabajo fin de semana).

También pregunto cómo la administración ve su papel durante el proceso. Es bastante fácil ver si tienen la actitud de disparar y olvidar (lanzamos, usted vuela, le preguntamos si alcanza el objetivo) o la actitud de "le ayudamos a remar el bote por el río".

Por lo general, estos te mostrarán cómo realmente hacen las cosas, no cómo se supone que deben hacerlas o cómo pretenden hacerlas.

La mejor manera que he encontrado para ver si alguien sabe lo que están haciendo desde una perspectiva de SDLC es preguntándoles dónde se equivocaron en el pasado y cómo lo harían de manera diferente. Las personas que han pasado por el proceso unas cuantas veces y admitirán completamente dónde cometieron el error, y en general son bastante detalladas. La apertura para discutirlo muestra un nivel de confianza, porque admiten que no son perfectos. Evitar la pregunta diciendo "prácticamente lo hacen bien todo el tiempo" es una verdadera señal de advertencia.

Con qué frecuencia se lanzan a producción. Cuanto más largo sea el tiempo, menos ágiles son. Cuantas veces tienen talleres de reflexión. Si saben de lo que estás hablando, bueno. ¿Con qué frecuencia tienen reuniones de 'catchup' de equipo? Diario es genial, mensual es malo ¿Tienen un servidor de integración continua? Esto no es obligatorio, pero le dará una idea sobre el uso de las herramientas. ¿Con qué frecuencia los usuarios finales se sientan con los desarrolladores? Nunca significa que no sean ágiles.

• Dales una situación y pídeles que lo resuelvan de manera ágil;
• Pregúnteles sobre sus prácticas ágiles favoritas (planificación de póker, programación en parejas, bdd / tdd, kanban);
• Pregúnteles por qué no eligieron o se movieron de otras metodologías (cascada, rup, 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 vale la pena mencionar. Pida ver el panel de la historia, qué tan grande es el registro de vuelta, o cuáles fueron algunos de los puntos 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 suaves 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 recibiendo.

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 estar usando Scrum, mira cómo lo escriben. Las tiendas que hacen Scrum también saben cómo escribirlo. Sugerencia: no es SCRUM.

Eso 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é" Cómo adaptar el "qué" a tu organización. En Scrum, la mayoría de las personas que están haciendo su tarea se encontrarán con un poco de información. Las personas que buscan recetas de libros de cocina para la gestión de proyectos generalmente se perderán ese detalle.

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

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

Puntos clave para escuchar aquí:

• ¿Los desarrolladores estiman las entradas?
• ¿Mantienes un registro de la velocidad?
• ¿Qué sucede cuando sus estimaciones son mayores que su velocidad?
• ¿Qué sucede cuando sus estimaciones superan su velocidad cuando tiene una fecha límite? (Esté atento a los giros aquí: ¿reducen la complejidad, cambian las prioridades o simplemente marcan al equipo de desarrollo?)

Ninguno de estos es un factor de ruptura en sí mismo, pero si sus respuestas a una cantidad suficiente de estas preguntas te hacen pensar, entonces tal vez estén interesados en los rituales ágiles, no en el desarrollo ágil .