LuizTools

Como criar uma Definição de Pronto que funciona?

done

Atualizado em 11/07/19!

Uma Definição de Pronto (Definition of Done, no original) é um artefato Scrum usado para garantir a qualidade do produto desenvolvido a cada iteração (Sprint). Um documento, um contrato entre os membros do Time Scrum e demais envolvidos para que todos entendam o que um produto “pronto” (done) significa.

Mas como criar uma definição de pronto que realmente funcione, que não seja apenas uma burocracia sem sentido no meio de um processo de desenvolvimento que deveria ser ágil?

Vou mostrar algumas ideias aqui no artigo!

Depois, se quiser conhecer mais do meu trabalho com Scrum, dê uma olhada em meu livro sobre o assunto. E se preferir assistir a um vídeo ao invés de ler o artigo, confira abaixo uma amostra gratuita do meu curso online de Scrum e Métodos Ágeis:

Basicamente a definição de pronto é o documento que define o que é considerado, para todos envolvidos no projeto, o que “pronto” (done) significa.

Quais são os requisitos para arrastar um card para a coluna DONE do Kanban? Se um desenvolvedor diz que algo está pronto, o que isso significa? O que o Product Owner espera ver, em termos gerais, durante a Sprint Review?

Essas são algumas perguntas que podem nortear a construção deste documento, que geralmente e um checklist de coisas a serem realizadas/verificada, antes de uma tarefa ser dada como pronta e, como manda o pilar da transparência do Scrum, deve ser visível e conhecido por todos do time. Dica: coloque ao lado do Kanban.

Documento colaborativo

Um primeiro ponto a se considerar é que a criação da definição de pronto deve ser realizada de maneira colaborativa, ou seja, por todos os membros do Time Scrum. Claro, alguns membros possuem mais direitos, e outros mais deveres, como o Time de Desenvolvimento, por exemplo, que será o principal encarregado de implantar os itens da definição de pronto na sua rotina de desenvolvimento. Já o Scrum Master deverá garantir e auxiliar o time na execução do que prega este documento, afinal, ele faz parte do processo Scrum e deve ser respeitado. E por fim, o Product Owner espera que todos os itens dados como prontos e entregues estejam dentro do padrão de qualidade acordado na definição de pronto.

Achou complicado? Não deveria, é mais simples do que parece.

Um bom começo é, durante a primeira Sprint Planning, o time definir a v1 da sua definição de pronto. Pense em uma folha A4 e comece com coisas simples como dizer que “todo item dado como pronto deve ter passado em testes unitários” e depois se aprofunde em itens mais “avançados” como testes de regressão, teste em pares, etc e até mesmo itens difíceis dependendo da disponibilidade do Time Scrum como “aprovar com o Product Owner”. Sim, é bem complicado deste último item ser factível pois geralmente o Product Owner não é (mas deveria ser) tão acessível quanto gostaríamos.

Como tudo no Scrum (pilares da inspeção e adaptação, lembra?), itere e melhore sua definição de pronto a cada Sprint. Pegue o que deu errado na Sprint Review (ela nunca sai 100% como foi planejado pelo Time de Desenvolvimento), aborde na Sprint Retrospective e aplique de maneira aperfeiçoada na próxima Sprint Planning. Comece simples e avance rapidamente. Lembre-se que a função deste artefato é garantir a qualidade, mas lembre-se também de se manter ágil. A dose certa de um e de outro é você que vai descobrir.

E por último, eu sugiro fazer na Sprint Planning pois dependendo dos itens colocados na sua definição de pronto, o tempo para que cada entrega fique pronta pode mudar drasticamente. Tenha a definição de pronto pronta antes de jogar Planning Poker, por exemplo.

Contrato moral

A definição de pronto é algo com o qual o time se compromete a cumprir para garantir a qualidade das entregas. Sendo assim, é um contrato moral. Moral porque estamos falando de pessoas e processos, não há um elemento de software envolvido, lhe cobrando diariamente que cumpra os requisitos do documento, embora o time possa optar por usar algum, como um dos itens da definição, mas nada a substitui.

Sendo um contrato moral e ao mesmo tempo algo colaborativo, o time terá de achar o checklist que agrade a todos, incluindo aqui o Product Owner, que é quem tem a palavra final sobre os itens do Backlog que o Time de Desenvolvimento está trabalhando. Jamais crie uma definição em que não há unanimidade dentro do Time pois caso contrário ela será sabotada, mais cedo ou mais tarde. Caso o time seja inexperiente, como Scrum Master “force” algumas regras pedindo um voto de confiança, explique que esse documento poderá ser alterado na próxima Sprint caso o Time não se adapte.

Mas principalmente: crie um documento que seja útil para garantir a qualidade das entregas que seja executável, exequível. É muito fácil cair na tentação de adicionar dezenas e dezenas de itens de qualidade que jamais serão empregados no projeto como “validar pessoalmente com o cliente final” seja porque não é prático, seja porque realmente e inviável (ex: cliente do outro lado do mundo). Se o Time optar por ferramentas, escolha o menor conjunto delas possível, caso contrário o tempo de desenvolvimento poderá ser enormemente afetado ou a definição enormemente sabotada.

E se você acha que seu Time não dará atenção a um contrato moral, que tipo de time você montou para executar o projeto?

Exemplos e Contra-exemplos

A seguir alguns exemplos de itens que já implementei em Times Scrum que eu liderei como Scrum Master e que sei que funcionam. Obviamente, alguns deles não funcionam dentro de realidades fora das que eu vivenciei, uma vez que a maioria das empresas que trabalhei desenvolviam software para si mesmas (cliente interno). Também obviamente não pegue todos e coloque na sua definição. Use-os como ideias, não tenho intenção alguma definir o que significa “pronto” para o SEU time de desenvolvimento.

Lembre-se que a definição de pronto deve ser clara e não permitir desculpas como “está pronto, só falta testar”…

Toda tarefa de software, para ser considerada pronta, deve…

Ter sido atualizado com o controle de versão e permanecer compilando;

Isto é o mínimo que se espera de algo dado como pronto. Em Times que usem versionamento de código (algum não usa?) o desenvolvedor, após concluir a codificação da tarefa, pegar a última versão do servidor, rodar seus testes (ver abaixo), fazer a fusão (merge) do que for necessário e garantir que, antes de enviar seu código amalgamado ao servidor, que tudo continua compilando. Ponto.

Contra-exemplo: cuidado com o envio de software inacabado (mesmo que algumas features individuais já estejam) para produção. Versionadores de código (como TFS, SVN, Git, etc) possuem recursos como branches e forks que permitem aos desenvolvedores manterem sempre uma versão de produção 100% operacional e livre de bugs enquanto trabalham em outra versão mais instável. Colocar na definição de pronto que o requisito de software desenvolvido esteja rodando em produção é muito perigoso.

Ter passado nos testes unitários com sucesso;

Se você ainda não usa Testes Unitários em sua equipe de desenvolvimento, deveria. A ideia aqui, basicamente, é que, se você testar cada uma das micro-partes que envolvem o seu software (unidades) isoladamente, a probabilidade de que o todo funcione é muito maior, ao mesmo tempo em que lhe obriga a manter um baixo acoplamento do seu software para que ele possa ser testado em micro-pedaços.

Contra-exemplo: colocar TDD na definição de pronto sem que o time tenha experiência com a metodologia. TDD é bem complicado e difícil de ser seguido à risca, mais do que o próprio Scrum.

Ter passado por testes de uso de outro colega da equipe;

Desenvolvedores tendem a ser os piores testadores do mundo quando o assunto é testar suas próprias criações. Certamente temos um gene defeituoso que faz com que auto-sabotemos os testes visando não encontrar bugs. Geralmente outro colega da equipe (chamado cross-testing ou peer-review), que não está preocupado com o trabalho que vai dar corrigir qualquer erro encontrado, é um testador melhor que o desenvolvedor original. E se isso não for suficiente para garantir a qualidade, em casos extremos mude para “teste de uso de quem vai usar a feature”, chamando para o teste de uso o próprio usuário da feature.

Ah, esse teste de uso deve ser em ambiente de homologação. Nada de chamar o colega ou o usuário final pra usar na tua máquina. Isso evita aquela famigerada frase: “na minha máquina funciona!”.

Contra-exemplo: teste de uso automatizado. Isso faz com que você perca a experiência da usabilidade do software. Podem existir testes automatizados, mas eles não devem substituir por completo os testes manuais quando o recurso envolver interface gráfica.

O código encontra-se dentro dos padrões da empresa;

É comum, embora não deveria, desenvolvermos uma v1 de qualquer funcionalidade de maneira meio…porca. O que não é “comum” é que essa v1 seja a versão “pronta” daquele requisito. Refatoração é a chave aqui. Garanta com esse item que o código passe por uma avaliação estrutural para ver se está 100% de acordo com as normas de desenvolvimento da empresa (ex. do Google). Obviamente para que isso funcione, estas normas também devem estar visíveis e serem de conhecimento geral do Time de Desenvolvimento.

Contra-exemplo: empresas que possuam normas de desenvolvimento muito particulares tendem a fracassar ao usar este item na definição de pronto. O que seria algo muito particular? Na minha opinião algo que foge aos padrões de codificações oficiais da linguagem/framework utilizados. Quando escrevo código em Java, uso os padrões da Oracle (Camel Case para métodos, por exemplo). Já quando escrevo código em C#, uso os padrões da Microsoft (Pascal Case para métodos, por exemplo). Isso facilita a vida para todos, inclusive novos funcionários e geralmente a resistência por adotar essa prática é culpa do ego dos veteranos da empresa.

Softwares de apoio e documentação atualizados;

Um último item na definição de pronto deve dar cabo de tarefas burocráticas e pouco interessantes, mas igualmente necessárias, como essas. Todo Time de Desenvolvimento usa algum software para controlar seu progresso (Trello, por exemplo). Mas para garantir que esse software mantenha sua utilidade, ele deve permanecer atualizado com o andamento do projeto e aqui o trabalho do Scrum Master deve ser bem forte, porque o time sempre se “esquece” de atualizar. Cobrar atualizações diárias, sempre antes da Daily Scrum, geralmente resolvem este problema, mesmo antes das tarefas serem dadas como pronto.

O mesmo vale para a documentação do projeto. Eu particularmente sempre gostei de Wikis internos por serem um formato de documentação viva, colaborativa e fácil de usar e manter. Obviamente tem empresas que preferem o bom e velho Word. Encontre o que funciona para você, mas garanta que um mínimo de documentação esteja sempre atualizada e visível, como diagramas da arquitetura, do banco de dados, de implantação, etc.

Contra-exemplo: tão nocivo quanto não ter documentação é tê-la em demasia, então tome cuidado com este item, caso contrário o time pode não se comprometer de verdade, gerando um comprometimento flácido.

Conclusão

Estas foram algumas ideias de como criar ou incrementar a sua definição de pronto. A combinação de uma definição de pronto clara, com objetivos e escopos definidos, tendem a garantir entregas consistentes e de qualidade, levando o projeto ao sucesso.

Associar a sua definição de pronto a acrônimos como DEEP, INVEST e SMART também pode ajudar bastante!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Tutorial CRUD em Node.js com driver nativo do MongoDB – Parte 3

O tutorial de hoje é uma continuação de uma série bastante acessada aqui no blog, onde ensino como fazer um sistema de cadastro bem simples em Node.js, usando o web framework ExpressJS e o banco de dados não-relacional MongoDB. Ou seja, o famoso CRUD.

Nesta terceira e última parte, introduzo um conceito importante de construção de interfaces que é a modularização da página através do recurso de partial views do EJS (view-engine que estamos usando com ExpressJS) e ensino como dar um “tapa” no visual usando o framework front-end Bootstrap, muito utilizado mundialmente para estruturar aplicações web responsivas e elegantes.

Para conseguir acompanhar todos os códigos, é importante que você tenha realizado a parte anterior ou pelo menos baixe os códigos-fonte que se encontram no formulário ao final do tutorial anterior (parte 2). Caso prefira assistir um vídeo, a primeira parte dessa séria pode ser resumida com este vídeo abaixo que é uma aula gratuita do meu curso de Node.js e MongoDB.

Aproveite!

O conteúdo do post é:

O que são Partial Views?
Partial views com EJS
Adicionando o Bootstrap
Customizando a aparência

Vamos lá!

Atenção, uma versão ainda mais completa deste tutorial está disponível em videoaula em meu curso de Node.js e MongoDB.

O que são Partial Views?

É muito comum quando estamos construindo aplicações web que certas porções de nossas views (telas) acabem se repetindo. Por causa disso, todas as linguagens de programação para web possuem recursos de partial views, ou seja, de modularização da interface a partir de “partes” da tela que são construídas separadas e depois são montadas em conjunto para que o usuário veja apenas o resultado final, completo.

Fazendo uma analogia com o que fazemos no código backend do Node.js, uma partial view é como se fosse um módulo NPM, que depois usamos o require para carregá-lo em nosso código. Em outras plataformas isso é chamado de import, include, using, etc.

Nossa aplicação é bem simples, possui apenas três views: index, new e error, conforme você vê na imagem abaixo.

Estrutura do projeto — Estrutura de Views

Essas views por sua vez também são mega simples, logo, não há uma reeeaaal necessidade de usar partial views aqui, usaremos mais a título de conhecimento. No entanto, esse conceito é muito poderoso e além de tornar seu código de front-end mais elegante e fácil de ler, ele torna a programação de novas páginas muito mais produtiva, pois sempre aproveitaremos elementos genéricos da interface que serão criados apenas uma vez.

Se olharmos agora para as views index e new, você deve notar que existem muitas tags em comum no início e no fim delas. É por aí que vamos começar a melhorar.

Partial views com EJS

Não é de hoje que eu uso EJS (Embedded JavaScript) em meus tutoriais e neste não será diferente. Apesar de não ser a view-engine (motor de visualização) padrão do ExpressJS (esse título é do PUG/Jade), ele é meu favorito pois a curva de aprendizado é ridiculamente baixa, considerando que usa HTML + JS, coisa que todo dev web está careca de saber.

Como não poderia deixar de ser, o EJS possui a funcionalidade de criar partial views (lembro dos meus tempos de ASP.NET em que chamávamos isso de MasterPages…). Isso é bem fácil de fazer, comece criando um arquivo top.ejs (top=topo) na sua pasta views e nele vamos colocar toda a parte comum que teremos no topo de todas páginas do nosso sistema, que é apenas o HTML abaixo por enquanto:

<!DOCTYPE html>
 <html>
 <head>
 <title><%= title %></title>
 <link rel='stylesheet' href='/stylesheets/style.css' />
 </head>
 <body>
 <h1><%= title %></h1>

<!DOCTYPE html>

<html>

<head>

</head>

<body>

Note que nesta top.ejs estamos usando algumas variáveis JS que devem vir do backend, através do model passado na função render do Node.js, lembra?

Agora vamos criar mais um arquivo novo, o bottom.ejs (bottom=rodapé), também na pasta views e nele vamos colocar toda a parte comum que teremos no rodapé de todas páginas do nosso sistema, que é apenas o HTML abaixo por enquanto:

</body>
</html>

1 2	</body> </html>

E agora, como fazemos para as demais views do projeto usarem essas partial views para compor a sua estrutura?

Bem simples, vamos começar pela index.ejs, remova a parte do topo do arquivo que é repetida ao arquivo top.ejs e no lugar desse pedaço, deixe como abaixo, usando o comando ‘include’ para “incluir” a partial view na primeira linha do arquivo:

<%- include top.ejs %>
 <ul>
  <% docs.forEach(function(customer){ %>
    <li>
      <a href="/edit/<%= customer._id %>">
      <%= customer.nome %>
      </a>
      <a href="/delete/<%= customer._id %>" onclick="return confirm('Tem certeza que deseja excluir?');"> X </a>
    </li>
  <% }) %>
  </ul>
  <hr />
  <p>
    <%= count %> clientes encontrados!
  </p>
  <p>
    <% for(var i=1; i <= qtdPaginas; i++) {
      if(i !== pagina){ %>
        <a href="/<%= i %>"><%= i %></a> |
      <%} else {%> <%= i %> |
    <% } }%>
  </p>
  <hr />
  <a href="/new">Cadastrar novo cliente</a>
 <%- include bottom.ejs %>

<%- include top.ejs %>

<ul>

<% docs.forEach(function(customer){ %>

<li>

<%= customer.nome %>

</a>

<a href="/delete/<%= customer._id %>" onclick="return confirm('Tem certeza que deseja excluir?');"> X </a>

</li>

<% }) %>

</ul>

<hr />

<p>

<%= count %> clientes encontrados!

</p>

<p>

<% for(var i=1; i <= qtdPaginas; i++) {

if(i !== pagina){ %>

<a href="/<%= i %>"><%= i %></a> |

<%} else {%> <%= i %> |

<% } }%>

</p>

<hr />

<a href="/new">Cadastrar novo cliente</a>

<%- include bottom.ejs %>

Note que já incluí também o include para o bottom.ejs no final do arquivo. Na hora que o arquivo HTML vai ser construído para ser enviado ao browser para renderização, o EJS vai ler essa linha e entender que parte desse HTML está em outro arquivo. Ele vai ir nesse outro arquivo, copiar o conteúdo de lá e colar bem nesse local.

Assim, com esses dois includes, nós mantemos nossa aplicação modularizada em três pedações: topo, centro e rodapé, facilitando manutenção e aumentando o reuso de código.

Sim, reuso de código, pois agora nas páginas new.ejs e error.ejs nós podemos fazer os mesmos includes para não ter de repetir aqueles blocos iniciais e finais de HTML. Os ganhos agora são pequenos, mas no futuro, são enormes pois facilitam muito a evolução e manutenção do sistema web.

Eu não vou colocar aqui o código dos outros dois arquivos ejs com os includes, embora você possa baixar o projeto completo no final desse artigo deixando seu e-mail.

Depois de fazer estas alterações, coloque sua aplicação Node para rodar (não esqueça de subir o banco MongoDB também) e você vai ver que nada mudou para o usuário, que a tela continua renderizando do mesmo jeito e que as alterações só servem para ajudar o programador a trabalhar melhor mesmo.

Um dos grandes ganhos desta abordagem vem agora: manutenção. Vamos adicionar o framework front-end Bootstrap nessa aplicação pra dar um “tapa” no visual dela e vamos fazer isso de maneira muito fácil porque já deixamos a aplicação preparada para este tipo de alteração.

Adicionando o Bootstrap

Eu não vou me prolongar muito na teoria do Bootstrap por aqui pois falo bastante disso no meu livro Programação Web com Node.js. Inclusive aquele “B” na capa é o símbolo do Bootstrap (os outros símbolos são o JQuery, o HTML5 e o MongoDB).

Basicamente o Bootstrap é um framework front-end muito popular no mundo inteiro, fornecendo uma estrutura e comportamentos padronizados que muitos devs web sabem como mexer, acelerando o desenvolvimento e manutenção de qualquer sistema que use Bootstrap como padrão para front-end.

É como se os sites tivessem a mesma estrutura básica, entende?

Apesar da estrutura básica ser a mesma, a aparência pode variar enormemente através da customização de arquivos de estilo (CSS).

A aplicação do Bootstrap em um projeto web se dá através de seus arquivos de CSS e de seus arquivos de JavaScript.

Vamos começar pelo arquivo CSS, que é obtido no site oficial e deve ser adicionado no topo do nosso arquivo top.ejs, logo antes da chamada original de CSS que foi colocada pelo express-generator:

<!DOCTYPE html>
<html>
  <head>
    <!-- Required meta tags -->
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
    <title><%= title %></title>
    <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
    <link rel='stylesheet' href='/stylesheets/style.css' />
  </head>
  <body>
    <h1><%= title %></h1>

<!DOCTYPE html>

<html>

<head>

</head>

<body>

Como adicionamos esta linha no top.ejs, TODAS as páginas que incluem essa partial-view vão estar agora com o CSS do Bootstrap. Isso é produtividade na programação!

Note que também adicionei duas meta-tags, conforme sugerido na página do Bootstrap, para garantir máxima compatibilidade com os recursos do framework, como a responsividade em dispositivos móveis.

Agora, vamos adicionar os scripts JS necessários pro Bootstrap funcionar corretamente no arquivo bottom.ejs. Eles devem ser adicionados logo antes da tag de fecha-body:

<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
</body>
</html>

</body>

</html>

Só o fato de termos feito essas adições já vão gerar alguns efeitos visuais na nossa aplicação, como pode ver na imagem abaixo:

Mas para despertar todo o “poder embelezador” do Bootstrap em nossa aplicação nós temos de fazer alguns ajustes na nossa estrutura, bem como usar algumas classes CSS definidas pelo Bootstrap.

Assim, vamos começar definindo uma “div class container” que vai englobar todo o conteúdo do body das páginas. Para fazer isso, basta adicionar o conjunto de tags div abaixo, com a abre-div no top.ejs e a fecha-div no bottom.ejs, de modo que ambas fiquem dentro do body.

<!DOCTYPE html>
<html>
  <head>
    <!-- Required meta tags -->
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
    <title><%= title %></title>
    <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
    <link rel='stylesheet' href='/stylesheets/style.css' />
  </head>
  <body>
      <div class="container">
    <h1><%= title %></h1>

<!DOCTYPE html>

<html>

<head>

</head>

<body>

Note que só mudou uma linha, logo acima do H1, bem no final do top.ejs. Já no bottom.ejs, também só vai mudar uma linha, que fica bem no início do arquivo:

</div>
<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
</body>
</html>

</div>

</body>

</html>

Após essa adição, teremos mais um ajuste perceptível nas páginas já existentes, que ficarão com uma margem e mais centralizadas. A div container faz a sua página funcionar em um grid-system de 12 colunas virtuais, ou seja, o Bootstrap permite que você organize o conteúdo das suas páginas em 12 blocos de tamanhos iguais, como em um Lego. Desde que você siga esta regra cuidadosamente, a sua aplicação web será responsiva, alterando a sua largura conforme a tela do aparelho que estiver acessando a mesma.

E isso é só o início!

Customizando a aparência

Eu poderia ficar aqui durante muitas e muitas horas escrevendo sobre Bootstrap, então vou ser breve. Vamos apenas dar uma embelezada na página para te mostrar o poder do framework e depois vamos encerrar o tutorial. Fica a seu critério depois se aprofundar, seja em meu livro ou na documentação oficial.

Uma vez adicionado a div container, que é o principal bloco da sua página, vamos personalizar os botões, ou os elementos que queremos que se pareçam com botões. Para isso, basta usarmos duas classes em cada elemento “btn btn-primary” para os botões principais e apenas “btn” para os secundários.

Cada âncora ou submit/button deve ficar parecida com o HTML abaixo:

<a href="" class="btn btn-primary">Teste</a>

1	<a href="" class="btn btn-primary">Teste</a>

O botão primário é azul no Bootstrap, mas isso obviamente você pode alterar sobrescrevendo ou editando o CSS original do Bootstrap, ou ainda através de templates que você pega na Internet. As classes CSS de botão também já adicionam um efeito de sombra ao passar o mouse por cima deles, o chamado “hover”.

Para “fechar” a tela inicial, vamos customizar a tabela além do botão, para ela ficar bem bacanuda. Para isso, além de usar o padrão HTML5 para tabelas (com thead, tbody, etc), vamos adicionar uma série de classes a saber:

table: classe padrão Bootstrap para tabelas;
table-bordered: com linhas nas bordas;
table-striped: com linhas “zebradas”;
table-hover: com sombra quando passa o mouse;
thead-dark (no cabeçalho): pro cabeçalho ficar escuro;

O código final que lista os clientes cadastrados pode ser visto abaixo, e substitui a lista antiga:

  <table class="table table-striped table-bordered table-hover">
      <thead class="thead-dark">
          <tr>
            <th scope="col">Nome</th>
            <th scope="col">Excluir</th>
          </tr>
      </thead>
      <tbody>
    <% docs.forEach(function(customer){ %>
      <tr>
        <td>
        <a href="/edit/<%= customer._id %>">
          <%= customer.nome %>
        </a>
      </td>
      <td>
        <a href="/delete/<%= customer._id %>" class="btn btn-danger" 
          onclick="return confirm('Tem certeza que deseja excluir?');">
          X
        </a>
      </td>
      </tr>
    <% }) %>
    </tbody>
  </table>

<tr>

<th scope="col">Excluir</th>

</tr>

</thead>

<tbody>

<% docs.forEach(function(customer){ %>

<tr>

<td>

<%= customer.nome %>

</a>

</td>

<td>

<a href="/delete/<%= customer._id %>" class="btn btn-danger"

onclick="return confirm('Tem certeza que deseja excluir?');">

</a>

</td>

</tr>

<% }) %>

</tbody>

</table>

Fechando de vez esta tela, atualize o código de paginação para ele ficar estilizado conforme recomendado pelo Bootstrap:

  <nav aria-label="Paginação">
    <ul class="pagination">
      <%
        for(var i=1; i <= qtdPaginas; i++) {
          %>
            <li class="page-item"><a class="page-link" href="/<%= i %>"><%= i %></a></li>
      <% }%>
    </ul>
  </nav>

for(var i=1; i <= qtdPaginas; i++) {

<% }%>

</ul>

</nav>

Com estas alterações, nossa tela inicial ficará muito melhor do que anteriormente, como mostra a imagem abaixo (coloquei btn-danger ao invés de btn-primary nos botões de exclusão):

Agora a segunda tela, de cadastro de cliente (new.ejs). Além de ajustarmos os botões com as classes que mencionei antes, vamos ajustar o form HTML conforme instruções do próprio Bootstrap:

    <form action="<%= action %>" method="POST">
      <div class="form-group">
          <label for="nome">Nome</label>
          <input type="text" class="form-control" id="nome" name="nome" placeholder="Digite o nome" value="<%= doc.nome %>" />
      </div>
      <div class="form-group">
          <label for="idade">Idade</label>
          <input type="number" class="form-control" id="idade" name="idade" placeholder="Digite a idade" value="<%= doc.idade %>" />
      </div>
      <input type="submit" value="Salvar" class="btn btn-primary"/><a href="/" class="btn">Cancelar</a>
    </form>

<form action="<%= action %>" method="POST">

</div>

<label for="idade">Idade</label>

</div>

<input type="submit" value="Salvar" class="btn btn-primary"/><a href="/" class="btn">Cancelar</a>

</form>

O resultado, você confere na imagem abaixo (os tamanhos são ajustáveis, mas por padrão ele é responsivo):

E com isso encerramos o tutorial de hoje e acredito que esta série sobre o CRUD com driver nativo do MongoDB. Qualquer dúvida que você tiver, deixe aí nos comentários que terei o maior prazer em responder.

Interessado em mais conteúdos sobre Node.js e MongoDB, clique no banner abaixo e conheça o meu curso em videoaulas sobre o assunto!

Certificações Ágeis para Scrum Master e Product Owner

Atualizado em 18/06/19 com vídeos!

Obtive minhas primeiras certificações em métodos ágeis, mais especificamente Scrum, em 2010, logo após fazer meu primeiro curso sobre o assunto e definitivamente mudar a minha carreira pra sempre. Estas certificações me foram muito úteis em diversas ocasiões e arrisco dizer que não seria hoje um Agile Coach no Agibank se não possuísse as mesmas.

A ideia do artigo de hoje é explicar um pouco sobre certificações em métodos ágeis, principalmente as disponibilizadas pela Scrum.org, a fundação sem fins lucrativos criada por Ken Schwaber em 2009, um dos fundadores do Scrum.

O que abordarei nesse artigo:

Por que tirar uma certificação?
Quem emite certificações?
Certificação Professional Scrum Master I
Certificação Professional Scrum Product Owner I
Dicas de estudo para a prova
Dicas para a realização da prova

Vamos lá!

Por que tirar uma certificação?

Para quem nunca tirou uma certificação antes, ela funciona como um diploma, um certificado de proficiência mas em um assunto bem específico, como programação Java, administração de servidores Linux ou neste caso, atesta que você sabe toda a teoria sobre o framework Scrum e um papel em específico (Scrum Master ou Product Owner).

Ser certificado não é garantia de que você tenha experiência com algo, mas de que ao menos domina a teoria daquele assunto. Mais do que isso, um profissional certificado mostra o seu interesse genuíno sobre determinado assunto, uma vez que certificações levam certo tempo para estudo e aplicação da prova, além do valor que pode ser bem salgado às vezes.

É bem comum no mercado de desenvolvimento as pessoas acharem que qualquer um pode ser um Scrum master ou um Product Owner e saber se a pessoa possui ou não certificação no papel demonstra que ela realmente busca uma carreira naquele papel em específico e não está apenas atrás de alguma vaga de emprego qualquer. Existem exceções? Com certeza. Mas entrevisto regularmente candidatos a vagas com essas nomenclaturas e é triste ver pessoas que não fazem ideia onde estão se metendo.

Quem emite certificações?

Falarei aqui apenas das duas principais certificadoras do mercado em métodos ágeis: Scrum.org e Scrum Alliance.

A Scrum Alliance foi fundada pelos criadores do Scrum: Jeff Sutherland e Ken Schwaber em 2003. Ela promove a disseminação do Scrum ao redor do mundo desde seus dias iniciais e muito da popularidade do seu método vem da atuação desta empresa. Aproximadamente em 2007 Ken e Jeff entraram em desacordo sobre os rumos da empresa, que estava com um apelo cada vez mais comercial (por exemplo, não era exigida prova para certificar um aluno à época, apenas um curso caríssimo e obrigatório) e que também não estava preocupado com o papel do Dev Team, apenas PO e SM.

Desse desacordo surgiu a Scrum.org aproximadamente em 2009, com o intuito de educar e certificar não apenas SMs e POs, mas também desenvolvedores em práticas ágeis de engenharia. Com um cunho mais educativo e menos comercial, a Scrum.org não exige cursos, embora eles existam para quem deseje fazer, para certificar alguém, apenas uma prova online em Inglês que explicarei mais sobre na sequência. Embora a Scrum Alliance possua provas também há alguns anos, as provas da Scrum.org são notoriamente mais difíceis.

Independente deste histórico, tanto as certificações da Scrum.org quanto da Scrum Alliance são bem avaliadas no mercado, embora existam rumores no forum da Scrum.org de que na Europa as certificações assinadas pelo Ken Schwaber (Scrum.org) possuam maior prestígio.

Sinceramente não recomendo qualquer outra certificadora. Como o Scrum Guide é mantido por estes dois senhores até os dias de hoje, somente ELES podem dizer o que o Scrum é ou não, ou como devem ser a atuação dos papéis ágeis. Já vi muita prova de outras certificadores falando besteira que contradiz o Scrum Guide, que é a fonte oficial de informação sobre o Scrum. Não vou citar nomes aqui por uma questão de ética, mas já vi gente ensinando e cobrando em prova conceitos errados. Tenha cuidado!

Certificação Professional Scrum Master I (PSM-I)

Eu vou me focar aqui nas certificações da Scrum.org pois foi onde tirei as minhas e sei como funciona tudo em detalhes. A certificação PSM-I é a equivalente CSM (Certified Scrum Master) da Scrum Alliance e mostra que o certificado possui conhecimento teórico completo do framework Scrum e do papel do Scrum Master.

Se preferir ver um vídeo ao invés de ler o texto, segue um trecho do meu curso de Scrum e Métodos Ágeis:

As suas principais características são:

custo de U$150 por tentativa;
somente em Inglês;
somente aborda conceitos vistos no Scrum Guide;
totalmente objetiva, com questões de múltipla escolha e V/F;
média de 85% para aprovação ou 80% para cidadãos cuja primeira língua não é Inglês;
80 questões;
60 minutos para conclusão;

Ao contrário da CSM, a PSM-I não expira e não requer renovação anual. Tirei a minha em 2010 e continua lá no site deles o meu nome até hoje.

Certificação Professional Scrum Product Owner I (PSPO-I)

A certificação PSPO-I é equivalente à CSPO da Scrum Alliance (Certified Scrum Product Owner) e mostra que o certificado possui conhecimento teórico completo do framework Scrum e do papel do Product Owner, bem como de outros princípios mais além relacionados ao desenvolvimento ágil de produtos.

Se quiser ver um vídeo onde falo da certificação para PO, parte do meu curso de Scrum e Métodos Ágeis, segue abaixo:

As suas principais características são:

custo de U$200 por tentativa;
somente em Inglês;
aborda conceitos vistos no Scrum Guide e em outras leituras para POs;
totalmente objetiva, com questões de múltipla escolha e V/F;
média de 85% para aprovação ou 80% para cidadãos cuja primeira língua não é Inglês;
80 questões;
60 minutos para conclusão;

Também não expira.

Dicas de Estudo para as Provas

A dica mais quente que posso dar é decorar o Scrum Guide de ponta a ponta. Ele é a fonte oficial de informação sobre Scrum e é nele que você deve confiar para saber o que é cobrado nas provas sobre o framework Scrum.

A segunda dica de estudo é fazer os simulados presentes no site da Scrum.org, o Scrum Open e o Product Owner Open. Se for fazer a PSM-I, fazer o Scrum Open vai te permitir conhecer algo entre 30-40% da prova (semelhante ao que acontece com as provas do Detran, sabe?) e se estiver fazendo 100% nos simulados, tem grande chance de conseguir passar na prova. Já se for fazer o PSPO-I, recomendo fazer tanto o Scrum Open quanto o Product Owner Open. Os simulados são bem didáticos e possuem questões no mesmo nível da prova, além de serem gratuitos.

A terceira dica é anotar e fazer resumos. Você tem de ter em mãos tabelas e anotações que te permitam rapidamente saber as principais atribuições de cada papel, as características de cada cerimônia (objetivos, timeboxes, etc) e o uso de cada artefato. Você também vai precisar ter a mão a definição do que é o Scrum e quais são seus valores.

Não recomendo qualquer outro simulado ou livro, pois eles podem mais confundir do que ajudar. A única exceção são os excelentes cursos da TI Exames que são preparatórios para as respectivas provas. Já fiz um deles, de Product Owner especificamente, e considerei muito bom, além de outros colegas de trabalho que também tiveram experiência semelhante.

Dicas para Realização da Prova

Como a prova é online, ter os rascunhos e anotações à mão facilita bastante, bem mais do que ter o Scrum Guide, embora este último também seja importante. Somente se inscreva para a prova (você paga e recebe uma senha para poder iniciar a prova) depois de estar tirando 100% em todos simulados que esteja fazendo, consecutivamente.

Quando eu fiz as provas, eu me tranquei em um local fechado, desliguei o celular e avisei minha esposa que eu não poderia ser incomodado sob hipóteses alguma. Você precisa de muita concentração e silêncio, só deixe o celular por perto como backup de Internet, caso sua banda larga dê problema no meio da prova. Usar um notebook também é importante caso falte luz, pois assim você terá a bateria do note para garantir que consiga fazer a prova até o final (ela dura no máximo 60 minutos).

Feche todas as abas do navegador e demais softwares do seu computador. Deixe no máximo um tradutor de Inglês aberto, caso tenha problema com alguma palavra.

Uma última dica é quanto à interpretação das questões: seja o mais literal possível. Não leve para o seu entendimento pessoal ou para qualquer prática que já tenha tido. Se no Scrum Guide diz que a cerimônia x deve ser feita sempre em pé, sim, a resposta é sempre em pé, mesmo que você eventualmente não siga esta regra, só pra citar um exemplo.

Eu também tenho a certificação de Professional Scrum Developer I (PSD-I), pois na época que comecei a trabalhar com Scrum eu ainda era um analista/programador. As regras são praticamente as mesmas, com a diferença que a PSD-I exige conhecimento de práticas de engenharia ágil, principalmente algumas abordadas no framework Extreme Programming (XP). Como tirar esta certificação não é algo muito comum no mercado, resolvi focar o artigo apenas nas duas supracitadas.

Então é isso. Essas são as orientações que eu poderia deixar sobre o assunto e qualquer dúvida que tiver, pode deixar nos comentários que terei o maior prazer em responder.

Na séria de vídeos abaixo, eu falo de Carreira em Agilidade, um tópico que tem tudo a ver com o assunto certificações:

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!