Chess - antoniomartel.com

Archivos de Categoría: Blog

Mi libro número tres entre todos los libros de programación

lunes, 03 julio 2017 19:06
antoniomartel
0 Comentarios

Mi libro Gestión Práctica de Proyectos con Scrum lleva vendiéndose desde mayo de 2014, más de 3 años en los que el libro ha llegado a bestseller en su categoría varias veces y en todo Amazon, brevemente, en dos ocasiones.

Pero en este tiempo ha seguido vendiéndose a una media de unos 2 a 3 libros diarios en los últimos tiempos lo que lo convierte ahora en un libro longseller. Esta misma tarde se ha colocado en el número 600 de todos los libros más vendidos en Amazon España y en el número 3 de todos los libros, no sólo digitales, en la categoría de Programación y desarrollo de software.

Además, en este tiempo ha cosechado 17 comentarios en Amazon México, 41 en Amazon.com y 56 en Amazon España con opiniones tan buenas como éstas:

«No me esperaba encontrar esto y la verdad que me ha sorprendido gratamente»
— Iván

«Lo que más rescato es la prioridad que se tuvo para exponer lo realmente importante, logrando así un libro compacto y preciso»
— Cliente de Amazon

«Claro y eficaz, utiliza un lenguaje sencillo y es una magnifica obra para introducirse en scrum de una forma realista»
— Cliente de Amazon

«Es la experiencia del autor en su aplicación, ventajas desventajas, lecciones,… Sencillo y ameno»
— KermitSBD

«Genial: En mi trabajo, vamos a implantarlo y me ha tocado ser Product owner… Ha sido un repaso, muy ameno de lo que vemos en las formaciones. Muy recomendable»
— Isabel Soler López

«Cumple exactamente lo que promete la sinopsis: Un libro interesante y práctico. Escrito desde la experiencia y el sentido común»
— Santi

«Genial libro para entender el Scrum de forma practica y util»
— Cliente de Amazon

«El libro me encanta, es una buena intro para metodología Scrum, y se lee muy bien y rápido. Lo recomiendo»
— WildWilly

«Una ‘novela’ real de un técnico: Me ha gustado mucho. Me parece muy fácil de leer y muy didáctico. Se lee como una novela de casos ocurridos al autor»
— Cliente Amazon

«Realmente bueno: Un libro muy interesante tanto para el que se inicia como para el conocedor de Scrum (es mi caso). En su texto que es muy ameno, -aderezado con dibujos y citas muy útiles-, vas a encontrar consejos y también la esencia de Scrum (…) Es conveniente releerlo otras veces»
— Cliente de Amazon

El Scrum Master y la organización

lunes, 01 mayo 2017 11:13
antoniomartel
0 Comentarios

¿En qué ayuda el Scrum Master a la organización o empresa en la que trabajamos? En textos anteriores vimos en qué ayudaba el Scrum Master al Product Owner y al Equipo de Trabajo pero ¿y a toda la empresa en su conjunto?

Lo más importante de todo es liderar los cambios en la empresa para poder adoptar Scrum, es decir, ayudar a todos a que entiendan el motivo de las reuniones diarias, las reuniones de demo, la pila del producto, etc. buscar un hueco para estas reuniones y organizarlo todo para poder implementar Scrum en la empresa.

Para hacer esto habrá que planificar la adopción de Scrum en la organización ayudando a poner fechas para una implementación de Scrum gradual y cada vez mayor en la empresa si este es el caso. Por ejemplo podría establecer un calendario para que cada vez más equipos se vayan sumando al uso de Scrum, fijando reuniones de formación previas para explicar cómo se trabaja con Scrum y hacer seguimiento de cómo van estas implementaciones de Scrum en la organización para luego realizar los cambios que sean necesarios que incrementen la productividad de los equipos Scrum.

El Scrum Master tendrá también que ayudar a sus compañeros y empleados en la empresa a entender cómo funciona Scrum y cómo llevarlo a cabo. Debe llevar ese papel de formador o ‘profesor’ de Scrum para hacer que todos entiendan este cambio de paradigma.

Por último el Scrum Master deberá trabajar con los otros Scrum Masters de la empresa para que en conjunto se incremente la efectividad y la productividad de la aplicación de Scrum que se está haciendo en la empresa. Deberán poner en común las cosas que están funcionando o no en la adopción de Scrum y hacer los cambios necesarios para mejorar la aplicación de Scrum en la organización.

El Scrum Master y el Equipo de Desarrollo

domingo, 23 abril 2017 17:06
antoniomartel
0 Comentarios

El trabajo del Scrum Master no es el de jefe de proyectos ni es sólo el de servir de ayuda al Product Owner (que tampoco es el jefe de proyectos). En el trabajo diario del Scrum Master también debe ofrecer servicios de ayuda al Equipo de Desarrollo además de al Product Owner.

El más importante quizás sea el de eliminar impedimentos para el progreso del Equipo, es decir, ayudar en lo que el equipo necesite para tener su trabajo preparado y no tener que estar esperando por nada. Si por ejemplo se necesita solicitar una exportación de la base de datos antes de realizar algún trabajo, será trabajo del Scrum Master realizar estas gestiones para que el Equipo de Desarrollo lo tenga preparado a tiempo y no tenga que quedarse esperando a que esto se resuelva.

Otro de los puntos importantes en los que debe trabajar el Scrum Master es en el de guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional. Los equipos de desarrollo normalmente esperan que alguien les asigne las tareas y a encargarse sólo de aquellas tareas que pone el título de su contrato. El Scrum Master debe intentar cambiar este paradigma haciendo que cambie esta mentalidad para que el Equipo de Desarrollo sepa elegir sus propias tareas (de acuerdo por supuesto a la priorización hecha por el Product Owner) y a encargarse de todas las tareas sin derivarlas a otros departamentos porque ellos son los especialistas (departamentos de administradores de bases de datos o de analistas para que ellos hagan el análisis o un import o export de bases de datos).

Entre los trabajos del Scrum Master también está el de organizar los eventos o reuniones de Scrum para facilitar que éstas sucedan. Deberá organizar la reunión diaria, la reunión de demo, la reunión de retrospectiva, procurar que todos asistan y que sea del máximo provecho para todos los interesados.

También deberá servir al Equipo de Desarrollo para ayudarlo a crear productos de alto valor que no quiere decir que tengan un nivel de calidad alto, que se da por supuesto, sino a que el Equipo de Desarrollo esté centrado en producir funcionalidades y características que le aporten el máximo valor o utilidad al producto que se está construyendo.

Por último, y no menos importante, el Scrum Master deberá guiar al Equipo de Desarrollo cuando éste no ha trabajado nunca con Scrum para ayudarles en su adopción y en que sea completamente entendido por todo el equipo.

El Scrum Master y el Product Owner

domingo, 16 abril 2017 17:25
antoniomartel
0 Comentarios

El rol de Scrum Master en un equipo Scrum no es el de jefe de proyecto como suele suponerse equivocadamente. Es más bien el de un guía que ayuda a todos a entender cómo funciona Scrum y que intentan asegurar que las prácticas de Scrum son bien entendidas y funcionan de la mejor forma posible.

El Scrum Master ayudará a los Interesados y a otras personas fuera del equipo Scrum a entender cuáles con las mejores formas de interaccionar con el Equipo Scrum, por ejemplo, si un Interesado tienen una solicitud de mejora que hacer, el Scrum Master deberá hacerle saber que es mejor si se la comunica al Product Owner para que este la meta en la pila de trabajo y la priorice si así lo cree necesario.

El Scrum Master es un líder al servicio del Equipo Scrum. En concreto, el trabajo que realizará el Scrum Master para el Product Owner será:

  • Ayudarle a gestionar la Pila del Producto de manera efectiva, por ejemplo, facilitándole herramientas para gestionar los elementos de la pila (MS Excel, Trello, JIRA, etc.) o indicándole cómo y cuando debe priorizar entre las tareas.
  • Explicarle cuando debe entrar en más detalle en ellas para que el Equipo de Desarrollo las pueda entender correctamente con especificaciones claras y concisas.
  • Ayudarle a entender las estimaciones empíricas que haga el Equipo de Desarrollo, es decir las basadas en datos reales y experiencias pasadas y no sólo en predicciones.
  • Asegurarse de que el Dueño del Producto sabe cómo priorizar las tareas y funcionalidades a realizar basándose en el Retorno de Inversión y en el coste que tienen. Es decir si una funcionalidad tiene un coste o tiempo de realización de 5 y un valor para la organización de 8 quizás convendría hacerla después de una funcionalidad de coste 2 y valor 6 porque conseguiríamos un valor similar para la organización (6) en menos de la mitad de tiempo, tan sólo 2 (y la organización la disfrutaría antes también).
  • Entender y practicar la agilidad, es decir, explicarle las principios ágiles que hay detrás de Scrum como los del manifiesto ágil. Algunos de ellos son: Nuestra mayor prioridad es la de satisfacer al cliente, Aceptamos que los requisitos cambien, Entregamos software funcional frecuentemente entre dos semanas y dos meses, Los responsables de desarrollo y el equipo de desarrollo colaboran juntos estrechamente durante todo el proyecto, etc.
  • Facilitar los eventos Scrum según se requiera: Organizarlos, reservar las salas, convocar las reuniones, llevar los artefactos que sean necesarios, comunicar el orden del día y los puntos de la reunión, etc.
Estos son los servicios que el Scrum Master presta al Product Owner, en próximos posts explicaré los servicios que el Scrum Master presta al equipo de desarrollo y a la organización en su conjunto.

El tamaño del Equipo de Desarrollo

domingo, 09 abril 2017 16:58
antoniomartel
0 Comentarios

Lo que nos indica la guía de Scrum como mejor tamaño del Equipo de Desarrollo (no el Equipo de Trabajo, sólo el Equipo de Desarrollo, es decir, sin contar con Scrum Master y Product Owner) es de tres miembros cuando menos y nueve como tamaño máximo.

La idea es tener un equipo lo suficientemente pequeño para ser ágil pero que puedan entregar al final de cada Sprint una cantidad de trabajo que merezca la pena como para ponerlo en producción. En cambio no se quiere que tenga un tamaño tan grande, mayor de 9, que haga que se multipliquen las interacciones en el equipo y que haga difícil la coordinación entre ellos.

¿Para un Equipo de Desarrollo de sólo una o dos personas merece la pena Scrum? Estaríamos añadiendo un overhead o sobrecarga de reuniones y ceremonias que podría dificultar la normal marcha del trabajo haciendo perder tiempo al equipo. En mi caso personal, para equipos de estos tamaños aún así he intentando ser ágil siguiendo sólo cuatro principios básicos de Scrum para obtener el máximo de sus ventajas sin sobrecargar de reuniones que podrían ser inútiles al ser tan pequeños. Por ejemplo, mantener la reunión diaria, la reunión de demo, el Sprint y las Pilas de Producto y de Sprint.

En cambio, yendo hacia el lado contrario, tener 10, 11, 12 o más miembros en un Equipo de Desarrollo podría requerir demasiada coordinación y demasiadas reuniones para ponerse de acuerdo entre todos. Si se van a auto-organizar ese tamaño va a llevar demasiada complejidad como para repartirse tareas y coordinarse sin que haya un seguimiento estricto de qué hace cada uno o las dependencias entre el trabajo entre unos y otros y qué tiene que estar listo primero para que el otro pueda avanzar.

El Dueño del Producto y el Scrum Master no cuentan como miembros del equipo de desarrollo a menos que también estén trabajando en la lista de cosas pendientes a acabar dentro del Sprint. En ese caso sí son contados como miembros del Equipo de Desarrollo sumando una o dos personas más según sea el caso.

Hay estrategias para el escalado de Scrum (estrategias para cuando el proyecto es tan grande que un sólo equipo no puede con todo) como DAD (Disciplined Agile Delivery) que no son tan estrictos con los tamaños de los equipos y no prescriben unos tamaños límites mínimo o máximo tan cerrados como estos.