h1

The Martian Principles for successful Enterprise Systems

06/11/2010

Wizbook [Icon By Buuf]  Libros: Software Engineering.
Hace algún tiempo publiqué un post relacionado al libro Código Hermoso de Andy Oram y Greg Wilson. En dicho post expliqué cómo algunos de los más brillantes desarrolladores de nuestros tiempos han resuelto problemas cuyo remedio se veía inalcanzable en un principio a través de soluciones elegantes e intuitivas. Incluyendo pequeñas joyas de la ingeniería de software como el quicksort o el modelo de drivers de Linux, en aquél entonces el capítulo que me había parecido más interesante fue aquél donde se describía la arquitectura del Portal de Información Colaborativa (Collaborative Information Portal – CIP), una solución de ámbito empresarial basada en Java/J2EE utilizada para dar seguimiento a los descubrimientos científicos realizados por el proyecto Mars Exploration Rover desde el 4 de enero del 2004 hasta el día de hoy.

Pues bien, en días pasados terminé de leer The Martian Principles for successful Enterprise Systems, de Ronald Mak. Este individuo fue el principal diseñador y arquitecto de la solución implementada para el CIP, responsable del análisis, diseño, construcción y soporte post-producción de aquél sistema. En base a la experiencia adquirida durante la realización de este proyecto para la NASA, Mak nos muestra veinte principios que reflejan las mejores prácticas que adquirieron él y su equipo durante el proceso de desarrollo. Algunos son bastante obvios, como "Tus clientes no saben lo que quieren" (Principio 3) y algunos requieren de una buena dosis de experiencia profesional por parte del lector para comprender la temática presentada, como "No ates tus servicios en nudos" (Principio 9) pero en términos generales, todos ellos aplican bastante bien a cualquier proyecto de software. Adicionalmente, todos los principios contienen pequeños tips bastante útiles, como no apagar el logueo en producción, con el fin de detectar patrones de uso (Principio 13: Loguea todo). Finalmente, a lo largo del libro existen una serie de anotaciones denominadas "Notas de la Misión" que corresponden a la experiencia de Mak y su equipo. Un ejemplo de éstas se encuentra en "Ten algo funcionando tan pronto como sea posible" (Principio 4):

Una vez que nos dimos cuenta cómo construir y desplegar nuestro primer hilo de ejecución [es decir, una funcionalidad que abarque todas las capas de la arquitectura] y conseguir que funcionara, aprendimos a usar nuestras herramientas de desarrollo y la forma de integrar los componentes a través de los tres niveles [interfaz, negocio y persistencia]. Esto nos dio la confianza y una plantilla con la cual podríamos desarrollar los demás servicios.

Por otro lado, estos veinte principios están clasificados en dos categorías: aquellos que se enfocan en la parte técnica y aquellos que son buenas prácticas de gestión de equipos y proyectos de software. Me enfocaré un poco en éstos últimos, pues me parecen indispensables y definitivamente aplican a las labores que he estado ejerciendo últimamente.

Principio 17: Un liderazgo fuerte conduce al éxito del proyecto

De acuerdo a Mak – de hecho, comparto su visión – un arquitecto debe ser también un buen líder y mínimamente, contar con experiencia práctica en la implementación de arquitecturas. Esto es algo que él y muchos en este negocio conocemos como hands-on experience y quiere decir que un arquitecto no sólo debe quedarse en su "torre de marfil" haciendo "dibujitos"; un arquitecto también debe saber cómo "picar teclas", dirigir equipos de trabajo y lidiar con los clientes. Resumiendo, la parte esotérica es importante, sí; pero también es indispensable saber cómo implementarla y tener las habilidades de comunicación necesarias para llevarla a cabo. De lo contrario nos quedaremos con el calificativo de gurú, pero como todo en este mundo: si no sabemos interactuar con otros seres humanos, nos quedaremos solos, muy solos.

Por otro lado, Mak recomienda adoptar una metodología de gestión de proyectos – asumiendo que ya se está implementando una metodología de desarrollo de software, como RUP, XP o Scrum – y que el administrador de proyectos debe ser un facilitador, no un capataz. La definición de Project Manager (PM) propuesta por Mak me pareció la más cercana a mis propias ideas de lo que significa ser un PM:

Los buenos administradores de proyectos son partidarios y facilitadores del equipo de desarrollo. Ellos se aseguran que el proyecto se mantiene de acuerdo al calendario y sirven como enlace en el ambiente en el que se implementa el proyecto, incluyendo a los futuros usuarios, la alta administración y otros proyectos. Ellos protegen a los demás miembros del equipo de realizar tareas administrativas y algunas veces tienen que resolver conflictos que surjan dentro del mismo equipo.

Principio 18: No ignores los problemas interpersonales

A final de cuentas – como en anteriores posts hemos comprobado – es muy rara la ocasión en que la tecnología influye negativamente en el resultado final del proyecto. La gente, en especial los desarrolladores, son quienes en última instancia determinan el éxito o fracaso de nuestros esfuerzos. Aunque el libro no ahonda mucho en el tema, se sugieren algunos tips que permiten "lidiar con el bug entre el teclado y la silla":

• Los proyectos de software no son democracias. Los programadores no esperan que sus proyectos sean democráticos, pero si al menos existe la "apariencia" de ésta, pueden lograrse maravillas. Como ejemplo, al principio del proyecto es buena práctica solicitar la opinión de los desarrolladores, incluyéndolos en la toma de decisiones y facilitando que cada uno de ellos contribuya personalmente en la planeación y ejecución del proyecto. Claro que a final de cuentas, la decisión final deben tomarla el arquitecto y/o project manager, pero tomando en cuenta las opiniones de cada integrante del equipo, logramos un sentido de inclusión y pertenencia al grupo.

• Escalar el proyecto de acuerdo a las habilidades y experiencia de cada desarrollador. Cuando se diseñe una solución, es necesario tomar en cuenta las habilidades de cada uno de los integrantes del equipo. De lo contrario, nuestros desarrolladores siempre estarán en "modo de investigación" y no realizarán suficiente progreso en las tareas que les fueron encomendadas. Esto puede lograrse dividiendo al equipo en módulos y repartiendo tareas de acuerdo a cada persona: no podemos dejar a un programador junior implementar el modelo de persistencia así como tampoco debemos asignar tareas de embellecimiento del look and feel a los seniors.

• No ser esclavo de la última moda en administración de proyectos. Es decir, ocupar lo que realmente nos ayude a avanzar en el proyecto y no dejarnos llevar por del síndrome de la bala de plata.

• Fomentar una buena comunicación y trabajo en equipo. Sin una buena comunicación entre los miembros del equipo, especialmente en un proyecto de desarrollo complejo, el trabajo puede volverse muy difícil. Siempre es necesario tomar medidas para incrementar la comunicación entre los diferentes stakeholders que integran el proyecto, incluyendo juntas presenciales, correo, mensajería instantánea o teléfono. De hecho, en estos tiempos tenemos tecnologías que simplifican todavía más el tema de la comunicación trabajando de manera colaborativa, como Skype o Google Docs. Según Mak:

El buen trabajo en equipo es consecuencia de una buena comunicación. Cuando los miembros del equipo interactúan constantemente, ellos mismos se asegurarán que todos estén en la misma página, avanzando juntos en la misma dirección.

• Eliminar miembros del equipo que no puedan o no quieran desempeñarse adecuadamente. En pocas palabras, deshacerse de los divos y las manzanas podridas, pues si por cuestiones de hartazgo o "yo soy el perro alfa" éstos afectan negativamente el trabajo de sus compañeros, pueden terminar por interrumpir el progreso del proyecto en su totalidad.

Principio 19: La ingeniería de software se trata de las D’s.

El autor propone que crear desarrollos de manera exitosa requiere en gran medida de buenas prácticas de ingeniería de software, usando los siguientes conceptos para lograrlo:

• Descubrimiento. Encontrar el problema que queremos resolver; todo lo demás es vanidad.

• Diplomacia. Colaborando con los stakeholders de manera adecuada influimos positivamente en el éxito del proyecto.

• Definición. Definir QUÉ vamos a hacer para resolver el problema.

• Diseño. Definir a detalle CÓMO vamos a hacer para resolver el problema.

• Desarrollo. "Picar teclas", siempre usando las mejores prácticas como patrones de diseño, refactoring o desarrollo guiado por pruebas.

• Debugueo. El mejor tester siempre ha sido, es y será el cliente.

• Documentación. Documentar sólo lo necesario. Las metodologías ágiles dictan que el mejor código es aquél que no necesita documentación.

• Despliegue. Dónde correrá el sistema, quién lo dejará en producción o qué permisos necesitamos para hacerlo.

• "Demantenimiento". Palabra inventada por el autor que en realidad significa mantenibilidad y adaptabilidad al cambio.

Principio 20: Las fórmulas del éxito no son complicadas

Finalmente, Mak define qué se necesita para desarrollar un sistema empresarial de manera exitosa y cómo ser un arquitecto sobresaliente. Los "formulazos" que utiliza para describir estas cualidades son tan sencillos y elegantes, que vale la pena presentarlos sin mayor explicación:

Arquitecto Exitoso = Buen diseñador + Buen desarrollador + Buen líder

Sistema Exitoso = Buena Arquitectura + Buena ingeniería de software

Conclusiones

"Los principios Marcianos" de Ronald Mak son una buena lectura que nos ayuda a comprender conceptos como "arquitectura basada en componentes", middleware o mantenibilidad. También nos sirve, aunque por encimita, a entender algunas de las mejores prácticas de ingeniería de software y gestión de proyectos que nos permitirán sobrevivir en proyectos de desarrollo de software empresarial. Recomendable para aprender un poco más acerca de este universo de prácticas, modelos y metodologías que son indispensables si queremos justamente, "llegar al infinito y más allá".

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: