Trabajo en equipos multidisciplinarios

Standard

Hola buen día a todos, de nuevo me reporto con un tema en el cuál llevo trabajando un tiempo. En el último mes hemos estado trabajando en un proyecto multidisciplinario, esto incluye dos mecánicos, dos mecatrónicos y una persona de sistemas computacionales, ya que, en Hunabsys R&D trabajamos con el método de SCRUM, lo que suena raro para muchas personas por no ser un proyecto exclusivo de sistemas, pero nosotros hemos encontrado una manera muy amena de llevar a cabo este tipo de proyectos, expondré varios puntos muy importantes que quiero compartir con ustedes.

1.-Todos son dependientes de los demás.

Esto es algo muuuuy importante, por que se requiere de mucha paciencia e imaginación para definir de que manera vas a hacer tu trabajo sin afectar el trabajo de tus compañeros, eso cuidando el peor de los casos, pero te das cuenta que realmente trabajas en equipo cuando complementas el trabajo de tus compañeros. Continue reading

Mis experiencias con respecto a equipos auto-administrados

Standard

Muy buen día, hoy les quiero hablar de un tema que desde que empecé en el mundo de SCRUM, me ha causado interés en el mundo del desarrollo de software.

Para empezar, hay que definir qué es un equipo auto-administrado

Un grupo de empleados auto-organizados, semi-autónomos cuyos miembros determinan, planean y administran sus actividades diarias prácticamente sin supervisión.

Referencia

Continue reading

Ruby on rails, documentación ágil a partir de proyectos existentes.

Standard

Desde hace un tiempo que las metodologías ágiles se han establecido más allá de ser una moda en la industria del desarrollo de software. Por ejemplo, nosotros en Hunabsys utilizamos Scrum, y nos ha dado muy buenos resultados. Nos basamos en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación. Lamentablemente para la mayoría que sigue el manifiesto ágil la documentación se ha ido dejando de lado. Al mismo tiempo que se le entrega valor al cliente, se deja una deuda técnica al dejar de ayudar a otros, a los que no están familiarizados con nuestro sistema. Aquellos futuros responsables del mantenimiento de un sistema serían los principales afectados por no documentar, la única alternativa al no tener documentación del diseño es explorar directamente en sistema, abrirse caminos y por ende invertirle tiempo.

Continue reading

SCRUM parte 4: “Introducción” y primeras dificultades que se presentan.

Standard

Bueno ahora continuaré donde me había quedado después de un buen rato de no publicar.

En el último artículo, hablamos de las historias de usuario (SP) y algunas de las características que deben de tener. Una vez completado nuestro product backlog, vamos a proceder a planear nuestro sprint.

3.- Sprint Backlog

Como podemos imaginar es una parte de nuestro product backlog sobre el que se trabajará durante el sprint.

Para esto, de nuestro PB vamos a elegir junto con el Product Owner las historias de usuario que espera que sean completadas para el final del sprint. Es decir, al planear el Sprint, el PO es quien nos dice qué tiene prioridad, el equipo lo que cuida es que en caso de haber dependencias entre historias de usuario, estas se resuelvan. Continue reading