Tabla de contenidos
Hoy en día la mayoría de las compañías reivindican que son “Ágiles”, se ha convertido en un estándar. La mayoría de ellas también dicen que construyen software que funciona, sin embargo cada compañía entiende el concepto de una manera diferente. Y aquí reside el problema! En Apiumhub hemos trabajado con desarrollo “Ágil” para varias compañías de diferentes industrias y llegamos a la conclusión que para ser una empresa “Ágil” de verdad, se debería instaurar TDD (Test Driven Development) & CI (Continuous Integration), centradas en software que funciona. Y cuando me refiero a software que funciona, no me refiero únicamente desde un punto de vista funcional, sino que desde la tecnología también, teniendo en cuenta actuación, escalabilidad y efectividad en costes.
Como muchos de vosotros ya sabéis, el desarrollo Ágil se basa en iteración y evolución incremental. La metodología Ágil ayuda a los equipos de desarrollo de software en un ambiente de rápidos cambios a entregar valor a los proyectos construyendo software que funciona. El desarrollo Ágil esta basado en un feedback rápido, mejora continua, flexibilidad y entrega de resultados y entrega de funcionalidad de alta calidad. En el mundo del software, cuando hablamos de la metodología Ágil, automáticamente, hablamos de “pruebas unitarias”, desarrollo guiado por pruebas y integracion continua.
Por ejemplo, usando TDD, los desarrolladores de software crean pruebas unitarias cuando configuran su código para que cada porción testee diversos trozo del codigo de software para asegurarse que las unidades actúan como debido. Además, TDD deja que los equipos eliminen, añadan o editen funcionalidades de una manera mas rapida y efectiva, aplicando diversos test automáticos e iterativos. Dentro del desarrollo de software, los errores son extremadamente frecuentes, TDD es una “obligación” para evitar fallos en etapas más finales y descubrirlos en las fases más iniciales. En TDD, empiezas por escribir el test antes que codificar las nuevas funcionalidades. Entonces escribes el código de producción necesario para que el test lo acepte, y después refactorizas el código para hacerlo mas fácil de mantener. Este método garantiza un feedback inmediato después de que los cambios están hechos, en otras palabras, hace que sea más fácil y rápido encontrar fallos. Este feedback inmediato deja que los desarrolladores de software arreglen los defectos mucho más rápido en comparación a otros métodos, donde el código se testea días más tarde de su implementación. TDD te muestra si el código reacciona como es esperado en tiempo real. Básicamente, te permite ahorrar tiempo y dinero así como tener mas ventajas, ya que lanzas unas funcionalidades de calidad más rápido. Y eso es clave para el éxito en este mundo tecnológico que avanza y cambia tan rápidamente. Además, la implementación en el desarrollo guiado por pruebas es mas dada a concordar con la visión de los product owners cuando hablamos de user stories. Los tests son desarrollados fácilmente desde los criterios acordados. TDD garantiza que la versión final coincida con las necesidades del los propietarios del proyecto, lo que es un gran valor en este mundo de desarrollo de software. Además, lo que nos gusta aquí en Apiumhub, es que TDD previene que se tenga componentes o diseños no queridos en el producto. Define las caracteristicas exactamente. Hace que sea fácil encontrar código redundante, detecta y elimina tareas innecesarias de desarrollo. TDD va de la mano con “working y Agile” software. Simplifica y acelera el proceso de desarrollo del software que funciona, haciendo posible que se lance un producto escalable mucho más rápido y con un MVP sólido.
La integracion continua, creemos que es una parte crucial en el desarrollo de software “Agil”. Y ayuda a los desarrolladores a construir software que funciona, ya que organiza el proceso de una manera funcional con historias de usuario y sprints. Cada vez, cuando los desarrolladores añaden alguna función a su codigo, puede añadirse al grupo de test que se está trabajando cuando es integrado. Les permite asegurarse que las nuevas adiciones no rompan el funcionamiento de los elementos existentes, y desarrolladores cuyo codigo “rompe el conjunto” puede notificarse rápidamente. Además, he de decir que somos grandes fans de Martin Fowler, siempre leemos su blog y apoyamos su punto de vista. El dice que integracion continua es una práctica de desarrollo de software que requiere que los miembros del equipo integren el código dentro de un repositorio frequentemente compartido. La idea es que cada persona integre al menos cada dia, lo que puede guiar a integraciones múltiples cada dia. Además, lo normal es que diversas personas o incluso múltiples equipos trabajen en el mismo proyecto y la integración continua les ayuda a prevenir problemas de integración. Estas integraciones están verificadas por unas construcciones automáticas que dirigen test de regresión para detectar errores de integración tan rápido como sea posible. Las normas C.I dicen que los programadores nunca deben dejar nada sin integrar al final del dia. Por lo que, los equipos siempre saben en lo que sus miembros del equipo han trabajado, como lo han hecho y se aseguran de que su codigo funciona y esta integrado correctamente e incluso si algo no se integra correctamente, es fácil de resolver. Integrar un código frecuentemente reduce el riesgo de fracaso, o gastar demasiado dinero en volver a hacer el código. Normalmente, una vez los miembros del equipo han implementado la integración continua, nunca vuelven atrás, se quedan con C.I, ya que significa menos problemas de integración y el desarrollo de software que funciona es más rápido.
En la producción, hay muchas dificultades y problemas, siempre. Pero nosotros pensamos que una buena manera de medir el progreso es software que funciona. ¿Que me refiero con esto? Software que funciona es un software testeado que da valor al consumidor final, valor que funciona bien, incluso mejor de lo esperado, pero nunca peor! En otras palabras, software que funciona es un software completamente integrado, testeado y listo para ser enviado hacia los clientes o producción. Lo único que cuenta es si está completado, piezas completamente funcionales del producto deseado – software que funciona.
Para construir software que funciona se han de seguir ciertas reglas:
- ¿No tienes lo planeado para finalizar? Entonces quita cantidad, pero hazlo bien. Haz la mitad, pero hazlo bien.
- Si ves defectos en tu codigo, testéalo lo antes posible.
- Si es complicado trabajar con tu codigo, vuelvelo a refactorizar a medida que avanzas.
- Si es complicado de integrar, divídelo en pequeñas piezas e integra más frecuente.
- Si entregas un proyecto a los clientes y no les gusta, habla con ellos más a menudo.
Entonces, que te puede ayudar a construir software que funciona? Tu compromiso y entrega, poniendo calidad en tu trabajo, participación activa con el cliente, buen entendimiento de lo trabajado, sprints de 2 semanas, TDD, CI, pensar en actuación, escalabilidad y reducción de costes.
Y una vez hayas construido software que funciona, asegurate que lo utilizas de manera adecuada.
Go live checklist
- Asegurate de que todos los tests y funcionalidades están en verde. Si no pasan el filtro, no está construido
- Una vez tenemos el artefacto, asegurate de que todos los criterios de aceptación son los mismos. Esto es importante cuando se habla del formato de “historia de usuario”
- Si todas los criterios estan OK, testea las funcionalidades mas principales de la app manualmente.
- La lógica de flujos de usuarios están cubiertas por tests de funcionalidad automáticos pero siempre puede aparecer un pequeño error de última hora, así que QA manual es inevitable.
Espero que este artículo haya sido de utilidad! Aquí en Apiumhub, creemos fuertemente que software que funciona es clave para trabajar en un buen proyecto de software.
Suscríbete a nuestro newsletter para estar al día de los eventos, meet ups y demás artículos!
Si te ha gustado este artículo, puede que te interese:
