Actividad #12 – SCRUM

En base a la clase, con ayuda de este artículo: http://www.mountaingoatsoftware.com/blog/separate-estimating-from-committing
y porque no, otros que compartan ustedes.
Desarrollar un post sobre cual es la diferencia entre estimación y planificación tratando de justificar la mayor cantidad de opiniones con artículos linkeables y/o ejemplos personales.

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

    Sabemos que mientras que la estimación es una actividad que refleja la cantidad de trabajo que requerirá una actividad, en la planificación se disponen recursos, tiempos, costos y demás activos para cumplimentar esa actividad.

    En la empresa donde trabajo la estimación de nuestras tareas es MUY importante. Está a cargo del desarrollador, de forma tal que, por la cultura de la empresa, nos incentivan para lograr cumplir nuestras estimaciones, considerando que nuestras estimaciones son totalmente precisas, como comenta el artículo. No cumplirlas no está copado ya que las tareas planificadas para nosotros a continuación se agolpan y se van atrasando.
    Debido a eso nosotros nos “colchoneamos” con tiempo extra en las estimaciones para resolver bugs, y otros inconvenientes tecnológicos con los que podríamos toparnos.

    En un equipo de SCRUM es de extrema importancia que participen todos los miembros del equipo en el proceso de estimación para estar en las explicaciones que el Product Owner pueda dar, entender lo que se quiere desarrollar y ver lo que piensa el equipo de cada funcionalidad. Finalmente teniendo en cuenta el trabajo a realizar, cantidad de horas, tecnologías, todos se comprometen a la entrega del incremento en determinada fecha.

    Finalmente les dejo un link muy interesante sobre estimación y planificación ágil:
    http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil

  2. Ángeles Contarbio dice:

    Creo que la principal diferencia entre estimación y planificación se basa en que la primera está incluida en la segunda; estimar es la base de la planificación pero ésta última se refiere a un concepto mucho más abarcativo/global a nivel proyecto.
    Por un lado, creo que la estimación se refiere a un rango que uno prevee que se requiere para completar una tarea/actividad determinada, en base a “juicio de expertos”, analogías o planning poker, entre otros. Acá dejo el link al capítulo 6 del libro “Agile Estimating and Planning” de Mike Cohn (el autor del artículo de la actividad en cuestión) que es cortito y conciso y está muy bueno porque explica brevemente y comenta lo positivo de cada método: http://www.mountaingoatsoftware.com/system/asset/file/15/aep_sample.pdf.
    Por otro lado, entiendo por planificación al proceso que se define a lo largo de todo el proyecto e involucra a diversas áreas, entre ellas los tiempos, los recursos, la calidad buscando lograr un equilibrio y un balance entre dichas áreas. Se podría decir que se vincula, dentro del ámbito de las metodologías ágiles, de manera directa con el product backlog y el sprint backlog (en éste último caso, “planificamos” a qué nos vamos a comprometer para el sprint entrante). Acá dejo un link a un artículo donde el autor hace una breve reflexión sobre la planificación en las metodologías ágiles y su diferencia con la planificación en las metodologías tradicionales: http://www.projectconnections.com/articles/120506-mcdonald.html.

  3. Ayelen Tamiozzo dice:

    Tal como dijeron previamente, me parece que la estimación es una parte de la planificación.
    En la estimación se arma de una forma lo mas objetiva posible cuanto se cree que demorará en horas hombre cierta actividad sin tener en cuenta cuales son los recursos que de dispone ni dependencias con otras actividades, etc.
    En el caso de mi empresa, la estimación se realiza a ppio de ciclo y se hace de la siguiente manera: todos los desarrolladores del equipo ven todos los proyectos del backlog (an sin priorizar) y cada uno dice cuantas horas estima que se tardará en hacer cada uno de los designs.

    EN el caso de la planificación, la misma ya es mas concreta, es decir, ya se tiene en cuenta, dependencias entre actividades, recurso asignado, etc.
    Nuevamente, en el caso de mi empresa, luego de que le pasamos a nuestro cliente el backlog estimado, nos lo devuelve priorizado y partir de ahi empezamos en orden a asignarlo a los recursos y estimar en q fecha (o sea, día del ciclo) terminaría hasta que todos los recursos estan ocupados en el ciclo. Las tareas del backlog no asignadas, son las que no se harán durante el mismo.

    Como se puede ver, la estimación y la planificación son actividades diferentes. Algo de hecho, muy importante, es que ante una escasez de tiempo, es decir, cuando se quiere que entren mas actividades en el sprint de lo que la primera planificación calcula, no se debe modificar nunca la estimación. En todo caso, se deben pedir mas recursos, “jugar” con las dependencias de las tareas, etc para que entren mas actividades.

  4. Martin Ciruzzi dice:

    – Sobre la diferencia, puedo aportar que la estimacion no deberia verse influenciada de ningun modo por algun aspecto de la planificacion (deadlines,compromisos). En proyectos I se nos ejemplificaba con un mal caso en el cual un empleado segun las reacciones de un jefe a su estimacion, modificaba la misma.
    Ej:
    – A tarda 5 meses
    – Lo necesitamos en 2
    – Ok ahora veo. Bueno lo podemos realizar en 3.30

    Como conclusion se nos queria dejar que, si las condiciones/contexto de una estimacion/trabajo no cambian, no hay razon para cambiar la estimacion. En si la estimacion busca dimensionar el problema o la solucion.

    Luego la planificacion toma como base las estimaciones pero ya con otro fin ===> Lograr objetivos. Buscamos acomodar las tareas de modo de cumplir con los objetivos planteados, si fuesen muchos priorizardos como se hace con el backlog.

    En cuanto a ejemplos sobre estimaciones (y despues de haber leido el articulo) lo primero que se me ocurrio fue la analogia con una convocatoria para un partidito de futbol. Algunos habran escuchado alguna vez el famoso “9 para 9.30”. El cual refiere a una planificacion de la hora a la cual hay que llegar para hacer entrada en calor. Quien define esa hora sabe que la entrada en calor son 15 minutos para salir a la cancha 9.30 (deadline para hacer nuestro trabajo). Sin embargo convoca a sus companieros con antelacion para colchoniar(en exceso) en caso de llegadas tarde, tiempos para cambiarse, etc.
    Finalmente, si alguien respeta la planificacion(mal hecha) y llega a las 9, se come 15 minutos solo(si es a las 9 en invierno puede ser sufriendo mucho frio) hasta que llegan el resto de sus companieros(obviamente nadie llega a las 9). Con lo cual, la proxima vez llegara 15 minutos mas tarde sabiendo que nadie respeta la planificacion(sera porque todos saben que esta mal hecha porque la hizo el DT/organizador/lider solo?).

    No se me parecio una anologia valida… pueden no sumarme los 5 puntos si no aplica jaja

  5. Roy Sandgarten dice:

    Yo creo que la diferencia pasa porque una estimación está asociada a una tarea (actividad, o story) en particular, mientras que una planificación comprende a un conjunto de dichas tareas, priorizables, dependientes entre sí y su contexto (feriados, etc).
    Haría una diferencia entre la importancia de cada proceso (estimacion y planificacion) en un enfoque ágil contra uno predictivo.
    Creo que en el enfoque predictivo, la planificación tiene un peso súper importante, ya que se completa al comienzo del proyecto (de “pe” a “pa”), teniendo como uno de sus inputs a las estimaciones de las distintas tareas involucradas. En un enfoque ágil, en cambio, se suelen hacer planificaciones modularizadas (en el caso de SCRUM, los sprint planning) a lo largo de toda la vida de un proyecto, reduciendo el impacto de error en alguna de dichas planificaciones iterativas, ya que el alcance de dichas planificaciones es menor. A medida que se avanza el proyecto, se puede ir reestimando las tareas (en el caso de SCRUM, actualizando el backlog), por ende mejorando las futuras planificaciones.
    En mi experiencia lo vivo de la siguiente manera (para un proyecto que estoy sólo): estimo el esfuerzo que me lleva realizar las tareas por separado de un proyecto, pero a la hora de planificar veo cómo pienso distribuir mi tiempo sobre esas tareas para poder comprometerme a una determinada fecha, idealmente agregando un “colchón” (cuando se puede) en la planificación.

    • Máximo Rocha Mejía dice:

      La diferencia es que la planificación es un compromiso, y la estimación es una aproximación de cuánto tiempo llevará realizar un trabajo.
      El problema principal, en mi opinión, es semántico, y cómo dice Mike Cohn en su artículo, es cuestión de educar al cliente, usuarios, gerentes, etcétera.
      Todos los involucrados en un proyecto deberían saber a qué nos referimos cuando hablamos de duración(compromiso) y esfuerzo(estimación).

      El esfuerzo es algo “no negociable”, es un número que surge en definitiva de la experiencia en trabajos similares (más allá de que existan otras técnicas de estimación además de la “opinión de expertos”). En base al esfuerzo es que podemos planificar y determinar una duración.

      Como (contra)ejemplo real puedo mencionar 2 proyectos en los que participé y en dónde se entendía por estimación a la cantidad de tiempo en el que te comprometías a terminar con el trabajo. De todas maneras este “mal” uso de la palabra no presentó inconvenientes puesto que todos sabíamos a qué nos referíamos cuando la usábamos…

  6. gdfesta dice:

    Si bien no son lo mismo son necesarias una a la otra.

    Cuando nos hablan de estimación internamente hacemos una planificación de menor envergadura. Como el ejemplo que se cita en el artículo la hija estima estar afuera 5:15 y para
    llegar a ese resultado tuvo que saber a grandes rasgos las tareas que implican estar afuera en ese horario y cómo podría llegar a hacerlas.

    Cuando realizamos una planificación sería conveniente, para poder hacerla correctamente, primero plantear una estimación sobre lo que nos pueden llevar las tareas a realizar, de este modo saber la prioridad y en consecuencia el momento en que vamos a realizar dichas tareas y así llegar a la planificación de todo lo que está involucrado en el proyecto.

    El autor del artículo separa lo que es estimación de compromiso, si bien es verdad que no son lo mismo, no hay que abusar de dicha diferencia. Cuando una persona nos pregunta sobre una estimación, dicha persona espera que nos comprometamos a hacer lo que decimos sino no nos lo pregunta. Por lo que un compromiso no deja de ser una estimación y una estimación tendría que hacerse con compromiso.

    También se cae en separar estos conceptos ya que cuando nos piden una estimación algunos clientes o managers esperan escuchar lo que ellos creen que puede llevar hacer dichas tareas sin a veces hacer un análisis de lo que se está pidiendo.

    Por lo que creo que teniendo una cierta transparencia y confianza entre el equipo y el cliente se pueden unificar estos conceptos. Por parte del equipo al realizar una estimación ponerle compromiso para que dicha estimación sea lo más cercana a la realidad posible, y por parte del cliente confiar en que dicha estimación fue hecha a conciencia y entender lo que conlleva realizar las tareas solicitadas, sabiendo que aunque sea con el mayor de los compromisos y tiempo dedicado, dicha estimación puede no ser finalmente el tiempo que lleve realizar la/s tarea/s.

  7. Leandro Linardos dice:

    Concuerdo con lo dicho con los chicos más arriba.

    Agrego que existe una diferencia en el conocimiento requerido, esfuerzo aplicado y fin para una u otra acción. Estimar, puede estimar cualquiera, lo vivimos en los ejemplos que se usan para marcar estas diferencias: podemos estimar el peso de una ballena, el tiempo de preparación de una tortilla, el precio en la construcción de un edificio, sin ser teriólogo, gastronómico o arquitecto.

    Para planificar, en cambio, requerimos conocimiento. El peso de una ballena no se planifica en principio (cambia el fin), el tiempo de preparación de una tortilla requiere conocimiento sobre tiempos de cocción, pasos, etc (cambio en el conocimiento requerido y en el esfuerzo) y el precio de la construcción de un edificio también.

    Me animo a concluir que una buena estimación (buena en el sentido en que es útil para planificar un proyecto de software) es aquella que se acerca a una planificación, sacando provecho del conocimiento y negociando en esfuerzo.

  8. Leandro Linardos dice:

    Concuerdo con lo dicho por los chicos más arriba.

    Agrego que existe una diferencia en el conocimiento requerido, esfuerzo aplicado y fin para una u otra acción. Estimar, puede estimar cualquiera, lo vivimos en los ejemplos que se usan para marcar estas diferencias: podemos estimar el peso de una ballena, el tiempo de preparación de una tortilla, el precio en la construcción de un edificio, sin ser teriólogo, gastronómico o arquitecto.

    Para planificar, en cambio, requerimos conocimiento. El peso de una ballena no se planifica en principio (cambia el fin), el tiempo de preparación de una tortilla requiere conocimiento sobre tiempos de cocción, pasos, etc (cambio en el conocimiento requerido y en el esfuerzo) y el precio de la construcción de un edificio también.

    Me animo a concluir que una buena estimación (buena en el sentido en que es útil para planificar un proyecto de software) es aquella que se acerca a una planificación, sacando provecho del conocimiento y negociando en esfuerzo.

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: