Sunday, 28 December 2014

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

Esta semana he lanzado en Amazon una nueva edición del libro Gestión práctica de proyectos con Scrum. Nueva portada, nuevos capítulos, revisión de contenidos, en definitiva, un montón de cosas en esta segunda edición del libro ¿Aún no lo has leído? Échale un vistazo en Amazon.com. Aquí tienes el enlace: Gestión práctica de proyectos con Scrum.


Con estos cambios el libro se ha colocado como número 1 en tres categorías al mismo tiempo (Programación y desarrollo software de la Tienda Kindle y Programación y desarrollo de software e Internet y web dentro de todos los libros de Amazon.es). En el momento en que escribo esto el libro se ha colocado en la posición nº 166 en ventas de todos los libros Amazon España ¿Llegará al top 100?




Sunday, 14 December 2014

El rol de Product Owner en Scrum

Hay muchas formas de denominar a la persona que cumple las funciones de Director del Proyecto en la organización que nos contrata. Aquel que tiene la visión del producto que necesita su compañía y que la representa ante el equipo de trabajo. Si pertenece a la organización externa que nos ha encargado el trabajo, el nombre que mejor se le ajusta es el de Dueño del Producto, como hace Scrum, porque es eso literalmente, el ‘Dueño’ de lo que se ha contratado. Si en cambio es una persona de nuestra propia organización la que va a representar al ‘negocio’ en el proyecto suele denominársele Product Manager o incluso Business Analyst según la empresa que le haya dado el cargo. Personalmente, quizás por el tipo de proyecto que habitualmente gestiono, me siento más cómodo llamándolo simplemente Director del Proyecto en el Cliente.

Lo llamemos como lo llamemos, cumple una función muy importante para el éxito de un proyecto. Es el encargado de decidir qué funcionalidades tendrá el producto que se está construyendo, cuáles son importantes y cuáles son prescindibles. Es posible que sea un usuario final del producto por lo que tendrá muy claro qué se necesita para obtener una herramienta útil en su trabajo diario, pero no debe ser útil solo para si mismo o su departamento, sino que deberá tener en cuenta los requisitos de toda su empresa.

Cuando comenzamos un nuevo proyecto, el Director del Proyecto en el cliente y todos los usuarios interesados en el producto final tienen un montón de ideas y grandes expectativas para el nuevo sistema. Lamentablemente, ningún proyecto, por grande que sea, puede contemplar todas y cada una de las sugerencias de sus usuarios. Algunas ideas serían irrelevantes para la mayoría, otras funcionalidades serán demasiado costosas de implementar o llevaría tanto tiempo desarrollarlas que retrasarían la puesta en marcha del producto. Es aquí donde el Director del Proyecto en el Cliente, que conoce bien el mercado y tiene una clara visión del producto, tendrá que priorizar las características más importantes y descartar aquellas que aportan menos valor al resultado final.

Para explicar hasta dónde llegan sus responsabilidades imaginemos que nuestra empresa decide contratar el desarrollo de un nuevo sistema de reserva de billetes de avión. En esta empresa han nombrado a Raúl como Dueño del Producto o Director del Proyecto y tendrá que trasladar a la empresa contratada todos los requisitos y necesidades que el nuevo sistema deberá cubrir.

Raúl tiene una visión muy clara de lo que quiere y está muy ilusionado con el proyecto. También lo están los responsables de IT, marketing y ventas que han elaborado una exhaustiva lista de funcionalidades a incluir en el nuevo producto. Incluso en conversaciones informales, los que serán nuevos usuarios del sistema, le trasladan a diario peticiones de nuevas funcionalidades. Raúl no quiere que se le escape nada importante y anota cuidadosamente todos estos requisitos en un cuaderno.

Al segundo mes de comenzado el proyecto Raúl se da cuenta que el Equipo de Trabajo en la empresa desarrolladora está entregando de 4 a 6 nuevas funcionalidades a la semana y que esta parece su capacidad máxima de trabajo. Está contento con el trabajo que están haciendo pero tiene un problema: en su libreta anota una media de 10 nuevos requisitos a la semana. La lista está creciendo y pronto necesitará un nuevo cuaderno.

Primero solicitó al Equipo de Trabajo que hiciera un esfuerzo para entregar estas diez funcionalidades cada semana. Lamentablemente, no muchas más funcionalidades eran entregadas y, lo que es peor, se comenzaba a percibir que la calidad de las mismas había bajado. En ocasiones incluso había que parar todo para corregir defectos en entregas previas. Si seguían así, la desmoralización y el estrés iban a dominar el proyecto.

Raúl iba a decidir a partir de ahora qué se hacía y qué no. Todas las funcionalidades no iban a poder se desarrolladas, por lo menos no ahora. Algunas tendrían que esperar a una futura versión. Desde luego, la funcionalidad similar al Clippy de Windows para asistir en la compra de los billetes de avión era un claro ‘No’.



Pero ¿cuáles desarrollar primero? ¿qué criterio seguir? Raúl se dio cuenta de que no había relación directa entre el coste de las funcionalidades y su valor para el producto final. Algunas funcionalidades eran fáciles de construir pero otras, en cambio, llevaban mucho tiempo de desarrollo pero no por ello eran las que más valor aportaban. Si preguntaba directamente al Equipo de Trabajo en cuantos días podría estar hecha cada una de las funcionalidades sabría su coste aproximado y si preguntaba a los usuarios por una valoración del 1 al 5 para cada funcionalidad sabría calcular el valor para su empresa.

Si había dos funcionalidades que tienen el mismo coste aproximado pero una tiene valor 1 y la segunda valor 3 estaba claro que se construiría la segunda funcionalidad. Si en cambio, había dos funcionalidades de aproximadamente el mismo valor para la empresa pero tardaríamos 5 días en desarrollar una de ellas cuando la segunda podría estar desarrollada en una horas, también estaba claro en cuál se trabajaría primero.

Raúl sabía que el coste y el valor de cada funcionalidad no eran números absolutos sino solo una aproximación. No sabemos cuánto pesa una manzana pero sí sabemos que es aproximadamente 5 veces más grande que una fresa y que la fresa gusta más (para los que van a pagar por ella al menos) por lo que la fresa se construiría primero. Es un modo fácil de decidir qué aporta más valor y más rápido a nuestro proyecto.

La comunicación es una parte importante de las responsabilidades de Raúl. Deberá estar en contacto directo con el Equipo de Trabajo pero también con las personas de su empresa que tienen algo que decir sobre el producto que se va a construir. Debe ser hábil para saber decir ‘no’ cuando sea necesario. Debe ser práctico también para tomar esta decisión de forma rápida y directa y, además, conocer muy bien su negocio para asegurarse de que se construye lo que realmente aportará valor a su empresa. Todo un papel para Raúl ¿no creen?


Este artículo se publicó por primera vez en el número 3 de la revista IT Proiectus. Puedes encontrar este artículo y muchos otros en la web de Proiectus, consultoría y formación en dirección de proyectos.

Sunday, 2 November 2014

Nuevo número de la revista Proiectus

Ya ha salido el nuevo número de la revista de gestión de proyectos Proiectus editada por Iván Tejera. Ya va por el número 3 y en esta edición alcanza las 80 páginas de artículos sobre la dirección de proyectos en Canarias escrita por jefes de proyecto como Javier Zaya, Fernando Manero, Toni Dorta, Pilar Tarriño, José Barato o Mike Griffiths.

Yo también tengo un artículo en este número titulado 'El rol del director del proyecto en el cliente' en el que hablo de la importancia que tiene el papel del Product Owner en todos los proyectos.

No te lo pierdas. Échale un vistazo en este enlace a la revista Proiectus en Issuu:


Sunday, 26 October 2014

Ponencia en las Jornadas del Proyecto Resiless

El proyecto Resiless es un proyecto europeo para la cooperación euroafricana para el desarrollo de un sistema de información de residuos atlántico y con el que se financió GUIRRE, el Sistema de Información de Residuos de Canarias, en el que participé en algunas fases de su desarrollo como analista y últimamente como responsable de proyectos.

El 16 de octubre FEMEPA realizó una presentación de este proyecto en Gran Canaria a la que tuvieron la amabilidad de invitarme como ponente para hablar de este sistema, de sus pasos previos y los futuros desarrollos que podría contener. Les dejo en este post la ponencia que dí allí y algunas fotos del evento:






Sunday, 19 October 2014

Curso práctico de Scrum

El pasado jueves 16 terminaron las sesiones de formación dentro del curso Organización de los Servicios TIC en Departamentos de Desarrollo Software organizados por la SPEGC y ITPROIECTUS.

Yo impartí una de las charlas dedicada a Scrum el jueves anterior, el 9 de octubre. Les dejo algunas fotos del evento y la presentación que usé durante la sesión.





Wednesday, 8 October 2014

CodeWeek Gran Canaria

El próximo sábado 11 de octubre se iniciar 'CodeWeek', el mayor evento para la difusión de la programación en Europa (codeweek.eu). BizKidzLab la startup de mi compañero Antonio Roque participa con varios talleres en la 'CodeWeek Gran Canaria'. Son talleres gratuitos. Aquí tienen el cartel:


Sábado 11 de octubre, Centro Comercial Las Ramblas (Las Palmas de Gran Canaria), http://events.codeweek.eu/view/1307/codeweek-gran-canaria/
  • (BizKidzLab) Taller “Desarrolla tu primera App”, 10:00 a 14:00, niños/as de 10 a 15 años. Si te gusta la tecnología y los móviles, ven a este taller y desarrolla tu primera app con AppInventor.
Domingo 12 de octubre, Ramblas Avenida Mesa y López (Las Palmas de Gran Canaria), http://events.codeweek.eu/view/1309/codeweek-gran-canaria/

  • (BizKidzLab) Taller “Desarrolla tu primer Videojuego”, 10:00 a 14:00, niños/as de 10 a 15 años. Si te gustan los videojuegos, ven a este taller y desarrolla tu primer videojuego con GameMaker.
  • (LpaFabrika) Taller de Robótica, 10:00 a 14:30, niños/as de 10 a 11 años. Acercando la robótica y la programación a las familias.
  • (Google Developer Group) Taller de Unity, 10:00 a 12:00, para jóvenes emprendedores. Unity es un software para la creación de videojuegos para diversas consolas y sistemas operativos.
Solo me queda mencionar que el taller tendrá una duración de media hora, se iniciarán a las en punto y a las y media y que la inscripción se hará en el lugar: Anímense a acudir!

Sunday, 28 September 2014

Número 1 en Amazon: Gestión práctica de proyectos con Scrum

Durante las tardes del jueves y viernes de esta última semana mi libro Gestión practica de proyectos con Scrum alcanzó el número 1 en los libros más vendidos de Amazon.com en la sección de Computadoras, Internet y Medios Digitales. Llegó a alcanzar también el número 2 en la sección Computación e Internet de todos los libros en español.



Las cifras de ventas son muy modestas pero por ejemplo hoy domingo 28 de septiembre, en el momento que escribo estas líneas (las cifras cambian cada hora), el libro llegó a alcanzar la posición 247 del ranking total de libros electrónicos más vendidos de Amazon España. Teniendo en cuenta que en el puesto 98 de la Tienda Kindle está Amin Maalouf y en el 90 el último libro de Almudena Grandes estoy muy contento. Hay obviamente una diferencia muy grande entre estos libros y el mío pero, a veces, solo a veces, las comparaciones no son odiosas (quizás para Almudena sí lo son).

¿Aún no has leído el libro? Está de momento a un precio muy económico en Amazon.com, no te lo pierdas. Tiene 85 páginas de formato bolsillo, es de fácil lectura y se aleja todo lo posible de demasiados tecnicismos ¡Seguro que te gustará!



Sunday, 21 September 2014

Nuevo curso Gestión de Servicios TIC

ITProiectus y la SPEGC organizan un nuevo curso de 'Gestión de servicios TIC en departamentos de desarrollo de software' en el edificio INCUBE los días 2, 9 y 16 de octubre.

Será un curso compuesto por 5 sesiones de dos horas de duración cada una en las que se tratarán metodologías y marcos de trabajo como PMP por Iván Tejera y Mónica Khiani, ITIL por Agustín Tapia, Kanban por Antonio Dorta y Scrum que será impartida por mí.

Serán sesiones orientadas a la práctica en las que se pondrán ejemplos de uso contando el por qué y para qué de cada técnica además de un pequeño debate al final de cada sesión. Seguro que les resultará interesante.

Tienen toda la información y datos para la inscripción y matrícula, sólo 30€, en la web de Proiectus. Ánimo y a apuntarse.

Sunday, 14 September 2014

Gestión basada en el talento vs. Gestión basada en los procesos

Cuando esto de la Informática empezaba hace ya unos cuantos años los proyectos software se gestionaban a base de la dedicación y el talento de los únicos que sabían programar por esa época. Normalmente eran unos matemáticos despistados que sin ningún método desarrollaban un montón de código utilizando sólo su ingenio. Su forma de trabajar no era repetible por otros y, si ellos no estaban, no había quién entendiera lo que allí habían dejado escrito ¿Cuánto iban a terminar en terminar el proyecto? Bueno, en un par de noches más estaría terminado.

En algunas empresas actuales se tiende a utilizar también este modelo. Se quiere que todo el equipo de trabajo esté formado por programadores ninja que saquen el trabajo adelante pase lo pase. No necesitamos ningún proceso a seguir ni ninguna metodología. Solo debemos apartarnos para no molestar. Ellos sabrán lo que hay que hacer. Puede parecer una solución ideal pero tiene algunos inconvenientes: Los programadores así no crecen en los árboles. Podríamos empezar a pagar más y más para atraer el mejor talento pero, aceptémoslo, nuestra empresa no es Google y por mucho que paguemos será imposible atraer todo el talento que necesitamos en nuestros proyectos.

Es también la forma de gestión de algunas start-up: Un equipo de programadores jóvenes y emprendedores capaces de abordar proyectos tecnológicos complejos. Llegarán tan lejos como bueno sea su software pero tendrán un problema para pasar al siguiente nivel repitiendo esos primeros éxitos cuando ellos ya no pueden formar parte del desarrollo de todos sus proyectos.

Todas las empresas de software necesitan poder repetir sus resultados aunque no cuenten siempre con el mismo equipo y escalar luego esa forma de trabajo a toda la organización para ir mejorando poco a poco la calidad de sus proyectos. Esto no es posible solo con la gestión del talento, necesitamos también utilizar procesos que nos ayuden a estabilizar la producción y obtener buenos resultados con todos los equipos de trabajo. Existen muchos procesos para la industria del desarrollo de software: CMMI, RUP, Extreme Programming, Scrum y otros métodos ágiles ¿Cuál es el tuyo?

Sunday, 31 August 2014

¿Estás usando Scrum?

Veo a menudo en la llamada 'comunidad Ágil' demasiada discusión sobre si se está usando Scrum o si lo que estás haciendo puede llamarse Scrum o no en lugar de centrarse en si se está entregando trabajo con frecuencia y si este trabajo es lo que el cliente necesita. Esto es lo realmente importante, el proceso que se siga para lograrlo es secundario.

Es una especie de fundamentalismo que afecta a unos pocos que han aprendido un Scrum 'único y verdadero' y ellos deciden lo que está bien o está mal. Lo implementan de una manera poco flexible pretendiendo que de un plumazo toda la organización cambie su forma de trabajar. Ante cualquier queja contestarán: 'Debe ser que no lo estás haciendo bien. En Ericsson y Spotify funciona perfectamente'.

Hay otro tipo de implementador de Scrum, el llamado pragmático. Es el que, conociendo aún poco de Scrum, usa sólo algunos de los métodos porque considera que los otros son demasiado difíciles de implementar o que hay mejores formas de hacer esa parte en concreto. Es como ir a una clase de kárate y después de la primera lección decirle al instructor 'Bueno, todo esto está muy bien, pero creo que puedo simplificarlo un poco para hacerlo mejor'.

No hay nada de malo en adaptar Scrum a las necesidades de tu proyecto, de hecho es necesario y a veces quizás imprescindible. Comenzar con Scrum siguiendo al pie de la letra el libro también es importante. Aprender del patrón ideal o común a muchos proyectos para luego flexibilizarlo y adaptarlo a tus características es bueno si se mantienen de fondo los principios ágiles. Haz lo que funcione para ti o tu empresa pero mantente en ello y mejóralo con el tiempo.

Referencias: Pragmatism, Fundamentalism and Transformation – the Three Modes of Scrum

Sunday, 17 August 2014

Trello, la gráfica burndown y Google Calendar

Probablemente sea siempre mejor un tablero físico, en una pizarra o pared de corcho, que un tablero Kanban virtual en la pantalla de nuestro ordenador pero es indudable que llevar este seguimiento en nuestro PC o portátil también tiene sus ventajas: mantener estadísticas automatizadas, guardar el historial de nuestro progreso y los cambios que hemos hecho almacenando los datos en la nube para que nosotros o nuestro cliente podamos ver el estado del proyecto desde su casa u oficina.

Hay muchos de estos tableros virtuales como KanbanFlow, Rally, Jira + Greenhopper o Pomodoro Daisuki, con más o menos ventajas o más o menos costosas pero hoy quería comentar sólo sobre una en partícular: Trello, del conocido blogger Joel Spolsky, un aplicación web gratuita para llevar los tableros Kanban de nuestros proyectos.

Utilizo Trello con cierta frecuencia por un par de proyectos, uno profesional y otro personal para el aprendizaje de idiomas. Permite llevar adelante cualquier tipo de proyecto, no sirve sólo para proyectos de desarrollo de software. Al crear un nuevo tablero aparecerán las tres columnas habituales (To Do, Doing y Done) pero aquí son tratadas como simples listas y a las que puedes cambiarle el nombre a lo que mejor se ajuste a tu proyecto, por ejemplo: Pendiente, En desarrollo, Revisado, Pre-explotación y Producción.

Una vez creadas las listas para tu proyecto comenzarás a crear las tareas que van en ellas priorizándolas o cambiándola de columna con solo mover una encima de la otra o arrastrándolas a las columnas de al lado. También puedes invitar a otros usuarios de Gmail a formar parte del proyecto y asignarles tareas directamente. Estos usuarios serán notificados por email cada vez que alguien escriba un comentario a la tarea o la cambie de estado. Hay más funcionalidades interesantes para las tarjetas con tareas: añadir comentarios, imágenes o archivos adjuntos para cada tarea, mantener una checklist de comprobaciones con cada una de ellas o etiquetarlas individualmente con un color y nombre diferente por tipo de tarea. 

Puedes incluso ponerles una fecha de finalización a cada tarjeta colocada en el tablero, cambiando de color según se acerca la fatídica fecha. También, si activas la extensión para el calendario de Google, todas estas fechas aparecerán automáticamente en tu agenda para que las tengas siempre presentes (para activar esta función en tu calendario de Google echa un ojo a esta página de ayuda de Trello)

Pero lo que más me atrajo de Trello (además de ser gratuito) no son solo sus propias funcionalidades sino la posibilidad de mantener una gráfica burndown de forma automática con una aplicación externa: Burndown for Trello. Se trata de una web que, conectándose a la API proporcionada por Trello obtiene todos los datos y estadísticas de este tablero a medida que mueves las tarjetas de columna calculándote automáticamente esta gráfica:



y estas estadísticas:

Se muestran el total de tarjetas, cuantas quedan por hacer, qué porcentaje del total se ha hecho, cuantas horas estimadas quedan de trabajo por delante, en cuantos días se calcula que se hará todo el trabajo y en qué fecha, también estimada, estará completado el trabajo si seguimos avanzando a este ritmo ¡Espero que te sea útil!






Sunday, 13 July 2014

Test no-oficial de Scrum

He creado estos días una pequeña aplicación web que permite al usuario probar los conocimientos que tiene sobre Scrum. Es un test similar al oficial de scrum.org y te permite, en español, poner a prueba tus conocimientos de Scrum.

Se trata de un test 10 preguntas aleatorias sobre este marco de trabajo y al final del mismo te indicará información sobre el número de respuestas correctas que has tenido y un enlace al test de prueba en inglés donde practicar antes de tomar el examen oficial para el certificado Professional Scrum Master I.

El test sirve como preparación para el examen PSM I y actualmente está disponible sólo para los lectores de mis 2 libros: Certificación Professional Scrum Master y Gestión práctica de proyectos con Scrum.

Información técnica:

El objetivo de hacer esta aplicación no era sólo hacer un test de Scrum útil al que esté pensando obtener la certificación, sino también como pet project para poner en práctica algo de Ruby on Rails y otras herramientas relacionadas. Les describo en los siguientes párrafos estas cuestiones más técnicas (pueden saltarse esta parte si les resulta aburrido):

La aplicación ha sido realizada con Ruby on Rails, un framework que promete una mejora de la productividad y del número de líneas de código sobre Java. Por otro lado, no ha sido desplegada en un Tomcat o JBoss sino en la 'nube' gracias a Heroku una de las primeras plataformas de computación en la nube. Para desplegar el código en Heroku bastaba con usar el comando git push para enviar el código fuente subido en mi cuenta de GitHub al repositorio remoto de Heroku.

La base de datos Postgres la facilitaba Heroku y, como no, también está en la nube. En esta base de datos no era necesario enviar scripts con sentencias SQL para crear las tablas y relaciones sino que Ruby on Rails deduce la estructura de tablas del modelo de clases de la aplicación y con él las crea. Si cambias un atributo de una clase, también cambiará el modelo de base de datos. Los registros con preguntas y respuestas iniciales no se crearon tampoco mediante sentencias SQL sino que en un único fichero se creaba cada registro con clases y objetos Ruby. Por ejemplo:

Question.delete_all
question = Question.create(:title => 'El Scrum Master es:', :value => 1, :order => 1)
question = Question.create(:title => 'Los equipos Scrum son:', :value => 1, :order => 2)


Si quieres aprender algo de Ruby on Rails, desplegar aplicaciones con Heroku y algunas cosas más sobre desarrollo Ágil y SaaS te recomiendo el libro 'Engineering Long-Lasting Software' de David Patterson y Armando Fox. Muy recomendable.

Tuesday, 24 June 2014

Estadísticas de uso de Scrum (2014)

Hace algo más de un año, en abril de 2013, publicaba una serie de gráficas y estadísticas sobre el uso de Scrum en los portales de empleo y sus búsquedas en Internet en general. Para hacerlo comencé por la demanda de profesionales que pudieran tener metodologías o técnicas como Scrum, Kanban o TDD. Contabilicé en primer lugar el número de veces que aparecían términos como estos en portales de empleo españoles, británicos y alemanes. Estos fueron los resultados que obtuve en 2013:
Comparativa 2013 de portales de empleo para Scrum, Agile, Kanban, Lean, TDD o PMP


He vuelto a buscar este año las palabras Scrum, Agile, Kanban, Lean, TDD, PMP, RUP y Waterfall en los portales de empleo Infojobs.net de España, Monster.co.uk del Reino Unido y el Monster.de de Alemania obteniendo los siguientes porcentajes de variación:
Comparativa 2014 de portales de empleo para Scrum, Agile, Kanban, Lean, TDD o PMP

Los términos ‘ágiles’ como Scrum, Agile, Kanban o TDD tienen una importante subida entre los anuncios de demanda de empleo de los tres países. Habría que destacar que mientras que en España la demanda de empleos que requieren de conocimientos en Scrum sube un 35%, en el Reino Unido sólo sube un 8% pero en Alemania baja incluso un 20%. Esto quizás se deba a que son mercados más maduros en los que términos como Scrum y Kanban están siendo sustituidos por otros más genéricos como Agile, que sube un 170% en Alemania mientras que Kanban baja un 19% en Inglaterra y un 9% en Alemania.

He buscado también el uso de estas palabras en todo Internet con la ayuda de Google Trends. Aquí tienen la gráfica de las búsquedas realizadas en Google por ciudadanos de todo el mundo para los términos 'scrum -espn -rugby' (para eliminar los resultados del deporte), 'pmp' y 'agile'. Esta es la gráfica:




Incluyo también la gráfica en la que se muestra de qué países provienen las visitas del término Scrum. Es asombroso comprobar cómo una gran parte de las búsquedas proceden de los países del norte de Europa y de otros importantes países en la producción de software como la India o Argentina.

Sunday, 8 June 2014

¿Tienes 5 minutos?

¿Tienes 5 minutos libres al día? Tienes entonces una pequeña fortuna. Solemos emplear ese tiempo y aún más en entretenernos con cualquier cosa en el móvil mientras esperamos nuestro turno en el médico o en la cola del supermercado. Si nos sobra media hora antes de salir para el gimnasio, encendemos la tele y malgastamos nuestro tiempo cambiando de canal sin detenernos en ninguno. En realidad sólo estamos dejando pasar el rato hasta que llegue la hora de salir.

¿Qué tal si apagas la televisión y dedicas esos minutos libres a aprender un idioma? Instala la app memrise.com en tu móvil y comienza a aprender vocabulario en inglés o el idioma que prefieras en ese rato. ¿Sabes que 500 palabras son las necesarias para comenzar a hablar en inglés? Aprender 5 palabras nuevas cada día no te llevará más que unos minutos y podrías mejorar tu nivel de inglés en sólo unos meses.

¿Y si grabas unos podcasts de audio sobre Scrum en tu lector de mp3 o en un CD y los escuchas mientras sales a correr o mientras vas al trabajo en coche o autobús? o mejor aún, graba esos mp3 con los podcasts de algún programa en inglés, como los de This Agile Life en PlayerFM, y aprende sobre éstas u otras metodologías mientras mejoras tu inglés. Tienes otros podcasts muy útiles que te ayudarán a mejorar tu listening mientras te explican cómo funcionan las reuniones de negocios en los Estados Unidos o cómo hacer una presentación eficaz en una reunión de empresa. Échale un vistazo a Business English Pod o ESL Pod para hacerte una idea.

Carlos Andreu propone emplear media hora al día en leer un libro sobre nuestra profesión o especialidad. Si hacemos esto cada día, con estas 15 horas al mes podremos leer un libro cada dos meses lo que supone leer unos 6 libros al año. Con una buena selección de los libros que leemos, en un par de años habremos leído los libros imprescindibles en nuestro campo y estaremos al día de todos los fundamentos de nuestra especialidad. ¿Cuántos libros no nos habríamos leído ya si hubiésemos hecho esto desde que dejamos la Universidad?

¿Seguro que no tienes 30 minutos? Apaga un rato la tele.

Saturday, 7 June 2014

El libro 'Gestión práctica de proyectos con Scrum' Número 2 en amazon.com

Esta misma mañana mi libro 'Gestión práctica de proyectos con Scrum'  ha alcanzado la posición número 2 en ventas de amazon.com para la categoría de Informática e Internet en español. Les dejo aquí la imagen:


Aunque quizás de lo que estoy más orgulloso es de que, haciendo una búsqueda por la palabra 'scrum' en amazon.com, mi libro apareciera esta mañana justo debajo del último libro del mismísimo Jeff Sutherland, creador de Scrum.

Si se animan a echarle un vistazo, pueden encontrar una preview del ebook en Amazon: Gestión práctica de proyectos con Scrum.




Tuesday, 20 May 2014

Publicado el libro Gestión práctica de proyectos con Scrum

Ya está publicado en Amazon mi libro 'Gestión práctica de proyectos con Scrum'. Se trata de un ebook en español sobre la gestión de proyectos ágiles. El libro se complementa con anécdotas, dibujos ilustrativos y pequeñas fábulas para contar, en la forma más amena que he podido, qué necesitarás para llevar a buen puerto un proyecto beneficioso para tu empresa pero también para tu cliente.

El ebook está en formato Kindle pero si no tienes uno de estos lectores puedes usar la app de Kindle para iPad, Mac o Android. Tienes incluso una aplicación para leer libros Kindle en PC.

El libro estará disponible para la descarga gratis durante toda la semana (hasta el viernes 23 de mayo) en Amazon. Es de lectura rápida, espero que les entretenga.
Libro Gestión práctica de proyectos con Scrum por Antonio Martel


Sunday, 11 May 2014

Libro Gestión práctica de proyectos con Scrum

Estoy terminando de escribir un libro sobre la gestión ágil de proyectos software usando Scrum. Se trata de un ebook en el que trato de explicar, de la forma más amena que me ha sido posible, la gestión de proyectos desde un punto de vista práctico evitando toda teoría y terminología que pudiera sonar rara a un novato que se acerca por primera vez a Scrum.

Dentro de un par de semanas lo publicaré en Amazon. Espero que les sea de interés. De momento les dejo un adelanto del contenido (clic en la imagen para ver el Prezi)

Libro Gestión práctica de proyectos con Scrum





Sunday, 4 May 2014

Scrumdamentalismo

Scrum y técnicas ágiles llevan solo unos años siendo populares en España y ya se está hablando de Post-Agile o lo que vendrá después de la moda de las técnicas ágiles ¡Si no hemos tenido tiempo de aprender Scrum y ya lo están reemplazando! En realidad el movimiento Post-Agile no pretende ser algo que sustituya a Scrum a Kanban o a otras técnicas llamadas ‘ágiles’ sino que más bien intentan que no se pierda la filosofía que hay detrás.

He visto a muchos profesionales preocupados por seguir todas y cada una de las reglas que se definen en Scrum, usando pomposos nombres para sus reuniones y un montón de tarjetas de colores para todo tipo de tareas posibles. Dicen cosas como ‘¿Qué no actualizas la gráfica burndown a diario? Entonces tú no estás haciendo Scrum’, ‘¿No mantienes una Reunión de Retrospectiva después de cada demo? Eso no es Scrum’.

En algunos casos es una especie de fundamentalismo del Scrum que afecta a los profesionales TI y que a veces nos lleva a convertirnos en pequeños talibanes de nuestro lenguaje de programación favorito o de la metodología que esté de moda en ese momento. En otros casos es algo así con una enfermedad, Scrumbutphobia, como la denomina Henrik Kniberg, conocida también como Scrumdamentalismo, y que se define como el miedo a seguir mal Scrum.

Hay un concepto divertido, que proviene de las artes marciales, en las que a las fases del aprendizaje se las llama Shu Ha Ri. Este concepto explica que cuando se está aprendiendo un arte marcial, y esto puede aplicarse a muchos otros campos, se pasa por estas tres etapas. La primera, Shu, en la que los aprendices sólo se siguen las reglas que les han enseñado. La segunda, Ha, en la que aprenden a adaptarlas para que les funcione mejor en sus condiciones particulares. La última, Ri, cuando ya se conocen y dominan las técnicas simplemente se ‘ignoran’ las reglas. Uno de los síntomas de los que padecen, o hemos padecido, la fobia a hacer mal el Scrum, es la de estar atascados en Shu, la primera fase del aprendizaje.

"¡Que le den a las reglas! Las reglas son buenas al inicio, luego rómpelas cuando lo necesites"

Si tu meta es entregar productos de calidad que sean verdaderamente útiles al cliente y no tener que acudir continuamente al contrato a verificar si estás obligado a hacer esa tarea. Si te olvidas un poco de porcentajes, de complejos procesos y de tanta herramienta para centrarte en si estás mostrando periódicamente demos que funcionan (con algún error que otro) en lugar de powerpoints y barras de progreso, entonces creo que vas por buen camino. No te preocupes si no cumples todas y cada una de las reglas de Scrum.



Saturday, 3 May 2014

Nuevo número de la revista Proiectus

Ya está en la calle el número 2 de la revista Proiectus, la revista sobre la dirección de proyectos en Canarias. Echadle un vistazo al número número haciendo clic en el enlace que pongo a continuación:


En este número hay profesionales reconocidos en la gestión de proyecto de nivel nacional como Mario Coquillat, José Barato o incluso internacionales como Mike Griffiths. También hay gestores canarios tan conocidos como Iván Tejera, director de la revista, Toni Dorta, Agustín Tapia o Manuel Vara. También yo tengo un artículo llamado 'Jefe de proyeto ¿y ahora qué?' en el que cuento a lo que nos enfrentamos cuando nos acaban de nombrar jefes de proyectos y qué podemos hacer para intentar conseguir mejores resultados.

Todos los artículos están muy bien pero no se pierdan 'El director de proyectos ágil' de José Barato, 'La velocidad, la botella, las pelotas, la arena ... ¿e ITIL?' de Agustín Tapia y, por supuesto, tampoco dejen de leer la entrevista del final a Mike Griffiths. Lo que se cuenta ahí nos ahorraría muchas dudas y horas de búsqueda de información en Internet si estamos implantando Scrum.


Sunday, 20 April 2014

Reuniones en Scrum

Dentro de la metodología Scrum se establecen una serie de reuniones con nombres algo complicados y duración, asistentes y fechas prefijadas. Les explico en este post el significado de estas reuniones y, sobre todo, cómo pueden ayudarte en tu trabajo:

Reunión de planificación del trabajo

Antes de comenzar el trabajo previsto para las próximas 2 semanas te reunirás con el cliente (o representante del mismo y con las personas que éste considere) y definirán qué tareas se realizarán durante esas dos semanas (si el equipo de trabajo considera que puede hacerlas en ese tiempo) Durante esa reunión el cliente dará toda la información necesaria sobre las tareas escogidas explicándolas al equipo que va a desarrollarlas.
Tener en cuenta la capacidad de trabajo del equipo durante esta reunión de planificación permite, entre otras cosas, encajar los periodos de vacaciones o las ausencias de los miembros del equipo. Es tan sencillo como explicar ‘Dentro de dos semanas nos comprometemos a entregar solo 3 de estas tareas en lugar de las 5 habituales. Alberto y Pilar tienen vacaciones la próxima semana’ Esto no suele suponer un problema ya que el cliente lleva recibiendo entregas del trabajo cada dos semanas de forma consistente.

Reuniones diarias

El equipo de trabajo y el Scrum Master se reunirán cada día, mejor al inicio de la mañana, durante 15 minutos para contestar a las siguientes preguntas:
  • ¿Qué se hizo desde la última reunión?
  • ¿Qué se hará desde ahora y hasta la próxima reunión?
  • ¿Qué está impidiendo hacer el trabajo lo mejor posible?

Ejerzo habitualmente de Scrum Master en varios proyectos y a cada una de las reuniones diarias llevo una hoja impresa con estas tres preguntas donde mantengo registros de las respuestas del equipo de trabajo. Al final de cada una de estas hojas he añadido un apartado adicional llamado ‘Tareas para el Scrum Master’ y en él anoto todas las cosas que el equipo de trabajo necesita para continuar o qué les está dificultando el trabajo. Anotaciones frecuentes son: ‘Llamar al cliente y pedir lista de usuarios (¡mañana comenzamos con esa tarea!)’ o ‘Pedir exportación de la base de datos (necesitamos una copia ya antes de empezar a modificar datos)’) Es habitual que me pase el resto de la mañana intentado resolver los problemas que me han contado a primera hora.

Reunión de demo

Al finalizar cada iteración de dos semanas se concreta una fecha de reunión con el cliente y se le hace una demostración del trabajo realizado en esas dos semanas. En esta reunión el representante del cliente, en su función como director del proyecto, revisará lo que se le está mostrando y dará su visto bueno o no a lo que ha visto.
Para poder cerrar la funcionalidad es importante que esté completamente terminada y libre de errores (serán necesarias las pruebas del equipo de trabajo y una validación completa del cliente). Si no fuese así, se llegaría al final del proyecto según la gráfica burndown (todas las tareas estarían a 0 horas de trabajo pendiente) pero el proyecto aún no está finalizado porque hay funcionalidades incompletas o con errores por corregir.
Estas entregas periódicas permiten ver al cliente cómo va avanzando su producto, qué se ha estado haciendo durante esas dos semanas y decidir luego, en la reunión de planificación, qué quiere ver en la siguiente reunión de demo. Esto permite ganar confianza ante el cliente que no pierde de vista a la empresa desarrolladora una vez ha terminado la toma de requisitos para volverla a ver meses después con un producto ya completado sobre el que tiene pocas posibilidades de modificación.

Reuniones de retrospectiva

Después de cada iteración de 2 semanas y una vez realizada la demo al cliente, el Scrum Master y el equipo de trabajo se reúnen para estudiar los problemas que han podido ocurrir en esas dos semanas, por qué la demo no salió todo lo bien que debería (o sí) y si se puede hacer algo para mejorar en la próxima entrega.

Es bueno que el equipo de trabajo se sienta libre de expresar lo que considera que han sido los principales problemas aunque eso te haga subir los colores. Los problemas a veces están en la ‘zona ciega’ del Scrum Master y la visión en conjunto ayudará a aportar luz al problema.

Sunday, 6 April 2014

Formación para profesionales IT

Hace ya mucho que se viene observando que ya no es válido aquello de sacarse una carrera de X, comenzar en alguna empresa siendo becario, luego convertirte en profesional de X y dedicarte a lo mismo hasta tu jubilación. Esos tiempos se acabaron y no creo que vayan a volver de nuevo.

La actual crisis nos ha hecho ver esto de forma aún más clara. Un título es papel mojado si no tiene una clara demanda en el mercado laboral o no va acompañado de una actualización continua o de otros estudios que amplíen los conocimientos que aprendimos en la universidad. Cada vez es más común ver que se soliciten dobles titulaciones, másteres o un segundo idioma ¿Qué hacemos con nuestro viejo título de hace 10 o 15 años en el que comenzamos a estudiar con disquetes de 5¼?

No podemos dormirnos en los laureles y pasarnos una cuarta parte de nuestra vida laboral trabajando, por ejemplo, con Delphi o Visual Basic para que cuando necesitemos un nuevo empleo, descubramos que ya nadie programa en eso. Intentar ponernos al día de lo que ha pasado en nuestro campo en la última década nos puede llevar al menos un par de años y, aún así, no va a ser fácil.

Mientras aquí centramos el debate sobre si en la educación deben haber asignaturas como Religión o Educación para la Ciudadanía en otros países discuten sobre cómo las nuevas tecnologías pueden cambiar la formación tal y como hoy la conocemos. Les hago en este post algunas sugerencias de los sitios web y aplicaciones que a mí me parecen más interesantes y que pueden ayudar a mantenernos actualizados o salir de nuestra zona de confort:

Cursos Masivos Online (MOOC)

Sitios web como edx o Coursera entre otros ofrecen cursos online de Universidades tan prestigiosas como Harvard, MIT o Princeton sobre casi cualquier tema que se nos ocurra. Tendremos acceso a vídeos grabados en las clases de estas universidades e impartidos por algunos de los mejores profesores en su campo, además de hacer los mismos ejercicios y prácticas que hacen los alumnos presenciales de estas universidades. Lo mejor de todo, es gratis.

Udemy, Udacity, Floqq o Khan Academy son otras de las muchas opciones que hay para formarnos. Algunas de pago, otras no, pero podremos encontrar en ellas la posibilidad para aprender sobre materias en las que quizás no tengamos ni una remota posibilidad de encontrar un curso en nuestra pequeña provincia.

Master online en informática por el Georgia Tech

El problema de los cursos MOOC es la acreditación de sus titulaciones. Son online y no hay nadie vigilando que no haces trampa en los exámenes o copias el contenido de las prácticas. Muchos de estos sitios web cuentan con software para la detección de prácticas o exámenes copiados pero no pueden dar una garantía al 100% a los certificados que expiden. Es ahí cuando surgen iniciativas como la del Instituto Tecnológico de Georgia y de Udacity para ofrecer un Master Online in Computer Science, con exámenes supervisados y los mismos estándares del Georgia Tech, por solo una fracción de lo que cuesta un master presencial en esa misma universidad. Es el primero de este tipo, espero que lleguen muchos más. Quizás de universidades españolas.

Aprender inglés

Hace algunos años me comentaba un profesor que para llegar a tener un nivel de inglés que nos permita entender y hacernos entender en ese idioma con cierta comodidad era necesario practicarlo durante unas 2000 o 3000 horas. Horas repartidas entre listening, speaking, reading y writing. 

Imaginemos que contratamos un curso que va de septiembre a junio, con clases de 2 horas, 2 veces a la semana, más 2 horas que utilizamos cada semana para hacer los deberes y estudiar por nuestra cuenta. Si hacemos unos pequeños cálculos veremos que a ese ritmo sólo habremos sumado 240 horas de práctica al año. Estudiando así ¿cuántos años necesitaremos para alcanzar esas 2000 o 3000 horas y tener un buen nivel de inglés?

El inglés es cada vez más importante en muchos tipos de trabajo. Toda la información está a solo un par de clics de distancia pero está en inglés y necesitamos, al menos, poder leer de forma rápida para separar la paja del grano cuando buscamos alguna información o para entender lo que nos está diciendo un reconocido experto en uno de esos vídeos TED. 

Aquí van un par de recomendaciones:
  • Memrise para practicar nuestro vocabulario.
  • Busuu para enviar nuestros textos a que sean corregidos por nativos mientras tú puedes corregir los ejercicios de otros usuarios en español.
  • Duolingo. El sitio tiene truco, en la misma filosofía que reCAPTCHA, utiliza tus ejercicios de traducción inglés-español, español-inglés para que a medida que crece tu nivel, ayudar a traducir páginas web y otros documentos, comparándolo con las traducciones que han hecho del mismo texto algunos de sus 12.5 millones de usuarios.

¡Espero que les sea de utilidad!




Tuesday, 25 March 2014

BizKidz Lab

Hace ya algunos meses que mi compañero de trabajo, Antonio Roque, comenzó un proyecto personal para promover el emprendimiento tecnológico entre niños y jóvenes: BizKidz Lab. Desde entonces ha impartido cursos a jóvenes donde aprenden a desarrollar aplicaciones para móviles Android o a hacer juegos con su curso Game Maker.

Está teniendo mucho éxito con estos cursos por lo que pronto comenzará una nueva edición de App Inventor en Canarias7 Formación. También tendrá presencia en el Hack For Good de Las Palmas con dos talleres tecnológicos para niños. Si quieres aprender a hacer aplicaciones móviles o juegos de ordenador, los de BizKidz Lab estarán el sábado 5 de abril, de 10 a 14 horas, para enseñarte. ¡No te lo pierdas!


Sunday, 23 March 2014

La cigarra y la hormiga

Cierto verano una cigarra andaba ociosa por el campo cuando descubrió a una pequeña hormiga que corría atareada de acá para allá.

- ¿Qué haces? le preguntó la cigarra.
- La Reina me ha pedido que comience a construir un nuevo hormiguero, contestó la hormiga.
- Pero si ya tienen uno a solo unos metros, inquirió sorprendida la cigarra.
- Sí, dijo la hormiga, pero se nos está quedando pequeño y en invierno, con las lluvias, se moja lo que hemos recolectado.

La cigarra, dispuesta a aprender de sus laboriosas amigas, pensó que era buena idea eso de prepararse para el invierno. Las hojas y ramas con las que construyó su refugio el año pasado se estaban secando y no estaría mal tener un nuevo hogar en el que pasar cómodamente el invierno.

Rápidamente tomó una decisión y se puso a planear el estupendo refugio que iba a construirse. Ahora que tenía tiempo lo construiría con todas las comodidades posibles. Sería la envidia de todo el prado. Incluso desde más allá del seto de cipreses querrían venir a ver su nuevo hogar. Tendría grandes ventanales para que entrase mucha luz y diseñaría un ingenioso sistema de poleas que le evitaría tener que andar entrando y saliendo del granero para dejar lo recogido.

La hormiga en cambio tenía un plan. En agosto construiría la primera estancia que serviría de granero. Así, si este año las lluvias comenzaban pronto, tendría por lo menos algo de hueco extra en el que dejar la recolección. Después planificó el resto del trabajo según su importancia. Si no le daba tiempo a terminarlo todo tendría, por lo menos, construidas las partes más importantes.

Para septiembre excavaría un agujero donde hacer la sala donde dejar las primeras larvas del año. En octubre construiría una estancia adicional para ampliar aún más la capacidad del granero y por último, en noviembre terminaría el trabajo construyendo una última estancia donde poder cultivar hongos.

Mientras, la cigarra andaba preocupada por tener un salón lo suficientemente grande y contar con una estructura enorme para dar cabida a todas las habitaciones, despensas y mecanismos que tenía pensados. Andaba de un lado para otro buscando los materiales que necesitaría para poner en pie los grandes planes que tenía en la cabeza.

Ya en octubre cayeron las primeras lluvias pero la cigarra no tenía siquiera un refugio básico en el que guarecerse. Además, el agua le arruinó algunas de las primeras construcciones que tenía a medio hacer y las tuvo que volver a comenzar. Luego llegó noviembre y el tiempo se puso feo. Fue necesario apurar el trabajo y comenzar a trabajar de sol a sol.

Las primeras lluvias de octubre hicieron pensar a la hormiga que algo podría salir mal y decidió probar si el trabajo hecho les sería útil. Comenzó a llenar con grano el nuevo hormiguero y pronto se dio cuenta que el agujero de entrada era demasiado pequeño para entrar con hojas grandes y que debía elevarlo un poco más si quería evitar que entrase el agua o el barro por él. Fue necesario parar el trabajo para arreglar esto.

El invierno llegó pronto también ese año para la hormiga que se dio cuenta de que no tendría tiempo suficiente para construir la última de las estancias, así que decidió hacer en su lugar una entrada adicional por si una piedra o un enemigo bloqueaba la principal.

A la cigarra, en cambio, el mal tiempo la pilló desprevenida. No sabía muy bien qué estaba terminado y qué no. Lo que se había dado por terminado no había sido usado en todo ese tiempo y ahora no había tiempo para mejorarlo si había que corregir algo. El invierno había llegado y no se podía seguir trabajando.

En su nuevo refugio, bajo las goteras, la cigarra se prometió a sí misma que esto no le volvería a pasar: El año que viene trabajaré el doble de horas que la hormiga, se dijo.


Sunday, 9 March 2014

¿Debe el jefe de proyecto haber sido antes un técnico?

Suele haber cierto debate sobre si un jefe de proyecto debe conocer con profundidad lo que se está cociendo en su proyecto o si basta con que tenga muy buenas habilidades de negociación, planificación y gestión de recursos ¿debe haber sido antes un buen técnico en su campo o es suficiente con que tenga una cierta idea del trabajo y se deje asesorar por su equipo?

Pocas veces tenemos en una misma persona todas esas cualidades, tener un alto conocimiento de las técnicas de su campo y a la vez contar con grandes habilidades para el trato con clientes y equipo de trabajo siendo capaces de llegar a un buen acuerdo incluso en las condiciones más difíciles.

Sin menospreciar el conjunto de soft-skills necesario para ser un buen negociador, yo me inclino personalmente por el jefe de proyecto que antes ha sido un buen técnico y que es capaz de entender lo que le están explicando sus técnicos ¿cómo si no va a tomar decisiones acertadas sobre lo que se debe hacer o el camino a tomar?

Además, no basta con que el jefe exija el cumplimiento de cronogramas y plazos a su equipo sino que es muy útil también que sea capaz de enseñar cómo hacerlo. Ser capaz de guiar y concretar las tareas a realizar va a ayudar que se consiga finalizarlas antes. Consigue más quién más concreta y consigue más quién más revisa lo concretado (Gabriel Ginebra)

Thomas J Watson vendedor de cajas registradoras que terminó fundando IBM, cuenta que en sus inicios como vendedor, después de una semana recorriendo con un caballo cargado de cajas registradoras las granjas de toda su zona, le contó a su jefe su pésimo resultado como vendedor: No consiguió una sola venta.

En lugar de echarle una bronca o despedirlo, su jefe le explicó en qué fallaba su discurso de ventas, le contó como hacerlo mejor y le acompañó en la carretera a cada una de las ventas para mostrarle personalmente cómo hacerlo. Watson no salía de su asombro, cada una de las visitas en las que participaba su jefe terminaba en un acuerdo de venta. Gracias a la labor como mentor de su jefe Watson llegó a ser el máximo vendedor de su área. Merece la pena contar con un jefe que conoce bien su trabajo ¿no?

Referencias:
The Mythical Man-month - The Other Face - What documentation is required


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.



Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

Tuesday, 4 March 2014

Primero un paso y luego el otro

¿Cómo se llega a tener equipos de trabajo productivos y procesos eficientes? Pues supongo que como muchas otras cosas en la vida, dando un paso primero, luego otro, y aún otro más. No conozco la respuesta exacta a preguntas como esa, yo mismo me la hago. De lo que sí estoy seguro es que no se consigue intentado abarcar todo al mismo tiempo.

En muchas ocasiones, cuando nos dan una pequeña responsabilidad, en nuestro afán por querer hacer las cosas bien intentamos aplicar todas las buenas prácticas que conocemos y deslumbrar con nuestro buen hacer. Esto suele ser receta segura para el fracaso ¿estás preparado tú y tu equipo para llevar a cabo todo lo que prometiste? ¿lo has hecho antes? ¿cómo sabes que puedes cumplirlo?

Tomar un montón de medidas al mismo tiempo sin esperar a ver los resultados positivos o negativos de cada una de ellas no te va a permitir saber qué funcionó y qué no o qué debe mejorarse. Las cosas sucederán en tu proyecto, para bien o para mal, pero no sabrás muy bien qué las produjo, o qué efecto tuvieron.

Cambiar de golpe todos y cada uno de los hábitos que existían hasta ese momento en un proyecto puede causar una sensación de confusión al equipo de trabajo que no tendrá tiempo de asimilar todos los cambios que has propuesto. Las nuevas medidas podrían terminar aplicándose mal o a medias, generar el rechazo de los compañeros de trabajo y descartarse porque no tuvieron la dedicación y el esfuerzo necesario para ver sus resultados. Además, incorporar a tu proyecto un montón de nuevas prácticas, herramientas y métodos de trabajo podría crear falsas expectativas sobre lo que vas a hacer que posiblemente luego no puedas cumplir.

Asegúrate de que cumples los cuatro principios básicos de tu profesión antes de incorporar tecnologías innovadoras. Una vez los cumplas, añade una práctica nueva al nuevo proyecto que vas a comenzar. Si es posible hazlo en un proyecto pequeño y abordable. Ya se sabe, los experimentos con gaseosa (aplicar nuevas técnicas además de tener un coste también tiene un riesgo)

¿Ha funcionado? ¿ha ayudado a bajar los costes o mejorado la calidad? ¿seguro? ¿lo puedes demostrar? Si es así, ya tienes una nueva práctica en tu repertorio. Ahora, a por la siguiente.

¿No funcionó? Pruébalo, equivócate otra vez, equivócate de una mejor forma (Samuel Becket)

Sunday, 16 February 2014

Cómo hacer que las estimaciones digan lo que quieras

Tu cliente te ha pedido una estimación. Tiene una idea en la cabeza y quiere saber cuánto le costará y en cuanto tiempo lo tendrá. Él ha hecho sus propios cálculos y te comenta brevemente las cifras que tiene en la cabeza.

Llegas a la oficina y te reúnes con los técnicos más expertos en este tipo de proyectos. Después de darle unas cuantas vueltas llegas a un acuerdo con ellos sobre el tiempo y la dificultad en realizar este tipo de trabajo. Has tenido que convencerlos un poco para que no sean tan precavidos, después de todo no parece un proyecto difícil.

Aún así la cifra obtenida es muy superior a lo que el cliente había previsto. Además, si esa previsión fuese cierta no podrían cumplirse las fechas en las que se necesita el proyecto terminado. Necesitarás reducir esta estimación en al menos un 50%. Aquí tienes cómo hacerlo en 5 fáciles pasos:

  1. Ya lo has hecho antes. Ahora vas a tardar menos. Has hecho proyectos parecidos en otras ocasiones, seguro que se ha aprendido de los errores cometidos y los problemas que surgieron en otras ocasiones no tienen por qué pasar ahora (10% menos) ¿seguro que no ocurrirán otros problemas nuevos?
  2. El cliente ha dicho que quiere algo sencillo. No será tan difícil de hacer. Podremos hacer algo básico eliminando complejidades (10% menos). El cliente conoce bien su negocio y le parece fácil pero ¿y tú? ¿tienes todo el conocimiento del negocio del cliente?
  3. Vigilaremos mucho los costes. En otras ocasiones el proyecto no se ha supervisado correctamente pero esta vez estarás especialmente atento a cada hora empleada y no dejarás que se te vaya de las manos (10% menos)
  4. Pondremos a los mejores técnicos. Es un proyecto relevante para un cliente importante. Habrá que asignar a los mejores técnicos para el trabajo (10% menos) aunque aún no sabes si estarán disponibles en las fechas que los necesitas.
  5. Se hará un esfuerzo extra. Si fuese necesario y comprobásemos que no podemos cumplir con el tiempo previsto se pedirá a todos los implicados que hagan un esfuerzo adicional durante unas semanas. Si fuese necesario añadiremos incluso algún técnico adicional a mitad del proyecto para así acabar en plazos. (10% menos) Recuerda la Ley de Brooks: 'Añadir personal a un proyecto retrasado sólo hará que se retrase aún más'

Ya lo tenemos. Con solo un poco de trabajo hemos conseguido reducir la estimación inicial en un 50%. En realidad, para hacer que la estimación encaje en un presupuesto, nos hemos autoconvencido de que podemos hacer el trabajo en la mitad de tiempo. Lamentablemente las estadísticas muestran que los proyectos software tardan, en promedio, un 120% más del tiempo previsto inicialmente y que el costo final resulta ser un 100% más elevado que el que se calculó en la primera estimación.

Puedes ver más sobre estimaciones en:


Referencias: Estimaciones: errores comunes (Carlos Fontela)


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.



Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

Sunday, 9 February 2014

Más vale pedir perdón que pedir permiso

Hace unas semanas Borja Prieto tenía a bien publicarme un post invitado en el blog de desencadenado.com. Algo que le agradezco mucho porque en los tres días siguientes a la publicación las visitas a mi blog se multiplicaron por diez y el número de suscriptores por email se ha duplicado desde entonces. Incluso el tiempo medio por visita es considerablemente más alto incluso ahora, tres semanas después.

En esa entrada comentaba la importancia de tomar la iniciativa y no cruzarse de brazos cuando hay alguna tarea por resolver porque 'no es mi cometido', 'de eso se encarga otro' o 'no está en mi contrato'. Pueden leer la entrada en el blog de desencadenado: Más vale pedir perdón que pedir permiso.

Sigo el blog de Borja desde hace mucho tiempo. Si estás pensando montar una empresa o convertirte en un nuevo emprendedor les recomiendo encarecidamente seguir este blog. En él podrán encontrar artículos de interés. Muchos tanto como éstos:

También he asistido a algunos de los webinars de desencadenado.com o comprado alguna de sus píldoras formativas. El estilo directo que utiliza para explicar el asunto sin rodeos hace que merezca mucho la pena cada uno de sus vídeos.





Sunday, 26 January 2014

Asfaltar el camino

Quizás porque los proyectos en los que trabajo actualmente no son muy grandes o quizás por simple deformación profesional pero veo que mi trabajo es cada vez menos parecido al de un jefe de proyecto tradicional y más cercano al de un facilitador del trabajo.

Por supuesto que sigo teniendo responsabilidades en el control del coste económico y en la gestión del equipo pero no entiendo esto como la parte más importante de mi trabajo. Suena polémico pero intento explicarme.

En un rol de gestor de proyectos tradicional el jefe de proyecto debía redactar las especificaciones del proyecto, calcular el costo, gestionar el equipo de trabajo, asignarle las tareas y hacer un seguimiento de cada tarea asignada. El equipo de trabajo trabaja para el jefe de proyecto que velará porque se estén cumpliendo los objetivos dentro del coste presupuestado.

En mi caso, en cambio, el 70% de mi trabajo se resume en reunirme cada día durante 15 minutos con los distintos equipos de trabajo para preguntarles qué hicieron ayer, qué se va a hacer hoy y si tienen algún problema que no les permita avanzar. Me anoto en esas reuniones qué tengo que hacer yo para solucionarlo y me paso el resto del día intentando dar una solución a esos problemas (pidiendo información al cliente, revisando una entrega o reclamando una copia de la base de datos)

Como verán, mi trabajo trata de facilitar las cosas al equipo de trabajo asfaltando el camino para que pueda ir más rápido. Trato de conseguir que puedan hacer cada tarea en el menor tiempo posible en lugar de sólo asignar la tarea y medir si el tiempo empleado es mayor del estimado.

Como he mencionado en alguna ocasión, si nos contratan para llevar una carga del punto A al punto B de poco nos servirá saber cuántos pasos hemos dado ya con la carga. ¿No sería más útil ver si estamos en el camino más corto hacia B o en el que menos dificultades hay?

Sunday, 19 January 2014

El mundo avanza que es una barbaridad

Es una expresión muy castiza pero no por ello deja de ser cierta. En el mundo de la tecnología las cosas suceden más y más rápido cada vez. A los profesionales TI nos cuesta Dios y ayuda saber qué se está cociendo en cada uno de los nichos tecnológicos.

En el desarrollo de software, por ejemplo, si trabajabas hace unos cuantos años para un banco o hacías un programa de contabilidad, trabajabas en un único lenguaje. En tu primer día de trabajo te dejaban un libro muy gordo que se llamaba "La Biblia de (pon aquí tu lenguaje favorito)". Todo estaba ahí, la lista de instrucciones, sus parámetros y ejemplos de su uso. Tenían incluso un anexo con la lista de todos los errores posibles. Nada podía salir mal. Después de tres años trabajando te conocías la lista completa de errores y no había instrucción que tuviera secretos para ti.

Lamentablemente alguien empezó a poner los servidores cada vez más lejos del usuario: Primero el servidor de base de datos, escondido al fondo de la oficina por lo que tuvimos que aprender SQL. Luego llegó Internet y junto al servidor de base de datos se puso un servidor de aplicaciones. Hubo que aprender a usar un Tomcat y a programar en Java, PHP o .NET.

Cuando al fondo de la oficina no quedaba hueco para tanto servidor se les buscó un sitio en un centro de datos en las afueras, donde había un montón de servidores de empresas diferentes. Pero no fue suficiente, unos años después Google se llevó los servidores y sus datos aún más lejos, a Arkansas o Arizona, o a ambos sitios a la vez, nadie sabe muy bien. Llegó la computación en la nube y ahora comienza a ser imprescindible programar en NoSQL, MongoDB o Cassandra, pero también con Android y para el iPhone, y ...

Ya no basta con tener un título universitario. En menos tiempo del que pestañeamos ya hay dos frameworks nuevos. Tampoco basta con acumular pequeños cursos subvencionados, mal traducidos y con temarios que son un 'refrito' de la misma información repetida de curso en curso. Coleccionar diplomas como estampitas te puede dar una falsa sensación de seguridad pero en realidad no te está ayudando gran cosa a mantenerte actualizado.

Afortunadamente, al igual que la tecnología nos obliga a mantenernos al día, también nos ayuda a hacerlo con cursos de gran calidad como los que puedes encontrar en Miríada XedX o Coursera. Muchos de estos cursos son impartidos en inglés ¿no lo dominas? Quizás tu formación debería empezar por ahí. Échale un ojo a webs como busuu.com donde podrás enviar tus textos en inglés para que los corrijan nativos de ese idioma. Mientras, tú puedes corregir los de otros alumnos en español. Te recomiendo también memrise.com que te ayudará a aprender nuevo vocabulario y a recordarte el ya aprendido si hace tiempo que no lo repasas o si cometiste un error cuando te lo preguntaba.


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.



Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).



Sunday, 12 January 2014

El ingeniero y el puente

En el siglo V antes de Cristo cierto ingeniero romano fue designado para dirigir la construcción de un puente sobre el río Leza. El puente era importante para la zona, permitiría el paso de personas y mercancías ahorrando tiempo en recorrer largas distancias buscando un paso llano por el que cruzar el río.

El ingeniero acogió su nombramiento con entusiasmo y se lanzó a planificar y estimar todo lo que sería necesario para su construcción. Calculó con exactitud cuantos albañiles, grúas, poleas, andamios y cimbras necesitaría y pudo ver claramente que contando con 50 trabajadores podría terminar un puente como aquel en 4,7 años de trabajo.

Con los 600.000 sestercios que recibió para ejecutar este encargo se apresuró a comprar todo el material que había calculado y ordenó depositarlo a pie de obra. Reclutó los 50 albañiles que había estimado y los envió a orillas del río para empezar los trabajos cuanto antes. No había tiempo que perder, cuanto antes se comience, antes se podrá acabar.

Pronto los trabajadores le dijeron que no eran necesarias tantas poleas y grúas pero que los picos y sierras eran claramente muy pocos para el trabajo que había que hacer. No puedo hacer nada, dijo el ingeniero, ya se ha gastado la mayor parte del presupuesto y no queda gran cosa para comprar nuevo material. Tendrán que adaptarse a lo que hay.

La construcción continuó su curso haciéndose pronto evidente que todo no marchaba según lo previsto. El capataz explicó al ingeniero que la cantera de donde se traía la piedra estaba demasiado lejos y que la calzada estaba llena de baches y socavones desde la riada del pasado invierno. Se tardaba mucho en traer la piedra en carretas hasta el puente. Tendrán que hacer un esfuerzo extra, dijo el ingeniero, no hay tiempo ahora para arreglar la calzada.

El capataz también hizo saber al ingeniero que era necesario construir arcos entre los pilares del puente para reducir los materiales utilizados y, sobre todo, para mejorar la resistencia del puente. No hay tiempo ahora para florituras, dijo el ingeniero, vamos retrasados. Pondremos algo más de mortero en los pilares, con eso será suficiente.

Las noticias sobre la marcha del puente llegaban a oídos del Prefecto que desesperaba por la lentitud de las obras por lo que mandó llamar al ingeniero. El Prefecto necesitaba justificarse ante Roma y exigía que el puente estuviese acabado para las próximas fiestas saturnales. El ingeniero explicó que para conseguir tal cosa necesitaría al menos otros 50 trabajadores adicionales. Ante la presión, el Prefecto accedió y se comprometió a enviar los nuevos trabajadores en el plazo de 1 mes.

De vuelta en el puente, el ingeniero reunió a todos los trabajadores y les pidió un esfuerzo adicional para cumplir los compromisos. Los trabajadores no entendían cómo podían trabajar el doble de rápido si no tenían suficiente piedra para continuar y en cualquier caso siempre debían esperar a que el mortero secase.

Ni siquiera con los nuevos trabajadores pudo terminarse el puente a tiempo. No había herramientas para todos, la piedra seguía llegando con lentitud a la obra y los desmoronamientos eran habituales por las prisas en la construcción.

En la antigua Roma, los constructores de un puente debían colocarse debajo mientras la primera legión lo cruzaba. Es un buen aliciente para construir puentes firmes y sólidos ¿no crees?


Si te interesa saber más sobre gestión ágil de proyectos, estimaciones, ventajas y desventajas de Scrum quizás te interese mi libro: Gestión práctica de proyectos con Scrum.



Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).


Monday, 6 January 2014

Propósitos para el 2014

Se suele decir que para lograr alcanzar nuestras metas debemos definir una serie de pasos objetivos y medibles que nos lleven a nuestro fin. Luego comprobar periódicamente cómo de cerca o de lejos estamos de cumplir nuestros objetivos. Yo no he hecho nada de esto en mis propósitos de este año. Mis metas para 2014 no pueden ser más subjetivas pero me quedaré más que contento si pudiese solo alcanzar la mitad de ellas.

Les dejo en esta imagen un enlace al prezi con mis propósitos en la gestión de proyectos para este nuevo año que comienza. Aquí va:

Propósitos para el 2013 en la gestión de proyectos