La toma de decisiones (reflexiones en voz alta)

Normalmente tomamos decisiones a diario sobre cosas tan comunes como levantarse de la cama o no, desayunar o no, en fin ... son decisiones que se toman en un ambiente de certeza, ya que se conoce el problema y las posibles soluciones; pero también las hay en entornos de incertidumbre.

En un entorno de incertidumbre, no se posee información suficiente para tomar la decisión, ya que no se tiene control o información sobre una situación o contexto, pese a que se puede sugerir diferentes tipos de soluciones, estas raramente pueden ser medidas (de allí que se le llama "incertidumbre, sin probabilidad"); en otras palabras, lo que viene a ser el desarrollo software.

Pero para tomar una decisión se vuelve básico el poder conocer la naturaleza de un problema, comprenderlo, analizarlo y finalmente, elegir un camino de entre los posibles, en contextos tan variados como el familiar, sentimental, laboral... en este caso durante el diseño de una aplicación o la dirección de un equipo de trabajo.

Los pasos, a grandes rasgos, para la toma de decisiones son:

1. Identificar y analizar el problema
2. Identificar las alternativas y ponderarlas
3. Definir la prioridad para atender el problema
4. Generar alternativas de solución
5. Evaluar las alternativas
6. Elección de la mejor alternativa "bajo el contexto final deseado"
7. Aplicación de la decisión
8. Evaluación de los resultados

Metodologías como TOGAF utilizan análisis GAP para saber el punto actual (contexto del problema) y saber hacia donde se quiere ir (solución deseada). De esta manera, al saber lo que tenemos, y lo queremos, podemos iniciar un plan de acción para implementar la solución.

Para la implementación (entiéndase forma de trabajo y sus resultados) existen otras metodologías complementarias como SCRUM o TDD/BDD que ayudan a detectar fallos de implementación desde los inicios para poder reaccionar a tiempo en caso de problemas técnicos y de recursos.

Lo que mayormente marca la diferencia y la similaridad, es la forma como afrontamos y asumimos los resultados de las decisiones, los cuales cuando son correctos nos provocan satisfacción, pero cuando son fallidos, solo nos queda reconocerlos y aprender de ello.

- FIN -

Instalando Enterprise Architect 8.0 en Ubuntu 10

Desde algunos años soy usuario, defensor (y evangelizador :-p) de Enterprise Architect como herramienta para modelar aplicaciones y para controlar ALM (Application Lifecycle Management).

Pues, por primera vez me he propuesto utilizarlo directamente desde Ubuntu con Wine (las veces anteriores fue usando una maquina virtual con XP) y aunque al principio he estado des-ubicado, he dado con la página de como instalarlo y no ha sido tan complicado como me lo esperaba o leia en algún que otro blog.

Dejo el enlace con las intrucciones (del fabricante), el único matiz sobre este artículo, es que he tenido que descargar un script de wine llamado "winetricks" y darle permisos de ejecución (aunque claro esto parece evidente :-) en el texto ).

En mi caso he instalado mas componentes de los recomendados (por salir de norma), los listo a continuación:

$ winetricks allfonts # install windows fonts
$ winetricks dotnet20
$ winetricks vb6run # install Visual Basic Runtimes
$ winetricks mdac28 # install data access components  
$ wine easetupfull.exe 

Enlaces relacionados:

• Installing Enterprise Architect inside WINE

- FIN -

¿ Hay que compartir el conocimiento ?

Compartir "Es lo que permite relacionarnos con los otros" y en este ámbito, devolver a la comunidad, lo que esta nos ha regalado.

Evidentemente mi respuesta es sí; y es lo que repito mentalmente cada vez que veo una "isla de poder", más adelante explicaré a lo que denomino una isla de poder.

Compartir el conocimiento nos permite relacionarnos con los otros, exponer nuestra forma de pensar, de expresarnos, y de aprender, ya que nos exponernos públicamente a comentarios buenos, constructivos, malos, destructivos, mordaces.. pero lo más importante es que nos da la oportunidad de equivocarnos y de retroalimentarnos en base al conocimiento de otros.

Pero considero que hay que ser conscientes, que al saltar a la palestra pública, seremos suceptibles de ser criticados; y por tanto debemos ponernos una coraza y mirar desde fuera lo bueno dentro de lo bueno, y lo bueno dentro de lo que nos parece desagradable y ofensivo.

En la batalla de la dialéctica, existen personas capaces de tomar nuestras frases y retorcerlas ... por tanto insisto, debemos ser capaces de ver tomar lo bueno dentro lo malo, y de ser humildes cuando todo sale bien, cosa loable, y poco frecuente en este sector, dado al gran ego que rebosa por todas partes.

Volviendo al tema, algunos no tienen claro lo de compartir conocimiento! Forman sus pequeñas islas de poder en base a no compartir conocimiento y a convertir en enrebesado lo sencillo, ...y para ellos es mi queja.

Para mí, una "isla de poder", es algo así como un pequeño nicho de mercado, donde alguien intenta posicionarse de forma errónea, para convertirse en indispensable, lástima que a algunos esta jugada les de resultado.

Y digo esto pensando, por ejemplo, a manera de reflexión (o tal vez de crítica), en algunas aplicaciones que me ha tocado rescatar, aplicaciones sin ejercimiento de roles, sin documentación, sin estructura, sin guía, sin control, caóticas!

Muchos saben del tipo de aplicaciones que hablo, a mas de uno de nosotros le ha costado, al menos las primeras veces, leer cantidades ingentes de documentos y mucha, mucha imaginación para comprender e intentar arreglar el entuerto.

Pero por muy ofuscado que este algo, solo retarda lo inevitable, hay otros que vienen por detrás y tarde o temprano sabrán desifrar aquello que con tanto sigilo se guarda, por tanto este tipo de actitudes no tiene razón de ser.

Ocultar el conocimiento, no posibilita estrechar los lazos sociales, ni incrementar nuestro capital intelectual.

Guardar información sin haberla pasado por la interrogación, por la opinión, por la justificación, o abolición del otro, no es conocimiento. Es tener una base de datos de "saberes muertos", sin vida, algo que no representa nada porque está inherte, sin conexión con los demás o con el medio que le da vida.

Por suerte hay mucha gente en internet que practica la divulgación de conocimiento, a todos ellos MUCHAS GRACIAS.



Enlaces relacionados:
¿Compartir el conocimiento?
- FIN -

Workshop sobre modelado de aplicaciones con UML

Hoy Viernes 28, he realizado un workshop de poco más de dos horas, dentro de la empresa, para hablar sobre "Enterprise Architect" como herramienta, la idea principal era el "modelado de aplicaciones empresariales con UML", pero sin querer se desvió hacia la parte de gestión de requisitos, asociaciones de requisitos con casos de uso, matrices de trazabilidad, releases ... y de UML2 se vio realmente poco.

Después de dos horas no quise finalizarlo sin hacer un pequeño repaso muy rápidamente con ejemplos de otras implementaciones UML2 que he realizado, utilizando esta herramienta.

Al principio del workshop la atmósfera era de formalidad, pero después de 15 minutos se torno jovial gracias a los asistentes, de tal forma que las otras dos horas se pasaron sin darme cuenta.

Desde aquí doy gracias a todos los que participaron, y por qué no, a todos aquellos que vean el video que grabamos más adelante.


- FIN -

La comunicación, gran desafio

Hoy en día saber comunicar es la clave para lograr transmitir ideas, pensamientos, actitudes, ... catalizar situaciones e incluso gestionar conflictos.

Ante la eterna pregunta ¿Por que fracasan los proyectos de Software?, una de las principales razones (no la única), simplemente es, la comunicación incorrecta.

Pero un tema, no menos importante que saber comunicar, es conocer los problemas que existen en la comunicación entre un emisor y un receptor.

1. El emisor pensó (cliente)
2. El emisor dijo  - solo aquello que considero oportuno -
3. El emisor creyó que estaba diciendo
4. El receptor escucho (persona que toma los requisitos)
5. El receptor creyó escuchar - a veces precipitadamente -
6. El receptor interpretó  - a veces usando ideas preconcebidas -
7. El receptor se quedó con
8. El receptor transmitió
9. Finalmente el receptor realizó algo.

Al menos siendo conscientes de estos problemas, podemos iniciar un punto de cambio, en la forma como nos comunicamos o trasmitimos, y evitar desarrollar productos como en la siguiente viñeta.

Enlaces relacionados: 

Por que fracasan los proyectos de desarrollo software.

- FIN -

Principios de desarrollo software ("Equilibrio")

Normalmente cuando un cliente nos encomienda que construyamos una aplicación y nos dice que sus requerimientos son por ejemplo:

• un vehiculo a motor que transporte dos personas como mínimo,


• que tenga cuatro ruedas,


• que tenga asientos confortables,


• que consuma poco combustible ya que tienen pocos recursos económicos,


• solo necesitan que funcione con Safari 4,


• y que lo necesitan en 1 mes.

Por naturaleza empezamos a elucubrar ¿Pero de que pueden estar hablando?

Un Smart		Una chiva
Un Nissan Micra		Un Audi R8
Un Ferrari Enzo		O talvez un carruaje

Nuestra imaginación normalmente nos empuja a crear productos más alla de los requerimientos iniciales (airbag, dirección asistida, GPS Integrado...), que en determinados casos son innecesarios; este comportamiento siempre se manifiesta en el momento más inesperado de la vida de un proyecto.

Cualquiera de estos coches citados anteriormente ¿cumple con lo requerido?.
Sin evaluar o conocer bien los requerimientos, unos dirán me apetece hacer un Audi R8 ya que mas urbano pero con mucha calidad, otros dirán pues el Smart..... y otros, un Ferrari por que nosotros también somos un ferrari ya que somos los mejores, etc, etc.

Implementamos dirección asistida, airbag, climatizador, reproductor de CDs ... merece la pena implementar todas estas características?
Realmente no son parte de los requisitos; implementarlas nos quitará un tiempo precioso! lo hacemos por decisión propia? Que cada cual responda con su consciencia je je je

Ese tipo de valor añadido al producto final, suele interferir en los tiempos de entrega, a menos que se pueda reaprovechar de otros proyectos. Ya que en ocasiones por añadir más de lo requerido, perdemos la visión del alcance del proyecto, y sin darnos cuenta empezamos a complicar el desarrollo de un producto que a priori deberia ser sencillo.

Pasada la fecha límite (1 mes), ¿como defender? al cliente, que no podemos entregarle lo que nos ha pedido, en la fecha indicada; sino que además tardaremos 6 meses más en entregárselo, por que le estamos haciendo un ferrari que tiene un sistema de localización mundial en caso de robo, y que estamos teniendo problemas de compatibilidad con Firefox e IE, pero que las estamos intentando solucionar.

Existen determinados tipos de filosofia o principios de desarrollo, que mezclados o aplicados en el momento exacto nos pueden favorecer a lo largo del proyecto, no solo en el alcance funcional, sino también el diseño o arquitectura del sistema, influyendo en el resultado final. Los más básicos son:

• YAGNI (You Ain't Gonna Need It),
  consiste en no hacer nada mas alla de lo necesario.
  


• DRY (Don't Repeat Yourself),
  consiste en hacer sólo una vez las cosas, evitando la duplicación.
  


• KISS(Keep It Short and Simple / Keep It Simple, Stupid),
  recomienda usar la sencillez para que la aplicación sea comprensible a nivel de todos los perfiles del proyecto.
  


• Peor es Mejor (Worse is Better),
  se puede decir que la teoría de los antipatrones tiene mucho que argumentar sobre la mala aplicación de los patrones, a pesar de sus beneficios.
  


• La navaja de Occam nos dice que a igualdad de condiciones la solución más sencilla probablemente sea la mas correcta "non sunt multiplicanda praeter necessitatem", es decir "no se debe presumir de más cosas de las que son absolutamente necesarias".

"El equilibrio" nos pone en el buen camino para el éxito de un proyecto, pero no no es fácil, ni siempre es el mismo, ya que depende de distintos factores.

Equilibrar las necesidades y espectivas del usuario, con las necesidades y espectativas del equipo, con las necesidades técnicas reales del proyecto, es un reto; pero los principios anteriormente citados ayudan a que ese ser vivo llamado "Aplicación" pueda llegar a buen puerto.

Probablemente no haya sido capaz de trasmitir todo lo que pienso, ni los matices que se aplican a cada una de mis frases, pero además de la sencillez, la visibilidad de nuestra faena y sobre todo la comunicación, son algunos de los puntos clave del éxito de un proyecto.


Enlaces relacionados:

Por que fracasan los proyectos de desarrollo software.

- FIN -

Un enfoque sobre la Arquitectura Software

Como siempre, navegando por el mismo maremagnum diario de mails me he topado con unas diapositivas interesantes...

Donde encaja, porque, razones... aunque sea del año 2007; no deja de ser un enfoque práctico que no esta ligado directamente "a los frameworks de moda"

Software Architecture SoftwareGuru 2007

View more presentations from dsolis.

Arquitectura de Software @ Software Guru 2007

- FIN -

Por que fracasan los proyectos de desarrollo software.

Navegando por ese maremagnum de mails spam que recibimos día a día, me he topado con una serie de artículos interesantes que hablan del ¿Por que fracasan algunos proyectos de desarrollo software?

Durante el desarrollo de los mismos se exponen no solo los porques, sino también se pueden encontrar una serie de consejos útiles que nos pueden ayudar a establecer una serie de buenas prácticas y cosas a tener en cuenta para evitar el fracaso.

1. Antecedentes de fracaso
   
   Nos cuentan sobre una serie de proyectos que fracasaron, alguno incluso antes de ver la luz. Pero también remarcan la importancia de una correcta gestión de proyectos ante el caos.
   
   "Lleva años construir una reputación, tan sólo hace falta un fracaso ..."
   
   
2. Toma de requisitos
   
   Hace énfasis en el alcance de los proyectos, en lo que se refiere a gestión; los prototipos para la recogida de requisitos, en lo que se refiere al análisis; y los requisitos NO funcionales, en lo que se refiere a la arquitectura y diseño.
   
   En definitiva la vista de Águila del sistema a construir.
   
3. La metodología
   
   Trata de la elección de una métodología que se adecue al punto anteriormente tratado (el 2), haciendo un pequeños repasos sobre las metodologías ágiles, en cascada y espiral; dando incluso la posibilidad de combinarlos para obtener lo mejor de cada una.
   
   "La mejor solución es no seguir ciegamente una metodología, sino comprender sus fortalezas y razones, y utilizarlas conscientemente"
   

Enlaces relacionados:
La comunicación, gran desafío




- FIN -