tag:blogger.com,1999:blog-2328925255230238869.comments2024-03-14T16:22:32.411+01:00Blog de un apóstol de Scrum y KanbanAlexander Menzinskyhttp://www.blogger.com/profile/05273164033669386910noreply@blogger.comBlogger424125tag:blogger.com,1999:blog-2328925255230238869.post-60357006431022517422024-02-23T00:28:28.263+01:002024-02-23T00:28:28.263+01:00He leído tu artículo y explica eficientemente el r...He leído tu artículo y explica eficientemente el rol y como define una guía de como debe aplicarse. En mi caso soy Chapter Lead en un banco y la realidad es que las tareas que debo cumplir a diario como CL, sumado a las labores de Deasarrollador me genera menor disponibilidad para desempeñar correctamente ambos roles, no tengo la misma productividad que el resto de los desarrolladores, porque mayormente estoy realizando labores del Chapter que involucran varias tareas y debo atender a 18 personas. Se ha analizado realizar modificaciones al cargo debido al doble rol que se genera, a mi en particular no me gusta y es la sensación que otros Chapters también me comparten. Gracias por leer. Tomas Gonzalezhttps://www.blogger.com/profile/13228312195886943732noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-59322496014799939572024-01-11T21:03:08.458+01:002024-01-11T21:03:08.458+01:00Hola Juan Carlos,
Tu responsabilidad como Scrum M...Hola Juan Carlos,<br /><br />Tu responsabilidad como Scrum Master es que exista un DoD y asegurarte que el equipo lo siga - básicamente no debes de permitir que se considere acabada una historia de usuario si no cumple con DoD.<br /><br />Es responsabilidad del equipo y del Product Owner definir que significa "terminado" para ambos, y son ellos los responsables de idenficar los criterios del DoD y de mantenerlos a lo largo del tiempo (si DoD varia se suele hacer en la retrospectiva).<br /><br />Si lo piensas es de sentido común, para ir a un ejemplo sencillo: solo el pintor (equipo) y el cliente (Product Owner) pueden decidir cuando cualquier pared (historia de usuario) esta pintada y acabada (por ejemplo grosor de pintura sobre la pared). El Scrum Master se asegura de que proceso a seguir se haga bien, que pintor y cliente verifiquen que la pared pintada esta acabada para ambos.<br /><br />Espero haberte ayudado,<br /><br />AlexAlexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-10029367296928952482024-01-11T20:19:46.680+01:002024-01-11T20:19:46.680+01:00Hola, se que ha pasad un buen tiempo desde que se ...Hola, se que ha pasad un buen tiempo desde que se escribió este articulo, pero pregunto, espero me puedan guiar un poco, quien es el responsable de velar por un DoD, soy nuevo como Scrum master y me dicen que esta tarea es mi deber, pero otros me dicen que no. GraciasJuan Carlos Pérezhttps://www.blogger.com/profile/17066758951314713196noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-32095656850639323022023-09-02T23:52:06.417+02:002023-09-02T23:52:06.417+02:00hreat post hreat post Olsenhttps://www.blogger.com/profile/05514851727977800109noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-11422416478832694392023-06-11T08:50:30.849+02:002023-06-11T08:50:30.849+02:00Excelente, me ayudo mucho.Excelente, me ayudo mucho.itsluis14https://www.blogger.com/profile/15972472767507771839noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-82281360000606994382023-03-22T22:28:09.995+01:002023-03-22T22:28:09.995+01:00Excelente post, me gusto saber que existe un juego...Excelente post, me gusto saber que existe un juego para simular las situaciones. <br />anteriormente habia hecho simuladores de preguntas como https://www.lumenti.com/learning/course/view.php?name=scrumgeorgehttps://www.blogger.com/profile/09290338070064554571noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-24669346430074221742023-03-09T14:47:13.243+01:002023-03-09T14:47:13.243+01:00Excelente Alexander. Muchas gracias por tu ayuda. ...Excelente Alexander. Muchas gracias por tu ayuda. Saludos.Alexander Buenohttps://www.blogger.com/profile/06934673374976153491noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-21347898029700588272023-03-08T15:59:24.492+01:002023-03-08T15:59:24.492+01:00Hola Alexander,
La clave no está en gestionar dep...Hola Alexander,<br /><br />La clave no está en gestionar dependencias, sino en identificarlas y resolverlas y comprometerse. Los que deben de hablar son los miembros implicados de ambos equipos, a veces puede ser una persona de cada equipo, a veces varias, a veces los equipos al completo. El Scrum Master solo se asegura de que ocurra y que se haya resuelto, no es parte activa.<br /><br />La pregunta que puedes hacerte es la siguiente: ¿las personas que están tratando una dependencia concreta son las que van a hacer el trabajo y tienen todo el poder de decisión para poder comprometerse?<br /><br />Espero haberte ayudado,<br /><br />AlexAlexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-56479028817438039822023-03-08T15:47:26.864+01:002023-03-08T15:47:26.864+01:00Alexander muchas gracias por tu aporte, pero me su...Alexander muchas gracias por tu aporte, pero me surge una duda, si tengo 4 equipos de 8 personas cada una, a esa reunión donde se gestionan los impedimentos debe ir el Scrum Master del equipo como tal? entendiendo que el es el responsable de gestionar los impedimentos, o debería ir todo el equipo? lo que no me queda claro es como se llega a un acuerdo con relación a las dependencias, es una conversación del equipo, es entre SM. quedo atento a tus comentarios. GraciasAlexander Buenohttps://www.blogger.com/profile/06934673374976153491noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-36995441687594716242022-11-21T10:48:43.957+01:002022-11-21T10:48:43.957+01:00Misglobos.com
¡Muy buen post y una forma diferent...<a href="https://misglobos.com/collections/lisos" rel="nofollow"> Misglobos.com </a><br />¡Muy buen post y una forma diferente de usar un globo! Es increíble la cantidad de usos que se le pueden dar a los globos, tanto para decorar fiestas de Halloween, eventos, bodas, cumpleaños, como para usarlos en juegos con niños, los cuales sirven como una gran distracción y diversión para ellos. NDhttps://www.blogger.com/profile/14477528151146256016noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-86018076605197342362022-11-16T23:35:08.683+01:002022-11-16T23:35:08.683+01:00Hola Claudio,
No estoy muy seguro de eso, los dif...Hola Claudio,<br /><br />No estoy muy seguro de eso, los diferentes navegadores "pintan" las páginas con diferencias... luego está la ejecución local como javascript. Además está la complejidad de las diferentes versiones de un navegador... aún hay empresas que utilizan IE.<br /><br />La perspectiva de este artículo es que primero identifiques los navegadores más utilizados en tu página, los ordenes de más a menos utillizados (eso te lo da Google Analytics por ejemplo). Empiezas por el primero, desarrollas tu página, la despliegas en producción y validas su uso. Luego vas a por segundo navegador de tu lista y ajustas y despliegas, luego el tercero, etc. Vas desplegando y validando de forma incremental.<br /><br />Saludos,<br /><br />AlexAlexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-43613822448296333002022-11-16T23:24:16.448+01:002022-11-16T23:24:16.448+01:00Hola Isaías,
En un entorno clásico estamos acostu...Hola Isaías,<br /><br />En un entorno clásico estamos acostumbrados a que nos digan y diseñen exactamente lo que quieren que construyamos, tanto la funcionalidad, la arquitectura y herramientas que hemos de utilizar. Eso se describe en gran medida en los casos de uso.<br /><br />Una historia de usuario trata de dar entendimiento de lo que necesita el cliente a aquellos que van a construir la funcionalidad. La toma de decisiones sobre tecnología, herramientas, el cómo hacerlo recae toda en el equipo. No hay nadie mejor que un equipo multidisciplinar y autogestionado para diseñar y construir la mejor funcionalidad posible. Lo único que necesitan es entender la funcionalidad, para lo demás ellos son los expertos.<br /><br />Puedes imaginarte que el uso de casos de uso o de historias de usuario dependerá de la autonomia y el método de trabajo del equipo.<br /><br />Espero haberte ayudado, saludos,<br /><br />AlexAlexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-68484654496885636302022-11-16T23:10:39.420+01:002022-11-16T23:10:39.420+01:00Gracias! :-)Gracias! :-)Alexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-5699256303252584442022-11-12T10:13:36.635+01:002022-11-12T10:13:36.635+01:00Siempre los problemas de compatibilidad de navegad...Siempre los problemas de compatibilidad de navegadores van a existir y de ahi dependerá el uso de uno o de otro. Con un buen servicio de <a href="https://intranetunidos.com/" rel="nofollow">Intranet para empresas</a> esto deja de ser problema claro.<br />saludosClaudio Lopezhttps://www.blogger.com/profile/14229530789655058113noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-67118112287652587342022-11-09T12:05:48.189+01:002022-11-09T12:05:48.189+01:00Entiendo la postura y el proceso que indica.
Hace...Entiendo la postura y el proceso que indica.<br /><br />Hace un par de días, ante un proyecto nuevo, en el análisis de las historias de usuarios, se estaban contemplando los procesos a realizar. No voy a decir nada que no sepamos todos ya.<br /><br />Gestión de cliente, gestión de solicitudes, gestión de servicios y todo derivaba en la creación del presupuesto. (entiéndase gestión como CRUD). Al desarrollar las historias de usuarios y plantear el roadmap para generar el sprint, se tuvo como premisa la creación primero de la gestión de cliente, en paralelo con la gestión de los servicios, pues sin esos puntos prioritarios no se podía llegar a la solicitud y mucho menos al presupuesto (dependencias).<br /><br />Todo eso en la época más temprana de la visión del trabajo, ya estaba asumida por los desarrolladores entendiendo que es el ciclo fundamental para las buenas prácticas.<br /><br />Bajo esa premisa, a la hora de la planificación, independientemente a la cantidad de participantes y todo ello regado con una documentación concisa y abierta a todos los integrantes, sientan las bases para minificar posibles "deudas técnicas", que a posteriori conlleven a retrabajo.<br /> <br />Si que en el proceso de coordinación de equipos, en un nivel superior, se puede hacer referencia a las premisas que se han tenido en cuenta a la hora de realizar un proceso en concreto sea del tipo que sea y de la complejidad que requiera el producto.<br /><br />Pero digo yo, en la reunión técnica donde hay varios encargados de equipos y donde seguro hay más de una persona del tipo arquitecto, no se planifica una línea de trabajo conjunta donde el tema de las dependencias no estén contempladas?<br /><br />Como siempre, si algo puede suceder, sucederá. Ley de Murphy <br /><br />Pero me gustaría saber que en el proceso más temprano, se ha planteado esas posibilidades y se ha contemplado un posible ROAM ante estas circunstancias, y no, en el proceso de trabajo del día tener que atender estas situaciones que implican reuniones, tiempo, refactorización y retrabajo, que desembocan en tiempo que no se dedica a entrega de valor al cliente.<br /><br />Un saludo.dradonehttps://www.blogger.com/profile/05744732862649117161noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-51244390341615521312022-11-09T11:06:30.980+01:002022-11-09T11:06:30.980+01:00Buenos días,
Quizá haya que poner las cosas en su...Buenos días,<br /><br />Quizá haya que poner las cosas en su contexto. Lo que describo en el artículo es una técnica, con un irradiador visual asociado, que solo tiene sentido cuando afecta a muchas personas. <br /><br />Cuando era programador en Inter Grundig eramos literalmente 4 personas, simplemente hablabamos y los riesgos estaban ahí, los conociamos y los gestionabamos sin más. En los equipos de Scrum pasa algo parecido, normalmente he visto en el tablero una zona con un par post-its que recogen los riesgos y hablan de ellos en la daily, sin más.<br /><br />¿Pero que pasa cuando tienes 3, u 8, equipos trabajando en un mismo producto? ¿Cuando hablamos de 50 personas qué hacemos? Allí es donde entra esta técnica, al igual que del tablero de dependencias (encontrarás algun post en mi blog). Sin las técnicas y los tableros no visibilizas, y ante la complejidad de tantas personas, si no visibilizas estás perdido.<br /><br />Lo que hacemos nosotros es hacer seguimiento de los riesgos que afectan a todos en una reunión semanal llamada PO-Sync. Es una especie de daily (weekly) con todos los Propietarios del Producto de esos equipos y otros expertos relacionados. En esta reunión se mira entre otros la evolución de esos riesgos.<br /><br />Yo lo que puedo contar, desde mi perspectiva de Agile Coach que acompaña a alrededor de 70 personas, es que la técnica que describo les es muy últil para gestionar los riesgos.<br /><br />Ya no hay heroes programadores como cuando yo programaba, hoy en día lo que importa es la suma de todos, ¡la colaboración es el diferencial! Y estas técnicas y sus tableros dan un referente comun.<br /><br />Gracias por escribir,<br /><br />AlexAlexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-12848225541590977142022-11-09T10:21:32.471+01:002022-11-09T10:21:32.471+01:00No puedo estar más en desacuerdo con esto. El ROAM...No puedo estar más en desacuerdo con esto. El ROAM originalmente está pensado para el Project Manager o Product Manager. Simplificar un proceso como el ROAM es como decir que un programa son solo unas líneas de código.<br />Los desarrolladores son profesionales, y tienen muy claro que están construyendo y a las dependencias a las que se enfrentan. <br />En que momento introducimos el ROAM? Otra reunión más? Venga.... reuniones, horas de una supuesta producción.<br />Cuando programo, tengo clarísimo que posibles dependencias se pueden crear a la hora de realizar el trabajo.<br />Scrum, ya tiene una reunión corta, donde se aborda mi trabajo, el seguimiento y de ahí puede partir una comunicación efectiva con el resto de los compañeros para detectar una implicación y un impacto de lo realizado. Nunca un riesgo. Somos profesionales, basta ya de intentar proteger, controlar, reducir algo que está implícito en lo que se hace y que se tiene la capacidad para afrontarlo.<br /><br />Me a decir usted que en Inter Grundig S.A., donde desarrollaba necesitaban horas para analizar dependencias del producto realizado? No era usted lo suficientemente profesional para que su analítica a la hora de escribir su código no tuviera en cuenta lo que estaba haciendo? De verdad no sabemos el principio de los tipos de relaciones entre tablas, datos? reutilización... y otros muchos más aprendizajes a la hora de programar?<br />dradonehttps://www.blogger.com/profile/05744732862649117161noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-55521823205234862692022-11-03T11:58:10.815+01:002022-11-03T11:58:10.815+01:00Otro ejemplo es el agile coach, que tiene su orige...Otro ejemplo es el agile coach, que tiene su origen en los entrenadores de diversos deportes. En el fondo de trata de formar equipo :-)<br /><br />Gracias por escribir!<br /><br />AlexAlexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-33972182348592366492022-11-02T21:29:41.444+01:002022-11-02T21:29:41.444+01:00Muchas gracias!Muchas gracias!Alexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-13199344754997467312022-11-02T17:52:24.053+01:002022-11-02T17:52:24.053+01:00Deportes Princesa
Es muy interesante la analogía...<a href="https://deportesprincesa.es/" rel="nofollow"> Deportes Princesa </a><br /><br />Es muy interesante la analogía que se termino por hacer a la hora de crear un sistema como el Scrum cogiendo como ejemplo el rugby y más concretamente lo que se conoce en este noble deporte con el termino francés de "melé". Seguro que más de uno lo hemos adaptado a nuestra vida personal en algún caso en concreto.JPhttps://www.blogger.com/profile/03786096510512528102noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-42906768572278655802022-11-02T17:44:26.174+01:002022-11-02T17:44:26.174+01:00Buen post.Buen post.JPhttps://www.blogger.com/profile/03786096510512528102noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-63820844996304706962022-10-29T19:43:57.766+02:002022-10-29T19:43:57.766+02:00Hola Alexander, soy Isaías, actuamente estoy estud...Hola Alexander, soy Isaías, actuamente estoy estudiando Ingeniería de Software, entiendo que una de las principales diferencias entre los casos de uso y las historias de usuario, es que en las historias la cercanía al cliente es mayor y el equipo de desarrollo debe tener la capacidad de poder entender la problemáctica desde la perspectiva del usuario, pero cuales serían otras diferencias más notorias?Isaías Rodríguez Couohhttps://www.blogger.com/profile/08317403855408343402noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-16768289710968212622022-10-07T00:29:53.606+02:002022-10-07T00:29:53.606+02:00Gracias a ti por escribirlo :-)Gracias a ti por escribirlo :-)Alexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-20028287331816951332022-10-06T19:47:38.297+02:002022-10-06T19:47:38.297+02:00espero que estes bien, tus notas me han ayudado cu...espero que estes bien, tus notas me han ayudado cuatro años despues. graciasSergio (si. asi sin apellidos)https://www.blogger.com/profile/02563433959902672602noreply@blogger.comtag:blogger.com,1999:blog-2328925255230238869.post-48638827617716708252022-08-18T11:36:40.925+02:002022-08-18T11:36:40.925+02:00¡En absoluto! La clave está en entender que todo N...¡En absoluto! La clave está en entender que todo NO puede ser. Contruirmos pieza a pieza con calidad y paramos cuando hayamos agotado el presupuesto (costo). Por eso es tan importante la priorización por valor de negocio, para empezar con la cosa de máximo valor e ir construyendo cosas de más a menor valor... y mientras dure el dinero... es como la vida misma. Recuerda que un proyecto ágil se aplica a situaciones en las que descubres el producto que necesitas a medida que lo construyes, recibes feedback y ajustas con cada sprint.Alexander Menzinskyhttps://www.blogger.com/profile/05273164033669386910noreply@blogger.com