scrummasterprofesional

[scrummasterprofesional]

Creación de un caso de uso y un ejemplo

Un caso de uso describe una secuencia de interacciones entre un sistema y un actor externo para una funcionalidad determinada. Hay distintos pero todos tienen estos elementos: -Identificar único. -Un título que indique el objetivo de un caso de uso. -Un detonante que genere la secuencia de pasos. -La precondición que se debe cumplir para iniciar un caso de uso. -La postcondición que debe tener el sistema luego de ejecutar el caso de uso. -Los pasos entre el actor externo y el sistema. Hay que comentar que un actor puede ser una persona, un sistema externo o un dispositivo de hardware. Ahora vamos a ver un ejemplo donde podemos crear uno para la funcionalidad de una aplicación web. Supongamos que tenemos una aplicación web en la cual ofrecemos el servicio de suscripción de streaming para poder ver las carreras de motos GP en vivo y en offline. La funcionalidad que queremos es que el usuario pueda suscribirse a la misma. En la siguiente página hay la tabla de este caso , es un ejemplo simple pero muy didáctico donde puedes ver cómo es un caso de uso simple pero muy claro.

Ejemplo de caso de uso

Diferencia entre un caso de uso y una historia de usuario

Vamos a basarnos en el ejercicio anterior en la funcionalidad de suscripción para ver la diferencia entre un caso de uso y una historia de usuario. El anterior ejercicio puesto como una historia de Usuario sería: Como visitante del sitio Quiero suscribirme al sitio Para poder ver las carreras de Motos GP en vivo y en diferido. En el caso de uso se toma otra perspectiva, no queremos saber qué es lo que el usuario quiere hacer con el sistema si no los pasos que tenemos que seguir para realizar la funcionalidad. En este caso es la suscripción a Streaming,es decir ,los pasos que tiene que hacer el visitante ,que es el actor externo, para conseguir suscribirse al streaming y poder ver las Motos GP en vivo y en diferido. Así que en definitiva con un caso de uso se indica los pasos y muchas veces hasta se describe que tipos de datos se utilizaran y se pone una serie de condiciones mucho más técnicas. Las historias de usuario son mucho más a alto nivel y para todos los usuarios mientras que los casos de uso son más como unas directrices solo para los desarrolladores. Read the full article

[scrummasterprofesional]

Libros de programación para desarrolladores!

Los libros de programación son fundamentales para que los programadores se formen continuamente: -Un nuevo framework -Un nuevo lenguaje como Angular -Nuevas arquitecturas como la hexagonal Por eso en Scrum Master profesional quiero traerte los 10 libros que debes tener en tu librería . Yo compro libros continuamente por Amazon,de informática,de SEO,marketing digital,si quieres vivir de crear contenido es fundamental además de hacer cursos en Udemy. Siempre puedes comprar ebooks si lo prefieres o suscribirte a kindle unlimited que puedes probarlo gratis 30 días después son 9.99 euros o tres meses gratis a 0,99 luego 9.99 euros. Pasemos a recomendar los libros de programación ,voy a crear dos articulos,libros para gente de España y otros para el resto de America porque el 15% de la gente que visita esta página es de ahí. Haré dos articulos porque para comprar la gente de américa muchos o compran a México o Brasil o tendrán que comprar en EEUU y seguro que muchos compran en EEUU.

1.El programador pragmático. Edición especial: Viaje a la maestría

Este libro es un libro de referencia tanto si eres un programador experto como si empiezas, es un libro que te hará pensar y te dará ideas. Qué dice Amazon? Dave Thomas y Andy Hunt escribieron la primera edición de este libro tan influyente en 1999 para ayudar a sus clientes a crear software mejor y a redescubrir el placer de escribir código. Estas lecciones han ayudado a una generación de programadores a examinar la propia esencia del desarrollo de software, independientemente de cualquier lenguaje, framework o metodología en particular, y la filosofía pragmática ha sido el germen de cientos de libros, screencasts y audiolibros, además de miles de carreras e historias de éxito. Es una nueva edición enfocada en el programador moderno,trata temas como la responsabilidad personal hasta tecnicas para que tu código sea reutilizable. Es un libro con muchas anecdotas y muchos ejemplos que pueden leerlo desde novatos a desarrolladores expertos e incluso responsables de proyectos de software. Un libro de programación perfecto como regalo de reyes. Si os parece caro podemos compralo en formato ebook en Kindle por 18.99 euros.

2.Aprende Python desde cero hasta avanzado - El libro completo de la programacion python para principiantes: Con ejercicios prácticos y contenido bonus

Este libro es el número 1 en la categoría de diseño de software orientado a objetos y de lenguajes de programación. Su autor es Xavier Reyes Ochoa un experto en programación que trabajo para grandes empresas como Google o Nintendo. En este libro aprenderas Python y te convertirás en un auténtico experto de la mano de una persona que ya enseña a muchas personas en youtube en su canal Programador X . El libro te enseña de manera clara y sencilla a programar pero utilizando el lenguaje Python. ¿Qué encontrarás en el libro? Conceptos básicos Primeros pasos en el lenguaje Un contenido para principiantes Consejos adicionales Temas específicos de este libro: Python para principiantes y avanzados Variables y tipos de datos: Aprende a manejar diferentes tipos de datos y a declarar variables. Operadores: Explora operadores aritméticos, lógicos y de comparación. Estructuras de control de flujo: Domina las sentencias condicionales y los bucles. Funciones: Crea y utiliza funciones para tu código. Números: Manejo de números y operaciones matemáticas. Texto: Manipulación y procesamiento de cadenas de texto. Listas: Aprende a trabajar con listas y sus métodos. Tuplas: Entiende las tuplas. Sets: Descubre los sets y cómo utilizarlos. ¡Y mucho más! (Diccionarios, programacion orientada a objetos (POO), módulos y paquetes, manejo de archivos, bibliotecas y frameworks) Es un libro con muchos ejemplos y ejercicios para que aprendas. Tienes la versión ebook de 9.99 euros por si quieres ahorrarte dinero. Tambien la versión del libro en tapa blanda,uno de los libros de programación más demandados!.

3.Aprende a programar con Java y ChatGPT: De principiante a programador con Inteligencia Artificial. Edición 2024

Este libro te permite aprender Java rapidamente y utilizar chatgpt para crear algoritmos mucho mas eficientes. Lo que encontrarás en estas páginas: • Fundamentos de programación explicados de manera clara y concisa • Introducción práctica a Java, ideal para principiantes que comienzan de cero • Capítulo dedicado a la integración de ChatGPT en tus proyectos • Abundantes ejercicios resueltos y explicados paso a paso • Técnicas para aprovechar la IA y potenciar tu código ¿Por qué elegir este libro? • Aprendizaje acelerado: Domina los conceptos básicos en poco tiempo • Enfoque práctico: Ejemplos reales y aplicables de inmediato • Autor experto: Escrito por un profesor de informática con experiencia en desarrollo de apps • Lectura amena: Contenido estructurado para mantener tu interés y motivación • Bonus especial: Incluye un regalo sorpresa que te encantará, ¡100% garantizado! Al terminar este libro de programación, serás capaz de: • Escribir código Java con confianza • Integrar ChatGPT y otras herramientas de IA en tus proyectos • Abordar desafíos de programación con un enfoque estructurado y eficiente Puedes comprar el libro en formato tapa blanda por 21.99 euros . También tienes el libro en formato ebook por los míticos 9.99 euros. Yo te recomiendo que si te gusta leer contenido de calidad te suscribas a kindle unlimited porque te compensará ,aparte de leer blogs como el mio, ayuda mucho para aprender estas suscripciones. La suscripcion es gratis por 3 meses o casi gratis ,0.99 euros, luego ya los 9.99 euros al mes ,cuanto te vale la suscripción a Udemy? ,24,99 euros ,esto compensa más.

4.C/C++. Curso de programación (MANUALES IMPRESCINDIBLES) 

El lenguaje C/C++ fue el primer lenguaje que aprendi en la universidad ,se utiliza sobre todo para programar sistemas operativos o acceder a controladores de periféricos. Se tiliza para utiliza en sistemas operativos de ordenadores y de dispositivos móviles, en software para oficinas, sistemas gestores de bases de datos, navegadores web, software de correo electrónico. Es decir sigue siendo un lenguaje muy utilizado para todo lo que acceder al hardware del equipo ,por lo tanto tanto si eres experto en programacion o no deberiás tener este libro. Son libros que no crees necesitarlos porque no se utiliza en el día a día más C# ,Python o Angular pero que nunca está demás tenerlo en tu libreria particular. Este libro de programación, con varias ediciones en su haber, se ha convertido en un clásico, un libro imprescindible para aprender programación. No hay versión en ebook lo siento mucho chicos!.

5.Aprendiendo Git y GitHub: Desde cero hasta buenas prácticas y estrategias de trabajo en equipo

Hoy en día es imposible imaginar el desarrollo de software sin Git. Según una encuesta de Stack Overflow de 2018,  el 90% de los desarrolladores usaban Git para manejar su código fuente. Este libro es fundamental tanto si trabajas ya como programador como si quieres trabajar debes manejar git a la perfección. Este libro explica el origen de Git ,caundo nació y quien lo creó además de que enseá a utilizar los comandos mas usados. Este libro no es de progarmación pero es fundamental porque el codigo hay que guardarlo. Este libro te ayuda a insatalar y configurar Git y a trabajar de manera remota y local. Además el autor te habla de cómo usar los alias, los hooks, trucos imprescindibles. ¿Te interesa dominar Git? ¿Quieres una guía que te va a acompañar siempre? ¡Este es tu libro! El precio es irresistible no te quejaras que no te muestro lo mejor ,bueno ,bonito y barato!. Lo pondría en el top de los libros de programación que recomiendo.

6.Código Limpio: Manual de estilo para el desarrollo ágil de software (PROGRAMACIÓN)

Cada año, se invierten innumerables horas y se pierden numerosos recursos debido a código mal escrito. El reconocido experto de software Robert C. Martin, junto con sus colegas de Object Mentor, nos presentan sus técnicas y metodologías ágiles para limpiar el código. Partes de este libro Esta obra se divide en tres partes: La primera describe los principios, patrones y prácticas para crear código limpio. La segunda incluye varios casos de estudio cuya complejidad va aumentando La tercera parte del libro contiene una lista de heurística y síntomas de código erróneo (smells) Este libro es fundamental como libro de cabecera para desarrollador ,ingeniero de software,director de proyectos ,jefe de equipo o analista de sistemas. El precio es un poco caro pero la realidad es que no hay muchos libros en español que enseén a programar de manera limpia y correcta. Aun no he terminado este artículo ,iré agregando más libros de programación que os puedan aportar a medida que los encuentre. Read the full article

[scrummasterprofesional]

Professional scrum master: como aprobar la certificación

Aprobar la certificación PSL o Professional Scrum Master en Scrum.org o en certiprof es difícil pero no imposible y es recomendable sacarse esta certificación tanto para el caso que quieras iniciarte en Scrum y agile como para gente ya experimentada que quieras un puesto de gerente de proyecto. En esta guía te daré una serie de consejos para que puedas aprobar la certificación y el primero es que compres mi libro jajajaja.

1. Ventajas y desventajas de la certificación

Los beneficios son los siguientes: -La certificación Scrum Master si la sacas por Scrum.org te dará mas cache pero por certiprof te saldrá mas barata y como certificado tiene igual validez -Te permite demostrar que eres un experto. -Las certificaciones de Scrum Master no caducan en general pero en algunos lugares si caducan en Scrum.org y en certiprof no caducan. -El coste es de unos 200 dólares y si suspendes tendrás que pagar de nuevo. Luego se podrá realizar el examen online cuando quieras. -Si no tienes experiencia como Scrum Master aunque si has trabajo con Scrum el tener esta certificación te ayudará a que te den una oportunidad en este puesto y demostrar que tienes el conocimiento. -Si ya eres un Scrum Master con experiencia la certificación Profesional Scrum Master te ayudara a asentar tus conocimientos de Scrum y acreditar tu conocimiento como Scrum Master.

2. Cómo es el examen de Professional Scrum Master

-Son 80 preguntas tipo test y tienes una hora ,60 minutos para completarlo. Es decir tienes 45 segundos para cada una y la dificultad es variable. -Para aprobar necesitas tener un 85 % de aciertos ,es decir puedes fallar 12. -Hay preguntas que pueden tener varias respuestas correctas y en el enunciado te lo indicara. -Está en ingles en el Scrum.org por lo que si no saben ingles es mejor hacerlo el examen en certiprof que permite hacer el examen en español o muchos más idiomas además que tiene una promoción de examen por 125 euros. -En el correo que te llega se mostrará la puntuación que sacaste pero sin indicar las partes que fallaste.

3. Qué materiales de estudio debo utilizar

En estas secciones te indicare como vas a estudiar este certificado. 3.1. Reflexión para Scrum Masters que trabajan de ello El que trabajes como Scrum Master te ayudará a aprobar el certificado y a aprender los conceptos profundos pero en la practica Scrum está muy viciado y por lo tanto muchos profesionales no saben que es Scrum y que no lo es. Estudiar para la certificación te permitirá aprender el scrum puro y no viciado ,de hecho en la practica se cree que los desarrolladores se comprometen a entregar todos los elementos del product backlog que se seleccionaron en el sprint planning pero se comprometen a a alcanzar el objetivo del Sprint pero el alcance puede negociarse con el product owner . 3.2. La Guía Scrum La guía Scrum hay que leerla pero ya te aviso que es un resumen donde no se profundiza en nada ni habla de las historias de usuario; te recomiendo que la leas un par de veces tanto en ingles como en español. Este documento es como la biblia de scrum y es desarrollada y mantenida por Jeff Sutherland y Ken Schwaber. 3.3. Estudiar por libros sobre Scrum Te recomiendo tres libros para preparar la certificación Scrum Professional master : Essential Scrum, de Kenneth S. Rubin y  Succeeding with Agile, de Mike Cohn que están en ingles y Certified Scrum Master que es un libro mío que está en español. 3.4. Practicar el tipo test Una de las mejores maneras de preparar el examen de Scrum Professional master es realizando exámenes de ejemplo y para eso no hay mejor lugar que Udemy ,hay un curso que esta formado por 6 exámenes de ejemplo para que practiques los exámenes y te quites todas las dudas que puedas tener. Haciendo exámenes puedes ver que tan preparado estas para realizar el examen y aprobarlo.

4. Ejemplos de preguntas

A continuación te dejo 3 preguntas para que te hagas una idea de como son las preguntas de examen. ¿Quién estima un elemento del Product Backlog? a) Los Desarrolladores, una vez aclarado su contenido con el Product Owner b) El Scrum Master, en consulta con los Desarrolladores c) El Propietario del Producto, teniendo en cuenta las mejores estimaciones proporcionadas por los Desarrolladores d) Los Desarrolladores de mayor rango, o aquellos que sean expertos en el dominio con respecto a ese Elemento del Product Backlog e) Las estimaciones son una fuente de desperdicio que debe ser eliminada por el Scrum Master f) El director del proyecto, en colaboración con el Product Owner El Scrum Master es (elija dos respuestas): a) Una rendición de cuentas obligatoria en Scrum b) El ágil gestor del Scrum Team c) Un verdadero líder que apoye la adopción de Scrum d) El que decide qué mejoras identificadas en la Retrospectiva del Sprint deben implementarse Los valores de Scrum son: a) Coraje, Enfoque, Compromiso, Autonomía, Transparencia b) Transparencia, Inspección, Adecuación c) Autoorganización, multifuncionalidad Te sabes alguna?,responder en los comentarios aquellas que sepáis y yo os diré si son correctas o no. Read the full article

[scrummasterprofesional]

Valores Scrum en un proyecto real

En el año 2016 la guía Scrum se actualizo para añadir los valores Scrum dado que Scrum se estaba implantando de manera mecanizada y deshumanizada. En muchos proyectos el equipo Scrum no aplica estos valores porque básicamente no los conoce y otras veces no los aplica por ser demasiado teóricos. Estos valores deben no solo aprenderse sino interiorizarse como una forma de pensar aplicada sin pensar.

¿Qué son estos valores Scrum?

Los valores son una guía de comportamiento que ayuda a los miembros del equipo en su conducta y toma de decisiones. Por lo tanto estos valores ayudan al Equipo Scrum a tomar decisiones y mejorar sus interacciones La guía scrum propone 5 valores: compromiso, coraje, foco, apertura y respeto. Estos valores fomentan un comportamiento ético mientras se está utilizando Scrum por lo tanto tantos Scrum como sus practicas deben respetar estos valores.

Explicación de los valores Scrum

La explicación de estos valores es la siguiente: Coraje= Los miembros de Equipo Scrum tienen la valentía para trabajar en problemas complejos y seguir el camino correcto. Saben que las equivocaciones son el mejor camino para aprender. No hay coraje cuando anteponemos intereses de la empresa antes de mirar el valor real de lo que hacemos y olvidamos los valores de Scrum. Foco=Hay que centrase en el trabajo del Sprint y en conseguir el objetivo del Sprint; no hay foco si ignoramos el objetivo del Sprint, si hacemos multitareas y no terminamos ninguna y si las tareas las dejamos para después. Compromiso=El compromiso personal es fundamental para lograr el objetivo del sprint, hay que entregar los elementos del Sprint backlog y cumplir el objetivo del Sprint pero además hay que comprometerse a dar lo mejor de uno. No hay compromiso cuando no hay voluntad de aprender y mejorar y además no ayudas a tus compañeros para que se cumplan los incrementos pactados. Respeto= Es fundamental que haya respeto entre los miembros del equipo Scrum y que la comunicación sea cordial . No hay respeto cuando menospreciamos a nuestros compañeros ,no los tomamos en cuenta ,queremos imponer nuestras opiniones o cuando gritamos .Está prohibido insultar a otros compañeros. Sinceridad, apertura=El equipo Scrum ha de ser transparente con su trabajo y con los artefactos pero también los stakeholders. No hay sinceridad si ocultamos información sobre el trabajo o artefactos o cuando engañamos a los stakeholders.

Creación de un entorno amable

Los valores de Scrum sirven para crear un entorno donde seguro donde los miembros del equipo puedan sentirse libres para decir que cosas se pueden mejorar, en que hemos fallado . Debe existir una critica constructiva y debe hablarse de las equivocaciones que ocurrieron en el sprint incluso las equivocaciones que uno realiza porque eso ayuda a que todos mejoren y que no se vuelvan a repetir. Criticar de manera respetuosa un artefacto no es algo malo si su función es mejorar el producto no así si su finalidad es atacar a un compañero o intentar ascender a base de hundir a otros. La confianza se consigue con el tiempo y hay que tener cuidado de como uno se explica, dependiendo del grado de tiempo de un grupo hay comentarios que se pueden decir y otros no.

Cómo poner en práctica los valores Scrum

La retrospectiva es el momento en el Sprint en que se habla de toda aquello que se ha hecho bien y de aquello que se puede mejorar y es el momento ideal para hablar de los valores de Scrum y como han afectado a ese Sprint: – ¿Qué valores nos han ayudado en este Sprint? – ¿Qué valor Scrum tenemos que trabajar mucho más? – ¿En qué situaciones nos resulta difícil ser fieles a los valores ? – ¿Qué pasa cuando dejamos de aplicar alguno de estos valores? Hay ejercicios que se pueden realizar para aprender como los valores Scrum se aplican en un proyecto real o como no se aplican por ejemplo podemos pedir que se escriban en un post-its aquellas situaciones donde se esta aplicando un valor de Scrum y otras en las que se dejo de aplicar. En muchas empresas es difícil aplicarlos por rivalidad entre departamentos, equipos o incluso personas. Scrum tiene unos valores pero también tiene unas serie de principios que puedes leer aquí. Pero coméntame en tu empresa o equipo utilizáis los valores Scrum ?,como los poneis en practica? Read the full article

[scrummasterprofesional]

Habilidades en T

Las habilidades en T realmente se refieren a profesionales que son especialistas en una determinada área de conocimiento pero que también tienen conocimientos en otras áreas. Por ejemplo, un profesional que sea experto en Testing pero que además tenga conocimientos avanzados de Scrum y DevOps. Por lo tanto, habilidades en forma de T son imprescindibles en Scrum porque ayuda a reducir el número de personas en el equipo Scrum al tener perfiles con distintos ámbitos de conocimiento y como sabemos del artículo de tamaño de un equipo cuanto más pequeño sea mejor.

Las habilidades en T en Scrum

En Scrum los objetivos se comparten ,el objetivo de un Sprint es responsabilidad de todos los miembros del equipo Scrum y las culpas se reparten no es sólo de una persona. Si no se entrega a tiempo habrá que hacer autocritica todos y ver como mejorar, en Scrum no hay culpas ni reproches. Un desarrollador de back-end si además de hacer su trabajo ,se encarga de realizar las pruebas de APIs, las pruebas unitarias y de crear pipelines y configurar el DevOps va ayudar mucho a sacar todos los items del sprint backlog. Por lo tanto no se trata de tener gente que sepa de todo sino de tener miembros del equipo que puedan ayudar en temas que no son de su especialidad para terminar el trabajo del sprint a tiempo. Por esta razón los gerentes deben intentar formar a los miembros del equipo para que tengan habilidades en forma de T.

¿Son recomendables los especialistas en un equipo Scrum?

Los especialistas son necesarios y además mejorar la velocidad de un Sprint pero un especialista si es necesario tiene que ayudar en otras áreas. Scrum defiende el compañerismo y la actitud de ayudar por lo tanto ser un especialista es bueno lo que no es bueno es negarse a realizar trabajos fuera de tu área porque no es tu rol principal . Scrum quiere profesionales especialistas pero que arrimen el hombre si es necesario para cumplir los objetivos del sprint actual. Algo que ocurre en muchas consultoras es que un especialista este en tres proyectos diferentes por temas de costes pero hay que aceptar que si ocurre eso la productividad de esa persona se reducirá. De hecho hoy en día eso ocurre mucho y genera en la persona estrés, ansiedad y baja productividad y suele mirar la salud a medio plazo. Read the full article

[scrummasterprofesional]

Tamaño del equipo scrum

La guía scrum indica que el Equipo Scrum no puede pasar de 10 personas. De hecho habla que como mucho deben ser 9 personas sin contar con el Scrum Master y el Product Owner ,siempre y cuando los dos últimos no realizaran tareas de programación dentro del Sprint. Lo anterior es si nos basamos en guía del 2017 porque en la guía del 2020 no lo deja tan claro el numero de miembros que debía tener además que no habla de Equipo de Desarrollo.

Razón para limitar el tamaño del Equipo Scrum

Esta razón se basa en una investigación empírica cuya resultado se muestra en el grafico de abajo ,que muestra el tiempo que se tarda en realizar proyectos de software parecidos teniendo en cuenta el numero de integrantes del equipo Scrum.

Si un equipo Scrum tiene 2 personas, es casi imposible que un equipo Scrum cuente con todas las habilidades necesarias para realizar un incremento de valor. Desde mi experiencia 3 personas que sean totalmente multifuncionales es lo mínimo que se necesita para sacar adelante un proyecto, un desarrollador, un tester y un scrum master. Lo ideal y el tamaño que genera la mejor productividad es entre 5 y 7 personas en el equipo Scrum sin contar con Product Owner Y Scrum Master. Los problemas empiezan a verse a partir de 10 miembros porque se empieza a perder productividad y se necesita una gran coordinación . Cada vez que añadimos miembros al equipo se pierde productividad y se tarda más en entregar ,el nuevo es un lastre mientras se está formando y ralentiza la velocidad. Cuanto más grande es el equipo más tiempo hay que gastar en coordinar y en no pisarse unos a otros y al final lo mejor es dividir el equipo en equipos de menos de 10 ,cuantos más pequeños mejor. Hay una falacia muy común en las consultoras ,que es creer que cuanto más gente en el proyecto mejor pero la gráfica anterior demuestra que no.

Equipos de más de 10 personas

Cuando tenemos un equipo formado por más de 10 personas existen dudas de si se está trabando con Scrum y la realidad es que si pero no te dará el mismo rendimiento. De hecho cuanto más grande ,más tiempo del sprint se gastará en reuniones ,por eso lo mejor es dividir el equipo en dos. Algunas personas dicen que estos equipos ya no serán multifuncionales pero si por ejemplo hay solo un tester en un equipo de 15 personas quizás es hora de dividir en 2 el equipo y contratar a otro tester. Scrum recomienda siempre equipos pequeños multifuncionales y de hecho la historia muestra que grandes ejércitos sucumbieron antes otros mas pequeños como los 300 guerreros espartanos contra los turcos.

Habilidades en forma de T

Los equipos Scrum tienen que ser multifuncionales por eso el Scrum Master debe intentar que los miembros del equipo tengan habilidades en forma de T ya que esto es lo que realmente hará que un equipo sea realmente productivo. Read the full article

[scrummasterprofesional]

Como ser un buen Scrum Master

¿Quién es el Scrum Master?

El Scrum Master es la persona que debe implementar Scrum en un proyecto y que sea entendido para que se pueda sacarle el máximo beneficio. Es un líder que debe servir al Equipo Scrum, al Producto Owner y a la organización. Al contrario de lo que muchos piensan el Scrum Master no tiene autoridad sobre el Equipo Scrum solo sobre el proceso de Scrum, de hecho ,debe apoyar al equipo porque su éxito depende del éxito del equipo. Si el equipo no funciona será porque posiblemente no se implemento correctamente Scrum y eso es responsabilidad del Scrum Master.

Características y habilidades del buen Scrum Master

El Scrum Master es un guía que ayuda a los miembros del equipo a sacar su mejor versión a través de Scrum. A continuación hablaré de las 20 características que debe tener un buen Scrum Master. 1.Es un líder sirviente, que ayuda a 3 tres niveles: Al Equipo Scrum, al Product Owner y a la organización. 2.Tiene que tener ganas de inspirar a los demás y hacer un checklist de los tres niveles anteriores con preguntas como las siguientes: Para el Product Owner -¿En que estado se encuentra el Product Backlog?. -¿Cual es la relación con los StakeHolders?. Para el Equipo de desarrollo -¿Solucionamos los problemas internos?. -¿Trabajamos como un equipo autogestionado?. -¿El equipo cumple con los valores de Scrum?. -¿La definición de hecho es correcta?¿Se está cumpliendo?. -¿Que practicas de programación estamos utilizando y que pruebas se están realizando? -¿Necesitamos más recursos para cumplir con los incrementos terminados? Para la organización -¿Apoya la organización la implantación de Scrum?. -¿Como se gestionará las relaciones con el resto de departamentos? 3.Crea el marco para que los Equipos Scrum aprendan a ser autogestionados. Ayuda a que el equipo tome sus propias decisiones sobre el trabajo porque Scrum ayuda a empoderar a profesionales y hacerlos más autónomos. 4.Gestiona el proceso Scrum y tiene autoridad sobre él. El Scrum Master no tiene autoridad sobre las personas ,no puede despedir, pero si sobre el proceso de Scrum, si se decide que un sprint va ser de dos semanas él tiene la autoridad para decidir que sea de dos semanas. 5.Gestiona y elimina aquellos impedimentos que el Equipo Scrum no puede eliminar. El Equipo Scrum debe saber cuando un impedimento puede ser solucionado por ellos y cuando hay que escalarlo al Scrum Master. 6.Se debe hacer responsable de maximizar el rendimiento del Equipo Scrum y de que sus miembros adopten Scrum, lo entiendan e interioricen. 7.Se encarga de que el conflicto haga que el equipo mejore y se haga mas productivo y creativo y que adopte los mejores estándares del momento. 8.Habla de los valores Scrum y los encarna como son valentía, foco, compromiso, respeto y sinceridad. También intenta que tanto los eventos como los artefactos de Scrum sea muy transparentes. 9.Crea un entorno amigable donde los profesionales puedan hablar sin miedo y donde los miembros del equipo colaboren y elimina cualquier comportamiento que pueda afectar a este entorno. 10.Tiene que tener un conocimiento profundo de Scrum Master. El tener mucho conocimientos técnicos, como puede ser un CTO o un líder de desarrollo, no significa que tenga que ser un buen Scrum Master dado que este rol no ayuda desarrolladores de como hacer un incremento de producto. 11.Es un coach del Equipo Scrum. Es decir ayuda a que los miembros del equipo desarrollen todo su potencial y aprendan solos. Sabe que preguntas hacer para que las responda el equipo. 12.Sabe escuchar y es un gran observador. Está en el día a día para ver en que puntos el equipo puede mejorar. 13.Es un profesor porque explica al equipo los fundamentos de Scrum como son sus roles, eventos y artefactos sobre todos cuando son equipos de reciente creación. 14.Es un mentor porque comparte las experiencias propias sobre Agile y además debería estar en contacto con expertos Scrum Master que tengan más conocimiento que él. 15.Debe ser un facilitador ,debe crear los eventos de Scrum aunque no en todos debe estar ,como en el caso de la daily. Es como un creador de vidrio donde los desarrolladores deben darle la forma. 16.Hace retrospectivas útiles donde se solucionan los problemas entre los miembros del equipo y las mejoras se añaden al siguiente Sprint Backlog. 17.Es quien genera el cambio en la organización ,implantando Scrum en la organización y en el negocio ,por lo tanto debe tener una gran colaboración con todos los departamentos de la empresa. 18.Debe ser un buen comercial, porque debe vender Scrum a la empresa, convencer al equipo Scrum de implantar ciertas técnicas o al departamento de QA para que asigne gente al equipo de Scrum. 19.Es humilde ,los éxitos son del equipo y los fracasos no son de nadie ,son una manera para aprender y mejorar tanto del equipo como de él mismo y del proceso Scrum. 20.Es prescindible ,realmente el rol de Scrum es temporal porque una vez el equipo llega a cuotas de autogestión y multifuncionalidad en el proyecto, su aportación será mínima y de hecho es un rol para el inicio de un proyecto.

¿Qué hace un buen Scrum Master?

Eventos de Scrum Sprint Planning El Scrum Master debe asegurarse que se cumplen los siguientes acciones: La creación del Sprint Goal por parte del Equipo Scrum. La selección de los elementos del Product Backlog por parte de los desarrolladores asesorados por el Product Owner. El diseño del plan de trabajo del Sprint. Donde habrá que desglosar las tareas de cada elemento del Product Backlog. La preparación del Sprint Planning por parte del Product Owner y los desarrolladores. Daily Scrum No tiene que participar en la Daily ,sólo los desarrolladores a no ser que el Scrum Master sean también un desarrollador. El Scrum Master debe asegurarse que en estas reuniones son útiles para la consecución del objetivo, que en estas reuniones no se vea problemas para que no se cumpla y que se respeta los 15 minutos. Sprint Review El Scrum Master debe enseñar al equipo Scrum y a los stakeholder cual es el fin de esta reunión ,que es más que mostrar la demo del incremento sirve para recibir un feedback del cliente y mejorar cosas. Sprint Retrospective Este evento lo suele liderar el Scrum Master y se basa en que el equipo se sincere y hable de lo que fue bien y mal en el Sprint y que salgan propuestas concretas de mejora. Las actividades que el buen Scrum Master desempeña durante el Sprint Este rol da servicio a tres partes: Servicio al Equipo Scrum Debe entrenar al equipo para que sea autogestionado , multifuncional, para que construya incrementos de valor que cumplan con la definición de hecho. Debe gestionar los impedimentos y asegurase que los eventos de Scrum se celebran ,son productivos y están dentro de los Time-Box. Servicio al Product Owner -Debe ayudarle a utilizar técnicas de definición de Product Goal. -Ayudarle a que utilice técnicas de gestión del Product Backlog como Historias de usuario, criterios de aceptación, sesiones de refinamiento ,eliminación de elementos obsoletos. -Ayuda a facilitar la colaboración con los stakeholder. Servicio a la organización -Lidera la implementación de Scrum en la organización. -Ayuda a los trabajadores y a stakeholders a entender Scrum. -Elimina barreras entre el equipo Scrum y los Stakeholders.

Preguntas frecuentes

¿El Scrum Master tiene que ser a tiempo completo? Lo ideal es que sí pero por temas económicos es posible que no se pueda. De hecho el Scrum Master puede dar apoyo hasta 3 equipos ,mas ya sería excesivo. En la actualidad suele estar en este rol la persona y también tener otro rol como puede ser desarrollador o Product Owner. ¿Deben los líderes de desarrollo ser Scrum Masters? Puede ser aunque la realidad demuestra que no son los mejores Scrum Master porque suelen dar consejos técnicos y por lo tanto el equipo terminaría siendo dependiente. También perfiles de este tipo no suelen tener una sensibilidad especial para el trato con personas. Diferencias entre el Scrum Master y el Agile Coach El Agile Coach suele ser un consultor externo a la organización mientras que el Scrum Master es un rol interno a la organización. Diferencias entre Scrum Master y Product Owner El Scrum Master se encarga de todo lo relativo a la efectividad del Equipo y al proceso Scrum. El Product Owner, de su lado, se ocupa de la maximización del valor del producto y de la gestión del Product Backlog. Read the full article

[scrummasterprofesional]

Enfoque de producto VS enfoque de proyecto

El enfoque tradicional de gestión de proyectos mide el éxito de un proyecto por cumplir 3 variables: alcance, tiempo y coste. Es decir si entregamos el alcance deseado por el cliente en el plazo acordado y coste deseado entonces el proyecto ha sido un éxito. El problema de este planteamiento es que no se tiene en cuenta si ese alcance entregado crea o no valor al cliente. En definitiva que puede que se entregue la funcionalidad que quiere el cliente pero le es útil? alguien la está utilizando?. Lo ideal es adoptar una mentalidad de producto donde se este entregando valor en cada sprint o en cada entrega. Voy a describir cada uno de los enfoques para que se entienda un poco mejor.

Enfoque de proyecto

El éxito de un proyecto viene dado porque se entregue el alcance deseado en el prepuesto y tiempo acordado. -El Gestor de proyecto gestiona las tareas y personas del proyecto. -El conocimiento se comparte a medida que avanzan las fases del proyecto. -Se usa Waterfall generalmente.

Enfoque de producto

-El éxito se mide fijándonos en las métricas del negocio: tasa de retención, ingresos, ahorro de coste. Esta integramente asociado a que el producto genere ingresos y guste al usuario -Despliegues a producción frecuentes con el objetivo de recibir feedback de los usuarios que utilizan la aplicación. Amazon al día hace varios despliegues con pequeñas nuevas funciones. -Énfasis en la visión y objetivos del producto ,con lo que conseguimos mas creatividad y gastar menos tiempo en informes de reporte. -Uso de Scrum y la mentalidad agile ,de hecho las funciones que solía hacer el Product Manager en el enfoque de producto son absorbidas por tres roles :Scrum Master, Product Owner y el Equipo de desarrollo. Muchas empresas se encuentran ante este dilema, utilizar un enfoque al proyecto o al producto pero la realidad de hoy en día es que si es un producto para el mercado es mejor el enfoque a producto. Si es un proyecto interno de la empresa o para la administración publica lo mejor es comenzar con enfoque al proyecto y en mantenimiento enfoque al producto. Una situación común puede ser aquella empresa que ha desarrollado un software propio pero que da servicio a partners y le ha ido bien pero cuando a querido escalar se ha dado cuenta que es imposible. Todas esas funcionalidades que sus clientes B2B les iba bien cuando han querido crear un producto más global se han encontrado con una gran deuda técnica. En definitiva algunas veces tenemos que eliminar funcionalidades que gustan a nuestros socios para que el producto sea viable y escalable a medio plazo. Otro problema que he visto es en las consultoras de software ,son meras fabricas de software donde realizan el producto que quiere el cliente, utilizan Scrum y practicas agile, pero en el fondo no entregan valor solo entregan un software . Estas empresas utilizan Scrum pero tienen enfoque de proyecto no de producto pero en los contratos solo se pide la entrega del producto con unas funciones ,en un tiempo y coste y como mucho el mantenimiento pero en ningún momento se habla del éxito del producto en el contrato, la consultora cobra tenga éxito o no. Las consultoras deberían aportar valor realmente y que en el contrato una parte de los ingresos esté vinculado al éxito del producto ,para que realmente no se haga lo que diga el cliente sino lo que realmente aporte valor al cliente en su nicho con su producto. Si te ha gustado este artículo ayúdame compartiéndolo en alguna red o suscríbete a mi Newsletter. Read the full article

[scrummasterprofesional]

Diferencia entre scrum master y product owner

La guía Scrum comprende dos roles además del product owner, aunque por ahí adelante se habla de Product Manager ,Agile Coach o Scrum Manager, pero sólo existen 3 roles: El scrum master, el product owner y el equipo de desarrollo. En el equipo de desarrollo están los desarrolladores y miembros de QA pero también el scrum master y el product owner . El scrum master es el líder que tiene básicamente tres funciones: -Ayudar a implementar Scrum en el proyecto. -Ayudar a desarrollar el potencial profesional de las personas del equipo. -Conseguir la máxima productividad. El product owner su función principal es maximizar el valor del producto que se está desarrollando y con ello tener un gran retorno de la inversión.

Eventos de Scrum con responsabilidades por roles

En la siguiente tabla resumo las principales diferencias entre ambos roles. EventosScrum MasterProduct OwnerResponsabilidadLidera a tres niveles: – Ayuda al Product Owner. – Ayuda al Equipo de Desarrollo. – Ayuda a la organización en su conjunto.  Gestiona e l proceso de desarrollo, gestiona los impedimentos, evita el despilfarro, cuida de la salud del equipo y gestiona la organización. Maximiza el valor del producto.   Gestiona el Product Backlog o pila de producto.   Gestiona las relaciones con clientes y stakeholders o partes interesadas.Sprint PlanningEn la reunión de planificación de Sprint define la estructura de la reunión y se asegura que el tiempo o el time-box es respetado. Durante la misma identifica oportunidades para enseñar al resto como por ejemplo enseñar a estimar o a desglosar las historias de usuario en tareas  Durante la misma, identifica oportunidades de aprendizaje. Por ejemplo, ayuda al Equipo de Desarrollo a utilizar técnicas efectivas de estimación, o de desglose de historias de usuario en tareasSelecciona los elementos Product Backlog a seleccionar en el Sprint, junto con un objetivo para este. Negocia con el Equipo de Desarrollo.Daily ScrumSe asegura de que tiene lugar esta reunión y de que el equipo respeta su time-box de 15 minutos. Decide si una reunión cambia la hora. No tiene por qué estar presente y, si lo está, como regla general, solo participa para explicar cómo funciona la Daily Scrum u ofrecer observaciones o feedback al terminar.No es obligatorio que esté presente. Puede estar si quiere, sin participar, a fin de interesarse y estar disponible a continuación para aclarar cuestiones del Equipo de Desarrollo o aportar feedback.Durante el SprintGestiona impedimentos, observa la relación entre las personas del equipo, facilita eventos y conversaciones, ayuda a que miembros externos al Equipo Scrum interactúen con el equipo Scrum, de forma adecuada, etc. Busca oportunidades para reforzar el carácter auto-organizado del Equipo de Desarrollo.   Vela porque el product owner tenga el Product Backlog listo para la siguiente Sprint Planning.   Recoge ideas para la Sprint Retrospective.   Promociona continuamente el uso de Scrum y la agilidad dentro de la empresa.Resuelve dudas que tengan el Equipo de Desarrollo y ofrece feedback continuamente   Interactúa con stakeholders (clientes, usuarios, miembros de otros departamentos) y realiza tareas de investigación y descubrimiento.   Gestiona y refina el Product Backlog, junto con el Equipo de Desarrollo.Sprint ReviewDebe estar presente porque es miembro del Equipo Scrum, y por lo general se limita a observar si el grupo es fiel al propósito de la reunión además de seguir las interacciones del Equipo Scrum con los stakeholders. Su feedback ayudará al equipo Scrum a mejorar las reuniones de revisión.Debe de hacer énfasis en la visión y explicar cómo el objetivo del Sprint ayuda a esta Recopila el feedback de stakeholders y revisa el Product Backlog junto con estos.  Planifica fechas probables de entrega basándose en el progreso que se tiene y el trabajo que falta (por ejemplo, utilizando un release burndown chart).Sprint RetrospectiveDefine como va ser la reunión con el objetivo de identificar lo que se tiene que mejorar en relación a procesos y relaciones lo que se de de mantener para el siguiente sprint.Participa como un miembro más del Equipo Scrum.   Comprueba si la visión de producto está siendo comunicada de manera efectiva, así como la implicación del resto del Equipo en tareas de descubrimiento y de refinamiento del Product Backlog.

Compenetración entre el product owner y el scrum master

El que ambos roles están presentes y hay sintonía la organización se ve beneficiada. Puede haber tensión entre estos dos roles porque uno protege al equipo y al proceso y el otro que se entregue valor continuamente en forma del producto. Por eso ambos roles deben compartir unos principios ágiles y de respetar el trabajo que realiza cada uno. De hecho ambos se ayudan mutuamente de la siguiente manera: El scrum master da servicio al product owner, de diversas maneras: -Ayudando a encontrar técnicas efectivas de gestión del product backlog. -Contribuyendo a que los objetivos y estrategias de producto sean comprendidos por el Equipo Scrum. -Facilitando cualquier tipo de evento. El scrum master también tiene que ayudar a que el rol de product owner sea respetado dentro de la empresa protegiendo la toma de decisiones con respecto al producto. El product owner con conocimientos sobre Scrum y agile permitirá que el Scrum Master pueda centrarse en dar servicio al Equipo de Desarrollo y a la organización. Lo anterior conseguirá que la velocidad del equipo sea mayor lo que ayudará a que el producto de valor se entrega antes.

¿Puede recaer el Rol Product Owner y Scrum Master en la misma persona?

En teoría si es posible que los dos roles estén en la misma persona sin que se deje de aplicar Scrum correctamente ,nada en la guía lo prohíbe. En proyectos es normal que el Scrum Master sea también el product owner y suele ir bien. Pero la realidad es que no es recomendable por dos razones: La persona puede tener demasiado trabajo y perder el foco. Puede ocurrir que el equipo Scrum en vez de ser autoorganizado sea dependiente en exceso de la persona que realiza ambos roles. Lo bueno es que la confrontación que podía haber cuando eran personas diferentes desaparece Read the full article

[scrummasterprofesional]

Teletrabajo con SCRUM

En el pasado el COVID obligo a adelantar el teletrabajo 10 años y hoy en día aún muchas empresas lo ofrecen como un plus comparado con otras empresas que no lo ofrecen. Scrum es una metodología preparada para cualquier cambio y que permite a un equipo adaptarse a los cambios con rapidez y entregar valor con pandemias o sin ellas. Scrum es ideal para trabajar de manera remota o con teletrabajo porque permite conseguir organización y transparencia en cada Sprint y esto se nota aún más en equipo que trabajan remotamente. Voy a comentar recomendaciones para los equipos que utilicen Scrum y tenga el mismo intervalo horario.

 Emular lo presencial al máximo

Esta claro que el teletrabajo no es la mejor situación para el trabajo de equipo ni la creatividad de hecho tiene los siguientes problemas: -Problemas de comunicación y mal entendidos entre los miembros del equipo al tener mucha comunicación por escrito donde no se ve las expresiones. – Disminución de la confianza y la colaboración. – Posible perdida de comunicación y sensación de equipo. De hecho para un proyecto para la administración publica donde las personas solo nos conocíamos por internet la sensación de equipo y la cercanía era nula. Por eso es importante hacer reuniones cara a cara entre el equipo al menos 1 vez cada dos semanas sino para trabajar si para realizar reuniones de ocio que ayuden a la confianza y a la colaboración.

Las personas e interacciones son más importantes que los procesos y herramientas a utilizar

Una de las cosas que nos dice el manifiesto ágil es que las personas y los las interacciones están por encima de los procesos y las herramientas. Las herramientas son importantes pero mucho más son las conversaciones útiles que tengamos. Uno de los principios del manifiesto ágil dice que la forma más eficiente de transmitir información es en conversaciones cara a cara. El diagrama de los diferentes modos de comunicación de Alistair Cockburn es bastante ilustrativo en este sentido.

Al no tener posibilidad de hablar cara a cara por culpa del teletrabajo realizar videoconferencias es fundamental, tantas como sean necesarias y en distintos formatos uno a uno, en equipo, cada vez que haya una duda hay que realizar una videoconferencia. Las videoconferencias deben ser algo habitual incluso sin tener que programarlas ni meterlas en el calendario ,pueden realizarse de manera espontanea. Las videoconferencias deben ser útiles y con un objeto claro .

Experimentar con las herramientas

Las interacciones entre los miembros del grupo son importantes pero las herramientas también lo son. Hay herramientas como Jira que nos facilitan la gestión del product backlog, la gestión del flujo de trabajo y las tareas diarias mediante el tablero . Herramientas como Confluence nos permiten tener un sitio para crear la documentación del proyecto, que todos los integrantes del grupo colaboren en su creación y un sitio donde puedan acceder todos los miembros del equipo. En la retrospectiva se puede valorar como han funcionado y crear planes de mejora. El Scrum Master es el que debe liderar la implantación de estas herramientas y su mejora

Las reuniones son importantes

Las reuniones que hay en Scrum son importantes y si lo son en presencial lo son más en el teletrabajo. La daily se tiene que hacer todos los días y a poder ser a la misma hora para acostumbrar al grupo a una rutina. A la reunión de la planificación del Sprint debe ir todo el grupo incluido sobre todo el Scrum Master. La revisión del sprint es fundamental que vaya el cliente. En la reunión de la retrospectiva todos los miembros del equipo deben asistir incluido el Scrum Master para verificar que se apuntan lo que se ha hecho bien y el equipo se compromete a mejorar en lo que no fue bien. Las reuniones en remoto son muy importantes porque indican las pautas a seguir y el trabajo y el equipo debe ser suficientemente maduro e independiente para realizar su trabajo sin excusas.

Visión

Es muy importante tener claro el objetivo del sprint y porque se realizan unas historias de usuario y no otras y es el Product Owner el encargado de esta función. En la planificación del sprint actual el PO debe dejar claro los objetivos del sprint para crear unidad y motivación al equipo.

Responsabilidad individual

Los miembros del equipo deben ser responsables. Deben tener sus rutinas ,su espacio de trabajo pero es la empresa quien debe proporcionar los recursos para realizar teletrabajo ,VPN, Internet, portátil, smartphones, ratones y demás accesorios. El Scrum Master no debe tener que perseguir a los miembros del equipo para que asistan las reuniones ni realicen sus tareas ,eso es de buen profesional. Si una persona no cumple en remoro quizás no debería estar en ese proyecto.

Reglas de equipo

El equipo debe definir claramente a que hora van a comer ,a que hora se hace la daily ,a que hora harán descanso y dejar claro la definición de terminado o DOD. Lo ideal es que sea a la misma hora siempre para tener una rutina y utilizar Slack para las comunicaciones automáticas de herramientas y el correo para comunicaciones formales y mas informales para un chat como Teams. Esto es fundamental en el teletrabajo.

Buenas prácticas

La programación en pares de XP, la revisión de código de herramientas como SonarQube, CI/CD, pruebas unitarias, pruebas de regresión, la automatización de pruebas, mockito para poder realizar pruebas unitarias sin tener todos los componentes terminados. Todo esto ayuda a mejorar el ciclo de desarrollo, aumentar la calidad y disminuir los bugs.

Invertir en formación

Realizar reuniones internas donde se enseñe a otros equipos lo que se ha aprendido con proyectos complejos o utilizar plataformas como Udemy para capacitar a bajo coste a los miembros del equipo Scrum es fundamental para que se cumpla con la mejora continua que busca Scrum.

Buscar más contacto con el cliente

El product owner tiene muchas reuniones con los usuarios o clientes finales y es un momento ideal al ser de manera remoto para que se meta también a miembros del equipo de desarrollo o de calidad para que de primera mano entiendan las necesidades del cliente. Read the full article

[scrummasterprofesional]

Mi libro de scrum:Lectores

Sígueme LinkedIn Hola a todos ,estoy muy alegre porque ya hay compradores de mi libro de scrum que están muy contentos con la compra y que les ha encantado lo completo y actual que es como Alfonso Fernández de O grove

Me comentaba lo siguiente sobre mi libro de scrum: Estoy muy contento con la compra,soy analista de soporte y hace tiempo que quería aprender Scrum ,QA y los conceptos de DevOps.Este libro de scrum es muy didáctico y completo, lo recomiendo totalmente. Alfonso Fernández También Yised Doria Vergara y Vanessa Blánquez Hernández ambas son Consultoras de QA en Itera Process .

Me comentaron lo siguiente mis compis de sector sobre mi libro de scrum: Me ha sorprendido el libro por la cantidad de temas que habla sobre tecnologías que nos demandan en nuestro sector,por eso lo compré, por su temario, me dí cuenta que era muy actual con lo que nos piden en QA donde trabajar con Scrum,DevOps,automatización de pruebas o mockito y pruebas unitárias es algo que nos demandan.Muy contenta con la compra. Yised Doria Estaba pensando en certificarme en Scrum Master porque ya tengo la certificación básica de Scrum y creo que este libro me va ayudar a certificarme.Un libro necesario para toda persona de QA o desarrollo Vanessa Blánquez Otra persona José Pereira Cabezuelo compró mi libro por curiosidad ,él es profesor de Economía en un instituto de Villagarcía pero le apasiona la tecnología y es muy curioso así que se decidió comprar mi libro .

Comentó lo siguiente sobre mi libro: Es un libro fantástico,yo no soy ingeniero en informática pero es tan didáctico que hasta yo que soy economista entendí muchas cosas ,Alejandro sabe explicar muy bien algo que para personas de fuera de este sector de tecnologia podría ser muy complicado de comprender. José Pereira La ultima persona que acepto hacerse la foto fue Roberto ,el es analista de soporte nivel 3 en Viewnext ,podeis ver la foto abajo con su libro todo contento.

Comentó lo siguiente sobre mi libro: El libro me llamo mucho la atencion por tratar de QA,Scrum y de temas de automatizacion de pruebas ,patrones de diseño y,pruebas unitarias y mockito ,es raro encontrar un libro que trate temas de QA,gestion de proyectos ágiles y temas de desarrollo en el libro.Un libro muy completo. Roberto Read the full article

[scrummasterprofesional]

Herramientas de testing que ayudan a ser ágil

Sígueme en LinkedIn Una herramienta de testing es un instrumento automatizado que soporta como mínimo una actividad de prueba aunque suelen ser mas como planificación,control,especificación y ejecución. Estas herramienta se pueden utilizar en cualquier test,tipo de prueba ,fase de desarrollo y ciclo de vida de desarrollo y ayudan a mejorar la eficiencia de los controles de calidad. Las metodologías de desarrollo ágil como scrum,XP o kanban tienen control de calidad y aseguramiento de calidad como otras metodologías iterativas,incrementales o secuenciales pero scrum es una metodología que se enfoca en la entrega continua ,la mejora continua y en aceptar los cambios sobre todo si va a traer valor al cliente por eso hay una serie de herramientas de control de calidad que se utilizan normalmente con esta metodología ágil y que voy a agrupar por el objetivo que tienen.

Tipos de herramientas

Análisis de cobertura de código Mide el % de código que se ha probado ,generalmente el código que hay en un método de una clase ,suele basarse en el número de caminos que se ha ejecutado del código. Este tipo de herramientas dependen del lenguaje de programación en que está escrito el código.  Estas herramientas miden la cobertura que no es mas que el porcentaje de código que se ha ejecutado de un método o de una clase de una librería. Estas herramientas crean informes de cobertura de manera automática. Estas herramientas depende del lenguaje asi para los lenguajes de java y python tenemos: -Clover que es una herramienta de analisis de cobertura de código que soporta los lenguajes de programación de java y groovy;soporta los framework de pruebas de componente Junit y TestNG y además se integra con los Intellij IDEA Y Eclipse. -Pytest-cov es un complemento gratuito de Python que se utiliza para realizar analisis de cobertura de código escrito en este lenguaje y que genera informes de cobertura de código.Lo puedes instalar desde la linea de comandos utilizando pip que es el instalador de paquetes de Python. Son herramientas que se utilizan en las pruebas de componente que se realizan en la metodología de scrum además de en otras metodologías y que son pruebas fundamentales en el control de calidad. y que ayudan a cumplir el principio noveno del manifiesto ágil. Herramientas de testing basadas en modelo Estas herramientas básicamente lo que hacen es generar casos de prueba automáticamente a partir de modelos. Los modelos se pueden representar casi con cualquier cosa como puede ser imágenes,gráficos,diagramas u otros elementos. Lo que es importante es que los requisitos se escriban de una manera que la herramienta los pueda entender. Hay herramientas que además de generar casos de prueba tambien los ejecuta ,una de las herramientas más utilizada para resto es Tricentis Tosca. Es unas herramienta muy completa porque permite automatizar las pruebas de un extremo a otro, diseñar casos de prueba, automatizarlos mediante scripts, diseñar y generar datos para las pruebas, analizar las pruebas y generar informes de las pruebas. Estas herramientas ayudan muchísimo a la hora de realizar las pruebas porque automatiza muchas actividades de pruebas y en metodologías ágiles como scrum la automatización de pruebas y de procesos es fundamental para conseguir ser ágiles y que ayudan a cumplir el principio noveno del manifiesto ágil. Análisis de código fuente Analizan el código fuente antes de ejecutarlo y lo comparan con reglas de buena codificación y generan informes para poder mejorar la calidad del código. Estas herramientas se esta volviendo imprescindibles en metodologías ágiles como scrum porque permiten encontrar defectos y vulnerabilidades en una fase temprana del desarrollo. El noveno principio del manifiesto ágil dice “la atención continua a la excelencia técnica y al buen diseño mejora la agilidad” por lo tanto estas herramientas nos ayudan a eso en cualquier metodología pero en las ágiles aún más porque favorecen la agilidad . La herramienta mas importante de este tipo es Sonarqube,una herramienta que permite analizar la calidad de un código desde un repositorio o desde un IDE, tiene versión de pago y gratuita ,también hay una versión en la nube que se llama SonarCloud, si te interesa un curso de esto en Udemy hay varios. En definitiva estas herramientas ayudan a cumplir el principio noveno del manifiesto ágil. Testing unitario Se prueba que la unidad de componente mas pequeña de un software funciona según lo diseñado, en general prueban los métodos de una clase. Se necesita de un framework y que suele poder integrarse con entornos de desarrollo integrados o IDE. Básicamente lo que se hace es que el programador o tester codifica la prueba que se ejecuta contra el código de la aplicación. Las herramientas de testing mas conocidas para java serían JUnit y TestNG y tambien mockito que se utiliza para simular llamadas a métodos externos. Estas herramientas ayudan a cumplir el principio noveno del manifiesto ágil como las otras. Gestión de incidentes Los defectos se suelen  gestionar en herramientas de gestión de incidencias ;estas herramientas de gestión de incidencias suelen integrarse con herramientas de gestión de proyectos. Suelen tener notificaciones por correo electrónico o a chat de herramientas de comunicación como Teams. La herramienta mas conocida para gestión de incidencias en Mantis ,es de código abierto, gratuita y es una aplicación web que puedes instalar en tu entorno y personalizar. Suele utilizarse para seguimiento de incidencias ,muy utilizada en telecomunicaciones . XRay es la otra herramientas mas utiliza sobre todo en proyectos con scrum u otras metodologías ágiles, se integra con Jira Estas herramientas ayudan a cumplir el principio noveno del manifiesto ágil como las otras. Ejecución de pruebas  Permiten la la creación de scripts de prueba automatizados ,es decir, permiten automatizar la ejecución de los casos de prueba. Estas herramientas se utilizan para ejecutar casos de prueba funcionales y los scripts se pueden crear utilizando un grabador o utilizando algún lenguaje de programación. Estas herramientas de testing son fundamentales para mejorar la agilidad de un proyecto y algunas de ellas son: Cypress. Es abierto, gratuito y se puede integrar con herramientas de CI como Jenkins y soporta los navegadores de Chrome, Edge y Firefox; permite automatizar las pruebas para aplicaciones web pero no soporta pruebas para móviles en mis libros escribo que sí pero no es verdad y no se integra con Appium por lo menos hasta lo que yo se. Esta basado en javascript y es más rápido que Selenium.Selenium Es abierto, gratuito y se puede utilizar con lenguajes como java, python y algunos lenguajes más ;permite automatizar pruebas funcionales y de regresión y soporta los navegadores de firefox, chrome, edge y safari. Permite automatizar pruebas sobre aplicaciones web y de móvil utilizando Appium.

Componentes de Selenium

Selenium IDE permite editar, grabar y depurar lo que se muestra en el navegador. Selenium remote control es un sistema de cliente/servidor que permite utilizar el navegador web de forma local o en otro ordenador. Selenium webdriver permite utilizar un navegador de forma local . Se inicia una instancia del navegador y así se puede controlar y realizar distintas acciones sobre el . Cualquiera de estos lenguajes son compatibles con Selenium WebDriver: PHP, Java, .Net, Perl, Ruby o Python. Selenium grid permite ejecutar varios navegadores a la vez en distintos SO.Permite ejecutar grandes cantidades de pruebas en poco tiempo.UFT Es una herramienta de pago de HP,se puede utilizar con windows y utiliza el lenguaje VisualBasic para automatizar casos de prueba;te permite automatizar pruebas sobre aplicaciones web y móviles.Katalon Studio Es una herramienta que permite automatizar pruebas en aplicaciones web ,escritorio y movil;además soporta los navegadores chrome,firefox,edge y safari y permite automatizar pruebas sobre API´s y importar colecciones de Postman. Se puede instalar en Windows,Linux y MAC y además se integra con todo tipo de aplicaciones como testlink,jira,jenkins y muchos más. Lo mejor que tiene es que pose una plataforma para pruebas online sobre distintos sistemas operativos y moviles y tiene versión gratuita y de pago. Te ha gustado hasta aquí el articulo de herramientas de testing?si quieres saber mas sobre herramientas de testing compra alguno de los libros que puedes ver en este sitio. Read the full article

[scrummasterprofesional]

Teletrabajo con SCRUM

En el pasado el COVID obligo a adelantar el teletrabajo 10 años y hoy en día aún muchas empresas lo ofrecen como un plus comparado con otras empresas que no lo ofrecen. Scrum es una metodología preparada para cualquier cambio y que permite a un equipo adaptarse a los cambios con rapidez y entregar valor con pandemias o sin ellas. Scrum es ideal para trabajar de manera remota o con teletrabajo porque permite conseguir organización y transparencia en cada Sprint y esto se nota aún más en equipo que trabajan remotamente. Voy a comentar recomendaciones para los equipos que utilicen Scrum y tenga el mismo intervalo horario.

 Emular lo presencial al máximo

Esta claro que el teletrabajo no es la mejor situación para el trabajo de equipo ni la creatividad de hecho tiene los siguientes problemas: -Problemas de comunicación y mal entendidos entre los miembros del equipo al tener mucha comunicación por escrito donde no se ve las expresiones. – Disminución de la confianza y la colaboración. – Posible perdida de comunicación y sensación de equipo. De hecho para un proyecto para la administración publica donde las personas solo nos conocíamos por internet la sensación de equipo y la cercanía era nula. Por eso es importante hacer reuniones cara a cara entre el equipo al menos 1 vez cada dos semanas sino para trabajar si para realizar reuniones de ocio que ayuden a la confianza y a la colaboración.

Las personas e interacciones son más importantes que los procesos y herramientas a utilizar

Una de las cosas que nos dice el manifiesto ágil es que las personas y los las interacciones están por encima de los procesos y las herramientas. Las herramientas son importantes pero mucho más son las conversaciones útiles que tengamos. Uno de los principios del manifiesto ágil dice que la forma más eficiente de transmitir información es en conversaciones cara a cara. El diagrama de los diferentes modos de comunicación de Alistair Cockburn es bastante ilustrativo en este sentido.

Al no tener posibilidad de hablar cara a cara por culpa del teletrabajo realizar videoconferencias es fundamental, tantas como sean necesarias y en distintos formatos uno a uno, en equipo, cada vez que haya una duda hay que realizar una videoconferencia. Las videoconferencias deben ser algo habitual incluso sin tener que programarlas ni meterlas en el calendario ,pueden realizarse de manera espontanea. Las videoconferencias deben ser útiles y con un objeto claro .

Experimentar con las herramientas

Las interacciones entre los miembros del grupo son importantes pero las herramientas también lo son. Hay herramientas como Jira que nos facilitan la gestión del product backlog, la gestión del flujo de trabajo y las tareas diarias mediante el tablero . Herramientas como Confluence nos permiten tener un sitio para crear la documentación del proyecto, que todos los integrantes del grupo colaboren en su creación y un sitio donde puedan acceder todos los miembros del equipo. En la retrospectiva se puede valorar como han funcionado y crear planes de mejora. El Scrum Master es el que debe liderar la implantación de estas herramientas y su mejora

Las reuniones son importantes

Las reuniones que hay en Scrum son importantes y si lo son en presencial lo son más en el teletrabajo. La daily se tiene que hacer todos los días y a poder ser a la misma hora para acostumbrar al grupo a una rutina. A la reunión de la planificación del Sprint debe ir todo el grupo incluido sobre todo el Scrum Master. La revisión del sprint es fundamental que vaya el cliente. En la reunión de la retrospectiva todos los miembros del equipo deben asistir incluido el Scrum Master para verificar que se apuntan lo que se ha hecho bien y el equipo se compromete a mejorar en lo que no fue bien. Las reuniones en remoto son muy importantes porque indican las pautas a seguir y el trabajo y el equipo debe ser suficientemente maduro e independiente para realizar su trabajo sin excusas.

Visión

Es muy importante tener claro el objetivo del sprint y porque se realizan unas historias de usuario y no otras y es el Product Owner el encargado de esta función. En la planificación del sprint actual el PO debe dejar claro los objetivos del sprint para crear unidad y motivación al equipo.

Responsabilidad individual

Los miembros del equipo deben ser responsables. Deben tener sus rutinas ,su espacio de trabajo pero es la empresa quien debe proporcionar los recursos para realizar teletrabajo ,VPN, Internet, portátil, smartphones, ratones y demás accesorios. El Scrum Master no debe tener que perseguir a los miembros del equipo para que asistan las reuniones ni realicen sus tareas ,eso es de buen profesional. Si una persona no cumple en remoro quizás no debería estar en ese proyecto.

Reglas de equipo

El equipo debe definir claramente a que hora van a comer ,a que hora se hace la daily ,a que hora harán descanso y dejar claro la definición de terminado o DOD. Lo ideal es que sea a la misma hora siempre para tener una rutina y utilizar Slack para las comunicaciones automáticas de herramientas y el correo para comunicaciones formales y mas informales para un chat como Teams. Esto es fundamental en el teletrabajo.

Buenas prácticas

La programación en pares de XP, la revisión de código de herramientas como SonarQube, CI/CD, pruebas unitarias, pruebas de regresión, la automatización de pruebas, mockito para poder realizar pruebas unitarias sin tener todos los componentes terminados. Todo esto ayuda a mejorar el ciclo de desarrollo, aumentar la calidad y disminuir los bugs.

Invertir en formación

Realizar reuniones internas donde se enseñe a otros equipos lo que se ha aprendido con proyectos complejos o utilizar plataformas como Udemy para capacitar a bajo coste a los miembros del equipo Scrum es fundamental para que se cumpla con la mejora continua que busca Scrum.

Buscar más contacto con el cliente

El product owner tiene muchas reuniones con los usuarios o clientes finales y es un momento ideal al ser de manera remoto para que se meta también a miembros del equipo de desarrollo o de calidad para que de primera mano entiendan las necesidades del cliente. Read the full article

[scrummasterprofesional]

Teletrabajo con SCRUM

En el pasado el COVID obligo a adelantar el teletrabajo 10 años y hoy en día aún muchas empresas lo ofrecen como un plus comparado con otras empresas que no lo ofrecen. Scrum es una metodología preparada para cualquier cambio y que permite a un equipo adaptarse a los cambios con rapidez y entregar valor con pandemias o sin ellas. Scrum es ideal para trabajar de manera remota o con teletrabajo porque permite conseguir organización y transparencia en cada Sprint y esto se nota aún más en equipo que trabajan remotamente. Voy a comentar recomendaciones para los equipos que utilicen Scrum y tenga el mismo intervalo horario.

 Emular lo presencial al máximo

Esta claro que el teletrabajo no es la mejor situación para el trabajo de equipo ni la creatividad de hecho tiene los siguientes problemas: -Problemas de comunicación y mal entendidos entre los miembros del equipo al tener mucha comunicación por escrito donde no se ve las expresiones. – Disminución de la confianza y la colaboración. – Posible perdida de comunicación y sensación de equipo. De hecho para un proyecto para la administración publica donde las personas solo nos conocíamos por internet la sensación de equipo y la cercanía era nula. Por eso es importante hacer reuniones cara a cara entre el equipo al menos 1 vez cada dos semanas sino para trabajar si para realizar reuniones de ocio que ayuden a la confianza y a la colaboración.

Las personas e interacciones son más importantes que los procesos y herramientas a utilizar

Una de las cosas que nos dice el manifiesto ágil es que las personas y los las interacciones están por encima de los procesos y las herramientas. Las herramientas son importantes pero mucho más son las conversaciones útiles que tengamos. Uno de los principios del manifiesto ágil dice que la forma más eficiente de transmitir información es en conversaciones cara a cara. El diagrama de los diferentes modos de comunicación de Alistair Cockburn es bastante ilustrativo en este sentido.

Al no tener posibilidad de hablar cara a cara por culpa del teletrabajo realizar videoconferencias es fundamental, tantas como sean necesarias y en distintos formatos uno a uno, en equipo, cada vez que haya una duda hay que realizar una videoconferencia. Las videoconferencias deben ser algo habitual incluso sin tener que programarlas ni meterlas en el calendario ,pueden realizarse de manera espontanea. Las videoconferencias deben ser útiles y con un objeto claro .

Experimentar con las herramientas

Las interacciones entre los miembros del grupo son importantes pero las herramientas también lo son. Hay herramientas como Jira que nos facilitan la gestión del product backlog, la gestión del flujo de trabajo y las tareas diarias mediante el tablero . Herramientas como Confluence nos permiten tener un sitio para crear la documentación del proyecto, que todos los integrantes del grupo colaboren en su creación y un sitio donde puedan acceder todos los miembros del equipo. En la retrospectiva se puede valorar como han funcionado y crear planes de mejora. El Scrum Master es el que debe liderar la implantación de estas herramientas y su mejora

Las reuniones son importantes

Las reuniones que hay en Scrum son importantes y si lo son en presencial lo son más en el teletrabajo. La daily se tiene que hacer todos los días y a poder ser a la misma hora para acostumbrar al grupo a una rutina. A la reunión de la planificación del Sprint debe ir todo el grupo incluido sobre todo el Scrum Master. La revisión del sprint es fundamental que vaya el cliente. En la reunión de la retrospectiva todos los miembros del equipo deben asistir incluido el Scrum Master para verificar que se apuntan lo que se ha hecho bien y el equipo se compromete a mejorar en lo que no fue bien. Las reuniones en remoto son muy importantes porque indican las pautas a seguir y el trabajo y el equipo debe ser suficientemente maduro e independiente para realizar su trabajo sin excusas.

Visión

Es muy importante tener claro el objetivo del sprint y porque se realizan unas historias de usuario y no otras y es el Product Owner el encargado de esta función. En la planificación del sprint actual el PO debe dejar claro los objetivos del sprint para crear unidad y motivación al equipo.

Responsabilidad individual

Los miembros del equipo deben ser responsables. Deben tener sus rutinas ,su espacio de trabajo pero es la empresa quien debe proporcionar los recursos para realizar teletrabajo ,VPN, Internet, portátil, smartphones, ratones y demás accesorios. El Scrum Master no debe tener que perseguir a los miembros del equipo para que asistan las reuniones ni realicen sus tareas ,eso es de buen profesional. Si una persona no cumple en remoro quizás no debería estar en ese proyecto.

Reglas de equipo

El equipo debe definir claramente a que hora van a comer ,a que hora se hace la daily ,a que hora harán descanso y dejar claro la definición de terminado o DOD. Lo ideal es que sea a la misma hora siempre para tener una rutina y utilizar Slack para las comunicaciones automáticas de herramientas y el correo para comunicaciones formales y mas informales para un chat como Teams. Esto es fundamental en el teletrabajo.

Buenas prácticas

La programación en pares de XP, la revisión de código de herramientas como SonarQube, CI/CD, pruebas unitarias, pruebas de regresión, la automatización de pruebas, mockito para poder realizar pruebas unitarias sin tener todos los componentes terminados. Todo esto ayuda a mejorar el ciclo de desarrollo, aumentar la calidad y disminuir los bugs.

Invertir en formación

Realizar reuniones internas donde se enseñe a otros equipos lo que se ha aprendido con proyectos complejos o utilizar plataformas como Udemy para capacitar a bajo coste a los miembros del equipo Scrum es fundamental para que se cumpla con la mejora continua que busca Scrum.

Buscar más contacto con el cliente

El product owner tiene muchas reuniones con los usuarios o clientes finales y es un momento ideal al ser de manera remoto para que se meta también a miembros del equipo de desarrollo o de calidad para que de primera mano entiendan las necesidades del cliente. Read the full article

[scrummasterprofesional]

Mi libro de scrum:Lectores

Hola a todos ,estoy muy alegre porque ya hay compradores de mi libro de scrum que están muy contentos con la compra y que les ha encantado lo completo y actual que es como Alfonso Fernández de O grove

Me comentaba lo siguiente sobre mi libro de scrum: Estoy muy contento con la compra,soy analista de soporte y hace tiempo que quería aprender Scrum ,QA y los conceptos de DevOps.Este libro de scrum es muy didáctico y completo, lo recomiendo totalmente. Alfonso Fernández También Yised Doria Vergara y Vanessa Blanco Hernández ambas son Consultoras de QA en Itera Process .

Me comentaron lo siguiente mis compis de sector sobre mi libro de scrum: Me ha sorprendido el libro por la cantidad de temas que habla sobre tecnologías que nos demandan en nuestro sector,por eso lo compré, por su temario, me dí cuenta que era muy actual con lo que nos piden en QA donde trabajar con Scrum,DevOps,automatización de pruebas o mockito y pruebas unitárias es algo que nos demandan.Muy contenta con la compra. Yised Doria Estaba pensando en certificarme en Scrum Master porque ya tengo la certificación básica de Scrum y creo que este libro me va ayudar a certificarme.Un libro necesario para toda persona de QA o desarrollo Vanessa Blanco Otra persona José Pereira Cabezuelo compró mi libro por curiosidad ,él es profesor de Economia en un instituto de Villagarcía pero le apasiona la tecnología y es muy curioso asi que se decidió a comprar mi libro .

Comentó lo siguiente sobre mi libro: Es un libro fantástico,yo no soy ingeniero en informática pero es tan didáctico que hasta yo que soy economista entendí muchas cosas ,Alejandro sabe explicar muy bien algo que para personas de fuera de este sector de tecnologia podría ser muy complicado de comprender. José Pereira También estoy muy contento porque mi libro está entre los 100 libros más vendidos en mi categoría Diseño de software,testing e ingeniería.

Por cierto, tengo mi canal de Youtube, los 100 primeros suscriptores entrarán en el sorteo de 5 códigos de promoción de mi editorial Rama para poder acceder a mi libro de scrum en formato de epub ,ve mis videos y dale like te van a encantar! https://youtu.be/9gtjQg7_124 Apúrate a comprar un libro porque se acaban solo queda uno aunque pedirá más Amazon,también si 28 euros es mucho tienen otros libros más baratos que quizás te interesen como los que te muestro abajo. Read the full article