Há algum tempo, escrevi este texto sobre o Scrum Master ter ou não um perfil técnico. Nele, eu digo que ter esse perfil não te torna melhor ou pior, mas é importante que o “tecniquês” não seja desprezado. Por isso, me comprometi a trazer uma lista de termos técnicos comumente utilizados na área mobile por Devs, QAs, DevOps e Uxers, com uma breve explicação de cada um deles, e agora aqui estamos.

Após essa breve introdução, vamos considerar um daily qualquer de um projeto qualquer, de um time que respira engenharia ágil…

Scrum Master: “E então, vamos começar o Daily?”.

Dev 01: “Eu começo. De ontem pra hoje, eu terminei as alterações na feature de inclusão no carrinho de compras. Já fiz um commit no meu branch local. De hoje pra amanhã, vou realizar mais alguns testes, antes de fazer um merge e um push no branch master. Sem impedimentos”.

Dev 02: “Opa. Minha vez. De ontem pra hoje, eu cobri de testes unitários a pesquisa de produtos. Assim que você fizer o merge no repositório, me avisa que eu vou fazer um pull pra testar um caminho feliz completo. Mas ainda estou fazendo com a API mockada. E também estou impedido pela falta dos assets pra concluir a UI”.

UX: “Estou terminando o flow de cancelamento de pedidos. Vou terminar esses assets e passo pra você, Dev 02”.

QA: “Encontrei alguns bugs nos testes automatizados. Vou cadastrá-los no board e continuarei executando os testes”.

DevOps: “Estou finalizando o desenvolvimento dos scripts de automação do deploy e da integração contínua. Devo continuar trabalhando nisso durante toda a semana. QA, a partir de semana que vem já teremos a Validação Contínua?”.

Scrum Master: “Mais alguém? Algum impedimento?”.

…

Scrum Master: “Até amanhã, pessoal.”

——————————————————————————————————————–

Quantos termos técnicos surgiram em apenas um daily, não é?

Analisando o diálogo, percebemos que o time utiliza o Git para realizar o controle de versões. O Git é uma ferramenta de versionamento de forma distribuída muito utilizada. É importante sempre utilizar um controle de versões para registrar as mudanças no código ao longo do tempo, mesmo que você esteja sozinho. Entretanto, quando dois ou mais desenvolvedores estão trabalhando no mesmo código, esse versionamento se torna essencial. Importante ressaltar que o tipo de versionamento do Git é distribuído, isto é, há um repositório central (“local”, onde ficam armazenados os códigos) e cada desenvolvedor possui uma cópia completa desse repositório. Quer conhecer mais sobre controle de versão (ou versionamento)? Dá uma lida aqui.

Commit, branch, merge, push, pull são comandos do Git, cada um com sua função específica.

Commit é o comando que registra as mudanças. Branch vem do inglês “ramo” e significa as divisões que um repositório pode ter. Merge mescla as alterações dos “branchs”. Push “envia” as alterações para um determinado repositório. Pull obtém as alterações do repositório. Quer saber mais detalhes sobre os comandos do Git? Recomendo dar uma passada aqui.

E sobre APIs? API é um acrônimo para Application Programming Interface, ou seja, Interface de Programação de Aplicação. É um conjunto de instruções e padrões de programação baseado na Web que acessa um aplicativo ou uma plataforma. Por meio das APIs, os devs podem se preocupar mais com suas funcionalidades principais e menos com “acessórios”. Um exemplo? Imagine que sua aplicação necessita obter sua localização para solicitar um serviço X. Sua funcionalidade principal é a solicitação do serviço, mas você pode usar a API pública do Google Maps que já faz todo o tratamento de geolocalização para obter essa informação. As APIs são construídas quando você quer que determinadas rotinas sejam utilizadas por diferentes aplicativos ou que algum processamento esteja no servidor e não no cliente. E o que quer dizer com API mockada? Mock é um termo utilizado para se referir a objetos que simulam o comportamento de objetos reais. Sendo assim, “API mockada” é um termo utilizado para simular o comportamento de uma API real. É muito comum a sua utilização na criação de unidades para testes.

Vamos falar sobre alguns termos de UX (User eXperience ou Experiência do Usuário)? UI é um acrônimo para User Interface, ou Interface do Usuário. E é a camada de interação entre o usuário e a sua aplicação, ou seja, a tela com a qual o usuário interage para completar tarefas. Flow significa fluxo e se refere à maneira com a qual o usuário irá “fluir” ou navegar na aplicação, dependendo, é claro, das features (funcionalidades) e das decisões que tomar ao longo da sua jornada de uso do aplicativo. Assets são os componentes de design incluídos em um aplicativo, como ícones e imagens. Os assets devem ser exportados separadamente – e em diversas resoluções – para que os devs os incluam na UI.

Iniciamos os termos de QA (Quality Assurance, ou seja, nossos guardiões da qualidade), explicando a diferença terminológica entre erro, defeito e falha (bug). Erro é uma ação humana que produz um resultado incorreto. Defeito, também conhecido como bug, é o resultado do erro. E falha é o defeito encontrado.

Ainda sobre qualidade, é importante termos as seguintes definições (que não citamos no nosso daily):

• Casos de uso: é um método para mapear e descrever requisitos e seus comportamentos;
• Casos de teste: é um conjunto de entradas de dados (input), condições de execução e resultados esperados para avaliar os requisitos especificados do sistema;
• Cenários de teste: é a descrição das situações de teste que ajudam o testador no momento da execução dos testes.

Testes automatizados, como o próprio nome sugere, são quando os cenários e casos de testes são automatizados em linguagens de programação para que os testes possam ser realizados com pouca ou nenhuma intervenção humana, ao contrário dos testes manuais, que dependem única e exclusivamente da ação humana para acontecerem.

Chegou a hora do DevOps, aqueles que por meio de seus scripts e ferramentas de automatização nos deixam focar no que realmente é importante. Primeiramente, deploy ou fazer um deployment é instalar a sua aplicação no servidor para que ela possa ser utilizada pelos usuários. Confira este artigo excelente do Thiago Lioy sobre Integração e Deployment (Entrega) Contínuos. Um breve conceito do que há no artigo é a que Integração Contínua (IC) é a integração de partes distintas do código na maior frequência possível, e o Deployment Contínuo (Entrega Contínua) é colocar o “artefato integrado” em produção sempre que houver uma integração. E validação contínua? É executar os testes automatizados continuamente, uma vez que eles já estão escritos e passíveis de serem executados. A Validação Contínua garante que a cada entrega o software seja devidamente validado de acordo com as especificações de testes.

E então, conseguimos ajudar um pouco sobre os termos comumente utilizados em times mobile que, às vezes, podem passar despercebidos por quem não é técnico? Deixe sua opinião aqui embaixo.