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.
Respuestas:
Siempre comienzo haciendo esta pregunta:
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:
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.
fuente
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.
fuente
Pregúnteles por qué lo usan .
Lo sabrás de inmediato.
fuente
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.
fuente
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.
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.
fuente
Hay varias cosas que separan a aquellos que están "haciendo" ágilmente de aquellos que son ágiles:
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.
fuente
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:
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.
fuente
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:
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
fuente
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.
fuente
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.
fuente
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í:
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 .
fuente