Qué es experiencia de usuario y quienes tienen que velar porque esta sea buena

Hace ya algunos días que no pasaba por aquí, no obstante, esta semana por fin he sacado un poquito de tiempo para escribir un post que me ronda por la cabeza desde hace mucho tiempo. El post lo he publicado en el blog de Kabel Sistemas de Información y habla sobre que es la experiencia de usuario, que no es y sobre todo quienes son las personas que han de velar porque esta, sea siempre buena.

El susodicho post podéis leerlo a continuación:

¿Que es la Experiencia de Usuario?

De un tiempo a esta parte, por todos lados se esta hablando de experiencia de usuario (ux), no obstante, continuamente nos encontramos con situaciones que ponen de manifiesto que en el sector todavía no está muy claro que es eso de la experiencia de usuario y quienes son los responsables de conseguir una buena experiencia de usuario.

Wikipedia, define la experiencia de usuario como:

Conjunto de factores y elementos relativos a la interacción del usuario, con un entorno o dispositivo concretos, cuyo resultado es la generación de una percepción positiva o negativa de dicho servicio, producto o dispositivo.

Normalmente cuando en el ámbito del desarrollo de software se habla de experiencia de usuario, nos encontramos con que de lo que se habla realmente es de usabilidad y diseño gráfico y según la definición anteriormente citada, podemos deducir que la experiencia de usuario  desde luego tiene que ver con aspectos como usabilidad y diseño gráfico, pero realmente con lo que tiene que ver es con la percepción.

Por lo tanto:

Experiencia de usuario, no es usabilidad.
Experiencia de usuario no es diseño gráfico.

Experiencia de usuario es más que todo esto, experiencia de usuario es percepción.

La percepción es el acto de recibir, interpretar y comprender a través de la psiquis las señales sensoriales que provienen de los cinco sentidos orgánicos.

Según Wikipedia:

La percepción obedece a los estímulos cerebrales logrados a través de los 5 sentidos, vista, olfato, tacto, auditivo, gusto, los cuales dan una realidad física del medio ambiente.

Por lo tanto, podemos afirmar que la experiencia de usuario cuando interactuamos con un producto concreto, sera buena o mala en base a los estímulos recibidos y la manifestación del producto en una realidad física. En desarrollo de software, los estímulos que vamos a recibir, van a ser los relativos a eficiencia, sencillez, visibilidad y calidad de la información, navegabilidad, encontrabilidad, consistencia, estándares, performance o gestión de los errores por citar algunos.

No obstante, de todos estos factores enumerados, encontramos que varios de ellos, si que están totalmente relacionados con el desarrollo de interfaces de usuario, pero también encontramos otros, que tienen más que ver con negocio y arquitectura del producto.

¿Quienes son los responsables de trabajar la experiencia de usuario?

Por lo general, se identifican a los arquitectos de información, diseñadores de interacción o diseñadores gráficos como los responsables de definir, trabajar y conseguir una experiencia de usuario buena, pero esto es un error.

El responsable de conseguir una buena experiencia de usuario es el equipo.

El equipo de desarrollo es el responsable de la experiencia de usuario, ya que es muy difícil encontrar una única figura que pueda ejecutar las acciones necesarias para garantizar que la experiencia de usuario es buena, principalmente porque para conseguir una buena experiencia de usuario, tenemos que trabajar aspectos de disciplinas muy diferentes.

Por un lado, tenemos que tener un responsable de producto (Product Owner) que además de velar por los aspectos relativos al negocio, sea consciente de que una buena experiencia de usuario es directamente proporcional a la calidad del producto y en muchos casos, también al éxito del mismo.

Por otro lado, el líder tecnológico del proyecto, además de velar por el diseño, arquitectura y calidad del software, también tiene que velar por la experiencia de usuario que en su ámbito de actuación, se traduce en performance.

Las aplicaciones han de ser rápidas y ágiles, y este objetivo, lo perseguirán tanto el arquitecto como los desarrolladores.

Y por supuesto, arquitectos de información, diseñadores de interacción y diseñadores gráficos, concibiendo una interfaz de usuario usable, accesible y amigable, con buena navegabilidad, con una acceso a la información sencillo, haciendo uso del diseño gráfico como medio no como un fin en si mismo.

No hay ningún producto de calidad y éxito en el mercado que tenga una mala experiencia de usuario o dicho de otra forma, la totalidad de los productos que hay en el mercado que han tenido éxito, tienen una experiencia de usuario excelente.

Pensad en los iPods de hace 6 años.

¿Y vosotros qué opináis?

Anuncio publicitario

El concepto de terminado en el mundo del desarrollo de software

La semana pasada, en medio de la vorágine que esta suponiendo este mes de Agosto, escribí un post en el blog de Kabel Sistemas de Información donde hablaba sobre el concepto del trabajo terminado.

En el ámbito del desarrollo del software, vamos a encontrar que en función del rol que interectue con una tarea, normalmente el significado de terminado es diferente. Es muy importante, definir que se espera de una tarea y cual es el camino para conseguirlo. A continuación podéis leer el post, o podeís acceder al post que escribir originalmente en el blog de Kabel.

Acabado, cerrado o terminado, son palabras usadas comúnmente para referirnos a lo mismo: el momento en el que a una tarea no es necesario dedicarle más tiempo.

Probablemente el concepto de terminado, sea uno de los conceptos que más controversia levanta en el mundo del desarrollo de software, ya que es algo muy habitual que el concepto de terminado sea diferente para los diferentes roles que intervienen el ciclo de desarrollo y por lo tanto, cuando una persona del equipo de desarrollo dice esto esta terminado o cerrado, el jefe de proyecto, el arquitecto o el product owner esperan una resultado concreto que casi seguro es diferente al que espera alcanzar el desarrollador.

¿Que supone esto? tareas que se reabren / tareas que no se cierran, fricciones y en algunos casos frustración.

Evitar los problemas que surgen en relación al trabajo terminado es un propósito que tiene que perseguir la persona que esta liderando el desarrollo del proyecto y además, tenemos que entender la importancia que tiene ya este concepto esta directamente relacionado con otros de gran importancia, como la evolución del proyecto o el trabajo ideal.

Evitar los problemas que surgen en torno al trabajo terminado es algo asumible, simplemente, prueba lo siguiente:

Define cuando se encuentran las tareas terminadas.

Las tareas se encuentran terminadas cuando el responsable de hacer las pruebas dice que esta terminada.

Sencillo, contundente y sin dejar lugar a ningún tipo de duda. Una tarea estara acabada cuando la persona que prueba dice que esta acaba y que no es necesario dedicarle más tiempo.

Los hay que también defienden que una tarea esta acabada cuando una vez se ha desplegado la solución funciona en un entorno idéntico al que será el entorno de producción. Más o menos es lo mismo, ya que cuando decimos que el responsable de pruebas dice que esta acabada, esto implica que la solución ha tenido que desplegarse, que la solución ha de ser estable etc.

Una tarea estará terminada cuando el responsable de hacer las pruebas dice que esta terminada. En esta afirmación hay una parte muy importante que es “el responsable de hacer las pruebas”, es decir, damos por hecho que tendremos una persona implicada en el proyecto cuya labor sera probar y decir que es lo que esta y que no esta cerrado. Una persona que en definitiva se responsabiliza de lo que se va desarrollando y de que los  acabados y niveles de calidad del producto son suficientes.

Define que significa terminado y que niveles de calidad esperas cuando algo esta terminado.

Comparte con el equipo de desarrollo que esperamos cuando algo esta terminado. La comunicación dentro del equipo es directamente proporcional al resultado del ciclo de desarrollo. En relación a las tareas que se encuentran hechas y las que no lo están, también. Como hemos dicho en la introducción normalmente nos encontramos que el concepto de terminado es diferente en base al role que desempeña cada uno de los miembros del equipos, así pues, unifica el concepto de terminado, deja claro cuando esta terminada una tarea y que es lo que implica.

Un buen ejercicio, es describir que es lo que se espera de cada una de las tareas y dejarlo escrito. Evidentemente esto tiene un coste en la gestión / creación de tareas, pero este sobre coste sera siempre inferior al coste que tiene sentarse con cada miembro del equipo que participa en el desarrollo de una tarea y contarle que esperas de ella o por supuesto, del coste que tiene esperar un resultado sin especificar cual es el resultado.

En un proyecto en el que participé, nos encontramos que el día que nos hicieron una demo del proyecto con las tareas terminadas, no se había realizado ningún trabajo en relación a la interfaz de usuario. Cuando nos hicieron la demo del supuesto trabajo terminado y preguntamos que pasaba con la solución ya que no tenía una hoja de estilos que plasmara la imagen corporativa del cliente ni ayudara a comprender lo que se le estaba exponiendo al usuario final, la respuesta fue:

El trabajo esta hecho, los estilos son interfaz.

Poco que decir al respecto la verdad. No obstante, ¿Que es lo que ha pasado para que un proyecto se considere terminado cuando falta por desarrollar una de las piezas más importantes del mismo?

No utilices el termino terminado.

Terminado es un concepto demasiado absoluto, muchas veces lo utilizamos pero no siempre es el mejor. Es decir, dado que vamos a tener en el equipo una persona que va a ser el responsable de definir que esta terminado, trata de que el termino terminado solo lo utilice él.

Desde el punto de vista del desarrollador, puedes utilizar otros términos, términos no tan absolutos que te dan margen para interactuar con las tareas, por ejemplo, en scrum, es un formalismo comúnmente aceptado utilizar los términos rojo y verde.

• Rojo cuando la tarea se encuentra en progreso.
• Verde cuando ya se ha realizado el trabajo y podemos considerarlo hecho.

Como conclusión, evitar los problemas que surgen en relación al trabajo terminado, es tan sencillo como hacerle ver al equipo cuando se puede dar una tarea por cerrada, quien dice que esta abierto y qué está cerrado y sobre todo que todas las personas que intervienen en el ciclo de desarrollo, tengan el mismo concepto de lo que supone que algo este terminado.

Y a tí, ¿que te parece? Espero comentarios.

Equipos de desarrollo, productividad y software o como mejorar la productividad del equipo de forma sencilla

Anoche, escribi un post muy chulo sobre como mejorar la productividad de los equipos de software en el blog de Kabel, compañia para la que trabajo.

En este post, cuento experiencias propias que pongo en práctica en los proyectos que ejecuto con Kabel. En el hablaba de una serie de prácticas que van a promover que el equipo de desarrollo se encuentre coexionado y alineado con una forma de trabajar y los objetivos que hay que cumplir.

Si quieres leerlo, puedes hacerlo mediante el post escrito en el blog de Kabel, o a continuación:

Uno de los aspectos recurrentes al que nos enfrentamos cuando nos encontramos inmersos en el desarrollo de proyectos de software es la gestión del retraso en la ejecución de tareas planificadas por parte del equipo de desarrollo.

Normalmente, antes de iniciar cualquier proyecto, incluso antes de de haber ganado un proyecto, se realiza un ejercicio de definición de alcance del proyecto y estimación. Estimar es un proceso (normalmente) empírico por medio del cual tratamos de definir el coste en tiempo(por lo tanto también en dinero) del trabajo que vamos a realizar. ¿Qué sucede en la vida real? que en algunas ocasiones, nos encontramos con que el tiempo dedicado a la ejecución de las tareas es más alto del que hemos estimado / planificado.

Cuando estoy liderando un equipo que crea software y detecto que esto sucede, la primera aproximación que realizo es tratar de analizar como esta trabajando el equipo y ver si hay un estado mental de equipo y proyecto. Que quiero decir con esto, pues simplemente que el equipo tiene que avanzar en un dirección y todos los miembros del equipo tienen que tener en la cabeza cual es el próximo objetivo a alcanzar, cuando lo vamos a alcanzar y la calidad que tenemos que alcanzar para poder calificarlo de éxito.

Es muy importante que lleguemos a este estado mental de proyecto ya que esto nos va a permitir ser mucho más productivos y aumentar el velocity de forma significativa.

Como lo conseguimos:

El equipo ha de estar junto.

Que el equipo de desarrollo ha de estar junto parece evidente, pero es sorprendente ver como algo que debería ser habitual no siempre sucede y encuentras que en una misma sala, hay varios equipos de desarrollo y cada miembro de los equipos, en una punta de la misma.

Esta situación genera interrupciones (por ejemplo, cuando tenemos que preguntar algo y nos levantamos y te cruzas con otro de tus compañeros y se mantiene una charla), genera ruido(cuando dos personas hablan desde sus sitios en voz alta), genera problemas de comunicación (ya que es muy dificil realizarla de forma eficiente), no permite que se comparta el conocimiento correctamente (la distancia física fomenta que no todas las personas puedan acceder al mismo) etc.

Reduce el espacio físico y pon a todos los miembros del equipo juntos y si puedes separados / aislados del resto. Verás como de repente, el equipo estará más centrado, verás como hay menos interferencias en la realización de tareas, verás como la comunicación es más eficiente y fluida y verás como poco a poco se crea ese ambiente de proyecto, es decir de tensión debido precisamente a que evitamos todo lo anterior.

Reduce las interferencias al equipo.

Muy importante. Reduce interferencias. Si ves que alguno de los miembros del equipo constantemete es interrumpido, trata por todos los medios que esto no suceda.

Cual es la mejor forma, nombra a un miembro del equipo como el portavoz (o como lo quieras llamar) del mismo, canaliza todas estas interrupciones a través de el y que sea esa persona el que se encargue de gestionarlas. Si alguno de los miembros del equipo, se encuentra desarrollando a tiempo parcial, trata de cerrar ese tiempo en base a jornadas, es decir, es mejor que este de lunes a jueves al 100% y el viernes se dedique a otro proyecto a que cada día de la semana le dedique una horita a ese proyecto.

La concentración del equipo en las tareas que esta realizando es directamente proporcional a la calidad, velocidad y resultado de la ejecución de tareas, por lo tanto del proyecto.

Crea hábitos.

Crea habitos, trata de realizar la reunión de scrum SIEMPRE a la misma hora, trata de ir a comer a la misma hora, trata de tomar el cafe a la misma hora y además, trata de hacer todo esto con todo el equipo. Nos reunimos todos, tomamos el cafe todos y comemos todos juntos. Estas acciones simples, permiten crear esa conexión de la que hablaba anteriormente, permite crear ese estado mental y en la práctica, implica que cuando tomamos cafe, tratamos de resolver dudas respecto a tareas, comentamos problemas que hemos encontrado, le ayudamos a un compañero, así que, cuando  estamos en la reunión de scrum, hablamos del proyecto, cuando tomamos cafe, hablamos del proyecto, cuando comemos, hablamos del proyecto, cuando… hablamos del proyecto. PROYECTO, PROYECTO, PROYECTO.

El proyecto siempre ha de estar presente y todo el mundo tiene que estar a mil con el mismo. Desde luego para asuntos personales / sociales etc. también hay tiempo, pero trata de que sea menor que todo lo relativo al proyecto.

Comparte objetivos, fechas y plazos.

Comparte los objetivos, fechas y plazos, es más, haz participe al equipo en la planificación de estos objetivos, de las fechas y los plazos y trata de que todo mundo este involucrado y de acuerdo con estos aspectos.

Que los compromisos salgan del equipo, siempre te va a ayudar a compartir la responsabilidad y que cada uno de los miembros del equipo trate de conseguir este objetivo ya que son responsabilidad suya directamente.

Que todo el mundo tenga presente que hay que entregarle al cliente y cuando hay que entregárselo.

Fomenta las buenas relaciones del equipo.

Todos los miembros  del equipo han de tener con sus compañeros una relación de confianza basada en el respeto. Es muy importante que el equipo este a gusto con sus compañeros, que disfrute trabajando con ellos y que los conozca bien.

Como fomentar estas buenas relaciones, pues simplemente al crear hábitos ya estas haciendo algo importante, además también puedes tratar de realizar alguna actividad que vaya en esta linea.

Lo que esta claro es que el equipo tiene trabajar bien junto y las relaciones tienen que basarse en el respeto. Si alguien no cumple con esto, tendrá que salir del equipo.

Aquí acaba el post, y a tí ¿que te parece?

Metro, mucho más que tiles

Y a continuación una entrada que escribi en su día en el blog de Kabel. Vamos con un poco de Metro y Windows Phone.

Supongo que a día de hoy todos hemos oído hablar de “Metro” o de términos como Metro Style.

Metro, además de ser un estupendo medio de transporte, viene a ser el código de identidad visual definido Microsoft, usado inicialmente en Windows Phone 7 y posteriormente evolucionado para Windows 8.

Lo primero que nos llama la atención de Metro, es el uso de una serie de elementos llamados tiles (traducido del inglés como adoquín) los cuales hacen la función de call to action (en los diferentes dashboards que implementemos) y exponen información de lo que hay detrás de las aplicaciones que representan.

Es chocante enfrentarte a una interfaz de este tipo precisamente por la presencia y entidad que tienen estos elementos. Pero la verdad es que aunque inicialmente es lo que más nos llama la atención, hay mucho más detrás de lo que llamamos Metro que los tiles, que son los pilares en los que se fundamenta, veamos nuestra interpretación de los mismos:

Gusto por lo que haces y los pequeños detalles.

Trabaja el detalle de tus aplicaciones. Cuando todos los pequeños detalles están bien resueltos, el conjunto de todos ellos implica una aplicación bien resuelta. Demuestra que te gusta lo que haces y que lo valoras.

En este punto, aspectos como equilibrio, simetría o jerarquía son vitales y tendremos que tenerlos en cuenta para transmitir seguridad y confianza.

Rápido y fluido.

Una buena experiencia de usuario, pasa siempre, por el buen performance de nuestras aplicaciones. Nunca vamos a encontrar usuarios satisfechos con aplicaciones lentas. Si a una aplicación con un performance bueno, le sumamos una interfaz de usuario, que responde de forma natural a nuestras acciones encontraremos el camino a los buenos resultados.

Cuando desarrollemos aplicaciones bajo la filosofía Metro, esto es fundamental, aplicaciones rápidas con interfaces que responden a nuestras acciones (sería maravilloso poder decir a nuestros estímulos  ).

Auténticamente digital

Metro huye de diseños “skeuomorphicos” y recomienda el uso de elementos puramente digitales. Google es el otro gigante que adopta este principio claramente demostrado con todos sus productos.

Usemos la tipografía, usemos los colores intensos que aplican bien en medios digitales, usemos el movimiento cuando tengamos que usarlo, usemos la nube para ofrecer más servicios. Usemos todo lo que tengamos a nuestro alcance, pero sobre todo, no nos encorsetemos en formatos físicos a la hora de crear experiencias digitales. No necesitamos imitar el cristal de un botón para saber que un elemento es un botón.

Haz más con menos.

Este principio no es nuevo, realmente sería una evolución del “menos es más” de Mies Van Der Rohe y el “menos, pero con mejor ejecución” de Dieter Rams.

Céntrate en lo que tiene que hacer tu aplicación y resuélvelo de la mejor forma posible. Céntrate en las funcionalidades concretas de tu aplicación y desestima aquellas funcionalidades satélites (que normalmente tienen un uso residual) y dale a tus usuarios lo que necesitan y nunca olvides que un diseño esta cerrado cuando no hay nada que puedas eliminar.

Trabaja en equipo.

Intégrate con otras aplicaciones. Hay aplicaciones estupendas que resuelven de maravilla ciertas acciones, intégrate con ellas y benefíciate de todo lo que esta desarrollado.

Este principio, parece ser tendencia en el desarrollo de software, si necesitas enviar un mail, haz uso de tu cliente de mail, no desarrolles uno para tu aplicación.

Estos cinco pilares, son muy interesantes y una vez vistos, fundamentales para entender lo que supone Metro, pero si algo significa Metro es cambio. Es orientarse completamente al usuario,  ponerlo en el centro de todo, escucharlo, mimarlo y satisfacerlo. Es evolucionar y andar el camino y sobre todo implica estar vivo en un momento de constante cambio.

6 consejos a tener en cuanta cuando lideramos equipos que crean software.

A continuación os dejo con un post que escribí en su momento en el blog de Kabel Sistemas de Información compañía en la que trabajo y desempeño mi carrera profesional.

Siguiendo la estela del post 6 consejos a tener en cuenta cuando escribimos software, hoy vamos  a ver algunos aspectos que se dan en los equipos encargados de generar software que tenemos que tratar de evitar.

El código no es ni tuyo ni mío, es nuestro.

Una frase típica en los equipos de software es “mi código funciona”. El código no es tuyo, es del equipo, es nuestro. Siente el código que ha desarrollado otra persona del equipo como tuyo, esto, te va a obligar a involucrarte más en el desarrollo y ser más crítico con nuestro trabajo.

En mi equipo funciona.

El software que desarrollamos no funciona hasta que está desplegado en los entornos de producción y vemos que funciona. Eso de “en mi equipo funciona” es un error. Tenemos que asumir que nuestro código falla, y una vez refactorizado y muy probado, podemos tener la seguridad de que funcionara ok, pero no te lo creas hasta que no lo veas.

Cuantas veces te has encontrado con este caso. Muchas. Aprende de los errores y asume que el entorno de desarrollo no es el mismo que el de producción, que los servidores no van a estar siempre configurados de la misma forma y que aunque no lo queramos, pueden aparecen sorpresas a última hora.

Despliega el software que estas creando de forma asidua en un entorno exactamente igual que el de producción y no te encontraras con estas sorpresas de última hora, que implica cambios a fuego en ficheros de configuración o trabajos a deshoras de la noche.

Los equipos grandes son inversamente proporcionales a la productividad.

Cuanto más grande es un equipo menos productividad tiene el mismo.

Cuanto más grande es un equipo más obligado te vas a ver a realizar tareas de documentación, revisión de código, gestión de tareas, gestión del equipo, etc.

Evítalo.

Si el proyecto es muy grande, crea equipos más pequeños con tareas concretas. Delega funciones. Verás cómo la gente está deseando involucrarse en tareas que de otra forma tendría que realizar el jefe de proyecto / arquitecto y cuanta más gente, más trabajo y sobrecarga para esta persona.

5 equipos de 4 – 5 personas y un jefe de equipo van a ser mucho más productivos y eficientes que 1 equipo de 30 personas.

Interfaces de usuario y perfiles muy “juniors”.

Es un clásico, a menudo se desprecian las interfaces de usuario y se ponen a las personas con menos experiencia a implementarlas.

ERROR GRAVÍSIMO.

La pieza más compleja de toda aplicación, es la que le permite la comunicación hombre-máquina.

Pon ahí a gente con experiencia, profesionales que entiendan que están haciendo, que tengan gusto por el detalle y las cosas bien hechas y sobre todo que le den la importancia que tiene.

La tecnología es un medio no un fin.

La tecnología es el medio que nos va a permitir desarrollar ideas o resolver problemas y tenemos que usarla para eso.

En muchas ocasiones, cuando estas desarrollando software nos olvidamos de esto perdiendo el foco de las tareas que tenemos que realizar, para crear plataformas tecnológicas que se apartan la “idea” inicial que pretenden resolver.

Los mejores han de estar en tu equipo.

Rodéate de los mejores. Busca buenos profesionales. Gente que haya puesto aplicaciones en producción. Es complicado, pero existen muy buenos profesionales con gusto por lo que hacen, búscalos e incorpóralos al equipo de desarrollo.

6 consejos a tener en cuenta cuando escribimos software

A continuación os dejo un post que escribí en su momento en el blog de Kabel Sistemas de Información.

Principio de simplicidad.

El principio de simplicidad ha de prevalecer siempre. Siempre que te encuentres ante una decisión toma la más sencilla. A menudo cuando creamos piezas sumamente complejas sufrimos un impacto la productividad del equipo ya que es mucho más difícil comprender, entender y usar el código.

Esto sumado a las tiempo que hay que emplear en pruebas regresión cada vez que nos vemos en la tesitura de modificarlo hace que estos códigos sean un lastre a la larga.

En aplicaciones en las que hay códigos sumamente complejos, el equipo de desarrollo pasa más tiempo leyendo y depurando el código que escribiendo código y esto hay que evitarlo toda costa.

Además gran parte de los proyectos de software son después mantenidos por equipos que no han desarrollado las aplicaciones, por lo tanto, la persona que ha creado un código sumamente complejo desaparece y esto suele derivar en códigos que nadie quiere tocar por miedo al impacto que pueda tener.

Nada es reutilizable hasta que se reutiliza.

A menudo, cuando diseñamos los diferentes componentes de la aplicación, pensamos en el futuro de la misma e intentamos crear códigos reutilizables “por si acaso”.

Error.

Nada es reutilizable hasta que se reutiliza. Esta es una gran verdad que tenemos que tener clara en todo momento. Crear un código para posteriormente reutilizarlo (por que sí) implica complicar ese código, cayendo en el punto anteriormente enumerado.

No a soluciones genéricas que se adaptan a todos los casos.

Cuidado con los casos “voy a diseñar un control que valide lo que introduce un usuario, ya sea un mail, un código postal o un DNI”.

Este tipo de acciones, deriva en códigos complejos y a los problemas anteriormente vistos. A menudo, estas piezas de software mágicas resuelven solo lo que contemplan y conforme tienes que ir añadiendo funcionalidad vas complicándolo más y más.

Soluciones concretas a problemas concretos.

Construir de menos a más. Haz refactoring.

Siempre que creemos piezas de software, tenemos que partir de código sencillo y conforme vayamos teniendo necesidades, crecer sobre lo creado anteriormente.

Hacer uso de refactoring (http://en.wikipedia.org/wiki/Code_refactoring) es una buena práctica, dado que, conforme vamos revisando nuestro software, podemos detectar carencias y subsanarlas, además de ir añadiendo funcionalidades necesarias. Por otro lado, el refactoring te va a dar una visión clara de las funciones de que cada una de las partes de la aplicación a lo largo de todo el proyecto.

No a tu framework, usa frameworks ya desarrollados.

Evita en todo momento crearte tu propio framework. Hay gente, equipos enteros que se están encargando de esto. Usa estos frameworks. Ten en cuenta que seguramente, están desarrollados por buenos profesionales, que están perfectamente testeados y que prácticamente en el 100% de los casos, estos frameworks, van a ser bastante mejores que el tuyo.

Usa JQuery, Modernizr, usa el .NET Framework, usa el framework que quieras, pero no te crees el tuyo.

Por ejemplo, no puedes estar desarrollando un framework de acceso a datos cada vez que desarrollas una aplicación. Esto tiene un gran impacto en la productividad del equipo y seguramente no te van a pagar por desarrollar esa pieza, sino por resolver una problemática concreta. Céntrate en tu negocio.

Haz Pruebas unitarias.

El trabajar con pruebas unitarias, puede parecer que tiene un impacto en los tiempos del proyecto, y bien es verdad que dado que tenemos que escribir más código inicialmente vamos a tardar algo más, pero a la larga, nos va a permitir reducir los tiempos.

Si un código no funciona, vamos a detectarlo en el momento en que ejecutamos la batería de pruebas y esto nos permite ser más eficaces dado que sabemos en qué punto concreto falla nuestro software.

Trabajar bajo el paradigma del TDD, nos va a obligar a diseñar el código de una forma concreta (desacoplado) para poder probarlo, obteniendo así un software diseñado de manera “uniforme” a lo largo de todo el desarrollo, lo cual hace más sencillo su posterior uso, reutilización y refactoring por todo el equipo.

 

Francisco de Goya, en el año 1799, publico una serie de grabados realizados por medio de aguafuerte, aguatinta y retoques de punta seca que llamo Los Caprichos. Mediante estos grabados busco satirizar y retratar la sociedad española de finales del XVIII.

El sueño de la razón produce monstruos, es el grabado 43 de los 80 que componían la serie. Y este, además de posiblemente ser el más famoso de todos, cuenta con un título totalmente inspirador con el que no años después, si no siglos después, nos encontramos que su mensaje sigue siendo totalmente vigente.

En nuestro sector seguro que todos hemos visto casos en los cuales podemos decir que la fantasía ha sido abandonada por la razón y esto se ha traducido en aplicaciones de software monstruosas.

The real world agile roadshow: The frontend: HTML5 y Windows Phone 7.

El pasado día 17 de Enero, participe en The Real World Agile Roadshow siendo el responsable de la ponencia The Frontend: HTML5 y Windows Phone 7. Globbtv, fueron los responsables de la retransmisión y difusión del evento y ya está online el video del mismo.

En la ponencia, hablamos sobre experiencia de usuario, que es la experiencia de usuario, como conseguir una buena experiencia de usuario y los beneficios que nos aporta la misma.

Además hicimos una breve introducción de lo que supone HTML5 y lo que nos va a aportar a los desarrolladores y usuarios finales, cuando se firmara el estándar y como tenemos que empezar a desarrollar mientras tanto.

Para complementar la sesión, hicimos una breve introducción a Windows Phone 7, viendo sus herramientas de diseño y desarrollo, portal de recursos etc.

La ponencia tuvo una duración de 50 minutos y fue complementada por medio de tres demos (que fusionamos en dos para ahorrar un poquito de tiempo).

Podéis ve el vídeo en blog de Kabel Sistemas de Información.

Ya se que hace mucho de esto, pero como he dicho anteriormente, estoy tratando de recopilar todo lo que he hecho en este tiempo.

Evolución

Hace dos años y pico casi tres que no sacaba ni un momento para escribir en este espacio. La verdad, toda una pena ya que este sitio me ha dado muchas satisfacciones, buenos momentos y sobre todo me permitio estár más cerca de la cresta de la hola en situaciones que eran necesarias.

Y ¿qué es lo que he hecho durante todo este tiempo? A nivel profesional, he vivido una evolución que me a permitido  ver el negocio del desarrollo del software desde diferentes perspectivas lo cual ha sido totalmente beneficioso. Actualmente desempeño la posición de Arquitecto de Soluciones en Kabel Sistemas de Información,  una compañía española dedicada a la consultoría de Soluciones basadas en Tecnologías de la información. Es más, desempeño mi carrera profesional en Kabel desde hace 6 años casí 7 siete, y he pasado por las posiciones de Consultor Senior, Jefe de Proyecto, Especialista de Producto y ahora mismo Arquitecto de Soluciones.

A nivel personal, mi vida se ha establecido bastante y ahora tengo una relación estable, aunque de esto no voy a dar más detalles.

Respecto a la blogosfera, durante este tiempo he posteado cuando he podido en La tasca de Anita (un blog sobre cocina, que por falta de tiempo se encuentra en la misma situación que este) y en el blog de Kabel (lugar donde voy hablando de mi visión sobre el sector del desarrollo de software).

¿Y ahora que?  Ahora me encuentro compatibilizando mi trabajo en Kabel Sistemas de Información, compañía con la que me encuentro totalmente alineado y con el proyecto NBICI, lugar que me permite experimentar en cuanto a tedencias del sector tanto a nivel de desarrollo de software, como a nivel de arquitectura, como a nivel de gestión (ágil por supuesto).

A partir de ahora, tratare de centralizar todo lo relativo a las IT Technologies en este blog de manera que vuelva a estar un poquito actualizado. Además ire contando tambien hacemos en NBICI y espero darle un vuelta al tipo de entradas que he estado escribiendo, ya que ahora prefiero orientarlos a aspectos más filosóficos