11 formas de acelerar su proyecto de software

0
29

Claro, cada líder y cliente de TI quiere que cada proyecto de software se produzca más rápido. Pero el desarrollo acelerado puede conducir a defectos en los códigos, pruebas de mala calidad, soluciones incompletas o, lo que es peor, software inseguro. Pero, aunque nadie quiere un proyecto de software fallido, a veces ciertos contextos -condiciones del mercado, necesidades comerciales, ventanas de oportunidad- pueden justificar en alguna medida el abandono de ciertas condiciones en favor de la velocidad.

El desarrollo de software no es solo un esfuerzo lógico. También es un arte y una parte integral de la estrategia comercial de muchas organizaciones. En algún lugar dentro de esas facetas superpuestas se encuentra la posibilidad de ajustar un proceso de desarrollo más eficiente, si se hace de manera efectiva, justa, simple y segura. Solo tiene que saber que dar a cambio y tomar decisiones que favorezcan la mejora del proyecto en lugar de desarrollar el sueño del software perfecto.

Controlar los sueños de las partes interesadas
Todos quieren input, y los representantes del equipo de marketing, el departamento de entregas y contabilidad acuden a la sala de reuniones con grandes sueños. El truco es encontrar los sueños que son más simples de cumplir. En una reunión milagrosa, mi equipo de software descubrió que solo por agregar ciertos valores predeterminados a un campo en un formulario ahorraría a los encargados de los datos millones de horas de trabajo. Había cientos de agentes de ventas llenando el formulario, desde cero, miles de veces al día. Algunos caracteres adicionales en el HTML y fuimos tratados como genios.

Hacer que las partes interesadas mantengan sus pies en el suelo ayuda a controlar el alcance de un proyecto. Si puede enfocar a las partes interesadas en funciones y mejoras que son más pequeñas y de gran valor, las casillas de verificación se completarán mucho más rápido.

Evite que los desarrolladores sueñen en grande
Pero no son solo los ejecutivos los que pueden dejarse llevar. Los desarrolladores también necesitan mantener los pies en el suelo. Para cada elemento en la lista de proyectos, habrá un desarrollador que lo verá como una oportunidad para finalmente probar alguna palabra de moda que sea inteligente, nueva e increíblemente lenta. ¿Hay dos columnas desalineadas en la pantalla? Ahora es el momento de reescribir toda la pila en funciones puras que implementan un descenso de potencia de gradiente múltiple que optimiza los algoritmos de aprendizaje cuántico.

Si bien el entusiasmo del desarrollador a menudo es vital para lograr un avance rápido, es primordial asegurarse de que el entusiasmo se canalice hacia un objetivo simple.

Reduzca funciones
Recortar los requerimientos parece un juego de vagos. Después de todo, es fácil hacer todo más rápido si redefine «todo” para que sea un conjunto más pequeño.

Pero a veces es necesario y útil enfocar al equipo. El enfoque ingenioso es asegurarse de que la base sea lo suficientemente sólida como para manejar las funciones omitidas en el futuro. Por ejemplo, asegúrese de que el esquema de la base de datos prevea algunas de las mejoras que alguien quiere agregar en una iteración posterior. Si solo significa ajustar un poco el esquema ahora, también puede ahorrar tiempo cuando regrese a las funciones que retuvo en esta ronda.

Pruebas optimizadas
Uno de los desafíos de implementar código es probarlo antes de que entre en funcionamiento. Últimamente, la tendencia ha sido dividir todo en proyectos más pequeños que pueden moverse de forma independiente. Si cada proyecto debe ser probado de manera independiente también, bueno, eso significa muchas más pruebas. Algunas de las nuevas arquitecturas de microservicios llenas de docenas de microproyectos deben probarse docenas de veces.

No puede deshacerse de la necesidad de probar, pero un truco es probar varios proyectos que funcionan juntos al mismo tiempo. A veces, agrupar varias partes puede eliminar la necesidad de probarlas de forma independiente.

Simplifique la arquitectura
Si va a recortar funciones y dejar algo de trabajo para más adelante, a veces puede repensar la arquitectura al mismo tiempo. A veces no.

Si las funciones pueden volver el próximo trimestre o incluso el próximo año, es mejor dejar las bases en su lugar. Pero si no son esenciales, puede ser extremadamente liberador limpiar grandes partes de la arquitectura.

Ajustar la garantía de desempeño
Cuando los tiempos eran inestables, todos querían respuestas en milisegundos mientras se aseguraban de que los datos se replicaran en tres centros de datos separados geográficamente, en caso de que un huracán y un terremoto golpearan simultáneamente. ¿Quién no desea perfección?

En general, el alto rendimiento significa muchas capas adicionales de almacenamiento en caché, balanceo de carga y replicación, y esas capas adicionales requieren tiempo para crear, configurar, depurar y mantener. Una de las formas más sencillas de reducir el tiempo de desarrollo es convencer a las partes interesadas de que estén dispuestas a relajarse si una pantalla tarda un poco más en actualizarse o -en el peor de los casos- algunas de sus partes desaparecen en una falla. No todos los proyectos requieren tanta precisión o confiabilidad como la cirugía cerebral.

Aproveche el código existente

La forma más fácil de gastar más tiempo es explorar una nueva tecnología. Sí, es importante a largo plazo invertir en la siguiente generación, pero el momento no es cuando alguien está golpeando la mesa pidiendo que un proceso termine más rápido. Usar el mismo lenguaje y base de datos que usó en los últimos 12 proyectos será más rápido y sencillo. Se moverá más rápido y, a veces, encontrará fragmentos de código que podrá reutilizar. No solo eso, sino que mantendrá una consistencia que facilita a los desarrolladores moverse entre proyectos.

Asuma la deuda técnica
A los desarrolladores les gusta hablar de «deuda técnica” cuando quieren que se haga algo. Al comprometerse con una solución limitada o rápida ahora, los desarrolladores pueden dejar el trabajo de arreglar o llenar los vacíos para el futuro. Es un concepto real que es importante tener en cuenta, pero a veces las personas lo invocan cuando quieren manipular el proceso.

Algunas deudas técnicas están bien. No siempre es necesario utilizar las últimas bases de datos o la tecnología de lenguaje más reciente. A veces es posible omitir tres o cuatro generaciones de tecnología milagrosa e ir directamente a la versión más reciente. Saltarse obstáculos puede ahorrar muchos dolores de cabeza y malas noches.

Existe un arte en este juego y no está exento de peligros. Pero muchas veces el espectro de la deuda técnica es mucho peor que la realidad de omitir algunas generaciones de actualizaciones.

Fuente abierta
Demasiados proyectos tienen demasiado código personalizado en ellos. Si está tratando de lograr algo, existe una buena posibilidad de que alguien más tenga el mismo dolor de cabeza. A veces, esa otra persona u organización ha comenzado un proyecto de código abierto y ahora es su oportunidad de unir fuerzas.

El código abierto no es una panacea. No existe tal cosa como un almuerzo gratis. A menudo necesitará hacer compromisos y trabajar con otros equipos para converger en un código que funcione bien para todos. Cuando el proceso funciona bien, solo pasará una parte del tiempo contribuyendo al proyecto de código abierto y todos prosperarán.

Use herramientas básicas
Muchos proyectos se pueden lograr con herramientas estándar. Es sorprendente lo que se puede construir con un formulario web estándar de, por ejemplo, Drupal, Formularios de Google o Survey Monkey, que vuelca los datos en una hoja de cálculo que realiza el análisis. No es impecable. Incluso podría no ser llamado «codificación” por la Liga de Defensa de Programadores. Aunque, si ofrece la respuesta de manera confiable y reutilizable, puede ser la forma más rápida de lograr un gran proyecto de desarrollo.

Sea realista
Todos soñamos con construir una página web que se vuelva viral, por lo que planeamos manejar la carga más extrema. He visto a arquitectos cuidadosos describir sus sistemas de tres niveles con balanceadores de carga y bases de datos replicadas en todas partes para apoyar un proyecto que podría atender a cien personas por día. No sería un problema si aumentar la escala con gracia fuera fácil, pero agregar estas capas aumenta la complejidad del proyecto, prolonga la construcción y complica el mantenimiento. Traer nuevos programadores es mucho más difícil y solucionar incluso el problema más pequeño puede requerir largas reuniones de equipo. Es cierto que algunas de las herramientas sin servidor más nuevas, como Google App Engine, simplifican el crecimiento de la escala, pero existen cosas que dar a cambio en cuanto a complejidad y costo.

Los buenos ingenieros anticipan problemas extraños que podrían surgir en el futuro. Pero una buena ingeniería de costos requiere ser realista sobre las probabilidades y, tal vez, decidir aceptar un mal desempeño o incluso un fracaso cuando estos valores atípicos atacan.

Peter Wayner, CIO.com