Chess - antoniomartel.com

Archivos por Etiqueta: libro

Ya está en preventa mi libro Curso práctico de Scrum: Algo más que teoría

Mi nuevo libro, Curso práctico de Scrum: Algo más que teoría ya está en preventa en Amazon.es, Amazon.com y Amazon.com.mx. Puedes pedir una copia ya, que te será entregada en tu ebook el próximo domingo 10 de septiembre.

En este libro encontrarás capítulos como:
  • Scrum funciona y te explicaré cómo lo hace
  • Los valores que están detrás de Scrum
  • Teoría de Scrum
  • El equipo de trabajo de Scrum
  • Ceremonias de Scrum
  • Herramientas de Scrum
  • Kanban con Trello
  • Los errores más habituales en Scrum
  • Ventajas y desventajas de Scrum
Ya sabes, no lo pienses más y adquiere ya tu copia de Curso práctico de Scrum: Algo más que teoría.

Curso práctico de Scrum: Algo más que sólo teoría

En unas semanas estará listo mi próximo libro, Curso práctico de Scrum: Algo más que sólo teoría en Amazon España, Méjico e Internacional (.com).

De mi primer libro siempre había alguien que echaba en falta algo más de teoría en el libro sobre cómo usar Scrum y no sólo contar mis experiencias personales. De esa idea sale este libro que pretende ahondar más en la teoría de Scrum, siguiendo y explicando la popular guía de Scrum de Scrum.org pero ampliándola con ejemplos reales que ayuden a poner en contexto toda esa teoría.

Este libro está destinado a todos aquellos que se quieran iniciar en el mundo de Scrum, qué han oído un montón de palabras extrañas asociadas a este framework pero que no las entienden bien o que incluso están usando ya Scrum en sus empresas pero lo hacen de una manera incompleta o desordenada porque les falta el conocimiento teórico y práctico de Scrum que este libro les podría aportar.

Jefes de proyecto, Scrum Masters que están empezando, desarrolladores y técnicos que trabajan en equipos que usan Scrum pero no entienden por qué se hacen de esta manera las cosas, etc., todos ellos podrán encontrar en este libro la explicación teórica a una reunión o un artefacto de Scrum pero también un ejemplo práctico que te ayudará a ponerlo en situación.

Curso práctico de Scrum: Algo más que teoría por Antonio Martel
Curso práctico de Scrum: Algo más que teoría

Número 1 en Programación y desarrollo de software

Mi libro Gestión Práctica de Proyectos con Scrum ha alcanzado de nuevo el puesto número 1 en ventas en la categoría Programación y desarrollo de software de la tienda Kindle de Amazon España.

Además, si se busca en Amazon España por la palabra ‘Scrum’, mis libros aparecen en las posiciones 2 y 4 de los más relevantes. Si se busca por la palabra ‘Agile’ mi primer libro aparece en la posición número 3 y su versión en inglés (Agile 101) en la posición número 15 de los resultados más relevantes.

Les dejo aquí con capturas del momento:

Libro Gestión Práctica de Proyectos con Scrum número 1 en ventas
Libro Gestión Práctica de Proyectos con Scrum número 1 categoría Programación y Desarrollo de software de la Tienda Kindle de Amazon España

Los valores que están detrás de Scrum

Hace 16 años, en 2001, se reunieron en Utah diecisiete profesionales del software críticos con los modelos de desarrollo de software que se llevaban hasta entonces. Los consideraban demasiado pesados o rígidos. En esa reunión estaba gente como los fundadores de Scrum o Kent Beck y Martin Fowler. Habían quedado para hablar sobre nuevas técnicas y procesos para desarrollar software.
De esa reunión salió un manifiesto con una serie de valores y principios que debían cumplir los nuevos métodos alternativos (y ágiles) que estaban proponiendo: Valores detrás del movimiento ágil.
Estos valores que rigen los principios ágiles son:
Individuals and interactions over processes and tools
Se pone el énfasis en los individuos y los equipos de trabajo más que en los procesos rígidos que hayamos establecido para comunicarnos entre todos o para hacer las cosas. Poniendo a los miembros del equipo de trabajo en el centro de las decisiones obtendremos un plus de productividad mayor que si es un proceso el que dicta qué hacer y no hacer en cada momento.
Tampoco las herramientas son importantes. Nos basta un tablero o unas hojas de papel con las listas del producto y del sprint o unos pequeños post-it. Las últimas herramientas, más caras (y difíciles de usar) herramientas en gestión de proyectos no nos van a dar una gran ayuda a la hora de resolver nuestro trabajo. Por esto, rara vez, una implementación de Scrum aconseja usar una u otra herramienta. Eres libre de elegir la que quieras siempre que seas consciente que esa no es la decisión más importante en tu proyecto.
Working software over comprehensive documentation
Esto significa que valoramos más un software que funciona y que está libre de errores que una exhaustiva documentación que documenta con pelos y señales cada sección de la aplicación. Esto no quiere decir que ignoremos o pasemos de la documentación. La documentación sigue siendo necesaria pero, por favor, no la pongamos por encima de loa verdaderamente importante, que es el código funcionando. Un código chapuza o de difícil mantenimiento funciona igual si tiene mucha o poco documentación. Prestémosle nuestro tiempo a mejorar el código y no a documentarlo. Nos pagan por línea de código funcionando no por tonelada de papel con documentación.
Customer collaboration over contract negotiation
Esta es uno de los problemas más enraizados en el desarrollo de software hoy en día. Los proyectos salen mal, se pasan de horas, se retrasan las fechas de entrega y para evitarnos las posibles discusiones con los clientes ponemos paños calientes sobre el problema preparando una batería de cambios que han solicitado y que no estaban en el contrato inicial.
Probablemente el cliente no entenderá que los cambios solicitados sean tan importantes como para justificar un retraso tan grande y aquí comienzan las negociaciones sobre el contrato: ‘Yo no te haré la integración con el sistema SAP porque me has saturado con pequeños cambios en las funcionalidades anteriores’ a lo que el cliente contesta ‘Sin esa integración el proyecto vale poco o nada por lo que no voy a abonar los pagos pendientes hasta que esté hecha hasta la última coma del contrato’.
En una negociación no seas el primero el poner el arma encima de la mesa. El cliente siempre tendrá una arma más poderosa que la tuya y ambos saldrán perdiendo. Sobre todo tú que perderás un posible futuro cliente y ganará en malas referencias.

 

Es más fácil tener la lista del producto sobre la mesa desde el inicio cuando comenzaron a pedir cambios que probablemente sí que les hacían falta hacer. Sobre esa lista del producto anotar los nuevos cambios y pedirle al cliente que saque de la lista otra serie de funcionalidades de igual valor que ya no le resulten tan importantes. Seguro que de buen grado encontrará funcionalidades a las que ya no le ve tanto sentido y que estará encantado de quitarlas con tal de que les hagas las que sí les hacen falta realmente.

Transparencia en Scrum

Como dice la guía de Scrum, Scrum se basa en la transparencia. La lista del producto o la lista del Sprint debe ser conocida por todos los miembros del equipo de trabajo y los interesados. Todos deben saber qué está pasando en el proyecto y por qué para poder tomar las decisiones más correctas.

Si Scrum se basa en la transparencia, la transparencia es también la base de la confianza. Si no conocemos el estado de las cosas, se oculta información al dueño del producto que no sabe si las cosas están correctamente terminadas o no, en qué estado está su producto o si es tan robusto como le están diciendo, terminará fallando la confianza en el proyecto y en las personas. Puede que el proyecto se cancele, que deje de haber flexibilidad cuando algo ha fallado y que perdamos toda credibilidad. El proyecto pasará a ser una marcha tortuosa hasta el final del mismo.

Para esto están las listas del producto, para decirnos cuántas cosas quedan por hacer en el proyecto, las listas del sprint, para que veamos qué estamos haciendo justo ahora y las reuniones de demo, para que el cliente pueda ver el resultado de las últimas semanas de trabajo y el producto por el que está pagando. Esta transparencia, si no la falseamos ni ocultamos la verdad será de gran valor en el proyecto.

A veces, por temor a llevarnos una reprimenda o evitar el enfado del cliente, del dueño del producto o del propio Scrum Master tendemos a ocultar la verdad convirtiendo la transparencia en una palabra hueca carente de todo sentido. Si una funcionalidad falla en ocasiones pero no se ve en la demo es mejor decirlo y explicar que queda este problema atrás. Si no hemos podido tener a todo el equipo de trabajo al 100% en el proyecto, es mejor decirlo también y que no falle la confianza. La transparencia será una gran aliada cuando las cosas pinten mal y necesitemos de la confianza de todos en que el proyecto saldrá bien.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad