¿Cuantas hijas/versiones debo mantener?

En software es fácil tener muchas versiones de un mismo producto, las peticiones del cliente y el reducido coste de actualizar nos hace que podamos tener fácilmente varias versiones en producción de un mismo producto.

Crear, mantener y gestionar estas versiones puede ser tan laborioso como tener descendencia.

Una versión funcionando en un cliente es como una hija:

  • Has tenido que parirla y eso cuesta
  • Has tenido que darle un buen trabajo (Instalándola en los clientes)
  • Si tiene algún problema te llamará y tu eres el responsable de ayudarla
  • A una hija/versión no puedes abandonarla
  • Cuantas más hijas/versiones distintas tengas en producción más difícil será “mantenerlas todas”
  • Cuantas más versiones, más te costara “identificarlas”. Ponles nombres
  • En reyes (cambio legal en la aplicación), tendrás que hacerle un regalo a todas 😉
  • Cuantas más hijas/versiones, más posibilidades que te salga alguna rebelde

Ten pocas y buenas hijas/versiones, te darán menos guerra y entrareis todos en casa en Nochebuena.

Lo que el cliente no pide, pero exige

En desarrollo de software es habitual que los usuarios pidan más y más funcionalidades, si fuera por ellos una aplicación crecería en “sus” funcionalidades hasta el infinito.

Pero por otro lado el cliente asume que la aplicación será rápida, estable y segura, pero eso no se suele pedir, se asume que es así.

Muchos de los trabajos relacionados con la calidad de tu software, son trabajos ocultos para el usuario, pero que son igual o más importantes que añadir más funcionalidad.

Es labor de todo el equipo dedicarle tiempo a la calidad del producto, ya que llegado un momento nuestra deuda técnica es tan grande que empezamos a sufrir distintos problemas relacionados con la falta de calidad.

Todos estos trabajos relacionados con añadir más calidad a nuestro producto deben ir incluidos en cada una de nuestras iteraciones, no debe ser un trabajo puntual cuando las cosas vayan mal.

¿Cuál es tu ciclo de desarrollo? (release cycle)

Escaleras que nos ayudan a subirLa salida de una versión de un producto de software suele ser el punto final de un gran trabajo, pero el principio para muchos otros. Por este motivo, es importante tener claro y transmitir al equipo interno y los usuarios como es nuestro ciclo de desarrollo. De esta manera nadie tendrá falsas expectativas respecto al qué y el cuándo.

Nuestro ciclo de desarrollo debe aclarar al menos :

  1. Duración del ciclo de desarrollo completo.
  2. Numeración de las versiones a publicar.
  3. Tipos de versiones que aparecerán en cada ciclo (Beta, RC, Final, Parche, etc.)
  4. Condiciones que se darán para la salida de cada tipo de versión.
  5. Entregables que tendremos en cada tipo de versión.
  6. Definir cuando esa versión no tendrá más mantenimiento o soporte.

1. Duración del ciclo de desarrollo

Totalmente relacionado con las iteraciones que hagas en tu compañía. El tiempo depende de cada producto o empresa, pero es importante tenerlo definido y no cambiarlo para no confundir a ninguno de tus stakeholders

2. Numeración de las versiones

Durante la vida de una aplicación existirán muchas versiones y es importante que todos sepamos identificarlas para conocer que cambios tiene respecto al resto de versiones.

3. Que aparecerá en cada ciclo

En cada ciclo de desarrollo, generalmente, aparecerán distintos tipos de versiones:

  • Una versión beta para probar las novedades y poder distribuir entre usuarios más expertos.
  • Una versión release candidate con la supuesta versión final (Antes de los últimos detalles)
  • Una versión final que se distribuirá entre todos los usuarios.
  • Unos posibles parches que arreglarán problemas una vez publicada la versión final.

No todos los productos funcionan igual ni necesitan todos estos tipos de versión.

4. Condiciones que se darán para la salida de cada tipo de versión

Esto hace referencia especialmente a los “parches”, debemos definir cuando y como saldrán los parches. No todos los cambios de nuestro software tienen porque generar un parche, en general solo los errores graves o que rompen una funcionalidad anterior deben convertirse en un parche. Publicar un parche tiene un coste operativo alto, en muchos casos con incluir ese cambio en el siguiente ciclo de desarrollo es suficiente.

5. Entregables que tendremos en cada tipo de versión

Cada tipo de versión es un mundo, en algún caso el entregable es un .zip o una url (beta), en otro son una url, instalable, pdf, documentación, vídeo, post, traducciones, etc.
Hacer un checklist de lo que incluye cada tipo de versión ayuda a preparar todo lo que liberaremos en cada parte del ciclo de desarrollo.

6. Definir cuando una versión no tendrá más mantenimiento o soporte.

Todas las versiones tienen un tiempo de vida, no podemos permitirnos dar soporte y mantenimiento a todas las versiones que han aparecido durante toda vida de una forma indefinida. Este tiempo pueden ser años y todos los stakeholders deben conocer este tiempo para saber cuando tienen para actualizarse a nuevas versiones.

Enlaces a información de ciclos de desarrollo de distintas aplicaciones :

Release Cycle de Confluence
Mcafee release cycle
Ciclo de desarrollo de Velneo
Blender Relase Cycle
Release Cycle de Fedora

Checklist para un cambio tecnológico en la empresa

En las empresas suele ser habitual tener que hacer todo tipo de cambios para adaptarse a las diferentes situaciones. En especial los cambios de herramientas tecnológicas.
Lo más importante es saber en todo momento que es un cambio que afecta a personas y que en muchas ocasiones poco importa lo bueno o lo mala que sea la herramienta. La palabra clave para el cambio se llama comunicación. Es necesaria mucha comunicación, es mejor en exceso que en defecto.

Por la experiencia de los últimos cambios tecnológicos en los que he estado involucrado he creado este checklist

1. Conocer la nueva herramienta y probarla

Es importante tener claro que la nueva herramienta es la más adecuada para la empresa y deberemos hacer las pruebas necesarias para no tener sorpresas de última hora.

2. Conocer las fortalezas y debilidades de la herramienta que vamos a sustituir

Debemos conocer la herramienta que vamos a sustituir o el proceso que vamos a quitar. Todo lo que desconozcas de ella podrá ser utilizado en tu contra 😉

3. Comunicar las intenciones y las motivaciones del cambio

A las personas les gusta conocer los porqués, si se hace el cambio es por algún motivo. Esta fase es muy importante ya que es donde ganamos aliados

4. Aclarar dudas con los detractores y personas clave

Siempre tendrás personas con dudas, que no les gusta el cambio. Algunas estarán molestas porque no les consultaste o porque se enteran a última hora. Es importante hablar con todos ellos y que se sientan escuchados. En muchos casos te aportarán información importante que no has tenido en cuenta.

5. Formación a todos

La formación es la excusa perfecta para que todos se imaginen el cambio. El primer paso para aceptar un cambio es imaginarte a ti mismo con el cambio realizado. La formación nos ayuda a sacar a las personas del día a día para que se puedan imaginar una vez realizado el cambio.

6. Comunicar que ya queda poco y que estarás personalmente para ayudar

A todo el mundo le gusta saber que estarás allí y que si hay problemas podrás ser totalmente accesible. Es importante transmitir seguridad. Serás el socorrista de la piscina, no importa si sabes nadar o no, lo importante es que estés atento.

7. Cambio gradual

Siempre que puedas busca la posibilidad de implantar la nueva herramienta de forma gradual, primero 2 usuarios, luego 10,  luego 100. Siempre salen detalles o elementos no previstos que puedes ir solucionando tranquilamente cuando el cambio afecta a pocos usuarios

8. Pedir confirmación de que el cambio ha ido bien y si hay algún detalle pendiente

Algún usuario puede estar mal a gusto con el cambio y no transmitirlo directamente, suele ser muy efectivo pedir confirmación del cambio y enterarte de los pequeños flecos que puedan quedar.