¿Cuál es el enemigo del buen desarrollo de software?

May 10 2022
Lo que no ayuda al desarrollo de software, lo perjudica
“El mayor truco que el diablo jamás jugó fue convencer al mundo de que crear software era fácil” Los enemigos brindan inspiración y enfoque, brindan un objetivo al que apuntar y la motivación para lograrlo. Cuando hay alguien a quien vencer, trabajamos más duro para hacerlo.
equipo de desarrollo de software

“El truco más grande que ha jugado el diablo fue convencer al mundo de que crear software era fácil

Los enemigos proporcionan inspiración y enfoque, dan un objetivo al que apuntar y motivación para lograrlo. Cuando hay alguien a quien vencer, trabajamos más duro para hacerlo. Los equipos se esfuerzan más para vencer a sus rivales.

Liverpool y Man City están involucrados en una batalla semanal para ver quién ganará la liga principal.

¿Cuál es el enemigo del desarrollo de software? ¿Tiene un enemigo? El enfoque del proyecto de software, el equipo de desarrollo y los desarrolladores está en crear y ayudar.

Poca gente se detiene a pensar en lo que nos frena, en lo que lo hace más difícil.

¿Qué detiene, dificulta o perjudica el desarrollo de software? Puede ser más fácil dejar de hacer cosas estúpidas, evitar errores que concentrarse en crear un gran software.

El enemigo son los desarrolladores perezosos.

Las personas que no entienden el desarrollo de software creen que los proyectos de software fallan porque los desarrolladores no trabajan lo suficiente o cometen errores debido a la falta de concentración.

Si todos trabajan duro, el software se creará a tiempo.

si todos los problemas de los proyectos de software pudieran resolverse con un esfuerzo adicional, casi nunca se producirían proyectos tardíos o fallidos. La verdad es que veo gente trabajando super largas horas en proyectos y aun así llegando tarde. Veo proyectos agregando más desarrolladores y haciendo el proyecto más tarde.

A pesar de toda la evidencia, el liderazgo no puede alejarse de la idea, el problema fundamental es la falta de esfuerzo o la falta de personas/desarrolladores.

No puede resolver sus problemas en el desarrollo de software. La creación de software de baja calidad lo perjudicará más adelante a medida que aumente la complejidad y la deuda técnica.

Me uní a un proyecto con un gran equipo de desarrollo trabajando duro. Hubo muchos desarrolladores, consultores, pymes y líderes comprometidos. Todos trabajaban horas extras, pero el proyecto se estaba atrasando cada vez más. DevOps con implementaciones automatizadas, desarrolladores experimentados.

¿Cómo podría estar retrocediendo con todos estos recursos?

El problema era la falta de habilidad, conocimiento y experiencia. Las decisiones de liderazgo tenían un enfoque a corto plazo, creaban código de baja calidad y deuda técnica.

Alguien tenía el equipo de desarrollo para darle al cliente lo que quería y lo que quería era seguir cambiando los requisitos.

Lo que me llamó la atención fue que todos en el proyecto estaban trabajando duro y trabajando muchas horas. El proyecto fue un completo caos.

Las suposiciones son errores creados por los desarrolladores al no aclarar los requisitos. En lugar de aclarar cuáles son los requisitos y comprender cómo debería funcionar el software. Los desarrolladores, en cambio, adivinan cómo debería funcionar y luego construyen el software sobre cómo ELLOS creen que debería funcionar.

Las suposiciones son lagunas en los requisitos y las conjeturas que hacen los desarrolladores pueden ser incorrectas. No solo la suposición puede ser incorrecta, sino que cualquier código construido sobre la suposición.

Las suposiciones generalmente se encuentran tarde en el proceso cuando los usuarios prueban el software y descubren que hace algo extraño que nunca le pidieron que hiciera.

Pensamiento a corto plazo

Pensar a corto plazo, tomar atajos, tratar el síntoma hace que el desarrollo de software sea más difícil. Elegir la opción fácil da la ilusión de progreso pero empuja el problema a ir más tarde o a otro lugar.

El software es un proceso largo y la calidad es la forma más rápida de crear software y ponerlo en producción. El pensamiento a corto plazo es como poner una bolsa de basura contra una ventana temporalmente y luego encontrarla todavía allí cuando empiezas a vivir. Más tarde, un ladrón salta por la ventana y roba algo valioso.

No escuchar a los expertos

La creación de software es una colaboración entre expertos empresariales (usuarios) y expertos técnicos (desarrolladores). Cuando cualquiera de las partes le dice a la otra parte qué hacer o una parte domina los procedimientos, se obtienen malos resultados.

  • Desarrolladores que crean un software basado en la funcionalidad técnica
  • Los clientes les dicen a los desarrolladores qué solución técnica hacer
  • Desarrolladores que hacen suposiciones, no aclaran los requisitos
  • Liderazgo/Administración tomando atajos

Hay una razón por la que paga a los expertos para que hagan un trabajo porque saben lo que están haciendo y entienden su área de especialización a un nivel que los novatos no entienden. Cuando los superes, prepárate para el desastre.

Requisitos deficientes

Es imposible obtener todos los requisitos por adelantado y es más rápido obtener la mayoría de los requisitos. Comience a crear software para descubrir los detalles que no pudo ver al principio.

Cuando cambia los requisitos, el plan debe cambiar para adaptarse al trabajo adicional.

Los requisitos cambiarán, pero necesita las personas adecuadas para obtener los requisitos básicos por adelantado. Los desarrolladores solo pueden construir lo que se les dice que construyan, si hay un problema con la calidad de la precisión de los requisitos, el proyecto se ralentizará.

Los requisitos son un área clave de un proyecto. Siempre cambian, pero un proyecto de software puede hacer mucho para obtener buenos requisitos, de modo que los desarrolladores puedan construir y los probadores puedan probar.

La disciplina y la orientación del liderazgo deben dar la dirección de que los requisitos deben TENERSE, no es bueno tenerlos. El software debe ser lo más simple posible y contener solo lo que se requiere.

El equipo de desarrollo de software

La creación de software es técnica, pero la velocidad y la calidad del software creado dependerán de la calidad del equipo de desarrollo y de los desarrolladores que lo componen.

Nunca he visto un proyecto de software exitoso que no tuviera buenas personas en los roles principales (desarrolladores principales, arquitecto de soluciones, DevOps, etc.). Si los miembros superiores no son buenos, es más probable que haya un desastre que un éxito.

El software es creado por personas y el equipo de desarrollo necesita trabajar con otras personas en el proyecto. Todo el mundo en un buen equipo de desarrollo conoce el proceso y constantemente tienen un progreso fluido.

El equipo de desarrollo necesita experiencia en las habilidades adecuadas; de lo contrario, cometerán errores mientras aprenden.

Deuda técnica

La mejor forma de gestionar la deuda técnica es no añadirla. Las mejores prácticas, la automatización, las revisiones de código, los estándares y los procesos ayudan a minimizar la deuda técnica.

Si no gestiona la deuda técnica, después de un buen comienzo, el proyecto tendrá problemas y se ralentizará.

Falta de DevOps

Si algo se puede automatizar, debería hacerlo. Los desarrolladores son recursos costosos que deben realizar actividades que puedan automatizarse.

Las actividades manuales son aburridas, propensas a errores y más lentas. DevOps ayuda a crear comentarios rápidos y permite que el equipo de desarrollo se recupere e implemente rápidamente.

Si algo es difícil, los desarrolladores evitarán hacerlo. Las implementaciones manuales sin devops ocurren menos. Esto reduce el tiempo y la frecuencia de la retroalimentación.

Retroalimentación lenta o nula

La retroalimentación sobre los requisitos, el software y otras actividades es vital para cambiar lo incorrecto por lo correcto.

La retroalimentación es

  • Requisitos de firma
  • Revisiones de código
  • Pruebas unitarias
  • Pruebas automatizadas
  • Canalizaciones de DevOps
  • Construye
  • Despliegues nocturnos
  • Población

Cuanto mayor sea la demora con la retroalimentación, mayor será el impacto que puede tener porque pronto se construirán otras cosas y el efecto del cambio crecerá.

Falta de tiempo

La mejor manera de hacer que un equipo de desarrollo de software cree software con errores de baja calidad es apresurarlos.

Una forma garantizada de despertar emociones, estresar a las personas, aumentar los errores es establecer plazos ajustados y hacer que todos se apresuren.

El objetivo es crear el software adecuado y de calidad. Cuanta más gente se apresure, menos probable es que esto suceda.

Liderazgo

Un buen equipo de desarrollo no puede vencer a un mal liderazgo

La toma de decisiones lenta, la mala decisión, no escuchar, la mala gobernanza y el cambio de prioridades pueden llevar un proyecto al desastre.

El mayor peligro son las decisiones a corto plazo, el cambio de prioridades y las múltiples sesiones de replanificación.

Los proyectos de software son máquinas de decisión, se requerirá liderazgo para tomar muchas decisiones para abordar los muchos problemas que surgen. Deben tener los expertos para ayudarlos en el proyecto, depende si los escuchan.

Conclusión

El enemigo del desarrollo de software y los desarrolladores no es una persona, un equipo o cualquier parte del enfoque.

Hacer cualquier actividad con mucha gente necesita liderazgo, estándares y procesos lógicos. Un equipo de desarrollo de software eficiente hace que la creación de software parezca simple, a pesar de que los problemas ocurren semanalmente.

En un buen equipo de desarrollo de software, todo parece obvio y todos saben qué hacer. Un proyecto de software efectivo tiene diferentes equipos/personas haciendo su papel y trabajando juntos en armonía.

Un proyecto de software que va mal es un caos. Nadie sabe lo que está haciendo o lo que hacen los demás. Hay pánico, reuniones de emergencia y conflicto, mientras las personas luchan entre sí y procesan.

Es más fácil evitar errores o actividades que perjudiquen a un equipo de desarrollo de software que hacer grandes cosas. Si evita los errores y logra un progreso constante, la mayoría de la gente lo aceptará. Le dará tiempo, confianza y buena voluntad para mejorar en el futuro.

Evitar las cosas que dañan el proyecto de software requiere que el equipo de desarrollo rechace el impulso del liderazgo de elegir atajos a corto plazo y otros procesos que perjudiquen al equipo de desarrollo.

No siempre es obvio dónde está el problema porque la mayoría de la gente ve que el proyecto está retrasado y debe ser culpa del equipo de desarrollo.

Uno de los mayores enemigos del desarrollo de software efectivo es el equipo de desarrollo que recibe consejos de personas sin conocimientos técnicos que no se dan cuenta de cómo funciona el desarrollo de software.

Inspiración

Este artículo se inspiró en la publicación de Seth Godin — Definiendo al enemigo

© Copyright 2021 - 2022 | unogogo.com | All Rights Reserved