Mostrando postagens com marcador Engenharia de Software. Mostrar todas as postagens
Mostrando postagens com marcador Engenharia de Software. Mostrar todas as postagens

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.

sexta-feira, 27 de fevereiro de 2009

Requisitos: A Disciplina "Ágil" Esquecida II

Após um "breve" hiato de 5 meses, cá estou. Não gosto de falar sobre futurologia do passado principalmente no que se refere ao meu trabalho, mas estou continuando um post que estava em rascunho de 17/09/2008. Vou concluir este trabalho abaixo e depois tentar dar continuidade frente a alguns fatos novos ocorridos nas últimas semanas.

Segue o "original".

No contexto de Engenharia de Processos em Software acredito que estejamos vivendo em um movimento pendular entre níveis de formalismo e agilidade. De um lado temos o que foi confortavelmente rotulado de "tradicional" pela liderança da comunidade ágil (um mix dos estratagemas de Schopenhauer números 12 e 19), do outro lado temos tudo que é bom, belo, justo e providencial regido sob os auspícios do manifesto ágil.

Qual o problema? O problema é justamente o seguinte: praticamente tudo o que é passível de adoção pela comunidade ágil é uma aceitação a priori da verdade de temas sem que uma avaliação crítica honesta seja feita por seus membros. Estes temas (ou variações menores sobre o mesmo tema) são propagados como rastilho de pólvora e aceitos (take for granted) sem contestação. Na velocidade do blogosfera é praticamente impossível avaliar criteriosamente o que blogueiros postam, fazendo com que o valor potencial da informação de fontes primárias seja prejudicado.

Um exemplo do prejuízo causado pela falta de contextualização histórica e análise crítica é justamente a presunção de achar que todos os benefícios do desenvolvimento de sistemas moderno é derivado das práticas ágeis. Trocando em miúdos, o mundo começou com o manifesto ágil, com o Scrum e com o XP.

Várias práticas efetivas dos "métodos ágeis" não foram uma invenção originária dos luminares dos métodos ágeis. Bem da verdade várias práticas "ágeis" já eram adotadas até dez anos (ou mais) antes do manifesto ágil (olhem McConnell). As práticas se tornaram cool apenas pelo rebranding.

Neste cenário quem é diretamente prejudicado? Esta é a deixa do nosso desenvolvedor Joe Six-pack. O Joe é um cara ocupado. Entrou para informática para desenvolver jogos, mas acabou se tornando um programador comercial.

Joe trabalha numa empresa onde a TI está em sua adolescência ainda. A TI não trabalha mais com sistemas meio e sim na própria atividade fim da empresa. A atividade fim, ao contrário de uma folha de pagamento ou sistema de manutenção, deve se adaptar ao mercado. Se os sistemas não se adaptam, a empresa simplesmente é engolida pelo mercado.

Com o peso de sistemas "fim" sob seus ombros, Joe não tem benefício da reflexão devido às pressões do ambiente. Joe tem que entregar. Joe já tentou uma série de metodologias para tentar se adaptar melhor ao ambiente, mas falhou em todas, por diversas razões: falta de buy-in da gerência, falta de priorização da diretoria e, principalmente, a falta de um plano de melhoria contínua, o que na administração é chamado de PDCA.

Joe, já desistindo completamente do processo de software (afinal o que não tem solução, solucionado está) houve falar de uma nova tendência de mercado, um tal de movimento ágil. Nele simplificamos as coisas (afinal é o que os blogueiros dizem) : não desenvolvemos documentação, aliás podemos até queimar a documentação, afinal o usuário sempre estará por perto para dar uma dica; não nos preocupamos em refletir sobre o que construir, afinal tudo muda tão rápido que é mais fácil construir primeiro e perguntar para o usuário depois, afinal já temos um lembrete na parede sobre o que devemos construir, qualquer dúvida, o usuário está lá.

A maior baixa neste fogo cruzado foi justamente a Engenharia de Requisitos, alvo do atrelamento infundado de grandes mitificações. Requisitos não são software em funcionamento, requisitos são um calhamaço de documentos do Word que podem ser jogados fora assim que o software estiver rodando, afinal para que requisitos escritos enquanto testes de software são "requisitos vivos".

Finalmente Joe achou alguma coisa valiosa. Tentou gerenciar a complexidade de desenvolvimento com processos prescritivos e não conseguiu, agora está mais tranquilo. Afinal ele já sabe nada o que foi feito antes chegou a funcionar algum dia.

Voltei

É claro que isto é apenas uma alegoria. Super simplificação? Com certeza, não tenho aspirações a fazer uma tese neste blog. Muito menos tenho a pretensão de expor A VERDADE em poucas linhas.

Agora retomo o assunto nos próximos posts.


quinta-feira, 11 de setembro de 2008

Sim Estamos no meio de um Hype

Definitivamente estamos vivendo mais um hype em TI.

Apenas mais uma evidência fortíssima: artigo no InfoQ sobre métodos ágeis na escrita de livros. Segue:



O Per Kroll (do OpenUP) fez um processo de interação semelhante com os co-autores, revisores e editores e não o chamou Agile Writing.

Qualquer livro sobre escrita de textos técnicos diria para se partir de uma tese principal (a resposta ao problema que o livro pretende resolver), fazer um outline dos argumentos principais e depois escrever o conteúdo. Abaixo tem algumas referências sobre o método.

segunda-feira, 25 de agosto de 2008

The Agile Ostrich Development Method Development Method

Como Andy Warhol preconizou, todos têm direito a seus 15 minutos de fama. Hoje, através da blogosfera, conseguimos atingir a institucionalização dos 15 minutos para as massas.

Não que eu considere Warhol. Para mim, contestação pseudo-aforística baseada apenas em devaneios pessoais, sem embasamento (não necessariamente empíricos, mas também racionalistas) valem tanto quanto um churrio intelectual. A blogosfera é um ambiente propício para isso, onde pálidos arremedos de empirismo são declarados como verdade prontamente generalizável.

Um filósofo brasileiro, talvez o único legítimo na nossa atualidade diz que as pessoas não deveriam esperar ser ouvidas sobre um determinado assunto por mais tempo que se dedicaram a estudar ou refletir sobre o tema. É um argumento objetivo, apesar do caos mental em que as pessoas andam imersas atualmente onde referenciais, se muito, entram em obsolescência em uma velocidade maior do que a maioria das pessoas consegue lidar.

Técnicos (bem como profissionais em alguma pos) gostam de ouvir a própria voz. É uma questão de Ego (um dia exponho a Teoria do Hamsterismo em Profissionais de TI, desenvolvida por um camarada meu desenvolvedor e dublê de psicólogo). Teorias são prontamente formadas baseadas em crenças, medos, preconceitos e observação enviesada do micro-ambiente circundante ao observador.

Neste sentido, deixo uma proposta anedótica de um meta-metodologia para desenvolvimento de software (não tão desenvolvida quanto o Glacial Methodology) ágil. Baseada unicamente na minha experiência ao analisar o comportamento das pessoas. Ela é absurdamente simples. É baseada unicamente pelo amálgama do buzzword oriented development com o comportamento clássico de pessoas avessas a mudanças (ou não muito dadas ao rompimento com o cordão umbilical de sua zona de conforto).

Eu chamo de Meta Agile Ostrich Development (MAOD). Segue:

  1. Devemos analisar nosso ambiente;
  2. Devemos ignorar completamente 40 anos de avanços em Engenharia de Software;
  3. Empiricamente ("" como diria Dr. Evil) devemos analisar o ambiente sócio-técnico de estudo;
  4. Formulamos uma hipótese pseudo-aforística, por exemplo: "vamos queimar a documentação de requisitos do software e elevar testes de software ao status de especificação" que aparentemente elimine a necessidade de tal burocracia passe a ser lei;
  5. Indo de encontra todos os fundamentos da honestidade intelectual, elevamos a hipótese unicamente baseada em nossas crenças ao nível de imperativo categórico;
  6. Insituimos a generalização e aplicabilidade do nosso modelo de forma ampla e irrestrita;
  7. Criamos um post no blog;
  8. Ficamos a espera de um feedback da comunidade que corrobore nosso sentimento auto-indulgente e rebatemos críticas ao estilo Groucho Marx: "Em quem você vai acreditar: em mim ou nos seus olhos?".
Este método de raciocínio orientado ao umbigo é parecido tem um modelo paralelo encontrado na natureza: é o comportamento do avestruz (ostrich). Para fazer uma análise adequada e rigorosa do ambiente basta enfiarmos a cabeça na areia (Ok, é um mito, mas vale como metáfora).

A buzzword do momento definitivamente é Agile. Concordo com meu camarada Diego Pacheco. Basta complementarmos uma série de princípios baseados no comportamento padrão das pessoas (tanto em stand alone como em organizações). Esta é a cereja no topo do bolo (se fosse uns 3 anos atrás era só trocar por Spring ou Hibernate).

Voilá! Temos uma metodologia de desenvolvimento com sex appeal. Com apelo às massas.

É só postar e esperar nossos 15 minutos profetizados por Andy Warhol.

segunda-feira, 18 de agosto de 2008

Enquanto a água não baixa do pescoço

Bom, estou aqui no mestrado, até o pescoço com a minha dissertação. Vou relaxar um pouco com algumas divagações. Assim que eu me livrar dessa naba vou escrever algo um pouco mais decente.

No mais, como posso descrever a sensação de se ter chegado ao mestrado... uma realização. Como posso descrever a sensação de ter chegado ao último semestre do mestrado... um terror. Não nasci para escrever textos com mais de cinco laudas.

Até eu escrever alguma coisa que preste na minha proposta, não tenho muita coisa a desenvolver por aqui, portanto vamos para o básico. Crenças:

  • A tentativa de enquadrar a Ciência da Computação no ramo das Ciências Naturais... falhou;
  • A metáfora das demais Engenharias aplicada à Ciência da Computação... também falhou.
Em relação à primeira crença, achei uma base interesante para minhas digressões, talvez não seja novidade para alguns acadêmicos. Vou tentar esclarecer (também pra mim) um pouco este imbróglio, sobre ombros de gigantes, em um segundo momento.

Em relação à segunda, bom esta acredito que seja mais tangível para nós na vanguarda (no sentido "infante"da palavra) da TI. Estamos vivendo um momento onde a Crise de Software que originou a própria Engenharia de Software como disciplina simplesmente não encontrou uma solução definitiva.

Isso mesmo, se construíssemos pontes, elas ruiriam, se construíssemos modelos teóricos (for real) rigorosos talvez ainda não tenhamos conseguido a lâmpada elétrica (sendo que Thomas Edison era um baita 171, vi no History Channel). Certo, não temos o corpo de conhecimento formado tal outras áreas, mas dada a devida proporção talvez pudéssemos ficar tranqüilos.

O problema é que nós somos ourives, ferreiros ou marceneiros (enfim, ponha seu "*smith" aqui). Vivemos do nosso (amado, espero) trabalho e nossos clientes são insaciáveis na demanda por novas ferramentas, novas estruturas, novos mecanismos. Seguindo uma analogia artesanal poderíamos até fazer anéis, braceletes ou pulseiras.

A má notícia é que a confecção da coroa ainda está longe do alcance da maioria de nós. Uma notícia pior ainda: muitos reis querem novas coroas e tantos outros querem manter e melhorar os adornos de suas coroas.

Só conseguiremos atender a novos reis se, com humildade e questionamento constantes (ok, um pouco de competição ajuda muito a azeitar a máquina), resolvermos honestamente melhorar nossa arte.

Aqui vai a notícia péssima. Quem está realmente disposto a encarar o desafio?

Claro que não estou falando da construção da coroa.