Actividad #15 – SCRUM

Detecte en el Atlas de scrum: http://agileatlas.org/atlas/scrum temas que no hayan sido hablados en la materia o que sienta que podrían profundizarse más, asocie y comparta otros vínculos relacionados con el tema que elija.
 
Suma 5 puntos más si además plantea dinámicas como juegos o actividades que podrían servir para explicar dichas actividades.

 

Anuncios
Publicado en Sin categoría
5 comments on “Actividad #15 – SCRUM
  1. Ángeles Contarbio dice:

    Uno de los temas que podría haberse profundizado un poco más es las métricas: en el Atlas de Scrum, se menciona que el equipo puede crear cualquier artefacto que sea necesario para asegurar que el status del proyecto se entienda por todos. Sin embargo, no se especifica cuáles métricas o registros de performance podrían llevarse; y en la clase tampoco se profundizó demasiado en el tema.
    Las métricas que conozco y creo que son las más comunmente utilizadas en metodologías ágiles son:
    – Burn-down chart: trabajo restante vs tiempo. Es el más popular y creo que es importante explicarlo porque muchas veces puede no quedar clara la diferencia entre “horas efectivamente trabajadas (actual hours)”, “horas estimadas para terminar (estimated burn)” y “horas efectivamente quemadas (actual burn)”. http://www.clariostechnology.com/productivity/blog/whatisaburndownchart
    – Burn-up chart: trabajo completado vs tiempo. (A veces se lo considera casi lo mismo que el cumulative flow diagram.) http://www.clariostechnology.com/productivity/blog/whatisaburnupchart
    – Velocidad: medida del esfuerzo total del equipo durante un sprint. http://guide.agilealliance.org/guide/velocity.html

    Acá dejo un link donde se explica brevemente qué es y se especifica por qué es importante llevar registro de cada uno de ellos: http://smokejumperstrategy.com/archive/the-three-most-important-metrics-for-agile-teams/

  2. Ayelen Tamiozzo dice:

    Yo creo q lo q quizas estaría bueno profundizar (y que se menciono en la clase, pero se podría haber hablado más del tema) es:
    en como crear y documentar realmente el backlog, es decir, como armarlo de tal forma de q tanto el usuario como el equipo de desarrollo sepa que esta incluido en el y que no, por ejemplo armando user stories y user test acceptance. es algo importante que todos sepan (con el menor esfuerzo de docuemntacion posible) que incluye relamnete cada punto dle backlog. una pagina que habla del tema: http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ o http://winnipegagilist.blogspot.com.ar/2012/03/how-to-create-user-story-map.html

    y por otro lado, lo que no se mencio en clase fue el punto “Part Two: How will the work be accomplished?” que es la parte en la cual se decide como se van a armar los puntos comprometidos para el siguiente ciclo

  3. Roy Sandgarten dice:

    Espero no estar hablando de más, pero de las clases a mi no me quedó fija la idea de esta subdivisión en partes del proceso de Sprint Planning.
    Por ejemplo, no me quedó claro que la cantidad de ìtems del Backlog que entran en el Sprint Backlog lo determina únicamente el equipo de desarrollo, y el Product Owner tiene aceptar lo que el equipo propone (éste se limita a priorizar los items del backlog). Acá creo que entra un punto clave sobre la “confianza” dentro de esta metodología ágil.
    Otro detalle, muy menor, es que de las clases me quedó la idea que, inicialmente, el backlog siempre se define a “alto nivel”, cuando en verdad es sólo una tendencia, ya que también es posible definirlo en detalle inicialmente.

  4. Alejandra Stamato dice:

    Estoy de acuerdo con lo mencionado por mis compañeros en que el tema métricas y documentación de User Stories podría haberse profundizado un poco más.

    En cuanto a métricas también tenés FUNCIONALIDAD COMPLETA y COBERTURA DE TEST ( http://thucydides.info/blog/104-code-coverage-metrics-and-functional-test-coverage )
    Dejo un último link relacionado: http://www.proyectosagiles.org/metricas-agiles-cuadro-mandos-balanceado-scrum

    También creo que el Manifiesto Ágil vale la pena mencionarlo y hacer hincapié en el primer encuentro como algo importante, así como también la importancia de la comunicación con el cliente, el trato y actitud y el manejo de sus expectativas ( http://www.inc.com/michael-olguin/6-tips-to-managing-client-expectations.html ).

  5. Matias Servetto dice:

    Temas que estarían buenos para profundizar en la materia:

    • “The ScrumMaster helps everyone improve to make the Scrum Team more productive and valuable.”: creo que estaría bueno ver en clase como realiza el trabajo el Scrum Master. Sobretodo aprender algunas técnicas para mejorar la productividad del Development Team.

    • “Sprint Planning. In this meeting the Scrum Team collaborates to select and understand the work to be done in the upcoming Sprint”: me gustaría que se viera más a fondo este proceso de planeamiento.

    • “When the Product Increment is delivered, it needs to be “done” according to a shared understanding of what “done” means”: dado que el objetivo del cada sprint es entregar incrementos de funcionalidad, estaría bueno saber más como es que se define este concepto de “Done” y quienes intervienen en el procesos y de qué forma.

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: