Un enfoque ágil para la implementación y el soporte de SuccessFactors
Hoy en día vemos que cada vez más empresas se mueven hacia una forma de trabajo ágil, lo que hace que a menudo nuestros clientes soliciten cómo adaptar este enfoque para su implementación de SAP SuccessFactors. ¿Qué significa ser ágil (Agile)? Agile es un enfoque iterativo de la entrega de software que construye soluciones de software de forma incremental desde el inicio del proyecto, en lugar de intentar entregarlo todo de una vez cerca del final.
Hemos observado muchas ventajas para las empresas y los equipos que utilizan el método Agile, como la toma de decisiones al nivel de la experiencia, la potenciación del aprendizaje de las personas y la experimentación de soluciones co-desarrolladas con los clientes. Lea a continuación para saber más.
Proyectos de implantación en la nube
Podemos confirmar que la metodología SAP Activate para la implementación de soluciones SAP SuccessFactors se basa en los principios rectores ágiles.
La hoja de ruta de la implementación está compuesta por fases, entregables y tareas y se ajusta a la metodología y estructura de SAP Activate.
Un aspecto importante de esta metodología es que la aplicación se ejecuta con mayor eficacia si se divide el proyecto en partes más pequeñas de la funcionalidad del usuario y se entregan en ciclos cortos llamados iteraciones.
Modelo de soporte de SAP SuccessFactors
Tras la implementación de SAP SuccessFactors, la mayoría de los clientes pasan a un modelo de soporte. Como se ha dicho en la introducción de este artículo, muchas empresas están pasando a una forma de trabajo ágil. Por lo tanto, es posible que su empresa quiera adoptar el enfoque ágil para todos sus procesos y normas empresariales, incluido el soporte de su sistema SAP SuccessFactors.
HR Path tiene múltiples clientes en los que hemos introducido y mejorado el enfoque ágil para su soporte de SAP SuccessFactors. Como práctica principal, cada ciclo debería comenzar con un evento de planificación trimestral en el que se discutirán, presentarán y acordarán las principales prioridades generales del negocio. Esta será la entrada para su planificación de sprint. Un sprint es una caja de tiempo fija repetible durante la cual se crea un producto “hecho” del mayor valor posible.
Antes de comenzar cualquier sprint, es importante entender la capacidad de su equipo para el próximo período. Como el sprint se centra principalmente en los cambios del sistema, es importante incluir el mantenimiento en curso (incidencias y tareas) también en los cálculos de la capacidad de recursos. El mantenimiento continuo (también denominado “ejecución”) afectará a la disponibilidad de recursos dentro de un sprint. Como práctica habitual, también debería calcular un margen del 20% en cada sprint para circunstancias inesperadas y para la preparación del siguiente trimestre.
Funciones y responsabilidades
Un equipo ágil debe tener un mínimo de cinco y un máximo de once miembros que incluyan:
● Propietario del producto: es el cliente y decide las prioridades. Como principio rector, el sprint comenzará con las historias de usuario indicadas como más importantes y se colocarán en la parte superior del backlog.
● Equipo de desarrollo: está compuesto por miembros multidisciplinares y se organiza por sí mismo. Son responsables del análisis, el diseño, el desarrollo, las pruebas y la documentación, y se asegurará de que el cambio se haya completado al final del sprint para que pueda implementarse en la instancia de producción.
● Scrum Master – guía y apoya al equipo para asegurar que se siga el proceso correcto de scrum. El scrum master facilita todas las reuniones y lugares junto con el hardware y el software. Este papel también es responsable de proteger al equipo de desarrollo para que no se les acerquen otras partes solicitando requisitos adicionales.
Proceso y reuniones
Hay puntos de contacto a lo largo de un sprint que son:
● Planificación del sprint – La práctica principal para cada sprint es un período de dos semanas. Cada sprint debe comenzar con una reunión de planificación con un límite de tiempo máximo de 1 hora. Las historias de usuario más importantes están en la parte superior del backlog del producto y se llevarán al sprint. El equipo de desarrollo se compromete a entregar las historias de usuario al final del sprint. Al final de la reunión del sprint, se sentarán juntos y decidirán quién recogerá qué historias de usuario. Por regla general, las historias de usuario con mayor prioridad deben asignarse primero.
● Diario
Stand-Up diario
Cada reunión debe cumplir los siguientes aspectos:
● Cada participante estará preparado
● Cada reunión comenzará a la hora
● Cada reunión se celebrará diariamente a la misma hora y en el mismo lugar
● La reunión no durará más de 30 minutos
● Los participantes deberán ponerse físicamente de pie, lo que acelerará la duración de la reunión
● Todas las historias de los usuarios se proyectarán en una pantalla
Cada miembro del equipo proporcionará una actualización sobre:
○ Sus historias de usuario asignadas
○ ¿Qué hice ayer?
○ ¿Qué voy a hacer hoy?
○ ¿Hay algún impedimento para el que necesite apoyo o que sea importante que otros miembros del equipo estén informados?
Estas actualizaciones deben ser breves. No se discutirán los detalles.
Revisión / Retrospectiva
La revisión está destinada a las lecciones aprendidas con la intención de mejorar el equipo. Todos los miembros del equipo están obligados a participar. Esta reunión será facilitada por el scrum master después de cerrar cada sprint y puede programarse justo antes de la planificación del nuevo sprint con un límite de tiempo máximo de 1 hora.
Como aportación, se espera que cada miembro del equipo comparta sus ideas sobre el sprint de cierre:
● Stop: algo que no aporta valor, o peor aún, que estorba
● Mantener: algo que el equipo está haciendo bien, y usted reconoce el valor en ello
● Inicio: una idea nueva, o algo que hayas visto funcionar antes y que te gustaría poner sobre la mesa
Las aportaciones pueden agruparse en temas y cada miembro del equipo puede proponer 3 puntos. Los temas con más puntos se seleccionarán como acción y se asignarán a un miembro del equipo que será responsable de elaborar el punto de acción específico.
Uno de los aspectos más importantes de una retrospectiva es también uno de los más desafiantes: los participantes deben ser capaces de hablar libremente hacia una cultura basada en la solución, pero deben entender que no se permite ninguna deuda personal con los demás por ningún retraso.
Refinamiento del backlog
Las historias de usuario en el backlog deben crearse cumpliendo requisitos específicos. Por lo tanto, es fundamental entender los requisitos del negocio utilizando el propietario del producto.
Las historias que siguen siendo imprecisas, como “desarrollar una interfaz de usuario” o “informes de gestión”, pueden dividirse en temas más pequeños, incluyendo, entre otros, “interfaces de usuario para diferentes grupos de usuarios”, “informes financieros” o “informes de RRHH”.
Esto creará la oportunidad de pensar en la(s) mejor(es) solución(es), dando lugar a una estimación más detallada de la solución. También proporcionará la opción de registrar los criterios de aceptación, lo que produce pruebas de aceptación. Tal vez se requiera un análisis adicional, lo que se denomina ”picos”, es decir, se necesita más tiempo para investigar la solicitud de cambio. El backlog suele realizarse hacia el final del sprint en curso. Se trata de un tiempo limitado, normalmente de no más de 2 horas para un sprint de dos semanas. Los equipos también pueden elegir un formato de cuatro reuniones con un máximo de 30 minutos por reunión. En esta reunión participan el propietario del producto y los analistas, y la facilita el scrum master.
El proceso está pensado para tener historias de usuario de alta calidad en el backlog que estén listas para ser recogidas en el siguiente sprint. Tan pronto como se definan las historias de usuario, los participantes deberían poder otorgar puntos en número de 0, 1, 3, 5, 8, 13, 20, 40 y 100. Como equipo, deberían acordar la definición de los puntos por orden de duración del tiempo, pero como práctica habitual, los nuevos equipos podrían empezar proporcionando puntos en función de las horas estimadas. Por ejemplo, a una historia de usuario (cambio) que se estima en tres horas de trabajo se le deberían asignar tres puntos. Como algunos números no se utilizan, como el número dos, se debería trabajar para conseguir uno o tres puntos.
Herramientas
Las historias de usuario deben ser rastreadas en un sistema de tickets como ServiceNow, JIRA, etc. Una historia de usuario puede tener el siguiente estado:
● Backlog
● Spike
● Prioridad y definición
● Sprint
Mientras el sprint no haya comenzado, las historias de usuario del backlog no se asignarán aún a un recurso individual. La asignación individual es una actividad de la propia planificación del sprint y, en la mayoría de los casos, el tema de cierre de la agenda.
Historia del usuario
Una historia de usuario es una descripción informal en lenguaje natural de una o varias características de un sistema de software. Las historias de usuario suelen escribirse desde la perspectiva de un usuario final o de un usuario de un sistema. Una historia de usuario debe tener el siguiente formato:
● Formato > Como (rol/usuario), quiero (función/acción), así que (objetivo/valor para el rol/usuario)
● Discutir y capturar los detalles de las historias de los usuarios
● Crear criterios de aceptación y una definición de Hecho
Vea a continuación un ejemplo de ritmo de sprint:
Proceso de implementación de los cambios de SAP SuccessFactors
Al implementar los cambios de SAP SuccessFactors en la instancia de producción, siempre recomendamos algunas de las prácticas principales mencionadas a continuación. Esto debería resultar en cambios debidamente documentados y un comportamiento de implementación controlado:
● Todos los cambios solicitados deben ser registrados en una herramienta de tickets. Las empresas deben entender y aceptar este requisito antes de solicitar cualquier cambio.
● Las solicitudes a otros equipos dentro de una historia de usuario específica deben registrarse como una tarea en el sistema de tickets y luego asignarse a ese otro equipo.
● Todos los cambios de SAP SuccessFactors deben configurarse primero en la instancia de desarrollo antes de pasar a la instancia de calidad y, finalmente, implementarse en la instancia de producción.
● Las responsabilidades dentro del equipo deben ser claras en lo que respecta a la configuración, las importaciones, el análisis (causas raíz), las pruebas (principio de los cuatro ojos) y la comunicación con el usuario.
● En cada comunicación por correo electrónico, debe incluirse el número de cambio y el tema para evitar cualquier error.
● Cada cambio requiere una prueba de configuración. En función del tipo de cambio, puede tratarse de una prueba sencilla que incluya únicamente una captura de pantalla, o de una prueba exhaustiva para cambios más complejos.
● Cada cambio requiere una prueba de aceptación del usuario.
● Toda la documentación relacionada con el cambio debe guardarse. La mayoría de las herramientas de gestión de tickets ofrecen la posibilidad de cargar documentos.
● Cada cambio debe ser revisado por otro miembro del equipo antes de implementarlo en la instancia de producción. La integración interna y externa y el impacto futuro en otras funcionalidades son aspectos importantes en esta revisión.
● En la medida de lo posible, los cambios deben ser liberados en un día fijo y siempre comunicados a la empresa cuando se liberen en la instancia de producción.
¿Desea obtener más información sobre el uso eficaz del enfoque ágil para su SuccessFactors Support?
Como SAP Gold Partner, ayudamos a nuestros clientes a desarrollar su equipo utilizando un enfoque ágil. Póngase en contacto con nosotros a través del siguiente formulario para hablar de sus necesidades.
