4. Metodología

Sin valoraciones

4. Metodología

Con el objetivo de realizar un desarrollo lo más organizado posible, el cual nos permita avanzar a buen ritmo y de forma eficiente. Para este proyecto se ha optado por el uso de una metodología ágil en lugar de una metodología tradicional. Esta decisión se justifica en las ventajas que aporta esta forma de desarrollar para un proyecto de este tipo, estas están reflejadas en la Tabla 2.

4. Metodología

Tabla 2- Metodologías Ágiles

http://portal.amelica.org/ameli/jatsRepo/24/2414011/html/

En concreto, para este trabajo, se ha optado por la metodología ágil conocida como Desarrollo iterativo e incremental (Antonieza Kuz, 2018). Esta metodología consiste en planificar el desarrollo en distintos bloques temporales, llamados iteraciones, de una duración entre dos y cuatro semanas.

videojuegos

Las iteraciones se han ideado para ir obteniendo resultados constantes e ir ampliando el proyecto progresivamente, es decir, el objetivo final de cada iteración es tener un producto operativo y conforme van pasando las mismas ir dando forma y mejorando el mismo hasta tener el producto final. Lo idóneo para que esta forma de trabajar funcione es fragmentar el proyecto en varias secciones y a su vez cada una de estas en varias tareas pequeñas, de esta forma el trabajo se encuentra organizado, se van realizando y completando tareas cada pocos días, por lo que productividad sube. Además, al tener un prototipo al final de cada iteración se puede hacer una evaluación de este por si hay que realizar correcciones y/o mejoras de las funcionalidades ya implementas o del contenido ya desarrollado

4.1 Herramientas de gestión

En concreto, para la organización de tareas y su evolución se ha optado por el método Kanban junto a la herramienta Trello, la cual nos permite clasificar las tareas mediante el uso de tarjetas en varias tablas en función de su estado actual. Esta clasificación, para que se vea de forma visual, se suele mostrar en forma de tablero, como se ve en la Figura 14.

MURO KANBAN

4. Metodología

Figura 14– Tablero clásico kanban
Fuente: https://www.javiergarzas.com/2011/11/kanban.html

A cada tarea se le asigna una duración estimada y una prioridad. Durante el desarrollo de la iteración se va midiendo el tiempo real que cuesta cada tarea y se compara con lo estimado inicialmente, para este control se utilizará la herramienta Clockify. Si se produce un desvío, tanto al alza como a la baja, se deben recalibrar los tiempos del resto de tareas para llegar a la fecha de fin de iteración con todas las tareas planificadas terminadas. En caso de que esto no sea posible y alguna tarea se retrase, esta pasará a la siguiente iteración con una prioridad superior, ya que es una tarea atrasada. En caso extremo de que una tarea sufra un retraso muy grande o su realización se vea comprometida, se debe realizar una reevaluación del proyecto y considerar la opción de descartar la tarea. Es importante remarcar que el objetivo de este sistema de trabajo se basa, como ya se ha mencionado, en ir creado un prototipo funcional por iteración.

4. Metodología

Figura 15- Trello Example Board

Fuente: https://blog.trello.com/engineering-teams-sample-trello-boards

4.2 Control de Versiones

Para realizar el control de versiones, como es normal, se va a utilizar GitHub en conjunto con GitKraken, un programa que nos facilita todas las funcionalidades de GitHub mediante una interfaz visual. El uso de estas herramientas nos va a permitir trabajar con mayor facilidad, pues garantiza acceso al trabajo de forma inmediata y, sobre todo, de forma segura, ya que se realizarán copias de seguridad de forma extremadamente simple a medida que se avance en el proyecto.

El uso de esta herramienta es obligatorio, ya no solo por todas las ventajas que aporta al desarrollo sino porque todas las empresas hoy en día usan esta herramienta, o una muy similar, para almacenar y proteger sus proyectos.

4. Metodología

Figura 16- Trello Example Board
Fuente: Elaboración propia

Como el proyecto es de carácter individual no será necesario utilizar muchas de las herramientas de GitHub, para este proyecto será suficiente el uso de los commits, para crear las copias de seguridad y el uso de ramas para la implementación de las distintas funcionalidades. Una vez que una funcionalidad esté operativa se fusionaría con la rama principal, en la que siempre habrá una versión usable del producto.

videojuegos

5. Análisis del proyecto

En este apartado se va a empezar a tratar los temas de forma más técnica y a profundizar en los aspectos más relevantes del trabajo. Se van a realizar análisis sobre diversos temas muy importantes que deber ser realizados previamente al comienzo del diseño del videojuego, tales como la planificación, la gestión de riesgos, software a utilizar y modelos de negocio.

5.1 Planificación Inicial

El objetivo es realizar el mejor trabajo posible dentro de las 300 horas posibles, pare ello, como ya se vio en el apartado de metodología, se va a trabajar siguiendo un modelo iterativo. Para este proyecto se dispone de unas siete semanas. Con esto en mente se ha fraccionado el proyecto en 8 iteraciones diferentes de la siguiente forma. El seguimiento de cada iteración se realizará mediante un tablero de Trello diferente para cada una. Esta división temporal se ha establecido con varios objetivos en mente:

  1. Fraccionar el trabajo en pequeñas tareas que permitan avanzar con rapidez.
  2. Para este proyecto se ha estimado que siete días es el tiempo mínimo necesario para poder cumplir con los objeticos de cada iteración.
  3. Al ser cortas las iteraciones es más fácil realizar cambios si estos son necesarios porque la evaluación del producto es constante.
  4. El tiempo disponible para realizar el trabajo no es óptimo así que realizar todas las iteraciones posibles ayudará a tener un mejor producto final.

La planificación fue modificada posteriormente debido a multitud de factores, en las conclusiones del proyecto se detallan, así como la replanificación que se realizó.

5.2 Estudio de viabilidad

En este apartado se va a realizar un estudio completo sobre la viabilidad del proyecto en el contexto actual. Este tipo de análisis es absolutamente crucial hoy en día, cualquier proyecto desde su concepción debe superar varias etapas antes de entrar en producción y una de ellas es el tema que nos atañe en este punto, puesto que un proyecto que se considera inviable será cancelado inmediatamente y nunca verá la luz.

Cualquier estudio de viabilidad debe contar con una serie de puntos para considerarlo eficaz, estos son:

5.2.1 Gestión de riesgos

En todo proyecto es necesario tener en cuenta la muy alta probabilidad de que surjan problemas durante el desarrollo que alteren los plazos o impidan realizar varias tareas. Para minimizar el impacto de estos sucesos, es necesario diseñar con anterioridad el cómo se les hará frente. Este proceso se realiza en 4 pasos (Sommerville, 2005):

  1. Identificación de riesgos: Determinar todos los potenciales riesgos
  2. Análisis de riesgos: Clasificar por peligrosidad y probabilidad de que ocurran.
  3. Planificación de los riesgos: Establecer los planes de actuación
  4. Monitorización de riesgos: Definir identificadores potenciales

Este sistema de gestión riesgos se encuentra representado en la Figura 20.

4. Metodología

Figura 17- Gestión de Riesgos

Fuente: http://ingesoftwaregestiondelriesgo.blogspot.com/2015/05/blog-post.html

5.2.1 Identificación

El primer paso es detectar y listas todos los posibles riesgos, esto es una tarea complicada, por lo que, para facilitar su realización, los riesgos se han clasificado en diversas categorías:

videojuegos

– Personales

o Enfermedad: Especialmente en proyectos como este, donde solo hay una persona encargada de todo, este riesgo es muy importante. Más aún dada mi facilidad para enfermar.

o Problemas Familiares: Dado que todavía soy dependiente económicamente de mis familiares, una mala situación familiar puede afectar gravemente al proyecto.

o Altos Niveles de estrés: La carga de trabajo puede llegar a ser muy alta, por lo que hay que intentar mantener unos horarios de trabajo saludables y descansar.

– Tecnológicos

o Pérdida de información: La pérdida de datos del proyecto, sobre todo en fases avanzadas del mismo puede ser catastrófico.

o Hardware poco potente: Dado que se va a trabajar con herramientas de muy alto nivel y que necesitan un hardware potente para funcionar de forma correcta es muy importante llevar cuidado al trabajar, especialmente con el motor gráfico.

o Problemas con el sistema operativo: Algo básico y que suele pasar con Windows, hay que realizar mantenimientos periódicos.

o Problemas con la conexión a internet: La conexión a internet es imprescindible para realizar el proyecto, hay que disponer de una alternativa.

o Rotura de PC: Imposibilitaría poder trabajar, obligatorio disponer de un equipo alternativo.

– Organizativos

o Mala planificación de las iteraciones: El trabajo de cada iteración debe ser asumible.

o Mal fraccionamiento de las tareas: Las tareas grandes hay que subdividirlas en pequeñas tareas para conseguir avances rápidos

o Dimensión del proyecto: Hay que ser realista con el producto real que se puede elaborar en el tiempo disponible, dado que el apartado más relevante es la memoria.

o No seguir con la metodología elegida: Kanban nos ayuda a trabajar de forma más eficiente, no hacerlo puede afectar al desarrollo de todas las tareas.

o No contabilizar las horas de trabajo: No llevar un registro del trabajo realizado puede llevar a una mala gestión del tiempo disponible.

– Requerimientos

o Práctica con el nuevo software: En caso de utilizar un software desconocido es necesario realizar un periodo de práctica para comprender su funcionamiento.

o Entrega del proyecto en la fecha indicada: No entregar el proyecto supone el fracaso absoluto del proyecto.

o Cumplimiento de los requisitos: Realizar el proyecto de forma que cumpla, por lo menos, con los requisitos mínimos establecidos para que pueda ser evaluado.

o Funcionalidades básicas: El proyecto debe incorporar un mínimo de funcionalidades para poder considerarlo un prototipo válido.

– Estimación

o Infraestimación de las tareas: Puede afectar a las demás tareas sin una de ellas se retrasa de forma importante.

o Sobreestimación las tareas: Puede afectar al resto de tareas si se dedica demasiado tiempo a una tarea, o demasiado poco.

o No tener un producto al final de iteración: El no cumplir con los objetivos de cada iteración puede alterar severamente el resto de la planificación.

– Herramientas

o Incompatibilidad entre las herramientas de desarrollo elegidas: Puedo suponer un retraso muy grave en función del grado de incompatibilidad.

o Fallos en el software durante el desarrollo: Puede ocasionar perdidas de información y del trabajo realizado.

o Finalización de las licencias: Impediría trabajar con la herramienta, afectando al ritmo de trabajo si no se soluciona rápidamente.

5.2.1.2 Análisis

Es este apartado se va a clasificar los riesgos es función de su gravedad y la probabilidad de que sucedan.

4. Metodología

4. Metodología

Tabla 3- Análisis de riesgos

Fuente: Realización propia

 

 

La elección de una metodología de desarrollo en el contexto de la creación de videojuegos es crucial para el éxito del proyecto. Hay varias metodologías, y la elección depende de factores como la naturaleza del juego, el tamaño del equipo, el grado de incertidumbre y otros:

1. Desarrollo en Cascada:

  • Características:
    • Fases lineales, cada una depende de la anterior.
    • Planificación y diseño completos antes de la implementación.
    • Cambios difíciles de incorporar una vez iniciada la implementación.

2. Desarrollo en Espiral:

  • Características:
    • Ciclos repetitivos con énfasis en la mitigación de riesgos.
    • Desarrollo incrementativo con retroalimentación continua.
    • Flexibilidad para adaptarse a cambios durante el ciclo de desarrollo.

3. Metodología Ágil:

  • Ejemplos: Scrum, Kanban, XP (eXtreme Programming):
    • Desarrollo iterativo e incremental.
    • Colaboración estrecha con el cliente y adaptación a cambios.
    • Scrum se centra en sprints, roles definidos y reuniones regulares.

4. Desarrollo Rápido de Aplicaciones (RAD):

  • Características:
    • Prototipos rápidos y ciclos de desarrollo cortos.
    • Enfoque en la participación activa del usuario.
    • Iteraciones frecuentes para mejorar el prototipo.

5. DevOps:

  • Características:
    • Integración continua y despliegue continuo.
    • Colaboración estrecha entre equipos de desarrollo y operaciones.
    • Enfoque en la automatización y mejora continua.

6. Modelo en V:

  • Características:
    • Similar al modelo en cascada pero con pruebas integradas en cada fase.
    • Las fases de prueba se ejecutan en paralelo con las fases de desarrollo.
    • Permite identificar y corregir errores más temprano en el ciclo.

7. Lean Game Development:

  • Características:
    • Enfoque en la reducción del desperdicio y la eficiencia.
    • Eliminación de actividades que no agregan valor al juego.
    • Iteraciones rápidas y mejora continua.

8. Desarrollo Basado en Prototipos:

  • Características:
    • Creación de prototipos rápidos para validar ideas.
    • Iteración basada en retroalimentación de prototipos.
    • Desarrollo completo basado en el prototipo validado.

9. Metodología Espartana:

  • Características:
    • Enfoque en mantener un equipo pequeño y altamente eficiente.
    • Reducción de procesos y burocracia al mínimo.
    • Enfoque en resultados rápidos y entregas continuas.

10. Metodología de Desarrollo Gamificado:

markdown
- **Características:** - Aplicación de principios de juegos al proceso de desarrollo. -Uso de recompensas, competiciones y otros elementos de juego. - Fomenta la motivación y la colaboración en el equipo.

Consideraciones al Elegir una Metodología:

  • Tamaño del Equipo: Algunas metodologías son más adecuadas para equipos pequeños, mientras que otras son más escalables.
  • Naturaleza del Proyecto: Proyectos más grandes o complejos pueden beneficiarse de enfoques más estructurados.
  • Cambios y Flexibilidad: Si se espera que haya cambios frecuentes en los requisitos del proyecto, las metodologías ágiles pueden ser más apropiadas.
  • Experiencia del Equipo: La familiaridad y experiencia del equipo con una metodología específica también son factores importantes.

Compártelo en tus redes

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

Valore este curso

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Utilizamos cookies para asegurar que damos la mejor experiencia al usuario en nuestra web. Si sigues utilizando este sitio asumimos que estás de acuerdo. VER