Noções básicas sobre arquitetura empresarial e ágil

Arquitetura Corporativa e Ágil - Guia do Backlog no Sprint

Equipes ágeis fortes encontram o caminho mais eficaz a seguir. O planeamento e a orçamentação a longo prazo existem devido à complexidade do ecossistema. O desafio é unir o planejamento de longo prazo à criatividade ágil. Unir o planejamento de cima para baixo e a execução de baixo para cima.

Eles precisam ser informados sobre as prioridades organizacionais em termos que possam ser incluídos no gerenciamento do backlog.

O Agile existe porque as pessoas mais próximas da solução podem encontrar o caminho mais eficaz. Organizações bem-sucedidas realizam priorização e compensação. Sem alcançar o futuro preferido devido às restrições de tempo e recursos, nenhum trabalho deverá começar.

Uma equipe de EA precisa ter a capacidade de oferecer suporte Portfólio e Projeto para guiar o backlog no sprint.

Problema Previsível: Garantir que os resultados esperados, o valor, as expectativas de desempenho em cascata e as restrições orientem o lançamento e o desenvolvimento do produto.

Parte difícil: Muitos evangelistas ágeis ficam surpresos com o fato de as organizações que adotam a metodologia ágil permanecerem profundamente comprometidas com o planejamento e o orçamento de longo prazo. Muitas vezes temos que superar a mitologia de que há preferência cultural por cachoeira.

Roteiro para orientar o padrão do produto

Problema Previsível: Ter um roteiro de produto abrangente, em vez de um ciclo de lançamento de recursos.

Abordagem: Usando um técnica de roteiro de arquitetura onde o produto, ou família de produtos, substitui o Portfólio. Garantir que os relatórios normais do produto incluam atividades em direção aos estados de transição.

Partes difíceis: Um excelente gerenciamento de produtos proporcionará um roteiro abrangente de produtos. Muitos proprietários de produtos bottom-up não têm experiência no gerenciamento do ciclo de vida ou na integração de um conjunto de produtos integrado. A equipe de EA precisará preencher ou substituir com base na habilidade da organização do produto.

Muitas equipes de arquitetura caem na armadilha da precisão artificial ou da onisciência imaginada. Ambas são maneiras elegantes de dizer pensamento em cascata. Um roteiro de arquitetura clássico falará de transições, lacunas e pacotes de trabalho. Isso será incompreensível para uma equipe de produto. Mude o idioma para produto e terminologia ágil. O proprietário do produto precisa entender as restrições dentro das quais está operando.

Construir o roteiro requer arquitetura suficiente. A única abordagem escalável é 'Apenas o suficiente.' Apenas o suficiente significa impor a prioridade organizacional e evitar problemas previsíveis. Apenas o suficiente significa ficar fora do design do produto. Use padrões de arquitetura que atendem todo o portfólio. Apenas o suficiente significa ignorar a sinergia potencial. Apenas o suficiente significa focar em problemas previsíveis. O valor de evitar problemas previsíveis é alto. Apenas o suficiente significa não ter medo de usar a destruição criativa. Use um conceito de ciclo de vida esperado para impulsionar a refatoração agressiva (abordagens novas e revolucionárias).

O uso das técnicas com o proprietário do produto ajuda a trazer as prioridades e restrições organizacionais para o roteiro do produto.

• • Qual produto ou recursos principais buscar de acordo com diferentes critérios – Roteiro de Arquitetura Tipo 4: Cenários
  • Quais produtos ou recursos agregarão valor (benefício, trabalho e incerteza – Roteiro de arquitetura Tipo 1: mapa de calor
  • Quando são necessárias mudanças no produto e na plataforma – Roteiro de Arquitetura Tipo 2: Ciclo de Vida
  • Qual é a dependência e o impacto do trabalho e da mudança – Roteiro de Arquitetura Tipo 3: Impacto e Dependência

Roteiro para guiar o padrão épico

Problema Previsível: Usando épicos para implementar resultados e restrições de cima para baixo no produto.

Abordagem: Usando estados de transição bem construídos em um técnica de roteiro de arquitetura onde o produto, ou família de produtos, substitui o Portfólio. Garantir que os relatórios normais do produto incluam atividades em direção aos estados de transição.

Partes difíceis: Requer produtos totalmente integrados ou fortemente restritos. A área de foco precisa estar na integração ou nos pontos de restrição. Vários produtos coexistindo dentro de um ecossistema e compartilhando dados de referência é um exemplo simples.

É comum cair na armadilha do design inicial. O foco deve estar nas áreas onde os desenvolvedores de software precisam limitar sua criatividade devido ao ecossistema ou a requisitos externos. Idealmente, isso deveria ser feito antecipadamente, e não como uma reação à dívida técnica.

Quando conseguimos isso, adotamos ativamente a linguagem de métodos como o SaFE e enquadramos o roteiro em termos de temas estratégicos e pistas de arquitetura.

Padrão de valor empresarial

Problema Previsível: Garantir que os fatores críticos de sucesso incluídos na transição e nos estados-alvo orientem a preparação ágil do backlog e o planejamento épico.

Abordagem: Traduza medidas e objetivos de cima para baixo em critérios consumíveis para uma preparação ágil do backlog. Garantir que os relatórios normais do produto incluam a seleção de atividades e a conclusão em direção ao valor declarado.

Partes difíceis: As medidas descendentes devem ser definitivas e fáceis de avaliar. Por exemplo, não se pode pedir à equipe ágil que desenvolva um equilíbrio sutil entre o tempo de colocação no mercado e a resiliência. É necessária uma terminologia inequívoca.

Quaisquer alterações nas medidas de cima para baixo causarão confusão. Isto é especialmente verdadeiro se um estado de transição tiver sido alcançado.

Para produtos internos, sempre nos certificamos de ter um modelo de custos sólido para produtos digitais antes de introduzir medidas de custos. Sem um modelo de custos, os custos operacionais e de plataforma serão perdidos e todos os custos serão justificados nos custos de implementação. Planeje ajudar o gerente de produto interno com entendendo ITFM. Por outro lado, os gestores de produtos digitais externos normalmente têm uma compreensão muito forte dos custos.

Restringir o padrão do proprietário do produto 'de baixo para cima'

Problema Previsível: Proprietários de produtos visualizam toda a empresa através das lentes de seus produtos e de seus usuários diretos.

Abordagem: Documente o produto e a função dentro do ecossistema. Documente as restrições que se aplicam ao produto. Critérios de avaliação de documentos. Garantir que os relatórios normais de produtos incluam o progresso em direção aos estados de transição e atividades alinhadas com o valor da empresa.

Partes difíceis: Os proprietários de produtos digitais internos costumam ser um elo fraco. Os desafios comuns incluem não compreender:

• • por que seu produto existe
  • papel do produto no ecossistema
  • criticidade das restrições empresariais
  • quem são os tomadores de decisão (financiadores)
  • como obter orientação sobre prioridades empresariais e medidas de valor

As equipes de EA que apoiam o portfólio e o projeto provavelmente precisarão restringir os proprietários de produtos “de baixo para cima”. Requer um esforço deliberado e atribuição de pessoal.