Explicando Scrum a mi abuela
Explicando Scrum a mi abuela
Introducción
El otro día me encontraba hablando con un compañero de trabajo a través del teléfono móvil, cuando mi abuela me escuchó nombrar palabras raras en la conversación.
Una de esas palabras era Scrum, y por la forma en la que hablaba fue lo que más atención la llamó, así que cuando colgué, lo primero que me preguntó fue con quién hablaba, de qué hablaba, y que era eso de Scrum.
Imaginaros la cara que se me quedó, porque… ¿cómo explicar Scrum a mi abuela?.
Aunque mi abuela es muy avanzada para la mayoría de la gente de su edad, la verdad es que no es fácil explicarla muchos de los aspectos tecnológicos emergentes, pero bueno, es mi abuela y tenía que intentar explicárselo de forma convincente.
Aquí, os transcribo aquella inverosímil conversación.
La conversación y sus explicaciones
¿De que hablabas?, parecía interesante eso que decías de Scrum. ¿Qué es exactamente?
¡Ah sí! Scrum es una metodología.
¿Y para que se utiliza?
Se utiliza en mi profesión, en el desarrollo del Software concretamente, aunque hay gente por ahí que la usa o la quiere usar en otras profesiones y áreas.
¿Y para eso del desarrollo del Software tenéis que usar ese tal Scrum?
En realidad no. No es estrictamente necesario.
Scrum por sus características no es válido para cualquier proyecto ni para cualquier persona o equipo de personas. Es más, Scrum según muchos especialistas de esta metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay empresas que han utilizado Scrum con éxito con equipos más grandes.
Yo diría que para el 90% de los proyectos y empresas, es una metodología válida, pero no es una metodología válida al 100%. Es más, no hay metodología mejor que otra ni válida al 100% para todas las personas y empresas.
Scrum es por lo tanto, una metodología más de las muchas que hay, y ésta en concreto, se basa en la filosofía del desarrollo ágil que fue expuesto por dos japoneses alrededor del año 1986.
Siempre estos japoneses… has dicho desarrollo ágil varias veces… ¿que es eso exactamente?, a mí eso sí que me suena a japonés o a chino
El desarrollo ágil pone de manifiesto básicamente lo siguiente:
- El mercado actual es altamente competitivo y la tecnología es muy cambiante. En el desarrollo del Software se pide básicamente rapidez, calidad y reducción de costes, pero para asumir estos retos, es necesario tener agilidad y flexibilidad.
- Los ciclos de desarrollo por otro lado, acostumbran a ser largos, y lo que se exige por otra parte, es que esos ciclos sean lo más cortos posibles.
El desarrollo ágil aboga por estas premisas principalmente.
Hay más detalles, pero no los voy a abordar ahora para no marearte con información que nos desvíe la atención de la propia explicación de Scrum.
Empiezo a entender algo más esto…pero… ¿en qué consiste exactamente eso de Scrum?
Scrum es como decía antes, una metodología ágil.
Obedece a las necesidades anteriormente citadas, y no responde a ninguna moda, sino a una necesidad realmente demandada en el desarrollo del Software.
Scrum no es ni la mejor metodología ni la única, antes te decía que hay muchas, pero sí, es una metodología que está empujando muy fuerte por la facilidad de implantación y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparación con otras metodologías.
Por un lado, Scrum evita la burocracia y la generación documental. No es que con Scrum no se deba o no se pueda documentar, si no que con Scrum no se exige documentar nada para iniciar un proyecto, algo que en otras metodologías es impensable.
Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prácticamente desde el primer momento y empezar a sacar frutos de ese trabajo para que el cliente vaya viendo los avances y se quede satisfecho con lo que se está haciendo y cómo se está haciendo.
Sí sí, vale… pero ¿cómo muestras al cliente esos progresos en el trabajo?.
Bien bien, no te he contado aún mucho sobre Scrum, sólo el cascarón que lo envuelve, pero ya que preguntas y te veo realmente interesada, te voy a contar todo lo que hay con más detalle.
De forma resumida y global, en Scrum vamos a diferenciar dos aspectos importantes, los actores y las acciones.
Vaya, esto se pone interesante, sigue sigue que me está empezando a gustar esto del Scrum.
¡Ja!, pues espera a que te cuente, que esto no ha hecho nada más que comenzar.
Te decía que hay dos aspectos fundamentales a diferenciar, los actores y las acciones.
Los actores son los que ejecutarán obviamente las acciones.
Estos de forma general, serán:
- Product Owner
- Scrum Master
- Scrum Team
- Usuarios o Clientes
Algo que no te he dicho aún, es que para que un proyecto Software tenga éxito, el Usuario o Cliente, debe involucrarse sí o SÍ.
Esto vale para todos TODOS los proyectos, aunque no todos los Usuarios y Clientes lo entienden así, pero nuestra misión es también hacérselo ver.
Prosigo.
El Product Owner conoce y marca las prioridades del proyecto o producto.
El Scrum Master es la persona que asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas.
El Scrum Team son las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product Owner.
Los Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los progresos, pueden aportar ideas, sugerencias o necesidades.
¿Y lo de las acciones?
Te veo con hambre de conocimiento, eso está bien.
Las acciones tienen relación directa con los actores. Sin ellas, todo sería un caos.
En Scrum se indican claramente las acciones a acometer y como acometerlas. Nuestra responsabilidad es hacerlo siempre de una forma adecuada y algo rígida para impedir que se aplique erróneamente esta metodología.
Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y forma de trabajar que a continuación se indica, tiene como objetivo minimizar el esfuerzo y maximizar el rendimiento en el desarrollo.
Las acciones fundamentales de Scrum son:
- Product Backlog
- Sprint Backlog
- Daily Scrum Meeting
El Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a realizar. Antes decía que el Product Owner es la persona que se encarga de marcar las prioridades, y es al fin y al cabo, la persona que mantiene y actualiza dado el caso, la lista de tareas.
El Sprint Backlog corresponde con una o más tareas que provienen del Product Backlog. Es decir, del Product Backlog se saca una o más tareas que van a formar parte del Sprint Backlog. Las tareas del Sprint Backlog se deben acometer (recomendado) en unas 2 semanas ó 4 semanas. Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas. Eso debe de ser marcado antes de iniciar el Sprint Backlog, de hecho, del Product Backlog se sacará la tarea o tareas realistas para acometer el Sprint Backlog. Una norma fundamental es que mientras un Sprint Backlog se inicia, éste NO puede ser alterado o modificado. Hay que esperar a que concluya el Sprint Backlog para realizar la correspondiente modificación o alteración cuya tarea, formaría parte de otro Sprint Backlog.
El Daily Scrum Meeting es una tarea iterativa que se realiza todos los días que dure el Sprint Backlog con el equipo de desarrollo o de trabajo. Se trata de una reunión operativa, informal y ágil, de un máximo de 30 minutos, en la que se le hace 3 preguntas a cada integrante del equipo.
- Qué tareas ha realizado desde la última reunión (que he hecho).
- Sobre qué va a trabajar en el día actual (que voy a hacer hoy).
- Identificación de obstáculos o riesgos que impiden o pueden impedir el normal avance (que ayuda necesito). El Scrum Master, debe eliminar aquí cualquier obstáculo que encuentre.
Una pregunta más… has dicho que del Product Backlog se sacan tareas que van al Sprint Backlog, pero entiendo que no todas las tareas del Product Backlog van a la vez al Sprint Backlog, así que… ¿que se hace cuando una tarea del Sprint Backlog se finaliza?
Bien, esta es una pregunta típica.
Quizás no me he explicado bien, pero el Sprint Backlog, una vez que se inicia, ni se toca.
Es decir, que una tarea se acaba, y punto.
Se continúa con otra tarea del Sprint Backlog y así hasta que se acaben.
Lo que debemos tener claro, es que al finalizar un Sprint Backlog (ya sea de 2 semanas ó de 4 semanas), debemos haber acabado las tareas del Sprint Backlog.
Reitero que las tareas del Sprint Backlog deben de ser realistas.
Así que cuando se ha finalizado un Sprint Backlog, deberíamos tener algo, un entregable o algo que se pueda mostrar y que enseñe los avances acometidos en el Sprint.
En el Product Backlog tendremos más tareas, y es posible incluso que hayan salido nuevas tareas o que otras hayan desaparecido, por lo que es cuando se acaba el Sprint Backlog, cuando debemos hacer varias cosas importantes y que te indico a continuación.
Esto me está gustando muchísimo…
Me alegro, a mí me parece interesantísimo, y es más, Scrum es de sentido común, tanto, que yo sin saberlo ya lo utilizaba hace algunos años sin saber que era realmente Scrum.
Bueno, prosigo con esta explicación.
Como te decía, adicionalmente a las acciones anteriormente comentadas encontramos otras acciones más.
Antes para no saturarte, no te dije que entre el Product Backlog y el Sprint Backlog, hay algo, una reunión concretamente, que se denomina Sprint Planning Meeting.
- El Sprint Planning Meeting es una reunión que tiene por objetivo, planificar el Sprint a partir del Product Backlog. El objetivo de esta reunión es la de mover las tareas del Product Backlog al Sprint Backlog. En esta reunión, suelen participar el Product Owner que es como te dije antes quien prioriza las tareas, el Scrum Master y el Scrum Team.
- Del Sprint Planning Meeting, sale también el Sprint Goal, que es un pequeño documento o una breve descripción que indica lo que el Sprint intetará alcanzar.
- En el Sprint Review se revisa en unas 2 horas como máximo el Sprint finalizado. Al llegar a este punto, debemos tener «algo» que el Cliente o el Usuario pueda ver y tocar. En esta reunión, suelen asistir el Product Owner, el Scrum Master, el Scrum Team y personas que podrían estar involucradas en el proyecto. El Scrum Team es quién muestra los avances realizados en el Sprint.
- Al finalizar un Sprint Backlog y el Sprint Review, se inicia el Sprint Retrospective. El Product Owner revisará con el equipo los objetivos marcados inicialmente en el Sprint Backlog concluido, se aplicarán los cambios y ajustes si son necesarios, y se marcarán los aspectos positivos (para repetirlos) y los aspectos negativos (para evitar que se repitan) del Sprint.
Mira, te pintaré un diagrama que espero te ayude a entender todas las acciones de Scrum.
¿Y porque es eso de las 2 ó 4 semanas?. ¿No sería más fácil que cada equipo pusiera su franja de tiempo?
Sí claro, cada equipo, cada empresa, cada proyecto, puede poner la franja horaria y frecuencia temporal que considere oportuno así como cambiar aspectos de Scrum, pero te voy a poner un sencillo ejemplo con el cuál entenderás que es mejor hacer esto así que de otra forma.
Supongamos el caso de la construcción de un rascacielos o de un edificio.
Si con el fin de controlar el proyecto y que no se te escape nada ni metamos la pata en algo, me preguntas cada día en varias ocasiones como estoy haciendo las cosas, como lo llevo y cuales son mis avances, te aseguro que no terminaremos la construcción del edificio en el tiempo planificado ni de broma. Además, seguro que querrás cambiar o modificar algo cada día o incluso varias veces en el mismo día.
Si me preguntas cada 6 meses por ejemplo, avanzaré mucho sin interrupciones, pero a buen seguro que el riesgo de desviaciones es mucho mayor y seguramente si ocurren, reajustar esas desviaciones al proyecto tendrá costes elevados asociados.
Un término medio es el ajuste temporal de 2 ó 4 semanas que está basado en la experiencia de muchas personas en muchos proyectos. No es lo mismo reconducir el proyecto perdiendo 2 ó 4 semanas, que reconducirlo perdiendo 6 meses por ejemplo.
La idea de la metodología ágil es fundamentalmente que adopte los cambios, que se pueda reconducir el proyecto en un momento dado, y que afecte lo menos posible a los costes, los tiempos y al equipo de trabajo.
No es la metodología ideal. Yo siempre digo que si hubiera algo ideal, todo el mundo lo usaría, pero sí te digo, que Scrum se acerca bastante a esa idea general de la gestión ideal de proyectos.
A mí personalmente es la que más me gusta y la que por experiencia, mayor satisfacción suele dar, tanto al cliente o al usuario final como al equipo de trabajo.
Y no te creas que hay mucho más que saber de Scrum, esta es la filosofía o idea general que espero te haya quedado clara y te haya servido para entender lo que hablaba con mi compañero de trabajo.
Sin duda que me ha parecido muy interesante. Muchas gracias.
Nota: queda prohibida la reproducción parcial o total de este artículo sin la correspondiente autorización.
P.D.: muchas gracias a mi amigo y compañero Rodrigo Corral, el Máster de Scrum, quién me ha aleccionado sobre Scrum y quien me ha revisado esta historieta.
165 Responsesso far
Muy buena tu explicacion creo que hasta mi abuela lo entiende 😀
Saludos
Excelente Articulo !!!,
Puedes encontrar un simulador gratis de SCRUM en http://lumenti.com/learning con 30+ preguntas
http://www.lumenti.com/learning/course/view.php?id=4
Estamos tratando de implementar SCRUM para realizar proyectos arquitectónicos. Alguna idea o sugerencia? Saludos!!!.
:o!, fabuloso, ahora si me siento más seguro que había aprendido las bases de Scrum, sólo falta la practica y listo :p.
Y también creo, que este es el primer paso para empezar a usar una metodología, ya que no es de difícil implantación, y como dices, creo que muchos desarrolladores venian trabajando así, pero no sabían que se llamaba Scrum, ahora ya pueden decir que usan una metodología :).
Saludos,
Muy bueno el documento, felicidades 😉
Me alegro mucho de la buena acogida del documento y de que por supuesto guste. 🙂
Lo he hecho con el mayor cariño para todos los que preguntan en este y otros blogs y foros sobre Scrum.
Espero que resuelva algunas de esas dudas que se tienen cuando uno se encuentra delante de Scrum por primera vez (aunque sirve para repasarlo en cualquier momento cuando surge una duda en nuestros proyectos).
si lo hubieras explicado antes….
no hubiera investigado por mi cuenta :), pero como dices, bien para los que andan viendo que quiere decir eso llamado Scrum, y lo mejor es que cuando se enteren, digan: -a que eso era.., pero yo hacia algo parecido…
Saludos,
A mí lo que más me gusta Sergio, es que aún habiéndo hecho algo parecido antes (sin saber que se llamaba Scrum o que pertenecía a los principios ágiles), la metodología te indica cómo hacer las cosas y el orden de hacerlas, lo cuál nos viene extremadamente bien para no salirnos por la tangente y evitar así el caos. 🙂
🙂
Peaso artículo Jorge,
Eres un fiera tio… No hace ni dos días que me comentaste tu idea por teléfono, y esta mañana mira lo que me he encontrado.
Pero ¿tu duermes o que?
Un abrazo desde Andorra,
Hola Jorge,
Había «escuchado» SCRUM mucho aquí en Geeks.ms, pero hasta ahora no he sabido que era realmente. Se basa en muchas cosas de las que ya he hecho cuando estoy con un proyecto. Muchas gracias por la aclaración [;)]. Buen artículo
Un Saludo
Excelente artículo … !!!
y un pequeño tip, lo mejor para comenzar a utilizarlo, si tienes un TFS a mano, es darse una vuelta por http://scrumforteamsystem.com/ProcessGuidance/ProcessGuidance.html y descargar el template para TFS, ahi podras comenzar a trabajar con Sprints, Products BackLogs, etc y veras que cuando se empieza, es dificil dejarlo !!!
Saludos y felicitaciones again 😀
Lluís, es algo que tenía entre manos (bueno en la cabeza exactamente) desde hacía tiempo y tenía muchas ganas de hacer… un ratillo para pensar como hacerlo y hacerlo, no es tan chungo.
¡Fran, esa es la idea de este artículo!… que se hable de Scrum pero que por lo menos sepamos de lo que se habla. Ahora sí podremos todos meter baza en los post de Rodrigo cuando este discute tal o tal cosa. 🙂
Bruno, espérate que otra cosa que tenía pensada era explicarle a mi abuela como usar TFS con Scrum… todo se andará… que también lo tengo en la agenda… 😉
Que grande !!! mu wen articulo Jorge, VIVA TU Y VIVA TU abuela 😛
Joder con tu abuela! Con ese ansia de conocimientos, dentro de nada ya me la veo hasta con blog propio dentro de geeks.ms «El blog de la Superabuela» xD
Saludos
Isako, ¿que tal la fiesta del otro día?… ¡¡¡VIVA TODAS LAS ABUELAS!!!
PabloNetrix, es mejor decir explicando xyz a mi abuela que decir para Dummies, torpes o novatos… es menos agresivo y el mensaje es el mismo. 🙂
¡Que viva la tecnología!
Muchas gracias de parte de todos los «abuelos» que no entendíamos este tema del todo. Felicidades por el artículo.
Muchas gracias MiguelSM, yo también soy abuelo, aunque al contrario que la propia vida, según vamos aprendiendo, vamos siendo algo más jóvenes.
Luis Enrique, se eso se trata exactamente, de crear inquietud (en el buen sentido claro). 😉
A menudo me preguntan sobre que libros y documento son interesantes a la hora de documentarse y aprender
Hola Jorge,
Alguien sabe alguna solución completamente OSS para gestión de proyectos (basada en SCRUM por ejemplo)?
Saludos.
Por OSS entiendo Open Source Software (espero no equivocarme), si es así, ahora mismo no caigo en una solución adecuada de ese tipo para gestionar proyectos… y menos aún basados en Scrum.
Anonimoatacante, cada uno de nosotros somos o nos debemos sentir abuelos y abuelas, y cada día aprendemos algo nuevo siéndolo. Nuestra película del día a día es siempre la película de nuestros abuelos y abuelas, jamás nadie se acuesta por mucha experiencia que tenga o sea muy abuelo o abuela, sin aprender algo nuevo. 🙂
Muy bueno el articulo, gracias.
Una de las ventajas de tener como compañero a Rodrigo Corral , un verdadero fuera de serie en el desarrollo
Anonimoatacante,
Si tu no recuerdas ninguno seguro que nadie los recuerda si los hay. Una lástima la verdad o quizas una oportunidad de realizar un nuevo proyecto, quien sabe.
Creo que no soy tan anóminmo porque en google salgo un monton… jejeje Y si, muchos días siento como un abuelo pero de forma literal con achaques y todo.
PD: evelardiez aka Emilio Velardiez
http://elbruno.com/blogs/evelardiez/default.aspx
Muy buen artículo, había oido de SCRUM, pero no me tome la molestia de revisarlo, sin embargo, ahora tengo una noción mas clara, eso me ayudará a ingresar en SCRUM y dejar otras metodologías que trataba de usar y que eran mas complicadas por ser pesadas o poco documentadas.
Saludos.
Que os parece esta visión del desarrollo del software, cuando menos un poco diferente a la visión de este peazo post:
http://msdnlive.net/blogs/mmav/archive/2007/05/14/mi-scrum-personal.aspx
PingBack desde http://hanzcocchi.net/entendiendo-la-metodologa-scrum/
PingBack desde http://legnita.wordpress.com/2007/05/28/explicando-scrum-a-su-abuela/
PingBack desde http://www.jorgetome.info/mis-bookmarks-en-delicious-del-29-de-may-de-2007.html
que articulo tan bueno, yo y mi abuela te lo agradecemos jejeje
en serio muy ilustrativo gracias
Muchas gracias giox y a todo el mundo por la buena acogida de este artículo y los comentarios recibidos.
La idea era la de hacer entender lo que es y significa SCRUM de una forma clara y pedagójica.
Me da la impresión de que lo he logrado o al menos me he acercado bastante a hacerlo bien, y sin duda esto me ha animado a hacer otro tipo de artículos de este tipo (en mente tengo algún proyecto).
Un saludo y muchas gracias por todos los comentarios y postbacks del artículo ya que me ayudan a mejorar y a saber si voy por el buen camino o no.
Juer Jorge me ha venido tu explicación de perlas para entender en que se basa esta metodología.
Gracias
Hola Jorge, de veras que muy bueno tu articulo, hasta hace relativamente poco me enseñaron en mi centro de estudios un poco de Scrum, pero definitivamente creo que el profesor debio leer primero tu articulo antes de ir a clases…Muy conciso, ilustrativo e interesante…Saludos y congratulaciones…!
Hola, me ha interesado tu artículo, ya que como no hago desarrollo de software, que sí de proyectos, podría ser la abuela.
Una idea de mejora, que nos ayudaria a todos los no enetendidos, traducir los perfiles a perfiles propios en España, i los conceptos de las acciones a coneptos castellanos (aún que tengamos que inventar alguna palabra), cre que nos ayudaría a los abuelos y abuelas de este país, que somos muchos
Muy bueno, soy certificado en scrum en EEUU y me parecio excelente.
felicitaciones!!
Aprovecho que eres certificado en Scrum para hacerte un par de preguntas:
1. ¿se considera Scrum una metodología? Escuché que sólo se le considera un marco de trabajo.
2. ¿Al desarrollar un software se requiere el uso adicional de una metodología de desarrollo (como Métrica 3 o RUP)?
Gracias de antemano por tu respuesta.
En mi modesta opinión, uno de los aspectos más complicados en el desarrollo del Software, es saber decir
Jajaja… Excelente el cuento… veo que te las ingeniaste para trasmitirnos el concepto un poco complejo, de lo que es el SCRUM, a personas como yo… que no sabemos el significado de esa palabra. En varias ocasiones observe artículos del EL BRUNO hablando de SCRUM y le huía, pensando siempre que loquera le estará pasando por la mente a Bruno Capuano.
Para mi, lo importe de este articulo, no es alardear del conocimiento que tienes y que una elite de desarrolladores te felicite por lo bueno del articulo, sino que personas como yo – simples mortales desarrolladores – entiendan el significado de la metodología SCRUM.
Me hiciste recordar en una oportunidad que asiste a una conferencia de webservice – para el 2002 aproximadamente – el orador de entonces fue Manuel Méndez, este caballero expuso esta idea tan clara y simple que hasta el portero que limpiaba la sala de cine, entendió de que se trataba este asunto.
Manuel Méndez – Director regional de Microsoft Venezuela, coordinador de los MVP.
Saludos de nuevo y felicitaciones por el buen articulo …
PingBack desde Una de Scrum » Presión Blogosférica
Jajaja me parece que una persona que no sabe nada del tema no comprenderia tanta terminologia, mucho menos mi abuela jajaja pero bien por la explicacion
Necesitaba ver de qué iba esto de SCRUM y no me quedaba del todo claro; pero ha sido visitar este artículo e iluminarme…
Muchas gracias.
Apenas estoy investigando mas sobre SCRUM y este articulo es justo lo que necesitaba para aterrizar varias ideas y conceptos que tenia en base a lo que me habia contado, excelente articulo, realmente me alienta a tratar de implantar esta metodologia en la empresa donde laboro.
Si alguien tiene experiencia manejando proyectos con la propuesta PMI y SCRUM seria excelente que aporte algun comentario, sobre todo para saber cuales son pros y contras que tiene identificados.
Saludos y otra vez felicidades por el excelente trabajo.
CJATM
Gracias a todos, no sabia lo que era esto pero me parece muy interesante y la explicacion es muuuuy buena. Intentare aplicarlo a alguno de mis proyectos personales para practicarlo. De nuevo gracias ayoooooo!!!!
excelente articulo
Hoy tuve q exponer un seminario sobbre el Tema,
gracias, me sirvio mucho de ayuda tu articulio..
PingBack desde h@nz …el Geek » Blog Archive » Libro gratuito “Flexibilidad con SCRUM”
Me parecio muy interesante el articulo, para entender a que se refiere esta metodología, pero como soy nueva en esto de desarrollo agil, estuve investigando respecto a otras metodologías similares, entre las que encontre a MIDAS,XP y otras que tienen relacion, pero realmente quisiera ver algun ejemplo practico de esta nueva metodologia y determinar si es 100% aplicable en mi lugar de trabajo, si me puedes ayudar en este tema, de agradeceria mucho, saludos
Hola Caterine,
mi sugerencia es leer el siguiente documento (en inglés) que te ayudará a tener una visión más práctica de Scrum en casos reales:
http://www.infoq.com/resource/minibooks/scrum-xp-from-the-trenches/en/pdf/ScrumAndXpFromTheTrenchesonline07-31.pdf
Espero que este documento PDF te ayude.
Un saludo,
Jorge
PingBack desde Cosas que hacen que Scrum funcione » Presión Blogosférica
He conocido Scrum desde hace un tiempo ya. Y leido bastante sobre el tema, pero es la primera vez que veo un explicación tan «sencilla y completa» a la vez de Scrum.
Muy bueno y muy bien explicado. Tu abuela estará orgullosa 😉
Te diré que en mi empresa se está usando esta guía como la mejor referencia para entender scrum.
Un saludo y gracias!!!
Muchas gracias Carlos y resto de personas que han agregado su comentario aquí.
En lo personal, me alegro mucho de la buena crítica recibida y de haber hecho algo que sirva a la gente y empresas.
Ya sabéis que cuando las cosas no se hacen bien se reciben tirones de orejas, pero que también a todo el mundo le gusta recibir buenos comentarios cuando se hace algo que gusta o que se ve con buenos ojos.
Un saludo y gracias a todos por vuestros comentarios sobre esta entrada. 🙂
Es un excelente material, para personas inexperta.
en mi caso fue de gran utilidad para exponer el tema.
Hola!!!
Muy buen articulo!!!! solo tengo una pregunta con respecto a un sprint en la etapa de sprint backlog, tu mencionas que no si hace observaciones o modificaciones al sprint estas no pueden afectar al sprint y que dicas observaciones se deben considerar como una tarea mas en el product backlog, la pregunta es, si las observaciones o modificaciones que se hacen son demasiado fuertes que vemos que el sprint en el planteamiento en el que se encuenta una vez terminado no servira de nada, se puede truncar el sprint y replantearlo???
Gracias por el tiempo que tomas en leer y responder esta pregunta.
Saludos !!! =D
Hola Yaca,
te comento para aclarar porque esta pregunta que haces es muy frecuente y normal.
Cuando se inicia un Sprint, nada debe distraer al Sprint. Si surgen cosas que olvidamos meter en el Sprint en curso o aspectos que nos hemos dado cuenta que deberíamos haber modificado, todo eso, lo deberemos dejar para otro Sprint, y para nada deberemos detener el actual Sprint.
Sin embargo, el «no» no es absoluto, ya que en el caso extremo de que detectemos una contingencia (nunca me gusta llamarlo problema sino contingencia) que haga lógico detener el Sprint, podríamos hacerlo, pero si hablo de que «nunca» debe ser detenido es porque lo que quiero indicar es que no debemos tomar por costumbre esa acción. Sólo deberíamos realizar una parada en un Sprint porque no hay más remedio o porque es obligatorio o necesario.
Tampoco vamos a hacer un Sprint por ejemplo, que sepamos que está mal de raiz y que sepamos a ciencia cierta que no va a servir para absolutamente nada.
Es muy raro que esto ocurra y por lo general, cualquier cosa que se haga sirve para algo, pero en casos extremos, por supuesto que podemos detener el Sprint en curso, pero es algo que repito, debemos evitar hacer. Debería ser algo excepcional o extraordinario, y por lo general, nunca debería suceder.
Espero que estas apreciaciones te sirvan.
Un saludo y gracias por el feedback y la pregunta. 🙂
Hola, tengo una pequeña duda.
Estoy hasta ahora empezando en esto de la gestion de proyectos, pues resulta que en unos dias tengo que hacer una propuesta para un proyecto bastante bueno.
Mi pregunta es, esta metodologia para un grupo de 3 personas es recomendable? Es decir, podria ser una misma persona (yo) Product Owner y Scrum Master a la vez? quedando las otras dos como Scrum Team?.
Saludos, Gracias
Genial la explicacion
como a tu abuela me quedo clarisimo el procedimiento basico, como para implementarlo en mi trabajo
se agradece
Saludos
Hola… la verdad yo andaba buscando una metodolgía por investigacio de la universidad, mas específico lo que es XP, sin embargo navegando me encontré con este concepto de Scrum, y ve vi en la tarea de investigar y llege aqui, y la verdad si explicaramos todos tipo de cosas pensando en las abuelitas creo que todo el mundo entedería de una manera excelente.. Gracias de nuevo por la explicación.
Gracias por la explicación, vamos a usar por utilizar esta metodología en nuestro proyecto de fin de carrera, nos aprece lo más adecuado 😀
Buen artículo Jorge, creo que es un buen «fast food» recomendable para todos los que empezamos a conocer Scrum, ahora si puedo navegar por los «n» artículos existentes. Gracias.
Jorge
Excelente articulo, muy bien explicado, estoy empezando en creación de la función de IT Quality Assurance y estaba buscando información para mi propuesta del enfoque y me encontré con esta metodología que me parece muy interesante, tengo algunas preguntas algunas surgidas de la lectura del foro y otras sobre SCRM y te agradecería mucho si me puedes ayudar:
– SCRUM es aplicable a una empresa que su rubro no es desarrollo de software pero que si tiene proyectos de desarrollo sobre sus aplicaciones internas?
– SCRUM es evaluable/compatible con herramientas como CobiT y estándares como ITIL o ISO?
– En el caso de tener que abortar un SPRINT igual se debería hacer el SPRINT RETROSPECTIVE?
– Que es un TFS?
Muchas gracias de antemano
Hola Jorge.
Un saludo y felicitaciones por el articulo.
Una consulta, como queda reflejado mis actividades a desarrollar ( Sprint Blacklog ) en mi GANTT, asi como tambien como reflejo las respectivas interaciones que surjan?.
¿Como dar una fecha final exacta de fin del proyecto al cliente?
Saludos y Gracias
MZR
PingBack desde Libro gratuito en espa??ol sobre Scrum y metodologias agiles « Tecno Week
PingBack desde Introducci??n a Scrum
Saludos
Tenia un pregunta, sobre el el desarrollo de software en si, posee fases especificas en el sprint (osea cuando se desarrolla??), ya que no dice que se debe documentar, pero mi duda es que si posee algunos pasos en el sprint especificos.
Como lo es OMT++ que tiene los casos de uso, operaciones, tareas, diagrama estado, y todo lo que sigue en la metodologia.
de ante mano gracias
Hola! buscando en el google algun resumen de scrum para rendir un parcial de ing de Software encontre este articulo y me sirvio mucho… asi que dejo mis felicitaciones y agradecimientos por el aporte 😉
saludos desde Mendoza, Argentina
Hola apañero!
Cuanto tiempo!!!
Pues justo ayer terminé un curso de Scrum que nos están dando (ahora estoy en un equipo de desarrollo de videojuegos, en otra empresa…) y buscando y buscando información por ahí… el destino ha querido que te encontrara!!!
En fín, que MUY buen artículo, como siempre muy didácticamente explicado … y un placer leerte 🙂
salu2,
Excelente este articulo, ya me habian explicado esta metodología y no lo habia entendido pero con este articulo de una. Ahora solo me queda una duda que debo resolver rapidamente.
Que herramientas (software) gratuitas existen para trabajar esta metodología?
Saludos desde Medellín Colombia
En México muchas empresas de software medianas o pequeñas he visto que no implementan procesos de desarrollo, metodologías o por lo menos una práctica ajustada a sus necesidades aún cuando esta no sea formal… Scrum puede ser una buena opción para todos ellos.
Me ha encantado; soy tecnica en calidad y la verdad… tiraría todo lo que he hecho hasta ahora… hay como un vicio por procedimentar y documentar todo… (SPICE) al punto de que dentro de nada no podremos movernos sin tener un proceso que nos indique como…
Pregunta: donde puedo encontrar más info, (pero en castellano por favor!) de este metodo, ejemplos graficos o reales, etc?????
SAludos y enhorabuena por tu articulo! STella
PingBack desde Explicando Scrum a mi abuela > Pablo Azorin
No intento entrar en el terreno personal (no conozco a tu abuela) pero, ¿podrías aplicar/explicar Scrum a tu pareja e hijos? Me refiero al entorno familiar, a cuando sales del trabajo y quieres disfrutar de tu tiempo. ¡Aunque sea en tono jocoso!
Me refiero a planificar las labores diarias, implicando a 2(madre-padre), 3(m-p-hijo), o más personas y ver sobre quién recae el trabajo sucio y cómo pueden ayudar el resto de personas.
Y lo mismo a los hijos, supongo que es una forma de poner orden, atender a las tareas, al estudio, y al tiempo de ocio.
Tómalo como un experimiento social, al estilo de la supernany de la tele, pero intentando (im)poner orden y disciplina.
Sería gracioso al menos …
Ayer mi comentario quedó un poco raro.
Quería que dieras tu visión de como un freelance puede integrar scrum en sus rutinas diarias, así como en pequeñas sociedades de 2 amigos-socios, que puntualmente pueden contratar a una tercera persona.
De ahí extraer la idea de emular ese entorno, y de hacerlo con la família (por hacerlo más ameno) donde exiten 2 miembros con igual capacidad de decisión y carga de trabajo, y sobre los que recaen los roles de Jefe de Producto / Scrum Master / Scrum / Currito.
La parte importante que tendría sentido es la pila de producto, planificación /retrospectiva de sprints, así como las demos de sprint.
¿Qué te parece? Sería un scrum personalizado a estas condiciones, o un micro-scrum.
Bye
Muy buen resumen.
Estoy preparando un paper sobre nuevas metodologías de gestion de proyectos y necesitaría contar con algunos elementos adicionales:
– Que entidades o empresas utilizan habitualmente scrum?
– Cuales son los parametros para considerar que un proyecto ha sido exitoso?
– Algunas estadísticas, como por ejemplo, cuantas entidades o proyectos utilizan scrum, cuantos proyectos ha finalizado exitosamente.
Jorge, la verdad buenisimo tu articulo sobre SCRUM. Te cuento un poco, soy estudiante de ingeniería en software, en Montevideo, Uruguay, y en una de las materias me pidieron hacer un software basico en JAVA, para llevar la gestion de un proyecto basado en esta metodolgia. Me gustaría si no es de inconveniencia, si podes darme algunos «trips» consejos para hacerlo.
Jorge muchisimas gracias, y cualquier cosa a las ordenes desde Uruguay.
PingBack desde SW Saber » Blog Archive » Scrum
Hola,
Muy bueno el tutorial, y el enfoque genial!
Por si os interesa os dejo un enlace a un tutorial sobre SCRUM:
http://swsaber.com/scrum/
Muchas gracias por el enlace Emilio. 🙂
Genial, muchas gracias por explicarme lo que es Scrum, esta es una ventana pero el paisaje esta mas alla de solo la vision y los sentidos.
PingBack desde Selecci??n de Noticias y Blogs [17] « Raul Barral Tamayo’s Alpha Blog
Hola,
Un grupo de personas hemos creado una base de conocimientos gratuita de Scrum en español: http://www.proyectosagiles.org. Está elaborada de manera que esta gestión ágil de proyectos pueda ser utilizada en diferentes departamentos y negocios (no sólo el de desarrollo de software) para así comunicar mejor a los «decisions makers» que existe una alternativa a la gestión clásica de proyectos. Os invitamos a contribuir con vuestras experiencias.
Salud,
Xavier
me ha encantado!
aunque creo que scrum no tiene nada que ver con la arquitectura de software. lo digo por el tag.
Hola a,
efectivamente no tiene que ver directamente con arquitectura, pero no puse ninguna etiqueta de metodología, gestión de proyectos, scrum ni nada por el estilo, y cuando lo escribí decidí englobarlo aquí, y aquí se ha quedado.
Me alegro de que te haya encantado. 🙂
Muy bueno, estoy llamando ahora mismo a contarle a mi abuela, y de paso a sus amigas…
Jajaja, es gracioso, como tu abuela en la 8va pregunta pudo memorizar Product Backlog y pronunciarlo!!!!!!!, jajaja
muy buena esplicacion para darla en el inicio del proyecto,la aplico a warroom empresarial ,donde me doy cuenta de los avances por funcion,con esto hasta mi abuela trabajaria con migo…
Excelente!!!
Muchas gracias por tomarteel tiempo para redactar este tipo de documentación, es muy util y clara la forma que tienes de expresarte
Muchas gracias!!!!!
estoy viendo una materia que se llama auditoria de sistemas de información! y estoy investigando sobre los agiles… y me fui por el scrum, me parece excelente lo que publicas y me encanto como llevas las cosas, ahh y mucho este articulo… saludos… siguele aportando conocimiento a la vida….
estoy viendo una materia que se llama auditoria de sistemas de información! y estoy investigando sobre los agiles… y me fui por el scrum, me parece excelente lo que publicas y me encanto como llevas las cosas, ahh y mucho este articulo… saludos… siguele aportando conocimiento a la vida….
Me parece una explicacion muy buena
=3 Yo no sbaía que era, me hicieron investigarlo y creo que es una explicación bastante sencilla que te hace entenderlo.
Saluditos.
Interesante, me lo chute todo de golpe, habia unas cosillas que no sabia de la metodología, las pondré en práctica cuanto antes. Gracias por dedicar un poco de tiempo para escribir este texto, seguro nos es útil a varios.
Lo bueno, si breve, dos veces bueno.
Y este pequeño articulo es muy, muy bueno.
Me uno a las felicitaciones de este artículo, lo he ya recomendado como parte del training para comenzar a utilizar SCRUM en nuestros proyectos.
Gracias!
¿No era Einstein quien decía que no entiendes algo realmente hasta que eres capaz de explicárselo a tu abuela? Enhorabuena, ha quedado muy claro. 🙂
Hola, en la empresa para la que trabajo estamos investigando sobre Scrum porque queremos implementar esta metodología. Tenemos una duda respecto al rol de Product Owner, ese rol lo cubre un empleado del Cliente? y Cuál es el perfil de la persona que cumple este rol?
Desde ya agradezco la infomación que nos puedas facilitar
Saludos
ola queria hacerles una consulta tienen algun programa para trabajar de forma ordenada con el metodo scrum, ya sea plantillas para el product baccklog y cosas asi? de antemano gracias
Idem, Analista intentando organizar lluvia de proyectos…
Sabado por la tarde intentando encontrar algo util acerca de scrum, y he aquí este material excelente!!!
Felicitaciones desde la Patagonia Argentia 🙂
Jorge,
Enviame el curriculum de tu abuela
Que memoria para acordarte de toda la conversación! ja.
Muy buen articulo!
jorge, como se puede costear (tiempo y dinero) un proyecto con SCRUM, si es suceptible a cambios ?
realmente muy bien hecho este articulo, tan solo con leerlo ya entendi lo que es scrum, es bueno no tener la necesidad de releer este y ademas otros articulos, realmente felicitaciones y gracias nuevamente 🙂
@Juan Carlos Madrid,
Scrum acepta todas las variantes posibles, ya sea pactar un precio cerrado previo (que obligará a marcar todas las funcionalidades y requisitos previamente), o a trabajar por horas, algo que debe ser pactado con el cliente previamente (pero que le servirá al cliente para ir viendo la evolución del proyecto en cada Sprint e ir implicándose en él, solicitando incluso más funcionalidades si llegara el caso).
En el caso de marcar tiempo/coste de forma previa, no hay más narices en mi opinión que marcar previamente todos los requerimientos, encajarlos sin variantes perdiendo la filosofía Scrum, y empezar a realizarlos uno detrás del otro. El problema es que Scrum no está pensado para encajar un proyecto en un marco de tiempo (recordemos las palabras ágil, flexible, adaptable).
Si te refieres a tiempo/dinero en cuanto a la flexibilidad y el hecho de comentarle al cliente «cuanto» le va a costar, la mejor forma es pensar en el marco de pago por horas que se habrá negociado con el cliente previamente, marcar una estimación generalista y pensar en la confianza cliente/equipo de desarrollo. Lo bueno es que el propio cliente verá en poco tiempo si la gente que está llevando a cabo el proyecto está dirigiéndose en el camino que el propio cliente. Si es así, la confianza crecerá exponencialmente y eso se notará y mucho en las dos partes con el avance del proyecto (los principios sobre todo cuando el cliente y el equipo que desarrolla empiezan a trabajar juntos por primera vez es o suele ser normal).
Un proyecto susceptible a cambios es por naturaleza flexible, y por lo tanto, el cliente debe saberlo previamente. Se cara al cliente, esa flexibilidad no le va a impedir incorporar funcionalidades al desarrollo, sino todo lo contrario… pagándolas claro está.
Los requisitos y el cambio de estos requisitos tendrán siempre un impacto directo con los tiempos y costes. Eso debe quedar claro, y Scrum que es ágil no se libra de ello, sino todo lo contrario. Quedando claros estos principios, los clientes que tienen temor en utilizar Scrum, se dan cuenta después de que lo han aplicado de que es una herramienta que les da más tranquilidad que el propio proyecto cerrado. Créeme.
La idea es que el cliente pague por lo que obtiene, y que lo que obtiene sea lo que pague (lo que invierte). Ni más ni menos. 🙂
Ayer estuve en la casa de mi abuela tomando el té. Entre muchas conversaciones sobre recuerdos del pasado
Buenos dias, soy estudiante de informatica de la UCLA Venezuela, y me gustaria colocar una breve introduccion a SCRUM, y luego colocar este enlace para que se pueda entender mejor, muy buen trabajo a la hora de explicar esta metodologia, si me puedes facilitar mas material o donde conseguirlo ya que estoy estudiando para el examen de arquitectura de la 5ta estrella, se que la internet tiene todo, pero me gustaria que un profesional me orientara.
Espero tu resp para armar mi entrada en mi blog.
http://zonainformatica.wordpress.com
Mira tio,
buena es y como nunca había visto argumentación,
si además nos hace ganar en la que participamos licitación,
mi cariño tendrás y posible (manda el jefe) participación,
con cariño te lo dice este .. on,
Y sin haberlo planeado me ha salido un pareado -:)
Hola Jorge, considero excesivo los treinta minutos máximo que indicas para las reuniones diarias (Daily Scrum Meeting) y creo que sería mejor emplear 15 minutos como máximo, y al mismo tiempo resolver todo lo que pudiese dilatar la reunión, tal como lo sugiere el siguiente artículo: [http://martinfowler.com/articles/itsNotJustStandingUp.html]
También sería bueno mencionar que los elementos que component el Product Backlog, si bien podrían ser «tareas», usualmente se desglosan en una o más tareas en el Sprint Backlog, por lo cuál resulta páctico expresarlos en términos de «historias de usuario», prestándonos el término de XP [http://www.mountaingoatsoftware.com/product-backlog].
Saludos.
Hola Johans,
lo primero de todo, muchas gracias por compartir tus puntos de vista.
Yo no he dicho nunca que las reuniones del Daily Scrum Meeting deben ser de 30 minutos, sino de entre 15 y 30 minutos (creo que el gráfico no deja dudas).
Pero entiende ese valor como un valor estimativo.
Tú, ni yo, ni nadie, puede hacer reuniones mirando el tiempo del reloj. si lo hacemos, correremos el riesgo de fracasar en las reuniones.
Habrá reuniones que a lo mejor nos lleve 5 minutos, y otras que nos lleve 20, y otras a lo mejor, incluso 45 minutos.
Las reuniones del Daily scrum Meeting tienen que ser operativas, rápidas, ágiles, ceñirse a la agenda marcada y resolutivas.
Respecto a tu segunda afirmación, nada que comentar. Me parece bien lo que indicas y está bien que lo comentes por si no quedaba claro, pero creo que es evidente que una tarea global puede englobar diferentes subtareas.
Hacer una casa no es una tarea en sí, pero lleva consigo un montón de tareas más, por ejemplo, poner ventanas.
Y poner ventanas, lleva inherente otro conjunto de subtareas que también se pueden desglosar.
Evidentemente, todo en su conjunto son tareas, pero algunas de ellas forman parte de un elemento superior que una vez agrupados todos, formarán parte de la solución.
Ya que estamos enfrascados en el desarrollo del software, imaginemos todo como un conjunto de nodos y subnodos al estilo TreeView o árbol, donde hay un nodo padre y el resto de nodos hijos, y así sucesivamente, un nodo hijo puede ser a su vez, padre de otros tantos hijos.
Muchas gracias por comentar.
Un saludo y Feliz 2010 a todo el mundo,
Jorge
Estupendo resumen!. Sólo hay un concepto que no me ha quedado muy claro. ¿Puedes poner algún ejemplo de qué se haría en el Sprint Retrospective?
Gracias.
******
Hola Jorge…
antes que nada dejame felicitarte por este artículo tan bueno. Soy estudiante de ing en sistemas y nos dejaron una tarea acerca de lo que es SCRUM leí algunos otros artículos pero ninguno me había aclarado mis dudas debido a que soy nueva en esto y muchos términos no los entendía. Lo veía solo como una tarea pero ahora estoy mucho más interesada en todo esto. muy interesante, gracias.
Felicitaciones tambien por todos los buenos comentarios que has tenido..
saludos y gracias por esta buena explicación.
*********
Creo en esta medología, aunque veo difícil que lo entienda mi abuela 🙂
es necesaria una iteratividad en tareas,
un control en equipo
y saber en cada momento qué hacemos, bien y mal de forma controlada.
Estableciendo además, para cada producto/requerimiento el inicio y fin del trabajo, para cada uno de los miembros del equipo.
Scrum lo tiene
Gracias por la explicación.
La verdad es que es muy muy buena.
tengo una duda…estoi en busca de un frameword para hacer testing…podria usar scrum para la fase de testing del desarrollo de software.
saludos
Jeje, probre de tu abuelita. No mentira. Muy buen articulo. Felicitaciones…
No trago con lo de la abuela… que tipo de abuela pregunta eso, por el amor de dios
Expectacular… muy buena explicacion 🙂 gracias por hacerla y colgarla 🙂
Muchas gracias por tu aporte a la comunidad de desarrolladores de software que dia a dia tratamos de evitar que el caos nos domine y que las cosas se salgan de control por cuestiones de tiempo.
Muchas gracias una vez más a todos/as por vuestras felicitaciones.
El texto lleva ya tres años escrito y lo cierto es que sigue vigente y actualizado como el primer día, algo que hace de Scrum una metodología formal.
Me cuesta mucho responder todas las dudas y preguntas que planteais, perdón por adelantado a quien no le haya respondido.
Ignacio, Scrum se puede usar para las pruebas o Test sin problemas. Es más, las pruebas unitarias deberían escribirse al mismo tiempo que la funcionalidad. Si no se ha hecho de esa manera, se deberá hacer ahora, y Scrum es una buena metodología para llevarlo a cabo, más aún que son pruebas sobre algo existente, por lo que dimensionar el Product Backlog y los Sprints es todavía muchísimo más fácil (más que estimar la creación de las pruebas unitarias al mismo tiempo que se avanza con el desarrollo).
Suerte con ello.
Un saludo,
Jorge
Excelente artículo. Felicidades
Excelente historia, mejor no pudo quedar explicado..Muchas gracias
Buenas,
Me parece bien que toquen este tema de metodologìa Scrum, Tengo una consulta para uds.
Estamos tratando de implementar esta metodología en mi lugar de trabajo, pero sucede que tenemos información de como tomar el punto de las pruebas en esta metodología, especialmente las PRUEBAS DE INTEGRACIÓN.
a ver si alguien me puede dar esa información, ya que he buscado en internet y no he encontrado nada.
Saludos y felicitaciones.
Excelente jajjaja aunque no creo que tu abuelita te haya preguntado todo eso ajja y de serlo asi mandale un abrazo de mi parte a tu abuelita y de Muchas pero muchas pero muchas gracias por esa historia tan bonita
bye
Muy buena y amena explicación, me interesé de principio a fin y lo entendí TODO, lo cual es muy bueno, porque leía en otros lados pero no entendía lo que era SCRUM con claridad…
Gracias.
Como no andamos con mucho tiempo, vamos a hacer breves: ScrumPeak , es una Aplicación Web para
Lo de que queda prohibida la reproducción parcial o total de este artículo sin la correspondiente autorización involucra también la autorización te tu abuela?
Evidentemente JLopez. 🙂
Excelente explicación, muy clara y comprendible.
Muchas gracias por compartirlo.
Saludos.
Muchas gracias por tus comentarios Jesús. 🙂
Quede encantado con la explicación de la metodología, pero aun me quedo un a duda sobre los entregables que se deberian realizar para entregas de proyectos con esta metodología
quete impactado como lo has detallado he visto un infinidad de documentos acerca de scrum soy novato en este asunto pero tu explicacion del tema es excelente un gran servicio podrias poner un ejemplo con todas las herramientas usadas en el tema si no fuese mucha molestia con plantillas un saludo y un abrazo fuerte desde peru….
Excelente explicación!! muy ameno!!
Muy Buena Explicación!!, he aclarado muchas dudas y me ha servido muchisimo aunque me surge una duda mas ya que soy novata en este tema… cuando se hace Sprint Retrospective pueden surgir nuevas tareas o ajustes que alimentaran el Product Backlog.. Está claro.. Pero si hay ajustes o tareas adicionales que surgen por parte del cliente también se incluirían en le Product Backlog o estos ajustes o solicitudes tiene otro manejo?.. Mientras no se salga de los especificado…Muchas gracias
Hola jorgue,te felicito por esta explicacion,eres lo maximo!!!
Queria comentarte que estoy haciendo mi tesis con un compañero y vamos aplicar scrum para el proyecto,como te daras cuenta seremos dos personas y haremos de scrum master ,Product Owner, Scrum Team ,crees que se pueda llevar bien esto?.
Otra cosa es que para elaborar el ganttProject lo podemos separar por acciones verdad?
Hola jorgue,te felicito por esta explicacion,eres lo maximo!!!
Queria comentarte que estoy haciendo mi tesis con un compañero y vamos aplicar scrum para el proyecto,como te daras cuenta seremos dos personas y haremos de scrum master ,Product Owner, Scrum Team ,crees que se pueda llevar bien esto?.
Otra cosa es que para elaborar el ganttProject lo podemos separar por acciones verdad?
Muy bueno en realidad… Cuidado con la Abuela jejeje muy buen articulo gracias por compartirlo…
El articulo es muy bueno creo que me canse de leer los comentarios. La verdad es que soy mas que nueva en esto y en mi trabajo me están pidiendo que aplique esta metodología mas sin embargo ni ellos saben de que se trata, con tu articulo los términos me quedaron mas claros que las miles de lecturas que llevo mas sin embargo el llevarlo a la practica se me hace un poco complicado en especial a la hora que quieren que lo aplique a un sistema ya desarrollado pero mal diseñado empezar a estandarizar todo y demás pero no encuentro un ejemplo que me ayude en algo así sabrás de algo? Bueno de antemano gracias, y espero leerte mas…
Por favor lee este post…al final quien es el autor??
http://www.christiamalvarado.com/marketing/agile-product-management-con-scrum/
muy buena explicacion, estoy estudiando ingenieria en informatica, y tengo un debate de las diferentes metodologias para el desarrollo del software esto me servira mucho..
Muy buen planteamiento del tema, me gustaría utilizarlos con mis alumnos, soy docente a nivel universitario en pregrado y postgrado en la Universidad Nacional Experimental de Guayana, UNEG en Venezuela. Abrazos cordiales
Muchas gracias por vuestros últimos comentarios.
Es una satisfacción enorme observar que 4 años después de escribir esto, sigue siendo actualidad y ayuda a mucha gente. Es el sumum, no quiero más. 🙂
@Marco, ¡por supuesto!.
Haz uso de esta información con tus alumnos, pero indica por favor a tus alumnos de donde se obtuvo. Con eso me conformo. 🙂
Un saludo a todos.
Jorge Serrano
me sirvió muy mucho la explicación! me parece que con scrum (…con las metodologías ágiles en realidad)hemos evolucionado en la manera de desarrollar software. Esto es un impulso tremendo, sin duda estamos en el futuro.
Si había algo que me frenaba para iniciar nuevos proyectos, era la documentación y el tratamiento de los requisitos.
Te cuento, estudiante de Ingeniería, por el momento no desarrollo de manera profesional.
Hola marbal.
Me alegro de que te sirva esta explicación.
Sobre si es el futuro o no, recuerda que ni Scrum es nuevo ni Scrum es el elixir de la vida, simplemente una metodología, y como tal, no es ni la mejor ni la única, y evidentemente no sirve para todo el mundo y organizaciones.
En el mundo profesional, las cosas no siempre son como uno las sueña, sino muy diferentes, y en muchas ocasiones, los plazos no existen porque todo es para ayer. Ahora bien, tratar de utilizar una metodología con organizaciones donde la planificación es ayer o ya mismo, no es recomendable.
Un saludo.
Jorge
Y casi 10 años después de que esto fue escrito,
sigue ayudando a personas como yo a entender lo basico del SCRUM
Saludos!
y Gracias!
[…] Si quieres saber más sobre SCRUM, puedes leer este entretenido artículo: Explicando Scrum a mi abuela […]
[…] Si quieres saber más sobre SCRUM y su funcionamiento, puedes leer este entretenido artículo: Explicando Scrum a mi abuela […]
Estoy iniciando con scrum sin embargo me gustaria conocer si podría ser aplicable a un proyecto que llega hasta un arquitectura de negocio, no llega a desarrollo y como esta metodologia se visuliza con pmbook
quisiera conocer si puedo usar scrum con pmbook y si scrum me sirve para proyectos que no llegar a la fase de desarrollo
[…] No es el objetivo de este artículo definir Scrum, pero para aquellos que queráis tener nociones básicas sobre el tema, os recomiendo la lectura de este divertido post: “Explicando Scrum a mi abuela” […]
[…] No es el objetivo de este artículo definir Scrum, pero para aquellos que queráis tener nociones básicas sobre el tema, os recomiendo la lectura de este divertido post: “Explicando Scrum a mi abuela” […]
Holas! pues quería copiar y pegar un pequeño fragmento (4 o 5 líneas como mucho) para publicarlo en Facebook junto con el enlace al artículo… no sé si esto sea posible…
Mi Facebook es http://facebook.soporteti.net
3 de Noviembre de 2017. Tu explicación sigue ayudando a gente, como yo.
Muchas gracias por compartir tu momento de inspiración de mayo de 2007
Hola, quisiera saber si tu abuela está disponible para llevar el scrum de nuestro proyecto.. el «jefecillo» que tengo, encima que le comentamos sobre lo de scrum (más bien que al menos nos escriba los requisitos), pues nada.. ni requisitos (solo una linea que le pasan a el), ni estimaciones (solo dale caña, dale candela que llevamos retraso), ni dudas (pues aun te enreda más) ni hacer un spring completo (te altera lo que te ha mandado, te pasa a otra cosa según prioridad y luego te exige porque no has acabado el anterior y porque tiene fallos).. en definitiva.. se supone que es el responsable del proyecto, pero no sabe comunicar, dirigir, explicar, permitir que seamos un equipo (pues juntarnos 2 compis para discutir sobre una cosa que hacemos en común y que no lo sabíamos, es perder el tiempo) y sobre todo, confundir, dudar de usar codeclear, refactoring, TDD etc.. y cobra y manda más que yo (sin contar que tengo alguna que otra bronca porque según el tío Bob dice: NADIE PUEDE OBLIGARTE HACER MAL EL CÓDIGO, cosa que el tipo se empeña.. le llamamos mister DRY por que su patrón de diseño favorito es «copy & paste only change the «hardcode»
Deje de leer en la primera pregunta. Lo primero que te enseñan en la certificacion es que Scrum no es una metodologia es un FRAMEWORK donde practicar las metodologias ágiles. Creo que tu abuela ya empezó mal…
https://www.scrum.org/resources/blog/scrum-no-es-una-metodologia-es-un-framework
Muchas gracias por comentar Curilla.
No pasar de la primera pregunta y opinar negativamente sobre un artículo es muy atrevido por su parte.
El artículo lleva escrito más de 10 años, por lo que los aderezos y ajustes léxicos que se hagan en este laxo de tiempo sobre Scrum pueden ser variables, así como las opiniones que queramos hacer sobre ello.
Por aquel entonces creo recordar que no existía ni certificación de Scrum de la cual por cierto, estoy completamente en desacuerdo y me parece un saca cuartos y bastante inútil.
Pero centrándonos en tus comentarios, te pongo lo que creo es la parte principal de los que comentabas:
«…Scrum no es una metodologia es un FRAMEWORK donde practicar las metodologias ágiles.»
¿Framework donde practicar las metodologías ágiles?.
¿Es Scrum «algo» para practicar?.
¿Es Scrum un Framework?.
No estamos en la escuela ni en un curso de certificación, sino en la realidad.
En el trabajo, en su aplicación, en su uso,… no en la teoría.
Me baso en mi experiencia personal y profesional durante aproximadamente 15 años utilizando esta forma de trabajar para afirmar que para mí es una metodología de trabajo.
Que los «gurús», los puristas, las empresas de certificación, organizaciones y otras personas lo llamen como quieran.
Que vienen personas diciendo que es un marco de trabajo como lo has hecho tú, lo respeto pero no lo comparto.
Que alguien saca un examen de certificación sobre Scrum y con eso se cree que sabe lo que es Scrum y que puede aplicarlo en todos los sitios de la misma forma, lo respeto pero no lo comparto.
Para mí, la mejor carta de presentación y el mejor examen de certificación es la experiencia personal, y con unos 15 años aplicando Scrum en diferentes empresas, entornos y equipos, creo que tengo bastantes argumentos (no siempre suficientes y siempre quiero aprender más) para afirmar lo que digo.
Desde mi personal punto de vista, un marco de trabajo puede ser empleado como sinónimo o no, depende del lector o de quién lo quiera explicar o cómo se quiera explicar.
Si se usa marco de trabajo como aglutinador de prácticas de metodologías ágiles, me parece bien, pero Scrum no aglutina todas las metodologías ágiles.
Es simplemente una de ellas, por lo que está fuera de ese marco de trabajo y forma parte de una metodología o forma de trabajar más.
Es un matiz que he discutido muchas veces con mucha gente que aplica Scrum.
Unos están de acuerdo conmigo y otros no.
Pero en el fondo, discutir sobre este detalle no aporta valor respecto a como usar Scrum realmente.
Es léxico carente de valor.
Lo verdaderamente importante es utilizar Scrum de forma que nos aporte valor.
Lo interesante de todo esto es que Scrum nos da la posibilidad de ajustarlo a nuestras necesidades como empresa, organización, cultura, equipo e incluso proyecto.
El que vea a Scrum como marco de trabajo y no lo vea como algo flexible no sabe usar ni usa metodologías ágiles realmente.
He usado Scrum de formas diferentes y con éxito (también ha habido fracasos porque no en todos los sitios se puede aplicar de la misma forma y en otros sitios directamente no se puede aplicar de ninguna forma).
Si fuera un framework me ogligaría a usarlo de forma rígida, lo cual paradógicamente es la antítesis de la palabra agilidad.
Si no estás de acuerdo con esto último que digo, entonces el problema es que no estamos entendiendo bien lo que significa marco de trabajo.
Pero lo realmente importante es que una metodología o Scrum en concreto esté al servicio de la empresa, de la organización, del entorno, de la cultura y del equipo, y no al revés.
Si es al revés, tarde o temprano esa metodología (o marco de trabajo si lo quieres llamar así y te sientes más a gusto) fracasará.
Mi abuela te lo habría explicado mejor sin duda.
Un saludo.
Excelente manera de explicarlo , incluso a principiantes nos ha servido de base, para introducirnos al mundo de Metodologías
Saludos, eres excelente en la redacción
Muchas gracias por comentar y por tus palabras Carolina.
Un saludo.
Jorge
Este artículo tiene más de 10 años y sigue vigente cada cosa. Para mí también es una metodología de trabajo, es una manera de organizar y desarrollar un proyecto. Gracias a tu abuela de seguro muchos aprendimos lo que es Scrum.
Muy interesante. Gracias por compartir
gracias por el aporte.
Muy bueno el artículo, lo único que he visto es algo muy común: Scrum NO es una metodología, es un marco de trabajo (framework), comentario constructivo 😉
Saludos!
Scrum NO es una metodología. Es un framework. Es la primera regla, asi que lo siento pero en la primera frase de tu articulo he dejado de leer. Si no sabes eso …
Hola Tamara
Gracias por opinar.
Un poco más arriba contesto a otra persona que opina similar a tí.
Eso sí, me gustaría decirte una cosa solamente:
Be agile
Open your mind
Estoy terminando un Taller de Project Managemente con Marco referencia Agil, y hasta hoy estaba bien enrredado. La expliación hecha en este articulo, ME DEJO TODO CLARITO.
Gracias
Felicidades por el artículo. Genial el enfoque que le has dado y la explicación queda muy clara. Lo he utilizado como recurso de lectura para los alumnos. Un saludo y enhorabuena.
Hola estimado Jorge, te saluda Cesar desde Peru, excelente articulo, muy didáctico y muy bien explicado para personas como yo que desean aprender lo que es SCRUM y como se aplica. Una consulta, por casualidad no dictas cursos de SCRUM??
Gracias.
muy buen explicación para los queremos entrar en el mundo de SCRUM