Este é o nosso terceiro FAQ (Perguntas e Respostas) sobre Engenharia de Software.
Mensalmente os membros da nossa lista VIP poderão enviar Perguntas que eu mesmo responderei, sobre quaisquer assuntos no campo da Engenharia de Software.
A seguir, as perguntas dos leitores, com as respectivas respostas.
Leitor: Humberto Cardoso
Olá, Plínio!
Minha dúvida está relacionada às opções e caminhos que podem ser trilhados por um profissional full-stack.
Assim, levando em conta o estado da arte atual de desenvolvimento e disponibilização de soluções web/mobile, quais seriam as competências, ferramentas/software e frameworks que uma equipe full-stack de pequeno porte deveria possuir para cobrir de forma profissional todo o ciclo de concepção e entrega dos serviços, abarcando no caso as temáticas de projeto, requisitos, front-end/UX, back-end, mapeamento objeto-relacional, banco de dados, testes/qualidade, versionamento e integração contínua em um ambiente residente inteiramente na nuvem e em software livre?
Abç,
Humberto Cardoso
/* Abaixo meus comentários. */
Olá Humberto!
Sua pergunta é uma pergunta difícil, pois se eu tentar respondê-la para abordar todos os possíveis “if’s”, ficará muito extensa (mesmo assim ficou um pouco, rs), e ainda poderá não lhe atender. Mas vou tentar passar minha visão macro a respeito. Imagino que poderá ajudá-lo.
O conceito de profissional Full-Stack é algo relativamente novo.
Antigamente (quando meus cabelos ainda eram pretos), os profissionais eram mais especializados, os papéis eram melhor definidos. Recentemente (alguns poucos anos atrás) o mercado começou a demandar um profissional que conhece “toda a pilha” (por isso o termo full-stack), sendo fluente em Front End, Back End, Banco de Dados, e mais recentemente ainda, infra-estrutura (leia-se “DevOps”).
Considera-se ainda que, além de projeto, construção e configurações, tal profissional para ser “full-stack mesmo” tem que ser bom em concepção (requisitos), comportamento (estórias, casos de uso etc.), design (uml, orientação a objetos) etc., programação (lógica, linguagem, padrões) modelos de processo (ágil e tradicional), técnicas de produção (entrega contínua, versionamento) etc.
Eu realmente acho super difícil um profissional ser bom em tudo isso. Acho até impossível. Mas é apenas uma opinião… ;(
Bom, considero possível o seguinte contexto (macro): Noções de Modelagem/Projeto, fluência em Front-End (HTML5 + CSS3 + JS), fluência em Back-End (um “mundo apenas” – PHP, Java, .Net) e fluência em programação para banco (um banco apenas ex: Oracle). Algo nessa linha acho possível, mas o profissional tem que ser Hércules, mesmo assim.
Em tal conexto, detalhando um pouco (micro), acho fundamental:
1 – Noções de Modelagem/Projeto: saber ler/interpretar bem, e conhecer muito bem, requisitos de software. Não precisa ser o “super Analista de Negócios”, mas em nossa área o maior problema dos projetos chama-se “escopo”. E resolve-se muito disso com uma boa Engenharia de Requisitos. Ainda, ter um conhecimento intermediário em Orientação a Objetos e visão intermediária de arquitetura (entender o que são APIs, camadas, no minimo protocolo HTTP, SOAP, padrão RESTful etc).
2 – Front-End (HTML5 + CSS3 + JS): saber ler/interpretar bem, e conhecer muito bem HTML/CSS/JS. Muitos profissionais acham que não precisa disso, pois como hoje tudo fica encapsulado em frameworks (por exemplo, Bootstrap e JQuery), basta conhecer as classes dos frameworks que está tudo resolvido. Não precisa ser papa em Java Script, penso eu, mas é importante não ficar na mão do JQuery quando for necessário fazer alguma extensão nele, por exemplo.
3 – Back-End (um “mundo apenas” – PHP, Java, .Net): vez ou outra surgem algumas vagas pedindo fluência em .Net e Java por exemplo, ou ser “o cara” em Xamarim, Ionic e Android Studio. Sintaxe é o menor dos problemas, mas cada “mundo deste” possui uma infinidade de coisas diferentes. Acho que o profissional, neste contexto, deve se especializar em apenas “um mundo”, e se necessário, “passear” por outros quando necessário.
4 – Banco de Dados: focar apenas no nível programação. Infra-estrutura para banco de dados, em nível avançado, é algo que demanda às vezes uma carreira inteira. Mas até mesmo na programação, não dá para ser ótimo em PL/SQL e Transact/SQL, salvo se for DBA. Acho que neste contexto, como varia muito as opções de banco de dados (excluindo os No-SQL), o profissional deve ser um conhecimento que o dê condições de ler triggers, procedures etc., dar manutenção e coisas do tipo. Ainda, ter boas noções de ORM – neste caso, dá para “estudar menos” a parte direta no banco, em função da abstração do mecanismo.
5 – Qualidade: penso que neste caso, apenas noções para a maioria dos conceitos é necessário. Compreender ao menos conceitualmente testes de caixa-branca, caixa-preta, exploratórios, regressão etc. E no nível mais “programação”, entender bem sobre Testes Unitários, mas sem se apegar ao framework usado (solução não passa pela tecnologia, em muitos casos, e conceitualmente um teste unitário é a mesma coisa independente do ambiente/tecnologia).
Mas é importante considerar o gosto do profissional e as tendências de mercado. Não adianta um profissional não gostar de uma tecnologia e focar nela, ou gostar muito de uma outra, mas o mercado não oferecer boas oportunidades.
Lembrar ainda da Síndrome do Pato: ele nada, voa e anda, mas não faz nada disso direito. E como consequência, rola uma frustração que nem sempre é legal. Eu e vários colegas já nos frustramos muito por “não ser bom em tudo”, quando o assunto é desenvolvimento de software.
Leitor: Lucas
Olá,
Minha empresa persiste em não contratar pessoal para a área de teste. Contudo, obviamente meus chefes esperam ótima qualidade na entrega do produto. Já tentamos TDD e alguns testes automáticos, mas o principal são as regras de negócio. Muitas vezes essas regras de negócio funcionam entre sistemas de linguagens diferentes. Não sei como automatizar tudo isso. Faço parte de uma equipe de 5 desenvolvedores, mas que atuam em projetos diferentes. O que posso fazer para melhorar essa etapa do desenvolvimento?
Lucas.
/* Abaixo meus comentários. */
Olá Lucas!
Seu cenário é mais comum do que pensa. Infelizmente, poucos recursos, e grandes resultados… ;(
Algumas soluções tem disso: arquitetura muito heterogênea, caixas preta (ou branca, mas fragmentada demais), e informações trafegando em “todas as caixas”. Vou lhe sugerir três possibilidades:
1 – Acho que pode pensar sobre uso de Proxy, Gateway etc. entre os sistemas, e focar em fazer testes unitários para eles. Mas mesmo assim, não deve ser possível. Mas acho que pode fazer “programinhas” que processam a informação, com as dependências de cada sistema acopladas a ele. Uma espécie de emulador. Então, você pode criar testes unitários para este emulador, amarrando nos métodos das classes dele.
2 – Imagino que ao menos um Front-End principal exista, ou seja, um local onde a transação começa. Neste caso, vocês podem avaliar a gravação de testes funcionais, onde de maneira automática, posterior à gravação, você consegue validar ponta a ponta, conforme as entradas inputadas e saídas geradas. Não é no nível unitário, mas dá uma visão global da solução.
3 – Crie um modelo de dados (pode-se utilizar views, por exemplo) onde se tem uma concentração das entradas e saídas das tabelas dos bancos, conforme o processamento ponta a ponta. Para analisar os resultados, o olhar estaria sobre tal modelo.
Mas se quiser me dar maiores detalhes (nos comentários deste post), de repente posso ser mais pontual na resposta.
Leitor: Débora Ribeiro
Olá Plínio. Bom dia
A minha dúvida é sobre a diferença entre o fluxo alternativo e o fluxo de exceção? Já ouvi de um professor que o fluxo de exceção não altera pós condição. O que você acha disso?
Obrigada
Débora Ribeiro
/* Abaixo meus comentários. */
Olá Débora!
O conceito de pós-condição em casos de uso, na minha opinião, é muito pouco relevante pelo valor que gera no modelo.
Todavia, é fundamental saber que, todos os fluxos (principal, alternativo e de exceção) podem sim alterar o comportamento do final do caso de uso.
Talvez o que ele quis dizer foi que, apenas se o caso de uso for bem sucedido (fluxo principal ou algum alternativo bem sucedidos) é que a pós-condição será atendida, e no caso do fluxo de exceção, por não chegar “até o fim”, não haveria impacto pois a pós-condição não seria atendida.
Mas sugiro que baixe nosso eBook sobre Casos de Uso, de repente poderá lhe ajudar neste sentido.
Leitor: Rômulo Monte
Bom dia Plinio,
sou designer por formação e fã de engenharia de software.Até paguei algumas matérias da pós de engenharia de software.
A questão que sempre me deparo é qual a melhor linha para documentar de forma mais completa
possível um software, levando em consideração que irá servir para o seu desenvolvimento e os stakeholders?Grato pela atenção e curto muito seu trabalho, parabéns.
Atenciosamente,
Rômulo Monte
/* Abaixo meus comentários. */
Olá Rômulo!
Obrigado! Que legal que gosta de Engenharia de Software, é uma área onde a criação ocorre a todo momento.
Sua pergunta dá margem a respostas diversas, vou tentar sintetizar.
A melhor linha a ser seguida para documentar de forma mais completa e possível um software, sempre será aquela em que o escopo fica o mais claro possível para todos os envolvidos. Isso é um aspecto mais comportamental que técnico, na maioria dos casos.
De nada adianta um mestre em Engenharia de Requisitos não ter o senso crítico, lógica e cuidado necessários.
Produzirá uma especificação bela, mas que não reflete o que deve ser feito. O inverso também se aplica. Alguém que tenha excelente raciocínio, compromisso, lógica etc. que não tenha um bom domínio da técnica a ser aplicada para materializar o que passa em sua cabeça.
O bom profissional de especificação deve dominar bem a técnica, e saber “pensar software”. O maior problema em todos os projetos de software não é de tecnologia, e sim de escopo e gestão. Sugiro que reflita sobre o Cone da Incerteza para entender melhor isso.
Leitor: Waldiney Guerra
Olá Plínio.
Pergunta:
Na utilização do Scrum com respeito as sprints. Qual a melhor forma de se dividir as tarefas de uma sprint? Visto que muitas equipes contam com profissionais multi disciplinares e outras não. Na entrega de uma sprint as suas tarefas devem ser norteadas pelo conceito de pronto?
Waldiney Guerra
/* Abaixo meus comentários. */
Olá Waldiney!
Teoricamente, a cada Sprint deve ser gerado incremento de software materializado, e a definição de pronto precisa estar amarrada em software materializado. Mas nem sempre isso é possível.
Existem empresas que criam, no início do projeto, Sprints de especificação, para que apenas depois de um entendimento viável para se ter um MVP, iniciar-se um Sprint que contemple o ciclo completo de produção, e então, viabiliza-se software materializado.
Já vi casos onde chama-se isso de “Sprint 0”, e o time-box deste Sprint varia dos demais, pois fica amarrado ao tempo necessário para se elucidar o escopo para poder pensar no MVP do Sprint 1.
Sobre a divisão de tarefas, no contexto que apresentou, é um pouco de “sinunca de bico”. Teoricamente (também), um time Scrum tende a profissionais multidisciplinares. Mas sabemos que nem sempre isso é realidade.
Vamos pensar que o principal input para um Sprint são os itens do Product Backlog, selecionados para serem feitos. A saída do Sprint espera-se que sejam estes itens prontos, materializados em incrementos de software (dentro do acordado de definição de pronto). Então penso que, em princípio, esse deve ser o norte.
Porém, para se produzir um item de backlog é necessário quebrar em Work Itens, Tasks etc. Tem item de backlog que às vezes é um Epic, por exemplo.
Sendo assim, acho que você pode sempre considerar o item (feature) como entrega a ser perseguida, mas quebrar isso em pedaços menores, e assim, planejar o trabalho dos profissionais conforme a especialização de cada um. Por exemplo:
– Item: tela de pagamento
– Tarefas: 1) Layout da Tela 2) Lógica de Negócio/Banco 3) Teste Funcional
Se tem um profissional que faz as três coisas, ele pode absorver tudo. Se tem três profissionais, um com cada perfil, então passa cada tarefa para cada um, e tome cuidado com o caminho crítico e time-box.
Se quiser debater mais a respeito, para eu poder ser mais pontual, deixe nos comentários para avançarmos.
Leitor: Roselle Matos
Olá, tudo bem?
Segue minha dúvida:
Trabalho com um produto pronto, ou seja, um software pronto que não realiza customizações para clientes, porém usamos um canal de ideias para democratizar as novas demandas de funcionalidades e entender de forma facilitada quais são as necessidades dos nossos clientes, já que são muitos e das mais diversas áreas. Além da viabilidade técnica e alinhamento com o negócio, usamos como base a votação dos clientes nas ideias. A análise de requisitos nesta área é bem trabalhosa, pois recebe-se dezenas de ideias semanalmente. Há alguma técnica, framework, etc que possa tratar esta área? Não localizo material, artigos ou livros que tragam respostas boas sobre esta modalidade de trabalho, percebo que é algo novo para o mercado de ERPs.
/* Abaixo meus comentários. */
Olá Roselle!
Se entendi bem o seu contexto, é semelhante a algo que já vivi, numa empresa de ERP.
Eu sugiro pensar em duas linhas: 1) Priorização 2) Esboço x Detalhamento.
Sem priorização não tem como ser feliz neste tipo contexto. A priorização sempre deve ser baseada naquilo que gera mais valor para o negócio, e que equaliza bem custo x benefício.
Clientes sempre querem tudo, em prazos geralmente inábeis, e querem pagar pouco, e ainda reclamam no final (não sou uma pessoa negativa, mas a realidade é bem essa).
Por exemplo: ha partir deste grupo de foco, votação etc. vocês chegaram a 10 itens. Primeira coisa é organizar cada necessidade (se na sua empresa rodar Ágil, você pode classificar isso como um Épico, se for algo mais tradicional, uma “Onda” [leia sobre Ondas Sucessivas]).
Segunda coisa é priorizar, com o que se tem (sem fazer análise de requisitos ainda).
Após priorizar, para o item da vez, (ainda sem requisitos) você pode fazer uma estimativa em algo nível (em Pontos de Função seria uma métrica estimada, em agilidade, pode-se usar um Planning Poker, ou então, apenas a opinião de especialista mesmo).
Depois que separar em itens, pegar o priorizado da vez e estimá-lo em alto nível, então, fazer nova avaliação para saber se vai ser feito mesmo, e se a prioridade não muda. Se mudar, reordena a fila. Se não mudar, somente então, inicia-se a especificação dos requisitos.
Muita gente tem problemas em contextos semelhantes, pois antes de saber o tamanho/custo do desafio, já se vai trabalhando nele, e mais à frente, se mostra um problema pois começam as frustrações de tempo, prazo, esforço custo etc.
Espero ter ajudado, e caso queira falar mais, fico à disposição nos comentários!
Finalizando
Agradecimentos sinceros aos leitores que enviaram suas perguntas! 🙂
Lembrando que não é possível esgotar muitas das questões aqui, pela amplitude destas. E que, ainda, trata-se da minha opinião, que pode ser revista à medida que vou me tornando menos ignorante.
Em breve o próximo FAQ, e faça parte da nossa lista VIP para enviar suas perguntas que estamos à disposição!
Grande abraço!