Dentro del mundo de desarrollo de aplicaciones hay varias fases importantes, da igual la metodología que apliquemos, sea Waterfall, Agile, SAP Activate o cualquiera. Siempre hay que Analizar el requerimiento, proponer soluciones, implementarlas y finalmente probarlas para validarlas y ponerlas en producción.
Vamos a ver el trabajo que se tiene que hacer por parte de los testers, probadores o validadores de la calidad del producto entregado. Veremos que hay varias capas de equipos de pruebas para asegurar la calidad final y cual es la labor de cada uno de ellos.
Eeeeeh, no, no me refiero a estos «probadores»
Por un lado tenemos los equipos de Calidad, QA y QC, por otro lado tenemos las pruebas de aceptación de usuario, las UATs. Y he dicho QA/QC pero eso no es un grupo de rock australiano. Se trata de dos siglas de dos equipos de trabajo en proyectos, ya sean de consultoría o de fabricación de batamantas.
QA – Quality Assurance
QC – Quality Control
Hard as a rock
Si bien se confunden entre sí, son dos equipos con tareas y objetivos distintos. Vamos a verlos.
¿Qué es Quality Assurance (QA)?
El Quality Assurance (QA) es básicamente un conjunto de acciones planificadas que se implementan durante el desarrollo de un producto, especialmente en software, para asegurar que todo funcione como debería antes de que llegue a las manos del cliente. ¿Cómo lo hace? Revisando y mejorando los procesos en cada fase: desde que se planea y diseña el producto, hasta su desarrollo, pruebas y despliegue. De esta manera, se minimizan los errores y se garantiza que el producto cumpla con los estándares de calidad esperados. Por lo general, en proyectos de tipo Waterfall, donde las fases son secuenciales y están muy delimitadas, se hace más énfasis es en la fase de pruebas.
De hecho en la mayoría de proyectos donde existe un equipo de QA, este se circunscribe únicamente a probar el software, eso sí, con la visión de control de errores, experiencia de usuario (UX) y pruebas de ciclo completo de integración entre sistemas. Lo cual hace que hay un equipo denominado de QA que realmente esté haciendo labores de Quality Control (QC).
¿Qué es Quality Control (QC)?
Quality Control (QC) es el proceso mediante el cual se revisa y evalúa el producto final para asegurar que cumpla con los requisitos de calidad establecidos.
El objetivo principal del QC es identificar cualquier fallo o discrepancia en el producto antes de que llegue al cliente, lo cual se logra mediante diversas pruebas, inspecciones y evaluaciones. Estas revisiones pueden incluir desde pruebas funcionales hasta revisiones visuales y de rendimiento. Si se encuentran problemas, estos se corrigen antes de lanzar el producto al mercado.
En resumen, QC se asegura de que el producto que se entrega al cliente final sea de alta calidad, revisando el resultado después de que todas las fases de desarrollo han sido completadas.
Diferencia entre Quality Assurance (QA) y Quality Control (QC)
Aunque suenan parecidos, Quality Assurance (QA) y Quality Control (QC) no son lo mismo. QA se encarga de que todo vaya bien desde el principio: se preocupa de que el proceso de desarrollo sea sólido para evitar que haya errores. QC, por otro lado, entra en acción cuando el producto ya está listo y se centra en revisar si hay problemas o defectos que se escaparon. Piensa en QA como el entrenador que te prepara para evitar errores, mientras que QC es el árbitro que señala los fallos cuando ya está todo en juego. QA trata sobre el proceso, y QC, sobre el resultado final.
No obstante, dentro de uno hay un poco del otro y viceversa, como el yin y el yang de la gestión de calidad. Pero cada uno tiene un objetivo marcado. Aunque en ocasiones no sepamos llamar a las cosas por su nombre.
¿Qué son las UAT – User Acceptance Testing?
Las UAT (User Acceptance Testing), o pruebas de aceptación de usuario, son un tipo específico de pruebas realizadas al final del ciclo de desarrollo de software que se realizan para validar que el producto cumple con los requisitos y expectativas del usuario final o del cliente. Es el último paso antes de que el producto se implemente o se lance oficialmente.
Para mi es imprescindible que el cliente tenga perfiles especializados que hagan de enlace entre el negocio, sus peticiones de desarrollo de software y el equipo implementador. Es necesario que estos usuarios expertos sepan cómo funciona el negocio, las expectativas y cómo funciona la tecnología a aplicar. Sin estas pruebas no debe pasarse nada a producción.
En conclusión
Como hemos dicho con la metáfora del yin yang, QA y QC comparten algunas tareas, lo mismo pasa en las pruebas (de integración, UATs, etc.). Las tareas de pruebas de calidad de QC también pueden realizar se en QA y las pruebas de validación de usuario UAT son parte del control de calidad del resultado final.
Esto no se ha hecho con IA, se ha hecho con WordArt. A veces menos es mejor.
En un mundo ideal todo esto tendría que ser tal y cómo lo hemos explicado, tendría que haber un equipo de QA que controlase que cada parte del proyecto se realice con la calidad adecuada. Si lo piensas bien, en la mayor parte de las ocasiones esto recae en el jefe de proyecto o, incluso, en los propios consultores. Mantener documentada la toma de análisis (actas de reunión, etc), el diseño (documentos de diseño bien definidos), la implementación (plan de desarrollo, buenas prácticas, limpieza, encapsulamiento y reutilización de código) y la entrega (plan de pruebas, plan de cutover y plan de Go-Live). Pero si hubiese una figura velando porque esto se realice correctamente, estaría todo más ordenado. La parte del QC y UAT suele ser más común verlo de una forma u otra.
Por último un chiste sobre el tema que me ha parecido muy gracioso.
Hoy en, anglicismos para parecer más cool (otro), vamos a explicar qué es eso de Proof of Concept. En castellano «Prueba de Concepto» o, más comúnmente llamado, «piloto».
Ya no hay pilotos como antes (si reconoces esta imagen estás en mi equipo)
¿Qué es Proof of Concept?
Hay veces que, ante una necesidad de un cliente, para satisfacerla a nivel tecnológico, sucede alguna de estas situaciones:
Incertidumbre tecnológica: No está clara la tecnología a aplicar
Evaluación de soluciones: No está clara la mejor de las soluciones de entre las propuestas
Costes elevados: El coste de implementar la solución es muy elevado
Resistencias internas: Hay resistencias por parte de los key users, dirección u otras áreas.
Si sucede alguna de estas situaciones una solución habitual es hacer una prueba de concepto (Proof of Concept) o piloto.
Un Proof of Concept o Prueba de Concepto es el implementar una solución acotada de la solución final. La forma de acotar puede variar dependiendo del contexto y los objetivos, pero generalmente implica reducir la escala del proyecto, simplificar funcionalidades y/o limitar el tiempo y recursos asignados. Y, en el caso de herramientas estándar, como SAP, minimizar al máximo, o incluso evitar cualquier desarrollo o ampliación, intentando enseñar como la herramienta estándar se adapta a las necesidades del negocio.
Resumiendo, lo más normal en una PoC es tomar un escenario aislado, dentro de todas las necesidades del cliente, y montarlo en la tecnología seleccionada como prueba del potencial a obtener si se implementa la solución completa para toda la necesidad.
Objetivos de un Proof of Concept
Una vez sabemos el qué es y el porqué, vamos a ahondar en cuales son los objetivos de realizar una PoC.
Validar la viabilidad técnica: Verificar si la tecnología propuesta es capaz de cumplir con los requisitos y expectativas del proyecto.
Identificar problemas y riesgos: Detectar posibles inconvenientes técnicos, organizativos o de otro tipo que puedan surgir durante la implementación.
Demostrar el valor de la solución: Proporcionar evidencia tangible de que la solución propuesta puede resolver el problema del cliente y ofrecer beneficios concretos.
Obtener retroalimentación: Recoger opiniones y comentarios de los usuarios clave y otras partes interesadas para ajustar y mejorar la solución antes de su implementación completa.
Pasos para desarrollar un Proof of Concept
Ya sabemos el qué, el porqué y el para qué, ahora vamos a ver el cómo. Para ello, como ejemplo, podemos proponer los siguientes pasos:
Definir los objetivos y el alcance: Establecer claramente qué se pretende lograr con la prueba y cuáles son los límites del proyecto piloto.
Seleccionar las herramientas y tecnologías: Elegir las tecnologías y herramientas que se utilizarán en la prueba de concepto.
Desarrollar un prototipo: Crear una versión simplificada de la solución final que permita realizar las pruebas necesarias.
Realizar pruebas y recopilar datos: Ejecutar la prueba de concepto y recopilar información relevante sobre su desempeño.
Analizar los resultados: Evaluar los datos recopilados para determinar si la prueba de concepto ha cumplido con los objetivos planteados.
Tomar decisiones informadas: Basándose en los resultados, decidir si se procede con la implementación completa, si se requieren ajustes, o si se debe reconsiderar la solución propuesta.
Riesgos de hacer una Prueba de Concepto (PoC)
Al hacer una PoC todas las partes implicadas tienen que estar alineadas con los requisitos, el alcance, la funcionalidad a implementar y las espectativas del resultado.
Entre los riesgos que hay que controlar cuando queremos hacer una PoC están:
Alcance mal definido: Como he comentado anteriormente, es crucial acordar. entre todas las partes, un alcance claro de cara, no solo a su implementación, sino también de las expectativas y demostración de funcionalidad potencial.
Alcance no relevante para el negocio: Una PoC sin sustancia suficiente no vale para que el negocio vea el potencial de la solución final
Alcance no claro: Habrá problemas con las expectativas de las partes. Desde el famoso «yo tenía un excel que hacía más cosas» hasta el «¿y esto no lanza la nómina de este mes?»
Alcance justo: No un alcance sin sustancia ni un alcance que sea ya la solución definitiva. Se trata de hacer un piloto, muchas cosas no funcionarán, porque no tendrán que funcionar.
Recursos insuficientes: Vamos, que te dejan a ti solo a hacer una PoC de un alcance que supone mucho trabajo. Tampoco está bien poner un equipo de 20 personas.
Dependencia de prototipos: Cuidado con ir montando la solución en base a prototipos o PoCs. La prueba de concepto ha de ser la llave de entrada al análisis, diseño e implementación de una solución final, robusta y funcional.
Falta de aceptación del usuario: Puedes ponerlo de colores, con música o con Gifs animados de gatitos. Puedes hacer una PoC perfecta, que satisfaga ese área del negocio acotado. Pero si no tienes a los usuarios/negocio apostando por ello, le buscarán los problemas. Ahora bien, mejor identificar estos problemas en una PoC que en un arranque a producción.
Problemas de integración: El eterno problema, es una PoC, hay que minimizar al máximo cualquier desarrollo. ¿Nos integramos con otros sistemas? Pues hay ocasiones en las que no hay más remedio si quieres que el negocio se sienta identificado. Hay que definir muy bien qué integraciones son necesarias e incluso posibles, puesto que en ocasiones las PoC se desarrollan fuera del ámbito tecnológico del cliente.
Conclusión
Las Proof of Concept, PoC o Prueba de Concepto son nuestros aliados, y cuando digo nuestros hablo de todos, Consultores, TI del cliente y negocio. Debe ser una palanca de cambio que nos ayude a ponernos en situación y poder evolucionar el negocio a nuevas metas tecnológicas.
Desde el punto de vista de la consultoría nos sirve como palanca para abrir negocio, poder mostrar nuestras capacidades y las de la solución, y la posibilidad de adaptación que tanto la solución como nosotros podemos aportar para conseguir satisfacer las necesidades del negocio.
Ahora vamos a ver una metodología de gestión de proyecto propia de SAP para el paso ágil a SAP S/4HANA. Vamos a ver SAP Activate.
¿Qué es SAP Activate?
SAP Activate es una metodología que ha sido desarrollada por SAP allá por el 2015 (Sí, 9 años he tardado en escribir esto) para proporcionar un enfoque estandarizado y ágil para implementar soluciones SAP. Este enfoque incluye las mejores prácticas, metodologías ágiles y herramientas de última generación para ayudar a las organizaciones a implementar soluciones SAP de manera más rápida y eficiente, minimizando los riesgos y maximizando el retorno de la inversión.
Si te quieres ahorrar leer este artículo hay varias referencias oficiales y/o útiles para conocer esto del SAP Activate.
SAP Activate es una metodología compuesta por tres elementos principales:
Best Practices (Mejores Prácticas)
SAP ha compilado una serie demejores prácticas que son específicas para diferentes industrias y procesos. Estas mejores prácticas son plantillas de configuración que permiten a las empresas implementar sus soluciones más rápidamente y con menos riesgos.
Se refiere a las herramientas y recursos que SAP proporciona para facilitar la configuración de las soluciones. Esta configuración guiada permite que las organizaciones configuren sus sistemas de manera ágil, asegurando que se adhieran a las mejores prácticas y a los estándares de la industria.
Agile Methodology (Metodología Ágil)
SAP Activate adopta un enfoque ágil para la implementación de soluciones, lo que permite a las organizaciones adaptar y ajustar sus procesos durante el proyecto, en lugar de seguir un enfoque rígido y secuencial.
Fases de SAP Activate
La metodología SAP Activate, como se ha comentado anteriormente, es una metodología Ágil y está organizada en seis fases clave:
Discover (Descubrimiento)
En esta fase, se analiza la viabilidad del proyecto. Las organizaciones evalúan las soluciones disponibles, identifican sus necesidades y definen el valor que pueden obtener de la implementación de SAP.
Prepare (Preparación)
En esta fase se establecen los fundamentos del proyecto, incluyendo la formación del equipo, la planificación inicial y la preparación de los recursos necesarios.
Explore (Exploración)
En esta fase, se realiza un análisis detallado de las necesidades del negocio y se exploran las diferentes soluciones de SAP que pueden satisfacer esas necesidades. Las configuraciones iniciales también se establecen durante esta fase.
Realize (Realización)
Esta es la fase de ejecución, donde las soluciones se configuran, prueban y ajustan según los requisitos del negocio. Los datos se migran y se realizan pruebas exhaustivas para asegurar que todo funcione según lo planeado.
Deploy (Despliegue)
En esta fase, la solución se pone en marcha en el entorno de producción. Se realizan pruebas finales, capacitaciones para los usuarios finales y se asegura que todo esté listo para la operación en vivo.
Run (Operación)
Una vez que la solución está en producción, comienza la fase de operación y soporte. SAP proporciona herramientas y recursos para monitorear el sistema, solucionar problemas y optimizar el rendimiento.
Herramientas ejecutar un proyecto SAP Activate
Para implementar un proyecto y seguir la metodología SAP Activate, SAP proporciona una serie de herramientas recomendadas para cada fase del proyecto.
SAP Solution Manager
¿Qué voy a decir de Solution Manager? Es una plataforma integral que proporciona soporte durante todo el ciclo de vida de las aplicaciones SAP, desde la implementación hasta el uso en producción. Facilita la gestión de cambios, pruebas, documentación de procesos, y el monitoreo de sistemas.
Todo esto sobre el papel está genial, lo que yo he solido usar no suele estar bien pensado o bien implementado.
SAP Cloud ALM (Application Lifecycle Management)
A grandes rasgos y como un resumen rápido podemos decir que es una heerramienta en la nube que soporta la gestión de proyectos y el ciclo de vida de las aplicaciones SAP, ideal para implementaciones en entornos Cloud.
SAP Best Practices Explorer
Se trata de un portal que permite explorar y acceder a las mejores prácticas de SAP específicas para diferentes industrias y procesos de negocio. Es esencial para la configuración inicial de soluciones SAP. Lo hemos visto en la parte de Elementos Principales de SAP Activate y podemos acceder a este portal en el SAP Best Practices Explorer.
SAP Central Business Configuration
Es una herramienta diseñada para configurar de manera centralizada los procesos de negocio en SAP S/4HANA Cloud, facilitando la adopción de SAP Best Practices.
Tricentis for SAP
Conjunto de herramientas para la automatización de pruebas dentro de proyectos SAP, que complementa la metodología SAP Activate asegurando calidad y estabilidad en las implementaciones.
SAP Roadmap Viewer
Una herramienta que proporciona una visión estructurada y personalizada de las hojas de ruta de implementación dentro de SAP Activate. Ayuda a los equipos de proyecto a seguir un plan claro y adaptado a las necesidades de su solución SAP. Podemos acceder a los Roadmaps disponibles en la web:
Se trata de un conjunto de herramientas que facilita el modelado, gestión y optimización de procesos de negocio. Es particularmente útil en las fases de Explore y Realize de SAP Activate, donde se necesita entender y mejorar los procesos empresariales. Esto, en sí mismo, ya tiene miga como para explicarlo pormenorizadamente.
En conclusión
Lo que antes era la metodología de gestión de proyectos ASAP (Acelerated SAP) pasó a evolucionar a SAP Activate, siendo ambas opciones válidas, pero siendo Activate la idónea para entornos S/4Hana y tecnologías SAP modernas.
Yo, y supongo que casi todos, estoy mucho más acostumbrado a metodologías Waterfall como ASAP. Pero hay que estar atento las formas de gestión de proyecto que tenemos encima de la mesa para saber aprovecharnos de sus ventajas.
Vamos a hablar de una de las metodologías de gestión de proyectos y desarrollo de software que más se ha estado usando y de la que vamos a analizar y definir para tener una idea global de sus características, ventajas e inconvenientes. Hablaremos de las metodologías Agile (a·jile).
Agile es un conjunto de metodologías de gestión de proyectos y desarrollo de software que se centra en la entrega incremental, la colaboración entre equipos multifuncionales y la adaptación constante al cambio. Surgió en 2001 con la publicación del Manifiesto Ágil, creado por un grupo de 17 desarrolladores de software que buscaban una alternativa más eficiente y flexible a las metodologías tradicionales como Waterfall. Desde entonces, Agile ha ganado popularidad no solo en el desarrollo de software, sino también en diversas industrias que valoran la capacidad de respuesta rápida y la mejora continua.
Se nota que priorizan que funcione la web a que sea bonita…
Individuos e interacciones sobre procesos y herramientas
Priorizar la comunicación y colaboración efectiva entre los miembros del equipo por encima de seguir procesos rígidos y usar herramientas específicas. Con esto se facilita la adaptabilidad, aumenta la motivación del equipo y fomenta la innovación. En ocasiones damos más valor al uso de herramientas y estándares para organizar el equipo y el trabajo, esto hace que perdamos mucho tiempo de valor y genere desmotivación y hartazgo.
Software funcionando sobre documentación extensiva
Este valor prioriza la entrega de software funcional que cumpla con los requisitos del cliente sobre la creación de documentación extensa. Si bien la documentación es necesaria, en Agile se considera más importante que el software funcione correctamente y aporte valor al usuario final. La documentación debe ser suficiente para apoyar el desarrollo y el mantenimiento, pero no debe convertirse en un fin en sí misma.
Colaboración con el cliente sobre negociación de contratos
En lugar de centrarse en la negociación de contratos detallados, Agile promueve la colaboración continua con el cliente. Esto significa que los clientes están involucrados activamente en el proceso de desarrollo, proporcionando feedback constante y participando en la toma de decisiones. La colaboración permite al equipo ajustarse mejor a las necesidades del cliente y responder rápidamente a los cambios.
Respuesta ante el cambio sobre seguir un plan
Este valor destaca la importancia de ser flexible y adaptarse a los cambios en lugar de seguir estrictamente un plan predeterminado. En un entorno ágil, se espera que los requisitos evolucionen y cambien a lo largo del proyecto. Los equipos ágiles están preparados para ajustar sus planes y procesos para acomodar estos cambios y maximizar el valor entregado.
Principios de Agile
Además, establece 12 principios que guían las prácticas Agile:
Satisfacer al cliente mediante entregas tempranas y continuas de software valioso.
Aceptar cambios en los requisitos, incluso en etapas avanzadas del desarrollo.
Entregar software funcional con frecuencia, desde un par de semanas hasta un par de meses.
Colaboración diaria entre desarrolladores y el negocio.
Construir proyectos alrededor de individuos motivados, y proporcionarles el entorno y el soporte que necesitan.
El método más eficiente y efectivo de transmitir información es la conversación cara a cara.
El software funcional es la medida principal del progreso.
Los procesos ágiles promueven el desarrollo sostenible.
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo y ajusta su comportamiento en consecuencia.
Metodologías Agile Populares
SCRUM
Scrum es una metodología ágil que se centra en entregas incrementales de productos a través de iteraciones cortas llamadas sprints. Los elementos clave de Scrum incluyen:
Roles en Scrum
Scrum Master
Facilita el proceso Scrum, asegura que todos comprendan y sigan los principios de Scrum, elimina impedimentos y ayuda a mejorar la productividad del equipo. Organiza eventos Scrum, optimiza la gestión del backlog y colabora estrechamente con el Product Owner.
Product Owner
Representa los intereses del cliente o negocio, define y prioriza los requisitos del producto. Gestiona el Product Backlog, documenta y prioriza las necesidades y responde a las preguntas del equipo de desarrollo.
Equipo de Desarrollo
Entrega incrementos de producto potencialmente utilizables al final de cada Sprint. Equipos autoorganizados y multifuncionales, responsables de sus éxitos y fracasos.
Eventos en Scrum
Sprint
Periodo de tiempo fijo (un mes o menos) en el que se crea un incremento de valor. El propósito es mantener al equipo enfocado y permitir ajustes basados en la retroalimentación.
Sprint Planning
Evento que define lo que se puede entregar en el Sprint y cómo se logrará. Seleccionar y planificar el trabajo del Product Backlog para el Sprint actual.
Daily Scrum
Reunión diaria de 15 minutos para inspeccionar el progreso hacia el objetivo del Sprint y ajustar el plan de trabajo. El objetivo es mejorar la comunicación, identificar impedimentos y tomar decisiones rápidas.
Sprint Review
Revisión del trabajo completado durante el Sprint con los stakeholders. El objetivo es inspeccionar el resultado del Sprint y adaptar el Product Backlog basado en la retroalimentación.
Sprint Retrospective
Evento final del Sprint para reflexionar sobre el proceso y planificar mejoras para mejorar la calidad y efectividad del equipo mediante la identificación de áreas de mejora
Herramientas de Scrum
Product Backlog
Lista ordenada de todo lo necesario para el producto. Ha de ser la única fuente de requisitos para el equipo de Scrum.
Sprint Backlog
Conjunto de Product Backlog items seleccionados para el Sprint, junto con un plan para entregar el incremento. Guiará el trabajo del equipo de desarrollo durante el Sprint.
Increment
Suma de todos los Product Backlog items completados durante un Sprint y los incrementos de todos los Sprints anteriores. Provee un incremento de producto utilizable y que cumpla con la definición de «Done».
KANBAN
Kanban es una metodología de gestión ágil que ayuda a los equipos a visualizar su trabajo, maximizar la eficiencia y mejorar continuamente. Originada en el sistema de producción de Toyota en los años 1940, Kanban se ha adaptado para el desarrollo de software y otros entornos de trabajo que requieren gestión de flujos de trabajo y optimización de procesos.
Ahí pone: «Tonto el que lo lea»
Principios de Kanban
Comienza con lo que haces ahora: Kanban no requiere cambios radicales iniciales. En lugar de eso, comienza con los procesos actuales y se mejora de manera incremental.
Busca el cambio evolutivo e incremental: Implementa cambios pequeños y manejables para evitar la resistencia al cambio y minimizar riesgos.
Respeta los procesos, roles y responsabilidades actuales: La metodología Kanban se integra con los procesos existentes y los mejora sin causar grandes disrupciones.
Fomenta el liderazgo a todos los niveles: Todos los miembros del equipo, desde los directivos hasta los empleados, son responsables de contribuir a la mejora continua.
Prácticas de Kanban
Visualiza el flujo de trabajo
Utiliza tableros Kanban para representar visualmente las etapas del trabajo, como «Por hacer», «En progreso» y «Hecho». Esto ayuda a todos a ver el estado del trabajo en tiempo real. Yo, personalmente, uso mucho la herramienta Trello para coordinar el trabajo del equipo y controlar el estado de los requerimientos del proyecto.
Limita el trabajo en progreso (WIP)
Establece límites en la cantidad de trabajo que se puede realizar simultáneamente en cada etapa del flujo de trabajo para evitar sobrecargas y mejorar el enfoque.
Gestiona el flujo
Supervisa y mide el flujo de trabajo para identificar cuellos de botella y asegurarte de que el trabajo se complete de manera fluida y predecible.
Hacer explícitas las políticas
Define y comunica claramente las reglas y políticas de trabajo, como criterios para mover tareas entre columnas, límites de WIP y procedimientos de revisión.
Implementa bucles de retroalimentación
Establece reuniones regulares para revisar el progreso, discutir problemas y planificar mejoras. Esto puede incluir reuniones diarias, revisiones de flujo y retrospectives.
Utiliza datos y retroalimentación para realizar cambios experimentales y medir su impacto, permitiendo ajustes y mejoras continuas
Beneficios de Kanban
Mejora la comunicación: Los tableros Kanban proporcionan una visión clara del estado del trabajo, mejorando la transparencia y la comunicación entre los miembros del equipo.
Priorización efectiva: Ayuda a los equipos a enfocarse en tareas que realmente importan y a priorizar eficientemente.
Visibilidad y transparencia: Hace visibles los cuellos de botella y otros impedimentos en el proceso de trabajo.
Asignación eficiente de recursos: Permite una visualización clara de la carga de trabajo de cada miembro del equipo, optimizando la distribución de tareas.
Mejora continua: La naturaleza iterativa de Kanban facilita la identificación y eliminación de obstáculos a lo largo del proceso, promoviendo la mejora continua
Extreme Programming (XP)
Extreme Programming (XP) es una metodología ágil de desarrollo de software que se enfoca en mejorar la calidad del software y la capacidad de respuesta a los cambios en los requisitos del cliente. Fue creada por Kent Beck a finales de la década de 1990 y se caracteriza por una serie de prácticas que se combinan para mejorar la productividad y la calidad del producto final.
Me da que a esto no nos referimos
Principios Básicos de XP
Como podemos ver en la web oficial de Extreme Programming, los principios/valores de XP son:
Pero ¿Qué significan todos estos principios del XP? Pues el objetivo es mejorar la calidad del software y la eficiencia del equipo de desarrollo pero teniendo en cuenta la colaboración, la simplicidad en el diseño, la adaptación rápida a los cambios, y la creación de un ambiente de trabajo respetuoso y sostenible. Es decir crear un entorno donde los equipos de desarrollo puedan producir software de alta calidad de manera rápida y efectiva, respondiendo ágilmente a las necesidades cambiantes del cliente. No está nada mal todo esto
Prácticas de XP
Ahora bien, ¿Cómo se pone en práctica estos conceptos teóricos? Todos sabemos que el papel lo soporta todo y que de buenas intenciones está empedrado el infierno. Vamos a ver las prácticas de Extreme Programming:
Desarrollo Iterativo: El software se desarrolla en iteraciones cortas, típicamente de una a tres semanas. Entronca con los Sprints de Scrum.
Planificación iterativa: El cliente y el equipo de desarrollo colaboran para planificar qué funcionalidades se desarrollarán en cada iteración.
Pruebas Unitarias: Los desarrolladores escriben pruebas automáticas para cada pequeña pieza de funcionalidad antes de escribir el código correspondiente.
Refactorización: Mejorar el diseño del código existente sin cambiar su funcionalidad externa.
Programación de pares: Dos desarrolladores trabajan juntos en una misma computadora, alternando roles de escritura y revisión de código.
Propiedad Colectiva del Código: Cualquier miembro del equipo puede modificar cualquier parte del código en cualquier momento.
Integración Continua: El código se integra y se prueba frecuentemente, al menos una vez al día.
Metáfora del Sistema: Utilizar una metáfora simple y común para guiar el diseño y el desarrollo. Es como usar una comparación fácil de entender para que todos estén alineados sobre cómo debería funcionar el software, facilitando la comunicación y la colaboración.
Diseño Simple: Se mantiene el diseño tan simple como sea posible. Aqui viene el principio KISS (Keep It Simple, Stupid!)
Semana Laboral Sostenible: Se evita el exceso de trabajo y se mantiene un ritmo sostenible.
Cliente disponible: El cliente debe estar disponible para responder preguntas y proporcionar retroalimentación continua.
Estándares de Codificación: Se acuerdan y siguen estándares comunes de codificación.
Conclusión
Cada una de las metodologías (Scrum, Kanban, XP) dan para un artículo, varios o incluso cursos al respecto. Yo no soy un experto, solo lo conozco y uso un poco de cada cosa según me convenga. Espero, al menos, que sirva de introducción a las metodologías Agile.
Volvemos a sentar las bases, en este caso, de lo que es un proyecto de implantación. Es posible que nunca hayas vivido un proyecto de implantación porque siempre has estado en mantenimiento, o que hayas entrado en uno que, o bien ya estaba empezado, o bien no se siguen las buenas prácticas a la hora de pasar por las distintas fases, generando la documentación necesaria en cada fase. Estas fases tan marcadas y secuenciales pertenecen a la metodología Waterfall de desarrollo de software que es la más común y la que hemos usado siempre. Otras metodologías como las Agile cambian estos paradigmas y la forma de realizar entregas, documentación y puesta en producción. Peto de Agile ya hablaré más adelante.
Un proyecto es como una carretera sinuosa, en muchos casos con tintes surrealistas.
No es necesario indicar que esta lista de fases, análisis, documentación y entregables es a máximos, no todo es imprescindible y, en muchas ocasiones, es imposible pasar por todo. Pero es lo deseable.
Fase 0: Etapa de Selección del Proveedor
Esta es la previa al proyecto pero, como veremos, es crucial. Si somos consultores participaremos en este proceso, o bien para sacar una oferta de funcionalidades que satisfagan los requerimientos, o incluso ayudando al cliente a crear la RFP.
🏢 Evaluación de Proveedores
Se analizan diferentes proveedores de SAP para evaluar su experiencia, capacidad, y compatibilidad con los requerimientos del proyecto. Esto se hace para acotar aquellos proveedores a los que se les quiere hacer la RFP.
📑 RFI (Request for Information)
Dentro del paso anterior se puede emitir un RFI (Request For Information) para recopilar información general sobre los proveedores. Se trata de un documento que las organizaciones utilizan para recopilar información básica de posibles proveedores de servicios SAP. Su propósito es obtener un entendimiento general de las capacidades y servicios que ofrecen distintos proveedores, ayudando a la organización a filtrar y seleccionar los que mejor se ajusten a sus necesidades específicas antes de solicitar propuestas más detalladas (RFP) o cotizaciones (RFQ). La RFI es un paso inicial importante para identificar los proveedores más adecuados para el proyecto.
📝 Assessment
Un proceso que puede solicitar un cliente, antes de la RFP, es que uno de los proveedores les ayude a estudiar sus procesos y elevar las necesidades de negocio. Como resultado de este proceso se generan documentos del AS IS (Cómo están los sistemas actualmente) y el TO BE (Qué es lo que se quiere).
Hay varios objetivos que puede tener esta fase:
Estimar a alto nivel costes futuros: Si tenemos que realizar un cambio tecnológico y necesitamos tener una magnitud de costes y tiempos de cara a preparar el presupuesto y a nuestro CEO del golpe que viene.
Identificar las posibilidades y poder comparar soluciones: El TO BE puede ser una comparativa de las soluciones que pueden ayudar a la empresa a realizar la evolución tecnológica. Por ejemplo, para satisfacer el AS IS y poder evolucionar a medio largo plazo en X negocio puedes usa SAP Sales Cloud V2 con estos PROS y estos CONTRA o Salesforce con estos PROs y estos CONTRAS.
Conocer el estado del sistema actual: Puede que tengamos un sistema infrautilizado, o con demasiados desarrollos propios y un mapa de integraciones loco.
📑 RFP – Request for Proposal
Este es el paso importante de la búsqueda de un proveedor desde el punto de vista del cliente. Se solicitan propuestas detalladas a los proveedores preseleccionados. Aquí se incluyen requisitos específicos del proyecto, plazos, y expectativas.
Desde el punto de vista del Proveedor la RFP es el documento de requerimientos (a muy alto nivel) sobre el que trabajar para presentar una oferta con la solución, plazos, perfiles, precio, etc.
¿Cuantas RFPs pasan por las manos de managers? Huelga decir que la persona o grupo de personas que realice la oferta necesita tener mucho conocimiento, de negocio, de las posibilidades de la herramienta, de esfuerzos necesarios (perfiles y costes), identificación de gaps o riesgos, etc.
📑 RFQ – Request for Quote
Cuando un cliente tiene muy claro lo que quiere, el alcance y cuando la funcionalidad a implementar es algo que no tiene discusión (Por ejemplo compra de Hardware), se genera un documento en el que la organización solicita cotizaciones específicas de proveedores potenciales. A diferencia de un RFP, que es más detallado y abarca cómo se abordarán los requisitos del proyecto, un RFQ se centra principalmente en el precio y los costos asociados.
Yo nunca me he encontrado con esta petición, puesto que no estoy en el departamento comercial y, lo que me llega a mi son RFPs para su análisis y preparación de la Oferta correspondiente.
🎯Respuesta al RFP
La oferta como tal. Pero no solo en términos económicos, sino como documento de análisis de los procesos y necesidades expresado en la RFP y propuesta de soluciones en la herramienta o herramientas seleccionadas. Incluye también, a alto nivel, estimación de tiempo, perfiles y esfuerzo. Y bueno, todo lo que se considere necesario para que el cliente lo lea y diga:
¡Está muy bien!
Fase 1: Preparación del Proyecto
En la Fase 1 de un proyecto de implementación de SAP, cada documento e hito tiene un propósito específico:
⚽ Kick Off
Como en los partidos de fútbol, el kick off es el evento que da comienzo el partido. Una vez contratado con un proveedor el proyecto, acordado el alcance y planificado las fases, tiempos y esfuerzos, comienza el partido.
Alguno empieza así el proyecto
✈️ Plan de Trabajo de Alto Nivel
Define la dirección general del proyecto, estableciendo los objetivos, el alcance y la estructura del equipo. Este documento es crucial para asegurar que todos los involucrados entiendan la visión y los objetivos del proyecto.
🛤️ Estudio de Viabilidad
Evalúa si el proyecto es técnicamente y financieramente viable. Incluye análisis de costos, recursos disponibles, y beneficios esperados, ayudando a tomar decisiones informadas sobre la viabilidad del proyecto.
🚑 Análisis de Riesgos
Identifica posibles riesgos asociados con el proyecto, evaluando su impacto potencial y proponiendo estrategias para mitigarlos. Este análisis ayuda a prevenir problemas futuros y planificar respuestas adecuadas.
⏳Especificación de Necesidades y Límites
Detalla lo que se incluirá en el proyecto. Esto implica definir los procesos y funciones que se necesitan mejorar o implementar con SAP, estableciendo así los límites del proyecto
👨💼👩💼Identificación de Actores
Se determinan todas las partes interesadas en el proyecto, asignando roles y responsabilidades. Esto incluye identificar a los miembros del equipo, los patrocinadores, los usuarios finales y otras partes relevantes.
Iñigo Montoya Consultor Senior SAP CRM
Fase 2: Business Blueprint
En la Fase 2, el enfoque principal está en mapear los procesos de negocio actuales, identificar las necesidades de adaptación y planificar cómo se configurará el sistema SAP para alinearse con estos procesos.
📋 Actas de Reunión
Durante la fase de Business Blueprint, se llevan a cabo múltiples reuniones con stakeholders y expertos en procesos empresariales. Las Actas de Reunión son esenciales para documentar las discusiones, decisiones y acuerdos realizados durante estas reuniones. Ayudan a asegurar que todos los detalles de los procesos de negocio y los requisitos del sistema estén claramente comunicados y acordados.
🏭 Business Blueprint (BBP) – Documentación de Procesos del Negocio
Esta es la piedra angular de la fase. Se documentan los procesos empresariales existentes y cómo se espera que funcionen con el nuevo sistema SAP. Este documento sirve como un mapa detallado que guía la configuración y personalización del sistema.
Me ha quedado bonita la caseta del perro. Quizás se ha pedido funcionalidad innecesaria para una caseta de perro.
📅Cronograma de Actividades
Desarrolla un plan de tiempo para el proyecto, estableciendo hitos y fechas límite. Este cronograma sirve como una hoja de ruta para la ejecución del proyecto y ayuda a garantizar que se mantenga en el camino correcto. Hay gente que usa el Project, otros con un Excel es suficiente. Su utilidad es para ver desviaciones, avances, cuellos de botella, esfuerzos, asignación de recursos, etc.
Tiene miga hacer la caseta
🌩️ Gap Analysis (Análisis de Brechas)
Identifica las diferencias entre los procesos de negocio existentes y las capacidades del sistema SAP. Este documento es crucial para determinar las necesidades de personalización o desarrollo adicional.
Sacamos los posibles problemas y damos soluciones alternativas
Fase 3: Realización/Diseño
La Fase 3 es donde se configura y personaliza el sistema SAP según lo definido en el Business Blueprint. Esta fase es crítica para asegurar que SAP funcione de acuerdo con las necesidades y expectativas del negocio. En esta fase:
🧩 Parametrización del sistema
Se realiza la configuración específica de los módulos de SAP para alinear el sistema con los procesos de negocio documentados.
Somos unos máquinas parametrizando
⛏️ Desarrollo ABAP
Involucra cualquier desarrollo de software personalizado necesario para cumplir con los requisitos que SAP no cubre de forma estándar.
En Deloitte ha cambiado mucho el tema de ir en traje
🖇️ Diseño de integraciones
Se detallan las integraciones entre SAP y otros sistemas, asegurando un flujo de datos sin interrupciones.
💼 Documentación técnica
Al finalizar o incluso durante la Parametrización y desarrollo de las funcionalidades para satisfacer los procesos de negocio, se realiza un documento maestro de las funcionalidades SAP implementadas. Puede dividirse en dos, uno de Parametrización y otro de desarrollos. Sea como fuere es un entregable imprescindible. Bajo mi punto de vista se le da poca importancia (nadie lo revisa) a este documento. Cuando es crucial para conocer como esta configurado el sistema.
Yo haciendo la documentación y los manuales
🧙 Documentos de Roles y Perfiles de Usuario
Se definen los roles y perfiles de usuario en SAP, asegurando el acceso adecuado a las funciones y datos del sistema.
Fase 4: Preparación Final
🤸 Pruebas Unitarias
Evalúan las funciones individuales del sistema para garantizar que cada componente funcione según lo previsto.
🤼 Pruebas de Integración
Verifican cómo los diferentes módulos y sistemas integrados funcionan juntos. Ya sea entre SAP y sistemas externos o todo el proceso de inicio a fin en los distintos módulos de SAP.
👥 Pruebas de usuario (UAT)
Las oruebas de Aceptación del Usuario (UAT) se realizan con usuarios finales para asegurar que el sistema cumpla con sus necesidades y expectativas.
🩺 Pruebas de Regresión
Comprueban que las nuevas configuraciones o desarrollos no hayan afectado negativamente las funcionalidades existentes.
📚 Manuales de Usuario
Se elaboran manuales detallados que proporcionan instrucciones sobre cómo utilizar el sistema SAP. Estos son esenciales para la capacitación de los usuarios finales.
👨🏫 Capacitación de Usuarios
Se lleva a cabo la formación de los usuarios finales para asegurar que puedan operar el sistema eficientemente una vez que esté en funcionamiento.
🪂 Plan de Cutover
Se prepara el plan para el traspaso final del sistema antiguo al nuevo sistema SAP, incluyendo la migración de datos y la transición operativa.
Esta fase culmina con la preparación completa del sistema para su implementación y uso en vivo, asegurando que todos los aspectos funcionales y técnicos estén afinados y listos para la operación.
Fase 5: Puesta en Producción y Soporte
La Fase 5 en un proyecto de implementación de SAP es la etapa de «Puesta en Producción y Soporte». En esta fase, es crucial mantener una comunicación efectiva y proporcionar el soporte necesario para garantizar una transición fluida y exitosa al nuevo sistema SAP. Esta fase incluye:
🌅Puesta en Producción (Go-Live)
El sistema SAP se pone en funcionamiento y se utiliza en el entorno real. Esta transición debe ser cuidadosamente planificada y ejecutada.
🚑Soporte Post-Implementación
Proporciona asistencia continua a los usuarios para resolver problemas y adaptarse al nuevo sistema.
⏱️Optimización del Sistema
Incluye el ajuste fino del sistema para mejorar el rendimiento y la eficiencia operativa.
🌋Disaster Recovery Plan (DRP)
Prepara planes de contingencia en caso de problemas graves o desastres para garantizar la continuidad del negocio.
En conclusión
Pero ¡voy a necesitar un par de personas para orquestar todo esto!.
Pues claro, se llaman jefes de proyecto y/o managers y no están (o no deberían) todo el día tomando cafés con otros de su especie. Ahora bien, como con otros perfiles, tienes que ser bueno en esto, metódico, ordenado, analítico, asertivo y, en ocasiones, cortante y estricto..
No obstante, todo el equipo debería tener claras todas las fases, hitos y entregables a realizar. Que luego nos enfadamos cuando nos piden que documentemos.
Jorge Ocampos 