El Contenido de la Guía
Capítulo 1. Qué es la Externalización de Software y Por Qué Ahora No se Trata Solo del Precio
Capítulo 2. Cómo Elegir el País, el Socio de Externalización y el Modelo de Negocio
Capítulo 3. Comencemos un Nuevo Proyecto: el Proceso de Configuración
Capítulo 4. Paso 1. El Análisis de Negocio y el Diseño son Clave
Capítulo 5. Paso 2. Desarrollo de Software: La Calidad es Imprescindible
Capítulo 6. Paso 3. Pruebas y Soporte para el Resultado
Capítulo 7. Preguntas Frecuentes sobre la Externalización del Desarrollo de Software
Para entregar la más alta calidad en el menor período de tiempo, el equipo elige la metodología de desarrollo de software más adecuada que se utilizará durante todo el proceso de desarrollo.
La metodología de desarrollo de software es un plan de acción con fases definidas que establece las normas para los miembros del equipo sobre cómo van a trabajar y de qué manera deben transmitirse la información entre sí.
Estos métodos se utilizan para gestionar el flujo de trabajo de desarrollo de manera más eficiente.
Aquí hay una lista de las metodologías de desarrollo de software más utilizadas:
Ágil (Agile)
El enfoque Ágil representa iteración y flexibilidad. La colaboración continua es clave en el proceso de desarrollo Ágil.
El equipo tiene la oportunidad de evaluar las demandas de las partes interesadas e implementar modificaciones rápidas, ya que ambas partes discuten continuamente los detalles durante reuniones programadas, llamadas sprints. Principalmente, los sprints duran de una a cuatro semanas. El cliente puede calcular los costes estimados antes de cada sprint para comprender mejor los costes aproximados de cada característica. Este enfoque ofrece más oportunidades para la toma de decisiones.
Al utilizar métodos Ágiles, el equipo puede continuamente repriorizar y refinar el backlog del producto. Crea oportunidades para evaluar la dirección de un proyecto durante el ciclo de desarrollo.
Los principales principios Ágiles:
o Un producto funcional es la principal medida de progreso.
o La colaboración con las partes interesadas es la prioridad, no la negociación del contrato.
o No es obligatorio seguir el plan predeterminado; se pueden hacer cambios.
o Entregar el producto en el plazo más corto posible.
o Los equipos deben cooperar a diario para ser más efectivos.
También podemos añadir a los principios Ágiles que el cliente recibe pequeñas piezas de funcionalidad de forma regular.
Scrum
Scrum es otro método flexible de gestión de proyectos de la familia Ágil. Este modelo fue diseñado para proyectos que requieren soluciones rápidas combinadas con tolerancia a las modificaciones.
La estructura principal del proceso Scrum involucra la planificación del sprint, reuniones diarias breves, resultados del sprint y retrospectivas.
Scrum divide el proyecto en partes que pueden ser utilizadas por el cliente para obtener backlogs. Los sprints duran de dos a cuatro semanas. Durante este tiempo, la duración de las reuniones se minimiza, pero su frecuencia aumenta. El control sobre la ejecución se vuelve más flexible y los desarrolladores responden más rápidamente a los problemas emergentes.
Este enfoque es adecuado para situaciones en las que no todos los miembros del equipo tienen suficiente experiencia en el campo en el que se está implementando el proyecto. La comunicación constante entre los miembros del equipo, que pueden compartir sus conocimientos, puede compensar la falta de experiencia o cualificaciones.
El Scrum Master es responsable de supervisar el trabajo del equipo y asegurarse de que los participantes del proyecto comprendan los principios y normas de la práctica Scrum. Él/Ella es un mediador entre el cliente y el equipo. El equipo es responsable de asegurar al final de cada sprint que todas las tareas necesarias se hayan completado. El Product Owner es la persona que representa los intereses de los usuarios finales.
Artefactos de Scrum
El Product Backlog es una lista de requisitos funcionales que se ordenan por orden de importancia.
El Sprint Backlog es la funcionalidad elegida por el Product Owner del Product Backlog.
Una Reunión de Planificación se lleva a cabo al comienzo de la iteración con el objetivo de determinar la cantidad de trabajo requerido.
Una Reunión Diaria (Stand-Up) es una reunión breve diaria durante la cual cada miembro del equipo responde tres preguntas:
- ¿Qué trabajo se ha realizado entre la reunión anterior y la actual?
- ¿Qué trabajo se habrá realizado entre la reunión actual y la siguiente?
- ¿Qué problemas obstaculizan el logro de los objetivos del sprint?
Kanban
Kanban es un sistema Ágil basado en visualizar el proceso de cumplimiento de las tareas del equipo. La idea principal en este sistema es reducir el número de tareas que se están realizando actualmente.
Este enfoque es menos estricto que el enfoque Scrum. No limita el tiempo de los sprints y no se asignan roles a los miembros del equipo, excepto el del Product Owner. Kanban permite que un miembro del equipo ejecute varias tareas a la vez, algo que no se practica en Scrum. Además, no hay reuniones estrictamente reguladas sobre el estado del proyecto. Es mejor usar el modelo Kanban cuando no hay plazos específicos. Cada tarea se da individualmente. Pasa por todas las etapas en el tablero y una vez que se ha completado, se puede mostrar al cliente.
El cálculo preciso de la carga de trabajo, la colocación correcta de restricciones y el enfoque en la mejora continua permiten ahorrar recursos y cumplir con los plazos y las restricciones presupuestarias. Y todo esto se combina con la flexibilidad de Kanban.
El modelo en Cascada (Waterfall)
El modelo en Cascada es un enfoque secuencial lineal con varias fases. Fue el primer modelo de proceso en ser introducido. Una secuencia típica de eventos se ve así: análisis de requisitos – diseño de software – implementación – pruebas – mantenimiento.
Se impone un control estricto durante el proceso de desarrollo con una gran cantidad de documentación escrita, aprobación y visto bueno por parte del cliente, y revisiones formales. Un enfoque estricto desalienta volver a visitar y revisar cualquier fase anterior una vez que está completa. Sin embargo, hay una puerta de etapa entre cada fase, ya que los requisitos deben ser revisados y aprobados por el cliente antes de que comience el proceso de diseño.
Es mejor usar el modelo en Cascada para proyectos relativamente pequeños cuando los requisitos están claramente establecidos y hay programadores disponibles con las cualificaciones requeridas.
