2013

Acabo el año revisándolo a nivel global. Teniendo en cuenta algunos objetivos marcados, el 2013 ha sido el año en el que:

• No he recaído de mis dolencias físicas. Un diez en eso, me encuentro estupendo.
• He participado activamente en la organización de la CAS 2013, y no ha ido mal. Siempre hay margen de mejora, pero en general la sensación es buena.
• Esto se ha llevado una gran parte de mi energía este año, así que no he hecho gran cosa en otros ámbitos.
• He estado (por destacar algo) en la Software CrapmanShit de Barcelona. Soy efectivamente más crap&shit que CraftmanShip, pero aún así un montón de gente interesante y buenos ratos, y mucho material para pensar…
• A nivel laboral, hacemos progresos pero muuuuuuuuy despacio. Si tengo una oportunidad en otro sitio, me gustaría aprovecharla, porque creo que me hace falta un cambio de aires, mucho tiempo para ser saludable en la administración (quizá demasiado para ser recuperable para la vida moderna).

Para este 2014 quiero:

• ACLARARME, que tengo mucho lío.

Normas higiénicas

En el SCBN Xavi Gost habló en una sesión sobre ciertas normas que observa a la hora de programar, las llamó prácticas higiénicas.  En un hilo de Agile-Spain se han recopilado, y ahora las recojo aquí, sobre todo para no perderlas:

* Todo es privado hasta que no se demuestre lo contrario.

* Encapsular siempre las colecciones.

* No usar primitivas en los niveles altos de abstracción.

* Los métodos públicos sólo deben tener llamadas a otros métodos, nunca elementos del lenguaje y siempre deben leerse como si fuesen pseudocódigo.

* Hacer sólo programación defensiva en las interfaces públicas de nuestro API.

* Utilizar siempre el Null Object pattern a la hora de devolver referencias vacías.

* Crear wrappers para librerías externas que utilicemos.

* No propagar excepciones que no son mias y que vienen librerías o componentes externos.

* Evitar los bloques try/catch vacíos.

* No hacer métodos de clase («static» en java). En ocasiones pueden estar justificados, pero sobre todo cuando no se tiene experiencia en OO se tiende a abusar de ellos y se termina con código que en realidad es más procedural que OO.

* Un nivel de indentacion por método. Este esta claro porque ¿no?.

* Solo usar herencia de implementación como ultimo recurso y nunca más de un nivel de herencia.

* Preferir siempre composición, esto nos obliga a poner el foco más en el paso de mensajes entre objetos que en construir jerarquias de objetos.

* 3 parametros por método como máximo. Obliga a construir ValueObjects para modelar conceptos que a menudo están «desperdigados» por nuestro código.

Inceptions

El pasado miércoles asistí a la reunión mensual de Agile Norte, en la que se hablaba del Inception deck (gracias a Iñaki Elkoro y Gorka Armentia). Resumiendo mucho es una técnica para arrancar un proyecto de manera ágil (más información en el artículo enlazado). Para mí tiene varias ventajas sobre las técnicas más tradicionales (que como en otras ocasiones suelen ser una mezcla de nada y alguna metodología, tipo CDMLDAE (Como Dios me lo dió a entender)), que os paso a comentar. En realidad lo siguiente es una mezcla de mis reflexiones al respecto con comentarios que se hicieron durante la charla, mi propio refrito de todo:

• Involucran a mucha gente (idealmente a todos los interesados) en el mismo espacio-tiempo, con lo que se suelen provocar discusiones varias porque cada uno entiende las cosas a su manera, y a veces estos malentendidos se mantienen hasta estadios muy avanzados del proyecto. Provocar estas discusiones por medio de las distintas herramientas que te proporciona el inception es bajo mi punto de vista más que saludable. Tiene otro efecto, y es que en estos casos no puede «tener razón» todo el mundo. Saber desde el primer momento que no eres infalible, y lo que es más, que no pasa nada y que es habitual que suceda es también muy saludable. Además es bastante acongojante que no lo sepamos ya, pero es increíble  la cantidad de personas que no son conscientes de que se pueden equivocar, incluso se van a equivocar seguro.
• Proporciona un mapa de como va a discurrir el proyecto. Esto depende un poco de como lo plantees, porque a la hora de definir el detalle de lo que incluimos o no en el proyecto la cosa puede quedar un poco, digamos deficiente. Yo lo que he empezado a hacer últimamente es complementar la inception con unas sesiones de «Story Mapping» para tener un mapa más concreto de por donde vamos a ir. No me voy a liar a explicar la técnica (más sobre Story Mapping), quizá otro día.
• Permite empezar más o menos igual a todos. Un problema con el enfoque tradicional de recogida de requisitos es que después los ingenieros ya lo tenemos todo solucionado en nuestra cabeza (entre otras cosas porque es el objetivo), no existe el diseño emergente y es cuasi-imposible meter baza en como lo vamos a solucionar, aunque la propuesta sea buena. Si nos pillas un poco desprevenidos somos más receptivos a propuestas, aunque nuestra mentalidad hace que nos pongamos un poco nerviosos por ponernos a hacer cosas sin tener todos los puntos sobre las íes. Esto no deja de ser realmente curioso, porque luego lo normal es cambiar todos esos puntos de sitio, pero si no están sentimos un estremecimiento en la fuerza.

También hay algunos puntos en los que hacemos cosas un poco distintas… dadas nuestras distintas circunstancias 🙂

• Normalmente cuando hacemos esto, el proyecto se va a hacer. En principio no existe la posibilidad de no hacerlo. Digo en principio porque para mi si existe la posibilidad de que no se haga, si el resultado de la inception nos dice que no es recomendable, o al menos de replantearnos cosas, esta parte si, esta no. Esto difiere un poco del planteamiento original, cuando la inception es clave en saber si el proyecto se lleva a cabo o no.
• Tampoco hacemos valoraciones económicas, lo cual simplifica el proceso, porque es un tema delicado. Cuando me llega, el proyecto ha sido ya tasado económicamente (perspectiva guapa, ¿eh?) y hacemos lo que podemos. Normalmente el tiempo y el dinero han sido fijados, pero podemos jugar con el alcance y si la cosa va bien no suele haber problemas con estirar un poco el tiempo, lo cual nos da posibilidades para casar las cosas de manera satisfactoria.
• Normalmente a estas alturas ya tenemos incluso el equipo conformado (aunque con posibilidades de ser modificado en función de las necesidades), asiste todo el mundo a la inception. A veces el equipo de desarrollo no aporta demasiado, pero recibe un montón y sólo asistir le involucra mucho en el proyecto.
• Algunas cosas no las hago, como diseñar la caja de producto. Aunque veo valor en diseñar la caja del producto, la verdad es que me parece una dinámica a la que se le ve poco valor, me suelo quedar en proponer las ventajas y un eslogan.

Dicen que es una reunión muy cara porque tiene que asistir mucha gente importante, y cuesta dinero tenerles juntos durante mucho tiempo. Yo diría que sale relativamente barata, porque minimiza muchos riesgos y maximiza la posibilidad de éxito. Es un argumento ganador, porque si no estás de acuerdo no tengo muy claro el sentido de hacer una reunión muy cara que no sirve, aunque si puede existir en algunos ámbitos dificultad para justificarla.

En resumen, una manera de comenzar con un proyecto de manera ágil, que nos permite consensuar objetivos, alcance (aunque sea a muy alto nivel), compartir conocimiento en torno al proyecto y en definitiva, dar el banderazo de salida intentando al menos que todos esperemos cosas parecidas en un rango de tiempo similar.

Si estás interesado la técnica aparece descrita en el Agile Samurai, y existe otro libro dedicado exclusivamente a la técnica: Agile Inceptions.

Actualización:

Me apuntan en los comentarios un par de enlaces interesantes:

Be code – Le petit inception

Be code – Le petit inception II