Deuda tecnica en Lean Startup.en.es.pdf

Cómo gestionar la deuda técnica en una startup lean
Tesis de Maestría en Ciencias en el Programa de Ingeniería de Software
HAMPUS NILSSON
LINUS PETERSSON
Universidad Tecnológica de Chalmers
Universidad de Gotemburgo
Departamento de Ingeniería y Ciencias de la
Computación Göteborg, Suecia, octubre de 2013
Traducido del inglés al español - www.onlinedoctranslator.com

El Autor otorga a Chalmers University of Technology y a la Universidad de Gotemburgo el
derecho no exclusivo de publicar la Obra electrónicamente y con fines no comerciales
hacerla accesible en Internet.
El Autor garantiza que es el autor de la Obra y garantiza que la Obra no contiene
texto, imágenes u otro material que viole la ley de derechos de autor.
El Autor, al transferir los derechos de la Obra a un tercero (por ejemplo, un editor o una
empresa), deberá reconocer al tercero acerca de este acuerdo. Si el Autor ha firmado un acuerdo
de derechos de autor con un tercero con respecto a la Obra, el Autor garantiza por la presente
que ha obtenido el permiso necesario de este tercero para permitir que la Universidad
Tecnológica de Chalmers y la Universidad de Gotemburgo almacenen la Obra electrónicamente y
la hagan accesible en Internet.
Cómo gestionar la deuda técnica en una startup Lean.
HAMPUS. NILSSON,
LINÚS. PETERSSON,
© HAMPUS. NILSSON, octubre de 2013. ©
LINUS. PETERSSON, octubre de 2013.
Examinador: MIGUEL. CHAUDRON
Universidad Tecnológica de Chalmers
Universidad de Gotemburgo
Departamento de Ingeniería y Ciencias de la
Computación SE-412 96 Göteborg
Suecia
Teléfono + 46 (0)31-772 1000
Departamento de Ingeniería y Ciencias de la Computación
Gotemburgo, Suecia, octubre de 2013.

Abstracto
Las empresas emergentes son cada vez más prominentes en el mundo actual y el
movimiento lean startup ha demostrado un método para alcanzar el éxito a través del desarrollo
rápido y la creación de prototipos. Los efectos que esto tiene sobre la calidad del software y
cómo debe manejarse es un tema novedoso, el concepto de deuda técnica se conoce en el
campo de la Ingeniería de Software desde hace más de una década, pero hay muy poca
investigación sobre cómo se maneja o cómo se debe manejar. en contextos de startups.
Este estudio tiene como objetivo llenar este vacío entrevistando a nueve empresas
emergentes sobre sus problemas de deuda técnica. Al mismo tiempo, los investigadores
desarrollaron un proyecto inicial de Internet y evaluaron la eficacia de los métodos y
herramientas de software que pueden utilizarse para gestionar la deuda técnica.
Para abordar las dificultades de discutir la deuda técnica, se presenta un nuevo modelo
para clasificar la deuda denominado Cuadrante de Deuda Técnica. Para solucionar el
problema de la gestión de la deuda técnica en las startups se desarrolló una lista de
consejos concretos para la gestión de la deuda técnica y una matriz denominada Matriz de
Estrategia de Deuda que puede ser consultada en las diferentes fases de la vida de una
startup. La validez de estas nuevas soluciones deberá evaluarse más a fondo en estudios
futuros para evaluar su utilidad.
Los nuevos términos para referirse a la deuda técnica serán de utilidad tanto para
investigadores como para profesionales en el campo de la Ingeniería de Software en el futuro.
Cualquier startup puede utilizar las estrategias para gestionar la deuda técnica sin los gastos
generales asociados con las soluciones anteriores para evitar problemas técnicos a largo plazo.

Agradecimientos
Nos gustaría agradecer a las siguientes personas por su apoyo durante el trabajo de nuestra tesis
de maestría.
Elma Delic, Henrik Lång y David Svensson en Alice.
Nuestro supervisor Jan Bosch.
Nuestro examinador Michel Chaudron.
i

Contenido
Glosario IV
1. Introducción 1
2 Fondo
2.1 Metodología Lean Startup
2.1.1 Construir-Medir-Aprender. . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Producto Mínimo Viable. . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Métricas
2.1.4 Pivote
2.2 Deuda Técnica
2.2.1 Tipos de deuda
2.2.2 Identificación de la deuda
2.3 Herramientas y métodos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 ESCALA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Sonda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 REMITIR AIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Código Clima. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Alicia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
2
3
4
4
4
6
6
6
7
7
8
8
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Propósito 10
4 Método
4.1 Recopilación de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Caso primario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Casos Secundarios. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 Evaluación de software. . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Amenazas a la validez. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
11
11
13
13
5 Resultado
5.1 Software evaluado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Sonda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 REPARAR AIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 Código Clima. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Caso Primario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Proceso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Deuda Técnica. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Datos de la entrevista. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Ene Salvador van der Ven . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Apelación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
15
dieciséis
17
18
18
18
19
19
20
ii

CONTENIDO
5.3.3 Burt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4 Duego. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5 NetClean. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.6 PugglePago. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.7 Futuro registrado. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.8 Repuesto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.9 Trimbia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Resumen de las entrevistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
23
24
25
26
28
29
30
6 Discusión
6.1 Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Problemas técnicos de deuda identificados. . . . . . . . . . . . . . . . . .
6.1.2 Actividades generadoras de deuda. . . . . . . . . . . . . . . . . . . . . . .
6.1.3 Métodos en uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Solución. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 El cuadrante de la deuda. . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Estrategia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Matriz de estrategia de deuda. . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Validación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
35
35
37
38
40
40
43
45
47
7 Conclusión 50
8 Trabajo futuro 51
Referencias 52
III

Glosario
Olor a código Un problema en el código, como complejidad excesiva, duplicación,
comentarios deficientes o código ofuscado, etc.
Programación vaquera Los desarrolladores trabajan sin ningún proceso formal y asignan
sus propias tareas sin mucha intervención de los desarrolladores
comerciales.
Kanban Una metodología ágil de desarrollo de software enfocada en la
entrega justo a tiempo.
Rastreador fundamental Un tablero de gestión de tareas en línea creado para el desarrollo de
Scrum.
SaaS Software como servicio, una solución alojada en línea y entregada a
los usuarios a través de la web en lugar de instalarla en sus propias
computadoras.
Melé
Puesta en marcha
Una metodología ágil de desarrollo de software.
En esta tesis una startup se define como “Una startup es una
institución humana diseñada para crear un nuevo producto o
servicio en condiciones de extrema incertidumbre”. (Ries, 2011, p.
27).
Trelo Un tablero de gestión de tareas en línea.
IV

1. Introducción
Al comenzar a trabajar en un nuevo producto basado en software, seguir las mejores prácticas y dedicar
tiempo a planificar la arquitectura y el diseño del producto puede ser un tiempo bien invertido, dado que
hay recursos disponibles y un conjunto de requisitos semifinales. Sin embargo, en un mundo donde el
modelo de startup lean se está volviendo más común y el enfoque del producto puede cambiar muchas
veces, tanto al principio como al final del proceso de desarrollo, el tiempo dedicado a la planificación
puede ser una pérdida de tiempo.
Eric Ries introdujo la metodología lean en 2008 (Ries, 2008). Lean se enfoca en realizar la mínima
cantidad de trabajo en el producto para poder venderlo y diseñar según los deseos del cliente en
lugar de perder tiempo implementando características que no sabes que son relevantes. Esta es
una propuesta valiosa para casas de desarrollo más pequeñas y empresas de nueva creación
donde los recursos económicos son limitados (Moogk, 2012; Ries, 2008).
Al fusionar estos dos conceptos, es obvio que renunciar a la planificación, las pruebas meticulosas y el
cumplimiento de los estándares de codificación, etc., puede ser una realidad cuando se desarrolla
utilizando lean. Esto conducirá a una acumulación de deuda técnica que se volverá más difícil de manejar
con el tiempo (Poort, 2011). Este informe intenta proponer una solución a este problema ofreciendo
directrices sobre cómo gestionar la deuda desde el principio y evitar acabar en una situación en la que
sea necesario frenar el desarrollo para rectificar errores anteriores.
La tesis aborda primero los antecedentes de la metodología lean startup, define la
deuda técnica y presenta trabajos previos realizados dentro del dominio. También
presenta algunas soluciones y métodos de software destacados que se pueden
utilizar para gestionar la deuda técnica. En un capítulo siguiente se presenta una
breve evaluación de las soluciones de software. Se presenta un caso de estudio
realizado en una empresa siguiendo la metodología lean startup que contiene
experiencias sobre cómo se comporta la deuda técnica en ese tipo de entorno. El
tema se explora más a fondo mediante entrevistas realizadas en varias empresas
emergentes para investigar cómo se maneja actualmente en la práctica. Además, se
presenta un nuevo modelo de cómo caracterizar la deuda técnica que ayuda a
comunicar sobre la deuda técnica al definir una terminología común. Finalmente,
1

2. Fondo
Este capítulo detalla qué es la deuda técnica y el método lean startup y una serie de
métodos diferentes disponibles para gestionar la deuda técnica y sus fortalezas y
debilidades.
2.1 Metodología Lean Startup
La metodología Lean Startup fue presentada por primera vez por Eric Ries en una publicación de
blog (Ries, 2008) que luego dio lugar al libro.The Lean Startup: cómo los emprendedores de hoy
utilizan la innovación continua para crear negocios radicalmente exitosos(Riés, 2011). La
metodología surgió de la experiencia de Eric trabajando con startups exitosas y fallidas. La
metodología es una combinación de desarrollo ágil de software, desarrollo de clientes y prácticas
lean utilizando interacción frecuente con el cliente e iteraciones cortas. Se centra en cómo utilizar el
tiempo de la manera más eficiente posible y cómo conocer rápidamente a los clientes y sus
necesidades.
2.1.1 Construir-Medir-Aprender
El proceso se centra en el aprendizaje validado y lo que Ries llama elConstruir-medir-aprenderbucle
de retroalimentación, visible en la figura 2.1, para realizar experimentos (Ries, 2011). Comienza con
elConstruirEtapa donde se construye algún tipo de producto. Puede ser como un producto
funcional, una maqueta interactiva, una maqueta en papel o cualquier cosa que se ajuste a sus
necesidades. Este artículo se conoce como artefacto y se entrega a un cliente y elMedidacomienza
el paso del ciclo de retroalimentación. La respuesta del cliente se mide utilizando técnicas tanto
cuantitativas como cualitativas. Los datos de la medición se utilizan en elAprenderPaso del circuito
de retroalimentación donde las ideas pueden validarse o descartarse. Luego se reinicia el proceso
con nuevas ideas y elConstruir-medir-aprenderEl bucle continúa de forma iterativa a lo largo de
todo el proyecto.
2.1.2 Producto Mínimo Viable
Un producto mínimo viable (MVP) es una versión muy temprana del producto que se crea con el
propósito de conocer a los clientes potenciales y validar la idea de negocio. Se construye con el
menor esfuerzo posible solo para ponerlo en manos de los clientes para que el equipo pueda
comenzar a recibir comentarios. No tiene por qué ser un producto completamente funcional que
haga todo de manera perfecta. (Moogk, 2012; Ries, 2011)
2

2.1. METODOLOGÍA LEAN STARTUP
IDEAS
APRENDER CONSTRUIR
DATOS PRODUCTO
MEDIDA
Figura 2.1:Ciclo de retroalimentación Construir-Medir-Aprender.
Por ejemplo, cuando la zapatería onlinezapoCuando comenzó, su fundador Nick Swinmurn
construyó una tienda web en línea muy simple y cuando un cliente pedía un par de zapatos,
iba a la zapatería local, los compraba y se los enviaba a su cliente (Ries, 2011). En lugar de
gastar mucho tiempo y dinero en crear un producto completamente funcional, creó este
sencillo MVP con muy poco esfuerzo. Con esto podría, con un riesgo muy bajo, validar su idea
de negocio en el mundo real antes de dar el siguiente paso. De eso se trata principalmente el
MVP.
2.1.3 Métricas
Para saber si el desarrollo del producto realmente está generando un progreso real, es necesario
realizar una medición adecuada. Es importante seleccionar las métricas correctas y mantenerse
alejado de los llamadosmétricas de vanidad. Las métricas de vanidad son métricas que “ofrecen la
imagen más optimista posible” (Ries, 2011, p.182) y, por lo tanto, pueden ser muy engañosas. Estas
métricas difieren entre empresas según su tipo de negocio. En cambio, métricas procesablesson
más apropiados. Un ejemplo de métrica procesable esPruebas A/B(también conocido como prueba
dividida). Cuando se utilizan pruebas A/B, se implementa una nueva característica para un grupo de
clientes y se mide su comportamiento (Burke, 2005). Los datos generados a partir de la prueba se
pueden utilizar para tomar una decisión sobre qué acción tomar a continuación y ayudarlo a
confirmar o refutar su hipótesis. Por supuesto, las pruebas A/B son sólo una de las muchas
métricas procesables que una startup puede utilizar. (Kohavi et al., 2007; Ries, 2011)
3

2.2. DEUDA TÉCNICA
2.1.4 Pivote
Durante el proyecto, a medida que el equipo aprende más sobre las necesidades de los
clientes y en qué dirección debe dirigirse el proyecto, el producto evoluciona y optimiza
continuamente. En algunos casos, el proyecto puede estar en el camino equivocado y necesita
dar un ligero (o brusco) giro y cambiar su estrategia. Este cambio de estrategia se llamaPivote.
(Ries, 2011)
Los pivotes son un momento polarizador para una startup, los pivotes le permiten ajustar el
producto a lo que los clientes realmente querían y deshacerse de las partes de su idea inicial que
resultaron ser incorrectas. La dificultad de pivotar es decidir cuándo es apropiado y hacerlo en el
momento adecuado para aprovechar tus recursos estratégicos de la mejor manera posible. (Ries,
2011; Bingham et al., 2011)
2.2 Deuda Técnica
El concepto de deuda técnica fue introducido por Ward Cunningham allá por 1992, y se refiere a la
tendencia del código en el que se sigue trabajando a volverse cada vez menos adecuado para los
nuevos requisitos para los que se ha diseñado (Cunningham, 1992). A medida que se incorporan
más y más funciones al sistema, se acumula una “deuda” metafórica en forma de complejidad
creciente. Esta deuda debe pagarse más adelante tomándose el tiempo para reescribir el sistema
original para que se ajuste mejor a las demandas actuales, en el proceso que ahora se conoce
como refactorización.
Pequeñas cantidades de deuda técnica pueden conducir a flexibilidad en las decisiones, como cita a
Cunningham (1992) “Un poco de deuda acelera el desarrollo siempre que se pague rápidamente con una
reescritura”. Sin embargo, es importante realizar un seguimiento de la deuda, ya que con el tiempo
generará gastos generales de desarrollo (Curtis et al., 2012; Kruchten et al., 2012).
2.2.1 Tipos de deuda
Existen muchas definiciones de los tipos de deuda técnica que existe. Kruchten et al. (2012)
divide la deuda en dos categorías destacadas: visible (que es la deuda que pueden identificar
personas que no son desarrolladores de software) o invisible (que es la deuda que solo
pueden identificar los desarrolladores de software).
Ejemplos de deuda visible son las nuevas características y defectos, que son visibles para el personal directivo, que
puede ver fácilmente estos objetos en el trabajo pendiente o en herramientas similares. En esencia, esto abarca los
atributos de calidad externos definidos inicialmente en la norma ISO 9126 (2001) y posteriormente complementados
por la norma ISO 25010 (2011).
La deuda invisible puede deberse a muchos factores y es muy difícil poner medidas exactas de su
tamaño. Este tipo de deuda incluye cosas como mala arquitectura, complejidad del código,
4

2.2. DEUDA TÉCNICA
malas elecciones tecnológicas y problemas de higiene del código, como la falta de estándares de codificación. Muchos
de los conceptos aquí se pueden vincular a métricas de calidad internas definidas en ISO 25010 (2011), es decir, cosas
que no son visibles en tiempo de ejecución sino solo cuando se observa el código fuente y la arquitectura de la
aplicación. Sin embargo, aquí también se pueden vincular algunas cualidades externas, como las cuestiones de
eficiencia.
McConnel (2007) habla de la deuda técnica desde otro aspecto. En lugar de dividir la deuda en
función de sus características, define dos categorías básicas en función de cómo se contrae. Los
dos grupos incluyen deuda que se contrae intencionalmente o no. El grupo no intencional incluye
la deuda que surge de hacer un mal trabajo, por ejemplo, cuando un programador junior escribe
un código incorrecto debido a su falta de conocimiento. Otro ejemplo es cuando una empresa
adquiere otra y se encuentra deuda técnica tras la adquisición. La deuda intencional es una deuda
asumida conscientemente por razones estratégicas. Por ejemplo, cuando una empresa debe lanzar
un producto antes de poder saldar la deuda.
McConnel divide además la deuda intencional en deuda a corto y largo plazo. La deuda a corto plazo se
contrae de forma reactiva y se paga con frecuencia, mientras que la deuda a largo plazo se contrae de
forma proactiva y se paga en el transcurso de varios años (McConnel, 2007).
Fowler (2009) presenta otra categorización de los diferentes tipos de deuda, en lo que llama el
“Cuadrante de Deuda Técnica”. Como se ve en la figura 2.2, Fowler agrupa la deuda en cuatro categorías:
deuda imprudente deliberada/inadvertida y deuda prudente deliberada/inadvertida. La deuda
imprudente incluye la deuda que se asume por desconocimiento o falta de conocimiento del buen diseño
y las mejores prácticas de forma deliberada o inadvertida. La deuda deliberada y prudente, por otro lado,
es cuando se contrae deuda conscientemente por una buena razón. Fowler (2009) señala que la deuda
prudente e involuntaria es un poco extraña, pero sostiene que es inevitable para los equipos que son
excelentes diseñadores.
Imprudente Prudente
"Debemos enviar ahora
y lidiar con el
consecuencias"
"No tenemos tiempo
¡Para el diseño!"
Adrede
"Ahora sabemos cómo
debería haberlo hecho"
Inadvertido "¿Qué son las capas?"
Figura 2.2:Cuadrante de deuda técnica de Fowler.
5

2.3. HERRAMIENTAS Y MÉTODOS
2.2.2 Identificación de la deuda
Una forma de realizar un seguimiento de la deuda es mediante el uso de herramientas de análisis de código.
Estos pueden identificar errores de coherencia, falta de comentarios y documentación y otras transgresiones
menores. Curtis y cols. (2012) introduce una forma muy mecánica de identificar la deuda mediante el uso del
paquete de software CAST, que se describe en detalle en la sección 2.3.3. Esto es muy similar al concepto de
deuda invisible que Kruchten et al. (2012) distinguen y el objetivo es hacerlo comprensible para los
desarrolladores que no son de software.
Sin embargo, no existe ninguna herramienta de análisis de código que pueda identificar errores
arquitectónicos que puedan requerir el rediseño de partes importantes del sistema, o la opción de
confiar en una tecnología que con el tiempo se vuelve obsoleta o marginada debido a cambios en el
entorno (Kruchten et al., 2012). ). La identificación de estas amenazas depende de la experiencia de los
desarrolladores y de su capacidad para transmitir los riesgos de las elecciones a las partes interesadas.
Con la experiencia, todos los desarrolladores comprenden qué código es bueno y qué código es malo y
aprenden a abordar el desarrollo de manera que se evite gran parte de él (Hunt y Thomas, 1999).
2.3 Herramientas y métodos
2.3.1 ESCALA
SQALE (Evaluación de la calidad del software basada en las expectativas del ciclo de vida) es un método
para evaluar la deuda técnica en un proyecto de software. Se basa en herramientas que analizan el
código fuente del proyecto, observando diferentes tipos de errores, como sangrías no coincidentes,
diferentes convenciones de nomenclatura y más. A cada uno de los errores se le asigna una puntuación
en función de cuánto trabajo supondría corregir ese error. Luego, el análisis arroja una suma total de
deuda técnica para todo el proyecto. (SonarFuente, 2013b)
Gran parte del método SQALE se basa en visualizar la cantidad de deuda presente. Como tal,
el análisis debe realizarse a diario, si no con mayor frecuencia, e ilustrarlo en un tablero o
similar es otra ayuda para mostrar a los ingenieros qué efecto tiene el código que están
escribiendo en la base de código compartida. (Letouzey e Ilkiewicz, 2012)
SQALE fue diseñado para ser genérico y aplicable a cualquier lenguaje de programación o
metodología de desarrollo. El método en sí se publica bajo una licencia de código abierto y
está totalmente libre de regalías. Está disponible un marco de código abierto que lo
implementa llamado Sonar, que también existe en versiones comercializadas. Este marco es
una implementación oficial de la metodología SQALE destinada a facilitar la comunicación de
la importancia de la deuda técnica entre gerentes y programadores. (Freddy Mallet, 2010)
6

2.3. HERRAMIENTAS Y MÉTODOS
2.3.2 Sonda
Sonar es una plataforma de código abierto que inspecciona y analiza la calidad de su código. Es
propiedad y está mantenido por SonarSource SA en Suiza. El software es multiplataforma y está
escrito en Java. Sonar, listo para usar, admite la inspección de código para Java (SonarSource, 2013
b) pero se puede agregar fácilmente soporte para otros idiomas a través de complementos. Hay
complementos disponibles para varios lenguajes populares como COBOL, C, C#, C++, PHP, Python,
VB.NET y más. Algunos son complementos gratuitos respaldados por la comunidad y otros son
comerciales.
Sonar incluye la capacidad de crear paneles que se pueden personalizar para diferentes usos. Los paneles se
pueden configurar mediante widgets que se pueden reorganizar arrastrando y soltando. Los widgets pueden
contener cualquier cosa, desde texto puro hasta gráficos avanzados e interactivos. Sonar viene con una serie de
widgets predeterminados y se pueden agregar nuevos widgets mediante complementos que necesitan algún
tipo de visualizaciones especializadas.
El software viene en tres versiones diferentes; Código abierto, profesional y empresarial. La versión
de código abierto es gratuita y no incluye complementos ni soporte comerciales. Las principales
diferencias entre los otros dos paquetes son la cantidad de complementos incluidos, el nivel de
soporte y la capacitación. La versión profesional comienza enmi12 500 y la versión empresarial
comienza enmi50 000 (SonarFuente, 2013a).
Sonar tiene un complemento gratuito que calcula la deuda técnica en su código base (SonarSource,
2012). Sin embargo, es muy limitado. En cambio, SonarSource ha creado un complemento comercial que
es mucho más avanzado y tiene todas las funciones (SonarSource, 2013).C). El complemento es una
implementación completa de la metodología SQALE (SQALE.org, 2013) y utiliza el modelo de calidad ISO
9126 con características y subcaracterísticas. Puede mostrar todo tipo de métricas, como el costo total de
remediación, el costo de remediación por archivo, el costo de remediación por característica, el costo de
remediación agrupado por gravedad, la calificación SQALE general, la calificación SQALE por
componente y más. Presenta todos los datos visualmente en un panel mediante widgets configurables.
Los complementos comerciales tienen un precio demi2.700 al año.
2.3.3 REMITIR AIP
La CAST Application Intelligence Platform (AIP) es una solución completa para analizar y medir la
calidad del software. La aplicación es muy completa y se centra principalmente en sistemas
empresariales complejos. Ayuda a las empresas a identificar y mitigar los riesgos de TI, analizar la
arquitectura y la calidad del código, monitorear el desempeño del equipo, reducir la deuda técnica
y mucho más. Tiene soporte para muchos lenguajes de programación, bases de datos y
frameworks diferentes como J2EE, Cobol y .NET.
Las herramientas incluidas en el CAST AIP pueden cuantificar la deuda técnica que se ha incurrido
en el proyecto y ayudar al equipo a gestionarla y reducirla de forma proactiva con el tiempo. CAST
AIP mide cinco tipos diferentes de deuda técnica, o factores de salud, como la llaman. El
7

2.4. ALICIA
Los factores de salud son: Cambiabilidad, Transferibilidad, Seguridad, Rendimiento y
Robustez (Cast Software, 2013). CAST AIP también puede comparar la calidad y el
rendimiento con otras aplicaciones a través del repositorio appmarq proporcionado por
CAST. Este repositorio contiene datos estadísticos, tendencias y mejores prácticas de
miles de otras aplicaciones. Los datos del repositorio se han extraído de aplicaciones de
diferentes industrias.
CAST AIP se centra en la transparencia y la visualización de calidad, tendencias, problemas, etc.
Esta visualización se realiza a través de paneles web que se pueden configurar para mostrar
información relevante según la audiencia prevista. Estos paneles brindan a los administradores y
desarrolladores un lugar común para seguir la evolución de la aplicación a lo largo del tiempo.
2.3.4 Código Clima
Code Climate es una solución SaaS para monitorear la deuda técnica diseñada específicamente
para monitorear la calidad del código de las aplicaciones Ruby. El servicio utiliza múltiples
herramientas de análisis disponibles para Ruby, como metric_fu y Flog, y las compone en una vista
de salida única para el desarrollador.
El software funciona desde un sitio web y solo requiere derechos de pago en un repositorio Git para funcionar.
Supervisa el código base continuamente, asignando puntuaciones en el rango de F (peor) a A (mejor) a las
clases y métodos en todo el proyecto, señalando "olores de código", como preocupaciones de complejidad
ciclomática, duplicación de código y también existe la opción de encontrar problemas relacionados con la
seguridad. Los desarrolladores reciben notificaciones por correo electrónico semanalmente sobre nuevos
problemas que surgen en el código o cosas que se han mejorado. Esto proporciona retroalimentación continua
sobre el estado del producto y la intención es mantener a los desarrolladores motivados para trabajar con
problemas de calidad del código.
2.4 Alicia
Alice es una pequeña startup ubicada en Gotemburgo, Suecia, que desarrolla software utilizado para la
gestión de la seguridad y la salud en las empresas. La empresa comenzó el desarrollo de software en
2013 en una incubadora de empresas en la Universidad Tecnológica de Chalmers.
El primer producto de Alice fue un sistema de gestión de incidentes donde los empleados pueden
informar incidentes que ocurren en el lugar de trabajo, como accidentes, deficiencias en el entorno
laboral, etc. Los eventos informados son luego rastreados y manejados por el gerente responsable
a través de una interfaz web. La empresa sigue la metodología Lean Startup creada por Eric Ries y
su primer MVP se desarrolló durante la primavera de 2013.
Alice fue estudiada durante unos meses durante el desarrollo de su primer MVP. Dado que es una
startup que sigue la metodología lean startup, encaja bien con el enfoque de investigación de
8

2.4. ALICIA
esta tesis. El producto cambió rápidamente durante el desarrollo y cambió de dirección y de
clientes objetivo hacia el final del proyecto de investigación.
9

3 Propósito
El propósito de este estudio es explorar y comprender mejor el concepto de deuda técnica en un
contexto de startup lean. En general, la deuda técnica se considera un perjuicio para el proceso de
desarrollo de software, pero este puede no ser el caso para una startup que utiliza la metodología lean
startup, ya que las soluciones rápidas pueden ser un recurso que debe aprovecharse (Ries, 2009).
El problema con las startups lean es que la rápida creación de prototipos y desarrollo que se utiliza
genera rápidamente un alto nivel de deuda (Poort, 2011), aunque tal vez esta deuda pueda usarse como
apalancamiento, y ¿qué métodos serían apropiados para gestionarla?
Al revisar la literatura en el área de startups y deuda técnica y unirla con aportes de
profesionales de la industria, identificamos algunas áreas clave que faltan en el manejo
de la deuda técnica:
1.No existe una buena manera de categorizar/clasificar la deuda técnica–Las
entrevistas y la literatura ofrecen poco para clasificar la deuda técnica en un nivel entre
dividirla en sus partes constituyentes más pequeñas y los tipos introducidos por Fowler
(2004), que apuntan a la adquisición de deuda, no al inventario.
2.Los métodos para gestionar la deuda tecnológica se centran en proyectos maduros–
Todas las metodologías disponibles para manejar la deuda técnica están dirigidas a
proyectos que utilizan estilos de gestión y planificación más tradicionales que las nuevas
empresas. Hay una notable falta de cómo se debe manejar y razonar la deuda técnica en una
startup lean.
3.Los métodos existentes no ofrecen una orientación clara sobre cuándo y cómo manejar
los diferentes tipos de deuda.–Finalmente, todos los métodos disponibles tienen un
enfoque muy mecánico, centrado en el análisis de código o definidos a través de pautas
generales y confusas sobre cómo los programadores experimentados trabajan con la
arquitectura. Nuestro objetivo es definir directrices y métodos más concretos sobre cómo se
debe gestionar la deuda en las startups.
El objetivo de este estudio es explorar estas áreas en profundidad y su lugar y relación en el
modelo lean startup. Se desarrollarán y presentarán posibles soluciones, pero no se validarán
mediante la práctica debido al alcance limitado del proyecto.
10

4 método
4.1 Recopilación de datos
El estudio se realizó mediante la recopilación de datos tanto a través de un caso primario como de una
serie de entrevistas con empresas emergentes en el negocio del software. En el caso principal, se
desarrolló un nuevo producto de software desde la etapa de prototipo hasta el lanzamiento y, un corto
período después, se tomaron muestras de los datos utilizando un enfoque de investigación de sistemas
blandos (N. Denzin, 2000), donde los investigadores participaron en el desarrollo.
Con base en la literatura, la experiencia adquirida en el caso primario y el conocimiento de la vida
real recopilado en las entrevistas, se definió un modelo y un conjunto de pautas.
4.1.1 Caso primario
El primer caso se llevó a cabo en la empresa emergente Alice en Gotemburgo. Los autores
participaron en el desarrollo de un nuevo producto de software para el mercado de empresa a
empresa. El desarrollo del producto aplicó la metodología lean, desarrollando un MVP al mismo
tiempo que intentaba vender el producto a los clientes e integraba los comentarios de los clientes
desde muy temprano en el proceso de desarrollo.
El caso principal se utilizó para obtener una experiencia de primera mano sobre cómo funciona una
startup lean. Se investigaron una serie de cuestiones, como qué desafíos surgen debido a la deuda
técnica, cuándo en el proceso de desarrollo hay que preocuparse por la deuda, etc. El caso principal
también se utilizó para evaluar una serie de diferentes soluciones de software que estaban disponibles
para gestionar deuda técnica, revelando sus fortalezas y debilidades en relación al contexto de una
startup. Esto se hizo analizando factores como los gastos generales de configuración, la facilidad de uso
de los datos que proporciona la herramienta, la relevancia de los datos y la dificultad de integrar la
retroalimentación que proporciona la herramienta en el producto.
4.1.2 Casos secundarios
Los casos secundarios se utilizaron como complementos del caso primario para respaldar los hallazgos.
Las entrevistas se centraron en preguntas sobre cómo la empresa encontró la deuda técnica, qué
hicieron para manejarla inicialmente y cómo la están manejando a lo largo del desarrollo, y también
para recopilar datos sobre cómo las nuevas empresas más antiguas han manejado sus problemas de
deuda técnica a lo largo del tiempo.
11

4.1. RECOPILACIÓN DE DATOS
Entrevistas
Las empresas a entrevistar fueron seleccionadas de una lista de nuevas empresas de Gotemburgo. La
razón por la que todos estaban en Gotemburgo era para que pudieran ser entrevistados fácilmente en
persona en lugar de por teléfono o alguna otra forma de comunicación menos directa. De la lista se
seleccionaron las empresas que mejor parecían encajar en el estudio.
Las entrevistas se realizaron de forma semiestructurada. Un enfoque semiestructurado tiene
la ventaja de permitir al entrevistador improvisar y profundizar en un tema durante la
entrevista (N. Denzin, 2000; Hove y Anda, 2005). La mayoría de las preguntas de la entrevista
planteadas se formularon de forma abierta, esto permite al entrevistado expresar su visión
sobre el tema en profundidad (Wohlin et al., 2012; Hove y Anda, 2005). Antes de que se
realizaran las entrevistas, no estaba claro cómo trabajaban las empresas con la deuda
técnica, cómo la definían o si siquiera sabían qué era. El enfoque semiestructurado permitió a
los entrevistadores aclarar y responder cualquier pregunta que tuvieran los entrevistados y
evitar malentendidos y malas interpretaciones. También, Es posible cambiar las entrevistas a
medida que aumenta el conocimiento sobre el tema. Esto es mucho más difícil cuando, por
ejemplo, se utilizan encuestas (N. Denzin, 2000). Los entrevistados fueron elegidos por las
empresas pero el tipo de persona necesaria para la entrevista lo dieron los entrevistadores.
Esto era importante ya que las personas entrevistadas debían tener cierto nivel de
conocimientos técnicos y estar en la empresa desde su concepción o cerca de ella.
Antes de realizar cualquier entrevista, se crearon y validaron una serie de preguntas mediante la
realización de una entrevista simulada para encontrar debilidades en la redacción y la estructura. La
mayoría de las preguntas se utilizaron en todas las entrevistas, pero se agregaron o perfeccionaron un
par de preguntas en las últimas entrevistas. Al realizar una entrevista, las preguntas se utilizaron como
guía y se hicieron preguntas de seguimiento apropiadas para profundizar en temas interesantes. En la
tabla 4.1 se pueden encontrar algunos ejemplos de preguntas y respuestas. Los mismos dos
entrevistadores estuvieron presentes en todas las entrevistas, haciendo preguntas y tomando notas. Un
entrevistador tomó notas más detalladas mientras que el otro anotó las cosas más importantes y se
centró en escuchar. Esto hizo que fuera más fácil evitar malentendidos y pérdida de datos importantes. y
se ha demostrado que hace que el entrevistado sea más hablador (Hove y Anda, 2005). Después de
formular todas las preguntas pertinentes y, si había tiempo, el entrevistado también pudo conocer los
resultados del estudio hasta el momento y pedirle su opinión sobre las conclusiones alcanzadas en ese
momento.
Una vez realizadas las entrevistas, los datos recopilados se analizaron mediante tabulación
(Wohlin et al., 2012). Los datos se ordenaron en tablas que contienen las características más
relevantes, ver tabla 5.1 y tabla 5.2, y se extrajeron conclusiones del análisis de los mismos.
12

4.2. AMENAZAS A LA VALIDEZ
Tabla 4.1:Ejemplos de preguntas y respuestas de entrevistas.
Pregunta
¿Piensas en la deuda técnica? ¿La deuda
técnica es un problema para usted?
Respuesta
Sí, pero no se discute en esos términos. Sí,
hay problemas con la confiabilidad debido a
la falta de pruebas.
Refactorizamos continuamente el código en torno
a los puntos donde trabajamos para mantener el
código base en buen estado.
Sí, especialmente si los desarrolladores abandonan la
empresa.
¿Cómo se aborda la deuda técnica a lo largo del
tiempo?
¿Cree que la deuda técnica se convertirá
en un problema en el futuro?
4.1.3 Evaluación de software
Durante el proyecto se evaluaron varias herramientas de software diferentes para monitorear la deuda
técnica y otras métricas de software. Como el desarrollo del caso principal solo se realizó utilizando Ruby
on Rails, no fue posible evaluar herramientas basadas en otros lenguajes en el caso principal. Para estas
soluciones, en su lugar se descargaron y analizaron proyectos de código abierto.
Para los diferentes productos, se centraron en los siguientes aspectos:
• El precio de la solución, ¿sería factible que un pequeño taller de desarrollo gastara
el dinero necesario para hacer uso del producto?
• El alcance de la solución, cuánta configuración se requirió para comenzar a utilizar el software. Los
requisitos de configuración excesivos perjudicarían seriamente a una startup lean a la hora de
centrarse en el producto, que es ortogonal al proceso lean.
• Los requisitos de mantenimiento, al utilizar la solución, requirieron mano de obra continua
para que fuera útil y, de ser así, en qué medida.
• ¿Los comentarios que brindó la herramienta fueron útiles para los desarrolladores? ¿Proporcionó
cantidades excesivas de información o muy poca? ¿Fueron comunes los falsos positivos? ¿Podrían
evitarse fácilmente, etc.?
4.2 Amenazas a la validez
Esta sección considera las amenazas a la validez del estudio realizado de acuerdo con los cuatro
aspectos de las amenazas a la validez establecidos por Wohlin et al. (2012).
Validez de constructo.La validez de constructo es la amenaza que supone la visión de los investigadores de
que el tema no está siendo investigado adecuadamente por las herramientas seleccionadas para el estudio
(Wohlin et al., 2012). Como la herramienta de muestreo utilizada en este estudio fueron las entrevistas, el
concepto de deuda técnica se discutió antes de la entrevista para asegurarse de que el entrevistado tuviera la
13

4.2. AMENAZAS A LA VALIDEZ
misma comprensión del tema. También las preguntas abiertas fueron una parte
importante para garantizar que al sujeto se le permitiera expresar información
tangencial sobre el tema y explicar sus puntos de vista a fondo (Hove y Anda, 2005).
Validez interna.La validez interna se refiere a cómo se vincula el tratamiento con el resultado
y si el investigador ha pasado por alto otros factores además del investigado al analizar los
resultados. La mayor amenaza interna es el sesgo de selección, que siempre es una amenaza
cuando los sujetos no se eligen al azar.
Las amenazas relacionadas con la instrumentación se evitaron utilizando una técnica de entrevista
probada (N. Denzin, 2000; Hove y Anda, 2005) y permitiendo que las empresas seleccionaran a la
persona a entrevistar (aumentando la aleatoriedad de los sujetos).
En el caso principal se utilizó la investigación-acción como método de investigación. Dado que los
investigadores participaron e influyeron en el proceso y lo estudiaron al mismo tiempo, existen riesgos
de sesgo y características de los recolectores de datos (Onwuegbuzie, 2000). El sesgo del recopilador de
datos se produce cuando los investigadores favorecen un grupo o resultado y, por lo tanto, consciente o
inconscientemente, sesgan los datos en esa dirección. Las características del recopilador de datos se
refieren a las características de las personas que realizan la recopilación de datos. Características como la
edad, el género, la cultura, etc. pueden influir en el tipo de datos que se recopilan (Onwuegbuzie, 2000).
Validez externa.La validez externa es la capacidad de generalizar los hallazgos a la población
general. En este informe esto sería si los hallazgos son válidos para startups más allá de las
investigadas. Como se trata de un estudio cualitativo, no se puede replicar de forma idéntica en
una fecha posterior; en cambio, la intención es estudiar y explicar los fenómenos y patrones
subyacentes encontrados. La mayor amenaza para la generalización del estudio es el hecho de que
todas las empresas entrevistadas estaban ubicadas en el área de Gotemburgo en Suecia y, como
tal, la cultura laboral sueca puede influir en los resultados. Esto se mitiga en parte entrevistando
también a un coach de startups en los Países Bajos.
Los resultados del caso primario pueden tener una baja generalización debido al método de investigación
utilizado. Se sabe que la investigación cualitativa tiene una baja generalización, principalmente debido a los
pequeños tamaños de muestra, lo que produce una baja significación estadística. Esto se ve mitigado por los
hallazgos en los casos secundarios, es decir, las entrevistas.
Fiabilidad.La confiabilidad se refiere a la dependencia entre los datos y los investigadores que
realizan el estudio (Wohlin et al., 2012). Por ejemplo, ¿el estudio arrojaría los mismos resultados si
otros investigadores intentaran replicarlo?
Dado que las entrevistas se realizaron de forma semiestructurada al entrevistar a las empresas,
surgieron preguntas y debates que no estaban planificados de antemano. Es posible que no todas
las discusiones y preguntas de la entrevista se reflejen en el informe. Si otros investigadores
realizaran las entrevistas en otras empresas, es probable que no surgieran las mismas preguntas,
lo que arrojaría resultados ligeramente diferentes.
14

5 resultado
El siguiente capítulo presenta los resultados del estudio, incluido el software evaluado, un
resumen del caso principal y entrevistas a la empresa.
5.1 Software evaluado
Durante el estudio de caso, se evaluaron multitud de software para analizar la calidad del código y
ayudar con el desarrollo de software.
5.1.1 Sonda
Sonar es una solución de software muy completa con muchas funciones, configuraciones y
personalizaciones. Desafortunadamente, es relativamente caro si necesita complementos comerciales.
Por ejemplo, si su proyecto está escrito en VB.NET, necesita complementos comerciales que cuestan
aproximadamentemi6.000 por año. Puede que esto no sea un coste enorme para una gran empresa,
pero para una startup con recursos muy escasos es muy caro. Por otro lado, si puedes arreglártelas con
los complementos gratuitos y la versión gratuita de Sonar, esto no es un problema. Sin embargo, el
equipo aún necesita dedicar tiempo a instalar, configurar e integrar el software en el flujo de trabajo
para aprovecharlo al máximo. Puede que esto no lleve mucho tiempo para un usuario experimentado,
pero para alguien que nunca haya usado Sonar puede resultar un poco abrumador y difícil de realizar
correctamente.
En el caso principal de este estudio se utilizó el lenguaje Ruby. Sonar no tiene soporte oficial para Ruby
por lo que no se pudo utilizar directamente en este proyecto. Existe un complemento de código abierto
desarrollado por PICA Group (2013) para el lenguaje de programación Ruby; sin embargo, es inadecuado
al admitir solo un pequeño subconjunto de las métricas necesarias para una evaluación útil de la calidad
del código.
Para evaluar Sonar se analizó un proyecto escrito en un lenguaje soportado por Sonar. Se
eligió el proyecto Storm (Storm, 2013), escrito mayoritariamente en Java. La instalación
incluye descargar el código fuente, configurar la base de datos e iniciar Sonar desde la línea
de comandos. Para ejecutar el análisis hay varios clientes disponibles. Para esta evaluación se
utilizó el Sonar Runner predeterminado, pero hay clientes disponibles para integración con
sistemas CI como Jenkins, Hudson, Bamboo y más.
Sonar se ejecuta como un servidor web y la mayor parte de la configuración se puede realizar
directamente en la interfaz web. Hay una gran cantidad de opciones donde puedes configurar perfiles de
calidad, ajustes de cifrado, paneles, usuarios y más. La sección de configuración es un poco abrumadora
y se dejó como predeterminada para esta evaluación. El complemento SQALE v.1.7 (SonarSource, 2013C)
se instaló para el análisis técnico de la deuda.
15

5.1. SOFTWARE EVALUADO
Hubo algunos problemas en los que la herramienta de análisis no pudo analizar el código fuente, por lo
que algunos archivos tuvieron que excluirse manualmente del análisis. Cuando se completó el análisis,
se configuró un panel con algunos widgets que muestran información sobre deuda técnica, violaciones
de estándares de codificación, calificación SQALE y más, como se muestra en la figura 5.1. El panel
muestra información de alto nivel, pero puede profundizar para ver exactamente qué código está
causando los problemas.
Figura 5.1:Panel de control en Sónar.
Cuando todo está configurado e integrado en tu proceso, Sonar funciona bastante bien. Sin
embargo, es importante configurar los paneles de manera que no se ensucien ni se
sobrecarguen con información. El costo de configurar Sonar e integrarlo en su flujo de trabajo
variará mucho según la experiencia previa y los complementos que necesite. Si es una startup
y no tiene experiencia previa con el software y necesita complementos comerciales costosos
para utilizar la herramienta, probablemente no valga la pena.
5.1.2 EMITIR AIP
CAST Software se centra principalmente en grandes empresas y corporaciones. Para este estudio,
los autores no tuvieron acceso a Cast AIP para realizar una evaluación más exhaustiva.
dieciséis

5.1. SOFTWARE EVALUADO
5.1.3 Código Clima
Code Climate es mucho más simple que sus competidores. Sin embargo, es mucho más fácil
de entender y más rápido para empezar. No requiere ninguna configuración más que los
derechos de pago de su repositorio git. El precio es bajo y comienza en $34USD/mes para 2
usuarios (excluyendo el monitor de seguridad), $74USD/mes para 8 usuarios (incluido el
monitor de seguridad) y hasta $399USD para 32 usuarios (Code Climate, 2013). Dado que es
muy fácil comenzar, intégrelo en su proceso junto con su bajo precio, encaja perfectamente
en una startup.
La interfaz es limpia y sencilla. Tiene un panel con un feed donde todos los cambios se enumeran
cronológicamente, muestra puntos de acceso y un gráfico de las calificaciones de sus clases, como
se ve en la figura 5.2. Es fácil navegar por las diferentes áreas y encontrar dónde están los
problemas en su proyecto. Además, cada semana se envía un correo electrónico con un resumen
de los cambios de la semana pasada. El resumen incluye tanto los nuevos problemas que han
surgido durante la semana como las mejoras. Este resumen garantiza que no se olvide del sistema
y conciencia al equipo sobre el estado de su aplicación.
Figura 5.2:Panel de control en Code Climate.
Sin embargo, Code Climate carece de muchas otras áreas. No admite ningún otro lenguaje que no sea Ruby y
solo realiza análisis en archivos de código Ruby puro (no plantillas). No puede analizar la cobertura de las
pruebas y los problemas que plantea, aunque en la mayoría de los casos son válidos, pueden ser difíciles de
identificar ya que la herramienta no siempre dice exactamente qué o dónde están los problemas. Por ejemplo,
puede indicar que una definición de clase específica es demasiado compleja, pero no exactamente qué parte
de ella o cómo mitigarla.
17

5.2. CASO PRIMARIO
En el monitor de seguridad es posible marcar un problema como “falso positivo” para ignorarlo en
el futuro. Esto no es posible en la sección de calidad del código, lo que significa que si no está de
acuerdo con Code Climate sobre un problema, no puede ignorarlo manualmente. Si hay muchos
desacuerdos, los temas que le interesan pueden perderse entre los que no le interesan.
5.2 Caso primario
Alice es una startup con sede en Gotemburgo, Suecia, que desarrolla software que las empresas pueden
utilizar para gestionar la salud y la seguridad. El equipo está formado por cinco personas; tres desarrolladores
de negocios y dos desarrolladores de software. La empresa comenzó como un proyecto de tesis de maestría en
la Universidad Tecnológica de Chalmers por parte de los desarrolladores comerciales y, una vez que se decidió
el producto, se contrató a los desarrolladores para crear un MVP. Puede encontrar más información sobre Alice
en la sección 2.4.
5.2.1 Proceso
Alice trabaja de forma ágil y sigue la metodología Lean Startup. Dado que el equipo es bastante pequeño
y todos están sentados muy juntos, la comunicación es muy sencilla y las reuniones formales son en su
mayoría superfluas. La empresa utilizó maquetas en papel y HTML antes de que comenzara el desarrollo
del MVP. Para realizar un seguimiento de las funciones que se implementarán, se utiliza el sencillo
tablero de tareas en línea Trello. No se utiliza el desarrollo basado en pruebas, pero se escriben pruebas
para la mayoría de las funciones, especialmente para las áreas de la aplicación críticas para el negocio y
relacionadas con la seguridad. Alice ejerció la programación en pares al principio, pero ahora se usa
raramente ya que solo hay dos desarrolladores y uno se enfoca en la aplicación web mientras que el otro
se enfoca en la aplicación móvil.
5.2.2 Deuda Técnica
No creen que la deuda técnica sea un problema todavía ya que su MVP aún está en desarrollo. Sin
embargo, creen que puede convertirse en un problema en el futuro, especialmente si la empresa
decide girar o los desarrolladores son reemplazados. Alice cree que la deuda más importante que
tienen es la falta de pruebas y documentación, arquitectónicamente el diseño es sólido hasta el
momento.
Alice no tiene ningún estándar de codificación formal definido, sino que simplemente sigue las mejores prácticas de
Ruby. Sin embargo, tienen algunas pautas informales con respecto a la complejidad del método, comentarios, etc. Las
revisiones manuales de código no se utilizan de manera formal hasta ahora. La base del código es todavía bastante
pequeña, por lo que los desarrolladores revisan continuamente las contribuciones de los demás a medida que se
realiza el trabajo. Además, no han considerado necesario crear ninguna documentación externa.
18

5.3. DATOS DE LA ENTREVISTA
para su aplicación. En lugar de eso, intentan escribir código claro y autodocumentado, agregar comentarios
cuando corresponda y utilizar los registros de confirmación.
El equipo utiliza Code Climate (lea más sobre Code Climate en la sección 5.1.3) para realizar un
seguimiento de la calidad del código, aunque todavía no se centra en optimizarlo. Lo revisan
continuamente para asegurarse de que la calidad no se salga de control, pero planean usarlo más
cuando su MVP se haya estabilizado.
5.3 Datos de la entrevista
5.3.1 Jan Salvador van der Ven
Jan Salvador van der Ven es estudiante de doctorado en la Universidad de Groningen y un
entusiasta ágil. Tiene formación académica pero también experiencia trabajando en la
industria. Tiene experiencia trabajando como líder de equipo, Scrum Master y Agile Coach.
Actualmente trabaja como Agile Coach en las empresas Factlink y Crop-R.
Proceso
En las empresas en las que Jan ha estado involucrado, el nivel de planificación varió mucho. Algunas
empresas planificaron durante varios meses antes de iniciar el desarrollo y otras tardaron una semana
en planificarlo. Sin embargo, siempre estuvo presente algún nivel de planificación.
La mayoría de las empresas tenían algún tipo de versión beta o piloto para probar su idea en clientes
potenciales. Utilizaron iteraciones cortas y de hecho construyeron un prototipo funcional. Muy a menudo, los
prototipos se reutilizan y evolucionan hasta convertirse en el producto final. Las maquetas en papel rara vez se
utilizaban más que como herramienta de diseño.
Todas las empresas utilizaban procesos de desarrollo ágiles que implicaban sprints cortos en equipos
pequeños. Todos redactan algunas pruebas, aunque la cantidad varía entre las distintas empresas. Un
punto en común fue que todos escribieron pruebas unitarias pero tuvieron problemas con las pruebas
de integración.
La programación en pareja se utilizó ocasionalmente, pero sólo cuando los desarrolladores decidieron trabajar en
pareja para resolver un problema complejo. Según su experiencia, muchos propagadores ágiles quieren que la
programación por pares se utilice todo el tiempo, pero en realidad eso no siempre funciona.
Deuda técnica
En las empresas en las que participaba Jan, se utilizaba algún software para realizar un seguimiento de la calidad del
código. Sin embargo, ninguna acción se basó realmente en estos datos. En su lugar, un desarrollador senior revisa el
código que se agrega revisando los registros de confirmación. Un problema con esto es
19

cuando el desarrollador senior está demasiado ocupado, no se revisará todo el código. A través de estas
revisiones, se espera que el desarrollador senior pueda descubrir cuándo se agrega deuda técnica o dónde
existen riesgos de que surja.
La deuda se generaba con mayor frecuencia a través de soluciones rápidas, como omitir pruebas o cambiar el
producto para satisfacer la demanda de un cliente en particular, algo que luego tenía que generalizarse para
que fuera útil para la base de clientes o reevaluarse. Este tipo de soluciones rápidas que encuentra son más
comúnmente la fuente de errores, mientras que los problemas arquitectónicos ralentizan el desarrollo.
Jan argumentó que si evitas todas las deudas y haces todo correctamente desde el principio, te
volverás lento y perderás parte de tu agilidad. Por otro lado, a medida que la deuda crece, también
se pierde velocidad y agilidad, por lo que hay que hacer una concesión. En una startup con
recursos escasos muchas veces no puedes permitirte hacer todo bien desde el principio. Necesitas
lanzar el producto al mercado rápidamente y más adelante, cuando tengas clientes que paguen,
podrás estar más relajado e implementar las cosas correctamente.
5.3.2 Apelación
Appello es una empresa que trabaja en el desarrollo de soluciones de mapas de navegación
dirigidas a dispositivos móviles. Sus principales clientes son operadores telefónicos que licencian
sus mapas y los comercializan ellos mismos. El prototipo inicial comenzó a desarrollarse en 2004
en el tiempo libre de los desarrolladores y lo lanzaron en 2006 y desde entonces ha expandido
gradualmente su negocio.
Proceso
El equipo técnico de Appello está formado por 8 desarrolladores, utilizan Scrum con iteraciones de tres
semanas y tienen un desarrollador deshonesto asignado al mantenimiento que utiliza un proceso Kanban para
corregir errores, etc. Consideran que esta división es una excelente manera de gestionar el mantenimiento.
También han descubierto con el tiempo que para utilizar Scrum de forma efectiva toda la organización, no sólo
la parte de desarrollo, necesita estar afinada y educada sobre el proceso, por ejemplo para que el personal de
ventas no venda características que no encajen en el proceso. sprint actual.
Como Appello es una de las empresas más antiguas entrevistadas, la diferencia entre cómo trabajaron
inicialmente y más adelante en el ciclo de desarrollo es un tema importante. Durante los primeros dos
años utilizaron un estilo de programación vaquero en el que no había un proceso definido, pero cuando
Scrum comenzó a hacerse popular en 2008, cambiaron a él y lo han mantenido desde entonces.
Tienen algunas pruebas en el lado del servidor del software, pero no las encuentran muy útiles. Dan
lugar a muchos falsos positivos y requieren mucho esfuerzo para mantenerlos y actualizarlos a medida
que evoluciona el producto. Si bien no existen demandas formales de documentación, intentan
mantener todo el código documentado.
20

También hacen uso de una wiki para documentar los ajustes realizados para diferentes clientes,
esto es muy útil cuando el sistema falla en medio de la noche y solo el desarrollador de guardia
está disponible, ya que él o ella puede pasar por alto fácilmente lo que es diferente del solución
estándar en el sistema.
Deuda técnica
Porque es muy difícil, si no imposible, actualizar las versiones implementadas del software instalado en
los teléfonos móviles, y todavía hay dispositivos con las versiones 2006 y 2007 del software en uso. Esto
significa que necesitan conservar la compatibilidad con versiones anteriores durante mucho tiempo, lo
que los obliga a conservar muchos códigos antiguos para comunicarse utilizando los protocolos
antiguos. Sin embargo, no dedican tiempo a mantener esto, por lo que no genera gastos generales
significativos, incluso si constituye una gran deuda técnica. Por el contrario, para el lado del servidor,
Appello tiene un entorno de implementación simple; aquí encuentran que la capacidad de actualizar
rápidamente el backend y resolver problemas reduce la carga de cualquier deuda técnica y soluciones
rápidas, ya que puede parchearlas rápidamente.
A menudo se ven obligados a hacer concesiones en las soluciones para cumplir con los plazos de los
clientes, algo que siempre les genera reacciones negativas más adelante en el proceso. Encuentran que,
a menudo, cuando tienes poco tiempo y haces arreglos rápidos, tampoco tienes tiempo para
documentarlos, y cuando se encuentran después de unos meses o algunos años, es más difícil de
arreglar debido a esto.
Hacen uso de herramientas de análisis estático para mantener bajos los errores; esto se hizo inicialmente debido a la
demanda de los clientes de obtener un informe de la tasa de error de la base del código. Pero han encontrado que las
herramientas son muy útiles para detectar errores latentes en el código base y hacer un uso regular de ellas desde su
introducción.
Si tuvieran la oportunidad de empezar de nuevo, cumplirían mucho más con los estándares de los
protocolos. El uso de comunicación estandarizada hace que sea más fácil conectar diferentes sistemas de
maneras que no fueron concebidas inicialmente (por ejemplo, para pruebas de integración). Por el
mismo motivo, también les hubiera gustado que el sistema fuera más modular desde el principio.
5.3.3 Burto
Burt es una empresa activa en el negocio del marketing que ofrece estadísticas y análisis detallados a
publicistas de publicidad online a gran escala. Su negocio principal es unir la analítica de los sitios web
(páginas vistas, actividad,...) con información de los sistemas empresariales como los ingresos.
Inicialmente estaban dirigidos a agencias de publicidad y dedicaron 9 meses a desarrollar el producto
inicial en estrecha comunicación con sus socios. Su esperanza inicial era ayudar a las agencias de
publicidad a crear mejores anuncios, pero después de un año se dieron cuenta de que su producto era
más adecuado para satisfacer las necesidades del editor de anuncios y cambiaron el enfoque mediante
un giro menor.
21

Proceso
Burt trabaja sin ningún proceso formal pero aún de manera ágil, etiquetada por ellos como “Ad-hoc
Agile”. Lo describen como algo parecido a "Kanban". En ocasiones han intentado hacer Scrum, pero
descubren que el proceso no es compatible con su metodología de desarrollo lean. Lean requiere que
usted presente alternativas rápidamente y repita solo lo que funciona, lo que hace difícil tener
iteraciones de longitud significativa con objetivos establecidos en mente. Creen que la razón por la que
tienen la capacidad de trabajar sin ningún proceso formal es gracias a su pequeño equipo de
aproximadamente 10 desarrolladores.
Tienen la ambición de probar todo su código, pero todos los miembros del equipo no lo ven como un
aspecto necesario del desarrollo. No creen que obligar a estos miembros del equipo a escribir pruebas
sea productivo, sino que cada desarrollador se da cuenta de los beneficios por sí mismo. En cuanto a la
documentación, hay una diferencia de opinión en el equipo pero el punto de vista de los entrevistados
fue que los comentarios del código son una señal de que el código no es lo suficientemente
comprensible. Los comentarios también se olvidan fácilmente mientras el código cambia y acaban
quedando obsoletos con el tiempo, lo que los convierte en un obstáculo más que en una ayuda.
No utilizan ninguna herramienta de análisis estático y creen que los programadores inteligentes y perezosos pueden eludirlas
con demasiada facilidad como para que sean de utilidad real. Es posible que los desarrolladores individuales los hayan
utilizado como una herramienta para promover el crecimiento personal del conjunto de habilidades.
Deuda técnica
Durante el desarrollo, el concepto de deuda técnica suele estar presente en sus mentes, aunque
no hablan de ello por su nombre, sino que todos tienen conciencia de qué partes del código
carecen de calidad.
Su método para evitar nueva deuda técnica está fuertemente orientado hacia Lean. Prefieren
hacer prototipos de nuevas funciones que puedan mostrar al cliente sin escribir ningún
código real y, si lo consideran útil, pueden desarrollarlo más adelante. Cualquier tiempo
dedicado a escribir código de calidad para el sistema que luego será desechado se considera
una gran pérdida de tiempo.
El entrevistado distingue entre lo que llama “deuda técnica incidental” y deuda técnica regular.
La deuda incidental es lo que se crea sin que el equipo esté consciente, cuando se toman
atajos para cumplir con una fecha límite, mientras que el tipo regular de deuda técnica se crea
con discusión y conciencia por parte de los miembros del equipo. El tipo de deuda incidental
es mucho más peligrosa ya que no se sabe cuánto existe y disminuye la capacidad del equipo
para ser ágil con las decisiones en el futuro.
22

5.3.4 Duego
Duego es una red social dirigida principalmente al mercado brasileño. La empresa se fundó
en 2010 y obtuvo capital de inversión para financiar el desarrollo en 2011.
El producto se desarrolló durante 6 meses durante 2011 antes de su lanzamiento. Como el lanzamiento
estuvo acompañado de esfuerzos de marketing, sintieron que era necesario tener un producto confiable
y funcional desde el principio. Los fundadores hicieron varias maquetas para presentar visualmente a los
desarrolladores cómo imaginaban que funcionaría el servicio y definir la funcionalidad del producto.
El servicio se implementó por primera vez en PHP ya que era con lo que los desarrolladores iniciales se
sentían cómodos. Después de un giro en el que se reorientaron para tener varias interfaces además de
su sitio web, reescribieron todo el sistema en Python Flask, haciendo que la web y los dispositivos
móviles sean ciudadanos iguales a su API.
Proceso
Duego trabaja con un proceso basado en Scrum. Inicialmente utilizaron iteraciones de dos semanas,
pero pasaron a una semana para afrontar mejor los rápidos cambios en los requisitos. Ven la falta de
proceso como una señal de un problema de priorización en la empresa; si no puede comprometerse a
dejar que los desarrolladores hagan lo suyo durante períodos de 1 a 2 semanas, debe reconsiderar lo
que está haciendo.
Tienen un fuerte compromiso con la redacción de pruebas, incluyendo siempre pruebas de las
características que han agregado en las confirmaciones. Ocasionalmente escriben pruebas antes de
escribir el código, pero esto varía según el desarrollador y lo que se va a implementar. Su
documentación está completamente en el código, excepto la API que exponen a sus clientes. Los
ejemplos en la documentación de la API también se prueban junto con la ejecución de pruebas
periódicas en su sistema de compilación. Esto garantiza que los ejemplos funcionen como se anuncia
cuando se prueban en producción.
Deuda técnica
Acumularon una gran deuda técnica a medida que el producto evolucionó durante los primeros
dos años, ya que todo su frontend y backend se unificaron en una aplicación PHP gigante.
Finalmente, decidieron reescribirlo todo cuando estaban girando, ya que reutilizar la aplicación
PHP para la nueva visión sería más trabajo que hacerlo de nuevo.
Tienen un fuerte compromiso con las pruebas y la calidad del código, que se refuerza mediante
revisiones de código antes de entrar en producción y no permiten que nadie se salte las pruebas de
escritura. Sin embargo, encuentran que es raro que tengan tiempo para realizar refactorizaciones
importantes de áreas del código que no son ideales, pero son conscientes de dónde residen los
problemas y no lo consideran un problema inminente.
23

En cuanto a cuestiones futuras, consideran sostenible su método actual. La cultura de la empresa
garantiza que el nuevo código cumpla con sus estándares y es muy raro que tengan que hacer
concesiones para cumplir con las fechas de lanzamiento u otras demandas.
5.3.5 NetClean
NetClean es una empresa más antigua que la mayoría de los entrevistados, ya que se fundó hace
diez años, en 2003. El entrevistado fue contratado como desarrollador en 2005 y ha estado en la
empresa desde entonces. NetClean produce software que puede detectar pornografía infantil en
computadoras y sistemas en red. Venden el software a empresas y su objetivo es que la instalación
del software sea un factor de higiene en cualquier lugar de trabajo.
La idea ha sido la misma desde el principio, pero la cartera de productos se ha ampliado con productos
adicionales, como la integración del servidor de correo y la inspección profunda de paquetes de la red.
Proceso
Tradicionalmente, NetClean ha estado operando bajo un estilo de programación vaquero, en el que los desarrolladores
eligen tareas para completarlas ellos mismos. Sin embargo, últimamente han estado avanzando hacia Scrum a medida
que el equipo está creciendo hasta alcanzar el tamaño en el que la metodología se vuelve importante. El principal
problema que tenían con el estilo antiguo era que a medida que crecía el tamaño del equipo, era más difícil realizar un
seguimiento de lo que hacían los demás y, a veces, sucedía que las personas captaban la misma historia de usuario por
error u otros enfrentamientos similares.
Tienen dificultades para crear prototipos de su software, porque se implementa en las
computadoras de los clientes, lo que hace más difícil implementar actualizaciones con frecuencia, y
porque es importante que el sistema funcione correctamente.
Probar el software en un entorno de producción es difícil debido a la naturaleza del producto.
Históricamente no se han centrado mucho en las pruebas, pero ahora están avanzando hacia más
pruebas; muchas partes del código antiguo no son adecuadas para las pruebas y se reemplazan a
medida que se encuentran. No tienen pautas para las prácticas de prueba o documentación, sino
que es una digresión propia de cada desarrollador. Sin embargo, tienen manuales de usuario
actualizados para sus clientes.
Deuda técnica
NetClean ha estado experimentando los problemas de una creciente deuda técnica durante mucho tiempo a
medida que los desarrolladores se trasladaron a diferentes partes del negocio y el producto creció. Gestionan la
deuda de forma continua mediante una refactorización gradual. Como partes del producto inicial se codificaron
en Visual Basic y desde entonces el equipo pasó a codificar principalmente en C#, las partes más antiguas se
identifican fácilmente. Una regla general es no actualizar el código de Visual Basic.
24

sino reemplazar el módulo con uno basado en C#, esto significa que la refactorización es una parte
integral del esfuerzo de desarrollo.
Nunca sintieron la necesidad de detener por completo la implementación de funciones para trabajar en la
mejora del código base existente. Sin embargo, a medida que han crecido, tienen más flexibilidad para realizar
mejoras en el código, ya que tienen un conjunto de clientes más diverso y no necesitan escuchar todos los
caprichos y cumplir con cada solicitud. En cambio, pueden dedicar más tiempo a hacer las cosas bien en lugar
de hacer concesiones. Recientemente, también comenzaron a utilizar herramientas de análisis estático para
cuantificar las mejoras que se realizan en el código base. Consideran que la herramienta es útil para
asegurarse de que haya mejoras, pero la gran cantidad de errores existentes hace que sea una tarea
demasiado desalentadora intentar eliminar todos los problemas técnicos.
No tienen muchas pruebas para el código del lado del cliente y tampoco intentan completarlo directamente
con el código existente, ya que en muchos casos es difícil probar el código que no se escribió teniendo en
cuenta las pruebas. En cambio, la mayoría de las pruebas se realizan manualmente y actualmente están
intentando establecer un proceso de preguntas y respuestas dedicado.
Rara vez necesitan hacer cambios importantes en el código existente, pero la gran cantidad de pequeños
problemas se convierte en un problema cuando ese es el caso. Hacer grandes esfuerzos de refactorización es
mucho más difícil cuando los problemas están en todas partes, cuando comienzas a refactorizar la cantidad de
cosas que deben cambiarse sigue creciendo incluso si solo estás tratando de mejorar una pequeña parte del
producto.
5.3.6 Pago Puggle
PugglePay es una nueva empresa en Gotemburgo que se especializa en pagos y facturación de
servicios a través de la web. La empresa se fundó en 2011 y hoy cuenta con tres desarrolladores de
tiempo completo y cuatro durante las etapas iniciales de desarrollo. Cuando trajeron a los
primeros desarrolladores, los fundadores ya habían planeado mucho creando historias de
usuarios, etc. Los fundadores tenían experiencia previa en este tipo de negocios, por lo que sabían
mucho sobre quiénes eran los clientes y qué querían. Esto les llevó por el camino correcto desde el
principio y pudieron conseguir su primer cliente tan sólo cuatro meses después de que comenzara
el proyecto.
Proceso
La empresa intenta tener un enfoque pragmático en su forma de trabajar. Trabajan de forma ágil
pero no utilizan ningún proceso formal, sino que seleccionan diferentes partes de diferentes
procesos, como Scrum, y utilizan lo que funciona bien en su equipo. En su proceso utilizan Pivotal
Tracker para la gestión y priorización de historias de usuarios.
Dado que trabajan en el ámbito financiero, creen que es importante tener un sistema de alta
calidad bien probado. Debido a esto, prueban la mayor parte de su código, a veces antes de
escribir la implementación, pero más a menudo después. Además, para aumentar la calidad de la
25

código, hacen uso de revisiones de código. Si un desarrollador ha escrito una característica solo, otro
desarrollador la revisa antes de fusionarla con el resto del código. Si una característica se desarrolla en una
sesión de programación en pareja, no sienten la necesidad de una revisión por separado, a menos que sea una
característica compleja e importante.
Tienen una documentación API pero no documentan el código en sí de manera estricta. Hacen uso de la
implementación continua y envían sus cambios a producción con frecuencia, confiando en que sus
pruebas detectarán los problemas antes de que entren en funcionamiento.
Deuda técnica
PugglePay cree que la deuda técnica es un tema importante en el ámbito en el que trabajan. La
filosofía que tienen es que no se convierte en un gran problema siempre que usted sea consciente
de ello. Cuando uno se endeuda, compra agilidad por el momento pero sacrifica agilidad futura.
Cuando realizan cambios en el código, intentan refactorizar el código a su alrededor. Al hacer esto,
aumentan la calidad de su código y evitan cierta deuda técnica.
La empresa cree que la mayor parte de su deuda proviene de grandes cambios en su API. Al
principio, sobredimensionaron partes del sistema y la API no era tan flexible como tenía que
ser. La API ha sido reelaborada varias veces y ahora tienen tres versiones diferentes de API
para administrar y han comenzado a trabajar en una cuarta versión.
PugglePay no utiliza comentarios de código en su base de código habitual, ya que se cree que esto es una
señal de que el código es demasiado complejo. Sin embargo, utilizan comentarios para documentar las
funciones de la API. Estos comentarios se utilizan para generar un sitio web independiente con documentación
de la API para sus clientes. Además, los comentarios incluyen ejemplos de código que se extraen y ejecutan
como pruebas.
5.3.7 Futuro registrado
Recorded Future se fundó en 2009 en Gotemburgo, Suecia. Hoy tienen una sede en Cambridge y
oficinas en Gotemburgo y Arlington, VA. Los fundadores trabajaron en el proyecto durante entre
12 y 18 meses como proyecto paralelo antes de ponerse en contacto con los inversores y poder
trabajar en él a tiempo completo. Al principio se centraron principalmente en negocios financieros,
pero después de un tiempo cambiaron su enfoque a la inteligencia empresarial, ya que se
adaptaba mejor a su producto. Hoy sus clientes son en su mayoría grandes corporaciones y
organizaciones nacionales.
Proceso
Recorded Future utiliza una variante de Scrum como proceso de desarrollo. Trabajan en pequeños
equipos de 4 a 5 personas en iteraciones de dos semanas. Al principio, la empresa no utilizaba ningún
método formal, pero a medida que la empresa creció, se fueron añadiendo métodos más formales.
26

Los desarrolladores no utilizan el desarrollo basado en pruebas, pero sí escriben pruebas unitarias
para las partes del software que consideran apropiado. Sienten que ésta es un área en la que
necesitan mejorar y planean hacerlo en proyectos futuros.
Las revisiones de código no forman parte del proceso de trabajo habitual de Recorded Future. De vez en
cuando realizan algunas revisiones, pero sólo si un desarrollador lo solicita activamente. La programación en
pares también es algo que se usa a veces, pero no de manera formal y solo cuando un desarrollador siente la
necesidad de hacerlo.
Recorded Future utiliza los servicios en la nube de Amazon y, a menudo, implementa código nuevo varias veces
al día. Usan recetas de Chef para administrar sus servidores y pueden enviar fácilmente diferentes códigos a
diferentes nodos que tienen roles específicos.
Deuda técnica
Recorded Future no cree que la deuda que tienen sea un gran problema. Ayuda que su sistema principal
sea global, lo que facilita su mantenimiento y actualización sin problemas heredados. Sin embargo,
tienen algunos clientes con instalaciones locales que son un poco más problemáticas. La mayor parte del
sistema es configurable, de modo que cuando prueban una nueva característica pueden probar tanto el
código nuevo como el antiguo al mismo tiempo. Un problema con esto es que una gran cantidad de
código antiguo queda en el código base y no se limpia cuando se suspende una función antigua. Sin
embargo, no creen que sea un problema ya que el código no está en uso. Piensan que es mejor priorizar
el desarrollo de nuevas funciones que limpiar el código antiguo.
Recorded Future ha realizado algunos cambios tecnológicos desde el principio. Al principio
utilizaron MySQL como base de datos, pero luego se dieron cuenta de que no encajaba bien con su
producto y migraron a Sphinx. Finalmente, también abandonaron Sphinx en favor de Elastic
Search. Creen que estos cambios son parte de la evolución natural de su producto y que la deuda
adquirida no se convertirá en un problema en el corto plazo. Intentan actuar para resolver
problemas reales antes de que surjan y constantemente tienen algunos cambios arquitectónicos
que planean implementar.
La empresa cree que han elegido un buen camino desde el principio. Según experiencias
anteriores, sabían que querían separar la API y no combinarla con la tecnología backend.
Esto les facilitó, por ejemplo, cambiar la tecnología de la base de datos backend cuando
surgieron problemas.
Recorded Future tiene cierta documentación en el código pero ninguna documentación externa aparte
de algunos documentos de diseño. No tienen ningún estándar de codificación formal porque creen que
obligar a sus desarrolladores a adoptar un estándar específico es malo. Los desarrolladores a menudo
convergen con el tiempo hacia un estilo de codificación común. No creen que la calidad del código o la
documentación sean un problema todavía, pero necesitan mejorar en la redacción de pruebas.
27

La empresa no utiliza ninguna herramienta para analizar su código base y cree que
no sería muy beneficioso en su situación actual.
5.3.8 Repuesto
Shpare es una empresa recién fundada que se centra en conferencias y trata de facilitar que las
personas que asisten a la conferencia encuentren quién es interesante para ellos y sus intereses y
reserven una reunión para conocerse.
Shpare se desarrolló inicialmente en el tiempo libre de un solo desarrollador, quien simultáneamente aprendió
Ruby on Rails a medida que se desarrollaba. En ocasiones han tenido más desarrolladores a lo largo del
tiempo.
Proceso
Operan con un enfoque ágil y eficiente, ya que el software se utiliza principalmente durante
conferencias. Los esfuerzos generalmente se concentran en unos pocos días. Se utiliza un tablero de
Trello para gestionar historias de usuarios; inicialmente se probó una solución más estricta basada en
Scrum, pero resultó ser demasiado sobrecargada para ser útil y les impidió hacer las cosas como
querían.
Hacen pruebas pero no de forma rigurosa, las pruebas son principalmente de los sistemas backend y no del
frontend. El código autodocumentado es el objetivo con algunos comentarios para aclarar la lógica compleja,
algo que podría hacerse mejor. Sin embargo, la API del servicio está exhaustivamente documentada, ya que es
fundamental para el negocio.
Deuda técnica
Como Shpare se desarrolló inicialmente cuando el desarrollador se familiarizó con Ruby on Rails, se
cometieron muchos errores. Sin embargo, la versión inicial del producto debería considerarse un
prototipo avanzado, y Shpare consideró que los comentarios sobre esta versión fueron una gran
ayuda para el desarrollo posterior y toda la deuda asociada con ella se disolvió. Después de otro
año de desarrollo, el servicio fue refactorizado en gran medida una vez más con una mejor
arquitectura.
Sería una buena idea realizar pruebas de integración adicionales, ya que hay muchos problemas
con la interrupción de la funcionalidad y nadie se da cuenta. El hecho de que su negocio esté
inactivo y se utilice en ráfagas hace que este sea un problema particularmente pronunciado.
También creen que agregar nuevas funciones antes de saber que la funcionalidad actual funciona
correctamente y que sus clientes la utilizan es una mala idea. Mantener funciones no utilizadas es
un desperdicio de recursos de mantenimiento.
28

Encuentran que la integración continua es una gran ayuda en la gestión de la deuda. Como los problemas se pueden
impulsar instantáneamente si tiene un entorno de implementación potente, los problemas de deuda más visibles no lo
afectarán por un período más largo. Consideran que la deuda arquitectónica es un problema mucho mayor que los
problemas de código y pruebas, ya que eventualmente debe solucionarse, y hacerlo requiere un tiempo y esfuerzo
considerables.
5.3.9 Trimbia
Trimbia es una nueva empresa en Gotemburgo que desarrolla una solución de empresa a consumidor
para gestionar las finanzas. Su objetivo es ser una alternativa ligera a muchos de los paquetes de
software profesionales, tanto en términos de coste como de tiempo. Comenzaron a desarrollar su
prototipo en 2012. Primero lo hicieron como una aplicación HTML pura con algo de JavaScript para
simular la interacción, luego de validar el concepto que se propusieron para construir el MVP en Ruby on
Rails.
Proceso
Trimbia intentó trabajar con un método Scrum poco definido al principio. Tenían iteraciones semanales
acompañadas de reuniones de planificación y un trabajo pendiente sincronizado con casos de uso.
Descubrieron que era una mala elección para la etapa de creación de prototipos, ya que un sprint tiene una
duración demasiado larga para establecer objetivos. Además, como el equipo es bastante pequeño, el proceso
generó más gastos generales que beneficios.
Los dos desarrolladores son propietarios del producto y preguntan a los desarrolladores
comerciales sobre requisitos adicionales a medida que avanzan. También realizaron estudios de
mercado y hablaron con los clientes para comprender mejor lo que construirían más adelante.
Para la calidad del código, tienen pocas pautas, lo consideran innecesario para equipos tan
pequeños como el suyo. Aceptaron sin ceremonias las pautas estándar de Ruby y toda su
documentación está en forma de comentarios del código fuente. Se centran en documentar
estructuras de datos complejas y dejan que el resto del código se documente solo.
No se esfuerzan por realizar un desarrollo basado en pruebas para todo el producto, sino más bien para un pequeño
subconjunto. Principalmente las partes financieras que consideran que deben funcionar correctamente para que el
producto sea viable, y también porque escribir las pruebas ayuda a definir todos los casos especiales.
Deuda técnica
Hasta el momento no han tenido muchos problemas con la deuda técnica. Su producto aún
es joven y sigue la misma arquitectura y utiliza la misma tecnología que imaginaron.
29

5.4. RESUMEN DE LAS ENTREVISTAS
desde el comienzo. La lenta tasa de captación de usuarios también significa que tienen tiempo suficiente para
implementar funciones de la manera "correcta".
Creen que el umbral en el que la deuda técnica se convierte en un problema es cuando el programador
se siente reacio a empezar a trabajar en un fragmento de código debido a los problemas presentes en él,
ya sea siendo la calidad general o la complejidad del mismo un obstáculo importante para modificarlo. .
Sienten que están lejos de este punto débil a partir de ahora, pero piensan que podría convertirse en un
problema mayor si cambian y se imponen mayores cambios en el código.
En general, su enfoque ha sido mantener los componentes del lado del servidor más modulares, mientras que el lado
del cliente es menos refinado. Esto se debe a que creen que el lado del cliente estará sujeto a más cambios a partir de
los comentarios de los clientes, mientras que los cambios del lado del servidor estarán motivados por decisiones
tomadas por ellos mismos.
5.4 Resumen de las entrevistas
Al observar los puntos en común entre las diferentes empresas, se pueden establecer
muchos patrones recurrentes.
La tabla 5.1 muestra las similitudes y diferencias de las empresas y sus procesos. La mayoría de las
empresas se fundaron en los últimos 5 años, siendo Appello y NetClean significativamente más
antiguas. La plataforma más común utilizada fue Ruby on Rails, que es una plataforma popular en
el mundo de las startups en general (Morini, 2011). Las empresas más antiguas usaban Java y C#,
esto se debe al hecho de que los marcos Ruby on Rails y Python Flask no eran lo suficientemente
maduros en el momento de la fundación de las empresas.
La mayoría de las empresas producían soluciones web y todas tenían componentes del lado del servidor que
ellas mismas eran responsables de administrar y actualizar. Las empresas que implementaron aplicaciones o
programas del lado del cliente encontraron que los problemas de deuda técnica eran más preocupantes, ya
que los errores y los problemas no se podían resolver de inmediato; en cambio, el software tenía un
cronograma fijo, lo que significa que el control de calidad era de más importancia. Para los componentes
basados en Internet, todos encontraron muy útil la capacidad de actualizar rápidamente la versión en vivo de
su sitio web o servicio.
Inicialmente, muchas empresas intentaron utilizar Scrum o un proceso similar para impulsar el desarrollo, pero
pocas lograron encontrarlo útil; en cambio, resultó ser una mayor sobrecarga para los esfuerzos de desarrollo.
Muchos describieron las iteraciones como innecesariamente restrictivas cuando se trabaja directamente con
los clientes y los requisitos cambian rápidamente. En cambio, se conformaron con un estilo de programación
vaquero con un tablero de tareas utilizado para realizar un seguimiento de las historias de los usuarios, con un
tamaño de equipo pequeño que permite que todos sean evaluados sobre la priorización y en qué están
trabajando las diferentes personas.
Si se analizan con más detalle el proceso y las cuestiones de deuda en el cuadro 5.2, también se pueden encontrar
factores comunes. Todas las empresas hicieron uso de pruebas hasta cierto punto, principalmente para backend.
30

sistemas e implementaciones. Muchos encontraron que el desarrollo basado en pruebas era demasiado
estricto, tanto en el esfuerzo inicial de escribir las pruebas como también con una menor agilidad, ya que las
pruebas debían actualizarse continuamente con nuevas funciones. Muchos lamentaron no tener suficientes
pruebas, pero consideraron que aplicarla era una herramienta ineficaz debido tanto al tiempo invertido como
al hecho de que los desarrolladores experimentados que se oponen a la metodología pueden solucionarla.
Todos, excepto Appello, consideraron que la documentación era innecesaria. La opinión expresada
fue que rápidamente se volvió obsoleto, y otro sentimiento a favor del código autodocumentado,
algunos mencionaron el libro "The Pragmatic Programmer" (Hunt y Thomas, 1999) como fuente de
inspiración. Hunt y Thomas (1999) sostienen que los comentarios en el código indican que el
código es malo y que se debe esforzarse por escribir un código que sea tan claro y fácil de
entender que los comentarios de bajo nivel se vuelvan innecesarios. Si se utilizan, deberían
reservarse para explicaciones de alto nivel.
Todas las empresas que tenían un servicio API como parte de su oferta comercial fueron rigurosas a la
hora de mantenerlo preciso, viéndolo como una parte fundamental de su servicio. Algunas empresas
también publicaron manuales, principalmente porque su negocio estaba orientado a otros negocios y, al
hacerlo, redujo las solicitudes de soporte.
La mayoría de las empresas no utilizaban directrices de código. Muchos dijeron que las directrices no
son constructivas y pueden dar lugar fácilmente a discusiones entre desarrolladores, encontrando más
útil centrar la energía en el desarrollo del producto.
Los prototipos se utilizaron de manera diferente entre empresas B2B y B2C. Las empresas objetivo
tenían una relación muy estrecha con algunos clientes y se sentían cómodas mostrándoles borradores
extremadamente simples de nuevas funciones y preguntándoles sobre su utilidad. Los que no lo
hicieron, consideraron que su producto era demasiado sensible para presentar versiones incompletas o
simplemente lo consideraron de uso limitado. Por otro lado, el consumidor objetivo utilizó prototipos
junto con métricas para juzgar si se estaba utilizando una característica y, de ser así, cómo, optimizando
el servicio a medida que se desarrollaba. Esto se acerca a la filosofía lean de la creación de prototipos.
Todas las empresas sintieron la necesidad de refactorizar partes del software a medida que se desarrollaban
nuevas funciones, y los desarrolladores a menudo lo hacían por su propia discreción a medida que lo
encontraban. Algunos expresaron los beneficios de no tener plazos de iteración estrictos que permitan a los
desarrolladores dedicar el tiempo necesario a mejorar un determinado sistema. Muchos de los entrevistados
abordaron el hecho de que para los desarrolladores de equipos pequeños es mucho más fácil realizar un
seguimiento de dónde está la deuda y qué se debe hacer para abordarla. Debido a esta aguda conciencia, se
sintieron más audaces al asumir deuda adicional y enfatizaron la importancia de discutirlo dentro del equipo
antes de comprometerse con soluciones subóptimas.
Cuando el tiempo apremiaba y las funciones eran necesarias en muy poco tiempo, todo se veía comprometido, ante
todo, en las pruebas y la documentación (si se usaba). Si eso no fuera suficiente para ahorrar tiempo, simplemente se
saltaron la refactorización de partes desagradables del código y continuaron parcheando las soluciones antiguas.
31

Las empresas que realizaron reescrituras importantes lo hicieron debido a la falta de experiencia
con el entorno desde el principio o como parte de un giro importante, donde la oportunidad de
una reescritura encajaba con la nueva dirección del negocio. Esto les dio el tiempo y la motivación
para realizar los cambios necesarios. Las empresas que no experimentaron un giro importante a
menudo tuvieron un giro menor en el que cambiaron el cliente objetivo; en estos casos, el
producto se mantuvo prácticamente sin cambios.
El único área en la que las empresas lamentaron haber comprometido, o se sintieron particularmente
orgullosas de dedicar tiempo a hacerlo de la manera correcta, fue la de las estructuras y protocolos de datos. Si
inicialmente tenían un diseño de base de datos subóptimo, descubrieron que afectó el desarrollo durante
mucho tiempo después de su concepción y desearon haberlo hecho de una mejor manera inicialmente. Las
empresas que dedicaron tiempo a diseñar las capas de la estructura de datos descubrieron mejor que incluso
si necesitaban cambiar de dirección o de tecnología, era relativamente fácil gracias a la solución ya existente
bien diseñada.
Sólo unas pocas empresas tenían algún conocimiento sobre la metodología Lean Startup y aún menos la
utilizaban. Shpare y Trimbia fueron las únicas empresas que emplearon activamente la metodología.
Comenzaron a vender el producto antes de que fuera desarrollado, utilizaron prototipos, etc. Otras
empresas, como Burt, eran “Lean” en algunas áreas, pero en su mayoría habían crecido hasta
convertirse en el equipo a medida que encontraron formas apropiadas de trabajar, no investigadas ni
empleadas activamente desde el principio, de manera formal Lean Startup.
32

Tabla 5.1:Características de la empresa
Compañía
Apeló
Burt
duego
NetClean
PugglePagar
Futuro grabado
comparar
Trimbia
Tipo
B2B
B2B
B2C
B2B
B2B
B2B
B2C
B2C
Fundado
2004
2009
2010
2003
2011
2009
2010
2012
Tamaño del equipo1
8
≥10
≥15
9
3
≥20
1
2
Proceso
Melé
tipo Kanban
Melé
Melé
Vaquero
Melé
Vaquero
Vaquero
Plataforma2
Java
Rubí
Pitón
C#
Rubí
Java/Scala
Rubí
Rubí
tipo de producto
Soluciones de mapas para móviles
Servicio web, seguimiento de publicidad
Sitio web, Redes sociales
Software, detección de pornografía infantil
SaaS, Facturación
SaaS y licencias3, Agregación de información
Servicio web, redes sociales
Servicio Web, Análisis de flujo de caja
1En este número sólo se incluyen los desarrolladores técnicos.
2El lenguaje de implementación principal, las partes auxiliares como las aplicaciones móviles no se consideran aquí.
3Permitir a los clientes implementar sus propias instalaciones del software para uso privado.
5.4.
RESUMEN
DE
LAS
ENTREVISTAS
33

Tabla 5.2:Características de la deuda de la empresa
Compañía
Apeló
Burt
duego
NetClean
PugglePagar
Futuro grabado
comparar
Trimbia
Pruebas
Limitado5
voluntario7, común
Obligatorio
voluntario
Obligatorio
Limitado
Limitado
Limitado
Documentación
Sí
No
API
Manuales
API
API, manuales
API
No
Creación de prototipos4
No
Sí
A veces
No
No
No
Sí
A veces
Problemas de refactorización
Continuo6
Continuo
Reescritura importante
Continuo
Con derecho preferente8
Continuo
Reescritura mayor dos veces
Continuo
Cambios tecnológicos
No
No
Frasco de PHP a Python
De VB a C#
No
Capa de base de datos dos veces
No
No
4¿Se utiliza la creación de prototipos de forma continua durante el proceso, no sólo al desarrollar la primera versión?
5Pruebas de determinados subsistemas. No integrado en el proceso.
6Los problemas se solucionan cuando interfieren con la implementación de nuevas funciones.
7Algunos desarrolladores lo hacen porque les resulta una herramienta útil. No integrado en el proceso.
8Refactorice el código incorrecto incluso si no es necesario para implementar una nueva característica.
5.4.
RESUMEN
DE
LAS
ENTREVISTAS
34

6 Discusión
Este capítulo es un relato reflexivo de las experiencias adquiridas al trabajar en un estilo lean
startup, el uso de herramientas de análisis estático y una discusión sobre el significado y las
similitudes entre las empresas entrevistadas. A partir de estas fuentes y literatura se presenta una
nueva forma de modelar la deuda técnica. Luego, utilizando este modelo, presentamos un
conjunto de recomendaciones que detallan cómo una nueva startup debe gestionar su deuda y
procesarla.
6.1 Análisis
6.1.1 Problemas de deuda técnica identificados
Esto detalla algunas de las razones por las que las startups acumularon deuda técnica y las razones de las
mismas en un intento de delimitar el alcance del problema e identificar los problemas subyacentes. Los
problemas se enumeran y se hará referencia a ellos más adelante a medida que se presenten diferentes
soluciones.
I Es difícil hablar de deuda técnica.
El primer problema que se identificó al hablar con profesionales de la industria es que, si bien la
deuda técnica es un concepto bien conocido, hay muy poca terminología para discutir sus detalles.
Durante todas las entrevistas los entrevistados tuvieron que empezar desde el principio a describir
diferentes aspectos de su deuda.
Por ejemplo, muchas empresas describieron que no estaban muy preocupadas por la deuda que
estaba visiblemente presente en el código base, como la falta de pruebas o documentación.
Mientras que encontraron problemas de deuda con tecnologías y procesos mucho más dañinos.
Sin embargo, la comunicación fue muy larga y esto es un problema. Los modelos introducidos
previamente por Kruchten et al. (2012) y Fowler (2009) no son una herramienta muy conocida ni
adecuada para decir exactamente qué tipo de deuda tiene una empresa. En cambio, siempre es
necesario describirla en detalle, lo cual es una pérdida de tiempo y podría simplificarse con una
terminología más potente a la hora de clasificar la deuda técnica.
II La deuda que no conoces es peligrosa.
Muchas de las empresas entrevistadas expresaron que no estaban preocupadas por sus
respectivas montañas de deuda técnica por la falta de pruebas, documentación y hackeos
porque estaban conscientes de su presencia.
Lo que en cambio tenían miedo era la deuda que no conocían, ejemplo de esto eran
debilidades de su diseño inicial que aún no habían encontrado, falta de adherencia.
35

6.1. ANÁLISIS
a estándares que no conocían o cómo el giro podría afectar la idoneidad de su
diseño.
III El desarrollo basado en pruebas es demasiado estricto, pero algunas pruebas son buenas.
Todas las empresas entrevistadas y nuestro propio trabajo en el caso principal utilizaron pruebas para el
desarrollo. Pero rara vez se hizo de forma sistemática, ya que se consideró que consumía demasiado
tiempo. En lugar de ello, las pruebas se mantuvieron a un nivel bajo y se centraron en las partes críticas
del sistema que no se podía permitir que fallaran.
Un problema al no escribir siempre pruebas es que los profesionales descubrieron que el código que se había
escrito sin pruebas terminaba con dependencias que hacían que las pruebas unitarias fueran difíciles o incluso
imposibles. Entonces, en una etapa posterior, cuando deseas completar las pruebas, te encuentras con una
base de código para la que es muy difícil escribir pruebas sensatas debido a su complejidad. Por el contrario, si
tiene la mentalidad de escribir siempre pruebas para su código, naturalmente terminará con un código
modularizado con estas dependencias (Janzen y Saiedian, 2008).
IV La complejidad y dificultad en la implementación de su producto hace que el manejo de la deuda sea más
Difícil.
Muchas empresas mencionaron la relación entre su ciclo de lanzamiento y su capacidad para manejar la
deuda. Si su producto es una aplicación del lado del cliente, es más importante garantizar su calidad que si es
un sitio web o un servicio. La razón de esto es que un sitio web se puede reparar casi instantáneamente si tiene
una arquitectura de implementación rápida. Por otro lado, una aplicación instalada en la máquina o el teléfono
de un usuario puede actualizarse como máximo cada semana; sin embargo, esto puede molestar a los usuarios
y debe tratar de ser más conservador en las actualizaciones (incluso si la fricción al publicarlas está
disminuyendo constantemente a medida que las tiendas de aplicaciones volverse más omnipresente).
En el caso de los servicios web, muchos sintieron que podían permitirse muchos trucos sucios para que
funcionaran, porque resolverlos cuando fallan es una cuestión sencilla. Compararon esto con la pérdida
de agilidad de los problemas arquitectónicos en el proyecto, siendo la flexibilidad de implementación un
contrapeso para manejar una mayor deuda técnica.
V La creación de prototipos es difícil de aplicar a la mayoría de los dominios problemáticos, pero es valiosa cuando
posible.
La práctica de crear prototipos y probar nuevas funciones mediante maquetas, que es una
parte importante de Lean, ha demostrado ser algo difícil de hacer. Muchas empresas quieren
utilizar más prototipos, pero les resulta difícil debido a la naturaleza de su producto, ya sea
porque es algo delicado de probar o porque solo es posible en entornos de producción reales.
Sin embargo, las empresas que pudieron utilizar la creación de prototipos de forma regular
sintieron que era muy valiosa, lo que demuestra que sigue siendo una herramienta muy útil. La
pregunta es cómo se pueden crear prototipos fácilmente con un desarrollo eficiente sin perder
demasiado tiempo en hacerlos correctamente.
36

Deuda tecnica en Lean Startup.en.es.pdf

Deuda tecnica en Lean Startup.en.es.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a Deuda tecnica en Lean Startup.en.es.pdf

Similar a Deuda tecnica en Lean Startup.en.es.pdf (20)

Más de Nicanor Sachahuaman

Más de Nicanor Sachahuaman (17)

Último

Último (16)

Deuda tecnica en Lean Startup.en.es.pdf