fifNeste post vamos falar sobre Scrum, obviamente. 🙂
Vamos abordar os aspectos principais deste famoso framework de trabalho, mas vamos analisar também alguns pontos que muitos profissionais não enxergam sobre a aderência do Scrum, a viabilidade, forma de empregá-lo etc.
Como sempre recomendo aos meus alunos, leitores e colegas de trabalho, quando falamos em tecnologias, ferramentas, modelos de processo, frameworks (de software ou de produção), sempre devemos aplicar senso crítico em nossa avaliação.
Scrum (por exemplo) serve para todos? Quando aplicar? É aderente ao projeto? A equipe tem condições de absorver? E perguntas como estas, sempre devem ser feitas, a todo momento.
/* Não sei se já pensou sobre, mas na área de produção de software (como em várias outras), é muito comum termos o perfil do Analista “Copista”. Este analista define o que vai usar, como usar etc. simplesmente porque outros profissionais o fazem. E isso não é bom. Toda opção tem que ter sua escolha baseada em critérios justificáveis, plausíveis, e muito dos problemas nos projetos de software decorrem da ausência da aplicação de “porquês* na definição das coisas. O que serve para um um projeto pode não servir para outro, o que serve para uma empresa, pode não servir para outra. */
Scrum é “modinha”
Muito se fala sobre isso. Na Engenharia de Software, quando falamos de métodos, padrões etc. temos também coisas semelhantes à Vaporware.
Não é o caso do Scrum. Scrum não é “modinha”.
Sua criação “de fato” se deu em 1986, e não foi na industria de software, foi na industria de veículos e de bens de consumo. Foi criado um por um Japonês (Hirotaka Takeuchi).
/* Eu realmente sou um grande admirador dos Japoneses (“paixão antiga”). Eles são espetaculares quando o assunto é linha de produção (e outros milhares de outros campos). */
À época, a motivação foi o fato de que, após experiências com um “novo método de gestão e execução”, percebeu-se que equipes menores e multidisciplinares eram mais eficientes e eficazes na produção. E então tudo começou! \0/
Caso queira ver o documento formal da época (em inglês), você pode acessá-lo diretamente no site da Harvard Business Review.
Entretanto, de lá para cá, o conceito original evoluiu, expandiu para o mundo a fora, “na boca do povo” foi misturado com um monte de coisa, foi customizado, xingado, elogiado etc. Mas isso tudo é parte do progresso, graças a Deus!
Agilidade e Scrum
Ágil || Agile || Agilidade
Muito se discute acerca de Agilidade e Scrum. Agilidade não é Scrum, importante isso ficar claro.
Agilidade é um objetivo que sempre existiu (e sempre existirá) em qualquer contexto de produção, de qualquer produto, ou na execução de serviços.
No contexto da produção de software, a ideia de “desenvolver software com agilidade” veio com a criação do Manifesto Ágil.
É um conjunto de princípios e valores, que algumas autoridades técnicas da nossa área entenderam que são recomendadas de serem seguidas para se entregar mais software, de maneira mais eficiente e mais eficaz.
Métodos para “ser” ágil
Para buscar o emprego dos valores e princípios do Manifesto Ágil, e então fazer (mais e melhor) software, naturalmente que precisa-se de algum método, algum “passo a passo”, para que se execute isso e alcance o objetivo.
É possível ser ágil sem Scrum. Hipoteticamente, dá para ser ágil com especificação em papel de pão, codificação no notepad e contato com cliente via megafone. 😯
Mas o Scrum é um meio muito pertinente e relevante para fazer software com agilidade. Mas não é o único.
Então rodou Scrum ficou ágil?
Isso muita gente pensa. Na realidade, como citei anteriormente, não há uma relação direta entre ambos os conceitos.
Uma coisa é um ideal de cultura, uma visão filosófica, estruturada em princípios e valores. Outra coisa é materializar isso na prática.
É possível utilizar-se Scrum e ir na contra mão do Manifesto Ágil.
/* Eu já vi casos onde reuniões de Sprint Review e Sprint Retrospective eram tão longas e burocráticas que não sobrava tempo para se priorizar o backlog (isso semana a semana). */
Scrum != Ágil, mas pode ser um excelente “modus operandi” para se alcançar a agilidade na produção de software.
Visão Geral
Abaixo, algumas definições do “Scrum Guide”, o guia oficial do Scrum (grifos meus):
“Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível”
“Scrum é um framework estrutural que está sendo usada para gerenciar o desenvolvimento de produtos complexos desde o início de 1990. Scrum não é um processo ou uma técnica para construir produtos; em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las.”
Obs.: um detalhe relevante do Scrum é que ele não é uma receita pronta. Na realidade, é orientado ao empirismo (“grosso modo”: tentativa e erro [aprendizado com os erros e melhoria contínua do processo]).
Penso que um dos objetivos mais nobres e pertinentes do Scrum é entregar produto de valor e em pequenos pedaços (incrementos).
Isso se dá através da priorização “iteração a iteração” (iteração no Scrum == Sprint) do escopo do produto, ou seja, se antecipa a produção daquilo que o cliente julga ser mais prioritário para o seu negócio (onde, entregando isso rápido, tendo feedback e melhorando o que foi entregue iteração a iteração, gera-se o tão falado “valor”).
Time
O Scrum tem o conceito de Time, que na prática, é a equipe do Produto, ou do Projeto, cada um com seus papéis bem claros, responsabilidades definidas, auto-organizáveis (se viram sozinhos) e multifuncionais.
/* Um dos grandes empecilhos de se executar Scrum “de fato” é o conflito entre “hierarquia rígida” e equipe “auto-organizável”. Uma equipe com este perfil demanda maior autonomia aos seus membros, e em organizações em que o organograma seja “pouco horizontal”, é quase impossível ter sucesso neste sentido. */
Os times devem ser pequenos (alguns profissionais sugerem 4 pessoas, outros 8, e variando…), pois equipes com muitas pessoas tendem-se a ser mais lentas em comunicação (reuniões, alinhamentos etc.), tornando assim o processo muito burocrático, elevando o overhead da produção.
(Na teoria) Um Time Scrum é composto pelos papéis: Product Owner, Scrum Master e “Equipe” de Desenvolvimento.
Papéis
Product Owner (PO)
É o profissional responsável por “administrar” o escopo do produto (no nosso contexto, produto == software).
É quem entende/deve entender o negócio, quem deve saber tudo do problema do cliente, junto com ele pensar a solução, e traduzir isso para o escopo do produto. Do ponto de vista funcional, também é quem deve melhor entender o software.
O PO é responsável por definir e priorizar o escopo junto ao cliente, manter isso sempre alinhado com o Scrum Master e Equipe de Desenvolvimento, e garantir que o valor seja gerado ao cliente, garantindo que o os itens do Product Backlog (veremos mais à frente) estejam sendo feitos, e feitos da maneira correta.
Considerando a teoria do Scrum, o PO ainda é quem levanta os requisitos e os especifica.
/* Os requisitos contidos em um Product Backlog não possuem um formato específico. Pode-se aplicar a Engenharia de Requisitos tradicional, usar Estórias de Usuário, Casos de Uso, UML ou técnicas semelhantes, desde que se dê condições de traduzir o desejo do usuário ao Time Scrum. É necessário muito bom senso, e senso crítico, neste contexto, pois a melhor forma de especificar o escopo sempre será aquela que gera mais clareza e segurança ao projeto, e é aderente à cultura da empresa e do cliente. */
Scrum Master
Este é um papel que gera mais confusão na cabeça de todos. Como já citado, é importante ficar claro que o Scrum não é uma receita de bolo, e mesmo que fosse, seguir “cegamente” o framework, em completude, pode comprometer a performance de todos.
Segundo a teoria, o Scrum Master não é um Gerente de Projetos, um Coordenador de Equipe, Líder Técnico, um Especialista ou algo do tipo. Ficou surpreso com isso? 🙂
O Scrum Master é, ao mesmo tempo, um Coach do Time Scrum (auxilia na compreensão do framework e sua aplicação, garante que o framework esteja sendo executado por todo o time etc.) e um Facilitador, que deve resolver/remover os impedimentos do a dia; dar condições dos membros do time darem seu máximo em termos de foco, atenção, disponibilidade etc. no dia a dia.
/* Mas teoria é uma coisa, a prática é outra. No dia a dia das empresas que empregam Scrum, geralmente o Scrum Master é alguém com facilidade de relacionamento, visão mais holística de todo o processo de produção, e também, alguém com background técnico. Algumas vezes é o Analista que mais domina o produto, outras vezes, um Gerente de Projetos. Realmente é muito difícil achar no mercado alguma empresa que tenha o Scrum Master realizando seu papel 100% conforme o framework prega. E não significa que assim deve ser… */
“Equipe” de Desenvolvimento
O Scrum não define, na teoria, especificidades para o papel de um membro da “Equipe de Desenvolvimento”.
Isso vai depender de como cada empresa estrutura seus times, conforme seu processo de desenvolvimento de software (ou outro, se for uma empresa de outro segmento).
Este equipe é responsável por entregar os incrementos do produto a cada Sprint. Ou seja, é quem produz a parte mais técnica do software (excetua-se o PO e o Scrum Master).
Dependendo da empresa pode ter uma composição de perfis, onde na mesma equipe, se tem Analistas, Programadores e Testadores. Mas o Scrum recomenda que um time seja multidisciplinar, ou seja, composto por profissionais que façam muitas coisas de maneira bem feita.
/* Aqui temos um ponto que gera muita polêmica. Na nossa área, como já citei em vários posts ou aulas dos meus cursos, sempre houve a definição clara de papéis de membros de uma equipe técnica (Analista, Programador, Testador [este é mais recente] etc.). Atualmente temos novas “figuras”, como o “Desenvolvedor Full Stack” [não o Full “Stack Overflow” – meme abaixo, rs] ou o DevOps. Profissional literalmente polivalente, que seja muito bom em Análise, Front-End, Back-End e Infra-Estrutura, é algo raro. Mas acredito, neste momento, que este seja o caminho no futuro do Analista de Sistemas.* /
Ainda sobre a Equipe de Desenvolvimento, o Scrum prega que os desenvolvedores devem possuir autonomia em relação ao seu trabalho. Isso também é algo muito difícil de viabilizar, considerando a cultura de 90% das empresas.
Eventos (ou “Cerimônias”)
O objetivo de definir Eventos é ter um leque “finito” de opções de reunião, para com base nas opções pré-definidas, se criar uma rotina, e assim, otimizar a produtividade.
Um detalhe super relevante do Scrum, e que eu acho o máximo, é o conceito de timebox.
Isso significa que todos os Eventos do Scrum possuem (ou devem possuir) uma duração máxima. Reuniões intermináveis são um dos piores males da produtividade das empresas, e em empresas de software (ou que possuem área de software internamente) isso é quase um padrão.
/* Pior que as reuniões intermináveis, é a falta de foco, disciplina e objetividade destas reuniões. Como cito sempre aqui no blog e nos meus cursos, comunicação é um desafio em qualquer empresa. E comunicar-se bem não é apenas escrever, ler, ou falar bem. É saber a hora de falar, o que falar, quando se calar, quando não melindrar quando alguém diz “ok, então fechamos. Podemos encerrar?” etc. Não quero dizer que deve ser “Oi! Tchau!”. É fazer o que tem ser feito, de maneira profissional, e avançar. */
Vejamos a seguir os Eventos do Scrum.
Sprint
Sprint é talvez o principal conceito do Scrum.
Um projeto que use Scrum, por exemplo, do ponto de vista de execução (pode ser também de planejamento e gestão) não é dividido em fases, etapas ou algo do tipo. É dividido em Sprints, que devem ser curtas (de uma a quatro semana no máximo), ter uma meta clara, e ser acompanhada conforme as “cerimônias” do Scrum.
Ao fim de cada Sprint, obrigatoriamente deve-se entregar incremento de produto, ou seja, “mais um pedaço” do produto, que é feito Sprint a Sprint (iteração a iteração).
O escopo de um (ou uma) Sprint é definido conforme a priorização do backlog do produto (veja sobre backlog mais à frente).
Sprint Planning Meeting (Planejamento de Sprint)
Nesta reunião todos os papéis devem participar (Product Owner, Scrum Master e Equipe de Desenvolvimento).
Além destes, devem também participar stakeholders (partes interessadas) do cliente, como usuários chave, usuários do produto ou outros profissionais que tenham interesse/contribuição a realizar, do lado do cliente.
Neste Evento se define o escopo do Sprint, onde Escopo do Sprint = Incremento do Produto que deverá estar pronto ao fim do Sprint.
O tempo recomendado pelo Scrum para este evento depende do timebox do Sprint, proporcionalmente. Abaixo exemplos:
- TimeBox: 4 semanas. Tempo: 8 horas.
- TimeBox: 3 semanas. Tempo: 6 horas.
- TimeBox: 2 semanas. Tempo: 3 horas.
- TimeBox: 1 semana. Tempo: 2 horas.
Recomenda-se que a reunião seja dividida em duas partes iguais (50% do tempo para cada parte), sendo:
- 1ª parte: O que será entregue ao fim do Sprint.
- 2ª parte: O que será feito para realizar tal entrega, e como será feito.
/* Existe um conceito importante chamado “Definition of Done” ou “Definição de Pronto”. Não vou estender neste conceito aqui, mas basicamente, trata-se de definir e deixar super claro o que significa “pronto” para o time, para então, amarrar isso ao conceito de “conclusão dos trabalhos”. Lembrando que, como qualquer iteração de projeto de software, um Sprint deve ser dado como “concluído” com a entrega de um “pedaço” de software executável, não se aplica entregar apenas documentação, testes, análises etc. Se assim for, não é iterativo e incremental, de fato. */
Daily Scrum (Reunião Diária)
Este evento é um dos mais interessantes, e o que demanda maior disciplina para não perder o foco.
A reunião diária é realizada todos os dias durante a execução do Sprint (por exemplo, se o Sprint for de uma semana, a reunião diária ocorrerá Segunda, Terça, Quarta, Quinta e Sexta).
Esta reunião deve ocorrer sempre no mesmo local e no mesmo horário, para otimizar a produtividade, e cada membro da Equipe de Desenvolvimento deve responder a três perguntas, de maneira objetiva (mas não é “Oi! Tchau!) a três perguntas, na ordem a seguir:
- O que foi completado desde a última reunião?
- O que será feito até a próxima reunião?
- Quais os obstáculos que estão no caminho?
O objetivo desta reunião é acompanhar o desenvolvimento do Sprint (evolução da “queima” do backlog), dar visibilidade ao Product Owner sobre como anda a evolução do incremento do produto, e dar visibilidade ao Scrum Master sobre possíveis impedimentos que a equipe possui, e que devem ser removidos.
/* Há um pouco de confusão sobre a finalidade da reunião diária. Algumas literaturas, empresas ou profissionais dizem que “não é uma reunião de status”, mas na prática é isso mesmo. Se passa um status de “como andam as coisas”, o que está havendo de negativo e se dá perspectiva a todos sobre as possibilidades de êxito do Sprint. */
O timebox desta reunião deve ser fixado, obviamente. Não há uma recomendação na teoria sobre o tempo limite desta reunião.
Penso que o tempo deve ser proporcional ao tamanho do time Scrum, onde recomendo:
- Times de 2 a 5 pessoas: 15 minutos.
- Times de 5 a 9 pessoas: 25 minutos (no máximo).
- Times maiores que 9 pessoas (aí é problema, sugiro repensar a distribuição dos profissionais em equipes menores). 😕
Uma observação fundamental: recomenda-se fazer esta reunião “de pé”, não sentado. Isso é uma “técnica” para que as coisas “acelerem”. Na real, é: de pé se cansa mais rápido, e se agiliza o assunto. Mas, obviamente temos que ter bom senso; isso é uma ideia que não cabe em todo lugar.
Sprint Review (Revisão de Sprint)
Esta reunião é realizada ao fim do Sprint, e tem como objetivo inspecionar o incremento do produto (“pedaço” do produto produzido durante o Sprint).
Nesta reunião o Product Owner avalia o que realmente foi feito do Backlog do Produto, inspecionando mesmo, para garantir aquilo que realmente foi entregue.
A Equipe de Desenvolvimento responde aos questionamentos do PO sobre isso, colocando ponderações acerca do que foi entregue de fato, o que não foi, porque não foi etc.
Nem sempre um Sprint é concluído conforme o planejado.
Nem sempre os incrementos do produto previsto para estarem prontos num Sprint ficam prontos.
Na reunião de revisão do Sprint isso deve ficar claro, e deve servir de input (entrada) para o próximo Sprint, considerando sempre aquilo que “ficou por fazer” no Sprint anterior, por exemplo.
O tempo recomendado pelo Scrum para uma Sprint Review depende do timebox do Sprint, proporcionalmente. Abaixo exemplos:
- TimeBox: 4 semanas. Tempo: 4 horas.
- TimeBox: 3 semanas. Tempo: 3 horas.
- TimeBox: 2 semanas. Tempo: 2 horas.
- TimeBox: 1 semana. Tempo: 1 hora.
Sprint Retrospective (Retrospectiva de Sprint)
Esta reunião ocorre/deve ocorrer após a reunião de Sprint Review.
/* Depois != mesmo dia. Fazer muitas reuniões num mesmo dia é desgastante, tira energia e foco. Sugiro fazer esta reunião no dia seguinte à Sprint Review, para todos refletirem sobre a revisão do Sprint, estarem mais bem dispostos etc. O tempo entre as duas reuniões é fundamental para as coisas “encaixarem na mente”, do contrário, será apenas “protocolar”, o que não é o objetivo do Scrum, ou do Agile. /
Ainda, deve ocorrer antes da reunião de planejamento do próximo Sprint, pois sua saída (saída de reunião == resultado produzido como produto da reunião) deve servir de input (entrada) para o planejamento posterior, como “lições aprendidas”. O foco deve ser em:
- Analisar como foi o andamento do último Sprint em relação ao processo (rodou legal, não rodou legal, muitos impedimentos, gargalos etc.).
- Analisar, sob o ponto de vista de execução técnica, o que foi produzido, o que não foi, porque foi, porque não foi etc.
- Compilar esta avaliação e definir formas de melhorar o processo de execução, as pessoas e a tecnologia aplicada, para que os próximos Sprints tenham maior sucesso.
/* Indiretamente o Scrum prega a Melhoria Contínua. Através dos constantes feedbacks, captura-se informação relevante para melhorar seguidamente, e no curto prazo. Isso é muito legal, e uma cultura de transparência é algo essencial para que isso se dê, de fato. */
O tempo recomendado pelo Scrum para este evento depende do timebox do Sprint, proporcionalmente. Abaixo exemplos:
- TimeBox: 4 semanas. Tempo: 4 horas.
- TimeBox: 3 semanas. Tempo: 3 horas.
- TimeBox: 2 semanas. Tempo: 2 horas.
- TimeBox: 1 semana. Tempo: 1 hora.
Artefatos
Os dois principais artefatos do Scrum são: Product Backlog e Sprint Backlog. Abaixo informações sobre ambos.
Product Backlog (Backlog do Produto)
O Product Backlog é o escopo do Produto. Neste artefato contém todo o escopo que deve ser produzido, recomenda-se ser a única fonte de requisitos do produto, para realmente poder ser a referência maior do time Scrum.
O responsável por este artefato é o Product Owner (PO), é a única pessoa que deve ter autonomia para mantê-lo.
Um dos trabalhos do PO sobre este Backlog é cuidar de sua priorização, onde, conforme alinhamento com a equipe do negócio, vai se definindo aquilo que é mais importante no momento, que gera maior valor para o negócio, e então os requisitos prioritários vão sendo inseridos no backlog dos Sprints vindouros (falo sobre isso no tópico posterior).
Detalhado ou Não?
No backlog do produto está a lista do que deve ser feito para o produto estar pronto. Mas nem tudo estará detalhado no início de um projeto.
Recomenda-se detalhar os requisitos conforme a priorização aplicadas. Muita coisa pode ser apenas “desejo”, e pode-se ter uma lista de “desejos” em algo nível, algo macro.
Á medida que os “desejos do cliente” vão sendo priorizados, ou sejam, passam para o início da fila de execução, então vão sendo detalhados. Vejamos:
- O cliente quer uma funcionalidade (chamada popularmente de feature em times Scrum) para “Visulizar Log de Operações Sensíveis”. Enquanto isso não é priorizado, fica em alto nível no backlog do Produto.
- Quando for priorizado deve ser detalhado, pois ninguém consegue construir algo somente com a informação “Visulizar Log de Operações Sensíveis”. Neste momento, por exemplo, se produz requisitos funcionais e não funcionais, regras de negócio, divide-se a funcionalidade em uma ou mais, ou uma com várias funções etc.
- No momento do detalhamento, aplica-se a técnica utilizada na empresa, seja Engenharia de Requisitos, Casos de Uso, Estórias de Usuário, prototipação, UML, ou várias destas combinadas.
Esta lista (backlog) deve sempre estar ordenada por prioridade. Itens com maior prioridade no início da lista e detalhados, itens com menor prioridade, fim da lista e não detalhados (nesta parte cabem ressalvas, rs).
E também, cada item detalhado (já priorizado e próximo de ser executado) deve ser estimado, possuir o dimensionamento dos recursos necessários (prazo/esforço/custo) para sua execução. Sem isso, não tem como planejar um Sprint.
Para realização das estimativas, o Scrum não tem recomendação na teoria. Pode-se utilizar o que for melhor para equipe, seja Análise por Pontos de Função, Opinião de Especialista, Pontos por Caso de Uso, Planning Poker etc.
/* Muitos profissionais que cegamente aderem ao Scrum pensam que apenas “técnicas ágeis” de dimensionamento devem ser aplicadas neste contexto. Estimar software é uma arte/ciência que poucos dominam. Não há receita pronta, existem técnicas que devem ser cuidadosamente analisadas, e aquela que for mais assertiva para o time e empresa, é a que deve ser aplicada. Não existe moda, existe eficiência e eficácia, focando resultado justo para todos. */
Incremento do Produto apenas?
Definitivamente, não. A construção, na prática, demanda entregas menores que apenas um “pedaço do produto”. Num Backlog de Produto os “pedaços menores” podem ser agrupados como:
- Epic (ou Épico): são os incrementos mais macro, os itens do backog que não se enxerga muito bem ainda (pela não priorização e pouco detalhamento), e são “grandes demais ainda”, por isso são chamados de épicos.
- Feature (Funcionalidades): são os incrementos já priorizados, já detalhados.
- Work Itens (Itens de Trabalho): aqui meio que “entra de tudo”. No contexto de produção de software, podem ser tarefas necessárias para se viabilizar uma funcionalidade (definição de arquitetura, modelagem de dados, correção de bugs, implementação de regra de negócio etc.).
Sprint Backlog (Backlog do Sprint)
Basicamente, é o escopo do produto que foi priorizado (já deve estar detalhado) e selecionado para ser implementado no próximo Sprint, que se tornará ao fim deste, um incremento do Produto.
O Product Owner, junto com o time, define o que será escopo do Sprint Backlog, e então na reunião de Sprint Planning isso será definido como a meta a ser perseguida.
Importante lembrar que apenas itens “priorizados e detalhados” do Product Backog (Features e/ou Work Itens) devem entrar em no escopo de um Sprint.
Durante a execução do Sprint o objetivo é queimar este backlog, ou seja, trabalhar para ir concluindo item a item do backolog do Sprint. Uma ferramenta muito utilizada para isso é o Burndown Chart (imagem abaixo), pois dá uma boa visibilidade da realização do Sprint Backlog, analisando o consumo do esforço projetado no tempo.
Importante lembrar que esta não é uma ferramenta definida pelo Scrum. É uma prática recomendada, não regra! Você pode fazer do jeito que achar melhor, desde que extraia o valor necessário para o seu melhor controle da evolução da queima backlog.
Burndown Chart pode ser utilizado tanto para acompanhar a evolução da queima do Sprint Backog, como também, do Product Backlog, como abaixo:
Finalizando
Com este post espero realmente ter gerado valor para seu progresso profissional. Scrum é algo muito legal, mas “uma faca afiada na mão de um açougueiro é ferramenta excelente, na mão de uma criança, pode gerar problemas sérios”.
Pense sempre a respeito, e lembre-se que:
- Metologia || Ferramenta || Framework não trabalham sozinhos.
- Paradigma inovador demanda cultura inovadora.
- Tudo custa dinheiro e os recursos são escassos. Antes de implementar, pense muito.
- Não seja “Analista Copista”, saiba o que está fazendo, porque está fazendo. Senso crítico sempre!
- Scrum pode ser customizado. Se a “letra” não cabe na sua empresa”, extraia o “espírito da letra”.
Sinta-se à vontade para participar dos comentários, à medida que o post demandar revisões, faremos. Afinal, até o momento, é o que cremos ser o melhor.
Grande abraço!