Ajedrez - antoniomartel.com

Archivos por Etiqueta: libro

Nuevo libro, esta vez con la editorial Anaya

Los que estén suscritos a mi blog probablemente hayan notado que llevo unos meses sin publicar nada nuevo. Si me llevan siguiendo algún tiempo, es probable que recuerden también que en febrero ya anunciaba en Amazon la preventa de mi tercer libro. Un lanzamiento que cancelé avisando que habría novedades más adelante.

Esas noticias parece que se confirman y que van tomando forma de una nueva publicación, pero esta vez con el respaldo de Anaya y su colección de Manuales Imprescindibles. Con el respaldo de esta editorial, y su enorme red de distribución, este libro llegará en septiembre, quizás octubre, a las librerías de toda España y buena parte del continente americano. Será todo un honor verlo en los estantes de El Corte Inglés, Librería Canaima o El Libro Técnico, por citar solo algunos de los centros más populares de ventas de libros solo en Las Palmas GC.

Publicar con Anaya es un gran privilegio, sobre todo si tenemos en cuenta que, después de haber leído de adolescente clásicos de esta editorial como Inteligencia Artificial de Tim Hartnell, terminé dedicándome a la informática o la programación. Otros muchos libros como Programación Java Server de Allamaraju et al. me ayudaron en mi lucha para aprender Java en mis primeros puestos de trabajo como profesional.

No será un libro centrado solo en Scrum o marcos de trabajo concretos, sino que hablaré en él de la gestión de todo tipo de proyectos, software y no software, de equipos de trabajo cohesionados y productivos y de la gestión de productos. Si quieres entender cómo, desde un punto de vista ágil, se puede aumentar la eficacia y el rendimiento de tu equipo o el tuyo personal, además de proporcionar tranquilidad a técnicos y managers, este es tu libro.

Si también quieres saber qué tienen que decir una psicóloga de la era soviética o un atracador de bancos de Pittsburgh sobre la eficiencia en el trabajo, este es tu libro. Podrás comprarlo en otoño de este año, y en el encontrarás muchas historias como estas o anécdotas vividas a lo largo de un montón de años de experiencia profesional.

No se trata de un libro teórico o académico; intenta ser entretenido desde las primeras páginas y animarte a que lo sigas leyendo con atención hasta la última. Pretende ser un libro divulgativo, con el que consigar calar en los lectores las ideas más avanzadas en gestión de equipos de trabajo y proyectos profesionales. Suscríbite a mi blog para mantenerte informado y anímate a leerlo (y comprarlo) cuando por fin se publique.

Contrato con Anaya para nuevo libro. Título provisional: Gestión de proyectos – Agilidad en la práctica

Error nº 9: Apretar demasiado en el objetivo del sprint

Es el equipo el que decide qué funcionalidades caben en un Sprint y cuáles no. Los miembros del Equipo de Desarrollo son los que mejor saben cómo se hace el trabajo y los que por tanto mejor pueden calcular si en el sprint caben seis u ocho historias de usuario o lo hacen a 10.
Si viene presión de fuera para que metan más cosas en el Sprint y que se comprometan a entregar más trabajo cuando realmente no lo ven factible, esto sólo puede hacer que se acumule el resentimiento o la desconfianza o que se fomente la baja calidad del trabajo para poder entregar a tiempo. Se sabe que cuanto más ridículos son los plazos de entrega más tiempo y dinero se malgastan en intentar conseguirlos.
Cuando se planea la cantidad de trabajo que podemos hacer, se planea un tiempo para las pruebas que necesitamos hacer y asegurarnos de que el trabajo es fiable. Se planifica también una cantidad de tiempo razonable para pensar y estructurar el desarrollo. Si falta tiempo para hacer estas cosas, la calidad del trabajo se resentirá y, más adelante, en próximos sprints o después de finalizado el proyecto, pagaremos esta deuda que hemos dejado atrás con intereses de demora convertidos en bugs que nos asaltarán en los momentos más inoportunos y que reducirán el nivel de satisfacción de nuestros usuarios.
Otra cosa es que el Equipo de Trabajo se sienta retado a conseguir más cosas dentro del Sprint y que se sientan con ánimo de conseguir mucho en poco tiempo. Si conseguimos un ambiente así, en el que los desarrolladores se comprometen por sí sólos al máximo alcanzable por ellos, habremos conseguido un gran objetivo y tendremos un gran equipo.

Error nº 8: El Scrum Master reparte las tareas

Se trata de que los equipos de trabajo sean auto-organizados y se repartan ellos mismos las tareas. Ellos son quienes mejor saben cómo hacer el trabajo y cómo mejor repartírselo entre ellos. Si dejamos que el Scrum Master o el jefe de proyecto reparta el trabajo probablemente no quede balanceado entre todos los miembros del equipo quedando más peso en unos que en otros o se hayan asignado tareas a alguien que no tiene ahora las habilidades técnicas para resolverlo igual que algún otro.
Si dejamos que ellos mismos, los miembros del Equipo de Trabajo, se repartan las tareas a realizar, el trabajo quedará más repartido y ellos tendrán un sentimiento de reparto más justo. Se trata de que levanten la mano y digan ‘Esa tarea la hago yo’ o ‘Creo que quién mejor puede hacerla es Carolina’ a lo que Carolina puede responder ‘Quizás sí, pero ya tengo asignadas las tareas 14 y 16 ¿Qué tal si la hace Fernando? Ya lo hizo una vez y puede ir ganando más experiencia con eso’.

Errores más habituales de Scrum (II)

Error nº 3: Pruebas insuficientes

El proyecto se te ha vuelto una pesadilla, todas las tareas hay que volver a abrirlas cuando se está terminando el proyecto porque el cliente las rechaza en las pruebas de aceptación o porque se convierten en bugs una vez están en producción. Los Interesados están descontentos y tu equipo está más tiempo buscando y corrigiendo incidencias que desarrollando nuevas funcionalidades que den más valor al producto. Para colmo de males todos están perdiendo los nervios con la situación.

Esto es señal de que en cada Sprint se han estado entregando las cosas sin estar realmente terminadas y sin ser suficientemente probadas. Una forma de probar más y mejor es automatizando los tests con pruebas unitarias, o tests de regresión y de integración con herramientas como JUnit, o de record&play como Selenium IDE. Irás creando unos pocos tests más cada Sprint para probar las historias de usuario desarrolladas en ese Sprint y el núcleo de la aplicación pero añadirás más el siguiente Sprint mientras se siguen probando automáticamente las pruebas de todos los sprints anteriores.

Los tests automatizados difícilmente sustituirán totalmente a los testers y a las pruebas manuales. Resérvate los dos o tres últimos días del Sprint para que se pare el desarrollo de funcionalidades y todos los miembros del equipo comiencen a probar las funcionalidades ya hechas para asegurarse de que están completamente libres de errores. Cada uno puede probar sus propios tickets y al terminar pueden coger las tarjetas de otros y comenzar a probar las funcionalidades de los demás miembros del equipo.

Error nº 4: Todos los entregables están grabados a fuego hasta el día del juicio final

Esto sucede cuando la Lista del Producto ha sido dividida en fases coincidiendo los sprints con una serie de entregables definidos desde el inicio del proyecto. Es decir, que si tenemos que entregar 80 funcionalidades en un proyecto de un año, se definirá desde el arranque del proyecto que debemos entregar 3 funcionalidades en los 26 sprints del año (suponiendo sprints de dos semanas) y además se definirá qué tres funcionalidades en concreto se van a entregar y éstas son inamovibles.

Esto puede convertir al proyecto en un terror de noches sin dormir porque en este Sprint hay que entregar las funcionalidades P, Q y R y en los sprints pasados no pudieron terminarse E, H, J y L. El trabajo se nos acumula. Además no estamos dando la oportunidad de redirigir el proyecto dando más peso a unas funcionalidades, quitándoselo a otras para añadir o quitar funcionalidades según lo que se demuestre más efectivo o importante.

La Lista del Producto se ha convertido en un contrato y cada Sprint en otro del que además arrastramos errores y deuda técnica dejada en el anterior. No se deja hueco para trabajar más en unas funcionalidades que llevaron más tiempo del previsto inicialmente. Todo está fijado y anclado a una estimación que se hizo al inicio del proyecto cuando no se tenía idea de qué iba a ser más fácil, qué más difícil o que podía obviarse por resultar irrelevante. Cumpliremos el ‘contrato’ de nuestra estimación diga lo que diga aunque el tiempo haya demostrado lo equivocado que estábamos cuando la hicimos.

Ya a la venta el libro Curso Práctico de Scrum

Ya está a la venta en Amazon las versiones en papel y electrónica del libro Curso Práctico de Scrum: Algo más que teoría. Puedes comprarlo aún a un precio reducido mientras esté en promoción.

Se trata de eso, de un curso de Scrum en el se explica al teoría de Scrum de forma práctica. En buena parte del libro se sigue la estructura que tiene la guía de Scrum de Jeff Sutherland y Ken Schwaber siguiendo su mismo orden pero evitando las palabras y tecnicismos que son sólo una traducción literal y aderezando las explicaciones con un caso real o ejemplo que te ayude a entender y poner en práctica luego lo que aquí trato de explicarte ¡Espero que te guste!
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

Suscríbete