En la primera parte del tema Agile Business Process Management , escribí mis primeros pensamientos sobre la forma de analizar los procesos modelados con Scrum. En la segunda parte, me gustaría abordar más de cerca la cuestión.

El uso de Scrum en proyectos BPM depende de varios factores. En primer lugar, la complejidad de los procesos y el objetivo del proyecto.

Estos escenarios diferentes, voy a explicar a continuación:

Para todos los niveles de complejidad son algunas precauciones a tener en cuenta antes de iniciar los procesos ejecutables en los sistemas de TI para poner en práctica:

• Estrategia para el proceso de aplicación está disponible
• Un sistema BPMS ejecutable está disponible
• Profesionales con experiencia están disponibles para el análisis de procesos

Si estos puntos no se cumplen, se debe crear en las fases iniciales del proyecto de estos principios. Se recomienda una estrategia para el proceso de aplicación que se ha definido. Aquí se describe cómo los procesos en el entorno de TI para ser integrados, de responsabilidades debe ser regulada para los procesos (propietario del proceso) y las metodologías, técnicas y convenciones que se utilizarán. Con una buena estrategia podría aplicarse más adelante los procesos de forma rápida y flexible. La estrategia para crecer sólo de forma gradual con cada proceso para ser implementado a menudo significa que los procesos no están estandarizados, difícil de mantener y voluntad inflexible. Una estrategia unificada también reduce la documentación necesaria y reduce la curva de aprendizaje de los nuevos empleados. Puesto que los elementos esenciales de los diferentes procesos son idénticos y siguen las mismas reglas.

Scrum para los procesos de baja complejidad:

Aquí puedes Scrum se vivió en su forma pura por completo. Sobre todo cuando muchos de los procesos se llevarán a cabo con una complejidad baja para el modelo de proceso con los sistemas de TI, esto puede ser muy bien aplicado Scrum. Los analistas de proceso se refieren a los procesos en el cliente y el mejor modelo con una notación de modelado estándar (por ejemplo, BPMN). Procesos simples pueden ser analizados durante el proceso de modelado por los analistas experimentados para optimizar el flujo del proceso, por una parte, sino también para definir los recursos necesarios, los datos y KPIs. Los modelos con el fin de modelado puede ser implementado en un BPMS. Algunas de las suites de BPM comerciales existentes ofrecen la oportunidad de construir los procesos modelados e implementar el proceso de diseño (aplicación de los detalles técnicos que son necesarios para el diseño del proceso). A raíz de los procesos pueden ser analizadas inmediatamente por el cliente en el BPMS. Los procesos de baja complejidad, permite que todos estos pasos en una carrera de velocidad (es decir, 4 semanas) para llevar a cabo.

Scum en proyectos con complejidad moderada:

Aquí es aún más difícil cumplir con los ciclos de iteración cortos del scrum. Scrum define que después de cada sprint un producto en ejecución puede ser entregado. Los procesos son demasiado grandes para modelar esto como una carrera de velocidad, analizar, diseñar e implementar uno tiene, en principio, tres posibilidades:

1. Los procesos se descomponen / reducir
2. El sprint para ampliar
3. Los resultados de una carrera de velocidad para definir diferentes

Descomponer 1) El proceso no es posible para todos los procesos. Por un lado para apoyar este enfoque no, todas las suites de BPM y sistemas. Para otros procesos entregar un resultado específico. Con los intermedios, lo que puede ocurrir durante el proceso, el propietario del producto hacer nada. Así, este de los procesos se descomponen sólo si el proceso esta divulgación posible. Esto es a menudo el caso cuando los procesos de mostrar muchas ramas paralelas. Entonces, estas ramas paralelas se pueden implementar de forma gradual. Una reducción de los procesos puede significar que los pasos deben ser automatizados, o interfaces se asignan a un proceso en la primera versión de prueba de una tarea manual. Esto obviamente no es posible en el tratamiento de los datos a granel, para los procesos de interactividad humano alto, sin embargo, ya. Por ejemplo, los usuarios pueden necesitar en la primera versión de los datos transferidos de forma manual en los sistemas de terceros y el próximo Sprint se desarrollan y automatizar las interfaces. Un inconveniente importante del proceso de descomposición / reducción es que el usuario debe acostumbrarse durante el proceso de aplicación después de cada paso en un proceso ligeramente diferente. Esto puede llevar a la confusión y la frustración.

Para 2) La extensión general de los sprints en un proyecto Scrum es posible. Así que uno puede desviarse de las habituales 4 semanas y, posiblemente, definir los 6 o incluso 8 semanas como duración sprint. Generalmente, esto no es en el sentido de Scrum. Debido a las largas carreras, gran parte de la agilidad se pierde por Scrum. El propietario del producto tiene que esperar mucho tiempo en ciertas situaciones a las nuevas demandas se pueden realizar. Por lo tanto, la extensión de las pruebas de velocidad con cautela y no debe exceder de 8 semanas.

Para 3) La tercera posibilidad es una combinación de Kanban y Scrum. No está implementado al final de un sprint el proceso final, pero hay por ejemplo requiere un total de tres sprints. En el primer sprint, los procesos se modelan en el segundo Sprint para analizar los procesos en el 3 y Sprint será el diseño e implementación. Esto reduce la agilidad tiempo atrás (el proceso en sí no está listo hasta después de 3 esprints), pero en comparación con la extensión de la ventaja de Sprint, que es cada 4 semanas, un resultado que se ve. El propietario del producto puede intervenir cada 4 semanas y, posiblemente, hacer nuevos productos para el Sprint Backlog con el y puede hacer el mejor proyecto. Además, esta versión permite que instruya a los equipos de cada sprint con diferentes tareas. Por lo tanto, el modelo se llevará a cabo por un equipo de analistas, puede tener el conocimiento técnico de los procesos a modelar y lo están haciendo muy bien con los procesos futuros usuarios en los talleres o entrevistas pueden grabar. El próximo equipo analizar y optimizar los procesos y se especializa pulg El tercer equipo está especializada en la implantación de procesos y, posiblemente, el desarrollo de interfaces. Esto puede aumentar la utilización de los equipos de forma clara y evitar tiempos de inactividad de los especialistas individuales. Se puede ver aquí, pero sé que si a partir de la "clásica" procesos Scrum debe desviarse de mediana complejidad para poner en práctica.

Scrum para procesos con alta complejidad

Los procesos con alta complejidad puede, posiblemente, sólo con la anteriormente descrita oferta combinada "Kanban y Scrum". Si esto talleres largos y análisis de modelado de procesos puede ser necesario que sean necesarias para la introducción de importantes cambios organizativos ya verdaderos expertos en Scrum que trabajar. Esta es probablemente una de Scrum de Scrum se utiliza para separar runterzubrechen actividades y se distribuye a los diferentes equipos. Esto es de nuevo importante asegurarse de que las historias de los usuarios se dividen en paquetes significativos sub que se pueden implementar en un sprint. Sin embargo, el manifiesto ágil también tenerse en cuenta aquí. Y debe ser modelado tan pronto como sea posible, trate de hacer que los procesos se ejecutan. Debido a que siguió una fase de modelado y análisis, que dura varios meses de una aplicación prolongada a menudo conduce al fracaso de los proyectos. Esto también se debe tratar de "empezar poco a poco crecer grande" enfoque seguirá. Con la versión de prueba primero para que no se debe tratar de procesar el 100% seguro, porque con todas las campanas y silbatos (interfaces, automatización, etc) para poner en práctica, pero una reducción significativa. Para el último 10% es siempre el más caro de todos modos.