Soy desarrollador en un equipo de Scrum al que me uní en septiembre y, por razones que serán evidentes, quiero irme y estoy tratando de descifrar las líneas del currículum.
El equipo de Scrum en el que estoy trabajando es problemático en formas como:
Odio este tipo de ambiente ya que siempre he sido un artista técnico individual y no estoy dispuesto a arrastrar a otros. El trabajo en equipo es excelente, pero solo si los demás hacen su propio esfuerzo.
Mi situación actual:
En este punto, solo estoy sobreestimando cuánto tiempo llevará el trabajo, codificando según las especificaciones (sin importar cuán absurdo sea) y canalizando el resto del tiempo de sprint a los cursos de Udemy, pero solo puedo hacer eso hasta cierto punto para agregar tecnologías a mi currículum después. semanas. Tal vez necesito 15 horas para completar todo mi trabajo y estoy haciendo la misma cantidad de puntos que los otros desarrolladores.
Tal como está, parece que no tengo supervisión (hablo con mi gerente tal vez una vez por semana y él no trabaja en los mismos proyectos que yo). Diablos, estoy trabajando abiertamente en los cursos de Udemy y nadie ha dicho nada. No parece que tengamos evaluaciones individualizadas de ningún tipo.
busco seguir adelante...
Ciertamente no me quedaré con la duración del proyecto, así que no puedo poner eso en un currículum.
¿Cuál es la mejor manera de extraer un beneficio individualizado de un entorno Scrum? No obtengo un área de proyecto definida. No soy responsable de ningún componente dado fuera de las dos semanas del Sprint. Soy básicamente un trabajador de fábrica genérico. Los trabajadores de la fábrica al menos podrían clasificarse por widgets (puntos en scrum) en relación con sus compañeros, pero tampoco hacemos un seguimiento de eso.
En términos de "logro", ¿qué debo poner en mi currículum cuando intente salir a los 6 meses?
Supongo que esta pregunta está un poco fuera de tema, pero ¿cómo se supone que funciona el "éxito o fracaso como equipo" en Scrum? Si el equipo tiene éxito o fracasa, parece irrelevante para mis intereses, por lo que un trabajador de Scrum no haría nada especial para que tenga éxito a menos que sea un miembro de la empresa. Lo mismo con la cosa de "eliminar el desperdicio y aumentar la velocidad".
El objetivo del desarrollo de software es desarrollar software funcional que tenga valor.
"Codificar según las especificaciones" y "no estar dispuesto a arrastrar a otros" no son atributos valiosos. Las características a medio terminar no tienen valor. Las características codificadas a ciegas con una mala especificación no tienen valor.
Si le dan una especificación que tiene problemas y usted es el único que se da cuenta de eso, su responsabilidad es hablar. Haga preguntas, aclare ambigüedades, dígale a alguien cuando un requisito no tiene sentido.
Si ha terminado sus tareas de sprint, pero el resto del equipo no, entonces su trabajo como miembro del equipo es dar un paso al frente y preguntar cómo puede ayudar, ya sea asumiendo trabajo adicional o desbloqueando a un compañero de equipo.
El desarrollo de software no es cumplimiento de pedidos. Es trabajo de conocimiento.
Lo anterior aborda la cuestión secundaria de cómo se supone que funciona el aspecto de "tener éxito o fracasar como equipo".
Para la pregunta principal de qué poner en su currículum:
Dado que parece querer considerar solo los logros individuales, hable sobre la calidad y/o la cantidad de su trabajo individual. Habla también sobre en qué has estado trabajando, tanto el tipo de proyecto como las tecnologías que usaste.
El método habitual es que el equipo asigne puntos a las tareas y luego los miembros del equipo elijan las tareas que deseen. Si de alguna manera logras que se asignen demasiados puntos a tu tarea, lo recogeré y me veré bien :-) Pero en realidad eso no va a suceder con el scrum hecho correctamente, porque todos los demás miembros se dan cuenta de que los puntos están inflados. .
Si tiene un administrador ineficaz, ese administrador contará los puntos de la tarea y eso es todo. Un gerente efectivo notará que usted codificó deliberadamente las tareas de acuerdo con las especificaciones y nada más, lo que genera trabajo desperdiciado. No pasará desapercibido. Un gerente eficaz también se dará cuenta cuando alguien se hace cargo de las tareas difíciles o las evita. Y un buen gerente notará que algunas personas pedirán consejo a otras personas y recibirán consejos (y pedir consejo es bueno si ahorra tiempo y malo si lo hace perder tiempo, mientras que dar consejos ayuda al equipo). Por lo tanto, se notará ser egoísta y solo cuidar sus propios puntos.
Es interesante que pienses que una persona no intentaría hacer que la empresa tuviera éxito a menos que sea "un miembro de la empresa". Empecé en mi trabajo actual con la intención de hacer que la empresa tuviera éxito, y mi objetivo es llegar a un punto en el que pueda decir honestamente que he hecho un buen trabajo y que ya no me necesitan, y luego comenzar en otro lugar y haz lo mismo otra vez. Por un mejor salario obviamente.
Probablemente solo sea una mala opción para ti.
Algunas personas están muy enfocadas en la retroalimentación y se sienten perdidas sin ella. Otros prefieren estar en una empresa donde puedan hacer lo suyo. No creo que esas personalidades puedan trabajar juntas por mucho tiempo. También están los que siguen de cerca los incentivos y los que no y, de nuevo, no pueden trabajar bien juntos. Scrum parece exacerbar las diferencias porque todo el mundo es arrojado a la misma olla y revuelto.
Su equipo no parece ofrecer oportunidades de logro directo y casi parece un proyecto huérfano. Considere lo que hice para una pasantía hace unos años (por diferentes motivaciones). Estaba en el equipo de innovación y me enviaron a una de nuestras oficinas para observar a un grupo de miembros del equipo durante un día para ver qué se podía hacer mejor.
Encontré un montón de cosas y se las informé a mi equipo. No se tomó ninguna medida oficialmente (comprensiblemente, ya que cada miembro del equipo hizo una expedición y encontró muchas mejoras potenciales), pero nuestra cultura y mi jefe estaban de acuerdo con que yo siguiera adelante de forma independiente.
Elegí reemplazar una pieza de software que costaba muchos miles de dólares al año y ya ni siquiera realizaba su función con precisión (era un remanente heredado de 20 años). Pasé una semana, lo codifiqué, lo envié al equipo que lo usó para la verificación del caso de prueba y luego lo entregué justo cuando me iba a la escuela nuevamente. Fue hace un par de trabajos, pero sigue siendo una excelente historia para una entrevista.
Tiene mucho tiempo disponible, así que busque un grupo alejado de la tecnología (finanzas, recursos humanos u operaciones) y automatice algo para ellos. Traduzca el ahorro de mano de obra en horas-hombre por año, multiplíquelo por el salario estimado pagado y tendrá su logro. SQL/Python puede ser enormemente útil aquí.
Hay muchas tareas repetitivas que el software podría hacer más eficientes. Encuentre uno, automatice, reclame los ahorros y pídale al gerente de ese grupo que le escriba una referencia para LinkedIn. Entonces puedes seguir adelante.
Lilienthal
Marte