Embracing Fun: Why Extreme Programming is Great for Game Development
- By Bill Schofield
- Gamasutra
- March 1 , 2007
- Traducción por: Dora Zárate
Programación Extrema (XP desde ahora) es una metodología de desarrollo de Software ágil, que se enfoca en adaptarse al cambio en lugar de predecirlo. El poder de la metodología XP consiste en permitir a los creadores del juego hacer grandes juegos de manera confiable mientras se conocen las distintas (y a menudo competitivas) necesidades de los editores, técnicos y desarrolladores en sí mismos.
El saber popular nos dice que haciendo mas por cada uno de estos grupos nos alejaríamos de los otros. XP desafía esta visión y le permite al grupo de desarrollo lograr resultados de alta calidad que puedan satisfacer las necesidades de todos los sectores.
XP produce grandes productos porque se enfoca en la prematura liberación del software en desarrollo. La prematura liberación del software en desarrollo significa que el diseñador del juego puede ver como lucen las características de mas alta prioridad sin tener que esperar a que un gran sistema sea implementado. Esto permite al diseñador encontrar una modalidad de juego divertida mas fácilmente y conducir al juego hacia las características mas divertidas lo antes posible.
Entonces XP ¿alienta al diseñador a gobernar el juego durante el desarrollo y hacer mas cambios al diseño?. ¡Esto es exactamente lo que la mayoría de los programadores no quiere escuchar!. Si tu software es difícil y doloroso de cambiar entonces un “cambio de planes” será lo último que querrás. Pero en realidad, para encontrar un modo de juego divertido el diseñador querrá cambiar de dirección mientras aprende como funciona el desarrollo en la actualidad. Si el trabajo del programador es hacer un gran juego entonces necesitamos hacer nuestro mejor esfuerzo para permitirle tanto manejo como podamos. La Programación Extrema procura concentrar energía del desarrollo en obtener resultados rápidamente y mantener el proyecto flexible.
Esto suena grandioso en teoría, pero probablemente ahora te estés preguntando, ¿que hace exactamente XP para permitir que un proyecto sea fácil de manejar?. XP usa recíprocamente prácticas reforzadas para mantener el código tan simple y saludable como sea posible. Para resumir, XP requiere que el equipo priorice las características mas importantes, que las trabaje en orden, solo escriba el código que sea necesario para implementarlas, y que aplique constantemente pequeñas mejoras de diseño para mantener al código saludable.
El resto del artículo nos da una perspectiva que 5 prácticas claves de XP: Test Driven Development, Part Programming, Continuous Desing, Real Customer Involvement y Energized Work. Estas prácticas junto con otras prácticas XP no mencionadas aquí, le permiten al grupo publicar resultados visibles rapidamente. Los resultados visibles informan al diseñador, quien luego puede manejar el juego en una dirección positiva. Porque los diseñadores han estado manteniendo el código flexile, hacer que este código haga algo nuevo es comparativamente fácil lo cual lleva al próximo ciclo de resultados visibles.
Mientras examinas estas prácticas es importante recordar que XP no es acerca de cada una de sus prácticas: test automatizados, 40 horas de trabajo por semana, ni tampoco es un sobre programar de a pares. Mientrasla mayoría de los buenos equipos XP hacen todas estas cosas, ellos son simplemente el medio para finalizar de construir un gran producto. De eso se trata XP, construir grandes juegos.
Test Driven Development
Cuando practicamos Test Drive Development (TDD), los programadores escriben una pequeña pieza de código que describe como quieren que una nueva característica en el programa funcione. Esta pieza de código se llama “Unit Test” e inicialmente falla porque la característica que el test describe no ha sido implementada aún. El programador sabe que ha concluido esa característica una vez que el “test” funcione. Este proceso tiene muchos beneficios pero, “Automated unit testing” es el mas visible.
Automated Unit Tests son test que prueban que cada pieza del software hace lo que el programador cree que hace. Los desarrolladores pueden facilmente correr estos test para validad que ningún cambio de los que han hecho rompieron las características ya implementadas. Estos test le permiten hacer cambios en el proyecto de manera rápida y segura.
La regresión es una de las formas mas insidiosas de fricción que un equipo debe afrontar. En una etapa inicial del proyecto hay solo unas pocas características en las que se necesita trabajar pero a medida que el equipo avanza y el proyecto crece, a menudo aparecen tantas características que es casi imposible mantenerlas funcionando a la vez (e incluso saber cuales están funcionando). Automated Tests nos da un marco de trabajo que escala con el número de características que tenemos por lo tanto nos permite implementar nuevas características sin preocuparnos por la regresión escondida.
Otro beneficio de TDD es que ayuda al equipo de programación haciéndolos sentir felices y energizados mediante constantes recompensas de pequeños éxitos, a través de test aprobados, mientras se acercan a el gran triunfode una característica funcional.
Pair Programming
Pair Programming es el proceso de tener dos programadores trabajando en la misma computadora a la vez. Generalmente uno de los programadores es conductor (esto es, escribir y decidir que código está escribiendo) mientras que el otro es navegador. El navegador no se enfoca en errores tácticos que el conductor podría hacer. En lugar de eso, piensa en el contexto en el que están trabajando. El navegante se hace preguntas como: “¿Como se acopla este código con el código existente?” y “¿Hay un modo de que podamos cambiar el código recién terminado para hacerlo mejor?”.
La calidad y la simplicidad del código que dos programadores hacen es generalmente mejor del que crearían de forma separada, debido a que hay muchas menos oportunidades perdidas para mejorar el código. “Dos cabezas son mejor que una”, conduce un código de calidad superior. Este código de calidad superior es fácil y seguro de cambiar que el código escrito por un único miembro del equipo.
Los programadores de juego están casi siempre tomando pequeñas decisiones de diseño. Estas decisiones pueden llevar a que el juego sea mucho mas (o mucho menos) divertido. Tener a dos personas creativas derramándoselos sesos por unos minutos puede llevar a resultados excepcionales. Trabajar en equipo de a pares alienta a tomar estás decisiones rápidas sin tener que reunir gente para una asamblea o interrumpir a alguien.
Esta actividad ayuda a construir equipos sólidos y felices formando lazos de confianza a través de experiencias compartidas, mucha interacción personal, y reduce la frustración de quedarse atascado a menudo.
Continuous Design
Continous Desing es el arte de mantener el diseño del software a tono con lo que el programa necesita hacer hoy. Si te aseguras que el diseño para la versión mas simple del sistema está bien, esto significa que no construyes el sistema generalizado sino hasta que el programa necesita la generalidad.
Escribir menos código no implica tomar atajos o hacer cambios bruscos; solo significa que deberías implementar solo aquello que necesitas porque será mas fácil cambiar la dirección de un código base cuando hay menos código.
Una parte del proceso de “Continous Desing” es reconstruir (o refactoring), lo cual significa cambiar el código para hacerlo mas saludable sin cambiar ninguna de sus características. Si tu comprensión del diseño mejora como así tambiénel diseño mas simple no se adapta a las necesidades crecientes del software, a menudo hallas que el programa sería mas saludable o mas simple si el código se viese diferente. Reconstruir es la respuesta a como mantenemos el código flexible.
Continous Desing nos lleva a un código mas simple. Un código mas simple es mas fácil de entender y menos frustrante. Esto ayuda a sentirse competente, confiado y seguro. Lo cual lleva a un equipo a sentirse feliz y energizado.
Real Customer Involvement
En términos simples, Real Customer Involment significa tener usuarios reales jugando al juego tan temprano como sea posible. Dado que el equipo se ha enfocado en obtener resultados visibles, esto debería ser notorio en unaetapa prematura de desarrollo. Esto ayuda al equipo a priorizar características y hacer mejores suposiciones en el futuro.
Otra visión de esto es tener el trabajo del diseñador muy cerca de los programadores mientras las características se están implementando. Esto enfoca el esfuerzo de programación donde este dará el mejor resultado, conseguirá las decisiones mas convenientes y le permitirá al diseñador decir “Es suficientemente bueno por ahora”. Cuando los programadores están enfocados en proveer resultados visibles y el diseñador puede proveer una realimentación útil sobre lo que es divertido o no, ambos grupos pueden encontrar la diversión juntos.
Trabajar con alguien para conseguir un resultado que funcione mejor para ellos hace felices tanto al cliente como a los desarrolladores. Este acercamiento cooperativo a implementar características también construye fuertes lazos de confiabilidad, lo que es muy bueno para el equipo.
Energized Work
Trabajar cuando estás cansado o enfermo conduce a: trabajar lento, muchos errores, infelicidad y largos periodos de cansancio o enfermedad. Porque programar es fundamentalmente acerca de ideas, los programadores pueden hacer mucho progreso en un corto tiempo si se les presentan las ideas correctas al tiempo correcto. Pero encontrarse con estas ideas es la parte dura, nuestras mentes necesitan estar operando al 100% o no será probable que nos den su mejor solución. Energized Work mantiene nuestro cerebro saludable y feliz, de forma que realice el trabajo que necesitamos que hagan mas seguido.
Energized Work ayuda a mejorar el resto de las prácticas de XP y mantiene a los programadores haciendo su mejor trabajo lo cual produce un mejor código y un juego mas divertido.
Conclusión
Como hice notar al comienzo de este artículo, XP no es acerca de test automatizados, 40 hour work week, ni es acerca de pair programming. Mientras la mayoría de los buenos equipos de XP hacen todas estas cosas, ellos son simplemente los medios para construir un gran producto. De eso se trata XP, construir grandes juego.
El poder de la metodología XP es que permite a los desarrolladores del juego confiar en hacer grandes juegos mientras reúnen las necesidades diversas de numerosos interesados envueltos en el desarrollo del proceso.
- Las necesidades de los editores se conocen porque sus productos son mas divertidos, ellos ven progresos mas seguido y cuando su mercado cambia el juego se puede modificar para encontrar aquellas nuevas necesidades.
- La administración se alegra porque la moral del equipo está mas alta, el juego puede cambiar para encontrar nuevos requerimientos del negocio y el progreso visible y la reacción les permite saber que el equipo está en el buen camino para lograr sus metas.
- Los miembros del equipo se alegran porque muchas de las practicas tienen recompensas, son divertidas y energizantes.
Al final, tiene sentido que cualquiera pueda ganar usando XP porque nosotros queremos lo mismo, “hacer grandes juegos”.
Aprendiendo mas acerca de XP
Estas prácticas, así como otras prácticas no comentadas aquí: Whole Team, Planning Game, Small Releases, Customer Test, Continuons Integratison, Collective Code Ownership, Coding Standard y Methafor, le permiten a un equipo entregar resultados visibles rapidamente. Hay muchos buenos recursos que puede utilizar si quiere aprender mas sobre XP o cualquiera de sus prácticas. El libro de Ken Beck, Exteme Programming Explained es generalmente reconocido como la mejor introducción a XP. También recomiendo estos sitios web: