diff --git a/_posts/20201-06-21-story-points.md b/_posts/20201-06-21-story-points.md
new file mode 100644
index 0000000..2eed84d
--- /dev/null
+++ b/_posts/20201-06-21-story-points.md
@@ -0,0 +1,239 @@
+---
+title: Story points
+category: foundations
+layout: post
+---
+
+# Story points
+Los *story points* son una técnica de estimación ágil que le brinda una estimación relativa de cuánto trabajo y esfuerzo se dedicará a una tarea en particular.
+
+## ¿Qué es Agile?
+Agile es un enfoque de gestión de proyectos que se ha utilizado ampliamente en el desarrollo de software para la entrega de proyectos. Se basa en desglosar todo el proyecto en ciclos de desarrollo más cortos (llamado iteración o sprint), que dura solo alrededor de 2-4 semanas.
+
+El objetivo principal de la [metodología ágil](https://clickup.com/blog/agile/agile-project-management/) es involucrar a los clientes en cada paso del proceso de desarrollo.
+
+## ¿Como hace eso?
+
+Al final de cada iteración, se desarrolla una versión de su producto llamada *iteración*. Presenta esta *iteración* a los clientes para recibir sus comentarios y mejorar el proceso.
+
+Luego, incorpore esta retroalimentación en su próximo proceso de planificación de iteración y repita hasta que tenga un producto final.
+
+## ¿Qué son los *story points*?
+Antes de hablar sobre qué es un story point, debemos comprender dos términos: "*historia de usuario*" y "*product backlog*".
+
+* Una historia de usuario es una explicación informal de las funciones que su usuario desea en el sistema. Un ejemplo de historia de usuario del mundo real es: "Como jugador, quiero que mi héroe pueda volar".
+
+* Una *product backlog* contiene una lista de cada historia de usuario en la que se debe trabajar e implementar en el producto final.
+
+Un *story point* es una unidad asignada a una historia de usuario para expresar cuánto tiempo y energía se requeriría para ese trabajo.
+
+Es como el nivel de dificultad de un juego. Un número más alto significa un nivel más difícil.
+
+Sin embargo, aquí es donde la mayoría de la gente se equivoca. En un videojuego, el nivel 2 no significa necesariamente que sea el doble de difícil que el nivel 1. Pero ese no es el caso en los story points.
+
+Los story points son una técnica de estimación relativa (también llamada tamaño relativo).
+
+La estimación relativa significa que los valores se asignan sobre una base de comparación. Eso significa que no hay unidades estándar para los story points.
+
+Por ejemplo, si una historia de usuario A tiene un punto 2 y la historia de usuario B tiene un story point: 1, significará que A requerirá el doble de esfuerzo en comparación con completar B. Por lo tanto, los story points tienen una similitud: puntos de referencia.
+
+Por ejemplo, digamos que dos equipos están construyendo dos juegos móviles de rompecabezas similares. El nivel 10 en el primer juego de rompecabezas no sería necesariamente tan difícil como el nivel 10 en el segundo juego de rompecabezas, ¿verdad?
+
+De manera similar, su equipo podría asignar un valor de story points de 8 a una historia de usuario, y otro equipo puede hacer una estimación de puntos de 13 puntos a una historia similar. El valor de los story points depende totalmente de tu equipo y tu tarea.
+
+Los story points te permiten calcular la velocidad del equipo y estimar el trabajo de manera objetiva.
+
+## Valores de print points
+1, 2, 3, 5, 8, 13, ...
+
+### ¿Qué entra en un Story Point?
+Los métodos ágiles como XP ("Programación extrema") y Scrum tienen una fase de planificación para que los miembros del equipo de desarrollo discutan cada elemento de la lista de trabajos pendientes priorizados y estimen colectivamente el esfuerzo involucrado para completar, y luego hagan un pronóstico de Sprint que describa cuánto trabajo puede lograr el equipo dentro del Sprint. La estimación del esfuerzo colectivo es donde entran los story points. Los story points representan el esfuerzo general requerido para implementar completamente un elemento de la cartera de productos o cualquier otro trabajo. En la literatura de Scrum, el esfuerzo es una construcción de múltiples facetas que consiste en riesgo, complejidad y repetición.
+
+![esfuerzo en Scrum](/wiki/assets/img/esfuerzo.png)
+
+Debido a que los story points representan el esfuerzo por desarrollar una tarea, la estimación de un equipo debe incluir todo lo que pueda afectar el esfuerzo. Eso podría incluir:
+- La cantidad de trabajo por hacer
+- La complejidad del trabajo
+- Cualquier riesgo o incertidumbre en la realización del trabajo. Debe considerar las dependencias que pueda tener mientras trabaja, estas pueden ser tanto internas (es decir, una MS desarrollada por otra persona y de la que no tiene conocimiento previo) tanto como externas (es decir, una integración de terceros como Auth0)
+
+Al realizar estimaciones con story points, asegúrate de considerar cada uno de estos factores. Veamos cómo afecta cada uno a la estimación de esfuerzo proporcionada por los story points.
+
+### Considere todo lo necesario para que una tarea se considere *hecha*
+El story point estimará todo lo que involucre finalizar una tarea, desde su inicio hasta que se considere finalizada
+
+- Documentación (si es necesario)
+- Pruebas (pruebas unitarias, de integración)
+- Pull requests 
+
+## Se puede calcular la velocidad del equipo
+La [velocidad de su equipo](https://clickup.com/blog/agile/velocity-chart/) es una métrica importante que simplemente no se debe ignorar.
+
+Al calcular la velocidad del equipo, así puede visualizar:
+
+* Eficiencia del equipo ágil
+* Velocidad a la que progresa el equipo ágil
+* Puede hacer mejores predicciones para el cronograma de sus proyectos futuros.
+
+### Velocidad
+La velocidad (también llamada velocidad de sprint) muestra la cantidad de trabajo que se ha realizado en cada sprint. Es el total de story points completados divididos por el número total de sprints.
+
+Por ejemplo, digamos que su equipo termina 50 story points en 2 sprints.
+
+Entonces, su velocidad de sprint será (50/2) = 25 puntos por sprint.
+
+## Estimación sin compromisos de tiempo específicos
+Las cosas no siempre salen según lo planeado, incluso en un proyecto ágil.
+
+Y cuando utiliza una estimación de tiempo, solo especifica un tiempo aproximado. Es posible que dedique más tiempo a tareas que pensó que se completarían en un santiamén y viceversa.
+
+La conclusión es que es difícil estimar la cantidad precisa de tiempo necesario para una tarea técnica.
+
+Dado que los story points son un método de estimación ágil, no hacen un compromiso definitivo (como dentro de una semana o el próximo viernes). En cambio, brindan una estimación relativa del esfuerzo general que se dedicará a una tarea.
+
+Esto ayudará a reducir el estrés innecesario de cumplir con plazos ajustados y poco realistas. En cambio, se queda con una estimación mucho más razonable y precisa.
+
+## Los story points no son subjetivos
+A veces, las personas difieren en sus estimaciones de cuánto tiempo llevará una tarea en un proyecto Agile. Esto a menudo conduce a la subjetividad al utilizar estimaciones de tiempo.
+
+Es por eso que este enfoque no siempre proporciona una estimación precisa.
+
+Por ejemplo, un desarrollador senior puede asignar una tarea "7 horas" de acuerdo con su estándar, pero al desarrollador junior le puede llevar 15 horas completar esa misma tarea. ¡No se puede comparar a un jugador novato con un programador profesional!)
+
+Mientras calcula un story point, todo el equipo se sienta junto y decide qué puntos asignar a la historia del usuario.
+
+## Factores clave que afectan los story points
+### ¿Cuánto trabajo se necesita hacer? (tamaño de la historia)
+No todos los elementos de que estan pendientes por realizar son iguales; un elemento puede requerir más trabajo que otro.
+
+Por ejemplo, suponga que hay dos elementos de la lista de trabajos pendientes diferentes:
+
+* Quiero una nueva arma para el héroe principal.
+* Quiero nuevas armas para todos los héroes.
+
+¿Cuál crees que llevará más tiempo?
+
+¡La segunda historia, por supuesto! Comparado con este, la primera historia no requerirá mucho trabajo.
+
+Entonces, la segunda historia obtendrá más puntos que la primera debido al mayor tamaño de la historia.
+
+### Riesgo e incertidumbre
+Cada proyecto tiene sus riesgos e incertidumbres, especialmente con ciertos tipos de elementos de la lista de pendientes.
+
+Por ejemplo: si el elemento pendiente implica trabajar con una nueva tecnología con la cual que su equipo no tiene mucha experiencia, ese factor de riesgo aumentará el valor de los story points.
+
+### Complejidad
+La complejidad es definitivamente un factor muy importante para cualquier técnica de estimación ágil. Aquí hay dos historias similares con diferentes criterios de aceptación:
+
+* "Quiero un disfraz nuevo para el personaje de Geralt"
+* "Quiero un nuevo ataque especial para Geralt"
+
+El primero es pan comido, solo algunos retoques aquí y allá y ¡listo !. El segundo requiere que codifiques un nuevo ataque especial y veas cómo funciona en el juego. Luego, tendrás que probar si hay errores.
+
+Naturalmente, durante el proceso de estimación del esfuerzo, estas historias de usuarios claramente ganan más puntos.
+
+## ¿Cómo se calculan los story points en la metodología Agile?
+Puede calcular los story points creando una historia base, eligiendo su escala y técnica de estimación, y luego calculando en consecuencia.
+
+La estimación de los story points generalmente se realiza mediante un método llamado "el póquer de planificación".
+### Prepara la mesa de póquer (crea una historia base)
+El primer paso de la técnica de estimación es crear una historia de referencia o una historia base.
+
+Es una historia de usuario completa de un ciclo de iteración anterior asignado con un valor de story point (generalmente 1 por simplicidad).
+
+Este será su story point normalizado. La nueva lista de pendientes también se presenta con todas las nuevas historias de usuarios.
+
+### Reparte las cartas (elige una escala para la estimación)
+Hay dos escalas que se utilizan para la estimación de story points:
+
+- Escala lineal: contiene números naturales como 1, 2, 3, etc.
+- Escala de Fibonacci: números de la serie de Fibonacci como 1, 2, 3, 5, 8, etc.
+En aras de la simplicidad, la mayoría de los equipos ágiles tienden a elegir la serie Fibonacci para su estimación de story points.
+
+En esta técnica de estimación, la escala de Fibonacci se inserta en una tabla donde puede asignar un valor a cualquier historia de usuario.
+
+Así es como se ve una tabla de estimación cuando el equipo comienza a completarla:
+![tabla de story points](/wiki/assets/img/sprint_points.png)
+
+### Planning poker
+El planning Poker es una técnica de estimación ágil que se centra en el consenso general. Esta técnica de estimación también se utiliza para estimar cosas distintas a los story points del usuario.
+
+Durante esta reunión de estimación ágil:
+
+* Cada estimador recibe un conjunto de tarjetas que contienen números de la escala de Fibonacci.
+* Se presenta un elemento del backlog a la vez y los estimadores tienen una discusión detallada al respecto.
+* Una vez finalizada la discusión, cada estimador selecciona una tarjeta con un número de Fibonacci.
+* Todos revelan su carta juntos (como en el póquer, todas las cartas sobre la mesa).
+* Si todas las estimaciones coinciden, se asigna el valor.
+* Si no coinciden, los estimadores analizan más para llegar a un consenso.
+
+Al final del póquer de planificación, nuestra mesa estará llena de historias de usuarios junto a sus puntos asignados.
+
+Espere que la matriz de estimación de story points se vea así:
+
+![tabla de story points completada](/wiki/assets/img/sprint_points_full.png)
+
+`Aviso importante!`
+
+Muchas veces cuando un equipo no está sincronizado, la persona que tomará una tarea tendrá la última palabra sobre el número de story points que se le asignará, recuerde que la práctica lo hace perfecto y nadie debe obligarlo a tener el mismo ritmo también si está comenzando con un nuevo equipo.
+
+La técnica de story points te permite a ti y a tus equipos llegar a ser técnicamente iguales cuando pasa el tiempo y es una técnica muy flexible.
+
+### Calcular la velocidad del equipo y planificar el cronograma del proyecto
+Después de la reunión de estimación, el [sprint backlog](https://clickup.com/blog/sprint-backlog/) se crea, después de una sesión de refinamiento del backlog el equipo comenzará a trabajar en las historias.
+
+Esta metodología Agile lo ayuda a realizar un seguimiento del desempeño del equipo y hacer mejores pronósticos. Una vez finalizado el primer sprint, hay una [reunión retrospectiva](https://clickup.com/blog/scrum-meetings/). Esto le proporciona los datos para calcular la velocidad del equipo (el número de story points completados durante un sprint).
+
+Una vez que obtenga la velocidad del sprint, puede determinar cuántos sprints necesitará su equipo de proyecto para completar todo el proyecto. Si su proyecto Agile tiene una estimación de story points con un total de 480 y su velocidad real es 48, entonces puede calcular que su equipo necesitará 10 sprints para completar todo el proyecto. Esto facilita la planificación de la programación de su proyecto ágil.
+
+## Formas de estimar los story points
+El esfuerzo estimado en un Sprint es un concepto latente, el significado no se puede observar ni medir directamente, a diferencia de conceptos observables como temperatura y distancia. Por lo tanto, no es sorprendente ver visiones diferentes, incluso contradictorias, sobre cómo se debe estimar el esfuerzo, particularmente si los story points deben ser una función del tiempo.
+
+Debido a las diferentes opiniones sobre el story point y los pasos subdefinidos para estimar, no es sorprendente observar varios métodos utilizados para estimar el story point en la práctica.
+
+### Utilice la primera historia como punto de referencia
+Asigne un número para la primera historia. Cualquier otra historia de este Sprint se comparará con la primera historia. Los Sprints futuros repetirán este proceso y se alinearán en la misma escala. Por ejemplo, si una historia tiene aproximadamente la misma cantidad de trabajo que la que ya ha dimensionado, dele la misma cantidad de puntos. Está claro que la estimación del esfuerzo se realiza de forma relativa.
+#### Pros
+
+* El cerebro humano es bueno para comparar y por lo tanto, este método tiene una carga cognitiva menor.
+* Dado que solo es necesario comparar con la primera historia, la estimación es relativamente liviana en el procesamiento cognitivo y eficiente en el tiempo.
+* Independientemente del tiempo de desarrollo, este método recompensa a los miembros del equipo por resolver problemas y centrarse en la entrega de valor.
+* Los story points están en la escala de intervalo y son significativos en suma, resta y medio. La escala de intervalo es suficiente para el cálculo de la velocidad.
+
+#### Contras
+* El punto inicial asignado a la primera historia es totalmente arbitrario. Aunque el valor no importa, ya que todos los puntos siguientes se asignan relativamente, el punto inicial y la historia sí importan cuando configuran la escala del sistema de story points.
+* Aunque es fácil comparar los esfuerzos entre tareas, es difícil medir la magnitud de la diferencia ya que los valores numéricos no pertenecen a nada directamente medible / observable.
+* Este método no se traduce de los story points al tiempo requerido para completar y, por lo tanto, no pudo responder una pregunta común de las partes interesadas: ¿cuánto tiempo se completará la tarea A?
+
+
+### Tallas de camiseta
+Utilice varios tamaños, como extrapequeño (XS), pequeño (S), mediano (M), grande (L) y extragrande (XL) para estimar el esfuerzo en un nivel alto. Cada tamaño corresponde a un valor de la secuencia de Fibonacci, p. Ej. XS - 1, S - 2, M - 3, L - 8, XL - 13.
+#### Pros
+* Dado que proporciona una estimación rápida y aproximada de la cantidad de trabajo que se espera para un proyecto, es eficiente en el tiempo.
+* Independientemente del tiempo, este método recompensa a los miembros del equipo por resolver problemas y centrarse en la entrega de valor.
+
+#### Contras
+* No está claro cómo el riesgo, la complejidad y la repetición se atribuyen a la estimación del tamaño y, por lo tanto, es difícil lograr consistencia en el tiempo.
+* La naturaleza de los distintos tamaños de camiseta está ordenada por categorías, correspondientes a la escala ordinal. Al convertir a la secuencia de Fibonacci como story points, la asignación de valor es arbitraria. Alguien puede cuestionar fácilmente por qué se asigna un tamaño a un valor en lugar de a otro.
+* La suma, la resta y el promedio de los story points no son significativos, p. Ej. ¿La diferencia de esfuerzo entre una historia de tamaño mediano y una historia de tamaño pequeño es una historia de tamaño extrapequeño? ¿Qué significa la velocidad como 20 story points, p. Ej. dos historias grandes y dos pequeñas?
+* Este método no se traduce de los story points al tiempo requerido para completar y, por lo tanto, no pudo responder una pregunta común de las partes interesadas: ¿cuánto tiempo se completará la función A?
+
+Nota: Algunos otros métodos se refieren a esfuerzos diferentes a los tamaños de camiseta, como animales y ositos de goma. Básicamente, son la misma idea.
+
+### Usar horas o días ideales
+Este método es de la metodología XP. Para cada historia, el equipo de entrega analiza cuántos días u horas ideales requiere. El día u hora ideal, usando la secuencia de Fibonacci, puede basarse en el tiempo promedio que necesita un desarrollador o el tiempo que necesita un desarrollador promedio. Para determinar cuándo se puede terminar una función, podemos usar un factor de carga (es decir, un día ideal equivale a 3 días reales) o un porcentaje (es decir, supongamos que en un día solo tenemos el 70% del tiempo para hacer el trabajo real) para Convierta los días u horas ideales en reales.
+
+#### Pros
+* El uso de horas o días ideales para estimar el esfuerzo promueve los story point en la escala de proporción. Esto permite una comparación significativa entre los story points de varias formas, como suma, resta, multiplicación, división, medio, etc. Por ejemplo, una historia con story points como 8 significa 4 veces más difícil de completar que una historia con story points como 2. La escala de razón también permite producir cualquier métrica de interés, p. Ej. métricas de error.
+* La medida del esfuerzo está más definida y es más fácil de explicar.
+* Los tres aspectos del esfuerzo se pueden capturar fácilmente con el tiempo.
+* Puede generalizar directamente los tiempos medios necesarios para tareas específicas, p. Ej. 2 días ideales para redactar pruebas, o 5 días ideales para documentación,
+
+#### Contras
+* Los humanos no son buenos para estimar el esfuerzo en el tiempo, ya que estamos inclinados a sobreestimar nuestra capacidad y por lo tanto a subestimar los días u horas ideales necesarios.
+* La gerencia puede mantener las horas o los días contra el equipo de entrega sobre por qué el desarrollo se atrasó.
+
+
+## Fuentes
+* Peck H., C.(Noviembre 2020). *The Ultimate Guide to Agile Story Points(2020)*, ClickUp. https://clickup.com/blog/agile/agile-story-points/
+* Fan S. C.(07 Enero 2021). *Best Way to Estimate Effort Using Story Points in Sprint Planning*, Serious Scrum. Medium. https://medium.com/serious-scrum/best-way-to-estimate-effort-using-story-point-in-sprint-planning-f43ad2d6fa91
+
diff --git a/_posts/2021-06-21-versionado-y-uso-de-branches.md b/_posts/2021-06-21-versionado-y-uso-de-branches.md
new file mode 100644
index 0000000..136490d
--- /dev/null
+++ b/_posts/2021-06-21-versionado-y-uso-de-branches.md
@@ -0,0 +1,329 @@
+---
+title: Versionado y uso de branches 
+category: foundations
+layout: post
+---
+
+# Versionado y uso de branches 
+
+## ¿Para qué?
+En desarrollo es necesario tener un lugar centralizado en donde se almacenan los proyectos que se desarrollan disponibles para cualquier developer teniendo un historial de cambios con responsables asignados.
+
+## ¿Qué areas lo necesitan?
+- Equipo de desarrollo (FrontEnd, BackEnd, Data Análisis)
+- Producción
+- Devops
+
+## Repositorios
+Es usual que las empresas usen herramientas de versionado como lo son GitHub y GitLab, pero además de usar estas herramientas, es necesario tener buenas practicas en el nombrado de los proyectos, así como del uso de branches. Abajo se expone algunos ejemplos de como usar el nombrado de repositorios:
+
+| Name | Descripción |
+| :---: | :---: |
+| Versión  | `Números: V1, V2, V4, etc ` >> `Core del negocio: Administración, Finanzas, Cobros` >> `Por años: 2021, 2020, 2019, etc.` >> `O bien una forma creativa usando nombres propios o acronimos: anaconda, boa, zebra, yak` |
+| Tipo  | `ms - Microservicio` > `fn - Lambda Function (Azure Function)` > `fw - Framework` > `back - Backend` > `front - Frontend` > `npm - Librería para npm` > `nuget - Librería para nuget` > `int - integración con otra aplicación` > `mig - migraciones de otras aplicaciones` |
+| Descripción del proyecto | Descripción breve del nombre del proyecto. En algunos casos puede incluir el módulo al que corresponde. Siempre-va-separado-por-guiones-medios |
+
+De esta manera, un ejemplo para un microservicio que se encarga de crear y manejar pendientes, que será usado en un ERP, pordría llamarse de la siguiente manera:
+> erp-ms-pending-items
+
+## Branches
+
+Dentro del sistema de control de versiones distribuido (DVCS) para llevar el flujo de trabajo y código así como el control de las liberaciones necesitamos llevar un proceso organizado.
+
+Para esto de los repositorios centrales (origin) deberán existir branches con una nomenclatura y rol específicos, facilitando varios aspectos como el trabajo asincrono y paralelo del equipo, visibilidad del estado de desarrollo de los features, etc.
+
+### Branches principales
+
+El repositorio principal siempre tendrá estos 2 los cuáles tienen en común que nunca mueren (como José  José): Master y Develop.
+
+#### Master
+
+Aquí sólo se encuentra código que está **listo para producción** por lo que es la versión estable de todos los proyectos de un producto.
+
+*Quién usa estas ramas:*
+- Branches que nacen de master
+- Branches que se unen a master
+- Enviroments que despliegan usando master
+
+#### Develop
+
+Aquí se encuentra el código que tiene los ultimos cambios para el siguiente release, cuando los cambios que se encuentran en este branch son validados y se encuentran en un estado estable deben de ser unidos a master por medio de un nuevo release.
+
+*Quién usa estas ramas:*
+- Branches que nacen de develop
+- Branches que se unen a develop
+- Enviroments que despliegan usando develop
+
+#### Feature
+
+Estos branches son utlizados para desarrollar los nuevos features de los proyectos. Tienen un ciclo de vida definido el cual acaba hasta que se finaliza el feature en el cual se está trabajando. La forma de nombrar estos branches deberá de respetar el patrón **feature/<feature-name/id>.** Para unir un branch de feature a develop deberá hacerse por medio de un PR.
+
+*Quién usa estas ramas:*
+- Branches que nacen de feature/*
+- Branches que se unen a feature/*
+- Branches de los que nace feature/*
+- Branches a los que se une feature/*
+- Enviroments que despliegan usando feature/*
+
+#### Release
+
+Estos branches son usandos para preparar una liberación a producción, aquí se pueden resolver **PEQUEÑOS** bugs/features que se detecten **antes de la liberación** así como actualizar la información del proyecto como versión, cambios (changelog) y documentación. **Estas operaciones son realizadas aquí para liberar develop para que allí se unan los nuevos cambios que servirán para el próximo release.**
+
+El momento de crear este branch es cuando está lo suficientemente estable y con los features necesarios para la siguiente liberación, el criterio para colocar el número del release se expondrá más abajo.
+
+La nomenclatura a seguir para este branch es la siguiente **release/x.x.x**
+
+*Quién usa estas ramas:*
+- Branches que nacen de release/*
+- Branches que se unen a release/*
+- Branches de los que nace release/*
+- Branches a los que se une release/*
+- Enviroments que despliegan usando release/*
+
+#### Fix
+Estos branches son utlizados para desarrollar fix pequeños dentro de los proyectos, que pueden surgir del feedback provisto por QA al hacer la revisión de un nuevo feature o bien un fix de una funcionalidad que ya esta en producción que no es bloqueante o bien es una mejora en un flujo, para optimizaciónes o sugerencias del usuario. Tienen un ciclo de vida definido el cual acaba hasta que se finaliza el fix en el cual se está trabajando. La forma de nombrar estos branches deberá de respetar el patrón **fix/<fix-name/id>.** Para unir un branch de fix a develop deberá hacerse por medio de un PR.
+
+*Quién usa estas ramas:*
+- Branches que nacen de fix/*
+- Branches que se unen a fix/*
+- Branches de los que nace fix/*
+- Branches a los que se une fix/*
+- Enviroments que despliegan usando fix/*
+
+#### Hotfix
+
+Este branch es usado cuando un error se presenta en producción (código que está en master) y necesita resolverse inmediatamente. Se usa para aislar el bug de master y no afectar el trabajo del equipo que esta agregando y desarrollando los features para el siguiente release en develop. Sigue la misma mecánica que los de release así que se tiene que actualizar la información del proyecto (versión del proyecto, changelog, actualización de documentación)
+
+La nomenclatura a seguir para este branch es la siguiente **hotfix/x.x.x**
+
+*Quién usa estas ramas:*
+- Branches que nacen de hotfix/*
+- Branches que se unen a hotfix/*
+- Branches de los que nace hotfix/*
+- Branches a los que se une hotfix/*
+- Enviroments que despliegan usando hotfix/*
+
+### Versionado
+
+#### ¿Por qué?
+
+Debido a que en una empresa se tienen varios proyectos que tienen muchas dependencias tenemos que tener un control para versionar nuestros productos de forma que con sólo leer la versión podamos identificar el estatus de un proyecto.
+
+Este sistema es un estándar llamado **[Semantic Versioning 2.0.0](https://semver.org/)** usa 3 números los cuáles se usan de esta forma.
+
+> MAJOR.MINOR.PATCH
+
+#### Major
+
+Este es usado para indicar cambios que son incompatibles con versiones anteriores.
+
+Por ejemplo el proyecto A usa como dependencia la versión 1.10.2 de B, si quiere usar la versión 2.0.1 de B, deberá de hacer los cambios pertinentes antes, ya que es seguro que varías cosas cambien lo cuál generaría bugs.
+
+#### Minor
+
+Es usado para indicar que nuevos features fueron agregados y que son compatibles con versiones anteriores.
+
+Por ejemplo el proyecto A usa como dependencia la version 1.10.2 de B, si quiere usar la versión 1.11.0 de B no debería de tener que realizar ningún cambio a menos que quiera implementar los nuevos features de la versión
+
+#### Patch
+
+Es usado para indicar bugs que fueron reparados y que son compatibles con versiones anteriores.
+
+Por ejemplo el proyecto A usa como dependencia la version 1.10.2 de B, si quiere usar la versión 1.10.3 de B no debería de tener que realizar ningún cambio a menos que quiera implementar los nuevos features de la versión
+
+![versioning-standar](/wiki/assets/img/versioning.png)
+
+#### Reglas
+
+1. Un número de versión normal deberá tomar la siguiente estructura:  X.Y.Z donde  X, Y, y  Z son números enteros positivos, y no deberpa contener ceros a la izquierda. X corresponde al `major` versión, Y es the `minor` versión, y Z la `patch` versión. Cada elemento deberá ser incremental, por ejemplo: 1.9.0 -> 1.10.0 -> 1.11.0.
+2. Una vez que se ha hecho release de los cambios, ** el contenido de esa versión NO DEBE modificarse. Cualquier modificación DEBE ser lanzada como una nueva versión.**
+3. La versión principal cero (0.y.z) es para el desarrollo inicial. Cualquier cosa PUEDE cambiar en cualquier momento. ** La API pública NO DEBE considerarse estable.**
+4. La versión 1.0.0 define la API pública. La forma en que se incrementa el número de versión después de esta versión depende de esta API pública y de cómo cambia.
+5. La versión del parche Z (x.y.z | x> 0) DEBE incrementarse si y solo si **se introducen correcciones de errores compatibles con versiones anteriores **. Una corrección de errores se define como un cambio interno que corrige un comportamiento incorrecto.
+6. La versión secundaria Y (x.Y.z | x> 0) DEBE incrementarse si se introduce una nueva funcionalidad compatible con versiones anteriores en la API pública. DEBE incrementarse si alguna funcionalidad de API pública está marcada como obsoleta. PUEDE incrementarse si se introducen nuevas funciones o mejoras sustanciales dentro del código privado. PUEDE incluir cambios de nivel de parche. ** La versión del parche DEBE restablecerse a 0 cuando se incrementa la versión secundaria.**
+7. La versión principal X (X.y.z | X> 0) DEBE incrementarse si ** se introducen cambios incompatibles con versiones anteriores en la API pública **. También PUEDE incluir cambios menores y de nivel de parche. ** El parche y la versión secundaria DEBEN restablecerse a 0 cuando se incrementa la versión principal. **
+8. Una versión preliminar PUEDE indicarse agregando un guión y una serie de identificadores separados por puntos inmediatamente después de la versión del parche. Los identificadores DEBEN incluir sólo alfanuméricos ASCII y guión [0-9A-Za-z-]. Los identificadores NO DEBEN estar vacíos. Los identificadores numéricos NO DEBEN incluir ceros iniciales. Las versiones preliminares tienen una precedencia menor que la versión normal asociada. Una versión preliminar indica que la versión es inestable y es posible que no satisfaga los requisitos de compatibilidad previstos según lo indica su versión normal asociada. Ejemplos: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
+9. Los metadatos del release PUEDEN indicarse agregando un signo más y una serie de identificadores separados por puntos inmediatamente después del parche o la versión preliminar. Los identificadores DEBEN incluir sólo alfanuméricos ASCII y guión [0-9A-Za-z-]. Los identificadores NO DEBEN estar vacíos. Los metadatos de compilación DEBEN ignorarse al determinar la precedencia de la versión. Por lo tanto, dos versiones que solo difieren en los metadatos de compilación tienen la misma precedencia. Ejemplos: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.
+10. La precedencia se refiere a cómo se comparan las versiones entre sí cuando se ordenan. La precedencia DEBE calcularse separando la versión en identificadores principales, secundarios, de parche y de versión preliminar en ese orden (los metadatos de compilación no tienen prioridad). La precedencia está determinada por la primera diferencia al comparar cada uno de estos identificadores de izquierda a derecha de la siguiente manera: Las versiones principales, secundarias y de parche siempre se comparan numéricamente. Ejemplo: 1.0.0 <2.0.0 <2.1.0 <2.1.1. Cuando mayor, menor y parche son iguales, una versión preliminar tiene menor precedencia que una versión normal. Ejemplo: 1.0.0-alpha <1.0.0. La precedencia de dos versiones preliminares con la misma versión principal, secundaria y de parche DEBE determinarse comparando cada identificador separado por puntos de izquierda a derecha hasta que se encuentre una diferencia de la siguiente manera: los identificadores que constan de solo dígitos se comparan numéricamente y los identificadores con las letras o los guiones se comparan léxicamente en el orden de clasificación ASCII. Los identificadores numéricos siempre tienen menor precedencia que los identificadores no numéricos. Un conjunto más grande de campos de prelanzamiento tiene mayor precedencia que un conjunto más pequeño si todos los identificadores anteriores son iguales. Ejemplo: 1.0.0-alpha <1.0.0-alpha.1 <1.0.0-alpha.beta <1.0.0-beta <1.0.0-beta.2 <1.0.0-beta.11 <1.0.0- RC.1 <1.0.0.
+
+![semver](/wiki/assets/img/semver.png)
+
+
+### Changelog
+
+En conjunto con el sistema de versiones cada proyecto debe de tener un registro de cambios (a.k.a) changelog, aquí debemos de tener una lista con los cambios ordenados cronológicamente.
+
+Esto nos servirá para que cualquier miembro del  equipo pueda visualizar los cambios que ha tenido el proyecto en cada versión y consultar si necesita hacer algo adicional para consumir el proyecto/dependencia.
+
+#### ¿Cómo lo hago?
+
+- Están hechos *para los seres humanos*, no para las máquinas.
+- Debe haber una entrada para cada versión.
+- Los mismos tipos de cambios deben ser agrupados.
+- Versiones y secciones deben ser enlazables.
+- La última versión va primero.
+- Debe mostrar la fecha de publicación de cada versión.
+- Indicar si el proyecto sigue el [Versionamiento Semántico](https://semver.org/).
+- Cada versión se escribe a manera de título, acompañado por la fecha del release: `[v1.5.10] - 2021-06-21`
+- Mientras no se libere un release con la nueva versión, los cambios se sumen a la próxima liberación se pueden colocarse con la etiqueta: `[Unreleased]`
+
+#### Tipos de cambios
+
+- `Added` para funcionalidades nuevas.
+- `Changed` para los cambios en las funcionalidades existentes.
+- `Deprecated` para indicar que una característica o funcionalidad está obsoleta y que se eliminará en las próximas versiones.
+- `Removed` para las características en desuso que se eliminaron en esta versión.
+- `Fixed` para corrección de errores.
+- `Security` en caso de vulnerabilidades.
+- `Unreleased` para llevar los cambios que se aplicarán en el siguiente release
+
+#### ¿Qué no debemos hacer?
+
+- Tener información erronea o desactualizada
+- Si hacemos un breaking change, debemos de estar conscientes de que la documentación debe de estar actualizada, así como una guía que explique como migrar entre versiones.
+
+#### Ejemplo
+
+```
+# Changelog
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [1.0.0] - 2017-06-20
+### Added
+- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
+- Version navigation.
+- Links to latest released version in previous versions.
+- "Why keep a changelog?" section.
+- "Who needs a changelog?" section.
+- "How do I make a changelog?" section.
+- "Frequently Asked Questions" section.
+- New "Guiding Principles" sub-section to "How do I make a changelog?".
+- Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo).
+- German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4).
+- Italian translation from [@azkidenz](https://github.com/azkidenz).
+- Swedish translation from [@magol](https://github.com/magol).
+- Turkish translation from [@karalamalar](https://github.com/karalamalar).
+- French translation from [@zapashcanon](https://github.com/zapashcanon).
+- Brazilian Portugese translation from [@Webysther](https://github.com/Webysther).
+- Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek).
+- Russian translation from [@aishek](https://github.com/aishek).
+- Czech translation from [@h4vry](https://github.com/h4vry).
+- Slovak translation from [@jkostolansky](https://github.com/jkostolansky).
+- Korean translation from [@pierceh89](https://github.com/pierceh89).
+- Croatian translation from [@porx](https://github.com/porx).
+- Persian translation from [@Hameds](https://github.com/Hameds).
+- Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s).
+
+### Changed
+- Start using "changelog" over "change log" since it's the common usage.
+- Start versioning based on the current English version at 0.3.0 to help
+translation authors keep things up-to-date.
+- Rewrite "What makes unicorns cry?" section.
+- Rewrite "Ignoring Deprecations" sub-section to clarify the ideal
+  scenario.
+- Improve "Commit log diffs" sub-section to further argument against
+  them.
+- Merge "Why can’t people just use a git log diff?" with "Commit log
+  diffs"
+- Fix typos in Simplified Chinese and Traditional Chinese translations.
+- Fix typos in Brazilian Portuguese translation.
+- Fix typos in Turkish translation.
+- Fix typos in Czech translation.
+- Fix typos in Swedish translation.
+- Improve phrasing in French translation.
+- Fix phrasing and spelling in German translation.
+
+### Removed
+- Section about "changelog" vs "CHANGELOG".
+
+## [0.3.0] - 2015-12-03
+### Added
+- RU translation from [@aishek](https://github.com/aishek).
+- pt-BR translation from [@tallesl](https://github.com/tallesl).
+- es-ES translation from [@ZeliosAriex](https://github.com/ZeliosAriex).
+
+## [0.2.0] - 2015-10-06
+### Changed
+- Remove exclusionary mentions of "open source" since this project can
+benefit both "open" and "closed" source projects equally.
+
+## [0.1.0] - 2015-10-06
+### Added
+- Answer "Should you ever rewrite a change log?".
+
+### Changed
+- Improve argument against commit logs.
+- Start following [SemVer](https://semver.org) properly.
+
+## [0.0.8] - 2015-02-17
+### Changed
+- Update year to match in every README example.
+- Reluctantly stop making fun of Brits only, since most of the world
+  writes dates in a strange way.
+
+### Fixed
+- Fix typos in recent README changes.
+- Update outdated unreleased diff link.
+
+## [0.0.7] - 2015-02-16
+### Added
+- Link, and make it obvious that date format is ISO 8601.
+
+### Changed
+- Clarified the section on "Is there a standard change log format?".
+
+### Fixed
+- Fix Markdown links to tag comparison URL with footnote-style links.
+
+## [0.0.6] - 2014-12-12
+### Added
+- README section on "yanked" releases.
+
+## [0.0.5] - 2014-08-09
+### Added
+- Markdown links to version tags on release headings.
+- Unreleased section to gather unreleased changes and encourage note
+keeping prior to releases.
+
+## [0.0.4] - 2014-08-09
+### Added
+- Better explanation of the difference between the file ("CHANGELOG")
+and its function "the change log".
+
+### Changed
+- Refer to a "change log" instead of a "CHANGELOG" throughout the site
+to differentiate between the file and the purpose of the file — the
+logging of changes.
+
+### Removed
+- Remove empty sections from CHANGELOG, they occupy too much space and
+create too much noise in the file. People will have to assume that the
+missing sections were intentionally left out because they contained no
+notable changes.
+
+## [0.0.3] - 2014-08-09
+### Added
+- "Why should I care?" section mentioning The Changelog podcast.
+
+## [0.0.2] - 2014-07-10
+### Added
+- Explanation of the recommended reverse chronological release ordering.
+
+## [0.0.1] - 2014-05-31
+### Added
+- This CHANGELOG file to hopefully serve as an evolving example of a
+  standardized open source project CHANGELOG.
+- CNAME file to enable GitHub Pages custom domain
+- README now contains answers to common questions about CHANGELOGs
+- Good examples and basic guidelines, including proper date formatting.
+- Counter-examples: "What makes unicorns cry?"
+```
+
+## Fuentes
+* Preston-Werner T. y Semver, C.(28 de Junio 2020). *Semantic Versioning 2.0.0*, Semver. https://semver.org/
+* Lacan O. y Fortune T. C.(30 de Abril 2021). *Keep a Changelog*, Keep a Changelog. https://keepachangelog.com/en/1.0.0/
\ No newline at end of file
diff --git a/assets/img/effort.png b/assets/img/effort.png
new file mode 100644
index 0000000..fd3cd4b
Binary files /dev/null and b/assets/img/effort.png differ
diff --git a/assets/img/semver.png b/assets/img/semver.png
new file mode 100644
index 0000000..f97996e
Binary files /dev/null and b/assets/img/semver.png differ
diff --git a/assets/img/sprint_points.png b/assets/img/sprint_points.png
new file mode 100644
index 0000000..0b9bc4d
Binary files /dev/null and b/assets/img/sprint_points.png differ
diff --git a/assets/img/sprint_points_full.png b/assets/img/sprint_points_full.png
new file mode 100644
index 0000000..8b206db
Binary files /dev/null and b/assets/img/sprint_points_full.png differ
diff --git a/assets/img/versioning.png b/assets/img/versioning.png
new file mode 100644
index 0000000..742c6a5
Binary files /dev/null and b/assets/img/versioning.png differ