Share
Desarrollo ágil o ágil: escuchamos estas palabras con más frecuencia en estos días. Pero, ¿sabemos realmente de qué se trata? ¿Cómo puede ayudarnos a ser más efectivos, mientras nos divertimos mucho desarrollando software? ¿Cómo podemos usarlo para comunicarnos con gente de negocios y hacer que esta comunicación sea fácil y constructiva para ambas partes??
Había un grupo de chicos muy talentosos y experimentados que estaban desarrollando un software serio. Estos desarrolladores observaron a otras compañías y equipos de desarrollo, y cómo sus procesos facilitaron su trabajo. Recopilaron sus observaciones para crear el Manifiesto Ágil. Y ellos dijeron:
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:
Es decir, mientras hay valor en los elementos de la derecha, valoramos los elementos de la izquierda más.
En este artículo, presentaré doce teorías y técnicas de desarrollo ágil. Este es solo el primer paso hacia el nuevo mundo del proceso de desarrollo de software..
Nuestra principal prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso, pero no completo. Esto significa que estamos desarrollando software y agregando al menos una característica, por iteración.
Imaginemos que queremos crear un motor de blog; Podríamos hacerlo usando el siguiente proceso:
Es un enfoque simple, pero el cliente ve el progreso real de su software y le brinda información inmediata sobre cada nueva función. Puede ser perfecto o requerir ajustes, pero puede responder rápidamente a los cambios: una situación en la que todos ganan.
Incluso al final del ciclo de desarrollo, los procesos Agile le permiten aceptar cambios para la ventaja competitiva del cliente.
El cliente desea que el proyecto termine rápidamente y lo más cerca posible del diseño dibujado en su mente. Esto se logra fácilmente simplemente escuchando sus comentarios y estando listo para los cambios. Si somos capaces de reaccionar rápidamente a los cambios en los requisitos, probablemente seamos la mejor elección que haya hecho nuestro cliente. Agile tiene que ver con la comunicación y los cambios. Hacemos las cosas como se nos pide, haciendo que el proceso de desarrollo de software termine más rápido. Esto se logra porque desarrollamos pequeñas piezas de software y un cambio en los requisitos realmente no nos afecta.
Debemos entregar actualizaciones de un par de semanas a un par de meses; cuanto más corto sea el tiempo, mejor.
Los clientes se sienten más seguros de nosotros y de nuestro producto a medida que se actualiza.
Según mis experiencias, los clientes se sienten más seguros de nosotros y de nuestro producto cuando se actualiza, lo cual es vital para nuestra relación con ellos. Otra ventaja es la retroalimentación de nuestro cliente; Permitiéndonos reaccionar cambiando clases, características, módulos o incluso la arquitectura. No nos despertaremos después de días o meses de trabajo, solo para ver que todo va a la basura. Consideremos una situación hipotética:
Se le ha pedido que cree un módulo que muestre un texto simple en un administrador de contenido. De repente, los requisitos cambian y debe agregar un formulario que debe enviar un correo electrónico a una dirección configurada. Además, el formulario debe ser personalizable para que el usuario pueda agregar nuevos campos y definir validadores. Entonces, básicamente tienes que olvidarte del requisito del texto original simple. ¿Qué tan pronto te gustaría saber sobre este cambio??
Si trabaja en un proyecto con su cliente y realiza entregas con frecuencia, conocerá estos cambios con mayor rapidez y los cambios como estos serán más fáciles para ambos..
Este puede ser el principio más difícil de acostumbrarse si ha estado desarrollando software en el antiguo estilo de cascada. Usted, como desarrollador, normalmente no habla el mismo idioma que su cliente, pero puede encontrar formas de mantener una comunicación significativa con ellos. Una de las mejores formas, en mi opinión, es describir todo con una historia simple que nos dice, el desarrollador, para quién es la característica, cuál es su responsabilidad y por qué la necesitamos en absoluto. Por supuesto, esto se hace más fácil cuanto más trabajamos con nuestro cliente. Otro enfoque útil es Behavior Driven Development (BDD), pero ese es un tema para un artículo diferente.
Ofrezca a las personas con las que trabaja el entorno y el apoyo que necesitan y, sobre todo, confíe en ellas para que hagan el trabajo.
Es importante proporcionar una atmósfera atractiva y todas las herramientas necesarias para crear un buen software. Las empresas pierden a sus mejores trabajadores principalmente porque realmente no se preocupan por ellos. La creencia de que los desarrolladores pueden escribir, probar e implementar software en algún servidor mediante un cliente FTP y editar archivos de producción en vivo se perdió en algún lugar. Si no has condenado esos viejos hábitos escolares, es mejor que lo hagas ahora..
Retener a los empleados es solo un beneficio; También puede desarrollar software mejor y más grande a un ritmo más rápido. Solo piénselo: escribir código reutilizable, pruebas automatizadas e implementación automatizada en cualquier servidor (entre otras cosas) puede afectar positivamente el tiempo de desarrollo. Por lo general, pensamos que ralentizamos un proyecto porque tenemos que aprender a usar herramientas útiles, como Jenkins, GIT, SVN, Gerrit, Behat, etc. Francamente, lo hacemos, pero luego podemos reutilizar esas herramientas y conceptos en proyectos futuros..
Es el método más eficiente y eficaz de transmitir información a nuestros clientes y al equipo de desarrollo..
¿Quién no se ha sentido abrumado o enojado al ver 6,255,384 correos electrónicos en su bandeja de entrada, porque su compañía exige que todas las conversaciones estén "en el papel"? Personalmente lo he visto algunas veces en mi vida, y no recomiendo trabajar en una empresa con tales hábitos. Las conversaciones cara a cara hacen que la comunicación sea más fácil y fluida, y nos permiten brindar más información. Podemos usar formas de comunicación verbales y no verbales para mostrar a nuestros compañeros lo que estamos pensando. Obviamente es más rápido que enviarse por correo electrónico.
Pero sobre todo, debemos confiar el uno en el otro; la confianza se gana fácilmente en un entorno que fomenta la comunicación cara a cara.
Esta es una de mis reglas favoritas; Nos permite trabajar libremente según nuestros propios procesos. Los desarrolladores de software son diferentes a otros empleados; tan naturalmente, deben ser tratados como tales. Desde mi experiencia personal, he aprendido a no juzgar a nadie del equipo de desarrollo mientras el trabajo esté terminado. Los desarrolladores no quieren crear software malo, y es menos probable que lo hagan si les permitimos trabajar de acuerdo con sus propias preferencias. Después de todo, el cliente está contento siempre que el trabajo que encargaron se haga correctamente; no les importa cómo se hizo.
Los procesos ágiles promueven el desarrollo sostenible, permitiendo mantener un ritmo constante por tiempo indefinido..
Las ventajas más conocidas de Agile (como la aceptación de requisitos cambiantes, la reacción rápida a la retroalimentación, etc.) son ampliamente apreciadas, pero la mejor ventaja, en mi opinión, es la capacidad de determinar con precisión la cantidad de tiempo que un proyecto o característica consumir. Después de algunas entregas, el equipo de desarrollo producirá el número de negocio más valioso: la capacidad. La capacidad es la cantidad de trabajo que el equipo puede hacer en una iteración. El número de capacidad es estable después de unas pocas iteraciones, y podemos evitar los plazos ridículos y las estimaciones de tiempo que se "sacan de encima" al presentar la oferta de nuestra compañía al cliente.
Muchas personas dicen que es imposible y la programación resulta ser más precisa. Estoy en desacuerdo; El horario asume que no habrá errores o retrasos inevitables..
Es un plan perfecto para un equipo perfecto, y eso no existe..
La atención continua a nuestra industria mejora la agilidad..
Se espera que evolucionemos y progresemos. Debemos seguir aprendiendo cada día, porque la industria se mueve a un ritmo tan rápido. A medida que mejoren tanto el hardware como el software, debemos mantenernos actualizados; de lo contrario, nos encontraremos perdidos en el "mar de lo nuevo" y será difícil volver a encarrilarnos.
La refactorización es la solución a la mayoría de los problemas. Al refactorizar constantemente (cuando sea necesario), podemos aplicar fácilmente nuevas técnicas y mejorar nuestra arquitectura de software.
Bill Gates dijo una vez:
Si tengo un trabajo complicado que hacer, se lo daré a la persona más perezosa que tengo, porque encontrarán la forma más sencilla de hacerlo..
La simplicidad es la regla de oro. Esto no significa que tenga que ser perezoso, pero sí significa que los desarrolladores complican su propio trabajo la mayoría de las veces. Si solo hace el trabajo que el cliente desea, sin funcionalidades y mejoras adicionales, su carga de trabajo se aligerará y logrará sus objetivos. En última instancia, eso es todo lo que le importa al cliente.
Las mejores arquitecturas, requisitos y diseños surgen de los equipos auto-organizados..
Solo somos humanos; no podemos predecir todo.
¿Alguna vez ha estado en una situación en la que desarrolló una aplicación grande y lenta, y después de pasar incontables horas frente a la pantalla escribiendo miles de líneas de código y leyendo artículos, tutoriales y libros, se sentó mirando algo malo (pero trabajando) código pensado, "ahora sé cómo escribirlo mejor"? Creo que todos hemos tenido estos momentos..
Aquí es donde entra en juego la undécima regla. Tenemos un equipo de desarrolladores que pueden seguir los principios de Test Driven Development (TDD), donde la refactorización es una parte del proceso. De alguna manera mágica, nuestro software es útil, hermoso, está bien escrito, probado y creado rápidamente. Solo somos humanos; no podemos predecir todo.
Todo esto proviene de la idea de un equipo autoorganizado, en el que cada miembro tiene un rol, no dado ni forzado, sino uno que surgió después de cierta cantidad de tiempo trabajando juntos. Esa es la belleza del trabajo en equipo..
A intervalos regulares, su equipo de desarrollo necesita reflexionar sobre cómo ser más efectivo y ajustar su comportamiento, según corresponda..
Esto puede requerir algunos ciclos de desarrollo, pero el equipo trabajará en perfecta armonía. Incluso agregar nuevas personas a este equipo no sería perjudicial. Un equipo de desarrollo Agile tiene que ver con hacer el trabajo. Si trabajan en un entorno amigable, encontrarán la "melodía del trabajo" y verán qué tan rápido puede ser el desarrollo de software..
Existen algunas metodologías derivadas de y basadas en principios ágiles. No los describiré todos porque cada metodología se puede cubrir en su propio artículo. Sin embargo, esbozaré algunos de los enfoques ágiles más conocidos. Una cosa para recordar es que no hay una sola metodología para gobernarlos a todos. Elija el que mejor se adapte a sus necesidades e incluso "configúrelo" para que se ajuste a sus requisitos específicos.
Creado por Ken Schwaber y Jeff Sutherland, SCRUM es un marco orientado a los negocios para administrar procesos de desarrollo de software. Hay muchos tipos diferentes de SCRUM; solo recuerde que el objetivo principal es trabajar con eficacia y eficiencia y no atenerse a las reglas.
Creado por Kent Back, XP es una lista de las mejores prácticas que los desarrolladores deben seguir al crear software. A menudo se llama "la extensión de SCRUM". Esta metodología de reglas orientadas al desarrollo nació debido a que SCRUM estaba orientado a los negocios..
Dos de los principios principales de Lean son: DALAP (Decidir lo más tarde posible) y DAFAP (Entregar lo más rápido posible). Personalmente recomiendo leer más sobre esta metodología, ya que puede ser muy útil..
Hay más metodologías en la familia Agile; Simplemente he referenciado las opciones más populares. Si decide utilizar Agile en su proceso de desarrollo, necesita saber cuáles son estas metodologías para elegir la más adecuada para usted..
¿Las técnicas ágiles realmente funcionan??
¿Realmente funcionan las técnicas ágiles, y las metodologías son tan mágicas como todos dicen? No siempre.
El problema que encontré en las compañías, donde los métodos Agile no dieron resultados (o incluso empeoraron las cosas), fue una metodología mal elegida y la falta de convicción entre sus usuarios (miembros de negocios, el equipo de desarrollo, etc.). Es por eso que, en opinión de este escritor, debe asegurarse de que todos los involucrados en el proceso entiendan las reglas y sepan "de qué se trata".
Gracias por leer!
Accentsconagua