├── src ├── assets │ ├── css │ │ └── main.css │ └── js │ │ └── main.js └── index.html └── README.MD /src/assets/css/main.css: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /src/assets/js/main.js: -------------------------------------------------------------------------------- 1 | // Este será o objeto principal no qual você irá se basear para as funções do desafio! 2 | // Caso haja dúvidas de como prosseguir, favor consultar a sala #js no nosso discord! 3 | let features = [ 4 | { 5 | feature: "Authentication", 6 | devHours: 10, 7 | testHours: 2 8 | } 9 | ]; 10 | 11 | alert("He4rtDevs <3"); 12 | 13 | // Dica: faça o layout e depois pense em como vai funcionar o script. 14 | -------------------------------------------------------------------------------- /src/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | He4rtLabsChallenges 7 | 8 | 9 | 10 | 14 |
He4rtLabsChallenges #2
15 | 16 | 17 | 18 | -------------------------------------------------------------------------------- /README.MD: -------------------------------------------------------------------------------- 1 | # Projeto 002 - Planilha de cotação para Freelas (2/2) 2 | 3 | Uma planilha com a cotação de todo o projeto a ser desenvolvido para melhor visualização do cliente. 4 | 5 | ## Qual é o valor que o desafio entrega? 6 | 7 | Quando você vai cotar um freelance, não adianta saber apenas o quanto vale a sua hora mas sim quantas horas você vai gastar fazendo cada uma das funcionalidades. Mas nem tudo no projeto é desenvolvimento e é sobre isso que devemos entender neste desafio. 8 | 9 | Em qualquer tipo de projeto que envolve um software, desenvolver é o principal fator determinante para a conclusão do projeto. Porém é bem comum não cobrir **testes de aceitação** pois isso custa **tempo** e agora sabemos que o nosso tempo tem algum valor, certo?! 10 | 11 | A ideia é desenvolver uma "planilha" na qual irá ser focada em cotar o trabalho como um todo, baseando-se em **horas de desenvolvimento e testes** de cada **funcionalidade**. 12 | 13 | Pense em um formulário onde você deverá preencher os seguintes campos: 14 | 15 | 1. Nome da funcionalidade 16 | 17 | Um nome simples e objetivo do que deverá ser desenvolvido, para um fácil entendimento principalmente do **cliente**. 18 | 19 | Exemplo: Autenticação de Usuários 20 | 21 | 2. Horas de Desenvolvimento 22 | 23 | Entenda esse campo como a quantidade de horas que você julga para a feature como um todo. Após ter esse valor já definido na sua funcionalidade, dentro do seu projeto deverá ser quebrado tarefas que contemplem essas horas. O exemplo abaixo é apenas para entendimento de como ficaria num projeto real. 24 | 25 | Exemplo: Autenticação de usuários, 10 horas. 26 | 27 | - Tarefa 1: Estruturação do banco de dados -> 2 horas 28 | - Tarefa 2: Desenvolvimento do Front-end -> 5 horas 29 | - Tarefa 3: Desenvolvimento do Back-end -> 3 horas 30 | 31 | 3. Horas de Teste 32 | 33 | Testes são na maior parte do tempo priorizados apenas no back-end, onde de fato é onde deve tudo funcionar. Porém testes devem cobrir muito mais do que apenas o **caminho feliz** e muito desses caminhos infelizes são descobertos à partir de testes no front-end. Então é de suma importância reservar horas especificas para testar e ter principalmente um **roteiro de testes** AKA. BDD (Behavior Driven Development). 34 | 35 | 4. Valor da funcionalidade 36 | 37 | Deverá ser gerado baseado no **valor da sua hora** multiplicado pelos valores somados das horas de desenvolvimento e testes para melhor visualização do cliente. 38 | 39 | A ideia do desafio é mostrar que para cotar um projeto, é necessário um pouco mais de cuidado para o que você está passando pro cliente e que ambas as partes estejam sempre alinhadas sobre o que está acordado. 40 | 41 | ## Desafio 42 | 43 | Wireframe: https://wireframe.cc/pro/pp/115e33462323006 44 | 45 | * Crie um fork deste repositório e trabalhe os arquivos da pasta "src". 46 | * Crie uma pagina usando o conceito do wireframe acima com os seguintes elementos: 47 | 48 | - Header 49 | 1. Logo da He4rt Developers 50 | 2. Nome do Projeto 51 | - Barra de ações 52 | 53 | 1. Inserir (Registro) 54 | - Ao clicar nesse botão, deverá aparecer o formulário/modal com os elementos descritos para o preenchimento dos campos: Funcionalidade, Horas de Desenvolvimento e Horas de Teste. 55 | 2. Remover (Registro) 56 | - Ao clicar nesse botão, deverá haver algum tipo de seleção do campo que você deseja apagar. 57 | 3. Importar (Registros) 58 | 59 | - Acione um input do tipo file e faça o upload de um arquivo de registros ao clicar no botão importar. 60 | - Deverá ser aceito um arquivo **json** com registros padronizados e esses mesmos registros devem sobrescrever os que já estão na tabela. O exemplo abaixo deverá ser usado como critério de aceite, sendo ele passado para um arquivo features.json. 61 | 62 | ```json 63 | [ 64 | { 65 | "feature": "Authentication", 66 | "devHours": 10, 67 | "testHours": 2 68 | }, 69 | { 70 | "feature": "User CRUD", 71 | "devHours": 14, 72 | "testHours": 3 73 | }, 74 | { 75 | "feature": "User CRUD", 76 | "devHours": 14, 77 | "testHours": 3 78 | } 79 | ] 80 | ``` 81 | 82 | - Caso não siga o padrão do json acima, deverá retornar um erro para o usuário invalidando o processo. 83 | 84 | 4. Exportar (Registros) 85 | - Ao clicar no botão de exportar, deve ser gerado um arquivo **features.json** com todos os dados que estão na área de funcionalidades. 86 | - O modelo deve seguir o mesmo padrão do exemplo abaixo: 87 | ```json 88 | [ 89 | { 90 | "feature": "string", 91 | "devHours": 0, 92 | "testHours": 0 93 | }, 94 | ... 95 | ] 96 | ``` 97 | 98 | - Valor Hora 99 | 100 | 1. Deverá ter um input com o valor (decimal) da sua hora. 101 | 102 | - Lista de Funcionalidades 103 | 104 | 1. Deverá ser feito em um tipo de lista (cards, tabelas etc) com os elementos do formulário. 105 | 2. Deverá ter um atributo que será o calculo dos valores referentes a funcionalidade, sendo o calculo: 106 | 107 | ```text 108 | valorFeature = valorHora * ( horasDev + horasTeste) 109 | ``` 110 | 111 | 3. As colunas finais serão: Funcionalidade, Horas Dev, Horas Teste, Valor 112 | 113 | - Sidebar 114 | 115 | 1. Deverá ter um contador de quantas funcionalidades estão sendo feitas 116 | 2. Deverá ter um contador de Horas de Desenvolvimento do projeto 117 | 3. Deverá ter um contador de Horas de Teste do projeto 118 | 4. Deverá ter uma somatória dos valores de todas as features como um valor total do PROJETO. 119 | 120 | - Rodapé (Footer) 121 | 1. Colocar links referentes as suas redes sociais e uma referencia a He4rtLabsChallenges. 122 | 123 | Cuidados a se tomar: 124 | 125 | - Todas as ações que forem tomadas, deverão ter algum retorno. Não serão aceito botões que não executam sem um retorno prévio pro usuário. 126 | - Pense nessa lista de funcionalidades como um **objeto**. 127 | 128 | ### Comentários 129 | 130 | O template passado no wireframe é OPCIONAL. Logo, você pode sim fazer algo no seu estilo porém devem ter os mesmos elementos descritos no desafio. Caso vocẽ faça um wireframe diferente que possa agregar no desafio, abra um pull request para que possamos avaliar. 131 | 132 | A ideia é criar um objeto principal onde será armazenado todos os valores e refletir os mesmos na sua lista de funcionalidades e também nas ações de importar e exportar. 133 | 134 | Os arquivos iniciais da pagina estarão com alguns comentários sobre 135 | 136 | ### Conclusão do Desafio 137 | 138 | Commite as alterações feitas e faça um post ou no nosso Discord na sala `#he4rtlabs-challenges` ou um post no Twitter com a hashtag `#He4rtLabsChallenges` e iremos divulgar e/ou fazer um review do seu código. 139 | 140 | Caso você se sinta confortável, deixamos um arquivo chamado REVIEW.MD para você fazer alguns comentários sobre o desafio e o que você achou no geral. 141 | 142 | ## Créditos 143 | 144 | Este desafio foi desenvolvido pelo grupo [He4rt Developers](https://heartdevs.com) para uso livre da comunidade. 145 | 146 | ## Autor 147 | 148 | - Daniel Reis (danielhe4rt) - Back-end Developer && He4rt Developers Leader - [Portfólio](https://danielheart.dev) - [Twitter](https://twitter.com/danielhe4rt) 149 | --------------------------------------------------------------------------------