Débito Técnico

Na minha coluna MundoOO da revista MundoJava, publiquei um artigo que dismistifica muito sobre User Stories e responde a algumas perguntas comuns sobre o assunto que observei no mercado em muitas equipes: Como escrever? Quem faz o que? Pra que usar cartões? Aonde está a especificação? e etc…

Essas dúvidas geralmente surgem no nosso Workshop Scrum, onde temos uma atividade prática muito legal sobre captura de User Stories dentro de uma concepção ágil (veja cases do blog).

Este artigo é parte de uma série sobre Agilidade que estou mantendo na coluna. Ultimamente escreví sobre modelagem ágil, TDD, requisitos/especificações executáveis e etc…

Segue o trechinho grátis:

É fato que a maior parte do mercado brasileiro hoje usa contratos de escopo fechado, principalmente nos grandes projetos (governo, bancos, Telecom, indústrias e etc…). O contrato de escopo fechado promete “previsibilidade” no desenvolvimento de software, porém, esta forma de contratação parte de duas premissas muito duvidosas: 1 – o cliente sabe exatamente o que quer; e 2 – a equipe sabe estimar exatamente o esforço de construção.

Se você já trabalhou em dois ou três projetos de software você sabe perfeitamente que essas premissas são folclore. Nem o cliente sabe exatamente o que quer e nós sempre temos um grau de confiança inaceitável nas nossas estimativas de longo prazo. Essa é a maior razão para o seu gerente colocar 50%, 100% e até 150% de “gordura” ou “pulmão” no valor da proposta para o cliente. E esse é o resultado: tentar forçar a “previsibilidade” num contrato de escopo fechado gera projetos mais caros e clientes muito insatisfeitos. Na maioria das vezes isso acontece porque o cliente se envolve timidamente no projeto, tomam suas especificações funcionais como verdade absoluta e dizem: “- Eu quero tudo!!!”, não se importando se a solução vai resolver os problemas ou não.

Na verdade, um projeto de software tem uma peculiar característica de “constante investigação”. Ken Schwaber chama isso de “inspeção e adaptação”. Em termos mais práticos, o dia-a-dia de uma equipe de desenvolvimento de software é “checar se estamos no caminho certo e ajustar o rumo sempre que necessário”. Desenvolvimento de software é um processo criativo de pesquisa, então, especificações pactuais gordas que apodrecem no nosso controle de versão nos ajudam muito pouco para o sucesso do projeto. Em projetos de software bem sucedidos é comum o produto final ser bem diferente da idéia concebida inicialmente. Durante o desenvolvimento do projeto, uma sugestão de solução nos leva a novos problemas ocultos que não podem ser ignorados e a outras possibilidades de solução ou “atalhos” que devemos aproveitar. Dentro do desenvolvimento iterativo esses problemas e atalhos se tornam muito claros.

Quer ler mais? Já nas bancas…

Na edição 29 da revista MundoJava escreví sobre o dia a dia de um agilista. Continuando uma série sobre TDD na Revista MundoJava nesta edição escreví um artigo sobre a ferramenta FIT para automação de testes. O artigo teve participação de Ivan Sanchez e James Shore.

O Ivan Sanchez foi o cara que fez o treinamento CSM junto comigo no início de 2007, e teve o azar de cair no mesmo grupo comigo! O Ivan é um agilista e grande evangelista de Coding Dojos. Atualmente trabalha na Signature Technologies no Reino Unido.

James Shore (Jim) é lider do projeto FIT (criado por Ward Cunningham), atua em projetos ágeis desde 1999 (sim, existem projetos ágeis antes do Manifesto Ágil) e escreveu o livro “The Art of Agile Development“.

Uma das coisas legais de escrever na MundoJava é ter contato com esses caras lá de fora e poder trazer estes conteúdos para nossa comunidade. Escrever com o Scott Ambler e o Jon Kern foi muito legal. Este artigo com o James Shore também foi especial. Infelizmente eu recebo mais não do que sim, mas ainda vou continuar insistindo com os mestres! Ah… vocês querem o trecho grátis do artigo, certo? Então aí vai:

Uma das questões comuns é: Quem escreve os dados de teste? Pela estratégia do FIT, os dados de teste são escritos a “oito mãos”. É comum que tudo inicie com o usuário ou cliente e com o analista de negócios, capturando cenários de teste iniciais que formatam alguns critérios de aceitação. Depois disso, um desenvolvedor pode verificar a formatação das tabelas, referenciar as Fixtures e assim obter o RED do ciclo TDD. Ao mesmo tempo os testers podem participar colocando mais cenários. Logicamente, o FIT é uma ferramenta ágil. É importante uma rica colaboração face a face de todos os envolvidos para que exista sucesso na adoção dessa abordagem.

Uma atenção especial deve ser dada ao trabalho do analista de negócios. Atualmente é comum que esses profissionais capturem requisitos em documentos texto e alguns diagramas. Geralmente este tipo de abordagem é muito pobre para o desenvolvedor, principalmente se não existe uma comunicação rica entre eles. Comunicação com documentos é uma forma muito pobre de comunicação (veja artigo “Modelagem Ágil”, MJ 27). Um modelo de requisitos em texto é muito deficiente na maioria das vezes. Pare para pensar: Não existe teste sobre documentos em texto e nem compilador para diagramas!
Rodrigo Yoshima

O que é o FIT e porque se importar com ele? O FIT é parte do seu arsenal ágil de prevenção de bugs. Diferente da abordagem tradicional para a qualidade, onde focamos em encontrar e remover defeitos, as práticas ágeis focam-se primeiramente em previnir que bugs sejam criados. Isso nos leva a alguns resultados impressionantes. Times ágeis experientes produzem poucos bugs por mês.

As “práticas ágeis de engenharia” pregadas pelo Extreme Programming (XP) são parte da solução. Essas técnicas como Test-Driven Development (TDD), programação aos pares, propriedade coletiva do código, design simples e trabalho energizado previne a maioria dos erros de programação. Elas garantem que o código faz exatamente o que os programadores pretendiam que ele fizesse.
James Shore

FIT ou Framework for Integration Testing é uma ferramenta excepcional no auxílio ao desenvolvimento de um software. O cliente (ou analista de negócio) escreve tabelas mostrando o que o sistema deve fazer através de exemplos. O desenvolvedor escreve o código das fixtures, que são as classes que ligam as tabelas com o sistema que está sendo implementado. A partir daí as tabelas se tornam “executáveis” e as regras definidas podem ser validadas de maneira automatizada.

FitNesse é a implementação mais popular de FIT, que funciona na forma de um wiki. Cada página representa um teste executável e é possível executar múltiplas páginas para validar um sistema como um todo. Além disso, por se tratar de um wiki, favorece a colaboração entre cliente e desenvolvedores, podendo servir como uma ótima base de conhecimento sobre o sistema que está sendo construído.
Ivan Sanchez

O FIT é uma ferramenta muito interessante: Uma coisa que chama a atenção em projetos onde utilizamos o FIT é que produzir as tabelas com os dados de teste é uma atividade de modelagem intensa. Modelar não é fazer diagramas, é muito mais profundo do que isso!

Já nas bancas!

Na edição atual da MundoJava (número 30) não teve artigo meu. Pedi “férias” exatamente para organizar este blog e colocar algumas outras coisas em ordem. Mesmo sem artigo tivemos na Aspercom a missão de fazer um poster com práticas ágeis para o pessoal da revista.

Nunca tinha feito um poster desses na vida, mas sabia que era um trabalho criativo, artístico… não muito diferente de modelar software e escrever linhas de código. Porém, além do poster passar informações importantes ele deveria ser bonito!

Antes de começar qualquer coisa, precisaríamos definir o que colocar no poster. O poster tem limitação de espaço e gostaríamos colocar as práticas mais importantes e não todas elas! Para fazer isso, definimos alguns post-its com o conteúdo. Decidimos colocar basicamente as práticas do Scrum.

Tinha visto algumas apresentações em eventos mostrando que o processo ágil é cíclico e não linear, assim como o famoso poster da VersionOne. O processo cíclico é uma das características mais importantes de qualquer processo ágil e não podia ficar de fora!

Estou viciado em modelagem ágil para fazer muitos tipos de trabalho. Fui influenciado pelos conceitos do Design Thinking para elaborar este poster: “Pense no processo como um conjunto de espaços e não uma sequência de passos predeterminados”. Tentamos vários “modelos” e usar post-its para testar o conteúdo na disposição do poster foi determinante. Após várias “versões” para escolher e vários rascunhos em papel A4, decidimos o melhor.

Eu e a Patricia (minha esposa, sócia da Aspercom e responsável pela parte de mídia) sentamos num único micro com o CorewDraw para passar aquilo para meio eletrônico em pair programming (neste caso, pair drawing), aonde também decidimos a imagem do fundo. Depois, foi só juntar tudo, descobrir como fazer algumas coisas no Corel, adaptar algumas idéias que não deram certo e testar o desenho o tempo todo. O resultado final foi muito bom.

Um pouco atrasado mas vamos lá. Na edição “atual” da MundoJava (maio-junho) escreví sobre o ciclo ágil de um dia envolvendo as práticas do XP e da TDD. Parte deste artigo já está publicado aqui no blog no post “O Anti-Pattern Caso de Uso – UML – Codificação – Teste”.

Neste artigo tivemos a participação do Carlos Vilella da ThoughtWorks. Segue um trecho muito interessante do texto dele.

“Tive a sorte de participar em um projeto aqui na ThoughtWorks onde todas as estórias eram analisadas por um analista de negócios extremamente competente, e um cliente que entendia mais do que eu poderia esperar sobre a operação e funcionamento da empresa. Em conjunto com os desenvolvedores e testadores, ditou-se no início do projeto que usaríamos testes de aceitação “executáveis” de forma a aumentar a produtividade. Fizemos isso juntando Fit, Fitnesse e Selenium, que ainda não são ferramentas perfeitas, mas que estão evoluindo bem.

Funciona assim: Matt, o analista de negócios, se reúne com Jane, representando o cliente, em uma sessão de uma ou duas horas por semana. Eles então descobrem tudo o que é importante ser feito na próxima iteração, e listam tudo que eles conseguem imaginar para cada estória ser considerada pronta.
Depois que essa reunião termina, Matt corre pra mesa do Richard, analista de testes, e eles passam algumas horas formatando tudo dentro do wiki do projeto. É aí que está a grande sacada: o wiki do projeto, rodando no Fitnesse, sabe entender os critérios de aceitação e rodá-los, efetivamente tornando-os casos de teste do mais alto nível possível.

Com estes casos de teste na mão, Richard corre pra minha mesa, me mostrando que nessa próxima estória em que eu vou trabalhar, existe uma validação de números de cartões de crédito da qual nunca havíamos precisado antes. Com essa informação em mãos, eu sei que preciso adicionar um pouquinho de código aos fixtures do Fit para que ele entenda como acessar a aplicação usando Selenium e manipular a parte que lida com os números de cartão de crédito. De dentro da minha IDE, eu não vejo muita diferença: é só código que lê um número e tenta entrá-lo numa caixa de texto. Para o cliente, é uma oportunidade de finalmente ver que o que ele ajudou a digitar num wiki está se tornando realidade, e é por isso que ele está investindo no software.”

Já nas bancas!!!!

Na edição 19 da Revista MundoJava em meados de 2006 iniciei a publicação dos meus trabalhos na coluna MundoOO. Este primeiro artigo publicado teve um impacto extremamente positivo e até hoje muitas pessoas comentam sobre esta publicação.

Eu já ministrava treinamentos UML há algum tempo e participava de muitos fóruns de discussão como o UML-BR e o GUJ. O mercado tem um entendimento muito ruim sobre UML e modelagem em geral, assim, o que eu já pregava nos cursos transformei em literatura.

O artigo “UML não é Documentação” demostra o uso da UML de maneira prática e concisa, bem próximo da visão de modelagem ágil de autores como Scott Ambler e Martin Fowler.

Numa iniciativa conjunta do Blog Débito Técnico e o pessoal da MundoJava, estamos deixando este artigo disponível para download no site da Aspercom na página do projeto HotMotors. Este projeto com fins acadêmicos que anda parado (e com uma arquitetura que apesar de popular em 2006 não me dá muito orgulho) ainda será reativado um dia. Minha idéia é portar isso para Seam e também Rails. Seria um ótimo comparativo! Alguém da comunidade se habilita?

Durante um único dia de trabalho de uma equipe ágil temos alguns instantes que fazemos a reunião em pé do XP ou o encontro diário do Scrum. Esta mini-reunião é um ponto de sincronização do status do projeto (é uma inspeção no ciclo da iteração). O Scrum sugere que essa reunião tome o tempo máximo de 15 minutos. Dentro de um dia de trabalho de uma equipe ágil, fora desses poucos minutos preocupados com o gerenciamento a equipe trabalha no sentido de fazer incrementos de software funcionar de maneira “atômica”, isto é, um pequeno requisito é capturado e rapidamente transformado em software funcionando. Isso é o ciclo ágil de um dia. Assunto que tratarei na próxima edição da MundoJava.

Uma caracterísca marcante do ciclo ágil de um dia é que ele é não precisa ser gerenciado no nível macro, isto é, ele não pode ser tomado como base para o andamento do projeto como um todo. Somente com software funcionando e usuários felizes é que você pode dizer que o projeto andou. Este ciclo ocorre de maneira muito rápida e quem gerencia é o próprio desenvolvedor. Essa responsabilidade é uma cultura auto-organizável que faz parte do cerne do gerenciamento ágil. Gerentes de Projeto e Coordenadores não devem interferir no trabalho que é responsabilidade técnica dos desenvolvedores.

Os pontos que defendo aqui são práticas ágeis essencialmente constantes na metodologia XP e no TDD. Infelizmente essas práticas não são adotadas na maioria das equipes que tive contato. Um padrão muito comum nas equipes são práticas fantasiadas de Unified Process (ou RUP) que seguem um formato “Casos de Uso - UML - Codificação - Teste”, seguindo basicamente um processo em cascata numa escala menor. Este modelo dá a entender que requisitos estão em Casos de Uso (geralmente em documentos Word), o projeto ou arquitetura está no modelo UML (uma abstração intermediária), o código simplemente é algo que o computador compreende e, ao final, testes baseados no Caso de Uso são aplicados.

Primeiramente, gostaria de deixar claro que esta pode ser uma maneira de você implementar uma funcionalidade específica de um usuário com certo sucesso, porém, esse tipo de desenvolvimento não deve ser sequêncial e nem mesmo ser um padrão para todas as funcionalidades e nem para todos os projetos. Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados. Porém, existem outras maneiras de você alcançar este mesmo objetivo! O próprio RUP não prega este tipo de prática.

Este anti-pattern causa uma cegueira técnica. O fato de sempre ter Casos de Uso, UML, Código e Testes em cascata leva a equipe a acreditar que todos os requisitos estão em casos de uso, temos que modelar tudo e codificar é uma atividade pouco criativa, assim como os testes. Porém, se verificarmos que estatisticamente somente um terço dos requisitos estão em casos de uso [Cockburn], que modelamos somente o que precisa ser modelado [Yoshima] e que todo o processo de desenvolvimento de software é uma atividade criativa (inclusive os testes [Fowler]), vemos que este padrão é muito questionável e muito dispendioso.

Você pode utilizar Casos de Uso para capturar requisitos e utilizar UML para analisar um problema. A culpa não é dessas ferramentas! O maior problema desse padrão é não conversar mais com os usuários depois que o Caso de Uso está escrito, roubando sorrateiramente a comunicação entre a equipe técnica e o cliente durante o desenvolvimento. Refinamentos surgem o tempo todo! A equipe precisa durante o desenvolvimento ligar para o cliente e tirar dúvidas! É comum que durante a codificação novos requisitos não capturados emergam. Requisitos capturados, modelados, codificados e testados podem não ser o que o usuário queria de fato, pois artefatos como Casos de Uso e modelos UML são propensos a muitas imperfeições (são abstrações e não são naturalmente executáveis).

Vejo que o padrão “Caso de Uso - UML - Codificação - Teste” é uma má influência do processo Waterfall, que declaradamente é uma péssima prática para desenvolvimento de software. Esse pensamento seqüencial é ainda mais danoso quando tentamos encaixar este padrão dentro da divisão e especialização de trabalho do Taylorismo, comum em fábricas de software. Nesse cenário, um analista de negócios escreve Casos de Uso, um analista de sistemas desenha o modelo, um programador codifica e um testador testa. Essa equipe muitas vezes utiliza artefatos para se comunicar (e logicamente, cada passo geralmente é controlado por um Gantt Chart). Antes de prosseguir, veja a citação de Kent Beck a respeito do Taylorismo:

“Especialização e rigorosamente dividir e conquistar serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido.” Kent Beck

A base da divisão do trabalho é que é possível quebrar um determinado processo em partes menores gerenciáveis, e se cada parte for otimizada, o processo como um todo é otimizado. A especialização diz que determinado recurso efetuando uma tarefa várias vezes torna-se ótimo para esta tarefa. A questão é que para desenvolvimento de software, nem sempre a soma “Casos de Uso + UML + Código + Testes” geram algo do agrado do usuário se ele não estiver envolvido em todo o ciclo. Isso nos mostra que esses passos não são mensuráveis. Além disso, um analista de negócio não se tornará um analista de negócio melhor se ele escrever muitos Casos de Uso, assim como acontece com um Analista de Sistemas ou Programador.

Desenvolvimento de software não é um processo mecânico. Todas as metodologias atuais pregam um trabalho coletivo, em constante comunicação, entrosamento e principalmente uma visão holística sobre o projeto (o todo, e não as partes). Se apegar a rígidos papéis e responsabilidades é péssimo sob qualquer aspecto para uma equipe que desenvolve software.

Na coluna MundoOO da Revista Mundo Java deste mês (número 27) publiquei o artigo “Modelagem Ágil”, onde abordo técnicas efetivas e sem frescuras de modelar um software. Alguns tópicos abordados:

1. As três qualidades do software (qualidade interna, qualidade externa, qualidade do projeto)
2. No desenvolvimento de software não existe separação entre design e construção
3. A comunicação rica do “papel sobre a mesa”
4. Rascunhos, uma forma de modelagem eficaz
5. Aprofundar em detalhes antecipadamente é ruim!
6. Não volte para casa para escrever documentos de requisitos
7. Software funcionando é o melhor artefato para levantamento de requisitos
8. Conceitos sempre provados com código

Separei um trecho para vocês:

“Mas mais importante de tudo é focar nas atividades do desenvolvimento e não nos artefatos criados. Quando você está levantando requisitos, a atividade de conversar com o usuário, obter informações e enriquecer o conhecimento é mais importante que os casos de uso, protótipos, modelos que surgirem dessa atividade. O mesmo vale para uma modelagem de design. O importante é a criatividade para solucionar as dependências dos objetos, a separação dos conceitos, as mensagens trocadas. O modelo de design é só uma manifestação dessas decisões. A tomada dessas decisões é mais importante que a manifestação dessas decisões.”

O que foi mais legal neste artigo foi a participação do Juan Bernabó e José Paulo Papo, demonstrando como eles utilizam as técnicas de Agile Modeling no dia a dia deles.

No meu artigo “Entregue Software Funcionando! Gerenciamento de Projetos Ágil” (MundoJava #26) publiquei um manifesto contra o uso de Gantt Charts para projetos de software (ou qualquer outra atividade criativa e empírica). Segue o trecho!

Quase todas as organizações que tive contato tentam, e falham miseravelmente, aplicar Gantt Charts para controlar e reportar status do projeto. Vamos estudar um exemplo:

Clique para ver imagem completa…

PROBLEMA 1 – O processo é cíclico: É muito comum ver Gantt Charts de projetos de software com essa disposição, porém, uma das maiores razões do acompanhamento do projeto falhar com Gantt Charts é que o processo de desenvolvimento de software é cíclico e não linear da maneira Requisitos-Análise-Codificação-Teste. Além disso, os produtos dessas disciplinas são abstrações, assim, não podemos tomar um documento de requisitos e tratá-lo como “pronto” de maneira determinista.

O desenvolvimento de uma funcionalidade de software passa por VÁRIOS ciclos de Requisitos-Análise-Codificação-Teste. Essa é uma das razões que Gantt Charts sempre estão atrasados. Muitas vezes não é previsto pelo cronograma que durante os testes o processo pode voltar várias vezes para a codificação, para análise ou até para requisitos. Como esse tempo não está previsto, naturalmente o cronograma se torna impossível de se cumprir.

PROBLEMA 2 - Síndrome do Estudante: Um dos problemas comuns do foco em tarefas é um fenômeno chamado “Síndrome do Estudante” defendido por Eliyahu Goldratt na Teoria da Corrente Crítica. Esse fenômeno é simples de observar nos projetos. Alguma vez você viu um projeto de software controlado por Gantt Charts ser entregue antes do prazo? Creio que isso deve ser extremamente raro! Essa falha acontece porque um Gantt Chart funciona melhor para projetos com controle definido e não empírico. A Síndrome do Estudante é também chamada de Procrastinação. Procrastinar é adiar continuamente o início das tarefas simplesmente pelo fato do cronograma lhe dar “um prazo confortável”.

No cronograma acima podemos ver que foi dado 32 horas para o Júlio fazer a análise. Mesmo que ele consiga fazer esse trabalho em 8 horas, a tendência é que ele só diga que terminou após as 32 horas, ou talvez ele inicie a tarefa somente quando estiver lá pelas 24 horas do prazo. A síndrome do estudante é provada pelo fato que as pessoas realmente sabem o último minuto possível que elas têm para iniciar uma tarefa. Ela tem esse nome por conta do nosso comportamento quando temos uma prova marcada para daqui a um mês: só começamos a estudar um dia antes da prova!

PROBLEMA 3 – Essas dependências não existem! Muitas pessoas realmente acreditam que existe uma dependência Requisitos-Análise-Codificação-Teste. Essas pessoas estão em contato há muito tempo com Gantt Charts, organizações funcionais, divisão do trabalho e desenvolvimento em cascata, e essa exposição a práticas ruins gerou paradigmas na mente delas, porém, essas dependências não existem na prática! É possível que você faça Requisitos, Análise, Codificação e Teste tudo ao mesmo tempo, ou talvez, num prazo tão curto de tempo (em frações de minutos) de forma que não é interessante gerenciar essas dependências!

Uma das coisas que as pessoas não compreendem na metodologia XP (Extreme Programming) é a prática do TDD (Test-Driven Development). Nessa prática, testes são escritos antes que qualquer código da funcionalidade seja escrito. Dessa forma, não existe código não testado e os testes são feitos antes ou durante a codificação. A idéia é: codifica-se um pouco, testa-se um pouco, e esse ciclo ocorre centenas de vezes num único dia. Outro ponto: agilistas gostam de tomar os testes como sendo seus próprios requisitos, então, testes e requisitos tornam-se uma coisa só. Dessa forma, numa única semana, o ciclo requisitos-codificação-teste pode ocorrer MILHARES de vezes dentro de uma equipe!

O levantamento dos requisitos podem ser feitos a qualquer momento através da prática do “cliente presente”, ou através de uma ligação telefônica para o cliente. A análise pode ser feita de modo incremental assim que novos requisitos vão sendo adicionados no projeto (via refactoring). As disciplinas não são fases! Elas ocorrem ciclicamente e esse ciclo numa equipe ágil é tão rápido que o custo para gerenciar isso não vale a pena. Acredite! Antes das pessoas começarem a tentar aplicar idéias Tayloristas no desenvolvimento de software, essa atividade era bem simples, divertida e a última preocupação que existia era o cronograma.

PROBLEMA 4 – A Grande Mentira da Porcentagem Concluída Leia o restante deste artigo »

Na MundoJava número 26 publiquei o artigo: “Entregue Software
Funcionando! Gerenciamento de Projetos Ágeis”. Nesse artigo escreví
sobre práticas erradas utilizadas em gerenciamento de projetos de
software. Vou passar uma listinha de tópicos abordados.

1. Manifesto Ágil
2. Software não é prédio
3. “Requisitos Detalhados” não são escopo
4. Um estudo de caso (não podia faltar, né?)
5. Por que Gantt Charts não servem para projetos de Software?
6. Liderança Corajosa x Gestão Covarde
7. Não confunda Tradicionalismo com Burrice

Recomendo que comprem a revista para os “gerentes” de projeto que
vocês têm que lidar no dia a dia!!!

Neste mês na minha coluna na revista MundoJava (número 25) escreví um artigo juntamente com Scott Ambler e Jon Kern. Creio que esses dois dispensam apresentações e foi muito legal fazer este trabalho com eles.

Separei alguns trechos de canjinha para vocês:

“É muito comum que arquitetos inexperientes dirijam a arquitetura baseada em opções pessoais, frameworks que estão na moda, alguma coisa que ele leu em algum lugar ou motivado por uma forte rigidez conceitual ou acadêmica. Também é comum que pseudo-arquitetos coloquem na arquitetura alguma idéia mirabolante que ele teve simplesmente porque ele achou isso “legal”. Nesse aspecto, a PROVA arquitetural pode filtrar aquilo que você realmente precisa daquilo que não passa de megalomania. Se o arquiteto está sugerindo a adoção da solução X ou do framework Y, dele deve ter razões muito lógicas, e principalmente, um grande embasamento nos requisitos ou nas características da área de negócios que prove os porquês dessas decisões.” Rodrigo Yoshima

“Trabalhando em inúmeras áreas, problemas e linguagens diferentes você ganha muitas experiências valorosas aplicáveis em qualquer projeto de software. Um habilidoso e experiente arquiteto de software reconhecerá soluções genéricas que comumente são aplicáveis, não importando a área de aplicação ou a linguagem de implementação. Além disso, um arquiteto hábil deve compreender o suficiente sobre modelagem de banco de dados, o suficiente sobre aplicações em tempo real, o suficiente sobre princípios sólidos de orientação a objetos e o mundo dos padrões de software, dos princípios de uma boa interface com o usuário, das arquiteturas distribuídas e do tratamento de erros para conseguir
direcionar a equipe.” Jon Kern

“Ter experiência é crítico para o seu sucesso, mas infelizmente, jovens profissionais de informática aparentam ter dificuldade com este conceito. É crucial ter uma vasta experiência construindo sistemas variados, e não somente ter muita experiência construindo a mesma coisa várias vezes. Você precisa compreender que existem muitas estratégias para construir sistemas, e ter diversos pontos de vista é importante para o seu sucesso. ” Scott Ambler

Sentí a necessidade de publicar este conteúdo pois vejo que no mercado todo mundo quer ser arquiteto e também tenho visto algumas arquiteturas (e alguns arquitetos) literalmente levando empresas para o “buraco”. Para uma empresa que desenvolve software, creio que a arquietura é um dos maiores ativos (logicamente as pessoas são mais importantes).