MetodologÃ_a de Desarrollo
Buenas noches 
El presente post es para preguntarles acerca de qué metodologÃ_a de desarrollo / producción usan. Resulta que hablando con mi tutor, decidimos irnos por XP (programación extrema) y mi corrector técnico se quedó en la prehistoria con Kendall y Kendall y dice que eso no nos sirve y no es metodologÃ_a 
Como estoy casi seguro que me preguntarán acerca del proyecto (y es obvio, ciertas metodologÃ_as funcionan mejor con cierto tipo de proyectos); en resumen es un simulador de instrumentos de percusión y se decidió usar SDL + gamepad modificado 
Por eso coloco la pregunta en el foro.
Bueno, muchÃ_simas gracias por su colaboración y si tienen una bibliografÃ_a recomendada.... más agradecido todavÃ_a,,
Originally posted by pmelendez
Por otro lado, en tu caso no veo tan claro el uso de esta metodologia, en primer lugar si es una tesis usualmente el grupo es de dos personas y en raras ocasiones las he visto de tres, y una de las tecnicas de la tecnologia es el pair programming (o programacion en par) en donde literalmente estaran dos personas sentadas frente a un solo computador trabajando en lo mismo, y considerando que en una tesis el tiempo es super valioso no creo que sea lo mas indicado. Por otro lado, otro de los puntos es hacer reuniones bastante periodicas (diarias o dos veces por dia) con el lider de proyecto (tu tutor en este caso) y no se como es tu caso, pero en general no he visto que un tutor se involucre tanto en una tesis.
Saludos Pedro, y gracias por tu colaboración.
FÃ_jate, en mi caso, la tesis la estoy haciendo yo solo porque normalmente la gente saca la tesis de su lugar de trabajo y yo actualmente no estoy (ni para el momento que tuve que formular un tema) trabajando en ningún sitio relacionado ni remotamente al desarrollo de juegos; y además no existÃ_a entre mis compañeros de clases alguien con quien me sintiera lo suficientemente cómodo como para trabajar en el proyecto final de grado.
Por otra parte, quisiera saber qué metodologÃ_a utilizan ustedes para el desarrollo de proyectos pequeños. Esto no sólo me servirá para mi proyecto de grado sino también para ir educándome más en cuanto a la industria y eventualmente conseguir empleo jeje
Hola pctroll,
Yo te diria que usases cualquier metodologia basada en objetos (OMT y/o RUP), pero para mi lo que te diria que es fundamental es que aprendas UML como herramienta de diseño, en especial los diagramas de casos de usos, secuencia y clases. (Estos son los que particularmente utilizo siempre)
Por otro lado, aunque no esta relacionado a la metodologia, queria aprovechar la ocasion para recomendarte que comenzaras a empaparte en lo que son los sistemas de control de codigo fuente, tales como Sourcesafe (ahora Team system), Perforce, CVS o Subversion.
Yo tu utilizaria este ultimo que es codigo abierto, facil de utilizar y muy versatil. Lo bueno de estos sistemas es que generalmente todas las compañias de desarrollo de software utilizan alguno (por lo que la experiencia en el area se agradece), y por otro lado, puedes trabajar tranquilo de que en caso de un error grave tu tesis esta resguardada en un sitio seguro.
Hola, XP es un proceso de desarrollo de software basado en iteraciones (como Uds. ya saben).
Yo si la he utilizado en el trabajo y en trabajos universitarios con buenos resultados. AquÃ_ http://ccg.ciens.ucv.ve/~esmitt/docs/Addison.Wesley.Extreme.Programming.Explored.pdf encontras un libro de William Wake que a mÃ_ me sirvio muchÃ_simo para entenderlo.
Espero que te sirva
saludos
Hola, luego de haber programado por décadas te puedo decir que para desarrollar software lo único que tienes que hacer es inventariar las salidas del sistema. Si empiezas por las entradas, o te pones a diseñar la base de datos, o cualquier otra cosa que no sean las salidas, estarás perdiendo el tiempo.
Para cada salida, debes inventariar qué necesitas para producirla, y esto te dará las entradas y procesos que el sistema debe utilizar.
Este es el primer paso obligatorio en la metodologÃ_a Cavallin, es decir, la mÃ_a, y funciona 100% a la perfección y nunca falla, pues siempre logro que el sistema cumpla con su objetivo.
Te darás cuenta cuando desarrolles sistemas, que el cliente o usuario no sabe exactamente lo que quiere, y por eso no se logra inventariar en detalle estas salidas, y asÃ_ es que los proyectos salen mal. El cliente te va a dar instrucciones al estilo "necesito saber si la persona habla inglés", y tu vas a poner tu campo booleano en tu base de datos de personas "bool speakEnglish", y luego cuando le entregues el sistema te va a decir "dile al sistema que me de los que hablen inglés intermedio", y tu campo booleano y demás pantallas no podrán darte esta información pues el campo ha debido ser un entero indicando que tan bien habla.
Una vez que tienes ese primer paso, entonces el segundo paso es preguntarse ¿Necesito saber cuánto tiempo y dinero me va a costar este proyecto con antelación? Si la respuesta es sÃ_, entonces debes adoptar una metodologÃ_a formal, la cual llevará un gran tiempo y limitará los cambios sobre la marcha; pero te permitirá hacer un buen estimado de cuánto te va a llevar.
Si la respuesta es no, por ejemplo para una tesis o un desarrollo de un videojuego por parte de un grupo independiente, entonces no vale la pena seguir ningún tipo de metodologÃ_a formal sino simplemente repartirse el trabajo entre los integrantes, por lo general dos o tres personas, y listo, a tirar código. ¿Cómo se reparten el trabajo? Ve mi nota al final sobre Kendall.
Luego cada vez que vayan cumpliendo metas, hacen un refactoring para dejar el código bien elegante y bien comentado.
Sobre todo en videojuegos hay que utilizar una metodologÃ_a Agil pues casi siempre tienes una idea pero no sabes si será divertida de jugar, asÃ_ que haces un prototipo lo más rápido que puedas para validar tu idea, asÃ_ el código sea un pasticho. Si la idea resultó buena, haces refactoring y dejas el código pepita.
De Kendall y Kendall debes aprender sólo estas dos lÃ_neas:
Máxima cohesión y MÃ_nimo acoplamiento
(Maximum Cohesion, Minimum Coupling)
Lo demás no sirve en videojuegos, al menos en el gameplay, quizás sirva para desarrollar los tools necesarios para crear los niveles, personajes, historia, etc., pero no para el gameplay. Estas dos máximas de la programación es lo único que me queda de cuando estudié Sistemas de Información hace casi 20 años en la USB.
Entonces de nuevo, ¿cómo te repartes el trabajo? Bueno eso va a requerir que dividas el sistema en módulos desacoplados para que cada quien pueda hacer su parte sin depender del otro. Si se reparten el trabajo y empiezan a depender el uno del otro para que la cosa corra, entonces no hicieron un buen diseño de los módulos a repartirse. O si alguien hace refactoring y entonces deja de funcionar el programa, no hubo un buen diseño ni una buena repartición de funciones.
El último paso de la metodologÃ_a Cavallin es hacer una lista grande y detallada de todas las pruebas que se desean hacer al sistema, y el resultado que se espera obtener. Luego hacer estas pruebas y repetirlas hasta que todas estén Ok.
En resumen, la metodologÃ_a Cavallin es la siguiente:
* Inventariar Salidas. Esto lo llaman el Business Requirement.
* Inventariar Entradas para generar estas salidas
* Inventariar Procesos para generar estas salidas
* Hace estimación de tiempo y costos si aplica
* Crear una Especificación Funcional. Es decir, separar los procesos inventariados de captura de entredas y transformación en salidas de tal manera que cada módulo pueda ser desarrollado de forma independiente sin depender de cómo el otro programador implementa su módulo. Cada módulo debe indicar qué transformación aplicará a los datos, incluso con pseudo código si se desea delegar este trabajo en un programador Junior.
* Ajustar estimado si aplica. Ajustar alcance si los costos y tiempos no dan.
* Tirar código como locos
* Validar que se obtiene lo que se quiere
* Hacer refactoring para dejar todo elegante y fácil de mantener
* Volver al punto de Tirar código hasta terminar el sistema.
* Producir documento de Test Script (puede hacerse sobre la marcha)
* Hacer Pruebas
* Invitar al usuario a hacer sus propias pruebas.
* Documentar
* Entregar formalmente sistema y caerse a curda con el resto del equipo de desarrolladores.
Gente!!
MuchÃ_simas gracias a todos por su aporte y de verdad Andrés gracias por tomar el tiempo de escribir el post bien bien detallado. Tomaré el post como fuente de información tecnológica para mi proyecto.
Por otro lado, en mi universidad los prof. son muy ortodoxos y como te digo; les gusta que uno use metodologÃ_as complicadas aunque sean proyectos pequeños. AsÃ_ que discutiré con mi tutor lo que he buscado, sus opiniones y el aporte que aquÃ_ en la comunidad he recibido para justificar todo en mi proyecto y asÃ_ llevarlo a buen término metodológico.
De todas maneras, seguiré pidiendo las notificaciones por e-mail para estar al tanto de cualquier otro aporte.
Una vez más, muchÃ_simas gracias a todos.
Hola pctroll,
Bueno, yo particularmente tengo mala experiencia con eXtreme Programming, SCRUM o cualquier tecnologia enmarcada en Agile software development, por lo que de plano mi opinion esta sesgada, pero bueno igual sigo por si te sirve de algo.
He escuchado de algunos estudios que han utilizado SCRUM y aparentemente les va bien, de cualquier forma mi problema con este tipo de iniciativas (o por lo menos de la forma en que fue aplicada cuando estuve involucrado con ella), es que se le da toda la responsabilidad de la vision del proyecto al lider del mismo, uno tenia que enmarcarse al task card que le habian asignado y en definitiva todos haciamos pequeñas tareas pero nadie sabia exactamente como ensamblarlas, dado que soy Ingeniero en Sistemas, esto iba en contra de toda la educacion formal que nos habian dado sobre la vision del sistema como un todo y la interaccion de sus partes, etc. Esa sensacion de trabajar de manera reduccionista me resulto muy chocante.
Hay que agregarle, que la persona que llevaba el proyecto (el ser mas chocante que te puedas imaginar) se le antojo de escoger la rama mas purista de la tendencia agil (y para mi fue hasta mal interpretada), y practicamente no hubo diseño, asi que se creaban clases y metodos y la gente que le tocaba trabajar despues con ellas no sabian que existian y muchas veces reinventaban la rueda, todo esto desplegando la bandera del refactoring por todo lo alto... en fin...
Aunque no me gusta para nada, debo aceptar que aprendi de alli habitos muy saludables, el mismo refactoring (no tener miedo a reorganizar el codigo) y las unidades de pruebas son tecnicas que agradeces siempre, pero que yo no las veo para nada atadas a una metodologia como tal.
Por otro lado, en tu caso no veo tan claro el uso de esta metodologia, en primer lugar si es una tesis usualmente el grupo es de dos personas y en raras ocasiones las he visto de tres, y una de las tecnicas de la tecnologia es el pair programming (o programacion en par) en donde literalmente estaran dos personas sentadas frente a un solo computador trabajando en lo mismo, y considerando que en una tesis el tiempo es super valioso no creo que sea lo mas indicado. Por otro lado, otro de los puntos es hacer reuniones bastante periodicas (diarias o dos veces por dia) con el lider de proyecto (tu tutor en este caso) y no se como es tu caso, pero en general no he visto que un tutor se involucre tanto en una tesis.
Como te dije antes, tienes que ponderar mi opinion con el hecho de que es una opinion sesgada, y cada proyecto es un mundo diferente, pero igual crei conveniente contarte mi experiencia para que por lo menos estes avisado de los posibles contras de la metodologia.
Para las personas que no estan muy empapadas con el tema les coloco algunos link:
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Scrum_(development)
http://pages.cpsc.ucalgary.ca/~sillito/seng-301/lecture-notes/what-is-scrum.pdf
Saludos,