Gerência de projetos
Last updated
Last updated
O gerente de um projeto possui funções essenciais à qualidade de vida de um projeto, como a criação do projeto em si, a gerência das sprints do projeto e a comunicação dos detalhes do projeto para os outros membros de equipe nas reuniões gerais. Em suma, o gerente do projeto conduz a execução do projeto, tomando as medidas necessárias para que seu desenvolvimento seja bem sucedido.
Está pagina contém as informações necessárias para se gerenciar um projeto de maneira adequada.
O primeiro passo em um projeto de software consiste na criação e configuração do repositório em que o projeto será desenvolvido. Isso inclui criar o repositório do projeto, as estruturas de pastas para abrigar o código fonte e outros recursos e configurar adequadamente os arquivos de controle de versão, os arquivos de documentação do projeto, a utilização de bibliotecas externas (gems), e o banco de dados do projeto.
Embora isso pareça ser muita coisa, iremos detalhar melhor cada passo nas seções abaixo.
O primeiro passo na inicialização do projeto é a criação do projeto na framework Ruby on Rails. Para isso, vamos escolher, utilizando o RVM ou Rbenv, uma versão de Ruby esteja um minor release atrás da última versão (ou seja, se a última versão de Ruby é a 2.x, utilize a versão 2.x-1 para o projeto). Na dúvida, utilize a versão de Ruby utilizada no último projeto. Isso evita que tenhamos que lidar com os bugs inerentes à versão mais nova do Ruby e das gems que o acompanham. Caso algum dos membros do projeto não tenha um gerenciador de versão de Ruby instalado (como RVM e Rbenv), ajude ele com a instalação (esse tipo de software é praticamente essecial para se trabalhar em vários projetos, cada um com uma versão diferente de Ruby).
Após escolher a versão de Ruby desejada, será necessário realizar a instalação de algumas gems (que são as bibliotecas do Ruby). Para instalar uma gem, basta rodar o comando gem install nome_da_gem. Com isso em mente, instale as gems rails (framework de desenvolvimento de websites e serviços web), mysql2 e pg (gems para o MySQL e PostgreSQL respectivamente, os sistemas gerenciadores de bancos de dados, ou SGBDs, mais utilizados). Além dessas gems, será necessário instalar os SGBDs MySQL e PostgreSQL em seu sistema operacional (assunto que não será coberto nessa página).
Após instalar as gems e os SGBDs em seu computador, caberá a você, como gerente de projetos, decidir qual SGBD utilizar no projeto. O MySQL é mais amigável para iniciantes e possui uma melhor forma de visualizar e manipular diretamente o banco de dados, mas requer mais tempo para ser configurado e a utilização de uma gem (figaro) para gerenciar os credenciais de login. Já o PostgreSQL pode ser utilizado com quase nenhuma configuração adicional, mas possui uma instalação mais complicada e não permite que o usuário manipule o banco de dados com facilidade. Caso seja sua primeira vez gerenciando um projeto, fale com o diretor de projetos ou com um membro mais experiente para pedir uma recomendação (eu, pessoalmente, recomendaria o MySQL).
Após escolher o SGBD a ser utilizado, chegou a hora de criar o projeto. Para isso, rode o comando rails new nome_do_projeto_em_snake_case -d {mysql | postgresql}, escolhendo o último argumento para coincidir com o SGBD desejado. O framework cuidará da criação de pastas e arquivos para o desenvolvimento do projeto.
Caso você tenha escolhido o MySQL, configure a gem figaro para gerenciar credenciais e, caso você não queira utilizar o usuário root no projeto, crie as tabelas de desenvolvimento e testes e um usuário com permissão de acesso a elas. Caso você tenha escolhido o PostgreSQL, preencha o arquivo config/database.yml com os credenciais do SGBD (em sistemas operacionais com o kernel Linux, você pode preencher apenas o seu nome de usuário e apagar o campo de senha caso você tenha optado, na instalação do PostgreSQL, por utilizar sua conta de usuário do sistema operacional como um usuário do SGBD).
Por fim, tente executar o projeto utilizando o comando rails s. Caso a execução do projeto não gere alguma mensagem de erro, adicione todos os arquivos gerados ao controle de versão sob o nome 'Commit inicial'. Caso contrário, corrija os erros do projeto antes de realizar o commit inicial.
A criação do repositório para o projeto deve ser feita no grupo da Struct do GitLab. O nome do repositório geralmente segue o padrão projeto_nome ou projeto_codinome (como gerente de projeto, sinta-se livre para criar um codinome épico para o projeto ). Configure o repositório como privado e não inicialize ele com um README, pois o Rails já gera esse arquivo para você. Após criar o repositório, faça o upload dos arquivos gerados pelo projeto de Rails para o repositório.
Após a criação do repositório, você deverá fazer um segundo commit na branch main que faça todas as configurações necessárias no projeto. Esse segundo commit deve colocar no README informações básicas do projeto, colocar no projeto arquivos padrão que devem estar presentes em qualquer projeto da Struct e configurar as gems que o projeto irá utilizar. Mais detalhes são fornecidos nas subseções abaixo. Após executar todos os passos de cada subseção, realize um commit com o nome "Estrutura inicial" adicionando as mudanças que você fez.
O README deve conter as dependências do projeto (versão do Ruby, banco de dados, etc...) e os dados do projeto em si, os quais incluem a especificação do projeto (bem resumida, em uma única frase), o codinome do projeto (se existir), a data de assinatura do contrato, o prazo de desenvolvimento do projeto e a data prevista de entrega do projeto.
Não utilize o README como uma lista de tarefas, pois isso pode ser feito por meio de issues.
No momento, existem 2 arquivos padrão que devem estar presentes no projeto: o .gitignore e o script start.sh.
Arquivo .gitignore
Como sabemos, o .gitignore é utilizado para impedir que arquivos locais sejam acidentalmente adicionados ao repositório. Arquivos que geralmente devem ser ignorados incluem arquivos de configurações pessoais (.bundle, .vscode, .idea, .DS_store), pastas de caches (tmp e storage), logs (arquivos *.log e pasta log) e módulos do node js (a pasta node_modules).
Nunca coloque arquivos que afetam o desenvolvimento do projeto (como Gemfile) no .gitignore.
É essencial que a configuração do .gitignore seja feita no início do projeto, pois problemas relacionados a esse arquivo são um pesadelo para serem resolvidos.
Segue, abaixo, um template de arquivo .gitignore:
Arquivo start.sh
O arquivo start.sh é um script de execução utilizado para o Docker, mas que também pode ser utilizado para que novos integrantes do projeto inicializem o projeto sem maiores dificuldades.
Segue, abaixo, um template de arquivo start.sh:
As gems do Ruby on Rails são bibliotecas externas que fornecem funcionalidades ao seu projeto. Dependendo do projeto em questão, os desenvolvedores precisarão utilizar gems que não vem configuradas por padrão em um projeto de Ruby on Rails, de forma que cabe ao gerente de projetos o trabalho de analisar quais gems serão necessárias no decorrer do projeto, colocar essas gems no Gemfile e realizar qualquer outra configuração para que essas gems funcionem adequadamente (a maioria das gems requer alguma configuração adicional para funcionar).
Além de configurar as novas gems, o gerente de projeto também deve verificar qualquer aviso de deprecated gem gerado pelo Rails após a execução dos comandos bundle install e rails s e corrigir esses avisos para evitar problemas com o projeto.
Idealmente, esse processo de configuração deve ser feito no começo do projeto para que todos os desenvolvedores tenham acesso às funcionalidades adequadas para o desenvolvimento do projeto (e para que eles não tenham que ficar rodando bundle install toda hora). Lembre-se de, após configurar ou substituir uma gem, sempre tentar executar o projeto com o comando rails s para garantir que o funcionamento do projeto não foi afetado por alguma gem mal configurada.
Para facilitar o uso dessa seção pelo gerente de projeto (ou qualquer outro membro da Struct), vamos dividir as gems que devem ser configuradas manualmente em duas seções: gems essenciais e gems úteis. Também vamos listar alguns casos comuns de deprecated gems que devem ser substituídas.
Gems essenciais
As gems essenciais são gems que devem ser configuradas em todos os projetos da Struct de Ruby on Rails, por proporcionarem funcionalidades que são necessárias ou para o desenvolvimento do projeto ou para a garantia básica da qualidade do projeto. Como gerente de projeto, é sua responsabilidade incluir e configurar todas as gems dessa seção no projeto.
RSpec
O RSpec é uma framework de testes utilizado para redigir testes de unidade e testes de módulo.
Para instalar e configurar o RSpec e o factory bot, siga os passos descritos nas páginas de instalação do Rspec e de instalação do factory bot
Devise and Simple Token Authentication
Duas gems que trabalham juntas para a criação de um usuário com login funcional (com proteção de sua senha em um token).
Com a gem Devise é possível criar uma model especial (device) com todas as características para permitir a criação de um usuário, como e-mail e senha.
Já a gem Simple Token Authentication garante que o acesso a rota da controller seja permitido apenas por quem esteja com o token certo, ou seja, logado corretamente.
Adicione o trecho de código abaixo ao arquivo Gemfile:
Execute o comando bundle install para instalar as gem adicionadas ao Gemfile.
Execute o comando rails g devise:install para instalar todos os arquivos do devise.
Rubocop
Rubocop é um analisador e formatador de código que serve para padronizar e melhorar seu código como um todo.
Essa gem é bem flexível (podendo ser configurada e estilizada) e garante um código mais limpo e organizado, já que os projetos são feitos em grupos e, assim, cada um tem sua forma de organizar distinta.
Adicione o trecho de código abaixo ao arquivo Gemfile:
Execute o comando bundle install para instalar as gem adicionadas ao Gemfile.
Rode o comando robocop -A no seu terminal do projeto para executar a verificação de seu código.
Note que, provavelmente, serão identificadas ofensas que podem não ser corrigidas automaticamente, sendo necessário concertá-las manualmente antes de ser feito o commit.
Regras do rubocop
Ao utilizar o rubocop, muito provavelmente você não vai querer utilizar todas as suas regras como padrão, já que em alguns casos vezes elas não fazem muito sentido ou são bem chatinhas e acabam atrapalhando mais do que ajudando. Nesses casos, você pode configurar desabilitar algumas regras por padrão e, para isso, basta criar na raíz do projeto o arquivo .rubocop.yml. Neste arquivo, primeiro adicione as seguintes linhas
Nesse trecho de código, estão sendo adicionadas as extensões rubocop-rails e rubocop-rspec (especificadas na gemfile), está sendo especificada a versão do ruby e habilitando os novos cops, o que será necessário para adicionar o rubocop ao CI no github, além disso, estão sendo excluídos alguns arquivos padrões do rails que podem dar problemas. caso queira ignorar um diretório inteiro, basta adicionar nessa lista - dir/**.
As últimas duas configurações estão desabilitando o cop de documentação com comentário e desabilitando o cop de Strings literais imutáveis, que introduzem uma feature que não é utuilizada com frequência em Rails e que possui pouca aplicação no momento.
Além disso, algumas configurações do rubocop são em relação ao tamanho das coisas (métodos, classes, testes), nesse caso, é possível apenas alterar o limite máximo ao invés de desabilitar o cop, já que esses muita vezes são importantes. Por exemplo, para alterar o tamanho máximo dos métodos para 16 linhas, basta colocar
Gems úteis
As gems úteis são gems que proporcionam funcionalidades desejáveis ou essenciais apenas em alguns casos, mas que não são necessárias em todos os projetos da Struct de Ruby on Rails. Como gerente de projeto, é sua responsabilidade ler a descrição das gems nessa seção e incluir e configurar apenas as gems que se apliquem ao projeto em questão.
Figaro
O Figaro é uma gem utilizada para gerenciar credenciais de bancos de dados em um arquivo de configuração local. Recomenda-se sua utilização em projetos que possuam um banco de dados com o SGBD (Sistema gerenciador de banco de dados) MySQL ou qualquer outro SGBD que não possua um bom sistema de armazenamento de credenciais de login (o PostgreSQL é um caso raro de SGBD que não precisa da gem Figaro).
Para configurar o Figaro, siga os passos abaixo:
Adicione o trecho de código abaixo ao arquivo Gemfile:
Execute o comando bundle install para instalar as gem adicionadas ao Gemfile.
Execute o comando bundle exec figaro install para configurar a gem.
Modifique o arquivo config/database.yml nas linhas demonstradas abaixo:
Adicione o trecho de código abaixo ao arquivo config/application.yml:
Após configurar a gem Figaro em seu ambiente, avise os outros membros do projeto que eles deveram executar os passos 2, 3 e 5 para configurar a gem em seus ambientes!
Deprecated gems
As deprecated gems são gems que não recebem mais manutenção e suporte por parte de um time de desenvolvedores, devendo ser retiradas dos projetos da Struct de Ruby on Rails. Como gerente de projeto, é sua responsabilidade substituir todas as gems dessa seção que estão presentes no seu projeto.
Chrome driver helper
A gem chromedriver-helper parou de receber suporte em Março de 2019. Substitua ela no Gemfile pela gem webdrivers.
SASS Rails
A gem sass-rails parou de receber suporte em Março de 2019. Substitua ela no Gemfile pela gem sassc-rails.
Um projeto bem estruturado contém um conjunto de branches padrões e um fluxo bem definido que novas features ou mudanças em features existentes devem percorrer para serem aprovadas definitivamente e chegarem aos clientes da aplicação. O gerente de projetos é o responsável por criar e configurar as branches padrões no repositório do projeto no GitLab. Também cabe ao gerente de projetos garantir que o desenvolvimento siga o fluxo definido pelas branches padrões, evitando a utilização de atalhos e os problemas gerados pela quebra do fluxo de desenvolvimento.
Esta seção detalha as branches padrão que todo projeto da Struct deve ter, com uma breve descrição do seu propósito geral e fluxo de desenvolvimento.
A develop é a branch de desenvolvimento padrão. Ela deve ser marcada como default e protected nas configurações de branch do projeto. Todas as features desenvolvidas devem ser adicionadas primeiramente à develop por meio de um Merge request.
A main é a branch da versão oficial do software para os desenvolvedores. Se possível, ela deve ser marcada como protected nas configurações de branch do projeto. De tempos em tempos, as features desenvolvidas na branch develop são levadas a branch main por meio de um Merge request, permitindo ao time de desenvolvedores revisar com mais afinco e atenção as features desenvolvidas (tipicamente, no final da sprint). Além disso, a main pode ser utilizada para receber diretamente correções de bugs ou problemas críticos, sem a necessidade dessas correções urgentes se misturarem com as features novas da Develop, encurtando o caminho de desenvolvimento até o cliente.
A production é a branch da versão oficial do software para os clientes. Se possível, também deve ser marcada como protected nas configurações de branch do projeto. De tempos em tempos, as features testadas e revisadas presentes na branch main são levadas à branch production por meio de um Merge request para que essas mudanças cheguem efetivamente aos clientes do projeto e possam ser utilizadas ou visualizadas pelos usuários do produto. Tenha muito cuidado ao colocar mudanças nessa branch, pois qualquer falha ou erro terá consequências reais para o cliente e para os usuários da aplicação.
Uma sprint consiste em um conjunto de features do projeto que deve ser desenvolvido em um conjunto específico de tempo. Cada feature possui atrelada a ela uma pontuação e um membro responsável pelo seu desenvolvimento. A utilização de sprints é uma característica do desenvolvimento ágil e possui o intuito de validar constantemente o projeto junto ao cliente por meio de entregas constantes de features (as sprints também são úteis para impedir que os desenvolvedores percam os prazos do projeto).
Como gerente de projetos, é seu trabalho definir todas as características de uma sprint, incluindo a sua duração, as features que serão desenvolvidas, a pontuação de cada feature e quem será responsável por cada feature. Também é seu trabalho gerenciar o andamento da sprint, garantindo que os desenvolvedores estejam desenvolvendo as features de forma adequada (com a utilização correta de branches e com a implementação de testes e utilização de comentários), esclarecendo quaisquer dúvidas relacionadas às regras de negócio do projeto, documentando o desenrolar da sprint quando ela acabar e redistribuindo features para outras sprints caso isso seja necessário.
No início de uma sprint, é altamente recomendado que, independente das circunstâncias, seja realizada uma reunião com a equipe de desenvolvimento. Isso permite ao gerente de projetos tratar todas as pendências necessárias relativas à sprint passada e ao começo de uma nova sprint.
Você também deverá criar um cartão no Trello no início da sprint para abrigar os detalhes da sprint. Esse cartão deverá ser atualizado no final da sprint ou caso alguma mudança ocorra nos detalhes da sprint.
Esta seção aborda como features devem ser elaboradas e integradas ao projeto, como o desenvolvimento de uma feature deve ser feito por um membro da equipe e quais as práticas que devem ser adotadas ao final de uma sprint.
Como dissemos, uma feature é uma parte do projeto que fornece alguma funcionalidade, e o desenvolvimento do projeto será divido no desenvolvimento de várias features. As features a serem desenvolvidas devem ser derivadas dos requisitos do projeto, colhidos em reuniões com o cliente. Por fim, as features devem ser divididas de forma que possam ser desenvolvidas por um único membro do projeto (ou seja, sem dependências excessivas com o código de outras features).
Com o intuito de deixar o desenvolvimento do projeto organizado, cada feature deve ser registrada no repositório do projeto por meio de uma issue, onde todos os detalhes necessários para o desenvolvimento da feature devem estar presentes. Dessa forma, qualquer desenvolvedor que não conheça os requisitos do projeto consegue desenvolver a feature apenas lendo a descrição da issue. Aliás, qualquer membro do projeto deve abrir uma issue quando perceber que uma nova feature precisará ser desenvolvida ou quando notar algum bug no projeto que não possa ser resolvido trivialmente.
No início de uma sprint, o gerente de projeto escolhe quais features serão desenvolvidas nessa sprint a partir das issues contidas no repositório, priorizando as correções de bugs e as features demandadas pelo cliente do projeto. Caso não haja issues no repositório, o gerente deve se reunir com a equipe de desenvolvimento para registrar as features pendentes como issues ou notificar o diretor de projetos que é necessário colher mais requisitos com o cliente.
Após as features serem escolhidas, elas devem ser pontuadas pela equipe de desenvolvimento. A forma de pontuar uma feature é bem simples: o gerente se reúne com a equipe de desenvolvimento, descreve o trabalho envolvido nessa feature e pede que a equipe de desenvolvimento indique um número entre os 6 primeiros números da sequência de Fibonacci (1, 2, 3, 5, 8, 13) que descreva quão trabalhosa a feature seria para ser desenvolvida (incluindo testes e comentários). Caso os desenvolvedores concordem (em linhas gerais) na pontuação, ela é atribuída à feature; do contrário, os desenvolvedores conversam entre si para se chegar a um consenso. Caso a feature tenha uma pontuação maior ou igual a 5, ela é denominada um épico, e deve ser dividida em sub-features menores. É importante frisar que correções de bugs não valem pontos.
Com as features pontuadas, elas devem ser distribuídas entre os membros da equipe de desenvolvimento. É importante garantir que a distribuição seja bem feita e leve em consideração a grade horária semanal dos desenvolvedores para evitar membros ociosos ou membros atarefados excessivamente. Também é ideal que desenvolvedores novatos sejam auxiliados no desenvolvimento de features mais complexas, por meio de recursos como pair programming ou maior atenção do gerente de projetos. Por fim, lembre-se de atribuir as issues no repositório aos seus respectivos responsáveis para que qualquer um que visite o repositório do projeto possa saber quem está trabalhando no que.
Assim que as features forem escolhidas, pontuadas e distribuídas, é hora de começar o desenvolvimento.
O desenvolvimento de uma feature em uma sprint deve seguir uma lógica bem definida para garantir que as diversas features desenvolvidas venham a ser adequadamente revisadas e integradas no projeto. Como gerente de projetos, você deverá entender plenamente essa lógica e explicá-la aos demais desenvolvedores.
Como dito anteriormente, seu projeto deve ter três branches principais: develop, main e production. O primeiro passo a ser feito no começo de cada sprint, é atualizar a branch develop com as mudanças contidas na branch main.
Depois disso, para cada feature a ser desenvolvida, os seguintes passos devem ser executados:
O desenvolvedor deve abrir uma nova branch a partir da develop, com o padrão de nomenclatura numero_da_issue_nome_da_feature (Exemplo: 001_tela_de_login).
O desenvolvedor deve, nessa nova branch, desenvolver sua feature, com testes e comentários. Após o desenvolvimento acabar, o desenvolvedor deve abrir uma merge request da sua branch para a branch develop, resolvendo qualquer conflito com a branch develop após abir a merge request.
Um outro desenvolvedor (que não seja o que desenvolveu a feature) deve revisar essa merge request, rodando e inspecionando os testes e verificando quais foram as mudanças realizadas, se há bugs no código, se a feature está de acordo com as regras de negócio do projeto e se mais testes precisam ser redigidos. Esse passo é extremamente importante para garantir que o código do projeto possua alta qualidade e seja livre de bugs.
Caso a revisão seja bem sucedida, o revisor resolve qualquer conflito que tenha surgido entre a submissão da merge request e a sua revisão, e aceita a merge request. Do contrário, o revisor notifica nos comentários da merge request as mudanças que o desenvolvedor deve adotar para que a merge request seja aceita e voltamos ao passo 2.
Esses passos devem ser executados até que a sprint chegue ao fim, o que ocorre quando todas as features da sprint foram desenvolvidas ou quando a data de finalização da sprint é atingida.
Quando uma sprint chega ao fim, os seguintes passos devem ser executados para preparar o projeto para a próxima sprint:
Todas as merge requests que estejam abertas devem ser resolvidas. Isso pode ser feito com a merge request sendo aceita ou com a merge request sendo recusada e a feature relativa a ela sendo postergada para a próxima sprint.
Uma merge request deve ser aberta da branch develop para a branch main. Essa merge request deve ser revisada por todos os membros da equipe de desenvolvimento. Essa revisão é mais sucinta que as outras revisões e tem o intuito de verificar se as features desenvolvidas foram integradas de maneira correta, se os testes estão sendo bem sucedidos ao serem executados e se a aplicação roda adequadamente (isso deve ser testado por um breve uso da aplicação em si).
Caso todos os membros aprovem a merge request da sprint, as features desenvolvidas na sprint são colocadas na branch main. Do contrário, as mudanças necessárias ou são implementadas rapidamente ou, caso se tratem de mudanças mais sérias, são colocadas em novas issues que serão resolvidas na próxima sprint. Nesse caso, a merge request poderá ser aceita para a main caso os bugs e problemas sejam poucos (mesmo com alguns problemas, é bom que o código seja colocado na main para evitar que features prontas se acumulem na develop). As correções de bugs e reparo de features incompletas devem ter prioridade na próxima sprint.
Caso a merge request tenha sido aprovada sem bugs ou ressalvas, as mudanças colocadas na main devem ser colocadas também na branch production, para que o cliente tenha acesso as mudanças. Caso a branch production esteja muito atrasada em relação a branch main, considere realizar uma sprint apenas com o intuito de corrigir bugs.
Como gerente de projetos, você também deverá fazer,ao final da seamana, um breve resumo da sprint, relatando o resultado final da sprint, as features desenvolvidas por cada membro da equipe e as dificuldades encontradas, além de falar sobre a situação geral do projeto. Esse resumo deverá ser mandado no canal de gerência de projetos no slack direcionado ao diretor de projetos, para que ele possa estar inteirado da situação do projeto.
O gerente de um projeto também tem o trabalho de participar das reuniões gerais (RGs) da Struct para informar aos outros membros da empresa júnior (em especial, o presidente e o diretor de projetos) o estado de desenvolvimento do projeto. Nessa hora, o gerente deve destacar de forma bem resumida se o desenvolvimento do projeto está progredindo de maneira adequada, se há necessidade de mais pessoas serem alocadas no projeto e se algo de anormal está acontecendo com o projeto.
Caso o gerente de um projeto não possa comparecer à reunião geral, ele deve instruir algum outro membro do projeto que estará na RG à realizar essa função. Caso isso não seja possível, o gerente deve enviar uma mensagem breve no Slack que detalhe esses fatores.
O ambiente de produção é o espaço onde colocaremos o código da branch production para que ele possa ser acessado diretamente pelo cliente ou pelos usuários. Como gerente de projeto, é seu trabalho colocar o código da branch production no ambiente de produção ao final do projeto (ou antes da data de entrega do projeto). Para esse fim utilizaremos o Docker, uma ferramenta que fornece um ambiente de virtualização para colocarmos o projeto.
Devido à complexidade do processo de colocar o código em produção, achamos melhor detalhar isso em uma página específica do Gitbook. Lembre-se, também, que qualquer mudança requisitada pelo cliente só será perceptível se o código estiver em produção, de forma que você deverá realizar esse processo regularmente (se esquecer de colocar novas features ou correções de features existentes em produção é uma excelente forma de irritar o cliente).