6 cambios culturales para que desarrollar software no sea una pesadilla

En un dos por tres, los proyectos de desarrollo de software pueden transformarse en una pesadilla de nunca acabar.

Generalmente -y con justa razón- culpamos a la tecnología que tenemos disponible de esta
pesadilla, pero olvidamos que el mayor problema se encuentra en la parte humana y de procesos. La cultura de trabajo en silos, tan arraigada en las empresas, dificulta la comunicación, la interacción y la manera en que se reparten y comparten las responsabilidades entre desarrollo y operaciones.

Frente a este escenario, se hace primordial un cambio de cultura basado en las personas y no solamente en las herramientas tecnológicas.

La cultura DevOps pretende unir dos mundos históricamente separados -desarrollo y operaciones- introduciendo cambios culturales en las personas y en los procesos.

Te compartimos las primeras 3 prácticas de la cultura DevOps que podrían cambiar tu mirada sobre el desarrollo de software:

1. Toma de requerimientos.
El entregable final nunca es igual al requerimiento inicial, y muchas veces, cada corrección o modificación que pide el negocio es como un balde de agua fría.

La cultura DevOps se basa principalmente en el aprendizaje y la mejora constante, por lo que las modificaciones son una parte natural y esencial para perfeccionar cualquier desarrollo.

Mitigar este “problema” no se basa en eliminar las correcciones o modificaciones. Al contrario, la recomendación es hacer que cada requerimiento y sus modificaciones sean algo trazable y que la documentación de especificaciones, además de estar en lenguaje entendible para todos los involucrados, se realice en un sistema de uso común, disponible y cercano a la parte operativa que plasmará la iniciativa.

2. Planificación y estimación.
Cuando las estimaciones de duración y costo de los proyectos son demasiado optimistas, se crean expectativas que después son muy difíciles de cumplir, y luego, empiezan los problemas con el negocio.

En una cultura DevOps, lo primero es aprender a separar tareas y enseñar al negocio algunas cosas que no tienen por qué saber y que si o si se deben considerar.
Por ejemplo, se deben separar el diseño y las implicancias técnicas del desarrollo de software, principalmente, por dos razones: el negocio no sabe lo que implica desarrollar, pero si tiene muy claro lo que necesita, cuando lo necesita y la prioridad.

Un especialista con experiencia en cultura DevOps, será capaz de plasmar el diseño, pero también de identificar las tareas operativas que conlleva y que deberán ser desarrolladas, realizando estimaciones con expectativas realistas.

3. Desarrollo.
Si buscas que los requisitos nunca cambien, lo mejor es dedicarse a otra cosa. En el área TI, especialmente, los objetivos van cambiando constantemente, lo que implica modificaciones en cualquier desarrollo.

Si bien la cultura DevOps entrega agilidad metodológica, esta debe estar acompañada de
tecnología que ayude a que todas las partes del proceso trabajen de manera ágil.

Ejemplos clásicos que restan agilidad son:

  • Se siguen usando lenguajes obsoletos.
  • Puedes esperar toda la vida un ambiente.
  • Se realizan pruebas manuales.

En una cultura DevOps, estas tareas –y muchas más- son vistas como un todo para entregar agilidad en todo el proceso. Ir cambiando parcialmente la tecnología utilizada en algunos casos es una de las cosas que se pueden realizar para sumar velocidad de entrega.

La capacidad de procesamiento en la nube que existe hoy permite levantar ambientes de forma atómica. Tenemos prácticas como infraestructura de código que permiten acelerar mucho las cosas.

Además, apuntar hacia el Code Coverage y contar con buenas métricas de análisis de código estático dentro del ciclo de vida de las aplicaciones, resuelve gran parte de las problemáticas de desarrollo a futuro ……