Agilidade em empresas dinossauro

Esse post é um resumo do que foi discutido no Openspace sobre Agilidade em empresas dinossauro proposto por Daniel Teixeira no primeiro dia do Agile Brazil 2016.

A sala estava lotada e a participação foi bastante ativa. Participaram pessoas de diversas empresas privadas e também do governo, com desafios comums ligados principalmente a cultura dentro das empresas “dinossauro”.

O grupo entendeu que “empresas dinossauro” não necessariamente são empresas de muito tempo de existência , mas sim empresas com uma cultura “dinossaurica”!!

Tentei organizar as minhas anotações e sintetizar o conhecimento que emergiu. Me perdoem se algo não fizer muito sentido. No momento que anotei o sentido era evidente!! 🙂

daniel

Cultura

  1. Coloque o Sponsor no taxi. Colocar o sponsor ciente das mudanças, explicar como funciona o Agile e os ganhos atingidos. “A agilidade não pode ser imposta e sim aderida.”
  2. Promova o intercâmbio entre pessoas do business e da TI. Como convencer o business? Coloque pessoas do business na TI e vice-versa. Isso pode quebrar a resistência das pessoas.
  3. Cole na onda de inovação. Nao estimule a TI Bimodal, use a seu favor como porta de entrada. A onda da inovacao deve permear toda a empresa.
  4. Quebre o apego ao passado com pilotos que entreguem valor. Não tente abraçar o mundo de uma vez só, faça pilotos em projetos e venda a idéia. Vender a ideia de cima pra baixo ou debaixo pra cima? “Agile, cabeça que se abre e nunca mais se fecha.” Use cases de empresas confiáveis como exemplo para vender a idéia.
  5. Contrate de forma ágil. Piratas fazendo ágil sem o cliente saber, mostrando benefícios e resultado.
  6. Quebre a resistência com DevOps. Use DevOps para quebrar a resistência. Suba as demandas sem o cliente saber e depois explique os ganhos e resultados. Use DevOps para quebrar a resistência da infra e adotar a cultura de infraestrutura ágil.
  7. Capacitação pela porta da frente. Promova a capacitação agile via PMO.
  8. Colaboração. Desenhe o processo ágil em conjunto.

Processos rígidos

  1. Use o MPSbr e o BPM ao seu favor. Identifique como ser mais ágil em cada processo, utilizando idéias do Agile para otimizar.
  2. Foque no ROI. Como mostrar dados para o cliente? Planeje e determine o custo no início e mostre os ganhos no final do projeto. O Bimodal pode ser porta de entrada para o agile quando há uma necessidade do controle devido a processos muito rígidos.
  3. Foque na melhoria de processos. Veja o que se tem de problemas no processo hoje e como a agilidade poderia resolver.
  4. Leve agile para a área de produto e não apenas na TI. o Agile (MVP, Sprints, Retros, etc) Mostrar a melhoria de cada projeto, usar o MVP, mostrar valor mais cedo.
  5. Colaboração. Crie processos ágeis em conjunto para quebrar a resistência. Esteja pronto para lidar com a resistência das pessoas. Promova a colaboração. Exemplos de resistência extrema: Cliente grita ao ouvir a palavra ágil; A área de qualidade não quer receber coisas antes; Contratação barras por compras e fornecedor perdeu o projeto.

Ansiedade

  1. Mudanças geram ansiedade e isso não é exclusividade do agile. Procure criar uma cultura de aceitação das mudanças. Falsa noção de controle do prazo fixo, custo fixo, time fixo, arquitetura fixa, quando chega próximo é que se vê que não vai conseguir gera ansiedade. Cultura de aceitar a mudanca combate isso.
  2. Capacitar o sponsor combate ansiedade. Cuidado com a falta de sponsor. O que é importante para o sponsor? Ele entendeu o conceito da agilidade? Você sabe e comunica porque mudar? Capacitar sponsor combate isso.
  3. Definicao de Budget gera ansiedade. No geral a direção acha que ágil é entregar rápido. Metáfora: “Vc pode pular do penhasco mas tem de cheguar rápido no chão com vida”. Livro “Scrum dobro em metade do tempo” explica os porquês. Promova leitura e grupos de estudo. Mudar para entregar o que as startups entregam.

Como tratar o legado?

  1. Novos sistemas demandam alterações no legado. Livro: trabalhando com código legado.
  2. DevOps ajuda a tratar o legado. Código legado é o que vc tem medo de alterar. Não tem documentação geralmente. Rastreabilidade não abrange tudo. Para atacar esse problema: Cobrir com testes , práticas DevOps, deploy canary, testes de integração ao alterar uma rotina.

Perfis juniores vs seniores

  1. Maturidade agile leva um certo tempo. Depois de 6 sprints o negócio melhora mas o projeto acaba.
  2. Problema de estimativas divergentes e imaturas acontece no início da adoção/transformação ágil. A média de maturidade do time tem de ser alta no Agile. Calibração das estimativas demora um pouco mesmo pela característica empírica do Agile.
  3. “Senioridade do júnior vs a junioridade do senior” Simplicidade nas soluções. Não fazer coisas mirabolantes.

Engajamento:

  1. Criação de um modelo de bootcamp ajuda o engajamento. “Escolhe em qual projeto vc quer trabalhar”. Melhorar capacitação, empoderamento e engajamento.
  2. Da pra fazer engajamento sem empoderamento? Daily, retro, planning , dar espaço para as pessoas falarem e contribuírem dá empoderamento para as pessoas. Algumas pessoas andam na contramão. Foi citada uma experiência de uma advertência por ter um livro específico em cima da mesa. O argumento foi que ele estava fazendo uma doutrinação por baixo dos panos.
  3. Promover uma experiência botton up de implantação de Agile. Agile pode emergir por opcao e iniciativa do time. É importante que a gestão tenha abertura para ajudar a promover as mudanças.
  4. Dar poder para pessoas sem maturidade pode ser tiro no pé. Time imaturo Geralmente fica em entregas técnicas e tem de se focar em entrega de valor. Empoderamento tem de ter experiência. Não adianta só entregar, tem de envolver o business. Faça demos e retros para promover o engajamento do business e tente ter um time dedicado para apagar incêndios com rotatividade do time.

Processo engessado

  1. Aceite os diferentes tipos de motivação. Algumas pessoas não puxam a mudança , não são pro ativas para promover mudancas, são boas em executar e executam bem. Tem de ser trabalhado de outra forma. Moving motivators do Management 3.0 identifica o que motiva aquela pessoa.

Falsa noção de controle

  1. “Status melancia: verde por fora e vermelho por dentro”. Métricas de vaidade : tem um número bonito mas sem valor. OKR é uma maneira diferente para pensar em métricas.
  2. “Travestir as coisas com ciência/tecnologia dá uma falsa sensação de controle e segurança.” Adote métricas simples e significativas.
  3. Não tenha medo de errar. Ver o erro como uma coisa boa e não tentar esconder os erros. “Diga como me medes que eu digo como me comportarei”

Quem são os facilitadores? O que eles fazem? Como vivem? … :)

facilitation-img

Depois de um final de semana intenso no Learning Camp de Learning 3.0, saí com muitas “pulgas atrás da orelha”. Uma delas foi a seguinte: Quem são os facilitadores? O que eles fazem? Como vivem? … 🙂

Para responder e organizar isso na minha cabeça, fiz uma retrospectiva das vivências do final de semana e algumas pesquisas breves para consolidar o aprendizado. O primeiro passo foi definir o papel de facilitador.

O facilitador é o responsável por conduzir o processo de uma sessão onde os participantes trabalham juntos para atingir determinado objetivo. Ele deve ser neutro com o relação do produto, ou seja, não julgar nada nem ninguém. Ele deve encorajar os participantes a usar o processo definido para a sessão da maneira mais efetiva possível, para cumprir as tarefas, respeitando as restrições em um período de tempo pré-definido.

Um ponto super importante que pude perceber foi que, como o tempo é curto, a abertura da sessão feita pelo facilitador dava o tom da sessão. É importante na abertura que após a sua apresentação o facilitador explique o processo que será usado na sessão incluindo qual será o seu papel e o dos demais participantes, se a sessão vai ser formal ou informal, quais os resultados esperados ao final da sessão, quais materiais estão disponíveis, quais são as tarefas e o fluxo de execução que deve ser seguido e quais restrições devem ser respeitadas, principalmente o tempo.

Por fim, para ajudar a verificar se um facilitador foi efetivo após uma sessão, pensei em como seria um form de avaliação dos diversos aspectos para enviar aos participantes. Isso seria uma forma de obter feedback e melhorar a cada sessão de facilitação.

O facilitador…

  • ajudou a dar um tom positivo para as discussões?
  • foi neutro em relação ao produto?
  • ajudou a manter o grupo focado?
  • ajudou o grupo a se manter no tempo?
  • ajudou o grupo a trabalhar melhor?
  • encorajou a participação de todos?
  • esclareceu as atividades e passos do processo definido para a sessão?

E você o que acha? Alguma crítica, sugestão ou comentário?

Link para a page de facilitadores do Learning 3.0: http://www.learning30.co/facilitators/

Architecture Owner

Architecture Owner

Outro dia eu estava conversando com um desenvolvedor super bom de serviço. Ele me disse que acha “waste” essa diversidade de práticas e processos de desenvolvimento ágil. Ele tem muita dificuldade em reunir e visualizar todas as práticas e métodos funcionando juntos porque veio de um contexto muito técnico onde o que tinha de ser feito era apenas escrever código e entregar o software. Ele me disse que gostaria de saber, por exemplo, o que o arquiteto de software faz. 🙂 Eu achei sensacional a duvida dele e expliquei rapidamente o papel do arquiteto, mas isso ficou na minha cabeça e resolvi fazer esse post.

O papel de arquiteto de software ágil hoje está bem mais consolidado. O Disciplined Agile Delivery define o papel do Architecture Owner e as principais responsabilidades desse papel são:

  • Guiar a criação e evolução da arquitetura da solução.
  • Mentor e o Coach dos membros do time nas práticas e questões de arquitetura.
  • Entender a direção arquitetural, os padrões da organização e garantir que o time esteja aderente à eles.
  • Garantir que o sistema será suportado de maneira fácil encorajando um design adequado e tocando as refatorações necessárias para garantir um bom design.
  • Garantir que o sistema seja testado e integrado frequentemente.
  • Tem a palavra final sobre as decisões técnicas, mas deve engajar o time nas decisões e não dita-las.
  • Lidera o esforço de visualização inicial da arquitetura.
  • Trabalhar junto ao time de arquitetura corporativa (se ele existir).

No ciclo de vida básico do DAD existe um marco específico para provar a arquitetura o mais cedo possível na fase de construção. É uma forma do arquiteto mitigar os riscos técnicos e um checkpoint de governança para sinalizar a gerência sênior e outros stakeholders as decisões e questões técnicas.

Por que você deveria considerar Microservices em um próximo projeto?

Por que você deveria considerar Microservices em um próximo projeto?

Para responder essa pergunta vou assumir que você desenvolve aplicações monolíticas. Os “monolitos” são o padrão “de fato” para a construção de aplicações de negócio hoje em dia. Você vai argumentar que as aplicações que você cria tem um alto-nível de modularização com alta-coesão e baixo acoplamento e que você desenvolve serviços e tal. Tudo bem, mas você tem de concordar que não é comum quebrar a aplicação em diversos serviços, implantáveis separadamente e manter essa prática em produção. Isso é novidade. Concorda?

Bom, se você já passou pelo desenvolvimento de uma aplicação grande em Java EE ou .NET, em algum momento já passou pelos seguintes problemas:

  •  A produtividade caiu ao longo do projeto. Sua aplicação se tornou difícil de manter a medida que a aplicação cresceu. Isso resultou em ciclos longos de build para implantar novas funcionalidades ou mesmo novos serviços, e você não conseguiu fazer muito mais rápido.
  • O deploy  era “tudo ou nada”. Os pacotes grandes forçaram a construção, testes e deploy, mesmo em uma pequena mudança. Os CRUDs, as transações mais críticas e os relatórios ficaram todos no mesmo implantável e na mesma infraestrutura;
  • A escalabilidade também foi “tudo ou nada”. Não dava para escalar apenas parte da aplicação. Até dava mas nem foi cogitado isso;
  • O Onboarding de novos desenvolvedores foi difícil. Os novos integrantes do time tiveram de baixar todo o código e aprender a lidar com a aplicação inteira.
  • O gerenciamento de dependências de código ficou complexo.
  • O projeto ficou preso a uma única opção de tecnologia.

Para atacar estes problemas os caras pensaram em modularização e particionamento da aplicação em pequenas partes que chamaram de micro-serviços. Cada micro-serviço funciona como uma aplicação independente, implantável separadamente, com interface de serviço baseada em REST agnóstica em relação à tecnologia. Isso possibilita uma liberdade de escolha de tecnologia de implementação. Com essa liberdade você pode implantar serviços em plataformas diferentes e escalar de forma independente também.

Mas não existe almoço grátis… atenção ao desempenho. Você vai ter de monitorar o tempo de resposta e o uso de recursos e é importante ficar atento desde o início. Serviços distribuídos tendem a ter problemas em função da latência, por exemplo. Atenção ao design dos serviços. Evite as dependências entre serviços e a necessidade de orquestração para conseguir que o deploy fique realmente independente, senão vai acabar tendo deploy “tudo-ou-nada” do mesmo jeito. 🙂

Mas voltando aos benefícios… outra liberdade que você tem com esse modelo é “rampar” times diferentes para cada serviço. Isso te dá a possibilidade de paralelizar ou adiar a entrada de um novo time de acordo com o melhor momento para investimento. Lembrando que a métrica do time de “2 pizzas” vale aqui e também a abordagem DevOps onde o time que desenvolve também é responsável por manter e acompanhar o serviço em produção.

As vantagens dessa abordagem estão sendo experimentadas ainda, mas resultados positivos tem sido apresentados em conferências. Acho que você deveria considerar para tornar os times mais capazes de responder rapidamente às novas necessidades de negócio. A abordagem de desenvolvimento de aplicações monolíticas gera respostas mais lentas. Microservices promete entregas mais freqüentes e mais rápidas. Isso permite feedback mais rápido dos usuários e ajustes nos investimentos por parte do time de negócios.

Enterprise Agile

Enterprise Agile

Como ponto de partida o Scrum é um excelente método ágil. No Brasil ele abre as portas das empresas para a agilidade. Isso se dá pela sua grande difusão entre os profissionais de gerenciamento de projetos nas áreas de TI. Agora, quando as empresas começam a levar o agile para um patamar corporativo o Scrum sozinho se mostra insuficiente.

Na prática, para uma abordagem corporativa é necessário recorrer a outros métodos para preencher os gaps de processo que o Scrum não trata. É aí que surgem as dificuldades. Quando as empresas começam a olhar para outros métodos surge o conflito de terminologias e a sobreposição de conceitos. Isso gera uma certa confusão na hora de definir e instalar esse novo processo. Faltam elementos para integrar o agile com as estratégias de governança das empresas.

Nesse contexto surgiu o Disciplined Agile Delivery (DAD). O DAD é uma abordagem híbrida que faz a “costura” de diversos métodos no formato de um framework de decisão. Esse framework te ajuda a definir o processo mais adequado de acordo com o contexto e a cultura organizacional da sua empresa. Diferente do Scrum, o DAD considera que existe um ecossistema corporativo e ele não pode ser ignorado.

O DAD estende o Scrum com estratégias do Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), Kanban, Lean Software Development, SAFe entre outros. Ele aborda práticas técnicas como Continuous Delivery, TDD, arquitetura, modelagem e também documentação e governança, fornecendo alternativas que aumentam a chance de você adotar estratégias que funcionem no seu contexto. Se você tem interesse em DAD entre em contato comigo. Vamos bater um papo.

Para mais informações acompanhe o blog Disciplined Agile Delivery. Para saber mais sobre treinamentos e certificações acesse o site do Disciplined Agile Consortium

O seleto grupo de certificados TOGAF 9 no Brasil

O seleto grupo de certificados TOGAF 9 no Brasil

O The Open Group vem fazendo investimentos desde 2010 para a difusão do TOGAF no Brasil. Em 2013, por exemplo, por iniciativa do AEA Brazil Chapter, participei como voluntário do time de tradução do glossário do TOGAF 9 para o português brasileiro. Essa iniciativa possibilitou a oferta da certificação e outros materiais no nosso idioma.

Mesmo com esses investimentos o número de profissionais certificados em TOGAF ainda é baixo no Brasil. De acordo com o TOGAF Visual Map, até outubro de 2014 tinhamos apenas 184 do total de 36.435 certificados em todo o mundo.

Screen Shot 2015-07-07 at 09.44.14

Seguem alguns detalhes da certificação para os interessados em entrar para esse seleto grupo de profissionais brasileiros.

A visão da certificação TOGAF 9

Definir e promover um programa de capacitação dirigido pelo mercado  e um programa de certificação para TOGAF 9.

Os princípios da certificação TOGAF 9

  1. Abertura,  o programa é aberto para aplicação em todos os países;
  2. Equidade, a certificação é obtida por todos os candidatos da mesma maneira, apenas passando no exame;
  3. Relevância para o mercado, programa estruturado para atender as necessidades do mercado;
  4. Apoio ao aprendizado, os treinamentos são fornecidos por parceiros de acordo com as necessidades do mercado;
  5. Qualidade, os treinamentos fornecidos devem ser chancelados pelo The Open Group (uma lista é fornecida no site);
  6. Melhores práticas, programa desenhado seguindo as melhores práticas do mercado.

A importância da certificação TOGAF 9

A existência do programa de certificação é um incentivo forte para firmar TOGAF como um método padronizado e aberto para arquitetura empresarial (ou corporativa) evitando a proliferação de métodos proprietários dependentes de fornecedor. Este é um passo importante para tornar a arquitetura empresarial uma disciplina bem definida e reconhecida e introduzir um rigor na seleção de ferramentas e serviços.

Sobre os exames

São 13 os tópicos da certificação do primeiro exame – TOGAF 9 Foundation:

  1. Conceitos básicos (3 questões);
  2. Conceitos centrais (3 questões);
  3. Definições gerais (3 questões);
  4. Introdução ao ADM (Architecture Development Method) (4 questões);
  5. Enterprise Continuum e ferramentas (2 questões);
  6. Fases do ADM (Nível 1) (9 questões);
  7. Diretrizes e técnicas do ADM (6 questões);
  8. Governança da arquitetura (Nível 1) (4 questões);
  9. Visões Arquiteturais, pontos de vista e envolvidos (2 questões);
  10. Blocos de construção (Building blocks) (2 questões);
  11. Produtos de trabalho (deliverables) do ADM (2 questões);
  12. Modelos de referência do TOGAF (Nível 1) (2 questões);
  13. Programa de certificação TOGAF (2 questões).

Cada um destes tópicos são divididos em sub-tópicos específicos que o candidato deve dominar. O exame tem 40 questões de múltipla escolha. O tempo do exame é de 60 minutos. O candidato deve acertar 22 questões para passar, ou seja, 55% de aproveitamento.

O segundo exame TOGAF Certified tem 8 questões baseadas em cenários. Para passar o candidato tem de obter 60% de aproveitamento, ou seja, 24 dos 40 pontos distribuídos. O tempo do exame é de 90 minutos.

Os exames são em português? Onde fazer?

Como já citei antes, os exames estão disponíveis em português. Eles são aplicados nos centros Prometric. Acesse o site e verifique o melhor centro na sua região.

Mais informações no site:

https://togaf9-cert.opengroup.org/home-public

http://www.opengroup.org/certifications/exams

Bons estudos!

Estou ajudando a organizar um curso oficial de TOGAF, que cobre todo o conteúdo da certificação, em BH, numa parceria entre a comunidade PanGea e a Gnosis. Caso tenha interesse em participar entre em contato.  

15 conceitos básicos para entender o TOGAF 9

togaf-certified

É um método? é uma arquitetura? O que é TOGAF mesmo? Para responder essas dúvidas eu listo aqui 15 conceitos básicos que vão esclarecer o que é o TOGAF.

1. Empresa

Definição: Uma coleção de organizações que compartilham um conjunto de metas em comum.

Exemplos:

  • Órgãos do governo;
  • Partes de uma corporação;
  • Corporações.

Grandes corporações podem ser compostas de muitas empresas. Podem ser “empresas estendidas” incluindo parceiros, fornecedores e clientes.

2. Arquitetura

Definição: Uma Arquitetura é a organização fundamental de “alguma coisa”, em termos dos seus componentes, os relacionamentos entre eles, o ambiente onde estão inseridos e os princípios que governam seu projeto e evolução.

3. Modelo Operacional

Definição: Um Modelo Operacional é o nível desejado de integração e padronização de processos de negócio para entregar bons serviços aos clientes.

4. Arquitetura Empresarial

Se substituirmos  esta “alguma coisa” da definição de arquitetura por “Empresa” e juntarmos o conceito de Modelo Operacional temos a “Arquitetura Empresarial” (chamada também de “Arquitetura Corporativa”).

Definição: Uma Arquitetura Empresarial é a organização lógica dos processos de negócio e infra-estrutura de TI, refletindo a integração e padronização dos requisitos do modelo operacional da empresa.”

Mais informações em: O que é arquitetura empresarial?

5. Tipos de arquitetura

TOGAF  classifica a arquitetura empresarial nos seguintes tipos de arquitetura:

  • Arquitetura de Negócio: processos de negócio, organização, pessoas;
  • Arquitetura de Aplicações: serviços;
  • Arquitetura de Dados: dados, informação;
  • Arquitetura Tecnológica: hardware, software, rede.

6. Porque Arquitetura Empresarial?

O gerenciamento efetivo e exploração da informação através da TI é a chave do sucesso dos negócios.

Bom gerenciamento da informação = vantagem competitiva;

Os sistemas atuais de TI não correspondem às necessidades de negócio em relação ao gerenciamento da informação apresentando deficiências como fragmentação, duplicidade da informação, entendimento ruim e não responder a mudanças. Os investimentos em tecnologia da informação tem foco em manutenção de sistemas. A maioria do esforço é despendido em desenvolvimentos táticos e reativos ao invés de estar ancorados em um planejamento estratégico. Neste cenário as duas razões principais de porque você precisa de uma arquitetura corporativa:

  • É crítico para sobrevivência e sucesso dos negócios;
  • Permite gerenciar a inovação da empresa;

7. Pressão para desenvolver  arquitetura empresarial

  • As leis e regulamentações como Sarbanes-Oxley, Clinger-Cohen Act (US Information Technology Management Reform Act 1996), EU Directives on the Award of Public Contracts;
  • empresas mais estendidas;
  • operações de TI mais cooperativas;
  • publicidade relativa a falhas;
  • aumento de litígios;
  • requisitos de auditorias.

8. Benefícios da arquitetura empresarial para o negócio

  • Ajuda a organização a atingir as estratégias de negócio;
  • rapidez no “time to market” para novas inovações e capacidades de negócio;
  • processos de negócio mais consistentes e informações entre as unidades de negócio;
  • maior disponibilidade e segurança;
  • além de redução de riscos.

9. Benefícios da arquitetura empresarial para a TI

  • Melhor rastreabilidade dos custos com TI;
  • redução de custos com projetos, compras, operação, suporte e mudanças;
  • desenho e desenvolvimento mais rápido; menor complexidade;
  • menor risco de TI.

10. A importância da governança

  • Uma arquitetura corporativa é tão boa quanto o frameowork de tomada de decisão que ela estabelece em torno do framework de governaça.

O sucesso do Framework de Governança depende:

  • De uma estrutura de autoridade clara;
  • Dos participantes corretos.

11. O que é um framework de arquitetura?

  • Um framework de arquitetura é um toolkit que pode ser usado para desenvolver uma ampla gama de arquiteturas diferentes;
  • ele deve descrever um método para desenhar um sistema de informação em termos de um conjunto de blocos de construção e mostrar como estes blocos de construção trabalham em conjunto.
  • ele deve conter um conjunto de ferramentas e fornecer um vocabulário comum.
  • ele deve também incluir uma lista de recomendação de padrões e produtos compatíveis que podem ser usados para implementar os blocos de construção.

12. O valor de um framework

  • Fornece um ponto de partida prático para um projeto arquitetônico;
  • Evita o pânico inicial quando a escala das tarefas se torna aparente;
  • Pragmático – “senso comum codificado”;
  • Captura o que outros tem de fazer no mundo real;
  • Contém uma “Baseline” de um conjunto de recursos para reuso.

13. Método para desenvolvimento de Arquitetura Empresarial

Características do método:

  • Um método geral abrangente e compreensivo;
  • Complementar e não concorrente com outros frameworks;
  • Amplamente adotado no mercado;
  • Customizável para atender uma organização e as necessidades da indústria;
  • Disponível sob uma licença livre perpétua;
  • Padrão aberto e neutro em relação a ferramentas, fornecedores e tecnologias;
  • Evita re-inventar a roda;
  • Alinhamento entre negócios e TI;
  • Baseado em melhores práticas;
  • Possível participar na evolução do framework.

14. TOGAF 9

Origens

  • Uma iniciativa que partiu dos clientes
  • Um framework, não uma arquitetura
  • Um framework genérico para desenvolver arquiteturas para atender diferentes necessidades de negócio
  • Não é  “one-size-fits-all”

Escopo do TOGAF

  • Originalmente baseado no TAFIM (U.S. DoD)
  • TOGAF enfatiza metas de negócio como condutores arquiteturais e fornece um repositório de boas práticas incluindo:
    • TOGAF Architecture Development Method (ADM)
    • ADM Guidelines & Techniques
    • TOGAF Architecture Content Framework
    • Enterprise Continuum
    • TOGAF Reference Models
    • TOGAF Capability Framework

15. Certificação TOGAF 9

A certificação TOGAF possui dois níveis, cada um corresponde a um exame:

Nível da certificação Propósito
TOGAF 9 Foundation Para fornecer a validação de que a pessoa conhece os conceitos básicos da terminologia e compreende os princípios fundamentais da Arquitetura Empresarial e do TOGAF 9
TOGAF 9 Certified Para fornecer validação que, além de conhecimento e compreensão, o candidato é capaz de analisar e aplicar conhecimentos de TOGAF 9

Para acessar outros recursos sobre TOGAF acesse o site: http://www.togaf.info/

Estou ajudando a organizar um curso de TOGAF em BH numa parceria entre a comunidade PanGea e a Gnosis. Caso tenha interesse em participar entre em contato.  

2 Pizzas = 1 Team

2 pizzas

Regra de ouro para dimensionar times ágeis.

Regra das duas pizzas: O Time deve ter o número de pessoas que possa ser alimentado com duas pizzas.

Assim, o time deve ter 7 mais ou menos duas pessoas, ou seja, de 5 a 9 pessoas. A razão para essa regra é que times pequenos facilitam a comunicação entre os seus membros. Agora, se o time for incluir o João Vitor, então pode pedir uma pizza só pra ele. 🙂

Essa regra é atribuída a Jeff Bezos, fundador da Amazon.

Novo livro sobre DAD: Introduction to Disciplined Agile Delivery

Você está procurando um livro enxuto, de poucas páginas, de fácil leitura, que mostra como aplicar o DAD em situações típicas do dia-a-dia?  Achou! 🙂

Acaba de ser lançado o livro Introduction to Disciplined Agile Delivery

Esse livro de 102 páginas é para aqueles que querem conhecer a essência do DAD, o que ele é e o que não é  e quais os seus benefícios.

Sobre o DAD, ele é gratuito para uso e apesar de ter sido desenvolvido originalmente na IBM agora é mantido pelo Disciplined Agile Consortion.  No DAC você encontra todas as informações sobre o programa de certificação em DAD.

Boa leitura!

IntroDADCoverMedium

A Small Agile Team´s Journey from Scrum to Continous Delivery.
by Mark Lines and Scott Ambler

Microservices

Enquanto estou criando uma massa de dados resolvi escrever sobre Microservices. 

Mas por que Microservices?

Porque é o estilo arquitetural mais falado do mercado no momento e porque eu acho bem interessante. Se você perguntar para aquele seu colega early adopter ele vai dizer que já aplicou no último projeto e que já está dominando o Node.js.:)

Brincadeiras a parte, segue uma definição de elevador:

Microservices é um estilo arquitetural no qual um sistema complexo de software é formado por um ou mais serviços pequenos, chamados de micro serviços. Estes serviços tem foco restrito a uma capacidade de negócio, são fracamente acoplados e agnósticos em relação à linguagem de implementação. Cada serviço é uma aplicação que tem uma API REST bem definida. Os serviços se comunicam uns com os outros através de suas APIs. Eles são desenvolvidos e mantidos por pequenas equipes. Essas equipes geralmente aplicam práticas ágeis e ao contrário da prática normal, onde uma equipe desenvolve e outra equipe mantém a aplicação, é comum que a equipe que desenvolve também seja responsável pela operação. Nesse contexto as equipes aplicam Continuous Delivery e práticas de DevOps.

Então é isso. A massa de dados está quase pronta. Fui…