elclerigo!

Hace tiempo que existen los IA One Sheeters, pero nunca había hablado de ellos por aquí. Los IA One Sheeters son unas hojas en las que se trata de explicar en qué consisten y para qué sirven los entregables que se dan en una metodología de diseño centrado en el usuario de una manera clara y sencilla.

Estos IA One Sheeters han ido poco a poco creciendo y aumentando y ya tenemos para:

• Wireframes 60KB PDF
• Heuristic Evaluations 59KB PDF
• Usability Testing 61KB PDF
• Card Sorting 112KB PDF
• Content Inventory 104KB PDF
• Content Map 108KB PDF
• Design Standards Guide 112KB PDF
• Mental Model 112KB PDF
• Personas 120KB PDF
• Task Analysis Grid 112KB PDF
• Use Cases 116KB PDF
• User Flows 104KB PDF
• Vision Scope 124KB PDF

Creo que en momentos puntuales pueden llegar a resultar terriblemente útiles y que nos abran alguna puerta que de otra manera sería dificil abrir.

Si alguien se anima a traducirlos que lo comente.

Etiquetas: arquitectura, informacion, ux, ucd, iaonesheeters

• Argumentar hasta la saciedad y convencer al cliente
• Argumentar hasta la saciedad y consensuar un mix, entre los dictados del cliente y los que se desprenden de los análisis y trabajo profesional
• Asumir los dictados del cliente, directamente
• Abandonar el proyecto y dejar al cliente

• Argumentar hasta la saciedad y convencer al cliente: nunca o casi nunca lo he logrado
  
• Argumentar hasta la saciedad y consensuar un mix, entre los dictados del cliente y los que se desprenden de los análisis y trabajo profesional: a veces ocurría
  
• Asumir los dictados del cliente, directamente: la mayoría de las veces era lo que terminaba pasando
  
• Abandonar el proyecto y dejar al cliente: nunca, puesto que no podía por los acuerdos de la empresa
  

Etiquetas: consultoría, clientes, no, escuchan

...que como dicen en una viñeta de Dilbert : "siempre sugieres cambios inesperados para crear la ilusión de añadir valor"

Estoy en época de saturación extrema por trabajo, así que lo único que escribiré serán post como este....reivindicando la exterminación de la estupidez humana. Si el tiempo (libre) me lo permite, la idea es empezar el curso con muchas novedades a todos los niveles. De momento os dejo una novedad:

En Octubre tendremos la charla de Daniel Torres Burriel y Adrian Coutin!!! Pronto comunicaré la fecha y el horario.

Etiquetas: charla, daniel, torres, burriel, adrian, coutin, dilbert

¿Qué es Programación Extrema, eXtreme Programming o XP?

Wikipedia: es un enfoque de la ingeniería de software formulado por Kent Beck. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

programacionextrema.org: La Programación Extrema es uno de los llamados procesos o metodologías ágiles (ProcesoAgil) de desarrollo de software. Consiste en un conjunto de prácticas (ver LasPracticas) que a lo largo de los años han demostrado ser las mejores prácticas de desarrollo de software, llevadas al extremo, fundamentadas en un conjunto de valores (LosValores).

Deigote's Blog: La programación extrema es una metodología de ingeniería de software para el desarrollo del mismo, que hace énfasis en los siguientes aspectos: satisfacción del cliente y trabajo en equipo.

¿Cómo funciona?

La programación extrema está compuesta por una serie de prácticas y actividades.

Las prácticas que componen la programación extrema se pueden agrupar en cuatro grandes bloques: plan, diseño, codificación y pruebas. Sin embargo, estos bloques no deben realizarse en orden, si no que cada uno consta de una serie de actividades, y todas ellas se irán realizando de manera evolutiva.

Las actividades son las siguientes:


• Planificacion
  
  
  • Se escriben user stories, cuya idea principal es describir un caso de uso en dos o tres líneas con terminología del cliente (de hecho, se supone que deben ser escritos por el mismo), de tal manera que se creen test de aceptación para el user storie y permita hacer una estimación de tiempo de desarrollo del mismo.
  • Se crea un plan de lanzamiento (release planning), que debe servir para crear un calendario que todos puedan cumplir y en cuyo desarrollo hayn participado todas las personas involucradas en el proyecto. Se usará como base los user stories, participando el cliente en la elección de los que se desarrollarán, y según las estimaciones de tiempo de los mismos se crearán las iteraciones del proyecto.
  • Se hacen pequeños lanzamientos con mucha frecuencia.
  • El desarrollo se divide en iteraciones, cada una de las cuales comienza con un plan de iteración para el que se eligen las user stories a desarrollar y las tareas de desarrollo.
  • Las personas cambian de área para evitar cuellos de botella y fomentar la propiedad colectiva del código.
  • Se cambia el proceso lo que sea necesario para adaptarlo a tu proyecto.


• Diseño
  
  
  • Se eligen los diseños más simples que funcionen.
  • Se elige una metáfora del sistema para que el nombrado de clases, etcétera, siga una misma línea, facilitando la reutilización y la comprensión del código.
  • Se escriben tarjetas CRC (class-responsabilities-collaboration) de clase-responsabilidades-colaboración para cada objeto, que permiten abstraerse el pensamiento estructurado y que el equipo de desarrollo al completo participe en el diseño.
  • Se "refactoriza sin piedad". Basicamente, consiste en no tener miedo de cambiar un diseño o eliminar un código que ya no sirve, o al menos que ya no es claramente la mejor solución.


• Codificación
  
  
  • El cliente está siempre disponible, a ser posible cara a cara. La idea es que forme parte del equipo de desarrollo, y esté presente en todas las fases de XP (escribe los user stories con la ayuda de los desarrolladores, participa en la elección de los que entrarán en el plan de lanzamientos, prueba pequeños lanzamientos, participa en las pruebas de funcionalidad...). La idea es usar el tiempo del cliente para estas tareas en vez de para que cree una detalladísima especificación de requisitos, y evitar la entrega de un producto peor que le hará perder tiempo.
  • El código se ajustará a unos estándares de codificación, asegurando la consistencia y facilitando la comprensión y refactorización del código.
  • Las pruebas unitarias se codifican antes que el código en sí, haciendo que la codificación de este último sea más rápida, y que cuando se afronte la misma se tenga más claro qué objetivos tiene que cumplir lo que se va a codificar.
  • La programación del código se realizará en parejas, para aumentar la calidad del mismo. En cada momento, sólo habrá una pareja de programadores integrando código.
  • Se integra código y se lanza dicha integración de manera frecuente, evitando divergencias en el desarrollo y permitiendo que todo el mundo trabaje con la última versión del desarrollo. De esta manera, se evitará pasar grandes periodos de tiempo integrando el código al final del desarrollo, ya que las incompatibilidades habrán sido detectadas enseguida.
  • Se usa la propiedad colectiva del código, lo que se traduce en que cualquier programador puede cambiar cualquier parte del código. El objetivo es fomentar la contribución de ideas por parte de todo el equipo de desarrollo
  • Se deja la optimización para el final
  • No se hacen horas extra de trabajo


• Pruebas
  
  
  • Todo el código debe tener pruebas unitarias, y debe pasarlas antes de ser lanzado.
  • Cuando se encuentra un error de codificación o bug, se desarrollan pruebas para evitar volver a caer en el mismo.
  • Se realizan pruebas de aceptación frecuentemente, publicando los resultados de las mismas. Estas pruebas son generadas a partir de las user stories elegidas para la iteración, y son "pruebas de caja negra", en las que el cliente verifica el correcto funcionamiento de lo que se está probando. Cuando se pasa la prueba de aceptación, se considera que el correspondiente user storie se ha completado.

Ventajas e inconvenientes

• Ventaja: Cuatro ojos ven más que dos. Al trabajar de dos en dos, el código será de mayor calidad desde el mismo momento de crearlo y tendrá menos fallos.
• Inconveniente: Para un programador experto puede resultar tedioso tener a un novato a su lado permanentemente.
  
• Ventaja: Los programadores novatos aprenderán de los expertos al emparejarse con ellos.
• Inconveniente: El programador experto no aprende y su trabajo se ve ralentizado.
  
• Ventaja: Si una pareja realiza un trozo de código susceptible de ser reutilizado en el proyecto, hay dos programadores que lo saben y que lo reutilizarán cuando puedan (ya que saben cómo funciona), enseñándolo a sus nuevos compañeros. De esta manera el conocimiento del código ya hecho se propaga de forma natural entre todos los programadores del equipo.
• Ventaja: El estilo de programación tiende a unificarse.
• Inconveniente: La mejora o cambios en el estilo de programación puede resultar más complejo

¿Cuándo usar XP?

La programación extrema fue creada pensando en las siguientes circunstancias:


• Proyectos en los que los requisitos tienen altas probabilidades de cambiar con el tiempo (por ejemplo, porque el cliente no tiene claro lo que quiere, o porque el cambio de requisitos está ligado al dominio del problema a resolver).
• Proyectos con alto riesgo (por ejemplo, proyectos con una fecha de entrega que es indispensable cumplir, o proyectos totalmente novedosos para la industria).
• Proyectos con un grupo pequeño de programadores (entre 2 y 12), aunque el equipo completo sea bastante más extenso (incluye a jefes de equipo y representantes de clientes).

La información para el artículo ha sido recopilada de:

Wikipedia: http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema
ProgramacionExtrema: http://www.programacionextrema.org
Deigote's Blog: http://deigote.blogspot.com/2006/03/extreme-programming.html
chuidiang: http://www.chuidiang.com/ood/metodologia/extrema.php

Etiquetas: metodologias, agiles, extreme, programming, programacion, extrema, desarrollo

¿qué es Scrum?

Wikipedia: es una metodología para el desarrollo ágil de productos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New New Product Development Game[Harvard Business Review Ene-Feb 1986]

Ingenierosoftware.com: es una forma de gestionar proyectos de software. No es una metodología de análisis, ni de diseño, como podría ser RUP, es una metodología de gestión del trabajo.

Controlchaos.com: Scrum is an Agile process that can be used to manage and control complex software and product development using iterative, incremental practices (Traducción del autor: es un proceso ágil que puede ser usado para gestionar y controlar el desarrollo de productos y software complejos usando prácticas iterativas y actualizables. )

¿Cómo funciona?

Elementos básicos de SCRUM.

• Product Backlog: Es una lista con las funcionalidades de la aplicación ordenadas de mayor a menor importancia. No hace falta que esta lista contenga todas las funcionalidades inicialmente.
  
  
• Sprint Backlog: De la lista anterior, se toman las primeras funcionalidades, se descomponen en tareas y son anotadas en esta lista. Estas tareas serán realizadas en el siguiente mes.
  

Además de estos elementos tenemos unas cuantas reglas básicas y sencillas que tenemos que cumplir.

• Una vez que se pasan las tareas más prioritarias del "Product Backlog" al "Sprint Backlog", estas no se pueden cambiar, esto quiere decir, que el trabajo de un mes queda fijado. Esta es la regla más importante de todas.
  
  
• Al final del mes, este periodo se le llama "Sprint", se tiene que tener un ejecutable con las funcionalidades del "Sprint Backlog".
  
  
• Todo el mundo puede añadir funcionalidades al "Product Backlog", pero sólo una persona puede ordenarlo. A esta persona se le denomina "Product Owner". Es el responsable del producto final.
  
  
• Cada día se hace una reunión de menos de 15 minutos, en la que se reúne todo el equipo: ingenieros y gestor (llamado "Scrum Master") en la que cada miembro del equipo expone sólo los siguientes temas:
  • ¿Qué es lo que se hizo el día anterior?
  • ¿Qué es lo que se va a hacer hoy?
  • ¿Qué impedimentos tengo para realizar mi trabajo?
  Sólo se tratan estos temas para que la reunión sea rápida y no malgastemos el tiempo de los demás. Si se tiene que tratar otro tema se hace otra reunión sólo con las personas implicadas.
  
  
• Al final del mes, es decir, al final del Sprint, se presenta el producto y se toma del "Product Backlog" ordenado las funcionalidades para cubrir en el siguiente mes.

El proceso está explicado en la siguiente imagen:

Ventajas e inconvenientes

Una de las principales ventajas de la metodología Scrum es la capacidad para aceptar modificaciones sobre la marcha sin influir en el desarrollo, además de la priorización de tareas gracias a la Product Backlog. Y uno de los mayores inconvenientes es que un mal uso de la metodología puede dar lugar a un desarrollo sin final en el que continuas modificaciones vayan llenando cada mes el Product Backlog.

La información para el artículo ha sido recopilada de:

Wikipedia: http://es.wikipedia.org/wiki/Scrum
IngenieroSoftware: http://www.ingenierosoftware.com/equipos/scrum.php
ControlChaos: http://www.controlchaos.com/

Etiquetas: scrum, metodologias, agiles, software, desarrollo

Ya hablamos en su día de la discusión generada a raiz de un post de Alberto Knapp sobre el desarrollo centrado en la metodología o en el producto, con las posteriores réplicas de Daniel Torres Burriel y Luis Villa. Pues bien, hoy Daniel ha vuelto a la carga, y sigue manteniendo los prototipos como la manera de hacer desarrollos teniendo siempre en mente al usuario final.

En este post quiero plasmar mi opinión sobre metodologías, producto y usuarios.

Las metodologías son necesarias en cualquier desarrollo.

Aunque sí es cierto que estas pueden ser más abiertas o más cerradas, más centradas en el proceso que en el resultado final o viceversa, da igual. Al final son pasos que se siguen desde el inicio de un proyecto hasta la entrega.

Para algunas personas una buena metodología es aquella que les aporta más beneficios económicos en el desarrollo, sin importarles qué entregan. Quizás un buen ejemplo de esta metodología, sin llegar a conocer el tema profundamente, sería la web del congreso. Está claro que esta web no se ha enfocado en el usuario (el ciudadano) , y que el desarrollo no es precisamente lo mejor pero probablemente habrá generado muchos beneficios a la empresa desarrolladora.

Otras personas/empresas pueden estar centradas exclusivamente en el producto final sin tener una metodología de trabajo. Quizás sea una afirmación muy extremista y exagerada, pero si sólo pensamos en el futuro (producto) olvidándonos del presente puede que nos perdamos por el camino.

El producto y el usuario es lo que realmente importa

Daniel en su post habla de la creación de prototipos para tener siempre a los usuarios en mente. Prototipos "colaborativos" remarcaría yo. Prototipos en los que varias personas de distintas disciplinas aporten sus conocimientos (arquitectos de la información, programadores, diseñadores gráficos). Los prototipos nos hacen plantearnos desde la interacción de los usuarios con la aplicación hasta la línea de negocio del cliente. Surgen muchas preguntas en las que los miembros del equipo de desarrollo tienen mucho que decir, y también el cliente.

En mi humilde experiencia he comprobado los buenos resultados que aportan los prototipos en el producto final. Los prototipos te fuerzan a pensar en el usuario, ¿qué quiere ver?, ¿qué hará?, ¿entenderá este texto?, ¿necesitará ejemplos?, ¿explicaciones? y las respuestas que el equipo y el cliente aportan a esas preguntas son las que terminan dando forma al producto final. Un producto que tanto el equipo como el cliente sienten que es suyo en parte, porque todos han colaborado.

Cómo funcionamos nosotros

En desarrollos de sitios web seguimos una metodología muy flexible que hemos ido creando casi sin darnos cuenta, y que empieza por la creación simultánea de un prototipo y una línea gráfica que se presentan conjuntamente al cliente. Después de la aprobación se unen creando los "pantallazos" que se maquetan, se programan y se entregan. Por supuesto que esto no es así de sencilla, porque siempre hay alguna "demo" para que el cliente vea como va el desarrollo, algún rediseño, etc...pero esa es la esencia de la metodología.

Pregunta

No he hablado nada de análisis de requisitos porque nuestra metodología está enfocada principalmente a portales corporativos, no a aplicaciones. Si añadiésemos a esa metodología el análisis de requisitos y funcional ¿creéis que vale la misma metodología para una aplicación web de 18 meses de desarrollo que para un portal coorporativo?

Etiquetas: metodología, producto, usuario, análisis

Estamos inmersos en pleno debate sobre el desarrollo de producto o los desarrollos en los que prima el proceso sobre el producto.

Mi experiencia dice que tener una buena metodología de trabajo que el equipo de desarrollo (desde el jefe de proyecto hasta el programador junior) tengan asumida y memorizada es primordial. Luego ya nos plantearemos si la seguimos al pie de la letra siempre o si podemos estirarla y amoldarla según qué proyectos y qué clientes para poder ofrecer un enfoque de producto.

Digo esto porque:

1. He trabajado en una empresa grande con buena metodología y los proyectos siempre salían bien
2. He trabajado en una empresa pequeña sin metodología y, salvo las creatividades (logotipos, imagen corporativa, cartelería, etc...), nunca salía nada.

Y mi opinión:

1. Un equipo de profesionales que se conocen y que han trabajado juntos, no necesitan centrarse tanto en el proceso, ya lo tienen asumido. Puede pensar más en el producto.
   
2. Un equipo que no se conocen o no han trabajado juntos necesita de una metodología y, sin olvidar el producto, pensar mucho en el proceso, mejorarlo, pulirlo y finalmente asumirlo

Lo resumo mucho para no aburrir a la audiencia. ; )

Estamos acostumbrados a que los desarrollos sean para empresas ya constituidas, sólidas y con las cosas claras. Pero ¿cómo enfrentarnos a una empresa recien nacida y con gran proyección?

Desde el mismísimo primer boceto a lapiz y papel tenemos que tener claro que los objetivos que persigue una compañía que va a crecer no van a ser los mismos en el parto que cuando se gradúe en la universidad. Al principio ni tendremos contenidos, ni prestigio de marca, ni una idea clara del negocio (por muchos planes de negocio que se hayan hecho).

Ser capaz de ver el crecimiento y necesidades de un embrión (llamarlo espermatozoide me parecía un poco feo) a largo plazo es complicado, por eso es muy probable que dentro de unos años los prototipos que ahora estamos haciendo nos sirvan como mucho para ocupar espacio en el disco duro, pero hay que mojarse, arriesgarse y hay que tomar decisiones. Hay que ser valientes. Pero sobre todo hay que exprimirle la cabeza al máximo al padre de la criatura, preguntarle cosas que ni siquiera él se haya planteado. El proceso puede alargarse pero ¡¡queremos hacer un buen trabajo!!

Es muy probable que si con las dos o tres primeras fases de desarrollo acertamos tengamos un cliente para muchísimo tiempo. Lo importante es explicarle al cliente las fases y que las entienda.

Ya iré contando con el tiempo si esta teoría funciona o no, y si hemos acertado con las fases de desarrollo (rediseños o como quiera llamarlos cada cual) de la web.

Etiquetas: prototipado, desarrollo, diseño