3 respuestas en este tema

[felipe]

Que tal compañeros, hace un buen tiempo he venido estudiando un poco sobre las metodologías ágiles de desarrollo de software, que aunque no es un tema tan reciente, es muy poco tratado o mencionado en la comunidad. Muchos de ustedes trabajan en grandes grupos de desarrollo o empresas que llevan experiencia en el tema.

Al paso que he encontrado información la afinidad por el tema se vuelve mayor, ya que no se trata simplemente de apegarse a un lenguaje en común o un framework de desarrollo, se trata es de una metodología para buscar generar un flujo de mejor eficiencia en los procesos de desarrollo de software.

Cuando se habla de metodologías ágiles viene a lista algunas como XP, Scrum y RUP. Existe otro esquema denominado Kanban pero no aparece como una metodología. Las empresas que han logrado posicionarse en temas de desarrollo y lograr valoraciones CMMI, en general han creado híbridos, algunas usarán Scrum pero manejan UML que es propio de RUP, de igual modo Kanban para organizar el trabajo.

Hoy leyendo un artículo nombrado "Cómo escribir historias de usuario" he encontrado algo llamado Behaviour Driven Development, que al mismo tiempo me permitió encontrar una herramienta para la implementación del mismo aplicado a Delphi. En general las hay en varios lenguajes, pero viendo lo educativo que puede ser para muchos, vine a la comunidad para compartir con ustedes http://sourceforge.net/projects/dspec/

Sería interesante ver más comentarios al respecto, conocer experiencias y/o aportes a dicho tema, que en algún momento o si ya no lo es, será de gran utilidad para todos nosotros.


Saludos!

[Delphius]

Yo no estoy totalmente informado sobre las metodologías ágiles pero si me lo permites quisiera hacer algunas observaciones:

Que tal compañeros, hace un buen tiempo he venido estudiando un poco sobre las metodologías ágiles de desarrollo de software, que aunque no es un tema tan reciente, es muy poco tratado o mencionado en la comunidad. Muchos de ustedes trabajan en grandes grupos de desarrollo o empresas que llevan experiencia en el tema.

Últimamente scrum viene ganando terreno, y cada vez son más quienes se vuelcan a ésta metodología. Más que nada por sentir un fracaso por conducir el proceso del desarrollo con otros paradigmas.
scrum sólo es posible de llevar a cabo siempre que se tenga un equipo mediano a grande y bien consolidado, ya que se requiere hacer trabajo de a parejas que se van rotando y es fundamental que el equipo entero esté bien aceitado.
Por tanto si no dispones de una buena cantidad de mano, y/o no hay demasiada confianza en equipo lo mejor es ir a por una estructura más rígida y formal. Scrum hace la asunción de que ya existe confianza y cada uno sabe trabajar bien´por lo que adopta una postura más flexible en esto... otros paradigmas refuerzan formalmente la presión a que se organicen... de allí que para equipos que recién se están acomodando, scrum puede ser más un reto.

Cuando se habla de metodologías ágiles viene a lista algunas como XP, Scrum y RUP. Existe otro esquema denominado Kanban pero no aparece como una metodología. Las empresas que han logrado posicionarse en temas de desarrollo y lograr valoraciones CMMI, en general han creado híbridos, algunas usarán Scrum pero manejan UML que es propio de RUP, de igual modo Kanban para organizar el trabajo.

Bueno, este... RUP no es una metodología ágil; es más ni siquiera es una metodología. RUP es un proceso, un paradigma de desarrollo; como así también lo son Secuencial/Cascada, Prototipado, y Espiral por dar otros ejemplos de modelos.
No hay que confundir los paradigmas o modelos con las metodologías.
La confusión es que tanto las metodologías ágiles como UP y sus derivados (RUP y USDP) comparten un conjunto de buenas prácticas. Por ejemplo, la idea de hacer codigo primero y después documentar es compartida por XP y RUP. O la de dirigir el proceso según los casos de prueba (unit testing first) también.
No es que existe un UML propio de RUP, sino más bien que se trata de un modelo propuesto por Rational. RUP es un proceso que posee derechos de autor (de hecho quien lo quiera implementar debe pagar a Rational para que le haga la consultoría), y en él han han propuesto un determinado conjunto de disciplinas y organizados los diferentes diagramas UML en modelos para cada disciplina. Todo esto en su conjunto hace a su propuesta que organiza a UML de una forma particular.
No puede haber un UML propio, ¡UML es un estándar y LIBRE!
En vista a esto es que han aparecido otras corrientes del Proceso Unificado (Unified Process, UP), como la USDP o Proceso Unificado de Desarrollo de Software (Unified Software Development Process ) que son más general y tienen sus similitudes con RUP pero que no tiene una licencia restrictiva.
Kanban me suena... pero no con algo relacionado con metodologías o un modelo de proceso. Creo recordarlo en algo sobre métricas... No lo he investigado la verdad.

Hoy leyendo un artículo nombrado "Cómo escribir historias de usuario" he encontrado algo llamado Behaviour Driven Development, que al mismo tiempo me permitió encontrar una herramienta para la implementación del mismo aplicado a Delphi. En general las hay en varios lenguajes, pero viendo lo educativo que puede ser para muchos, vine a la comunidad para compartir con ustedes http://sourceforge.net/projects/dspec/

Sería interesante ver más comentarios al respecto, conocer experiencias y/o aportes a dicho tema, que en algún momento o si ya no lo es, será de gran utilidad para todos nosotros.
Saludos!

He escuchado tanto el término Historias de usuario, y en ese entonces creía que tiene su similitud a los casos de uso pero nunca me dí el tiempo para investigarlo de que se trata. De lo que leo en ese enlace veo que no es ni remotamente parecido a lo que me imaginaba. El término de Desarrollo  dirigido por el Comportamiento no me suena... Lo máximo que es escuchado de parecido es el Desarrollo dirigido por Contratos; otros de los artefactos que propone la filosofía UP/USDP/RUP.

Saludos,

[felipe]

Bueno, este... RUP no es una metodología ágil; es más ni siquiera es una metodología. RUP es un proceso, un paradigma de desarrollo; como así también lo son Secuencial/Cascada, Prototipado, y Espiral por dar otros ejemplos de modelos.

Válida la aclaración Delphius, lo menciono precisamente por ser un modelo que aunque muchos vemos en papel, tiene una aplicación en el mundo real, pero no como una idea cerrada sino adaptable, ahí donde mencionaba que quienes aprovechan estos recursos los acomodan a su necesidad, criterio o interés.
Si bien UML es libre de aparecer donde le guste (lo considero incluso aplicable a cualquier materia) en principio es muy asociado a dicho modelo RUP, quizá porque nunca se aborda a profundidad del tema a nivel educativo, y es más por capacidad autodidacta que abrimos esa ventana para ver que sigue. Se despejan muchas dudas y siempre habrá algo que aprender.
Fíjate que Kanban suena muy interesante, tiene gran similitud con Scrum pero sin pretender ser tan estricto, ya que el tiempo y el trabajo tiene más libertad que la planteada en los sprint de Scrum. Hace poco leí un documento en donde se hace una aproximación y comparación de ambos.
Lo de historias de usuario parecen propio de Scrum y Kanban, son las particulares notas adhesivas de los tableros, a mi parecer vienen siendo un resumen de lo que podría ser en mayor detalle un caso de uso, por hacer una comparación.

Si alguien aquí tiene una experiencia real de trabajar con "agile", esperamos conocerla .


Saludos!

[Delphius]

Válida la aclaración Delphius, lo menciono precisamente por ser un modelo que aunque muchos vemos en papel, tiene una aplicación en el mundo real, pero no como una idea cerrada sino adaptable, ahí donde mencionaba que quienes aprovechan estos recursos los acomodan a su necesidad, criterio o interés.

Pues si, la idea detrás de los modelos es que no sean rígidos, sino que uno les incorpore elementos. De hecho, ningún paradigma de proceso te dice QUE has de hacer... eso te lo dejan a ti, sino que proponen un conjunto de actividades en las que se han de organizar, tus propias actividades reales (lo que Pressman denomina actividades estructurales). En todo caso se podría decir que los procesos dicen un sutil COMO.
Los procesos ofrecen un marco de trabajo, luego queda en uno en aplicarlo.
Distinto es lo que sucede con las metodologías, que mezclan QUES y COMOS de una forma particular y ofrecen un libreto que hay que seguir rigurosamente de otro modo no resulta.

Es muy habitual que uno termine combinando dos o más paradigmas de desarrollo. De hecho yo tengo una carpeta que forma parte de mi desarrollo profesional con las descripciones de cada modelo que he estudiado, y tengo unas tablas que me sirven de apoyo para determinar las posibles combinaciones de dos modelos cualesquiera. De este modo puedo apreciar como sería el marco de trabajo si empleare Prototipado combinado con Secuencial, por ejemplo. Me ha llevado un  buen tiempo pero eso me ayudó a comprender justamente lo que es en verdad el marco y cuando se convierte en las actividades reales.

Si bien UML es libre de aparecer donde le guste (lo considero incluso aplicable a cualquier materia) en principio es muy asociado a dicho modelo RUP, quizá porque nunca se aborda a profundidad del tema a nivel educativo, y es más por capacidad autodidacta que abrimos esa ventana para ver que sigue. Se despejan muchas dudas y siempre habrá algo que aprender.

Pues si, he apreciado esa confusión... en muchos usuarios de Y!R. Asocian a UML como algo que pertenece a RUP. Es más, se tiene la creencia de que aplicar RUP implica y es hacer POO.
Grave error conceptual, porque el paradigma de desarrollo o proceso es independiente del paradigma de programación (quizá lo que confunde a muchos es justamente la palabra paradigma y ya uno piensa que se refiere a una forma más de programar).
El problema es que UP apareció justamente para dar respuesta a necesidades y dificultades que se estaba teniendo con la transición del paradigma estructurado al paradigma orientado a objetos y este nuevo enfoque les desordenó la casa... trayendo la 2da gran crisis del software. Entonces se terminó asociando erróneamente que hacer UP es emplear POO.
Pero lo cierto es que nada impide que se adopte uno de los modelos UP y estar desarrollando la aplicación con el pensamiento estructurado. E incluso, nada impide tampoco, viendo otro punto extremo, en utilizar Secuencial o Cascada para un desarrollo basado en POO.

Fíjate que Kanban suena muy interesante, tiene gran similitud con Scrum pero sin pretender ser tan estricto, ya que el tiempo y el trabajo tiene más libertad que la planteada en los sprint de Scrum. Hace poco leí un documento en donde se hace una aproximación y comparación de ambos.
Lo de historias de usuario parecen propio de Scrum y Kanban, son las particulares notas adhesivas de los tableros, a mi parecer vienen siendo un resumen de lo que podría ser en mayor detalle un caso de uso, por hacer una comparación.

Si alguien aquí tiene una experiencia real de trabajar con "agile", esperamos conocerla .


Saludos!

Pues tendré que investigarlo. A ver si logro darme un tiempo.

Saludos,