Use o nosso código BABRAZIL2022_CADU_10 e garanta 10% de desconto, não cumulativo.

Sobre:

O BA Brazil é um evento sem fins lucrativos, concebido e realizado pelo capítulo brasileiro do International Institute of Business Analysis (IIBA®) com o apoio do IIBA® Internacional e dos demais capítulos do IIBA® na América Latina (México, Peru e Porto Rico).

Quando

Terça-feira, 22/11/2022 @ 15:00 (GMT-3)

Local

FIAP Paulista Unit.
Avenida Paulista, 1100, 6th-floor
São Paulo, SPBrazil

Participante

Carlos Eduardo Vazquez

Evangelista de métricas de software há 30 anos

Sócio fundador da FATTO

Resumo

Integração da análise de requisitos e do roadmap com a implementação em cadências desacopladas.

Porque é importante você participar

  • Escassez de “Devs” & inflação no custo da mão de obra: Os recursos no desenvolvimento de soluções com habilidades de programação, configuração de plataformas e ferramentas de software; enfim, os “devs”, está escasso. Competimos no Brasil por mão de obra especializada com todo o mundo em Euro e Dólar. É importante buscar soluções para melhor organizar o trabalho sem comprometer a agilidade.
  • Colapso na produtividade: Você observa o Scrum como referência e usa ferramentas de produtividade, como plataformas de desenvolvimento low code; ainda assim, se vê demorando demais para entregas de releases funcionais e, cada vez mais, são necessários mais sprints para conseguir resultados de qualidade. A velocidade parece ser boa; mas numa perspectiva externa é como se brotassem cartões para “algo” que já deveria estar pronto.
  • Crise de Liquidez Global: Até muito pouco tem atrás havia dinheiro sobrando no mundo. Se imprimiu mais dinheiro em três anos do que em TODA A HISTÓRIA. Isso acabou. Modelos que funcionavam naquela realidade, simplesmente vão deixar de funcionar. Daí é importante você conhecer alternativas, cujos objetivos sejam também aumentar a produtividade, antecipar decisões que podem ser antecipadas e prevenir bloqueios.
  • Menores tempos de entrega: Uma mesma esteira de análise de negócio, trabalhando a partir de um backlog de solução, pode gerar itens para o backlog de várias diferentes equipes. Permitindo alcançar resultados em menor tempo.

Como você vai alcançar isso

  • Entendendo melhor o que é o desenvolvimento desacoplado, como essa estratégia se insere na Análise de Negócio como definida pelo IIBA e os cuidados para você não engessar seu processo desnecessariamente.
  • Obtendo insight ou inspiração sobre o como diferenciar o que seja o refinamento de uma necessidade em um requisito da solução do que seja o detalhamento de um desses requisitos. Para isso, usando referências da ISO na busca de saber “o que pode ser antecipado”, o conceito de Up Stream e Down Stream associado ao Kanban, descolar o esforço de se refinar as ideias e definir as histórias do lead time do desenvolvimento; e cada processo tem o seu próprio ritmo; a sua própria cadência.
  • Ouvindo e discutindo histórias dessa transição para o desenvolvimento desacoplado, na qual uma dela se avançou para o uso do BDD. Pretendemos compartilhar o que fizemos certo e o que fizemos errado.

Uma palavra sobre o evento

Enquanto alguns trabalhos estão completos e prontos para entrega, outros trabalhos estarão em andamento. Tendo desacoplado o tempo de espera para o desenvolvimento da cadência de entrega, faz sentido questionar com que frequência a priorização (e talvez o planejamento e a estimativa) devem acontecer. Parece improvável que as discussões de planejamento, estimativa e priorização precisem acontecer no mesmo ritmo que a entrega e o lançamento do software.

São funções completamente diferentes, muitas vezes exigindo a atenção de diferentes grupos de pessoas. O esforço de coordenação em torno da entrega é certamente diferente do esforço de coordenação em torno da priorização de novos trabalhos.

Nosso objetivo é apresentar um caso no qual houve o desacoplamento entre o desenho de solução de sua implementação; porém mantendo o espírito da agilidade por meio de alguns cuidados na definição e monitoramento do escopo de solução de maneira integrada ao roadmap do produto; da validação contínua de ambos junto ao negócio; e do alinhamento junto às equipes de implementação por meio de seu próprio backlog.

Por fim, eu vejo o Product Owner tendo o seu tempo dividido em questões relacionadas à Análise de Negócio e questões relacionadas a aspectos mais relacionados à implementação. Ao desacoplar esses dois âmbitos, podemos melhorar o desempenho em ambas as frentes e eliminar bloqueios lá atras, que caso contrário, surgiriam lá na frente.