Ppas arquiteturaságeis-resumo

1.453 visualizações

Publicada em

Fragmento do workshop realizado no evento de Maré de Agilidade.

0 comentários
6 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.453
No SlideShare
0
A partir de incorporações
0
Número de incorporações
436
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
6
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Ppas arquiteturaságeis-resumo

  1. 1. Princípios e Práticas de Arquitetura Ágeis<br />Facilitador: Marco Aurélio S. Mendes<br />ApresentaçãoRealizada no EventoMaré de AgilidadeemMaio de 2010Belo Horizonte - 2010<br />
  2. 2. Sobre o instrutor:<br />ConsultordaARKHI Consultoria e Treinamento, escritório de ArquiteturaCorporativa.<br />Professor de Pós-Graduaçãoda PUC MINAS (Instituto de EducaçãoContinuada)<br />Maisinformações:<br />contato@arkhi.com.br<br />marco.mendes@arkhi.com.br<br />
  3. 3. ConceitosFundamentais da ArquiteturA DE SOFTWARE<br />O quefaz o arquiteto de software<br />Definição e importância da arquitetura de software<br />
  4. 4. Objetivos da unidade<br />Ao final desta unidade, os participantes devem ser capazes de:<br />Descrever as competências do arquiteto de software.<br />Definir o que é arquitetura de software.<br />Descrever a importância da arquitetura de software.<br />
  5. 5. Arquitetura – Importanteoumodismo?<br />Novo centroadministrativo do Governo de Minas Gerais<br />
  6. 6. Quem é o arquiteto de software?<br />Huumm... arquiteto de software é aquelequedesenha a arquitetura do software, certo?<br />Nãotão simples assim…<br />O arquiteto é responsáveltambémporváriasatividadesqueenvolvem a arquitetura de software além do desenho.<br />
  7. 7. O que é o arquiteto?<br />Grécia, 500 a.C.:<br />Arkhitekton: construtormestre<br />Arkhi: líder<br />Tekton:trabalhadorouconstrutor<br />Antes, o quesignifica ser “arquiteto”?<br />
  8. 8. O que é arquitetura?<br />Le Petit Larousse 2005:<br />Habilidade de conceber e de edificarconstruçõesdentro de restriçõesfuncionais, estéticas, técnicas e regulamentares.<br />Estrutura, organização.<br />E o que é arquitetura?<br />
  9. 9. Para quê um arquiteto?<br />Toda construção tem umaarquitetura.<br />Mesmoque simples e intuitiva!<br />Umaoca – residência de umafamíliaindígena<br />Construídaporalgunsíndios, emalgunsdias e com ferramentasrústicas.<br />
  10. 10. Para quê um arquiteto?<br />Toda construção tem umaarquitetura.<br />Arquiteturassofisticadasexigemprojetoscomplexos!<br />“Oca” do Ibirapuera<br />10000 m2<br />Construídaporcentenas de pessoas, porváriosmeses, com técnicas e ferramentasmodernas.<br />
  11. 11. “O arquiteto ideal deve ser umapessoa de letras, um matemático, familiar com estudoshistóricos, um diligenteestudante de filosofia, interessadoemmúsica, nãoignoranteemmedicina, proficienteemquestõesjurídicas, familiar com a astronomia e oscálculosastronômicos.” <br />– Vitruvius, 25 d.C., em “De Architectura”<br />O arquitetonaantiguidade<br />
  12. 12. Responsávelpor:<br />concepção da arquitetura<br />apoio à contrução<br />O quefaz o arquiteto<br />
  13. 13. O quefaz o arquiteto<br />Responsávelpor:<br />concepção da arquitetura<br />apoio à contrução<br />de software<br />do software<br />do software<br />
  14. 14. O quetipicamentefaz o arquiteto de software <br />Obtéminformação:<br />-requisitos<br />-estratégias<br />-tecnologias<br />Arquitetando:<br />-modelagem<br />-prototipação<br />-avaliação<br />-documentação<br />-etc<br />Forneceinformação:<br />-comunica a arquitetura<br />-assisteoutrosenvolvidos<br />
  15. 15. Desenvolvimentotípico do arquiteto de software<br />
  16. 16. GeneralistaouEspecialista?<br />Conhecimentoemextensão<br />Bancos de dados<br />Java EE<br />Técnicas de liderança<br />.NET<br />Processoss<br />Testes<br />Desenho<br />PLSQL<br />Padrões<br />Generalista<br />Generalista<br />Conhecimentoemprofundidade<br />
  17. 17. Conhecimentoesperado do arquiteto de software<br />
  18. 18. Habilidadesesperadas do arquiteto de software<br />O arquiteto deve possuir e desenvolver habilidades advogadas pelos métodos ágeis, tais como:<br />experiência;<br />liderança;<br />comunicação;<br />orientação a objetivos;<br />pró-atividade;<br />visão;<br />negociação;<br />Necessita abranger as capacidades de desenhista (ou projetista), mas:<br />tende a ser mais generalista que especialista;<br />deve tomar decisões técnicas mais abrangentes.<br />
  19. 19. Contra-exemplo de arquiteto<br />O arquitetodatorre de marfim!<br />
  20. 20. Time de arquitetura<br />
  21. 21. Influênciassobre a arquitetura de software<br />
  22. 22. O que é arquitetura de software?<br />
  23. 23. O que é arquitetura de software?<br />
  24. 24. Uma definição para lembrar!<br />“Arquitetura de software é o conjunto de decisõesque, se feitasincorretamente, podemcausar o cancelamento do projeto.”  – Eoin Woods<br />
  25. 25. O quearquitetura de software não é…<br />Umalista de tecnologias.<br />Um diagrama.<br />Um documento.<br />Trabalho de um únicoarquiteto.<br />Umaciência.<br />Uma arte mística.<br />
  26. 26. Dinâmica<br />Vocêpega o elevador no últimoandar e encontra o oseudiretor, queacabou de descobriuquevocê é um arquiteto de software.<br />Ele, curioso com o nome, faz a pergunta – “O quevocêfaz, exatamente? “<br />O elevadorcomeça a descer e você tem exatamente45 segundosparadescrever o quevocêfazpara o seudiretor!<br />
  27. 27. A arquitetura de software envolve…<br />Alinhamento do software com a estratégiaorganizacional.<br />Balanceamento de influênciasdiversas.<br />Orquestração com outrosprocessos.<br />Modelagem e consistência entre visualizações do modeloarquitetural.<br />Análise de riscostécnicos.<br />Decisões, muitasdecisões…<br />
  28. 28. Produtos da arquitetura de software<br />
  29. 29. A fronteiradaarquitetura com o desenhotécnico<br />A arquitetura de software estabelece o contexto para o desenho detalhado e implementação.<br />“As decisõesarquiteturaissão as maisfundamentais; modificá-lascausa um efeitoemcascata.” – Grady Booch<br />
  30. 30. Importância da arquitetura de software<br />A arquitetura ajuda a gerenciar a complexidade técnica.<br />A arquitetura de software fornece a visão geral para garantir que se está no caminho certo.<br />Habilita a comunicação entre os stakeholders sobre como o software vai ser construído.<br />Logo no início do ciclo de vida, ressalta decisões que têm profundo impacto em todo trabalho.<br />Lembre-se: construçõescomplexasexigemmodelos e planoselaborados.<br />
  31. 31. Papopara o café com o chefe<br />Arquiteturareduzriscos – masnão remove todas as incertezas.<br />Arquitetarsignificaelaborar com eficiência e eficácia.<br />Arquiteturaenvolvehabilidadespsicossociais.<br />Arquiteto é o estrategistatécnico.<br />
  32. 32. Tradeoffs<br />Todo o trabalho do arquiteto de software envolvebalanceamento entre tradeoffs e escolhas<br />“A vida de um arquiteto de software é umalonga e rápidasucessão de decisões sub-ótimas e parcialmentetomadas no escuro.” - Philippe Kruchten<br />Tradeoffs, tradeoffs, tradeoffs…<br />
  33. 33. Conclusões da unidade<br />A importância da arquitetura cresce conforme a complexidade do projeto.<br />O arquiteto de software é papel essencial em projetos de desenvolvimento de software.<br />A profissão da arquiteto de software exige constante atualização de conhecimento assim como habilidades psicossociais.<br />
  34. 34. Arquiteturaságeis<br />O quesãoarquiteturaságeis<br />Práticasfundamentais de arquiteturaságeis<br />
  35. 35. Objetivos da unidade<br />Ao final desta unidade, os participantes devem ser capazes de:<br />Descrever o que são arquiteturas ágeis<br />Descrever práticas fundamentais de arquiteturas ágeis.<br />
  36. 36. O quesignifica ser ágil?<br />Indíviduos e interaçõessobreprocessos e ferramentas<br />Software funcionalsobredocumentaçãocompleta<br />Colaboração com o clientesobrenegociação de contratos<br />Responder a mudançassobreseguir um plano<br />Isto é, enquantonósvalorizamososvalores à direita, nósvalorizamosaindamaisosvalores à esquerda.<br />
  37. 37. A realidade de umafatia do mercado<br />Os caóticos (conserta e remenda) nãoendereçamarquiteturas no projeto. Elesadiam as preocupaçõesarquiteturaisatéque o sistemacolapse.<br />
  38. 38. A realidade de umafatia do mercado. Os puxadinhos de software!<br />
  39. 39. Consenso<br />Arquitetos e agilistasconcordamque a estrutura de um sistemaé umapreocupaçãoimportante e real<br />
  40. 40. O debate<br />Arquitetos e agilistaseventualmentediscordamsobre a maleabilidadedestaestrutura e emqueextensãoeladeveria ser pré-definidaaolongo de um projeto.<br />
  41. 41. O contexto do projeto é chaveparadefinir a maleabilidadedaestrutura<br />
  42. 42. Como definir a maleabilidade<br />A maleabilidade é definidapelo volume de atributos de qualidade (requisitosnão-funcionais) quesãotratados a priori no projeto.<br />Exemplos de atributos de qualidadeincluem o desempenho, usabilidade, inter-operabilidade, segurançaouportabilidade.<br />
  43. 43. Maleabilidade e definiçãopréviadaestrutura. Quantomais à direita, maisestrutura é definida a priori.<br />
  44. 44. Métodoságeis e a definiçãodaestruturaarquitetural<br />Nosmétodoságeis, a arquitetura é definidaaolongo do projeto, a medidaqueosrequisitosfuncionais de maior valor sãoacomodados.<br />
  45. 45. Como arquitetar de forma ágil?<br />O planejamento de iteraçõesé chave. <br />Cadaiteração (ou sprint) endereça um oumaiscenáriosarquiteturaisestritamentenecessáriospara a entrega do produtodaquelaiteração.<br />A medidaque o novoselementosarquiteturaissejamendereçados, códigojáconstruídoprecisa ser refatoradoparaacomodar as mudanças.<br />
  46. 46. A acomodação arquitetural iterativa pode introduzir riscos no projeto.<br />
  47. 47. A metáfora do cheque especial<br /> Ao entregarmos um produto com uma arquitetura sub-ótima estamos usando um cheque especial técnico.<br />
  48. 48. Arquiteturas sub-ótimas<br />Umaarquiteturaquenãorespondeàspreocupaçõesarquitetônicasrelevantespara o projeto.<br />ex: não performática ou com uma usabilidade deficitária, caso estes sejam condutores importantes,<br />
  49. 49. Como usar o cheque especial técnico<br />O quão provável que a futura funcionalidade seja realmente necessária no produto? <br />Existe um investimento arquitetural que eu possa fazer agora que irá reduzir o custo futuro de implementar esta funcionalidade?Qual o custo do investimento arquitetural? (ex: custo da oportunidade, custo de implementação)<br />Qual a consequência econômica de no futuro precisar implementar a funcionalidade sem o investimento arquitetural realizado a priori?<br />É importante lembrar, conforme pesquisas diversas (ex: Standish Group), que quase metade das funcionalidades solicitadas de um produto são raramente ou nunca usadas.<br />
  50. 50. E comoeupago o cheque especial?<br />Com refatoraçãoarquitetural.<br />A refatoraçãoarquiteturalacomodaelementosarquiteturaisem um sistemajáexistente.<br />
  51. 51. RefatoraçãoArquitetural - Exemplo<br />Vocêimplantou um sistema Web emproduçãoque opera sobre o Internet Explorer.<br />Após um mês, vocêdevetorná-lo portávelparaoperarsobre o Firefox 3.5 e melhorar odesempenho de páginasquedemoram 20 segundospara 8 segundos.<br />O custodarefatoraçãopode ser alto. Istosãoosjuros do cheque especial técnico.<br />
  52. 52. E se eunãopagar o cheque especial técnico. O queacontece?<br />O bancoarquiteturalpodecobrarjurosaltíssimos!<br />O seusistemapodeliteralmenteimplodir. <br />
  53. 53. Como avaliarpragmaticamente o uso do cheque especial?<br />DescubraosDINOS do seuprojeto!!!<br />
  54. 54. Riscos arquiteturais mais críticos devem ser elicitados e publicados em murais ou kanbans.<br />Os riscosmaiscríticospodemindicarelementosestruturais a seremacomodadosnasprimeirasiterações (sprints).<br />Riscosmaiscríticosindicamque um atributonãodeveusar o cheque especial<br />Top TenRisks<br />
  55. 55. Iteração 3<br />Iteração 2<br />Iteração 1<br />Acomodação de riscosemarquiteturaságeis<br />Riscos<br />Estórias<br />Riscos<br />Estórias<br />Estórias<br />Estórias<br />Riscos<br />Estórias<br />Estórias<br />Estórias<br />Estórias<br />Estórias<br />Riscos<br />Estórias<br />Riscos<br />Estórias<br />Riscos<br />Estórias<br />Atributos de Qualidade<br />Atributos de Qualidade<br />Atributos de Qualidade<br />
  56. 56. Um plano de mitigação define ações 5W2H para reduzir a probabilidade e impacto deste risco.<br />5W2H = O quê, quem, quando, onde, por quê, como, quanto custa.<br />Uma arquitetura pode ser acomodada com um plano de mitigação dos riscos críticos<br />Exemplo: Risco – Desconhecimento de JMS pelo time.<br />Ação: Um estudo preliminar do JMS será realizado pelo João Silva na semana que vem nas dependências da empresa para conhecer o modelo de programação assíncrono de filas através da exploração de exemplos no Eclipse e tutoriais do Java EE, com um custo estimado em 1000 reais (40 horas) de P&D.<br />
  57. 57. E se eunãogostar de planos, mesmoqueágeis?!!!<br />
  58. 58. A ausência de planospodeproduzir “arquiteturas” disformes<br />
  59. 59. Consideração Final<br />Entender as dependências entre as estórias e a arquiteturaé críticoparaqueumaarquiteturaágilescale.<br />
  60. 60. Conclusões da unidade<br />Arquiteturaságeismesclamosbenefíciosdaagilidade com a mitigação de riscos e benefíciosestratégicosdaarquitetura.<br />Planejamento de liberaçõesdevemesclarobjetivos, riscos e endereçaratributos de qualidade.<br />Metáfora do cheque especial deveservir de guiaparafacilitar o processodecisório do adiamento de atributos de qualidade.<br />
  61. 61. Para saber mais<br />Who Needs an Architect? - Martin Fowler<br />Common Misconceptions about Software Architecture - Philippe Kruchten<br />What is a software architecture? - Peter Eeles<br />Characteristics of a software architect - Peter Eeles<br />The process of software architecting - Peter Eeles<br />The benefits of software architecting - Peter Eeles<br />What are the Duties, Skills, etc. of a Chief Software Architect? - SEI<br />The Past, Present, and Future of Software Architecture - Philippe Kruchten e outros<br />What do software architects do? - Philippe Kruchten<br />System Architecting - GerritMuller<br />
  62. 62. Tao do Arquiteto de Software<br />O arquitetoobserva o mundo.<br />Masconfiaemsuavisão interior.<br />Elepermiteque as coisasvenham e vão.<br />Seucoração é abertocomo o céu.<br />Quando o arquitetolidera, o time <br />dificilmentepercebequeeleexiste. <br />O segundomelhor é o arquitetoque é amado.<br />Depois, o que é temido.<br />O pior deles é aqueledesprezado.<br />O arquiteto não fala, age.<br />Quando o trabalho está pronto, <br />o time diz: <br />“Incrível: nós fizemos tudo sozinhos!"<br />The Tao of the Software Architect<br />Lao-Tsu, revisitadopor<br />Philippe Kruchten<br />

×