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

Agile to the Rescue! (Right?)

Es fácil saber que es un proceso en cascada, desde el principio vimos como este presento problemas en el desarrollo del proyecto de nuestros personajes.

En su último proyecto Bruce y Dan trabajaron con Tom, un gerente de cuentas, las primeras semanas las pasaron construyendo las especificaciones de la nueva tragamonedas. Tom solo paso la mitad del tiempo en la oficina lo que le permitió a Bruce y Dan planificar la arquitectura, Una vez se acordaron los requisitos se convocó a una reunión para revisarlos y realizar los cambios pertinentes para así empezar la construcción.

Se dividió el proyecto en tareas y se le asignaron al equipo para así empezar a construir el software, cuando software estaba casi que finalizado Tom reunió a un grupo de Ejecutivos y Usuario comerciales, pero esta no resulto bien.

En la presentación todo se volvió incomodo debido a que uno de los directores ejecutivos pregunto sobre funcionalidades las cuales el proyecto no presentaba lo que ocasiono gran incertidumbre pues fue la falta de comunicación la que genero esto, ahora tendrás que reemplazar grandes cantidades de código para poder añadir el video póquer que fue lo que se les solicito.

En este punto ahora todo quedara enredado en un código espagueti, ya que será difícil mantener un código base, y el equipo se siente frustrado por que esto no debía ser así, esto fue un problema para todos ya que por este suceso el director del proyecto estaba tan desconecto que dejo la empresa, y aunque las bases habían cambiado las fechas preestablecidas seguían siendo las mismas, el director se excusó diciendo que su equipo no dio buenos números y al poco tiempo después de esto fue reemplazado por Joanna.

Tom fue uno de los mas frustrados debido a que tuvo que enfrentarse a todos los clientes que encontraron los problemas, uno de los más grandes clientes continuo, pero esto no le impidió firmar un contrato con la competencia lo cual hizo que los directivos culparan al equipo de Tom por esto.

Al final quedo muy claro que proyecto había quedado mal y cada persona culpaba a una u otra persona, pero nadie tenia realmente una idea de como solucionar este tipo de problemas y el software aún era un desastre.

Adding Agile Makes a Diference

Todos nuestros personajes fueron almorzar cuando Tom volvió a la ciudad, Joanna allí les hizo la sugerencia de que era tiempo de volverse más agiles, así comenzaron a discutir sobre que significaba llegan a ser “ágil”, Cada uno tenía una idea diferente sobre el significado de ágil, entonces empezaron a instruirse sobre el manejo de proyectos de forma ágil, cada uno uso métodos diferentes como Blogs donde se hablaba con personas de otros proyectos Y Leer libros o documentos cada uno descubrió muchas cosas nuevas e interesantes que empezaron a implementar en sus proyectos, Dan empezó a utilizar pruebas automatizadas unitarias y empezaron a utilizar el desarrollo impulsado con pruebas, creando un servidor que ejecutara pruebas automáticas cada hora y funciono, esto hizo notar inmediatamente mejoras en el código, se encontraba los errores con facilidad y el código se hacia mucho mas dispuesto al cambio.

...