Curso de desarrollo para asegurar la calidad del software
Con el término desarrollo ágil se agrupan una serie de buenas prácticas en el sector de la informática que ayudan a conseguir productos de calidad, adaptados a las necesidades de los clientes, y flexibles. En esta sesión veremos en qué consiste el desarrollo ágil.
Se entenderá qué es el desarrollo ágil, y se empezará a organizar el trabajo para emprender el desarrollo de un proyecto dentro de los términos del curso.
Se habrá asimilado en qué consiste el desarrollo ágil, y diferentes técnicas y herramientas usadas en ella, y se habrá comenzado a elaborar una épica de la cual surgirán las historias de usuario que se vayan a usar más adelante.
Hace ahora 20 años, el manifiesto ágil apostaba por una nueva manera de entender el desarrollo de software que aportara valor al cliente y que fuera ágil en la evolución del mismo, a la vez que proporcionara un entorno de trabajo más satisfactorio para quien lo desarrolla.
Este manifiesto tenía una serie de lemas, que en general se presentaban en contraposición al método de cascada o waterfall en el que las diferentes fases de desarrollo estaban aisladas y diferenciadas, y sólo se pasaba a producción al final de una larga cadena de departamentos aislados entre sí. Los principales lemas eran
Estos lemas se organizan en una serie de principios, doce en total. Pero de ellos vamos a extraer unos cuantos:
Estos principios deben guiar una metodología de trabajo. Para empezar, dice que hay que empezar por un problema a resolver, no con qué se quiere hacer. Las soluciones no pueden estar por delante del problema. Es decir, empezar por decir las herramientas que se van a usar para hacer algo es una forma de empezar algo que no va a ser simple, posiblemente no resuelva ningún problema, y sea difícil de probar si efectivamente funciona o no. Además, te indica que hay que organizar el trabajo en hitos, cada uno de los cuales implicará la publicación de un producto mínimamente viable, cada uno de los cuales se construirá sobre el anterior (o se agregará al anterior, según el problema). Sin un producto mínimamente viable, no se puede testear, y sin tener claro qué problema se quiere resolver, tampoco.
La calidad en el software empieza por el diseño, y este diseño incluye desde la modularización del problema, hasta el el uso de lenguaje, bibliotecas o estructuras de datos para trabajar. En informática rara vez hay una sola forma de hacer las cosas, y siempre hay que tomar decisiones técnicas que tendrán implicaciones en la evolución del software. Diseñar te va ayudar a escribir menos código, y el mejor código es el que no hay que testear, con lo que será código de más claridad. Un diseño flexible, por capas, que desacople diferentes partes del mismo, será también mucho más fácil de adaptar a diferentes circunstancias.
Y la búsqueda de mejores prácticas es esencial. La sintaxis y los manuales de referencia, y los tutoriales, rara vez se preocupan de guiar en la toma de una serie de decisiones técnicas. Te presentan una solución como ideal, o posiblemente la única posible. Sin embargo, llegar a esas soluciones implica una serie de decisiones, y es en las que hay que seguir las mejores prácticas, a todos los niveles: personales, empresas, industria.
Finalmente, se tiene que establecer una infraestructura para revisión de código. Lo más simple es establecer un estándar en el cual no se incorpore código a la rama principal directamente, sino que se haga siempre mediante pull requests. Pero adicionalmente, el desarrollo ágil pide la creación de una serie de reuniones, normalmente llamadas retro, que revisan el código que ha puesto en producción, y sugiere, siempre de forma constructiva, diferentes mejoras (que se incorporarán a un MVP futuro). El pasar tests frecuentemente para guardarse de posibles cambios en las dependencias también es una buena práctica, porque cerrarse en una versión determinada de todo puede ser eficiente a la hora de llevar a producción, pero las versiones de todo acaban siendo deprecadas y no quieres encontrarte en una situación en la cual tengas que reescribir todo por usar algo con posibles huecos de seguridad.
Los deseos de los clientes se capturarán en unas historias de usuario. Pero previo a las historias de usuario se tendrán que crear unas narrativas de los diferentes pasos que van a dar los diferentes tipos de usuario, una visión más global que, más adelante, se dividirá en fragmentos, historias de usuario, testeables y programables. Estas narrativas se llaman épicas. En general, como afirma en el enlace anterior:
Son historias de usuario demasiado extensas que se tienen que dividir en otras más pequeñas.
Y en este punto es donde es conveniente empezar a usar las mejores prácticas en el desarrollo ágil. Hay muchas formas de llevarlo a cabo, pero generalmente se agrupan en dos campos diferentes: los partidarios de usar scrum o los usuarios de kanban. Hay diferencias considerables, aunque los dos coinciden en el hecho de que se trabaje sistemáticamente con historias de usuario… y con un tablero. Los tableros permiten ver claramente en qué estado está el trabajo, y permite organizar las historias de usuario en diferentes columnas según el estado en el que estén. Las columnas clásicas son “Por hacer”, “haciéndose” y “hecho”, pero se pueden añadir otras columnas según el proyecto y el equipo: Diseño técnico, o Tormenta de Ideas. Estas últimas permiten interaccionar, a través de la herramienta que se elija (que, por simplicidad, es mejor que sea la que provee el gestor de código, por ejemplo, el de GitHub).
Estas columnas de “tormenta de ideas” se pueden usar, por ejemplo, para elaborar colaborativamente una épica. De esa épica, posteriormente, surgirán las diferentes historias de usuario. Pero eso lo veremos a continuación.
Como la metodología ágil aboga por presentar frecuentemente los resultados al cliente para ver si corresponde a sus expectativas, y cambiar o adaptar los requerimientos como resultados de las mismas, por lo que el desarrollo de un producto se debe hacer de forma incremental como una serie de entregables, cada uno de ellos apoyado en el anterior, con complejidad creciente y también un acercamiento creciente al cumplimiento de las historias de usuario (que, en muchos casos, no se podrán cumplir hasta el producto final).
Todo el desarrollo tiene que organizarse alrededor de estos entregables, como si fueran mojones en una carretera (o milestones). La metáfora es que uno va avanzando por la carretera, hasta llegar al destino final, que es un producto que satisface una cantidad aceptable de historias de usuario (y puede, por tanto, ser desplegado o subido a un app store o simplemente una versión nueva en una biblioteca).
Los milestones, por tanto, tienen que cumplir estas características
Como siempre se va a desarrollar para el siguiente PMV, todo desarrollo que se haga tendrá que fluir desde las historias de usuario, pasando por issues que lo desarrollen, hasta los productos mínimamente viables, que también incluirán a los pull requests que agrupen una serie de issues. Las historias de usuario, en general, podrán irse moviendo de un milestone al siguiente, según se vayan implementando, o simplemente dejarse fuera de los milestones; los issues siempre tendrán que estar en un milestone. Evidentemente, como se va avanzando por una carretera, en general sólo se estará trabajando en un PMV.
Por la misma razón, no es necesario planificar desde el principio todos los milestones que se vayan a desarrollar, sólo una cantidad suficiente para tener claro el horizonte al que se avanza; según se vaya desarrollando, se verá la necesidad de crear nuevos milestones, con releases que pueden ser internas (para el propio equipo) o externas (para el cliente).
Los PMVs pueden ser internos o externos. En general, son un punto de control para pararse y decir “¿Es esto lo que queremos/quiere el cliente?”. También es una forma tangible del desarrollo, puesto que es algo que se puede liberar o publicar. Por eso también se suele establecer un tag para el repositorio con cada uno de los PMVs, que establezcan claramente cuál era el punto en el desarrollo. A ese punto se puede volver, por ejemplo, para corregir errores o simplemente volver a él si algún PMV posterior no es viable.
Este whitepaper gratuito describe en general la metodología Scrum.
En esta actividad, que corresponde al hito 4 (es decir, que habrá que etiquetar con la versión 4, se tiene que seguir trabajando dentro del tablero para desarrollar el resto de las actividades y organizarlas. Aquí se empezarán a elaborar las historias de usuario, por ejemplo, a partir del wiki creado anteriormente.
Esta entrega se llevará a cabo, como el resto de las mismas, como un pull request al fichero de proyectos, tras añadir en el fork propio el nombre del proyecto y un enlace al repo, así como la versión.
Recordatorio: el tag deberá corresponder exactamente a la versión que se haya enviado.