| # | Pregunta | Quién pregunta | Respuesta | Quién responde
|
| 1 | En cada sprint se tiene que realizar un pase a producción o solo son entegables que se muestran al usuario y al final se pasa a porducción todo? | Jacqueline Pantoja <jpantoja.j@gmail.com> | La teoria indica que al final de cada Sprint todo lo generado PUEDE pasar a produccion, pero los pases a produccion dependen mucho de las politicas de las empresas. En mi experiencia he tenido casos que al final de cada Sprint no paso a produccion sino simplemente el equipo demuestra lo que se ha hecho y luego de 2 o 3 Sprints recien pasamos a Produccion. | Deusdit Correa
|
| 2 | Solo se puede utilizar Scrum para proyectos pequeños de corta duración? Si es asi, de cuanto tiempo mas o menos? | Jacqueline Pantoja <jpantoja.j@gmail.com> | No, Scrum se puede usar con proyectos de cualquier duración, porque sea grande o pequeño siempre se puede dividir en Sprints. La duración de los Sprints si puede variar en cada proyecto, por ejemplo en mi experiencia, a veces hacemos Sprints de 4 semanas para proyectos complicados (porque puede ser que en 2 semanas no se pueda terminar algo que sea demostrable) y luego hacemos Sprints de 2 o 3 semanas para proyectos mas sencillos (o incluso dentro del mismo proyecto pero en etapas en que los requerimientos son mas sencillos, pero procuramos mantener la duracion de los Sprints fija por un buen tiempo para que se genere la cadencia o ritmo y los involucrados siempre sepan cuando va a salir algo nuevo en el producto). | Deusdit Correa
|
| 3 | Que tipo de documentación es la mínima indispensable? Quien o como se definen? | | Eso depende mucho de las politicas de las empresas, de manera general la documentación indispensable es la que agrega valor al Producto y que realmente es leida por los involucrados, y como tienes al Product Owner a tu alcance es facil coordinar con el y decidir de manera consensual con el Equipo que documentos deberan ser creados/mantenidos durante el proyecto. Ademas, como lo indica el Agile Manifesto, es mejor invertir mas tiempo en tener software de calidad que haciendo documentos que no van a ser leidos | Deusdit Correa
|
| 4 | Es tan factible realizar Scrum in-house? o siempre se hace con servicios tercerizados (outsourcing)? | | Scrum se puede usar en cualquier caso pues como es un Framework puede ser adaptable a cualquier situacion. Mi experiencia con Scrum es el desarrollo de proyectos in-house. | Deusdit Correa
|
| 5 | El manifesto Agile se revisa periodicamente o es algo fijo y estatico? | <yucra.jose@gmail.com> | El Manifesto Agile fue creado en 2001 y hasta el momento todos los valores sugeridos alli son muy utiles y aplicables, y creo que como no son normas o dogmas, simplemente principios, entonces van a quedar vigentes por mucho mas tiempo. | Deusdit Correa
|
| 6 | En el Daily Scrum debe estar presente el Product Owner? | <yucra.jose@gmail.com> | El Product Owner puede estar presente durante el Daily Scrum y si lo esta es para que escuche la reunion, no para que participe de ella, si tiene algo que decir, lo pueed hacer despues de la reunion. | Deusdit Correa
|
| 7 | Hay penalidades ante las estimaciones individuales erroneas? | <yucra.jose@gmail.com> | Antes que nada, siendo estrictos, no existen estimaciones erroneas pues las estimaciones, por definicion, no son absolutas ni precisas, siempre son solo eso, estimaciones, es cierto que con el tiempo y el uso de tecnicas la precision puede mejorar, pero nunca ser absoluta (El hombre, hasta donde yo se, no tiene la capacidad de ver el futuro y por ello no puede asignar valores absolutos a algo incierto). Por otro lado, en Scrum no hay estimaciones individuales, las estimaciones las hacen todo el equipo y el valor final es decidido por consenso y para ello se puede usar la tecnica llamada Planning Poker. | Deusdit Correa
|
| 8 | Como se definen requerimientos para una metodologia Agile? | | Existen varias tendencias, la mas generalizada es la comentada en la Conferencia que es utilizar User Stories pues generan dialogo y discusion entre todos los participantes. Pero hay equipos que usan incluso User Cases, todo depende que la forma en que se toman los requerimientos no sea un impedimento para avanzar agilmente con el desarrollo del producto. Asimismo, se menciono que en un Sprint se realiza todo: Analisis, Diseño, Pruebas, etc., entonces la toma de requerimientos (definidos por el Product Owner) se realiza tambien dentro del Sprint. | Deusdit Correa
|
| 9 | Que pasa cuando una empresa exige como parte de su metodologia una serie de documentacion que segun Scrum no da valor, pero ha sido parte de los entregables? | | No se trata de decir al jefe "vengo del Lima Agile Day y me dicen que Scrum es lo maximo y toda esta documentacion no sirve", eso es parte de la negociacion que se debe hacer con el Product Owner pues se tiene que hacer notar que tal o cual documento no es muy util y esto es posible porque tienes al Product Owner a tu alcance, si ya la documentacion esta comprometida y no se puede cambiar, pues debe hacersela y para la proxima vez analizar mejor que tipo de documentacion generar. | Deusdit Correa
|
| 10 | Como se adquiere el detalle de los Stories o Requerimientos? Se puede empezar sin especificaciones funcionales detalladas? | | El detalle de los Stories se analizan durante el Planning Meeting (pero se pudo conversar sobre ello en el Story Time Meeting) y para eso el Product Owner debe tener bien claro que es lo que se quiere obtener en cada Requerimiento. Por otro lado, claro que se puede comenzar sin especificaciones Funcionales detalladas pues esa ese concepto es parte del modelo Waterfall en el que alguien ya analizo y diseño lo que se debe hacer y el desarrollador "solo tiene que programar", en Agile ese documento no existe y todo el detalle necesario es obtenido en el Planning Meeting. | Deusdit Correa
|
| 11 | Que sucede con los errores una vez terminado el Sprint? | | Buena pregunta!, es responsabilidad del Product Owner calificar los errores reportados y si es muy critico entonces pasa a ser un Story mas en el Product Backlog que debera ser priorizado junto con el resto de Stories y segun ello sera corregido en un siguiente Sprint. | Deusdit Correa
|
| 12 | Como trabaja Scrum con participantes que trabajan en multiples proyectos? | | Si hay varias personas que estan involucradas en mas de un proyecto a la vez, entonces simplemente no estan usando Scrum, pues uno de los conceptos es que los miembros del equipo trabajan al 100% en un solo Sprint a la vez; ademas, como lo explico Gustavo Quiroz en su ponencia sobre Fundamentos de Agilidad, esta demostrado que el Multitasking no es bueno para las personas. | Deusdit Correa
|
| 13 | Scrum, diferencias en la gestion de Proyectos de Software Libre? | | Scrum es una metodologia que sugiere como buena practica que los miembros del Equipo esten co-locados, sin embargo cuando el equipo esta distribuido al rededor del mundo, entonces hay que adaptar Scrum a esa realidad, y ese es el caso de Proyectos de Software Libre, sin embargo los conceptos de Sprint, Planning Meeting, Daily Scrum, Review Meeting y Retrospective Meeting son aplicables sin ningun tipo de problemas, pues son guias que se pueden utilizar sin ninguna restriccion de tecnologia. No tengo mucha experiencia con temas de Software Libre pero creo que Scrum calzaria perfectamente en la forma de desarrollar. | Deusdit Correa
|
| # | Pregunta | Quién pregunta | Respuesta | Quién responde
|
| 1 | ¿Qué puede hacer un SM si el PO no es idóneo, infunde miedo, o duda de Scrum (ama su cronograma) ? | | Lo primero es buscar la forma que no salga de él, esto debe salir en la retrospectiva y surgir como impedimento desde el mismo equipo, en el momento en el que se propongan alternativas de solución el ScrumMaster (si lo cree necesario) podría dar alguna idea más de solución a debatir, en todo caso, el tema es delicado, personalmente propondría la siguiente alternativa de solución: 1) Hablar directamente con el PO. 2) Si el punto 1 no solucionara nada, hablar con el team y (por ejemplo) intentar en un sprint trabajar con el PO bajo esas condiciones y analizar al final en la reunión de retrospectiva si es dable o no el seguir llevando el proyecto así (tal vez no sea tan malo como el SM piensa, recordemos que lo que más importa es cuanto agrega de valor al proyecto y si es considerado un impedimiento por el equipo). 3) Hablar con una instancia superior y dar a conocer que el exito del proyecto está en peligro debido a la actitud y al manejo del PO. | Raúl Uribe
|
| 2 | ¿En el Scrum Daily Meeting habla también el SM o sólo el team? | | Lo ideal es que el sólo sea el Team, pero podríamos decir que (en general) en las primeras Scrum Daily el SM de vez en cuando si debe hablar, debido a que está aún entrenando al equipo y haciendole ver con el ejemplo cuál es el verdadero fin de esa reunión, en el tiempo, cuando el equipo domina la dinámica de la reunión, el SM actúa de espectador y registra los impedimentos expuestos de existir alguno. En ocasiones especiales el SM comenta sobre algún impedimiento (presentado previamente) solucionado o que está dificil de solucionar, esto es polémico, debería hacerse siempre y cuando no interfiera con el timebox, personalmente me gusta, porque inspira un aroma de "todos aquí estamos trabajando, yo el SM, también!". | Raúl Uribe
|
| # | Pregunta | Quién pregunta | Respuesta | Quién responde
|
| 1 | Sobre "The Blame Game", ¿cué hacer cuando hay tareas asignadas, hay un "culpable" o responsable?
| | Idealmente el equipo es quien se propone sus propias tareas. Cuando por algún motivo un miembro del equipo no puede completar una tarea o ve que se está tomando demasiado tiempo, durante la reunión diaria esto se hace visible y otro miembro del equipo puede ofrecerse a ayudar o a tomar la tarea completa. El Scrum Master debe velar porque esta dinámica se de, y facilitarla en caso el equipo aún no lo haga espontáneamente. | Gustavo Q.
|
| 2 | ¿En qué momento del proyecto hacer slack? (juego, relajamiento) | | Depende del equipo y de la cultura organizacional. En mi caso lo hacemos después de la jornada laboral, a partir de la 6 ó 7 pm. Otras empresas usan la hora de almuerzo y otras, las más "atrevidas" no tienen restricciones de horario porque confían en que su gente no se va a quedar jugando Wii o Playstation todo el día, sino que va a producir valor para empresa. Aquellos que no lo hacen casi por selección natural tienden a dejar la empresa. | Gustavo Q.
|
| 3 | ¿Qué es el Buen Samaritano? | | Es un experimento social que muestra que cuando el ser humano se encuentra bajo una presión excesiva de tiempo tiende a dejar de hacer cosas muy importantes, cosa que bajo un contexto normal no harían. Esto, en los proyectos de software se traduce en calidad. Es decir, los desarrolladores casi sin darse tienen a reducir la calidad del software que producen cuando están bajo una extrema presión. Aquí pueden encontrar información más completa sobre el experimento: http://faculty.babson.edu/krollag/org_site/soc_psych/darley_samarit.html http://www.experiment-resources.com/helping-behavior.html | Gustavo Q.
|
| 4 | Si tenemos por ejemplo 3 equipos trabajando c/u un proyecto. Termina un proyecto y este equipo, económicamente, ¿cómo se mantiene? La gerencia focaliza la productividad económica de los trabajadores. ¿Qué vía hay para esto? | | Aunque sería ideal que los equipos se mantengan unidos proyecto tras proyecto, en la práctica esto se hace difícil por la manera como se generan proyectos en muchas empresas. En este caso es viable que los miembros del equipo pasen a conformar otros equipos según las necesidades del negocio, lo cual de hecho conlleva a tener prácticas adecuadas de comunicación y gestión tanto del de conocimiento como de las personas. | Gustavo Q.
|
| 5 | Caracteristicas previas del Equipo (Requisitos) "Knowledgement". Condiciones favorables en la empresa? | | Los conocimientos específicos varían según el proyecto. Lo básico que yo opino que todo miembro del equipo debe tener es: capacidad de comunicación y capacidad de aprender y enseñar. Además, es un hecho que la cultura organizacional es importante y va a influir directamente en el grado de dificultad de la aplicación de métodos ágiles. Una cultura más pegada a los principios y prácticas que delineé en mi presentación va a ser mucho más receptiva a los valores ágiles | Gustavo Q.
|
| # | Pregunta | Quién pregunta | Respuesta | Quién responde
|
| 1 | Las imágenes estuvieron muy buenas, ¿dónde las consiguieron? | | Entiendo que Deus, Gustavo V., Raúl y yo las obtuvimos mediante el buscado de imágenes de Google o similares. En el caso de Abner, el las compró en uno de esas tiendas on-line de stock photos. | Gustavo Q.
|
| 2 | ¿Cuántas personas como mínimo debe haber para una metodología ágil? | | En cualquier metodología Agile se sugiere equipos con grupo reducido de personas, en Scrum se sugiere 7+-2 personas. Si se tratase de un numero mínimo yo sugeriría 2 personas pues así se puede hacer hacer dinamicas de interacción e integración (como pair programing/review). | Deusdit Correa
|
| 3 | ¿1 ó 2 personas pueden hacer software con métodos ágiles? | | Como lo indiqué en la respuesta anterior, personalmente sugiero que hayan 2 personas como mínimo, pero eso no implica que no sea posible utilizar metodologías ágiles con una sola persona, pues en la mayoría de ellas hay principios y practicas que son sencillas de aplicar. | Deusdit Correa
|
| 4 | ¿Cómo distribuir el esfuerzo u horas hombre con respecto a la lista de tareas o actividades que uno se compromete a hacer? | | Interesante pregunta, en las metodologias agiles se sugiere no llevar el "micromanagement" de horas hombres por cada tarea, pues lo que se busca es el trabajo en equipo, lo que se busca medir es el desempeño de todo el equipo; al fin y al cabo, el equipo en su totalidad se comprometio con una serie de tareas y al momento de hacerlo no se conoce quien hara cada una de las tareas por lo tanto no se puede hacer tal distribucion (la cual es normalmente una practica de las metodologias Waterfall) | Deusdit Correa
|
| 5 | ¿Cómo se relacionan estas actividades con otras metodologías no ágiles y más complejas tipo CMMI ó PMBOK? | | Si bien hace algunos años muchos practicantes de métodos ágiles veían con cierto recelo tanto al modelo CMMI como al PMBOK, desde hace un tiempo ha habido mucho más acercamiento entre ambos mundo para buscar coincidencias y sinergías en pos de mejorar la gestión de los proyectos de desarrollo de software. Por citar un caso, el año pasado el SEI publicó un White Paper llamado CMMI or Agile: Why Not Embrace Both! http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html Otro caso importante es que, en el reciente Scrum Gathering de Orlando, Gregory Balestrero, Presidente y CEO del PMI, dio uno de los Keynotes. | Gustavo Q.
|
