Actividad #141.3 – Scrum y agilidad – Podés aplicarlo?

Contanos alguna situación actual (laboral o personal) en la que sientas que podría ser útil aplicar alguno de los principios del Agile Manifesto o los conceptos/prácticas de Scrum.

– Esta actividad tiene 5 puntos: Contanos la situación, que poblema tratás de resolver, cómo aplicarías el cambio y el resultado esperado.

– Si lo aplicas y nos contas como lo hiciste y que resultado obtuviste, tenes +5 puntos.

Anuncios
Publicado en Sin categoría
13 comments on “Actividad #141.3 – Scrum y agilidad – Podés aplicarlo?
  1. Juan Ignacio Marchese dice:

    Muchas veces, en varios proyectos, solemos tener quejas en cuanto a la performance de las aplicaciones que desarrollamos. Según lo que podemos ver, la mayor cantidad de veces tiene que ver con que no le dedicamos el suficiente tiempo al código para hacerlo de la manera optima.

    Yo creo que aplicando el principio:
    La atención continua a la excelencia técnica y al
    buen diseño mejora la Agilidad.

    Podríamos mejorar la satisfacción del cliente.

    El cambio lo aplicaría, destinando un poco mas de tiempo para la planificación de las tareas del proyecto, de manera de planificar mejor el como hacer dicha tarea para que sea mas optima.

    De este cambio, esperaría que el código sea mas optimo, y mayor satisfacción del lado del cliente.

  2. Mariano Longo dice:

    En el post anterior comenté que aplicábamos varios principios de la metodología ágil.
    Así y todo, creo que hay algunos puntos que podríamos “formalizar” un poco más.
    Por ejemplo, algo que me parece interesante de SCRUM, son las reuniones que establece (planning, daily, review, retrospective).
    En el caso de mi trabajo creo que vendría muy bien implementar, no sé si daily, pero al menos 2 o 3 veces por semana, reuniones (cortas) entre todos los miembros del equipo, para ver que anda haciendo cada uno básicamente.
    Como en las aplicaciones en las que trabajamos, todos pasamos por todas ellas en algún momento, hay muchas veces donde uno está haciendo algo qué otro ya hizo, o tiene más conocimiento de alguna aplicación en particular, y muchas veces, al no haber una reunión formal donde cada uno exponga “con qué está”, esa comunicación se pierde (a menos que dé la casualidad de que uno le comente a otro con qué está o le pregunte, “che, vos que estuviste con esto”).

    Esa es la situación que pienso que se resolvería implementando reuniones periódicas.
    El resultado esperado sería: evitar el retrabajo (reducir la investigación que cada miembro tiene que hacer por su cuenta) reduciendo los tiempos de desarrollo

    Saludos!

  3. Jorge Rodriguez Breuning dice:

    En este momento estoy liderando un equipo de 3 personas que se dedica al desarrollo y manutención del principal producto de la empresa.

    Si bien el cliente hoy es interno por cuestiones comerciales puede haber deploy de requerimientos (De algún usuario en particular) en cualquier día de la semana. Dentro del equipo se ha podido armar una buena comunicación en base a “dailys” que se organizan conforme surjan. Esto hizo que la sinergia dentro del equipo subiera sensiblemente, haciendo mejor código, en el sentido de mantenibilidad y mejores prácticas aplicadas.

    Estaría bueno poder fomalizar un poco más los principios de SCRUM para conseguir deploys a producción más medibles, metrificables y que realmente aporten valor al negocio.
    Para eso ya estoy planteando insistentemente la necesidad de un product owner que guíe la prioridad de los requerimientos, todavía sin resultados.

  4. Ramiro Diaz dice:

    Como comenté en la actividad 141.2, los desarrolladores no participan en la planificación del ciclo. Esto trae como consecuencia que las personas que determinan estas tareas no tengan en cuenta la viabilidad de lo que tienen en mente, por lo que dicha planificación muchas veces debe ser modificada (aunque sea mínimamente) luego de que es expuesta a quienes van a realizar las tareas. Dado que esta planificación no lleva mucho tiempo, la inclusión de parte del equipo de desarrollo en esta reunión no debería considerarse como una tarea fuera del alcance de los mismos. Los beneficios que traería son: disminuir la re-planificación, priorizar tareas en base al esfuerzo que pueden llegar a consumir, considerar limitaciones, riesgos o inputs necesarios para cada incidencia y poder evaluarlos con anterioridad, etc.

  5. Gustavo Silva de Sousa dice:

    Con respecto a lo personal, se me ocurre aplicar las metodologías ágiles en mi equipo de fútbol. El concepto principal que tomaría es el hecho de trabajar en iteraciones. Actualmente participamos en un torneo que transcurre a lo largo de todo el año. Al final del mismo hacemos una especie de retrospectiva asado mediante. A lo largo de los años, de estas reuniones han salido sugerencias, comentarios e ideas que terminaron siendo muy constructivas, pero que se empezaron a aplicar recién al año siguiente. Se podría decir que se trata de un proyecto anual con un único sprint. Teniendo en cuenta esto, creo que se podría dividir el año en varias iteraciones, definidas por tiempo o por cantidad de partidos, para luego realizar una retrospectiva. De esta forma podríamos aplicar cambios de forma más temprana y sobre la marcha. Sumado a esto, se podría definir un sprint backlog para cada una de las iteraciones. Además de contemplar todas las tareas como partidos, amistosos, cuestiones burocráticas y organizativas del equipo, se podrían definir ciertos objetivos mas específicos del juego como “tratar de no tener ningún expulsado” o “tener 3 suplentes por partido”, con su correspondiente prioridad.

  6. Gonzalo Prieto dice:

    Organizar mi actividad diaria me lleva tiempo, pero más que nada siempre término dejando algo en el olvido. Organizar mis tareas diarias o semanales asignándoles prioridad sería una buena idea a aplicar en mi día a día

  7. Jonathan Marino dice:

    Yo trabajo en sistemas embebidos para una empresa como único desarrollador.
    El problema esta en que mi jefe va tirando requerimientos a medida que se les presentan y pide avanzar con eso frenando con lo que se venia y sin tener en claro las prioridades de cada requerimiento de acuerdo a su ROI y si vale la pena perder la concentración.
    Lo resolveria implementando el Product backlog y el Sprint planning y el respetar no intentar agregar un objetivo nuevo en medio del sprint a menos que sea muy necesario, que él de un puntaje de valor y yo uno de esfuerzo y tener sprints muy cortos una semana quizas (el tipo de desarrollo lo permite).
    El resultado esperado seria focalizarse en lo importante y no interrumpir el desarrollo para un requerimiento por uno con menor ROI o parecido.
    Se ha sugerido el cambio.

  8. Cuando realice el trabajo profesional final (calculo a principios del año que viene) voy a tratar de cumplir lo mas estrictamente posible los principios. En el laburo lo aplicamos pero a veces creo que es dificil hacer algún cambio en determinados aspectos que no cumplen con los principios.
    Calculo que los resultados van a ser muy buenos y voy a poder cumplir con los tiempos pactados para realizar el trabajo.

  9. Sebastián Metta dice:

    Por mi parte en el proyecto en el que trabajo tenemos a varios involucrados, con distintos roles, en estados unidos. A partir de reiteradas peticiones pudimos lograr efectuar reuniones semanales de 30 minutos – 1 hora, las cuales mejoraron en gran medida la comunicación ya que algo que lleva una cadena larga de mails en unos pocos minutos quedó claro para todos. Esto está referido al principio “La gente de negocio y desarrolladores debe trabajar junta diariamente a traves del proyecto”.

    Saludos!

  10. Sebastian E. Balazote Oliver dice:

    En éstos días entregué junto a 2 compañeros el Tp Profesional. Si bien intentamos usar la metodología Scrum, un poco por el desconocimiento que teníamos para aplicarlo y a veces la dificultad para realizar por ejemplo las Daily Meetings (por incompatiblidad horaria, entre otras cosas), el resultado fue un Scrum “modificado”. Creo que el resultado de todas formas fue mas que satisfactorio ya que el proyecto llegó a buen puerto y las pequeñas dificultades que atravesamos se verían reducidas considerablemente si tuviesemos que comenzar de cero un proyecto nuevamente.

  11. Juan Antonio Monetti dice:

    Utilizo algúnos principios como:
    – Daily meetings
    – Backlogs

    Un cambio que aplicaría sería el uso de sprints, y retrospectivas al final de cada uno. Con el fin de hablar del trabajo hecho, y aplicar mejoras para el próximo sprint.

  12. Javier Etchegaray dice:

    A mitad de año comienzo el TP final con un compañero, intentaremos usar scrum mezcla kanban (por el board), y adaptar las metodologías a nuestra conveniencia y la del tutor. para planificar y estimar y métricas ágiles sobre todo. reuniones cada dos días o tres. y revisión luego de cada iteracion junto al entregable. Aunque seamos solo dos, siempre ayuda tenes una metodología, para organizarse, mas en un trabajo final que hace falta mucha documentación y cuestiones fuera de lo que es desarrollo y que también son tareas que deben tenerse en cuenta, estimarse y planificarse. Por lo tanto los métodos ágiles en este caso, creo que aporta a no desviarse del objetivo.

  13. En el trabajo estamos intentando realizar algunas cosas de scrum, asignación de las tareas, dailys y board con las tareas, cuesta mucho incorporarlo pero va trayendo sus frutos.
    Cuesta mucho con gente que no esta metido con estas ideas y les cuenta adaptarse.
    Pero de a poco va queriendo.

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: