significado - scrum for dummies pdf español

¿Cómo se aplica Scrum a la parte de diseño del desarrollo web? (7)

Si tuviéramos que utilizar los métodos de Scrum, ¿cómo se llevaría a cabo este desarrollo?

Si bien esta publicación es bastante antigua, me impulsó a investigar por mi cuenta. Encontré las "Doce prácticas emergentes" de Jeff Patton para los diseñadores / profesionales de UX, que pensé que eran específicamente aptas para esta pregunta, y un conjunto de marcos bastante útil:

Drive: los profesionales de UX son parte del equipo del cliente o del propietario del producto.
Investigue, modele y diseñe por adelantado, pero solo lo suficiente.
Chunk su trabajo de diseño
Utilice el desarrollo de pistas paralelas para trabajar por delante y siga hacia atrás.
Compra tiempo de diseño con complejas historias de ingeniería.
Cultive un grupo de validación de usuarios para usar para la validación continua de usuarios.
Programe la investigación continua del usuario en una pista separada del desarrollo.
Aproveche el tiempo del usuario para múltiples actividades.
Utilice RITE para iterar la interfaz de usuario antes del desarrollo.
Prototipo en baja fidelidad.
Tratar el prototipo como especificación.
Conviértete en un facilitador de diseño.

Si desea profundizar, jeff lo explica agileproductdesign.com.

Estoy empezando a aprender sobre Scrum y me interesa probarlo con nuestro equipo de desarrollo. Tengo muchas preguntas al respecto ... pero mi mayor obstáculo mental está en el diseño gráfico real.

Con nuestro ciclo de desarrollo actual [waterfall-esque], nuestro diseñador gráfico despliega la página con todas las imágenes y demás basadas en un PRD suelto. Si tuviéramos que utilizar los métodos de Scrum, ¿cómo se llevaría a cabo este desarrollo? Creo que estamos acostumbrados a ver el panorama general y conducir hacia él ... en lugar de encajar las piezas visuales a medida que avanzamos, que es lo que esperaría de la política de Scrum para el diseño gráfico.

¿Sería inaudito al menos cablear todas las funciones en el backlog? ¿O sería más sabio, para el primer sprint, diseñar su funcionalidad de tal manera que podamos agregar las nuevas características de otros sprints a medida que avanzamos? (es decir, cuando sea el momento de una nueva función, comente "¿Dónde encajaría esto en el diseño actual?")

Es fácil peasy! :) Bueno, déjame compartir cómo lo hacemos.

Primer sprint

1) El propietario del producto crea alambrados y los agrega a la cartera de pedidos (usamos Yodiz, www.yodiz.com) 2) Nuestro diseñador gráfico crea mockups y los pone en la herramienta de intercambio de maquetas (www.concept.ly) 3) Nuestros desarrolladores trabajan en configurando servidores. Si todo está listo, tenemos un propietario de producto bastante inteligente, siempre tendrá elementos en el registro pendiente para seleccionar.

Sprint dos

1) El desarrollador comienza a trabajar en las maquetas finalizadas, que se finalizaron conceptualmente. 2) El trabajo del diseñador en otro marco de alambre agregado por el propietario del producto en el trabajo pendiente.

¡Te dije que es fácil!

Estoy totalmente en desacuerdo con la respuesta proporcionada por Jason. El objetivo de Scrum es deshacerse del método en el que los diseñadores primero "hacen lo suyo" y luego pasan a otras cosas. ¡Eso es completamente y 100% contra todos los principios de Lean / Scrum!

¿La forma de incorporar diseñadores en un proceso Scrum? ¡Tíralos a la mezcla! ¡Asegúrese de que no solo está envolviendo un proyecto de cascada en Scrum, ya que es la mejor manera de fallar! Scrum solo funciona cuando se implementa sin excepciones. "Scrum, pero ..." es el peor modelo de proyecto. Organice el trabajo de modo que sea posible para el diseño y desarrollo concurrente. No exagere con el diseño inicial, sino conviértalo en una situación push-pull, en la que ambos lados de la moneda influyan en el otro. El objetivo de Scrum es iterar, iterar y iterar, así que aproveche al máximo.

Además, es bastante sencillo rechazar el diseño tradicional basado en Photoshop. Puede leer más sobre esto en esta excelente publicación de blog en Signal vs. Noise: http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop

He hecho esto antes, donde los diseñadores hicieron lo suyo en las primeras iteraciones, y su producto de trabajo fue utilizado por el equipo de desarrollo en iteraciones posteriores. Cuando el equipo de desarrollo comenzó a trabajar, los diseñadores avanzaron a otras partes del proyecto, o posiblemente a otros proyectos.

Creo que estamos acostumbrados a ver el panorama general y conducir hacia él.

Todavía puedes hacer esto. Sus diseñadores pueden hacer un diseño frontal más grande, y el equipo de desarrollo puede usar Scrum para iterar hacia eso.

Me gustaría compartir. Soy el scrum master para un equipo de desarrollo de una futura aplicación social. Este equipo tiene 1 diseñador de Interfaz de usuario, 1 diseñador de Experiencia de usuario (yo), 1 desarrollador de front-end (css, ajax, etc.) y 3 programadores.

Este es nuestro primer proyecto con un marco SCRUM, por lo que ha sido un gran desafío. La tendencia durante nuestras reuniones diarias de scrum es que nuestro trabajo de diseño nunca se realiza del todo porque nuestra cartera de productos inicial tenía historias como "El usuario quiere ser persuadido para que se registre" y luego agregamos a esa historia una "forma de demostración". allí podríamos determinar qué se debe hacer (es decir, debemos hacer una estructura alámbrica, hacer una redacción, etc.)

Eso, se podría hacer mejor. Detalla cada tarea en base a esa historia y calcula el tiempo para cada tarea. Por ejemplo, durante la acumulación de productos, a partir de ahí podríamos crearlos en orden: Mapas del sitio> Flujos de tareas> Wireframes

Ahora la pregunta es, ¿hacemos todo esto en un sprint? ¿O deberíamos hacer esto incluso antes de cualquier sprint? Derrota el propósito del scrum si lo hacemos fuera de los sprints, ¿no?

Quienes hayan realizado el diseño de la experiencia del usuario sabrán que estas tareas requieren bastante tiempo para prepararse. Entonces, ¿por qué no hacer que todos estos sean parte de un sprint también? Haga que los programadores participen también en estas tareas.

El cableado es muy importante a lo largo de la duración del proyecto. Es como el plano de un edificio, donde se usa de principio a fin.

Por lo tanto, realice un cableado inicial basado en la acumulación de productos durante su primer sprint. Y ajusta el armazón de alambre en consecuencia durante cada otro sprint. Nuestros programadores diseñarán su código en función del flujo de tareas y luego lo crearán visualmente en función de la estructura alámbrica.

Oh, por cierto, no te preocupes demasiado por cómo se verá el producto (aunque tener una maqueta de diseño inicial siempre es algo bueno). En su lugar, concéntrese en las necesidades y deseos de los usuarios y diseñe un flujo muy centrado en el usuario para lograr precisamente eso. Más tarde, nuestro diseñador descubre qué tipo de interfaz va a diseñar. Si el cableado se realizó correctamente, el diseñador tendrá muy pocos problemas al diseñar la interfaz de usuario. Lo mismo ocurre con la creación de redacción.

En resumen, trabajar de la mano durante cada iteración. Para los principiantes (como yo), dale a SCRUM la oportunidad de trabajar para ti. Si puede funcionar para compañías como fantasyinteractive.com , también puede funcionar para ti n me :)

ps para grandes wireframes, use omnigraffle (mac) tis the shite!

Para la parte de diseño en sprint 0 puede usar una técnica como Styletyles ( http://styletil.es ) para determinar el estilo gráfico necesario para el proyecto. Así que no necesitas un gran diseño por adelantado y aún así ser ágil cuando estás corriendo.

así es como te sugiero que lo hagas (es decir, cómo hemos intentado hacerlo)

Pre-sprint 0: asegúrate de tener una buena visión de lo que quieres hacer. No tiene que ser muy detallado, pero no debe ser "queremos crear un sitio web que sea social"

Sprint 0 : Desarrollador de herramientas: configure los servidores de CI, trabaje en los scripts de implementación, etc., de modo que todo el marco básico esté listo. Al final de esto, debería poder presionar un botón (en el peor de los casos: ejecutar un solo comando en un servidor REMOTO) que toma el código de su sistema de control de origen, lo crea, lo empaqueta, ejecuta todas las pruebas que desea en informa que, de vuelta, y si es posible, lo instala en un servidor de prueba (o al menos da como resultado un paquete que puede instalar en el servidor de prueba).

En este momento, el diseñador está haciendo los wireframes. Su objetivo es hacer wireframes básicos para la mayor cantidad de sitio que crea que necesita (piense en sitemap y no en campos y píxeles). Luego, cuando eso haya terminado, resuelva con el PM lo que es más importante, y explique detalladamente eso: alámbrico. No píxeles AÚN.

Los gerentes de proyecto y similares están trabajando con el diseñador y la empresa / parte interesada, escribiendo historias y tareas para que usted pueda hacer y rastrearlas. Obviamente, necesitan tener una idea del mapa del sitio, etc. para hacer esto.

Esto puede tomar más de un sprint. comience con uno (recomiendo sprints de 2 a 3 semanas: 1 es demasiado corto, 4 es demasiado largo), vea cuánto necesita hacer, etc.

Así que al final del sprint 0, tienes:

Muchas historias, en orden de prioridad (PUEDE agregar más más tarde, de hecho, siempre que los requisitos cambien)
Un mapa del sitio (es decir, una idea general de lo que todo va a contener)
Wireframes para el primer bloque de trabajo.
Todas tus herramientas están funcionando y configuradas.
Su CI, sistemas de seguimiento de errores, control de fuente y despliegue están en su lugar

Entonces comienzas el sprint 1

Tenga en cuenta que durante los primeros 3-4 sprints, no sabrá cuánto trabajo puede hacer en el sprint, ¡por lo tanto, ESPERE que lo haga mal! Saque tanto trabajo (en el orden de prioridad en el que la empresa / PM los ha puesto) como crea que pueda HACER SEGURO. ¡Siempre puedes tomar más tarde!

Usted desarrolla esas páginas y el diseñador (s) cablea el siguiente bloque de páginas (según lo determinen los PM). Tal vez el diseñador haga el arte de esas páginas, así que puedes hacerlo en el próximo sprint

Entonces, estás desarrollando lo que tienes y los diseñadores están trabajando en cosas para tu próxima carrera.

Por supuesto, también podrían tener un proceso de scrum, ¡solo comenzaron un sprint más temprano!

ahora repite hasta que te quedes sin trabajo

durante un sprint, si (por ejemplo) un requerimiento cambia o se agrega algo nuevo, entonces se escribe una nueva historia para eso, y está programada para el trabajo. Si es una prioridad súper alta, puede ir en la parte superior y ser el elemento principal para el próximo sprint (que será de 1 a 2 semanas, generalmente). O puede ser bueno tenerlo, por lo que va al final, el negocio decide.

Los PM / diseñadores deben saber que pueden cambiar las cosas, pero los cambios TIENEN consecuencias, por lo que no es de su interés (financiero) cortar y cambiar hacia atrás y hacia adelante. pero los requisitos cambian, y XP y Scrum tratan esto mejor que la cascada.

No te olvides

puede detener un sprint en cualquier momento y volver a la planificación, por ejemplo, si los requisitos cambian demasiado o se queda sin trabajo
puede programar más trabajo del que tiene tiempo, siempre y cuando no se haya comprometido (es decir, es un trabajo "extra" o "extendido")

Su PM debe poder predecir cuándo finalizará el proyecto: observe cuánto trabajo realizó en el último sprint (su velocidad), y divida la cantidad de trabajo que queda por ese número, y obtendrá la cantidad de sprints que debe realizar. Fácil.

Ah, y lea sobre los puntos de la historia - no estime las historias en horas o días. Usa puntos. Para arrancar eso, simplemente haga la primera historia que estima (digamos) un 8 (la secuencia es 1,2,3,5,8,13,21,40,60,100, infinita). Luego tome la segunda historia y estime la relativa a la primera: ¿es el doble del trabajo (13)? La mitad del trabajo (5)? sobre el mismo (8)?

Al final del sprint, suma los puntos que hiciste, y esa es tu velocidad. La cantidad máxima de trabajo que COMPROMETAS a hacer en el próximo sprint es esa cantidad. Siempre se puede detener el sprint antes de tiempo, o simplemente sacar más trabajo del trabajo acumulado, etc., si se acaba antes. A medida que avanzas, tu velocidad se estabilizará.

Maldita sea, estoy seguro de que hay libros, etc. sobre cómo ejecutarlo, así que me detendré :)