Chess - antoniomartel.com

Archivos de Categoría: Blog

Curso de Scrum: preparación certificado Professional Scrum Master PSM I

miércoles, 28 febrero 2018 12:49
Antonio Martel
0 Comentarios

Acabo de lanzar un nuevo curso de Scrum para la preparación del certificado Professional Scrum Master (PSM I) de Scrum.org. El curso es online y, además de enseñarte el Scrum que necesitas para aprobar el certificado, incluye ayudas y consejos a la preparación, numerosos tests y preguntas de práctica y libros y plantillas de regalo.

Diploma Certificación Professional Scrum Master PSM I

Tendrás también, entre otras cosas, un capítulo dedicado a los recursos que puedes encontrar en Internet para que puedas documentarte, practicar los exámenes y aprender más sobre estas certificaciones. Además podrás encontrar abundante información sobre los distintos tipos de examen de certificación para Scrum Master: Una Comparativa entre las certificaciones de Scrum Master más populares en el mercado, explicando las ventajas e inconvenientes de cada una de ellas:

  • Professional Scrum Master, PSM I de Scrum.org
  • Certified Scrum Master, CSM de Scrum Alliance
  • Agile Certified Practitioner, PMI-ACP de PMI
  • Certificado o acreditación Scrum Manager, de Scrum Manager

Si te interesa, échale un vistazo a la página del curso online. Ahí tienes una preview de algunos de los capítulos del curso. Está a la venta ahora por tan sólo 79€ el curso completo.

Curso de Scrum: Preparación para el certificado Professional Scrum Master (PSM I).

¿Lo sabemos todo?

domingo, 25 febrero 2018 22:03
Antonio Martel
0 Comentarios

Este es un error muy habitual en el que yo y los equipos con los que he trabajado hemos caído más de una vez. Es frecuente que no se pregunte al Dueño del Producto por los detalles del trabajo que tienen que hacer. Asumen que la tarea es de una cierta manera sin preguntar y luego aparecen las diferencias cuando el Dueño del Producto lo ve en funcionamiento en la reunión de demo. Es cuando surge la temida pregunta «¿Quién les dijo que hicieran esto así?»

Esto puede suceder sobre todo por doscosas 1) temor a parecer demasiado ignorantes si preguntan nimiedades 2) por querer ir demasiado deprisa sin pararse a preguntar por qué las cosas son así cuando algo suena raro. Nos surge alguna pregunta pero asumimos una de las posibles respuestas para poder seguir adelante.

El feedback entre el Dueño del Producto y los miembros del Equipo de Trabajo debería ser algo común y frecuente. El Product Owner debe tener una alta accesibilidad y el Equipo de Trabajo no debe de tener miedo de preguntar, preguntar y volver a preguntar antes de hacer las cosas. Podrían tener que hacerse de nuevo si se entendió mal o se asumieron demasiadas cosas.

Esto requiere de mucha dedicación del Product Owner que debe estar siempre disponible para multitud de preguntas y reuniones pero requiere también de mucha atención al detalle del equipo de desarrollo. Es necesario levantar la mano (o el teléfono) y preguntar siempre que sea necesario. Terminará ahorrando trabajo a todo en lugar de darlo.

Interrupciones urgentes que no nos dejan avanzar en el proyecto

domingo, 21 enero 2018 20:00
antoniomartel
2 Comentarios

A veces tenemos que manejar un montón de interrupciones para resolver problemas de mantenimiento, corrección de errores o soporte que hacen que no lleguemos al objetivo del Sprint porque nos llega una cantidad grande de tareas que no estaban planificadas al inicio del Sprint.

Lo primero que tendremos que hacer es verificar si esas interrupciones urgentes son en realidad tan urgentes como nos las pintan o nos hemos dejado llevar por el alarmismo de haber encontrado un error en producción.

Lo segundo que debemos hacer es ver cuál es la razón principal por la que tenemos tantas interrupciones y de forma tan constante ¿Se deben a la mala calidad del software? ¿Quizás debido a las constantes interrupciones? Quizás debamos dedicar algunos sprints a resolver la deuda técnica que hemos ido dejando atrás o a dar más estabilidad a las partes del software que más problemas están dando.

También hay otras cosas que podemos hacer:

Tener sprints cortos

Con esta solución mantendremos las tareas ya programadas en la planificación del Sprint. Al tener sprints de una o dos semanas de duración podremos incluir la tarea no planificada como prioritaria en la lista de cosas a hacer en el siguiente Sprint. Si el Sprint tiene una semana de duración tardaremos una media aproximada tres días laborales en comenzar a acometer la tarea urgente.

Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.

Factor de dedicación bajo

Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el Sprint para dar ‘hueco’ a la resolución de estos problemas.


Sabiendo que en cada Sprint el equipo tiene capacidad para resolver 10 puntos de historias programadas podríamos comprometernos a entregar solo 7 para que el equipo tenga tiempo de resolver las incidencias urgentes. De este modo no fallaremos un Sprint tras otro en entregar lo prometido.

En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos Scrum pero ¿Cómo se está gestionando el resto del tiempo del equipo? ¿Qué sabemos sobre esa pila de tareas que estamos resolviendo Sprint tras Sprint?

Evitemos crear equipos sólo para dar soporte

Eso sería un anti-patrón a evitar en todo tipo de proyectos. Si creamos equipos que se dedican sólo a resolver bugs o errores encontrados en producción dejaremos al resto de equipos con las manos libres para centrarse en su trabajo sin interrupciones para llegar al final del Sprint pero esto puede hacer que cada vez aumente más el número de errores encontrados.


Los equipos necesitan hacerse responsables del trabajo que entregan y si no ven lo que se causa entregando código defectuoso porque otro equipo especializado se encarga de ello, estaremos fomentando que aparezcan más y más errores. Si ellos mismos tienen que corregir sus propios errores, terminarán dándose cuenta de lo importante que es la calidad para evitar desaguisados y de lo que tienen que hacer para construir software más robusto que evite tanto error.

Mi app en Android: Red global de sensores de temperatura móviles

domingo, 07 enero 2018 19:11
antoniomartel
0 Comentarios

Estas últimas semanas antes de Navidad he estado jugueteando un poco con un pet-project, una app para móviles Android que usan los sensores de temperatura, humedad y presión que tienen algunos modelos como el Samsung Galaxy S4 y el Galaxy Note para mostrarle estos datos al usuario pero también para guardarlos en la nube de Google con Firebase.

La app te mostraría la temperatura actual que registra el sensor del móvil, si lo tiene, pero al mismo tiempo te pide permiso para guardar estos datos y los de presión y humedad en la nube junto a las coordenadas de latitud y longitud del sitio donde fue tomada esa temperatura. Si tu móvil no tiene sensores de temperatura, humedad o presión la app te avisa de ello.

Este es el aspecto que tiene la aplicación (la presentación gráfica del termómetro está tomada de un sitio web, referencias al final):

Imagen de la consola de Firebase, la base de datos en la nube de Google donde se guarda la información, en la que cada nodo del árbol es una toma de temperaturas desde un móvil. En el centro se ve uno de los nodos desplegados con la información que se toma, o se podría tomar, en cada ejecución de la app.

La idea es que, si existe una red suficientemente amplia de móviles con esta app, todos los datos de temperatura almacenados alrededor de todo el mundo con los usuarios que se han descargado la app, queden guardados en registros en una base de datos NoSQL de Google que pueda ser consultada por algún científico que esté interesado.

El código de la app está disponible en un repositorio abierto de GitHub. Aquí algunos snippets del código que guarda en la base de datos:

En esta otra parte del código, la sección que toma los datos del sensor de temperatura:

Referencias:

Dependemos demasiado de héroes: otro error habitual en la gestión de proyectos

domingo, 17 diciembre 2017 20:50
antoniomartel
0 Comentarios

Cuando dependemos demasiado de uno o dos programadores estrella dentro de nuestro equipo, de los que necesitamos que no fallen nunca, que hagan muchas horas extra porque no llegamos o que, cuando están de vacaciones, los echamos demasiado en falta, estamos ante un gran problema.

Scrum nos puede ayudar a conseguir grandes equipos de trabajo, equipos de alto rendimiento que pueden conseguir entregar mucho trabajo y de calidad. Si lo que tenemos es un equipo formado por un desarrollador estrella del que dependemos absolutamente y el resto del equipo sólo resuelve tareas de menor nivel, no tenemos exactamente un Equipo de Trabajo, tenemos un cirujano y tres o cuatro auxiliares.

Debemos evitar esto facilitando que más miembros del Equipo de Trabajo conozcan las partes de la arquitectura que sólo el programador o programadora estrella conocen, que otras personas realicen también las partes del trabajo que sólo le tocaban a él para que el conocimiento (y el esfuerzo) quede más distribuido.

Por bueno que sea, un Equipo de Trabajo completo siempre podrá producir más que sólo nuestro héroe y además no lo agotaremos a base de horas extra y llamadas durante las vacaciones. Poco a poco el resto del Equipo de Trabajo debe ir acostumbrándose a asignarse a sí mismo las tareas que típicamente sólo hacía el programador estrella e irá ganando en experiencia y en confianza en sí mismo hasta alcanzar un nivel óptimo.
Dependemos demasiado de héroes
Dependemos demasiado de héroes