Archivo de la categoría: Programación

Cosas que se van descubriendo sobre la programación

Sentándose un día con un desarrollador

En Lean cuando hablamos de Gemba, significa que los que están a cargo de un equipo o una empresa se paseen o estén donde realmente ocurre la acción. En las plantas de producción tradicionales estos lugares son los pasillos donde se elabora el producto. En desarrollo de software el Gemba sólo se puede realizar sentándose con el propio desarrollador.

Sin embargo, lo normal es que cuando un líder, jefe o responsable se acerca para ver cómo está trabajando el desarrollador, éste se ponga en modo inspección y empiece a explicar qué está haciendo y cómo lo lleva. Lo que ocurre en ese momento es el Principio de Incertidumbre, lo que se quiere estudiar cambia su comportamiento solamente por observarlo. También es normal que el líder, después de esta más o menos breve explicación se levante y vuelva a su puesto dejando que el desarrollador continúe para no interrumpirle más.

¿Es esto suficiente? ¿Se pueden saber así los problemas reales con los que se enfrenta y ayudarle a realizar mejor su trabajo? Mi respuesta es que no. Para hacer un autentico Gemba hace falta que el desarrollador trabaje como si no estuvieramos ahí. Para ello tenemos que ponernos en pair programming y sentarnos al menos un día completo con él para que “se olvide de las cámaras”.  Trabajando juntos de este modo empezaremos a conocer sus problemas con el  framework, la arquitectura, lo que le cuesta un cambio de requerimientos, de datos de entrada, etc … . También en esas condiciones son en las  que podemos hacer coaching y enseñarle cómo organizar mejor el código, mejorar en TDD para desarrollar con mejor calidad y ayudarle a ser más productivo y ágil.

¿Cuánto tiempo hace que no te sientas un día completo con un desarrollador?

Cómo el stress afecta a la calidad del software

El uso de las metodologías ágiles en el desarrollo de software ha supuesto un antes y un después en relación a la calidad de los productos. Webs, aplicaciones, juegos, son cada vez más elaborados, imaginativos y más seguros.

Uno de los principios ágiles habla de ritmo sostenible (sustainable pace). La interpretación más aceptada es la de jornadas de trabajo de 40 horas semanales. Está más que demostrado empíricamente que las horas extras en desarrollo de software está linealmente relacionado con un incremento en los bugs cometidos.

Bien, pues aquí tenemos la razón.  La culpa la tiene el stress.

El stress envía hormonas a la sangre para preparar al cuerpo y la mente para la situación amenazante. Durante miles de años, para los humanos, las situaciones amenazantes tenían que ver con peligros físicos de animales depredadores, posibles accidentes o peleas entre tribus y estas sustancias preparaban al cuerpo para afrontarlas. Sin embargo en la época de la información y para trabajadores del conocimiento tienen precisamente el efecto contrario.

Estas dos simpáticas hormonas son la famosa adrenalina, que produce un incremento en el ritmo cardíaco, la presión de sangre y la respiración; y glucocorticoides como el cortisol. Bueno, pues estos últimos producen entre otros, unos efectos muy perjudiciales a la memoria de corto plazo y la memoria de trabajo.

La memoria de trabajo es la parte del cerebro en la que almacena los datos que tenemos que combinar, comparar y analizar para resolver los problemas. Nuestra memoria RAM. Tipicamente un cerebro  normal mantiene y trabaja con 7+-2 chunks o bloques de datos simultáneamente para resolver los problemas. Los glucocorticoides reducen este número por lo que la mente se ve limitada a trabajar con menos datos y menos alternativas para intentar resolver ese diseño o ese código que hay que hacer que funcione.

Los militares han hecho muchos estudios relacionados con la reacción de las personas en situaciones de stress (ver referencias). En un estudio se demostró que el stress tenía el efecto positivo de reducir el tiempo de reacción, sin embargo esto tenía el efecto colateral de crear un mayor número de falsas alarmas y errores que las surgidas en condiciones de tranquilidad. Es decir, estresados fallamos más que una escopeta de feria. Mantenemos nuestra atención en la parte negativa del problema para intentar resolverla lo cual nos impide mirarlo desde fuera, afrontarlo lateralmente para poder ver otros ángulos y encontrar mejores soluciones.

En otro estudio se demostró que las personas, en situaciones de stress experimentamos una percepción superficial de la realidad, poniendo nuestra atención sólo a una pequeña parcela del problema a la hora de tomar una decisión o encontrar una solución. En este estado de alta tensión tomamos decisiones basadas en un conjunto incompleto de información y tomamos atajos basados en experiencias pasadas.

En resumen, tenemos que un desarrollador o u trabajador en general cuando está estresado reduce  su memoria de trabajo, no es capaz de tener visión lateral y creativa y toma atajos para resolver el problema lo más rápidamente posible sin pensar en más allá que el alcance de su problema… Conseguimos al DESARROLLADOR BOMBA. Preparaos para bugs por doquier, deuda técnica acumulandose, software de baja calidad y clientes decepcionados.

Todo esto se puede evitar manteniendo el ritmo de trabajo a un ritmo mantenible. Respetando la capacidad del departamento de desarrollo mediante sistema PULL con Kanban o de compromiso de equipo en el  sprint de Scrum. Respetando la definición de DONE sin saltarse por la presión y manteniendo un ambiente de trabajo animado y relajado. Todo esto no debe ser un lujo, sino un requerimiento.

 

 

 

 

 

 

 

 

 

 

Referencias

 

http://en.wikipedia.org/wiki/Effects_of_stress_on_memory

http://en.wikipedia.org/wiki/Short-term_memory

http://en.wikipedia.org/wiki/Working_memory

http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

http://the-programmers-stone.com/wp-content/uploads/2007/10/StressAndPerformance.pdf

http://www.researchgate.net/publication/259781769_Impact_of_Overtime_and_Stress_on_Software_Quality

¿Está TDD muerto? Resumen del videodebate

Mientras hacen subtitulos para el Hangout entre David Heinemeier Hansson, Kent Beck y Martin Fowler, voy a escribir un poco lo que han hablado para que los que no entiendan el inglés, o no tienen los 30 minutos para verlo entero, puedan quedarse con las claves. En mi anterior artículo hablo de los artículos y tweets que empezaron la discusión.

El link al video es éste.

Empieza David hablando de los 3 problemas que ve al TDD: la insistencia en que los tests tienen que correr en milisegundos, que termina creando un diseño feo y complejo y que el bucle de rojo-verde-refactor es poco natural para el programador.

Kent cuenta que el TDD le da la confianza que necesita a la hora de dar un desarrollo por completado y funcionando. Sin TDD, uno se va a casa sin la seguridad de que el código que ha escrito funcione bien. Además le ayuda a pensar primero en el problema. Cuando no se tienen especificaciones concretas TDD sirve para empezar de lo más concreto (ejemplos en los tests) a la implementación más genérica.

David entiende en que Kent piense en la seguridad como un factor de felicidad del programador. Él mismo dice que le da prioridad a la felicidad del programador cuando empezó Ruby on Rails. Sin embargo, la seguridad de que todo va a funcionar es sólo un factor de felicidad del programador pero hay otros. El tener que cambiar el flujo de pensamiento a pensar primero el test antes de empezar lo ve como una forma de confundir al programador y no dejarle crear del modo que le es más natural. Además dice que la seguridad de que el código funciona no debería venir unicamente del TDD

Ante un ejemplo reciente de Kent sobre un uso idoneo del TDD, David responde que en los desarrollos que él hace no es normal tener un código tan aislado como el que Kent comenta. Que para poder conseguir un codigo perfecto testeable típico de un input consigue un output tiene que separar capas y capas y crear muchos mocks. Que tiene que hacer un gran sacrificio para conseguir ese código perfecto para TDD.

Kent afirma que en todo esto tiene que haber un balance. Hay que tener en cuenta el coste de aislarlo todo para testearlo de manera independiente y su beneficio. Que no hace falta hacer mocks de todo. Si tienes unos tests de objetos que usan otros objetos reales o un sistema real y se es capaz de tener así la prueba de si va o no va, es suficiente. Cuenta que mucha gente se queja de que el Unit Test no le deja refactorizar. Esto ocurre porque sus tests complejos que tienen mocks que devuelven mocks y como fruto estos tests están muy acoplados a la implementación.

Segun David, el problema está en la definicion de TDD segun algunos sectores del desarrollo. Estos sectores afirman cosas como que cualquier test tiene que estar basado en mocks y que si no usas TDD no eres buen profesional. Incluso que si el diseño del programa no está dirigido por tests, no es buen diseño. Para David es al contrario, TDD fuerza a tener un diseño no natural.

Martin Fowler, quedandose un poco en medio y actuando un poco como arbitro del debate, también dando su opinión más pragmática. Dice que hay en la calle muchas definiciones de TDD. Algunas de ellas dicen que todo tiene que estar con mocks. Sin embargo la realidad es que si no usa mocks y el test es util, perfecto. Dice que el TDD y el Unit test son dos cosas aisladas y hay que tratarlas como tal. Se puede hacer TDD sin que todo el codigo testeado esté aislado. Para él, como ya dijo en su artículo, lo importante es que el código sea autotesteable, que haya un botón que pueda probar todo el código. TDD está bien porque ofrece esto como uno de sus beneficios.  Está de acuerdo en que en ocasiones no se puede usar TDD, cosa que le apena ya que dice que es una herramienta que le gusta. También opina que incluso hay que separar conceptualmente el Unit testing aislado y el no aislado.

El debate termina barajando un posible futuro debate hablando unicamente de si el TDD crea un buen diseño o no.

 

 

 

To TDD or not to TDD. That is the question

Menuda guerra ha ocurrido esta semana. Cómo decía un compañero, parecía una discusión de Salvame Deluxe pero en el mundo del desarrollo.

Todo empezó cuando David Heinemeier Hansson, padre del Ruby on Rails,  escribió un artículo sobre los problemas de usar TDD. David afirma que hacer TDD no es conveniente, que obliga a separar demasiados intefaces  y que es mejor hacer tests de integración más lentos que de todos modos, con paralelización y test en la nube se pueden hacer muchos a la vez.

Al poco, Bob Martin (Uncle Bob) respondió en su blog que unicamente cuando se aplica TDD se consigue reducir el tiempo de depuración, una documentación unequivoca en los tests y un desacoplamiento entre clases muy valioso por sí mismo. Poco después volvió a escribir explicando un poco más dónde no se puede usar TDD y dónde sí. De este modo respondía a las críticas que suelen surgir sobre la falta de aplicabilidad en algunos entornos.

El propio  Kent Beck, padre del TDD, escribió en facebook un supuesta nota postuma sobre el TDD, echando de menos la técnica y rogando poder encontrar otra que le diera la misma seguridad a la hora de escribir, la misma documentación y enfoque a la hora de escribir.

Personalmente el TDD es una herramienta que vale la pena conocer bien. Entiendo sus dificultades. En más dificil hacerlo bien que cualquier framework, IDE o incluso lenguaje. Requiere que el desarrollador dedique tiempo no a crear, que es lo que más le gusta, sino a poner redes de seguridad a lo que aún no ha empezado a escribir. En VSN no lo hacemos el 100% de las veces. Tenemos “sólo” un 40% de cobertura que nos ofrece ya una gran seguridad a la hora de añadir nuevas funcionalidades o refactorizar. Sin embargo, nada no nos impide intentar tener cada vez más cobertura y usar TDD cada vez en más ocasiones. Como alguien me dijo una vez, si intentas saltar tan alto como para tocar la luna lo más seguro es que nunca lo consigas, pero llegarás muchísimo más alto que si nunca lo hubieses intentado.

Cuando el manager se convierte en un lastre para el equipo

En nuestro equipo de desarrollo hacemos una retrospectiva al final de cada sprint (como se debe). Nosotros usamos la técnica del barco. Dibujo un barco en la pizarra con un espacio de motores que simboliza los lo que nos hace ir a buena velocidad y unos lastres atados que simboliza problemas que nos dificultan ir a mayor velocidad.

En la retrospectiva anterior que celebramos ocurrió algo que no había pasado y el que ocurriera me llenó de orgullo. Me dijeron que YO era un lastre cuando tocaba código de producción. Ocurrió que para intentar hacer una historia de usuario que parecía que no iba a entrar decidí hacerla yo por mi cuenta. Al final produjo unos problemas que les hizo perder el tiempo arreglándolo 😛

Por un lado, como me gusta tanto programar fue en parte una lástima pero como facilitador de equipo me encantó. De hecho di las gracias personalmente después de la reunión a quien me lo dijo y explico por qué.

1.- Decir algo así a quien en principio “es tu jefe” requiere cierto grado de valentía. No debe ser fácil. Por lo tanto veo que hay CONFIANZA por su parte.
2.- Yo, que me esfuerzo en que el equipo vaya cada vez más rápido y con mejor calidad, si en lugar de tener que hacer algo para ello tengo que dejar de hacerlo, para mi es más sencillo.
3.-  Me hace ver que hay el clima de sinceridad en las retrospectivas que es muy necesario para mejorar sprint tras sprint.

Por lo tanto, no tengáis miedo si un día os dicen que habéis hecho algo que se considera un lastre para el equipo, u os habéis equivocado. Es el mejor indicador de que el trabajo de uno es importante y que el resto de cosas se hacen bien, ya que si no fuera así alguien se lo diría para mejorarlo.

El sabor de la buena UX

Los programas de TV de moda van cambiando año tras año. Reality shows, concursos de talento de canto, de baile, de salto en trampolín (sigh!). Ahora estan de moda los concursos de cocina como Master Chef, Top Chef y otros…

Tengo que admitir que a estos últimos sí estoy algo enganchado porque me siento identificado con los concursantes en los momentos en los que los jueces van a probar el plato, lo miran, lo prueban y lo juzgan. Todo lo aprendido por el cocinero antes de esa elaboración junto con la suerte y pericia en el momento de la elaboración se plasman en el plato.

Sé que es la enésima analogía del desarrollo de software, pero me vais a permitir usarla. Voy a analizar las tres partes de un software bien desarrollado.

La receta es la historia de usuario.
Cuando se define la historia de usuario es cuando el cocinero piensa qué va a cocinar. Puede ser lomo de atún, muslos de pollo a la pimienta o pastel de boniato con cintas de chocolate. El cocinero piensa qué es lo que le va a gustar al cliente y pasa a su ejecución. Igualmente un equipo de trabajo se enfrenta con una historia de usuario. La definición de esa historia indica cómo va a dar valor al cliente.

La presentación del plato es la estética del software
Tanto cuando se presenta un plato como cuando el cliente va a usar el software, el producto tiene que entrar por los ojos.  En cocina es muy importante aspectos el corte de los ingredientes, su color, cómo están alineados en el plato,… . En software igualmente hay que prestar atención a las fuentes que se usan, los bordes, los colores, los iconos,… Todo tiene que tener un aspecto cuidado.

Y para terminar…
El sabor es la Experiencia de Usuario, la UX
Aqui es donde el cocinero y el equipo de software más se la juegan. En cocina un plato puede estar bien planificado y con una cuidadisima estética pero pueden pasar cosas como una textura de un ingrediente que no es la que te habías imaginado, como algo que cruje y no debería, una combinación de sabores que no encajan,… Cuando el usuario usa la característica desarrollada pueden sucederle cosas muy parecidas: información que falta y hace que no sepa usarla, tener que hacer muchos clicks, tener que ir abriendo y cerrando interfaces, tener elementos de interfaz muy pequeños o muy grandes,…

Me faltan dos páginas para terminar el libro de Lean UX (mi mente ya no procesaba letra escrita). En breve hablaré un poco cómo se trabajan esos dos aspectos, la estética y la experiencia de usuario. En un equipo Ágil se trabajan de forma completamente distinta y en momentos distintos. Lo veremos.

Programa sinvergüenza!

Cuando uno empieza la carrera de Ingeniería en Informática, nos dicen que estudiamos la carrera para ser jefes de proyecto, no programadores. ¡Tonterías!

Cierto es que la vida de programador es difícil, dura y aburrida cuando uno termina la carrera. Salen bugs por doquier, se escribe un código horrible y se pasan horas y horas haciendo que todo “medio funcione”.  La cosa cambia cuando se empieza a controlar el Código Limpio, a usar bien los tests unitarios y usar herramientas como la integración contínua. En ese momento se empieza a disfrutar programando como nunca, creando nuevas características con nuevas tecnologías prácticamente sin errores y en un ambiente de trabajo distendido que te permite ir a casa a una hora razonable.

En ese momento tu papel tiene que cambiar y te toca llevar un equipo.

Cuando se lleva un equipo de trabajo la mayoría de gente piensa que ya no debe programar, que te tienes que centrar en quitar bloqueos al equipo y proveer del mayor valor posible al cliente a tiempo. ¡ Qué pena!, ¿no?

En el libro “Lessons in Agile Managment: On the Road to Kanban“, David J Anderson habla que un jefe de equipo no tiene por qué dejar de programar. De hecho la mejor manera de inculcar las buenas prácticas es mediante el ejemplo. Yo tengo que aportar una cosa más. Tambien puede programar si el objetivo de ese software es evitarles interrupciones y/o mejorar su productividad. Un jefe de equipo puede practicar sus artes haciendo esa herramienta que viene perfecta a los de operaciones para obtener información de qué hacer sin tener que llamar a desarrollo, o esa herramienta para gestionar las dependencias de los proyectos. Esto tambien es gestionar.

Nuestro humilde Coderetreat

El pasado sábado 14 de Diciembre celebramos en Alicante nuestro primer Coderetreat. Si quieres detalles de qué es un Coderetreat aquí los tienes.

Gracias a Santiago Melía conseguimos un aula muy buena en la Universidad de Alicante y fue el pistoletazo de salida para empezar a prepararlo. Creé el evento en la web del Coderetreat y en Eventbrite para que la gente se pudiera apuntar de manera sencilla.  Sabía que debía conseguir que algún patrocinador que pagara el almuerzo o la comida del día y poder traer la comida a la propia aula. Para ello contacté con empresas locales de papelería, componentes informáticos, bancos, el ayuntamiento, la diputación… “Rien de rien”. Lo único que conseguí fue alguna respuesta diciendo “No vamos a patrocinar nada pero suerte en el evento”.

Angel Armenta se propuso prepararse el papel de facilitador. Así yo podría estar en las conexiones con otras ciudades del mundo, actualizando el estado de nuestras sesiones, poniendo la publicidad y estar atento al evento. Los días pasaban y pocos apuntados iban apareciendo. Llégó la fecha del 14 de Diciembre con sólo 6 inscritos. Sin embargo, tras hacer cancelado un par de eventos por ser poca gente y haberme arrepentido despues,  tiré millas hacia delante con el evento.

Llegó el día. Como no conseguimos patrocinador yo compré unas empanadillas y dulces para comer allí y Ángel se encargaba de las bebidas y el café. Puse los carteles para indicar bien cómo se llegaba al aula (no sea que alguien se fuera a perder). Cuando llegó la hora de comenzar nos encontramos 4 personas en el aula: Angel, dos inscritos y yo.

Total, que tanto Ángel como yo hicimos parejas con ellos y dejé aparcado el tema de conexiones globales y hangouts. Como dicen los mismos organizadores, lo más importante es la gente que hay dentro. Fueron unas sesiones muy interesantes. Abordamos el juego de la vida desde todos los puntos de vista posibles: la vida y muerte de la celula, cómo contar sus vecinos, qué criterio se elige para que sobreviva o no. Al medio día nos fuimos a comer a un restaurante y cerramos las sesiones de tarde con un Randori compartiendo la pantalla con un proyectos y resolviendo entre todos una vez más el juego.

Resultado: A la vista está. Esperamos repetir el próximo año. IMG_20131214_173632

Preguntas que tal vez te hagas de los Coderetreats

Apuntaros esta fecha todos los desarrolladores: Sábado 14 de Diciembre del 2013. Ese día se celebra en distintas ciudades de todo el mundo el Día Global del Coderetreat.

“¿Y qué es esta frikada?” Esta frikada es una oportunidad única de aprender a mejorar la calidad personal del desarrollo de software.

“Pero yo ya programo mucho en el trabajo”. Sí, pero cuando se trabaja la atención está en acabar lo antes posible. Normalmente se programa del modo que se cree más rápido sin intentar buscar nuevas maneras de hacerlo. Haciendo un kata, como el del Juego de la Vida que es el que se suele hacer ese día, te puedes permitir el lujo de hacerlo de esa forma que has leído u oídopero que nunca te habías atrevido a probar. El objetivo NO es terminar el kata. De hecho, a los 45 minutos tienes que borrar el código que has hecho.

“¿Queeee?, ¿Borrar lo que he hecho?” Cierto. Cada 45 minutos vas a enfrentarte al problema desde distintos ángulos y con determinadas restricciones que van cambiando.

“¿Y crees entonces que aprenderé algo?” Ciertamente. Mejorarás estas habilidades:

TDD: +4 Todas las sesiones se realizan haciendo primero los tests y después la solución.
Código limpio: +3 El foco constante está en trabajar con ese código ideal que nunca te has atrevido a escribir por falta de tiempo
Programación en parejas: +3 Todas las sesiones son en pareja mediante el método de PingPong. Uno escribe el test y hace que falla, el otro lo desarrolla,lo pasa a verde y escribe el test para el otro miembro.
Otros lenguajes: 30% de probabildades En cada sesión podrás trabajar con otros que usan otros lenguajes de programación como su segunda lengua madre
Carisma: +2 Trabajar codo con codo con gente con la que nunca has trabajado servirá para mejorar tus habilidades sociales en el trabajo.

“¿Dónde me puedo apuntar a uno?” En España se están haciendo en varios lugares. Aquí tienes una lista

Alicante http://tinyurl.com/on39bq4
Barcelona http://agile-barcelona.org
Caceres http://tinyurl.com/p52qq3d
Madrid http://tinyurl.com/p884qtw
Ourense http://tinyurl.com/on72tsj
Valencia http://tinyurl.com/q3yyj5d
Zaragoza http://tinyurl.com/pa7xp6r

Para buscar en otros lugares del mundo puedes buscarlo aquí: http://coderetreat.org/events

Date prisa. Normalmente las plazas son limitadas.

Si te pica el gusanillo aquí puedes ver más información de los amigos de Agile Madrid. madridcoderetreat.wordpress.com

Si tienes una empresa o conoces alguna que esté dispuesta a patrocinar algo de estas sesiones. Todos los participantes estarán muy agradecidos de que por ejemplo traiga la comida del día o de algun regalo o alguna licencia de software. Animará mucho el día y todos los asistentes tendrán en muy buena imagen la empresa. Contacta con el organizador de la sesión y preguntale qué necesita si estas interesado.

Cuando el desarrollador se pregunta “¿Qué voy a hacer hoy?”

Esta pregunta se pueden hacer muchos desarrolladores todos los días cuando entran al trabajo. Hay mucho trabajo por completar pero.. ¿qué es lo más eficiente que se puede hacer?

Cuando se intenta tener un sistema Agile/Lean es muy importante que el flujo de trabajo sea llevado mediante sistema PULL. Para conseguir esto las tareas deben atraerse hacia las ultimas fases del desarrollo. También hay que intentar reducir la cantidad de Trabajo en Curso (Work In Progress,WIP) por lo que antes de empezar nuevas características hay que intentar completar antes las que estan en curso.

Para conseguir todo esto, y con el apoyo de un tablero kanban fisico o virtual, los desarrolladores pueden decidir qué hacer en base a estas preguntas.

1.- ¿TENGO ALGUN TEST FALLIDO QUE DEBO ARREGLAR?  –> ARREGLARLO

Muchas veces los tests fallidos se acumulan y sólo se arreglan al final de sprint. Esto provoca que haya una acumulación de desarrollos y tests que pueden hacer que el deadline o fin de sprint se retrase. Debería ser la prioridad principal el completar los desarrollos ya hechos arreglando esos fallos que se han encontrado antes de otra cosa.

2.- ¿EL NUMERO DE TESTS PENDIENTES HA ALCANZADO SU MAXIMO? –> PASAR UN TEST

En VSN, el equipo de desarrollo ha definido cómo número máximo de historias esperando el test a 3. Si en el daily stand-up se ve que ha alcanzado ese número, se reparten 2 tests entre los desarrolladores para aliviar esa saturación. Naturalmente, ningún desarrollador testea lo que él mismo ha desarrollado, sino lo que ha hecho otro.

3.- ¿TENGO ALGUN DESARROLLO EN CURSO? –> CONTINUAR CON EL DESARROLLO

Naturalmente, una buenísima manera de avanzar es seguir con la historia y las tareas que había en curso.

4.- ¿PUEDO AYUDAR A TERMINAR ALGUNA HISTORIA EN CURSO? –> AYUDAR CON ESA HISTORIA

Si hay desarrolladores a los que se puede ayudar hay que hacerlo llegado este punto. Puede ser mediante el pair-programming, puede ser haciendo alguna tarea que se puede paralelizar, puede ser invesigando algo en Internet que necesite. Lo que se pueda hacer para ayudar a terminar antes con las historias que ya están en desarrollo.

5.- EMPEZAR HISTORIA LISTA EN ORDEN DE PRIORIDAD

Si a las anteriores preguntas se ha respondido NO pues no hay mayor problema. Se elige una historia por empezar siguiendo el orden de prioridad  establecido y a desarrollarla