El desperdicio de proyectos de software está costando $1 mil millones por día en empresas y gobiernos de todo el mundo que realizan trabajos que son completamente innecesarios.
Cada día, los equipos de software de todo el mundo desperdician 30-60% de su tiempo (y el tiempo y dinero de los empleadores) debido a prácticas ineficientes. La mayor parte de este desperdicio es evitable. En cualquier momento, cada miembro del equipo puede estar haciendo un trabajo útil pero, el trabajo que están haciendo podría haberse evitado. En la mayoría de los casos, los directivos no son conscientes de que esto está sucediendo.
Este artículo analiza algunas de las principales causas del desperdicio en el trabajo de software. Comencemos mirando las actividades de los equipos de software que son un desperdicio. Cualquiera que haya trabajado en un proyecto de software habrá experimentado varios de estos.
Los equipos de software suelen desperdiciar esfuerzo y tiempo:
- revisar características mal diseñadas de sprints anteriores,
- comprender y reelaborar el código mal estructurado de otros desarrolladores en sprints anteriores,
- abordar malentendidos porque el autor del requisito no se aseguró de que los requisitos fueran claros de modo que todos los lectores (usuarios, arquitectos, desarrolladores, evaluadores) alcanzaran un entendimiento común,
- haciendo reelaboración porque el autor del requisito no entendió lo que realmente se necesitaba,
- escribir pruebas manuales o automatizadas contra requisitos que luego resultan ser incorrectos,
- cambiar o eliminar código incorrecto porque los requisitos eran deficientes,
- retrabajo o trabajo adicional porque se eligió una estructura de datos deficiente, tal vez porque los requisitos eran inconsistentes,
- implementar requisitos de baja prioridad porque no se estaba considerando o no estaba disponible una imagen más completa del conjunto completo de requisitos.
- reelaboración del código debido al uso de lenguaje inconsistente y no estructurado en los requisitos,
- corregir y volver a probar errores que se podrían evitar si los requisitos y diseños hubieran sido más claros,
- escribir criterios de aceptación detallados e inapropiados de requisitos que carecen de una descripción básica,
- Cambio de tareas causado por retrabajo debido a requisitos o diseños deficientes. (lo opuesto a “hazlo bien y hazlo una vez”)
- participar en reuniones de estimación (punto de historia) que se dedican principalmente a descubrir el significado de los requisitos, porque los requisitos no están claros,
- trabajar en proyectos que posteriormente se cancelan debido a que el proyecto excedió el presupuesto y el cronograma, porque el conocimiento del alcance general era deficiente o incompleto al principio
Se habla mucho de prácticas lean por parte de los equipos de software, que consisten en eliminar el desperdicio. Sin embargo, es raro encontrar equipos que examinen cuidadosamente la fuente real y la magnitud de los desechos, determinen su impacto en el progreso y determinen cómo podrían evitarse en el futuro. La mayoría de los equipos incurren en algunas o muchas de las actividades inútiles mencionadas anteriormente. El impacto acumulado promedia alrededor de 40-50% de todo el trabajo realizado por los equipos de software. Y la mayor parte de esto es evitable.
Esfuerzo desperdiciado en el trabajo del conocimiento
El esfuerzo desperdiciado en conocimiento es común y sustancial. Por ejemplo, cambiar un código que ya es estable es muy costoso porque tanto él como todas las características que lo rodean deben reconsiderarse y volverse a probar. Es necesario volver a realizar la prueba para garantizar que el cambio no haya introducido algún efecto adverso. Un cambio de código de una línea puede requerir volver a probar miles de líneas de código relacionado. El desarrollo impulsado por pruebas (TDD) es una técnica que ayuda a aliviar este problema, pero no lo previene ni detecta todos los defectos posibles.
En proyectos con equipos más grandes, el trabajo de una persona depende del trabajo previo de otra. Antes de realizar un cambio en algún código, un desarrollador debe comprender lo que escribió su predecesor, luego averiguar dónde más se estaba utilizando y finalmente puede comenzar a realizar los cambios deseados. Lo mismo se aplica a los requisitos, diseños y pruebas. El pre-cambio aprendiendo puede llevar horas o incluso días. Lo que parece ser una modificación menor puede resultar desproporcionadamente costosa.
Saltar de un fragmento de código a otro implica un cambio de contexto. Para que el conocimiento funcione bien, debemos centrarnos y evitar el cambio de contexto. La corrección de errores implica más cambios de contexto que escribir el código en primer lugar. El cambio de contexto es un completo desperdicio. La combinación de reaprendizaje y cambio de contexto explica en cierta medida cómo un pequeño cambio de código puede resultar extraordinariamente costoso. Lo ideal es modificar un método el menor número de veces posible más allá del sprint en el que se creó.
¿Los equipos miden el desperdicio real?
En general no, no lo hacen. Así es, las empresas y los gobiernos de todo el mundo desperdician $1Bn al día y muy pocos lo miden. Estos residuos no se reducirán ni desaparecerán mágicamente por sí solos; es necesario un trabajo proactivo.
El análisis de la causa raíz puede ser útil para identificar dónde, por qué y cuánto desperdicio se genera. Antes de considerar un próximo trabajo de software que requiere un cambio o corrección del código existente, debemos hacernos algunas preguntas importantes; aquí hay una lista no exhaustiva:
- ¿Podría haberse previsto o anticipado razonablemente este requisito o cambio?
- ¿Cómo podríamos haber sabido esto antes para haber evitado tener que cambiar el código existente? ¿Podría haberse evitado este cambio por completo?
- ¿Cuánto esfuerzo adicional y duración prolongada se genera al realizar este cambio ahora en comparación con si lo hubiéramos abordado cuando se escribió el código por primera vez?
- ¿Cuánto tiempo y esfuerzo adicional se está dedicando a las pruebas de regresión como resultado de este cambio?
- ¿Cuál es el efecto dominó de hacer este cambio ahora en comparación con si lo hubiésemos hecho antes?
- ¿Este cambio introduce nuevos riesgos de rendimiento o seguridad en el código implementado anteriormente (introduce una solución incorrecta)?
- ¿Se expresa este cambio en términos inequívocos de manera que cualquier lector lo entienda?
La causa raíz más común
La causa fundamental de la mayor parte de este desperdicio es el trabajo deficiente en las primeras etapas del ciclo de vida del software. Trabajo con requisitos deficientes, decisiones arquitectónicas apresuradas, trabajo con opciones de solución o trabajo de diseño descuidados.
La mayoría de los equipos de software rara vez consideran el impacto real de los defectos de los requisitos en su productividad y el desperdicio que causan. Además, pueden pasar por alto el costo de las malas decisiones de diseño hasta mucho después de que se haya implementado el diseño. Esto está etiquetado como deuda técnica.
Los requisitos poco claros que se implementan con un diseño deficiente e inflexible pueden generar costos extraordinarios de retrabajo. Este costo de retrabajo puede aumentar aún más si causa un retraso en otros trabajos relacionados y no relacionados. En algunos casos, y con bastante frecuencia en proyectos más grandes, los requisitos deficientes y las decisiones tempranas de diseño deficientes pueden llevar a que se descarte todo un proyecto.
Los defectos de requisitos descubiertos tarde suelen ser el tipo de defecto más costoso de solucionar.
Alrededor de $720Bn se gastan anualmente a nivel mundial en trabajos de software empresarial. Aproximadamente la mitad de esto es reelaboración que es evitable y está causada por requisitos deficientes, decisiones de diseño deficientes y las consecuencias de ambos. A nivel mundial, esto equivale a aproximadamente $360 mil millones por año o alrededor de $1 mil millones por día.
¿Qué pasa con Ágil?
Agile no cura el desperdicio que hemos descrito aquí. El principal beneficio de las metodologías ágiles de desarrollo de software es un rápido ciclo de retroalimentación entre usuarios y desarrolladores. Vemos que en muchos casos, la adopción ágil trae consigo una caída en la calidad y diligencia de los requisitos y otros trabajos de precodificación. Las organizaciones tienen prisa por ofrecer nuevas capacidades basadas en software. Quienes participan en la realización del trabajo presentan un enfoque de “adaptarnos sobre la marcha”, que parece atractivo. Si se hacen bien, las prácticas ágiles ayudan a garantizar que el cliente obtenga lo que desea, pero cuando se acompañan de un trabajo de precodificación descuidado, los resultados son niveles significativos de retrabajo durante el proyecto y un mayor esfuerzo desperdiciado.
Los datos de miles de proyectos muestran que se introducen tantos defectos antes de la codificación como durante la codificación.[i] Esto se conoce como potencial de defecto. 16% – 35% de todos los defectos de producción son causados por requisitos deficientes o incompletos.[ii]
Pocos equipos de software consideran cuidadosamente que los requisitos y los defectos de diseño son la causa fundamental de tanto esfuerzo desperdiciado. No puede desarrollarse hasta que tenga una idea de los requisitos. En otras palabras, el desarrollo sigue los requisitos. Un requisito mal investigado o mal expresado puede llevar a que todo un equipo desperdicie días o semanas de trabajo. A menudo, este tipo de desperdicio se descarta como “aprendizaje” o “requisitos de usuario en evolución” cuando en realidad no es ninguna de las dos cosas, sino un trabajo de requisitos deficientes. Hay varias razones por las que los requisitos pueden ser deficientes. Una razón es que muchas organizaciones no logran garantizar que el personal que redacta los requisitos tenga la capacitación y la experiencia adecuadas para realizar un trabajo de requisitos de alta calidad. Otra razón es que hay poco acuerdo y coherencia en toda la industria sobre lo que constituye un buen requisito.
Otras causas comunes de desperdicio de proyectos de software
Hemos mencionado el trabajo previo deficiente y el cambio de contexto como las principales causas de desperdicio; algunas otras causas comunes incluyen:
- desperdicio causado por un mal liderazgo,
- Desperdicio causado por bajos niveles de habilidad, lo que lleva a un mayor retrabajo y errores.
- desperdicios de siguientes procesos que parecen agregar valor pero no lo hacen,
- no seguir buenos procesos que sí agregan valor pero que tal vez no estén de moda,
- desperdicio en gastos generales de comunicación debido al tamaño excesivo del equipo,
Los requisitos de software suelen ser de mala calidad
Los requisitos de software y las historias de usuarios suelen ser de mala calidad. Quizás el autor no tenga las habilidades o la experiencia adecuadas. Quizás no tengan acceso a la información que necesitan. El problema con casi todos los requisitos es que están escritos en lenguaje natural sin restricciones. Por lo general, los autores carecen de formación formal sobre los requisitos de calidad de la redacción. El lenguaje natural sin restricciones no es el medio ideal para comunicar los requisitos del software, pero es el que utilizamos mayoritariamente. La mayoría de las organizaciones no gestionan los requisitos de calidad.
En Scopemaster, hemos analizado más de 300.000 requisitos de cientos de proyectos de software en diferentes países e industrias. Lo que hemos encontrado es que:
- En promedio, un requisito (o historia de usuario) consta de 12 palabras (excluidos los criterios de aceptación). Y, en promedio, cada palabra corresponderá a 125 palabras de codificación o tokens que se escriben. Por lo tanto, podemos decir que un error con una sola palabra de un requisito podría dar lugar a que sea necesario reescribir 125 palabras de codificación. Estos números no deben usarse como base para la estimación, pero indican qué tan importante es cada palabra de un requisito.
- En promedio, vemos entre 4 y 8 problemas en cada requisito. Estos problemas varían en gravedad pero, a menos que se solucionen a tiempo, cada uno de ellos causará, o es probable que cause, un error de software.
Los defectos de requisitos comunes incluyen:
- No orientado al usuario
- Inconsistente
- Poco claro
- No comprobable
- Inmenso
- Contenido técnico excesivo
- Duplicado
- Desaparecido
- No valioso
- demasiado detallado
La mayoría de los lectores interpretarán un requisito escrito de manera diferente. Si la diferencia en la interpretación no es trivial, es probable que se produzca un error de software. Si ese error no se identifica hasta más adelante, es posible que se haya realizado mucho trabajo que será necesario rehacer para solucionarlo. Hacerlo bien a la primera o encontrar los defectos a tiempo es realmente importante.
Atributos de calidad de los buenos requisitos de software
Existen diversas fuentes y opiniones sobre lo que constituye un requisito de buena calidad. Hay un gran trabajo por parte del IEEE y revisan regularmente este tema. Existe una lista de atributos comúnmente adoptada, aunque en nuestra opinión deficiente, que con frecuencia promueven varios entrenadores ágiles, resumida en el neumónico INVEST.
Aquí está nuestra lista de atributos de calidad requeridos.
Verificar cada requisito aborda bien todo lo anterior, es un trabajo bastante tedioso, pero necesario si desea minimizar el desperdicio. Afortunadamente, herramientas como ScopeMaster ahora pueden hacer la mayor parte del control de calidad de estos requisitos por usted.
Otras formas de desperdicio de proyectos de software
Gracias a Todd Sedano por su útil imagen en la parte superior de este artículo que muestra las formas comunes de desperdicio de proyectos de software. Hemos cubierto los tres primeros con cierto detalle ahora, ya que son las principales causas fundamentales del desperdicio de proyectos. Veamos los demás:
Soluciones innecesariamente complejas
La deuda técnica, las integraciones complejas, la mezcla de lenguajes, las reglas comerciales complejas y las arquitecturas de software deficientes conducen a soluciones demasiado complejas, lo que lleva a una pérdida de tiempo en reelaboraciones, descubriendo cómo funcionan los sistemas y garantizando que la introducción de cambios no cause resultados no deseados. es decir, una buena arquitectura conduce a una flexibilidad eficiente.
Carga cognitiva extraña
El desperdicio de proyectos de software a veces se debe a que los desarrolladores y diseñadores tienen distracciones y limitaciones adicionales. Los proyectos exitosos protegerán a los desarrolladores, evaluadores y diseñadores de cualquier cosa de la que no deban preocuparse.
Trastorno sicologico
Esta causa de desperdicio tiende a ser menos común o causada por presiones externas o, en algunos casos raros, por una gestión muy deficiente.
Pérdida de conocimiento
En entornos de sistemas grandes o complejos, la continuidad del personal ayuda a retener el conocimiento. Si los expertos se van, pueden pasar semanas o meses de aprendizaje para alcanzar el nivel del personal que se marcha.
Multitarea/espera
Los proyectos de software pierden tiempo y esfuerzo en el cambio de tareas (como resultado de la multitarea). A menudo, un desarrollador puede tardar entre 20 y 50 minutos en volver a donde estaba antes de que una distracción interrumpiera su línea de pensamiento.
Comunicación ineficaz
En gran medida hemos cubierto esto con requisitos deficientes. Pero a veces otras comunicaciones del proyecto no se manejan bien, por ejemplo, si los ejecutivos no dan una orientación clara sobre lo que es importante para el negocio.
Evitando el desperdicio
Para evitar este desperdicio, solo necesitamos trabajar mejor con los requisitos y diseñar mejor. ¿Es así de simple? Sí.
Si escribe mejores requisitos que se comuniquen de forma clara y coherente a todos los lectores, y luego dedica el tiempo suficiente para garantizar que las opciones de diseño se consideren cuidadosamente, los diseños se revisen y optimicen antes de codificar, sucederán cosas buenas y el desperdicio será mínimo.
Rara vez se presta una atención adecuada a la calidad de los requisitos. Además, muchos enfoques, marcos y tendencias ágiles están socavando formas probadas y eficientes de entregar software de alta calidad a la primera. Requisitos de calidad y calidad de diseño. poder ser medidos, rastreados y mejorados, pero rara vez lo son.
Los equipos necesitan ayuda para resolver este problema
Redactar buenos requisitos no es fácil, requiere formación y experiencia. Muchos equipos tienen un propietario de producto que es un experto en la materia o un licenciado en administración con experiencia; es posible que conozcan el negocio pero no cómo redactar requisitos de buena calidad. He aquí algunas razones por las que este problema sigue sin abordarse en gran medida:
1. Hay poca recompensa laboral por desafiar los requisitos de calidad.
2. Si el requisito es bajo y tienes que construirlo dos veces, te pagarán más.
3. Los autores de requisitos rara vez tienen un conocimiento profundo de las necesidades del usuario, los sistemas existentes y cómo escribir buenos requisitos.
4. A menudo, los autores de requisitos son los desarrolladores que escriben tareas de desarrollo ricas en jerga, requisitos de usuario que no son fácilmente comprensibles y que todos pueden entender.
5. Los equipos rara vez limitan el lenguaje de los requisitos a aquel que logre entendimientos comunes consistentemente claros.
6. El equipo confía en la discusión como medio para aclarar malentendidos. Las discusiones a menudo quedan sin documentar.
7. Existe una amplia variabilidad en las opiniones sobre lo que constituye una buena calidad de los requisitos.
2022 y la automatización/IA viene al rescate
Están surgiendo herramientas que pueden ayudar con el aseguramiento de la calidad (QA) de los requisitos. Los proveedores de herramientas de gestión de requisitos están trabajando en nuevas capacidades para ayudar con algunos aspectos del control de calidad de los requisitos. IBM Doors, Jama Connect, Visusolvings y ScopeMaster son ejemplos. Nuestra propia herramienta AlcanceMaster es la herramienta más avanzada disponible que aborda los problemas descritos en este documento. Automatiza el control de calidad de los requisitos en las primeras etapas del ciclo de vida del software. Es como un analizador estático de requisitos; lo hace para requisitos que SonarQube lo hace para el código.
ScopeMaster y algunas otras herramientas utilizan el procesamiento del lenguaje natural y otras técnicas analíticas para interpretar y probar los requisitos. ScopeMaster guía al autor de requisitos para mejorar la calidad de los requisitos a una velocidad y minuciosidad que hasta ahora ha sido imposible. (ScopeMaster realizará una media de 100.000 pruebas en un conjunto de 100 historias de usuarios en 4 minutos). ScopeMaster normalmente encuentra entre 2 y 4 defectos por requisito en tan solo unos segundos.
ScopeMaster encontrará aproximadamente la mitad de todos los defectos latentes en un conjunto de requisitos. Los tipos de defectos cubren 9 de los 10 atributos de calidad mostrados anteriormente. Esto puede ayudar a los equipos a elevar muy rápidamente la calidad de un conjunto de requisitos a un estándar mucho más alto, ayudando a aliviar este problema de $360Bn pa.
Conclusión
Si está involucrado en proyectos de software en un sector corporativo o gubernamental, es posible que esté desperdiciando hasta 50% de su presupuesto en trabajos evitables. La causa fundamental de gran parte de este desperdicio son los requisitos deficientes y el trabajo de diseño del sistema. Reconocer que hay un problema y que ésta es la posible causa raíz es el primer paso para poder resolverlo. El siguiente paso es introducir una iniciativa de mejora de la calidad que aborde el inicio del ciclo de vida del desarrollo: objetivos, requisitos, arquitectura y diseño. Empiece a medir los defectos en los requisitos y el impacto que están teniendo en su progreso. Reconocer posibles defectos e introducir iniciativas para encontrarlos y solucionarlos lo antes posible. Herramientas como ScopeMaster cambian las reglas del juego para la seguridad del software.
Escrito por Colin Hammond, veterano de TI con 37 años de experiencia y fundador de AlcanceMaster.
[i] Fuentes de defectos Defectos por punto de función Defectos de requisitos 0,75 Defectos de arquitectura 0,15 Defectos de diseño 1,00 Defectos de código 1,25 Defectos de documentos 0,20 Defectos de malas soluciones 0,15 Potencial total de defectos 3,65
https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf
[ii] Capers Jones y Accenture, enero de 2021
Economía de la calidad del software, por C Jones y Olivier Bonsignour.
