Cómo hacer transición desde cascada a Scrum | Dass Devarajan | Skillshare

Velocidad de reproducción


1.0x


  • 0.5x
  • 0.75x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 1.75x
  • 2x

Cómo hacer transición desde cascada a Scrum

teacher avatar Dass Devarajan, Software professional

Ve esta clase y miles más

Obtenga acceso ilimitado a todas las clases
Clases enseñadas por líderes de la industria y profesionales activos
Los temas incluyen ilustración, diseño, fotografía y más

Ve esta clase y miles más

Obtenga acceso ilimitado a todas las clases
Clases enseñadas por líderes de la industria y profesionales activos
Los temas incluyen ilustración, diseño, fotografía y más

Lecciones en esta clase

    • 1.

      Introducción

      0:59

    • 2.

      Cómo hacer la transición de una cascada a Scrum

      18:17

    • 3.

      Problemas clave a que se enfrenta en la transición

      8:54

  • --
  • Nivel principiante
  • Nivel intermedio
  • Nivel avanzado
  • Todos los niveles

Generado por la comunidad

El nivel se determina según la opinión de la mayoría de los estudiantes que han dejado reseñas en esta clase. La recomendación del profesor o de la profesora se muestra hasta que se recopilen al menos 5 reseñas de estudiantes.

17

Estudiantes

--

Proyecto

Acerca de esta clase

En los años noventa se introdujeron muchos marcos, modelos y métodos para abordar los problemas con el modelo tradicional de cascadas. De todos los marcos y modelos, Scrum es extremadamente popular. Scrum sigue un enfoque iterativo e incremental para el desarrollo.

Scrum es muy adecuado para desarrollar, entregar y mantener productos complejos donde no se conocen los requisitos y es muy probable que ocurran cambios durante el desarrollo.

En esta clase aprenderás 1) cómo hacer una transición del modelo de desarrollo de software tradicional como cascada a Scrum 2) retos clave que muchas organizaciones enfrentan durante el proceso de transición

Conoce a tu profesor(a)

Teacher Profile Image

Dass Devarajan

Software professional

Profesor(a)

I am a software professional with two decades of experience in product development and project management. I have worked for small as well as large organizations, developing large enterprise applications and products, using different technologies and adopting various agile practices.

I started my career as a software programmer developing applications using “C” language. Later, I moved on to Java and spent many years developing various Java based enterprise applications and products, and managing project teams of various sizes.

I obtained my PMP certification from Project Management Institute in 2006. My hands-on experience in various operating systems, languages, technologies, frameworks, tools and techniques combined with my vast managerial experience makes m... Ver perfil completo

Level: All Levels

Valoración de la clase

¿Se cumplieron las expectativas?
    ¡Superadas!
  • 0%
  • 0%
  • Un poco
  • 0%
  • No realmente
  • 0%

¿Por qué unirse a Skillshare?

Mira las galardonadas Skillshare Originals

Cada clase tiene lecciones cortas y proyectos prácticos

Tu membresía apoya a los profesores de Skillshare

Aprende desde cualquier lugar

Ve clases sobre la marcha con la aplicación de Skillshare. Progresa en línea o descarga las clases para verlas en el avión, el metro o donde sea que aprendas mejor.

Transcripciones

1. Introducción: Hola, bienvenidos a este curso sobre cómo pasar de cascada a Scrum. Mi nombre es hace el origen. Qué 25 años de experiencia en desarrollo de productos de software y gestión de proyectos. Si ya conoces los conceptos básicos de Scrum, esta clase te enseñará proceso paso a paso sobre cómo hacer una transición exitosa desde el scrum de cascada. Cada transición tiene sus propios retos. De igual manera, la transición al scrum también ha tenido sus propios retos. Para el final de esta clase, tendrás una buena comprensión tanto del proceso de transición como de los desafíos que te ayudarán a jugar un papel efectivo en el equipo de Scrum. Gracias por ver este video, y espero verte a la brevedad. 2. Cómo cambiar de acuarela a Scrum: Si su organización ha estado siguiendo el modelo tradicional de cascada desde hace bastante tiempo, cambiar de cascada a Scrum no es una tarea fácil. Esta transición, porque estás drásticamente cambio de mentalidad y toma su tiempo, esfuerzo y dinero jurado. En este video, voy a presentar sí. Proceso de diez pasos que puedes seguir para transitar con éxito del agua para esos conteos. Paso número uno, entender la naturaleza de los productos. Entender los productos naturales y el desarrollo y hacer una evaluación realista de ese ahora es uno de los pasos clave determinar si la escoria será o no la elección correcta para su organización. El proyecto se considera un éxito si los requisitos dados se completan a satisfacción del cliente a tiempo y dentro del presupuesto. Como sabrá, cada producto se gestiona teniendo en cuenta tres limitaciones, a saber, alcance, tiempo y costo. A estas se les llama triple restricciones en la gestión de proyectos. Es necesario que el cambio que realice a cualquiera de estas limitaciones tiene un impacto en otras restricciones. Dame un enfoque tradicional. El alcance se fija generalmente con la compensación entre las variables de costo y horario. Pero en Scrum, el horario y costo del alcance fijo se convierte en la variable ya que el alcance es devolver nuestro gusto con cada sprint o lanzamiento. Por lo tanto, la estafa es más adecuada para entregar regularmente con alcance variable. La duración del proyecto es corta. Nuestros requisitos son simples y fijos, entonces la escoria puede no traer muchos beneficios a ese equipo. Por otro lado, si los requisitos del producto son complejos, poco probable que cambien durante el costo de desarrollo, duración del producto es larga y se necesitan liberaciones frecuentes, entonces el implementación efectiva de Scrum ofrecerá muchos beneficios a ese equipo. Paso número dos, superior o consultar coach scrum. Una vez que identifiques Scrum mass, el marco ITIL para el desarrollo de tu producto, el siguiente paso es contratar o asesorar, sí, entrenador de escoria. Con la ayuda del coach scrum, puedes crear una propuesta para tu equipo directivo. Esta propuesta debe cubrir los problemas existentes, respuesta por fallas de los productos y cómo Scrum puede ayudar a las PMs del proyecto a completar el proyecto con éxito. Esta propuesta también debe hablar de nuevos procesos de desarrollo, métodos, herramientas, cambios organizacionales, recursos, escalas, roles, responsabilidades, y requisitos de capacitación que son necesaria para implementar con éxito Scrum. entrenadores de Scrum ayudan a los equipos y empresas a transformarse del trabajo enfocado en productos, también, del trabajo centrado en el producto. El equipo de ayuda y las empresas crean un atraso de productos que impulsa el trabajo en lugar de crear un plan de proyecto más grande. Los entrenadores de escaneo trabajaron con el propietario del producto, ha venido master y ayudarles a crear atraso de sprint, ayudar a los equipos en la realización efectiva de eventos sprint, compartir algunas mejores prácticas en el desempeño de la medida y el propósito de los equipos. Los entrenadores de Scrum son responsables de guiar a los equipos a través del proceso de implementación y brindar todo el apoyo necesario a los equipos de Scrum. Paso número tres, buscar compromiso a la dirección. Una vez que estés listo con tu propuesta, Bienvenido al equipo directivo a través de la propuesta destacando todos los beneficios y desafíos. Buscar commit pen de su administración es extremadamente importante porque implementar scrum requiere una mentalidad completamente diferente. Porque mucho tiempo, esfuerzo y dinero de la organización. Implementar Scrum en una organización que es nueva el desarrollo de productos y no tiene experiencia previa. Es más fácil que hacer lo mismo en una organización donde las personas están bastante acostumbradas a desarrollar productos en un modelo tradicional como la cascada. Educar a nuestro equipo directivo según sea necesario, y atender sus consentimientos. Conseguir ese compromiso, apoyo y aprobación es muy importante. No podrás cosechar los beneficios de Scrum sin involucrar tanto a la dirección como al equipo. Paso número cuatro, identificar un producto piloto y asignar recursos. implementar scrum recomienda encarecidamenteimplementar scrumde manera escalonada. La primera fase sería la fase piloto, donde se puede identificar un producto o un módulo dentro un producto que puede ser desarrollado, probado y entregado de forma independiente. Si el producto, nuestro módulo ya está bajo apretado horario o restricciones de costos, puede que no sea un buen candidato. En cambio, elige el producto, teniendo en cuenta el código de aprendizaje. La duración del proyecto no debe ser demasiado corta ni demasiado larga. Podría tardar por lo menos cuatro a seis semanas evaluar cómo funciona la piel. Elegir personas que ya saben que son Scrum, pueden ser capacitadas en sus principios antes de implementar su proyecto. El equipo de Scrum necesita un individuo de cada departamento o áreas especializadas para que cuenten con todos los registros, conocimiento de casos, apoyo y capacidad de toma de decisiones. Aunque tu equipo scrum puede tener de tres a nueve desarrolladores. Tener un pequeño equipo con el que empezar sería genial. Equipo de phi sería una venta ideal. Asegúrate de que todos estos recursos estén totalmente dedicados a este producto y que no estén trabajando en ningún otro proyecto. Construyendo la fase piloto, el equipo puede ramificar ideas sólidas de productos, planificar cómo implementar su proyecto piloto e identificar los requisitos de capacitación necesarios. Cuanto más trabajen juntos, más fácil irá el proyecto. Paso número cinco, capacita todos los recursos en Scrum. Una amplia capacitación de scram es extremadamente importante para todos los miembros del equipo de Scrum, como el propietario del producto, scrum master , desarrolladores y otras partes interesadas que forman parte del Equipo Scrum. Esta capacitación tiene que ser realizada por el entrenador de Es kommt que tenga experiencia práctica en la implementación de escoria desde cero. Muchas organizaciones piensan que ya están usando Scrum, pero casi están haciendo lo que estaban haciendo antes del scrum. Al seguir utilizando el modelo tradicional donde se pide a los miembros que trabajen en múltiples proyectos con prioridades y plazos conflictivos. Simplemente agregar su reunión diaria de stand-up y usar términos como sprints solo puede Watson el proceso existente. En muchas organizaciones, gerentes de producto que están acostumbrados a administrar productos en su bahía tradicional o que se espera que desempeñen el papel de maestro Scrum con algunos conocimientos superficiales sobre Scrum, ha sido señaló que Scrum Masters y gerentes de proyectos desempeñan diferentes roles. Paso número seis, usar herramientas de automatización como uno de los objetivos en Scrum es mejorar la productividad. Es muy recomendable que utilices herramientas de automatización tanto como sea posible. Por ejemplo, para administrar bedrock y realizar un seguimiento del progreso de todas las historias de usuarios, decidió recomendar que utilice software de su negocio en lugar de usar y distribuir muchas hojas de cálculo. De igual manera, es muy recomendable que use herramientas para diseñar codificación, versión, controlar, verificar la calidad del código, probar y liberar. uso de todas estas herramientas mejora la productividad del equipo de agua al reducir el retrabajo y mejorar la calidad. Asegurar que el miembro del equipo y otros interesados estén capacitados según sea necesario en todas estas herramientas y procesos establecidos dentro de la organización. El primero y más importante escrito para la automatización en pruebas de Scrum es el corto ciclo de desarrollo. Los equipos de Scrum solo tienen un par de semanas para probar en frío e integrar funciones recién agregadas. Si todas las pruebas de su que manualmente, incluso tomará más tiempo que el tiempo de desarrollo real. En muchas ocasiones, es posible que algunas historias de usuarios no se completen dentro de un sprint dado debido a la falta de tiempo para las pruebas. Por otro lado, las pruebas inadecuadas conducen a problemas de calidad. Ven siempre las etapas bienvenidas o los cambios frecuentes necesitan ser probados a fondo. Además, en un cambio que implemente no debe afectar la funcionalidad existente, esto se denomina pruebas de regresión. forma manual. Hacer tales pruebas es aburrido, requiere mucho tiempo y propenso a errores humanos. Capturar a otros rápidamente a través de la automatización permite a los desarrolladores verificar la estabilidad de un código. Se han solucionado los problemas, completa historias a tiempo y cumple con el Objetivo de Sprint. La automatización no debe limitarse únicamente a las pruebas. También debe abarcar otras actividades como la construcción, el despliegue y la liberación. Los procesos y herramientas de automatización pueden reducir significativamente el tiempo de comercialización. Paso número siete, implementa Scrum. Habiendo obtenido la aprobación de la dirección, identificó un proyecto piloto, asignó recursos, identificó herramientas, y completado toda la capacitación necesaria. El siguiente paso sería implementar SCOM. Suave. Sin embargo, se prefiere el sprint de dos semanas. Qué, lo que tenía más tiempo equipo de scrum sprint se espera que siga los principios de agenda, en vivo por los valores de escoria. Atender a toda escoria incluso a tiempo, y realizar sus roles y responsabilidades a su máximo potencial hacia cumplir con el bueno sprint. El equipo de estafa puede crear una hoja de ruta para el trabajo piloto. Y el equipo siempre debe vigilar la hoja de ruta para establecer prioridades, comprender las expectativas y alinearse con los demás. Aunque, el equipo de estafa se autogestiona, no pueden hacer lo que quieran. En cambio, concurrentes entregables en cada sprint. La falta de comunicación puede afectar significativamente estas iniciativas y, en última instancia, conducirá a su producto que no cumpla plenamente con los requisitos de las partes interesadas. Al establecer una clara ln de los equipos de intercambio de conocimientos, usted será capaz de mantenerse al día con todos los cambios y ajustes. Todos los miembros del equipo, independientemente de las reglas, son igualmente responsables entrega exitosa de historias y tareas terminadas. En cada sprint, se espera que cada miembro ayude y apoye a otros miembros en todas las posibilidades para completar el sprint con éxito y cumplir con este gol sprint. Empieza pequeño, haz cambios como más enfermo y establece metas y expectativas realistas. Celebra los éxitos, hitos y logros a lo largo del camino. Paso número ocho, evalúa el rendimiento periódicamente para hacer una comparación precisa antes y después, necesitas tener una idea clara de cómo funcionan las cosas hoy usando algunas métricas clave. Métricas o medidas de evaluación cuantitativa. Si los datos no están disponibles, es importante mirar algunos proyectos recientes y un poco y obtener algunos datos de referencia SES punto de partida. A continuación, puede usar exactamente las mismas métricas para comparar y evaluar la efectividad de la transición. El evento en perspectiva es una gran oportunidad para todos los miembros del equipo de Scrum discutan todos los puntos positivos y áreas de mejora. Todas esas áreas identificadas y aceptadas de mejora deben implementarse en los siguientes Sprint y CLS posibles. Además, buscar retroalimentación periódica de clientes y otras partes interesadas que no participan en el evento retrospectivo sería útil para elegir tu matriz sabiamente. No se quiere tomar una decisión basada en una sola métrica. Tampoco quieres recolectar y medir demasiadas métricas. Estas son algunas de las métricas que puedes considerar. Burndown Sprint. El gráfico de Sprint Burndown muestra cuánto trabajo se ha completado hasta un día determinado y cuánto tiempo está disponible para completar el trabajo restante. Al mirar este gráfico en tu negocio diario, típicamente antes del Daily Scrum, puedes comprobar si el equipo está en horario para completar el gol sprint. Éxito de gol Sprint. Sprint Goal es el único objeto a para el sprint. Este gol sprint se crea durante la planeación sprint y se suma al atraso del sprint definiendo goles sprint y luego midiendo cuántos sprints cumplieron la meta, puede medir cómo con frecuencia se cumplen los objetivos del negocio. Los defectos escapados es la métrica crucial que muestra cuántos errores fueron experimentados por los usos en producción para un lanzamiento dado. Idealmente, sí, el equipo de Scrum debería probar completamente historias y entregar en el otro producto gratuito. Pero en realidad, esto rara vez sucede. Los defectos escapados reflejan la calidad del producto. Velocity muestra el promedio de puntos de historia que el equipo ha completado en sprints anteriores. También se indica de puntos de historia comunista que el equipo puede cometer en el próximo sprint. Además, atrapa el progreso del equipo a través de los gastos. Tiempo de comercialización. tiempo de comercialización es la duración del tiempo desde el consumo de su producto hasta que comienza a proporcionar variados los clientes son, se libera al mercado. retorno del gasto publicitario para este proyecto es el total de ingresos generados por un producto frente al costo de los sprints requeridos para desarrollarlo. Satisfacción del cliente. Hay muchas formas en que el Servicio Connect, comentarios de los reclusos y cuantifican la satisfacción del cliente. Puntuación de satisfacción del cliente, puntuación de esfuerzo del cliente, y una puntuación neta de promotor, o algunas de las formas de obtener la satisfacción del cliente. Elige el que mejor funcione para tu organización, da satisfacción. Llevar a cabo de forma periódica en servicio, podría ver cuán satisfechos están los equipos de Scrum. Paso número nueve, compartió el éxito y construye más equipos. Una vez concluida la fase piloto, comparta la historia de éxito y las lecciones aprendidas con dirección y otros 11 miembros de la organización. Compartir historias de éxito con otros trae los siguientes beneficios que he tenido se obtiene en cuanto a cómo proyectamos ven de manera diferente antes de implementar scrum. Y cómo los equipos ahora son capaces de entregar productos y servicios y resultados a través de una implementación efectiva de un escaneo, demostrando el éxito, se demuestra, la reputación, credibilidad, simplicidad y la confianza de los equipos de Scrum comparten retos a los que se enfrentan y lecciones aprendidas por el trabajo y está en el trabajo realiza el equipo y expresando su gratitud. Se sienten valorados y motivados. Además, confían en ti y te apoyarán en todas las situaciones. Bit more contiene para agregar más valor a su organización. Y clientes. Pasó por diez, hace venir el entrenamiento como parte del programa de inducción. Hacer obligatoria la capacitación de scram para todos sus empleados haría que una organización totalmente adj. Y permiten a los empleados o de la ciudad aprender y adoptar a Scrum desde el principio. Aquí está la lista de todos los pasos que acabamos de mirar. 3. Los retos clave en la transición: transición de un modelo tradicional como la cascada, la escoria tiene muchos desafíos. En este video que ha mirado diez retos clave. Número uno, resistencia al cambio. Esta instancia de cambio se ve a menudo como uno de los principales desafíos. Usted o la gerencia pueden no estar interesados en hacer algo nuevo, lo que requiere una mentalidad diferente. Cambios organizacionales, nuevos roles y responsabilidades, mucho tiempo y esfuerzo, dinero, etcétera Gerentes que prefieren tener buena autoridad, mando y control. ¿ Cuáles son los equipos que pueden no estar dispuestos a ir? Un marco sugiere escoria donde delta Posada empoderó y la autogestión. Tus empleados que no estén dispuestos a aprender y mejorar sus habilidades pueden ayudar a la implementación de Scrum. Falta de conocimiento. Cuando las personas no entienden por qué un Scrum en particular practica necesariamente, los resultados pueden ser impredecibles e ineficaces. Por ejemplo, si el equipo de TI el inicio, entiendo el propósito de tu scrum diario. A menudo terminan brindando tu típica actualización de estado a la persona mayor de edad que participa en el evento. Disgusto general del cambio. Algunas personas, esta es la implementación de Scrum simplemente porque no les gusta el cambio. Número para desarrollarlo equipo verdaderamente empoderado y autogestionado. Scrum. Es que el trabajo en equipo que trae éxito a los miembros del equipo de Scrum se espera que exhiban las siguientes características. Viniendo pintura, enfoque, apertura, coraje, y respeto. Además, cada equipo debe ser multifuncional y autogestionado. Desarrollar un equipo de este tipo no es fácil, sobre todo cuando los miembros, solo están acostumbrados a trabajar y la dirección y control completos de los gerentes de producto en su anterior cascada basada productos. Mucha gente, qué poca o ninguna experiencia con la comunicación abierta y la colaboración. Son muy vacilantes en compartir sus puntos de vista y consentimientos y los no participan activamente en todos esos eventos de Scrum. Para cosechar los beneficios de Scrum, los miembros del equipo necesitan algo de libertad y espacio para construir cosas que quieran. Esto podría ser un reto en una organización donde la micro gestión sigue existiendo. Número tres, falta de disciplina. En un equipo de Scrum. Se espera que todos los integrantes sean altamente disciplinados en cuanto desempeñar el papel de manera efectiva, asumir la responsabilidad de competir, tener comunicaciones abiertas con otros miembros, trabajar en equipo, y asistir a todas las reuniones a tiempo. Necesitas falta de disciplina no ayudará al equipo a cumplir con éxito el Gol Sprint. Número de historias incompletas al final de un sprint. Hay situaciones en las que los desarrolladores en un sprint dado no son capaces de completar las historias de los usuarios a tiempo. Y solicitan al maestro scrum extender la duración de ese sprint en particular. Eso podrían ser muchas razones por las que las historias de usuarios no se completan a tiempo. Algunos de ellos son malentendidos de historias de usuarios. La falta de dominio son técnicamente escalas, estimaciones inexactas, falta de BAM, y cuestiones de calidad. Extender la duración de un sprint en particular puede no motivar a los miembros del equipo. El completo hay unas historias sobre diez. En segundo lugar, la velocidad del equipo se verá sesgada. Número cinco, eventos de Scrum no realizados en diez. Scrum no recomienda a muchos son reuniones innecesarias. Es importante que todos los eventos scrum, sugiere refinamiento de backlog, Sprint Planning, Daily Scrum, Sprint review, y retrospectivas sprint se realicen a tiempo. Y todos los miembros del equipo participan activamente en ellos con base en la regla. Por ejemplo, se espera que el evento de refinamiento atrasado se lleve a cabo en medio de un sprint en curso. que utilice a los estudiantes para el próximo sprint se puede mantener listo si lo estafó retrasa esta reunión. Y los desarrolladores están muy ocupados trabajando en historias de usuarios actuales. que el backlog del producto no tenga suficiente cantidad de historias de usuarios. Para el próximo sprint, y afectará planificación del sprint y progreso fuera de los próximos sprints. Número seis, mezcla, cascada y Scrum. Sin una formación adecuada, dar a los miembros que afirmaron tener alguna experiencia previa en un DJ de otras organizaciones traten de traer sus experiencias y hacer que otros las sigan. En realidad que experimenta la mayor parte de su tiempo, combinación de Scrum, cascada. Y no permite que la organización actual coseche los beneficios de la piedra. Número siete, miembros del equipo que trabajan en múltiples equipos. Pese a que los lípidos, buscando en un equipo de Scrum o se espera que estén completamente dedicados, y no es aconsejable que trabajen en varios equipos a menos que estén ociosos y no tengan historias de usuario para trabajar on. Si los desarrolladores están trabajando en varios equipos, es posible que no puedan enfocarse en una cosa y suelen ser menos producto hacer. Además, será difícil cumplir con el Gol Sprint debido a su no disponibilidad y diversas otras prioridades. Número ocho, esperando rápidamente células, implementando Scrum para los primeros diez en una organización, nos lleva desgastados. Implica muchos cambios organizacionales, dedicación, compromiso, enfoque, capacitación, aprendizaje y continuo de implementar. Todas estas cosas no pueden pasar durante la noche. Puede llevar unos meses a varios meses, dependiendo de cuán efectivamente se implemente y practique la estafa. Esperar rápidamente con las células solo conducirá a la decepción. Número nueve, haciendo que las plantas entiendan a Scrum. Cuando desarrollas tu producto en colaboración con tu cliente que es nuevo en Scrum, siempre es bueno hacerles entender los beneficios de Scrum y cómo te ayudará a entregar con éxito el producto. A las latas suelen gustarles eventualmente los procesos reales porque llegan a revisar los pequeños bits y proporcionar retroalimentación al final de cada sprint. No obstante, educarlos en la gestión procesos más colaborativos al principio podría ser un reto. Número diez, falta de gestión de riesgos. Aunque, el propio Scrum mitiga muchos de estos en el desarrollo de productos o en la gestión de productos, simplemente seguir scrum no garantiza el éxito. Existen muchos riesgos inherentes a los que cada producto está asociado. Es importante que cada organización tenga todavía un buen plan de gestión de riesgos y todos los riesgos potenciales se manejen de manera muy proactiva. Por ejemplo, la alta rotación de empleados es una de las tareas comunes con las que las mini organizaciones cómo lidiar. Podría haber razones como una gran demanda de mercado, tiene salario, nuevas tecnologías, mejores prestaciones para empleados, etcétera por alto volumen de negocios. A menos que se mitiguen dichos riesgos, tendrá un impacto en el propósito ordenado del producto en desarrollo.