Estrutura SAFe ou Scaled Agile

O que é o SAFe?

O que é Agile, muitos sabem. Um número ainda maior de pessoas envolvidas em TI usa terminologia. Mais para ouvir sobre o Agile.

Nem todo mundo que usa com confiança o termo Ágil para comunicação, crítica, por isso; Para apresentar melhor sua equipe ou empresa, eles entendem, por exemplo, qual é a diferença entre SCRUM e Agile; e geralmente coloca um sinal de igual entre esses dois conceitos diferentes. Mas não faz muito tempo, em 2015, o SAFe também apareceu. O que é e por que é necessário?

Uma das vantagens e desvantagens importantes do SCRUM, considero que o tamanho prescrito dos comandos é 7 + -2 (ou 3-9 dados mais recentes do Scrum Guide ), incluindo o Product Owner.
É claro que 9 profissionais de alto nível e bem motivados são capazes de muito, mas às vezes é necessário construir algo com um grande número de mãos, cabeças, olhos e cérebros no final. Inflar equipes é ruim, portanto, seu número precisa ser aumentado, e aqui surge o problema de comunicação entre equipes, a sincronização do trabalho e o próprio SCRUM não oferecem nenhuma solução para essas tarefas. Existem tentativas de usar o SCRUM no nível do gerenciamento de comandos do SCRUM (Jeff Sutherland, um dos autores do manifesto Agile aconselha a fazê-lo), há Scrum em grande escala, há Entrega ágil disciplinada, há muito mais, mas também há SAFe - Scaled Agile Framework.

O SAFe é uma estrutura de gerenciamento da empresa que requer coordenação do trabalho em um determinado projeto ou projetos relacionados para 5 ou mais equipes da SCRUM. I.e. essa é uma superestrutura sobre o SCRUM que permite gerenciar equipes de 100 ou mais pessoas

Benefício?

Antes de tudo, é claro, a metodologia é necessária para quem a vende e se envolve em treinamento. Dave Thomas (um dos autores do manifesto Agile) falou muito bem sobre esse assunto No GOTO 2015, em sua apresentação de Agile is Dead

Em segundo lugar, departamentos de gerenciamento de programas. Aqueles que estavam anteriormente envolvidos no gerenciamento de projetos receberam a certificação PMP, desenharam gráficos de Gantt e implementaram o conceito de gerenciamento rígido (o lado mais suave da liderança e o mais difícil dos executores). O fato é que em um SCRUM típico não há função para eles, no SAFe é. O mesmo se aplica a todos os tipos de arquitetos. No SCRUM, não há função para eles no SAFe - existe um plano de carreira.

Além disso, pode ser benéfico para os proprietários de empresas em que os gerentes trabalham em grandes projetos devorando um grande número de horas-homem e não podem (às vezes por razões objetivas) tornar esses projetos independentes.

Muitos desenvolvedores com qualificações abaixo da média muitas vezes, para fazer algo, eles precisam ser exponencialmente mais do que os profissionais mais experientes e motivados.

Toda a indústria. Porque o número de desenvolvedores dobra a cada 5 anos (veja o futuro da programação do tio bob ), cuja conseqüência é que, a qualquer momento, pelo menos metade dos desenvolvedores tem menos de 5 anos de experiência de trabalho. Se a tendência não muda, mas aparentemente não muda, são necessários processos que prescrevam e formalizem suas funções de trabalho, mecanismos de interação entre os participantes e todo o processo.

Essence

O SAFe é um bolo de camadas de várias técnicas ágeis. No nível inferior, está o quase tradicional SCRUM, com sprints típicos de duas a três semanas, equipes de 3 a 9 pessoas, incluindo Product Owner. Todos os rituais típicos, desde o planejamento diário - stand-up e terminando com o interrogatório em retrospectiva. Embora exista uma diferença fundamental. O comando deixa de ser um módulo independente totalmente funcional. E o sprint deixa de ser um período independente de tempo com um ciclo de vida completo. Os sprints são combinados em incrementos de programa que consistem geralmente em 5 sprints. I.e. se no SCRUM clássico não construímos o que o cliente gosta, então fazemos a correção do curso no próximo sprint; em seguida, no SAFe, continuamos em direção ao limite até o final do programa.

No próximo nível, temos trens - o chamado Trem de Liberação Ágil. Existem novas funções para gerenciar 5 segmentos de sprint: um arquiteto de sistema (aquele que possui a arquitetura - ou seja, não é mais uma equipe), o gerente de produto (aquele que controla o produto, não o Dono do Produto, este último solicita conselhos à PM) e RTE - o mesmo PMP do mundo distante da cachoeira. Aqui, alguns desenvolvimentos do Kanban são aplicados, em particular, um quadro, um método para atribuir prioridades e, no geral, o princípio de medir o desempenho histórico das equipes (velocidade) e projetar o que será construído no final do intervalo de tempo, em oposição à abordagem com estimativas e designação de prazos para um funcional já fixo ( escopo). Uma das inovações é que o último sprint de 5 é declarado organizacional e durante o qual são realizadas grandes reuniões (todas as equipes juntas - e são 100 ou mais pessoas), é realizada uma análise da dívida técnica, são feitos planos para o desenvolvimento da arquitetura e o trabalho de todas as equipes é sincronizado.

Acima do nível do trem, temos coordenação entre departamentos, diretores e o cliente. Há mais empréstimos do Lean Agile, mas as mesmas ferramentas do Kanban são preservadas. Esta é uma análise da viabilidade econômica da mudança. Idealmente, quaisquer alterações passam por uma análise preliminar, onde é apresentada uma hipótese mensurável sobre a próxima mudança (por exemplo, se fizermos uma loja on-line de um datacenter para a nuvem, aumentando rapidamente as capacidades no pico das vendas sazonais, podemos aumentar o número de transações em 10%) e, em seguida, essa hipótese será confirmada. não Para empresas com menos de um bilhão de dólares - esse pode ser o último andar. Os planos de trabalho para 12-36 meses são criados aqui (hi planos quinquenais de qualidade, quantidade etc.)

Acima do nível dos grandes sistemas está o gerenciamento de portfólio. Os fundos são alocados para várias áreas de negócios. O gerenciamento de portfólio enxuto é usado, usando a estratégia de desenvolvimento da empresa, e são selecionadas áreas das quais você pode obter retorno. Aqui são tomadas decisões sobre a compra ou fusão com outras empresas. Criação de novas linhas de negócios, fechamento de antigas. O orçamento é regularmente ajustado e reatribuído (em oposição aos planos trimestrais ou anuais). Para cada componente do portfólio, um conjunto de métricas mais ou menos padronizadas é estabelecido e, em seguida, todas são avaliadas de acordo com elas. Assim como nos três níveis anteriores, existem rituais especiais para sincronização a cada duas semanas (geralmente) - há uma troca de status e indicadores-chave.

Liderado por toda a estratégia. A maneira como é definida não é descrita pela estrutura.

Prós

1. Um número significativo de ferramentas muito boas (WSJF, Kanban, Gemba, etc)
2. Etapas formalizadas e prescritas para SDLC, desde a gravação do código (prescrito pelo TDD) até a execução de varredura estática e alternância de CI / CD e recurso. Se cada uma das práticas é boa ou não é outra questão, mas pelo menos existe um plano e todos o seguem.
3. O processo pode ser entendido, explicado e implementado.
4. Cada pessoa na estrutura deste processo recebe uma função bastante estritamente definida.
5. Aumenta a transparência da empresa para quem nela trabalha.

Desvantagens

1. Tempo suficiente para responder a uma incompatibilidade da realidade com as expectativas
2. Uma enorme quantidade de dinheiro é gasta em comunicação e reuniões
3. As soluções frequentemente recomendadas dentro da estrutura estão desatualizadas

Introduzir ou não? Acredito que, se houver uma escolha, então não, é melhor reduzir a dependência entre departamentos e projetos. E se não houver escolha e você precisar gerenciar um grande projeto, é bem possível.