Sunday, 24 November 2013

3 artículos imprescindibles en el desarrollo de software

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.

Sunday, 17 November 2013

Jornada sobre cómo "Adoptar Scrum y sobrevivir al intento..."

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




Sunday, 10 November 2013

Lecciones aprendidas en la implementación de Scrum

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)

Sunday, 3 November 2013

5 lecciones aprendidas en la gestión de proyectos

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