Ontem fui buscar novas oportunidades de emprego, já que concluí meu estágio, e estou somente cumprindo contrato por enquanto.
Diante disse parei pra pensar nos meus conhecimentos, e nas exigências do mercado de trabalho, não somente nos conhecimentos técnicos, mas também nos conhecimentos gerais, como por exemplo, contabilidade, compra e venda, faturamento, gestão de negócios, dentre outros.
Nisso fiquei pensando em uma coisa específica: A REGRA DE NEGÓCIOS
Dei uma lida sobre o assunto, e até entendi o que é, mas fiquei com dificuldade pra imaginar formas de trazer isso pro nosso mundo, sendo assim, alguém que conheça mais sobre pode explicar o que é do seu ponto de pista e citar exemplos explícitos de aplicação na T.I?
Você foi contratado para criar um sistema que será responsável por gerenciar uma fábrica de móveis.
O objetivo principal da construção do sistema é diminuir o desperdício e melhorar o aproveitamento da mão de obra e das matérias primas.
Acontece que você não sabe nada de marcenaria.
Como você faria para desenvolver o sistema?
As regras de negócio são parte fundamental do processo de desenvolvimento/manutenção de sistemas. Elas podem ter natureza interna ou externa e serão identificadas a partir do levantamento dos requisitos.
As regras de negócio internas contemplam situações como “o usuário precisa estar logado e ter perfil administrador para acessar esta funcionalidade”, ou seja, dependem, exclusivamente de uma definição estipulada pelo cliente.
As regras de negócio externas contemplam situações como “de acordo com o código civil brasileiro, artigo X, parágrafo Y…”, ou seja, devem atentar à fatos legais, como legislação municipal, estadual ou federal (principalmente em sistemas que serão auditados para que possam ser comercializados ou utilizados).
O que diferencia uma regra de negócio de um simples requisito? É a regra de negócio que vai definir limites, em geral.
Eu costumo dizer que devemos construir o sistema sem aplicar nenhuma regra de negócio e, para finalizá-lo, vamos, uma a uma, implementando as regras.
Em abordagens de desenvolvimento voltadas a testes (como TDD e BDD), as regras são identificadas e serão utilizadas como markups nos testes. Um sistema só está apto a ser homologado (e, consequentemente, posto em produção) a partir do momento que atende a todas as regras de negócios.
@AbelBueno, tirei de uma coisa chamada experiência.
Mas, me explica, como que um sistema que não atende a regras de negócio pode ser homologado?
Um sistema de rastreamento de veículos, cuja principal regra de negócios é identificar a posição do veículo, minuto a minuto. Como (e por quê) colocar em produção um sistema que não atende esta regra?
Pensei que estava citando alguma documentaçao ou filosofia de um processo.
Veja bem que você mesmo deu a dica de como isso pode acontecer na sua pergunta “cuja principal regra de negócios é identificar a posição do veículo”.
Assim que um sistema pode entregar valor a usuário, ele pode ir pra produçao. Você implementa as principais primeiro, monitora como se comportam em producao, recebe feedback dos usuários, etc e parte para a próxima.
É um dos principios ágeis, software funcionando o mais breve possível.
Se eu entendi direito, teu raciocínio significa que, mesmo que eu não consiga apresentar o veículo do cliente no sistema, está tudo certo, pois atendi o que ele pediu?
Mesmo em metodologias ágeis temos que ter qualidade e, mais do que um código bonito, qualidade é atender ao que o cliente comprou (nem tudo o que ele comprou são regras de negócio).
Nao, nao acho que me entendeu direito. Nem estou entrando no mérito de qualidade de código aqui.
A parte principal do que eu disse foi: “Assim que um sistema pode entregar valor a usuário, ele pode ir pra produçao”
E o que eu quero dizer com isso? Vamos dizer que a idéia final desse sistema seja monitorar em tempo real a posiçao do veículo, descartando veículos com modelos antes do ano 2000 ( e você consegue essa informaçao usando a API do Detran) e que você possa traçar a rota do últimos 50KM ou 30 minutos andados no mapa.
Estou aqui inventando coisas que tal sistema poderia fazer.
Enquanto o produto final fica super legal, você pode por em produçao na primeira semana, uma tela que só apresenta a coordenada do veículo. Talvez isso já ajude o usuário, com seja lá o que ele precise fazer com essa informaçao. Enquanto você trabalha pra integrar com o Detran, o cliente te fala que há um bug que o sistema nao funciona em certos lugares (como túneis). Daí você decide com ele se o próximo passo é integrar com o Detran ou fazer funcionar em todo lugar? Talvez para isso precise de outro dispositivo de gps, sei lá.
A questao aqui é que o usuário já consegue ter uma noçao do que o sistema vai ser e encontrar problemas nele. E claro, já ter o benefício de uma versao simplificada, enquanto você vai terminando o resto.
Nao tem porque você esperar 1 mês inteiro pra implementar as idéias iniciais e só depois mostrar pro cliente o que foi feito.
Desculpe, @AbelBueno, estou falando sobre um tema do qual eu tenho pleno conhecimento que é o mercado de rastreamento de veículos, por trabalhar numa empresa que faz monitoramento de veículos (entre outros).
Logo, o que estou dizendo é que o cliente pode até “achar engraçadinho” ver uma tela onde vai aparecer um mapa e seus veículos, mas, isso para ele é igual a nada.
Agregar valor ao cliente é uma questão que se refere a: 1 - público a ser atingido, 2 - tipo de contrato que você está mantendo com o cliente.
Eu entendi o teu ponto de vista, mas, estamos trabalhando em realidades muito diversas.
Outro ponto super importante é que, falando em termos de metodologias ágeis, não existe mais a figura da especificação de casos de uso, mas, a história a ser desenvolvida na sprint. Essa história, em geral, mostra o cenário atual e desenha o cenário requerido, aquele que existirá quando a sprint for finalizada.
Esta história vai nortear o desenvolvimento, detalhando requisitos e regras a serem atendidas.
Esta mesma história irá definir como os casos de testes serão escritos (independente de utilizarmos ou não coisas como TDD ou BDD).
Estou falando tudo isso pois é a realidade que vivo aqui. Entendo que pode ser uma experiência específica, mas, é a que conheço.
O que quero dizer é que não importa se a metodologia é ágil ou seguirá o modelo cascata: desenvolver um sistema sempre terá suas peculiaridades, suas regras de negócio, seus requisitos. O que cada empresa, gestor e programador faz com isso é que vai mudar.
Estamos sim, em partes. Eu apenas defendo que a entrega parcial sempre entregará alguma coisa. E esta coisa a ser entregue foi aprovada, validada, recebeu um ok, foi homologada, etc. Dificilmente é, apenas, um esboço.
Meus 2 cents à thread que já conta com excelentes pontos de vista: acho que você não deveria se preocupar com todas as exigências do mercado em conhecimentos gerais de regras de negócio. Se preocupe, além de sempre evoluir tecnicamente, em conseguir entender um problema, uma regra de negócio.
Acho mais eficiente entender um problema real para depois pensar numa solução técnica, mesmo não sabendo tanta coisa tecnicamente, do que saber muita coisa do lado técnico e depois ter dificuldade pra entender uma regra de negócio, requisito, ou coisa assim. Claro que, conseguindo com o tempo unir as duas capacidades, melhor
Como trazer uma regra de negócio pro nosso “mundo”? Entendo que poderia ser assim: você precisa desenvolver um jogo de luta onde os jogadores jogam dados, um de cada vez, sendo que a diferença entre os dados é o dano causado pelo atacante ao defensor. Perde quem chegar a 0 primeiro.
Isso sendo o teu “produto” em questão, claramente pode-se dividir em diversas “estórias” a fim de priorizá-las e finalmente entregar teu jogo pronto. A grosso modo, e isso não é verdade absoluta, sendo muito relativo de acordo com a experiência da pessoa/equipe e também do cliente, eu poderia elencar alguns steps a seguir:
Uma sequência de perguntas podem ser feitas
As respostas das perguntas vão gerar uma lista de coisas a serem desenvolvidas
Para essas coisas a serem desenvolvidas, pode-se escrever algumas asserções que vão garantir que o comportamento vai ter o resultado esperado (testes)
Implementar/desenvolver de modo a fazer as asserções (testes) serem cumpridos
Entregar e validar com o requisitante
O processo todo pode ser repetido se for necessário, e desde que isso seja feito o mais cedo possível, com certeza haverá economia de recursos. Cada step também pode ser iterativo, ou seja, não precisa necessariamente fazer um após o outro de forma serial, mas pode-se voltar steps para trás e depois andar novamente.
