La respuesta corta es que la construcción de software se hace de la misma manera que te comes un elefante, un bocado a la vez hasta que te atragantas con él.
Casi todo el software se puede resumir a la cosa más simple que se supone que debe proporcionar, el valor más alto que está destinado a llenar. Esto se conoce a menudo como el nivel de 50.000 pies.
Creo que a los gestores de proyectos les gusta utilizar este término porque les gusta imaginarse a sí mismos en un bombardero de gran altitud a punto de dejar caer la muerte en llamas indiscriminadamente. Si te encuentras en una reunión a 50k pies y sacas a colación algo que está algo más abajo en altitud y que, no por casualidad jode todo el asunto, se te instruirá rápidamente para que vuelvas a estar por encima de la cubierta dura.
Pero todo proyecto comienza con un… ¿qué coño es esta cosa?
Así que al principio tienes que tener una idea bastante clara de lo que es. En mi experiencia, cuanto más complicada sea la explicación de la cosa al más alto nivel más posibilidades tendrá de ser un fracaso. Si el elevator pitch de la idea de la cosa ya está experimentando scope creep estás en problemas.
Entonces la siguiente pregunta es, ¿cuáles son las cosas que necesitamos hacer para hacer la cosa?
Esas son las características. Es mi recomendación que mantengas esas cosas tan cortas como sea posible. Cada cosa debe ser examinada, medida, probada, pinchada, ignorada, incendiada, reencarnada y limpiada antes de que realmente decidas que debe ser una característica para el Producto 0.
Construye la menor cosa que puedas conseguir, pero no menos.
Es realmente difícil. Todo el mundo, incluido yo, puede entusiasmarse y empezar a decir «¿y esto? ¿Podemos hacer esto? ¿Y no sería esto lo mejor? Si hacemos esto todos esos niños que se burlaban de nosotros en la escuela secundaria se arrepentirían»
Deja esa mierda. Averigua cuál es el núcleo de la cosa y construye eso. Se llama Producto Mínimo Viable si quieres ser así.
Así que coges una de esas características y dices. Qué cosas necesito hacer para que esa cosa funcione. Sigues haciendo eso hacia atrás hasta que tienes una lista bastante buena de todas las pequeñas cosas que necesitas hacer para que esa cosa funcione. Cada una de esas pequeñas cosas debe ser realizable en unos pocos días a no más de una semana.
Alguien probablemente va a decir, Mark, bastardo escurridizo, estás yendo todo ágil en mí.
No.
No me importa lo que la religión de la metodología de software en particular es que tienes que romper lo que vas a hacer en trozos del tamaño de un bocado. Incluso cuando estábamos en cascada, sólo construíamos mierda de a poco.
Parte de eso es sólo psicología.
Vaya a construir Word. Qué, eh…ah…hmm.
Vaya a construir un diálogo que le permita guardar un archivo en el disco duro. OK.
El desarrollo de software se trata de abstracciones y tienes que llegar al punto en el que te centras en una pequeña parte y el resto se asume. Cuando construyo mi cuadro de diálogo para guardar archivos, no sé dónde ni cómo se va a utilizar, sólo estoy construyendo un cuadro de diálogo.
Pieza a pieza el elefante se come el culo.
Así que lo que te sugiero es que quizás estás dejando que la complejidad del conjunto se interponga en lo pequeño. Haz la cosa pequeña y luego la siguiente y luego integra esas dos cosas pequeñas en una cosa más grande. Aclarar, repetir.
Ahora bien, algunas cosas requieren mucha más reflexión y unos cuantos diagramas e incluso quizás algunos documentos y si estás trabajando con otras personas reuniones y discusiones. No puedo decirte cómo hacer todo eso porque simplemente haces lo que hay que hacer para la cosa en la que estás trabajando en ese momento.
Puedo decir que mucho de eso se hace en una pizarra hoy en día y se borra porque nada de eso parece durar, era un pensamiento que nos hacía pasar al siguiente. Antes era un auténtico cabrón por tener cierto tipo de documentos de diseño y ahora soy mucho menos irracional al respecto.