Este é o último artigo da série sobre agilidade, que foi composta por uma apresentação da minha visão segmentando a discussão em três pilares: Processos, Pessoas e Tecnologias. Agora como última etapa dessa série sobre como orquestrar e contribuir com as demais áreas.

Saber usar as ferramentas certas vai te possibilitar ir mais longe e com mais facilidade no mundo da agilidade. Já imaginou tocar um órgão como esse aí embaixo, se ele fosse cheio de adaptações que não considerassem a harmonia entre: o músico, o instrumento e as notas usadas para se escrever as partituras?

Tecnologias

O suporte tecnológico é obrigatório e pode facilitar muito a execução das atividades do dia-a-dia. É importante garantir agilidade no tocante a tarefas repetitivas, pois permitirá poupar tempo para focar no que realmente importa.

Sendo assim, vamos definir o que estou chamando de tecnologias segundo a Wikipédia:

Tecnologia é um conhecimento sobre uma técnica ou processo que possa ser usado ou embarcado em máquinas e sistemas.

Ele deve ser tão simples quanto o necessário para suportar as provas do tempo e do tamanho do time.

A prova do tempo, é cruel pois dependendo das nossas escolhas tecnológicas e padrões arquiteturais utilizados, um alto preço será cobrado devido a interdependência e complexidade que naturalmente vão surgir com a evolução da solução ou mudanças no negócio.

É importante que exista um padrão claro para dar segurança, dessa maneira o time pode usar para evoluir de forma consistente.

Alguns padrões que tenho usado frequentemente e tem suportado a prova do tempo, inclusive com mudanças no time de desenvolvimento, são: CQS ou CQRS e conforme o caso, SRP e Mediator.

Veja o poder do Observer e Mediator respectivamente no framework PureMVC e TodoMVC onde o Addy Osmani mostra que se pode redefinir a arquitetura e organizar a aplicação focando apenas na camada de interatividade entre os componentes.

A prova do tamanho do time surge quando se tenta escalar um projeto para uma equipe, ex: três desenvolvedores para seis e você começa a ter problemas de concorrência e indefinições. Nesse processo os poucos padrões que por ventura você tenha definido, vão durar muito pouco.

É importante que você tenha clara as definições tecnológicas para cada uma dessas dessas simples camadas, visualizando dessa maneira você consegue avaliar o que usar de forma clara. Mas, isso não significa que você deve ficar preso ao modelo arquitetural [Multi-camadas].

Essa é apenas uma visão do projeto para você se organizar e identificar o modelo de interação e arquitetura geral e de cada camada. Isso vai te ajudar a estruturar o seu projeto de forma mais clara. Abaixo segue uma visão.

Tenha em mente que cada camada deve garantir o desacoplamento em relação a outra para possibilitar a testabilidade do software o quanto antes.

Se o time não tem experiência com TDD, garanta que pelo menos a camada de negócio tenha cobertura de 100%

Para facilitar a orientação dos testes a serem desenvolvidos no início, gosto de definir padrões a serem testados:

• Divido primeiro em três categorias:
  • dados que estão ligados ao estado válido dos objetos da aplicação
  • regras de negócio que são as condições de execução pré e pós mudanças de estado
  • retorno de consultas, retorno de dados
• Em termo de dados, verifico todos os parâmetros obrigatórios
• Em termos de regras de negócio, todos os caminhos principais e alternativos
• Ainda termos de regras de negócio, todas as situações de retorno de erros
• Em consultas, verifico os retornos operações sem dados no retorno, com uma linha, com várias linhas e com cada campo filtrado caso existam filtros.

É importante constantemente reavaliar a necessidade de inclusão de novos padrões ou remoção de padrões quando desnecessário.

Dessa maneira você não precisa ficar pensando que teste fará em cada funcionalidade, mas sim apenas verificar os padrões que se aplicam à realidade daquela funcionalidade que está implementando.

Infraestrutura

Infraestrutura é sempre um ponto complicado, pois explorar o seu pleno potencial depende do envolvimento de pelo menos dois departamentos: infraestrutura + desenvolvimento. Isso pode ser difícil na sua empresa, mas é o que chamamos de DevOps.

Usar conceitos de DevOps no seu projeto vai te fazer entender que uma solução é muito mais que escrita de códigos e documentação, você vai passar a olhar para a solução sob todos os aspectos, inclusive deploy em produção.

Mesmo que devops não seja uma realidade na sua empresa, somos agilistas e sempre damos um jeito de seguir em frente. No caso você pode trabalhar alguns conceitos de maneira a facilitar a execução do seu projeto.

Nesse momento me apoio muito nas recomendações dos 12 Fatores.

Lembre-se que todas as horas gastas na configuração de uma boa infraestrutura são recuperadas durante a execução do projeto, atualização ambiente entre outras coisas, faça o que puder pois valerá a pena.

Abaixo apresento alguns itens que me ajudam bastante em meus projetos.

Instrumentação de tudo que for "possível" (em termos de esforço e prazo)

• Aplicação
• Projeto
• Códigos

Quando falo de instrumentação, de aplicação, um exemplo seria logs usando um framework apropriado, fazendo o devido armazenamento e definição da estrutura do evento de log a ser registrado.

Devemos nos lembrar que o log vai nos ajudar no futuro, principalmente se desejarmos evoluir a estrutura para um arquitetura descentralizada.

Em termos de projeto e códigos, use uma ferramenta de controle de versão, se não sabe ou não tem um processo, siga as recomendações da ferramenta. Use a estrutura padrão e depois evolua conforme os problemas forem aparecendo ou as coisas forem ficando mais claras.

Pense bem ao escolher a sua ferramenta de gestão de códigos, pois ela irá influenciar em todo o seu processo de instrumentação.

Estruturação do projeto

Pessoalmente eu sempre acho difícil definir uma boa estrutura para organizar as soluções e projetos, mas procuro conseguir algumas linhas, para isso foco em dois pontos principais:

1. Fácil replicação, ou seja criar outro projeto que pode ser composto de vários módulos.
2. Separação dos conceitos de maneira a ter uma clara referência de onde criar as classes ou componentes para cada funcionalidade

Para facilitar essa estruturação faço um exercício usando caixas. Abaixo segue um exemplo onde cada caixa azul é um "projeto de código" na solução (é o conjunto delas) por sua vez dentro do Projeto (software completo a ser desenvolvido) .

A ideia desse tipo de desenho é conseguir visualizar os mini "frameworks" que seriam generalizações das possíveis camadas lógicas da aplicação.

É de suma importância que esses frameworks sejam simples, leves e não comprometam a estrutura do projeto.

Automação

• Use ferramentas de construção
• Ferramenta de testes unitários

Automatize o projeto o quanto antes, escolha uma das ferramenta de construção da sua plataforma e integre ao seu projeto, de preferência possibilitando a construção local do projeto.

Mais uma vez, voltemos aos 12 Fatores: Construa, Lance e execute

Bônus altamente desejável

• Verificação de cobertura

Essa eu coloquei como bônus, pois se você não têm "tempo" formalmente separado para melhoria do processo, implementar verificação de cobertura pode ser complicado, mas se você conseguir será uma ótima ferramenta para te orientar no desenvolvimento de testes unitários.

Lembre-se que o relatório de cobertura é uma ótima ferramenta para se garantir a efetividade dos testes unitários implementados.

Frameworks

Esse é um ponto onde encontramos muitos problemas, pois a insegurança e coragem exacerbados podem trazer grandes problemas, abaixo ilustro alguns:

1. Elevar o custo de um projeto com tempo pelo aumento de complexidade forçosamente inserido no projeto.
2. Dificultar a gestão das dependências do projeto ao se incluir uma nova sem a devida avaliação
3. Comprometer um projeto caso uma avaliação incompleta não identifique por exemplo a falta de suporte a uma funcionalidade ou plataforma necessária
4. Trazer problemas desnecessários ao projeto com modificações não analisadas ou priorizadas

Planeje o que vai fazer antes de começar a fazer, converse com seu time.

Por esses e outros fatores que eu procuro escolher conforme vários critérios, e sim, eles podem ser subjetivos. Cada um olhará de uma maneira diferente com base na sua experiência, a minha seria nessa linha.

Nessa hora não podemos ser fãs de tecnologias, devemos considerar como ferramenta de entrega de valor no menor tempo possível de maneira sustentável.

Entrega de valor no menor tempo possível de maneira sustentável a longo prazo

Isso significa que a plataforma base do projeto não pode apresentar limitações do tipo:

• Conflito de dependências entre componentes de tecnologias diferentes, quando módulos usam diferentes versões de um mesmo componente.
• Tornar-se obsoleta impossibilitando ou dificultando evoluções, quando a tecnologia te obriga a uma atualização com mudança de tecnologia.

Outros itens a serem considerados, são:

1. Custo da "facilidade" a médio e longo prazo.
2. Número de dependências, verifico o peso dessa dependência.
3. Portabilidade
4. Possibilidade de extensão, tento avaliar o quão "travada" é a tecnologia

Faço essas verificações, pois poucas plataformas são robustas e flexíveis como Spring Java por exemplo. Ela te dá várias possibilidades dentro de uma mesma funcionalidade, ex: frameworks web, abstrações diferentes da camada de persistência, etc.

Com esses itens pelo menos consigo saber o quão simples é fazer o que preciso e tento com base nisso avaliar o quão complexo será fazer algo mais elaborado ou diferente no futuro.

Classifique para escolher em categorias

Para esse eu me apoio em alguns padrões de arquiteturas emergente de mercado: Microservices e Reatividade

1. Fundação (Chassis) - inicializa e hospeda a aplicação
2. Comportamento - Define as características de interatividade entre objetos, ex: mensagens, callbacks, métodos, etc.
3. Apresentação - qualquer interface API, usuários
4. Armazenamento - tudo relacionado a dados
5. Concorrência - execução de operações em paralelo

Para facilitar a escolha eu acabo categorizando os frameworks conforme o uso no projeto e uma vez definido isso eu não mudo mais até o final do projeto.

Pode parecer meio fatalista, mas em meus projetos eu não mudo a infraestrutura projetada, apenas estendo e evoluo seus componentes.

Para mim o trabalho do arquiteto ou sênior no início de um projeto é exatamente pensar de maneira a projetar algo que seja sustentável a médio/longo prazo mas que seja entregue rápido.

A Solução um Exercício de Visualização

Pessoalmente para agilizar o meu trabalho eu tenho kits, ou pilhas de software que monto em meus estudos e testes. Dessa maneira posso experimentar e harmonizar tecnologias.

Para fazer essa avaliação eu mais uma vez recorro aos desenhos de caixas, procurando visualizar o uso de cada tecnologia na arquitetura que pretendo implementar. Abaixo segue um exemplo:

Trabalhe com o conceito de Kits

Pilhas completas de tecnologias, abaixo seguem alguns exemplos de pilhas (stacks) que gosto de utilizar em meus projetos.

Não incluí bancos de dados, pois aí o buraco é um pouco mais em baixo, pois a sua escolha depende de uma série de fatores não cobertos no tema agilidade, como: modelo de dados e objetivo da base de dados. Falarei sobre isso no futuro.

Estilo arquitetural

• Pense no longo prazo
• Implemente para o curto prazo

O estilo arquitetural fará diferença quando você tiver vários módulos prontos e começar com a manutenção ou evolução, conforme o estilo seja ela, baseada em: SOA, micro serviços , eventos, monolítica, etc. Você terá que lidar com a complexidade e características de cada estilo.

Escolha a mais aderente ao seu ambiente e aplicação a ser desenvolvida

Algumas práticas de ouro a serem consideradas

1. Prepare-se para definições que vem do cliente
2. Regras e comportamentos que vem da sua empresa
3. Limitações e definições do seu projeto

Todo projeto tem que estar aderente a certos padrões, produzir documentos específicos, registrar alguma métrica, não importa. Eu falo um pouco disso no primeiro artigo em fronteira de processos

Você precisa considerar esses elementos para evitar surpresas como auditorias inesperadas, ou pedidos de relatórios que faziam parte da definições e você não sabia.

Sempre descubra tudo o que precisa ser: seguido, produzido ou registrado em cada projeto antes de tentar entregá-lo.

Agilidade

Espero que essa visão de Pessoas,Processos e Tecnologias te ajude na busca de agilidade, são muitas frentes e aqui eu apenas arranhei as 3 que considero importantes.

O caminho não é fácil, mas valerá a pena, em breve vou trazer mais informações sobre como eu trabalho em cada uma dessas áreas de maneira compartilhar o aprendi ao longo de 20 anos trabalhando com computação.

E mais uma vez. É importante estarmos prontos como agilistas para pegar as oportunidades tão logo elas apareçam de maneira a:

Seguirmos na estrada para a agilidade

Que esse artigo sirva de breve referência para os seus estudos em agilidade e melhoria continuada, se você está por aqui já é meio caminho andado, parabéns.

Tags: agile | agilidade | agility | desenvolvimento ágil de software | extremeprogramming | metodos | processos | tecnologia | tecnologias | xp