Definición de ágil
Luke ha sido contratado recientemente como director de proyectos en una nueva empresa que busca cambiar la forma en que realizan la gestión de proyectos. Ha sido contratado porque tiene experiencia con Agile , un enfoque que es incremental e iterativo, desglosando los componentes primarios del proyecto de alcance y cronograma para completar porciones más pequeñas de trabajo en ciclos repetidos más frecuentes. El objetivo es ser más flexible y receptivo al cambio.
Agile intenta ser una alternativa a las metodologías tradicionales de gestión de proyectos. Estos son típicamente lineales y requieren que cada fase del proyecto, como la documentación de requisitos, esté completa antes de que pueda comenzar otra fase, como el desarrollo. Esto puede hacer que las metodologías tradicionales sean ineficientes y llenas de documentos, cosas que Agile intenta remediar.
Los ejecutivos de la nueva compañía de Luke están en su mayoría a bordo, pero les preocupa que, dado que se sabe que Agile no tiene mucha documentación, no involucrará documentación en absoluto. Luke les asegura que Agile todavía implica documentación.
De hecho, en el Manifiesto Agile , que detalla los principios fundamentales de Agile, la documentación completa se identifica explícitamente como algo de valor. Sin embargo, se le da un valor aún mayor al software que funciona. Cuando existe una compensación, un producto terminado y utilizable se considera más importante que una gran cantidad de documentación, pero idealmente se puede lograr un equilibrio entre ambos.
Metodología de documentación
Para ayudar a su nueva empresa a comprender la documentación ágil, Luke se centra primero en la metodología o en cómo se aborda la documentación en Agile. El enfoque incremental e iterativo utilizado en la gestión ágil también se aplica a la documentación. Utilizando un enfoque incremental, la documentación se completa en cantidades más pequeñas, en lugar de todo a la vez. Utilizando un enfoque que también es iterativo, el proceso de trabajar en la documentación es continuo y se repite a lo largo del proyecto.
¿Qué requisitos se necesitan para acceder a la universidad en España?
El pensamiento detrás de esta metodología es simple: la documentación más valiosa es lo que realmente se construye. Luke explica además esto utilizando el concepto ágil de producto mínimo viable (MVP) , que involucra suficiente producto terminado para proporcionar valor y obtener comentarios de los usuarios. En general, el objetivo es encontrar el punto que maximiza la compensación entre el valor del producto y el esfuerzo que implica producirlo. Este mismo concepto de «lo suficiente» se aplica a la documentación.
Las metodologías tradicionales que completan toda la documentación a la vez al inicio del proyecto deben cubrir todo lo que se podría hacer dentro del proyecto. Rara vez se completa todo de este proceso original. Además, hay requisitos que surgen durante el proyecto a medida que las partes interesadas aprenden más. Para los elementos que no se completan, se pierde el tiempo dedicado a documentarlos. Los elementos que surgen durante el proyecto simplemente no se conocen al principio. La documentación es más valiosa cuando se realiza en cantidades más pequeñas y se repite a lo largo del proyecto.
Requisitos y ejemplos
Lo último que Luke revisa con su nueva empresa para ayudarlos a comprender la documentación Agile es en qué consisten sus requisitos. Utiliza uno de sus proyectos recientes como ejemplo. Uno de los últimos proyectos en los que trabajó la empresa fue un portal interno para empleados. La principal limitación era una fecha límite estricta, que era una de las razones por las que el producto final se veía bastante diferente de lo que se documentaba originalmente para los requisitos. Este no habría sido el caso con Agile; veamos por qué repasando los dos tipos principales de documentación en los que se basa.
Historias de usuarios / Criterios de aceptación
En Agile, los requisitos que tienen la máxima prioridad se definen y documentan primero para que el equipo pueda trabajar en ellos primero. La forma principal de requisitos son las historias de usuario , que son una descripción breve y de alto nivel de la funcionalidad deseada para un usuario específico. La estructura implica describir a un usuario, su funcionalidad deseada y la razón por la que se necesita la funcionalidad. Las historias de usuario van acompañadas de criterios de aceptación , que miden si la historia de usuario se ha logrado al detallar acciones y resultados específicos.
Para el portal de empleados, la máxima prioridad era la página de inicio. El componente principal de esta página era el calendario de la empresa, que muestra los próximos eventos de la empresa. Como historia de usuario, Luke habría documentado esto como: «Como empleado, quiero ver un calendario del mes actual con eventos para saber lo que está por venir». El criterio de aceptación que lo acompañaría sería: «Cuando veo la página de inicio, veo un calendario para el mes actual». Otro sería, «Cuando hago clic en una fecha del calendario, veo una ventana emergente con los eventos específicos del día seleccionado».
Formación de una Corporación: Definición, requisitos y proceso
Épicas / Características
Para los requisitos que no son una prioridad tan alta o no se sabe lo suficiente como para documentar todo lo necesario, existe otra forma de documentación ágil. Esto se conoce como una epopeya o característica , que es de un nivel extremadamente alto y relativamente indefinido. Solo cuando las epopeyas o las características se convierten en prioridades más altas, se dividen en historias de usuario. Si resulta que la característica épica / no se convierte en una prioridad máxima en ningún momento dentro del proyecto, no necesita ningún trabajo adicional.
Debido a la fecha límite estricta, hubo una serie de componentes que no se completaron para el proyecto del portal de empleados, como páginas individuales para cada unidad de negocio dentro de la empresa. Más adelante en el proyecto, se consideró que no eran necesarios, a pesar de que se dedicó tiempo a redactar todos los requisitos. Al usar Agile, Luke habría capturado esto como una característica épica, simplemente documentando ‘páginas de unidades de negocios’. Este marcador de posición es todo lo que se necesita para estos requisitos. Si se convirtieran en una prioridad, se definirían y documentarían mejor. Sin embargo, si estos no se convirtieran en una prioridad, no se realizaría ningún trabajo adicional.
Resumen de la lección
Agile intenta proporcionar una alternativa a las metodologías tradicionales utilizando un enfoque incremental e iterativo que le permite ser más flexible y receptivo al cambio, en lugar de estar impulsado por procesos y con mucha documentación. Sin embargo, como se describe en el Manifiesto Agile, Agile aún valora la documentación. La metodología que Agile utiliza para la documentación se basa en el enfoque incremental e iterativo de Agile y también se basa en la metodología general de buscar un producto mínimo viable (MVP).. El MVP es el punto que maximiza la diferencia entre el valor de algo y el esfuerzo que implica. El resultado final es que la mayor parte del esfuerzo invertido en la documentación en Agile es para requisitos que realmente se construyen, en lugar de una lista completa de requisitos, la mayoría de los cuales no se construirán. La forma detallada de los requisitos ágiles son historias de usuarios que identifican la funcionalidad deseada acompañada de criterios de aceptación , que proporcionan más detalles de la funcionalidad. Para trabajos de menor prioridad, los requisitos adoptan la forma de épicas o características , que funcionan como marcadores de posición hasta el punto en que los requisitos deben ser más extensos.
Explora más sobre este tema
Selecciona un tema y sigue aprendiendo...
