Política de versionado ejemplos y tips

¿Qué es una política? Introducción

Antes que nada, cuando hablamos de políticas o de una política, estamos queriendo significar un conjunto de reglas que gobierna el objeto al que se hace referencia. Así podemos hablar de políticas de nombres, de versionado, políticas organizacionales, etc. En definitiva son reglas de negocio, pero restringido a un ámbito o temática. Otra vez, al hablar de política de versionado estamos hablando de reglas de negocio de versionado.

Las políticas ayudan y guían tus acciones y decisiones dentro de la organización respecto de la temática que tratan.

La política de empresa es un conjunto de normas o reglas establecidas por la dirección de la misma para regular diferentes apartados del funcionamiento de la empresa. 

En algunos ámbitos la política se define como el criterio o directriz de acción elegida como guía en el proceso de toma de decisiones al poner en práctica o ejecutar las estrategias, programas y proyectos específicos del nivel institucional. Siendo así la política empresarial define previamente como quiere hacer las cosas la organización, en otras palabras se diría coloquialmente: "En esta empresa se hacen las cosas de esta manera", y no importa si la empresa es del mismo rubro, del mismo sector o subsector de mercado, sus políticas pueden ser diversas. 

Politicas de versionado

La política de versionado de un producto determinado (o todos en general) deberá estar formada por un conjunto de reglas que provean a la versión del producto de cierta consistencia e integridad, no dejando fisuras en las que permeen problemas asociados con el versionado.

Podemos hablar a diferentes niveles, así por ejemplo podemos hacer referencia a políticas que afectan de las versiones de productos de software, productos de trabajo, de archivos, etc.

Veamos un ejemplo

Especificaciones de formato de versión 1.0 para el versionado de productos de software de nuestra organización.

V<nro_producto>.<nro-funcional>.<nro-correccion>.<nro-recompilacion>

...

Políticas de versionado dentro de nuestra organización.

1. Cada producto de software utiliza como estructura de versión, la especificación de versión 1.0 para el versionado de productos de software, a partir de 01 de marzo del 2014.
2. Cada nuevo producto se inicia con un número secuencial creciente que comienza con el 1, la primera vez. La asignación es realizada por el Área de ventas. 
3. Cada vez que se crea un producto, todas los secciones de la especificación de versión serán 0, excepto el correspondiente al número del producto. El número de producto se incrementa en uno respecto del último número usado.
4. Cada vez que un producto atiende una solicitud de cambio que agrega, modifica o quita funcionalidad se incrementa en un dígito la sección correspondiente a funcionalidad. A partir de esta sección el resto de las secciones que le continúan se inicializan en 0.
5. Cada vez que se corrige un error, la sección correspondiente a corrección se incrementa en un dígito. El resto de las secciones que le continúan se inicializan en 0.
6. Cada vez que el código se compila, este incrementa en 1 dígito la compilación. Si es la primera compilación. Se pone 0.
7. Independientemente de la cantidad o el tamaño de la funcionalidad siempre se incrementa en 1.
8. De cada versión de producto entregada se guarda una linea base.
9. Se debe especificar para cada versión cual es el corrección y se debe especificar que funcionalidad se agrega, cambia o quita. No se específica porque se compila en forma obligatoria.
10. Gerencia es el sector de la organización que determina la discontinuidad de un producto y su correspondiente congelamiento de versión. A partir de esta decisión el producto de software no evolucionará y tampoco se comercializará.

Tips para la definición de reglas de una política de versionado

1. Cada regla debe ser independiente. Cada regla debe entenderse por si misma.
2. Cada regla tiene un identificador.
3. Preste atención a no poner politicas por que si.
4. Tenga en cuenta de explicitar los valores de las secciones cuyos valores dependen de otras secciones. Ejemplo regla 5
5. Realice “mentalmente” un ciclo de vida de cada sección o grupo de secciones, es decir, evalúe cuando nace, como evoluciona y si puede caducar, agotarse  o volverse obsoleta una sección.
6. Se pragmático y no consuma horas de discusión en cosas que no ocurrirán en el largo plazo, sus políticas se ajustaron en el mediano plazo por otros elementos no tenidos en cuenta. 
7. Las políticas se versionan.
8. Las políticas se auditan.
9. No sea purista, es probable que las políticas contengan elementos que no sean reglas de negocio estrictas, si aportan valor y no generan confusión déjelos

Tareas de Análisis. Características

Introducción

Sin importar la forma que le des al proyecto, ni cual ciclo de vida tomes como base; un proyecto de desarrollo siempre tendrá las tareas de análisis, diseño, codificación y prueba. Son tareas básicas.

Puedes tener motivos y razones super convincentes para negar una actividad básica. Puede suceder que utilices un generador de código y la programación se simplifique, estamos de acuerdo; se consume menos esfuerzo; pero la tarea existe.

La forma que adquiera el proyecto no es nuestro centro. Algunas personas prefieren invisivilizar ciertas tareas, diciendo que no hay diseño, o que no se realiza la prueba. No importa lo que digan. Si no explicitas la prueba te está faltando o esta oculta bajo otro título.

No se debería pasar un producto de software al cliente sin hacer pruebas; no debería comenzarse la programación sin un diseño mínimo. Lo que no se haga donde corresponde quedará en manos del que sigue en un proceso de desarrollo. Si el que sigue es el cliente, bueno es tu riesgo.

Luego según la cultura de tu empresa, de tu equipo o tu región realizarás proyectos en donde algún tipo de tarea destaque sobre otra; siendo, por ejemplo, las pruebas mínimas y de un solo tipo.

En este blog trataremos las características de las actividades básicas. Nuestro centro es la tarea de análisis.

Objetivo

Explicitar las características generales de la tarea básicas de análisis dentro del marco de un proyecto.

Análisis

El análisis es un tarea que puede especializarse en muchas subtareas y muchas formas; pero una característica casi natural es que es una actividad netamente iterativa y cognitiva; estas son las características que la destacan.

Un analista realiza un conjunto de acciones para comprender el sistema bajo estudio, volviendo y una otra vez sobre tareas que parecían terminadas, pero no lo están.

Característica 1. Materialización del producto de trabajo.
Un analista realiza una entrevista y comienza el análisis; como consecuencia descubre omisiones, falta de información y otras yerbas; el resultado volver a realizar una entrevista.

El párrafo anterior muestra que avance pero no produje nuevos artefactos; comencé con una entrevista y por el estado del arte regresé por una nueva entrevista. Es cierto que he avanzado pero no en forma lineal sino iterativa. Continuo relevando el sistema pero con otro conocimiento inicial.

Luego pasaron 2 días y el analista tiene más dudas que productos de trabajo elaborados. Esto es y debe considerarse completamente natural. Lo importante no es documentar el sistema, sino comprenderlo y luego documentar la comprensión. Como sea, pueden pasar varios días de borradores, bosquejos y anotaciones; pero ninguna producción concreta.

Es importante tener presente está característica pues, en una tarea de análisis de una semana es probable que comencemos a ver producción a partir del día 3 o 4; esto es aproximadamente en el 50% del esfuerzo ejecutado. En una tarea de análisis de 15 días se puede comenzar a ver la producción de la documentación cuando la tarea lleva un 20 %, pero no será cerrado hasta un 90%  avanzada su ejecución.

Estas ideas son cuestionables; en el sentido que las personas tienden a tener distintas estrategias de trabajo. Algunos profesionales crean al principio todos los documentos que saben que usarán, lo cual puede parecer que se han desarrollado muchísimos artefactos; pero ninguno está ni siquiera completado con contenido significativo; ver muchos documentos realizados es una falsa presunción de avance en muchos casos.

Característica 2. Cantidad de productos de trabajo
El análisis es una de esas tareas que crea un número interesante de artefactos: listas de requerimientos, reglas de negocio, maquinas de estado, modelos del dominio, tabla de actores, diccionarios de datos.

Mientras que en otro tipo de negocios cada actividad produce un producto de trabajo ( o 2), en el análisis se producen al menos una decena. Algunos ni siquiera estaban planeados...grrrr.

Esta cantidad no es sinónimo de tamaño. Hacer 10 productos de trabajo sobre un total de 20 no significa que se ha realizado el 50 % de la tarea. Si pensabas eso, pues lo siento no es así.

Característica 3. Evolución de productos de trabajo
El análisis tiene eso viste, pensás que estás terminando un producto de trabajo y cuando comenzás (o continuás con) otro; descubrís que estabas errado.

Ey!!!!, no debería decir que la tarea de análisis es una tarea compleja; pues bien lo es.

Ahora bien, la tarea de analisis es de estas tareas que cuando más crees que avanzaste, más seguro estás que no; luego finalmente como por arte de magia, se estabiliza y todo fluye.

Aquí se presentan algunos ejemplos que muestran la evoluciones típicas en la producción de artefactos / productos de trabajo:
Ejemplo 1

Este podría decirse que es el más natural, escasos o nulos artefactos al comienzo de la actividad / tarea y luego de superado el 50 % un crecimiento continuo.
Observe que no se indica el tiempo en números es simplemente una idea de evolución teórica.
Ejemplo 2

En este caso se intenta mostrar que al principio no existen artefactos, pero luego comienza a aparecer hasta alcanzar la totalidad de artefactos que debían crearse. En este fenómeno el analista estuvo un tiempo importante realizando procesos mentales hasta que decidió que el trabajo ya podría comenzar a materializarse. Tiene ciertas semejanzas con el ejemplo anterior.

Ejemplo 3

Aquí se intenta mostrar que se producen una serie de artefactos al principio y el resto al final.
Este es el caso del analista se apresura a crear artefactos pero no completará mucho hasta acercarse al final.

Ejemplo 4

Este caso no es real en el análisis. Aquí se muestra que la producción de artefactos es continua y constante, nada más irreal en la tarea de análisis.

Claro está que no son las únicas evoluciones, pero la intensión es simplemente ejemplificar la idea.

Oportunidad de Mejora

Definición
Denomino oportunidad de mejora a la incorporación, modificación de ciertas cualidades y/o características del negocio y/o sistema que le proveen de una optimización significativa, mejorando algún aspecto del negocio y/o sistema actual.

Las oportunidades de mejora se presentan a lo largo del estudio del sistema al compartir con terceros la visión, los problemas actuales, el objetivo y los requerimientos del sistema de información.

Es muy común que al describir expresiones de deseo encontremos nuevas ideas por el solo hecho de compartir nuestra forma de ver/pensar un sistema, un componente, etc.

La oportunidad de mejora es, parafraseándola, encontrar una mejora a lo que ahora se realiza o se va a realizar.

Las oportunidades de mejora se ven restringidas por posibilidades técnicas o tecnológicas, de costo, de recursos o de tiempos, entre otras.

Ejemplos

1. En un sistema de ventas  con atención en mostrador, podría sugerirse que las personas que son clientes y realizan periódicamente los mismos pedidos, lo hagan por la web. Así la organización tiene dos mecanismos de ventas aumentando las oportunidades del negocio y mejorando la atención de cierto grupo de clientes.

2. Actualmente el sector de ventas realiza presupuestos, los imprime y se los remite por correo tradicional al cliente, previa llamada telefónica.
Hoy el presupuesto podría generarse como un archivo PDF, enviarse por correo electrónico al cliente y si se  posee el celular del responsable se le comunica mediante un SMS del envío.

3. En un negocio pequeño, el tomador de pedidos realiza la solicitud el pedido en forma manual en papel, repitiendo gran cantidad de datos del cliente en cada ocasión que este realiza un pedido. A través de un sistema automatizado ciertos datos ,como los personales, no serían obligatorios cada vez que se realiza la toma de un pedido.

Los ejemplos son numerosísimos... agregá otros....