Guion. Un Arquitecto, un gerente de proyecto y un líder de equipo entran a un Bar

Un Arquitecto, un gerente de proyecto y un líder de equipo entran a un Bar

Dan es un desarrollador líder y arquitecto de una empresa que fabrica quioscos interactivos y tragamonedas. Ha trabajado en múltiples proyectos en los últimos años, En este tiempo ha trabajado con un líder de equipo llamado Bruce, Se unieron para trabajar en uno de los proyectos mas grandes de la empresa una maquina tragamonedas de las vegas llamada “SLOT-O MATIC WEEKEND WARRIOR”.

Joanna fue contratada hace unos meses como directora de proyectos para dirigir la creación de un software para una nueva línea de maquinas de disco que la empresa quiere introducir al mercado, la idea se tomo de una ya existente en el mercado.

Joanna se ha llevado bien con Dan y bruce, se siente emocionada de trabajar con ellos, pero ellos no están tan entusiasmados con el nuevo proyecto.

Se encontraron en un bar después de la jornada laboral, hablando de los proyectos Joanna se dio cuenta que en la empresa se encontraba muy seguido que estos resultaban en error, aunque Dan y Bruce se esforzaran en largas horas de trabajo para que estos resultaran exitosos, el problema es que al tomar atajos de código causaron pesadillas para el soporte, lo que Joanna noto es que el problema que ocasionaba tantos fallos era que usaban un modelo de cascada ineficiente, en el cual aceleraban el proceso de requisitos se entregaba a el desarrollo y se construirá tal cual estuviera documentado.

Joanna por su experiencia conocía que a menudo la teoría y la practica diferían. Bruce y Dan confirmaron algunas de las cosas que sospechaba Joanna, la empresa tenia grandes cantidades de proyectos archivados por problemas en sus especificaciones, ya que en el proceso de elaboración los requisitos tendían a cambiar lo que resultaría ser un desastre cuando se comprobara la documentación  y el software, aun así en la empresa intentaban ejecutar los proyectos como fuera posible y esto generaba muchos inconvenientes.


lo que empezaron a entender es que los problemas que se presentaban en el proyecto eran debido a la documentación tan Entre más charla Bruce menciono que otro problema que se presentaba era que algunos de los equipos con los que trabajo presentaban dificultades para construir su software incluso cuando los requisitos estaban correctos(aunque esto no había sucedido mucho) y cuando el equipo los tomaba apropiadamente (lo cual nunca había sucedido), ya que a menudo presentaban dificultades con la arquitectura de software, lo cual mostraba que los proyectos a menudo tenían errores y eran muy difíciles de entender, ambos problemas llevaron a muchos proyectos a tomarse como fallidos. Joanna explico que esto se debía a la incapacidad de su método cascada, con un método diferente los proyectos sabrían perfectamente lo que necesitaría para las entregas finales, ya que utilizando un método de cascada diferente podrían escribir todo de una forma ordenada y que el equipo lo construya con facilidad.

Dan y Bruce estaban mas en confianza y ahora era una maratón de quejas compartidas a Joanna,
Dan menciono que en casi todos los proyectos los clientes cambiaban de ideas a mitad del camino, cambiando todo lo planteando con anterioridad, volviendo al inicio de la cascada para tener que construir requisitos totalmente nuevos, pero los equipos no realizaban esto y buscaban hacer enredaderas entre el código y los requisitos ya construidos, provocando errores ya que este software no estaba diseñado para el nuevo propósito que se le planteo, además el código quedaba completamente desordenado y no era entendible, esto lo hacían por no tener un manejo correcto del tiempo.
estricta que manejaban y la mala comunicación, lo que no permitía ir al ritmo de los cambios solicitados.

Lo que los dejaba al final de la noche con la duda, ¿Sera posible encontrar una forma de solucionar estos problemas?.

No Silver Bullet

Se sabe que hasta el día de hoy no hay una “Mejor” forma de crear software, pero hace algún tiempo en la industria mucha gente creía que podía descubrir una forma única y altamente descriptiva que resolviera los problemas que se presenten en cualquier proyecto. Las personas creían que los desarrolladores podían crear software solo siguiendo instrucciones como si fuera una receta. Se encontraron muchas soluciones propuestas en las que se buscaban 2 cosas, encontrar una forma infalible de crear software o tecnologías que permitieran evitar y eliminar errores. La idea buscaba que si una empresa decidía una metodología los equipos se tenían que regir a esta para crear un gran software. Dan y Bruce sabían bien que esto no funcionaba por que tuvieron que pasar mucho tiempo trabajando con metodologías y tecnologías que no aportaban ninguna mejora duradera. Estos intentos de buscar un software definitivo resultaban siendo algo decepcionante para todos Condenado a los equipos a crear software desactualizado y para nada útil de que lo que pedía el cliente.

Algo que Joanna descubrió fue que algunos equipos lograron realizar un buen software siguiendo un proceso de cascada (o similar) que utilizaba inicialmente mucha documentación. Para realizar un buen uso del método cascada se necesita algo mas que requisitos estables, normalmente cuando un equipo realiza un proyecto en cascada tiene estas características en común:

-Buena Comunicación, ya que si se mantiene en constante interacción con los usuarios, gerentes y ejecutivos se tiene mucho mayor éxito.

-Buenas prácticas, principalmente revisiones de código y pruebas automatizadas, con lo que se buscaba encontrar errores y prevenir defectos.

-Cajones llenos de documentación, ya que las personas del equipo comprenden que es importante escribir el plan y las preguntas.

Otra cosa que añadir, Dan empezó su carrea después de la revolución de la década de 1990, por lo que sus trabajos utilizaban el desarrollo orientado a objetos para crear mejores diseños de software, Dan Utilizaba mucho los IDE ya que le permitían mantener un control apropiado del código, Bruce  A trabajado en proyectos por más tiempo que dan y vio como cambiaban las herramientas de desarrollo a lo largo de los años, esto fue positivo ya que les permitió automatizar tareas y así permitir mas tiempo para hablar con el Usuario y compañeros de equipo.

Por desgracia nuestros 3 personajes están por aprender esto a las malas

Puntos clave

-los procesos en cascada requieren una descripción del software desde el principio del proyecto para luego construir exactamente lo que se escribió

-Presenta dificultades al cambio debido al enfoque tan bajo que tiene a la colaboración

-No existe un método milagroso para realizar proyectos

-Los equipos que hacen que funcione el método cascada lo hacen adoptando prácticas y principios eficaces, siendo principalmente la comunicación

...