que - metodologias agiles

¿Los equipos que trabajan en Agile son típicamente resistentes a la contratación de personas que no han trabajado en Agile? (14)

Absolutamente si

Hay mucho trabajo en equipo y confía en tus compañeros de forma ágil y específicamente en programación extrema. Necesita saber que otras personas están escribiendo pruebas decentes y no están rompiendo su código. Los buenos desarrolladores de XP no quieren que haya gente en el equipo que va a hacer su trabajo mucho más difícil.

No hay nada de malo en ser un principiante, o alguien nuevo en un equipo, pero hay un elemento de construcción de confianza al igual que lo haría para obtener los derechos de los usuarios en código abierto .

En estos días, todos dicen que son ágiles y si ofrecen suficiente dinero, prácticamente todos los que tengan la menor habilidad técnica solicitarán el trabajo ... así que espere que la gente lo haga pasar por una entrevista de programación en pareja .

Típicamente necesitamos saber:

¿Puedes realmente emparejar el programa?
¿Realmente sabes cómo hacer TDD?
¿Estás diciendo estas cosas o puedes demostrar que las haces?
¿Va a tomar la iniciativa o está esperando que un "gerente de proyecto" de la vieja escuela le diga qué hacer?

Cosas que te ayudarán a contratarte en una tienda ágil:

Ha intentado introducir el desarrollo impulsado por pruebas en algún lugar, incluso si no obtuvo la aceptación. (Funcionó para mí ...)
Tiene un código de muestra que escribió, o un proyecto de código abierto en el que puede demostrar el desarrollo basado en pruebas , compilaciones automatizadas ...
Encuentras que has trabajado en equipos con ciclos de lanzamiento cortos ...

Como desarrollador que nunca ha trabajado específicamente en Agile (pero ha trabajado en tiendas TDD), veo empleadores que están ejecutando tiendas Agile que se resisten a contratar a alguien que no ha trabajado en Agile. Me he encontrado con esto unas cuantas veces en los últimos años. ¿Es realmente eso lo fundamental de un cambio de filosofía? Después de trabajar en TDD, casi puedo hacer un argumento para no contratar a alguien que nunca ha hecho TDD (cuando trabaja en un entorno TDD pesado). Tal vez no entiendo Agile y la diferencia entre él y TDD.

Realmente me gustaría trabajar en Agile, pero este parece ser uno de esos momentos en los que tienes que tener la experiencia para obtener la experiencia. Claro, puedes hacerlo por tu cuenta, pero eso no califica si me preguntas. Como empleador, realmente no lo llamaría aplicable.

Agile no es una filosofía de ingeniería en sentido estricto (TDD, Peer Programming, etc.) son prácticas de ingeniería que Agile utiliza, sino que Agile es una metodología de gestión. Como tal, es más importante que alguien esté abierto a la mentalidad que Agile exige, en lugar de que ellos hayan trabajado en una tienda Agile antes. Sí, realmente es una filosofía y enfoque diferente al desarrollo de software. Las personas que esperan todo por adelantado y que se les diga lo que deben hacer estarán muy fuera de lugar en un entorno ágil.

Cuando he entrevistado a personas, les pregunto si tienen alguna experiencia o conocimiento ágil, pero lo que realmente busco son algunos de los siguientes:

Mentalidad flexible
Confianza para permitir el autoempoderamiento (crítico en cualquier entorno ágil)
Capacidad de autoasignar tareas
Habilidades de comunicación (top 3 más importantes)
Ok con instrucciones vagas, capaces de auto-enseñar

Esas son algunas de las cualidades que creo que califican a alguien para trabajar en un entorno Agile.

Comprender cuáles son los principios básicos de Agile es importante para comprender Agile. TDD es solo una pequeña parte de Agile y más específicamente XP (Programación Extrema).

Primero echaría un vistazo al Manifiesto Ágil:

Individuos e interacciones sobre procesos y herramientas.
Software de trabajo sobre documentación completa.
Colaboración del cliente en la negociación de contratos.
Respondiendo al cambio siguiendo un plan.
Es decir, mientras hay valor en los elementos de la derecha, valoramos los elementos de la izquierda más.

Luego echaría un vistazo al proceso SCRUM (que también es una pequeña parte de Agile) para ver qué hay involucrado allí.

Cuando entrevisto a los desarrolladores, veo que tienen una comprensión de Agile y lo que eso conlleva para que luego pueda determinar si el entorno / mentalidad ágil es uno en lo que les gustaría trabajar.

Creo que es un caso típico de insistir demasiado en un conjunto de habilidades específicas. Como los empleadores que no quieren a alguien que conoce a JBoss cuando usan BEA para su servidor de aplicaciones.

Un buen empleador reconocerá si alguien es adaptable a un método ágil o no. Ahora, si tienen dos candidatos iguales, tal vez sea un poco diferente.

Cualquier compañía u oportunidad que dicte el SDLC por práctica en lugar de la mejor opción para el proyecto / situación actual ya está mostrando señales de sus limitaciones y es probable que esté mejor atendido para continuar su búsqueda de empleo.

Cuando una empresa utiliza el término general "Agile" en el reclutamiento sin ser más específico (por ejemplo, al solicitar experiencia XP o Scrum), a menudo es un marcador de posición para otra cosa que están buscando. Es posible que deseen "desarrolladores que emparejen programas" o "desarrolladores que no quieran evitar los requisitos y que no diseñen documentos antes de que comiencen" o "desarrolladores que no van a caer en un rincón oscuro durante semanas ". El truco es averiguar qué significan.

Desde la estrecha perspectiva de la contratación de Silicon Valley, un candidato que está familiarizado con las prácticas ágiles (por ejemplo, sabe qué es XP), ha hecho algunas de ellas (por ejemplo, programación de pares y TDD), y quien quiere trabajar en un entorno ágil pasa. ese obstáculo

En su trabajo actual, ¿puede implementar algún tipo de desarrollo ágil para demostrar que está interesado, lo ha investigado y en realidad tiene algo de experiencia? Es posible que encuentres algunos no desarrolladores para que trabajen contigo. Un usuario avanzado podría sentarse contigo durante un tiempo de codificación. Estoy seguro de que nadie se interpondría en el uso de parte de la documentación de Agile (registro de velocidad, tabla de grabación).

Entiendo tu frustración, pero la verdad es que si nunca trabajaste en un entorno Agile es muy probable que te comportes de manera contra ágil (por así decirlo), y es probable que ni siquiera entiendas qué es lo que estás haciendo mal.

Ya que Agile tiene tanto que ver con la filosofía del trabajo, no es algo que pueda aprender simplemente leyendo un libro, debe tener una comprensión íntima de cómo operan las empresas que no son Agile, los problemas que esto causa, cómo Agile cambia eso y cómo luchar contra el problema. entropía (los intentos del mundo externo para introducir de nuevo la no agilidad).

Mi consejo es que primero lea más acerca de Agile y comience a analizar su propio comportamiento y el comportamiento de cualquier empresa en la que trabaje actualmente desde la perspectiva Agilidad / no Agilidad. Una vez que pueda discernir los patrones, puede comenzar a tratar de cambiar su empresa desde dentro. Cuando fallas con eso, ve a una empresa Agile y te contratarán, lo prometo.

He contratado a desarrolladores en equipos ágiles unas cuantas veces. No me resisto en lo absoluto a contratar a un desarrollador sin experiencia ágil previa; serán un poco más baratos ;-)

Sin embargo, hay preguntas que le haría a un candidato así y hay ciertas respuestas que activan las alarmas, haciéndome saber que esta persona va a ser demasiado trabajo para volver a entrenar.

Por ejemplo, siendo preciados sobre su código y sus diseños, una señal segura de que serán una yegua en los scrums y en las revisiones de códigos.

Agile es una democracia extrema: todos somos iguales, pero eso no es para todos. Algunos desarrolladores simplemente parecen más felices en una autocracia (dime qué hacer y cómo hacerlo), monarquía (capas de mandos medios) o burocracia (especificaciones y desarrollo de memoria): esos tipos simplemente no trabajan de forma ágil.

Algunos desarrolladores están mucho más contentos con las ideas ágiles, y esos tipos pueden ser contratados ya sea que tengan o no un ágil previo.

No me preocuparía por no conocer todos los detalles del proceso: los buenos desarrolladores leen y se mantienen actualizados sobre las tecnologías que utilizan, no sobre la metodología de procesamiento. Como todas las compañías ajustan su modelo ágil de todos modos (si no lo hacen, lo están haciendo mal), realmente no importa con qué variante empezaron. Debe saber algo de la terminología, pero eso toma un día de lectura antes de la entrevista a lo sumo.

La marca de Agile que utilizamos está compuesta por Prácticas de gestión de proyectos definidas por SCRUM y Prácticas de ingeniería definidas por XP. Si estamos empezando un nuevo equipo, buscaremos roles clave para servir como coaches integrados para el equipo (un Gerente de iteraciones / Scrum Master Coach, Analyst Coach, Technical Coach y Testing Coach). Para un equipo existente, dado que usamos el emparejamiento, estamos más interesados en los desarrolladores que trabajan bien con otros que con un super programador.

Debido a que utilizamos el emparejamiento, un nuevo desarrollador se volverá productivo en un mes con las prácticas de ingeniería ágil, así como con los dominios de negocios y aplicaciones. Le da poco valor al equipo si un programador fuerte se une al equipo pero no puede emparejarse de manera efectiva.

Cuando nos entrevistamos, les pedimos a los candidatos que formen parejas con varios miembros del equipo. A través del emparejamiento, aprendemos si el desarrollador funciona bien con otros en un par. Además, obtenemos información sobre las habilidades técnicas del desarrollador. Debido a que el candidato trabaja en varias parejas, obtenemos la perspectiva de varios miembros del equipo.

Todos nuestros equipos ágiles han sido muy efectivos y sus proyectos exitosos. Hemos capacitado a más miembros del equipo para que sean más ágiles de lo que hemos contratado a personal ágil experimentado.

Lo más probable es que los empleadores se adhieran a contratar personas que tengan conocimientos de agile, en lugar de no hacerlo, porque las metodologías ágiles requieren que casi todos los miembros del equipo conozcan los procesos requeridos por cada metodología ágil (SCRUM, Crystal, XP). Por ejemplo, SCRUM requiere que todos los miembros del equipo, incluida la administración, comprendan y sigan el concepto de autoorganización. Deberán comprender que no se les impondrá su desempeño actual: en su lugar, deben abordar sus problemas abiertamente (o lo que suele ocurrir en el SCRUM diario). Si coloca a alguien en el equipo que no sabe ágil, puede asumir inmediatamente que, dado que esta metodología tiene poca documentación, puede ejecutarse y codificar y corregir para construir un proyecto. Sin embargo, las metodologías ágiles son un proceso pesado, en lugar de una documentación pesada.

Probablemente me haga esta pregunta: ¿Qué metodologías de desarrollo ha estado utilizando hasta este momento en su carrera? ¿Alguno de ellos abarca el espíritu de los ideales de Agile?

Si usted es alguien a quien le encanta desarrollarse a través de Waterfall y cree que es absolutamente perfecto para su mundo de desarrollo, entonces ir de Agile sería como pasar de conducir un automóvil a volar un avión o un bote. Es una diferencia fundamental, ya que no necesariamente sabrás a dónde vas y lidiar con los cambios de manera muy diferente a un estilo de cascada donde cada etapa va en orden y no hay ninguna reorganización sin poner en peligro todo el proceso.

Sin duda, es una forma práctica de tener que explicar otras razones que pueden jugar un papel más importante en la decisión.

Tal vez tomen la mentalidad del barman en la cantina de Mos Eisley (parafraseado):

No queremos a tu tipo aquí.