Juan, gracias por este recurso, que bate el record de valor por centímetro cuadrado ;-).

He buscado en google el artículo al que haces referencia "The new development game" y no he encontrado nada. ¿está publicado en internet? si es así ¿podrías incluir un enlace?

Lucas Rodríguez Cervera
Nevant

Lucas, gracias por tu felicitación, y ¡perdón!, había una errata en el título del artículo.
Ya he actualizado la ficha, y donde decía "The New Development Game" ahora dice "The New New Product Development Game".
El artículo lo puedes localizar en Harvard Business Online, (6$ :-)
Ahora sí, entrecomillando en Google el título sin erratas, lo podrás localizar en muchos sitios.
Gracias por la advertencia y un saludo.

Juan Palacio

Hola Julio,
Tengo una pregunta sobre cual es el papel del equipo de calidad (testing) en el Sprint. Supongamos que son 4 semanas el Sprint. ¿Sería 3 semanas de desarrollo y una semana de testing? Yo lo veo como que desarrollo implementa durante tres semanas y QA prepara los test cases....pero mientras se hace el testing ¿que hacen los desarrolladores? porque se supone que ya han terminado sus tareas ¿no? como se gestionaría el testing y la regresión de defectos encontrados.

Muchas gracias

Tocayo. Como te habrás dado cuenta no obtuviste respuesta luego de dos años. Eso es así por que QA no tiene una definición formal en los entornos Ágile y me arriesgo a decirte que en SCRUM no está bien estipulado como es el proceso de testing y calidad. Leí varios libro y en todos ellos dicen "la calidad no se negocia", pero en ninguno de ellos explican como evitan la merma de calidad con iteraciones tan cortas, o dicho de otra manera, como la obtienen y garantizan.
Alguna respuesta lógica podría ser:
1, la intervención temprana del equipo de testing en el ámbito del proyecto
esto quiere decir que hay que apartarse de la idea de esperar a que los requisitos estén maduros para tomar el documento de requerimientos y realizar el diseño de casos de pruebas. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos en tiempos muy cortos, la eliminación de algunos de ellos y la aparición de nuevos.
Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando el requerimiento es expuesto al equipo. Allí comienza nuestra fase de análisis al mismo tiempo que para el equipo de desarrollo. Prontamente estaremos en la fase de diseño de las pruebas, donde también es extremadamente dificultoso ser veloces y preciso con iteraciones tan cortas.
Es debido a ello que verás muy pocas propuestas serias para trabajar y hoy ya se están abriendo paso

2, herramientas colaborativas, donde los encargados de indicar criterios de calidad, criterios de aceptación, modos de fallos, modos de prueba y demás, son todos los miembros del equipo e interesados. Esto es así dado a que la industria se dió cuenta que las mejores pruebas las hacen nuestros clientes y en todo el ciclo de vida de un requisito, los distintos tipos de analistas (negocios, requerimientos, sistemas, soporte, pruebas) representan algún aspecto de los clientes, pero no todos. Estas herramientas ayudan a

3, automatizar el proceso de desarrollo, donde la generación del requisito es el inicio natural, pero está acompañada su evolución por aspectos de la gestión de proyectos, tales como criticidad y priorización, estimaciones, asignaciones, control de cambios, control de estados, gestión de recursos, desvíos, replanificación y métricas. Todos elementos para sostener un curso razonable de la calidad del proceso y del proyecto.

en relación a tus preguntas te diría que:
Tres semana de desarrollo y uno de testing es posible. Debes contar con los recursos necesarios y adecuados. El problema aquí nuevamente es la planificación del testing y la calidad. ¿tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional.

Mientras se hace testing los desarrolladores codifican. Para eso están, salvo que también sean testers, ya que aunque está mal visto en los paradígmas tradicionales, puedo asegurar que visto con un pensamiento lateral es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo QA. También adoptan perspectivas diferentes que le ayudan en sus próximos enfoques para el desarrollo de las soluciones.
Tiene sus aspectos negativos que se pueden ir puliendo. Por ejemplo un desarrollador que eventualmente pasa a testing, al detectar un defecto lo analizará desde el aspecto que más conoce. Querrá acceder a la base de datos y debaguear el código, y si fuera posible corregir y recompilar inmediatamente.
Bueno, eso también lo hemos hecho, pero en otras situaciones, por ejemplo cuando se hace la verificación de las correcciones de defectos. Particularmente yo me salto "el aparato comunicacional" y le digo "master, tengo un defecto persistente. Que te parece mirarlo juntos y resolverlo de buenas a primera?"
Como elemento QA, lo que debes hacer es generar los ambientes para pruebas netamente funcionales, es decir, aislados de accesos a bases de datos e IDEs de desarrollo, ya que lo que se pretende al menos en las pruebas de funcionalidad, es utilizar el sistema como lo haría nuestro cliente final, pero con mucho más rigor.
Entonces, como verás hay muchísima tela para cortar al respecto. Solo hemos "tocado por encima" algunos aspectos QA & Testing. Imagina si tenemos que hablar de pruebas unitarias, de componentes, de integración, métodos y técnicas.... en fin.

Lo cierto es que SCRUM es solo una metodología de gestión de proyectos, bien sinérgica, orientada a equipos maduros, autogestionados, con altísimos conocimientos técnicos, con gran dominio del negocio que genera los requerimientos y no pretende indicar como se hará el arte de desarrollar, ni de probar, mucho menos se hará de conceptos para el mundo QA & Testing.

Saludos,
Javier Santillán García

Hola Javier,
Muchas gracias por tu respuesta. Me ha interesado mucho todos tus comentarios, pero en especial el último párrafo: "Lo cierto es que SCRUM es solo una metodología de gestión de proyectos". SCRUM no entra en como se deben de hacer los test, pero si que creo que hay un vacío que deberían de revisar...tal vez reuniendo varios expertos del mundo del testing para asesorar y completar un poco más esta parte que falta. Saludos

Estimados
Javier Fernández-Pello
Javier Alejandro Santillán García

Me ha resultado muy provechosa la lectura de sus comentarios, hasta tal punto que he tomado (si me lo permiten) parte de sus exposiciones para elaborar un artículo que lo estaré subiendo a mi blog (por supuesto, haciendo la referencia a esta url, como corresponde)

Realmente hay "mucha tela para cortar" sobre este tema y a nivel general -creo- solo se está tratando la "punta del iceberg" por ahora.

Quisiera seguir manteniendo contacto con Uds, y estaré colocando la url de este website como uno de mis favoritos.

Trabajo en testing para una compañía automotriz y además intervengo en proyectos a distancia, y todo lo expuesto aquí lo vivo y lo he vivido infinidades de veces.

Encuentro una gran diferencia cuando trabajo con equipos de desarrollo maduros, inclusive también si del lado del cliente hay un usuario también lo suficientemente capacitado para avanzar con el mismo ritmo que llevamos nosotros, la sinergia que se produce es muy buena, y la calidad del producto final es la esperada.

Pero no siempre tenemos lo que deseamos, e incluso no todas las organizaciones están preparadas para adaptarse a este tipo de metodología rápidamente.

Pero bue...seguiremos viendo como evolucionan este tipo de metodologías.

Les mando un saludo
Cordialmente
Gustavo