Planificacion ágil en la vida real

Copyright IBM Corporation 2009 MarcasPlanificacin gil en la vida real Pagina 1 de 14

Planificacin gil en la vida realConsejo inicial para el desarrollo de versiones con planificacin gil

Steffan Surdek ([email protected])User Experience LeadIBM

21-05-2009(Primera publicacin 31-03-2009)

Forma parte de un equipo que desea implementar una planificacin gil? Est usando eldesarrollo iterativo y contina atascado haciendo "inundaciones de iteracin"? En este artculo,el autor utiliza su experiencia para ayudar y capacitar a los equipos del producto de IBM paraque se familiaricen con un plan de accin que responde a la siguiente pregunta: "Cmocomienzo a desarrollar versiones con planificacin gil?" Adems, Steffan desarrolla todoslos fundamentos de la planificacin gil y comparte sus conocimientos sobre qu funciona yqu no. Nota del editor: Se actualizaron las figuras 1 y 4 y se agregaron otras correcciones apedido del autor.

"Somos giles y realizamos iteraciones". Los equipos que dicen utilizar el desarrollo gil suelenafirmar esto con frecuencia. Pero muchos otros factores, adems de realizar sus desarrollos pormedio de iteraciones, son necesarios para ser realmente gil.

Tradicionalmente, los equipos de desarrollo tienen versiones especficas con contenidospredeterminados y fechas predeterminadas. Al comienzo de cada versin, el equipo de gestin serene con el equipo de desarrollo para cumplir con el ritual de imponer los contenidos que deseanque se incluyan y fijar la fecha de lanzamiento.

El desafo en este escenario consiste en que la gerencia est tratando de establecer tanto lafecha de lanzamiento como los contenidos que se deben incluir, mientras que el equipo dedesarrollo cree que slo pueden lograr uno de estos dos objetivos. En realidad, los contenidospueden llegar a ser ms flexibles que lo que el equipo de desarrollo cree. Desafortunadamente,los equipos de desarrollo no siempre se dan cuenta de esto y la gente comienza a trabajarexcesivamente para lograr los objetivos.

Resumen de un desarrollo gil de software

El desarrollo gil de software es un grupo de metodologas de desarrollo de softwareque se basan en principios similares. Generalmente, estas metodologas promueven un

developerWorks ibm.com/developerWorks/ssa/

Planificacin gil en la vida real Pagina 2 de 14

proceso de gestin de proyecto que alienta la inspeccin y la adaptacin frecuente, mejoresprcticas de ingeniera que facilitan la entrega rpida de software de alta calidad y unafilosofa de liderazgo / negocios que abarca el trabajo en equipo, la auto organizacin, laresponsabilidad y el desarrollo alineado con las necesidades del cliente y los objetivos de lacompaa.

Los siguientes enfoques modernos de anlisis y gestin de operaciones compartenfundamentos conceptuales similares:

Fabricacin / Produccin ajustada: Una prctica de produccin que considera undesperdicio la utilizacin de todo recurso que no cree valor para el consumidor final.

Metodologa de sistemas leves: Un enfoque apropiado para el anlisis de situacionescomplejas con puntos de vista divergentes sobre la definicin del problema (es decir,problemas "leves" como en el caso de "Cmo gestionar los desastres?").

Six Sigma: Un enfoque que busca identificar y eliminar las causas de los defectos ylos errores en los procesos utilizando un conjunto de mtodos de gestin de calidad ycreando una infraestructura especial de personas (expertos en estos mtodos) dentrode la organizacin ("Cinturones Negros", etc.).

Este artculo sirve a modo de plan de accin para ayudarlo a superar esta dificultad y hacer quesu equipo pase de realizar un desarrollo iterativo plano a realizar un desarrollo gil. El plan deaccin incluye lo siguiente:

Sugerencias para ayudar a su equipo con la transicin hacia la planificacin gil. Gua sobre las iteraciones. Cmo deberan ser? El equipo slo debera trabajar en las

iteraciones durante una versin en particular? Qu debera hacer el equipo entre versin yversin?

Consejos para crear historias de usuario y comprender la funcin del propietario del producto.Qu son las historias de usuario? Quin las debera redactar? Cul es la diferencia queexiste entre una epopeya y una historia? Cul debera ser la longitud del trabajo incluido enla historia? Quin es el propietario del producto en el proceso?

Consejos sobre cmo planificar y gestionar los registros a nivel del producto, la versin y laiteracin. Cada nivel de planificacin tiene su propio registro. Qu deberan incluir estosregistros diferentes? Qu nivel de estimacin se requiere para cada nivel de planificacin?

Tcnicas para medir e interpretar la velocidad del equipo. Qu clase de informacin sepuede extrapolar a partir de la velocidad del equipo?

Facilitar la transicin

A continuacin, se presentan algunos factores que se deben tener en cuenta antes de darcomienzo a la transicin:

Comprender qu es lo que se quiere lograr con el proceso. A algunas personas lesresulta muy difcil cambiar y, por lo tanto, usted debe entender en qu lugares desea hacerque las personas se comprometan al comienzo del proceso para as poder obtener losresultados deseados. Recuerde que siempre podr pedir ms una vez que haya demostradoque est obteniendo los resultados deseados. Exprese que lo que desea agregar essimplemente el prximo paso en la evolucin del proceso.

No d comienzo a la transicin de manera repentina. Si obliga al equipo a transitar elproceso sin que ste haya recibido la capacitacin necesaria, existe la posibilidad de que

ibm.com/developerWorks/ssa/ developerWorks


se cree un gran resentimiento y una falta de confianza generalizada en relacin al nuevoproceso.

Comprenda que la educacin es su amiga. Aprenda todo lo que necesita aprender ysintase cmodo con ello. Trate de utilizar mtodos giles en un proyecto pequeo enprimer lugar para as solucionar algunos de los tpicos problemas. Cuando haya aprendidotodo lo necesario, eduque al resto de su equipo. Asegrese de que todos utilicen el mismovocabulario y comprendan el proceso antes de comenzar. Este proceso de educacin loayudar a identificar las brechas en sus propios conocimientos.

Compromtase con el proceso. Una vez que haya comenzado, no mire hacia atrs. Yodadebe de haber tenido esto en cuenta cuando dijo: "Hazlo o no lo hagas... No existe intentar."Si las cosas empiezan a salir mal, realice todos los ajustes necesarios al proceso nuevo envez de volver a lo que sola hacer antes de dar comienzo al proceso en cuestin.

Es necesario contar con el compromiso de su equipo para lograr el xito. Para ello es necesarioque usted crea en el proceso. La planificacin gil puede funcionar para su equipo si usted secompromete a hacer todo lo correcto.

Programacin de sus iteracionesComencemos con una pregunta muy popular: "Cul debera ser la longitud de sus iteraciones?"El objetivo de las iteraciones consiste en permitir que el equipo obtenga la retroalimentacinnecesaria en las primeras etapas del proceso y de los interesados (clientes, el propietario delproducto y dems personas involucradas).

La iteracin ms comn dura entre dos y cuatro semanas (a veces, dura hasta seis semanas).Las ms cortas suelen ser ms fciles de planificar ya que el cambio rpido crea un sentido deurgencia. Aquellas ms prolongadas dan la falsa impresin de que se dispone de mucho mstiempo para hacer el trabajo requerido. Esto puede resultar muy contraproducente.

Las iteraciones son el latido del corazn de su equipo. Usted siempre debera realizarlas, inclusocuando no est trabajando en una versin. Esto har que el equipo pueda programar tempranasinvestigaciones (tambin conocidas como clavos arquitectnicos), realizar prototipos o crearhistorias de usuario para la prxima versin. Realizar estas actividades antes de trabajar en lasiteraciones "oficiales" correspondientes a la versin lo puede ayudar a identificar los riesgos conantelacin y disear planes de mitigacin de ser necesario.

Intente no modificar la longitud de la iteracin durante una versin en particular slo con elpropsito de cumplir con una fecha de lanzamiento estipulada. Es posible que su equipo seresista al cambio. Adems, si modifica la longitud de la iteracin de manera muy frecuente, seestar demostrando que los lderes de su equipo no confan en el nuevo proceso. Tambin resultams difcil calcular la velocidad del equipo (un tema que trataremos ms adelante en Medicin dela velocidad) cuando las longitudes de la iteracin varan, ya que no se est utilizando un perodode tiempo constante para realizar la medicin.

La excepcin a preferir una iteracin ms corta es la iteracin final. Si la iteracin final incluyeactividades, principalmente, de etapa final, tales como la globalizacin y la correccin de errores,al equipo le resulta menos disruptivo contar con una iteracin ms corta en este momento.



Como alternativa a la programacin de una iteracin ms corta para la iteracin final, usted puedeprogramar una longitud menor (como, por ejemplo, dos semanas) para todas las iteraciones.Mediante la utilizacin de este enfoque, si la fecha de lanzamiento no se encuentra al final de laiteracin, usted podr finalizar el trabajo para realizar el lanzamiento una semana antes.

En el ltimo da de una iteracin, destine el tiempo que sea necesario para realizar unademostracin y un anlisis retrospectivo de la iteracin e incluya a los desarrolladores, al equipode gestin y a los interesados. La demostracin de las caractersticas ayuda a todas las personasinvolucradas a ver el progreso que realiz el equipo y, adems, brinda una oportunidad paraobtener retroalimentacin temprana, lo que podr resultar en ajustes valiosos durante el curso dela versin.

Creacin de historias de usuarioLas historias de usuario son frases ingeniosas que establecen los requisitos del cliente.Imagnelas como lo que usted le dira a un cliente para explicarle lo que est haciendo. Lashistorias de usuario se concentran en las necesidades del cliente y no explican los detalles de laimplementacin.

El propietario del producto habla con los clientes para lograr comprender sus requisitos y creaun conjunto inicial de historias de usuario de alto nivel. Para crear historias de usuario msdetalladas, probablemente necesite crear un equipo de clientes que tengan un gerente deproducto, testers, usuarios reales y diseadores de interaccin. Esta plantilla resulta muy til parala redaccin de historias de usuario:

En mi calidad de, deseo lograr.

Las historias de usuario tambin pueden tener una jerarqua. Las epopeyas son aquellas historiasde usuario que describen las caractersticas o las funcionalidades en un nivel ms avanzado.Usted puede iterar con stas, desglosarlas y generar nuevas historias de usuario y epopeyas. Lafigura 1 ilustra una epopeya que se dividi en mltiples historias de usuario.

Figura 1. Epopeya dividida en historias de usuario

Las historias de usuario representan el trabajo que el equipo debe realizar para satisfacer losrequisitos del producto. Cul debera ser la longitud de las historias de usuario? En el casode las epopeyas, realmente no tiene importancia, ya que luego se los podr dividir en unidades



ms cortas. La creacin de aquellas historias con las que el equipo trabajar durante la iteracindeberan llevar entre dos y tres das y estar impulsadas por las funcionalidades, siempre que estosea posible.

Nunca se debera determinar la longitud de las historias de usuario de manera tal que se adaptena una iteracin. Por ejemplo: En el caso de una iteracin de cuatro semanas de duracin, existe laposibilidad de que se cuente con una historia larga que no se pueda incluir dentro de la iteracin.Al final de la iteracin, es probable que se d cuenta de que el equipo no puede abarcar latotalidad del trabajo que se comprometi a realizar.

Es normal que el registro de su versin tenga una gran cantidad de historias de usuario.Considere esto como una verificacin de la realidad. Si cuenta con menos historias de usuariopero le lleva ms tiempo implementarlas, esto quiere decir que no tiene una clara idea del trabajoque necesita realizar.

Debera tratar de adoptar el enfoque de componentes fundamentales al momento de crearhistorias de usuario. Cul es el comportamiento funcional mnimo que puede brindar? Comiencedesde dicho punto. Luego, cree otra historia para el prximo conjunto de comportamientosfuncionales y siga avanzando hasta que haya creado todas las historias que sean necesarias paracubrir la totalidad de esta caracterstica.

Tenga en cuenta que las historias pueden llegar a penetrar en los diferentes componentes de suproducto. En tal caso, su equipo slo necesita crear las tareas para cada componente durante lafase de planificacin de la iteracin.

Identificacin del propietario del productoLo prximo a hacer es identificar el propietario del producto. El propietario del producto esalguien que est en contacto con los clientes y comprende sus necesidades. l identifica lascaractersticas requeridas que el producto debe incluir para lograr el xito comercial y satisfacerlas necesidades de los clientes.

La relacin que existe entre el propietario del producto y el equipo de desarrollo es muy similara la relacin que hay entre un cliente y su proveedor. Lo ms importante a recordar sobre laplanificacin gil es que el equipo de desarrollo siempre debera trabajar sobre los puntos queel propietario del producto considera importantes. Por esta razn es que tanto el registro delproducto como los registros de la versin son listas que establecen prioridades.

Incluso cuando el propietario del producto sea quien toma la decisin final en relacin con lasprioridades, tendr que seguir existiendo una relacin saludable entre el equipo de desarrollo yel propietario del producto. El equipo debe garantizar que sus necesidades, en relacin con eltrabajo de arquitectura que debe figurar en el registro de la versin, se comprendan y prioricen demanera adecuada.

La responsabilidad del propietario del producto consiste en garantizar que se priorice tanto elregistro del producto como el registro de la versin de forma adecuada para as garantizar que elequipo siempre est trabajando sobre los puntos ms importantes.



Registro del productoEl propietario del producto es el responsable del registro del producto, un conjunto de historias deusuario ordenadas segn su prioridad que se implementar en el producto.

Es probable que su equipo ya cuente con una base de datos de requisitos o reas de trabajo.En tal caso, estos constituyen un buen punto de partida para crear su registro del producto. Paraconvertir su base de datos ya existente, el propietario del producto debera revisar la base dedatos de los requisitos e identificar las historias de usuarios de alto nivel relacionadas con cadauno de ellos.

Es necesario priorizar el registro, ya que esto hace que el propietario del producto puedaseleccionar las partes ms importantes de un requisito a implementar. A un requisito se lo puedellegar a dividir en diez historias de usuario. Pero si el equipo de desarrollo logra completar lascinco historias ms importantes, es probable que eso sea suficiente como para satisfacer losrequisitos del cliente.

Figura 2. Cmo alimenta el registro del producto a todos los dems?

Es necesario que el equipo estime las historias de alto nivel en el registro del producto utilizandopuntajes. Todos los grupos involucrados en la entrega de caracterzaciones (desarrollo, seguro decalidad y documentacin) participan del proceso de estimacin. Estas estimaciones hacen que elpropietario del producto pueda determinar el costo relativo de cada rasgo.

El registro del producto debe ser dinmico y se podrn agregar, eliminar y volver a priorizar suselementos. Al mismo tiempo, es necesario que se lo actualice. El trabajo que representa nodebera superar los 18 meses. Una vez superado dicho perodo de tiempo, se deberan quitar dela lista todos los elementos de baja prioridad.

Por qu se debera limitar la longitud del registro? Esta sugerencia resulta de los principiosSensibles (vea el Resumen del desarrollo gil de software). No tiene sentido mantener unacantidad de trabajo en espera que usted sabe que no podr realizar en una cantidad de tiemporazonable. Si una buena idea se quita del registro, se la volver a incluir, si realmente es unabuena idea, y usted est en contacto con las necesidades de sus clientes. Por lo tanto, permitaque algunos elementos se quiten de la lista y no trate de conservarlos en otra lista de registrosecreta o escondida.



Registro de la versin

Al comienzo de una versin, el propietario del producto mira el registro del producto e identificalas historias de usuario que se incluirn en la prxima versin. Luego, estos elementos pasan alregistro de la versin.

Generalmente, el ritual de imposicin de ideas y plazos comienza en este momento. Ahora, elequipo de desarrollo debe trabajar conjuntamente con el propietario del producto para garantizarque el trabajo identificado sea apropiado para el tamao y la duracin de la versin. El rastreo dela velocidad del equipo durante la versin ofrecer un panorama ms claro de qu proporcin detodo el trabajo se llevar a cabo de manera efectiva.

Al crear el registro de la versin, divida las historias de usuario de alto nivel en historias deusuario ms cortas. Para hacer esto, considere la creacin de un equipo del cliente que incluya ungerente de producto, testers, usuarios reales y diseadores de interaccin.

El equipo del cliente trabaja conjuntamente con el propietario del producto con el fin de establecerla prioridad de las historias nuevas y, luego de esto, agregarlas al registro de la versin. Despusde esto, el equipo de desarrollo realiza estimaciones sobre estas historias nuevas y les asigna unpuntaje. El objetivo de esta etapa es que el equipo de desarrollo tenga una idea clara de lo que serequiere que figure en la versin ms partes y ms pequeas para as poder realizar la estimacincorrespondiente.

A medida que el equipo de desarrollo trabaja con las historias de usuario durante lasiteraciones, el propietario del producto y el equipo de desarrollo adquieren conocimientos. Estosconocimientos pueden llegar a generar nuevas historias de usuario o demostrar que algunashistorias no son tan importantes. En el caso de las historias nuevas, el propietario del productoy el equipo de desarrollo necesitan atravesar el proceso de estimacin y prioridad una vez ms.El propietario del producto debera eliminar todas aquellas historias que no sean tan importantesdel registro de la versin o reducir su importancia. Adems, el equipo tambin puede utilizarestos nuevos conocimientos para modificar las estimaciones correspondientes a las historias yaexistentes que figuran en el registro.

El registro de la versin es dinmico. Pero una vez que se da comienzo a la iteracin, elpropietario del producto ya no puede modificar el trabajo que se seleccion para la iteracin.Si, luego de que se dio comienzo al trabajo, el equipo adquiere conocimientos que revelan queciertos elementos no entran en la versin o en la iteracin, nos encontraremos ante una situacindiferente (como se discute en la prxima seccin). Durante la iteracin, el equipo de desarrollodebe poder concentrarse en sus entregas.

Registro de la iteracin

Al comienzo de la iteracin, el propietario del producto puede volver a determinar la prioridaddel registro de la versin con el fin de que el equipo de desarrollo tome conocimiento de loselementos con los que va a tener que trabajar. Tanto el propietario del producto como el equipo dedesarrollo deberan realizar la reunin de planificacin de la iteracin durante la mitad del primer



da de la iteracin. Durante esta reunin, el equipo debera seleccionar todos los elementos dealta prioridad que pueda incluir el registro de la versin y agregarlos al registro de la iteracin.

El hecho de tener listo el registro de la versin nos permite limitar esta actividad a slo la mitad delda. Si el equipo est a cargo de crear las historias de usuario de iteracin a iteracin (en vez dehacerlo lo antes posible), es probable que usted pierda tiempo muy valioso y tarde ms en realizarla planificacin. Adems, usted nunca sabr con exactitud la cantidad de trabajo que se planificpara su lanzamiento.

Durante la reunin de planificacin, por cada historia de usuario que figura en el registro de laiteracin, el equipo necesita desglosar todas las tareas requeridas para que se pueda considerarla historia como completa. Tambin es necesario identificar las tareas de todos los equiposinvolucrados en la historia (desarrollo, seguro de calidad, documentacin). Adems, el equiponecesita estimar la carga horaria correspondiente a cada una de estas tareas y, luego de esto,agregar estas estimaciones al plan.

La mayor preocupacin es el compromiso excesivo. Durante sus primeras iteraciones, considerela cantidad de horas necesarias en la estimacin para as poder garantizar que el trabajo seadecue al tiempo asignado para la iteracin. Si el equipo termina el trabajo antes de tiempo,siempre puede volver al registro de la versin y seleccionar tareas adicionales que se puedancompletar durante la iteracin.

La otra preocupacin consiste en no poder identificar todas las tareas requeridas para completaruna historia. Desafortunadamente, esto es inevitable en sus primeras iteraciones. Estoselementos olvidados se apilan y pueden llegar a hacer que usted no pueda completar una historiaen particular durante una iteracin. A continuacin, incluimos dos ejemplos de este error tancomn:

Contar con un sector de almacenamiento denominado "Prueba" que no incluye el tiemponecesario para redactar los casos de prueba.

No incluir una tarea para que el equipo de desarrollo redacte pruebas de la unidadautomatizada.

Antes de que el equipo vuelva al registro de la versin, asegrese de que se hagan las historiasque figuran en la iteracin (luego de esto asegrese de que se hagan dos veces ms). Es decir,se completaron todas las tareas? Si todava queda pendiente alguna prueba para una historia deusuario, lo que ms le conviene es hacer que el desarrollador ayude al tester a completar dichaprueba. Si sigue habiendo defectos en el caso de las historias de usuario desarrolladas en laiteracin, corrjalos ahora antes de seguir avanzando. Contribuya con la calidad. Lo que realmenteimporta no es la cantidad de trabajo que realice en una iteracin sino el hecho de que el trabajoentregado est lo ms libre de errores que sea posible.

Adems, le conviene establecer criterios de salida para sus iteraciones. Por ejemplo, todos losdefectos de alta prioridad (severidad uno y dos) se deben resolver para que se pueda considerarque la historia est completa. Todos los defectos de baja prioridad (severidad tres y cuatro) quequeden sin resolver se debern resolver en la siguiente iteracin y se agregarn en la parte



superior del registro de la iteracin. Es muy importante no permitir que los defectos se prolonguenpor un perodo de tiempo extenso. De esta forma, usted se encontrar en una posicin muchoms favorable durante la parte final del proceso correspondiente a su lanzamiento.

Si, durante el transcurso de la iteracin, el equipo se da cuenta de que una historia de usuarioresulta ser ms complicada que lo que se pensaba en un principio y no puede formar parte dela iteracin o incluso de la versin, usted deber presentar este problema lo antes posible. Esmuy importante identificar sus opiniones. Existe una forma de reducir paulatinamente la historiamientras que se sigue creando valor para el cliente en la versin actual? En tal caso, cree lashistorias de usuario adecuadas y disctalas con el propietario del producto. La versin reducidapuede ser slo una medida temporaria: Qu hara si contase con el tiempo necesario para hacerlo correcto? Identifique las historias de usuario correspondientes a estos elementos y disctalascon el propietario del producto. Es probable que aparezcan en las versiones futuras del producto.

El equipo puede agregar todo tipo de trabajo en el plan de iteracin. Si una caracterstica enparticular requiere un clavo arquitectnico, agregue una historia de usuario al registro de laversin y cuente con las siguientes tareas por ejemplo: "Diseo", "Construccin del prototipo" o"Investigacin". Lo que tiene de bueno agregar una historia de usuario al registro de la versinpara el clavo arquitectnico es que permite que el propietario del producto le d prioridad. Siel propietario del producto cree que el costo de la investigacin es muy elevado, la historiacorrespondiente al clavo arquitectnico se encontrar ms abajo en la lista o se eliminar lacaracterstica de la versin.

Asignacin del puntaje a las historias de usuario

En el registro del producto y en los registros de la versin, el equipo de desarrollo estima y asignael puntaje para cada historia de usuario. Por qu conviene utilizar puntajes en vez de unidadesde tiempo (como, por ejemplo, las horas)? La razn principal es que, en las primeras etapas dedesarrollo, usted no sabe cunto trabajo le demandar una historia en particular. Y, si realiza todoel anlisis y el diseo de antemano, es posible que evite que el diseo evolucione, ya que ustedconoce ms sobre la caracterstica en cuestin.

Otra razn es que el tiempo ideal puede variar de una persona a otra. Si la persona que realiza laestimacin no es la misma que hace el trabajo, existe la posibilidad de que la estimacin no seacorrecta.

Por ltimo, lo que originalmente era una estimacin del tiempo ideal se puede llegar a interpretarerrneamente como una estimacin del tiempo transcurrido. El tiempo transcurrido es el tiempoque lleva hacer el trabajo luego de contabilizar todas las interrupciones que el empleado sufredurante un da de trabajo comn y corriente. Entonces, por ejemplo, una tarea con una duracinestimada de cinco das podra llevar entre ocho y nueve das reales si se toman en cuenta lasreuniones diarias, los correos electrnicos, las llamadas telefnicas y las revisiones.

Cuando se utilizan puntajes, lo que se hace es comparar la complejidad relativa que existe entredos caractersticas. Si toma una historia que tiene slo un punto y la compara con otra que tienecinco puntos, lo que se establece esencialmente es que la segunda historia es cinco veces ms



grande que la primera. Tenga en cuenta que nunca se dijo que esto necesariamente involucraracinco veces ms trabajo.

Es posible que haya historias de usuario que el equipo no pueda estimar, ya que se desconocenmuchos factores. En tales casos, el equipo puede agregar una historia de usuario especfica alregistro para luego realizar una investigacin adicional al respecto. Una vez hecho esto, el equipopuede volver a analizar la historia para asignarle el puntaje correspondiente.

Al principio, estimar los puntajes es un gran desafo, ya que su equipo no cuenta con un puntajede referencia. A medida que el equipo realiza ms y ms estimaciones, la precisin de stas iraumentando. Para estimar los puntajes, puede usar la tcnica de Planificacin de Pker.

La Planificacin de Pker es una tcnica de estimacin basada en el consenso que se utilizapara estimar el esfuerzo requerido por las tareas de desarrollo de software o su tamao relativo.Esto busca minimizar el anclaje(comentarios tempranos que los miembros del equipo expresan aviva voz y "anclan" el tiempo que lleva una tarea). Cada miembro del equipo muestra su carta deestimacin (la que expresa los valores 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40 100 pero no unidades, yaque el moderador est a cargo de determinarlas) de manera tal que los dems participantes nopuedan verla. Luego de que todos los participantes hayan hecho esto, todas las cartas se ponenen conocimiento de los dems al mismo tiempo.

Medicin de la velocidad

La velocidades son el rastreo a largo plazo de la cantidad de trabajo que realiz un miembro delequipo por iteracin. Esto se mide utilizando las mismas unidades que figuran en el registro de laversin (es decir los puntajes).

Al principio, al equipo le asigna un puntaje a cada historia en el registro de la versin. El elcomienzo de cada iteracin, el equipo selecciona las historias con las que trabajar durante eltranscurso de la iteracin. Para ganar los puntos que se asignaron a una historia en particular, elequipo debe completar todas las tareas correspondientes a dicha historia durante la iteracin.

Si el equipo no completa una o ms tareas correspondientes a una historia en particular, norecibir ningn punto por dicha historia al finalizar la iteracin actual y la misma pasar a laprxima iteracin. El equipo ganar los puntos correspondientes a la historia en la iteracindurante la que complete las tareas pendientes.

A medida que el equipo completa las iteraciones, acumula puntos y observa los datoscorrespondientes a las iteraciones anteriores, una imagen como la que se puede observar en laFigura 3 comienza a surgir. Tenga en cuenta cmo el equip no gana la misma cantidad de puntosen cada iteracin.



Figura 3. Velocidad a lo largo de varias iteraciones

Lo interesante sobre la velocidad es que, luego de algunas iteraciones, usted puede comenzara utilizar las cifras que figuran en sus cuadros de rastreo para extrapolar la cantidad exacta deelementos de su registro de la versin que podr completar.

Tabla 1. Puntaje por iteracin

Iteracin Puntos

1 28

2 32

3 36

4 34

5 33

6 37

7 31

8 35

La Tabla 1 muestra los puntajes por iteracin. Utilizando los datos que figuran en la Tabla 1, ustedpuede extrapolar la siguiente informacin:

La cantidad promedio de puntos por iteracin es 33. La velocidad actual del equipo es 35 puntos. El promedio de las tres iteraciones ms lentas es 30 puntos.

Por lo tanto, asumiendo que usted tiene 6 iteraciones pendientes en su versin, puede comenzarpor realizar las siguientes suposiciones:

A una velocidad promedio, el equipo obtendr 198 puntos adicionales (6 x 33). A la velocidad actual, el equipo obtendr 210 puntos adicionales (6 x 35). A la velocidad ms lenta, el equipo obtendr 180 puntos adicionales (6 x 30).

En la Figura 4, se puede observar el registro de la versin dividido en tres secciones. La seccindel medio representa el trabajo que se puede incluir en las ltimas 6 iteraciones utilizando lassuposiciones que figuran ms arriba.



Figura 4. Extrapolacin donde culmina el trabajo

La Figura 4 tambin muestra que el equipo de desarrollo no puede completar todas las historiasde usuario en el registro de la versin. No obstante, si el equipo siempre comienza a trabajar conlos primeros puntos que figuran en la lista, existen ms posibilidades de que el equipo siemprehaya trabajado con los puntos ms importantes de la versin.

Conclusin

El principal objetivo de la planificacin gil consiste en que la mayor parte posible del trabajo"conocido" est sobre la mesa a la vista de todos. Este artculo enfatiza lo "conocido" porque, amedida que usted adquiere conocimientos sobre lo que est haciendo, existe la posibilidad deque agregue historias nuevas al registro. Esto hace que el propietario del producto modifique laprioridad del registro de la versin de manera continua y garantice que el equipo de desarrollosiempre est trabajando con los temas ms importantes.

Generalmente, los propietarios de productos sobreviven incluso cuando no todas las historiasllegan a formar parte de la versin. No obstante, suelen enojarse por esto cuando el equipodedica demasiado tiempo a temas que no tienen una importancia crtica y, por lo tanto, no puedenincluir todas las historias importantes en la versin porque no les alcanza el tiempo. Por lo tanto,trate a los propietarios de productos como si fuesen sus clientes y concntrese en priorizar lastareas que ellos consideran primordiales.

Todas las opiniones que inclu en este artculo son personales y no necesariamente compartidascon IBM.



Recursos

Lea los artculos que se usaron para la redaccin del presente: Estimacin y planificacin gil(Prentice Hall PTR, 2005) es una gua para la estimacin

y la planificacin de proyectos giles, cumplimentada con una visin filosfica y prcticasobre la estimacin y la planificacin gil.

Historias de usuario aplicadas: Para el desarrollo gil de software(Addison-Wesley,2004) se concentra en la importancia de las historias de usuario para el desarrollo gil.

Tambin vea la capacitacin para el desarrollo gil. Planificacin de Pkeres una tcnica que ayuda a los equipos distribuidos a que realicen

estimaciones en conjunto. La serie de trabajos denominada "Manifiesto arquitectnico: Adopcin del desarrollo

gil" (developerWorks, marzo de 2008 - enero de 2009) puede ayudarlo a decidir si eldesarrollo gil se adeca a sus necesidades:

Parte 1: Sobre los procesos, los beneficios y los requisitos Parte 2: Cmo se lo utiliza para los diferentes proyectos? Efectos del cliente Parte 3: La funciones de los interesados Parte 4: Definicin de los requisitos Parte 5: Historias de usuario y priorizacin Parte 6: Desde el punto de vista del cliente Parte 7: Estimacin del esfuerzo de trabajo Parte 8: Modelacin Parte 9: El vnculo entre gil y SOA

Es esta transmisin,"Scott Ambler analiza el desarrollo gil" (developerWorks, abril de 2007),el experto en Prcticas de Desarrollo gil de IBM explica este enfoque iterativo y gradualsobre el desarrollo, presenta un caso de negocios y despeja algunos de los mitos relativos alproceso.

"Desarrollo gil de software: Anlisis de sus orgenes y autores" (developerWorks, marzo de2007) tiene el objetivo de mostrarle cul es el verdadero significado de la palabra "gil".

En el rea de Linuxdenominada developerWorks, usted podr encontrar ms recursos paralos desarrolladores de Linux (incluyendo aquellos desarrolladores querecin empiezan atrabajar con Linux), y ver nuestrosartculos y tutoriales ms populares.

Vea todos losconsejos de Linuxylos tutoriales de Linuxen developerWorks. Utilizando elsoftware a modo de prueba de IBM, que est disponible para bajarlo

directamente desde developerWorks, construya su prximo proyecto de desarrollo en Linux.



Sobre el autor

Steffan Surdek

Steffan Surdek es Lder de Experiencia del Usuario y se autoproclam Campen gilpara el equipo de WebSphere Business Services Fabric. Steffan usa su experienciapara permitir que los Talleres giles Grupales de Software de dos das de duracinayuden a su equipo a trabajar en la forma de mejorar sus procesos giles.

Copyright IBM Corporation 2009(www.ibm.com/legal/copytrade.shtml)Marcas(www.ibm.com/developerworks/ssa/ibm/trademarks/)

Planificacion ágil en la vida real

Documents

Transcript of Planificacion ágil en la vida real