Decálogo VIII: Toda la información en la tarea

El octavo punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Cada tarea recogida en el gestor de tareas debe contener toda la información para realizar el traspaso».

Como hemos comentado en otros puntos no siempre una tarea se pone en producción nada más terminada, que es cuando tienes fresco lo que has hecho. También hay que tener en cuenta que si algo va mal en un traspaso cuanta más información tengas recogida de forma accesible más fácil va a ser recordar que es lo que si hizo y porque.

Es por ello que en el gestor de tareas en cada tarea hay que recoger la información necesaria para poder reconstruir la tarea.

He tenido compañeros muy diligentes que se apuntaban en la libretita todos los ficheros que iban cambiando y todo lo que iban haciendo. Me parece genial esa actitud, pero lo que les decía a esos compañeros es que si en vez de hacerlo en su libretita, que solo la conoce la persona, si lo haces, exactamente el mismo trabajo, en el gestor de tareas queda recogido para cualquiera que tenga que continuar esa tarea.

Estuve en un proyecto en el que en un periodo de tiempo muy corto tuvimos dos bajas médicas inesperadas de una cierta duración, que nos hizo un roto muy grande, ya que el equipo no era muy amplio, así que una baja de una persona suponía una perdida grande.

Si no llega a ser porque teníamos todo recogido en el gestor de tareas y otra persona pudo retomar el trabajo, ciertamente con dificultades, pero muchas menos de las que hubiese tenido si no lo hubiésemos tenido todo recogido.

Decálogo VII: Traspasos parciales

El séptimo punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Se debe poder realizar traspasos parciales de un proyecto».

A veces pasa,que una vez preparado un traspaso, alguna tarea no funciona bien y hay que quitarla. Aunque no debiera de suceder en muchas ocasiones, porque significaría que algo no funciona en nuestro proceso, a veces pasa y hay que estar preparado.

Hay que estar preparado para este tipo de contingencias y tener definido cual es el procedimiento que se va a seguir. Quitar el código de la tarea de la etiqueta del repositorio, ya que esa tarea no va a ir y actualizar el estado de la tarea en el gestor de tareas.

Decálogo VI: Automatización

El sexto punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Los traspasos entre entornos deben estar automatizados completamente o realizarse lanzando un script o similar, nunca manualmente moviendo ficheros».

Todas las reglas anteriores están bien, pero tenemos que tener un mecanismo que nos asegure que hacemos las cosas bien, es decir que si queremos reproducir el traspaso no vamos a hacerlo en las mismas condiciones. Si dejamos pasos manuales es posible que alguien con prisas o que no conozca bien el procedimiento no lo realice bien y por ejemplo traspase ficheros de su ordenador, sin que estén en el repositorio.

Aparte de tener la seguridad de que hacemos las cosas bien también nos interesa el que el  proceso sea lo más rápido posible.

Es por ello que debemos buscarnos automatismos. Bien desde sencillos scripts de shell (en caso de Linux) hasta herramientas como AntHillPro o Jenkins

Decálogo V: Todas las tareas deben estar recogidas en el gestor de tareas

El quinto punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Todas las tareas deben estar recogidas en el gestor de tareas».

El motivo de este punto es el saber en cada traspaso que es lo que se ha enviado, para ello debemos tener recogido en el gestor de tareas todas aquellas tareas que se traspasan, o que deben ser realizadas para poner el producto.

Esto nos permitirá saber en caso de problema todo lo que realizamos para poner ese desarrollo en producción.

Hay proyectos en los que nada más se termina una incidencia se pone en producción, pero hay otros proyectos en los que esto no es así. Yo he estado en alguno. Nunca entendí el motivo de no poner algo hecho en producción hasta bastante después de haberlo terminado (y hablo de meses).

Industrialización del Software: Manual del paracaidista III

Ya vamos avanzando en poner orden y tomar el control de la situación. Con los dos pasos anteriores ya debieras de tener lo más importante controlado. Que la aplicación haga lo que tiene que hacer.

Ahora, a mi modo de ver, debieras de empezar a mirar un poco los temas internos. Para mi lo primero a controlar es el código. Por eso es lo primero en el decálogo.

Es vital que tengas el control del código fuente, sino vas a tener problemas. Créeme, he estado en sitios en los que se ha perdido código y no es una situación agradable.

Debieras de organizar el repositorio de tal forma que te permita automatizar la compilación. Aunque no lo hagas al principio de todo, en algún momento querrás optimizar el proceso productivo y la automatización es esencial. Además el automatizar te garantizará que lo que tienes en el repositorio es lo correcto, y que están todos los ficheros que necesitas.

En este punto casi se podría seguir el orden del decálogo. Siempre adecuando las prioridades a lo que en el proyecto en el que estés veas que es más sangrante.

Atar en corto a los compañeros o no…

Uno de los principales factores para que un proyecto vaya bien es el factor humano. La industrialización del desarrollo de software se puede apoyar en herramientas y procedimiento o normativas, pero al final lo que marca la diferencia es la gente.

Hay metodologías como el scrum que propugnan el crear equipos pequeños y darles libertad, pero anteponen una condición que me parece sustancial: ten gente buena.

Ahí es donde creo que radica la cuestión. Si tienes gente buena las cosas suelen salir bien sin mucho esfuerzo, sino es mucho más complicado. El problema es que normalmente todo el mundo cree que es buena en lo suyo. Otra cosa es que lo sea.

Soy un ferviente defensor del dar libertad a los compañeros, pero con criterio. Es decir, dar el grado de libertad que cada uno pueda asumir sin pegarse un batacazo grande. Pequeños sustillos controlados no está mal que se lleve la gente, así ven donde están sus límites y van ampliando progresivamente su zona de confort.

Yo he estado en creo que casi todas las situaciones. Tanto en las de dar libertad a compañeros bajo mi responsabilidad, tanto compañeros competentes como no competentes. Y por supuesto he tenido jefes que me han dado más o menos libertad.

Alguno no sabia delegar y te daba muy poca cuerda y otros si que sabían delegar y valoraban bien las posibilidades que les podía aportar, así que lo único que hacían era supervisar que no me pegase un castañazo muy grande. También tuve un jefe que tenia un curioso concepto de lo que era un pequeño sustillo… mejor no pensar que sería para el un gran susto…

Decálogo IV: Trazabilidad

El cuarto punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Las incidencias que se envían corregidas en el traspaso deben estar etiquetadas en el gestor de tareas con un número idéntico al número identificador del traspaso».

El objetivo de este punto es poder asegurarse que sabemos en cada traspaso que cambios de código implica, que lo tenemos con el punto tercer, y saber cada traspaso que incidencias resuelve. Para ello deberemos tener una correlación entre el contenido del repositorio y el contenido del gestor de tareas que utilicemos.

Decálogo III: Etiquetar todo

El tercer punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Los ficheros que se traspasan deben estar etiquetados en el repositorio de código con un número único identificador del traspaso.«

A la hora de realizar un traspaso, sobre todo cuando va a haber diferentes versiones es imprescindible el etiquetar en el repositorio que es lo que se envía en cada uno de ellos. De esta forma si hay algún problema podremos comparar el código y detectar fácilmente los cambios.

Así mismo si tenemos que realizar un parche podremos recurrir rápidamente a la etiqueta.

Hay que hacer una mención en este punto de etiquetar al punto anterior de construir el proyecto desde el repositorio. Obviamente si queremos tener la seguridad de que lo que hemos enviado es lo etiquetado, tenemos que construir el proyecto desde el contenido etiquetado, no desde la rama general.

Decálogo II: El entregable se genera desde el repositorio

El segundo punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «El contenido del traspaso se genera a partir del contenido del repositorio de código y solo desde el repositorio de código.«

En el primer punto hemos fijado que todo fichero necesario para la construcción del proyecto debe estar albergado en el repositorio. Pero de nada sirve esto si luego a la hora de generar el producto a entregar no nos aseguramos que este producto se construye desde el contenido del repositorio.

El asegurar este punto hace que podamos confiar en que el contenido del repositorio es el correcto, es decir lo que se ha entregado, y no es una versión que está en el ordenador del responsable del traspaso.

Hay que recalcar especialmente el apartado de solo desde el repositorio de código, sino estaríamos contraviniendo el primer punto, ya que habría contenido que no está en el repositorio.

Veremos en sucesivos puntos como hacer para tener esta seguridad.

Decálogo I: Sobre la localización de los ficheros.

El primer punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Lo que no está en el repositorio de código no existe«.

El motivo es muy simple, si algún fichero no está recogido en el repositorio de código es muy fácil que se pueda llegar a perder, bien por borrado accidental bien por rotura del soporte. O bien que no se pueda encontrar porque, aunque exista, no se sepa donde está. De cualquiera de las dos forma es como si no existiese, bien porque se ha perdido, bien porque no se encuentra.

En este aspecto lo mejor es tener un planteamiento claro y simple de donde están los ficheros necesarios para generar una versión del programa. Y ese sitio debe ser el repositorio.

El tener un repositorio de código nos permitirá:

  • Tener una política de backups más sencilla, ya que el contenido está centralizado.
  • Nos evitará el tener que andar buscando donde está un determinado fichero, porque debe estar en el repositorio.
  • Nos permitirá tener diferentes versiones de un fichero.
  • El tener definido un criterio sobre donde se encuentran los ficheros y cual es su organización nos permitirá ponerlo por escrito y hacerlo público para conocimiento del resto de compañeros involucrados.

He visto proyectos en los que se ha perdido código y no es una experiencia gratificante. Deja una sensación de incompetencia entre los propios afectados que no es agradable.

Hay diferentes opciones dentro de los repositorios de código, tales como Git, SVN, Rational Tem Concert y otras muchas más.