Generalmente en el norte del país, los departamentos de TI no sobrepasan los 5 empleados para TI, representado por el 69,2 % del total, y el departamentos de TI que tengan entre 50 a 100 empleados está representado por el 7,7 %. Entonces, los grupos pequeños de profesionales de TI tienen mayor presencia y generalmente necesitan multiplicarse para cubrir las necesidades del negocio. En la mayoría de casos existe otro sub grupo dentro del departamento de TI dedicado al desarrollo de software, estos son: los programadores, y muchas veces el directorio o dueños de negocio no se percatan que estos programadores son insuficientes para cubrir todo un proceso correcto de desarrollo de software, y empujan a que estos programadores tengan el papel de un jugador de fútbol que sea arquero, defensa, medio y delantero, todo a la vez, además de exigir que sean magos es decir por ejemplo solicitudes semejantes a que nueve mujeres den a luz a un niño en un mes. ¿Cómo poner paños fríos a este asunto?

¿Qué y cómo mejorar?

Hay que mejorar el pensamiento del gerente sobre el desarrollo de soluciones en la organización.Para esto debes preparar los datos necesarios para convencer a los gerentes o dueños de negocio que el modelo en ejecución traerá muchas malas consecuencias: como falta de trazabilidad ante una detección de error, regresión de versiones de las aplicaciones, juez y parte ante la programación de funcionalidad, falta de manos ante una confusión amplia en la infraestructura, mala gestión de riesgos, etc.

¿Cuál es lo mínimo que debo tener?

Generalmente el ciclo de desarrollo de software debe cubrir el Análisis, Diseño, Programación, Evaluación y Despliegue. Se recomienda que Evaluación (Aseguramiento de la calidad de software o mejor conocido como QA) sea ejecutado por una persona diferente que realizó el Análisis, Diseño y Programación, estos últimos pueden ser ejecutados por una sola persona, ya que están muy amarrados, el despliegue o instalación del sistema podría ser realizado por la misma persona de ADP, o por un tercero, pero este tercero debe tener conocimientos sólidos de la infraestructura y la configuración de la propuesta desarrollada.

¿SCRUM, ISO 29110, O combinación de ambos?

Después de acudir a varios eventos y estar al tanto sobre qué estándares, marcos de trabajo, normas o buenas prácticas se deben aplicar en una organización en particular, siempre se recomienda que se analice el campo de desarrollo o mejor dicho, el área de TI de la organización. Dependiendo de tu organización deberás buscar la mejor solución para tu objetivo. Se podría rescatar que en SCRUM existe la agilidad como escudo principal, mientras que en ISO 29110 la documentación rápida y orden es la lanza de guerra, la combinación de ambos podría ser soportada por una herramienta software online como asana o trello, ambos basados en kanban, recordemos que lo visual es lo más intuitivos para el avance en un equipo pequeño. Ahora, toda tus plantillas exigidas por la ISO 29110 podrían estar controlados por una macro de word o crear tu propio software que apoye tus plantillas exigidas por esta ISO.

Consejos de AudIT

Se recomienda estudiar y poner en práctica esta metodología y norma, y conforme se va implementando consultar a tu equipo desarrollo si se tiene la comodidad plena de la implementación propuesta, y revisar los ajustes que presente y resultados consecuentes, sin salirse del objetivo principal: Orden, agilidad y calidad de software.
En AudIT contamos con Ingenieros profesionales que podrán supervisar tu área de desarrollo de software y constatar en qué nivel de la ISO 29110 y SCRUM se encuentran, tras ello elaborar un plan para obtener los mejores resultados a corto y largo plazo en la mejora de tu área de desarrollo de software.