Actividad #11 – SCRUM

Para el video: https://www.youtube.com/watch?v=502ILHjX9EE ver y extraer los puntos ya tratados y los no tratados durante la materia

Suman 15 puntos extra y además lo pueden hacer en grupo (de máximo 3 personas) aquellos que armen un script en castellano y 5 mas si además mezclen el video con los subtítulos

Anuncios
Acerca de

Soy uno de los siete fundadores de FDV Solutions. Como CEO de la compañía, ejecuto la estrategia general de FDV Solutions y la supervisión de las distintas áreas de negocios y gerentes que me reportan: Ventas y Marketing, Operaciones, Administración y Finanzas, y Recursos Humanos. Además tengo un rol activo en las distintas acciones institucionales de la empresa, siendo representante de la misma en diversas cámaras e instituciones, como la Cámara de Empresas de Software y Servicios Informáticos de Argentina (CESSI). Soy graduado en la Carrera de Ingeniería en Informática, y cuento además, con un posgrado en comercialización para ingenieros del Instituto tecnológico de Buenos Aires (ITBA). Actualmente estoy finalizando un máster en Ciencias Cognitivas de la Universidad de Buenos Aires y soy docente universitario en dicha casa de estudios. Soy también Fundador de Proyecto Nahual (www.nahual.com.ar), una iniciativa que busca la inclusión social y la inserción laboral a partir de la capacitación tecnológica en programación y testing de software. Participo además activamente de la Comisión de Inclusión de CESSI.

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

    Puntos tratados (ya sea directa o tangencialmente):

    – Roles: PO, stakeholders, equipo de desarrollo. Es vital la comunicación entre dichos roles.
    – Los requerimientos expresados en forma de US.
    – Noción de: Product Backlog, visión, ciclo iterativo corto de retroalimentación (“short feedback loop”).
    – El equipo de desarrollo trabaja a una velocidad aproximada de entre 4 y 6 US por semana.
    – Hay que descomponer los requerimientos en US que no demoren más de un par de días en implementarse.
    – Hay US que requieren horas y otros que requieren meses, hay US que son críticos y hay otros que son un “bonus feature”. No hay ninguna correlación directa entre tamaño/complejidad y valor que le aporta al negocio.
    – Administración de la capacidad/priorización: los stakeholders generarán muchos más requerimientos que los que puede manejar el equipo de desarrollo. Si el equipo se pusiera como propósito implementarlos a todos, se generaría un “overload”, y consecuentemente la desmotivación del equipo, baja calidad en lo desarrollado y demás efectos negativos. En el video se lo representa como un “caño” donde entran 10 “unidades” y salen 4 – 6. De allí surge la necesidad de priorización de los US.
    – Testing: para cada US se elabora al menos un “automated acceptance test” para probar las “features” y al menos un “unit test” para probar el código. Todo esto con el objetivo de “mantener el ritmo” y no meterse en testing de regresión manual.
    – El PO tiene que decidir “qué se implementa ahora y qué se implementa después” y, para esto, debe existir una comunicación estrecha con el equipo de desarrollo y los stakeholders. Con los stakeholders para conocer el valor que cada US le aporta al negocio, y con el equipo para saber el esfuerzo que requiere construir cada US.

    Puntos no tratados:

    – El equipo de desarrollo tiene un “WIP (work in progress) limit” que se refiere a la cantidad de US que puede manejar el equipo simultáneamente.
    – El PO tiene que saber decirle “no” a aquellos nuevos requerimientos de stakeholders y tomar completa responsabilidad sobre esa decisión.
    – Noción de “Backlog Grooming”: estimar tamaño y valor, priorizar, descomponer en US menores, etc.
    – Tipos de riesgo:
    – negocio: estamos construyendo lo correcto?
    – social: el equipo de desarrollo lo puede efectivamente construir?
    – tecnológico: se podrá utilizar sobre la plataforma requerida?
    – tiempo/costo: se puede terminar el proyecto en un tiempo razonable y a un costo razonable?
    – Valor para el cliente vs Tiempo: al inicio del proyecto, para contrarrestar el riesgo y la incertidumbre, se pone foco en el conocimiento; luego se focaliza en sumarle valor al cliente (ya se investigó y se tienen los conocimientos necesarios, asique simplemente hay que “hacerlo”); finalmente se trabaja en los “bonus features”.
    – Corto plazo, accionar reactivo largo plazo, accionar proactivo
    – Se debe encontrar el balance justo entre: construir lo correcto, construirlo de manera correcta, construirlo rápido. En el primer caso, el PO es el que vela por que se cumpla, en el segundo caso, es el equipo de desarrollo, en el último caso, es el coach.
    – En proyectos grandes, se trabaja con N equipos de desarrollo y N PO’s respectivamente. En general, se incorpora el rol de CPO (Chief Product Owner) que se encarga de la sincronización entre PO’s.

  2. Matias Servetto dice:

    Product owner:
    • Posee la visión del proyecto.
    • No sabe detalladamente que va a hacer el producto pero sabe porque se está construyendo que problema va a resolver y para quien.
    • Debe transmitir al equipo de desarrollo la visión del producto.
    • Debe encargarse de que haya comunicación entre todas las personas que formen parte del proyecto.
    • Debe manejar las expectativas de los stakeholders.
    Stakeholders
    • Personas que van a participar, apoyar o incluso serán afectadas por el desarrollo del producto.
    User story:
    • Contiene las necesidades de los stakeholders con respecto al producto.
    • El Product Owner ayuda a transformar las ideas de los stakeholders en user stories.
    Development team:
    • Son las personas que llevan a cabo la construcción del producto.
    • En lugar de entregar el producto entero al final, realizan entregas pequeñas en entregas a lo largo de la vida del proyecto (6 o 7 user stories por semana, normalmente).
    Capacidad del equipo de trabajo:
    • Cantidad de user stories entregadas en determinado rango de tiempo: ej x User Storiy / semana.
    Story point
    • Forma de medir la capacidad del equipo de desarrollo.
    • Cada user story cuenta por 1 story point, salvo por
    o User stories muy pequeñas: cuentan por ½.
    o User stories muy grandes: cuentan por 2.
    Burntdown chart:
    • Gráfica de user stories entregados en relación al tiempo.
    • Basándose en el mejor y peor caso de la proyección de la función de user stories en relación al tiempo, se puede:
    o Estimar un lapso de tiempo en el cual se puede terminar determinado user story.
    o Estimar para un momento un lapso de user stories a completar para esa fecha
    Como se mantiene la capacidad del trabajo:
    • Se hace uso de pruebas automáticas y de la integración continua.
    o Cada user story tiene al menos una prueba funcional por feature.
    o El código está respaldado por unit test.
    Overloading:
    • Los stakeholder tienen muchas ideas y por cada user story entregada se les ocurren mas ideas todavía.
    • El overloading se da si la cantidad user stories que se compromete a hacer el equipo de trabajo es mayor a la capacidad del mismo.
    • El resultado es:
    o Desamino por parte del equipo de trabajo.
    o Peor calidad de producto.
    o Miembros del equipo realizando múltiples tareas al mismo tiempo.
    Evitar overloading:
    • El equipo analiza cual fue la capacidad de trabajo en la iteración anterior y se lo hace saber al product owner. Este debe encontrar cuales son las user stories más importante para realizar d emanera tal que la suma de sus story points sea igual a la capacidad anterior.
    Wip limit:
    • Es la cantidad máxima de user stories que pueden ser realizadas por el equipo de trabajo de manera simultánea sin generar overloading.
    Product backlog:
    • Cola de user stories ordenadas por prioridad que están a la espera de entrar en la próxima iteración.
    Mantención del product backlog:
    • El product owner mantiene el product backlog:
    o Decide que se incluye y que no.
    o Decide que se construye antes y que no.
    o Las decisiones las toma en conjunto con el equipo de trabajo y los stakeholders.
    • Si crece descontroladamente, no hay que tirar las user stories porque si.
    • Si crece descontroladamente, no seguir agregando sin ningún tipo de filtro más user stories al backlog.
    • Se debe tener en cuenta el valor que agrega una user story al proyecto y el esfuerzo (teniendo en cuenta que no hay relación entre estas variables).
    • El product owner debe tratar de estimar el valor de una user story comunicándose con los stakeholders. El esfuerzo, con el equipo de desarrollo.
    • Se debe realizar la priorización de manera continua.
    Estimaciones:
    • Se puede comprar “tamaño” entre una user story conocida y otra desconocida.
    • Al comienzo del proyecto, las estimaciones suelen ser muy malas.
    • A medida que se realizar entregas, el equipo de desarrollo aprende lecciones y la estimación mejora.
    Backlog grooming:
    • Es la tarea de, entre otras:
    o Estimar el valor y el tiempo de las user stories.
    o Priorizar user stories.
    o Dividir user stories.
    • Participa el product owner y el equipo de trabajo. También pueden ser invitados los stakeholders que se relacionen con las user stories que los implique.
    Riesgos:
    • Al comienzo del proyecto es en el momento en el que más presentes están.
    • Tipos
    o Negocio: ¿estamos construyendo el producto adecuado?
    o Social: ¿puede la gente construir el producto adecuado?
    o Técnico: ¿funcionara en la plataforma escogida?
    o Costo y calendario: ¿se puede terminar el proyecto en un tiempo y con un costo determinado?
    Tecnicas para reducir riesgos:
    • Realizar investigaciones (spikes).
    • Realizar prototipos de interfaces de suario.
    Ciclo de vida del proyecto:
    • En un principio está enfocado en el punto de vista del conocimiento del equipo de trabajo
    o Se realizan investigacione y prototipos para evitar o mitigar riesgos.
    o El valor para el cliente aumenta de a poco en el tiempo.
    • Luego le sigue el enfoque al valor que se le entrega al cliente:
    o Se desarrollan los requerimientos más importantes.
    o El valor del producto crece de manera elevada.
    • Finalmente se entra en una etapa de desarrollo de requerimientos bonus:
    o Lo más importante ya está construido y el valor que se suma al producto comienza a crecer de a poco.
    o En este punto el equipo de desarrollo o el product owner puede decidir terminar el proyecto exitosamente.
    Balance:
    • Se debe balancear entre realizar trabajos a corto plazo o largo plazo.
    • Se debe pensar en cómo realizar el producto correcto, de la manera correcta y de forma veloz. Como esto es muy difícil se debe analizar cuál de estas 3 variables son ams importantes:
    o Producto correcto para que sea lo que quiere el cliente y no tener algo construido de forma perfecta y que no sirva.
    o Manera correcta para no tener problemas técnicos pero cumplir con los plazos de tiempo.
    o Velocidad para no quedar fuera del negocio y no tener algo que técnicamente tenga muchos errores.
    Finalización del proyecto:
    • Los proyectos nuca terminan, ya que los stakeholders desean seguir incrementando las funcionalidades de los productos o realizar cambios.
    • Como es muy costoso cambiar al equipo de desarrollo de un producto por otro, se trata de que el mismo equipo siga con las tareas de los proyectos que se dieron por finalizados pero a las cuales se les sigue pidiendo de vez en cuando que se creen más cosas.
    • Debido a los dos puntos anteriores, el product backlog se termina convirtiendo en un team backlog.
    Escenario con multiples equipos:
    • Todo lo anterior es válido.
    • Aparece un product owner por cada equipo de desarrollo.
    • Se agrega la responsabilidad, al product owner, de comunicarse con el resto de los product owners para minimizar dependencias.
    • Puede aparecer un actor nuevo: el chief product owner. Se enga de sincronizar a los product owners.

    Como quedó mal identado agrego link al drive: https://docs.google.com/file/d/0B_ZoFU_4QIUAWk40VFNSdW10ckU/edit?usp=sharing

  3. Rodolfo Cruz dice:

    En cuanto a los puntos que trata el video, discriminados según si se han tratado o no en clase, tenemos:

    Puntos que se han desarrollado en clase:

    – Rol del Product Owner
    – Rol de los interesados
    – Definición y características de las User Stories
    – Rol del equipo de desarrollo
    – Concepto de capacidad de un equipo
    – Importancia de tests automatizados
    – Importancia del manejo de expectativas con el interesado (saber cuando decir “no”)
    – Relevancia de la comunicación entre todas las partes a la hora de definir el product backlog y la priorización de las stories
    – Distinción entre valor de la story y su complejidad o tamaño (No hay relación entre ellas)
    – Concepto de estimación
    – Backlog grooming
    – Riesgos vs Conocimiento
    – Evolución del valor de lo entregado al cliente a través del tiempo
    – Compromiso entre cosas a corto y largo plazo
    – Combinación entre tareas de desarrollo y de mejora en un sprint

    Puntos que no se han profundizado en clase:

    – Técnica del “yesterday weather”
    – Metodología Kanban
    – Balance entre “hacer lo correcto”, “hacerlo correctamente” y “hacerlo rápido”
    – Análisis de burnup chart
    – Concepto de Chief Product Owner

    Respecto a la traducción del video en sí para que más cantidad de gente pueda entender lo que dice, con Martín Ciruzzi encontramos la siguiente transcripción del contenido:

    http://jose-barato.blogspot.com.ar/2013/06/el-rol-del-product-owner-en-la-practica.html

    Y ya integrado en el video anterior por el mismo autor:

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: