miércoles, 13 de diciembre de 2006

Formación interna en empresas de software

Ayer comenzó, para algunos compañeros en mi empresa, un curso básico de programación orientada a objetos.
Se que a estas alturas muchos de vosotros os preguntareis: "¿ De POO en el año 2006 (2007 casi...) ? ¡Pues a buenas horas!", o... "Je, je... una empresa de desarrollo de software... y un curso de esos a estas alturas, con el Web 2.0 por ahí, AJAX, etc, etc... díme que empresa es para no contar con ella..."


Pues bien, teneis razón, pero en el campo donde se mueve la empresa, realmente, no son necesarios esos conocimientos, ni siquiera hoy en día, en el 90% de los desarrollos; leí hace unos días en PresiónBlogosférica (gracias Angel por el link) titulado "Hacer bien una cosa".

La empresa para la que trabajo, es realmente, si no la mejor, casi, en lo que se refiere al conocimiento del negocio en el que se mueve, sus desarrolladores son especialistas o casi, en la materia, y los analistas no solo son reclamados por los clientes para desarrollos nuevos, si no como consultores que les ayuden en su propio negocio.



Con sólo un día de curso (presentación y esas cosas), ya hay alguno que se ha atrevido a cuestionar la validez del mismo, no solo poniendo en cuestión la calidad profesional de la persona que lo imparte, si no, y lo que me parece más llamativo, la utilidad de esos conocimientos que su empresa le pone al alcance de la mano.
Si bien es cierto que estas personas llevan "haciendo lo mismo" desde hace años, en el mismo entorno, con los mismos métodos, etc. etc., no es menos cierto, por tópico que sea, que el saber no ocupa lugar y más aun en este "mundillo". Frases tales como "si luego se me olvidará... total...", u otras del calibre de "si me valiera para algo...", no son la primera vez que las escucho en situaciones semejantes anteriores. Las mismas, no son más que la expresión hablada, a mi modo de ver, del cerrado entrecejo, limitado entendimiento del mundo informático y empresarial, de la persona que las dice.

La escasa amplitud de miras de estos compañeros, quiero pensar que se debe más a ganas de tocar las narices que a sus sentimientos reales, porque aun en el caso de ser ciertas dichas afirmaciones, ¿alguien les asegura que en un futuro (lejano o no) van a seguir "haciendo lo mismo"? ¿Tienen una bola de cristal en casa en la que han visto que su futuro profesional está asegurado, en puesto y funciones, en la empresa donde están ahora? ¿Realmente piensan que engordar su curriculum de conocimientos es una pérdida de tiempo?.
Si fuera yo, que evidentemente no es el caso, quien tubiera que financiar estos cursos, la siguiente vez me lo pensaría muy mucho, a pesar de poder encontrarme entonces en un círculo vicioso... "Mi empresa no me forma, haré siempre lo mismo, que aburrimiento"... lo que encima, aumentará la desilusión, la baja productividad, y mandará al garete cualquier intento de incentivación del personal.
Y lo peor de todo... es gente joven, muy joven, con una media de alrededor de 30/35 años de carrera profesional por delante... no quiero pensar que será de ellos dentro de 10 años...


Por favor, es un tema en el que necesito críticas y otros puntos de vista, porque se que lo miro con un filtro muy subjetivo. Deja tus comentarios. Gracias por servir de desahogo.

martes, 12 de diciembre de 2006

Reglas para el buen desarrollo de un producto

En el blog Product Musing, hubo una entrada el pasado 5 de Noviembre sobre 20 reglas para conseguir el lanzamiento de un producto software con éxito (en inglés). No es que esté de acuerdo al 100% con todos los puntos, pero realmente, dan en que pensar, o al menos, para echarse unas risas.

Paso a comentar las que me han parecido más acertadas:

  1. Asegúrate de saber qué estás desarrollando. Muchos de los retrasos en los proyectos se deben a que "el cliente", el/los analista/s, los programadores, etc. (inclúyete en el pack correspondiente), no saben realmente cuál es el objetivo final del proyecto. Reconoce, añade en una actualización del post, que lo que estás desarrollando ahora mismo, cambiará casi de forma irremediable en el futuro hasta completar el proyecto, así que asegúrate de que tus procesos, clases, sistemas o subsistemas, admitirán estos cambios preparándolos para ello desde el origen.
  2. Trabaja solo en los puntos necesarios para lanzar la versión 1.0
    • Sin olvidar lo mencionado en el punto anterior, claro...
  3. Asegúrate de mantener un prototipo siempre funcional
    • Si lo vas actualizando con las últimos desarrollos, y lo mantienes accesible a los usuarios finales, podrás ir corrigiendo o debatiendo con ellos desde la interfaz a posibles malentendidos en las funcionalidades de la aplicación, con lo que podrás, entonces, anticipar estos cambios en las partes que aun no has empezado o tienes entre manos...
  4. No hagas del proyecto un escaparate para mostrar lo "guay" que eres
    • Aquí... no es que discrepe, pero... si tu proyecto puedes aprovecharlo como escaparate del buen desarrollo y buen hacer de tu empresa o grupo de trabajo, es posible utilizarlo como un trampolín para futuros proyectos... o a la inversa, si la picias o el cliente no queda contento... una puerta abierta menos...
  5. Lo breve, si bueno, dos veces bueno... osea, mejor las cosas pequeñas
    • No seas mal pensado... estamos hablando de los métodos, ficheros, procesos, funciones....
  6. Si alguien no está en sintonía con el resto del grupo...
    • Habla con él/ella en privado
    • Reasígnalo o cambia sus tareas o funciones
    • Habla con él/ella en privado
    • Y si eres tu mismo... recuerda lo del escaparate...
  7. Diseña los módulos o clases construyendo interfaces, de forma que sea accesible facilmente por terceros módulos, reutilizable y facil de implementar cambios masivos.
    • Documenta estas interfaces a la perfección, pero no los módulos o clases que usa la interface, eso sí, mantén una escrupulosidad absoluta en la facilidad de lectura y mantenimiento del código de estos módulos.
  8. Cuando estés en el proceso de debug de un problema, nunca digas ¡¡¡ Pero si en mi equipo funciona !!!
    • ¿Quién no lo ha dicho alguna vez?
  9. Si hay algún fallo de funcionalidad o algún bug grabe en la parte ya desarrollada, no continues con partes de código nueva hasta haber resuelto estos problemas
  10. Si alguna parte del código es complicada de seguir el Lunes a primera hora, antes del primer café, rediséñalo.

Después de todos estos puntos, sería casi obligado hablar de algunos temas importantes, y debatir sobre ellos:

  • Tomas de especificaciones.
  • Reuniones de seguimiento con los clientes/usuarios y con el equipo de desarrollo.
  • Equipos multidisciplinares o equipos de especialistas
  • Prototipos, maquetas, beta releases...

Y prometo ir ocupándome poco a poco de estas cositas... por supuesto, necesito de tu colaboración, opiniones, críticas, experiencias... no te cortes...

lunes, 11 de diciembre de 2006

Librerías básicas javaScript para sitios Web "so cool taste"...

Recopilando las librerías de diseño que tengo en mi biblioteca, las que últimamente he utilizado más en algunos clientes y/o aquellas que sin utilizarlas por no serme necesarias hasta la fecha, he considerado como "must have", me he encontrado con estas:
  • Moo.fx - librería muy ligera para aplicar efectos, "hija" de prototype.js o de mootools, a elegir, provee mecanismos para controlar el ancho, alto y la opacidad de elementos impidiendo una re-escritura de estos por el usuario de forma accidental.
  • Rico - Soporte para AJAX, y gestión de Drag and Drop, efectos cinematic, y más...
  • script.aculo.us - Pues más de lo mismo... AJAX, efectos, Drag and Drop, Tablas a go-go, y los ejemplos integrados con Rails... (lo mejorcito hoy por hoy... ¿no?)
  • Mochikit - Yo uso la parte de logging, pero tiene muchas más cositas, como todos...
  • dojo - El uso principal que le ha dado ha sido con gráficos estadísticos y vectoriales en 2D. Implementa también ayuda a discapacitados visuales (alto contraste, readers, etc) junto con "gadgets" curiosos...

Y no siendo JavaScript, en último lugar pero no menos importante (me ha resultado muy util en ocasiones):

¿Se te ocurre alguna más que yo no tenga en mente? ¿Usas tú alguna que crees que todo el mundo debería conocer? Este el momento de añadir elementos a esta lista...

Brainstorming (II)

Posteado por Ángel en PresionBlogosferica el 11 de Diciembre de 2006


Tal como
prometí, la continuación del artículo sobre la realización de Brainstormings.

Nos quedamos al final de la fase de creación:



Las ideas han ido surgiendo y se han ido anotando… Es importante insistir en que, si bien debe establecerse un límite horario, es igualmente importante fijar un objetivo cuantitativo, y mi consejo es fijarlo en el orden de los cientos de ideas. A veces no será posible, sobre todo cuando el objetivo de la sesión esté muy delimitado o el campo sea muy específico, pero es bueno marcarse objetivos ambiciosos.


Otra cosa que se me olvidó comentar en el artículo anterior: Invitad a gente de fuera. Los miembros de un grupo, equipo o Departamento pueden estar muy retroalimentados entre ellos con la misma información. Traer a personas de fuera - incluso mejor si no tienen ningún conocimiento sobre la materia - estimulará el proceso creativo. Además, el cruce de experiencias y conocimientos durante la fase de destilación puede ser crucial si de lo que se trata es de innovar.


Pasemos pues a la destilación. Durante esta fase, procuraremos no solo identificar las buenas ideas, sino ver qué podemos aprovechar de las que se descarten e incluso generar nuevas ideas derivadas de las que ya existen.


Al igual que en la fase anterior, existen unas reglas de obligado cumplimiento:


ANOTAR LOS CRITERIOS DE VALORACIÓN: Usar frases comenzando con “Debería”, “Sería deseable”, “Es necesario que”. Esto nos servirá para evaluar las ideas de forma homogenea y no arbitraria.


IDENTIFICAR GRUPOS O CATEGORÍAS DE IDEAS: Para esto, los mapas mentales son fenomenales. Si además habéis seguido mi consejo de usar post-it, podréis ir moviendo las ideas hacia las zonas del mapa a las que pertenezcan.


REVISAR TODAS LAS IDEAS: Por extrañas, pequeñas o absurdas que parezcan, ninguna idea debería quedar si evaluar. Dedicadle al menos un minuto a cada una.Si, ya lo se, cien ideas a un minuto cada una son cien minutos…Nadie dijo que la creación de buenas ideas, de esas que marcan la diferencia, fuese rápida. Si queréis ideas rápidas y baratas, buscad algo en google… (*)


CLARIFICAR LAS IDEAS Y LO QUE SIGNIFICAN: Durante la fase de creación dijimos que no valía criticar ni hacer preguntas. Ahora es el momento. ¿Que ha querido decir la persona que ha propuesta esa idea? ¿En qué funcionamiento estaba pensando exáctamente? ¿Cómo piensa que se imlementaría?


USAR FRASES CONSTRUCTIVAS, NO DESTRUCTIVAS: Si os dedicáis a reiros de los que han propuesto las ideas más absurdas, solo lograréis coartar el proceso creativo. Por otra parte, si no sois constructivos con una idea podríais dejar pasar algún aspecto de la misma que os de la clave de lo que andais buscando… Algunas frase de estimulo podrían ser:


  • ¿Qué se podría hacer con esto?

  • ¿Cómo podría modificar esto para aplicarlo a un nuevo uso?

  • ¿Qué pasaría si se cambiase esto de alguna manera?

  • ¿Qué cambios podríamos introducir para provocar mayor atención?

  • ¿Por qué no arriba en vez de abajo?

  • ¿Qué podríamos eliminar?

  • ¿Qué se conseguiría si alteramos el orden?

  • ¿Cuáles son las cosas opuestas?

  • ¿Por qué no podría tener menos partes?

  • ¿Y si dijésemos esto al revés?


CLASIFICAR O PUNTUAR: Usar un baremo, bien con calificativos (excelente, interesante, no aprovechable) o con puntos (cero a cinco, cero a diez)…



ELIMINAR CONSENSUADAMENTE LAS IDEAS QUE NO SEAN UTILIZABLES: Cuando una idea no vale, no vale. Hay que intentar exprimirlas y luego pasar a la siguiente. Pero si alguien piensa que la idea no es tan mala, quizás tenga razón. Preservadla hasta el final, cuando hagáis una segunda o tercera criba. Solo deberían eliminarse las ideas a las que todos penséis que no se le puede sacar más partido.



Con toda esta información, es recomendable que el coordinador de la sesión realice un pequeño memorandum en el que explique el objetivo, los participantes, las áreas de ideas exploradas y las mejores que se han obtenido. Este tipo de documentos ayudan a demostrar a las organizaciones la utilidad del Brainstorming como técnica productiva.



(*) Esta frase me recuerda a una similar aparecida en una tira cómica protagonizada por

Dogbert: “Puedo darle buenos consejos por una tarifa de 60.000$…También puedo darle malos consejos al precio reducido de 40.000$”

jueves, 7 de diciembre de 2006

IBM vota "no" al OpenXML de Microsoft en el ECMA

Pues aunque todo el mundo esperaba un "si" por parte de todos las grandes empresas del mundillo del desarrollo, IBM se ha desmarcado con un rotundo "no" a la ratificación como estandar la propuesta "OpenXML" para la definición de documentos de oficina (léase MSOffice, OpenOffice, etc, etc.)

Bob Sutor, quien defendió la postura de IBM en el congreso celebrado hoy, llevaba tiempo anunciando su postura: la defensa a ultranza del estandar OpenDocument Format (ODF), sobre el que ha publicado varios trabajos...

Y me gustaría plantear la pregunta... ¿ IBM defiende sus intereses con este voto o el interes de los estándares, sean o no de facto ?, porque, al final, todos sabemos que terminará siendo aprovado el esquema de definicion OpenXML como estandar ISO y utilizado por todo el mundo (ya lo es con Open Office, etc... pero si tal como dicen al menos 7 de cada 10 ordenadores usan Windows con MS-Office o MS-Works en su defecto...) ¿Por qué el voto en contra de IBM?... no se....

En anteriores congresos, Microsoft jugó en el mismo equipo que IBM definiendo las bases de estos estándares e incluso los orígenes comunes (hoy ODF), fueron ratificados por Microsoft a petición de IBM....

ODF, cuenta a día de hoy con varias versiones y revisiones en las que se han ido añadiendo posibilidades a este formato, curiosamente, posibilidades que ya tiene el formato ofrecido por Microsoft.

Enlaces:
Blog de Bob Sutor
Is Open XML a one way specification for most people? (por Bob Sutor)

Brainstorming (I)

Desde Presión Blogosférica por Ángel

Se abusa demasiado de este término. Cada vez que se juntan cuatro personas a discutir, pensar o darle vueltas a una idea, es que hemos estado de brainstorming. Pero si nos ponemos académicos, este término se refiere a una técnica concreta para estimular el proceso creativo y, como tal, tiene ciertas reglas y procedimientos. Voy a reflejar aquí las que a mi me constan y que he empleado, lamentablemente, en muy poquitas ocasiones (porque las empresas no suelen prestarse a estas frivolidades, fijate ellas que serias ) pero en todas ellas con resultados espectacularmente buenos - ya ves, lo que son las cosas .


Ante todo, es necesario que una persona dirija la sesión. Solo en grupos que ya están muy acostumbrados a la mecánica del brainstorming aconsejaría prescindir de esta figura. El siguiente principio básico de un brainstorming (tormenta de ideas, para los puristas del idioma) es dividir la sesión en dos partes. Tres si lo hacéis con calentamiento.


Un calentamiento consistiría en hacer unas cuantas listas de prueba que no tengan nada que ver con el objetivo de la sesión. Por ejemplo, empezar nombrando cincuenta marcas de comida. Luego seguir con cincuenta prendas de ropa, cincuenta marcas de coche…¿Os acordáis del un-dos-tres? . Da igual si se consigue llenar la lista o no, se trata solo de difuminar un poco la consciencia, comenzar a disociar las ideas y calentar un poco las neuronas.


A continuación hay que centrar el concepto de la sesión: ¿Por qué estamos aquí? ¿Qué queremos conseguir? Para no perder el foco, recomiendo reservar una pizarra o papelógrafo en el que ir realizando un

mapa mental de la sesión.

Pasaríamos entonces a la primera fase del brainstorming: La fase de creación. Durante esta fase, todo vale. La cantidad vale más que la calidad. Se trata de fijar un número determinado de ideas (100, 200, 300…) e ir nombrando todas las que se nos vayan ocurriendo, por absurdas o inconexas que nos parezcan. Hay una serie de reglas que es importante cumplir:


TODO VALE: Da igual lo absurdas que parezcan las ideas. Precisamente cuando se agotan las respuestas convencionales es cuando empieza el proceso creativo.


CANTIDAD ANTES QUE CALIDAD: Lo importante en esta fase es generar muchas ideas, agotar el saco de las preconcebidas, las lógicas y las evidentes


PROHIBIDO CRITICAR: Las ideas no se critican. Todas las ideas valen lo mismo. No se permiten comentarios negativos:

  • Eso no funcionaría
  • Seamos serios
  • Vaya tontería
  • Esto no sirve para nada
  • No tenemos personal / tiempo / recursos / presupuesto para eso


ESTIMULAR/VALORAR LO DIFERENTE Y EXTRAÑO: Frente al punto anterior (no criticar), el contrapunto es precisamente premiar e incentivar las ideas que más se salgan de la senda habitual de pensamiento


ROBAR IDEAS: No solo se permite, sino que se estimula y se premia el copiar las ideas de otros dándole otros matices


TRABAJO EN EQUIPO (NO HAY “PADRES”): El director de la sesión debe conducir la misma y procurar que todo se haga según las reglas, pero ahi acaba su autoridad. No es su labor reñir a los que se saltan las reglas oi los que menos participan. Es el equipo el que debe tomar esa labor.


ORGANIGRAMA PLANO (NO HAY “JEFES”): Si los integrantes del equipo están cohibidos porque hay Jefes en el mismo y no quieren discutir con ellos, contradecirles o temen parecer ridículos ante ellos, es preferible que los Jefes no participen. Lo ideal es que reine un clima de equipo y organigrama plano.


TODOS PARTICIPAN (100% ENERGÍA): El equipo debe procurar estimular a los que más les cueste arrancar. Típicamente, al principio habrá personas que contribuyan poco, pero si logran saltar la barrera mental, se convierten en colaboradores al cien por cien.


TRABAJO EN CÍRCULO: Si en un momento dado la sesión se atasca, repasar desde el principio las ideas generadas y tratar de generar nuevas ideas basadas en ellas o como combinación de varias.


TOMAR NOTA DE TODO: Es responsabilidad del director de la sesión ir tomando notas de todas las ideas. Tambien es recomendable ir identificando areas o grupos de afinidad, para lo cuál es muy util usar el mapa mental que mencionaba al principio. Una técnica muy buena para esto es lo que los americanos llaman COW: Cards On the Wall, o sea, usar post-its u otro tipo de medio para anotar las ideas e ir pegándolas en la pared, lo cuál permite ir moviéndolas de sitio para acercarlos a grupos o areas de similitud.


Seguimos en otro post con la siguiente fase: La destilación…


Technorati Tags:

Ruby on Rails 1.2 RC1

Desde genbeta por Salva Castro







La primera versión candidata para la versión 1.2 de Ruby on Rails 1.2 ya puede usarse y descargarse desde hace un par de días. Parece ser que incorpora muchísimas novedades al framework de desarrollo de este potente lenguaje y que constituye una actualización bastante importante a todos los niveles, recomiendan que la comunidad de desarrolladores vaya viendo las novedades que se incorporan y ayuden a mejorar la plataforma para que pueda lanzarse una versión final con la mayor brevedad posible para que todos puedan disfrutar de las mejoras estructurales que trae esta nueva versión.



Vía
digg

Más información Riding Rails: Rails 1.2 RC1

Bonus Track Libros online gratuitos sobre Ruby on Rails

InputDraw, usa la pantalla táctil en aplicaciones web

desde genbeta por Sacha Fuentes
















InputDraw es un componente diseñado en flash que permitirá a nuestras aplicaciones web aprovechar las características de los dispositivos con pantalla táctil. Los que seáis fieles lectores de Xataka sabréis que los UMPCs y los smartphones están a la orden del día. Pero los formularios web no pueden aprovechar todas las características de estos.
Con InputDraw solo tendremos que insertar un componente flash y el usuario podrá escribir y dibujar en ese control, obteniendo como resultado un fichero en formato SVG con los datos que se que hayan introducido.

Posibles aplicaciones de esto son, por ejemplo, un webchat donde los usuarios puedan enviarse dibujos ellos por hechos mismos. Su uso es gratuito para proyectos no comerciales, mientras que si es comercial habrá que pagar 15 euros de base más 2 euros por cada lugar en que se use.


Enlace InputDraw.