PBF: Metodología de Desarrollo bastante usada y no reconocida

Como sabemos, hay varias metodologías de desarrollo que han evolucionado desde sus comienzos hasta la actualidad, hagamos un breve repaso de ellas (definiciones tomadas de Wikipedia):

1970

• Programación estructurada

1980

• Diseño y análisis de sistemas estructurados
• Análisis de información de requisitos

1990

• Desarrollo rápido de aplicaciones (RAD)
• Programación orientada a objetos (POO) 
• Desarrollo Dinámico de Sistemas 
• Scrum 
• Rational Unified Process (RUP) 
• Programación Extrema (XP)

2000

• Proceso Unificado Ágil (AUP) 
• Entrega Ágil Disciplinada (DAD)

2010

• Frameworks de Escalado Ágil (SAFe) 
• Scrum a gran escala (LeSS)

Persistentes en el tiempo

Varias metodologías antiguas han desaparecido o ya casi no se usan, y hay metodologías que han comenzado alrededor del año 2000 y que han ido madurando en el tiempo, siendo (a día de hoy) las siguientes:

• Behavior Driven Development (BDD)
• Chaos Model (sí, todos conocemos esta:)
• Incremental Funding Metodology
• Lightweight Metodology
• Test Driven Development (TDD)
• Acceptance Test-Driven Development (ATDD)
• Feature Driven Development (FDD)
• Otras

Pero hay una que no sale en nigún sitio, que no está documentada, con una (lamentablemente) larga fila de seguidores, y que creo que más de uno habrá visto, aunque no supiera su nombre:


Programación Basada en la Fé (PBF)
No hay link justamente porque formalmente no existe, pero está ahí...

¿Cómo funciona?
Es fácil: se hacen desarrollos en modo "para ayer", donde no hay tiempo para detenerse a comprobar la calidad o hay un mínimo de tiempo para algunas pruebas poco fiables porque ese tiempo de pruebas se ha ido reduciendo para poder meter alguna característica más.

¿Y las pruebas automatizadas?
Bien, gracias. Si hay suerte, puede que haya algunos tests semi-automatizados de hace varios años, cuando en algún momento había tiempo para los mismos, con lo que al ejecutarlos ahora podemos comprobar que algunas especificaciones de hace muchos años aún funcionan, pero de las nuevas no sabemos nada.

Obviamente, esta metodología genera muchas incidencias y los usuarios las reportan, y hete aquí dos puntos fuertes de esta metodología:

1. Cada cierto tiempo las incidencias abiertas "se cierran", aún sin estar seguros de que se corrigieron, sobre todo las más antiguas o sangrantes, todo sea por que salgan bien las estadísticas. Si la incidencia no se reabre quiere decir que se ha acertado con la solución y que se puede seguir así, pero si se reabre, entonces significa que no hubo suerte y que hay que intentar otra cosa, incluso con el método de prueba y error, más una dosis de Fé (o sea, "ojalá que funcione").
2. Con el tiempo los usuarios se cansan de reportar errores debido al desgaste, y entonces disminuyen las incidencias (las reportadas, no las reales), dando la señal aparente de que las cosas mejoran, cuando es todo lo contrario (nuevamente, favoreciendo las estadísticas)

De esta metodología solo puede esperarse una cosa: El Big Bang . Porque tarde o temprano ocurrirá y se irá todo al traste.

El sistema realmente es bastante perverso y las responsabilidades están repartidas entre todos los involucrados, desde los que piden cosas imposibles o innecesarias en tiempos ilusorios hasta los que debieran velar por la calidad de la solución y de la arquitectura de las aplicaciones, pasando por quienes deben gestionar todo el proceso.

Lamentablemente muchos son presa de esta metodología y aunque tengan buena voluntad, no tienen forma de luchas contra el Sistema, ya que ponerle solución implicaría hacer cambios que no todos están dispuestos a hacer. Al final la excusa de que "siempre se hizo así" muchas veces gana.

Cualquier parecido con la realidad es pura casualidad...


Seguramente alguno tendrá alguna anécdota para comentar al respecto.

Hasta la próxima!