18

Jan

Publicado por: Xavi Hidalgo | Agile | product owner | software development

Habilidades necesarias para construir software de calidad

El ser humano tiene la tendencia de explicar la realidad en sus propios términos. Y esto se ve reflejado cuando se habla de calidad en software. Por ejemplo, Para los antiguos, el sol que salía por la mañana era un dios que los bañaba en sus rayos. Para el hombre ilustrado del renacimiento dentro de su concepción heliocéntrica era el centro del universo. Para un científico contemporáneo, se trata de una bola de gas en precario equilibrio entre sus fuerzas explosivas que lo empuja hacia fuera y la fuerza de la gravedad, que lo hace replegarse en sí mismo. Un mismo fenómeno puede tener explicaciones diferentes y a veces antagónicas, según quien lo aclare.

Construyendo un software que funcione

Si hablamos de software, ¿Cuál es la razón por la que algunos profesionales, equipos o empresas entregan software de calidad extrema?

Con las disculpas de mis compañeros, diré que los responsables de control de calidad podrán expresar que la entrega ha sido perfecta gracias a un control exhaustivo de la calidad funcional. También por contar con portentos tecnológicos y sistema de automatización de test funcional.

El equipo de desarrollo puede también afirmar que el motivo principal del éxito es, sin duda, su gran pericia a la hora de desarrollar software. Esto será gracias al uso de arquitecturas modernas, poco verbosas y con patrones arquitecturales y de diseño impecables. El Product Owner puede argumentar que es gracias a la gestión del backlog, dado que las historias de usuario han sido redactadas con unos criterios muy claros en cuestión de granularidad y concreción.

Un gestor de proyecto nos dirá que los recursos y los hitos están gestionados a la perfección, y los compañeros de recursos humanos nos pueden explicar que gracias a su política de contratación y a sus sistemas continuos de formación se ha conseguido un grado de excelencia tal, que hace que las entregas sean perfectas. Igual los compañeros de devops, los cuadros intermedios… imagino que si la empresa tiene un psicólogo o coach, también este se podría atribuir su parte de éxito como artífice de la estabilidad emocional, el foco y motivación de los miembros de los equipos.

A la vista de estas suposiciones parece claro que como dijo en alguna ocasión Kent Beck, una buena respuesta a una pregunta compleja pasa muchas veces por contestar “depende”. Y es cierto. Este ejercicio previo de imaginar a cada uno de los miembros esgrimiendo motivos de su participación en el éxito es, a parte de un divertimento, una manera de ilustrar la probabilidad de que todos tengan algo de razón.

Ciertamente se pone de manifiesto que con toda probabilidad, el éxito medido en el grado de excelencia de la entrega y la proximidad con el concepto “working-software” es un éxito
compartido.

En base a mi experiencia, pienso que la capacidad de producir “software que funciona” viene determinada por la capacidad de integrar diferentes disciplinas, trabajando al unísono con un mismo objetivo compartido por todos.

Desarrollo Agile

No es que sea imprescindible, pero tener un método de trabajo enfocado en la producción es tendencia en este momento. El agilismo o las metodologías ágiles vinieron para quedarse. Repito, no es una condición sine qua non, pero si aplicamos conceptos de Agile como el DRY, o si trabajamos en interacciones donde finalmente entregamos una parte del producto que se puede usar, estamos industrializando el proceso productivo que es la generación de software.

Un proceso que se repite es un proceso que se puede medir, por medio de indicadores o KPIs. Del mismo modo, un proceso repetitivo nos permite encontrar puntos de mejora (mejora continua) y esto es básico para refinar el equipo y la manera en la que trabajan.

Tener una buena metodología Agile es determinante en muchos casos.

 

También te puede interesar: Mejora continua en el desarrollo de software

 

Inteligencia social

Lo decía Tom DeMarco en su aclamado libro “peopleware“: se trata de personas, no de código. Hoy en día, las empresas tecnológicas no compiten por clientes, compiten por desarrolladores y profesionales tecnológicos en general. Si consigues tener un equipo remando en la misma dirección estarás consiguiendo el 90% de lo que necesitas para entregar productos digitales increíbles.

Se sabe que el equipo es quizás lo más importante. Esto lo vemos en las startups en donde los inversores han puesto en segundo término al producto.

El razonamiento es claro… si un equipo es bueno y el producto no vale, me va a costar muy poco hacer pivotar el producto para encontrar mi nicho de mercado. En cambio, si el producto es muy bueno pero el equipo no es capaz de reaccionar a los cambios, las probabilidades de que la cosa prospere son muy pequeñas.

Definición del estado “finalizado”

Muchos procesos de desarrollo de producto digital fallan porque el equipo no tiene bien definido cuando acaba su trabajo en una parte de ciclo.

Pongamos por ejemplo a un programador: ¿Cuándo acaba su trabajo en el producto?, ¿Cuándo sube los cambios al repositorio de código?, ¿Cuándo el cliente lo consigue ver?, ¿Cuándo está en el servidor de pruebas?, ¿Cuándo el equipo de test valida que lo que ha hecho es lo que el gestor de producto espera?

Siempre será diferente para cada equipo pero eso sí, tiene que quedar muy claro para todos los integrantes del grupo.

Integración continua

Hay (creo) alguna falacia en las metodologías Agile si las miramos desde un prisma muy pragmático. Se habla constantemente de iteraciones que duran un determinado tiempo fijo, en muchas ocasiones hablamos de sprints de dos semanas. La falacia que comento es pretender que sin automatizar los procesos repetitivos (subida al servidor de pruebas, compilación y otras actividades que tienen muchas repeticiones) vamos a poder efectivamente hacer iteraciones de 2 semanas.

Alguien que no esté de acuerdo puede argumentar que igualmente es una metodología Agile o Scrum (no se debe de confundir un framework como Scrum con Agile).

Mi posición en este debate, muy productivo por otro lado, es que si no se automatizan procesos, el agile es un agile “anémico”. Yo prefiero decir que en este caso “no es agile” o “no hay agile”.

Si hacemos iteraciones o sprints de dos semanas pero nuestra velocidad es muy baja porque estamos realizando manualmente tareas que podrían estar fácilmente automatizadas, particularmente opino que no estamos haciendo Agile. Entiendo igualmente que la integración continua no es más que automatizar los procesos de desarrollo.

Es en realidad, muchas cosas más. Es estar integrados. Es decir, que significa que todo el equipo está trabajando sobre la misma versión de código (rama o branch). También propongo el uso de una sola rama, en detrimento de algunas políticas de branch como Feature Branch o Developer Branch.

Gestión de la calidad

Durante los últimos años hemos vivido una consolidación de las tecnologías de testing. Testear es comprobar que la aplicación o el producto hace lo que se espera que haga. Testear es una ciencia y los tests se engloban en familias o “suites” de test. En este escenario, se habla de test de performance, o de regresión, de avalancha, de contrato, de integración…

Dejo a un lado los tests que realizan los programadores sobre el código de manera unitaria, es decir, los tests que no solamente me sirven para verificar que las funciones y demás componentes que conforman el software o código fuente están correctamente realizados. El test unitario, es parte esencial de una metodología de desarrollo llamada TDD (Test Driven Development), en donde el test se transforma en una manera efectiva de diseñar código.

Si nos referimos únicamente al test funcional de la aplicación, aquellas partes donde no es necesario conocer el código fuente y se testea la aplicación final, estamos hablando de test funcional.

Una correcta política de test funcional es la pieza clave que garantiza que el producto entregado funciona.

Transparencia con el cliente

En un gran número de proyectos los problemas pueden venir del hecho de comunicar poco o mal al cliente. El cliente debe formar parte activa del desarrollo, asistiendo a las reuniones de planificación y demo, donde se enseña la funcionalidad que se ha desarrollado en el último sprint.

Para desarrollar productos que funcionan es necesario incluir al cliente, comunicar correctamente y entender su feedback. Gestionar las expectativas y saber manejarlas es de extrema importancia.

 

También te puede interesar: El Product Owner en el desarrollo de working software

Gestión del conocimiento

Un profesional hoy en día está obligado a aprender. Es probablemente su única responsabilidad y por lo tanto, será su salvación.

Calidad, fusión de los elementos

Después de conocer estos puntos ya debes de haber comprendido las connotaciones que se desprenden de usar el término “working software” y los factores implicados, capaces de restar o sumar cualidades en el resultado final de un producto digital y su interfaz.

Puede ser un concepto muy amplio, pero que debe estar focalizado en producir aplicaciones o servicios que funcionen, es decir, que sean capaces de aportar valor al usuario.

Artículos relacionados:

 

Descubriendo BDD: Desarrollo guiado por comportamiento

 

Manual del buen desarrollador: Principios básicos de eXtreme Programming

 

Qué es Domain-Driven Design (DDD) y qué aporta al desarrollo de software

 

 

 

CTA-interesting-justdigital

 

Barcelona
Passeig Gaiolà 13
+34 933 801 144
Lleida
Carrer Agustins 7
+34 973 988 222
Andorra
(Escaldes-Engordany)
Parc de la Mola 10, AD700
Bogota
Carrera 9A #99-07 Piso 9. Despacho 02
Torre la Equidad