Actividad #9 – SCRUM

Profundizar en la práctica de planning poker: http://www.infoq.com/interviews/nils-haugen-planning-poker y diseñar un ejemplo de al menos 4 o 5 historias de usuario donde mediante esta técnica logre tener una idea de esfuerzo.
Si puede utilizar ejemplos de trabajos  o de la facultad mucho mejor.
Un articulo interesante sobre los problemas de estimaciones y esta practica es este: http://www.infoq.com/news/2012/08/planning-fallacy que es una opinión sobre este otro: http://effectivesoftwaredesign.com/2012/08/05/planning-poker-avoiding-fallacies-in-effort-estimates/
Otra posibilidad es profundizar sobre la escala que se use para estimar. De acuerdo a lo que propone http://michaellant.com/2010/07/13/agile-planning-poker/ en Tools y las respuestas obtenidas por http://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker Escribir una justificación de por qué su equipo debería usar una u otra escala.

Otras ideas (mucho mejor con links que las expliquen bien) de estimaciones relativas que se les ocurran suman 5 puntos mas.

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
5 comments on “Actividad #9 – SCRUM
  1. Alejandra Stamato dice:

    Ya sabemos que el Planning Poker es un sistema de estimación del tiempo que se requerirá para terminar una determinada tarea o historia con las que se trabaja en la metodología SCRUM.

    Vimos en clase ejemplo de realización de un censo en distintos países.

    Un ejemplo de la vida diaria puede ser el de cocinar distintos platos:
    * Risotto de cordero.
    * Sopa de calabaza.
    * Salmón ahumado con papas.
    * Fajitas de pollo y ternera.
    * Bife de cuadril con puré mixto.

    Un ejemplo del marco laboral es la construcción de una aplicación:
    * Realización del login de la aplicación.
    * Diseño y construcción de menúes y páginas.
    * Diseño y construcción de bases de datos y tablas.
    * Lógica de backend para pantalla 1
    * Lógica de backend para pantalla 2
    * Lógica de backend para pantalla 3

    El Planning Poker funciona de manera tal que tiene en cuenta todas las historias a considerar, deja saber si todos los miembros están entendiendo lo que hay que hacer, si todos se ponen de acuerdo en la medida del esfuerzo requerido.

    Por último los dejo con un link que tira un poco abajo el planning poker, explica distintos métodos de estimación relativa y al final se anima a más: a tirar abajo el proceso de estimación:

    http://thomaswallet.blogspot.com.ar/2012/06/cansado-del-planning-poker-4.html#.UiuHTD_9Wf8

  2. Martin Ciruzzi dice:

    Encontre unos slides que me parecieron piola. Igual en lo que refiere a los ejemplos de estimacion relativa no me gustaron mucho (tamanio de perros? construccion de edificios?). En fin, al menos es se lee con fluidez y es didactico

    http://www.slideshare.net/JohnnyDark/estimacin-gil-story-points-y-planning-poker

    En cuanto a estimaciones relativas, la de las camisetas como escala (S,M,L, XL, XXL) tambien parece tener consenso, este articulo la menciona. Pero lo comparto porque me gusto que itemiza 5 reglas sencillas para estimaciones correctas (obviamente subjetivas)

    http://eamodeorubio.wordpress.com/2011/05/16/estimacion-3-tecnicas-agiles/

  3. Rodolfo Cruz dice:

    En mi opinión la escala que mejor se adapta a mi equipo de trabajo es la de Fibonacci (de hecho, es la que utilizamos). El razonamiento es el siguiente: dado que las user stories que debemos completar tienen una amplitud en esfuerzo bastante variable (las hay desde algunas que se podrían terminar en un día hasta otras que quizás ocupen un poco mas de una semana), la escala de 1 a 5 me parece poco descriptiva ya que si le damos el valor mínimo de 1 a estas stories menores, las de mayor envergadura quedan fácilmente fuera de escala. Por el contrario, la escala de Fibonacci tiene como ventaja que tiene un rango mas amplio, con una mayor granularidad en la parte mas baja que es donde podemos distinguir con mayor exactitud entre distintos valores a la hora de estimar y mas espaciada en el extremo opuesto, donde la incerteza debería ser mayor.

    Respecto a otros métodos de estimación relativa, les comparto este link donde el autor describe, ademas del planning poker, otros dos métodos más que me parecieron bastante novedosos basados en ir ubicando y moviendo post-it con las user stories sobre un afiche

    http://www.agileblog.org/2012/06/different-estimation-methods-compared.html

  4. Sebastian Rodriguez dice:

    Existen distintos tipos de escalas para utilizar en Planning Poker. Van desde el uso de las manos (1:5), talle de remeras (XS, S, M, L, XL), cartas de Fibonacci o de Cohn (1,2,3,5,8,13,…), hasta razas de perro (Chihuahua representa la más pequeña, Gran Danés la más grande). Lo importante al decidir cuál utilizar, es que el equipo entienda la escala y que se sientan cómodos con la misma.

    En mi opinión, el tipo de escala a utilizar es aquella que no es continua, por ejemplo la de Fibonacci, dado que obliga a la persona a pensar seriamente en la estimación y no dar una estimación intermedia. Ejemplo: Si se usase la escala 1:5, una persona estaría tentada a estimar en 4 una tarea por no decidirse si realmente es compleja (5), o si en realidad es normal (3); y de esa forma quedar “bien” con el resto del equipo. Utilizar una escala como la de Fibonacci, hace que la persona se deba convencer de la estimación en base a su propia opinión.

    Les comparto un link que me pareció interesante. Es del blog de Mike Cohn, quién popularizó el concepto usando la escala: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, y habla de cómo obtener las mejores estimaciones del tamaño de las User Stories.
    http://www.mountaingoatsoftware.com/blog/how-can-we-get-the-best-estimates-of-story-size

    En cuanto a métodos de estimación alternativos al Planning Poker, me llamó la atención el método “Team Estimation Game” (http://properosolutions.com/2009/05/team-estimation-game/) y el “Wall Estimation” (http://msdn.microsoft.com/en-us/library/hh765979.aspx)

  5. Leandro Linardos dice:

    No sé si encaja perfectamente en esta entrada, pero lo siguiente me parece una mirada distinta y bastante interesante sobre estimación que quería compartir.

    En éste artículo el autor ve las estimaciones como una métrica más. Propone el almacenamiento de estimaciones para buscar patrones en las mismas según quién las hace, el tipo de tarea sobre la que está hecha, resultados, etc. para luego utilizarlos para estimar no sólo duración, sino también bugs, re-trabajo, etc..

    Me parece un enfoque sensato, ya que el cambio es intrínseco al desarrollo de software y comprometerse fervorosamente con una estimación tiende a ir en contra del cambio.

    En el artículo además se nombra el Movimiento #NoEstimates. La idea básica es que es posible hacer pequeños pedazos de trabajo incrementalmente convergiendo rápidamente a un producto entregable alineado con la definición de valor (DoV) sin necesidad de estimar user stories, ni mucho menos. Estos pequeños pedazos de trabajo deben ser lo suficientemente pequeños como para ser no ambiguos, concretos en acción y neutrales en riesgo.

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: