Bajo el capó: Los procesos detrás de la tecnología en Shoprocket

Este es el primer artículo de una nueva serie donde descubrimos cómo hacemos las cosas en el departamento de tecnología de Shoprocket. Estamos orgullosos de los sistemas y procesos que tenemos en marcha, pero siempre estamos buscando mejorar y desarrollarnos. Así que nos encantaría saber cómo hacen las cosas ustedes.

Hoy, vamos a echar un vistazo a cómo se establece un sprint en Shoprocket.

Realizamos un proceso de sprint de 10 días. Así es como se ve un día promedio para uno de nuestros desarrolladores:

• 4 horas de sprint
• 2 horas de corrección de errores
• 2 horas de tiempo libre

Eso significa que cada desarrollador tiene 40 horas en un sprint para trabajar en sus tareas de sprint. Cada hora equivale a un punto de historia y estos se desglosan de la siguiente manera:

Tamaño de Historia

• pequeño = 5 puntos de historia
• mediano = 10 puntos de historia
• grande = 20 puntos de historia
• extra grande = 40 puntos de historia

Usamos puntos de historia para controlar nuestro burndown y las entregas estimadas. Nunca prometemos una fecha de entrega ya que los humanos son simplemente terribles en esto. En el futuro, planeamos utilizar los metadatos en nuestra herramienta de sprint y unirlos al tamaño de la historia para calcular promedios históricos sobre cuánto tiempo tomó hacer X, ya que es un buen indicador de cuánto tiempo llevará realizar tareas similares. Sin embargo, aún no tenemos esta herramienta, así que si alguien quiere construirla (te estoy mirando, sprint.ly) sería increíble.

En este sprint, fue un asunto bastante simple. Comenzamos arreglando errores y escribiendo actualizaciones del sistema como de costumbre.

Una de esas actualizaciones fue el informe de pedidos. Al ofrecer soporte de línea de artículo, los usuarios ahora pueden ver de qué consta un pedido en lugar de solo ver el total del pedido. A simple vista, esto parece algo muy simple de hacer, pero en realidad, es bastante complicado ya que el informe tiene que ser construido de tal manera que sea compatible con la multitud de paquetes contables que existen. Además, tiene que funcionar con nuestra base de datos completa retrocediendo un año completo y exportar un informe completo en tiempo real en aproximadamente un segundo.

En lo que respecta a la tecnología básica, Winston ha estado trabajando en separar nuestro primer microservicio e integrarlo con nuestra aplicación existente. El que elegimos inicialmente fue un Sistema de Gestión de Sesiones, que es el código que genera un GUID único utilizado durante la vida de un pedido (ya sea completado o abandonado). Vamos a escribir toda una serie sobre nuestra aventura con microservicios, así que no entraremos en demasiados detalles aquí, basta con decir que pasar de un sistema monolítico a microservicios es un desafío pero divertido.

Alex ha estado trabajando en una herramienta de backend para tratar con UTM. Marketing ha estado insistiendo por esta herramienta durante mucho tiempo y estamos maravillados de que algo así no exista actualmente en el mercado (probablemente la haremos de código abierto una vez que esté completa) ya que es una herramienta relativamente simple y muy necesaria.

Shashi ha estado en llamas esta semana. Ha terminado su módulo de envoltura de regalos, que ya está con producto y que básicamente permite agregar opciones de envoltura de regalos a su carrito de manera muy rápida. Después de eso, se movió rápidamente a construir nuestra integración con Google Analytics. Ahora, esto es algo que no teníamos en nuestra lista de prioridades, pero uno de nuestros socios vino a solicitárnoslo, diciéndonos lo importante que era para su ciclo de vida del producto. Siendo el equipo técnico complaciente que somos, lo hemos incluido. Ya se ve genial y rastrea todos los elementos principales de un carrito de compras sin esfuerzo. Realmente nunca nos desviamos de un sprint una vez que está establecido, pero dejamos la flexibilidad en el sprint para poder hacerlo.

Aquí hay una imagen de una de nuestras tareas de Sprint.ly.

El proceso para la creación de estas es también bastante simple: alguien que toma la iniciativa escribe la especificación inicial y luego todos nos unimos en un Google Hangout y lo elaboramos. Luego se envía a cualquier parte externa para obtener comentarios y es revisado por el resto de la empresa. 

Y luego lo construimos. Simple, ¿verdad?