Recentemente participei desde o início de um grande projeto SOA, onde um dos maiores problemas foi uma corrida desenfreada contra o tempo. Acredito que a principal lição, e um tanto quanto obvia, foi: quanto mais rápido você tenta correr, mais se distancia do seu objetivo. Seguem os pontos positivos e pontos de melhoria do projeto como um todo:
Pontos positivos: No começo do projeto foram estabelecidas práticas de integração contínua. Isso economizou muito tempo.
Pontos de melhoria: Reuniões de kickoff, cerimônias como Daily Meeting, Sprint planning não podem ser ignoradas. Elas existem por um motivo, só as remova caso sua equipe tenha muita sinergia e maturidade (como equipe, maturidade individual não conta muito neste sentido).
Tenha apoio de um especialista no domínio (Project Champion, PO (Project Owner), analista de negócio, etc) caso não seja possível, aloque um membro da equipe no cliente e transforme-o no seu PO. Depois de algumas semanas imerso, ele conseguirá direcionar funcionalmente o restante da equipe, compensando em partes esta deficiência do projeto, conduzindo kickoffs de fases do projeto e sprint plannings.
Arquitetura
Várias decisões arquiteturais foram tomadas visando atender a principal prioridade do projeto: o Prazo Impossível. Isso influenciou negativamente o projeto em vários aspectos, como na modelagem dos serviços, do Modelo Canônico, e no tratamento de falhas.
Modelagem dos Serviços
Para promover o paralelismo, ‘diminuir a complexidade’ de uma modelagem adequada e suprir a deficiência de PO’s, a camada SOA foi moldada exatamente como os sistemas, adotando inclusive o mesmo Contrato (WSDL) para evitar transformações nos serviços dos principais sistemas custom da empresa, que estavam sendo construídos em paralelo ao ‘Projeto SOA’. Esta falta de Abstração e Autonomia nestes serviços, trouxe alguns problemas, principalmente no forte acoplamento da camada SOA com o sistemas que, fatalmente iria levar a duplicação de vários serviços, cada um basado na perspectiva do seu sistema.
Por este motivo também, a modelagem de uma arquitetura funcional não foi estabelecida.
Modelo Canônico
Após mais de um ano e meio de projeto e evolução, o Modelo Canônico se mostrou resiliente! É evidente que existem problemas que se tornaram visíveis com o decorrer do tempo, porém nenhum que tenha gerado muito stress.
Governança
Se em empresas onde o desenvolvimento orientado a serviços é ‘organizado’ e ‘maduro’ a governança SOA é falha ou inexistente, imagine em um cenário desses. O impacto de não ter nem uma área de arquitetura nem governança estruturadas foi uma maior dificuldade para definições de papéis e responsabilidades.
Na verdade, o propósito daquele membro da equipe que ficou alocado no cliente era estabelecer processos de governança. Porém, devido ao momento do cliente, isso não foi possível.
Uma evidência da falta de planejamento, foi a presença de serviços ‘V2’ antes mesmo do sistema estar plenamente em produção!
Outra evidência dessa falta de planejamento, é a priorização a base do grito. Onde o backlog fica congelado e novas atividades, aparentemente prioritárias, furam a fila. O mais frustrante é quando elas são realizadas a ‘toque de caixa’ e nunca chegam a ser promovidas a homologação.
Comunicação
Um dos problemas mais recorrentes em projetos de TI, quando negligenciado, tende a agravaram o cenário já caótico.
Equipe
Um dos fatores decisivos para a sobrevivência no projeto, foi uma equipe tecnicamente muito competente, que realizou diversas melhorias no processo de integração contínua de forma pró-ativa!
Estratégia
Erro na estratégia lançamento das funcionalidades
Já ouviram a frase: “Quando tudo é prioridade, nada é prioridade“? Então, ela não pode ser ignorada senão gera o efeito mencionado no início do texto: quanto mais rápido você tenta correr, mais se distancia do seu objetivo.
No início do projeto haviam várias funcionalidades em um backlog whaterfall, que poderiam estar prontas, mas acabaram perdendo a relevância, e foram desenvolvidas apenas para entregar, mas que nunca foram sequer olhadas pelo cliente. Isso sugere que existia uma prioridade, porém não foi utilizada para otimizar o processo de desenvolvimento.
