1. ¿Por qué seguir los principios ágiles?#

Según los estudios citados en el libro (gráficas de éxito y fracaso de proyectos):

• Mejor control de presupuesto y tiempo: los proyectos ágiles tienden a ajustarse mejor a la realidad.
• Mayor valor de negocio: se entregan funciones útiles al cliente en cada iteración.
• Menos proyectos inconclusos: la entrega incremental reduce el riesgo de abandono.

Ejemplo: En SaaS muchas empresas adoptan Ágil porque funciona en la práctica (prueba y error constante, interfaces personalizables, documentación mínima pero suficiente).

2. Metodologías clásicas (MC) vs ágiles (MA)#

• MC (Clásicas):

  • Útiles cuando el cliente no está disponible o hay demasiados usuarios finales (mercado horizontal).
  • Se prioriza documentación y seguridad (ej: CMMI).
  • Adecuadas para proyectos embebidos o críticos donde no se permiten errores.

• MA (Ágiles):

  • Necesitan interacción frecuente con el cliente o stakeholders.
  • Funcionan mejor en entornos web y SaaS, con cambios frecuentes.
  • Evitan la figura del analista como único intermediario.
  • No son apropiadas si no existe un usuario claro para entrevistar o validar.

3. Principios ágiles#

Del Manifiesto Ágil y las prácticas en SaaS:

1. Individuos e interacciones sobre procesos y herramientas → Comunicación directa.
2. Enfocarse en el producto más que en la documentación → Documentar solo lo esencial para que el sistema funcione y sea entendible.
3. Colaboración con el cliente → El usuario debe probar, dar feedback y validar. “Es mejor tener un poco de algo que nada”.
4. Respuesta al cambio → Nuevos requerimientos son bienvenidos si aportan valor (ej: un cajero que ahora debe aceptar una nueva forma de pago).

⚠️ Ejemplo: Un cambio aparentemente simple como reemplazar la tecla TAB por ENTER puede afectar al sistema operativo. Por eso se debe evaluar siempre el impacto.

4. Herramientas para prácticas ágiles#

• Sistemas de seguimiento automatizados → Facilitan trazabilidad de requisitos y pruebas.

• Git → Control de versiones con trazabilidad de cambios, ramas y estados de código.

• DevOps y CI/CD → Integración y despliegue continuos. Ejemplo de flujo:

  1. Requisitos (R1, R2, R3).
  2. Versionado en repositorio.
  3. Servidor de pruebas (con DB similar a producción).
  4. Staging (con usuarios reales y cluster de procesamiento).
  5. Producción.

• Herramientas comunes:

  • DevOps pipelines
  • Capistrano, RoR (Ruby on Rails), Viking (para despliegues automáticos).
  • Métricas de cobertura de código → Porcentaje de código cubierto por pruebas unitarias (ej: 95%).

5. Bases de datos y Ágil#

• Antes: los administradores de BD eran indispensables.
• Ahora: los frameworks (ej. Rails) abstraen gran parte de la gestión de BD.
• Las reglas de normalización siguen siendo importantes, pero muchas veces no se pueden cambiar durante el desarrollo ágil.

6. Glosario#

• Stakeholder: Persona interesada en el proyecto (cliente, usuario, inversionista).
• CMMI: Modelo clásico de madurez de procesos, enfocado en seguridad y documentación.
• SaaS (Software as a Service): Modelo de software en la nube, siempre disponible, sin necesidad de instalación local.
• Feedback: Retroalimentación del cliente o usuario.
• DevOps: Cultura y prácticas que integran desarrollo (Dev) y operaciones (Ops) para entregar software de forma continua.
• CI/CD (Continuous Integration / Continuous Delivery): Práctica de integrar, probar y desplegar código automáticamente en ciclos cortos.
• Cobertura de código: Métrica que indica qué porcentaje del código está cubierto por pruebas automatizadas.
• Staging: Entorno intermedio entre pruebas y producción, usado para validar con usuarios reales antes del despliegue final.
• Cluster: Conjunto de servidores que trabajan en conjunto para ofrecer más disponibilidad y escalabilidad.