Nuestra publicación sobre calidad en la revista Software Gurú de Mexico

1. Gestión de procesos
Pag. 38
DevOps
Pag. 40
Pagos Móviles
Pag. 42 No.45
TUTORIAL
Desarrolla con
Kinect v2
ESPECIAL
LA ERA
DE LAS
APIS
CONOCIMIENTO EN PRÁCTICA
www.sg.com.mx
TESTING TENDENCIAS Y PRÁCTICAS

2. www.sg.com.mx | Software Guru
Especial
APIs 18
Las APIs son engranes muy importantes en el mundo del software y por ello es vital
comprender su funcionamiento. Estos engranes están siendo referenciados como el
futuro de muchos negocios en línea. Conoce más de este tema en esta sección espe-cial
que tenemos para ti.
Reseña
SGCE 2014 06
Columnas
Tejiendo nuestra red 08
Por Hanna Oktaba
Mejora continua 10
Por Luis Cuellar
Tendencias en Software 13
Por Luis Daniel Soto
Tecno-lógico 46
Por Mauricio Angulo
Columnas invitadas:
DevOps ¿Qué es? 40
Por Ismael Villegas
Análisis de la Situación Actual de los Pagos Móviles,
desde la Perspectiva de un Usuario de la Banca 42
Por Sergio Bolaños
Implantando Big Data 44
Por Victor Pichardo
.CONTENIDO
03
Pág.
18
Emprendiendo
¿Por qué todos en tu Startup deberían
contestar Correos de Soporte? 11
Por Celeste North
Prácticas
Calidad 36
Por Ana Vazquez
Gestión 38
Por Pilar Barrio, Rodrigo Guzmán y Raúl Martínez
Herramientas y Novedades
Lo que viene 12
Docker 17
Tutorial
Desarrolla apps con
Kinect SDK v2 14
Por Laura Frías Carrillo
Personas
Carrera 48
Por Pedro Solares
Tecnología
Diagnóstico Físico Utilizando
Google Glass y Machine Learning 50
Por Jair A. Serrano, Lainy C. Regalado, Victor F. Villa,
y Germán H. Alférez
En Cada Número
Editorial 04
Noticias 05
SG Perfiles 52
Gadgets 54
Biblioteca 56

3. .PRÁCTICAS
Gestión
Acercando el Producto
de Software al Negocio ›› Pilar Barrio, Rodrigo Guzmán y Raúl Martínez
Este trabajo resume los pasos seguidos por una
38
empresa en un ambiente híper competitivo
como es el comercio electrónico y las decisiones téc-nicas
y organizacionales que tomaron para mejorar su
desempeño. Se analizan éstas luego para extraer con-clusiones
aplicables a cualquier empresa.
El escenario previo
Arquitectura técnica
Originalmente la plataforma de e-commerce fue
monolítica y cerrada. Su base de datos y su código
estaban centralizados. El diseño de esta arquitectura
fue pensado para generar ventajas competitivas, pero
con altos costos en pérdida de flexibilidad y riesgos
ante cambios.
Impacto de las fallas
En este esquema monolítico, centralizado y cerrado,
un defecto producto de un error en el desarrollo,
tenía una alta probabilidad de impacto cruzado en
distintas partes de la aplicación con su consecuencia
directa e importante en el negocio. El riesgo asociado
a un defecto latente era muy alto y los efectos no
deseados sobre el negocio podían ser significativos.
El foco estaba puesto en corregir los defectos.
Procesos de desarrollo
Los procesos se diseñaron bajo la premisa de evitar
errores resultando en ciclos de desarrollo y pruebas
extensos, difíciles de escalar y con un “time-to-market”
poco acorde a la industria de e-commerce.
Los ciclos de desarrollo-liberación eran extensos, con
semanas/meses en pruebas, frecuencia de liberación
– “release”- quincenal y en ocasiones mensual.
Organización
Se generó una dinámica organizacional poco toleran-te
a los defectos, con incentivos alineados a evitar y
prevenir cualquier tipo y magnitud de defecto. Equi-vocarse
no era bien visto, por lo tanto la capacidad
de innovar e iterar tendió a reducirse.
El concepto de calidad de producto era elemen-tal
y estaba definido en términos de cantidad de de-fectos.
Las métricas y objetivos a lograr se diseñaron
bajo ese concepto y se enfocaban en medir y contro-lar
cantidad de fallas en producción.
Este escenario puede visualizarse como a base de
una pirámide. En él, el esfuerzo estaba puesto en un
producto sin defectos y con el resto de las características
cumplidas. Los indicadores de éxito estaban referidos a
un producto con baja tasa de errores. Ver Figura 1
Figura 1. Escenario visto como una pirámide.
El nuevo escenario
Arquitectura técnica
Se produjo un cambio radical cuando la plataforma
dejó de ser un sitio web para convertirse en una pla-taforma
abierta de e-commerce. Se rediseñó la arqui-tectura
para abrir la plataforma y descentralizar tanto
la base de datos como el código fuente, permitiendo
distribuir la aplicación en distintos departamentos
de la organización.
Impacto de las fallas
La nueva arquitectura eliminó fricciones y depen-dencias
funcionales y técnicas existentes entre los
módulos en el modelo monolítico. El riesgo se dis-tribuyó
y esto obró como factor de cambio en la or-ganización
y en el negocio.
Procesos de desarrollo
Se establecieron procesos ágiles de desarrollo y prue-ba
permitiendo aumentar la frecuencia de pruebas,
cantidad y paralelismo de los cambios, mejorando
la velocidad de implementación y corrección de de-fectos.
Se pasó de tener una única implementación
quincenal a tener casos de más de ochenta pasajes a
producción en un mismo día.
Organización
La nueva perspectiva introdujo un cambio radical en
la dinámica organizacional, enfocando y alineando
a los equipos de trabajo con la mejora continua y el
cambio constante, no tratando de prevenir todos los
defectos, sino de lograr un producto con la calidad
suficiente para no afectar los indicadores del negocio.
El impacto de los defectos en el producto no es
ya la fricción principal en el negocio: Esto permite
manifestarse al resto de las variables que afectan al
negocio y que antes no formaban parte explícita de la
definición interna de la calidad del producto.
Los nuevos indicadores e incentivos definidos
requieren un comentario adicional.
Ya no es suficiente evitar errores en el producto,
o asegurar el funcionamiento y la disponibilidad de la
plataforma; se trata de dar a los usuarios lo que necesi-tan
y como lo necesiten, satisfaciendo sus expectativas
y logrando una experiencia que diferencie a la empresa
de la competencia. Hay espacio para equivocaciones,
pero existen mecanismos sensibles de alertas y proce-sos
de cambios y corrección muy agilizados.
Para monitorear el comportamiento de las nuevas
variables se consideraron varios niveles de indicadores,
como muestra la pirámide de la Figura 2. Este escenario
puede visualizarse completando la pirámide de la Figu-ra
1 con otros dos niveles: producto útil para el usuario
y, si esto se cumple, producto exitoso para el negocio.
Los indicadores de éxito se relacionan en la base con la
baja tasa de errores, y hacia el vértice, se definen en rela-ción
a los KPI’s que interesan al negocio, no olvidando
además la satisfacción de los clientes.
Nivel 1 (base) - Escalabilidad
Nivel 2 (base) - Funcionamiento Core
Nivel 3 (base) - Usabilidad
Nivel 4 (medio) - Customer Satisfaction
Nivel 5 (vértice) - Rentabilidad
Nivel 6 (vértice) - Competitividad
Figura 2. Pirámide completa

4. www.sg.com.mx | Software Guru
.PRÁCTICAS
Gestión
Análisis del caso
Tratando de interpretar las decisiones más importan-tes
tomadas surge: Interesados y sus expectativas.
Los siguientes aparecen como interesados principales:
La Empresa, que requiere un producto ágil y amplia-ble,
competitivo en funcionalidad, con costos acep-tables
de desarrollo y operativos, medido mediante
indicadores que relacionen el comportamiento del
producto y el del negocio.
El Visitante/usuario, que requiere un producto con-fiable
y maduro, completo en funcionalidad, sencillo
de utilizar, seguro y de buena performance.
El Grupo de Desarrollo que requiere un producto cons-truido
de modo tal que les permita satisfacer el Time-to-market,
mantenible, posible de ser probado y auditable.
Para satisfacer al universo de interesados, la Em-presa
encaró cambios radicales en la arquitectura del
producto, los procesos de negocio y técnicos, y la or-ganización
que los soporta.
Analicemos los cambios
Arquitectura
El cambio tuvo como finalidad que ésta no fuera una
traba para cumplir las expectativas de la Dirección y gru-pos
responsables del producto en cuanto a agilidad en los
cambios y clara responsabilidad de los intervinientes. Los
visitantes/usuarios observan un comportamiento estable
y similar en el producto, o mejorado en algunas funcio-nes.
El costo de lograr este comportamiento es menor,
algo no visible al visitante, pero sí a la Organización.
Procesos de desarrollo
El proceso convencional de desarrollo y manteni-miento,
adecuado para un producto monolítico y
altamente acoplado, se cambió por prácticas ágiles.
Organización
La organización original evolucionó en paralelo con
los nuevos procesos, para satisfacer expectativas de ti-me-
to-market, responsabilidades, costo de cambios, e
indicadores de comportamiento producto / negocio.
Se formaron equipos pequeños, descentralizados
y multifuncionales responsables desde la definición
y planificación de nueva funcionalidad o cambio,
hasta su puesta en Producción y posterior evolución.
Se disolvió el QA centralizado reasignando sus
integrantes a los nuevos equipos.
Se implementó la función de Business Assuran-ce,
que controla el producto en operación y analiza
el impacto de su comportamiento en el negocio me-diante
indicadores.
Indicadores
El producto y organización originales, no mostraban
cómo los indicadores técnicos se relacionaban con los
del negocio (ver Figura 1). No existía una relación
directa entre las acciones a tomar en el producto para
corregir o potenciar situaciones de negocio.
Los distintos niveles de indicadores (ver Figura 2),
permiten ahora detectar la calidad en uso del producto
para los interesados y efectuar mediciones que delimitan
sobre qué parte del producto accionar si fuera necesario.
Estos indicadores accionables, en forma indirecta, estable-cen
si se cumplen los objetivos de negocio dependientes
del producto, posibilitando dar incentivos a los responsa-bles
de las distintas partes de la plataforma de la Empresa
en función al cumplimiento de dichos objetivos.
Próximos pasos
Interesados
Continuar la detección de interesados, además de los vi-sitantes
y comerciantes, ampliando a otros con expecta-tivas
sobre el producto: comunidad de desarrollo exter-na,
auditores, seguridad informática, etc. Entendiendo
la influencia y comunicación con cada uno.
Detección y priorización de expectativas
Realizar encuestas o consultas instantáneas a los visi-tantes/
compradores y comerciantes para entender sus
expectativas. Utilizar herramientas como el Modelo
Kano y los Mapas de Empatía para detectar y priori-zar
requerimientos y expectativas.
Modelo de calidad y evangelización
Formalizar en la medida necesaria y posible, el co-nocimiento
tácito de calidad para la Organización y
transmitirlo a los equipos propios, a terceros y a otros
interesados mediante reuniones y eventos. Ejemplo,
al desarrollador que amplía el producto de la Em-presa
mediante APIs, la formalización le permitirá
comprender la calidad esperada, y a la Empresa, eva-luar
la calidad ofrecida. El software será visto enton-ces
como homogéneo, ya sea el producto base o sus
extensiones.
Aquí resultan aplicables los modelos establecidos
en la industria de calidad de sistemas y de productos
de software.
KPIs del negocio
Continuar midiendo “features” del producto por los
resultados sobre el negocio. Las medidas deben ser
accionables, y se debe poder relacionar el KPI del ne-gocio
con el producto, para intervenir si es necesario.
KPIs del producto
Desarrollar nuevos KPIs que midan la calidad técnica
del producto, para pronosticar su calidad final. Como
se mencionó anteriormente, aquí aplican los modelos
de calidad de software y las métricas que proponen.
Mejora continua
Compenetrar al personal técnico del producto cada vez
más en el negocio, ya que el negocio se basa en el pro-ducto,
completando así un ciclo para mejorar la calidad
del producto haciéndolo más competitivo y exitoso.
Conclusiones
Se mostró cómo esta Empresa:
• Colocó en el centro al cliente y al producto y
no a la tecnología.
• Relacionó el negocio con el producto de soft-ware
y el éxito en el negocio con la calidad de
dicho producto.
• Cambió su organización y modelos de trabajo
para adecuarlos a los tiempos y necesidades que
demandaba su mercado.
• Dio, intuitivamente, los pasos necesarios para
considerar todo el contexto en el que el producto de
software estaba inserto y reaccionó ante ese contexto.
• Los próximos pasos propuestos intentan hacer
más visibles y analizables estas decisiones conso-lidando
aún más la calidad del producto que se
está logrando.
Si bien este análisis es de un caso en particular,
permite extraer conclusiones aplicables a otras or-ganizaciones
que quieran lograr una mayor y mejor
relación entre sus productos de software y el negocio
en el que se aplican.
.BIO
Pilar Barrio la Iglesia fue docente universitaria en distintas materias relacionadas con la tecnología informática. Socia fundadora de RMyA S.R.L.,
especializada en consultoría sobre aseguramiento de calidad y testing. pbarrio@rmya.com.ar
Rodrigo Guzmán es Gerente Senior de Desarrollo de Producto en MercadoLibre empresa líder de comercio electrónico. Responsable de varios
proyectos de desarrollo de producto, principalmente la verticalización de la plataforma para las principales categorías. Lic. en Admón de Empresas,
postgrado en Calidad y Gestión y Certified Scrum Master. rodrigo.guzman@mercadolibre.com
Raúl Martínez se especializa en Gestión de Proyectos de TI y calidad de productos de software. Docente de la Facultad de Ingeniería (UBA). Socio
fundador de RMyA SRL interesado en mejora de procesos, gestión de proyectos, gestión de la calidad. rmartinez@rmya.com.ar
39