Actividad 1606 -Agilidad… ¿siempre es mejor?

Mucho de esta  materia nos lleva a hablar de agilidad y queremos escuchar tu opinión: ¿Crees que siempre es mejor trabajar con Metodologías Agiles?

Si crees que es así, fundamentá y proveé ejemplos. Si crees que no siempre, da un ejemplo claro y concreto en que sí y otro claro y concreto en el que no. Fundamentá en ambos casos.

Anuncios
Publicado en Sin categoría
29 comments on “Actividad 1606 -Agilidad… ¿siempre es mejor?
  1. Maximiliano Prystupiuk dice:

    No siempre.

    Caso en que sí: En una materia de la facultad para un trabajo práctico estamos usando scrum (junto con otras prácticas agiles) con mi grupo. Los profesores evalúan y especifican requerimientos cada dos semanas, por lo que es un caso ideal.

    Caso en que no: En la clase de “Escalera de inferencia” se presentó el caso de un proyecto avanzado, atrasado en fechas y que debía lanzarse al mercado en la brevedad. Un cambio brusco hacia metodologías agiles no era prioritario ni recomendable.

  2. En mi opinión, siempre que se empiece un proyecto de 0, y que la duración del mismo sea lo suficientemente larga como para usar metodologías ágiles (proyectos de 1 o 2 días) conviene usarlas.

    En mi experiencia, tengo 2 ejemplos muy claros en la facultad de proyectos que fueron un caos (Taller 1) y uno que fue todo lo contrario (Taller de Desarrollo de Proyectos 2), en uno no utilizamos ninguna metodología ágil (no las conocíamos) y en el otro si.

    Entonces como conclusión, para mi siempre conviene utilizar metodologías ágiles.

  3. Yo creo que siempre conviene utilizar metodologías ágiles. Es una buena forma de organizar todo el proyecto y poder tener un seguimiento de todas las tareas que se van realizando.

    Como ya mencionaron, por desconocimiento, en la mayoría de las materias de la facultad que requerían la realización de un trabajo practico grupal de programación, no aplicamos metodologías ágiles y la verdad que a veces era muy difícil saber el estado de las tareas que teníamos que realizar, quien las estaba llevando a cabo, los bugs que habían, etc.

    Recién en Taller de Programación II, utilizamos algunas metodologías ágiles como es tener todas las tareas creadas como issues, asignarlas a quien corresponde y tener un seguimiento de que tareas se realizaban en cada commit, branch y sprint. Luego, en Taller de Desarrollo de Proyectos II, si aplicamos bien de lleno scrum junto con otras metodologías y la verdad que la forma de trabajo es mucho mas organizada y hace que el proyecto arranque bien desde cero. Tener bien definido para cada sprint los compromisos, quienes lo va a hacer y toda la documentación que tenemos es muy bueno.

    Por lo tanto, recomiendo siempre arrancar un proyecto utilizando metodologías ágiles. Desde ya, que creo que es muy complejo aplicar metodologías ágiles en un proyecto que ya se encuentra empezado, porque implica un cambio rotundo en la manera de trabajar y probablemente haga atrasar demasiado el avance del proyecto hasta que se logre implementar las metodologías ágiles correctamente.

  4. Yo creo que siempre es mejor, por lo que siempre que se pueda utilizar una metodología ágil recomendaría usarla.
    Permite involucrarse en el proyecto de una forma diferente a otras metodología, enfocándose en entregas parciales, sprints, etc. Logrando, creo yo, un compromiso distinto entre los integrantes del equipo y el proyecto.

    De todas formas, quizás me resulta más difícil ver este tipo de metodologías con grupos muy grandes. En donde creo que la comunicación se hace más complicada.

  5. Uciel Rodriguez dice:

    Mi opinión es que siempre debería usarla. Al menos siempre en proyectos de la vida real (donde se trata de proyectos de variadas escalas: baja, media, alta). ¿Por qué habría de usarse? Básicamente, me baso en seis de los principios del por qué usar Metodologías Ágiles:
    1.- Son más baratas
    2.- Son más rápidas
    3.- Son más flexibles
    4.- La organización del equipo es más sencilla
    5.- Implica más a todo el equipo
    6.- El producto final se ajusta más a lo que quiere el cliente

    El mejor ejemplo que se me ocurre de proyectos grandes que todos los aquí presentes tengamos en mente es el de Taller de Programación, donde por no usar M.A. el producto final, y el desarrollo en si del producto, no se beneficiaba de los sies ítems antes nombrados.

  6. mnforlenza dice:

    Creo que si el equipo esta muy distribuido se pierde todo lo bueno de las relaciones personales y las distintas ceremonias. Lo mismo si el equipo trabaja en distintos horarios, creo que en esos casos por ahi la agilidad no es la mejor metodología.

  7. Juan Manuel Baracat dice:

    En mi opinión, depende del proyecto y del cliente. Me parece una buena metodología cuando tenemos proyectos donde el cliente está muy involucrado y no tiene muy en claro lo que necesita, por lo tanto vamos a necesitar flexibilidad para los cambios.
    Un ejemplo donde vi que les resultaba mejor utilizar cascada en vez de metodologías ágiles, fue en una empresa de telecomunicaciones, donde cada proyecto requería de mucha planificación, burocracia y etapas de control.

  8. Federico Esteban dice:

    No siempre es lo mejor. Mas alla de que depende del cliente siempre, ya que uno tiene que adaptarse siempre al cliente, este “lineamiento” en particular:

    Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

    No siempre es verdad, pues en proyectos realmente grandes, donde se requiera la integracion de varios equipos de desarrollo, se necesita una organizacion inter equipos, o siquiera externa a los equipos, que pueda abstraerse de la implimenetacion de cada uno y tenga una mejor vision global de proyecto (cosa que miembros de uno de los equipos no tendrian)

  9. Mariano Rodriguez dice:

    Creo que hay que saber elegir la metodología en base al proyecto que se tenga que encarar, por lo tanto no me parece que las metodologías ágiles sean “la solución para todos los problemas”.
    Por ejemplo, si el proyecto inicialmente no está del todo definido, o si el equipo de trabajo es relativamente chico me parece que está bueno optar por una metodología ágil.
    En cambio si el trabajo requiere un nivel especial de burocracia, o si es algo de muy poco tiempo de duración, utilizar una metodología ágil para encararlo me parece algo que va a generar más problemas que soluciones.

    Siempre depende del caso, ambiente y contexto en particular.

  10. Gabriel Omar Masi dice:

    Hoy en día los proyectos cambian mucho ya que la demanda es muy variable…
    Por eso es importante tener al cliente involucrado profundamente en los avances del proyecto.

    Sin embargo, si el cliente no tiene horarios para soportar una metodología ágil va a ser bastante molesto implementarla.

  11. Eliana Diaz dice:

    No creo que siempre sea mejor trabajar con Metodologías Ágiles, para mi son ideales para equipos con integrantes de alto expertise, o al menos que los integrantes tenga uno parecido o igual entre ellos, donde todos trabajen la misma cantidad de horas de manera presencial y en empresas organizadas. Para mi estas condiciones hacen que la carga de trabajo sea equitativa entre los distintos integrantes del equipo evitando que se generen malestares.
    Por otra parte, también depende del tipo de contratación que haga el cliente.

    Ejemplo en que NO es aplicable Metodologías Ágiles:
    Se tiene un equipo de cuatro personas, dos juniors y dos seniors, donde no se encuentran trabajando todos en el mismo lugar. Obviamente las horas que insumen los desarrolladores
    juniors para realizar una tarea es mayor a la de los seniors, por lo que los juniors solo resuelven 2 requerimientos de 6 que hay, mientras que los seniors resuelven 4 en total.
    El esfuerzo insumido por todos los integrantes del equipo es el mismo pero puede dar lugar un mal ambiente laboral, porque los seniors pueden pensar que estan haciendo mas trabajo, pues no ven que los juniors efectivamente usaron la misma cantidad de horas que ellos para poder resolver los requerimientos ya que tienen menores conocimientos.

    Ejemplo en que SÍ es aplicable Metodologías Ágiles:
    Un equipo donde todos los integrantes tienen el mismo o parecido expertise, trabajando todos en el mismo lugar.

  12. Manuel Iglesias dice:

    Casi siempre todo depende de su contexto, lo mismo para los proyectos y su desarrollo.
    Creo que la mayoría de los proyectos van bien con una metodología ágil, por eso son tan populares.

    Pero si se tratase de proyectos con contextos menos comunes como por ejemplo:

    – proyectos gigantes con mucha gente de muchos lados de muchos usos horarios y muchas culturas diferentes. Acá creo que una metodología ágil debería hacer una adaptación muy fuerte para funcionar bien. Para eso mejor optar por otra metodología.

    – Para proyectos demasiado pequeños, el uso de cualquier metodología puede hacernos perder más tiempo que el que ganaríamos usándola.

  13. Buenas.
    Creo que depende mucho de la actividad que se realice y el contexto en el que se realice.
    En equipos chicos puede servir, siempre y cuando la metodología no se lleve más tiempo del que no se usaría. Ya cuando el número de personas es demasiado grande, se hace más complicado implementar esto.
    Si se requiere todo documentado con exactitud, no creo que dicha metodología sean las apropiadas.
    Para proyectos con riesgos de cambios continuos, es interesante utilizar metodologías ágiles.

  14. debmarblog dice:

    Las metodologías Ágiles pueden ser útiles, pero no creo que sean aplicables en todos los contextos. Principalmente porque requieren que de los participantes una organización intrínseca, que colabore para el éxito del proyecto. En equipos que tienden hacia la desorganización, usar estas metodologías puede ser perjudicial. En particular, hace poco un compañero me comentó que en su trabajo trataron de implementarlas. Según contó, las reuniones diarias que se extendían demasiado, contribuyeron a cortar en segmentos la jornada laboral, y quedaban tiempos muertos en los que la gente no trabajaba. Por lo que la productividad decayó drásticamente.

  15. Utilizaria metodologias agiles en proyectos chicos o en proyectos asociados a negocios cambiantes. Particularmente trabajo en una empresa donde el negocio es exageradamente cambiante y hay requerimientos que van de un lado a otro en todo momento y es buena idea usar metodologias agiles.

    Por otro lado, en mi trabajo hay también proyectos mas grandes y no tan cambiantes que requieren de un lider de proyecto que pueda coordinar los distintos equipos involucrados en el proyecto

  16. nestor huallpa dice:

    Desde mi punto de vista las metodologías ágiles son siempre aplicables, pero dependiendo del proyecto o contexto en el que se esté, puede utilizarse diferentes frameworks como scrum y Kanban. En mi experiencia personal, pasar de un enfoque en cascada, a un enfoque más ágil fue muy beneficioso, ya que ahora logramos reducir los tiempos de entrega, el usuario obtiene el producto que necesita, y obtenemos un retorno de inversión de manera temprana.

  17. Matias Duarte dice:

    Todo proyecto requiere de un análisis previo para definir que metodología es conveniente utilizar. En muchos casos, encapricharse con una metodología puede llevar al fracaso del mismo. No debe creerse que Scrum va a solucionar todos los problemas.
    Scrum por si solo no es suficiente, debe acompañarse de un conjunto de practicas y otros métodos preferiblemente ágiles. Eso si, no debe implementarse todas juntas de una sola vez.

    Por lo tanto, dependiendo del contexto, utilizaría metodologías ágiles para proyectos dinámicos.

    Para proyectos mas grandes y rígidos convendría analizar la situación y evaluar que es conveniente utilizar.

  18. belubeltran dice:

    En mi opinión sería bueno utilizarlas siempre, ajustándolas a medida.

    Para la facultad hicimos un trabajo en grupo utilizando metodologías ágiles, seleccionando un modelo y adaptándolo a nuestras necesidades. Fue muy buena experiencia, ya que nosotros estábamos en contacto continuo, todos sabían en qué estaba el otro y en qué necesitaba ayuda, a pesar de nuestros horarios muy distintos. Además los profesores hacían un seguimiento semanal, por lo que aprendíamos sobre la marcha y adaptábamos el modelo a lo que el grupo en particular necesitaba.

  19. Daniela Riesgo dice:

    Yo creo que primero está la consistencia y el equipo.
    Como dijeron arriba, si el proyecto ya está empezado y no seguía esa metodología, excepto que se tenga muchas ganas y tiempo para lograr reestructurar todo para implementarlo, no suele ser lo conveniente.
    Segundo, el equipo, si el equipo está en contra, el resultado de la metodología ágil no va a ser bueno. Y es especialmente importante el cliente (o Product Owner, o como la metodología lo llame) y su opinión ya que es el parámetro del éxito o fracaso del proyecto. Aunque hayas conseguido un producto excelente, en excelente tiempo y demás, si el cliente siente, por ejemplo, que es un desastre, que no sabe en qué estado exacto está el proyecto, que nunca se comunicaron bien y demases, porque no le gustó la metodología, el proyecto fue un fracaso.

    Sacando esto, yo creo que es la mejor opción, siempre y cuando se use de la forma correcta, se preste atención a la comunicación, la organización, la disciplina y todos esos aspectos que muchas veces se desvirtúan porque a gente tiene un concepto incorrecto de cómo es la metodología. Creo que no es fácil enseñarle a la gente esto, ya que muchos lo toman como “hay que hacer muchas menos cosas de procedimiento, es más relajado” y creen que mágicamente todo se organiza.

  20. Tobías Lichtig dice:

    No siempre.

    Tiene que poder hacerse una división de funcionalidades/objetivos que puedan hacerse por separado y/o incrementalmente, para poder así ir haciendo iteraciones sucesivas e incrementales. Es especialmente útil si hay muchas chances de cambios de requerimientos a lo largo del proyecto, o si no se tiene del todo claro qué/cómo conviene hacer algo y se pretende descubrirlo probando.

    Por ejemplo, si se va a hacer un sistema de alta complejidad y/o crítico, donde difícilmente haya grandes cambios de requerimientos, probablemente no convenga usar una metodología ágil. Un caso (algo trillado) de esto sería el software de un marcapasos.

    Por otro lado, si sí se puede dividir verticalmente en funcionalidades, es posible hacer primero una pequeña parte e ir evolucionando y agregando sobre eso, y es muy probable que haya cambios en lo que se quiere o se planea hacer a modo de prueba y error para descubrir lo que más sirve, sí conviene. Por ejemplo, desarrollando una aplicación móvil suele ser mejor usar una metodología ágil.

  21. Juan Costa dice:

    Caso en que si: Apps en donde el cliente exige un cambio constante.

    Caso en que no: Tableros de control o implementaciones de BI. Son cosas en las que se hace un entendimiento y un diseño y despues se lo implementa, es raro que tengas que usar una metodología agil si hiciste un buen entendimiento. Los más normal es que hayan cambios simples de diseño.

  22. Kevin Lew dice:

    Yo creo que no siempre es lo mejor. En la mayoria de los casos conviene trabajar con metodologias agiles pero hay casos en los que no. El uso o no de metodologias agiles depende de como este formado el equipo de trabajo y de que tanto este involucrado el cliente en el proyecto

  23. cdesseno dice:

    En particular considero que las metodologías ágiles pueden ser de gran utilidad pero no siempre son viables. Algunas restricciones, en mi opinión son:

    – El tamaño del equipo de trabajo: en equipos de tres o menos personas a veces es más el overhead de utilizar una metodología ágil que las ventajas que puede traer su uso. Obviamente se pueden aprovechar algunas herramientas.

    – En organizaciones donde el equipo está distribuido geográficamente: si bien nunca es recomendable esta situación, a veces se da. Y una metodología ágil hace fuerte hincapié en la comunicación personal entre los distintos participantes y si esto no es posible….

    – El cliente debe entender y participar del proceso de desarrollo. Si no hay un ida y vuelta o el cliente no entiende la metodología de trabajo, poco se puede hacer.

  24. La agilidad no siempre es lo mejor.
    Ademas, no todos los proyectos son iguales.
    Creo que la mejor opcion es sacar de entre todas las metodologias agiles los puntos que mejor se adapten a la situacion.

    En particular, un ejemplo donde sirve ser agiles:

    * Proyecto grande y de larga duracion: Mientras mas largo y grande sea el proyecto, mejor se puede aplicar las metodologias agiles que nos aporten entregas incrementales, pudiendo adelantarle al cliente funcionalidad y descomprimir la entrega final.

  25. Luis arancibia dice:

    Depende del tamaño del proyecto, y también del equipo con el que contamos. Las metodologías ágiles nos aportan muchos beneficios como que permite entregar lo que el cliente necesita de manera incremental, permite adaptarse a los cambios de una manera natural, maximiza la productividad en un equipo bien formado y comprometido.

    Hay casos en que la envergadura del proyecto no amerita usar desarrollo ágil, pero en lineas generales es muy útil.

  26. palmaleandro dice:

    Según lo que vimos en clase no siempre es conveniente aplicar Scrum.

    Según vimos los problemas se categorizan según la complejidad e imprevisibilidad de su dominio. En particular es conveniente aplicar Scrum para lograr avance en problemas con un dominio complejo donde el resultado de las decisiones tomadas no esta claro.
    No es recomendable su aplicacion en dominios caóticos que requieren una solución inmediata.

    Ahora bien, la pregunta va a si las metodologías ágiles son apropiadas siempre. Yo no conozco todas las metodologías y tal vez algunas de estas completen las falencias de Scrum.

    En mi opinión y por lo que aprendí de la materia no siempre es una buena idea usar metodologías ágiles, es una desicion que debe considerarse en conjunto con otras técnicas mas tradicionales.

  27. Nahuel dice:

    Si hablamos de agilidad en proyectos de cualquier tipo diría que no siempre es aplicable.
    Yo veo aplicable las metodologías ágiles en proyectos con las siguientes características:
    * Que el negocio sea muy cambiante
    * Sea complejo
    * No sea necesario tener todo planificado de antemano antes de empezar a construir
    * Se pueda modificar lo construido sin tener que destruir gran parte
    * Donde el cliente o un representante esté cerca del equipo de construcción.

    Por esto no aplicaría agilidad en proyectos del tipo de las grandes obras de construcción, por ejemplo de un puente que cruza un río ya que se necesita una gran planificación previa, no se pueden hacer entregas incrementales rápidas que le den valor al cliente. Es decir, si al final del sprint se entrega una columna del puente no le agregan valor al usuario, pues no podría usar el puente.
    Otro aspecto que impediría aplicar agilidad es que no se puede modificar lo construido como en software. Ej: en el medio de la construcción no se puede decidir levantarlo 20 metros sin tener que destruirlo por completo, o al menos gran parte.
    Además un puente no es propenso a sufrir grandes cambios, el negocio es estable.

    Refiriéndome a la agilidad al desarrollo de software creo que es aplicable especialmente en empresas que quieran desarrollar un producto que a priori no tienen determinado como va a ser pero quieran ponerlo en producción pronto, comenzar a utilizarlo y aprender a medida que el usuario utiliza el sistema. Este podría ser el caso de una startup donde debido a los bajos presupuestos se necesita dar el mayor valor al producto lo antes posible.

  28. Pienso que en los proyectos grandes y a largo plazo siempre es mejor trabajar con metodologías ágiles. Durante el desarrollo de un proyecto prolongado en el tiempo el mercado suele cambiar y estas metodologías se adaptan bien a los cambios. En un proyecto grande el cliente no puede tener en claro cada detalle de lo que quiere, y con una metodología ágil permite corregir el rumbo en cualquier momento. Además disminuye la ansiedad del cliente y de los integrantes del equipo porque se puede ver (y comenzar a usar) los avances del producto sin tener que esperar hasta el final.

    Solamente optaría por una metodología en cascada en un proyecto muy pequeño, que en poco tiempo pueda realizar y entregar (un mes máximo), pues al ser corto se tiene más claro lo que se quiere hacer y es poco suceptible a cambios.

    Ejemplos donde es mejor: Sistemas de gestión en general. Videojuegos. Aplicaciones ofimáticas.

    Ejemplos donde no es mejor: Página web institucional básica. App botonera de sonidos. One button games.

  29. Creo que la respuesta general sería depende. ¿De que? Equipo, proyecto, tiempos, etc….
    Las metodologias agiles tienen muchos beneficios a la hora de gestionar y ejecutar un proyecto pero muchas veces forzamos su uso a casos en los que no es conveniente.

    A mi particularmente me gustan y creo, como mencionaron varios compañeros, que si muchos trabajos practicos se hubieran encarado de esta forma hubieran sido mas faciles de manejar.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: