Guía Esencial

Navegue en las secciones

BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Este contenido es parte de Guía Esencial: Guía esencial de desarrollo de aplicaciones corporativas
Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Un CIO va más allá de lo ágil, directamente a la mesa de dibujo

Los lemas de Niel Nickolaisen para el desarrollo de software le han servido bien en los últimos años. Ahora es el momento de ir más allá de lo ágil.

Reúnanse, niños, el viejo Nickolaisen quiere compartir con ustedes una historia de los viejos tiempos. En aquel entonces, lo último en el diseño y desarrollo de software era encerrar a un equipo multifuncional en una habitación por unos días y hacer que crearan un documento enorme de requisitos de software. Luego las diversas partes terminarían los requisitos, y el equipo de software se pondría a trabajar –solo para resurgir meses después y presentar orgullosamente algo que clamaban coincide con los requisitos. Todo el mundo miraría el producto final y diría que en nada era parecido a lo que necesitaban. Después de que terminaban los señalamientos con el dedo, todo el mundo cedería, y eventualmente terminaríamos con algo utilizable.

Fue a través de varias rondas de este tipo de proyectos que definí mis tres lemas para el desarrollo de software (que ahora extiendo a todo lo que hago):

  1. Nadie sabe lo que quiere hasta que lo ve (así que consígales algo que ver, no leer, tan pronto como sea posible).
  2. Tan pronto como ellos lo vean, van a querer cambiarlo (así que no construya mucho antes de que ponerlo frente a los clientes, para que pueda reunir sus comentarios).
  3. Todos los grandes proyectos fracasan (así que haga todo en pequeños trozos).

Hace años, adopté principios ágiles con el fin de asegurarme de que me estaba adhiriendo a mis tres lemas. Por favor, no crea que soy algún tipo de fanático de la metodología ágil. Estoy mucho más interesado en los principios detrás de los métodos ágiles que en los propios métodos. Hacemos iteraciones cortas, encajadas en tiempo. Al final de cada iteración, demostramos a nuestros clientes lo que hemos construido. De esa manera, ellos pueden ver lo que hemos construido para que nos puedan dar retroalimentación. E iteraciones cortas rompen naturalmente los proyectos grandes en partes más pequeñas.

Durante los últimos meses, he estado pensando encómo puedo mejorar la aplicación de mis lemas. En mis momentos de tranquilidad, me pregunto cómo puedo hacer un mejor trabajo en cuanto a dejar que mis clientes vean lo que estamos construyendo –idealmente, lo más pronto posible. Como resultado, hemos estado experimentando con algo que yo llamo más allá de lo ágil. Hasta ahora, parece que funciona bastante bien. Así es como funciona:

Como parte del diseño inicial de una aplicación, hacemos un mapa y rápidamente repetimos el proceso de la experiencia del usuario. Por experiencia del usuario, quiero decir el flujo y la navegación de la aplicación. Bosquejamos lo que los clientes harán en la aplicación. Y sí me refiero a dibujar. Nuestro punto de partida son dibujos hechos a mano de la funcionalidad. Debido a que  involucramos a nuestros clientes en este proceso, ellos llegan a perfeccionar el flujo y la funcionalidad en tiempo real. Un diseñador de la interfaz de usuario asiste a esta sesión para que pueda convertir rápidamente las imágenes dibujadas a mano en un prototipo donde se puede hacer clic. Este prototipo representa cómo funcionará la aplicación –una vez que tenga algunas funciones detrás de él. Lo importante es que conseguimos una retroalimentación casi inmediata en algo que los clientes pueden ver. Una vez que todos estamos de acuerdo en que estamos cerca, comienza el trabajo de desarrollo de software. Utilizamos nuestra versión de los métodos ágiles para el resto del proyecto, pero sentimos que conseguir la experiencia de usuario correcta al principio es la mejor manera de empezar.

Somos nuevos en este enfoque más allá de lo ágil, pero ya está dando sus frutos para nosotros. Una de nuestras nuevas aplicaciones era una especie de papa caliente política. Varios departamentos reclamaron la propiedad y querían asegurarse de que nos adheríamos a sus estándares. Debido a los riesgos, utilizamos este enfoque. Juntamos a las partes en una habitación, dibujamos nuestras imágenes, discutimos sobre las imágenes, pero muy rápidamente estructuramos algo que todo el mundo podía ver y gustar. Hemos convertido esto en un prototipo rápido que nuestros ingenieros de software usan como su documento de diseño. Ellos simplemente tuvieron que desarrollar la funcionalidad representada por el prototipo.

Estoy seguro de que los demás están muy por delante de nosotros en el uso de tales métodos. Para nosotros, esta es nuestra más reciente mejor forma para hacer las cosas mejor la primera vez.

Acerca del autor: Niel Nickolaisen es CIO de la Universidad Western Governors, en Salt Lake City. Él es un orador frecuente, presentador y escritor sobre la doble función de las TI: permitir la estrategia y entregar la excelencia operativa. Puede encontrarlo en: nnick@wgu.edu.

Este artículo se actualizó por última vez en agosto 2014

Únase a la conversación

2 comentarios

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

Yo creo que algo mucho mas allá de lo ágil sería centrarse en lo que respecta a la mayoría de las aplicaciones administrativas.

Ha habido mucho debate en cuanto a mockups, wireframings o prototipos, fuera de la intención de hacer publicidad, el equipo que desarrollo Uxpin ha realizado muy buena documentación al respecto, ellos nos ofrecen una herramienta en el cual es posible entender y de igual forma poder implementar estas herramientas https://www.uxpin.com, sin embargo, yo creo que el problema se da mucho antes (primera parte)
Cancelar
Siento que el problema fundamental es que como área de desarrollo nosotros queremos empezar el proceso creación de forma muy rápida, y entonces empezamos con el dilema de preguntarnos si lo hacemos en forma tradicional (cascada) o de forma ágil, empezamos a crear diagramas de interacción, diagramas de responsabilidades, etc etc... y al final de cuentas dejamos de lado, a mi entender, la esencia de todas las cosas, la creación e implementación de una aplicación informática tiene dos grandes categorizaciones: Sistematización y Automaticación
Cancelar

- ANUNCIOS POR GOOGLE

Close