La plataforma global e independiente para la comunidad SAP.

Scrum - El papeleo en la era digital

¿Por qué Scrum? Los métodos ágiles -sobre todo Scrum- se han impuesto en el desarrollo de software. Cómo puede aumentar la eficiencia de sus desarrollos SAP con Scrum y mantener siempre una visión de conjunto, incluso en movilidad.
1. octubre 2016
management1610_scrum-1
Este texto ha sido traducido automáticamente del alemán al español.

Miroslav AntolovicHoy en día, es importante reducir al máximo el tiempo de comercialización de los programas informáticos. Especialmente SAP-los proyectos son demasiado complejos para ofrecer una Especificaciones para crear.

En el desarrollo de productos con un enfoque tradicional, a menudo pasan meses o incluso años antes de que se desarrolle un producto. Especificación se ha completado.

E incluso después de la finalización, puede que siga habiendo lagunas y ambigüedades. Pero incluso con un concepto impecable, se corre el riesgo de tener que esperar varios meses (¡o años!) en el mercado o en el Requisitos de sus clientes.

Así pues, entre las principales deficiencias del desarrollo de software tradicional se encuentran las siguientes

  • Pasos de desarrollo demasiado grandes: si el proyecto fracasa o va en la dirección equivocada, nos damos cuenta demasiado tarde.
  • Pensamiento de silo: el departamento especializado y el departamento de desarrollo tienen poco contacto directo.
  • Pérdida de eficiencia: la burocracia y las cargas administrativas obstaculizan la productividad.
  • Problemas de comunicación: Malentendidos o falta de claridad Requisitos se notan demasiado tarde

La causa de estos problemas radica en la modelos de proceso porque son demasiado inflexibles y burocráticos y obligan innecesariamente a todo el equipo a encorsetarse. Esto limita la agilidad y los errores se reconocen demasiado tarde.

En Scrum, no sólo el producto, sino también la planificación se desarrolla de forma iterativa e incremental. Esto da lugar a resultados provisionales ejecutables (incrementos del producto) que pueden presentarse al cliente o al departamento especializado en una fase temprana.

Esta transparencia significa que los Requisitos rápidamente y pueden tenerse en cuenta en la siguiente iteración (llamada sprint).

El Proceso de desarrollo en Scrum

Scrum se basa en un proceso muy simple. En un proceso Scrum solo intervienen tres roles.

El Propietario del Producto proporciona la RequisitosEl Scrum Master desempeña el papel de jefe de proyecto, el Equipo Scrum desarrolla el producto.

Lista de productos pendientes

En el backlog del producto, el Requisitos mantener, ampliar y priorizar.

A diferencia del enfoque clásico con una lista de deberes y Especificaciones La cartera de productos se modifica en función de las necesidades. Esto permite que los nuevos descubrimientos o circunstancias fluyan directamente hacia el desarrollo del producto.

Sirve como única fuente de requisitos para todos los cambios del producto. El backlog del producto enumera todas las características, funcionalidades, mejoras y correcciones de errores que conforman los cambios del producto en futuras versiones; evoluciona con el producto y su uso y no es una estructura rígida como un catálogo de productos. Especificaciones.

Sprint backlog

Un paquete de trabajo, conocido como incremento, se define a partir del backlog del producto a intervalos fijos y regulares.

El incremento se procesa durante el sprint, la pieza central de la metodología Scrum. El backlog del sprint es el conjunto de elementos del backlog del producto seleccionados para el sprint.

El backlog del sprint visualiza todo el trabajo que el equipo de desarrollo tiene que completar para alcanzar el objetivo del sprint.

El sprint

El corazón de Scrum es el sprint, un período máximo de un mes en el que se produce un incremento de producto terminado, utilizable y potencialmente entregable.

El incremento se procesa durante el sprint. Para ello, el incremento se divide en paquetes de trabajo más pequeños, conocidos como tareas, se asignan a un procesador y se estima la carga de trabajo.

Una tarea puede tener un estado definido por el equipo, por ejemplo "Por hacer", "En curso" y "Realizada".

Durante un sprint, todas las tareas se anotan en post-its y se fijan en un tablón de anuncios, el llamado ScrumBoard. Este tablón de scrum se divide en tres columnas, por ejemplo: "Por hacer", "En curso" y "Hecho".

Cada equipo o miembro del equipo marca el progreso del trabajo asignando las notas respectivas al estado correcto en el tablón de anuncios.

En una reunión diaria de 15 minutos, el llamado Scrum Diario, el equipo del proyecto coordina sus actividades para las 24 horas siguientes.

Cada miembro del equipo responde a tres preguntas:

  • ¿Qué he hecho desde el último Scrum diario?
  • ¿Qué tengo previsto hacer antes del próximo Scrum diario?
  • ¿Hubo algo que obstaculizara mi trabajo (impedimentos)?

management1610_scrum-2

Control del progreso hacia un objetivo

Al final del sprint, en la llamada reunión de revisión del sprint, el equipo presenta el resultado y el feedback fluye hacia la planificación del siguiente sprint y el proceso comienza de nuevo.

Este enfoque iterativo le permite reducir al mínimo la falta de Requisitos más rápidamente y definir soluciones con mayor eficacia.

Los ScrumBoards se cuelgan en la pared de una oficina y, por lo tanto, no son muy ágiles y flexibles.

Especialmente en SAP- Los proyectos suelen implicar a tantas personas que no caben en una oficina o el espacio disponible no permite una sala dedicada al equipo.

También hay dificultades logísticas adicionales debidas a Nearshoring- o la deslocalización de componentes.

Una pizarra también resulta ser una herramienta voluminosa y poco práctica para presentar la situación actual en las reuniones con las partes interesadas.

El retraso y el agotamiento suelen Excel-listas, y el progreso del proyecto también se controla manualmente en un Excel-para poder generar un gráfico desplegable.

Alternativa electrónica

Los ScrumBoards electrónicos ofrecen aquí una alternativa sensata, ya que combinan todo el proceso Scrum en una aplicación y cada miembro del equipo tiene acceso a ella en todo momento.

Los "Post-Its virtuales" no pierden su efecto adhesivo y el tablón de anuncios puede volver a utilizarse como tal.

Si las condiciones espaciales lo permiten en una sala de equipo, también puedes mostrar el ScrumBoard electrónico en un televisor o pantalla (táctil) para todos los miembros del equipo.

Scrum en SAP

En un proyecto SAP, sin embargo, estos scrum boards electrónicos tienen la desventaja de que no hay integración en el sistema SAP.

Para optimizar el uso de la metodología Scrum, el ScrumBoard de bsc para la integración de SAP® pueden aumentar considerablemente la eficacia de su equipo.

Al utilizar el moderno framework UI5, nuestro ScrumBoard impresiona con un diseño de interfaz de usuario moderno e intuitivo.

Se maneja fácilmente mediante arrastrar y soltar y permite a los miembros de su equipo realizar sus tareas con mayor rapidez y concentración.

Los organismos de supervisión no tienen por qué prescindir de información esencial y actualizada.

El ScrumBoard digital le ayuda a usted y a su equipo en todas las actividades diarias y en el procesamiento del estado de los proyectos paralelos, la asignación y gestión de nuevas tareas y muchas otras acciones sin añadidos confusos o que distraigan.

Escriba un comentario

Trabajar sobre la base de SAP es crucial para el éxito de la conversión a S/4. 

Esto confiere al centro de competencia una importancia estratégica para los clientes actuales de SAP. Independientemente del modelo operativo de S/4 Hana, temas como Automatización, Supervisión, Seguridad, Gestión del ciclo de vida de las aplicaciones y Gestión de datos la base de las operaciones S/4.

Por segunda vez, E3 Magazine organiza una cumbre para la comunidad SAP en Salzburgo con el fin de ofrecer información exhaustiva sobre todos los aspectos del trabajo preliminar de S/4 Hana.

Lugar de celebración

En breve recibirá más información.

Fecha del acontecimiento

Miércoles 21 de mayo y
Jueves, 22 de mayo de 2025

Entrada anticipada

Disponible hasta el viernes 24 de enero de 2025
390 EUROS sin IVA

Entrada normal

590 EUROS sin IVA

Lugar de celebración

Hotel Hilton Heidelberg
Kurfürstenanlage 1
D-69115 Heidelberg

Fecha del acontecimiento

Miércoles, 5 de marzo, y
Jueves, 6 de marzo de 2025

Entradas

Entrada normal
590 EUR sin IVA
Entrada anticipada

Disponible hasta el 20 de diciembre de 2024

390 EUR sin IVA
El acto está organizado por la revista E3, publicada por B4Bmedia.net AG. Las presentaciones irán acompañadas de una exposición de socios seleccionados de SAP. El precio de la entrada incluye la asistencia a todas las ponencias de la Cumbre Steampunk y BTP 2025, una visita a la zona de exposición, la participación en el acto nocturno y el catering durante el programa oficial. El programa de ponencias y la lista de expositores y patrocinadores (socios de SAP) se publicarán en este sitio web a su debido tiempo.