5 errores frecuentes de planificación en el desarrollo de software

Es difícil predecir el futuro, aunque existen métodos específicos para ello. La realidad es que incluso la planificación de un proyecto simple de desarrollo de software es un desafío. Hay muchas cosas que deben tenerse en cuenta y muchas cosas que pueden salir mal. Está comprobado que frecuentemente las cosas salen mal cuando el software se entrega solo en base a pronósticos. Lamentablemente, esta sigue siendo una costumbre arraigada.

Los errores más frecuentes que se cometen en el desarrollo de software:

1. La complejidad del desarrollo de software se subestima con frecuencia

El desarrollo de software se compara a menudo con la construcción de una casa. Parece una buena comparación, porque a primera vista los desarrolladores de software "construyen" algo. Lamentablemente, el desarrollo de software difiere fundamentalmente de la construcción tradicional de casas. Cuando se aplican tales métodos de planificación, pueden surgir problemas.

Nassim Nicholas Taleb describe en su libro "The Black Swan" dos mundos diferentes, "Mediocristan" y "Extremistan". Ambos mundos representan dos tipos diferentes de incertidumbre.

Para demostrar esta diferencia, Taleb propone el siguiente experimento:
Se seleccionan 1.000 personas diferentes de la población. Estas personas se acuestan cabeza con pies, una detrás de otra, formando una línea larga.

Supongamos que la estatura promedio de una persona es de 1,68 m. La línea tendría entonces aproximadamente 1.680 metros de largo. Una línea el doble de larga (3.360 m) debería consistir en unas 2.000 personas (que también tengan una estatura promedio de 1,68 m).

¿Qué pasaría si otras 1.000 personas se unieran a la línea existente? Sin embargo, esta vez se incluiría al hombre más alto del mundo (Sultan Kösen, 2,51 m). En este caso, solo se necesitarían 1.999 personas. Incluso después de incluir un escenario de peor caso en la planificación, no hay una gran diferencia con nuestro cálculo original.

Ahora intentemos el mismo experimento de nuevo, pero con un cálculo diferente:

Esta vez se seleccionan 1.000 personas diferentes de la población y se registra el patrimonio de las familias respectivas. El patrimonio promedio de una familia en EE.UU. es, por ejemplo, de 110.000 dólares. Para este grupo sería una suma total de 110.000.000 dólares. A continuación, se estima el tamaño necesario de una bóveda para guardar el patrimonio total de 2.000 personas. Se puede calcular el tamaño relativamente fácil averiguando el tamaño necesario para el patrimonio de 1.000 personas y luego duplicándolo.

Ahora tomamos de nuevo 1.000 personas pero incluimos a Bill Gates. ¿Qué podría pasar ahora? La estimación original era para una bóveda en la que se pudieran guardar 220.000.000 dólares. Ahora, sin embargo, se necesita una para 77.500.000.000 dólares. ¿Qué diferencia marca aquí un escenario de peor caso?

¿Qué tienen que ver estos experimentos con el desarrollo de software?
Si ya tienes experiencia en desarrollo de software, seguramente te has encontrado con algún problema que no pudiste resolver. Quizás es un bug que es muy difícil de corregir. O es un problema técnico que no puedes resolver con las herramientas disponibles. La estimación original no fue solo un poco imprecisa, sino que tiene una desviación del 10%, 20% o 500%. Este es el mundo del desarrollo de software. Esto es "Extremistan" (segundo experimento), donde un incidente o un elemento puede tener un gran impacto en el resultado.

La mayoría de los proyectos de construcción pertenecen al mundo de "Mediocristan" (el primer experimento), donde las desviaciones se compensan en conjunto. Repitamos el experimento con rascacielos seleccionados al azar y pongámoslos uno al lado del otro como fichas de dominó. Ahora entra en juego el edificio más alto del mundo, el Burj Khalifa. ¿Es el resultado final el mismo que en el ejemplo de la estatura de las personas o el ejemplo del patrimonio?

¿Cómo se puede evitar confundir "Extremistan" con "Mediocristan"? Es importante comprender en detalle el tipo de tarea que se planifica. Si el esfuerzo de trabajo de un solo item puede desviarse potencialmente mucho del de otros items, es aconsejable utilizar métodos de planificación adecuados. Por ello, los métodos de planificación empíricos utilizados en Scrum son más adecuados para proyectos de "Extremistan".

2. No planificamos lo imprevisible

Las tareas complejas necesitan un tipo diferente de gestión de riesgos. En la planificación habitual de proyectos se utilizan márgenes para imprevistos. A menudo se cree que lo imprevisible se compensa porque el tiempo perdido se recupera con el tiempo ganado. Lamentablemente, esto no funciona en el caso de trabajo complejo.

En este proyecto estamos seguros de que podemos entregar en la fecha prevista. Pero supongamos que los hechos de fondo fueran los siguientes:

• Eres un pavo
• El progreso que se rastrea es tu peso
• Nadie te ha contado sobre el Día de Acción de Gracias. ¿Qué pasa con los pavos en Acción de Gracias?
  ¿Cómo te sientes ahora?

Nassim Nicholas Taleb usa esta metáfora en su libro "The Black Swan" para ilustrar el impacto de eventos imprevisibles. El pavo nunca ha oído hablar del Día de Acción de Gracias y tampoco hay margen calculado. Los eventos imprevisibles no están contemplados en la planificación convencional. Pero en el desarrollo de software ocurren con frecuencia.

¿Cómo se puede evitar este error? El marco de trabajo de Scrum establece que se entreguen partes individuales de software a intervalos regulares. El riesgo se reduce entregando temprano y con frecuencia, no mediante márgenes planificados. Si ocurren imprevistos, existe la posibilidad de recurrir a lo que se ha construido hasta el momento.

3. A menudo se hace una promesa a los stakeholders que no se puede cumplir

Si sabemos que el desarrollo de software es complejo y arriesgado, ¿por qué no podemos simplemente comunicárselo a los stakeholders? ¿Por qué hacemos promesas que no podemos cumplir? La respuesta es que los líderes necesitan certeza. Establecen el presupuesto, necesitan estar seguros de que todas las actividades están planificadas, quieren un plazo límite y, por supuesto, quieren todas las funcionalidades deseadas.

¿Pero son necesarios los compromisos grabados en piedra?
La mayoría de los profesionales del sector entienden el riesgo. También entienden que a menudo deben asumir riesgos para obtener rendimientos y ganancias. Muy frecuentemente, el nivel de riesgo está directamente relacionado con el rendimiento potencial. La mayoría de las empresas preferirían un rendimiento garantizado. Pero saben que las ganancias de tales inversiones son tan bajas que a menudo no vale la pena invertir. Si todos saben esto, ¿por qué no lo hacen todos?

Si los stakeholders entienden la relación entre riesgo y recompensa (ganancia), ¿por qué no se sigue el mismo principio en el desarrollo de software? Con cada nuevo release hay un elemento de recompensa. En todo buen proyecto hay un cálculo de rentabilidad (Return on Investment, ROI). Si se espera una rentabilidad significativa en un proyecto, entonces los stakeholders deben esperar cierto riesgo. Así que habla con tus stakeholders al respecto. Hazles saber que quizás no obtendrán todo lo que se esperaba en el momento de la planificación. Ese es el riesgo en el desarrollo de software. No significa que no se pueda limitar el riesgo. Pero definitivamente debería mantenerse una conversación honesta.

Si los Stakeholders quieren compromisos vinculantes de tu parte, entonces solo haz aquellos que puedas cumplir. Comprómetete a la colaboración. Comprómetete a seguir el proceso acordado. Comprómetete a trabajar orientado a la calidad. Comprómetete a la inspección y adaptación continua. Comprómetete a garantizar la transparencia.

Habla con los stakeholders sobre riesgo y recompensa y explícales que construir nuevo software sigue el mismo principio. Discute qué medidas de mitigación de riesgos se pueden aplicar. Y comprómetete solo con lo que realmente puedas cumplir.

4. A menudo damos a los stakeholders la impresión de que ciertos trabajos son gratuitos

Cuando prometemos ciertas funcionalidades a nuestros stakeholders para una fecha determinada y un presupuesto específico, ellos piensan que han pagado y comprado esas funcionalidades. Como desarrollador, te has comprometido a entregarlas. El riesgo ahora es que los stakeholders piensen que no habrá costos adicionales. Después de todo, ya han pagado y creen que todas las funcionalidades adicionales están incluidas en el precio. Lo único que les preocupa son los costos de eventuales cambios. En su libro "Predictably Irrational", Dan Ariely describe el cambio en el comportamiento humano cuando algo es gratuito:

"En todas partes hay ventajas y desventajas, pero cuando algo es gratuito, se olvidan las desventajas."
Cuando tus stakeholders entienden que ninguna funcionalidad está garantizada hasta que esté terminada, participarán más a menudo, tomarán decisiones y harán compromisos. Insistirán en que primero se completen las funcionalidades importantes y luego las menos importantes. Estarán menos dispuestos a invertir mucho esfuerzo en funcionalidades que no son tan importantes.

Por lo tanto, se debe recordar regularmente a los stakeholders que no hay garantía de que una funcionalidad se entregue según lo planeado antes de que realmente se haya entregado.

Para la priorización, se debe colaborar permanentemente con los stakeholders durante el proyecto. Los Sprint Reviews de Scrum dan a los stakeholders la oportunidad regular de revisar el progreso del proceso, discutir los trabajos pendientes y establecer prioridades.

5. No actuamos profesionalmente

Imagina que vas a someterte a una operación de ojos. El oftálmologo sabe que en esta operación hay un riesgo del 10% de complicaciones y que en lugar de una mejora, la ceguera podría ser la consecuencia. El médico decide ocultarte esta información. Cree que de lo contrario podría perder tu encargo. Ahora imagina que te sometes a la operación y pierdes la vista. Luego descubres que el oftálmologo conocía este riesgo pero no te informó al respecto. Debería enfrentar serias consecuencias. Esto ciertamente no es el proceder que se esperaría de un profesional.

¿Sería mejor si el oftálmologo advirtiera sobre el riesgo pero luego dijera: "No se preocupe, soy un muy buen oftálmologo y le garantizo que nada pasará"? ¿Sería eso más profesional?

Este escenario se repite constantemente en los proyectos de desarrollo de software. Le mentimos a nuestros stakeholders. La razón por la que mentimos puede ser mala (lograr que los stakeholders firmen el contrato) o buena (quitarles el miedo a los stakeholders) o simplemente nos mentimos a nosotros mismos. El resultado es el mismo: ¡es extremadamente poco profesional!

Para evitar este error, hay que ser honesto, aunque sea difícil. Así se da a los stakeholders la oportunidad de reconocer los riesgos y planificar en consecuencia. Un profesional utiliza y promueve los fundamentos empíricos de Scrum y así ayuda a los stakeholders a gestionar mejor los riesgos.

Resumen: Errores de planificación en el desarrollo de software

Es difícil predecir el futuro. Cuando planificamos desarrollo de software complejo, cometemos muchos errores que frecuentemente conducen a una baja tasa de éxito. Mediante el uso de Scrum se evitan estos errores.

Este texto proviene del blog de Steve Porter y fue traducido al español.

¿Qué hace un Product Owner?

=> Conoce más sobre las tareas y responsabilidades de los Product Owners.

La reunión de Sprint Planning

=> Desarrollo y consejos importantes para Product Owners sobre el Sprint Planning