Uno de los elementos más usados son las variables en Javascript. Podemos describir a las variables en Javascript como cajas para guardar información, las cuales etiquetamos para que podamos encontrar esa información fácilmente. Esta etiqueta es el nombre de la variable y la cajita es el espacio utilizado en la memoria RAM.
Variables y constantes, cajas que guardan información
Así son las variables en Javascript, y de hecho en cualquier lenguaje de programación. También puedes almacenar cualquier tipo de dato, ya sean números, cadenas de texto, funciones o cualquier tipo de objeto.
Existen dos maneras de declarar una variable. Una es usando let y la otra usando var.
//Variables de tipo Stringvar nombre ='Jaime';let apellido ="Cervantes"
La forma var es la que siempre ha existido desde el origen del lenguaje, después en el 2015 apareció let con la finalidad de mitigar ciertas deficiencias de var. Por esta razón, la recomendación es usar let, de todos modos es importante conocer bien var debido a que te encontrarás con mucho código que use aún var.
¿Cómo se usan las variables en Javascript?
El nombre o identificador de una variable, no puede iniciar con un número, debe iniciar con alguna letra (incluyendo _ y $), y además Javascript es sensible a mayúsculas y minúsculas. No es lo mismo nombre y Nombre, estas son dos variables diferentes.
Las variables se definen de dos formas:
Con un solo let:
let nombre ='Jaime', apellidoPaterno ='Cervantes', apellidoMaterno ='Velasco';
Un solo var:
var nombre ='Jaime', apellidoPaterno ='Cervantes', apellidoMaterno ='Velasco';
Ahora con un let por cada variable:
let nombre ='Jaime';let apellidoPaterno ='Cervantes';let apellidoMaterno ='Velasco';
Con un var por cada variable.
var nombre ='Jaime';var apellidoPaterno ='Cervantes';var apellidoMaterno ='Velasco';
En el ejemplo anterior se define variables de tipo string (cadenas de texto), pero recuerda que puedes almacenar cualquier tipo de dato.
Es recomendable poner cada variable en su propia linea porque es más rápido de entender para el “tú” del futuro y tus compañeros que no han tocado tu código. Por ejemplo NO definas las variables así:
let nombre ='Jaime', apellidoPaterno ='Cervantes', apellidoMaterno ='Velasco'; edad =32, sexo ='H'
Probemos con números.
let edad =32.9;let hijos =1;
var edad =32.9var hijos =1;
Los datos boleanos solo almacenan falso o verdadero.
let esHombre =true;let esAlto =false;
var esHombre =true;var esAlto =false;
Como su nombre lo dice, su valor puede ser variable, por lo tanto puedes reasignar un nuevo valor a tu variable:
var nombre ='Jaime';nombre ='Pepito';nombre ='Menganito';console.log(nombre);// 'Menganito'
Ámbitos de las variables en Javascript, let vs var
La principal diferencia entre las variables definidas con let y var es el ámbito que alcanzan cuando se declaran:
Con let tienes ámbito de bloque {}.
Con var tienes ámbito de función function () pero no de bloque.
Ejemplo del ámbito de bloque.
if (true) {letnombre='jaime';}console.log(nombre);// Uncaught ReferenceError: nombre is not defined
Porque let tiene ámbito de bloque, al querer acceder a la variable nombre Javascript muestra:
Uncaught ReferenceError: nombre is not defined
Tratar de usar ámbito de bloque con var.
if (true) {varnombre='Jaime';}console.log(nombre);// 'Jaime';
En este ejemplo la variable nombre si puede ser accedida desde afuera de los bloques, esto es porque no está dentro de ninguna función.
Ahora vamos a declarar la variable con var dentro de una función.
functionsetearNombre(){varnombre='Jaime';}setearNombre();console.log(nombre);// Uncaught ReferenceError: nombre is not defined
Vamos a ver que pasa con let cuando intentamos usar ámbito de función.
functionsetearNombre(){letnombre='Jaime';}setearNombre();console.log(nombre);// Uncaught ReferenceError: nombre is not defined
Si definimos una variable con let dentro de una función, tampoco podemos acceder a ella desde afuera, porque la propia definición de la función usa bloques {}.
Constantes en Javascript
Las constantes son de igual forma que las variables, cajitas etiquetadas para guardar información, con la única diferencia que no se le puede reasignar algún otro valor.
const nombre ="Jaime";nombre ="Pepito";// Uncaught TypeError: Assignment to constant variable
No nos olvidemos de declarar cada constante en su propia linea para mejorar la lectura de nuestro código.
const nombre ="Jaime";const apellidoPaterno ="Cervantes";const apellidoMaterno ='Velasco';
const nombre ='Jaime', apellidoPaterno ='Cervantes', apellidoMaterno ='Velasco';
Mismas reglas que las variables con let
Las constantes siguen las mismas reglas de ámbito de bloque que las variables en Javascript con let.
Así como let, const tiene ámbito de bloque, por lo que si se define una variable con var y tiene el mismo nombre de una constante, se lanzara el siguiente error:
{constnombre="Jaime";varnombre="Pepito";// Uncaught SyntaxError: Identifier 'nombre' has already been declared}
Constantes en javascript de solo lectura y mutables
Las constantes son de solo lectura, es por eso que no se les puede reasignar un valor. Aun así estos valores guardados siguen conservando el comportamiento de su tipo de dato.
Por ejemplo, si se crea una constante de un objeto, si se pueden cambiar las propiedades de ese objeto.
Un objeto literal en JavaScript no es más que un conjunto de valores identificados con un nombre o clave, como lo siguiente:
const jaime ={nombre:"Jaime",apellidoPaterno:"Cervantes",apellidoMaterno:"Velasco"};jaime.nombre ="Pepito";// todo bien, se puede cambiar una propiedadjaime ={};// Uncaught Type Error: Assigment to constant variable
La referencia al objeto es de solo lectura, pero no quiere decir que el valor sea inmutable. Como se ve en el ejemplo, se puede cambiar la propiedad, pero no reasignar un nuevo valor a la constante jaime como podemos comprobar en la última línea del ejemplo.
¿Cómo nombrar a las variables y constantes en Javascript?
Cualquier tonto puede escribir código que una computadora pueda entender. Los buenos programadores escriben código que los humanos pueden entender.
Martin Fowler
El objetivo principal del nombre de variables y constantes es entender inmediatamente que es lo que estamos guardando en ellas. Es importante describir correctamente el contenido de las variables, porque así le facilitamos la vida a la siguiente persona que necesite leer y modificar nuestro código.
Esta siguiente persona muy a menudo eres “tú” del futuro, y al menos que seas un robot, no podrás recordar cada detalle de tu código.
La mayor parte del tiempo utilizado por un programador es para leer y entender código, no queremos gastar mucho tiempo descifrando el contenido de ellas, como programadores somos más contentos creando cosas nuevas.
Por esta razón no debe sorprendernos la importancia en el nombramiento de nuestras variables y constantes, es una de las mejoras maneras para no malgastar nuestro tiempo y el tiempo de nuestros colegas.
Recomendaciones:
Dedica el tiempo suficiente para nombrar una variable. Es como organizar tu cuarto, entre más ordenado más rápido será encontrar el otro calcetín (me pasa mucha cuando no ordeno el mío) xD.
El nombre debe ser muy semántico y explicar el contexto del mismo. Evitar nombres como data o info porque no dicen mucho del contexto, es obvio que son datos e información, pero ¿Para qué? o ¿Qué?.
Ponte de acuerdo con tus colegas sobre como nombrar las variables, en especial aquellas que tiene mucha relación con el negocio. Por ejemplo para los datos de registro de un usuario, puede ser “registroDeUsuario”, “registroDeCliente”, “registroDeVisitante”, las tres formas pueden ser válidas (depende mucho el contexto), pero es mejor seguir una convención a través de un acuerdo.
Evita los nombres muy cortos como “u1”, “a2”, “_”, “_c”
Evita las abreviaciones, prefijos, sufijos e infijos. Estos son difíciles de entender. Por ejemplo pmContenido, ¿Qué es “pm”?
Si la variable o constante tiene un ámbito muy pequeño, es decir, es utilizada en líneas cercanas, entonces el nombre puede ser corto.
Si la variable o constante se utiliza en un ámbito grande, es decir, se hace referencia a ella a una distancia de muchas líneas, entonces el nombre debe ser muy descriptivo, y por lo tanto es normal que pueda ser largo.
El corazón ágil y el manifiesto ágil. Siempre he pensado que las cosas simples son las mejores de implementar, permiten avanzar y aprender. Y tal vez el manifiesto ágil no es tan claro y fácil de entender. Además muy a menudo las metodologías, técnicas y frameworks complican las cosas, o simplemente uno como estudiante de ellas pierde el enfoque principal.
La base del manifiesto ágil son principios humanos, los cuales funcionan como la masa rocosa en la que se edifica el castillo de la agilidad.
Para cualquier aprendizaje es necesario tener un base sólida, una esencia. La masa rocosa en la que se pueda edificar un castillo. No la masa de arena en la que se construya una casa y a la primera llovizna se derrumbe.
Y te preguntarás, ¿Cuál es mi masa rocosa, fuerte, sólida, que me hará conseguir lo que quiera? Como por ejemplo un producto exitoso y la felicidad de mis compañeros o empleados.
Es muy sencillo, necesitamos mantener las cosas simples (principio ágil), y tu masa rocosa son los principios humanos universales, estos principios nacen de algo lamentablemente despreciado en algunos entornos laborales, tu masa rocosa es el amor. El cual tiene una relación muy estrecha con el manifiesto ágil.
Si, ya sé lo que estás pensando, que soy demasiado cursi, pero piensa por un instante. Cuando amas lo que haces, con gusto estás dispuesto a hacer las cosas lo mejor posible. A colaborar con tus compañeros para resolver problemas y no dudas en ayudar en cualquier problema que se les presente.
Justicia, respeto y honestidad
Si tienes amor en tu corazón, respetaras a los demás, respetaras su valioso tiempo, su individualidad, pensaras en ser justo, trataras de ponerte en los zapatos de ellos y entenderlos, esto aumentara la comunicación y por ende la colaboración para lograr objetivos compartidos. Serás transparente y honesto con el cliente, usuarios y toda persona relacionada con el producto y tu organización, siempre pensando en un beneficio mutuo.
Del amor surge tres principios universales, justicia, respeto y honestidad, principios que arraigados en un equipo permitirá la creación de productos brillantemente mágicos, de enorme satisfacción para todos los desarrolladores, usuarios, clientes, socios e inversionistas.
Principios que se vuelven valores y cultura en pequeñas y grandes empresas, locales e internacionales. Con personas de cualquier nacionalidad, raza, creencia religiosa, color, género, etcétera, etcétera.
Estos principios universales humanos, justicia, respeto y honestidad,son la masa rocosa para poder crear cualquier tipo de producto utilizando agilidad.
No todo es color de rosa
No todo es color de rosa, por supuesto que habrá muchas inconformidades y conflictos. Aun así, estos tres principios te ayudaran a resolver esas inconformidades y conflictos buscando un equilibrio y el beneficio mutuo.
Este equilibrio y beneficio mutuo claro que puede romper relaciones laborales en el caso de que sea necesario. Una ruptura en que las partes involucradas acuerdan que es lo mejor para todos, con una planificación adecuada y justa.
No te preocupes, si lo piensas no es más que sentido común, si ayudas a alguien con su problema, seguro que le dará ánimos de ayudarte con los tuyos. Y esto genera un ciclo infinito de buenas intenciones entre todos los integrantes de un equipo y de toda una organización.
La masa rocosa y el Manifiesto Ágil
De hecho el manifiesto ágil, si lo analizamos, se puede decir que está basado en estos tres principios fundamentales. Usando la analogía de construcción de un castillo. Primero tenemos una masa rocosa, luego arriba de esta existen los pilares fuertes que forman la estructura del castillo, estos pilares son el manifiesto ágil.
Un ejemplo grandísimo sobre estos principios humanos y donde se refleja su influencia, está en lista de los valores de scrum y extreme programming, todos los valores están relacionados con estos tres principios, incluso el de respeto destaca con una relación muy directa.
La capacidad de crear y responder al cambio con el fin de tener éxito en un ambiente incierto y turbulento
agileallieance.org
Manifiesto Ágil
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otras personas a hacerlo. A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación extensiva.
Colaboración con el cliente sobre negociación contractual.
Respuesta ante el cambio sobre seguir un plan
Es decir, aunque valoramos los elementos de la derecha, valoramos más los elementos de la izquierda.
https://agilemanifesto.org/
El desarrollo Ágil se ha vuelto demasiado decorado. Desechemos esas decoraciones por un minuto y regresemos al corazón ágil.
Dr. Alistair Cockburn, uno de los autores del manifiesto ágil
Me gusta mucho esta frase del Dr. Alistar Cockburn, porque vuelve a lo que es realmente importante, a no complicarse las cosas. De hecho actualmente existen dos nuevos conceptos que toman este concepto de simplificar la agilidad.
El enfoque de esta publicación es un paso aún más adentro, a la raíz de las relaciones interpersonales. Para utilizar esa masa rocosa y edificar fuertes prácticas ágiles. Esto lo vamos a reflejar en cada uno de los puntos del manifiesto ágil.
Entonces, a continuación voy a explicar desde mi punto de vista lo que los autores nos quieren comunicar y como se relaciona con la masa rocosa que ya hemos planteado.
Individuos e interacciones sobre procesos y herramientas.
Individuos e interacciones
Primero los individuos que crean empresas y generan calidad
Todos somos personas y seres humanos, por lo que las personas es el factor más importante para el éxito de cualquier proyecto. La comunicación efectiva, la motivación y principios compartidos para lograr un objetivo superior determinarán la calidad del producto final.
Ok, ok, ¿Por qué es muy, muy importante un individuo? Pues porque son las personas las que crean el producto o software, y son estas mismas las que forman a las empresas. Sin mencionar que los clientes y usuarios también son personas.
Como dijo Alistair Cockburn, uno de los creadores de este manifiesto ágil:
El proceso y la tecnología son un efecto de segundo orden en el resultado de un proyecto. El efecto de primer orden son las personas.
Alistair Cockburn
Los procesos, patrones de diseño, patrones de trabajo y las prácticas de desarrollo de software y desarrollo ágil son importantes, pero son las personas las que harán que funcionen.
Las personas no son piezas reemplazables
Las personas no son piezas reemplazables
Kent Beck
Las personas no son como piezas de un software o proceso, no son piezas reemplazables en una organización, un individuo no es algo lineal, es muy complejo y existen muchas variables que determinan su comportamiento, su desempeño, su moral y por consiguiente su productividad.
Si un líder ve y trata a su equipo como piezas reemplazables sumamente lineales, y no trata de ver a su equipo como individuos, esto baja la moral (productividad). Las personas buenas siempre buscan un mejor lugar donde estar.
El líder termina cosechando lo que siembra, piezas reemplazables sumamente lineales que no ayudan a la productividad, o al menos no se desempeñan con su máximo potencial. Esto provoca perdidas de tiempo, esfuerzo y dinero a las organizaciones.
Otra forma más fuerte de perder recursos en las organizaciones, es si el individuo decide irse de su equipo. Imagínense el tiempo en conseguir y capacitar al reemplazo, mientras el reemplazo está listo, el esfuerzo necesario de los demás personas del equipo aumenta porque al inicio es como no tener al compañero que se fue.
Gastos por renuncia de un integrante del equipo
Además estas mismas personas del equipo actual, seguro deben contribuir invirtiendo tiempo en la capacitación del reemplazo. Existe un gran retraso y desembolso económico a causa de la renuncia de una persona.
Un proyecto exitoso se logra con un equipo satisfecho, contento y dispuesto a colaborar entre ellos para lograr un objetivo en común y superior, los cuales se autoorganizan para ser mucho más productivos.
Las organizaciones que se encomiendan a formar equipos de este tipo, obtienen una enorme ventaja competitiva sobre aquellas que tratan a las personas como simples piezas lineales que forman parte de un proceso.
Al tratar a las personas como lo que son, con justicia, con respeto, y siendo honestos con ellas, se puede lograr lo imposible.
Software funcionando sobredocumentación extensiva
Software funcionando
Para tener una documentación detallada es necesario mucho tiempo y esfuerzo porque la documentación siempre cambia conforme se le agregan nuevas funcionalidades o se modifican las ya existentes. Entonces ese tiempo y esfuerzo mejor se invierte en obtener software funcionando que puede ser presentado al cliente y obtener retroalimentación. Es muy difícil mantener sincronizada la documentación con el verdadero funcionamiento (con el código), con el tiempo la documentación miente sobre la funcionalidad, la única fuente de verdad es el código.
La mejor documentación son las personas y el código
¿Cómo se entrena un nuevo integrante?, o ¿Cómo una persona recuerda lo que hizo hace un día, una semana o hace un año?, o ¿Cómo otro integrante del equipo utiliza un componente, un módulo, una clase o una función sin perder todo un día tratando de comprender?
La mejor documentación e instrucciones de como funciona una pieza del sistema se encuentran en las personas y el código que ellas crean.
Es de valor inigualable poner énfasis en la excelencia técnica y al buen diseño para mejorar la agilidad, es decir, código limpio, bien diseñado y utilizando prácticas ágiles como BDD y TDD para que cualquier integrante lo pueda entender, aumentar nuevas funcionalidades y modificar existentes con gran facilidad.
Incluso para que la misma persona o personas que lo crearon puedan recordar cada detalle minúsculo. De hecho a veces no necesitas llegar al detalle, simplemente utilizas la pieza del sistema con seguridad del resultado debido al buen diseño y a la calidad de la misma, lo que por supuesto te ahorra muchísimo tiempo. Claro que esto no se puede lograr sin las personas, sin su disciplina y auto organización.
Si existe documentación
No es que no exista documentación, pero se puede posponer, o ser poca y enfocado en las cosas que no cambiaran mucho. En etapas tempranas del desarrollo sería una pérdida de tiempo documentar algo que tendrá constantes cambios y mejoras. El momento ideal para una documentación es cuando se escriben las especificaciones con BDD y TDD. El segundo momento ideal es cuando se tiene una versión estable.
¿Entonces como logramos que nuevos miembros del equipo entiendan los detalles del producto o software?
Ya habíamos establecido la respuesta, se logra gracias a las personas y el código que ellas crean. Porque se trabaja muy de cerca con cada individuo del equipo, transfiriendo el conocimiento de manera práctica, ayudandose mutuamente a resolver sus dudas, sus problemas.
Por dar ejemplo. Se puede aplicar pair programming, trabajar para lograr la confianza de que son parte del equipo y pueden comunicarse con toda honestidad.
Si en el peor de los casos un miembro del equipo se va, mínimo el conocimiento se transfirió a todos los demás integrantes de manera empírica y rápida, estos integrantes seguirán transfiriendo el conocimiento a las personas nuevas.
Y ¿Qué pasa si todos los integrantes del equipo se van? Bueno aquí tenemos un problema más grande, porque entonces no se están aplicando los principios humanos de justicia, respeto y honestidad, y no se está aplicando el primer punto del manifiesto ágil, individuos e interacciones sobre procesos y herramientas.
Colaboración con el cliente sobrenegociación contractual
Colaboración con el cliente
Es muy importante involucrar al cliente en todo el ciclo del desarrollo de tal manera que los requisitos se recolecten progresivamente, evolucionen y se adapten según la retroalimentación del usuario final y de los demás involucrados. Diferentes puntos de vista y perspectivas mejoran la cálida del producto en cada iteración.
Aquí tenemos una oportunidad muy importante de poner en práctica los tres principios universales humanos en relación con el cliente, necesitamos ser justos, respetuosos y honestos en todas y cada una de las interacciones con el cliente y su negocio.
Siempre existirá incertidumbre
No se recomienda crear contratos detallados que especifiquen lo que el software va a hacer, lo que se va a cobrar por ello, y un calendario de entregas. Eso es demasiado fijo y nunca, nunca se cumplen las expectativas porque un desarrollo ágil se adecúa a los ambientes inciertos y turbulentos implícitos dentro de la creación de software.
Por mucho que se sepa del negocio y de la tecnología, siempre habrá una variable desconocida de la cual se debe aprender. Esta variable desconocida hará cambiar todo lo detalladamente planeado con anticipación.
Un contrato fijo nunca va a funcionar, debe ser algo flexible que se adapta conforme a los usuarios cambian y necesitan, debido a esto un contrato que indique los requerimientos fijos, sin intervención del cliente y usuarios, es seguro que será un fracaso.
Buscar beneficio mutuo, lo primero son las personas
Más sin embargo tener un acuerdo con el cliente donde se establezcan lineamientos buscando el beneficio mutuo. Indicando por ejemplo que los pagos se estarán haciendo conforme a lo que se vaya entregando. Donde se acuerde que el cliente estará involucrado todo el tiempo en el desarrollo para que apruebe las funcionalidades en cada iteración. Esto es algo mucho más justo y honesto, respetando el tiempo y el dinero del cliente, así como sus sueños.
Este punto del manifiesto tiene mucha relación con el primero, hasta me atrevería a decir, que este es una subrama del primero. Porque los clientes son individuos y entre más nos preocupemos por las interacciones con ellos, más rápido entregaremos un producto de valor, que indudablemente mejorara las actividades que benefician al cliente, al equipo que desarrolla el producto, y en general todos los involucrados
Respuesta ante el cambio sobre seguir un plan
El producto final siempre tiene una relación estrecha con el ambiente real y con personas (usuarios finales, desarrolladores y demás), todo a nuestro alrededor y las personas se encuentran en constante cambio, es imposible seguir un plan y que funcione completamente, pero si es ágil y efectivo tener la capacidad de responder al cambio dentro de un ambiente de incertidumbre.
No puedes planificar a detalle todo lo que se va a realizar en el proceso de la creación de un producto, tampoco es que no se hagan planes, si se hacen, pero con el conocimiento que seguro cambiaran en algún momento, muchas técnicas ágiles recomiendan hacer planificaciones muy detalladas en plazos cortos de tiempo, un poco de detalle a plazos medianos y muy, pero muy poco detalle para plazos largos. Aun así todo es incierto y debido a esta incertidumbre es que se debe de generar la capacidad de responder a cualquier cambio, esta capacidad la debe tener tanto el producto como las personas que lo crean.
Todos los integrantes del proyecto deben tener la suficiente flexibilidad para adaptarse a las necesidades que surjan en el ambiente, esto incluye la comunicación, la manera de trabajar y hasta las habilidades que estén dispuestos a aprender, en frameworks como scrum le llaman equipos multidisciplinarios.
12 principios ágiles
En cuanto al producto, bueno, utilizare un ejemplo del área de software donde tengo más conocimientos. Aunque no voy a explicar los 12 principios del movimiento ágil, este último punto del manifiesto, comparte una estrecha relación con los siguientes principios, y realmente son ejemplos que nos permiten responder al cambio:
La mayor prioridad es satisfacer al cliente con la entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Los procesos ágiles promueven el desarrollo sostenido. Los promotores, desarrolladores y usuarios debemos mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
¿Qué es un software con valor?
Todos los principios anteriores giran alrededor de la construcción de un software de valor, pero, ¿Qué es un software con valor?¿Será un software que funcione? Bueno, creo que sí, al menos en parte, pero el software o cualquier tipo de sistema tiene dos tipos de valores, por desgracia muy a menudo le ponemos más atención al tipo que es secundario y que realmente surge del valor principal. Déjame explicártelo más a detalle en los siguientes párrafos.
Normalmente un sistema tiene valor si funciona y resuelve un determinado problema para los usuarios y clientes, ¿En verdad es este valor lo más importante? Yo no lo creo y menos en los ambientes cambiantes e inciertos para lo que estos productos se crean, la primera solución, la primera versión de un sistema por supuesto que resuelve algo, pero no a la perfección, y no ser perfecto esta bien, los desarrollos ágiles son iterativos e incrementales, aprendiendo y satisfaciendo las necesidades de los usuarios y clientes en paralelo y progresivamente. Además las piezas o componentes de un producto también van mejorando y también se lleva un control de sus versiones.
Los clientes realmente no saben exactamente como debe ser su producto, tienen idea, eso es claro, pero conforme van probando su producto y obteniendo retroalimentación van modificando sus ideas y hasta puede que la idea de un producto de un giro de 360 grados, esto es porque no se sabe el verdadero valor de un producto hasta probarlo con usuarios, además la gente cambia, la sociedad cambia, así es, repito, el mundo es un ambiente incierto y turbulento al que debemos ser capaces de adaptarnos.
El software debe ser flexible
A lo que quiero llegar es que un software debe ser lo suficientemente flexible, lo suficientemente sustentable para poder adaptarse al cambio con gran facilidad. El valor primordial de un software es que en cualquier momento pueda adaptarse a las necesidades de los usuarios. Y con esto viene en segunda posición que funcione.
Lo anterior tiene una razón, aunque la función tenga valor para los clientes y usuarios, si es muy difícil adaptar el producto a las nuevas necesidades del ambiente o peor aún, adaptar el producto a las funcionalidades que ya se tenían pensadas, entonces estamos perdiendo valor. Un software con valor debe tener la capacidad de agregar y cambiar funcionalidades a una velocidad sustentable, sin retrasos y de lo más fácil posible, esto es de enorme valor para nuestros clientes y usuarios finales.
Si dejamos a los clientes sin nuevas actualizaciones por mucho tiempo, entonces ya deja de tener valor y los usuarios dejan de usar el producto, porque las nuevas necesidades precisamente son otras diferentes a las que actualmente el software proporciona. Sin mencionar el caso de que el producto tenga demasiados fallos y entonces estos fallos provoquen dificultad al cambio.
Conclusión
Para que la adaptabilidad fluya en un equipo debemos estar conscientes de que habrá muchos cambios y amar la incertidumbre, pues es como de verdad se aprende de lo que es prioritario o necesario hacer. A aceptar los fallos tempranamente con honestidad, respeto y justicia hacia todos los involucrados para entregar continuamente un producto profesional, que evoluciona y mejora con el tiempo, nunca se estanca y nunca pone en peligro su negoció. Se aprovecha al máximo los recursos, respetando el tiempo y el recurso económico de todos.
Estos principios humanos de honestidad, respeto y justicia, rigen el manifiesto ágil, es tan importante que dos de sus puntos tiene una relación directa. Hablamos de:
Individuos e interacciones sobre procesos y herramientas
Colaboración con el cliente sobre negociación contractual
Los otros dos aunque no tienen una relación directa, sí que indirectamente todo lo que hacemos se trata sobre las personas y las relaciones que tenemos con ellas.
Aunque probablemente el cambio de desarrollo tradicional a desarrollo ágil empezó mucho antes de los acontecimientos que voy a mencionar, estos son los más importantes que marcaron la base para lo que hoy en día llamamos agilidad, como todo buen cambio, no sucedió de la noche a la mañana, fue un proceso lento, como un cambio de paradigma, el cual la sociedad de la administración de proyectos y software empezaron poco a poco a interiorizar o al menos a utilizar.
En cuanto a los métodos, puede haber un millón y algo más, pero los principios son pocos. El hombre que capta los principios puede seleccionar con éxito sus propios métodos. El hombre que prueba métodos, ignorando principios, seguramente tendrá problemas.
Ralph Waldo Emerson
Es importante mencionar que a pesar de que el movimiento ágil se relaciona mucho con del desarrollo de software, realmente no tiene que ver específicamente con esta industria, más bien sus raíces son en las personas mismas, por lo que se aplica a todas las áreas que te puedas imaginar donde existan personas, es decir, en todo.
El desarrollo ágil es un cambio cultural, lleno de principios y valores humanos, que todos y cada uno de los integrantes de un equipo y de una empresa deben tener arraigado muy en su ser, para que de esta manera sucedan cosas mágicas, como la creación de productos que llenan de enorme satisfacción al usuario y los clientes, velocidad de producción, reducción de costos, proyectos exitosos, empleados felices y en general el beneficio de todos los involucrados, tanto internos como externos, directos o indirectos.
Total Quality Management (TQM)
El primer cambio significativo con dirección al desarrollo ágil sucede durante la segunda guerra mundial donde Williams Edwards Deming les enseño control estadístico de los procesos a los ingenieros estadounidenses con el fin de mejorar los materiales de guerra, aun así, parece que los estadounidenses no le prestaron mucho interés, probablemente debido a la guerra. Después de esto en 1950, Deming se trasladó a Japón, en la época donde la industria y economía de este país estaba en crisis, esta vez si pudo transmitir exitosamente sus conocimientos y filosofía de la calidad de los productos y servicios. Los japoneses lo escucharon y estuvieron dispuestos a cambiar la cultura de trabajo.
Al implementar los principios de la metodología de Deming, los japoneses convirtieron totalmente su economía e industria posicionándose como lideres mundiales en ámbitos como tecnología, industria manufacturera y comunicaciones
De hecho la metodología TQM que creo Deming fue la base para el nacimiento del movimiento ágil, los principios más importantes de TQM son los siguientes:
Mejorar la calidad resulta en reducción de costos, reducción del costo de los defectos, reducción de soporte al cliente y menos llamadas de los mismos en relación con defectos.
Mejora continua en todos las partes del sistema y las personas.
Orgullo del trabajo que hace una persona, es la clave principal para obtener la calidad necesaria de un producto/servicio, que los empleados disfruten su trabajo y con orgullo.
Plan – Do – Check – Act (PDCA) – Ciclo de desarrollo para poder probar y obtener retroalimentación sobre soluciones de problemas y creación de sistemas complejos.
Del punto uno y dos, Deming fomentó lo siguiente:
Mejorando la calidad, automáticamente, mejora la productividad.
Williams Edward Deming
En la actualidad, existe un principio ágil muy relacionado con lo que dijo el señor Deming:
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
Del punto tres tenemos su relación con el principio actual
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
Si analizamos los primeros tres puntos de TQM y en concreto el tercer punto, podemos concluir que al preocuparnos por las personas obtendremos calidad y una mejora continua tanto en los sistemas y procesos como en las personas mismas, por que al final de todo, los individuos son el recurso que genera productos/servicios y forman empresas.
En el manifiesto Ágil que veremos en otra publicación, el primer elemento de manifiesto y el más importante dice así:
Individuos e interacciones sobre procesos y herramientas.
Como podemos ver el desarrollo ágil no es realmente algo nuevo, siempre se ha estado buscando mejores maneras de trabajar.
Sobre el último punto, el ciclo PDCA se parece mucho a lo que se utiliza actualmente en Lean, Lean startup, Lean thinking, Design thinking, RAD, DSDM, Extreme programming, Scrum, Crystal clear y demás metodologías estilo ágiles. El objetivo es obtener retroalimentación inmediatamente para aprender y mitigar errores o direcciones equivocadas.
Este ciclo PDCA nos permite responder al cambio, con lo cual se ejerce un principio fundamental del manifiesto ágil:
Ahora veamos los diagramas de algunos de los ciclos de retroalimentación que tiene las metodologías ágiles:
Design Thinking Ciclo de retroalimentación
Lean Startup ciclo de retroalimentación
Scrum ciclo de retroalimentación
Extreme Programming
DSDM ciclo de retroalimentación
¿Qué tal, todos estos ciclos son muy parecidos verdad?
Toyota Production System (TPS)
Este sistema desarrollado entre 1948 y 1975, y presentado formalmente en los 80´s fue inspirado en los trabajos de Henry Ford y también en TQM debido a que sus inicios datan de la misma época cuando Edwards Deming fue a Japón a transmitir sus conocimientos de Gestión de calidad Total (TQM) y en esos tiempos Taichii Ohno estaba trabajando para Toyota Motors Company. Como todo buen diseño, no solo de una fuente surgen las inspiraciones y las ideas, pero podemos notar la influencia y evolución de TQM en TPS.
Este sistema fue el precursor de Lean Manufacturing y demás metodologías Lean de la actualidad. Los principios en los que se basa TPS son los siguientes:
Mejora continua, tomando como base a las personas, mejorando su ambiente laboral, su aprendizaje, su creatividad e ideas para que de esta manera mejoren en todo lo que hacen incluyendo los procesos, herramientas y métodos utilizados en toda la empresa.
Respeto por las personas. Aquí de nuevo otra constante clave del éxito de este sistema, el respeto por las personas. Aunque también el enfoque es en la mejora continua, esto nunca se lograría sin el respeto, ¿Qué es el respeto? Para mí, y esto ya lo escribí en otro post cursi sobre agilidad (¿Qué es Scrum? ¿Por qué es importante en la creación de productos y/o servicios? Valores, empirismo y pilares) es el amor por otra persona, aunque no intenso, es la naturaleza del ser humano preocuparse por los demás, un sentimiento latente en mayor o menor medida, todos somos diferentes, y lamentablemente algunos de nosotros lo tenemos muy escondido, pero ahí esta, un principio natural que genera un ciclo infinito de buenas intenciones.
A través del principio de mejora continúa y respeto por las personas, TPS propone lo siguiente:
La eliminación de desperdicios (Muda), los cuales son provocados por la sobrecarga de trabajo y estrés de los empleados, máquinas, procesos, etc (Muri), también por inconsistencias y variaciones no previstas que causan un desequilibrio en la producción (Mura). Con Muri y Mura podemos destacar de nuevo la importancia de las personas para el éxito de este método. TPS define 7 tipos de desperdicios, solo los voy a mencionar:
Desperdicio por sobreproducción
Desperdicio por Tiempo de espera
Desperdicio por transporte
Desperdicio por procesos
Desperdicio por inventario
Desperdicio por movimientos
Desperdicio por defectos
Lotes pequeños. La mejor manera de encontrar errores, aprender de ellos y mitigar sus efectos negativos lo más pronto posible es por tareas/procesos pequeños y simples mucho más fáciles de manejar y entender.
Kanban. Para eliminar el desperdicio, Taiichi utilizó un tablero con tarjetas (Kanban) donde se puede visualizar lo que se tiene que hacer, lo que sé está haciendo, lo que se terminó y si una tarea necesita de materiales o de la finalización de otra tarea para continuar.
Pruebas constantes. Siempre probando con lotes pequeños para encontrar errores y mitigarlos inmediatamente. En cada lote pequeño es más fácil hacer pruebas, actualmente en agilidad se utilizan las pruebas unitarias y funcionales de un lote pequeño de elementos del sistema que entregan valor para los usuarios/clientes en periodos cortos de tiempo.
Estos últimos puntos están muy relacionados con el siguiente principio ágil:
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Todo lo anterior permite que Toyota se encuentre actualmente como una de las tres mejores compañías de autos, con un 70% de satisfacción de sus empleados. ¿Que compañía logra eso? el enfoque de respeto hacia las personas ha hecho de Toyota lo que hoy en día es.
¿El modelo en cascada propuso algunas practicas de lo que hoy llamamos desarrollo ágil?
¿Qué? ¿Cómo? y seguro pensaras algo así, “A mí me enseñaron que el ciclo del modelo en cascada era secuencial, no te creo”. Bueno a mí también me enseñaron lo mismo, pero investigando resulta que hay un mal entendido global de lo que propuso Winston Royce acerca del modelo en cascada y la prueba que encontré esta aquí, por si quieres abrir los ojos por ti mismo.
Expliquemos lo que propuso Winston Royce en su documento del año 1970, si, como he estado explicando, siempre ha existido una tendencia hacia el desarrollo ágil. Winston Royce presento el siguiente diagrama:
Pero inmediatamente aclaró que este modelo era muy riesgoso y propenso al fracaso. ¿Entonces por que demonios lo empezamos a utilizar? No lo sé, pero en mi caso, lamentablemente fue lo que me enseñaron en la universidad, cuando en esa época ya existían mejores métodos para el desarrollo de software como XP y Scrum que se establecieron formalmente a los mediados de los 90’s. Winston Royce propuso cinco mejoras al método de cascada, son los siguientes:
El diseño del sistema debe ser primero
Documentar el diseño
Hacerlo dos veces
Planear, controlar y monitorear pruebas
Involucrar al cliente
Aunque las dos primeras mejoras se podría decir que no son ágiles, los ultimas tres mejoras claramente tienen su merito ágil. Aun así el método que propone Winston Royce no es secuencial, sino más bien iterativo e incremental, bueno, tampoco no tan iterativo e incremental como actualmente lo es el desarrollo ágil pero era un gran comienzo. Veamos ahora el diagrama con las cinco mejoras de Royce:
Modelo cascada ágil
No explicare a detalle las cinco mejoras, pero las describiré brevemente y su relación con los principios fundamentales del desarrollo ágil. Antes de eso si se fijan de lado derecho existe otro ciclo de retroalimentación que va desde pruebas, desarrollo y requerimientos, por lo que totalmente lineal waterfall nunca lo fue.
El diseño del sistema debe ser primero, esto actualmente siempre se hace solo que en ciclos pequeños e incrementales sobre todo el sistema, también en escala aún más pequeña al realizar las pruebas unitarias o funcionales se piensa inmediatamente primero en el diseño de la funcionalidad antes de escribir código para poder crear la prueba.
Documentar el diseño. En las metodologías ágiles de hecho se realiza documentación solo que muchas veces no están en documentos, sino en las pruebas unitarias y funcionales, es decir, en lugares donde no se podrá mentir, en la fuente, el código. Pero esto último es otro tema, lo de mayor prioridad es tener un software funcionando, aun así la documentación también se hace por ciclos iterativos e incrementales.
Hacerlo dos veces. Royce empieza a recomendar ciclos iterativos e incrementales al sugerir realizar dos veces la creación del sistema. Actualmente en desarrollo ágil no solo se realiza dos veces, sino muchas veces en periodos cortos del mismo día, en horas y hasta en minutos, también siendo iterativo e incremental,
Planear, controlar y monitorear pruebas. En metodologías ágiles se utilizan las pruebas para obtener retroalimentación lo más pronto posible y hacer los arreglos necesarios, aunque el modelo de Royce a mi parecer no implementa las pruebas tan seguido como en las metodologías ágiles actuales, mínimo lo hace dos veces durante una iteración.
Involucrar al cliente. Este es el más importante para mí porque hace mucho hincapié sobre las interacciones de las personas. En el manifiesto ágil de la actualidad tenemos lo siguiente:
Colaboración con el cliente sobre negociación contractual
En el ámbito de la creación de software, mucha antes de la creación del famoso manifiesto ágil, metodologías y frameworks tradicionales que se utilizaban para crear productos o proyectos no estaban funcionando, existía un porcentaje muy alto de fracaso.
El porcentaje alto de fracasos fue influido por la mala implementación del modelo en cascada de Winston Royce. Entonces varias personas empezaron a preguntarse si habría mejores maneras de desarrollar software, es aquí donde empezaron a crear sus propias métodos ágiles, empezaron a surgir metodologías como:
Rapid Application Development (RAD) – 70s – 80s
Como vemos en este ciclo de retroalimentación, existen iteraciones en las fases de diseño y construcción.
RAD ciclo de retroalimentación
Dynamic software development method (DSDM) – 80s
En el ciclo de retroalimentación de esta metodología, incluye iteraciones en la factibilidad y fundación, es decir, los requerimientos, además de poder hacer iteraciones en las fases diseño y construcción.
DSDM ciclo de retroalimentación
Extreme Programing (XP) – Mediados de los 90s, Kent Beck, Ward Cunningham, Ron Jeffries
Este es un mejor ciclo de retroalimentacion en comparacion con los anteriores, en todo momento se hacen iteraciones, en todos los niveles, además:
Mucho uso de TDD, continuamente durante todas las etapas
Pruebas de aceptación y unitarias
Origen de los Dailys o stand up meetings
También las famosas historias de usuario.
Extreme progamming ciclo de retroalimentación
Scrum – A mediados de los 90s – Ken Schwaber, Jeff Sutherland
Bueno este es el más conocido de todos y el más usado actualmente, para mas detalles sobre este framework te dejo los siguentes enlaces:
Aunque estos frameworks ya habían empezado con el desarrollo ágil, era necesario definir ciertos principios comunes para mejorar el entendimiento y la rápida adopción de estas nuevas formas de crear software.
En el 2001, 17 desarrolladores de software se reunieron en Snowbird, Utah para analizar sobre los métodos de desarrollo de software ágil que estas 17 personas estaban utilizando, DSDM, Extreme Programming, Scrum y crystal clear. El resultado fue el Manifiesto ágil y los 12 principios ágiles.
¿Por que es de suma importancia el manifiesto y los 12 principios ágiles?
Es importante entender que más adelante podría surgir un nuevo framework ágil con una mejor manera de hacer las cosas y que probablemente deberíamos de adoptar, pero el manifiesto y los principios ágiles seguirán siendo la base primordial que si se comprende bien y se interiorizan, cualquier equipo u organización podra utilizar el framework o método que más le convenga en determinadas circunstancias o proyectos.
Es como la creación de código y piezas de un sistema computacional, no importa el lenguaje de programación, librería o frameworks de desarrollo, si no las bases de lógica, patrones y principios de diseño y arquitectura, los que harán entender cualquier nuevo lenguaje o framework que pudiera salir en el futuro.
Hablando un poco más sobre las prácticas utilizadas en los frameworks ágiles, estás prácticas están subordinadas por los principios, es decir, en un proyecto, se utilizarán las prácticas más acordes a las circunstancias del problema que se quiere solucionar. Por la tanto es importante comprender el porque se ejecuta una práctica, o sea, que practica me dará mejores resultados y agilidad basándome en los principios y factores específicos del problema.
¿Qué es ágil?
La capacidad de crear y responder al cambio con el fin de tener éxito en un ambiente incierto y turbulento
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otras personas a hacerlo. A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación exhaustiva.
Colaboración con el cliente sobre negociación de contratos.
Respuesta ante el cambio sobre seguir un plan
Es decir, aunque valoramos los elementos de la derecha, valoramos más los elementos de la izquierda.
En esta publicación explico a detalle la razón y como aplicar el manifiesto ágil:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Antes que nada, recordemos el significado de Ágil.
La capacidad de crear y responder al cambio con el fin de tener éxito en un ambiente incierto y turbulentoagileallieance.org
agileallieance.org
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Uno de los 12 principios de “Agile Manifiesto”
Con este enfoque, un producto que se crea usando metodologías ágiles debe ser adaptable, es decir, responder al cambio en un ambiente turbulento. Esta respuesta al cambio nos permite crear productos que sean sustentables. Más abajo se describe a que nos referimos como sustentable.
¿Qué son las pruebas ágiles?
Pruebas ágiles son técnicas esenciales en el desarrollo de software que implementan los principios y prácticas ágiles.
Una de las prácticas ágiles para implementar el principio de adaptación al cambio son las pruebas ágiles.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
Uno de los 12 principios del “Agile Manifiesto”
Las pruebas ágiles mejoran la agilidad porque nos permite crear un producto con un mejor diseño, más entendible y en general de mejor calidad. Esto promueve un fácil mantenimiento y la adaptabilidad en una ambiente súper cambiante. Lo que nos lleva a menores costos financieros.
Cuando hablamos de pruebas ágiles hablamos de varias técnicas y de diferentes tipos de pruebas, como pueden ser TDD, BDD, las pruebas unitarias, funcionales, de integración, de rendimiento, de usabilidad, etc.
¿Qué significa sustentable o sostenible?
Se refiere a algo que está en condiciones de conservarse o reproducirse por sus propias características, sin necesidad de intervención o apoyo externo.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
Uno de los 12 principios de “Agile Manifiesto”
Siempre deberíamos preguntarnos a nosotros mismos si estamos creando productos sustentables, que se adapten al cambio fácilmente.
Características de las pruebas ágiles
Como ya hemos descrito hasta este punto, existen muchos principios que se relacionan muchísimo con el uso de pruebas ágiles. Hago hincapié, las pruebas ágiles se basan en principios ágiles.
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Uno de los 12 principios del “Agile Manifiesto”
Es una ilusión, nos engañamos a nosotros mismos, cumplir con la fecha de entrega dejando de lado la calidad. Tirando las buenas prácticas como Desarrollo guiado por pruebas (TDD ) o Desarrollo guiado por comportamiento (BDD), y creando código en el último minuto. Eso no es desarrollo ágil, aunque se pudiera obtener velocidad a corto plazo, el costo a mediano y largo plazo es muy grande para el negocio y/o stakeholders. ¿Eso es la descripción de un software con verdadero valor para nuestros clientes?
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Uno de los 12 principios del “Agile Manifiesto”
El software funcionando es la medida principal de progreso.
Uno de los 12 principios del “Agile Manifiesto”
Guían al desarrollo a través de especificaciones claras
TDD y BDD son técnicas ágiles, pero si nos fijamos en sus definiciones, la frase principal es “Desarrollo guiado por“, así es, no se trata de pruebas, se trata del desarrollo y las pruebas son una parte que integra al todo, las pruebas forman parte del desarrollo. Y aunque técnicamente son pruebas, realmente son especificaciones de como debe funcionar el software.
Existe un hecho importante y que se nos olvida a la hora de indicar que una funcionalidad está terminada, si las pruebas no están terminadas y las pruebas son parte del desarrollo, entonces la funcionalidad tampoco puede estar terminada.
¿Cómo podemos entregar software funcional y como podemos decir que estamos progresando si en realidad no estamos entregando ninguna funcionalidad “Terminada” a nuestros clientes?
De hecho creo que TDD es una mala definición, no debería tener la palabra prueba (Test). BDD es una evolución de TDD para tener una perspectiva más hacia el cliente y el negocio, precisamente es una mejora en el nombre, más centrado en darle un verdadero valor a un software.
Relación con Individuos y colaboración
A veces perdemos el enfoque dentro de una metodología o framework ágil, nos centramos mucho en los procesos y las herramientas, cuando siempre debemos darle prioridad a los individuos (las personas) y las interacciones sociales que se producen. Estos individuos son los que genera las especificaciones del software.
Olvidamos de las prácticas de colaboración y de las prácticas de desarrollo técnico que nos permiten establecer la calidad, la arquitectura y las soluciones que se generan en equipo, que le dan la cualidad sustentable a un producto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
Uno de los 12 principios de “Agile Manifiesto”
Un equipo de desarrolladores es más productivo si se encuentra creando nuevas funcionalidades en lugar de estar arreglando bugs que pudieron mitigarse antes y que por la complejidad y madurez del sistema es muy difícil de resolver actualmente. Si, el estrés del programador es un factor clave.
Relación con pilares de scrum
Reitero que las pruebas ágiles se basan en principios ágiles, lo podemos ver en el proceso empírico de scrum y sus tres pilares:
Transparencia
Inspección
Adaptación
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Uno de los 12 principios de “Agile Manifiesto”
Necesitamos la transparencia con todo el equipo a la hora de definir las especificaciones que se traducen en pruebas, de esa manera todos obtienen un mejor entendimiento sobre la parte lógica del negocio y la parte técnica de la implementación.
La inspección nos permite aprender de manera rápida usando las pruebas para definir y fallar tempranamente con la ayuda de todo el equipo. De modo que se obtiene un ciclo de Retroalimentación muy pequeño obteniendo información y dirección lo más pronto posible.
Luego de que aprendimos de todos y de nuestros errores, se adaptan las pruebas para cumplir con las necesidades del cliente y entregar un producto de calidad probado correctamente. Ahorrándonos mucho esfuerzo y dinero, porque el coste de arreglar bugs en etapas maduras de un producto es muy costoso en comparación con mitigarlos desde el principio con pruebas pequeñas.
Todos se involucran en las especificaciones
En scrum, un equipo multidisciplinario es más eficiente que un equipo dividido por habilidades específicas. Una división muy común y que disminuye considerablemente la agilidad de un equipo es la fuerte división de manual testers, programadores y automation testers.
Aunque posiblemente cada uno de los integrantes tenga mayor habilidad en una área, es importante que sean flexibles y se adapten a las necesidades del proyecto.
Es necesario que también la perspectiva del negocio, para que aporten significativamente a la creación de las pruebas ágiles, por poner un ejemplo, un Product Owner tiene el mayor entendimiento sobre lo que es de mucho valor para el cliente.
Todo el equipo se involucra en las pruebas para fomentar el entendimiento global desde un enfoque centrado en el cliente, y esto genera un aumento en la creatividad de las soluciones.
Al estar todos involucrados en las pruebas, se elimina un cuello de botella significativo porque se acelera la definición y la creación de las mismas. Es más rápido terminar una tarea entre varias personas que si lo hiciera una sola.
Incorporan muchas prácticas ágiles
Además de las características ya mencionadas, las pruebas ágiles permiten incorporar técnicas de gran productividad en el desarrollo de software como:
TDD, Test Driven development
BDD, Behavior Driven Development
Pair programming
Mob programming
Example mapping
Listado de características
Existen muchas cualidades buenas en las pruebas ágiles, pero listemos las características principales:
Se basan en principios y prácticas ágiles.
Las pruebas forman parte del desarrollo, formando un todo integral, no es algo que esté separado.
Acelera la retroalimentación para poder realizar las adaptaciones necesarias lo más pronto posible.
Se acelera el proceso de definición, creación y terminación de las pruebas.
Todo el equipo se involucra en las pruebas para fomentar el entendimiento global desde un enfoque centrado en el cliente, y esto genera un aumento en la creatividad de las soluciones.
Permite incorporar prácticas ágiles para aumentar la agilidad y productividad.
Menos estrés y desarrolladores felices, mayor productividad y mayor calidad.
Ahorran tiempo y dinero.
La matriz de pruebas ágiles
Las pruebas ágiles nos proporcionan la certeza de que con el aprendizaje actual estamos resolviendo un determinado problema con la solución correcta y la implementación y/o construcción sé está realizando correctamente.
Las pruebas ágiles maximizan el valor de la solución y minimizan los riesgos, esto se consigue fallando inmediatamente de manera segura para aprender y adaptarse rápidamente.
Con esto último tenemos cuatro aspectos fundamentales a la hora de hacer pruebas:
Perspectiva tecnológica
Perspectiva de negocio
Soporte y guía al desarrollo
Crítica del producto
Cuadrantes en relación con los cuatro aspectos
Esos cuatro aspectos anteriores se representan en los siguientes cuadrantes:
Matriz de agile testing
¿Cuáles son las actividades que hacemos diariamente para contestar las siguientes preguntas?
¿Estamos construyendo el producto correcto?, Perspectiva de negocio.
¿Estamos construyendo el producto correctamente?, Perspectiva tecnológica.
¿Cómo guiamos el desarrollo para asegurarnos que el producto es correcto y que se está construyendo correctamente?, Soporte y guía al desarrollo.
¿Cómo obtenemos crítica del cliente que nos ayude a construir el producto correcto de manera correcta?, Crítica del producto.
Describiendo cada cuadrante
El cuadrante 1 proporciona una guía y soporte al programador desde la perspectiva tecnológica. Se crean pruebas unitarias y de componentes, estas pruebas se construyen antes y después de escribir código, nos indica que las partes más pequeñas funcionan como deberían. Aquí se puede utilizar BDD con un enfoque más inclinado a las unidades o piezas del software de manera aislada.
El cuadrante 2 proporciona igual una guía y soporte al programador, pero desde la perspectiva del negocio. Se utilizan pruebas funcionales para User stories y features de tal forma que se validan como el Product Owner las definió y como el usuario final las necesita. Aquí se utiliza mucho BDD (Behavior driven development) para automatizar las pruebas. Y si no existe otra opción, se pueden hacer pruebas manuales.
El cuadrante 3 proporciona crítica del cliente desde la perspectiva de negocio. Son pruebas a nivel del sistema completo, sé válida que el sistema cumple con las expectativas de funcionalidad y usabilidad. Se realizan en su mayoría manualmente porque involucran al usuario y a los testers dentro de un ambiente real o simulado.
El cuadrante 4 proporciona crítica del cliente desde la perspectiva tecnológica. Son pruebas para asegurar la calidad del sistema completo en términos de velocidad de carga, rendimiento, seguridad y escalabilidad. En general pruebas no funcionales que se realizan mediante herramientas y automatización.
Divide y vencerás. Pruebas pequeñas y automatizadas
Las pruebas ágiles generan un producto de alta calidad. Para que esto sea posible es necesario tener una filosofía de prevención de bugs en lugar de buscarlos. Es obvio que existe el error humano, siempre existirán bugs, pero la pregunta principal es ¿Pudimos haber evitado este bug?
Las técnicas como TDD y BDD son muy útiles porque su filosofía es “test-first”, es decir, antes de escribir cualquier línea de código primero crea tus pruebas para entender con mayor claridad el negocio, el cliente y por consiguiente los requerimientos. De esta manera se reduce el tiempo en que se recibe la retroalimentación por las dudas que surgen al momento de escribir las pruebas.
El diseño es superior (más si se realiza en equipo) y se puede refactorizar las funcionalidades rápidamente, eliminando futuros bugs, esto puede suceder varias veces en un mismo día.
Obtener retroalimentación diaria y adaptarse cada minuto o cada hora, es menos costoso y más ágil que hacerlo cada mes o cada semana con pruebas mucho más grandes. Es por eso que las pruebas que nos dan retroalimentación más rápida, son en las que más se deben invertir, normalmente estos tipos de pruebas son las pruebas relativamente pequeñas como unitarias, funcionales y de integración que se pueden automatizar.
Es importante disminuir el uso de pruebas manuales porque son mucho más lentas que las pruebas automatizadas. No estoy diciendo que las pruebas manuales deben desaparecer. Al final son necesarias, pero podemos ahorrarles mucho tiempo a los testers manuales para que reporten bugs que solo se puedan identificar realizando una prueba manual.
Así podemos disminuir las pruebas manuales en la medida de lo posible porque representan un costo mayor que las pruebas automatizadas.
Conclusión
Pasamos mucho tiempo trabajando, tal vez demasiado, creo que más de la mitad de nuestra vida adulta. Pero me he dado cuenta de algo importante, lo he percibido en mi mismo y también en mis compañeros de trabajo. Todos, en algún momento nos la pasamos mal y no estamos contentos, esto produce estrés y nuestra productividad individual empieza a disminuir, lo que sé traduce en disminución de la productividad de todo el equipo.
Las pruebas ágiles y el desarrollo ágil en general ayudan mitigar este problema. Creo firmemente que soy más productivo y hago mejor mi trabajo cuando estoy feliz haciéndolo, aún más si estoy consciente de entregar productos de alto valor para los clientes.
Tampoco estoy diciendo que todo es negro, pero sin duda las pruebas ágiles contribuyen en gran medida a tener un equipo contento, clientes felices y negocios sustentables, ahorrando tiempo, dinero y esfuerzo en el camino.
¿Cómo logramos encapsulación de nuestros nuevos elementos HTML que no provoque conflictos con el resto de una aplicación?, es decir, que los estilos, HTML interno y JS de un componente web, no colisionen con el resto.
La respuesta básicamente es, el Shadow DOM. El Shadow DOM nos permite tener los estilos y contenido HTML interno totalmente aislado del exterior. También se ayuda del API del DOM y custom elements para establecer comunicación con otros elementos y componentes internos. Además con el exterior.
El amor es de naturaleza interna. No lo vas a encontrar en alguien más, naces con ello, es un componente interno de cada persona. Mira a un bebé, simplemente es feliz por el hecho de existir. Irradia amor, te lo comparte.
Anónimo
Antes de comenzar, si aún no estás familiarizado con los custom elements y los componentes web nativos en general, te recomiendo revisar primero estas publicaciones:
Primero vamos a revisar la etiqueta <template>, para luego utilizarla dentro de nuestro componente web usando shadow DOM.
¿Qué es una plantilla?
Un template o plantilla HTML con el tag <template>, es una forma de crear elementos visuales de manera sencilla y eficiente, de tal forma que se pueden definir partes de una página web o aplicación a las cuales les podemos insertar valores.
Este template puede ser reutilizado en diferentes vistas de una aplicación. Tal vez estés familiarizado con jade, pug, mustache, o con algunos frameworks y librerías como angular y vue, los cuales utilizan templates. También si has utilizado wordpress y php, los archivos de los temas serian una especie de templates.
Ahora, los templates que vamos a aprender son específicos de HTML y por lo tanto funcionan en los navegadores web. Para entrar un poco más en contexto veamos un ejemplo sencillo de como podemos crear varios elementos para mostrar un saludo, utilizaremos estas tres fuciones, que forman parte del API del DOM.
document.createDocumentFragment()
document.createElement('nombreTag', [opciones])
nodo.appendChild(nodo)
Queremos mostrar en nuestra aplicación un saludo al usuario y lo hacemos de la siguiente forma:
Ahora veamos como hacer lo mismo, pero utilizando la etiqueta <template>:
Como podemos ver, con la etiqueta <template> se usa mucho menos código, si el contenido de lo que queremos mostrar crece, solo debemos agregar las etiquetas y demás contenido de manera sencilla dentro de la etiqueta <template>. Pero si usamos el primer método, nuestro código javascript crecerá mucho más, esto es más difícil de entender y mantener con el tiempo.
La etiqueta template usa internamente un DocumentFragment, la ventaja de utilizar document fragments es que su contenido no es aún agregado al árbol de nodos, sino que se encuentra en memoria y se inserta una sola vez al final, cuando el contenido esta completo.
// Agregar document fragment a la páginahost.appendChild(df);
Existen 4 puntos importantes al utilizar la etiqueta <template> para crear plantillas:
La etiqueta <template> no se pinta en nuestra aplicación, por default tiene un display: none;.
El contenido de la etiqueta <template> es un document fragment, el cual tiene la característica de no estar insertado en el árbol de nodos. Esto es bueno para el rendimiento de la aplicación debido al alto costo de pintar elementos.
El código JS necesario es muy simple y corto
Cuando clonamos el contenido de nuestro template usando cloneNode(), debemos pasar el valor true como parámetro, de otra manera NO clonaríamos los elementos hijos del document fragment de nuestro template.
Shadow DOM
El shadow DOM es un DOM o árbol de nodos en las sombras, escondidos de los demás elementos de una aplicación. Para entender esto vamos a crear nuestro primer componente web utilizando el estándar de custom elements, la etiqueta <template> y el shadow DOM.
Nuestro componente se llama mi-saludo, con el contenido del ejemplo anterior:
Si aún no sabes que son los custom elements, sigue este link. En el ejemplo anterior creamos un custom element llamado mi-saludo, dentro del constructor() creamos una instancia del template.
// Obtengo la única etiqueta 'template'const tpl = document.querySelector('template');// Clono su contenido y se crea una instancia del document fragmentconst tplInst = tpl.content.cloneNode(true);
Luego creamos un shadow DOM y lo adjuntamos al custom element mi-saludo:
// Se crea un nuevi shadow DOM para las instancias de mi-saludothis.attachShadow({mode:'open'});
Y finalmente agregamos el contenido clonado del template dentro del shadow DOM:
// Y se agrega el template dentro del shadow DOM usando el elemento raíz 'shadowRoot'this.shadowRoot.appendChild(tplInst);
En este último paso usamos la propiedad shadowRoot, creada cundo invocamos attachShadow, esta propiedad hace referencia a un nodo raíz especial de donde se empieza a colgar todo lo que definimos dentro de nuestra etiqueta <template>, y es a partir de este nodo que agregamos contenido.
Lo que se agrega al shadow DOM esta oculto para el exterior, ningún document.querySelector() externo puede acceder a los elementos del shadow DOM y los estilos definidos en el exterior no pueden acceder a estos elementos ocultos. Esto quiere decir que dentro del shadow DOM podemos utilizar atributos id y name sin temor a colisionar con los ids y name del exterior.
Cuando creamos un shadow DOM, se hace con la propiedad mode: open, de esta manera se puede acceder al contenido del shadow DOM usando Javascript y el atributo shadowRoot. Sin el atributo shadowRoot es imposible acceder a los elementos y eso nos proporciona encapsulación a nuestro componente.
Para crear una nueva instancia de nuestro nuevo componente, solo utilizamos el nombre que registramos como etiqueta:
// Se registra el custom element para poder ser utilizado declarativamente en el HTML o imperativamente mediante JScustomElements.define('mi-saludo', MiSaludo);
Y en el html utilizamos código declarativo:
<mi-saludo></mi-saludo>
¿Qué pasa si a nuestro template le agregamos una etiqueta style? Debido a que las instancias de nuestro template son agregadas al shadow DOM, entonces esos estilos solo afectan dentro del shadow DOM.
Para establecer estilos dentro del shadow DOM al nuevo tag creado, se utiliza la pseudoclase :host, que hace referencia a la etiqueta huésped del shadow DOM, es decir, mi-saludo.
También agregamos en el exterior estilos para las etiquetas <h1>, estos estilos no pudieron afectar al contenido interno del shadow DOM, el único h1#mi-id con borde rojo es el que se encuentra fuera de nuestro componente. El h1 externo como el interno tienen el mismo id, a causa del encapsulamiento con shadow DOM, no colisionan los estilos con el mismo selector de id.
Ahora en nuestro código html, agreguemos más etiquetas mi-saludo:
Como podemos ver la combinación de estas tres tecnologías; custom elements, template y shadow DOM nos permite crear nuevas etiquetas personalizadas con su propio contenido interno sin afectar el exterior y también el exterior no puede afectar directamente la implementación interna de nuestro componente. En el último ejemplo podemos ver como creamos cuatro instancias de nuestro componente simplemente utilizando etiquetas, es decir, reutilizando nuestro componente encapsulado.
En la próxima publicación veremos como implementar más funcionalidad Javascript encapsulada del componente web y también más características muy útiles del shadow DOM como composición, eventos y más estilos. Finalmente veremos los módulos de JS para completar un componente web reutilizable que pueda ser importado en cualquier otra aplicación web.
ES_MX 
EN