Historias
Slashboxes
Comentarios
 

Taiga: Gestor de proyectos agiles

editada por Drizzt el Jueves, 02 Octubre de 2014, 14:40h   Printer-friendly   Email story
desde el dept. agil-develop
pobrecito hablador nos cuenta: «Se ha publicado Taiga, un gestor de proyectos ágiles libre. Está desarrollado por la empresa española Kaleidos, que da la opción de utilizarlo como servicio en su propia infraestructura o descargarse el código fuente de su repositorio en github y desplegarlo en servidores propios. Está construido usando Python, Django, Postgresql para el backend y Angular-JS para el frontend. La licencia con la cual se ha publicado es la Affero GPL

Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Efecto Barrapunto?

    (Puntos:2)
    por Linuxtron (1489) el Jueves, 02 Octubre de 2014, 18:47h (#1364921)
    ( http://ch3m4.org/ )

    Es interesante ver el vídeo [youtube.com] que visualiza lo que tuvieron que aguantar los servidores de Kaleidos durante la avalancha de visitas cuando apareció la noticia en @HackerNewsYCBot. No creo que esta vez el Efecto Barrapunto sea significativo en comparación.

    Si alguien quiere probar ya, se puede entrar desde tree.taiga.io [taiga.io]

    [ Responder ]
  • por pobrecito hablador el Domingo, 05 Octubre de 2014, 13:52h (#1364981)
    Es muy fácil... coge tu proyecto y tíralo hacia arriba. Si cae con las patas para abajo es ágil, si no es de windows. Y si se queda pegado al techo es que se ha hecho en una cárnica.
  • Re:¿Que hostias es un proyecto agil?

    (Puntos:1, Informativo)
    por pobrecito hablador el Lunes, 06 Octubre de 2014, 07:26h (#1364988)
    Simplificándolo mucho, podríamos dividir la ejecución de proyectos de dos formas principales: ágiles y tradicionales.

    El modelo tradicional, de los que probablemente el más famoso sea el modelo en cascada, divide el proyecto en etapas bien definidas y aisladas la una de la otra, como por ejemplo: captura de requisitos, estimación, planificación, desarrollo, pruebas, mantenimiento, ... A una etapa no se pasa hasta que la anterior se ha completado, y si algo cambia a posteriori con impacto sobre el software, hay que volver a repetir todas las etapas. Es un proceso relativamente estricto y poco flexible, muy basado en la ingeniería tradicional. Por otro lado, la implicación del "cliente" (el que paga a los desarrolladores) es limitada, es un poco "yo te digo lo que quiero, y tú me lo das ya hecho, cómo lo hagas y cómo te organices, a mí me da igual". El problema más típico es que el cliente no reciba lo que quería o necesitaba. Lo peliagudo es que no es solo responsabilidad de los analistas el plasmar correctamente los requisitos del proyecto, sino que a veces el cliente no sabe explicar exactamente lo que quiere, o incluso no sabe lo que quiere.

    El modelo ágil viene a romper esa rigidez, y a día de hoy, SCRUM es sin duda el modelo más famoso. Existe un "manifiesto ágil" que habla de cuatro puntos importantes en los que se basa una metodología ágil:

    • Personas y relaciones son más importantes que procesos y herramientas.
    • Software que funcione es más importante que documentación exhaustiva.
    • La colaboración con el cliente es más importante que las discusiones contractuales.
    • La habilidad para responder efectivamente ante los cambios es más importante que seguir una planificación.
    Luego ya, a partir de ahí, hay diversas formas de aplicarlo, pero vista la tendencia general, los cambios clave de una metodología ágil están en la forma de organizarse y en la implicación del cliente. Los requisitos se dividen en unidades de trabajo que se puedan realizar de forma lo más aislada posible, y en períodos de tiempo reducidos, de tal forma que se pueda disponer de una lista de tareas fácil de organizar y repartir en base a las estimaciones del equipo. Por otro lado, el desarrollo se divide en sprints cortos (de 1 a 3 semanas, más o menos), con la idea en mente de que al final de cada sprint, se entrega una porción del proyecto que se puede usar y probar, y ahí es donde el cliente es capaz de ver de primera mano cómo se va formando el producto que ha encargado, pues el cliente es parte tanto de la evaluación del resultado del último sprint, como de la planificación inicial sobre lo que es importante para el próximo sprint, siendo capaz de detectar fallos mucho antes que en un proceso tradicional, y pudiendo reasignar prioridades de forma mucho más flexible.

    Aparte de detectar antes malentendidos en los requisitos y errores de diseño, un proyecto ágil en teoría lidia mejor con los retrasos, porque el cliente es capaz de priorizar y desechar requisitos que no sean críticos, por lo que si se agotan los recursos (bien sea tiempo, bien sea presupuesto), se puede parar el desarrollo y tendrá un producto usable. En un proyecto tradicional, si los recursos se acaban de forma súbita, tendrá un producto a medias, que puede que sea usable o puede que no, por muchísimas posibles razones.

    Sobre qué es mejor o peor, pues esto es como todo. No hay balas de plata en el desarrollo de software. Dependiendo del proyecto, será más recomendable ágil, tradicional, o una mezcla de ambos.

  • Re:¿Que hostias es un proyecto agil?

    (Puntos:1, Informativo)
    por pobrecito hablador el Lunes, 06 Octubre de 2014, 09:24h (#1365000)

    Con ágil se refieren a metodologías ágiles para desarrollar proyectos informáticos. Y el taiga del que habla se supone que es una herramienta de software que ayuda a hacer un seguimiento de proyecto basado en metodologías ágiles

    Teniendo en cuenta que un porcentaje altísimo de proyectos fracasan o multiplican por dos o por tres o por diez sus plazos (y coste), se está buscando desesperadamente una metodología para desarrollar el trabajo y que llegue a buen puerto (siguiendo estos pasos, apuntado esta información, planificando según estos criterios, y realizando estas pruebas, todo proyecto tiene final feliz). Las metodologías tradicionales se basan en hablar con el cliente, escribir unos requisitos, ir desarrollado por fases etc etc. La metodologías ágiles se basan en ir hablando continuamente con el cliente para ir ajustando sobre la marcha.

    Realidad: Tienen aproximadamente el mismo éxito que las tradicionales, es decir 'mu' malo. Al final, lo que más cuenta es la experiencia y capacidad de director del proyecto. Si no la tiene, ni cascada, ni ágil, ni nada. Si la tiene, se adaptará a lo que haya, y probablemente será un a combinación de lo que hay, más cosas propias (Seguramente escribirá un libro creando una nueva metodología que, como las otras, al que no está fogueado no servirá de nada).

    Las metodologías ágiles son sólo la última moda, pero en lugar de originado en las grandes corporaciones, se ha original en el mundo del software libre y aledaños, con lo que es mucho más "cool".

    Te recomiendo que leas esta historia en la misma barrapunto del 2012 En defensa de la 'cascada' [barrapunto.com]. Es muy instructivo, y léete los comentarios, que algunos no tienen desperdicio.

  • 4 respuestas por debajo de tu umbral de lectura actual.