segunda-feira, 1 de junho de 2009




quarta-feira, 1 de abril de 2009

Designer não é Piloto de UML

Mais uma das "inovações" que vieram com o Java, o Designer é mais um dos camaradas incompreendidos no processo de software convencional. Este é mais um dos cacoetes da Análise Estruturada Moderna mal aplicada (pior, antes fosse só isso) que ainda vicejam no mercado.

Nós, profissionais de TI, desenvolvemos sistemas para resolver problemas com o emprego de TI. No entanto a resolução de problemas é um ramo muito maior que o imaginado por nós. Para resolver um problema temos um algoritmo básico composto das atividades:




  • formular um enunciado
  • implementar um modelo de análise (um modelo pode ser mental, em escala, visual ou matemático)
  • realizar a análise
  • testar o modelo
  • implementar a mudança

Fazendo um breve exercício mental agora... A grosso modo, a tarefa do enunciado do problema é delegada à Engenharia de Requisitos. A implementação do modelo de análise e a análise podem ser executadas por um analista de sistemas / OO. Daí podemos partir para a implementação da solução. Até aí nenhuma novidade.

E a implementação fica a cargo de quem? Ora, do desenvolvedor. Quem é o desenvolvedor? Ora, é um programador sênior. O que um programador sênior faz? O mesmo serviço do júnior, só que mais rápido com maior qualidade, afinal ele tem anos de experiência E CONHECE UML o suficiente para especificar um software e delegar a implementação para o desenvolvedor júnior. Certo...

Volto a seguir a este assunto...

No desenvolvimento de software temos dois grandes domínios: o espaço do problema, isto é, o mundo "real", e o espaço da solução, o mundo do computador.

Na OOAD (Object Oriented Analysis & Design) o analista é encarregado de modelar o problema independentemente de tecnologia de modo a descobrir insights sobre o sistema em desenvolvimento. É vantajoso trabalhar de uma forma mais conceitual simplesmente para "evitar as tentações" do detalhamento inerente à tecnologia usada na implementação do sistema.

Em UML o analista utiliza os estereótipos Entity, Workflow e Boundary (não sei se o método é do Booch ou do Jacobson) para identificar objetos e representar respectivamente entidades, lógica de controle e interface externa (gráfica ou de serviços). Para concluir seu trabalho o analista pode criar um diagrama de robustês para verificação de consistência entre casos de uso e elementos do modelo de análise. Antes que vestais agilistas e desenvolvedores molestados por consultores CMMI gritem "CASCATA", Bittner, um engenheiro do processo unificado resume elegantemente esta questão em uma pergunta : "Artifact or not artifact?".

Qual o trabalho do Designer? O trabalho do designer é transpor as definições do espaço do problema para o espaço da solução, isto é definir as linhas gerais da solução para o problema levantado durante as atividades de requisitos e análise restrita pelas estruturas arquiteturais pré-definidas ou construídas concomitantemente.

Isto quer dizer uso UML? Uso de UML é uma prerrogativa que a equipe do projeto deve decidir, portanto a resposta pode ser talvez. Não vou falar do "bom-senso", se tudo se resumisse a bom-senso certamente não teríamos a menos expectativa de melhora. Acho este termo tão overused quanto "agile" ou "web 2.0". Alguns critérios podem ser utilizados para definir quando e como usá-la.

Larman no livro do "barquinho" propôs 3 usos para a UML: elucidação do problema, documentação e UML executável. UML não é linguagem de programação, contém estruturas insuficientes para sua transformação em uma linguagem compilável, portanto já descarto de cara a última alternativa (sorry, MDA).

Em relação a documentação o uso da UML já começa a ficar interessante. Neste sentido o balanço adequado entre texto e diagramas pode prover documentos ricos e de grande valor principalmente para a manutenção de um sistema.

A UML conduzida pela Modelagem Ágil pode servir como veículo para a elucidação de um problema E da solução. Solução? Este é o interesse do designer.

Voltando às atividades do designer na OOAD... O nosso "programador sênior que conhece UML" constrói a solução a partir do modelo de análise. Na forma mais simples ele faz a "tradução" dos modelos de análise para o modelo de solução. Neste sentido ele criaria uma classe de entidade decorada com atributos JPA (ou Entity Beans 2.x), uma classe service decorada com atributos de transação do Spring (ou Session Beans 2.x) e alguns controllers (Struts 1.1, alguém??) em conjunto com alguma view JSP, JSF, ou Freemarker.

Mas o que não está nos livros? Melhor, o que está apenas subentendido nos livros?

Há todo um trabalho de coaching conduzido pelo designer, agora chamado de líder técnico. O designer conversa com o arquiteto e elabora a estrutura de um módulo. Pode fazer uma especificação temporária no quadro branco usando, quem sabe?, UML.

Depois conversa com o desenvolvedor e o ajuda a implementar a infra-estrutura do módulo: teremos um façade, um mediator, as responsabilidades destas estruturas são proteger o negócio e coordenar o workflow de diversos objetos da interface. De olho na arquitetura o designer prepara a infra-estrutura de artefatos seguindo as especificações do arquiteto e do gerente de configuração.

Durante a implementação do módulo, o Designer será solicitado pelo desenvolvedor para resolver problemas de queries, problemas de APIs de terceiros e quem sabe elucidar requisitos com os analistas frente a problemas que só podem ser encontrados durante o desenvolvimento.

Concomitantemente o Designer pode fazer a documentação de um módulo, especificando as responsabilidades de cada componente e, quem sabe?, usando UML.

Concluindo

O meu ponto foi: o Designer tem um papel importantíssimo na condução de um projeto, é a pessoa responsável por elaborar solução e viabilizar a implementação. Uma das falhas do pessoal de processos é ignorar a interação humana necessária para a resolução do problema. Uma das falhas dos agilistas é negar a priori todo um apanhado de técnicas OOAD que podem servir para a resolução de um problema. Onde falo OOAD não excluo abordagens para enriquecer o design como DDD ou ficando no básico dos Design Patterns ou GRASP Patterns.

Outro termo overused como "agile" e "bom-senso" é "a virtude está no meio". Este é mais um paliativo que solapa a execução de uma reflexão honesta sobre nossas atividades de TI. Cada tópico de um processo de software deve ser bem pensado e experimentado. E isso só se dá com estudo, aplicação e reflexão constantes.

segunda-feira, 30 de março de 2009

Soft-shaman agora com Twitter

Como paliativo ao meu problema de atualizações, vou tentar adotar uma estratégia mais imediatista. Estou usando o twitter para registrar progressos intermediários nas minhas pesquisas, experimentando uma abordagem de micro-blogging.



Inclui um gadget "Twitter" aí ao lado que trás os últimos posts no twitter (o howto peguei daqui).

Como beta inclui algumas impressões do livro do Ragsdale sobre o tópico de Multi Objective Linear Programming.

T++

quarta-feira, 25 de março de 2009

No meio da enrascada, respire fundo e siga adiante!

Pois é, ando meio sumido. Tive problemas de ordem técnico-acadêmica.

Bom, primeiro, a lâmpada da tela do meu note foi desta pra melhor. Até o técnico descobrir, encomendar a peça e executar o conserto se vao uns dez dias.

Como desgraças nunca vêm sozinhas (me lembro de uma citação do Corvo mais ou menos parecida), meu orientador finalmente decidiu a data de entrega da minha dissertação. Está perto. Bem no momento onde tive que me render ao apelo das lan-houses.

Fico agradecido a vocês que mantiveram meu contador do Motigo acima do zero. Na verdade este post é uma "prestação de contas" ao leitor Rogério sobre o post Padrões de Gerência de Configuração com Subversion 1.5 - Parte I: Conceitos. Ele pergunta sobre a continuidade da série de padrões de gerência de configuração.

Pretendo postar alguma coisa no meio da semana que vem, depois de entregar uma versão para revisão da minha dissertação para o meu orientador (segunda), talvez próxima quarta ou quinta (01/04 ou 02/04). Certamente a segunda parte da série de padrões de configuração está na frente.



Não gosto muito de prometer, afinal gerenciamento de expectativas é um problema a ser enfrentado. Mas lá vai um road map para os próximos assuntos que pretendo tratar no blog:

  • Aplicação de padrões de configuração;
  • Conciliação de gerência de projetos com "métodos ágeis". Uma método que adaptei e estou conduzindo com sucesso na minha empresa. Consegui manter um bom nível de balanço entre cumprimento de objetivos de médio e longo prazo, gerência de escopo e auto-organização de equipe (isto mesmo, com SCRUM). O legal do método baseado nos trabalhos de um pessoal fantástico: Kurt Bittner (esse é o cara do gerenciamento baseado em objetivos), Craig Larman, Per Kroll e Ken Schwaber.
  • Pensamento Sistêmico. Peter Senge na veia!
Até o momento estou focado na parte mais Corporativa da Arquitetura de Software. Então tem um assunto fantástico que descobri na administração para tentar avaliar uma série de possíveis arquiteturas de software. Aí vai então:

Espero com o tempo pôr alguns temas mais próximos da arquitetura de sistemas, como SOA, ESB, e de outras disciplinas da Engenharia de Software.

Então tá. Já estão me chutando da Lan House.

Até mais.

sábado, 7 de março de 2009

Sobre Prudência, Métodos Ágeis, Honestidade Intelectual e Caça as Bruxas

Não acredito que o tempo seja a verdadeira escala de medida do progresso. Apenas porquê temos hoje uma profusão de novas informações, novos métodos e novas promessas, não acredito que sejamos melhores do que os que nos precederam.

Não acredito num futuro brilhante como resultado unicamente baseado nas nossas ações do presente. Acredito no máximo num futuro razoável a enormes expensas de muito trabalho físico e cognitivo baseado na experiência pessoal de cada indivíduo. Compreendo que a estabilidade e a mudança devem ser reconhecidas e reconciliadas.

O que já é um ganho em si.

Apenas para mantermos nossos ganhos devemos nos esforçar para resistir à esmagadora força da entropia (no sentido de dispersão de energia). Sendo assim, o feedback é um mecanismo importante para a manutenção da concentração de energia do sistema para que este consiga sustentar um nível de trabalho aceitável, possibilitando o reconhecimento de uma cadeias de causa e efeito passíveis de uso na manutenção de ciclos virtuosos.

Isto foi o que me atraiu mais no advento do Scrum. Uma prática calcada na revisão constante de nossas ações passadas. Mas o Scrum não é nada mais que isso, é uma descrição de um mecanismo de feedback em um sistema.



Atualmente está ocorrendo uma caça às bruxas onde o Scrum é o bode expiatório da vez (Adopting the Whole Enchilada, Flacid Scrum e outras asneiras vindas a reboque do Decline and Fall of Agile).

Retrospectivas não são apenas pontos de replanejamentos per se. Tampouco são reuniões de terapia de grupo. São pontos ativos onde o feedback é usado para correção de rumo do método. É o ponto onde o relacionamento causal de nossos atos pode ser analisado e corrigido. É o reconhecimento do pensamento sistêmico como modo de se usar a dinâmica de sistemas em nosso proveito.

A despeito de toda uma indústria de consultorias e certificações criadas a seu redor, este é o valor de Scrum: sua simplicidade. Seu respeito a uma regra básica da física o torna um método elegante. Ponto.

Obviamente Scrum não é o suficiente. Para tirarmos proveito disto temos que ser criteriosos durante a retrospectiva. Isto não significa usar o bom senso, ou senso comum. O que quer que isso signifique acredito que não seja o ponto. Falo de honestidade intelectual. Não existe bala de prata.

Ser intelectualmente honesto não é uma tarefa fácil, reconfortante, ou que traga felicidade ou paz. Não foram nem uma nem duas vezes que idéias minhas foram refutadas (tanto justa como injustamente). O conhecimento da verdade, e principalmente de sua extensão, não é uma tarefa para fracos. Scrum não é o suficiente.

O que falta aos praticantes, agilistas convictos ou não, é pensamento crítico. Aproveitar os momentos de retrospectiva para REALMENTE fazer um ponto de inflexão. Onde podemos adotar uma série de técnicas fartamente documentadas na literatura de ciência da computação sistemas de informação e administração, submetê-las ao duro teste da prática e avaliá-las sem dogmatismo.

Durante a retrospectiva devemos entender que não há nada o que fizemos, absolutamente NADA, que seja realmente novo (não sou um fã de Nietzche). No decorrer de 40 anos de engenharia de software e de 10000 anos de outras engenharias, o que temos a fazer é olhar os que nos precederam, e isto não se restringe aos agilistas, nem tampouco ao RUP ou outra metodologia.

Não é uma questão de adoção do "bolo inteiro" é uma questão de adoção do que realmente podemos adaptar e empregar em um sistema sócio-técnico altamente dinâmico para que possamos retardar o avanço da entropia.

domingo, 1 de março de 2009

Sobre Arquitetos de Software, Life Planners, Consultoras Natura e Jequiti e Rebranding

Atenção! Este post deve ser lido com a tecla SAP ativada. Caso não seja muito dado a sarcasmo ou ironia, por favor, nem tente.

Rebranding é o processo pelo qual um produto ou serviço desenvolvido sob uma marca, empresa ou linha de produtos é comercializada ou distribuída com uma nova identidade. Geralmente isto decorre de um reposicionamento de uma marca na tentativa de se descolar de conotações negativas da marca anterior.

Corretagem de seguros é uma profissão cheia de inconvenientes para o próprio e para o cliente. Corretores te ligam, marcam encontros em horários de estudo ou trabalho, insistem e ainda por cima pedem indicações suas. O cliente se faz de louco, não atende ou simplesmente manda o corretor longe.

Certa feita, fui chamado para uma entrevista numa multinacional em expansão agressiva no país (corporativês é o máximo). Ao chegar lá o recrutador foi falando sobre a empresa, foi falando sobre o produto, seguros, sobre a abrangência e tudo mais. Eu já imaginando "nossa, imagina a TI desses caras".

Com andamento, fiquei sabendo que não me chamaram para arquitetar algum sistema deles, mas para ser um life planner a um soldo de milhares de reais mais benefícios e comissões. Bom ainda estava interessado, pelo soldo, aí me veio a prescrição da vaga, era um corretor de seguros. Declinei e agradeci, não tenho perfil para trabalhar com humanos estranhos 100% do tempo (apesar de viver em reuniões, workshops e entrevistas).



Isso foi o rebranding em ação.

Há tempos a indústria de cosméticos vaseada em distribuição direta contava com Vendedoras Avon, Natura e Jequiti. O tempo transformou estas vendedoras em Representantes Avon, Natura e Jequiti. Por fim estas representantes se tornaram Consultoras Avon, Natura e Jequiti.

Mais um exemplo de rebranding.

Bom, a maior parte da minha carreira fui um consultor trabalhando em algumas empresas de consultoria de TI em Porto Alegre. Talvez se minha carreira tivesse tomado outro rumo não teria tido a variedade de experiências que adquiri. Já trabalhei em áreas diversas como DBA e administrador de servidores Linux, programador e arquiteto de software e como analista de sistemas e engenheiro de processos. Sempre tive sucesso em todas as áreas. Claro, fracassos se somam ao resultado final, mas o balanço até o momento é bem positivo.

Isso ocorre devido ao rebranding nas empresas de consultoria. Não é conduzido pelo departamento de marketing, e sim pelo departamento comercial. Um consultor se torna um profissional alocado via rebranding logo após o comercial questioná-lo: "Tem idéia de como se faz?". Temos aí um rebranding à la carte no ramo de outsourcing.

Antes que se perguntem, respondo: Não, nunca fui consultor Avon, Natura ou Jequiti.

O Reverse Rebranding e o Arquiteto de Software

Como falei anteriormente aqui, o mercado local de TI passou por um tempo de dificuldades na assimilação das tendências de mercado externas. Um dos problemas de assimilação foi justamente a posição de Arquiteto de Software. Outro foi justamente a vinculação da complexidade da TI atual à plataforma java, que em si, é apenas um reflexo da própria complexidade da indústria de tecnologia atual. Isso mesmo, Java é muito mais que uma linguagem.

Ouso dizer que são poucos os verdadeiros arquitetos de software que conheço. Não vou tratar o meu entendimento sobre arquitetura de software neste post. Isto dá muito pano pra manga. Vou resumir o meu ponto: Arquitetura de Software diz respeito à mitigação de riscos em sistemas sócio-técnicos.

Isto demanda uma abordagem amplamente interdisciplinar para resolução de problemas. Dêem uma olhada na lista de livros ao lado, acredito que sejam parte integrante do corpo de conhecimento técnico do arquiteto de software.

Na área de arquitetura de software ocorreu justamente o reverse rebranding. Haviam demandas novas (gerenciamento complexidade de TI) que deveriam ser solucionadas, no entanto ao invés da adaptação estrutural necessária, foi feito um rebranding do desenvolvedor sênior em arquiteto de software sem que os skills adequados sejam desenvolvidos para o atendimento de novas demandas. Afinal faz todo sentido descolar os aspectos deficientes de uma marca antiga e esperar que todos estes sejam atendidos apenas pelo que se imagina das conotações positivas da nova marca.

Um arquiteto de software não trabalha apenas com a integração do Spring e do Hibernate. Não é um piloto de API. Deve sobretudo entender o mecanismo interno desses e o mais importante deve desdobrar o funcionamento destes mecanismos sob as condições demandadas pelo sponsor como, por exemplo, escala, tempo de vida, manutenibilidade, integração e atendimento ao negócio que em si demanda grande conhecimento do domínio.

O arquiteto deve ter conhecimento em profundidade e amplitude sobre vários aspectos da TI, do protocolo de rede, ao funcionamento de frameworks, processos de desenvolvimento até o alinhamento estratégico da organização. Isto subsidia talvez o principal skill, na minha humilde opinião, do arquiteto de software: Pensamento Sistêmico. Ver as árvores e a floresta de acordo com a necessidade.

Como resultado do reverse rebranding, já vi vários erros cometidos por "arquitetos de software". Não erros decorrentes de deficiências em conhecimentos organizacionais, conhecimentos em soft-skills, como engenharia de requisitos ou relacionamento interpessoal (por si a maior reclamação do pessoal das organizações em relação a "arquitetos" intratáveis), mas conhecimentos em tecnologia, o famoso "baixo-nível":

  • dizer que o impacto de mapear chaves primárias compostas é nulo: pois é afinal só porquê o framework suporta não significa que o custo de trocar de paradigma de modelagem é zero
  • paginar 50000 itens em arrays java script: paginação com "cache built-in no client". Depois de 5 minutos do primeiro download fica rápido. Imaginem 10 usuários acessando a mesma página
  • construir frameworks in-house: também acho que recursos como tempo e dinheiro são inesgotáveis e que uma equipe de 3 gatos pingados cheirando a cueiros (apesar da idade avançada) consegue fazer um produto de maior qualidade do que a Oracle ou alguém da Apache.org. Isso é um viveiro para idéias estúpidas.
  • transformar camadas de abstração em paredes de concreto: a maior delícia para rastreamento e resolução de problemas, fazer 50 desenvolvedores trabalhar com uma série de ótimos frameworks de mercado, por trás de abstrações estúpidas.
  • alterar código fonte servidores de aplicação PADRÃO Java EE para contornar falhas de design: Pois é
  • componetizar usando técnicas agropecuárias de enxerto: também acho que a manutenção da integração de dois grandes sistemas se dá melhor através da injeção viral de um em outro
  • alterar código fonte de produtos open-source à revelia da comunidade:

Concluindo

O contratante deve tomar muito cuidado quando alguém oferecer um "arquiteto de software" ou um "arquiteto corporativo". Não digo que esta situação seja generalizada, apenas que já presenciei mais de uma vez a ocorrência de fenômenos semelhantes. Volto ao assunto de definição dos skills de um arquiteto no futuro.

Um breve Contexto sobre a Tecnologia nos Últimos anos aqui no Brasil

O nosso país sempre esteve atrás das maiores tendências em TI. Talvez este gap esteja diminuindo agora com a internet. Mesmo assim temos nossos problemas ainda.

A ciência da computação passou por revoluções tão avalassadoras nos últimos 40 anos que faz com que as organizações tenham dificuldades em acompanhar não apenas a tecnologia mas o próprio mercado de TI (Quem não falou com o velho gerente de CPD que falava dos tempos do DATAFLEX, ADABAS, COBOL, ZIM e mesmo do Digitador).



Com um ciclo de mudanças nas subfunções da TI inferior a 5 anos novas carreiras e novas especializações surgem como Arquiteto de Informação, Analista IHC entre outros, como o Arquiteto de Software.

No desenvolvimento do nosso mercado local (Brasil e mais especificamente região sul), várias inovações da TI chegaram num determinado momento, mais ou menos a partir de 1996 - 1998. Entre elas a linguagem java em ambiente comercial, a adoção da arquitetura 3 camadas, o emprego da tecnologia TCP/IP e o uso deinterface Web.

Antes disso haviam plataformas proprietárias de diversos vendors, como a Oracle, a Borland, a Microsoft, e outras jabuticabas como o ZIM. Todas essencialmente duas camadas.

A gestão deste mix Tecnológico pelos departamentos de TI foi complicada. Um dos mitos que recorrentemente ouço é que toda essa complexidade é inerente à plataforma Java.

Durante a reserva de mercado na década de 80 ocorriam as guerras por padrões de plataformas corporativas, como CORBA, COM e DCOM, bem como as guerras de consolidação dos protocolos Internet. Coisas que o mercado local acompanhara apenas marginalmente. A grande maioria das empresas médias não têm acesso ao desenrolar das brigas por padrões (não é sua obrigação e nem seria de seu interesse) chegando a adotar padrões relativamente consolidados pelo mercado.

A encarnação atual de plataformas pode ser vista nos entreveros pela definição do padrão de HDTV no Brasil e nos padrões de discos óticos que substituirão o DVD, como o blu-ray.