El mundo avanza que es una barbaridad

Publicada el enero 19, 2014 por antoniomartel

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 X, edX 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).

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

El ingeniero y el puente

Publicada el enero 12, 2014 por antoniomartel

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

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

Propósitos para el 2014

Publicada el enero 6, 2014 por antoniomartel

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

Publicado en Blog, Blog 1 | Etiquetado | Deja un comentario

Repaso a 2013

Publicada el diciembre 29, 2013 por antoniomartel

Finaliza el año 2013 y con él se cierran casi diez meses de publicaciones semanales en el blog. Han sido unas 45 entradas en las que he escrito sobre muchas cosas diferentes. La temática ha ido adaptándose a mi propia evolución, a mis intereses y por supuesto, también a los temas que percibía como más interesantes por los lectores.

Les dejo aquí un resumen los posts que han tenido más repercusión, empezando por los más leídos:

Los más comentados o con más likes:
Algunas entradas se escribieron durante el primer mes de existencia de este blog por lo que creo que no recibieron la suficiente audiencia. Ahí van:
Este es mi resumen del 2013 en este blog de dirección de proyectos. Sólo me queda desearles que tengan un gran 2014. Espero verles por aquí en este nuevo año.

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

5 errores gestionando proyectos

Publicada el diciembre 15, 2013 por antoniomartel

Gestionando proyectos se comenten errores continuamente, yo por lo menos he cometido unos cuantos. Publico aquí sólo cinco de ellos, los más importantes o los más confesables según se mire. He metido la pata de muchas otras formas pero había que ponerle algún límite a esta entrada en el blog. Ahí van:

Primero el problema, después la solución

Ese es el orden, primero se identifica un problema y luego se le aplica una solución, no al revés: Es habitual oir hablar de una solución muy guay que luego aplicamos entusiasmados al proyecto. Haya problema previo que solucionar o no. ¿De qué sirve implantar en el trabajo diario el nuevo y sofisticado software para hacer Test Driven Development si realmente estás teniendo un problema mucho más básico con ese proyecto que te trae de cabeza?

Contar los pasos en lugar de mirar el camino

Todos sabemos que en los proyectos se suelen disparar las horas empleadas y que rara vez se cumplen los cálculos hechos en las estimaciones. Nuestra primera reacción suele ser la de supervisar cada hora registrada y hacer complejas gráficas que nos muestren lo bien o mal que vamos con respecto a la estimación pero ¿nos ayuda ésto a terminar antes el proyecto?

Si nos contratasen para llevar una carga desde el punto A hasta el punto B e hiciésemos una estimación según la cual haremos ese trabajo dando 10.000 pasos ¿en qué nos va a ayudar saber que ya hemos dado 5.000? ¿Sabemos dónde estamos o si hemos estado dando vueltas en círculo? ¿No será mejor levantar la vista, mirar cuánto hemos recorrido ya, si el camino realmente lleva a B o si hay algún modo más fácil de llegar allí?

Requisitos fantasma

En ocasiones le pedimos a los miembros del equipo de trabajo que cambien lo que ya han hecho porque ‘así no lo va a aceptar el cliente‘ o porque nosotros pensamos que el producto debe funcionar de otra manera. Nuestro compañero ya hizo una propuesta que ha costado tiempo y esfuerzo. Es mejor que la vea el cliente y dé su opinión. Él decidirá si está bien o está mal. Invertir tiempo en correcciones o mejoras no solicitadas sólo nos va a retrasar la entrega (con esto no quiero decir que no se revise lo que se ha hecho o que no se compruebe si tiene la calidad suficiente antes de mostrarlo al cliente)

Contagiar las prisas

Como jefe de proyecto suelo trabajar en varios a la vez, lo que suele implicar a varios clientes, cada uno con sus necesidades, múltiples fechas de entrega, tensión y mucho estrés. Intento no contagiar este estrés a los miembros del equipo de trabajo y aportar la tranquilidad que pueda. Por supuesto, todos los miembros del equipo deben conocer las fechas de entrega y el trabajo comprometido en cada una de ellas. Añadir prisas al trabajo diario sólo suele traer problemas en la calidad del producto final o cosas que quedan a medio resolver.

¿Puedes hacerlo más fácil?

Uno de los principales errores que se comete en un proyecto es el de comenzar cuanto antes cada tarea sin pararse a planificar los pasos a dar en esa tarea, si realmente es necesaria y, sobre todo, si puede simplificarse de algún modo. Me refiero no solo a implementarla del modo más fácil posible sino a simplificar la tarea en sí. Para ese complejo sistema de interconexión entre múltiples ordenadores ¿no existe ya algún estándar predefinido? Para ese analizador sintáctico ¿es necesario que sepa resolver ecuaciones de tercer grado? No hay tiempo mejor invertido que el utilizado para reducir la complejidad del trabajo a hacer.

Estos son los errores de los que me he dado cuenta hasta ahora. A algunos ya les he aplicado alguna solución, en otros todavía tengo que encontrarla. Seguro que me quedan aún errores nuevos por cometer. En los siguientes enlaces pueden encontrar algunas de las lecciones aprendidas de estos errores:

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

Contratos a precio cerrado

Publicada el diciembre 8, 2013 por antoniomartel

Hace algunas semanas me preguntaba Antonio, a través de los comentarios de este blog, por el tipo de contrato que tenía en mis proyectos y si estos contratos se realizaban con clientes internos o externos. La negociación sobre el contrato es uno de los asuntos más difíciles con los que nos podemos encontrar en un proyecto y probablemente, dónde puede surgir más fricción entre proveedor y contratante.

Trabajo en el área de administración pública de una empresa de desarrollo de software. Eso significa que, al menos en el 90% de los proyectos en los que trabajo, tengo como cliente a un organismo público. Los contratos vienen normalmente determinados por un pliego de cláusulas administrativas y otro de prescripciones técnicas en los que se detallan los servicios contratados, las características del producto a ser desarrollado y el precio máximo que puede tener la oferta. Se especifican incluso las características técnicas del software y hasta el perfil de los participantes en el proyecto. Todo está muy acotado y delimitado. Es el precio que tiene que pagar la administración pública para evitar arbitrariedades.

Si se ha tenido suerte y se ha podido ganar el concurso público nos enfrentamos luego, tanto cliente como proveedor, con la cruda realidad de los proyectos. Y es que las circunstancias cambian, aparece nueva legislación que afecta al proyecto o lo que se pensó que era correcto unos meses antes se ha podido comprobar que ahora las necesidades son distintas. ¿Qué hacemos? Si adaptamos el producto a todos los cambios que el cliente necesita,  nosotros como proveedores, sufriremos ese coste adicional. Si negamos al cliente cualquier posibilidad de cambio, remitiéndonos siempre al contrato y a los pliegos, corremos el riesgo de entregar al cliente un producto ajustado a un decreto del año anterior o que, por otras causas, ya sabe que no le va a servir a sus necesidades.

La forma de evitar ésto, por lo menos la que mejor me ha funcionado hasta ahora, ha venido dada por la propia forma de trabajar en estos proyectos, usando Scrum. Al inicio del proyecto hago una lista con las funcionalidades que hay desarrollar y le asigno a ellas una puntuación que el cliente conoce desde el principio. Si el cliente quiere incluir dos nuevas funcionalidades le pido que me indique qué otras funcionalidades de similar puntuación sacamos de la lista. Normalmente esta solución le sirve para resolver la situación y no tiene problemas en renunciar a otras funcionalidades que ahora sabe que no son tan importantes. Si todo queda constatado en un acta de reunión y, sobre todo, queda entendido a qué se renuncia y qué se va a obtener a cambio, no suele haber muchos problemas.

Esta es la solución que yo aplico. Como siempre, espero que le pueda servir a alguien.

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Revista ITPROIECTUS y las I Jornadas en Dirección de Proyectos

Publicada el diciembre 1, 2013 por antoniomartel

El pasado viernes 29 tuve la oportunidad de dar una charla sobre el Factor humano en la dirección de proyectos en las I Jornadas de Dirección de Proyectos organizadas por la SPEGC y ITPROIECTUS, la empresa de consultoría y formación en gestión de Iván Tejera.

Me sorprendió mucho la buena asistencia que tuvo el evento: acudieron alrededor de 90 personas que prácticamente llenaron la sala. Muchos aguantaron hasta la ronda final de preguntas pasadas ya las 9:00 de la noche de un viernes. Creo que fueron unas jornadas interesantes por la calidad profesional de los ponentes (espero que hayamos estado al nivel esperado por los asistentes) Conocía personalmente a algunos de ellos y muchos suman un montón de años de experiencia dirigiendo proyectos y equipos de trabajo ¡es difícil contarles algo nuevo!

En las jornadas participaron, entre otros, directores de proyecto, responsables de departamentos de desarrollo o de nuevas tecnologías como:

  • Raúl Herranz hablando sobre Metodologías Ágiles en la dirección de proyectos
  • Antonio Dorta sobre la Gestión visual en la gestión de proyectos
  • Mónica Khiani interviniendo para hablar sobre Gestión de Proyectos desde el enfoque de PMI – PMBOK
  • Agustín Tapia que hizo una divertida comparación entre la gestión con Scrum o PMBOK
  • Miguel Quintanilla Eriksson sobre La Dirección de Proyectos en la Administración Local
Además de las charlas, se aprovechó para hacer la presentación del primer número de la revista PROIECTUS en la que, además de los ponentes en estas jornadas, también escribieron Eduardo Gutiérrez Bahillo, Manuel Vara, Juan Carlos Falcón, Davide Mazzanti, Vicente González Medina y Roberto González Yuste. Se incluye también una entrevista a Claudia del Toro Vargas, jefa del proyecto de revisión de la traducción del PMBOK 5 al español.
Les dejo aquí un enlace a la revista en su versión digital y algunas fotos del momento de mi charla. Atentos a http://proiectus.es/ dónde se publicarán los vídeos de las charlas.
Enlace al 1º número de la revista Proiectus
Enlace al 1º número de la revista Proiectus

Factor humano en la dirección de proyectos. Ponencia Antonio Martel
I Jornadas Dirección de proyectos. Ponencia Antonio Martel
I Jornadas Dirección de proyectos. Ponencia Antonio Martel

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

5 Lessons learned in Project Management

Publicada el diciembre 1, 2013 por antoniomartel

Whenever I finish a project I try to have a look at what went wrong, what worked as a charm, and what I tried but it didn’t work out. Even when I get a final negative balance, the project may has been worth it if I don’t make the same mistakes again.

From some of these balances, I have extracted five of the most important lessons I’ve learned. Some are beginner mistakes, others should have been solved using simple logic but, by then, it wasn’t that evident to me. Here you go:

Agility works

It is difficult to quantify it but since I started using Scrum in my projects, the number of hours spent by functionality went down. Just doing the daily meeting for 15 minutes, maintaining project status chart that tells us if we are going well or not and a delivery every two weeks allowed us to obtain 80% of the benefits of Scrum. In addition, delivering consistently every two weeks, showing client what was agreed two weeks earlier, seemed to bring customers some comfort. In July or August, when meetings were not possible, the weekly delivery of a simple two-page document with the percentage of completion for each functionality and two paragraphs explaining the reason of those percentages, helped to restore credibility in a difficult project (especially in September when they could check that those percentages were real)

Everything is not positive in Scrum

It requires much more dedication of the Scrum Master than it would if you only were playing the role of project manager. Those 15 minutes at the daily meeting will tell you a lot about the difficulties that need to be solved to keep going forward. Trying to solve them will take you the rest of the morning.

On the other hand, having a delivery every 2 weeks can be exhausting. You cannot be sprinting for months and months. After six months you will be ending trotting (hopefully) You need to take this into account since the first planning.

Last but not least, Scrum is not magic. Whatever methodology you use you will need a team able to perform at a good level, willing to pitch in and eager to contribute. Teams like that do not grow on trees. If you already have one of those teams the project manager mission will be to interfere as little as possible.

Adding more workers to the team will slow it down

Well, this is already said for a lot of years in the book The Mythical Man-Month. Yet it is necessary to emphasize this, there are no much exceptions to this rule. No matter how tight the deadlines are: Nine women cannot make a baby in one month.

Who is the owner of all this?

No matter how we call it: identifying stakeholders, designating the product owner or involving the stakeholders. At the end we need to know who will actually validate. And I do not mean who will sign the bill. You also need to know who will use the product. The project will only be successful if after delivering it works and it is useful.

In certain project, the client’s director gave us all the documentation, validated partial deliveries, tested the entire application and congratulated us for the work done. Unfortunately, when his secretary attended the training session a week before sending the product to production, she said: ‘This is not going to help me: that one is not the right template and I need to collect different data than the one showed there’ . This meant a week of overtime and extra effort and the risk of putting into production environment a product that could be unstable.

Minimum Viable Product

If you already have something that may be useful to the user, give it to it, put it into production, take it out for sale. Do not wait until you have completed every single functionality. If you remember the Pareto principle, with only 20% of them you will obtain 80% of uses of your product.

While in production you will begin to get the impressions from its users. They will know more accurately what they really need and you will know what you did wrong and how you can improve it. If you bet on a single final delivery you will have only one bullet to hit the target (to do this would have saved us a lot of problems with the product mentioned in the previous point)

Those are my lessons learned. I hope someone will make the most of them.

Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario

3 artículos imprescindibles en el desarrollo de software

Publicada el noviembre 24, 2013 por antoniomartel

De cuando en cuando publicaré una entrada en este blog sobre aquellos artículos que me han parecido importantes y de los que pienso que merece la pena su lectura. Aquí van los tres primeros:

La nueva jerga de la programación en el blog Coding Horror

Jeff Atwood menciona en este post algunos de los términos que se han convertido en populares en la jerga informática desde hace algunos años. Creo que más que populares son sobre todo divertidos. Me gustan especialmente uno de ellos: La funcionalidad por jurisprudencia se utiliza para definir aquel error que lleva tanto tiempo en la aplicación que se convierte en el comportamiento esperado de la misma. Cuando deja de aparecer se solicita al departamento de soporte que ‘lo arregle’

4 signos de que Agile está en declive- La secuela

También me parece muy divertido y sobre todo muy claro este post sobre signos de declive de Agile, postagilismo y los principales errores que debemos evitar en esto de la agilidad. Al final del artículo aparece un listado de cuatros puntos que indica que repitamos como un mantra (muy de acuerdo con todos los puntos):
  1. No hay soluciones mágicas ni un único camino al éxito.
  2. Esto en un proceso de aprendizaje. Los fallos son inevitables y necesarios.
  3. Lo que quiera que sea lo que yo hago no tiene porque ser la clave del éxito para otros.
  4. Estoy dispuesto a ayudar a construir un puente entre desarrolladores y el negocio.

La verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más

En esta entrada de su blog Javier Garzás explica que dónde mejor podemos ver la verdadera calidad de un software es acudiendo directamente al código fuente. De él podremos deducir la calidad y el diseño que se ha seguido mejor que de la documentación y pdfs que acompañan cada entrega.
Recomiendo todo el blog de Javier, no sólo este post. Si le echan un vistazo a su historial de artículos podrán ver un montón de posts interesantes sobre el desarrollo de software en España. Seguro que verán reflejados en muchos de ellos su trabajo diario.
Publicado en Blog, Blog 1 | Etiquetado | Deja un comentario

Jornada sobre cómo «Adoptar Scrum y sobrevivir al intento…»

Publicada el noviembre 17, 2013 por antoniomartel

El pasado jueves tuve el placer de dar una pequeña charla en el edificio IncubeGC de la SPEGC al departamento de Desarrollo e Innovación Técnológica de www.aidacanarias.com sobre la adopción de Scrum y los problemas que pueden encontrarse al comenzar a implantarlo.

Espero que les resultara de interés. Solo me queda desearles buena suerte en su implementación. No será fácil pero, con todo el empeño y esfuerzo que han puesto Emilio, Alejandro y sus compañeros, seguro que todo les irá bien.

Les dejo con enlace a la presentación en Prezi que utilicé y con algunas fotos del evento:

Presentación Prezi sobre cómo "Adoptar Scrum y sobrevivir al intento..."

Tiempo para preguntas en la charla sobre Scrum a AIDA Canarias
Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Lecciones aprendidas en la implementación de Scrum

Publicada el noviembre 10, 2013 por antoniomartel

La semana pasada escribía sobre las lecciones que había aprendido en la gestión de mis propios proyectos. Les dejo esta semana con un vídeo de la charla que Jeff Sutherland dio a los ingenieros de Google sobre sus lecciones aprendidas en la implementación de Scrum en lugares como Nokia, PatientKeeper o la propia Google. Les cuento en este post algunas de las cosas que me parecieron curiosas:

  • En Google se introdujo Scrum poco a poco por temor a la resistencia de sus ingenieros que podían pensar que introducir un proceso formal no les beneficiaría sino que les ralentizaría en su trabajo. Comenzaron la implementación de Scrum usando solo las prácticas más básicas.
  • Hubo incluso resistencia para las reuniones diarias para las que también pensaban que sería un tiempo invertido en vano. Comenzaron por reuniones que duraban mucho más de 15 minutos ya que cada ingeniero tardaba mucho tiempo en explicar lo que estaba haciendo y los problemas que estaba teniendo. Después de un tiempo, cuando todo el mundo había explicado su trabajo y era consciente del de los demás, las reuniones fueron mucho más fluidas.
  • La gráfica burndown les ayudaba a darse cuenta de cuál era el tiempo real que iban a emplear en desarrollar una funcionalidad. Para una funcionalidad a la que inicialmente asignaron un tiempo de 3 semanas y 40 puntos comprobaron que en la primera semana hicieron solo 8 puntos. En la segunda consiguieron terminar solo 7,5 puntos. Aún así, uno de los responsables pensaba que tendrían la funcionalidad lista en esas 3 semanas cuando la gráfica hacía evidente que no estaría en ese tiempo.
  • En un proyecto para el sector sanitario, usado por cientos de doctores y usuarios online, la definición de Hecho (Done) se fue ampliando desde pasar inicialmente por los test unitarios y de aceptación para luego añadir a la definición de verdaderamente Hecho o Terminado algo como ésto: ‘Poner en producción y si el teléfono no suena con incidencias durante 1 hora la nueva entrega estaba completa’
  • Para mi alivio, en su Scrum inicial simplificado no usaban gráfica burndown por cada iteración sino una por cada entrega. Esto me hizo sentir mejor ya que yo no había podido nunca mantener un tablero Kanban actualizado a diario para cada Sprint (sí, ya sé, Scrumbutophobia)
Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

5 lecciones aprendidas en la gestión de proyectos

Publicada el noviembre 3, 2013 por antoniomartel

Siempre que acabo un proyecto procuro hacer balance de lo que fue mal o de lo que fue bien en él, de lo que intenté y no funcionó o de lo que debo anotarme para no volver a hacer. Incluso cuando el balance final lo he considerado negativo, puede que el proyecto haya merecido la pena si en el siguiente proyecto no vuelvo a cometer los mismos errores.

De algunos de esos balances he extraído aquí cinco de las lecciones más importantes que he aprendido. Algunos son errores de principiante, otros los debería haber resuelto la simple lógica pero no me resultaron tan evidentes cuando estaba en ello. Ahí van:

La agilidad funciona

Es difícil de cuantificar pero desde que comencé a usar Scrum en mis proyectos, el número de horas invertidas por funcionalidad bajó y en mi opinión lo hizo bastante. Simplemente haciendo el seguimiento diario durante 15 minutos, mantener la gráfica del estado del proyecto que nos indica si vamos bien o no y las entregas cada dos semanas nos permitieron obtener el 80% de las ventajas de Scrum. Además, a los clientes parecía aportarles cierta tranquilidad que de forma consistente cada dos semanas se entregara y mostrara lo que se había acordado dos semanas antes. En los meses de julio y agosto, cuando no eran posibles las reuniones, el envío semanal de un simple documento de dos páginas con el porcentaje de realización de cada funcionalidad y dos párrafos explicando el porqué de esos porcentajes, ayudó a recuperar credibilidad en un proyecto difícil (especialmente cuando en septiembre se pudo comprobar que los porcentajes eran reales)

Todo no es positivo en Scrum

Se requiere de bastante más dedicación del Scrum Master de la que tendría si solo jugase el papel de jefe de proyecto. En esos 15 minutos de seguimiento diario te van a contar un montón de dificultades que se necesitan resolver para seguir avanzando. Intentar resolverlas te va a llevar el resto de la mañana.

Por otro lado, tener una entrega cada 2 semanas puede ser agotador. No se puede estar esprintando durante meses. Al cabo de seis meses se termina trotando (y eso con suerte) Es necesario tener esto en cuenta desde la primera planificación.

Por último, y no por ello menos importante, Scrum no es magia. Uses la metodología que uses necesitarás un equipo formado en el trabajo a realizar, dispuesto a arrimar el hombro y con ganas de aportar. Equipos así no crecen en los árboles. Si cuentas con uno, la misión del jefe de proyecto será estorbar lo menos posible.

Incorporar más trabajadores al equipo no consiguirá más que ralentizarlo

Bueno, esto ya se decía desde hace un montón de años en el libro The Mythical Man-Month. Aún así es necesario recalcarlo, no hay excepciones a la regla. No importa lo ajustado que sean los plazos: nueve personas no pueden crear un bebé en 1 mes.

¿Quién es el dueño de todo esto?

Da igual cómo lo llamemos: identificar a los interesados, designar el product owner o hacer partícipes a los stakeholders. Al final necesitaremos saber quién va a validarlo en realidad. Y no me refiero a quién va a firmar la factura. Necesitarás conocer también a quién va a usar el producto. El proyecto sólo será un éxito si después de entregarlo funciona y es útil.

En algún proyecto el director de área nos facilitó toda la documentación, validó las entregas parciales, testeó toda la aplicación y nos felicitó por el trabajo realizado. Lamentablemente, cuando su secretaria acudió a la sesión de formación una semana antes de la puesta en producción nos dijo: ‘Esto no me sirve: esa ya no es la plantilla correcta y necesito recoger datos diferentes de los que ahí pone’. Esto significó una semana de horas extra y esfuerzo adicional además del riesgo de poner en producción un producto que podría ser inestable.

Producto Mínimo Viable

Si ya tienes algo que puede ser útil al usuario, entrégalo, ponlo en producción, sácalo a la venta. No esperes a tener todas y cada una de las funcionalidades terminadas. Si recuerdas el principio de Pareto con sólo el 20% de ellas conseguirás completar el 80% de los usos que tendrá tu producto.

Cuando esté en producción comenzarás a obtener las impresiones de los usuarios. Ellos sabrán con mayor exactitud qué es lo que de verdad necesitan y tú sabrás qué has hecho mal y cómo puedes mejorarlo. Si apuestas por una única entrega final sólo cuentas con una única bala para acertar en la diana (haber hecho esto nos habría ahorrado un montón de problemas con el producto mencionado en el punto anterior)

Estas son mis lecciones aprendidas. Espero que a alguien le sirva de ayuda como lo hizo para mí.

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.

Libro Gestión práctica de proyectos con Scrum

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Mi página web con Twitter Bootstrap

Publicada el octubre 27, 2013 por antoniomartel

Hace algunos meses oí hablar de Bootstrap, la herramienta de trabajo que dos trabajadores de Twitter crearon para acelerar los tiempos de desarrollo de nuevas páginas web y disminuir las tareas de mantenimiento haciéndolas más homogéneas. Me decidí a probarla y para ello qué mejor que crear una página web real en la que pudiera publicar contenidos como complemento a este blog.

Crear una página web con Bootstrap no puede ser más sencillo. Descargas las librerías de esta herramienta, la plantilla que te interesa (en mi caso el carrusel de imágenes) y luego las librerías de jQuery. Apenas es necesario programar nada, solo hacer unas modificaciones a los enlaces y las etiquetas del menú y ya tenemos una página web con menús desplegables, carrusel de imágenes, bloque de destacados, etc.

Hasta aquí sólo tenía un html en mi disco duro así que necesitaba un servidor web o una empresa de hosting donde alojar mi página para que estuviera accesible desde Internet. En lugar de eso utilicé el espacio de Google Drive (ver referencias) que viene con mi cuenta de Gmail y creé ahí una carpeta pública donde copié el index.html, las imágenes de la web y otros archivos que necesita Bootstrap.

Ya tenemos la página web publicada en Internet. Google Drive te proporciona un link enorme a esa carpeta pública (https://googledrive.com/host/0B7JU-NBrpaxVaktjOHVkNWM5Vlk/) pero con la ayuda de acortador de urls como el de Google (https://goo.gl/) se puede convertir esa dirección a una url un poco más amigable.

Twitter Bootstrap probablemente no sea de gran ayuda para el desarrollo de aplicaciones web de gestión pero si tienes que construir una página web con un diseño claro y limpio que además siga los estándares actuales de diseño web puedes contar una gran variedad de componentes y plantillas predefinidas en Bootstrap que te harán el trabajo mucho más fácil.

Les dejo aquí un enlace al resultado final enlazada desde mi esta misma web: http://perfil.antoniomartel.com.

Referencias:

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.

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

Publicado en Blog, Blog 1 | Etiquetado , | 2 comentarios

Administración Pública y las nuevas prácticas de gestión

Publicada el octubre 20, 2013 por antoniomartel

Somos muchos los que de una manera u otra trabajamos para la Administración Pública, algunos directamente pero otros muchos indirectamente, como proveedores de servicios o productos pero trabajando en este sector al fin y al cabo.

Muchos tratamos de realizar estos servicios o entregar esos productos aplicando técnicas de gestión ágiles como Scrum o Lean Management pero solemos encontrarnos con cierta rigidez en la formalización de los contratos o en los pliegos de contratación de los concursos públicos.

Alguien preguntaba recientemente en un debate del grupo PMP Canarias en LinkedIn si las administraciones públicas estaban preparadas para la gestión de este nuevo tipo de proyectos. En mi opinión, a la Administración Pública Española aún le queda un buen trecho pero creo que ya se comienzan a ver ciertos avances en la aplicación de nuevas formas de gestión como Lean Government, especialmente en otros países.

En el NHS, el sistema de seguridad social británico, con la aplicación de técnicas Lean para eliminar retrasos innecesarios, reducir el papeleo y aprovechar los tiempos muertos de espera para realizar ‘actividades útiles’ se consiguió reducir la mortalidad en dos tipos graves de fractura de un 22,9% a un 14,6% en solo seis meses. Eso significa que en ese periodo, de media, unos 14 pacientes más lograrían sobrevivir a la operación.

Otro ejemplo de Lean Healthcare se encuentra en un hospital de distrito del NHS. La clasificación de las pruebas de ultrasonido en ‘verdes’ para las más simples y ‘rojas’ para las más complejas permitió reducir la lista de espera para estas pruebas de 12 semanas a tan solo 2. Se asignó el tiempo justo para la complejidad de cada prueba y se redujeron los trámites y el papeleo al mínimo para las pruebas más simples con lo que además de la reducción en los tiempos de espera se logró que quedasen más huecos en el calendario para tratar adecuadamente las posibles urgencias.

Mucho más reciente es la actualización de las normas de contratación del Departamento de Defensa de Estados Unidos para declarar ‘ilegales’ los proyectos en cascada. Parece ser que uno de los proyectos que ha disparado esta decisión fue el proyecto Sentinel en el que después de un proyecto fallido inicial de 170 millones de dólares, retrasos considerables, 6 años de trabajo y 451 millones de presupuesto se consiguió finalmente poner en marcha el nuevo sistema, gracias entre otras cosas, a la aplicación de técnicas ágiles de desarrollo para reducir los tiempos de entrega y los costos de cada funcionalidad entregada.

También en España parece haber un creciente número de instituciones públicas como el Museo Thyssen, el Hospital Clínico de San Carlos en Madrid y su Smart Health Lab o la Agencia Tributaria que están comenzando a usar y aplicar técnicas ágiles como Lean Government en sus negocios. Espero que estas instituciones sean solo la punta de lanza para lograr una Administración Pública más eficiente en estos ‘lean times’

Referencias:

Publicado en Blog, Blog 1 | Etiquetado , , , | Deja un comentario

SCRUM Pros and Cons

Publicada el octubre 17, 2013 por antoniomartel

If you are considering SCRUM as a working method but you do not know very well what SCRUM is all about. You’ve heard a lot of people talking about the benefits of this system but, how many technologies and techniques have appeared quickly and disappeared even faster? All of them promised to be revolutionary. When we hear so much hype about a new one we bow in critical eyebrow .

A few months ago I published a prezi to explain the advantages and disadvantages of implementing SCRUM in an organization (I tried to be impartial, I promise):

In this post I will explain this prezi using words instead of pictures.

The team may be tempted to take the shortest path

You have to deliver things every two weeks. At the last delivery the team was not able to complete all planned functionality. The team velocity does not predict that you will finish on time this time. It is then when a new problem arise: the team may be tempted to resolve pending tasks in a hurry leaving behind them technical ‘debts’. Apparently everything goes well, more functionality made​, new ones are started, and the customer is happy because they are on schedule.

But whenever a blur is left behind you can be sure that you will have to face it sooner or later. If new things are built on this blot, the ‘debt’ begins to multiply. Soon you’ll have to stop everything and commit to repay the debt (with interest rate). The project does not come to an end when there was little to finish it: burndown chart seems to have a horizontal asymptote at 0 (sorry, some Maths)

Do you need dates of delivery well in advance?

This is one of the most common critics to SCRUM. In a way it makes sense, it is not possible to predict when you’re going to end if what you are going to build may change and vary over time. But do you prefer a product that is known with certainty to be completed in 10 months but it is built on the ideas and opinions you had 10 months ago? Maybe you prefer a product that could be finished within similar time but it can evolve to your real needs.


Stress!

We can not spend our lives sprinting. As soon as we deliver a new functionality, we are committed to the following one, which is only a couple of weeks away. Then another and another one. If we had to travel many miles, we can begin with a quick sprint to reach the first goal but we’ll be walking slowly to reach the last one.

Is your team self-organized?

One of the principles of Scrum is that the team should make their own decisions and manage themselves. Furthermore, it requires that there is no members of the team focused only in specific tasks such as analysis or testing. Inside the same team you should have someone able to test, to code, to write a specification, to analyse, and so on. Do you always have a team like that? What if we do not have it?

It is certainly a problem but, is there any methodology that can finish projects successfully not having at hand people with the required skills?

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

IV Conference on Sustainability

Publicada el octubre 17, 2013 por antoniomartel

Last Thursday I had the honor of giving a presentation on Phase 2 of the Canary Islands Waste Information System (GUIRRE) at the Fourth Conference on Sustainability inside the activities for the World Environment Day.

GUIRRE is a very special project for me for several reasons: It was the first time we run a project using continuous integration (Jenkins) and automated tests using Selenium IDE.

At the beginning of the project, before starting to program, we defined a section called ‘How to test it’ for every feature we had to develop. We recorded tests with Selenium, following the steps of the ‘How to test it’ section. Those tests helped to show that the new feature worked properly. If we found a bug, we recorded also a test to reproduce it. When the test became green, we had fixed it.

Every two weeks, we recorded all tests of the current Sprint on a Selenium ‘suite’. Every night, the continuous integration server, Jenkins, ran the suite and all suites from previous Sprints and reported if there had been mistakes. If the previous morning someone had modified a piece of code affecting a functionality developed some months ago, Jenkins showed us some dark clouds.

The other reason GUIRRE is a dear project to me is because we managed to finish under budget (yes, those projects exist) despite we fully assumed the cost of learning Jenkins and Selenium, and that the budget was very adjusted. Quite a challenge.

I leave below a few pictures of the event and a link to the paper I presented. Hope you find it of interest.

Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

More about estimations

Publicada el octubre 17, 2013 por antoniomartel

When talking about estimations ysing Agile techniques, there are certain things that are hard to accept for those who, for a few years, have already been planning and calculating times and dates.

We can find many planning techniques Agile: Planning Poker, clothing sizes ( S , M , L , XL , etc. . ) or the Team Estimation Game but, admittedly, all of them are difficult to integrate into a traditional development environment and even less for the customers of our products (at least those I’ve been working with)

Most of us are not used to see a team ‘playing cards’ for a session of Planning poker (at least I’m not) However, I agree with the philosophy behind these techniques and I think the fact that they are becoming increasingly popular it is, in part, because they are attempting to banish certain beliefs about the estimates:

Wrong estimations

Can we get it right? Estimate is to make a prediction about what would take to do a task or the materials we need to do a job. When we estimate with a high uncertainty, as when we do it based on some procurement specifications, rather than a prediction is a gamble.

It is obvious that we need to estimate. We try to predict what will happen to make decisions, but unless you have done the same task many times before and we have done it with the same team and under the same circumstances, we must know that there are high chances of being wrong.

The more effort you devote to the estimate we approach reality

To estimate has a cost and a it is a high cost. When we do not know the detail of every feature of the work, Does it make sense to devote hours and hours to elucidate tasks that do not know well? Make an exercise for me, when you finish your next project check the time recorded in each task. You will see that where you estimated 20 took 100 to you and where you estimated 100 hopefully only took 20 to complete the task. You will also see other tasks with no imputed hours. Simply they were not needed. However, how many hours were logged on tasks, which nobody thought about them at the initial estimation.

With this or that technique will estimate better

There are many estimation techniques but few will be as useful as a simple comparison of the time that took to do similar projects, the simple breakdown into smaller tasks or the expert judgment.

To use complex estimation techniques can give us a false sense of security about our estimation but it may not provide much higher reliability .However it can lead us to incur a very high cost (see above) and to invest a precious time that we could have used better in other things (such as reducing uncertainty)

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

My communication at the V Conference on Sustainability in the Canaries

Publicada el octubre 17, 2013 por antoniomartel

A few weeks ago, the Canary Islands Department of Environment was kind enough to invite me to give a talk at the V Canary Sustainability Conference in held on Thursday October 3. My paper was on the Waste Information System of the Canary Islands and other software systems that help the Waste Department to control the produced waste in the islands. I hope I have not bored much to those not versed in information systems for hazardous waste!

I leave here a link to my presentation on Thursday:

The V Conference on Sustainability in the Canaries were chaired by the Deputy Minister of Environment of the Canary Islands Government and had as its theme the challenges in waste management on islands so several representatives of Cape Verde attended to share experiences on the management of waste in both archipelagos.
The presentations focused on :

  • [Sal, an island with no plastic] with a representative of the City Council of the Island of Sal in Cape Verde.
  • [Models and waste plan in Cape Verde] by Mr. Gilberto Silva, Councillor for the Environment of the City Council of Praia.
  • [El Hierro 100 % recyclable] by Ms. Fabiola Avila, Environmental Technician Cabildo de El Hierro.
  • [The impact of waste on Climate Change] by Mr. Fernando Herrera, Head of Prevention and Control of Pollution of the Canary Islands.
  • Best practices in waste management by representatives of the Group Martinez Cano and Lopesan Islands.

You can find all the information and some pictures of the event at the following address: Guacimara Medina opens the V Sustainability Conference in the Canaries.

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

Keep it Simple, Stupid

Publicada el octubre 17, 2013 por antoniomartel

Recently, after a conversation with a professional colleague on the current IT world, something reminded me of a Andres Diplotti cartoon I saw first time in Google+:

As a programmer I have been for a long time, and partly still I am, acknowledge that I have had this kind of arrogance (without going to these extremes) I guess it is a sin of youth that has been mitigated with age and that some of us already had since college.
By that time I remember to have discovered the software design patterns book from The Gang of Four. Our applications began to fill with design patterns, the more you used the better, in a kind of competition won by the one who used the more complex and difficult pattern. I guess this helps me to understand the posts and articles I see now on refactoring to eliminate design patterns and the cost of all these changes in some projects.
Over the years I learned firsthand the KISS principle (Keep it Simple , Stupid) not only with patterns, but also when customizing graphical components on screen or with the ‘ghost requirement’, a name that I heard on a rise to a co-worker to refer to those features that nobody asked but one believes important to the customer and that ‘for sure’ he would end up needing.
Long ago, a project manager on a client told me that someone in another team had indicated that it was impossible to get the functionality he asked. I replied that practically everything could be achieved by investing the necessary time. I was not clear enough . I should have added, Is it reasonable to use all that time on that functionality? With almost any programming language one can send a rocket to the moon but do you really want to go to the moon or do you want a working application on time?
Publicado en Blog, Blog 1, English | Etiquetado , , | Deja un comentario

Keep it Simple, Stupid

Publicada el octubre 13, 2013 por antoniomartel

Hace poco tiempo, después una conversación con un colega de profesión sobre el mundo IT actual, algo me recordó una viñeta de Andrés Diplotti que vi por primera vez en Google+:

Como programador que he sido durante mucho tiempo, y que en parte sigo siendo, reconozco haber tenido este tipo de soberbia (sin llegar a estos extremos) Supongo que un pecado de juventud que se ha ido mitigando con la edad y que algunos ya teníamos desde la universidad.
Por aquella época recuerdo haber descubierto los patrones de diseño software con el libro de The Gang of Four. Nuestras aplicaciones comenzaron a llenarse de patrones de diseño, cuantos más usabas mejor, en una especie de competición ganada por aquél que usaba el patrón más complejo y difícil de entender. Supongo que esto me ayuda a entender los posts y artículos que veo ahora sobre refactorizar para eliminar patrones de diseño y los costes que esto tiene en algunos proyectos.
Con los años he aprendido en carne propia el principio KISS (Keep it Simple, Stupid) no solo con los patrones, sino también con la personalización de los componentes gráficos que aparecen en pantalla o con los ‘requisitos fantasma’, denominación que oí en una ocasión a un compañero de trabajo para referirse a esas funcionalidades que nadie te ha pedido pero uno cree importante para el cliente y que ‘seguramente’ que él terminará necesitando.
Hace mucho tiempo, un director de proyecto en un cliente me comentó que alguien en otro equipo de trabajo le había indicado que era imposible conseguir la funcionalidad que él pedía. Le contesté que prácticamente todo podía conseguirse invirtiendo el tiempo necesario. No fui lo suficientemente claro. Debí haber añadido: ¿es razonable usar todo ese tiempo en ese funcionalidad?  Con casi cualquier lenguaje de programación uno puede enviar un cohete a la Luna pero ¿de verdad se quiere ir a la Luna o se quiere una aplicación terminada en el tiempo previsto?

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario