El versionado de software es el proceso de asignación de un nombre, código o número

único, a un software para indicar su nivel de desarrollo.

Generalmente se asigna dos números, mayor.menor (en inglés: major.minor), que van
incrementando conforme el desarrollo del software aumente y se requiera la asignación de un
nuevo nombre, código o número único. Aunque menos habituales, también puede indicarse
otro número más, micro, y la fase de desarrollo en que se encuentra el software.
Se aumenta el número cuando:

 mayor: el software sufre grandes cambios y mejoras.

 menor: el software sufre pequeños cambios y/o correcciones de errores.
 micro: se aplica una corrección al software, y a su vez sufre pocos cambios.
 fase: se indica si se encuentra en una fase de desarrollo que no sea la final o estable, es
decir, una fase inestable o en pruebas. Se suele indicar con un guion seguido de
la fasecorrespondiente en minúsculas, o un espacio seguido de la fase. Puede haber
varias versiones de una misma fase, para indicar el avance en el desarrollo del software
pero manteniendo la fase para indicar que todavía es inestable, indicándose añadiendo un
número al final del nombre de la fase que va incrementando conforme se publiquen
nuevas versiones de esta fase.

INTEGRACION CONTINUA

La integración continua es una práctica de desarrollo de

software mediante la cual los desarrolladores combinan los cambios en el
código en un repositorio central de forma periódica, tras lo cual se
ejecutan versiones y pruebas automáticas. La integración continua se
refiere en su mayoría a la fase de creación o integración del proceso de
publicación de software y conlleva un componente de automatización (p.
ej., CI o servicio de versiones) y un componente cultural (p. ej., aprender
a integrar con frecuencia). Los objetivos clave de la integración continua
consisten en encontrar y arreglar errores con mayor rapidez, mejorar la
calidad del software y reducir el tiempo que se tarda en validar y publicar
nuevas actualizaciones de software.

Anteriormente, era común que los desarrolladores de un equipo

trabajasen aislados durante un largo periodo de tiempo y combinasen los
cambios en la versión maestra una vez que habían completado el
trabajo. Este proceso por lotes hacía que la combinación de todos los
cambios en el código resultase complicada y llevase mucho tiempo. Esto
se agravaba cuando numerosos errores leves se acumulaban durante
mucho tiempo sin que se arreglasen. La combinación de estos factores
hacía que resultase más difícil proporcionar las actualizaciones a los
clientes con rapidez.

Con la integración continua, los desarrolladores envían los cambios de

forma periódica a un repositorio compartido con un sistema de control de
versiones como Git. Antes de cada envío, los desarrolladores pueden
elegir ejecutar pruebas de unidad local en el código como medida de
verificación adicional antes de la integración. El servicio de integración
continua detecta los envíos al repositorio compartido y crea y ejecuta de
forma automática pruebas de unidad en los cambios en el código para
detectar al instante cualquier error funcional o de integración.

La integración continua se refiere a la fase de creación y pruebas de

unidad del proceso de publicación de software. Cada revisión enviada
activa automáticamente la creación y las pruebas.

Con la entrega continua, se crean, prueban y preparan automáticamente

los cambios en el código y se entregan para la fase de producción. La
entrega continua amplía la integración continua al implementar todos los
cambios en el código en un entorno de pruebas y/o de producción
después de la fase de creación.

PRUEBAS UNITARIAS
Las pruebas unitarias o Unit testing, forman parte de los diferentes
procedimientos que se pueden llevar a cabo dentro de la metodología ágil.
Son principalmente trozos de código diseñados para comprobar que el
código principal está funcionando como esperábamos. Pequeños test
creados específicamente para cubrir todos los requisitos del código y
verificar sus resultados.

El proceso que se lleva a cabo, consta de tres partes. El Arrange, donde se

definen los requisitos que debe cumplir el código principal. El Act, el proceso
de creación, donde vamos acumulando los resultados que analizaremos. Y
el Asert, que se considera el momento en que comprobamos si los
resultados agrupados son correctos o incorrectos. Dependiendo del
resultado, se valida y continúa, o se repara, de forma que el error
desaparezca.
 Características de las pruebas unitarias

 Automatizable; Aunque los resultados deben ser específicos de cada test

unitario desarrollado, los resultados se pueden automatizar, de forma que
podemos hacer las pruebas de forma individual o en grupos.
 Completas; El proceso consta de pequeños test sobre parte del codigo, pero
al final, se debe comprobar su totalidad.
 Repetibles; En el caso de repetir las pruebas de forma individual o grupal, el
resultado debe ser siempre el mismo dando igual el orden en que se
realicen los test, los tests se almacenan para poder realizar estas
repeticiones o poder usarlos en otras ocasiones.
 Independientes; Es un código aislado que se ha creado con la misión de
comprobar otro código muy concreto, no interfiere en el trabajo de otros
desarrolladores.
 Rápidos de crear; a pesar de lo que muchos desarrolladores opinen, el
código de los tests unitarios no debe llevar más de 5 minutos en ser creado,
están diseñados para hacer que el trabajo sea más rápido..

Ventajas de pruebas unitarias

1. Proporciona un trabajo ágil; Como procedimiento ágil que es, te permite

poder detectar los errores a tiempo, de forma que puedas reescribir el
código o corregir errores sin necesidad de tener que volver al principio y
rehacer el trabajo. Puesto que las pequeñas se van haciendo
periódicamente y en pequeños packs. Disminuyendo el tiempo y el coste.

2. Calidad del código; Al realizar pruebas continuamente y detectar los

errores, cuando el código está terminado, es un código limpio y de calidad.

3. Detectar errores rápido; A diferencias de otros procesos, los tests

unitarios nos permiten detectar los errores rápidamente, analizamos el
código por partes, haciendo pequeñas pruebas y de manera periódica,
además, las pruebas se pueden realizar las veces que hagan falta hasta
obtener el resultado óptimo.

4. Facilita los cambios y favorece la integración; Los tests unitarios, nos

permiten modificar partes del código sin afectar al conjunto, simplemente
para poder solucionar bugs que nos encontramos por el camino. Los tests
unitarios, al estar desglosados en bloques individuales permiten la
integración de nuevas aportaciones para hacer un código más complejo o
actualizarlo en función de lo que el cliente demande.

5. Proporciona información; Gracias al continuo flujo de información y la

superación de errores, se puede recopilar gran cantidad de información para
evitar bugs venideros.

6. Proceso debugging; Los Tests unitarios ayudan en el proceso de

debugging. Cuando se encuentra un error o bug en el código, solo es
necesario desglosar el trozo de código testeado. Esta es uno de los motivos
principales por los que los tests unitarios se hacen en pequeños trozos de
código, simplifica mucho la tarea de resolver problemas.

7. El diseño; Si primero se crean los tests, es mucho más fácil saber con
anterioridad cómo debemos enfocar el diseño y ver qué necesidades
debemos cumplir. Testeando una pieza del código, también puedes saber
que requisitos debe cumplir, y por eso mismo te será mucho más fácil llegar
a una cohesión entre el código y el diseño.

8. Reduce el coste; Partiendo de la base que los errores se detectan a

tiempo, lo cual implica tener que escribir menos código, poder diseñar a la
vez que se crea y optimizar los tiempos de entrega, vemos una clara
relación con una reducción económica.

Es necesario saber que las pruebas unitarias por sí solas, no son perfectas,
puesto que comprueban el código en pequeños grupos, pero no la
integración total del mismo. Para ver si hay errores de integración es
necesario realizar otro tipo de pruebas de software conjuntas y de esta
manera comprobar la efectividad total del código.

Esperamos que este artículo te haya servido de ayuda y si tenias alguna

duda sobre la implementación de este tipo de tests la hayamos resuelto.

Retrospectiva
Retrospectiva (del latín: retrospectare) es una enumeración y celebración de eventos ya
ocurridos, y normalmente organizada y presentada al final del año, en algún medio de difusión
(generalmente televisión o radio),12 aunque también puede abarcar un período mayor del
anual.3
El término también puede hacer referencia a la carrera4 de un artista o a un resumen de vida
de una persona, por ejemplo, donde se presenta a grandes rasgos la obra artística de
un pintor en la inauguración de una exposición,5 o las actividades de un cineasta o de
un actor o de un caricaturista en oportunidad de un determinado aniversario o de un
homenaje.6 En festivales de cine o en aniversarios, también es usual presentar imágenes del
homenajeado desde su infancia en adelante, repertoriando en forma gráfica sus actividades
más importantes.
En televisión, las emisoras usualmente presentan programas periodísticos especiales hacia el
fin de cada año, señalando los eventos importantes ocurridos durante dicho período.
En Brasil por ejemplo, la Rede Manchete oportunamente realizó los programas Documento
Especial: Televisão Verdade (1989-1991), así como 24 Horas (1994-1997) y Câmera
Manchete (1993-1998).

Desarrollo de software
Este término también se aplica a la ingeniería de software, en cuyo marco una retrospectiva
refiere a una reunión cuando se ha finalizado un proyecto o se está cerca de finalizarlo, y que
trata sobre los aciertos y errores del mismo, su proyección y posibilidades a futuro, las
enseñanzas que pueden extraerse de este emprendimiento, etc.
Una exposición retrospectiva puede ser planificada y desarrollada en muchos modos
diferentes. El Agile Retrospective Resource Wiki12 es un buen recurso para compartir
proyectos, pautas y trucos, instrumentos e ideas, para así tratar de sacar el máximo partido
posible de las exposiciones retrospectivas.
Cuando se aplica el llamado desarrollo ágil de software, las exposiciones retrospectivas
juegan un rol muy importante respecto del desarrollo iterativo e incremental. En efecto, al final
de cada iteración, una exposición retrospectiva es cumplida buscando específicamente modos
de mejorar el proceso para la siguiente iteración. En el marco del Scrum, se llama a esto
"Exposición retrospectiva del Sprint (o período en el cual se lleva a cabo el desarrollo de la
iteración)".

Leyes y normativas[editar]
En estos casos, el término se aplica en situaciones donde la ley o la normativa cambia,
haciendo que un acto antes considerado legal sea ahora ilegal (o viceversa), o provocando un
cambio importante en una norma.
Un ejemplo de una norma retrospectiva o retroactiva vigente, es el Código Internacional de
Nomenclatura Zoológica (ICZN), que es la convención que gobierna el nombramiento formal
científico de animales, de los cuales la 4a edición es aplicable desde el año 2000. Todas las
ediciones anteriores del Código de ICZN, u otras reglas y convenciones anteriores, no tienen
ninguna fuerza más hoy día, y no son aplicables.13
Documento Especial 1989 en portugués: Televisão
Verdade (presentador: Ronaldo Rosas)[editar]
Programa: Documento Especial - Retrospectiva 1989 (08 / diciembre / 1989)

 O presidente José Sarney foi inaugurado o Memorial da América Latina, em São Paulo.
 A grande festa da cerimônia de entrega do Globo de Ouro, Oscar e Grammy.
 O estadista Saddam Hussein foi retirada da União Soviética no Afeganistão.
 Na primeira eleição direta depois da instalação no Brasil, Fernando Collor de Mello.
 A Copa América que o Brasil quebrou o jejum de 19 anos sem títulos sub-americanos.
 A holandesa Angela Visser é eleita do Miss Universo.
 Movimento da desigualdade na Fundação da Cidade Baiana de Adustina, em terra
políticos corruptos.
 Flashes, escândalos, brigas, segredos, decepções e alegrias que marcaram 89.

La retrospectiva es la última reunión en una iteración de Scrum, el momento de cierre del

sprint que está terminado. Es un momento de análisis y reflexión del pasado, pero también es
un encuentro del cual tienen que salir decisiones y acciones para el futuro. Y sin embargo, es
común dejar que las retrospectivas sean "una reunión más", y desperdiciemos así una de las
mejores oportunidades para aprender, crecer y mejorar nuestro trabajo en equipo.

¿Para qué hacer una retrospectiva?

Las retrospectivas son un concepto de años en el desarrollo de software (y en cualquier otro
ámbito, de hecho), que Scrum formaliza y ubica como reunión al finalizar cada iteración de
desarrollo. En Scrum, la retrospectiva es el último evento del sprint y hace un vínculo
entre el sprint que termina y el que está por empezar: en la retrospectiva el equipo analiza
el pasado y planea su futuro. Pero no piensa su futuro en términos del proyecto en particular,
sino con un enfoque más amplio: durante la retrospectiva el equipo reflexiona cómo trabaja.

Así como las prácticas técnicas hacen foco en el producto (integración continua, pruebas
automatizadas, demostraciones frecuentes, etc.), la retrospectiva es la herramienta que
hace foco en el equipo, analizando cómo trabajamos y nos relacionamos, y buscando
soluciones reales que el equipo mismo pueda aplicar.

El objetivo de una retrospectiva es mejorar: mejorar la productividad, mejorar los

conocimientos y habilidades del equipo, mejorar la calidad del producto... en última
instancia, el objetivo de una retrospectiva es mejorar la calidad de vida de quienes
participan.

Las 5 etapas de una retrospectiva

Todas las retrospectivas pasan por 5 etapas, aunque a veces no sean formales. Es bueno
tener en cuenta estas etapas y ser conscientes de que deben ocurrir: si se saltea alguna
etapa, o si la misma no ocurre de forma efectiva, no llegaremos al mejor resultado posible de
la retrospectiva. Y en el peor de los casos, terminaremos con una reunión más,
desaprovechada.

Entonces, las 5 etapas de una retrospectiva son:

1. Preparar el escenario
2. Recolectar datos
3. Reflexionar
4. Decidir qué hacer
5. Cerrar la retrospectiva

1. Preparar el escenario
El inicio de la retrospectiva ocurre con la "Preparación del escenario", un evento de 5-10
minutos en donde se da inicio a la reunión y marcará el rumbo de la retrospectiva.

En esta etapa se deberá presentar la persona que llevará la retrospectiva. Esta persona
puede ser alguien del mismo equipo o un participante externo; en caso de ser miembro del
equipo, no es necesario que sea siempre el mismo, y hasta sería deseable que se vaya
rotando con el tiempo. Quien guía la retrospectiva es una única persona, y sus
responsabilidades son:

 armar la agenda y las actividades para cada etapa de la retrospectiva

 llevar y coordinar la charla
 controlar el tiempo
 cerrar y documentar
Cuando se inicia la preparación, el presentador deberá recordar cuánto tiempo dispone el
equipo para la retrospectiva (el cual dependerá según la duración del sprint; por ejemplo, 1
hora para un sprint de 2 semanas). A su vez, deberá ir controlando el tiempo a medida que
avance la reunión, recordándole al equipo cuánto tiempo falta, y ajustando las actividades
acorde.

Una vez hecho esto, se deberá presentar el objetivo de la retrospectiva. El objetivo lo

determina quién guiará la retrospectiva, con consultas previas al equipo. Tiene que ser un
objetivo amplio y que, a la vez, sirva para darle foco a las actividades y reflexiones que salgan.
Por ejemplo, algunos objetivos válidos podrían ser:

 buscar formas de mejorar nuestras prácticas

 descubrir qué estamos haciendo bien
 entender porqué no cumplimos con el compromiso del sprint
 buscar formas de mejorar nuestra flexibilidad con el cliente
 reconstruir relaciones dañadas
Estos son algunos ejemplos, los cuales obviamente varían de acuerdo al contexto del equipo.
La idea es plantear distintos enfoques para la retrospectiva, y salir del clásico "mejora continua
del proceso": es un objetivo válido, pero después de un par de retrospectivas sería bueno
aplicar otro enfoque.

2. Recolectar datos
Esta es la etapa donde el equipo hablara sobre hechos, sin juzgarlos. La idea es llegar a un
acuerdo sobre los eventos que ocurrieron durante la iteración, y tener así una base común
sobre la cual reflexionar luego y sacar conclusiones.

En esta etapa, los miembros del equipo deberán presentar hechos que ocurrieron durante
la iteración, eventos que consideren relevantes. Por ejemplo, se pueden presentar:
 historias terminadas
 historias no terminadas
 impedimentos
 decisiones que se tomaron
 reuniones
 métricas varias (velocidad, cantidad de bugs, cobertura de código, etc.)
 eventos
 emociones de los miembros
Además de hechos tangibles, quien lidera la retrospectiva puede decidir que los participantes
presenten emociones que ellos mismos hayan sentido durante algún momento (por ejemplo,
"me enojé durante la reunión X", o "me asusté con la decisión Z").

3. Reflexionar
Aquí es donde comienzan a aparecer las ideas, los posibles caminos a recorrer. Durante la
reflexión el equipo analiza los hechos y busca responderse dos preguntas básicas:

 ¿por qué pasó lo que pasó?

 ¿cómo mejorar?
El equipo empieza a tener ideas sobre cómo poder seguir avanzando, no perdiendo de vista
las consecuencias que cree generarán los cambios.

Es aquí donde se empieza a comprender cómo los eventos, comportamientos y circunstancias

afectan al trabajo del equipo desarrollando software.

4. Decidir qué hacer

Este es un momento crucial en la retrospectiva, y representa el compromiso del equipo para
actuar a futuro. El equipo deberá armar un plan de acción para concretar alguno de los
experimentos planteados en la reflexión.

Las acciones que el equipo decida tomar deben poder llevarse adelante por ellos mismos:
esperar que otras personas actúen por el equipo es un camino seguro a la frustración.

Es importante evitar las retrospectivas de "hacer nada", porque pierden justamente el sentido
de la reunión: las retrospectivas son para experimentar, para buscar mejoras y seguir
progresando. Siempre hay algo que mejorar, y la retrospectiva es el espacio seguro para
buscar cómo avanzar.

5. Cerrar la retrospectiva
Durante la retrospectiva el equipo trabajó mucho, realizó varias actividades y generó un
compromiso y plan de acción para el próximo sprint. Debemos guardar todo el trabajo hecho
durante la retrospectiva. Por ejemplo:

 registrar en una wiki la decisión tomada

 sacar fotos de las actividades
 sacar fotos al pizarrón
Lo esencial del cierre es que todos los miembros del equipo se retiren con acciones concretas
y experimentos para aplicar durante la próxima iteración.