martes, 26 de junio de 2012

AOS2012 - Una mirada atrás

Hola, esta entrada no es más que un compendio de diversas entradas que he ido creando, como resumen de las charlas a las que asistí en el pasado evento  Agile Open Space 2012, en Zaragoza.

He aquí el resumen:
  1. Extender el virus ágil
  2. Técnicas para el trabajo en remoto
  3. Gestión del código heredado
  4. Inception (1 de 2)
  5. Inception (2 de 2)
Como no pude asistir a todas, pero sí lo hicieron algunos de mis compañeros, mi reto es que me ayuden a preparar resúmenes de sus charlas. Como no me gustan los resúmenes en plan transcripción, les reto a que aporten sus opiniones, que no sólo digan lo que se dijo, sino lo que pensaron, las pegas que durante la charla, o después de la charla, vino a sus mentes. Es decir, las reflexiones del día después.

¿Que qué fue el AOS?

Fué un evento, en el que se trataron temas de metodologías ágiles en el mundo del desarrollo del software principalmente. Con casi 300 asistentes, se puede considerar todo un éxito de asistencia y participación.
El formato era variopinto: había charlas, coloquios, exposiciones, actividades participativas, talleres, etc. Todo comenzó el viernes 22 por la tarde, en que se decidieron los temas, y continuó durante todo el sábado (desde las 9 de la mañana, hasta la tarde/noche)

¿Esto del Open Space qué es?

Es una forma de organizar eventos que es autoorganizativa. Los propios participantes se presentan y postulan sesiones que se apuntan en un tablón. Los participantes votan por las más interesantes, y de esa forma se organizan las salas y horarios. Así se consiguen realizar las charlas más interesantes, y se descartan las menos votadas. Tal y como dice Juan Quijano en su blog de GenBetaDev:

"este sistema debería ser caótico y que no se debería poder llegar a ningún resultado coherente. En cambio los resultados demuestran que esto no es así. En poco más de una hora, estaban definidas todas las charlas, asignadas a una sala y a un horario..... Por un efecto de imitación y de forma vírica, se consiguió cosas que parecían imposibles. Como dejar un restaurante al completo en absoluto silencio, en unos pocos segundos. Y los comensales que no eran parte del evento, preguntar asombrados (después de realizar el anuncio que requirió el silencio)"

Otra descripción del Open Space, en palabras de David Bonilla en su blog:
"...no existe una agenda fija, sino que cualquiera puede proponer los temas que le parezcan interesantes para debatir y son los propios asistentes los que deciden, con sus votos, sobre qué se hablará durante el evento"

¿Y cuáles fueron las conclusiones?

  • Temas avanzados pero también hubo temas sencillos e introductorios para personas noveles en el mundo ágil.
  • Ambiente participativo y ágil (cómo no)
  • Oportunidad única de conocer los temas directamente de las personas que los conocen de primera mano.
  • Oportunidad única de tratar los temas en charlas abiertas y distendidas, donde todos pueden aportar ideas y conceptos.
  • Todo un ejemplo de motivación y ganas de compartir
  • Excelente organización, en un marco único, el edificio Seminario, facilitado por el Ayuntamiento de Zaragoza.
  • Posibilidad de aprender y compartir no sólo con desarrolladores. En este evento participan activamente psicólogos, expertos en User Experience, diseñadores, gente de marketing y RRHH, etc.
Para finalizar, adjunto unos links que tan pacientemente ha recopilado Visi Serrano, una de las ponentes en su Blog (no sé si hay un recopilatorio mejor de links, ya me perdonaréis pero el mejor que he encontrado ha sido el de Visi):

Links:

Otras entradas relacionadas:

http://najaraba.blogspot.com.es/2012/02/metodologias-agiles-y-coaching.htmlç
  • Psicología y Scrum: desarrollo ágil de equipos
1ª parte: http://uvedevisi.blogspot.com.es/2012/02/psicologia-y-scrum-desarrollo-agil-de.html
2ª parte: http://uvedevisi.blogspot.com.es/2012/03/psicologia-y-scrum-desarrollo-agil-de.html
  • Soluciones integradas de Project Management y Agile:
http://www.slideshare.net/Uve1971/project-management-and-agile-solutions

AOS2012 Gestión del código heredado

Esta entrada está basada en la charla que sobre este tema tuvo lugar en el Agile Open Space 2012, en Zaragoza, y al que tuve el placer de asistir.

Si queréis leer sobre otras charlas del AOS 2012, he preparado un índice aquí.

Una de las primeras charlas a las que asistí era la de cómo enfrentarnos al código heredado. La verdad es que el propio ponente (Pablo Bouzada), ya se me ha adelantado (claro, para eso es su ponencia), y lo ha dejado todo escrito en su blog. La verdad que fue una gran exposición, y se nota que domina el tema.

De todas formas, me gustaría que:
1º- Leyérais tranquilamente el blog original y
2º - Me permitiérais añadir aquí unos comentarios.

La verdad es que aunque interesante, el fondo del artículo no es nada novedoso. Básicamente nos indica que  todo ha de ser gestionado, y que los riesgos han de gestionarse también. Y en este caso, se trata de gestionar la transición para tomar el control de un proyecto heredado.

Mucho más interesante que el artículo en sí, me interesa el detalle de que si bien hasta ahora éramos simplemente ágiles, y rechazábamos procesos de gestión, nos empezamos a dar cuenta de que realmente la gestión es necesaria. No podemos ser tan ágiles como para decir: "Ok, me acaban de meter en un proyecto con código heredado, y como soy ágil, me pongo a picar y ya está".

Es precisamente el hecho de considerar necesaria la gestión, lo que me sorprende. Por fin somos ágiles...¡y gestionamos! Pues enhorabuena.

Pero no se trata de gestionar al tuntun, ni de meter el mega-proceso de gestión PMBOK que nos permita abordar con el 100% de garantías el proyecto. Se trata simplemente de abordarlo de forma lógica y ordenada, y con el mayor grado de agilidad posible. Aquí es donde Pablo Bouzada tras revisar otros métodos, acaba proponiendo uno más simple:
  1. Qué: Identificar qué tengo (a qué me enfrento)
  2. Cuánto: identificar el alcance.
  3. Cómo: preparar una estrategia para abordarlo, en especial creando una red de seguridad (test funcionales, UAT, unitarios,etc) que me permitan realizar cambios con cierta seguridad. Establecer un límite en dichos test (no se puede cubrir todo), relacionado con el alcance anterior.
  4. Cuándo: establecer una priodidad de las tareas, que me permita planificarme.
  5. Trabajar, ya por fin, con una cierta seguridad.
Otro punto interesante que surgió en la charla, estaba relacionado con algunos puntos que se producen en el mundo real:
  • ANS: ¿Has heredado un proyecto con Acuerdos de Nivel de Servicio? Pues lo tienes muy mal. Primero tienes que atender al contrato con el cliente, y luego, solo luego, podrás atender el proceso descrito. Por supuesto, lo ideal es poder tratar abiertamente esto con el cliente, y convencerle de que nuestra vida se puede volver un infierno si no nos da un período para poder aplicar nuestros 5 puntos anteriores. Sin embargo, el cliente ya tiene un contrato, y nada le obliga a hacer nuestra vida más fácil.
  • Compromisos: ¿Y si hay una fecha de entrega asociada al proyecto heredado? Aquí se supone que hemos heredado un proyecto sin entregar. La parte buena, es que al no estar en producción, no tenemos el call-center echando humo con clientes quejándose de incidencias. La parte mala, es que seguramente habrá una fecha en que ese proyecto heredado se deberá entregar. De nuevo, para acometer convenientemente los 5 puntos anteriores, es vital contar con la comprensión y el compromiso del cliente.
Voy a hacer un inciso. Y es que efectivamente, como se comentó en la charla AOS2012 sobre este tema, "el primer interesado en que el proyecto salga bien, es el cliente". Ok. De acuerdo, pero debo apuntar: "el cliente, lo primero en que está interesado es en NO PERDER DINERO". En algún caso, el cliente preferirá denunciarme y no pagarme (al menos no pierde dinero), que concederme de forma gratuita, el tiempo necesario para que usando los 5 pasos anteriores, pueda tomar las riendas del proyecto en condiciones.

¿Cómo? ¿Que el cliente prefiere no tener su producto? Pues no sería la primera vez que se da el caso. Por desgracia, en las metodologías ágiles, damos por sentadas dos premisas que al parecer nadie se detiene a comprobar:
  1. El cliente se involucra en el proyecto, y está dispuesto a dedicar el tiempo necesario para lograr el éxito del proyecto.
  2. El cliente desea el producto final, y está dispuesto a ese fin, sin escatimar en gastos.
Pues es posible, en algún caso, que no ocurra así. El éxito a cualquier coste, y menos en los tiempos que corren, no se lo pueden permitir todos los clientes. Y hemos de tener en cuenta, que en las empresas, quienes nos contratan han de reportar "hacia arriba" con el avance del proyecto y su coste.

Y no quiero decir, por supuesto, que en el mundo real las metodologías ágiles no sirvan (como parecen afirmar muchos). Lo que simplemente quiero decir, es que NO PODEMOS DAR TODO POR SUPUESTO. Todo tiene un límite, incluso la paciencia y el dinero de nuestro cliente.

Y vuelvo al tema tras el inciso. Los 5 puntos anteriores, el proceso mencionado, hay que aplicarlo. Pero hay que hacerlo dentro de los límites y plazos que tengamos, y haciendo partícipe al cliente. El cliente, debe tener visibilidad de porqué estamos refactorizando, metiendo test unitarios, etc. etc.

Y aquí me permito añadir un problema adicional (es lo que tiene el mundo real, que no es simple y maravilloso, sino retorcidamente complejo):
  • ¿Qué ocurre si heredamos el código...no de otra empresa sino de otro empleado? ¿Somos lo bastante honestos para decirle al cliente que necesitamos dedicar tiempo a "protegernos" de la chapuza que le habíamos hecho hasta ahora? Muchos pensarán: "claro que sí, el cliente lo va a entender". Es posible. Otros dirán "No, mejor lo hacemos sin que se entere el cliente, porque seguramente el cliente prefiera no seguir gastando dinero en alguien que ya le ha traicionado en su confianza".
En fin. Disfrutad de este gran artículo original de Pablo Bouzada, y sobre todo...suerte con los proyectos heredados.

domingo, 24 de junio de 2012

AOS2012 Técnicas para el trabajo en remoto

Esta entrada está basada en la charla que sobre este tema tuvo lugar en el Agile Open Space 2012, en Zaragoza, y al que tuve el placer de asistir.


Si queréis leer sobre otras charlas del AOS 2012, he preparado un índice aquí.

Introducción.

Esta charla estaba enfocada a tratar las herramientas, ventajas e inconvenientes de trabajar en remoto. Y no me refiero simplemente a equipos distribuidos. Me refiero a cuando un trabajador hace su actividad prácticamente al 100% de forma remota. Puede ser desde su casa, desde una oficina alquilada, etc. Lo que sí se ha de dar es que la mayor parte del tiempo, se encuentre en distinta ubicación géográfica respecto al resto del equipo (y respecto al cliente, claro).

Recomendaciones a seguir.

Vamos a ver algunas recomendaciones, que los asistentes nos hicieron para que si nos encontrábamos asistiendo en un trabajo de forma remota, se mitigaran los posibles problemas que pudieran surgir.
  • Es importante pasar las primeras fechas del proyecto, o la primera etapa, de forma presencial con el resto del equipo. Esto es muy adecuado de cara a mitigar la sensación de alejamiento posterior, y además, potencia el sentimiento personal de equipo entre los integrantes, facilitando su conexión y complicidad. El hecho de cultivar las relaciones humanas al principio, facilita enormemente el trabajo posterior.
  • Mantener un contacto personal periódico. Además de al inicio, es recomendable un contacto personal periódico con el resto del equipo. Por ejemplo, 1 vez al mes.
  • Mantener unificada toda la información relacionada con el proyecto, incluidos todos los correos electrónicos: tanto los intercambiados con el cliente, como los internos del proyecto. Esto facilita el poder hacer seguimiento de conversaciones o reuniones en las que no hemos podido estar al encontrarnos en remoto.
  • Utilizar una herramienta de comunicación  o chat en grupo que permita establecer charlas instantáneas en grupo, hacer comentarios, etc. Es importante no dejar fuera de las conversaciones a la persona desplazada, ya que se establecen lagunas en la conversación, que a la larga, afectan gravemente el rendimiento del trabajo.
  • Pair programming. Se habla de entorno a un 50 o 60% de trabajo siguiendo esta técnica.
  • Peer Review. Revisiones cruzadas de código.
  • Cultura de informar siempre lo que se está haciendo, al resto del grupo.
  • Cultura de estar informados en todo momento de lo hablado en reuniones, y de las conversaciones del resto del grupo.
  • Si se trabaja con auriculares, tener en cuenta que las conversaciones o reuniones en remoto no son como las presenciales. Cuando hablan 2 o más personas, tratar de seguir la conversación es muy complejo en remoto. Es por ello importante respetar los turnos, tratar de no mantener conversaciones paralelas, etc.
  • Es importante contar con alguna herramienta de control de presencia, que nos permita identificar si la persona remota está online, y al revés: que él pueda ver si el resto del equipo está conectado, o se ha ido a tomar un café (de nuevo aquí ayuda el char simple tipo "café. vuelvo en 10 minutos").

Herramientas

A continuación, comentamos algunas de las herramientas que se trataron en el evento.
  • Join.me
  • Terminal Server
  • Team Viewer
  • Lync
  • Kanban Flow

Ventajas

  • Por supuesto, una ventaja es la posibilidad de tener un horario completamente flexible. Nos podemos levantar a la hora deseada, lo mismo al acostarnos, etc, etc.
  • Propiedad colectiva del código
  • Ahorro de costes
  • Facilidad de atender sobre-esfuerzos en el proyecto
  • Facilidad de conciliar vida familiar, de viajar, etc.

Inconvenientes

  • Dificultad de mantener conversaciones o charlas en grupo a través de auriculares.
  • Riesgo de perder información (conversaciones, chats, correos, etc.)
  • Riesgo de aburrimiento (en el evento agile salió la frase "acabas viviendo y trabajando con el mismo pijama con el que te acostaste la noche anterior")
  • Riesgo de falta de compromiso
  • Riesgo de pérdida de relaciones humanas con el resto del equipo
  • Problemas con horarios (distintas costumbres, distintos países) y concurrencia
  • Dificultad de atender reuniones con el cliente, u otros eventos que requieran la presencia física.

AOS2012 Extender el virus ágil

Bueno, ya ha pasado el Agile Open Space (AOS 2012 en Zaragoza, España). La verdad es que ha sido una experiencia magnífica. Una excelente organización, y una gran oportunidad de compartir conocimientos y experiencias, tanto de la mano de los ponentes, como a través de las charlas de pasillo con los distintos asistentes. Si queréis leer sobre otras charlas, he preparado un índice de mis entradas aquí.

La primera charla a la que asistí era la de extender el tema ágil dentro de la propia empresa de cada uno.

Para empezar, se nos introdujo un libro con una serie de prácticas a seguir que permitan llevar a cabo  esta extensión del agilismo. El ponente, Alberto Gualis, nos fue desgranando estas pequeñas perlas:
  • Se útil
  • Facilita tus reuniones
  • Examina tus normas
  • Se puntual
  • Estructura tus interacciones
  • Anuncia tu intención
  • Gamificatus reuniones
  • Conduce experimentos con frecuencia
  • Gestiona visualmente
  • Inspecciona frecuentemente
  • Se entrenado
  • Gestiona tus límites
  • Socializay extiende libros
  • Pon atención explícita
  • Abre el espacio
  • Se jugetón
Al final, de lo que se trata es de hacer "ágil" fuera del propio desarrollo de software.
Algunos de los logros que se pueden obtener cuando el agilismo llega a otros ámbitos, son:
  • Rapidez para sacar conclusiones
  • Aumento de la motivación (diversión)
Una buena forma de empezar, es haciendo retrospectivas (insisto, en nuestro ámbito, no sólo en desarrollo de software). Y por supuesto, habrá algunas palabras que tendremos que evitar, para que el agilismo no se encuentre con obstáculos:
  • Cambio. La gente no quiere cambio. Bastantes cambios e indeterminaciones genera ya nuestro trabajo diario. Por eso no hay que hablar de cambio. No se busca cambiar (como tal). Lo que se busca es mejorar. Y  todo el mundo quiere mejorar, ¿no?
  • Nombres como Scrum, Kanban, y nombres propios/específicos de metodologías en general. De lo que se trata es de evitar que se rechace el agilismo desde el inicio. La gente puede verse resistente a la metodología "RJAB347", ya que puede percibirse como algo muy friki o exclusivo, una moda que genera inseguridad. Sin embargo, conceptos más generales como Mejora Continua, es más fácil que sean vistas con buenos ojos.
Además, hemos de dar seguridad tanto a los responsables como al resto de miembros de la empresa. La mejor forma de hacerlo es midiendo. Pero midiendo cosas sencillas.

miércoles, 20 de junio de 2012

Testing (III) - Análisis y resultados de las pruebas


Este es el tercero de una serie de artículos sobre el testing y el cmmi:

Vamos a retomar esta serie de posts dedicados al testing.

Nos habíamos quedado en el post anterior en la planificación de las pruebas. Por supuesto, faltaría la realización de las pruebas según lo planificado. Pero para ello, me gustaría dedicar un exhaustivo análisis de la herramienta HP Quality Center que he tenido el placer de probar.

Vayamos pues a la etapa de análisis y resultados.

Recopilación de resultados

En primer lugar, hay que recopilar los resultados. Es decir, para poder hacer cualquier tipo de análisis, no basta con probar. Ni siquiera basta con apuntar los resultados. Hace falta que esos resultados estén consolidados en un repositorio.

¿Acaso no desarrollas tu código y después recopilas y unificas todo en un repositorio? Pues con las pruebas igual. Hay varias formas de hacerlo:
  • Con herramientas como HP Quality Center que centralizan todo el proceso y se responsabilizan de las distintas fases y su integración.
  • De forma manual con simples ficheros Excel, por ejemplo.

Análisis de los resultados de las pruebas 

  • Con los resultados de las pruebas y el informe de pruebas presentes, se analizan los resultados para comprobar si se han cumplido los criterios que se especificaron para asegurar que la prueba ha sido exitosa. Los resultados de las pruebas de cada producto de trabajo tienen que figurar en los informes y éstos se tienen que analizar incrementalmente para poder darlos como correctos.
  • Cuando el resultado de las pruebas no es el esperado y no está claro que el defecto resida en el producto, es útil estudiar el “cómo se hizo”, para descartar que los errores se deban a problemas de métodos, de criterios o del entorno de pruebas. De nuevo, las herramientas nos ayudarán a buscar el "porqué" de los resultados.
Hay que aclarar que en ocasiones esta fase de análisis no tiene porqué llevarla a cabo la misma persona que se encarga de las pruebas, ni tampoco los programadores. Aquí un buen rol de QA, o incluso el jefe de proyecto, puede aprovechar su experiencia para arrojar luz sobre los resultados. En entornos ágiles, el scrum master podría encargarse de esta tarea.

Comunicación de resultados de pruebas

Una vez se han analizado los resultados de las pruebas, llega la parte más desagradable para el personal técnico: la comunicación de resultados. La comunicación se hace a varios destinatarios:
  • Al equipo de desarrollo. Es importante que sepan el estado del producto en cuanto a defectos encontrados, y una comparación respecto a fases anteriores o si es posible, respecto a otros proyectos más o menos similares. No se trata nunca de decir "lo hacemos mejor" o "lo hacemos peor". Este tipo de actitud es la mejor forma de cargarse las métricas.
  • Al gerente y otros responsables del proyecto. Aquí es crucial dar un sentido de "vamos bien" o "hay que mejorar". Tratar de engañarse con un "no es tan malo como parece", es la mejor forma de llevar un proyecto al fracaso. Si los resultados son buenos, hay que ser realistas y no dejarse llevar por un falso entusiasmo, acortando plazos (por ejemplo).
  • Al cliente. En numerosas situaciones, sobre todo en los entornos de testing y preproducción, el cliente estará al tanto del estado de defectos, y de los resultados de las pruebas. Es importante transmitir seguridad, y sobre todo, franqueza.
 
El próximo post debería ser por fin el que estoy preparando de automatización y gestión de pruebas con HP Quality Center como ejemplo.

miércoles, 13 de junio de 2012

Rolling Wave Planning

Mientras estaba preparando una formación en Microsoft Project para jefes de proyecto, he recordado este término. La verdad es que la expresión en inglés, si la conocía, no la recordaba. Ésta es una técnica de planificación, vieja conocida, que algunos habrán oído también nombrar como "planificación progresiva". Para mí, éste último era el término con el que la había aprendido. También la encontraréis como "planificación gradual".

En el PMBOK, está referida como "planificación continua con detalle incremental"

¿En qué consiste? Vamos a verlo.

Esta técnica se traduce en preparar una planificación como siempre, a alto nivel, pero a la hora de bajar al detalle de tareas del plan, lo haremos sólo para la primera fase del proyecto, la que tengamos que llevar a cabo de forma inmediata.

Por ejemplo, supongamos que hacemos un Project con las típicas fases (no entremos de momento en interacciones) de: "requisitos", "diseño", "desarrollo", "pruebas", "implantación". Esta técnica consistiría en dejar solamente detallada la primera fase, la de requisitos. Conforme nos encontráramos con el fin de los requisitos, actualizaríamos el detalle de la fase de diseño. Antes de terminar el diseño, tendríamos previsto el detalle de la fase de desarrollo...y así sucesivamente.

Se podría aplicar a otros ciclos de vida: por ejemplo en desarrollos ágiles, sería posible dar más detalle a las historias de usuario de las primeras 2 o 3 iteraciones, y dejar el detalle de las siguientes iteraciones para más adelante. En realidad, esta técnica está recomendada por muchos seguidores de las metodologías ágiles. De hecho, la planificación iterativa permite beneficiarse del conocimiento obtenido tras cada fase, ajustando mucho más el detalle de las fases siguientes, de forma progresiva.

Las ventajas:

- Me ahorro proporcionar detalle de las tareas para las que todavía no tengo suficiente visibilidad.
- Centro mis esfuerzos en el corto plazo, lo que me permite proporcionar una planificación mucho más ajustada a los equipos que están "en las trincheras" (y para los cuales, el "medio y largo plazo", no es más que un obstáculo, una preocupación futura).
- Proporcionan una forma de unificar los conceptos ágiles, con las metodologías tradicionales.

Inconvenientes:

- Sin proporcionar suficiente detalle a las fases o iteraciones futuras, es posible que la estimación global, y por tanto la planificación, no se ajuste a la realidad.
- Con ello, es difícil proporcionar una visión realista de los plazos, costes y esfuerzos totales o a largo plazo.

Al principio del post he puesto imagen que creo que muestra el concepto. Ojo, porque la imagen muestra una forma de llevarlo a cabo, dando un detalle menor conforme la fase que describimos se aleja en el tiempo (menos detalle conforme nos alejamos del momento actual). Mi aproximación en el ejemplo ha sido menos incremental: yo propongo detallar la fase actual, y dejar todas las demás fases con un detalle menor, pero igualado entre ellas.

Al final, todo dependerá del grado de detalle que necesitemos, y sobre todo, de la necesidad que tengamos de detalle a la hora de dar la estimación global.

martes, 5 de junio de 2012

El mito de la usabilidad

Me tiene harto. Me ha hecho perder un buen rato. Y no sólo a mí. He hecho la prueba con varios compañeros, y a todos les ha pasado lo mismo. De hecho, el problema quizás no sea de usabilidad, sino de diseño erróneo de página.

Pero voy a introducir el problema. Me tenéis aquí, tratando de evaluar un producto de HP, el famoso Quality Center, para poder probar sus características, y pasar con el debido conocimiento de causa a la compra/alquiler/loquesea del mismo. Estupendo.

Pues en esas me veo cuando tras rellenar multitud de campos de información personal, utilísima para HP (quiero pensar)....no consigo superar el primer escollo. Cada vez que hago clic en "Enviar" la información, me da un error en uno de los campos obligatorios.
- Ok. Ya veo que está rojo...ya veo que es obligatorio....¡Pero ya está relleno!
- Bien, pues entonces como es el idioma ("Spanish"), voy a elegir otro...
- Pues no. Me harto de probar idiomas. Y lo hago en mi máquina. Y en una máquina virtual. Y con Internet Explorer y con Firefox....y aquí es cuando harto de probar, desisto.

Adjunto captura de pantalla de la maravillosa interfaz que me ha tenido entretenido a mí y a algún que otro amable compañero, y que agradezco en el alma a su equipo de desarrollo el inolvidable rato que me ha hecho pasar. Gracias. Pero que muchas gracias.

Y digo yo...¿no se podría pedir toda esta información más adelante? No podría rellenarlo por ejemplo...mientras instalo el producto? ¿No podría ser un poco más....AGIL?

[Editado] Gracias a un amable lector, al final no he hilado mi problema con el titular, y es que la usabilidad es un mito que aquí me ha golpeado amargamente. Supuestamente, este formulario web se desarrolló usando los últimos estándares de usabilidad y tecnologías novedosas (obsérvense los colores de fondo y texto, los distintos tipos de colores adicionales que proporcionan errores o enlaces, Ajax para facilitar el contenido dinámico, etc, etc.).
El caso es que la usabilidad, no puede lograrse únicamente con tecnologías novedosas. La usabilidad lleva pareja el ser amable con el usuario, no hacerle sentir estúpido, asumir su entorno (navegador, PC, etc.) y no imponer el nuestro, entender el objetivo final del usuario (darme de alta), en lugar del nuestro (obtener los datos a toda costa, aunque ello suponga perder usuarios). Usable también debe estar probado...¡resulta irónico que para la descarga de un prestigioso producto de testing, me encuentre fallos absurdos que me impidan su descarga!
Por otro lado, el lector tiene razón. Aunque están relacionados, un mito como el de la usabilidad se merece un post sólo para él, y no simplemente una mención de rebote. Por cierto, para los interesados en la usabilidad, leed algo de Alan Cooper. No os defraudará.

Pd.: al final, conseguí encontrar una persona que ya tenía cuenta HP y que por tanto, pudo entrar directamente desde la pestaña "Registro" (aunque también le tocó rellenar datos, y más datos, etc. etc.). Ahora, si consigo hacerlo funcionar, me gustaría poder comentar alguna bondad de este producto desde el lado de la experiencia.

[Editado] También comentar, que al final, pude probar la aplicación, comprobar las funcionalidades de este gran producto, y darme una idea de sus prestaciones y su adecuación al tipo y tamaño del proyecto...pero eso mejor lo dejaremos para otro post (o varios, porque hay mucho en esta familia de productos, que puede ser de utilidad si sabemos integrarlo en nuestros proyectos).

lunes, 4 de junio de 2012

Comando Scrum



Me ha gustado. Un compañero me ha facilitado el link que voy a comentar, y donde vais a poder disfrutar con todo detalle del contenido, que me parece brillante. Aquí va un resumen:

El sargento

Esta figura la podemos asimilar al Scrum Manager, el responsable de mantener al equipo enfocado y motivado, de forma que los grupos de desarrollo actúen como unidades eficientes. Luchará encarnizadamente por eliminar cualquier impedimento u obstáculo a este fin.

Comunicaciones

El product owner, realiza esta función de mantener al equipo bien informado de los requisitos del producto, y asegura que la información fluya bidireccionalmente.

Infantería

En Scrum representado por el equipo de desarrollo. Sin estos tíos, no existiría el ejército, ni sería posible ninguna batalla. Representan la fuerza necesaria, que hay que cuidar y mantener, entrenar y no agotar nunca.

Médicos

Los especialistas en aseguramiento de calidad (QA), son responsables de saltar las alarmas cuando la salud del proyecto no es la adecuada. Verifican el cumplimiento de estándares, y dan soporte en su consecución.

Reconocimiento

En todo proyecto suele haber una parte del equipo que realiza un prototipo, o que investiga una tecnología para identificar si es plausible o no implantarla en el proyecto. Estos investigadores (equipo de reconocimiento), hacen las labores de preparar el camino al resto, y de identificar problemas. En todo proyecto hay "zonas minadas" que hay que evitar, y que esta avanzadilla de héroes nos ayuda a anticipar.

¡ El día de la victoria!

Este día, es el día del despliegue. El pase a producción habrá sido más o menos complicado, pero con las dosis adecuadas de esfuerzo, planificación, gestión y suerte, la victoria habrá llegado. Es el momento de celebración, liberar a los rehenes, y pasar a la reconstrucción del país...quiero decir...al mantenimiento del producto.

Novedades Microsoft 2012

Dentro de un año que ya prometía ser novedoso, acaban de salir recientemente para descarga varios productos de Microsoft:
El caso de Windows 8 RP, nos permitirá probar las novedades de la interfaz metro hasta enero de 2013 (salvo extensión de última hora).

A ver si tengo tiempo, y me pongo a repasar brevemente las novedades de Visual Studio 2012 y el nuevo .Net Framework.