agile-spain.com - Experiencias e informes

ErroresDeConceptoDeLaProgramaciónPorParejas

Tue, 24 Jul 2007 13:19:14 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Se tiene que programar por parejas si se sigue un proceso ágil.
Esto es completamente falso. 'Ágil' es un término muy amplio definido sólo en términos de valores y principios, el más notablemente en el Manifiesto para el Desarrollo de Software Ágil. El manifiesto no menciona el programar por parejas y la mayoría de los métodos ágiles no lo incluyen en su aproximación.
Ya que programar por parejas es una práctica de XP, ha tenido mucha influencia en la comunidad ágil. Por consiguiente a menudo es mencionado como una práctica ágil – tomando como práctica algo que es comúnmente usado por la gente en proyectos ágiles. Pero esto es una observación, no una prescripción..

HerenciaDiseñada

Mon, 23 Jul 2007 08:07:10 +0000

Escrito por Martin Fowler
Traducido por Rafael Vacas

Uno de los más largos debates en los círculos orientados a objetos es el debate entre HerenciaAbierta y HerenciaDiseñada. Josh Block ha sido probablemente quien mejor ha resumido el principio de la herencia diseñada: “Diseña y documenta para herencia o si no prohíbela”. Con este planteamiento te preocupas de decidir qué métodos pueden ser heredados y proteges los otros para evitar que sean sobrescritos.

El argumento más común para la herencia diseñada es que dado que la herencia supone una relación muy estrecha (y rompe la encapsulación) es fácil que las subclases efectivamente rompan las superclases por ejemplo, omitiendo comportamientos necesarios cuando sus métodos son invocados.

Muchos programadores, particularmente aquellos con una ActitudPermisiva, no están muy convencidos por este estilo de argumento. Otro argumento que encuentro más apetecible es el de Elliote Rusty Harold al discutir los principios de diseño de XOM. La cuestión aquí es que “las API son escritas por expertos para no expertos”. El creador de librerías debería estar debidamente versado en la tecnología con la que trabaja la librería. Deberían trabajar para simplificar esta tecnología a los usuarios de la librería. La encapsulación consiste en esconder secretos, por tanto una buena librería debería esconder toda clase de complicaciones y puntos peligrosos a los usuarios de la librería, ya usen la librería mediante invocaciones o herencia. Por tanto, con XOM puedo sobrescribir de forma segura las clases de la librería para hacer lo que quiera ya que la librería garantiza que aún así producirá XML bien formado, sin que tenga que preocupar a mi fea cabecita con todas las cosas que de otra forma podrían ir mal.

Diseño planificado y Evolutivo

Thu, 12 Jul 2007 15:23:44 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Para este artículo voy a describir dos estilos de cómo se hace el diseño en el desarrollo de software. Quizás el más común es el diseño evolutivo. Esencialmente, el diseño evolutivo quiere decir que el diseño del sistema crece mientras se implemente el sistema. El diseño es parte de los procesos de programación y según el programa se desarrolla el diseño cambia.

En su uso habitual, el diseño evolutivo es un desastre. El diseño termina siendo la agregación de un manojo de decisiones tácticas tomadas en el momento, cada una de las cuales hace el código más difícil de cambiar. Se podría argumentar de muchas formas que esto no es diseño, de hecho esto por lo general conduce a un diseño pobre. Como Kent dijo, el diseño está ahí para permitir cambiar el software fácilmente a largo plazo. Como el diseño se deteriora, entonces se necesita la capacidad de hacer cambios con eficacia. Se tiene el estado de entropía de software, con el tiempo el diseño se pone de mal en peor.

No sólo hace esto el software más difícil de cambiar, esto también hace los errores más fácil de reproducirse y a la vez más difícil encontrar y seguramente para resolver. Esto es la pesadilla “codificar y arreglar”, donde los errores se hacen exponencialmente más caros de arreglar según el proyecto avanza.

HypótesisDeResistenciaAlDiseño

Wed, 11 Jul 2007 12:15:06 +0000

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

¿Merece la pena el esfuerzo para diseñar el software bien?

De vez en cuando tengo conversaciones indirectas sobre si el diseño de buen software es una actividad que vale la pena. Digo que estas conversaciones son indirectas porque no creo que me haya encontrado a nadie diciendo que el diseño de software no tiene importancia. Por lo general es expresado de la forma " realmente tenemos que ir rápido para cumplir nuestro objetivo el próximo año y entonces reducimos ".

Existe la noción de que el diseño es algo que se puede comerciar para conseguir una mayor velocidad. De hecho he tenido la impresión un par de veces de que el esfuerzo de diseño es aceptado para mantener a los programadores felices aun cuando esto reduzca la velocidad.

SCRUM y XP desde la experiencia práctica

Fri, 01 Dec 2006 06:47:37 +0000

Aún no he terminado de leerlo, pero por lo que he visto hasta ahora el artículo de 90 páginas Scrum and XP from the trenches es definitivamente uno de los mejores que se han escrito sobre el tema. Cuenta las experiencias de la aplicación de diferentes prácticas de SCRUM y XP durante un año en una empresa con los típicos problemas de desarrolo de software (incumplimiento de fechas, efecto "siempre estamos apagando fuegos", mala calidad, etc).

En el artículo se describen desde un punto de vista completamente práctico la forma en la que han están haciendo las cosas ahora después de una añ aprendiendo (gracias a las retrospectivas periódicas). Pero también es muy importante lo claro que deja que esta no es la forma definitiva y que seguirán evolucionando (de nuevo apoyándose en retrospectivas periódicas). Hay que recordar con respecto a esto que no sólo cada proyecto es diferente sino que cada día el mismo proyecto es un poco distinto al día anterior.

En definitiva un artículo muy recomendable para coger ideas y contrastar las prácticas que estamos usando con lo que le ha funcionado a otra gente.

La hora de la verdad con Ruby on Rails

Mon, 10 Apr 2006 21:51:05 +0000

La versión 0.1 de SprintTracker contenía únicamente funcionalidades típicas de los artículos de Rails. La hora de la verdad ha llegado al proponerme implementar las funcionalidades que había sugerido para la versión 0.2 y 0.3. Las más importantes son:

Gráficas Burndown de los sprints
Reordenación jerárquica de las páginas de administración de proyectos, sprints y tareas. Esto ha permitido mejorar mucho la usabilidad de SprintTracker
Páginas de edición rápida para añadir todas las reestimaciones de un día concreto o para una tarea concreta. Esto es fundamental si, como estoy haciendo yo últimamente, usas una hoja excel para llevar el seguimiento del proyecto
Otras mejoras menores: borrado en cascada de proyectos, sprints y tareas, validación a medida de reestimaciones (no puede haber dos para la misma tarea y día), etc.

En la captura de pantalla se muestra la vista de un sprint en la que se aprecian varias de estas funcionalidades.

Tras implementar estas funconalidades he liberado SprintTracker v0.3 y creo que ya empieza a ser una aplicación lista para ser usada. Para ellas no había ningún artículo que me guiara y ello me ha obligado a aprender mucho más sobre Rails y sobre todo a manejarme con las referencias online imprescindibles para todo desarrollador de Rails:

Peculiaridades de Ruby para desarrolladores Java (parte 2)

Tue, 04 Apr 2006 12:09:27 +0000

Continuando con la entrada anterior sigo explorando los aspectos de Ruby mas peculiares para un programador que viene del mundo Java.

Closures

En los artículos de autores relacionados con el mundo de los métodos ágiles es habitual oir hablar de lenguajes que soportan closures. Pues bien, tengo que reconocer que aunque creía haber entendido bien el concepto lo cierto es que al menos no lo había asimilado. Usandolo con Rails por fin lo he conseguido, así que ahí va mi intento de explicar lo que son:

Un closure puede verse como un bloque de código que se sitúa en paralelo al del método y al que éste puede pasarle el control cuando crea conveniente usando el método yield()

Un ejemplo típico de uso podría ser un método que itera por un árbol y realiza una acción con cada nodo. En Ruby es posible pasar al método (al que llamaremos iterateTree) un fragmento de código que será el que realice la operación sobre el nodo. Por ejemplo, la invocación del método para imprimir cada nodo podría ser:

  tree.iterateTree do |node|
     puts "Iterating node: " + node
  end

El fragmento de código entre do y end recibe el nombre de closure. El método iterateTree invocará el closure usando el método especial yield:

Peculiaridades de Ruby para desarrolladores Java

Sun, 02 Apr 2006 16:22:31 +0000

Durante estos días en que he estado aprendiendo Ruby y Rails para desarrollar SprintTracker 0.1 me he ido encontrando diferentes elementos de sintaxis que me han sorprendido, confundido o incluso disgustado (al menos inicialmente). He pensado que podía ser buen idea revisarlos porque creo que conociéndolos resulta mucho más fácil entender los fragmentos de código presentados en la mayoría de artículos sobre el tema. Como son bastantes cosas lo voy a dividir en dos entradas del blog.

Llaves y paréntesis opcionales

En Ruby los paréntesis y las llaves (() y {}) pueden omitirse cuando son obvios. Por ello en Rails es habitual encontrar invocaciones a métodos de la forma:

  nombre_método parametro

Que es equivalente a :

  nombre_metodo(parametro)

Cuando un mapa (hash) es el último parámetro de un método las llaves pueden ignorarse, así que uniendo esto a lo anterior es habitual encontrarse llamadas a métodos de la forma:

  nombre_metodo primer_parametro, :clave1 => "valor1", :clave2 => "valor2"

Que es equivalente a:

  nombre_metodo(primer_parametro, {:clave1 => "valor1", :clave2 => "valor2"})

Y que un programador Java escribiría como:

  Map segundoParametro = new HashMap();
  segundoParametro("clave1", "valor1");
  segundoParametro("clave2", "valor2");
  nombreMetodo(primerMarametro, segundoParametro);

Publicado SprintTracker v0.1

Thu, 23 Mar 2006 22:52:54 +0000

Efectivamente SprintTracker ya está aquí empaquetada y descargable. No esperes que te resulte muy útil aún, claro, es más bien una prueba de concepto. Tras completar la funcionalidad tal y como expliqué en mi post anterior sólo queda un lavado de cara visual a la aplicación y empaquetarla para que sea fácil de probar. En la siguiente captura de pantalla puede verse el resultado final, en concreto la pantalla con el listado de proyectos dados de alta:

Os explico cuales han sido los últimos pasos para crear la versión 0.1:

Mejorando el aspecto visual y la navegación

Según iba avanzando con el desarrollo de la aplicación me había preocupado bastante poco del aspecto visual de la misma y la navegación entre sus apartados. Simplemente había dejado la apariencia que se crea por defecto al ejecutar el script scaffold. El principal inconveniente de esta es que no hay ningún mecanismo para acceder de unas herramientas a otras (y SprintTracker tiene ya 5).

Así que lo primero que pensé fue en crear un primer menú. La cuestión es ¿dónde lo pongo? Leyendo uno de los artículos que tenía a mano vi que en Rails las páginas se construyen a partir de tres componentes visuales:

Layout: es el fichero que contiene la estructura de un conjunto de páginas. Se encuentran en la carpeta views/layouts
View: es el fichero que contiene el contenido principal de cada página concreta. Se encuentran en subcarpetas de views con el nombre del controlador asociado a la vista.
Parts: son ficheros incluidos, generalmente desde views usando el método <% render :partial => 'nombre_del_part' %>. Por convenio el primer caracter del nombre del fichero es un subrayado y la extensión es (por ejemplo _nombre_del_part.rhtml). Las parts se encuentran junto a las Views que las incluyen.

Aquí me encontré con el primer problema, para cada una de las herramientas se había generado en la carpeta view/layouts un layout diferente. Eso es un problema, porque si el menú es igual a todos ¿tengo que copiarlo a cada uno de los layouts? Eso viola el principio DRY (Don't Repeat Yourself) y por tanto no me hacía mucha gracia. Pero rápidamente leí la solución: basta con borrar todos esos layouts y crear una nuevo (copiando el contenido de cualquiera de los otros) llamado application.rhtml. Rails primero mira si hay un layout con el nombre del controlador que se ha invocado y si no lo encuentra busca siempre uno llamado application.rhtml. De esta forma creando este fichero es muy sencillo hacer que todas las páginas del portal tengan la misma apariencia, pero si hay alguna excepción se puede crear un layout para un controlador concreto.

Una vez determinado el fichero ya podía escribir el código HTML de la cabecera, el menú etc. Lo que quería era:

Crear una apariencia más o menos decente (no soy diseñador, no le puedo pedir peras al olmo) pero muy poco sobrecargada
Tener el código HTML lo más sencillo posible
Poder cambiar la apariencia lo más posible usando CSS (para permitir a futuros usuarios de la herramienta adaptarla)

Con estos requisitos en mente me encajaba a la perfección usar el framework CSS de Mike Stenhouse que ha sido propuesto recientemente. La idea de este framework es proponer una estructura HTML concreta con unos nombres de identificadores y estilos CSS definidos que permitan representar cualquier página web normal. Gracias a las técnicas CSS soportadas a la gran mayoría de los navegadores es posible aplicar toda la apariencia a la página desde fuera del HTML. Este framework ha tenido repercusión en el mundo Java gracias al concurso propuesto por Matt Raible para crear apariencias para él.

En resumen, decidí seguir las guías de dicho framework CSS para SprintTracker y viendo los resultados me alegro de ello. Por un lado he perdido mucho menos tiempo de lo habitual maquetando el código HTML y por otro futuros cambios en la apariencia afectarán en la mayoría de los casos sólo al código CSS. En concreto siguiendo las guías de CSS modular del propio Stenhouse he dividido los CSS en componentes. En particular uno de ellos, _color.css contiene todas las definiciones de colores con lo que modificando sólo ese es posible cambiar todos los colores usados por SprintTracker.

Empaquetamiento

Uno de los aspectos que más me preocupaba cuando pensaba en implementar SprintTracker en Ruby on Rails era la dificultad de distribuirlo para que la gente lo probara. Yo pensaba "Si lo hiciera en Java, cualquiera puede instalar un tomcat y desplegar en él un WAR, o incluso puedo distribuir un tomcat con el WAR desplegado". Sin embargo mis temores se han convertido en nuevo reconocimiento hacia la comunidad de Ruby dado que me ha sido posible incluso crear un ejecutable autocontenido con toda la aplicación. ¡Más facilidad imposible!

Las herramientas que llevan a cabo la magia necesaria son tar2rubyscript y rubyscript2exe. Para instalarlas basta con ejecutar:

$ gem install tar2rubyscript
$ gem install rubyscript2exe

Una vez instalados aprendo a usarlas tal y como se explica en el artículo Distributing Rails Applications. El artículo es bastante nuevo (de hace 10 días) pero tiene bastantes imprecisiones, quizá porque habla de una versión antigua de Rails. En definitiva los que he tenido que hacer es ir al en el que hay un subdirectorio denominado SprintTracker que contiene toda la aplicación y ejecutar:

$ tar2rubyscript SprintTracker

Con este comando genero un fichero SprintTracker.rb que contiene toda la aplicación. Basta con tener Ruby instalado para poder ejecutarlo como ruby SprintTracker.rb. Me ha recordado a empaquetar una aplicación java en un jar y ejecutarla como java -jar app.jar sin embargo con aplicaciones J2EE no es tan fácil.

Pero ruby permite ir un paso más: puede incluirse el propio ruby en el paquete y crear un ejecutable. Basta con ejecutar:

$ rubyscript2exe SprintTracker.rb

Como inconveniente valga decir que esta herramienta genera un ejecutable que sólo funciona en la plataforma en la que se empleó. En mi caso para Linux (SprintTracker_linux).

En la generación de estos ficheros me he encontrado con dos problemas:

No se incluía la dependencia con sqlite3 y por tanto fallaba al ejecutarlo en un ordenador que no lo tuviera instalado aparte. Creo que esto ya lo he corregido, pero agradecería al que pudiera probarlo que me lo confirmara.
No me ha funcionado el sistema para sacar la base de datos fuera del ejecutable. Por ello esta versión 0.1 pierde los datos una vez se cierra. No me preocupa para esta primera versión, pero tenlo en cuenta: ¡no introduzcas datos reales que se van a perder

Debido a estos problemas de empaquetamiento he decidido marcar a los ficheros que he subido a RubyForge con la versión 0.1beta1. Os invito a todos los que estais siguiendo esta serie a descargarlos y probarlos:

SprintTracker v0.1

Relaciones entre entidades y validación en Rails

Thu, 23 Mar 2006 11:46:26 +0000

Lo prometido es deuda y tal y como comenté en el post anterior hoy toca explicar el resto de pasos que me han llevado a implementar la funcionalidad de la primera versión de SprintTracker funcional.

Estos han consistido en la creación de las herramientas de gestión de Proyectos, Sprints, Tareas y (re)Estimaciones con las oportunas relaciones entre estas entidades. Después he añadido un poco de validación (muy fácil, ya lo verás).

Proyectos, Sprints, Tareas y estimaciones

En el último post concluía que parece preferible usar la generación de código por script cuando vas a tener que modificar el resultado así que en esta ocasión lo uso directamente. Eso sí, lo primero es crear el modelo de datos. Lo hice en dos pasos en los ficheros 003_add_projects_and_sprints.rb y 004_add_tasks_and_estimates.rb, creados ejecutando:

$ ruby script/generate migration add_projects_and_sprints
$ ruby script/generate migration add_tasks_and_estimates

Muestro la parte más interesante de su contenido (el código de self.up)en ese orden:

    create_table "projects" do |table|
      table.column "name",:string,:limit=>128
      table.column "description",:string
    end
    create_table "sprints" do |table|
      table.column "target",:string
      table.column "start_date",:date
      table.column "duration", :int
      table.column "project_id", :int
    end

    create_table "tasks" do |table|
      table.column "name",:string,:limit=>256
      table.column "description",:string
      table.column "user_id",:int
      table.column "sprint_id",:int
      table.column "initial_estimate", :int
      table.column "real_effort", :int
    end
    create_table "estimates" do |table|
      table.column "reestimation_date",:date
      table.column "reestimation", :int
      table.column "task_id", :int
      table.column "is_going_well", :int
      table.column "explanation",:string
    end

Es importante fijarse que las claves extranjeras deben seguir un convenio de nombres. Por ejemplo en estimates la columna task_id apunta a tasks y por ello debe llamarse como la tabla a la que apunta en singular seguido de _id.
Para cada uno de ellos apliqué los cambios a la base de datos con:

$ rake migrate

Y ya estamos listos para generar el código:

$ ruby script/generate scaffold Project
$ ruby script/generate scaffold Sprint
$ ruby script/generate scaffold Task
$ ruby script/generate scaffold Estimate

Tras ejecutar estos comandos ya tengo el 80% de las herramientas de gestión. Lo primero que queda es establecer las relaciones.

Relaciones entre entidades persistidas

Tomemos como ejemplo la relación entre Proyectos y Sprints (un proyecto contiene varios sprints, un sprint pertenece a un proyecto). Para declarar esto en Rails basta con escribir lo siguiente:

[project.rb]
class Project < ActiveRecord::Base
  has_many :sprints
end

[sprint.rb]
class Sprint < ActiveRecord::Base
  belongs_to :project
end

Esto permite navegar de uno a otro usando la notación habitual: project.sprints o sprint.project y Rails se encarga del acceso a base de datos. También proporciona facilidades adicionales opcionales como la obtención de datos a priori (eager).

En el formulario de los sprints debemos poder elegir uno de los proyectos existentes. Para eso uso el siguiente código:

<p><label for="sprint_project_id">Project</label><br>
  <%= select("sprint", "project_id", Project.find_all.collect {|p| [ p.name, p.id ] }) %>

Gestión de usuarios en Rails: hacia SprintTracker v0.1

Tue, 21 Mar 2006 23:29:40 +0000

Ya me hago a la idea de lo que es una aplicación con Rails con suficiente claridad como para embarcarme en la tarea de crear la primera versión de SprintTracker. El objetivo de esta versión es que permita gestionar usuarios y proyectos, crear sprints asociados a proyectos, crear tareas dentro de un sprint y asignárselas a un desarrollador y por último ir añadiendo (re)estimaciones de la tarea durante los días que dura un sprint. La interfaz de usuario no me preocupa por ahora y dejaré la que genere Rails.

Primeros pasos

En primer lugar me decido probar un IDE específico de Ruby y encuentro RadRails así que digo adios a kate. También me pongo a buscar más artículos de Rails y me encuentro con una recopilación de los 12 mejores artículos de Ruby on Rails. A leer se ha dicho.

Una de las primeras cosas que se aprende de Rails es obliga a desarrollar de abajo a arriba: es decir empezando por el modelo de datos y llegando hasta la interfaz. Por ello es interesante comenzar la aplicación pensando bien el modelo de datos. El de SprintTracker es este:

Generación de código de persistencia en Rails

Rails ofrece dos modelos de generación de código (scaffolding) que podríamos denominar generación dinámica y generación por script

Aprendiendo más sobre Rails y Ruby

Tue, 21 Mar 2006 22:44:05 +0000

Tras conseguir instalar Ruby on Rails en la última sesión ha llegado la hora de entrar en materia. Como ya comenté mi idea era partir de los artículos del último número de la revista on-line ObjectiveView. Gracias a ellos he conseguido crear mi primera aplicación Ruby on Rails y por el camino también he aprendido mucho más tanto sobre este framework como sobre Ruby. Os cuento como ha sido la experiencia.

El primer artículo de la revista es sobre Ruby. Lo he leído rápidamente por encima y no me ha entusiasmado aunque si me he quedado con algunas de las peculiaridades de Ruby. En realidad tenía ganas de llegar al artículo "Ruby on Rails" de Obie Fernandez. Todo lo que escribo a continuación te resultará mucho más útil si has seguido, estás siguiendo o piensas seguir próximamente dicho artículo.

Siguiendo el artículo sobre Ruby on Rails

Siguiendo las instrucciones de los primeros párrafos he creado la aplicación ejecutando:

$ rails sprinttracker

Me ha gustado mucho la idea de que tras ejecutar el comando ya tengo una aplicación ejecutable y a la que puede accederse desde el navegador. Es más fácil y gratificante ir construyendo poco a poco sobre algo que funciona que escribir líneas y líneas que probablemente no funcionarán a la primera ni a la segunda.

Instalando Ruby y Ruby on Rails en Ubuntu

Mon, 27 Mar 2006 12:08:57 +0000

Ya no me he podido aguantar más. Después de meses escuchando las bondades de Ruby on Rails y en particular para conseguir un ritmo de desarrollo muy ágil me he decidido a probarlo. Llevaba varios días coméntandolo con amigos y compañeros, pero lo que me ha decidido ha sido el encontrar una idea para una aplicación: he pensado en desarrollar un entorno via web para llevar el seguimiento de una iteración con gráfica Burndown incluida. Últimamente estoy usando una hoja de cálculo, con la que estoy muy contento, pero echo de menos varias funcionalidades y el que varias personas puedan acceder a ella simultáneamente.

En definitiva que esta mañana me he puesto manos a la obra comenzando por instalar Ruby on Rails en mi Ubuntu 5.10. Lamentablemente la cosa no ha sido tan fácil como yo esperaba. Al final lo he instalado de la forma manual. Si no te interesan los problemas que me llevaron a esa decisión sáltate la sección que sigue ya pasa a la siguiente para una explicación rápida de cómo recomiendo proceder después de mi experiencia.

Primeros intentos con apt-get

Naturalmente lo primero que he hecho es mirar a ver si había paquetes disponibles para instalar con apt-get. Una de cal y una de arena. Ruby está y rails también (aunque una versión algo vieja) pero rubygems no. Primero instalé ruby:



Cinco señales de problemas en una iteración
Mon, 06 Mar 2006 10:51:12 +0000
A todos los que hayais empezado a usar gráficas Burndown para llevar a cabo el seguimiento de los proyectos os resultará muy interesante el artículo Five Signs of Trouble in an iteration donde Mishkin Berteig evalúa varias formas que pueden tomar esas gráficas y cómo identificar problemas a partir de ellas.


Una Experiencia real aplicando métodos ágiles
Sat, 18 Feb 2006 18:48:41 +0000
Nelson Tapia (NTapia) nos envia esta interesante reflexión sobre su experiencia trabajando con métodos ágiles:
"Me tocó trabajar en la empresa Forestal mas grande de Chile en la Mantención de un Sistema desarrollado en Gupta ( Sql Windows ) con un equipo de trabajo de 3 personas en donde nos dedicabamos principalmente a resolver problemas y enfrentar modificaciones.

Principalmente para los desarrollos nuevos solamente se contaba con una Especificación Funcional ( que indica como el Usuario desea que funcione el Sistema ) y posteriormente uno debia preparar la Especificación Técnica en donde mediante redacción, grafos, propuestas de pantallas y otros, indicabamos lo que debiamos hacer y cuanto tiempo nos tomaría. Sin saberlo estabamos trabajando con un método ágil, sin utilizarlo completamente, pero si con la presión de hacer desarrollos cortos y con una fuerte interacción con el Usuario.

Debo comentar que lo que hace actualmente exitoso esta forma de trabajo ( con muy poco errores y una alta cohesión en los Sistemas ) no son los métodos, ni el lenguaje, ni la plataformas de Hardware.

El éxito se debe a lo siguiente:

1.- Un equipo que posee un amplio conocimiento del negocio.

2.- Confianzas ganadas con el tiempo en la completitud de los desarrollos como en su exactitud.

3.- Ambiente de trabajo colaborativo y proactivo.

4.- Coordinación de esfuerzos depositando a los mejores en sus ambitos de conocimiento.