¿Qué significan las siglas de SOLID?
- Single Responsibility Principle
- Open-Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
SRP: Single Responsibility Principle
¿Qué es?
Este principio establece que una clase debe tener una única responsabilidad, es decir, una única razón para cambiar. Si una clase tiene múltiples responsabilidades, se vuelve más difícil de mantener y extender.
Ejemplo: Supongamos que tenemos una clase llamada Empleado que se encarga tanto de almacenar la información de un empleado como de calcular su salario. Este sería un incumplimiento del SRP. En cambio, podríamos tener una clase Empleado que solo almacena la información del empleado y otra clase CalculadoraSalario que se encargue de calcular el salario.
OCP: Open-Closed Principle
¿Qué es?
Este principio establece que las clases deben estar abiertas para la extensión pero cerradas para la modificación. Es decir, deberíamos poder agregar nuevas funcionalidades sin tener que modificar el código existente.
Ejemplo: Imagina una clase Forma que tiene un método calcularArea(). Si queremos agregar una nueva forma, como un triángulo, deberíamos poder hacerlo sin modificar la clase Forma. Podríamos crear una subclase Triángulo que implemente el método calcularArea() de manera diferente.
LSP: Liskov Substitution Principle
¿Qué es?
Este principio establece que las clases derivadas deben poder ser sustituidas por sus clases base sin alterar el comportamiento del programa. Es decir, cualquier instancia de una clase base debería poder ser reemplazada por una instancia de una clase derivada sin afectar la funcionalidad del programa.
Ejemplo: Supongamos que tenemos una clase Cuadrado y una clase Rectángulo, donde Cuadrado es un tipo especial de Rectángulo. Si se espera que un método funcione con cualquier objeto Rectángulo, entonces debería funcionar correctamente con un objeto Cuadrado sin necesidad de modificar el código.
ISP: Interface Segregation Principle
¿Qué es?
Este principio establece que los clientes no deben verse obligados a depender de interfaces que no utilicen. Es decir, las interfaces deben ser lo suficientemente específicas para cada cliente, evitando interfaces genéricas que contengan métodos no relevantes para ciertos clientes.
Ejemplo: Supongamos que tenemos una interfaz Impresora que tiene métodos imprimir(), escanear() y faxear(). Si un cliente solo necesita imprimir, se verá obligado a depender de los métodos escanear() y faxear(), lo cual no es ideal. En cambio, podríamos dividir la interfaz en interfaces más específicas como Impresora, Escáner y Fax.
DIP: Dependency Inversion Principle
¿Qué es?
Este principio establece que los módulos de alto nivel no deben depender de los módulos de bajo nivel, sino de abstracciones. Además, las abstracciones no deben depender de los detalles, sino que los detalles deben depender de las abstracciones.
Ejemplo: Supongamos que tenemos una clase Motor que depende directamente de una clase Coche. Esto hace que Motor esté fuertemente acoplado a Coche. En cambio, podríamos introducir una interfaz Vehículo y hacer que Motor dependa de Vehículo. Luego, Coche implementaría la interfaz Vehículo, cumpliendo así con el principio de inversión de dependencias.
MVP, ¿Qué es?
Es una versión de un producto que permite al equipo recolectar la máxima cantidad de aprendizaje validado sobre los clientes, con el mínimo esfuerzo.
Es lo suficientemente grande como para causar adopción, satisfacción y ventas, pero no tanto como para ser arriesgado.
¿Qué cosas NO es MVP?
MVP NO es:
- Versiones de producto
- Resultado de todo un proyecto (siempre es. la parte inicial, que debe ser complementada, refinada, mejorada)
- Salir rápido, trabajando a las apuradas.
- Un prototipo (es una versión real del producto)
¿Para qué se hace un MVP?
- Para evitar entregar un producto demasiado tarde.
- Para tener ROI (retorno de inversion) más temprano (pór el cash flow).
- Para evitar entregar un producto que no sirva (supuestos no validados).
- Para satisfacer más pronto las necesidades de los usuarios.
¿Qué 3 conceptos tenemos para ser más claros respecto de un MVP?
- Earliest Testable Product
- Earliest Usable Product
- Earliest Lovable Product
¿Qué es el Earliest Testable Product?
¿Qué actividad clave tiene?
El Earliest Testable Product es la primer entrega con la que los clientes pueden hacer algo. Probablemente no resuelva su problema, pero genera feedback. Aprender es el principal propósito.
Discovery es una actividad clave. No sólo al inicio.
¿Qué es el Earliest Usable Product?
Es el primer entregable que los early adopters verdaderamente podrán usar. Está lejos de ser terminado y puede que no sea muy atractivo. Pero acerca más a los clientes a una solución a su necesidad real.
¿Qué es el Earliest Lovable Product?
El primer release que los clientes adorarán, les contarán a sus amigos y por el que estarán dispuestos a pagar. Todavía hay mucho que mejorar, pero hemos llegado al punto en el que tenemos algo comercializable.
¿Qué ejemplos tiene de cada Earliest Product?
- Earliest Testable Product:
Una aplicación que registra el tiempo de ejercicio sin características adicionales. - Earliest Usable Product:
Se añaden funciones básicas como seguimiento de progreso y sugerencias de entrenamiento. - Earliest Lovable Product:
Se incorporan elementos de gamificación, integración social y personalización avanzada para generar una conexión emocional con los usuarios.
¿Qué es la User Story Mapping?
El user Story Mapping es una técnica que se utiliza para visualizar y organizar las User Stories en función de las actividades del usuario y su flujo de trabajo.
Consiste en crear un mapa o diagrama que representa la secuencia de pasos que un usuario sigue para lograr un objetivo específico, mostrando las historias de usuario relacionadas ocn cada paso.
Ayuda a comprender mejor el contexto en el que se utilizará el producto y a priorizar las funcionalidades de manera más efectiva durante el desarrollo,
