Chess - antoniomartel.com

Archivos de Categoría: Blog

Gestión práctica de proyectos seleccionado para una promoción de Amazon

Mi libro Gestión práctica de proyectos con Scrum ha sido seleccionado por el equipo KDP en español para participar en la promoción Kindle Flash de amazon.com, amazon.com.mx y amazon.es.

Las promociones Kindle Flash son promociones en las que, durante 24 horas, 3 libros son promocionados por Amazon a un precio especial destacándolos en una newsletter que Amazon envía a todos los suscritos. Desde ahí, los usuarios de Amazon pueden comprar alguno de los libros promocionados con un descuento de hasta el 80%.

Puedes suscribirte a la newsletter en este enlace para Amazon.es si estás en España, o en Amazon.com para otros países. Ahí estará mi libro a sólo 1$ si lo compras desde el enlace de las newsletter entre las 12:00 am hasta las 11:59 pm del 11 de agosto. Además, suscribiéndote a esa newsletter puedes participar en el sorteo de un ebook gratuito.

En este otro enlace puedes ver también los libros Kindle que estarán de promoción hasta las doce de la noche de hoy en Amazon Kindle Flash.

Aquí tienes también los accesos al libro en los tres Amazon donde puedes comprarlo (si no quieres esperar al descuento del 11 de agosto):

Amazon.com
Amazon.es
Amazon.com.mx

Historia de los proyectos software en tres sencillos actos

En los inicios de la informática comenzaron a aparecer las empresas especializadas en el desarrollo de software que ayudaban a resolver aquellos primeros proyectos TI que, por aquella época, parecían de ciencia ficción.

Desde entonces han habido empresas de todo tipo que empezaron a evolucionar según la corriente de los tiempos y el tamaño de sus proyectos: De empresas de garaje a Blue Chips pasando por consultoras de todos los tamaños para volver de nuevo a las empresas de garaje (ahora llamadas startups).

Todas estas décadas de aprendizaje en esta nueva ingeniería, la del desarrollo de software, no han sido fáciles. Muchas empresas quedaron por el camino ante cambios tan rápidos: La ingeniería del software es la ingeniería con mayor tasa de proyectos fallidos de entre todas las ingenierías.

Un estudio de 2012 indica que el 45% de los proyectos IT grandes exceden el presupuesto, un 7% excede el plazo y el 56% termina entregando menos valor del que se pretendía. Un porcentaje elevado de ellos va tan mal que su resultado amenaza incluso la propia existencia de la compañía.

La historia de lo sucedido en todos esos años probablemente pueda resumirse en tres sencillos actos:

Primer acto: Hacemos todo lo que el cliente solicita

Los cambios aparecen. Se necesitan modificar cosas. Lo que se construyó de una manera resulta no ser la mejor y es necesario rehacer parte del trabajo. Lamentablemente, en la mayoría de las ocasiones, el contrato está cerrado y se va a cobrar el mismo importe que se presupuestó inicialmente. La empresa debe continuar trabajando hasta que todo esté terminado, incurriendo en sobrecostes que en la mayoría de las ocasiones no estaban previstos. El desánimo cunde. El proyecto se alarga y alarga devorando horas y horas del equipo de trabajo que intenta terminarlo a tiempo.

 Segundo acto: No admitimos cambiar ni una coma

Nos enfadamos. Los sobrecostes llegan a ser tan altos en algunos proyectos que se comen cualquier margen comercial.

Las empresas de software han aprendido la lección y no pueden permitir esto. Colocan como jefe de proyecto a un duro negociador que no admite cambios. Cualquier modificación debe ser firmada por el cliente por triplicado y registrada en un acta formal. Las reuniones de análisis se convierten en algo similar a esto: ‘En el acta de reunión del 3 de junio se dijo que … corroborado luego en el acta del 9 de agosto por lo que ahora no puede cambiarse‘.

Pero los cambios ocurren, el mercado, las leyes o los decretos cambian y los errores de juicio se cometen. Nadie puede estar 100% seguro de que lo que dijo 2 años antes, al inicio del proyecto, sea válido ahora.

Tercer acto: Agilidad

El cliente puede llamarte y decir:

  • ‘Sabes qué? He estado pensando y puede quedar mejor sí…’
  • ‘Después de que pusimos en producción la versión 14 hemos visto que no está usando nadie la feature C. Mejor saltamos también D y comenzamos a trabajar en E y F’
  • ‘Hemos enseñado la aplicación en las sesiones de formación y todos nos preguntan que porqué no hay una exportación a Excel. Mejor comenzamos por ahí en el siguiente sprint en lugar de cambiar los logos y los iconos del menú’

Para esto tienes que estar en contacto continuo con el cliente. No puedes encerrarte año y medio con los tomos de análisis de requisitos, de casos de uso y las especificaciones de diseño y dejarle ver al cliente el resultado cuando hayas implementado hasta el último caso de uso (se necesite ya o no).

Este tercer acto no es tan sencillo como parece:

  • Es necesaria la confianza mutua entre ambas partes. 
  • Es necesario que el dueño del producto o representante del cliente conozca bien su negocio, tome decisiones acertadas (o corrija el rumbo con destreza cuando no ha podido ser así).
  • Es también muy importante que el jefe del proyecto en la empresa contratada sepa asesorar al cliente y darle apoyo en cuestiones técnicas y no tan técnicas. Probablemente no conozca el negocio del cliente pero seguro que tiene alguna experiencia útil en lo que salió bien (o no tan bien) en productos similares en los que ha trabajado.

Referencias:

Metodologías ágiles explicadas

Les dejo al final de la página un vídeo que explica las diferencias entre una metodología en cascada y otra ágil para la planificación de un viaje de miles de kilómetros hasta Portland, Oregon.

Dos equipos de trabajo reciben las mismas especificaciones para un proyecto: Viajar de la costa este hasta Portland en la costa oeste de Estados Unidos.

El equipo que trabaja en cascada planifica todo el viaje con antelación. Forman varios equipos distintos, cada uno especializado en un aspecto distinto del viaje: mecánica, avituallamiento, mapas, etc. Deciden cuál es el presupuesto que necesitarán, cuántos kilómetros recorrerán cada día, el sitio exacto dónde pararán a por gasolina, a por comida o a revisiones en el taller.

En cambio, el equipo ágil forma un único equipo en el que entre todos tienen el conocimiento suficiente para tomar decisiones sobre mecánica, rutas del viaje o meteorología. Establecen una serie de metas en el camino y toman las decisiones según lo aprendido en lo que ya llevan recorrido. Puede que decidan cambiar la ruta planeada por que la carretera estaba en mal estado o la velocidad con la que se preveía circular resultó no ser la prevista.

El presupuesto y la ruta ágil han ido adaptándose a lo que el cliente necesita y a las necesidades reales del proyecto, las que se conocen justo en el momento en que pasan. Esto puede permitir superar las expectativas del cliente o reducir el presupuesto al adaptarse a las cosas a medida que suceden.

Aquí les dejo el enlace a la página del vídeo: Agile Methodology by Common Craft.

Nuevo libro Certificación Scrum Master

En unos meses sacaré a la venta un nuevo libro en Amazon. Esta vez con todos los trucos y consejos para preparar y aprobar a la primera la certificación Professional Scrum Master (PSM I) de scrum.org.

La entrada de este blog que dedico a explicar cómo obtener esta certificación es, de lejos, el post más popular de todo el blog: Certificación Professional Scrum Master. Ahí sólo explico algunos datos sobre el examen como el precio, número de preguntas o algunos trucos para prepararlo pero en este nuevo libro ampliaré toda esa información e incluiré también capítulos para:

  • Explicar los beneficios de obtener una certificación ágil.
  • Explicar por qué certificarse como PSM I.
  • Mostrar una lista de recursos que puedes necesitar para estudiar o practicar las preguntas del examen.
  • Describir los cursos de Scrum que pueden llevarte a obtener la certificación agile que buscas.
  • Trucos y consejos para preparar el examen Professional Scrum Master (PSM I).
  • Realizar una comparativa entre la certificación PSM I y otras como certificaciones de renombre como Agile Certified Practitioner de PMI (PMI-ACP), Certified Scrum Master (CSM) o Scrum Manager.
  • Soluciones y respuestas a las preguntas del cuestionario/examen del no-oficial Test de Scrum.
Espero que el nuevo libro sea de interés para muchos de los profesionales de Scrum que quieran certificarse en Scrum. Hasta que esté publicado puedes echar un vistazo a mi primer libro Gestión práctica de proyectos con Scrum que publiqué en abril del pasado año. Durante el pasado viernes y la mañana de sábado estuvo en varias ocasiones como bestseller en tres categorías al mismo tiempo de Amazon España llegando al puesto número 380 entre el total de libros electrónicos vendidos en Amazon.es.

Libro Gestión práctica de proyectos con Scrum de Antonio Martel bestseller en Amazon
Actualización: Ya salió a la venta en Amazon el ebook Certificación Professional Scrum Master: Cómo preparar la certificación PSM I de Scrum.org. Puedes comprarlo ya, pero sólo está en preventa para promoción durante las próximas semanas. Si lo compras ahora con el precio de descuento Amazon te lo entregará el 13 de septiembre que es el día de publicación oficial.

En este libro podrás encontrar acceso gratuito a un test de práctica online, cuatro cuestionarios de preparación para el examen, comparativas con otras certificaciones populares de Scrum Master y otras muchas cosas útiles para esta certificación. Te dejo con un enlace al libro en Amazon.com (también en Amazon.es). Espero que te guste y que te sea útil si decides presentarte al test oficial:
Libro Certificación Professional Scrum Master: PSM I por Antonio Martel
Libro Certificación Professional Scrum Master (PSM I)

La importancia de saber hacia dónde se va

A veces, cuando empezamos un nuevo proyecto no transmitimos o no nos transmiten correctamente la idea de lo que se va a desarrollar. Sí, sabemos las especificaciones técnicas y conocemos los requisitos pero no sabemos el porqué ni para qué se necesita esa nueva funcionalidad o ese nuevo sistema.

Sucede como cuando hay niebla en la carretera, no vemos bien hacia donde vamos por lo que tendemos a reducir la velocidad. No vamos tan rápido como si hubiese una clara visión del objetivo.

Si nos piden que desarrollemos un nuevo servicio web que acepta y envía un complejo lenguaje con información de residuos lo construiremos tal y como nos dijeron y ya está ¿Funcionó? ¿Sirvió para algo? ¿Se está usando? Ni idea, nadie sabe muy bien.

En cambio, si en la reunión de arranque del proyecto, alguien explica al equipo de trabajo que con ese servicio web se pretende conseguir que todas las comunidades autónomas intercambien información sobre lo que se hace con los residuos y hacia dónde los llevan los gestores. Sabiendo que con software como ese se puede evitar que baterías de coche usadas terminen vertidas en una playa de Senegal por el mercado ilegal de residuos tendremos un idea mucha más clara del objetivo.

Saber esto desde el principio va a ayudar al programador a entender mejor los requisitos, identificar si alguno es incorrecto o a proponer incluso mejoras ahora que sabe para qué sirve. Además de todo eso puede que esté más contento. Sabe que lo que está haciendo es útil, que sirve para algo y que es importante que no tenga errores (quizás esto sea más efectivo para la calidad del software final que las pruebas unitarias).

Referencias: