Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

Gestión práctica de proyectos en Google Play

No sólo de Amazon viven los libros. Desde hace unos días, mi libro Gestión práctica de proyectos con Scrum está en preventa en Google Play Books. Puedes reservarlo ahora que lo recibirás la próxima semana cuando esté a la venta de forma oficial.

Google Play es el antiguo Android Market y es algo así como el iTunes de Apple. Es una tienda online en la que puedes comprar desde música, libros y películas hasta teléfonos móviles.

Google Play Books (o Libros) es también una app que viene incluida por defecto en todos los móviles y tabletas Android. Si la buscas dentro del menú aplicaciones de tu móvil la encontrarás junto a Play Store, Play Música, Play Películasm, etc. Una vez comprado el libro podrás leerlo en el móvil con esta app o desde tu propio navegador en un PC o portátil.

En el momento en el que escribo esto, si buscas la palabra Scrum en Google Play Books, el libro aparece en la tercera posición del resultado de las búsquedas (supongo que estará priorizando los resultados en español y por eso sale algo más alto) ¡A ver si se mantiene ahí!

Les dejo aquí el enlace al libro en el Google Store:

Gestión práctica de proyectos con Scrum en Google Play Books
Gestión práctica de proyectos en Google Play Books

Gestión práctica de proyectos con Scrum de nuevo en el Top 100

Después de la promoción de ayer de Amazon, Gestión práctica de proyectos con Scrum, está desde ayer de nuevo en la lista de libros más vendidos en Amazon España. Hoy sobre las 10:00 de la mañana llegó a alcanzar el puesto número 5 en ventas siendo número 1 en tres categorías al mismo tiempo entre los libros Kindle:

  • Internet y web entre los libros Kindle
  • Programación y desarrollo de software entre todos los libros (papel y ebooks)
  • Internet y web entre todos los libros (papel y ebooks)
En Amazon.com alcanzó también el puesto número 4 en la categoría Gestión de proyectos software (ebooks de todos los idiomas).
En el momento en que escribo esto, el libro está en el puesto número 11 de la lista de más vendidos de la Tienda Kindle de Amazon. En el 15 está El regreso del Catón de Matilde Asensi y en el 21 Palmeras en la nieve de Luz Gabás (claro que ellos estarán mañana ahí también y mi libro mucho más abajo).

Mi libro de nuevo en la Kindle Flash

Hoy domingo estará mi libro Gestión práctica de proyectos con Scrum entre los promocionados hoy por Amazon en su selección Kindle Flash.

Junto a mi libro están también de promoción:

  • La nube en la que vivo. Calum (El libro oficial) de Calum Heaslip.
  • El secreto del alquimista de Scott Mariani.
También en Kindle Flash con otros precios promocionales podrás encontrar libros como Nunca dejes de bailar de Carmen Grau o una selección de libros de Julia Navarro como Dime quién soy o Dispara, yo ya estoy muerto.

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 75%.

Haciendo clic en la portada tienes el enlace a la oferta de hoy en Kindle Flash de Amazon.com, Amazon.es y Amazon Méjico:

Amazon.com
Amazon.es
Amazon.com.mx

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?

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

 

Suscríbete