style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Metodologia

Que tal Comunidad:

Que metodología de las llamadas "ágiles" me recomiendan para un proyecto rápido en java .

He leído y escuchado algo de XP, Scrum pero aun no defino cual seria la ideal.

Mi aplicación sera un sistema que ayude al control y registro de vales, cheques, agenda de cobros y pagos
del departamento de ingresos de la empresa donde trabajo.

Sera como una ayuda, para que no manejen todo de manera manual.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de neko069

Reglas

Sería mejor que le echaras una leída a las reglas para extreme programming y las reglas de Scrum

Ya en base a lo que mejor se acople a tu proyecto, sacas conclusiones.

Imagen de Algus Dark

Scrum

Yo he trabajado con la metodología Scrum, si no me equivoco el XP viene de la programación extrema donde uno de sus métodos es la programación en par, donde son dos programadores por PC. La idea de una metodología Ágil es eso, agilizar las iteraciones de tu producto, hacer que tus tiempos de entrega no sean en lapsos de tiempo tan grandes.

Debes tener en mente que programación Ágil no significa que vas a hacer menos cosas, o que simplemente adiós a la documentación. No, la programación Ágil te servirá para entregar tu trabajo en lapsos de 2 a 3 semanas (tu pones el límite de tiempo) con un producto funcional, para esto debes de organizarte para decir cuales puntos son los esenciales para tu sistema.

Por experiencia puedo decirte que SCRUM es un método muy bueno, trata de investigar un poco más y verás cómo te servirá. Éste tipo de metodologías las haces para hacer entregables, o ese es mi caso.

Saludos!

Imagen de CesarAlducin

Por lo que estuve

Por lo que estuve investigando Scrum es para desarrollarla en un esquema de equipos,
con varias iteraciones, el problema es que soy solo yo el programador y necesito
una metodología que como dice @Algus Dark me permita entregar mi proyecto funcional en un lapso corto.

Imagen de ezamudio

ninguna

Ninguna metodología te ayudará a entregar un proyecto en un lapso corto. De hecho si quieres entregar algo rápido, pues mejor no uses ninguna metodología.

Las metodologías son para que entregues resultados de calidad, de manera repetible, al tener un proceso definido (ya sea rígido o flexible) y documentar las etapas del mismo, y que durante el proceso (y al final) puedas identificar qué hiciste bien, qué hiciste mal, etc.

Por lo tanto cualquier metodología que sigas va a tomarte más tiempo en tu desarrollo, porque va a ser la primera vez que la utilices. Solamente si ya tuvieras tú experiencia en alguna metodología, te podría ahorrar tiempo, en tus siguientes proyectos. Pero no en el primero.

Imagen de Algus Dark

@CesarAlducin

Creo que se malentendió mi frase h"acer que tus tiempos de entrega no sean en lapsos de tiempo tan grandes", me refería a las iteraciones, un proyecto de 2 años puedes hacer entregables funcionales en iteraciones de 3 semanas.

Te dejo unas caricaturas muy buenas

Y como dice Ezamudio, ninguna te va a servir para lo que estás tratando de realizar... si quieres entregar algo rápido... no duermas! jejeje.

Muchas veces es burocrático

El desarrollo ágil se consigue con un equipo de trabajo autodirigido y que se entiende bien. No es que las metodologías no tienen su lugar, pero, para poder definirlo en el caso necesitaríamos saber el tamaño del equipo de desarrollo, el tipo de proyecto y otras cosas más.

He visto quebrar empresas que usan PSP, TSP y CMMI; así cómo también he visto empresas que entregan trabajos a tiempo con un equipo que se entiende y que no hace más que trabajar y comunicarse. He visto cómo muchas empresas dejan de lado Scrum, Extreme Programming y cualquier otro esquema similar.

Imagen de CesarAlducin

De hecho si quieres entregar

De hecho si quieres entregar algo rápido, pues mejor no uses ninguna metodología

Es precisamente lo que hacen en el lugar donde trabajo, solo crear algunos diagramas UML y comenzar a programar
hasta ahí todo bien, el problema es cuando el usuario final nos dice es que quiero que le modifiquen porque ahora necesito que haga esto...... y nosotros nos quedamos con cara de "What".

Por ello es que a mi parecer si ocupamos una metodología adecuada podemos dejar nuestro proyecto
si no a un 100% modificable si lo suficiente para adaptarlo a las nuevas necesidades del usuario final.

chequen esto que encontré sobre desarrollo iterativo

http://robertoyudice.com/programacion/introduccion-al-desarrollo-de-soft...

Imagen de Algus Dark

@CesarAlducin

Es el asunto final que nos sucede siempre, el usuario quiere una modificación. Será muy raro cuando no te encuentres con un usuario que haga lo contrario. Lo que puedo recomendarte es que hagas una muy buena entrevista con el usuario, y ya sabes, el usuario piensa que es lo que quiere y tu eres el que puede decirle qué le serviría y qué es lo que finalmente puedes entregarle. Si puedes, involúcralo en el avance de tu sistema, hazlo saber los tiempos de desarrollo. Yo lo que siempre hago es realizar primero la interfaz para que el usuario le de su visto bueno, no tiene que ser el final pero sí una idea de lo que te ha hecho saber.

Re: De hecho si quieres entregar

Este tipo de problemas es muy general, y pasa porqué siempre la vemos bien simple. Si nos dicen: "Quiero un programa que me haga una suma", nosotros cómo programadores muchas veces no analizamos y para pronto en la mente tenemos:

public class Suma{
----private Integer valorPrimero, valorSegundo;
----public Suma(Integer valorPrimero, Integer valorSegundo){
--------this.valorPrimero = valorPrimero;
--------this.valorSegundo = valorSegundo;
----}

----public Integer mostrarResultado(){
--------return this.valorPrimero + this.valorSegundo;
----}
}

// Y en la clase principal:
public class Main{
----public static void main(String ... args){
--------System.out.println("Bienvenido al SumCenter \n Ingrese el primer valor:");
--------Scanner scanner = new Scanner(System.in);
--------Integer valorPrimero = scanner.nextInt();
--------System.out.println("Ingrese el segundo valor:");
--------Integer valorSegundo = scanner.nextInt();
--------Suma suma = new Suma(valorPrimero, valorSegundo);
--------System.out.println("El valor de la suma es: " + suma.mostrarResultado());
----}
}

Le entregamos al cliente y en eso hace sus propias pruebas e ingresa los valores: 10.06 y 0.985; y nos llama: "Oiga, pues el programa deja de funcionar cuando ingresamos los valores"...ya después te das cuenta que lo que quieren es poder sumar números enteros y decimales. Haces los cambios pertinentes:

public class Suma{
----private Double valorPrimero, valorSegundo;
----public Suma(Double valorPrimero, Double valorSegundo){
--------this.valorPrimero = valorPrimero;
--------this.valorSegundo = valorSegundo;
----}

----public Double mostrarResultado(){
--------return this.valorPrimero + this.valorSegundo;
----}
}

Y listo, volvemos a entregar, y el cliente haciendo sus pruebas luego ingresa los valores: 'y' y 'h'...Llama el cliente y dice: "Oiga, el programa sigue fallando al ingresar valores"...Uno después de hablar con el cliente se da cuenta que lo que busca el cliente es un programa que también sea capaz de hacer una suma algebraica....y así se repite muchas veces.

El problema en el hipotético caso que plantee es falta de análisis y hacer una arquitectura limitada de la aplicación sin pensar en más. Lo pertinente ahí es una entrevista larga y que parezca bien cómo manual gringo de un televisor (¿nadie ha comprado televisiones en E.U.A?, pues los que han comprado verán que viene instructivo hasta para conectarla), si se que los gringos exageran en lo explícitos que son, pero, con el usuario uno tiene que ser así. Hay una frase que dice: "Hay que programar cómo si un estúpido fuera a usar este sistema".

Imagen de neko069

Si no hay tiempo de usar

Si no hay tiempo de usar metodología, por lo menos genera algunos diagramas, y agrega a tus clases comentarios a más no poder, además de especificar algunas convenciones de código, por ejemplo, para discernir entre interfaces e implementaciones pueden usar el nombre + i mayúscula, o el prefijo Service, definir que las definiciones de clases, interfaces, métodos y propiedades sean en inglés o español ... ésto lo he visto, en distintos proyectos y te da una idea de la capa a la que pertenecen las clases, igual para el empaquetado, si van en servicios, daos, utilerías, front, etc.

Si no hay tiempo de establecer documentación formal, cuando menos cuida el detalle de que el código sea autodescriptivo e hiperdocumentado.

Imagen de CesarAlducin

dos puntos claves en los

dos puntos claves en los comentarios que me acaban de hacer, el primero es hacer una buena entrevista
para conocer del todo lo que quiere el usuario y mas que ello a mi parecer es pensar a futuro que modificaciones
o que alcances pudiera tener el sistema que se esta desarrollando, es decir quizá sea un modulo pequeño que
con el tiempo se convertirá en un sistema Grande, o quizá con lo que se haya realizado sea suficiente y solo
se tenga que dar mantenimiento a la aplicación en ciertos momentos.

Y el otro comentario que el código sea auto descriptivo e hiperdocumentado al grado de que ya sea yo como desarrollador inicial del proyecto o algún otro programador que haga mantenimiento del mismo pueda
hacer las modificaciones/adecuaciones necesarias.

Sin duda alguna acudir a foros como este ayudan mucho y en base a la experiencia de los demás
podemos mejorar en mucho nuestra forma de trabajar.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">