{"id":2048,"date":"2022-09-21T09:00:39","date_gmt":"2022-09-21T08:00:39","guid":{"rendered":"https:\/\/keepler.io\/2022\/09\/21\/5-pasos-para-implantar-un-framework-agil-en-un-proyecto-cerrado\/"},"modified":"2024-01-15T13:28:47","modified_gmt":"2024-01-15T12:28:47","slug":"5-pasos-para-implantar-un-framework-agil-en-un-proyecto-cerrado","status":"publish","type":"post","link":"https:\/\/keepler.io\/es\/2022\/09\/21\/5-pasos-para-implantar-un-framework-agil-en-un-proyecto-cerrado\/","title":{"rendered":"5 pasos para implantar un framework \u00e1gil en un proyecto cerrado"},"content":{"rendered":"

Cuando, como agilistas, escuchamos las palabras \u201cproyecto cerrado\u201d, suele ocurrir que un escalofr\u00edo recorre nuestra espalda de arriba a abajo. Sin embargo, afrontar un proyecto cerrado usando un framework \u00e1gil no tiene por qu\u00e9 ser una terrible experiencia. En este art\u00edculo veremos c\u00f3mo, <\/span>aplicando unos sencillos pasos, podemos echar a andar un proyecto y hacer que dos t\u00e9rminos aparentemente opuestos puedan confluir<\/b>.<\/span><\/p>\n

El escenario para el que estos pasos aplicar\u00edan ser\u00eda un proyecto con duraci\u00f3n determinada y para el cual se ha propuesto al cliente seguir un framework \u00e1gil para obtener feedback cuanto antes que pueda ayudar a trasladar bloqueos, riesgos o dependencias y proveer de las herramientas para planificar nuevas fases.<\/span><\/p>\n

Este escenario supone un aut\u00e9ntico reto para un agilista, puesto que debe identificar con el cliente qu\u00e9 bloqueos existen, a qu\u00e9 acuerdos se llegan y qu\u00e9 avance ha habido en el desarrollo de la soluci\u00f3n, de cara a gestionar correctamente las expectativas. El objetivo principal es evitar burocracia adicional consiguiendo que haya una transparencia total en todo momento. Veamos c\u00f3mo podr\u00edamos conseguir ese objetivo y ser exitosos.<\/span><\/p>\n

Paso 1. Elecci\u00f3n del framework que se quiere implantar.<\/h3>\n

Normalmente, al ser un proyecto con alcance cerrado, el marco m\u00e1s adecuado ser\u00eda acercarnos a Scrum siempre y cuando exista un incremento de valor, mientras que el acercamiento ser\u00eda m\u00e1s adecuado usando Kanban en el caso de que tuvi\u00e9semos un flujo continuado de tareas.<\/span><\/p>\n

Paso 2. Kick-off con el cliente.<\/h3>\n

El objetivo de esta sesi\u00f3n es establecer un entendimiento compartido del alcance del proyecto, explicitar qu\u00e9 objetivos se quieren conseguir y definir el marco de colaboraci\u00f3n con el cliente, esto es, el d\u00eda a d\u00eda. En este \u00faltimo punto es donde se encajar\u00eda este paso. El objetivo principal es explicar pormenorizadamente aspectos como los eventos, su periodicidad, su objetivo, qui\u00e9n se precisa que asista, la dedicaci\u00f3n de personas por parte del cliente y los bloqueos en caso de que existan (accesos, etc.). De cara a un enfoque m\u00e1s \u00e1gil, una fase de inception m\u00e1s light podr\u00eda ayudarnos mucho como forma de sustituir esta parte del Kick-off cl\u00e1sico.<\/span><\/p>\n

Paso 3. Puesta en marcha del framework.<\/h3>\n

Al terminar el kick-off, se deber\u00e1 al menos agendar la daily y la primera planificaci\u00f3n del sprint. Ser\u00eda aconsejable que durante la primera semana se asignen intervalos fijos de tiempo para las reviews, las retrospectivas y los refinamientos (si es necesario, puesto que pueden ser ad hoc). De este modo, a las personas requeridas por parte del cliente les resultar\u00e1 m\u00e1s f\u00e1cil asistir. <\/span>Es importante que, especialmente durante la primera iteraci\u00f3n, se haga especial hincapi\u00e9 en recordar para qu\u00e9 sirve cada uno de los eventos, de manera que los asistentes tengan claro el objetivo y de este modo evitar temas que no vienen al caso y que generan dispersi\u00f3<\/b>n. Si el equipo no es lo suficientemente maduro es posible que se requieran algunas sesiones adicionales para mentorizar sobre el framework y que tengan claro el objetivo de cada evento y el principio de entrega de valor en cada iteraci\u00f3n. Tambi\u00e9n es importante que en las primeras iteraciones no solo se trabaje con el Product Owner en lo que se ha decidido en el Sprint Planning, <\/span>sino que se intente adelantar refinando lo que vendr\u00e1 en siguientes iteraciones, y siempre que el alcance tenga aspectos por definir m\u00e1s en profundidad<\/b>. Igual que antes, si el equipo es suficientemente maduro los refinamientos ser\u00e1n ad hoc y frecuentes, y si no habr\u00e1 que establecer unas ventanas donde realizarlos.<\/span><\/p>\n

Paso 4. Uso del Incremento.<\/h3>\n

La Gu\u00eda Scrum indica lo importante que es el buen uso los distintos artefactos (Product Backlog, Sprint Backlog e Incremento) para que el cliente tenga una visi\u00f3n clara de c\u00f3mo est\u00e1 yendo el proyecto en todo momento. Al ser un proyecto cerrado, el incremento cobra el papel de protagonista principal. <\/span>La clave es:<\/b> \u00bfC\u00f3mo mostramos el incremento de forma que no suponga burocracia adicional y nos sirva como artefacto \u00fanico para explicitar el estado global del proyecto?<\/b> Haciendo uso de la Sprint Review para mostrar un entregable mediante el cual los stakeholders puedan ver aspectos como el sprint goal, qu\u00e9 se ha hecho y qu\u00e9 no, el avance global, los bloqueos, los acuerdos e incluso para tener la aceptaci\u00f3n formal de un incremento de valor. T\u00edpicamente, aparte de lo que se muestre visualmente durante la Sprint Review para obtener feedback de los stakeholders, resulta de mucha ayuda realizar una presentaci\u00f3n donde se reflejen los aspectos mencionados anteriormente. Usar dicha presentaci\u00f3n como gu\u00eda cumple varios objetivos:<\/span><\/p>\n

    \n
  • Hacer transparente el avance y los bloqueos<\/span><\/li>\n
  • Mencionar los riesgos existentes para que se puedan paliar<\/span><\/li>\n
  • Explicitar el estado del proyecto, asumiendo los posibles retrasos si son causados por no ir a la velocidad esperada, pero paliando los posibles retrasos ocasionados por terceras partes o por el cliente.<\/span><\/li>\n
  • Que al cliente le sirva de entregable sin necesidad de recurrir a burocracia adicional<\/span><\/li>\n
  • M\u00e9tricas para demostrar el avance y la implicaci\u00f3n del equipo en la mejora continua<\/span><\/li>\n<\/ul>\n

    Paso 5. Cambios de alcance y acuerdos.<\/h3>\n

    Este paso solamente ser\u00eda necesario si el cliente quiere a\u00f1adir <\/span>nuevas funcionalidades o reemplazar existentes <\/b>a las acordadas en la propuesta. Estos son dos de los escenarios m\u00e1s probables:<\/span><\/p>\n

      \n
    • El cliente decide a\u00f1adir una funcionalidad. Se deber\u00e1 acordar que otra de la misma complejidad debe salir del alcance del proyecto<\/span><\/li>\n
    • El cliente decide incluir una funcionalidad pero se quiere mantener el mismo alcance. En este caso el equipo de desarrollo tomar\u00e1 nota de los requerimientos de la nueva funcionalidad y realizar\u00e1 una estimaci\u00f3n en esfuerzo. Se realizar\u00e1 una planificaci\u00f3n conjunta a\u00f1adiendo este esfuerzo en base al n\u00famero de iteraciones necesario para llevarla a cabo de acuerdo con la capacidad del equipo de desarrollo. Por \u00faltimo, se renegociar\u00e1 el alcance y el coste con el cliente de acuerdo a esa planificaci\u00f3n, involucrando a desarrollo de negocio.<\/span><\/li>\n<\/ul>\n

      Es importante recalcar que si no se realizan acciones similares a las descritas en este \u00faltimo paso, el riesgo de sobreesfuerzos e incumplimiento se incrementa exponencialmente. Dos l\u00edneas rojas que se deben paliar con una adecuada gesti\u00f3n de expectativas y negociaci\u00f3n con el cliente.<\/span><\/p>\n

      En conclusi\u00f3n, siguiendo estos consejos y realizando una adecuada gesti\u00f3n de las expectativas y de los riesgos, un proyecto cerrado bajo un framework \u00e1gil puede ser exitoso y no necesariamente precisar de otro tipo de reportes y reuniones extra.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

      Cuando, como agilistas, escuchamos las palabras \u201cproyecto cerrado\u201d, suele ocurrir que un escalofr\u00edo recorre nuestra espalda de arriba a abajo. Sin embargo, afrontar un proyecto cerrado usando un framework \u00e1gil no tiene por qu\u00e9 ser una terrible experiencia. En este art\u00edculo veremos c\u00f3mo, aplicando unos sencillos pasos, podemos echar a andar un proyecto y hacer […]<\/p>\n","protected":false},"author":134360170,"featured_media":34808,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_analysis_target_kw":"","_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","_crdt_document":"","content-type":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"_wpas_customize_per_network":false,"jetpack_post_was_ever_published":false},"categories":[303],"tags":[270,276],"class_list":["post-2048","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile-es","tag-metodologias","tag-scrum-es"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/keepler.io\/wp-content\/uploads\/2022\/09\/keepler-5-steps-implement-agile-framework-in-closed-project.jpg?fit=1280%2C452&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/p9CeZw-x2","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/posts\/2048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/users\/134360170"}],"replies":[{"embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/comments?post=2048"}],"version-history":[{"count":1,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/posts\/2048\/revisions"}],"predecessor-version":[{"id":2316,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/posts\/2048\/revisions\/2316"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/media\/34808"}],"wp:attachment":[{"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/media?parent=2048"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/categories?post=2048"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/keepler.io\/es\/wp-json\/wp\/v2\/tags?post=2048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}