Scrum, el cancer de los developers

Scrum, el cancer de los developers

Por Fernando Ticona

Ahora tengo que ser sincero ante este tema ya que existe bastante desinformación, incomodidad y sobre todo miedo hacia los superiores con una mentalidad radical.

Como trabajo realmente con el Scrum

Hola querido manager, se que llegaste a este punto un tanto ardido, tranquilo, respira y ahora si escucha como trabajo dia a dia con Scrum. Gracias.

Actualmente trabajo en una fabrica de software, estoy de proyecto en proyecto y es el mismo proceso.

  1. Se presenta una propuesta, como idea base
  2. Una vez aprobada, se reúnen los requisitos reales
  3. Trabajamos en conjunto con la empresa, escuchamos sus necesidades y frustraciones
  4. Damos una capacitación y revisamos los conocimientos en común
  5. Desarrollamos un prototipo en papel
  6. Relazamos un prototipo en Figma
  7. Sacamos los requerimientos técnicos y fechas de presentación
  8. Esperamos una aprobación y si no sale retornamos al paso 4
  9. Desarrollamos el software
  10. Testing pre-entrega, si falla a que arreglar
  11. Capacitación e instalación
  12. Prueba de campo
  13. Soporte

Es la forma en la cual trabaje varios proyectos, mi participación empieza en participar en las reuniones, dar ideas, y por supuesto desarrollar la parte técnica.

Normalmente para cada equipo se contrata a un desarrollador por area que se necesite, como ser backend, frontend o mobile. Ademas de pasantes que quieran ganar experiencia para apoyar el area técnica, un project manager, un diseñador UX/UI. Asi que veo algún que otro conocido y un par de caras nuevas.

En la etapa de desarrollo de software, surgen los problemas o roces, al momento de hacer las reuniones diarias:

Daily meting

Mi problema principal va con el tiempo que se dedica esta reunion, realmente debería ser unos 10 minutos, no mas, donde respondes:

¿En que estuviste trabajando?

¿Tuviste alguna dificultad con esa tarea?

¿En que tareas trabajaras hoy?

Es comprensible, pero en equipos medianos tarda como una media hora, donde se puede bastante tiempo en la puntualidad, problemas de cámara y/o micrófono y sobre todo la dificultad de expresarse.

A pesar de todo, la reunion sale bien, para que luego de unos veinte minutos me llamen otra vez a reunion para poder ayudar a alguien a aclarar las dudas o en una dificultad. Y con el PM presente.

Entiendo que es difícil expresar que tuviste un problema, pero estamos para solucionarlo en el momento, pudiste enviarme un mensaje ayer a la hora que detectaste el problema y no esperar a Daily o peor decirlo después al PM para que me arrastres a esta reunion.

Lo se y lo dije, pero se me va el dia rápido y si lo lleno con reuniones no voy a poder codificar nada, si tienes un problema, dificultad o duda, envíame un mensaje y te ayudo. Si es necesario avisamos al PM para que nos pueda ayudar…

Duración de los Tickets

Como desarrollador es difícil dar un estimado exacto, surgen problemas en diferentes lugares o el diseño tiene fallas que no vimos antes. Asi que no puedo darte un estimado exacto y te lo digo cada vez que un ticket se atrasa o a que sub dividirlo.

Otro problema grande son las dependencias de tickets, no puedo iniciar un ticket si el otro desarrollador aun esta trabajando en ello y tampoco puedo ayudarle a terminar mas rápido. Puedo guiar ciertas cosas o hasta darle algunos consejos, no me cargues mas trabajo.

Si eres PM, déjame darte un abrazo

Entiendo que este no es tu único proyecto y que tienes en tu espalda mucho trabajo, pero la comunicación es muy importante. Usemos un sistema de organización como Notion, Asana o si no hay de otra Trello.

Dame la confianza en tener la confianza de poder enviarte un mensaje, entrar a tu oficina y que me puedas atender. Estamos aquí para colaborar y sacar otro software con buenos estándares de calidad.

También quiero salir a la hora, aunque no parezca también debemos tener una vida, no podemos vivir encerrados como maquinas.

Ayudémonos mutuamente, Gracias.