Curso

IT Recruiter
Módulo 2:

Los perfiles IT

Unidad 1:

Las metodologías ágiles

Presentación

2
Para reclutar eficazmente, una buena idea consiste en conocer los perfiles IT
más demandados. Un perfil en sí mismo, es una convención entre los
conocimientos técnicos necesarios como así también la organización de los
proyectos, desde los cuales, las tareas diarias de los profesionales se definen.

Como toda actividad organizacional, los proyectos en IT están bajo modelos de

organización del trabajo que los profesionales ejecutan con el fin de alcanzar
sus objetivos. Por consecuencia, es importante para un IT Recruiter asimilar
cómo los proyectos se conciben y organizan porque deberá reclutar
profesionales que aporten al desarrollo de dichos proyectos a los cuales serán
asignados. Esto implica que los profesionales no solo deberán tener cierto
conocimiento técnico específico sino también un saber-hacer para relacionarse
con su equipo de trabajo, en la búsqueda de sus objetivos.

En el mercado IT, rápidamente notaremos que la organización del trabajo de sus

proyectos está primordialmente inspirada en las denominadas metodologías
ágiles. Estas metodologías, permiten una rápida adaptabilidad al cambio, muy
necesario en nuestro ámbito, en la medida que las empresas de software
buscan la satisfacción de sus clientes con sistemas de calidad que entreguen
valor agregado desde las etapas más tempranas de producción. Así, ya sea una
software factory, una consultora especializada o una empresa de producto
propio, las características propias de trabajar en un ambiente tan dinámico les
exige otorgar calidad sin malgastar el tiempo. Pues como hemos visto, el
mercado es altamente competitivo, y el talento escaso.

En este módulo 2, aprenderemos sobre los perfiles IT más demandados por el

mercado. En la unidad 1, estudiaremos sobre las las metodologías ágiles
presentes en los proyectos, mientras que en la Unidad 2, pondremos la lupa
sobre cada profesional por separado.

Objetivos

3
Que los participantes logren…

● Analizar y conversar sobre el mercado IT en Argentina

● Comprender los fundamentos generales de las metodologías ágiles.

Bloques temáticos

4
 1. Diferencias entre las metodologías ágiles y las metodologías en cascada o
tradicionales
2. Scrum
3. Kanban

Diferencias entre las metodologías

ágiles y las metodologías en cascada
o tradicionales
Para comprender rápidamente de qué tratan las metodologías ágiles y sus
diferencias con las metodologías tradicionales para planificar y ejecutar
proyectos, los invito a imaginar que somos integrantes de una empresa de
construcción y uno de nuestros clientes nos pide que construyamos un edificio
destinado a departamentos y vivienda.

Para diagramar las etapas de nuestro proyecto, quizás un buen punto de inicio
consistiría en destinar tiempo a entender la necesidad del cliente y elaborar un
presupuesto inicial. Luego repasaríamos los recursos necesarios para llevar
adelante la construcción y estimaríamos un tiempo de plazo para la entrega.
Una vez todo aprobado, nos abocaríamos a contratar personal y a construir el
edificio, con sus respectivas etapas de comienzo, desarrollo y final de la obra.
Una vez entregamos la estructura finalizada, el cliente puede hacer uso de su
edificio y destinarlo a sus inquilinos, que por supuesto, no podría hacerlo antes
de que el edificio esté terminado y en condiciones óptimas para las familias. Por
último, podríamos decir también que la construcción completa demandó un par
de años en realizarse, un tiempo lógico y prudente por el tamaño de la obra.

Este ejemplo hipotético, pudiera considerarse como un proyecto ejecutado

mediante una metodología en cascada, nombre que se atribuye así debido a
que el proyecto completo consistió en atravesar etapas diferentes entre sí con
un orden que sería imposible de realizarse de otro modo (por ejemplo, no

5
pueden los inquilinos utilizar el edificio antes que este se finalice; o construir sin
antes entender todo lo que se desea hacer). Bajo esta manera de organizar el
trabajo, hay una estructura clara y secuencial, con documentación detallada,
que permite prever qué entregar y cómo hacerlo. A su vez, permite una
detección temprana de riesgos. Esta manera de organizar el trabajo de
proyectos por etapas, puede verse en más de una industria y ha dominado la
manera de trabajar de las empresas por mucho tiempo.

Sin embargo, también presenta sus inconvenientes. Uno de ellos es que es un

modelo rígido para la adaptación a los cambios. Por ejemplo, si en medio de la
construcción de nuestro edificio el cliente desea agregar un cambio a los planos
originales, probablemente no podrá hacerlo. A su vez, la satisfacción del cliente
sabe estar ligada al producto ya terminado, no pudiendo volver hacia atrás en
caso que el producto final no le haya complacido.

Ahora, dejemos el mundo de la construcción y volvamos a nuestro mundo IT. Un

mundo atravesado por la versatilidad, el dinamismo, la competencia y la
evolución tecnológica veloz. Y en lugar de un edificio, debemos construir un
sistema para un cliente, por ejemplo, una cadena de supermercados que desea
vender por internet sus productos. Este sistema, por supuesto, es tan grande y
complejo como para asimilar el esfuerzo a la construcción del edificio que
imaginamos antes, pero para el caso de IT, en sus proyectos cambian las reglas
de juego:

● En este caso, el cliente no puede esperar años a que esté terminado su

sistema para empezar a vender por internet, sino que se espera un
sistema que esté operativo cuanto antes. Con el tiempo, se le pueden ir
agregando actualizaciones pero sin dejar de estar on-line el servicio de
venta.

6
 ● Quizás para cuando el sistema se termine, el mundo tecnológico haya
cambiado y sea necesario innovar en cómo adaptar lo hecho a las nuevas
tendencias. Esperar a tenerlo listo es sinónimo de no terminarlo nunca.
● El cliente necesita estar periódicamente presente en el día a día de la
construcción debido a que hay nociones legales que atender (imagen de
marca, colores, protocolos de tarjetas de crédito, leyes impositivas, etc.) y
cambios frecuentes en el sistema que se está construyendo (ofertas
especiales, nuevos catálogos de productos, actualización de precios,
etc.). También, puede ir descubriendo nuevas necesidades a partir del uso
de sus sistemas.

Estos ejemplos, y otros, son indicios habituales en IT sobre el por qué las
metodologías en cascada quizás no son el mejor enfoque para las empresas en
este contexto. En su lugar, en IT imperan las metodologías ágiles para llevar
adelante los proyectos.

Las metodologías ágiles

Las metodologías ágiles son un conjunto de prácticas diversas que persiguen el

objetivo de promover una mentalidad de aprendizaje y de mejora continua.
Permite que los equipos de trabajo puedan adaptarse rápidamente a los
cambios y entregar a su vez productos de alta calidad que satisfacen las
necesidades del cliente.

A comienzos de la década del 2000, un grupo de expertos en IT discutieron

sobre cómo mejorar los proyectos de la industria ante la insatisfacción que
generaban los enfoques tradicionales. Juntos desarrollaron el manifiesto ágil
(disponible en https://agilemanifesto.org/) que permitió un enfoque más efectivo
para la gestión de proyectos de desarrollo de software. El manifiesto aboga por
un enfoque colaborativo, adaptable e iterativo, centrado en satisfacer las
necesidades del cliente y responder a los cambios de manera rápida y eficiente.

7
En pocas líneas, el manifiesto ágil estipula que en los proyectos se valorará:

● Individuos e interacciones sobre procesos y herramientas

● Software funcionando sobre documentación extensiva
● Colaboración con el cliente sobre negociación contractual
● Respuesta ante el cambio sobre seguir un plan

Se valoran más los aspectos mencionados a la izquierda que los mencionados a

la derecha, aunque también sean importantes.

En base al manifiesto ágil, muchos autores encontraron la inspiración para

desarrollar metodologías de trabajo, que en conjunto se les conoce como
metodologías ágiles. Las metodologías ágiles son muchas y diversas, y se han
extendido más allá de la industria del software, pudiendo encontrarse en el
Marketing, RRHH, el comercio, el deporte y muchos otros ámbitos más. Las hoy
denominadas áreas de People en las empresas, donde los IT recruiters forman
parte, están profundamente inspiradas en los entornos de trabajo ágiles, por lo
que aprender de ellas para nosotros tiene un doble juego: aprender para
reclutar, aprender para aportar a nuestros equipos de trabajo.

En este curso, nos centraremos en las metodologías ágiles más frecuentes en

las empresas IT. Ellas son Scrum y Kanban.

Scrum
Scrum es una de las metodologías ágiles más populares, no solo en IT sino en
diferentes industrias.

Ante la necesidad de entregar valor con nuestros productos de manera veloz y

eficaz, Scrum consiste en pactar entregables al cliente periódicamente en un

8
tiempo determinado. Esta unidad de tiempo se le denomina sprint y usualmente
consiste en dos semanas entre cada presentación de un entregable. A su vez,
Scrum posee una serie de reuniones o meetings que los integrantes del equipo
de profesionales IT pueden disponer para organizarse internamente entre cada
sprint con su entregable correspondiente. Las meetings no deben ser tomadas
como reglas a seguir, sino que son recomendaciones para que cada equipo
según su realidad pueda disponer para organizarse como mejor lo crea
necesario. Estas son:

● Plannings (reuniones de planificación): es una reunión al comienzo del

sprint en donde todo el equipo recibe información respecto qué atenderán
en los siguientes días. Se discuten los objetivos a lograr y se resuelven los
aspectos ligados a la planificación del sprint. Es una reunión que puede
extenderse hasta una jornada completa y los equipos de trabajos saben
buscar privacidad para poder efectuarla.
● Daily (reunión diaria): es una reunión corta de no más de 15 minutos de
duración. En ella los integrantes del equipo comentan qué estuvieron
haciendo el día de ayer, qué realizarán el día de hoy y si encontraron un
inconveniente en el medio. La idea de esta reunión diaria no es perder
tiempo sino ir al hueso para detectar algún problema que esté ocurriendo
para resolverlo lo más rápido posible.
● Demostration (reunión de revisión): es una reunión que tiene una hora
aproximadamente por cada semana que contempla el sprint estipulado y
se efectúa usualmente al final del sprint. Consiste en realizar una prueba
de todo lo desarrollado al momento y puede ser entendido como un
entregable al cliente para ir evaluando la progresión del sistema.
Usualmente se le denomina simplemente una Demo.
● Retrospectiva: es una reunión normalmente realizada al final del sprint
donde el equipo se centra en todas las dificultades que pudieron haber
vivenciado en el transcurso del sprint para intentar que no vuelvan a

9
 ocurrir en los sprints venideros. Dependiendo del equipo, es común que
se realice la Demo y la Restrospectiva dentro de una misma reunión.
● Grooming (reunión de refinamiento del Backlog): esta reunión tiene por
objetivo revisar los requerimientos que se están trabajando en el sprint a
fin de mantener siempre las prioridades a la orden del día. Puede
significar que algunos ítems a desarrollar se eliminen o bien se agreguen.
También puede celebrarse cuando los integrantes del equipo descubren
que los requerimientos relevados originalmente no fueron bien
comprendidos o bien necesitan volver a ser redactados.

Para aprender más sobre scrum pueden visitar su web oficial Scrum.org.

El Scrum Master y el Product Owner

Si bien los perfiles IT los veremos con detenimiento en la siguiente unidad, no

deja de ser relevante mencionar que hay dos roles que se definen
específicamente por Scrum:

● Scrum Master: es el profesional encargado de la organización de las

ceremonias y del relevamiento de lo que acontece en ellas para garantizar
el adecuado funcionamiento del equipo en relación de los objetivos. Se
asegura que todos los inconvenientes que pudieran surgir dentro del
equipo sean resueltos para garantizar los resultados.
● Product Owner (PO): es la persona responsable de asegurar que el
producto que está siendo desarrollado responda efectivamente y sin
inconvenientes al modelo de negocio para el cuál fue creado. Recordando
que hay softwares altamente especializados y que necesitan un delicado
tratamiento en cómo trabaja con la información (por ejemplo, un sistema
de RRHH debe liquidar salarios acorde a la Ley y otros requerimientos sin

10
 margen de error), la figura de PO es de una gran responsabilidad pues
valida el correcto avance o no del producto en desarrollo. Este rol
usualmente es llevado adelante por alguien propio del cliente en el caso
de Software Factories, aunque también puede ser alguien interno del
equipo de trabajo y oficiar como el representante del usuario final. Tiene
un rol central en las ceremonias de Scrum ya que se asegura que el
equipo aporte valor agregado a sus productos.

Kanban
Es un método para organizar el trabajo subdividiéndolo en tareas concretas y
realizables para posteriormente ser delegadas de manera equilibrada a los
diferentes profesionales.

Consiste clásicamente en una pizarra dividida en columnas donde en la primera

columna se escriben todas las tareas que hay por realizar (denominada Backlog
en sistemas). Cada tarea se asigna a un profesional en particular y se la
traspasa en la pizarra a la siguiente columna “en proceso”. Finalizada la tarea, se
la traspasa a la comuna “realizado” y el profesional queda a disposición para
que una nueva tarea del backlog le sea asignada.

La imagen de tablero permite en una visual sencilla observar cuánto trabajo

pendiente hay por hacer, cuánto trabajo ya se realizó y que cada profesional
posea una carga equilibrada de trabajo acorde a lo que puede entregar.

Existen en la actualidad diferentes sistemas que ofician como tableros Kanban

siendo el más común Jira de la suite de Atlassian. Otros softwares similares
para realizar la misma funcionalidad son Trello, Rally, ALM (de HP), etc.

11
Conclusión

Hemos comenzado a transitar el módulo 2 y con ello a aprender sobre los

perfiles IT. En esta primera unidad nos hemos centrado en la utilización de
metodologías ágiles, en particular Scrum y Kanban, como método preferencial
en IT para la ejecución de sus proyectos. Pues en sistemas es necesaria la alta
adaptación al cambio y pronta disponibilidad del valor agregado a los clientes.

Sin embargo, no debemos caer en conclusiones apresuradas respecto a si es

mejor trabajar con metodologías ágiles o tradicionales ya que ambas tienen sus
fortalezas y debilidades propias. Incluso podemos encontrar muchas empresas
en IT que trabajan mejor con planificación en cascada antes que con
metodologías ágiles. Algunas empresas ligadas al desarrollo de hardware,

12
quizás prefieran modelos industriales de producción de sus bienes y también
encontraremos empresas Pyme que ante la necesidad de crecimiento veloz no
posean la estructura necesaria para implementar scrums muy sofisticados.
Desde ya que las metodologías tradicionales tienen una historia robusta en
aportes al mundo del trabajo y que existen importantes certificaciones que un
gestor de equipos de trabajo puede necesitar para llevar adelante complejos
proyectos.

Por supuesto, una elección correcta del cómo hacer las cosas es potestad de
cada empresa. Y es notorio ver cómo en IT la elección está normalmente ligada
a la implementación del agile con Scrum y Kanban más que nada.

Retomaremos sobre las metodologías ágiles durante la siguiente unidad, pues a

la hora de entender qué hace un desarrollador por ejemplo y como reporta con
sus pares Analistas de testing o Analistas Funcionales, tendrá que ver con la
lógica que las metodologías ágiles han acercado a esta industria en particular.

Todo IT Recruiter de experiencia debe entender estos principios básicos pero

fundamentales, pues no solamente estará trabajando probablemente dentro de
un equipo ágil con sus pares, sino también le permitirá comprender si un
profesional, más allá del nivel de conocimiento técnico que tiene consigo, puede
aplicar o no a nuestras posiciones y no perdernos fácilmente en nuestras
primeras entrevistas. Todo ello lo seguiremos trabajando en la siguiente unidad.

Bibliografía utilizada y sugerida

13
Libros y otros manuscritos:
Material confeccionado por el docente.

https://www.scrum.org/

https://agilemanifesto.org/iso/es/manifesto.html

14