O que é Scrum?

Atualizado em 07/04/2019!

Conheço e aplico métodos ágeis desde 2010, principalmente o framework empírico Scrum. Durante o final da minha faculdade a empresa onde trabalhava, RedeHost, necessitava urgente de uma reorganização dos seus processos de desenvolvimento de software e queriam que eu me tornasse um de seus líderes de desenvolvimento. Obviamente agarrei a oportunidade, que foi muito importante para minha carreira, e isso me rendeu uma ida à São Paulo participar da segunda turma de um treinamento latino-americano oficial da Scrum.org para desenvolvedores Scrum. O treinamento de uma semana foi incrível e me capacitou para tirar duas certificações na área de gerenciamento de projetos com métodos ágeis e passei a atuar como facilitador do framework Scrum na empresa, em treinamos e em consultorias (como esta).

No artigo de hoje resumo o famoso Scrum Guide, o livro de apenas 19 páginas que detalha tudo o que você precisa saber sobre o Scrum antes de passar a aplicá-lo em seu time de produto. No fim do artigo você encontra os slides de um treinamento que eu aplicava, disponíveis no Slideshare.

Caso queira saber mais sobre o meu trabalho com Scrum, dê uma olhada em meu livro ou em meu curso online.

O que é Scrum?

A definição formal, cunhada pelos criadores Ken Schwaber e Jeff Sutherland, diz que:

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.

Entenda um framework como uma caixa de ferramentas. Scrum não é algo pronto que resolve todos seus problemas, mas sim um conjunto de processos que norteiam o desenvolvimento de produtos complexos.

Apesar de leve e simples de entender, Scrum é extremamente difícil de dominar, uma vez que envolve rigidez em sua aplicação. Implementações de Scrum que não seguem as regras previstas em seu manual são o que chamamos de Scrum flácido, e tendem a não alcançar o potencial máximo da metodologia.

Mas por que confiar e seguir cegamente este framework?

Scrum é um processo empírico, baseado pura e simplesmente nas experiências passadas de seus criadores que desde o início da década de 90 aplicam Scrum em projetos de software com sucesso, já sendo uma das metodologias ágeis mais usadas no mundo. E uma vez que você se torna adepto do Scrum, o empirismo passa a fazer com que você respeite o processo cada vez mais e adicione novos processos e artefatos complementares baseados nas SUAS experiências com o mesmo.

Os Pilares

O Scrum se baseia em três pilares de sustentação, suas ideologias:

Transparência: aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados.

Inspeção: os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas.

Adaptação: se um ou mais aspectos de um processo desviou para fora dos limites aceitáveis ou produto não será inaceitável, o processo ou o material sendo produzido deve ser ajustado.

Existem ainda, em versões mais modernas, cinco valores: comprometimento, coragem, respeito, foco e abertura.

Sobre estes pilares o framework Scrum divide-se em papéis, eventos e artefatos.

Papéis

Os papéis dentro do time Scrum são:

Product Owner

É o responsável pelo ROI (retorne sobre o investimento) do projeto, é responsável por gerenciar e priorizar o Product Backlog (veja mais abaixo) e para que o Scrum funcione e ele consiga trabalhar, toda a organização deve respeitar as suas decisões. No mundo mais tradicional da gestão de projetos, o P.O. seria o Gerente de Produto (Product Manager), embora em grandes empresas, existam diferenças entre esses dois papéis.

O P.O. é membro do Time Scrum e deve estar presente e disponível para solucionar dúvidas do time em relação ao produto e ao backlog. Se esse papel for assumido por alguém da empresa do cliente, esta pessoa idealmente dever ter um canal de comunicação ininterrupto com o time de desenvolvimento, para que ele possa avançar sem atrasos.

Desenvolvedores

São os responsáveis por desenvolver o produto. O time de desenvolvedores (que não precisa e não deve ser composto apenas por desenvolvedores) é auto-gerenciável, multifuncional e compartilham a responsabilidade pelo sucesso ou fracasso do projeto.

O time de desenvolvimento é quem decide o quanto consegue entregar a cada iteração, para que haja comprometimento com a entrega.

Scrum Master

É o responsável por aplicar e garantir a adoção do Scrum dentro da equipe e até mesmo dentro da organização onde estão inseridos. Cabe ao Scrum Master, que é um líder-servidor, liderar o time para que os objetivos do Product Owner sejam alcançados e para que o time de desenvolvimento consiga avançar sem impedimentos, removendo-os quando necessário.

Todos os eventos Scrum são facilitados pelo Scrum Master da equipe, que idealmente não deve ter outra função paralela no time Scrum.

Eventos

O Scrum chama seus eventos de time-boxes, uma vez que são eventos de duração fechada. Um evento pode ser encerrado em tempo menor do que o previsto, mas nunca maior, e o Scrum Master deve garantir isso enquanto facilitador dos eventos. Permitir a extrapolação cria um sentimento inconsciente de impunidade e faz com a equipe não respeite os objetivos e o planejamento da Sprint. Por sua vez, falhas constantes em entregar os objetivos de uma Sprint forçarão o time de desenvolvimento em serem mais eficientes no planejamento, focarem mais nos objetivos e se comprometerem de maneira mais coerente com as entregas.

Sprint

As sprints são time-boxes de 1 mês ou menos e são o coração do Scrum. Durante o período da Sprint um incremento utilizável do produto é criado. Mas nem só de desenvolvimento vive a Sprint, fazendo parte da mesma também o planejamento, as reuniões diárias, a revisão e a retrospectiva.

Sprint Planning

Time-box de 8h para uma sprint de um mês, ou menos tempo de acordo com o tamanho da Sprint. Nesta reunião é onde o Product Owner é ouvido em relação às prioridades e os objetivos desta Sprint. É nela também onde o time irá deliberar sobre o que conseguem fazer nesta sprint em relação às necessidades do P.O., formalizando o Sprint Backlog, ou lista de coisas que serão feitas no próximo mês.

É comum o uso de artefatos externos ao Scrum nesta fase, como o Planning Poker, usado para estimar o custo de tarefas a serem realizadas. O ideal é que independente da técnica usada para estimar (pontos de história, por exemplo), que cada tarefa não ocupe um membro do time por mais de um dia. Se isso acontecer, veja como pode quebrar a tarefa grande em tarefas menores.

planningpoker

Outro artefato muito popular, que também não é do Scrum, é o kanban (especialmente usando Trello), um board onde temos colunas com cards, onde em cada card temos uma tarefa a ser realizada, previamente estimada. Cada coluna representa um estágio do ciclo de desenvolvimento de uma tarefa, tais como: TODO (para fazer), DOING (fazendo), Testing (testando) e DONE (pronto).

kanban-board-e60650d1-1

Daily Scrum

Time-box de 15 min que deve acontecer diariamente, sempre no mesmo local e horário para gerar consistência e evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e que popularmente é feita em pé (para evitar prolongamentos e distrações), cada membro do time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo.

A reunião diária é o método mais eficaz de alinhamento dos membros do time que tive a oportunidade de experimentar. Ela permite a descoberta rápida de problemas e desvios de curso e suas respectivas correções, por isso deve ser respeitada.

burndown-chart-formula

Artefatos possíveis de serem usados nessas reuniões incluem um Burndown Chart, que nada mais é do que um gráfico de features a serem desenvolvidas (eixo y, vertical) versus tempo da Sprint (eixo x, horizontal). Um Burndown Chart sempre visível garante o dia inteiro, todos os dias, que todos sabem o quanto falta para terminarem a sprint, e caso estejam longe do seu objetivo, de resolverem os problemas. A ideia aqui não é analisar o Burndown Chart na reunião diária, que é curta e deve se manter assim, mas apenas acompanhar rapidamente, também de maneira diária, o progresso do time.

Esse evento é um dos que representam o pilar de inspeção do Scrum.

Sprint Review

Time-box de 4h para sprints de 1 mês onde o incremento do produto, que está pronto pra uso, é apresentado ao Product Owner para apreciação. Também é na review (que deve ser facilitada pelo Scrum Master) que o Product Owner apresentará os números, gráficos e tudo o mais que for importante à equipe saber sobre o produto. Novas prioridades, movimentos do mercado, etc, tudo focado em manter os objetivos coerentes ao longo das sprints.

Essa é o evento que melhor representa o pilar de inspeção do Scrum.

Sprint Retrospective

Time-box e 3h para sprints de 1 mês onde o time de desenvolvedores e o Scrum Master (que atua apenas como facilitador) falam sobre os resultados obtidos na Sprint que passou e as lições tiradas a partir daí, para melhorar o processo, fortemente arraigado ao pilar de adaptação. Trato em mais detalhes desta importante reunião neste post.

Artefatos

O Scrum determina alguns poucos artefatos:

Product Backlog

Lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. Gerenciado única e exclusivamente pelo Product Owner, que o faz a todo momento, o product backlog deve ser mantido longe do time de desenvolvimento, para evitar dispersão.

Muitas empresas tem usado a ferramenta Trello para seus products backlogs. Já usei muito, mas atualmente uso só o Visual Studio Online ou o Jira.

Sprint Backlog

Uma versão reduzida de backlog apenas com os itens que devem ser desenvolvidos nesta Sprint, retirados do backlog original. Também pode ser organizada em formato de kanban no Trello, mas em um board separado do Product Backlog.

Cabe ao time de desenvolvimento montar o Sprint Backlog com base nas prioridades do Product Owner e é sua responsabilidade dar cabo de todos itens até o fim da sprint, servindo o Scrum Master como um facilitador para que nada interrompa o ciclo de desenvolvimento.

Conclusões

É isso. O Scrum Guide tem apenas 19 páginas e esse post umas 2000 palavras. O Scrum é pequeno, mas difícil de ser posto em prática porque exige muita disciplina. Nos treinamentos que ministro aplico sempre um exercício prático aos alunos para enriquecer a experiência e vivenciar na prática, mesmo que por poucas horas, como funciona o ciclo de desenvolvimento de um produto usando Scrum.

Boa sorte aplicando o Scrum em sua empresa!

* 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!

 

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Zona de Conforto: Neymar, Evaristo Costa e eu

Neymar
Neymar

O que o Neymar, o Evaristo Costa e eu temos em comum? Decidimos sair da zona de conforto recentemente.

Calma, já explico.

O Neymar, que era titular absoluto do Barcelona, campeão da Champions League e a atenção de toda mídia esportiva possível, decidiu largar o Barça e ir para o PSG, um time “inferior”, sem títulos expressivos a nível internacional, para construir história e claro, ganhar mais também, embora eu acredite que dinheiro não tenha sido o principal fator pra ele, considerando o quanto já ganhava no time catalão.

Neymar queria sair da sombra de Messi e buscar o título de melhor jogador do mundo, algo que estava bem complicado junto ao Barcelona.

Evaristo Costa, que embora não seja tão famoso mundialmente quanto Neymar, é muito famoso por quem assiste o Jornal Hoje, um noticiário diário próximo da hora do almoço que ele apresentava com Sandra Annenberg há 14 anos. Pois é, o Evaristo também estava em uma posição super confortável, assim como o Neymar, ganhando muito bem como âncora do telejornal e decidiu sair da maior emissora do país para tocar outro projeto ligado a entretenimento em uma emissora concorrente (é o que estão dizendo por aí).

Sim, ele também vai ganhar mais lá, mas acredito que o principal fator foi a sua vontade de fazer algo novo e diferente, de ser desafiado ou pôr em prática seus sonhos e aspirações que o jornal não permitia.

Se o assunto for fama, eu nem deveria estar nessa lista, mas confesso que me identifiquei com as atitudes recentes do Neymar e do Evaristo pois eu mesmo estava chateado com a zona de conforto na qual estava há alguns meses.

Evaristo Costa
Evaristo Costa

Meu último desafio

Em 2015 eu estava encerrando as atividades com minha startup Busca Acelerada e apenas lecionava à noite quando topei aceitar o desafio de ser o Gerente de Projeto de uma startup chamada Route. O desafio era imenso pois a startup já rodava no vermelho, sem um único cliente, há 3 anos e um beta que parecia eterno pois o escopo do projeto nunca era definido.

Não precisei pensar muito para aceitar a oferta que era boa não apenas financeiramente, mas para o meu currículo. Ao que tudo indicava, minha experiência anterior como CEO de uma startup fracassada poderia evitar que esta fracassasse também.

Durante um ano e meio gerenciei o projeto, ajudei a fechar o escopo do produto, ajudei a fechar com algumas dezenas de clientes e até mesmo meti a mão no código para entender melhor como o produto funcionava, tendo sido responsável pelas integrações com diversas ferramentas do mercado que nos ajudaram a converter mais clientes.

A situação era preocupante pois queimávamos R$40 mil por mês e o faturamento era ridiculamente baixo. Tracei algumas estratégias que envolviam pivotar nosso produto para nichos mais específicos mas não consegui convencer o CEO, que também era nosso investidor, de que o projeto ainda tinha futuro e ele foi encerrado um ano e meio depois de eu entrar na equipe. Quatro anos e meio depois da startup ter sido fundada.

Foi a segunda vez que vi uma startup afundar comigo dentro, mas não fiquei nem um pouco triste pois o desafio foi muito interessante, aprendi muito no processo, fiz novos amigos, agregou no meu currículo e o salário não era ruim. 🙂

O problema veio após o Route ser encerrado.

Route
Route

Entrando na zona de conforto

O CEO do Route também é o CEO da Umbler, startup de cloud hosting que está crescendo rapidamente no mercado nacional e está em vias de expansão para outros países ainda este ano.

O Route foi encerrado não apenas por ser um projeto que estava dando prejuízo, mas porque o CEO teve de escolher um projeto para se focar, e ele fez a escolha mais óbvia (e correta): a Umbler. Com isso, o projeto do Route foi encerrado e toda equipe foi absorvida no time da Umbler.

Foi nos dada uma pergunta bem simples para ser respondida: o que vocês querem fazer na Umbler?

As respostas não podiam ser mais óbvias: quem era do marketing, quis ir para o time de marketing. Quem era designer, foi pro time de front-end. E assim por diante, escolhas “seguras”.

No entanto, a Umbler já tinha um Gerente de Projeto, posição que eu ocupava no Route e eu tinha uma sinuca de bico pela frente: ou eu voltava a ser desenvolvedor (ou seja, uns dois passos para trás na minha carreira) ou “inventava” alguma coisa para eu fazer lá dentro.

Claro, eu também podia recusar entrar pra Umbler e voltar pro mercado, mas como estava lecionando em Gravataí à noite, era muito cômodo que o emprego diurno também fosse em Gravataí.

Eu devia ter associado que optar pelo que fosse mais confortável me deixaria em uma zona de conforto rapidamente, mas na ocasião não me ocorreu isso.

Umbler
Umbler

Atuando em uma posição de conforto

Acabei optando por sugerir uma posição de evangelismo técnico dentro da Umbler pois era uma posição disponível e que eu me encaixava muito bem. Como eu já faço esse tipo de trabalho como autor de livros, escritor aqui no blog, palestrante há 7 anos e estou começando com videoaulas, achei que seria o melhor a fazer. Na verdade era uma das poucas opções que eu via para mim à época sem ter de competir com a galera que já estava estabelecida na Umbler e que são meus amigos. Detesto competir com amigos. 🙁

Pra quem não sabe, cabe ao evangelista técnico levar ao mercado as inovações tecnológicas e tecnologias utilizadas e criadas pela empresa que ele representa. Como evangelista técnico de uma empresa de cloud hosting, cabia à mim educar nosso mercado sobre desenvolvimento web, ajudando a tornar a Umbler referência no assunto.

E foi muito legal, durante meio ano.

Não me entenda mal, amo ir a eventos, conversar com outros desenvolvedores, palestrar, ministrar workshops, escrever artigos e fazer videoaulas. Sério.

Mas não curti nem um pouco fazer “só” isso. Além disso, estar distante de projetos de software de verdade durante 6 meses me deixou muito preocupado. Para não enferrujar, eu “entrei” pra dentro de artigos técnicos, criei muitos projetos aleatórios e estudei muita coisa que não tinha lá muita coesão, mas que me pareceu importante saber caso eu precisasse voltar a programar “de verdade”.

Sempre critiquei os evangelistas técnicos que só enchiam linguiça, que não sabiam programar de verdade e que não conseguiam responder pergunta alguma mais avançada que o conteúdo da sua palestra. Certamente você já deve ter ido em alguma palestra assim, e é horrível. Um bom palestrante técnico é um profissional técnico, não um marketeiro. Sempre me considerei um bom professor e palestrante justamente por ter larga experiência de mercado como desenvolvedor, analista e até mesmo gerente de projetos (embora tenha bem menos experiência nessa função), resumindo: eu falo a mesma língua da minha audiência e sei as “dores” deles.

Eu estava com muito medo de me tornar um “programador de palco”. E se eu ficasse um ano ou dois como evangelista, será que conseguiria voltar a ser gerente ou analista caso necessário? Ou até mesmo um programador?

Fui aí que me deparei com uma dúvida ainda pior: eu estou crescendo como profissional? E a minha resposta foi rapidamente um não.

Zona de conforto = zero crescimento

Ler muitos artigos técnicos, fazer diversos projetos de exemplos e falar com muitas pessoas sobre o que você estuda e escreve não o faz um bom profissional. Isso é a “cereja do bolo”. Um bom profissional na área de TI, na minha opinião, é o que aplica corretamente o que estuda, caso contrário, é apenas um teórico.

Além disso, estar estagnado na área de TI é algo excepcionalmente pior do que muitas outras áreas, pois você não fica “estacionado”, mas é considerado “atrasado” rapidamente, ou seja, é muito mais nocivo do que parece à primeira vista.

Outra coisa que logo reparei e que me deixou muito apreensivo é que minha função primordial era ensinar. Mas o que eu estava aprendendo no processo? Com quem eu estava aprendendo alguma coisa?

Eu tenho 29 anos anos e 11 de TI, mas não sou nenhum “deus da programação” como alguns brincam por aí, tenho muito a aprender ainda, muito o que crescer. Estou muito longe de atingir todo o meu potencial e cada dia que passa que não aprendo algo novo é um dia perdido para mim. E caso você não saiba, aprender é muito diferente de estudar. E eu estava apenas estudando para criar os materiais necessários da minha função.

Note que, em nenhum momento, estou culpando a Umbler ou o CEO dela por isso. Foi uma decisão minha me tornar evangelista técnico em tempo integral. Fui eu que me meti nessa.

Fui aí que me surgiu a pior dúvida nos últimos anos: será que ainda sou “empregável”?

Alerta vermelho: zona de conforto!

Há 11 anos que trabalho com TI e em todo esse período fiquei desempregado durante apenas 3 dias. Sempre tive uma alta taxa de empregabilidade, sempre recebi ofertas mesmo sem estar procurando e isso em grande parte pois sempre me esforcei em ser um profissional diferenciado.

Quando pintou a desconfiança de que eu poderia estar perdendo essa característica que tanto me orgulho (sem falsa modéstia, por favor), eu surtei.

A posição de evangelista técnico não é lá muito comum e se eu continuasse me focando nela nos próximos anos ficaria extremamente dependente da empresa atual e das demais empresas que possuem essa posição disponível (que não são muitas aliás). Além disso, cada vez mais me distanciaria de tocar projetos de desenvolvimento que inclui as habilidades que demorei uma década para refinar: análise, desenvolvimento, gerenciamento, etc.

Ou seja, eu estava em uma posição confortável no presente, mas como toda zona de conforto, com um futuro incerto.

Eu não sou do tipo que fica procurando vagas de emprego, nunca fui (exceto quando estava tentando entrar no mercado de trabalho). Na verdade eu costumo olhar as vagas em busca de oportunidades para meus alunos. Se você me segue nas redes sociais já deve ter visto eu postando vagas, especialmente para iniciantes.

Em uma dessas buscas para ajudar o próximo me deparei com uma vaga que me chamou a atenção: coordenador técnico mobile, em uma banco de Porto Alegre, o Agiplan.

Agiplan
Agiplan

Descobrindo uma nova oportunidade

Nunca pensei em trabalhar em um banco antes, sempre me pareceu algo burocrático, chato, engessado e pouco inovador. No entanto a vaga era bem enfática em afirmar que o banco Agiplan estava justamente buscando mudar essa visão que todos desenvolvedores possuem dos bancos. Que estavam investindo pesado para mudar essas cultura, desde o ambiente até as posições. Claro que eu não acreditei nisso de primeira.

Fui investigar o site da Agiplan. Procurei funcionários no LinkedIn. Encontrei amigos em comum. Fiz todo o dever de casa que alguém que não quer entrar em uma roubada deve fazer.

Conversando com pessoas próximas que possuem vínculo com a Agiplan descobri que a financeira com 18 anos de existência havia se tornado banco há pouco mais de um ano, o que era bom, pois ainda não possuíam os vícios dos demais bancos. Descobri que o banco é de apenas um dono, o que é excelente, pois agiliza e muito a tomada de decisão. Descobri que eles estavam “roubando” talentos de diversas outras empresas ligadas à dinheiro, como pessoas importantes da Elo, da Caixa, PagSeguro, Santander, etc. E que eles pagavam bem e tinham PPR, o que não faz mal a ninguém, não é mesmo?!

Mas daí me surgiu a dúvida: será que eu conseguiria entrar como coordenador técnico mobile?

Atualizei meu currículo (que tem apenas uma página e sempre terá) e apliquei para a vaga que exigia pós-graduação e muita experiência na área. Conversei com algumas pessoas influentes lá dentro para que meu CV chegasse nas mãos certas e fiquei no aguardo. Depois de alguns dias sem resposta é fácil perder as esperanças, mas logo veio um desafio técnico que eu prontamente fiz da melhor maneira que pude com o tempo que me foi dado.

Depois vieram as entrevistas. Muitas delas. Eu estava de férias da Umbler e durante vários dias tive de interromper meu descanso para ir à sede da empresa que fica em um bairro nobre de Porto Alegre para conversar com diferentes gestores. Não é todo dia que se tem a oportunidade de ajudar na criação de um novo banco e eu não queria perder essa oportunidade, estava muito interessado na posição.

Finalmente fui aprovado no processo seletivo e me foi dada uma oferta bem generosa para sair da minha zona de conforto. Melhor do que passar na seleção foi o sentimento de saber que ainda estou no controle da minha carreira.

Mas quem pensa que tudo são flores, está redondamente enganado, e essa é a melhor parte.

Novos desafios. Enormes desafios.

Mario Sérgio Cortella diz que “mudar é complicado, mas acomodar é perecer” e é exatamente isso.

Eu estava em uma zona de conforto enorme: ganhava razoavelmente bem, morava a 15 minutos do serviço, trabalhava apenas com amigos (incluindo o CEO da Umbler) e em um cargo extremamente fácil para mim, que pouco me desafiava. Meus alunos da faculdade diziam que eu tinha o emprego dos sonhos, hehehe.

Saio da Umbler para trabalhar em outra cidade, com uma equipe completamente nova em uma empresa extremamente competitiva em um mercado dos mais competitivos: o bancário. Não há certeza alguma de que trabalhar no Agiplan é tão legal quanto dizem e que conseguirei coordenar a equipe do jeito ágil que gosto de fazer. A única certeza é o desafio.

E é o desafio enorme que se abre à minha frente que me motivou a aceitar a oferta, muito mais do que o dinheiro que me foi oferecido para trocar de empresa. Porque se eu conseguir transpor esses desafios crescerei como profissional, e muito.

Aliás, ao que tudo indica eu não trabalharei na posição a qual submeti, de coordenador técnico mobile, mas sim em algo ainda mais abrangente chamado Especialista de Sistemas, posição responsável não apenas por coordenar o desenvolvimento dos apps, mas pelo Internet Banking deles também.

Se isso não é desafio o bastante para não entrar em uma nova zona de conforto por um bom tempo, não sei dizer o que é!

Sem arrependimentos, apenas alegrias

Tenho o orgulho de dizer que sempre coube a mim direcionar a minha carreira para onde eu quisesse. Para isso, claro, já tive de abrir mão de salários maiores, recusar propostas ou mesmo me demitir algumas vezes. Tudo para não sair do caminho que decidi trilhar há 11 anos atrás.

Obviamente nem sempre acerto e esses últimos 6 meses, que eu chamo agora de “etapa de transição”, foi um período importante de auto-conhecimento, reflexão e reafirmação de valores em cima de um período que estava meio “perdido”. Isso pode acontecer com qualquer um e se você está em uma situação confortável demais, atenção, faça alguma coisa antes que seja tarde.

Em épocas de crise como essa que vivemos no país, vejo muitos profissionais com anos de experiência desempregados. Eles não entendem que não basta apenas ter anos de experiência, você tem de ter anos de “crescimento” no currículo. Se eu aperto o mesmo botão há 10 anos, isso não me faz mais capaz do que quando eu tinha 1 ano de experiência apertando aquele botão e posso ser facilmente substituído por alguém que aperta o botão mais rápido ou dois botões ao mesmo tempo. Ou por um software, mas essa é uma história ainda mais triste. 🙂

Não tenho arrependimentos e vivi muitas coisas fantásticas como evangelista de software nestes meses na função. Viajei por lugares incríveis e conheci pessoas mais incríveis ainda. Tive a liberdade de explorar tecnologias que tenho a esperança de poder usar na prática ainda e pude me manter lecionando mesmo após deixar meu cargo de professor na FAQI no semestre passado (esta por questão de agenda mesmo).

Para os próximos meses, devo me dedicar absurdamente à esta oportunidade que me foi dada e talvez até tenha que sacrificar um pouco a periodicidade das postagens aqui no blog (que é até um pouco insana se comparado à minha disponibilidade para escrever).

Mas tudo isso por uma boa causa: sair da zona de conforto!

Novidades de junho e julho de 2017

Que ano corrido! Quem me acompanha nas redes sociais como no Facebook já deve estar à par disso, mas jamais teve um ano em que participei de tantos eventos, dei tantos workshops, etc quanto este ano. E olha que entre 2010-2012 eu fiz uma maratona em 37 instituições de ensino hein!

Workshop no JSExperience

No dia 22/06 eu peguei um avião para São Paulo para participar do evento JS Experience, promovido pelo iMasters. O evento que é focado em JavaScript e que reúne mais de 1.000 entusiastas desta tecnologia e seus frameworks e plataformas derivadas (Node.js, React, Angular, etc) aconteceu durante alguns dias e teve a Umbler como patrocinadora.

Palestrando no JS Experience
Palestrando no JS Experience

Minha contribuição para o evento foi um workshop lotado (deviam ter umas 70 pessoas na sala pelas fotos) sobre como criar mecanismos de busca usando Node.js + MongoDB, homônimo a um post meu aqui do blog. Foi super bacana, recebi bons feedbacks e críticas construtivas após a apresentação e em breve devo escrever mais por aqui sobre este assunto.

Foi um bate-volta em São Paulo bem rápido, pois à noite eu tinha de dar aula na faculdade, mas foi bem bacana.

KeyNote e Host no JSDay em Feira de Santana

Já no dia 15/07 eu tive uma oportunidade única de estar pela primeira vez no nordeste brasileiro. Jamais tinha saído do eixo sul-sudeste a trabalho e foi uma experiência muito gratificante conhecer uma cultura nova, novas pessoas, uma nova comunidade de desenvolvedores, etc.

Minha estada foi em Feira de Santana na Bahia, mais especificamente no evento JSDay, na faculdade FTC (Faculdade de Tecnologia e Ciências). Aqui a experiência foi completamente diferente do que estou acostumado, primeiro porque a minha palestra sobre porque Stanford trocou Java por JavaScript foi a palestra de abertura (keynote) do evento.

JS Day em Feira de Santana
JS Day em Feira de Santana

Como se abrir este evento que contou com 250 participantes não fosse o bastante, eu fui convidado a ser o host do evento! Houve muita interação com os palestrantes, com o público, muita troca de experiências, conteúdos bacanas e, é claro, comida temperada!

‘Taí uma experiência diferente na minha carreira!

Saída da FAQI

No dia 19/07 eu deixei de ser membro do corpo docente da QI Escolas e Faculdades após quase 4 anos trabalhando no ensino superior de maneira regular com eles. Devido a conflitos de agenda e de objetivos a curto e médio prazo, tive de me desligar da instituição que foi a primeira a me abrir portas como instrutor lá em 2010-2011, quando comecei a dar cursos de extensão logo no final da minha graduação.

ADS na FAQI
ADS na FAQI

Tenho quase certeza de que é apenas um até logo e não um adeus e fica aqui o meu agradecimento pela oportunidade, pelos ensinamentos, pela troca de experiências com os colegas de profissão e alunos. Agora com esse tempo livre poderei estar mais presente em outros projetos igualmente importantes como meus cursos, meus livros e na educação do meu filho, é claro.

The Developers Conference – São Paulo

Que eu sou “rato de evento” todo mundo aqui já sabe, mas um especial eu não costumo perder: o TDC. Já participei das edições gaúcha e catarinense, e agora pela primeira vez estive maior delas, a edição paulista.

Foi quase uma semana de evento como mais de uma centena de palestrantes, com dezenas de trilhas, mais de uma dezena de expositores e milhares de participantes. Eu não participei de todo o evento, mas mais especificamente dos dois últimos dias, sexta e sábado.

Workshop Node+Mongo no TDC
Workshop Node+Mongo no TDC

No dia 21/07 eu fui instrutor de um workshop de desenvolvimento usando Node.js e MongoDB para um grupo de aproximadamente 15 pessoas. O grupo pequeno foi perfeito para uma imersão focada e extensa dos conceitos básicos do Node, do Mongo e do uso dos dois em conjunto. Nada muito avançado, mas enriquecedor que permitiu que em apenas 3h todos saíssem da sala com uma aplicação CRUD completa rodando em suas máquinas e com a oportunidade de fazerem deploy facilmente na Umbler depois.

Já o dia 22/07 foi mais intenso, pois tive de me dividir entre duas trilhas. Pela manhã eu estive assistindo palestras e interagindo com os participantes da trilha de .NET. Aqui eu apresente meus conhecimentos de mecanismos de busca em uma palestra sobre como criar um usando ASP.NET Core e MongoDB.

PHP e MongoDB no TDC
PHP e MongoDB no TDC

Já na tarde do dia 22/07 eu fiquei na trilha de PHP aprendendo mais sobre esta linguagem que eu definitivamente não domino, mas que arranho um pouco. Minha contribuição foi com uma palestra de criação de mecanismos de busca em PHP com MongoDB, a mesma que eu já havia feito há meses atrás durante meetup do PHP RS e que culminou em um post no site do PHP RS e outro no site do iMasters.

Para agosto já tenho alguns eventos agendados e muita novidades do ponto de vista de cursos e ebooks, que devem ter um foco maior na minha agenda agora. Fique ligado!