Ajedrez - antoniomartel.com

Archivos por Etiqueta: gestión de proyectos

Preguntas de examen PMP con QuizPM

Si estás pensando en obtener la certificación PMP de gestión de proyectos y buscas preguntas y tests para practicar o un simulador del examen en español, échale un vistazo a la nueva web QuizPM.

Ahí vas a encontrar varios modos de examen con una base de datos de más de 1.500 preguntas similares a las que encontrarás en el examen oficial:

  • Modo Personalizado, para los que están empezando a asimilar los conceptos del BOK de PMP.
  • Modo Inteligente, donde el sistema, basándose en tu historial, te propone preguntas sobre aquellas áreas de conocimiento en las que tienes peor porcentaje de aciertos.
  • Modo Examen, para los que ya se sienten preparados para el examen real y quieren hacer una simulación lo más parecida a la realidad posible: 200 preguntas a resolver en cuatro horas con 72 segundos para responder cada una.
  • Test de prueba: Un test de 50 preguntas en el que podrás probar el simulador de forma gratuita y valorar si estás preparado ya o si quieres continuar y suscribirte para hacer tests con baterías de preguntas más grandes.
Me ha sorprendido mucho la cantidad de funcionalidades y ayudas para practicar los tests que tienes. En todo momento tienes a tu izquierda el número de preguntas que ya has resuelto, el número de minutos y segundos que te quedan para acabar pero también puedes guardar el test para continuar en otro momento y, si minimizas la pantalla o pones el foco en otra ventana, QuizPM entra automáticamente en pausa para que puedas continuar más adelante sin perder tiempo para el examen.
También me ha sorprendido el agradable diseño gráfico y lo fácil e intuitivo que es de entender tu historial de aciertos o cómo grabar y recuperar el estado del último test que estabas realizando. La web tiene un diseño responsive que te permitirá hacer los tests desde tu móvil de una forma muy cómoda y clara: no hay letras pequeñas y se adapta a varios tipos de pantalla y giros con el móvil.
No sólo está en español sino que puedes ver también las preguntas en inglés para la traducción exacta de ciertos términos del BOK de PMP. Esto es importante si vas a realizar el test fuera y lo tienes que realizar en inglés pero los libros que has leído han sido siempre en español.
Les dejo con algunas imágenes de la aplicación:

 

 

 

Tercera edición del libro Gestión práctica de proyectos con Scrum

En unas semanas estará disponible en Amazon, en su versión ebook, la tercera edición del libro Gestión práctica de proyectos con Scrum.

Más de 25 nuevas páginas de contenidos que incluyen más información sobre cómo hacer estimaciones ágiles, lecciones aprendidas en el trabajo diario, los principios y valores detrás del movimiento ágil o qué hacer con los requisitos que cambian durante el proyecto.

Si has comprado el libro ya, pásate de nuevo por la página de Amazon, que deberás recibir una actualización de contenidos automática cuando la tercera edición esté ya publicada. Deberás entrar con tu usuario en la página, ir a Gestionar mi Kindle, seleccionar este libro y actualizar los contenidos.

Si quieres leer el libro y no tienes un lector Kindle o no quieres descargarte la aplicación para tu PC, móvil o tablet, siempre puedes leer el libro yendo a la página read.amazon.com. Allí, con la cuenta de correo con la que compraste el libro, podrás leer cualquier ebook que hayas comprado en Amazon, aunque no tengas un lector Kindle.

Aquí tienes también los accesos al libro en los tres Amazon donde puedes comprarlo (también está disponible en Google Play)

Amazon.com
Amazon.es
Amazon.com.mx

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

 

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.

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).

Suscríbete