Agile Methodology

Top mitos ágiles y conceptos erróneos en la administración ágil de proyectos – Yodiz Project Management Blog


 myths_and_misconceptions_in_agile_project_management
Guest Blogger: Danés Wadhwa

 danish-wadhwa

Danés Wadhwa es un pensador estratégico y un profesional de TI. Con más de seis años de experiencia en la industria del marketing digital, es más que un individuo orientado a los resultados. Está bien versado en proporcionar soporte técnico de alto nivel, optimizar ventas y automatizar herramientas para estimular la productividad de las empresas.

Además del hecho de que la mayoría de las compañías de software afirman implementar metodologías ágiles, todavía hay conceptos erróneos y mitos comunes sobre Agile que son necesarios para desacreditar, ahora y siempre.

Esto no solo ayudaría a los que ya están implementando ágiles para evitar trampas comunes, sino que hará que las empresas comprendan más ágilmente, se den cuenta de sus beneficios y acepten el cambio y, en última instancia, mejoren el proceso de creación de prototipos. Incluso puede planear tomar un entrenamiento ágil para aprender más de varios organismos de certificación ágil para seguir los principios del manifiesto Ágil de la mejor manera.

Comencemos con los mitos comunes de ágil.

1. Los proyectos ágiles no dan estimaciones presupuestarias

Al igual que en las metodologías de desarrollo tradicionales como Waterfall, cuando los proyectos están encerrados en cajas, dada la lista de requisitos junto con sus estimaciones, el cronograma y los presupuestos se derivan de estas estimaciones por completo.

Dado que el enfoque del modelo de cascada de extremo a extremo de desarrollo y entrega, la estimación se proporciona sin entrar mucho en detalles, esas estimaciones se proporcionan al comienzo de cada fase. Entonces, el riesgo es que, si esa estimación es incorrecta, que normalmente es el caso, normalmente el ciclo de iteración es realmente largo. Como las estimaciones no pueden ser totalmente precisas, si el final medio de cada iteración necesita rehacerse algo o ampliar el alcance, se tarda más en volver a enfocarse y reestimarse, lo que hace que los proyectos demoren más que si se utilizaran metodologías ágiles. Es más fácil planificar los detalles para las próximas semanas y luego durante algunos años. Esa es la principal diferencia entre Agile y Waterfall cuando se llega a la estimación.

Scrum y Extreme Programming son metodologías ágiles que usan el concepto de tiempo-boxeo, ya que al hacerlo se pueden optimizar los retrasos, la planificación puede ser detallada, ya que el enfoque es muy corto , tendemos a ver las cosas más de cerca y hacerlo mejor, incluso si no lo hacemos por completo, lo que hacemos está alineado con el objetivo.

Esto lleva al hecho de que las estimaciones son dignas de no solo para la tarea da la vuelta al tiempo, pero también proporciona la finalización general de la meta al mirar un trozo más pequeño de cajas de tiempo.

Otros beneficios que las estimaciones proporcionan, es que los equipos trabajan durante un período fijo predefinido (de una a cuatro semanas), logrando el máximo en ese período, según sea posible.

Los equipos pueden usar estimaciones para calcular cuántos sprints se necesitan para desarrollar todos los requisitos, pero cada sprint tiene un costo fijo. Esto facilita el proceso de presupuestar.

El equipo ágil después de algunos sprints puede utilizar la velocidad promedio del equipo, para tener visibilidad sobre el futuro con respecto a los lanzamientos o entregables más grandes, lo que brinda una poderosa herramienta para que el propietario del producto tenga algunas estimaciones sobre cuánto tiempo Para entregar una característica / producto, cuál será el costo / presupuesto en función de la cantidad de sprints necesarios para completar una función / producto.

2. Agile no es para proyectos de oferta fija

El proyecto grande fijo es donde el producto / servicio debe entregarse según el costo o presupuesto acordado.
Agile encaja bien con este tipo de proyectos, debido a las metodologías ágiles características de tener el corto y retroalimentación rápida con el cliente, ya que el costo es fijo, por lo que debemos asegurarnos de que todo en lo que trabaje el equipo de scrum esté dentro del alcance acordado. La demostración regular de sprint, la estrecha cooperación del propietario del producto con el cliente, ayuda a reducir la brecha que permite al equipo enfocarse completamente en el producto.

En un proyecto ágil si es de naturaleza de plazo fijo, la responsabilidad del propietario del producto es aún más desafiante. porque (s) necesita asegurarse de que los requisitos se prioricen correctamente en orden y el alcance no cambie.

3. Agile = Sin Compromiso

Uno de los mitos populares es que los equipos ágiles no se comprometen ya que generalmente hay de 6 a 8 desarrolladores trabajando hasta que alguien confirma que "¡él o ella está listo!" En contraste, los equipos ágiles exitosos son transparentes y realistas cuando se trata de sus promesas.

XP y Scrum tienen un concepto de retraso acumulado que incluye la lista de elementos que se desarrollarán durante un sprint. Aunque la versión más reciente de Scrum se retrasa por la solidez del compromiso, por lo general, para algunos equipos scrum, los elementos del sprint acumulado se tratan como un contrato: el equipo entregará todos los elementos que haya cometido en ese sprint solamente.

Sin embargo XP permite el cambio si el equipo acepta colectivamente y el ítem que debe reemplazarse aún no se ha iniciado. En scrum y XP, el aplazamiento (no completar un artículo que se prometió) no se trata a la ligera y se toma como una ocurrencia excepcional. Esta cadencia regular y el compromiso de ofrecer software en pequeños incrementos generan confianza entre los miembros del equipo y otras partes involucradas, como usuarios, clientes y partes interesadas. Los equipos que siguen las últimas enseñanzas sobre el scrum no prometen en el alcance del sprint. Esto elimina la idea de boxeo de alcance ya que es un juego peligroso de jugar.

El equipo de Scrum debe centrarse en bucles de retroalimentación rápidos, colaboración y comunicación y transparencia constantes para implementar ágilmente con éxito. Por lo general, cuando los equipos son comunicativos, la demanda de un compromiso inamovible se reduce. La confianza resultante y la colaboración de los equipos anulan la necesidad obsoleta de compromisos. En comparación con los proyectos de Waterfall que se basan en estimaciones y los equipos no entregaron lo que prometieron.

4. Los proyectos ágiles no involucran a los analistas de negocios

Scrum no utiliza el término de analista de negocios y en su lugar se refiere al propietario del producto. Esto lleva a un único punto de contacto para el equipo cuando tienen preguntas sobre cualquier cosa. Esto no significa que los analistas comerciales no estén incluidos en los proyectos ágiles. Por el contrario, el conocimiento específico del dominio que tienen los analistas de negocios es un activo esencial para el propietario del producto. Estos expertos ayudan a componer los elementos atrasados ​​y ayudan a concluir la prioridad y el orden.

XP no inscribe un solo rol como el propietario del producto de Scrum, sino que toma analistas comerciales y clientes como un equipo colaborativo que decide la prioridad y el orden de los elementos atrasados. Los equipos se pueden dividir en equipos de características cuando escala proyectos ágiles. Estos equipos seguirán dependiendo de los usuarios, los analistas de negocios y los clientes para crear un retraso para cada una de estas características y el retraso acumulado completo del proyecto.

You Might Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Powered by themekiller.com