Reelaboración de proyectos de software

Retrabajo de software explicado

El retrabajo de software es el trabajo consecuente que surge de alterar requisitos, diseños, códigos y pruebas después de que ya se ha iniciado algún trabajo. En la mayoría de las empresas de software, esto representa entre 30 y 501 TP3T de toda la actividad. Generalmente excluimos la corrección de errores de la categoría de reelaboración de software. El retrabajo generalmente describe el trabajo adicional que es consecuencia del "cambio de requisitos".

Retrabajo de software: bueno o malo

Algunas modificaciones pueden verse como un indicador positivo de que los comentarios de los usuarios están guiando el cambio hacia lo que se necesita. Esto es justo si los cambios fueran imprevisibles. Sin embargo, los niveles típicos de retrabajo en proyectos de software son persistentes, alrededor de 30-50% de todo el esfuerzo. Esto está costando a la mayoría de las organizaciones entregar software sustancialmente más de lo que debería.

Cómo el retrabajo del software hace que los costos se disparen

Un problema particular con el retrabajo del software es que es más lento o menos productivo que el desarrollo inicial. En otras palabras, escribir código la primera vez es más rápido que modificar ese código para hacer otra cosa. Utilizando un enfoque estándar para la medición y la productividad del software, podemos realizar un seguimiento de la productividad de los equipos de software cuando realizan la compilación inicial y durante el retrabajo. Las tasas típicas de construcción de desarrolladores son alrededor de 1 Punto de función CÓSMICA (CFP) por día (rango típico: 0,7-2 CFP/día), mientras que la productividad en el retrabajo es menor, 0,75 CFP por día.

Cuando es necesario volver a trabajar, usted incurre en el esfuerzo de hacer el trabajo la primera vez (1 día por 1 CFP) y luego (1,5 días más por CFP) para modificarlo. Por tanto, el coste total pasa a ser 2,5 días en lugar de 1 día.

Esta sencilla explicación muestra cómo los proyectos de TI modestos pueden convertirse en desastres que arruinan el presupuesto. Al realizar un seguimiento temprano de la calidad de los requisitos, la probabilidad del desastre se vuelve predecible. Además, al prestar más atención a los requisitos, se puede reducir sustancialmente la calidad del trabajo previo.

Las causas fundamentales del retrabajo

Cuando nos damos cuenta de que alguna característica que estamos construyendo o hemos construido no es correcta, debemos tomar la decisión de dejarla incorrecta o corregirla. Que más adelante en el ciclo de vida de desarrollo se haga este descubrimiento, se causen más retrabajos, interrupciones y retrasos. No importa si el requisito es el resultado de una conversación, una historia de usuario escrita o un documento escrito más detallado. La incorrección o la falta de comunicación es la causa probable del retrabajo. Quizás el requisito original fue mal entendido, mal interpretado o mal comunicado, todo se reduce a una mala comunicación. A veces, la mala comunicación se descarta o se tergiversa como “requisitos cambiantes” cuando en realidad no lo es.

La mayoría de los cambios no son genuinos

Muy ocasionalmente vemos un cambio genuino inesperado en las circunstancias comerciales durante un proyecto que conduce a requisitos modificados. Sin embargo, la mayoría de los requisitos se conocen o se pueden conocer tempranamente. Del mismo modo, la mayoría de las decisiones arquitectónicas que debían satisfacer esos requisitos se pueden conocer (por adelantado). A veces el usuario dice “no sabemos lo que necesitamos hasta que lo vemos”. Para descubrir estos requisitos, es necesario utilizar técnicas de obtención adicionales, como la creación de prototipos.

La gran mayoría de los “cambios de requisitos” y, por tanto, del retrabajo, se deben a un trabajo de requisitos deficiente o incompleto.

Algunas causas fundamentales de retrabajo relacionadas con los requisitos (una lista incompleta):

• Requisitos mal articulados
• Requisitos conocidos, pero no declarados (omisiones)
• Inconsistencias entre un conjunto de requisitos.
• Requisitos no declarados que podrían haberse descubierto mediante la creación de prototipos (es decir, el usuario debe ver algo primero)
• Requisitos no declarados que podrían haberse descubierto mediante análisis
• Confusión entre objetivos de negocio, requisitos funcionales y criterios de aceptación. (mala articulación).
• Confusión entre restricciones y tareas funcionales, no funcionales.
• Y quizás la única razón legítima para volver a trabajar: requisitos desconocidos e incognoscibles.

El retrabajo sigue prevaleciendo en niveles altos: justificación

La mayoría de los estudios mostrarán que el 30-50% de todo el esfuerzo en proyectos de software se gasta en retrabajo. Hay varias razones por las que los niveles de retrabajo siguen siendo altos. Algunas de las razones rara vez se analizan, ya que pueden ser verdades incómodas.

Requisitos inconsistentes Estándares de calidad

La industria no puede ponerse de acuerdo sobre lo que constituye buenos requisitos. Una organización que intenta promover la calidad de los requisitos es el IIBA. Para la mayoría de las personas, no existen estándares formales para los requisitos de redacción y la calidad es generalmente baja.

Evitar comunicaciones importantes

A la mayoría de los desarrolladores les gusta escribir código, suelen ser introvertidos y no grandes comunicadores. Es posible que la interacción humana no les resulte tan fácil y se sienten más contentos reelaborando que teniendo esas desafiantes conversaciones sobre requisitos de antemano.

A menudo, los equipos de desarrolladores describirán el retrabajo como "refactorización de código". Podrían adaptarse a requisitos deficientes y utilizar la excusa de: “somos ágiles y aprendemos sobre la marcha”. O podrían decir que los usuarios no sabían lo que querían hasta que se lo mostramos. Lo primero es una excusa para “no aprender antes de partir”; este último es un problema que se soluciona de forma más económica mediante la creación de prototipos.

No hay responsabilidad por las buenas historias de usuarios

Las historias de usuarios son el pilar de la comunicación de un equipo ágil sobre lo que se va a construir. Pero ¿quién es el responsable de las historias de los usuarios? ¿Quién es responsable de garantizar que se describan correctamente un conjunto holístico de necesidades que brinden capacidades valiosas? Diferentes equipos dan diferentes respuestas, algunos dicen el propietario del producto, otros dicen todo el equipo. La falta de una responsabilidad clara puede generar historias de usuarios de menor calidad, lo que a su vez genera malentendidos y reelaboraciones. ¿Quién es responsable de la calidad de las historias de los usuarios? Nuevamente obtenemos respuestas inconsistentes a estas preguntas. Revisar la claridad de una historia de usuario es un trabajo tedioso que involucra al menos a tres miembros del equipo (los tres amigos). Es un trabajo que requiere mucho tiempo y es bastante aburrido y que a menudo se realiza de manera ad hoc, en todo caso. Idealmente, la necesidad de estas sesiones se reduce al ubicar al equipo en el mismo lugar. Con el trabajo remoto, la coubicación es esencialmente imposible. En algunos casos, el propietario del producto es un representante del usuario real y un verdadero experto en la materia. Todo ello conduce a menores requisitos de calidad.

Contratos que aumentan los niveles de retrabajo

Cuando se subcontrata el desarrollo de software. A la empresa a la que se subcontrata el trabajo normalmente se le paga por día. Para ellos, cuantos más días trabajaban, más días facturaban. Puede haber algunos marcadores contractuales que fomenten superficialmente un trabajo eficiente, pero normalmente carecen de fuerza. En última instancia, a la organización contratada suele interesarle incurrir en altos niveles de retrabajo. Por eso, a menudo vemos los peores requisitos en los compromisos contratados. En mi experiencia, existe una farsa sobre el trabajo eficiente; en realidad, la mayoría de los contratistas están incentivados a alargar el proyecto y vender más días-hombre. Con requisitos deficientes, el trabajo repetido es elevado y es inevitable que haya más horas facturables. Si está comprando desarrollo de software contratado, tenga cuidado.

Causas culturales de la reelaboración

Si un requisito no está claro, el equipo debe verificar su comprensión antes de comenzar a trabajar. Es probable que cualquier posible malentendido provoque la repetición del trabajo. En algunas culturas, cuestionar los requisitos del cliente es una conversación incómoda que preferirían evitar. En lugar de eso, el equipo puede trabajar con suposiciones y desarrollarlas. Esto es particularmente común en contratos subcontratados. Cuando los requisitos están escritos en un idioma que no es el idioma materno de todos los miembros del equipo, es muy probable que se produzcan malentendidos (y, por lo tanto, reelaboraciones).

Reducir el retrabajo

Observar y cuantificar el problema.

Al final de cada sprint, pregúntense cuánto trabajo acabamos de hacer que fue reelaborado versus trabajo nuevo. Entonces pregúntese: ¿cómo podríamos haber evitado esto? Finalmente registre el esfuerzo extra (es decir, el costo) que surgió porque tuvo que hacer el trabajo más de una vez.

Adopte estándares para redactar buenos requisitos

Nuestra lista recomendada de atributos de calidad es:

1. Claro
2. Conciso
3. Orientado al usuario
4. Comprobable
5. Mensurable
6. Coherente
7. Completo
8. Único
9. Valioso
10. Sin diseño

Con la excepción del #9 en esta lista, ScopeMaster verifica automáticamente que sus requisitos cumplan con estos atributos de calidad, por lo que no es necesario que los verifique manualmente. (No recomendamos la lista INVEST ya que no cubre todas las características anteriores que consideramos importantes).

Utilice herramientas que mejoren los requisitos

Bien, entonces construimos ScopeMaster exactamente para este propósito. Al utilizar ScopeMaster, expondrá y resolverá 9/10 de los tipos de calidad comunes enumerados anteriormente y a un ritmo aproximadamente 10 veces más rápido que hacerlo manualmente. En resumen, puede esperar reducir drásticamente el retrabajo utilizando ScopeMaster para ayudarle a evaluar y perfeccionar sus requisitos. Hay otras herramientas de QVScribe e incluso IBM Doors, pero éstas sólo tocan la superficie de lo que hace ScopeMaster.

Redactar contratos que incentiven un bajo nivel de retrabajo

Hay varias formas de abordar este problema. En primer lugar, es tener plena conciencia de que se trata de una preocupación. Recuerde que la mayor parte del trabajo repetido se puede evitar. Tenemos un paquete de recomendaciones contractuales que pueden ayudarle a dar forma a sus contratos de desarrollo subcontratados para minimizar la probabilidad de retrabajo.

Cuantificar el retrabajo

Hemos visto que el retrabajo causado por requisitos deficientes provoca un aumento del esfuerzo de 1x a 2,5x. En realidad, esta es una estimación modesta, porque cuando cambias de dirección, la interrupción de un bloque de código puede tener un impacto negativo en otras partes del código base, provocando aún más retrabajo.

Predicción de defectos: uso de números para reducir el retrabajo

Los estudios han recopilado datos sobre la creación y eliminación de defectos. Estos han demostrado que los defectos potenciales ocurren en cada uno de los artefactos clave del desarrollo de software: requisitos, diseño, código, pruebas. La consecuencia es que conocemos los potenciales defectos de cada uno y, por tanto, cuántos defectos debemos eliminar hasta alcanzar una calidad satisfactoria. Nuevamente, utilizando el tamaño estándar sabemos que los defectos potenciales típicos son aproximadamente 5 defectos por CFP, de los cuales 1 probablemente esté en los requisitos. También sabemos que el tamaño promedio de una historia de usuario es 5,5 CFP, por lo que tenemos un potencial de defectos de requisitos de 5,5 por historia de usuario. Esto significa que, a menos que seamos proactivos, esos 5,5 defectos permanecerán y se volverán a trabajar más adelante. Herramientas como ScopeMaster pueden encontrar alrededor de 50% de defectos en los requisitos, es decir, 2-3 por historia de usuario. Esto reduce a la mitad la causa probable de retrabajo.

Escrito por Colin Hammond, 35 años de experiencia en TI y fundador de ScopeMaster.