Publicado em

SAFe – Preparando a PI Planning

A PI Planning (PI = Program Increment) é o evento que provê a definição que guiará os times envolvidos na entrega do ART (Agile Release Train), para que a cerimônia tenha sucesso é necessário que haja alguns preparativos antes do evento.

Uma das coisas que precisam estar claras é a estratégia, tanto para área de produto quanto para área de tecnologia, o contexto precisa estar pacificado, todos devem concordar, ao menos em alto nível, com o escopo a ser endereçado e tecnologia a ser utilizada.

Os assuntos que deverão ser priorizados precisam estar definidos pela área de produto/negócio ao menos em grandes linhas de forma que se tenha as condições para dar um direcionamento claro dos objetivos a serem alcançados.

Uma Program Increment Planning é a cerimônia em que o Agile Release Train (ART) planeja e entrega valor incremental na forma de software e sistemas funcionais. Esse planejamento compreende o trabalho de 8 a 12 semanas.

Preferencialmente os times envolvidos precisam estar definidos e com o menor número de pendências (inclusive setup) possível dentro do possível considerando o cenário da organização.

Isso viabilizará para que a PI Planning possa prover uma visão compartilhada e consistente do contexto em questão assim como a declaração dos objetivos de forma que os times de fato consigam tracionar o ART em direção a meta.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

SAFe – Agile Release Train (ART)

O ART ou Agile Release Train é um time de times, ou seja, é um conjunto de squads e stakeholders que em conjunto irão dentro de um determinado período planejar, desenhar, executar e entregar soluções em fluxo de desenvolvimento de produto contínuo. Ele é multifuncional todas as disciplinas necessárias para a entrega devem estar contidas no ART (software e hardware).

Além de alinhar todos os times em uma única missão colabora para mitigação de riscos e da variabilidade inerentes a esse tipo de situação no caso de não haver uma organização deste tipo.

Um dos principais objetivos de um Agile Release Train (ART) é entregar features e/ou componentes buscando sempre a minimização de dependências para que o trabalho flua mais rapidamente e com a menor sobrecarga possível.

O ideal é que os times sejam organizados de forma a entregar um novo incremento a cada 2 semanas, deve haver sincronização entre os times para que o ART seja capaz de liberar um incremento com valor para o negócio, é claro que é mais fácil falar do que fazer, é uma operação complexa e que exige um nível de organização razoável dos times e gestores envolvidos, o framework SAFe colabora fornecendo práticas para aplicar cadência e sincronização necessárias.

O Program Increment ou PI é a janela de tempo da qual o ART de forma incremental deve entregar valor conforme o que foi feito pelos times o que pode conter entregáveis não apenas de software, esse timebox tem tipicamente de 8 a 12 semanas divididas pelas “Systems Demos” que ocorrem ao final de cada sprint de forma a permitir a inspeção e adaptação (I&A) .

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Processo de homologação, como é que é ? (Parte 2/3)

Antes de iniciarmos uma homologação precisamos nos certificar que uma série de coisas tenham sido feitas para que não haja impactos no planejamento previsto com a descoberta de problemas que deveriam ter sido resolvidos nos testes dos times.

Cada time envolvido precisa realizar os testes relacionados ao seu escopo, é recomendável que haja um ambiente aonde os incrementos possam ser integrados e façam conexão com sistemas que compõem a solução como um ERP ou um TMS por exemplo:

  1. Testes unitários;
  2. Testes de regressão;
  3. Testes automatizados;
  4. Testes integrados (quando possível);
  5. Testes de performance;
  6. Testes de segurança;
  7. Testes de carga;
  8. Testes de usabilidade;
Os times precisam garantir a integridade do seu incremento passando por todos os passos necessários conforme a natureza da sua demanda.

Quantos mais testes forem feitos no ambiente integrado (“pré-homolog”) pelos times melhor, deve haver um responsável para organizar as subidas para esse ambiente de forma a garantir sua integridade e disponibilidade, assim todos poderão executar as validações e fazer os ajustes oriundos dos apontamentos que surgirão, não se pode garantir que todos os problemas sejam eliminados porém essa prática garante maior robustez ao incremento do programa para a homologação.

Apesar de exigir grande esforço de organização é de extrema importância que aconteça, caso esses passos não sejam realizados, passamos a atribuição dos testes para os responsáveis pela homologação juntamente com a área de negócio, o que é extremamente contraproducente, vamos parar por aqui, continuamos no próximo post.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Processo de homologação, como é que é ? (Parte 1/3)

Tipicamente projetos de médio e grande portes fazem uso do ágil escalado, múltiplos times trabalham e existem dependências entre eles para que se demonstre incremento do programa para as áreas de negócio.

Muitas das vezes dependendo da criticidade a revisão da sprint não se aplica nesse cenário, é necessário integrar o resultado do trabalho dos times em um ambiente que garanta a integridade do que foi construído pelos times para a validação do negócio.

Em uma homologação de sistema corporativo é necessário organizar todos os envolvidos de forma a evitar desperdícios e desencontros,

Imagine um projeto para implantação de um e-commerce aonde temos funcionalidades das mais diversas envolvendo múltiplas áreas como vendas, financeiro, logística, transporte, fiscal, marketing dentre outras, imagine a quantidade de integrações e sistemas envolvidos.

É necessário uma abordagem diferente para situações como esta, é preciso que se organize ciclos de homologação considerando a jornada do cliente elaborando um planejamento consistente para dar sustentação a homologação considerando a idas e voltas que acontecerão, veja o post de amanhã, continua…

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Dependências entre times, como tratar !?

Como sabemos em um projeto que faz utilização de Scrum escalado tipicamente os time envolvidos na demanda trabalham no mesmo backlog de produto, sendo assim é inevitável que hajam dependências.

Vão haver situações aonde os times pontualmente precisarão de algum integrante de outro time ou ação, o que é muitas vezes acontece nesses casos é a classificação da situação como impedimento ou block e se espera que se resolva sozinho ou passam para Scrum Master resolver.

Isso não é recomendável, imagine que durante o projeto, todas as vezes que isso acontecer seja passado para o Scrum Master, essa pessoa se tornará um gargalo.

Se alguém não chegar ninguém chega, o trabalho estará imcompleto e não poderá ser considerado entregue, “fiz minha parte” não vale aqui.

O comportamento a ser incentivado é que a coordenação dos trabalhos entres o times seja realizado por eles mesmos, dependendo do assunto essa interação será essencial para que os trabalhos continuem, pois nem sempre o Scrum Master terá o domínio do assunto. O impedimento deve ser declarado apenas quando os times não conseguirem evoluir com o assunto devido a questão que está fora do controle dos times, a autoorganização e transparência precisam ser praticadas, ajude-os a conseguir.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Pecado capital no ágil escalado.

O trabalho precisa ser organizado e sequenciado, as dependencias resolvidas e os resultados apresentados, isso pode ser dificil quando temos mais de um time utilizando o mesmo backlog de produto devido a necessidade da integração destes incrementos e testes integrados.

As dependências precisam ser mapeadas o mais cedo possível e é essencial que os times envolvidos colaborem para completar o trabalho de forma a alcançar a definiçao de pronto, é importante que tanto os times quanto o backlog do produto sejam organizados de forma a diminuir essas dependências otimizando o trabalho, a forma em que acontece vai variar conforme o ramo e os recursos envolvidos.

O sucesso da iniciativa depende fundamentalmente da participação ativa dos envolvidos, a colaboração é a chave.

Posto isso um pecado capital costumeiro e que presenciei em várias ocasiões é a crença dos times de que devem se importar apenas com o seu trabalho ignorando o que acontece com as dependências, o trabalho que está sendo executado nos outros times do projeto deve ser acompanhado regularmente e quando necessário deve haver colaboração para que o planejamento realizado continue em linha.

A continuidade deste tipo de expediente é um dos principais motivos de falha nos projetos escalados, é essencial que todos tenham ciência da responsabilidade em conjunto com cada interação do projeto na integração de um incremento coeso, fique de olho nas dependências, não as perca de vista, se alguém não conseguir chegar você também não consegue fazer sua entrega.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Scrum Escalado x Definição de Pronto

Em Scrum escalado utilizando frameworks conhecidos como o SAFe ou Nexus por exemplo, existe mais de um time trabalhando no mesmo Backlog do Produto, isso implica na necessidade de uma organização maior já que para que um incremento de software seja considerado pronto, o trabalho executado por mais de um time deve ser integrado para que a entrega possa ser realizada de forma correta.

É responsibilidade de cada time que todo o trabalho previsto no Sprint Backlog ao final reflita a Definição de Pronto (DoD) vigente.

No caso de mais de um time, todos eles são responsáveis por garantir que seus respectivos incrementos sejam devidamente integrados aos incrementos dos outros times envolvidos, pois a soma de todos os incrementos formarão o incremento do projeto para um determinado período (Sprint(s)) sempre levando em conta a Definição de Pronto acordada na iniciativa ou projeto.

Um engano comum é que a entrega seja considerada realizada sem a devida integração do que foi implementado pelos times envolvidos, isso causa diversos contra tempos além do atraso, já que os incrementos ainda terão que ser integrados e ajustes certamente precisarão ser feitos durante o processo gerando mais tarefas “não previstas” (correção de bugs, testes regressivos e etc) afetando o planejamento do trabalho subsequente.

Os times precisam chegar a um acordo sobre uma definição de pronto

O ideal é que uma vez que os times estejam trabalhando no mesmo Backlog do Produto, seja alinhada uma Definição de Pronto comum para todos os times inseridos em uma determinada iniciativa, sendo assim o trabalho previsto nesta Definição de Pronto será considerada no planejamento de cada time envolvido, o que facilitará a integração do trabalho de todos os times ao final de uma sprint.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!!