Noções básicas sobre desenvolvimento ágil e EA

Arquitetura ágil e corporativa se encaixam perfeitamente. Ambos resolvem diferentes partes do problema.

O desenvolvimento ágil de software se destaca na construção de algo que nunca tivemos antes e não sabemos como. A arquitetura corporativa se destaca antes das decisões quando você não sabe o que fazer.

Agilidade, Arquitetura Corporativa e desenvolvimento de software se encaixam em três áreas

  1. arquitetar uma empresa ágil
  2. práticas de trabalho ágeis para desenvolver arquitetura empresarial de melhores práticas
  3. desenvolvimento ágil de software e arquitetura empresarial

A maioria dos arquitetos pula para o fim. Eles tentam encaixar dois mundos extremamente divergentes, geralmente sem parar para entender nenhum deles.

Tive uma conversa divertida com o engenheiro de confiabilidade de sistemas recém-contratado. O especialista em SRE estava animado. Finalmente começamos as práticas modernas de CI / CD. Ela me perguntou o que a equipe da EA estava fazendo para ajudar.

Eu tive que sorrir quando ela perguntou, 'o que a EA Team está fazendo para ajudar? ' O que ela realmente quis dizer foi, 'o que você está fazendo para me apoiar hoje? ' Hoje, contra seus desafios imediatos, poderia ser - nada. Ela saltou para como a equipe da EA apoiou seu trabalho diário.

Ela nunca viu o roteiro de portfólio que trouxe contêineres, gerenciamento de dados de teste e, francamente, um conjunto de testes automatizados ridiculamente insuficiente. Ela não percebeu que o mesmo velho roteiro identificou um ponto de transição que financiou seu trabalho.

Equipes de EA bem-sucedidas cumprem seu propósito. Eles não entregam em mais nada. Mesmo se eles pudessem.

Seis casos de uso cobrem todos os aspectos da arquitetura ágil e corporativa

Uma estrutura simples para pensar sobre arquitetura corporativa é perguntar a que eles oferecem suporte.

  1. Estratégia de apoio
  2. Portfólio de suporte
  3. projeto de apoio
  4. apoiar a entrega de soluções

https://conexiam.com/togaf-9-2-body-of-knowledge/

Desenvolvimento Ágil e Arquitetura Corporativa

Ao vincular ao desenvolvimento ágil de software, a mesma pergunta é feita, o que a equipe deve ajudar a responder. Parte do alinhamento é impulsionado pelo que a equipe de arquitetura corporativa foi projetada para oferecer suporte.

  1. definindo a abordagem ágil
  2. orientando o acúmulo no sprint
  3. restringindo os sprints
  4. resolução de dependência de produto cruzado
Produto de trabalho de arquitetura ágil e empresarial

Arquitetura ágil e empresarial: defina a abordagem ágil

Normalmente, uma equipe de EA que está servindo à estratégia e portfólio irá definir a abordagem ágil.

produtos

Os produtos aparecem em um roteiro como lacunas ou pacotes de trabalho. A equipe da EA pode falar sobre capacidade ou serviço comercial. Quando isso acontecer, espere ver os produtos novos ou reformulados.

Plataformas

EA apoiando produto de trabalho de desenvolvimento ágilO que oferecerá suporte ou operação ao produto? Saber se o produto é autônomo, baseado em uma nova plataforma, usando uma plataforma existente ou aproveitando plataformas de terceiros, definirá os elementos-chave de sua abordagem ágil, geralmente bem antes do sprint zero.

Os praticantes mais fracos se fixarão em termos de definição como "Plataforma". Uma definição nítida e excessivamente precisa é uma armadilha. Pense um pouco, é perfeitamente razoável que alguém fale sobre SAP, 0365, Facebook, Pega ou mesmo Angular e Containers como plataformas. O termo precisa de um contexto para uma definição restrita. Tudo que você precisa é que o consumidor e a operadora concordem. Eu sucumbi à tentação de especificar um produto que fosse uma plataforma consumida por outras pessoas. Os pedantes tentaram determinar se era produto ou plataforma.

Estratégia de entrega de serviço

É melhor que os roteiros de nível superior sejam claros sobre como implementar a transformação. Exemplos incluem.

  • Construir uma capacidade interna robusta ou usar terceiros?
  • Garantir sistemas sustentáveis de vida longa ou tratar alguns ou todos os produtos como lenços de papel descartáveis?

Pontos de descanso de valor principal

Usamos rotineiramente Pontos de Repouso de Valor como sinônimo de transições de arquitetura. Sempre forneça aos seus stakeholders uma rampa de saída. Usamos rampas de saída por dois motivos:

  1. Quando o esforço para alcançar o próximo ponto de repouso excede o valor incremental.
    Esta é uma conversa de ROI. As conversas sobre ROI geralmente levam a uma mudança de prioridade.
  2. Quando o esforço para chegar a um ponto de descanso pode chegar a um descanso mais emocionante ou gratificante.

As conversas de trade-off fornecem um dos resultados mais valiosos de um exercício de estratégia ou roteiro de portfólio. Os recursos são finitos. Os líderes seniores estão sempre em busca do melhor caminho a seguir, não do maior retorno potencial. O melhor caminho. As considerações incluem o valor comparativo em repouso e o valor potencial como trampolim para outra atividade.

Os implementadores raramente entendem essas conversas. Eles se tornam emocionalmente comprometidos com um caminho ou ponto de descanso. Especialmente quando a existência do produto, ou o próximo lançamento, está sob consideração.

Arquitetura Agile e Enterprise: Guia Backlog no Sprint

Profissionais de EA que oferecem suporte a portfólio e projeto geralmente se envolvem com equipes ágeis orientando o backlog no Sprint.

Eu observei que surpreende muitos evangelistas do Agile que as organizações profundamente comprometidas com os benefícios do desenvolvimento de software ágil permaneçam profundamente comprometidas com o planejamento e orçamento de longo prazo. Normalmente, a conversa confunde uma preferência cultural mítica por uma cachoeira.

Em vez disso, pense no problema. O planejamento e o orçamento de longo prazo existem devido à complexidade do ecossistema. Cada organização tem vários caminhos a seguir e diferentes restrições. Organizações bem-sucedidas realizam priorização e compensação. Sem alcançar o futuro preferido nas restrições de tempo e recursos, nenhum trabalho deve começar.

Produto de trabalho de arquitetura ágil e empresarial

A arquitetura corporativa se resume a restrições. Cada restrição limita a criatividade de uma equipe ágil de desenvolvimento de software. Sem uma necessidade primordial de restrição, não o faça. Apenas não faça isso.

Roteiro para orientar o produto

O roteiro para orientar o produto está entre os resultados mais difíceis para uma equipe EA talentosa. A tensão fundamental de saber para onde você está indo sem saber como chegar lá é um ponto quente.

Muitas equipes de arquitetura caem na armadilha da precisão artificial ou da onisciência imaginária. Ambos são maneiras sofisticadas de dizer pensamento em cascata.

O desenvolvimento ágil oferece resultados impressionantes quando a equipe tem todos os graus de liberdade. Basta pensar sobre o ponto ideal de um produto autônomo greenfield.

Freqüentemente, uma boa arquitetura se resume a fornecer as restrições mínimas para garantir que as decisões não falhem em um teste que não é aparente para o tomador de decisão. Se o tomador de decisão puder ver o teste, você não precisa da arquitetura para restringi-lo. A arquitetura existe para guiar ou restringir a escolha quando o fator está fora do campo de visão do arquiteto.

Um roteiro clássico da EA abordará transições, lacunas e pacotes de trabalho. Será incompreensível para uma equipe de produto. Faça a transição do roteiro para os termos certos com o product owner. O product owner precisa entender as restrições dentro das quais está operando.

Espere tensão

Roteiro para guiar épico

O roteiro para guiar épico é o resultado mais difícil para uma equipe EA talentosa. Sempre penso em ficar preso em um campo minado durante um bombardeio. Não há nenhum lugar seguro para ir.

As expectativas da linha do tempo tornam a armadilha comum do pensamento em cascata ainda pior. Saltar à frente da jornada de descoberta de uma equipe ágil com precisão artificial e onisciência imaginária mina tudo no desenvolvimento ágil. Só não faça isso!

Sem produtos totalmente integrados ou restritos, os roteiros para o épico estão fadados ao fracasso. Os exemplos, quando necessário, incluem vários produtos que coexistem em um ecossistema e compartilham dados de referência. Consumir a exaustão de dados uns dos outros frequentemente exigirá épicos associados ou regulamentações punitivas complexas.

Sem pressão externa, não execute esta atividade. Especificação excessiva e design excessivo por profissionais auto-designados oniscientes são algo que inventamos para dispensar o Agile. Se você for forçado a roteiros para épicos, certifique-se de entender exatamente por que é necessário restringir a criatividade de seus desenvolvedores de software. Cada restrição que restringe sua liberdade e criatividade deve servir melhor para superar a entrega de valor que vem da criatividade desenfreada

Espere o fracasso.

Quando alcançamos o sucesso, adotamos ativamente a linguagem de métodos como o SaFE e estruturamos o roteiro em termos de temas estratégicos e pistas de arquitetura.

Valor da empresa

A arquitetura superior sempre abordará as preocupações comuns das partes interessadas. Deve fornecer um conjunto de princípios internamente consistente que forneça restrições na definição de valor. Aqui, a arquitetura está garantindo que a negligência na avaliação de valor não crie custos posteriores.

A avaliação de valor desleixado é o problema mais comum que uma boa arquitetura aborda. Regra de considerações transitórias. Uma dicotomia clássica é a distinção entre tempo tático de comercialização e segurança, resiliência ou estabilidade. Quando sua organização tem imperativos, os gerentes de produto e as equipes scrum precisam ser informados. Caso contrário, eles não podem avaliar adequadamente o backlog em relação às métricas que realmente importam.

Restrinja proprietários de produtos 'ascendentes'

Muitos proprietários de produtos não têm visibilidade de por que seu produto existe ou Muitos proprietários de produtos não têm visibilidade de porque seus produtos existem ou qual é a função do ecossistema. Restrinja a liberdade de um proprietário de produto de baixo para cima, proibindo a escolha ou impondo pontuação e avaliação.

Arquitetura Agile e Enterprise: Restringir sprints

Os profissionais de EA que desenvolvem arquitetura para oferecer suporte à entrega de projetos e soluções devem limitar os sprints. Profissionais orientados a portfólio que estão desenvolvendo um ecossistema ou plataforma também devem esperar trabalhar com as equipes ágeis aqui.

Restringir sprints pode ser emocionalmente difícil para novos arquitetos que costumavam ser ativos no desenvolvimento. É difícil deixar seu antigo emprego para trás. Freqüentemente, a especialização no assunto leva a um excesso de especificação e design. Cada restrição que restringe sua liberdade e criatividade deve demonstrar que anula a entrega de valor que vem da criatividade desenfreada.

A dificuldade de deixar seu antigo emprego é porque tratamos todos os que são novos na arquitetura corporativa como um newb. O recém-formado e a pessoa com 30 anos de experiência em algo diferente da arquitetura corporativa são novos arquitetos.

Eu vejo novos arquitetos com anos de outro experiência mais perto. Eles têm muitos hábitos ruins que os impedem de serem arquitetos de alto desempenho.

Produto de trabalho de arquitetura ágil e empresarial

Nathan e Sam falando sobre desenvolvendo novos arquitetos empresariais. É muito importante que todos arquitetos empresariais compreender os direitos de decisão e servir as partes interessadas.

Critérios de aceitação

Uma ligação muito simples em um sprint são os critérios de aceitação definidos externamente. Se a arquitetura requer algo, enquadre-o como critério de aceitação. A menos que o nível de detalhe esteja muito próximo de interferir na criatividade ágil, a restrição será algo consistente. Haverá uma demanda da arquitetura de negócios, arquitetura de aplicativo de arquitetura de dados ou arquitetura de infraestrutura. A especificação da arquitetura será um principal, padrão ou padrão. Forneça a restrição como critério de aceitação. Alinhe para um Sprint ou libere. Então saia do caminho e observe a criatividade

Guia do Governador

Eles interpretaram razoavelmente a orientação e restrição da arquitetura de destino?

  • Em caso afirmativo, sua interpretação deve ser aceita como conformidade. Este é um ponto chave. Uma boa arquitetura pode ter várias opções de implementação. O implementador não é obrigado a seguir uma opinião. Se a escolha de implementação for uma interpretação razoável, ela é compatível.

Valor (medidas e pontos de repouso)

Um ponto recorrente de conflito é a compreensão do valor.

As melhores práticas de desenvolvimento ágil de software são focadas no valor. Infelizmente, a maioria dos praticantes tem uma compreensão limitada do valor. A abreviatura é que o valor é expresso em termos de algo que foi entregue. O valor é evidente na entrega.

Em um mundo complexo, a coisa entregue pode facilmente ter um valor degradante. Um exemplo fácil são os recursos direcionados para longe dos clientes-alvo ou a movimentação de trabalho entre unidades de trabalho. Isso é comum quando um grupo é servido pelo produto. Recomendamos fortemente o aprendizado de práticas básicas de Lean e Seis Sigma sobre otimização e valor local. Da mesma forma, os conceitos do Business Model Canvas de Cliente-alvo e Proposta de Valor são úteis.

Para enfrentar esses desafios, esperamos que a arquitetura de negócios seja definitiva sobre como o valor é avaliado. A arquitetura precisa fornecer critérios de avaliação de valor para as equipes de desenvolvimento.

Greenfield, evolução ou revolução

Na Fase E do TOGAF há uma etapa legal. Observe o pacote de trabalho e selecione uma estratégia apropriada.

O trabalho será Greenfield, Evolucionário ou Revolucionário? Queremos preservar o máximo possível, refatorar radicalmente ou começar do zero? Esta é uma orientação crítica e uma forte restrição em uma equipe ágil. Devem começar do zero (Greenfield)? Melhorar os sistemas existentes de forma incremental (evolução)? Ou realizar uma mudança radical para eliminar os atritos e aborrecimentos com os quais vivemos (Revolucionário)?

A escolha da abordagem pode não ser deles. Quando eles não têm escolha, isso sempre será motivado por escolhas acima de sua classe de pagamento.

Restringir interfaces

Quando um produto deve se ajustar a um ambiente corporativo existente ou oferecer suporte a um ambiente corporativo em evolução, as interfaces são essenciais. As interfaces serão orientadas por dados e métodos. Mesmo quando o produto está emergindo, em um mundo complexo, não haverá liberdade para permitir que a estrutura de dados ou interface também surjam. Dados mestres, dados de referência e sistemas existentes restringirão o desenvolvimento ágil.

Os sistemas existentes não serão alterados. Até mesmo o F-22 Raptor teve que se conectar com sistemas legados usando interfaces desenvolvidas na década de 1970. Mesmo um avião tão caro não poderia ter os sistemas legados remodelados. O Raptor se encaixa na interface e estrutura de dados existentes.

Uma restrição comum negligenciada por equipes que se movimentam rapidamente é como a legislação multijurisdicional ou um plano de negócios afetará o produto. Nesses casos, a equipe da EA tem o dever de aprofundar e desenvolver as restrições mínimas necessárias para evitar que o produto exija uma reformulação radical em um momento inconveniente. Como todas as restrições à criatividade, bons profissionais de EA entendem a importância de apenas o suficiente.

Arquitetura Empresarial e Agile: Resolva Dependência

Pode-se esperar que os profissionais de EA que trabalham em uma empresa precisem intervir e resolver dependências e conflitos que surgem entre soluções de produtos e sistemas. Basta olhar para a fase G do TOGAF, que destaca a necessidade de orientação e mudança de arquitetura. O desenvolvimento ágil e o escopo da integração moderna tornam esse serviço de necessidade de longa duração mais importante do que nunca.

Produto de trabalho de arquitetura ágil e empresarial

Desbloquear o portfólio

Mesmo que você não esteja limitado pelo legado, haverá vários produtos avançando. As equipes de desenvolvimento ágil de práticas recomendadas criativas encontrarão maneiras diferentes de resolver os problemas. É tolice esperar que a criatividade não crie conflito. Pode-se esperar que uma boa equipe de EA trabalhando na Fase G, onde acontece todo o desenvolvimento ágil de software, desbloqueie o conflito em todo o portfólio da empresa.

Identifique os verdadeiros interessados

As partes interessadas reais são freqüentemente difíceis de encontrar. Muitas decisões táticas são delegadas. Quando a delegação é formal, a equipe ágil pode esperar ter um acesso razoável. Onde a delegação é informal, pode-se esperar que especialistas locais no assunto e usuários conduzam uma agenda desalinhada.

A equipe de arquitetura corporativa não tem uma habilidade especial para obter engajamento. Eles têm a capacidade de representar as preocupações das partes interessadas por meio de uma arquitetura superior.

Cruze o portfólio

Os proprietários do produto e outros membros de uma equipe de desenvolvimento são levados a entregar um produto de forma incremental. Produto mínimo viável e entrega incremental estão no cerne da proposta de valor ágil.

Toda a abordagem ágil vem da falha observada em tentar imaginar todas as interações em um portfólio complexo, esse é o caminho da falha. O projeto corporativo detalhado de cima para baixo pode funcionar para sistemas isolados. Dentro de um ecossistema que está mudando, o design de cima para baixo sempre falha. Esse caminho de falha é o motivo pelo qual o Agile existe e por que o Agile é preferido.

É quase impossível imaginar um futuro complexo, esforços para fazê-lo muitas vezes se transformam em farsa. No entanto, precisamos fazer apenas o suficiente. À medida que vários produtos emergem, novos conflitos e sinergias emergem. Uma boa equipe de EA, com um rico entendimento das mudanças nas prioridades de sua empresa, ajudará a lidar com sinergias e conflitos.

Quando a equipe da EA descobre cruzamentos, eles precisam usar seu insight e engajamento para obter a melhor resposta. Freqüentemente, essa será uma abordagem de gerenciamento de risco. Avaliar rapidamente o conflito para determinar se a resolução pode ser adiada é a primeira etapa. Tirar vantagem da sinergia e evitar conflitos é caro. Caro e demorado. Eles interferem diretamente no tempo de colocação no mercado.

Falamos em termos de forças de mercado e destruição criativa quando devemos cruzar o portfólio.

Solte o impacto

Arquitetura suficiente significa que cada contingência, cada restrição, cada conflito, não foi descoberto antes do lançamento.

Há um caso em que uma equipe de arquitetura passa por uma emergência. É uma crise pós-lançamento. Aqueles raros casos em que as implicações vão além do produto. O produto está em estado selvagem. Usuários finais dentro e fora de nossa organização estão usando. Eles estão lidando com um defeito ou, pior, criando riscos e responsabilidades imprevistos para nossa organização.

Conclusão da Arquitetura Ágil e Corporativa

Tanto o desenvolvimento ágil quanto a arquitetura corporativa sofrem de má aplicação crônica. Muitas vezes ao mesmo tempo.

Seis casos de uso cobrem todos os aspectos da arquitetura ágil e corporativa. A arquitetura corporativa orienta e restringe o desenvolvimento ágil de software.

Ao se vincular ao desenvolvimento ágil de software, os arquitetos corporativos precisam:

  1. definindo a abordagem ágil
  2. orientando o acúmulo no sprint
  3. restringindo os sprints
  4. resolução de dependência de produto cruzado

Arquitetura corporativa se resume a limites - faça isso, não faça aquilo. Cada limite restringe a criatividade de uma equipe ágil de desenvolvimento de software. Sem uma necessidade primordial de restrição, não o faça. Apenas não faça isso.

https://conexiam.com/togaf-9-2-body-of-knowledge/

O Corpo de Conhecimento TOGAF apóia o desenvolvimento de uma abordagem de governança eficaz.

Junte-se ao Kickstart de Arquitetura Corporativa Pessoal da Conexiam

Programa gratuito de 12 semanas para ser um arquiteto empresarial melhor

Rolar para cima