Sunday, 27 December 2015

Primer encuentro de autores indie de Amazon

Hace ya algunas semanas Amazon me invitó a asistir al Primer encuentro de autores independientes de Amazon en España en el Colegio Oficial de Arquitectos de Madrid. Allí nos reunimos unos 200 autores que editamos nuestra propia obra junto a profesionales del periodismo o la edición.

Como sé que algunos de los lectores de este blog tienen ya publicado o quieren publicar su libro en Amazon les dejo con algunas de las notas que me parecieron más importantes y que no siempre pueden encontrarse con facilidad en Internet:
  • Es importante la selección de las categorías en las que se encontrará tu libro. Si no alcanza buenos puestos en la categoría actual es mejor seleccionar categorías más específicas.
  • Echar un vistazo a cómo queda la descripción de tu libro en formato móvil. Cada vez más lectores acceden a Amazon desde uno de esos dispositivos y lo que allí vean les ayudará a decidir si compran tu libro o no.
  • Recomiendan poner el precio x,99 en Amazon.com y Amazon.es. Aumenta las ventas. Para Amazon Méjico x9,00 (por ejemplo 49,00 o 79,00 pesos).
  • No poner conversión automática de moneda entre los distintos mercados. El cambio de moneda cambia cada día y esto hace más difícil que tu obra sea seleccionada para una promoción de Amazon. Poner, por ejemplo, precios específicos: 2,99 para .com, 3,99 para .es y 49,00 para .com.mx.
  • Para ser seleccionado para una promoción de Amazon debes cumplir que:
    1. Hayas vendido al menos un libro diario en los últimos 30 días.
    2. El precio sea superior a 2,99 euros o 39 pesos (si no el descuento de la promoción no tendría mucho sentido).
    3. Esté a la venta al menos en los tres mercados principales de habla hispana: Amazon.com, Amazon.es y Amazon.com.mx.
    4. Tenga al menos 3 estrellas de media en las valoraciones.
  • Muchos títulos pre-aprobados para promoción pero sólo hay 200 plazas al mes.
  • Las portadas de los libros deben verse y leerse bien en blanco y negro. Muchos lectores acceden con Kindle readers que sólo muestran pantallas en B/N. Enseñaron algunos ejemplos y no había manera de distinguir letras del título o del autor sobre las imágenes del fondo.
  • Otra buena recomendación: Incluir un capítulo al final del libro para solicitar al lector que incluya una recomendación a tu libro en Amazon.
  • Trabajar con correctores y redactores para que revisen tu obra y le den un perfil más profesional a tu libro.
  • Tiempos medios que un lector de Amazon dedica a valorar tu libro por cada una de las secciones:
    • Las secciones que tú controlas:
      • 6 segundos: Valoraciones, precio, portada.
      • 4 segundos: Descripción.
    • Lasa secciones que no controlas:
      • 9 segundos: Primeros 2-3 comentarios.
      • 8 segundos: Recomendaciones/sugerencias automáticas
  • Considerar la traducción del libro. El mercado en inglés es 10 veces más grande que el hispano.
Ahora unos enlaces al evento en las noticias y fotos tomadas ese día:
Fotos:

Sunday, 22 November 2015

Principios detrás del movimiento ágil

Hace casi 15 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 salieron una serie de principios que debían cumplir los nuevos métodos alternativos (y ágiles) que estaban proponiendo: Principios detrás del manifiesto ágil.

Uno de estos principios es:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Parece obvio que esto es lo que debe hacerse en cualquier desarrollo y con ese ánimo comenzamos cada nuevo proyecto pero pronto comienzan las prisas. Nuestro director nos pregunta cuántas horas llevamos empleadas (y llevamos ya muchas), nuestro cliente nos pregunta cuándo va a tener listas todas las funcionalidades y nuestros compañeros de trabajo nos preguntan si ya pueden cogerse las dos semanas de vacaciones que les debemos.

Empieza a pintar feo. Ya nos hemos vuelto a meter en un jaleo. Tenemos que volver a rehacer el diagrama de Gantt con las nuevas fechas de entrega programadas, tenemos que buscar otras fechas para las vacaciones (incluso las nuestras) y tenemos que dar un montón de explicaciones al director: 'Es que nos han pedido cambios, es que las tecnologías eran nuevas, es que estimamos mal'.

A partir de aquí es cuando tendemos a ponernos firmes, a exigir un esfuerzo adicional al equipo de trabajo y a negar cualquier pequeño cambio al cliente. Si no está exactamente escrito así en el contrato que firmamos o en el acta de una reunión que tuvo lugar hace seis meses, lo siento, pero no lo haremos.

El caso es que el cliente también hizo esto. Redactó un contrato muy claro en el que te dijo cada una de las funciones que quería (o las que quería en el momento de redactarlo). Quizás ya no las necesite o se haya dado cuenta de que hay otras más importantes pero están en el contrato y hay que hacerlas. El proyecto no puede acabar y dejar un 30% de funcionalidades por hacer.

En este momento ya hemos perdido de vista la que debe ser la máxima prioridad en nuestro trabajo. Entregar de forma continua software que funcione y que aporte valor. A partir de aquí ya no quedan sino duras negociaciones y un contrato que trataremos de cerrar cuanto antes con el menor daño posible.

El contrato podrá tener muchos artículos y estipulaciones pero, ponga lo que ponga, cuando el cliente lo redactó lo que quería era una solución a su problema, no una discusión sobre si se debe o no implementar esa función o la otra.

Pero, si vamos entregando cada poco tiempo el software que vamos haciendo, lo dejamos para que lo pruebe y lo use, que nos diga su opinión. Dejemos que encuentre lo que echa en falta o lo que podría mejorar. Va a querer que le implementemos esto que ahora ha visto que necesita y estará encantado de quitar a cambio esa funcionalidad para exportar a ficheros .rpt que ya ni se acuerda de quién se lo pidió ni por qué.

Al finalizar el proyecto el cliente tendrá un producto que de verdad resuelve sus problemas, que ha ido evolucionando a medida que él mismo aprendía y que ha podido usar y probar desde las primeras semanas del proyecto. Suena mejor para cliente y proveedor ¿no?

Tuesday, 3 November 2015

De cómo Agile y Zara hacen cambiar la industria de la moda americana

En mi última entrada comentaba que no sólo el software puede escribirse de forma ágil. Un libro también podía escribirse usando estas técnicas pero ¿sólo el software y los libros? Por supuesto que no. También las prendas de ropa pueden diseñarse, fabricarse o inventariarse de forma ágil.

Aquí les cuento cómo empresas de la industria de la moda como Zara dan una respuesta ágil al mercado dejando a sus competidores americanos perdiendo cuota de mercado.

Agile para acelerar las ventas en la industria de la moda

El periódico El País cuenta en un artículo con ese título cómo algunas multinacionales americanas están teniendo problemas para adaptarse al ritmo de ventas que tienen dos de sus principales competidores, Zara y H&M.

En el trimestre presentado habían perdido un 6% en ventas y en el ejercicio del último año (2014) su cotización bursátil había bajado un 25% por lo que muchas empresas del mundo de la moda han terminado rindiéndose a las nuevas técnicas comerciales de la fast fashion:
"(...) admite que el viejo modelo de producir la ropa con un año de antelación está desfasado en la era del comercio online. Primero, porque el sistema que sigue es tan rígido que no le permite reducir los pedidos en los artículos que se quedan en la estantería sin vender. Segundo, y casi más importante, está atado de manos cuando una prenda tiene éxito."

Cómo lo hace Zara

En 2004 la Harvard Business Review analizaba las nuevas prácticas de gestión de Zara y afirmaba sobre ellas que "eran cuestionables, si no, directamente locas" aunque admitía que "La compañía puede diseñar, producir y entregar una nueva prenda de vestir y ponerla en sus tiendas en cualquier parte del mundo en tan sólo 15 días. Ese ritmo no se había visto nunca en el negocio de la moda, donde los diseñadores normalmente pasaban meses planificando la siguiente temporada".

Zara consigue aumentar su margen de beneficios en un 28% siendo hasta 4 veces más rentable que sus competidores mediante una combinación de márgenes altos, tiempos de venta bajos y reducción del riesgo de inventario.

Tal cómo explica Forbes una de las técnicas ágiles que permitió a Zara mejorar de forma drástica sus resultados financieros fue la de retrasar hasta el último momento la transformación del producto final. Sólo cuando saben qué producto se está vendiendo bien es cuando lo pasan a fabricación. No manufacturan todo su stock antes de que comience la nueva temporada evitando llenar las tiendas de prendas que no aún saben si se venderán bien.

Esto ha hecho que Zara en sus rebajas descuente sólo un 15% de media a los productos que no ha podido vender a su precio original (son pocos). Mientras, otros competidores tienen que aplicar descuentos del 50 al 70% a los productos que no han podido ser vendidos en toda la temporada.

El artículo de Forbes indica también:
"El rendimiento de la gestión ágil en la fast fashion está ya bien documentado, pero aún como en otros sectores, muchos managers americanos están todavía atrapados en la forma de pensar de la gestión tradicional y están siendo lentos para responder."
Otra de las joyas de la corona que permite a Zara ser tan eficiente en la gestión de su stock para mantenerlo siempre en movimiento es el chip RFID. Gracias a él, han podido reducir hasta en un 90% el tiempo que necesitan para realizar un inventario o para buscar un artículo concreto en la tienda.


Ser tan rápidos inventariando, diseñando o poniendo sus productos en las estanterías aumenta su margen de beneficios y disminuye el riesgo de quedarse con productos que no pueden vender. Como ves, ser ágil es bueno tanto si se trata de vender moda como de escribir software. También es bueno para producir coches como en el caso de Toyota pero esto ya es tema para otro artículo.

Referencias:



Sunday, 4 October 2015

Cómo escribir un libro ágil

Sí, también puede escribirse un libro de forma ágil. No solo el software se construye de esta manera. Todo esto de agile es aplicable a muchos campos, no solo a la tecnología. En esta entrada les cuento cómo usé esta filosofía de trabajo para escribir el libro Gestión práctica de proyectos con Scrum:

Centrarse en lo importante, quitar lo accesorio

A los libros actuales, sobre todo a los libros técnicos, les pasa algo parecido a lo que le pasó hace unos años a los CDs de música. Tú sólo comprabas el CD porque habías oído aquella canción por la radio pero ¿Cómo iba el CD a tener menos de 20 canciones (y costar menos de 20 euros)?

Había que rellenarlo con algo. ¿Que las últimas canciones no tenían la misma calidad que los dos o tres primeros hits del disco? Bueno, era necesario justificar el precio y rellenarlo un poco. Esto podía hacer que terminases aborreciendo al autor por aquellas tres últimas canciones en un dueto con Tom Jones o con la versión tecno-pop de su primer éxito.

Con los libros nos puede pasar lo mismo. Nos sentimos mejor si nuestro libro tiene 500 páginas y estamos dos años escribiéndolo pero ¿Qué coste tiene eso para ti que lo escribes? ¿Y para el que lo compra? Probablemente a él sólo le interesaban los capítulos sobre estimaciones ágiles o sobre las ventajas de Scrum.

Algo así me pasó a mí cuando comencé a escribirlo. Tenía muy pocas páginas y tuve la tentación de meter otros capítulos de relleno. En realidad no eran igual de interesantes que los demás o no estaban tan dirigidos hacia el tema principal del libro. Terminé quitándolos. La primera versión del libro sólo tenía unas 67 páginas pero preferí eso a que el lector se quedase con la sensación de un libro demasiado largo o aburrido.

Real artists ship!

Esta frase atribuida a Steve Jobs (Real artists ship!) alude a que los artistas de verdad no están dándole vueltas a su obra hasta conseguir el cuadro o la escultura perfecta. Lo entregan, lo sacan a la venta y miran qué es lo que interesa de verdad al mercado.

¿Has escrito un tutorial sobre la instalación de Pentaho? ¿Un manual de configuración de Wordpress? ¿Qué hacen en el cajón? Búscate una portada (hay cientos de webs por ahí para eso), dale formato, escribe una descripción atractiva y ponlo a la venta en KDP de Amazon, en iTunes o dónde quieras.

¿Sólo tiene 30 páginas? Bueno, ponlo a la venta por uno o dos dólares. Con que vendas unos cuántos ya te habrán pagado las 20 horas que te costó prepararlo. Además, habrás aprendido un montón de cosas sobre marketing digital, ventas, royalties, etc. y qué temas venden libros y cuáles no.

La perfección es una asíntota vertical

Por más que intentes escribir el libro perfecto, con la portada perfecta, con el precio exacto para el máximo de ventas y sin erratas... no podrás hacerlo. La perfección es una asíntota vertical (lo siento, de-formación profesional o más bien académica: Cálculo I en la universidad).

Cuanto mejor intentes hacerlo, mayor coste tendrá para ti. Cuando ya le hayas dedicado un número enorme de horas, dedicarle otro montón igual no te va a poner mucho más cerca de conseguir un bestseller.

Cuando saqué el libro a la venta, me di cuenta por las primeras opiniones de libro que los usuarios creían que sería un manual de Scrum. Tuve que aprender de eso y cambiar la descripción para dejarlo más claro. Pequeños cambios en la descripción tenían un impacto alto en las ventas.

Del mismo modo, cuando puse la segunda portada que utilicé para el libro aumenté las ventas alrededor de un 30%. Lamentablemente bajé un porcentaje aún mayor cuando la cambié para poner la tercera. Era una portada más cara y que a mí me parecía más bonita pero al parecer no era del gusto de los usuarios de Amazon.

Son los posibles compradores los que te dirán si el contenido, la portada o la temática les interesa o no. Puedes pensarlo y repensarlo pero hasta que el libro no esté en las estanterías virtuales no sabrás lo que funciona y lo que no. Evita la parálisis del perfeccionismo y no le des muchas vueltas. Pon tu libro a la venta y que ellos decidan (recuerda, real artists ship!).


A propósito, ya está a la venta la edición en papel de mi libro Gestión práctica de proyectos con Scrum. Si no lo habías comprado ya porque no tenías un Kindle o no te gusta leer en tu PC, ahora tienes la oportunidad de comprarlo en el formato de tapa blanda en Amazon.com o Amazon.es.
Gestión práctica de proyectos con Scrum en Amazon
Gestión práctica de proyectos con Scrum en Amazon

Sunday, 27 September 2015

Scrum en la práctica: Cómo lo usamos en DESIC

La semana pasada publicaba un prezi con una introducción al uso que dábamos a Scrum en DESIC. Esta semana les dejo con el enlace a una segunda presentación en la que concretamos con algo más de detalle cómo usamos Scrum en el trabajo diario en DESIC:

  • Cómo hacemos los tests
  • Cómo planificamos los sprints
  • Cómo ha sido el proceso hasta llegar a la versión de Scrum que utilizamos actualmente y qué nuevas automatizaciones queremos incorporar.
Tienen acceso a la presentación aquí: Scrum en la práctica: Cómo lo usamos en DESIC.

Scrum en la práctica: Cómo lo usamos en DESIC - Antonio Martel




Sunday, 20 September 2015

Presentación Cómo usamos Scrum en DESIC (I)

He creado una presentación en prezi que muestra cómo usamos Scrum en DESIC: nuestra particular versión de este marco de trabajo y cómo lo aplicamos. En las últimas diapositivas explico también las que creo que son las principales ventajas que Scrum (o agile si quieres) aporta a los proyectos en general (y a los nuestros en particular).

Puedes acceder a la presentación a pantalla completa haciendo clic en la imagen o en este enlace directamente a prezi: Cómo usamos Scrum en DESIC (I).

Cómo usamos Scrum/Agile en DESIC por Antonio Martel


Sunday, 13 September 2015

Cómo usamos Scrum en DESIC

En los blogs sobre software o metodologías varias solemos contar las bondades del framework que usamos o filosofamos sobre el devenir de la industria pero pocas veces contamos qué tal nos va o qué estamos haciendo exactamente en nuestro trabajo diario. De eso va esta entrada, de cómo trabajamos y de qué hacemos para sacar adelante nuestros proyectos.

Trabajo en DESIC, una empresa de desarrollo de software canaria, en la que llevo trabajando en multitud de proyectos desde hace ya más de 10 años. Llevamos unos cuantos intentando ser un poco más ágiles en cada uno de esos proyectos. De unos se aprendió qué debíamos hacer, de otros aprendimos qué no había que hacer y de lo aprendido en todos ellos hemos llegado al estado actual (mejorable aún, eso seguro). Aquí van unas pinceladas sobre cómo trabajamos en DESIC:

Trac para planificar el sprint

No usamos una de esas populares herramientas de gestión de tableros kanban, ni siquiera tenemos un tablero físico con todas esas pegatinas de colores. Usamos Trac en su lugar. Ya sé que no suena tan cool y que tiene una pinta un poco, digamos, vintage, pero nos funciona y la verdad es que lo hace bastante bien.

Cada dos semanas planificamos las tareas a realizar durante las siguientes dos semanas y las introducimos como tickets en el trac para el sprint que vamos a comenzar. Cada vez que alguien resuelve un ticket entra en trac y lo marca como cerrado o lo pasa a un compañero para que continúe con su parte. De un simple vistazo todos vemos el trabajo pendiente que nos queda por acabar y la prioridad que tiene.

Si no hemos podido cerrar muchos tickets en este sprint nos quedamos algo preocupados porque llegaremos al día de demo y no tendremos mucho que enseñar. En cambio si todo ha ido bien y hemos terminado nuestros tickets e incluso comenzamos ya con los de la semana siguiente vamos a estar mucho más contentos (sí, a veces adelantamos lo previsto para el sprint).

Cómo planificamos el sprint

Normalmente tenemos sprints de dos semanas que en alguna ocasión han sido de 3 por vacaciones de parte del equipo de trabajo durante las navidades y en otras de solo una semana. Esto último no funcionó nada bien. Fue muy difícil planificar una demo, la planificación del siguiente sprint, pruebas y todo lo demás en sólo 5 días de trabajo.

Les pongo aquí cómo es el calendario habitual en un uno de nuestros sprints de dos semanas. Está copiado casi literalmente del panel de Google+ donde anunciamos lo que tenemos previsto para los próximos días:

Previsto en el sprint del proyecto para el paso por test, pre-demo y demo:
1. Miércoles de 2ª semana del sprint: 
          a) Test de la batería de tests de 8:00 a 12:00
          b) Pre-demo de 12:00 a 13:30
2. Jueves de 2ª semana del sprint:
          a) Correcciones a bugs/incidencias de 8:00 a 12:00
          b) Subida a demo a las 13:00 (con lo que haya hasta ese momento. No será posible hacer nuevas subidas hasta la demo del día siguiente)
          c) Después de demo correcciones que no hayan podido caber en esta demo y trabajo en siguiente sprint hasta la demo del día siguiente.
3. Viernes de demo
          a) Demo a las 12:00
          b) Planificación del siguiente sprint a las 13:00

En esta planificación que pueden ver ahí, hay algunas cosas que son particulares a nuestra forma de trabajar:
  • Tenemos una pre-demo el miércoles antes de terminar el sprint. Se estableció así porque en las primeras demo de los viernes fallaban muchas cosas o no nos habíamos entendido bien. Se muestra sólo al Scrum Master lo que han hecho durante esas casi dos semanas que puede ya ir viendo cómo de bien o mal va a quedar el sprint. Esto sirve también de ensayo para lo que vamos a ver el viernes en la reunión de demo real.
  • El último día del sprint, el viernes de la segunda semana tenemos una demo ante todo el equipo de trabajo, en la que no siempre está el Product Owner, nuestro cliente. Trabajamos en un entorno distribuido por lo que no podemos estar en las mismas oficinas que nuestro cliente cada dos semanas. La misma aplicación que hemos visto en demo la enviamos al product owner para que pueda comprobar el trabajo hecho en ese sprint y que valide o no el resultado.
  • En clientes más recientes, que han adoptado la agilidad desde hace mucho, hacemos una demo por Skype y se le explica lo realizado en esas semanas. Al final hay una retrospectiva en el que nos cuenta su impresión de lo que hemos hecho y lo que le ha gustado o no y puede mejorarse. Es una demo ensayada y probada para intentar que todo quede casi cronometrado en una hora de duración.

Cómo informamos al cliente

Cada vez que termina un sprint enviamos al cliente un informe de estado con las tareas y tickets de trac que hemos cerrado en esas dos semanas. Así pueden saber qué se pudo completar de lo previsto. Del mismo modo enviamos también qué tickets tenemos previsto cerrar durante las próximas dos semanas. Si todo ha ido bien deberá ser muy parecido a lo que digamos en el siguiente informe de estado que hemos podido finalizar.

Estos correos van con copia a la cuenta de correo de todo el grupo de trabajo y en él le indicamos al cliente también la URL donde podrá probar la versión de la aplicación que acabamos de desplegar y que revisamos en nuestra demo interna del viernes. En el correo van también las instrucciones sobre cómo probar los cambios realizados o dónde pueden encontrarlos.

En todo momento los clientes tienen acceso al entorno de demo para hacer sus pruebas, indicarnos qué va mal o decirnos qué cambios quiere sobre lo que está probando. Este entorno ha resultado ser muy útil porque nos permite mostrar muy rápidamente cada cambio aunque no esté finalizado sin tener que esperar a despliegues programados en pre-explotación o en producción.


Puedes ver más sobre las herramientas que usamos en esta otra entrada: Google+ como herramienta de gestión de proyectos.


Sunday, 16 August 2015

Ya está a la venta el libro Certificación Professional Scrum Master: PSM I

Ya salió a la venta en Amazon el libro Certificación Professional Scrum Master: Cómo preparar la certificación PSM I de Scrum.org. Puedes comprarlo ya, estará en promoción a precio especial durante las próximas semanas (septiembre - octubre 2015).

En este libro vas a encontrar todo lo que necesites saber para aprobar la certificación como Profesional Scrum Master (PSM I) a la primera junto a:
  • Un enlace a un test online gratuito y de acceso ilimitado donde podrás practicar las veces que quieras preguntas en español similares a las que encontrarás en el examen real de PSM I.
  • Cuatro tests de pruebas que podrás descargarte también en formato PDF a tu PC o tablet o imprimir para poder practicar los tests sin necesidad de conexión a Internet.
  • Soluciones a las preguntas del test online y de los test de prácticas incluidos en el libro.
  • 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
  • Listado de guías de preparación, libros, resúmenes y recursos en general que te ayudarán a prepararte para el examen.
  • Consejos prácticos para aprobar la certificación que me sirvieron a mí para aprobar al primer intento y que probablemente puedan ayudarte a ti a hacerlo también.
Es un ebook en formato Kindle pero no te preocupes si no tienes un lector de libros electrónicos. Una vez comprado seleccionas que lo quieres leer en Kindle Cloud Reader y desde entonces podrás leerlo siempre que quieras sólo con ir a la página read.amazon.com. En tu ordenador de casa, en un tablet o en tu móvil, donde quieras.

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)





Tuesday, 11 August 2015

Gestión práctica de proyectos en el Top 100 de Amazon

Después de la promoción Kindle Flash el libro Gestión práctica de proyectos con Scrum se ha colocado por primera vez en el top 100 en ventas de la Tienda Kindle de Amazon.es.

Llegó a alcanzar el número 9 de 7:00 a 8:00 de la tarde y en estos momentos, sobre las 9:00 de la noche, ha llegado al número 3 del total de ventas (Grey, el segundo libro de E.L. James, autor de Cincuenta sombras de Grey está en el número 7 e Italo Calvino, con El barón rampante en el 19).

El libro también ha alcanzado puestos altos en Amazon.com. En concreto la posición número 2 en la categoría Computación e Internet de todos los libros en español (no sólo Kindle) en Amazon.

Actualización (miércoles, 12 de agosto): Hoy ha alcanzado el número 1 en el total de ventas en la Tienda Kindle de Amazon.es (2º día en el Top 100). Además, en Amazon.com, ha alcanzado también la posición nº 1 en tres categorías al mismo tiempo. Un de ellas es la categoría de Negocios e Inversiones para todos los libros en en español (no sólo Kindle).












Mi libro hoy en la promoción Kindle Flash de Amazon

Mi libro Gestión práctica de proyectos con Scrum ha sido incluido entre los tres libros promocionados hoy por Amazon en su selección Kindle Flash.

Junto a mi libro están también de promoción:
  • Mi alma gemela de Caroline March que fue II Premio Digital en los premios HQÑ.
  • El barón rampante de Italo Calvino.
Si aún no lo has leído, anímate a comprarlo. Con esta promoción estará durante todo el día con un descuento del 80%.

Haciendo clic en la portada tienes el enlace a la oferta de hoy en Kindle Flash de Amazon.com:

(Actualización: Parece que esto de ser promocionados por Amazon funciona. Hoy a las 6:15 de la mañana ya había vendido 30 libros! Espero que no los devuelvan todos...)


Sunday, 19 July 2015

Ya está a la venta el libro Espacios culturales de Las Palmas de Gran Canaria

El libro Espacios culturales de Las Palmas de Gran Canaria, de mi hermano Carmelo Martel, ya está a la venta por fin en Amazon. Ha llegado a estar durante casi todo el día de hoy domingo en el número 1 en la categoría de Arquitectura de la Tienda Kindle de Amazon España (en el momento que escribo estas líneas está en el número 4).

Si se busca 'Las Palmas de Gran Canaria' en Amazon España o Amazon.com, el libro aparece en las posiciones 1 y 2 entre los más de 500 resultados de, por ejemplo, amazon.es.

Les dejo un enlace al libro y a las imágenes de las posiciones que tuvo el libro durante la mañana de hoy. No necesitan un lector kindle ni una tableta para probarlo, ni siquiera instalarse una app ni nada parecido en el equipo. Al comprarlo, Amazon detecta que no tienen un Kindle y ya les ofrece la opción por defecto para que puedan leerlo desde su PC, portátil o Mac usando sólo el navegador.




Es un ebook en formato Kindle pero no te preocupes si no tienes un lector de libros electrónicos. Una vez comprado seleccionas que lo quieres leer en Kindle Cloud Reader y desde entonces podrás leerlo siempre que quieras sólo con ir a la página read.amazon.com. En tu ordenador de casa, en un tablet o en tu móvil, donde quieras. 




Sunday, 12 July 2015

El libro Espacios culturales en Las Palmas de Gran Canaria

Mi hermano, Carmelo Martel, también ha publicado un libro en Amazon. Se titula 'Espacios culturales en Las Palmas de Gran Canaria'. Trata sobre el desarrollo urbanístico y cultural que se ha creado en Las Palmas de GC, desde 1950 hasta hoy en día, alrededor de centros culturales como el CAAM, el Teatro Cuyás, La Regenta, La Casa de Colón o el Pueblo Canario entre otros muchos. 

Está en lanzamiento estos días en Amazon. Resérvalo ya haciendo clic en la imagen o en este enlace: Espacios culturales en Las Palmas de Gran Canaria. Lo recibirás en tu móvil, tablet, mac o pc el domingo 17.

El libro está en formato Kindle, pero no te preocupes si no tienes este lector, puedes bajarte la app para que puedas leerlo desde tu móvil Android, iPhone, tableta, pc, o mac. Sólo tienes que hacer clic en este enlace de Amazon y pulsar Descargar, él sólo detectará desde qué dispositivo lo estás instalando.

Aprovechen el precio reducido que tiene ahora para intentar que se coloque alto en las listas de Amazon. De momento, ya ha llegado a colocarse en el top 6 de la lista de ventas en la sección de Arquitectura para libros Kindle en Amazon España.




Si se animan a leerlo, cualquier comentario que le ayude a mejorar el libro será bienvenido. Por supuesto también, si pueden darle difusión entre sus amigos, sus redes sociales o, si lo leen, les gusta y quieren dejarle un comentario en Amazon, seguro que les estará muy agradecido.




Sunday, 5 July 2015

Qué certificación agile elegir: ventajas y desventajas

También me preguntan de cuando en cuando me preguntan a través del blog qué certificación ágil es la más valorada o cuál es la que más les conviene para acceder a un puesto de Scrum Master o Product Owner.

Actualmente, las tres más importantes son Professional Scrum Master (PSM) de Scrum.org, Certified Scrum Master (CSM) de Scrum Alliance y Agile Certified Professional (PMI-ACP) de PMI (los mismos de la certificación PMP).

Las dos primeras tienen su origen en la misma persona, Ken Schwaber. Ken es uno de los creadores de Scrum, que junto con Jeff Sutherland, definió las versiones iniciales de Scrum que presentaron juntos formalmente en la OOPSLA del 95.

Juntos crearon también la organización Scrum Alliance en la que comenzaron a certificar profesionales de Scrum con la certificación CSM.

En 2010, Ken decide dejar la Scrum Alliance y fundar el instituto scrum.org para intentar orientarlo más hacia el objetivo de divulgar Scrum. Desde este nuevo instituto (scrum.org) se comenzaron a entregar las certificaciones PSM. Desde 2012 hay también un nuevo competidor en liza, la certificación PMI-ACP que está sonando bastante fuerte desde entonces.

Comparativa entre las certificaciones ágiles

  • PMP. Test sólo online. Coste 150 dólares. 80 preguntas en inglés a resolver en 60 minutos. Necesario tener un 85% de preguntas correctas. El certificado no expira.
  • CSM. Antes del examen debes tomar un curso de dos días cuyo coste puede rondar entre los 1000 y los 2000 dólares. Luego un test presencial de 35 preguntas (en 2012) de las que tendrás que acertar 24. Al parecer no es complejo. Deberás renovar el certificado cada dos años aportando 100 dólares y, a partir de 2015, un cierto número de SEUs (algo equivalente a las PDU de PMI).
  • PMI-ACP. Se requieren 1500 horas de experiencia ágil previa y 21 horas de un curso de formación ágil en cualquier institución que te lo certifique. Test de 120 preguntas en un centro Prometric. El certificado debe renovarse cada tres años para lo que se debe obtener 30 PDUs nuevos en gestión de proyectos (1 PDU equivale a una hora de formación o actividad profesional).

Qué certificación ágil elegir

Esto depende de muchos factores: Cuál es la más valorada en el sector en el que trabajar, la facilidad o no de acceder a un curso de preparación, tu disponibilidad de tiempo o dinero o los conocimientos previos sobre Scrum que tengas.

Probablemente PMI-ACP o CSM sean más valoradas actualmente que Professional Scrum Master pero te cuento los criterios por los que yo aposté por esta última (PSM I):
  • PSM I es una de las tres certificaciones principales. Está respaldada por uno de los fundadores de Scrum y lleva tiempo en liza por lo que a la hora de pedir una certificación Scrum es siempre una de las requeridas.
  • Viviendo lejos de alguna de las ciudades más importantes era difícil para mí tomar un curso de preparación para CSM o para pasar un test en un centro Prometric. Al coste del certificado se requeriría añadir el de los billetes de avión o la estancia de una o dos noches de hotel.
  • El tiempo de preparación es más bajo para PSM que para PMI-ACP que también me habría requerido tomar algún otro curso de gestión de proyectos y gestionar con PMI los PDUs que obtuviera.
Teniendo todo esto en cuenta e intentado ser ágil en la toma de decisiones (como un Product Owner priorizando su backlog) la respuesta era clara para mí. Con PSM I iba a obtener probablemente un 80% de los beneficios de cualquiera de las otras dos certificaciones pero a un coste en tiempo y dinero mucho menor. Además el tiempo en recuperar mi inversión era mucho más bajo. Así que desde 2013 estoy certificado como PSM I.



Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.


Referencias:

Sunday, 28 June 2015

Ponencia sobre GUIRRE en las Jornadas del proyecto Resiless

Femepa ha tenido a bien invitar un año más a DESIC a dar, el pasado jueves, una ponencia sobre el sistema de información GUIRRE que hemos venido diseñando y evolucionando en los últimos años para la Viceconsejería de Medio Ambiente del Gobierno de Canarias.

GUIRRE es el acrónimo para el Sistema de Información de Residuos de Canarias y en su ponencia, mi compañero Aridany Ramírez, jefe de proyecto para los desarrollos en esta aplicación, ha explicado los avances realizados en el último año:
  • La posibilidad para gestores y productores de residuos de presentar documentos de control y seguimiento (DCS) a través de la sede (habilitado cuando se apruebe la normativa que admite este medio como presentación oficial).
  • La pantalla de avisos en GUIRRE que permite al técnico de medio ambiente saber si se acaba de entregar un DCS para un residuo en el que el gestor no está autorizado o si el centro que la ha presentado tiene su autorización en vigor. 
  • La aplicación que lee la bandeja de correos electrónicos donde los gestores de residuos, además de la presentación oficial, envían el documento en formato electrónico. Esta aplicación lee estos correos, los interpreta y guarda en la base de datos de GUIRRE indicando al usuario si el documento es correcto, si ya lo ha presentado anteriormente o si se ha equivocado y ha enviado una notificación de traslado (NT) en lugar de un DCS.
Al final del año ya el gestor ha dicho a la Consejería a través de los DCS qué ha hecho con los residuos, a quién se los recogió, quién los transportó y a qué centro los entregó. Con toda esta información recibida a través de los DCS que ha ido entregando a lo largo del año, un gestor de residuos podrá generar un borrador de la memoria que deben entregar cada anualmente. . 

A través de una nueva opción, los gestores se traen todos los datos que GUIRRE tiene de ellos y los importan en la memoria anual de forma similar a como lo hace la declaración de la renta. Si está de acuerdo con lo allí presentado o quiere añadir algo más, sólo tiene que completar el resto y pulsar el botón tramitar (esto puede ser importante para gestores que llegan a presentar memorias de más de 300 páginas).

También intervinieron en estas jornadas Carlota Cruz, directora de la fundación Canarias Recicla y Juan Carlos Betancor, secretario general de Femepa.

Y por último, les dejo la presentación en prezi que utilizó Aridany Ramírez para su ponencia: Gestión de Residuos - Sistema de Información de Residuos de Canarias y algunas fotos del evento:







Sunday, 21 June 2015

El sprint 0 de Scrum y el diseño inicial

Hace poco me preguntaban a través del blog sobre qué es lo que hay antes del primer sprint de Scrum. Al lector le daba la impresión de que todos los textos que leía sobre Scrum empezaban directamente en el desarrollo pero y ¿qué hay de la preparación de los entornos, de los equipos o de la oficina? ¿y del diseño? ¿No hay que pararse a pensar en todo el diseño y la arquitectura de lo que vamos a construir antes de empezar a programar?

Sobre la preparación o el 'antes' de comenzar a programar, hay gente que lo resuelve con el llamado 'sprint número 0' en el que se preparan las herramientas, se instala lo que se necesita, se forma al equipo, etc. Puede ser un sprint más largo (3, 4 semanas o así). Hay algunos detractores a este sprint nº 0 por no ser ágil y estar escondiendo ahí un trabajo que no se está resolviendo en la misma forma que el resto del trabajo. 

Es cierto que puede ser muy cómodo porque le dices al cliente que en 3 semanas estás de vuelta para tener la reunión de preparación del primer sprint y para entonces tú ya tienes casi todo organizado. También he usado esos sprints 0 en mis primeros proyectos pero ahora prefiero resolver esos trabajos también de forma ágil.

Intento que cada una de esas tareas (instalar servidor de despliegue, instalar servidor de demo, crear proyecto y tareas en Trac o Redmine, instalar IDE, etc.) formen parte ya del primer sprint y que tengan, en lo posible, un entregable al final de cada demo.

En esa demo podría mostrarse por ejemplo la herramienta de gestión de proyectos ya instalada en la url definitiva y con la lista de tareas esperando ser asignadas, o arrancar el IDE en esa reunión de demo comprobando que el workspace está bien creado y que el jetty ejecuta correctamente una aplicación 'Hola Mundo'.

Otro punto importante es el diseño inicial de la arquitectura. Si hacemos un gran diseño de toda la arquitectura de la aplicación (big up-front design) antes de comenzar a programar nada estaremos volviendo hacia un diseño en cascada tradicional: primero lo analizamos todo, tres meses después hacemos todo el diseño durante otro par de meses, y por último comenzamos a programarlo todo del tirón hasta acabarlo seis meses más tarde. Si al acabar todo el trabajo se lo enseñas al cliente y te dice: 'eso no es lo que hablamos hace un año...' estamos ante un problema.

Mejor haz el diseño de uno de los módulos de la aplicación o de la nueva funcionalidad, crea las especificaciones y pásalas a desarrollar. Mientras una parte del equipo lo implementa, los analistas pueden ir recogiendo los requisitos para otro nuevo módulo u otras funcionalidades, y así sprint tras sprint.

Habrá sprints en los que no haya nuevas cosas que analizar y otros en los que el desarrollo avanza un poco más rápido de las especificaciones pero normalmente siempre hay algún trabajo listo para comenzar hasta que el product owner dé su visto bueno a los últimos requisitos o estén ya completamente definidos.

Trabajando así, los nuevos módulos o funcionalidades podrían ir pasando a producción o pre-producción cada cierto tiempo por lo que los usuarios pueden ir usándolos sin esperar hasta que la última de las características de la aplicación esté diseñada.

Referencias:

Sunday, 14 June 2015

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

Sunday, 7 June 2015

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:

Sunday, 31 May 2015

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.

Sunday, 17 May 2015

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)



Sunday, 10 May 2015

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:

Sunday, 3 May 2015

La banca también es ágil

Comentaba la semana pasada que la agilidad no está siendo usada solo por los proyecto software sino que también la aplican tiendas de moda como Zara o bancos como ING para su departamento de IT.

Pero ING no es el único banco que utiliza Scrum y otros métodos ágiles en su gestión. También lo hace el banco BBVA Compass, filial americana del BBVA. Su director de informática cuenta sobre los métodos ágiles:

«Los rigurosos y repetitivos procesos de desarrollo de agile nos permiten reaccionar más rápidamente ante los problemas que surgen sin que los plazos y los clientes se vean perjudicados».

«Crear un entorno agile es mucho más que poner en práctica una nueva forma de gestionar proyectos»

«Estamos cambiando nuestra mentalidad, nuestra cultura».

La señora Huesman, directora de la oficina de gestión de carteras del BBVA Compass afirma también que en apenas seis semanas de aplicar la agilidad ya habían evitado retrasos y sobrecostes al identificar los problemas mucho antes que con la metodología en cascada.

Aquí, en España, también lo usa directamente el tan denostado Bankia que empieza a hacer cosas de manera diferente con sus oficinas ágiles (esperemos que sea así siempre). Estas oficinas están especializadas en operaciones y transacciones básicas que comercializan productos sencillos dejando para sus oficinas convencionales cercanas el asesoramiento y los productos complejos.

Las llamadas oficinas ágiles de Bankia son antiguas sucursales reformadas para darles una nueva imagen y que cuentan también con un horario más amplio, hasta las seis de la tarde de forma ininterrumpida.

En Bankia fueron ágiles también en la apertura de estas oficinas. No abrieron todas las sucursales al mismo tiempo sino que en 2013 crearon la primera oficina ágil en Alcalá de Henares (Madrid) como proyecto piloto. Su éxito permitió que otras veinte oficinas más se abrieran ese mismo año. En 2014, la entidad contaba ya con 120 oficinas ágiles a la que se espera que se unan otras 20 nuevas oficinas durante este año.

Según Bankia, la productividad de estas oficinas ha tenido un incremento de "dos dígitos altos" durante el último año dejando el tiempo medio de espera en 3:31 minutos y el de atención en 4:53. Esto supone, según el director de banca particular de Bankia, que desde que los clientes entran hasta que terminaron sus gestiones, han pasado menos de diez minutos.

Parece que incluso sectores tan tradicionales como la banca se apuntan a esto de la agilidad. Está empezando a dejar de ser sólo cosa de informáticos.



Referencias:

Monday, 27 April 2015

Scrum en la serie de TV Silicon Valley y en las tiendas Zara

Scrum, Lean y otros métodos ágiles se están haciendo cada vez más populares. Han pasado de la industria del automóvil al del desarrollo del software y de ahí se está disparando hacia un gran número de sectores diferentes. Hasta en Hollywood se ha interesado por estos nuevos métodos.

Ya se están viendo casos como el del gigante de la moda Zara que usando Lean Manufacturing o Lean Management para producir determinados artículos sólo cuando hay demanda (just in time). Cuando comprueba que una nueva línea de prendas con topos rojos está causando sensación, pone en marcha su maquinaria para fabricar y enviar en solo unos días los nuevos productos a sus tiendas de Shangai o Nueva York.

No tiene que esperar a la próxima temporada de otoño-invierno para diseñar, producir y distribuir los productos que veremos en verano en las tiendas ¡A saber qué estará de moda en ese momento!

También está pasando en la banca. Hablaba hace unos días del caso de ING pero no se está limitando sólo a sus departamentos de informática sino también de oficinas ágiles que intentan adaptarse a las nuevas necesidades de los clientes (ya hablaré de banca ágil en otro post).

Pero quizás la prueba definitiva de la popularidad de lo ágil venga de la mano de la televisión. En la comedia Silicon Valley de la HBO los actores interpretan a programadores recluidos en la casa de un millonario gracias a las páginas web. En varios capítulos pueden verse tableros kanban, gráficas burn-down o de deuda técnica.

En otro capítulo un consejero de la start-up recomienda al dueño usar Scrum pero cuando deciden implantarlo el equipo se queja amargamente y todo acaba con muy malos resultados (ya sabes, es sólo ficción).



Referencias:






Sunday, 19 April 2015

Meteduras de pata, confianza y política CYA

Los errores en un proyecto software son algo habitual, algo con lo que lidiar cada día. Se calcula que una aplicación web tiene una media de 4 errores por cada punto de función (contando 1 punto de función como unas 50-55 líneas aproximadamente de código Java).

Recuerdo incluso haber leído en mis tiempos de Universidad que, en la construcción de cierto sistema operativo, por cada 3 bugs corregidos se introducían 2 nuevos. Quizás una aplicación web no tenga la complejidad de ese sistema operativo pero no me resultaría extraño si alguien me dijera que en ese caso la relación fuese de 3 a 1.

Los errores al programar no son los únicos fallos que puede cometer un equipo de desarrollo. Pueden haberse entendido mal las especificaciones. Pueden haber olvidado copiar un archivo en un despliegue o no haber concretado lo suficiente un requerimiento. Oportunidades para equivocarse hay muchas.

Si ante cada error afeamos la conducta al que lo cometió e insistimos en encontrar al culpable para señalarlo con el dedo sólo vamos a conseguir que el equipo de trabajo esté más preocupado de salvar su pellejo que de hacer su trabajo lo mejor que sabe. Se tenderá a argumentar y argumentar en la documentación para justificar el porqué de las decisiones y dejar claro quién fue el que tomó la decisión.

En inglés hay un término llamado 'CYA (cover your ass)' para indicar cuando se están tomando acciones sólo para protegerse las espaldas. Se dice también que cuando no tienes que emplear una mano en tapar tus vergüenzas puedes contar con las dos manos para trabajar mejor.

Si logramos en nuestros equipos una cultura 'No need to CYA' podremos trabajar más tranquilos y ocuparnos sólo en entregar nuestro trabajo. Si alguien comete un error, bueno, quizás la próxima vez sea uno mismo quién lo cometa. Se asume, se explica, se toman las acciones necesarias para corregirlo y se avanza a la siguiente tarea. Es más rápido y más efectivo que estar buscando al culpable entre acusaciones cruzadas.


Referencias:


Sunday, 5 April 2015

Estadísticas de uso de Scrum (2015)

Este es el tercer año ya que publico estas estadísticas sobre el uso de Scrum. En 2013 se podía ver que términos como Scrum, Agile o Kanban estaban en pleno auge. Había muchos resultados en los portales de empleo o en las búsquedas de Google.

En 2014 prácticas concretas como Scrum o Kanban tenían aún en España una fuerte subida con respecto al año anterior. En cambio, en países del norte de Europa como Alemania o Reino Unido la subida no era tan grande o incluso bajaban. Términos más genéricos como Agile mantenían y aumentaban mucho su presencia en las redes. Veamos ahora 2015.


Para España (infojobs.net) se ve una fuerte subida de Scrum y Lean (esta última cada vez tiene más peso en el mundo Ágil). También se aprecia un aumento importante de puestos de trabajo que solicitan PMP. Un 33% nada menos. Sigue sonando fuerte la certificación de pmi.org.

Estas subidas tan altas podrían deberse en parte a que existe un número mayor de ofertas de trabajo en general en el mercado español. Por esto los resultados podrían ser más positivos al haber más demanda de empleo en general.

En el Reino Unido (monster.co.uk) hay una bajada muy fuerte de todos las palabras clave. Parece que el número de ofertas puede haber bajado al haber una mayor deslocalización de puestos de operaciones IT hacia Asia. Puede también que monster.co.uk haya sufrida una fuerte competencia de otros sitios web de empleo o LinkedIn y ya no sea tan popular en UK.

En Alemania me ha sorprendido sobre todo el alto número de puestos de trabajo que solicitan PMP que sube un 265%. PMP no es requerido solo para puestos IT sino también para la industria de la automoción. Diría que PMP tiene un gran futuro en Alemania.

También se puede comprobar en la tabla la importante subida que tiene Lean en Alemania al igual que sucede en España. Es curioso también que en Alemania han comenzado a declinar en su idioma la palabra agile. Si sólo se busca por ella aparece la mitad de resultados. Buscando por otras combinaciones (agile or agiler or agiles or agil or agilen) hay más de mil ofertas de empleo que buscan a alguien 'ágil'.

Aquí ahora la comparativa entre Scrum, Agile y PMP de todos los años con Google Trends:

Scrum y PMP están empatados en número de búsquedas en Internet. PMP ha moderado su caída de los últimos años y el interés por Scrum parece aumentar en lo que llevamos de este año 2015. Las búsquedas en Internet por la palabra Agile siguen aumentando y suman ya casi tanto como las búsquedas por Scrum y PMP juntas.

Por si es de interés aquí tienes esta misma comparativa del uso de Scrum para los años 2013 y 2014:


Sunday, 22 March 2015

Scrum en ING Holanda

ING Holanda había comprobado mediante proyectos piloto que el rendimiento de su departamento IT era, competitivamente hablando, muy desfavorable. Existía una cultura de la burocracia en la organización y, desde el resto de departamentos, había una clara insatisfacción con los servicios que proporcionaba.

El responsable de canales digitales de ING decidió tomar cartas en el asunto poniéndose como meta conseguir el doble del valor que se estaba obteniendo por cada euro que se destinaba a IT. Pidió consejo a un gran número de colegas sobre qué podía hacerse para mejorar el rendimiento de este departamento. La mayoría de ellos apuntaron a Scrum como posible solución. Inmediatamente se reunió con colaboradores de Capgemini para estudiar la adopción de Scrum en ING y en el departamento de IT específicamente.

Los primeros proyectos pilotos con Scrum comenzaron en 2011. El ciclo de vida para esos proyectos se redujo de los 3-6 meses a 6-9 semanas. Inicialmente se usaron puntos de función (FP) para medir la productividad. El ratio euro/FP y la calidad, expresada en defectos/FP, se mantuvieron pero los equipos Scrum habían realizado importantes trabajos de mantenimiento y mejora en el código.

No solo la innovación y la satisfacción del empleado subieron drásticamente sino que también lo hizo la mejora de las habilidades técnicas y la colaboración entre los miembros del equipo de trabajo. Desde los departamentos de negocio de ING comenzó también a aumentar la confianza en el departamento IT a medida que se iba entregando con éxito nuevo software que además era usable.

La reducción de costes en la entrega de software estaba en un rango de entre el 30 y el 50%. El número de incidencias técnicas reportadas se había reducido, en algunos casos, incluso por encima del 30%. La cantidad de releases puestas en producción se aumentó gradualmente para reducir los ciclos y para aumentar el aprendizaje (cuanto antes se ponía en producción antes se aprendía qué era bueno y qué no o como mejorar el producto).

Para septiembre de 2012 el número de equipos Scrum en ING había pasado de 45 a 75. Se esperaba que para diciembre de 2012 todos los equipos de trabajo en ING Holanda hubiesen adoptado Scrum en sus proyectos.

¿Y tú? ¿Pensando en adoptar Scrum en tus proyectos? Quizás te interese continuar leyendo aquí
Jornada sobre cómo "Adoptar Scrum y sobrevivir al intento...", aquí Implementar Scrum y cómo sobrevivir para contarlo o en mi libro Gestión práctica de proyectos con Scrum.

Referencias: