Após esta seleção, um backlog com as tarefas do projeto de BPM é criado. O trabalho de modelagem é planejado e dividido em pequenas entregas (sprints) com duração aproximada de 15 ou 30 dias. De acordo com esta duração, será necessário dividir essas entregas em um ou mais sprints. As tarefas a serem executas são alocadas em seus respectivos sprints. O backlog e os sprints são cadastrados em uma ferramenta, aonde a equipe de modelagem fará o acompanhamento do projeto de BPM.
Além disso, a modelagem de processos seguirá uma padronização através de regras e boas práticas definidas em um documento de diretrizes de modelagem e será realizada em uma ferramenta de modelagem de processos colaborativa, facilitando assim a revisão que poderá ser realizada durante a própria modelagem.
Por fim, podem ser alocados mais de um analista por processo e adotado um rodízio de analistas nos processos. Isto torna a modelagem mais dinâmica, pois os analistas podem discutir as dúvidas que surgem durante a modelagem e apresentar ideias ou soluções de modelagem para alguns problemas de representação não triviais. O rodízio de analistas também ajuda a padronização da modelagem entre os diferentes processos tratados no projeto e a elaboração de modelos com mais qualidade, já que visões diferentes contribuem com sugestões de ajustes e melhorias.
A diferença do BPM Ágil ou Lean BPM para o uso do BPM tradicional é que neste caso são utilizadas técnicas não tradicionais vindas das metodologias ágeis ou lean (Scrum, XP, Kanban) na gestão de processos. Os princípios, valores e práticas ágeis presentes nestas metodologias ágeis foram adaptados e inseridos no ciclo de BPM.BPM Ágil ou Lean BPMpode ser resumida pela figura abaixo. Na figura, a modelagem do processo é dividida em pequenas entregas. Nas reuniões são levantados os processos que serão descritos como estórias. As estórias descrevem através de post-its o funcionamento dos processos e atividades e são usadas para o planejamento, priorização e divisão do trabalho.
Atualmente, os projetos estão cada vez mais dinâmicos e os gestores desejam resultados cada vez mais rápidos. Com isso, a Gestão de Processos de Negócio (BPM) começa a ser revista para entregar prontamente resultados e produtos. Como solução para este problema, veio a ideia de adaptar as praticais ágeis do desenvolvimento de software para a gestão de processos, tornando-a mais dinâmica e iterativa, propiciando entregas mais rápidas e com isso uma maior satisfação dos clientes.
Em desenvolvimento ágil, os limites de trabalho em andamento (WIP) definem a quantidade máxima de trabalho que pode existir em cada status de um fluxo de trabalho. Limitar a quantidade de trabalho em andamento facilita a identificação da ineficiência no fluxo de trabalho de uma equipe. Obstáculos no pipeline de entrega de uma equipe são claramente visíveis antes de uma situação se tornar extrema.
Os limites de WIP melhoram a produtividade e reduzem a quantidade de trabalho “quase feito”, forçando a equipe a se concentrar em um conjunto menor de tarefas. Em um nível fundamental, os limites de WIP incentivam uma cultura de “concluído”. E, o mais importante, os limites de WIP tornam os bloqueadores e os obstáculos visíveis. As equipes podem analisar problemas de bloqueio para que eles sejam entendidos, implementados e resolvidos quando há um claro indicador de qual trabalho existente está causando um obstáculo. Uma vez que os bloqueios são removidos, o trabalho da equipe começa a fluir novamente. Estes benefícios garantem que incrementos de valor sejam entregues aos clientes mais rapidamente, tornando os limites de WIP uma ferramenta importante no desenvolvimento ágil.
Durante o desenvolvimento, é comum pensar: “Farei uma pausa em relação a esse problema enquanto começo a trabalhar em outro”. Ter dois problemas em aberto significa alternar de contexto entre duas coisas diferentes ou transferir trabalho entre colegas de equipe. Ir de um problema para o outro não é fácil – leva tempo e diminui o foco. Quase sempre é melhor trabalhar no problema original do que começar – e não concluir – um novo trabalho. Ou seja, os limites de WIP nos desencorajam a obstruir nosso próprio fluxo.
Finalmente, os limites de WIP mostram as áreas com ociosidade crônica ou sobrecarga. Eles ajudam a equipe a ver as ineficiências no processo todo em vez de apenas em uma área específica de trabalho.
Pode parecer estranho para equipes novas no uso dos limites de WIP. Reserve um tempo para discussão nas primeiras iterações. Entenda como e o motivo pelo qual a equipe atinge os limites de WIP. Resista à tentação de fazer ajustes arbitrários. Se uma violação se tornar consistente, é um sinal de que o limite de WIP é muito restritivo ou que o processo da equipe é ineficiente.
Ao lançar um novo fluxo de trabalho, tome uma decisão em equipe para determinar os limites de WIP para cada status. Recomendamos definir os limites de WIP após monitorar o número médio de itens de trabalho em cada status para alguns sprints. Abaixo é possível ver um quadro ágil de exemplo com os limites de WIP usados por uma equipe de desenvolvimento de software comum.
Acima, um limite de WIP foi definido na revisão de código. Como a coluna está excedendo seu limite, o histórico ficou vermelho.
Como não resta nada a fazer quando um problema é concluído, não há necessidade de um limite de WIP. No quadro acima, “Pronto para desenv.” significa que a história foi totalmente analisada pelo proprietário do produto e pela equipe. A equipe de desenvolvimento passa o trabalho de “pronto para desenv.” para “em andamento” à medida que começam a trabalhar nos itens. Como melhor prática, é importante manter trabalho suficiente no status “pronto para desenv.” para que cada membro da equipe de desenvolvimento permaneça trabalhando. Ao manter apenas histórias suficientes no estado “pronto para desenv.”, o proprietário do produto não fica muito à frente quando se trata de detalhar os requisitos e o programa se torna mais responsivo para alteração.
O status “em andamento” lista o trabalho que está sob desenvolvimento ativo. A meta dos limites de WIP nesse caso é garantir que todos tenham trabalho para fazer, mas ninguém esteja fazendo múltiplas tarefas. No quadro cima, o limite para os itens “em andamento” é quatro e há, no momento, três itens nesse estado. Isso mostra à equipe que eles conseguem assumir mais um trabalho. Como melhor prática, algumas equipes definem o limite de WIP máximo abaixo do número de membros da equipe. A ideia é preparar o espaço para as boas práticas ágeis. Se um desenvolvedor finalizar um item, mas a equipe já estiver no limite de WIP, eles saberão que é a hora de resolver algumas revisões de código ou chamar outro desenvolvedor para ajudar na programação.