La metodología ágil existe desde hace más de 20 años, y varios marcos ágiles han permitido la colaboración, reducido el desperdicio y acortado drásticamente el tiempo desde la visión hasta la realidad para una miríada de proyectos de software. No es una panacea, pero la metodología ágil está casi universalmente aceptada como la plataforma preferida para un desarrollo de software eficiente. Con algunos ajustes sorprendentemente sencillos, los principios del desarrollo ágil de software pueden aportar el mismo enfoque y eficiencia a muchos problemas empresariales cotidianos.
En 2001, los 17 autores del Manifiesto Ágil expusieron en detalle los valores y principios de Agile. Vale la pena leerlo de primera mano, pero la esencia es que cierta estructura es importante, pero demasiado la estructura a menudo ralentiza las cosas. Los valores generales que desarrollaron los autores estaban destinados al desarrollo de software, pero hay algunas verdades fundamentales que podemos aplicar a las empresas en general.
El primer valor es priorizar los individuos y las interacciones por encima de los procesos y las herramientas. Nadie (incluidos los autores del manifiesto) dice que los procesos y las herramientas no sean valiosos, pero es fácil perder de vista lo que las personas realmente necesitan cuando confiamos demasiado en procesos y herramientas rígidos. Interactuar con las personas y tomarse el tiempo necesario para comprender realmente su perspectiva es fundamental para prácticamente todo lo relacionado con los negocios.
El Manifiesto también valora software funcional sobre documentación completa. Bien, tal como está escrito, ese es bastante específico para el desarrollo de software, pero si podemos permitir cierta flexibilidad (como fomenta la metodología ágil), cambiar «software» por «proceso» abre un mundo de posibilidades. El principio aquí es que, en lugar de pasar semanas (o meses) creando una especificación completa que explique todo con un detalle insoportable, obtendremos un mejor resultado si empezamos por crear algo (una pieza de software, un proceso, un prototipo) para que podamos probarlo y ver cómo funciona. Agile llama a esto el producto mínimo viable (MVP). Una vez que construyamos el MVP y veamos cómo funciona, podemos repetir la solución para mejorarla cada vez. No te preocupes, en algún momento, desarrollaremos la documentación adecuada; al igual que ocurre con los procesos y las herramientas, la documentación es importante... pero no tan importante.
Lo siguiente es valorar colaboración con los clientes sobre la negociación de contratosn. Un mentor mío me dijo una vez: «Si tienes que usar el contrato para gestionar una relación con un cliente, en realidad no tienes una relación». Esto se aplica a los clientes y partes interesadas internos y externos. Todos los problemas tienen matices de gris, por lo que si dedicas todo tu tiempo al blanco y negro de tu contrato, no te estás concentrando en entender el problema.
El valor final es responder al cambio siguiendo un plan. En otros tiempos, recuerdo los proyectos en los que pasábamos semanas, a veces incluso meses, reuniéndonos con las partes interesadas y desarrollando requisitos detallados (muchos tenían más de 100 páginas). Usamos esos documentos para desarrollar un plan de proyecto y más documentos de diseño técnico. Luego pasamos a las pruebas de desarrollo, control de calidad y aceptación por parte de los usuarios y, finalmente (entre 6 y 9 meses después), entregamos nuestra solución. Fue una maravilla; todo el mundo quedó encantado y todos (incluido el cliente) estuvimos de acuerdo en que la solución era exactamente lo que el cliente había pedido.
El problema, con una consistencia asombrosa, era que lo que el cliente pidió hace un año no era lo que su empresa necesitaba ahora. Así que, tan pronto como terminó la efímera celebración, empezamos a trabajar para cubrir la brecha entre la solución que habíamos desarrollado y la solución que el cliente necesitaba ahora. Este es otro ejemplo de software, pero se aplica por igual a muchas áreas de la empresa. Las empresas modernas avanzan con demasiada rapidez como para pasar meses elaborando un plan que quedará obsoleto antes de que el proyecto esté terminado.
La metodología ágil es un tema enorme y, aunque su esencia ha sobrevivido al paso del tiempo, sigue evolucionando. Los valores de los que he hablado dan lugar a un conjunto de principios fundamentales y, a partir de esos principios, se han desarrollado diversas formas de metodología ágil para adaptarse a casos de uso y estilos de trabajo específicos. Fuera del mundo de la gestión de proyectos y el desarrollo de software, hay mucho más de lo que la mayoría de nosotros necesitamos saber. Sin embargo, estos valores intemporales pueden ser una guía útil; la próxima vez que trabajes en un proyecto (ya sea de software, ingeniería de procesos, reparación de un flujo de trabajo o simplemente la solución de un problema persistente), lee una o dos páginas del manifiesto sobre la metodología ágil.
La metodología ágil existe desde hace más de 20 años, y varios marcos ágiles han permitido la colaboración, reducido el desperdicio y acortado drásticamente el tiempo desde la visión hasta la realidad para una miríada de proyectos de software. No es una panacea, pero la metodología ágil está casi universalmente aceptada como la plataforma preferida para un desarrollo de software eficiente. Con algunos ajustes sorprendentemente sencillos, los principios del desarrollo ágil de software pueden aportar el mismo enfoque y eficiencia a muchos problemas empresariales cotidianos.
En 2001, los 17 autores del Manifiesto Ágil expusieron en detalle los valores y principios de Agile. Vale la pena leerlo de primera mano, pero la esencia es que cierta estructura es importante, pero demasiado la estructura a menudo ralentiza las cosas. Los valores generales que desarrollaron los autores estaban destinados al desarrollo de software, pero hay algunas verdades fundamentales que podemos aplicar a las empresas en general.
El primer valor es priorizar los individuos y las interacciones por encima de los procesos y las herramientas. Nadie (incluidos los autores del manifiesto) dice que los procesos y las herramientas no sean valiosos, pero es fácil perder de vista lo que las personas realmente necesitan cuando confiamos demasiado en procesos y herramientas rígidos. Interactuar con las personas y tomarse el tiempo necesario para comprender realmente su perspectiva es fundamental para prácticamente todo lo relacionado con los negocios.
El Manifiesto también valora software funcional sobre documentación completa. Bien, tal como está escrito, ese es bastante específico para el desarrollo de software, pero si podemos permitir cierta flexibilidad (como fomenta la metodología ágil), cambiar «software» por «proceso» abre un mundo de posibilidades. El principio aquí es que, en lugar de pasar semanas (o meses) creando una especificación completa que explique todo con un detalle insoportable, obtendremos un mejor resultado si empezamos por crear algo (una pieza de software, un proceso, un prototipo) para que podamos probarlo y ver cómo funciona. Agile llama a esto el producto mínimo viable (MVP). Una vez que construyamos el MVP y veamos cómo funciona, podemos repetir la solución para mejorarla cada vez. No te preocupes, en algún momento, desarrollaremos la documentación adecuada; al igual que ocurre con los procesos y las herramientas, la documentación es importante... pero no tan importante.
Lo siguiente es valorar colaboración con los clientes sobre la negociación de contratosn. Un mentor mío me dijo una vez: «Si tienes que usar el contrato para gestionar una relación con un cliente, en realidad no tienes una relación». Esto se aplica a los clientes y partes interesadas internos y externos. Todos los problemas tienen matices de gris, por lo que si dedicas todo tu tiempo al blanco y negro de tu contrato, no te estás concentrando en entender el problema.
El valor final es responder al cambio siguiendo un plan. En otros tiempos, recuerdo los proyectos en los que pasábamos semanas, a veces incluso meses, reuniéndonos con las partes interesadas y desarrollando requisitos detallados (muchos tenían más de 100 páginas). Usamos esos documentos para desarrollar un plan de proyecto y más documentos de diseño técnico. Luego pasamos a las pruebas de desarrollo, control de calidad y aceptación por parte de los usuarios y, finalmente (entre 6 y 9 meses después), entregamos nuestra solución. Fue una maravilla; todo el mundo quedó encantado y todos (incluido el cliente) estuvimos de acuerdo en que la solución era exactamente lo que el cliente había pedido.
El problema, con una consistencia asombrosa, era que lo que el cliente pidió hace un año no era lo que su empresa necesitaba ahora. Así que, tan pronto como terminó la efímera celebración, empezamos a trabajar para cubrir la brecha entre la solución que habíamos desarrollado y la solución que el cliente necesitaba ahora. Este es otro ejemplo de software, pero se aplica por igual a muchas áreas de la empresa. Las empresas modernas avanzan con demasiada rapidez como para pasar meses elaborando un plan que quedará obsoleto antes de que el proyecto esté terminado.
La metodología ágil es un tema enorme y, aunque su esencia ha sobrevivido al paso del tiempo, sigue evolucionando. Los valores de los que he hablado dan lugar a un conjunto de principios fundamentales y, a partir de esos principios, se han desarrollado diversas formas de metodología ágil para adaptarse a casos de uso y estilos de trabajo específicos. Fuera del mundo de la gestión de proyectos y el desarrollo de software, hay mucho más de lo que la mayoría de nosotros necesitamos saber. Sin embargo, estos valores intemporales pueden ser una guía útil; la próxima vez que trabajes en un proyecto (ya sea de software, ingeniería de procesos, reparación de un flujo de trabajo o simplemente la solución de un problema persistente), lee una o dos páginas del manifiesto sobre la metodología ágil.
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.png)
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.jpeg)
