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

14

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.

indyK1ng
fuente
14
¿Les preguntas si son un cerdo o un pollo?
Robert Harvey
1
@Robert Lolwut?
Matthew leyó el
@ indyK1ng 1. ¿Conoces alguna empresa que sea realmente ágil? 2. La mayoría de las veces la metodología debe ajustarse a la realidad y viceversa. PD: Estoy de acuerdo con la palabra de moda!
Amir Rezaei

Respuestas:

8

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.

Martin Wickman
fuente
55
El estándar de facto es de 2 a 4 semanas. 1 semana de sprints ...? Hmm ... sospecharía.
Aaron McIver
55
No hay un "estándar"; Varía entre empresas / equipos / situaciones. Creo que la sobrecarga de Scrum es, como proporción de la longitud del sprint, demasiado derrochadora para sprints de una semana, por lo tanto, usamos dos.
Christopher
1
He probado muchas duraciones diferentes y me gusta 1 para proyectos muy pequeños en equipos pequeños, pero para proyectos de grandes empresas, 3 o 4 me dieron mejores resultados.
3
Creo que son estos términos de "real" versus "aguado" ágil lo que irrita mis plumas. Siempre he aplicado los conceptos y principios del Manifiesto Ágil, pero nunca he usado una de las versiones de marca de Ágil. Insistir en una sola de las muchas metodologías ágiles viola el primer principio del manifiesto. Pero entiendo lo que estás diciendo.
Berin Loritsch
2
Para mí, "real" ágil es ágil que aplica el manifiesto y sus 12 principios, independientemente de cómo se llame. Hay muchas palabras de moda que se suman al significado central de ágil y luego afirman que no eres ágil si no lo haces.
Berin Loritsch
6

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.

Mark Canlas
fuente
44
+1 Siempre es bueno encontrar formas de entrevistar a la empresa.
Jeremy Heiler
@Jeremy desafortunadamente no lo tomarían muy bien. ¡No lo recomendaría!
Amir Rezaei
@Amir: ¡Por favor explique! Nunca he dejado una entrevista sin que me pregunten si tengo alguna pregunta. ¿Qué tiene de malo que el buscador de trabajo quiera saber más sobre la empresa? Si no lo toman bien, ¡es una señal segura de que no quiero trabajar para ellos!
Jeremy Heiler
1
Sé que a algunas compañías en realidad no les gusta cuando su entrevistado no hace preguntas ... para ellos, muestra una falta de interés en el trabajo.
Rachel
2
Creo que pedirles "defender las metodologías ágiles" probablemente no sea el mejor método para preguntar;)
Matthew leyó el
6

Pregúnteles por qué lo usan .

Lo sabrás de inmediato.

usuario2567
fuente
8
Esto se puede responder con bastante facilidad, aunque con respuestas enlatadas. "Para reducir nuestro tiempo de comercialización y seguir siendo competitivos". Tiene que ser un enfoque más de ida y vuelta. Si el OP está familiarizado con Agile / Scrum y quiere estar seguro de que el negocio también lo está; Me gustaría saber que el OP debería tener una gran cantidad de preguntas sobre el asunto ... específicamente, qué les molestó en un lugar de empleo anterior y cómo podría la nueva empresa abordar esto.
Aaron McIver
2
La respuesta que mencionas no puede decirla alguien que entienda la agilidad. Es una buena indicación de que no saben por qué deberían usar scrum. Todas las empresas intentan reducir el tiempo de comercialización y seguir siendo competitivas. Si me responde la pregunta, yo respondería "es la única metodología adaptada para el desarrollo de software" o "aporta mucha visibilidad sobre lo que deberíamos mejorar".
@Pierre 303 Cualquier razón para sugerir por qué, desde una posición comercial, que la adopción ágil fue un proceso que podría aumentar nuestro tiempo de comercialización y seguir siendo competitivos con lanzamientos oportunos de nuestro software no es válida y definiría a esa persona como no sabiendo por qué debería utilizar Scrum? Debe comprender que los gerentes de contratación no siempre tienen una inclinación técnica, pero eso no significa que el uso de Scrum dentro de la organización sea en vano.
Aaron McIver
1
@Pierre 303 ¿Puedes elaborar un poco tu respuesta? La razón para usar cualquier método de desarrollo de software es "ofrecer un valor lo más eficiente posible a nuestros clientes" y eso se aplica tanto a RUP ágiles como a otros.
Martin Wickman
1
Totalmente de acuerdo. Pregúnteles por qué incluso eligieron Agile. Sólido. +1
Agile Scout
5

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.

Rachel
fuente
Buen punto con respecto a preguntar sobre SDLC. Sin embargo, he estado en una organización donde siguieron todos los pasos en SDLC pero el equipo aplicó mal la metodología.
Amir Rezaei
@Amir: Si ese fuera el caso, asumiría que al menos intentaban seguir la metodología ágil. Lo más probable es que tengan una buena razón para desviarse o no sepan lo que están haciendo y estarían dispuestos a aprender si se tomaran el tiempo para enseñarles.
Rachel
Tienen buena razón. Adaptan la metodología a su realidad.
Amir Rezaei
3

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.

Berin Loritsch
fuente
2

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.

Michael Brown
fuente
1
"Preguntar sobre TDD (desarrollo basado en pruebas) restar 2 puntos si no usan TDD y agregar 1 si lo hacen" no tiene sentido. Simplemente agregue 3 si lo hacen.
cbrandolino
Veo lo que estás diciendo ... No simplifiqué mi fórmula ... pero creo que mi punto es claro.
Michael Brown
1
¿WTF tiene que ver con CI y TDD con Agile? Claro, hace que la liberación sea más fácil, pero realmente no necesitas que funcione de manera ágil. Y créanme, conozco empresas con TDD y CI que NO son ágiles en absoluto.
gbjbaanb
TDD y CI por sí solos no hacen que un entorno sea ágil. Sin embargo, la falta de esos elementos es una señal de advertencia de que no hay un verdadero compromiso de ser ágil.
Michael Brown
2

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.

Jon Hopkins
fuente
2

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.

JohnFx
fuente
2

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.

marca
fuente
Esta es una pregunta que haría durante la parte de la entrevista "¿Tiene alguna pregunta para mí"? Estoy haciendo una pregunta para determinar si dicen la verdad cuando dicen que son ágiles. Ya he estado en un ambiente de vaquero y me gustaría evitar que eso suceda. Sé que hay organizaciones que usan ágil como palabra de moda, así que estoy tratando de filtrarlas. Además, las entrevistas van en ambos sentidos, estoy entrevistando a la empresa mientras me están entrevistando a mí.
indyK1ng
1

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.

Christopher Mahan
fuente
1

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.

kemiller2002
fuente
1

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.

Enrique
fuente
+1 IMO, lo primero que muere en una organización ágil-aspirante es la retrospectiva. Eso es realmente más un concepto Scrum, pero el ágil éxito viene con la comprensión de qué tan bien está habilitando su proceso en lugar de deshabilitar su organización. Sin algún mecanismo de introspección, no veo cómo eso es posible.
MIA
0
  • 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.
Eimantas
fuente
1
Honestamente, fallaría el cuarto punto. Sé lo ágil que es, y he leído una serie de recursos en línea sobre cómo diferentes personas abandonaron las cosas. Sin embargo, mi camino hacia lo ágil siempre ha sido personalizado para el equipo / entorno en el que trabajo.
Berin Loritsch
0

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.

JB King
fuente
0

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.

desaparecido en combate
fuente
0

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 .

RyanWilcox
fuente