 Es saltarse todo el
material que
representa lo real
(gráficos, cajas, flech
as, esquemas, etc.) y
en realidad crear el
objeto real.
 Es menos. Haz sólo lo
esencial

 Comienza con la interfaz, las pantallas
reales que la gente va a usar.
 Entrega sólo lo que los clientes necesitan
y elimina todo lo que no.
 Se trata de iteraciones y de reducir el
coste del cambio.

 Líneas de tiempo que toman meses e
incluso años
 Especificaciones funcionales que sean pura
fantasía
 Debates sobre escalabilidad
 Reuniones de grupo interminables
 La \"necesidad\" de contratar docenas de
empleados
 Itinerarios que predicen el futuro perfecto
 Pruebas de usuario irreales
 Papeleo innecesario

 Da mejores resultados
que estas tratando de resolver en lugar
de tus ideas acerca de ellos.
y
otra documentación transitoria en favor
de la construcción de pantallas reales

 Es una aproximación idealmente
adaptada al software basado en la
web.

 No tiene sentido realizar estimaciones a
años vista.
 Debemos estar dispuestos a incorporar
cambios en el proyecto en cualquier
momento del proceso.
 Es correcto construir menos
cosas, saltarse la documentación y los
detalles, y tomar atajos en el proceso
siempre que esto nos permita poner el
proyecto en funcionamiento más
rápidamente

 El diseño es un elemento relativamente
flexible. Un boceto en papel es barato y
fácil de modificar
 Los diseños en html se pueden cambiar
(o desechar)
 Diseñar primero te mantiene flexible con
relativa simplicidad

 Comenzar programando te cierra
opciones y conlleva futuros costes
adicionales. Es la parte que es mas cara
y difícil de cambiar.
 Empezamos con la interfaz para poder
ver desde el principio el aspecto y
funcionamiento de la aplicación
 El diseño es un elemento relativamente
flexible. Un boceto en papel es barato y
fácil de modificar

 Toma lo que piensas que debe ser el
proyecto y pártelo por la mitad.
 Sigue recortando objetivos para
quedarte con lo básico.
 Vuelve a partir el resultado por la mitad:
ya tienes lo esencial. Es el “corazón” del
proyecto.

 Considera tus decisiones
temporales, volverás de nuevo sobre
ellas.
 No te pares, decide y sigue adelante. No
te obsesiones con hacerlo todo perfecto
a la primera: es imposible.
 Deja que el proyecto crezca y te
hable, que tome forma y evolucione.

 Conforme avances en el proceso
iterativo, tus decisiones serán más
informadas y contarán con la
aportación de tus colaboradores.
 Diseña las pantallas, úsalas, analízalas y
entonces comienza otra vez

 Tormenta de Ideas
› ¿Qué es lo que tiene que hacer la aplicación?
¿Cómo sabemos cuando es útil? ¿Qué es
exactamente lo que vamos a hacer?
 Bocetos en papel
› Dibujos, garabatos, cuadros, líneas, círculos
 HTML
› Realiza una versión html de la característica.
 Codificar
› Cuando la maqueta se ve bien y demuestra
suficiente de la funcionalidad necesaria, seguir
adelante y conectar el código de programación.

 Trabaja desde grande a pequeño
 Nos fascinan los detalles.
› El espacio entre objetos
› La sangría perfecta para los textos
› El color perfecto
› Las palabras perfectas
› Cuatro líneas de código en vez de siete
› 90% versus 89%
› 760px versus 750px
› $39/mes versus $49/mes
 El éxito y la satisfacción están en los detalles

 Sin embargo, éxito no es lo único que
encontrarás en los detalles. También
encontrarás
.
 No te preocupes del tamaño de tus titulares
en la primera semana.
 No tienes que lograr el tono perfecto de
verde en la segunda semana.
 No tienes que mover ese botón \"enviar\" tres
pixeles a la derecha en la tercera.
 Sólo pon todo en la página por ahora.
Luego úsalo. Asegúrate de que funciona.
Más tarde podrás ajustarlo y perfeccionarlo.

 Decide los pequeños detalles para que
tu cliente no tenga que elegir. ¿Rojo o
negro? Si no es absolutamente vital para
el proyecto, toma tú la decisión.
 Todas las decisiones son temporales.
Volverás de nuevo sobre ellas. Así que
no te pares: decide y sigue adelante

 Desestabilizan nuestro flujo natural de
trabajo.
 Cada minuto que gastas en una junta
podrías estar terminando tu trabajo.
 Puedes discutirlo via e-mail .

 Para aquellos tiempos cuando usted
absolutamente debe tener una reunión
(esto debería ser un raro caso), siga
estas simples reglas :
› Establecer un cronometro a 30 minutos
› Invitar a tan pocas personas como sea
posible.
› Nunca tener una reunión sin una agenda
clara.

 La Ley de Metcalfe explica bien la
necesidad de contar con equipos
pequeños:
 Las probabilidades de que surjan
aumentan
de forma brutal cuando el número de
miembros se dispara.

 Para la primera versión de tu
aplicación, empieza sólo con tres
personas. Un desarrollador, un
diseñador, y un sweeper (alguien que
pueda alternar entre ambos mundos).
 Si no puedes construir tu versión inicial
con tres personas,entonces necesitas a
diferentes personas, o aligerar tu versión
inicial

 Testea con usuarios de verdad en
condiciones reales. No busques
sustitutos: no existen. Trabaja con datos
reales.
 No sirven las reflexiones en el limbo, ni las
pruebas en laboratorio.
 Consigue una retroalimentación
auténtica y haz las mejoras basándote
en la información que has obtenido. Se
lo debes a tus usuarios.