Desarrollo ágil

"¡Hola, amigo!"

"¡Hola, Bilaabo!"

“Hoy les voy a hablar de cómo se suelen desarrollar los programas”.

"En el siglo XX, cuando la TI moderna estaba en su infancia, todos parecían pensar que la programación era como la construcción o la fabricación".

"Las cosas solían ser más o menos así:"

" El cliente explicaba el tipo de programa que necesitaba: qué debería hacer y cómo debería hacerlo".

" Los analistas de negocios lo escucharían y harían una lista completa de los requisitos del programa en función de lo que dijo".

"Luego, los gerentes de proyecto dividirían estos requisitos en tareas y también determinarían qué programador haría qué tarea y en qué orden".

"Entonces los programadores se ponían a trabajar. A veces trabajaban varios años (!)".

"Cuando terminaron, el programa se entregó a los probadores".

"Los evaluadores revisarían cada uno de los requisitos del programa para verificar que se implementaron y que el programa funcionó como se suponía".

"Si algo salía mal, los evaluadores registraban los errores y los enviaban a los programadores".

"Luego, los programadores arreglarían los errores y enviarían el programa corregido de vuelta a los evaluadores. Y el ciclo se repetiría".

"Cuando se corrigieron los errores principales, el programa se entregó al cliente".

"¿Así es realmente como fueron las cosas?"

"Bueno, por supuesto, he simplificado mucho, pero eso es bastante parecido a cómo se hacían las cosas".

"¿Y un proyecto realmente podría tomar un año y medio o dos años en completarse?"

"A veces, si el desarrollo de un proyecto era realmente largo, lo dividían en versiones separadas. Cada 3 a 6 meses, los desarrolladores tenían que crear una parte específica de la funcionalidad del programa, probarla, corregir todos sus errores y mostrársela al cliente."

"Primero, para que pudiera compartir sus impresiones. Y segundo, y más importante, para que siguiera pagando por el desarrollo del programa".

"¿Seguir pagando?"

"En aquel entonces, el desarrollo a menudo tomaba de 2 a 3 veces más de lo planeado. Y debido a que a los programadores a menudo se les pagaba por hora, el programa se volvió de 2 a 3 veces más caro. Además, los beneficios también se redujeron. Después de todo, lo que el cliente quiere hoy por $ 100,000 puede no ser necesario en 3 años, especialmente al triple del precio".

"¿Los clientes a menudo se niegan a pagar?"

"Sí. Más tarde comenzaron a agregar sanciones al contrato, pero esto no mejoró la situación. El desarrollo del software se prolongó una y otra vez. Y nadie podía hacer nada al respecto, incluso si quisiera".

"¿Pero por qué?"

"Bueno, primero, se sabe muy poco durante la etapa de planificación. La mayoría de las veces, al principio, nadie podía predecir los problemas que enfrentarían los programadores".

"Pero los programadores experimentados deberían haber sido capaces de prever todo, ¿verdad?"

"¿Puedes ver que la programación es una profesión única?"

"Un trabajador ordinario frecuentemente realiza el mismo trabajo una y otra vez. Los relojeros hacen relojes, los cocineros cocinan, los maestros enseñan, los médicos tratan, etc."

"Cada uno de estos profesionales hace básicamente lo mismo día tras día. Como resultado, comienzan a mejorar cada vez más en sus trabajos".

"En la programación, el enfoque es diferente. Tan pronto como un programador se enfrenta a la misma tarea todos los días, escribe una función, un módulo o un programa para realizarla y nunca vuelve a hacerlo".

"Cada programador suele resolver cada tarea una vez en su vida".

"Algo así como científicos o ingenieros de diseño que inventan cosas".

"Ah. Bueno, ¿cuál es el papel más importante en un proyecto?"

"Hmm, ¿cómo debo responder eso? Es fácil decir cuál es el más importante, pero identificar el menos importante es difícil".

" El trabajo principal de un probador ( Garantía  de calidad , control de calidad )  es monitorear el estado de un programa e informar los errores de inmediato. Cuanto más y antes encuentre un probador errores, más se pueden corregir.  Un buen probador influye en la calidad del producto más que un buen programador lo hace ".

"¿Por qué los programadores no pueden probar sus propios programas? Después de todo, ¿no saben mejor que los probadores qué funciona y qué no?"

"Un buen programador simplemente es incapaz de ser un buen probador. Un programador sabe muy bien cómo funciona el programa, por lo que siempre lo usa de cierta manera. A diferencia de los usuarios comunes que usan el programa como les gustaría. "

"Además, los probadores no prueban lo que aún no funciona. El probador prueba la funcionalidad o partes del programa que el programador dice que ya funcionan casi a la perfección".

"Y cuando el probador encuentra toneladas de errores en esa funcionalidad y el programador los corrige, entonces el producto se acerca a la perfección".

" La tarea principal de un programador ( Ingeniero de desarrollo de software  , D  eveloper ,  SDE  ) es implementar una nueva funcionalidad. O, dicho de manera más simple, realizar las tareas que se le asignan. Cuando a los programadores se les asignan tareas con nuevas características , los realizan. Cuando se les asignan errores, corrigen errores".

"Pero a veces hay tareas más desafiantes, por ejemplo, crear la arquitectura para el programa o partes de él. Cuanto mejor sea la arquitectura propuesta, más fácil será hacer las cosas en el futuro".

"El problema es que la arquitectura debe elegirse desde el principio, pero no es hasta que estás en medio del desarrollo que está claro si elegiste la arquitectura correcta".

"Además, si la arquitectura es exitosa y el programa resulta excelente, entonces el cliente probablemente querrá usarlo como base para nuevas versiones del programa".

"Esto es a lo que me refiero".

"Cualquiera que sea la arquitectura que elija, siempre habrá un montón de cambios, adiciones y nuevas características que la arquitectura no tiene en cuenta".

"Aquí hay un buen ejemplo".

"Un cliente te pide que construyas un edificio de 5 pisos, entonces diseñas una arquitectura y construyes la casa".

“Luego el cliente pide agregar otra historia, y luego otra, y así sucesivamente”.

"Pero las paredes del primer piso no fueron diseñadas para tanto peso, ni tampoco los cimientos. Así que todo tiene que ser rehecho".

"Pero después de terminar el edificio de 5 pisos, ¿qué pasa si el cliente decide inmediatamente que quiere un edificio de 50 pisos?"

"Sería más fácil demoler la estructura existente y reconstruir todo desde cero..."

"Pero tengo un consejo para ti con respecto a la arquitectura".

“La arquitectura de una aplicación debe, ante todo, ser flexible, lo que significa que no tendrás que empezar de cero si decides rehacer la mitad de la aplicación. Este tipo de arquitectura suele llamarse flexible y modular ” .

" El trabajo principal del gerente de proyecto es tomar decisiones. El gerente de proyecto es quien ve el panorama general y toma decisiones basadas en esa perspectiva".

"Suponga que durante el desarrollo queda claro que cierta tarea no se completará según lo planeado. El gerente del proyecto puede entonces:"

" a)  tratar de negociar con el cliente para modificar la tarea"

" b)  destinar más tiempo a la tarea"

c )  traer programadores más experimentados de otros proyectos.

"Y hay muchas otras posibilidades".

"Cada opción requiere que sacrifiques algo, y el trabajo del gerente es minimizar las pérdidas totales de estos sacrificios " .

"Por ejemplo, supongamos que los competidores roban al programador líder ofreciéndole el doble de dinero".

"El director del proyecto puede:"

" a)  no hacer nada. El programador se irá y es probable que el proyecto se retrase e incurra en sanciones".

" b)  duplicar su salario. Entonces todos los demás en el equipo también querrán aumentos. Si les da a todos más dinero, entonces los costos del proyecto aumentarán y podría dejar de ser rentable".

c )  alguna otra opción que se le ocurra.

"Veo."

“Con un mal project manager, un buen equipo suele alargar un proyecto, pero no siempre”.

"Un buen gerente con un equipo de programadores promedio casi siempre completará un proyecto más rápido que un mal gerente con un equipo de excelentes programadores".

"Veo."

"Está bien, tomemos un breve descanso y luego continuaremos".