Inicio chevron_right Blog chevron_right Scrum Master en Platzi: lo que aprender metodologías ágiles cambió en cómo gestiono proyectos
Estrategia schedule 5 min de lectura

Scrum Master en Platzi: lo que aprender metodologías ágiles cambió en cómo gestiono proyectos

Hacer el curso de Scrum en Platzi no fue para conseguir un certificado. Fue para tener un lenguaje común con los equipos y clientes que trabajan con metodologías ágiles, y para sistematizar lo que ya hacía de forma intuitiva.

person

OSCARLEON

OSCARLEON

Compartir

Los proyectos de desarrollo web tienen una particularidad que los hace difíciles de gestionar con metodologías rígidas: los requisitos cambian. El cliente ve el primer prototipo y se da cuenta de que quería algo diferente. El diseño que parecía perfecto en wireframe no funciona igual con contenido real. Las prioridades del negocio cambian a mitad del proyecto.

Scrum existe, entre otras razones, para gestionar exactamente ese tipo de cambio sin que el proyecto descarrile. El curso de Platzi me dio el framework formal para lo que ya hacía de forma parcial e inconsistente.

Lo que Scrum resuelve que los proyectos de precio cerrado no resuelven

El modelo de proyecto de precio cerrado y alcance fijo tiene un problema estructural: asume que el cliente sabe exactamente lo que quiere desde el inicio. En la práctica, los clientes descubren lo que quieren a medida que ven el trabajo tomar forma. El modelo de precio fijo convierte cada cambio en una negociación incómoda.

Scrum — o adaptaciones de Scrum — maneja esto con sprints cortos: períodos de 1-2 semanas donde se define un alcance pequeño, se ejecuta, se revisa con el cliente, y se ajusta la dirección. El cliente ve progreso constante y puede redirigir sin que cada cambio sea un conflicto.

Lo que adapté de Scrum para proyectos con clientes no técnicos

Scrum puro está pensado para equipos de desarrollo internos. En proyectos con clientes que no son técnicos, hay que adaptar la ceremonia. Los daily standups no tienen sentido con un cliente externo. El backlog tiene que estar en lenguaje de negocio, no en jerga técnica. Las demos de sprint tienen que mostrar algo que el cliente pueda evaluar sin conocimiento técnico.

La adaptación que uso: sprint de 2 semanas, reunión de inicio con alcance acordado por escrito, demo al final con el cliente, y retrospectiva interna. Eso da estructura sin generar burocracia innecesaria para proyectos de pequeña y mediana escala.

¿Querés saber cómo gestionamos los proyectos?

El proceso es parte de lo que hace que los proyectos lleguen a tiempo y sin sorpresas. En la consulta inicial explicamos cómo trabajamos y qué podés esperar en cada etapa.

Lo más valioso del curso: el lenguaje compartido

Muchos de los clientes con los que trabajo tienen equipos internos que trabajan con Scrum o con Kanban. Tener el lenguaje — backlog, sprint, velocity, user story, definition of done — hace que la coordinación sea más fluida. No tengo que explicar conceptos básicos de gestión de proyectos ágiles en cada reunión.

También ayuda cuando hay que integrarse con el equipo de desarrollo interno del cliente — saber qué significa "este ticket está en el sprint" o "lo pasamos al backlog para el próximo ciclo" sin tener que preguntar.

La certificación de Scrum Master está en mi página de certificaciones junto con la de Profesional de Scrum. Si querés entender cómo aplicamos estas metodologías en proyectos concretos, hablemos.

¿Te fue útil este artículo?

arrow_back Volver al blog

Recibe más artículos como este

Únete a más de 2,000 lectores que ya reciben nuestro contenido semanal.

¿Hablamos de tu proyecto?