A Sabedoria de Esvaziar a Mente​

A essência do verdadeiro aprendizado está em esvaziar a mente. Imagine sua mente como uma xícara: se já estiver cheia, não há espaço para mais nada. Mas, se estiver vazia, pode receber novas experiências e conhecimentos infinitamente. Este é o princípio que devemos adotar.

Humildade e Abertura​

Para esvaziar a mente, a humildade é fundamental. Devemos reconhecer que, independentemente de quanto saibamos, sempre há algo novo para aprender. Esta humildade nos mantém abertos e receptivos a novas ideias, prevenindo a estagnação mental.

Flexibilidade como o Café​

A mente vazia é flexível, adaptável como o café. O café não tem forma própria; ele se molda conforme o recipiente que o contém. Se colocado em um copo, torna-se um copo. Se colocado em uma jarra, torna-se uma jarra. Devemos ser como o café, prontos para nos ajustar a novas circunstâncias e informações.

Superando a Arrogância do Conhecimento​

A crença de que sabemos mais que os outros pode nos levar a um perigoso sentimento de superioridade. Esse estado mental fecha nossa mente para novas ideias e impede o crescimento pessoal. Precisamos reconhecer que a verdadeira sabedoria vem da contínua busca por aprendizado, e não do conhecimento imutável.

Experimentando novos drinks​

Não devemos nos apegar a uma única maneira de fazer as coisas. Experimente novas abordagens, aprenda novos frameworks, explore novas linguagens de programação. Esteja sempre aberto a expandir seus horizontes, sem julgar que uma forma é superior a outra. Este processo de experimentação e adaptação é essencial para o crescimento contínuo.

Autonomia na Decisão​

Cuidado ao seguir conselhos. Não confunda sugestões com ordens. Alguém pode te sugerir seguir um caminho, mas você tem autonomia para ouvir, absorver e decidir se vai seguir ou não. Um conselho é algo que alguém sugere para seu bem, para que você consiga crescer e evoluir; é um aprendizado que pode te poupar de um problema. Agora, uma ordem é algo que você precisa seguir sem questionamentos.

É importante entender a diferença entre as duas. Sugestões são valiosas, pois vêm com a intenção de ajudar e orientar. Elas permitem que você aprenda com a experiência de outros e evite erros comuns. No entanto, você não deve seguir cegamente todas as sugestões. Avalie cada conselho com cuidado, considerando se ele se aplica à sua situação atual e se realmente beneficiará seu crescimento.

Esvaziar a si mesmo não significa aceitar tudo, mas sim estar sempre aberto a novas ideias e sempre aprendendo. Aceitar todas as sugestões e seguir tudo cegamente sem questionar faz de você alguém altamente manipulável, e ser manipulável é ruim quando os conselhos são prejudiciais a você ou para o projeto. Você também precisa se impor. Esvaziar a si mesmo não significa necessariamente que você é alguém sem conteúdo, mas sim que você está sempre disposto a adquirir mais conhecimento, desamarrar-se de vícios e aceitar novas abordagens.

Pense no café. Uma xicara cheia não tem como aprender mais, pois está cheio. Um xicara vazia está sempre disposto a se encher de conhecimento e a buscar novos sabores e saberes. A ideia não é ser uma xicara vazia de conhecimento, mas sim nunca estar completamente cheio. Esvaziar-se não significa remover tudo que você sabe, mas sim estar disposto a coisas novas e a ideias novas.

Respeito e Colaboração​

Manter a mente aberta também envolve respeitar os colegas e suas perspectivas. O respeito mútuo cria um ambiente colaborativo, onde todos se sentem valorizados e incentivados a contribuir. Este ambiente é propício para a troca rica e produtiva de ideias.

A Importância do Brainstorm​

O brainstorm é um exemplo perfeito de esvaziar a mente. Neste processo, todos são incentivados a falar, dar ideias e opinar, sem medo de julgamento. Durante uma sessão de brainstorm, não existem ideias ruins. Esse ambiente seguro e receptivo permite que todos expressem suas ideias livremente, promovendo a criatividade e a inovação. O brainstorm é essencial porque:

• Estimula a Criatividade: Sem medo de julgamentos, as pessoas se sentem livres para pensar fora da caixa.
• Fomenta a Colaboração: Todos têm a oportunidade de contribuir, enriquecendo o processo com diversas perspectivas.
• Desenvolve a Confiança: Quando ideias são aceitas e respeitadas, os participantes ganham confiança para compartilhar mais.
• Promove a Inovação: A troca livre de ideias pode levar a soluções inovadoras e inéditas para problemas complexos.

Lean Inception: O exercício "É e Não É" e "Faz e Não Faz"​

No processo de Lean Inception, o exercício do "É e Não É", "Faz e Não Faz" é uma ferramenta essencial para alinhar a visão da equipe sobre o produto a ser desenvolvido. Este exercício simples, mas poderoso, ajuda a esclarecer as percepções variadas que diferentes membros da equipe podem ter sobre o mesmo produto. Mesmo quando acreditam que têm uma compreensão clara e completa, o exercício revela que podem existir diferenças significativas nas expectativas e entendimentos, um exemplo de como alinhar pessoas e ideias.

Como Funciona o Exercício​

Resumidamente o exercício consiste em um quadro separado por 4 tópicos, as pessoas com postits vão escrevendo e colocando no quadro o que o produto é o que o produto não é, o que ele faz e o que não faz.

• "É e Não É":

  • É: Definir claramente o que o produto é. Isso inclui suas características, funcionalidades principais e o problema que ele resolve.
  • Não É: Especificar o que o produto não é. Isso ajuda a evitar mal-entendidos sobre o escopo e as funcionalidades que não serão incluídas.

• "Faz e Não Faz":

  • Faz: Descrever o que o produto faz. Quais são as ações e tarefas que o produto permitirá aos usuários realizarem.
  • Não Faz: Definir o que o produto não faz. Isso previne expectativas irreais sobre as capacidades do produto.

Benefícios do Exercício​

• Clarifica a Visão do Produto: Ao definir claramente o que o produto é e o que não é, todos os membros da equipe alinham suas expectativas e compreensões.
• Destaca Diferenças de Percepção: Muitas vezes, pessoas diferentes têm ideias muito distintas sobre o mesmo produto. Este exercício ajuda a identificar e resolver essas diferenças.
• Previne Mal-entendidos: Mesmo quando achamos que entendemos um produto por completo, o "É e Não É" pode revelar áreas de confusão ou mal-entendidos.
• Fomenta a Comunicação: Promove uma comunicação aberta e honesta, essencial para o sucesso de qualquer projeto.
• Ensina Humildade: Mostra que até mesmo aqueles que acreditavam saber tudo podem ter ideias equivocadas, ensinando a importância da humildade e da capacidade de ser mais humano e receptivo às perspectivas alheias.

Este excercício simples é uma etapa crucial no processo de Lean Inception, garantindo que toda a equipe esteja na mesma página e pronta para trabalhar de forma colaborativa e eficiente no desenvolvimento do produto.

A Jornada do Agora​

Estar presente no momento é uma prática poderosa. Quando focamos no presente, libertamos nossa mente de preocupações passadas e ansiedades futuras. Este estado de atenção plena nos permite viver plenamente e aproveitar cada oportunidade de aprendizado.

Conclusão​

Adotar a mentalidade de esvaziar a mente é um caminho contínuo de aprendizado e crescimento. A verdadeira sabedoria reside em estar sempre disposto a aprender, manter a humildade e ser flexível como o café. Lembre-se, uma mente vazia é uma mente pronta para ser preenchida com novos drinks e experiências. Valorize o presente, respeite os outros e esteja sempre aberto a novas possibilidades. Assim, você se tornará um verdadeiro mestre no caminho da vida.

Este artigo reflete bem os conceitos de abertura, aprendizado contínuo e flexibilidade. Está bem estruturado e oferece uma perspectiva inspiradora sobre a importância de manter a mente aberta e estar sempre disposto a aprender.

Introdução: A Importância da Comunicação​

Comunicar-se eficazmente e defender suas ideias com base em argumentos racionais é uma habilidade crucial. Quando confrontados com decisões difíceis, é importante avaliar todas as opções, considerar os riscos envolvidos e tomar uma decisão informada. Este artigo explora a importância de priorizar argumentos e compartilha lições valiosas sobre responsabilidade e ética profissional.

O Efeito Dunning-Kruger na Comunicação​

Evitando acidentes e riscos​

Refinamento é Contínuo e Não é Algo Feito uma Vez​

A Natureza Contínua do Refinamento​

O refinamento do backlog é realizado regularmente, tipicamente uma vez por sprint, mas pode ocorrer com mais frequência, conforme necessário. Durante essas sessões, a equipe de desenvolvimento e o Product Owner trabalham juntos para detalhar as histórias, ajustar prioridades e garantir que os itens estejam prontos para serem puxados para a próxima sprint.

“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.” — Guia do Scrum

Identificação de Regras de Negócio​

Embora o Product Owner tenha a responsabilidade principal de definir e priorizar os itens do backlog, os desenvolvedores também desempenham um papel crucial na identificação e clareza das regras de negócio. Durante o refinamento, os desenvolvedores podem levantar questões, identificar dependências e sugerir melhorias que podem não ser inicialmente evidentes para o Product Owner. Esta colaboração ajuda a garantir que todos os aspectos técnicos e de negócio sejam considerados, resultando em histórias de usuário mais completas e bem definidas. Ou seja o desenvolvedor pode e deve falar de regras de negócio, mesmo não definidas pelo P.O se ele identificou que aquilo pode gerar algum risco.

Benefícios do Refinamento Contínuo​

1. Previsibilidade: Mantém o backlog preparado para as sprint plannings, garantindo que a equipe tenha sempre histórias bem definidas para puxar para a próxima sprint.
2. Adaptabilidade: Permite ajustes contínuos nas prioridades e detalhes das histórias de acordo com o feedback dos stakeholders e mudanças no mercado ou nas necessidades do cliente.
3. Colaboração: Promove a colaboração contínua entre o Product Owner e a equipe de desenvolvimento, melhorando o entendimento das histórias e facilitando a entrega de valor ao cliente.

O Medo de Perguntar​

Perguntar nunca vai ser prejudicial, agora deixar de perguntar por medo de julgamentos pode ocasionar em perca de informação, riscos e incidentes que poderiam ser evitados.

Dados sobre Absorção de Informação​

A retenção de informações em reuniões é um desafio conhecido. Estudos mostram que, em média, apenas uma pequena fração do que é discutido em reuniões é realmente absorvida pelos participantes. Isso reforça a importância de fazer perguntas para garantir que todos os pontos importantes sejam compreendidos.

Um estudo publicado pela National Training Laboratories sugere que a retenção de informações varia significativamente de acordo com o método de ensino. Por exemplo:

• Palestra (5%): Um método passivo onde o aluno escuta o professor falar. A retenção é baixa porque os alunos não estão ativamente envolvidos.
• Leitura (10%): Também um método passivo, mas ligeiramente melhor do que palestras.
• Áudio-visual (20%): Inclui vídeos e apresentações que combinam áudio e imagem. A retenção é melhor porque envolve mais sentidos.
• Demonstração (30%): Envolve mostrar como algo é feito, o que melhora a retenção em comparação com métodos puramente passivos.
• Discussão em grupo (50%): A retenção melhora significativamente quando os alunos discutem e interagem com o material em grupo.
• Praticar fazendo (75%): Colocar em prática o que foi aprendido leva a uma retenção muito maior porque envolve a aplicação ativa do conhecimento.
• Ensinar aos outros (90%): O método mais eficaz, pois ensinar força o professor a organizar o conhecimento de maneira clara e compreensível, consolidando assim a própria compreensão e retenção.

Esses dados destacam a importância de métodos de aprendizado ativos e envolventes para melhorar a retenção de informações. O envolvimento ativo dos participantes durante as reuniões, utilizando diferentes métodos de ensino e garantindo que as informações sejam apresentadas de maneira clara e envolvente, pode aumentar significativamente a retenção de informações.

"Se o grupo permanecer quieto, verifique. Pergunte, 'Por que está quieto? Vocês estão pensando? Confusos? Não interessados?' Você pode perceber que eles não entenderam a pergunta ou que estão distraídos por outro problema." — Harvard Graduate School of Education

Para mais detalhes, confira o estudo completo no artigo "Making Meetings Work" da Harvard Graduate School of Education e as discussões sobre retenção de informações no artigo da Education Corner e do The Peak Performance Center.

A Importância de Perguntar​

Um colega pode acreditar que responderia ou perguntaria melhor, mas, na prática, qualquer um pode fazer perguntas mais inteligentes depois que elas já foram feitas, mas nem todos tem a iniciativa e coragem de tomar as rédeas e fazer a pergunta. Às vezes, nem todas as perguntas serão totalmente eficazes, e isso é normal e faz parte do aprendizado. O ideal é quando não fizermos uma pergunta efetiva um cobrir o outro e mostrar como poderia ser feita de maneira melhor.

A Analogia com o Futebol​

A Importância de Treinar a Escuta​

Feedback de Comunicação​

Muitas vezes, a comunicação é criticada, mas é essencial reconhecer que uma comunicação eficaz requer esforço contínuo e colaboração de todas as partes envolvidas. Todos podemos aprender a nos comunicar melhor fazendo perguntas e buscando entender antes de julgar. Receber feedback é uma oportunidade para melhorar, mas é importante que esse feedback seja construtivo e baseado em observações objetivas, e não apenas em percepções superficiais.

Conclusão​

A comunicação eficaz é uma habilidade vital no desenvolvimento de software, que vai além de apenas fazer perguntas. Envolve reconhecer as próprias limitações, estar disposto a aprender continuamente e utilizar a colaboração para alcançar clareza e entendimento mútuo. O efeito Dunning-Kruger nos alerta sobre a superestimação das próprias habilidades e a importância de avaliar criticamente nossas capacidades de comunicação.

Argumentos sólidos são mais valiosos do que hierarquias e decisões precipitadas podem acarretar em riscos e perdas irreversíveis. A prática de refinamento contínuo no Scrum mostra como a colaboração entre o Product Owner e a equipe de desenvolvimento pode levar a histórias de usuário mais completas e bem definidas, beneficiando o projeto como um todo.

O medo de perguntar e a falta de interesse em ouvir atentamente podem ser grandes obstáculos para uma comunicação eficaz. Estudos demonstram que a retenção de informações em reuniões é limitada, destacando a necessidade de métodos de aprendizado ativos e envolventes para melhorar a absorção de informações. Criar um ambiente onde perguntas são bem-vindas e onde todos se esforçam para escutar ativamente pode transformar a dinâmica de uma equipe, resultando em melhores resultados e menos retrabalho.

Ao treinar a escuta e incentivar a participação ativa de todos os membros da equipe, podemos superar as barreiras de comunicação e construir um ambiente de trabalho mais eficiente e colaborativo. Lembre-se de que a busca contínua por clareza e entendimento mútuo é o caminho para uma comunicação realmente eficaz no desenvolvimento de software.

No ambiente de desenvolvimento de software, a metodologia ágil Scrum tem se mostrado extremamente eficaz para promover a entrega de valor de forma rápida e adaptativa. Uma das principais características do Scrum é a ausência de hierarquia formal entre os membros da equipe de desenvolvimento. Neste artigo, discutiremos por que a hierarquia não funciona para o Scrum e por que é crucial adotar uma mentalidade colaborativa. Também abordaremos a importância do Code Review por toda a equipe e os perigos de um desenvolvedor sênior sem a cultura do Scrum ou agilidade.

Colocar sistemas hierarquicos promovem a divisão e dificulta a comunicação, a revisão de código deve ser algo compartilhado e não exclusivo, a rotação do code review não é em temporadas, mas constante, isto é, todos devem fazer revisão de todos.

Hierarquia versus Autonomia no Scrum​

A hierarquia tradicional, com suas estruturas rígidas de poder e tomada de decisões centralizada, não se encaixa no contexto ágil do Scrum. No Scrum, a equipe de desenvolvimento é autogerenciada e responsável por tomar decisões técnicas e de implementação. A ausência de uma hierarquia formal permite que os membros da equipe sejam mais autônomos, colaborativos e adaptáveis às mudanças.

A mentalidade colaborativa é essencial no Scrum, pois todos os membros da equipe têm a responsabilidade de alcançar os objetivos do projeto. Através da colaboração, as habilidades e perspectivas de cada membro da equipe são aproveitadas de forma eficaz, levando a soluções inovadoras e de alta qualidade.

A hierarquia cria barreiras na comunicação e dificulta o fluxo de informações e ideias entre os membros da equipe. Isso pode levar a uma falta de transparência, perda de tempo e falta de engajamento por parte dos desenvolvedores. Além disso, a hierarquia pode inibir a autonomia e a criatividade, pois os membros da equipe podem se sentir restringidos por uma estrutura de comando e controle.

O Papel do Scrum Master no Scrum​

Embora o Scrum preze pela ausência de hierarquia dentro do time de desenvolvimento, isso não significa que a liderança seja descartada totalmente. Pelo contrário, é essencial ter líderes fortes que garantam a efetividade do Scrum e facilitem o trabalho da equipe.

O Scrum Master como Líder Servo​

O Scrum Master desempenha um papel de liderança no Scrum, atuando como um servo líder. Eles facilitam o processo e promovem a adoção efetiva do framework, orientando a equipe sobre as práticas ágeis, ajudando a remover obstáculos e promovendo uma cultura de colaboração e autogerenciamento.

No entanto, é importante ressaltar que o Scrum Master não é um gerente no sentido tradicional. Em vez de dar ordens ou impor autoridade hierárquica, o Scrum Master trabalha em estreita colaboração com a equipe, incentivando a transparência, a responsabilidade e a melhoria contínua.

A Liderança do Scrum Master​

A liderança do Scrum Master é baseada na facilitação, na escuta ativa e no apoio aos membros da equipe. Eles atuam como facilitadores, garantindo que as cerimônias do Scrum sejam realizadas de forma eficaz, promovendo a colaboração entre os membros da equipe e removendo quaisquer obstáculos que possam atrapalhar o progresso do projeto.

Além disso, o Scrum Master desempenha um papel crucial na disseminação da mentalidade ágil e na cultura de melhoria contínua. Eles encorajam a equipe a refletir sobre seu trabalho, identificar áreas de melhoria e experimentar novas abordagens para alcançar resultados melhores.

O Sucesso do Scrum e o Papel da Equipe​

Enquanto o Scrum Master oferece orientação e suporte, é importante destacar que o sucesso do Scrum depende da colaboração e do engajamento de toda a equipe. Cada membro tem a responsabilidade de se autogerenciar, tomar decisões e contribuir ativamente para o sucesso do projeto.

O Scrum Master trabalha em conjunto com a equipe para criar um ambiente propício à criatividade, inovação e colaboração. Eles ajudam a desenvolver a capacidade da equipe de tomar decisões informadas e assumir a responsabilidade pelo trabalho realizado.

O Scrum Master não apenas lidera, mas também capacita a equipe a se tornar autogerenciável e alcançar um desempenho excepcional. Eles promovem a comunicação efetiva, resolvem conflitos e incentivam a melhoria contínua.

Code Review: Uma Prática Colaborativa Essencial​

Embora o Scrum seja um framework de gerenciamento de projetos ágeis e o code review seja uma prática de revisão de código, eles podem estar relacionados e se complementar dentro de um ambiente de desenvolvimento ágil.

No Scrum, o Code Review é uma prática fundamental para garantir a qualidade do código e promover a colaboração entre os desenvolvedores. Todos os membros da equipe devem participar do processo de revisão de código, independentemente de sua experiência ou posição na equipe.

Ao envolver toda a equipe no Code Review, várias vantagens são alcançadas. Em primeiro lugar, isso ajuda a disseminar o conhecimento técnico, permitindo que todos os desenvolvedores aprendam e cresçam. Além disso, promove a responsabilidade coletiva pela qualidade do código, identificando possíveis erros, melhorias e oportunidades de otimização.

Ao ter uma mentalidade colaborativa no Code Review, os desenvolvedores podem compartilhar conhecimentos, oferecer sugestões construtivas e aprender uns com os outros. Isso resulta em um código mais limpo, mais eficiente e mais resiliente, melhorando a produtividade e evitando problemas futuros.

Limitar o code review a posições hierárquicas pode ser um erro, pois isso pode criar uma falsa sensação de superioridade entre os desenvolvedores. No contexto do code review, é importante que todos os membros da equipe tenham a oportunidade de revisar e serem revisados, independentemente de sua posição na hierarquia.

Ao permitir que todos participem do processo de code review, cria-se um ambiente de colaboração e aprendizado mútuo. Todos os desenvolvedores têm conhecimentos e perspectivas diferentes, e permitir que todos tenham voz nas revisões de código pode levar a melhorias significativas na qualidade do código e no crescimento profissional da equipe.

O Perigo de um Desenvolvedor Sênior sem a Cultura do Scrum ou Agilidade​

Um desenvolvedor sênior, com uma vasta experiência técnica, pode ser um recurso valioso para a equipe. No entanto, se esse desenvolvedor não estiver alinhado com a cultura do Scrum ou agilidade, pode representar um perigo para a organização. Aqui estão alguns motivos pelos quais um desenvolvedor sênior sem a cultura do Scrum ou agilidade pode ser problemático:

1. Falta de colaboração: Um desenvolvedor sênior que não valoriza a mentalidade colaborativa do Scrum pode ser resistente a trabalhar em equipe e preferir tomar decisões de forma independente. Isso pode levar a lacunas de comunicação, falta de compartilhamento de conhecimento e redução da eficácia da equipe como um todo.

2. Resistência à mudança: A agilidade requer uma mentalidade flexível e aberta a mudanças. Um desenvolvedor sênior preso a métodos de trabalho tradicionais pode ser resistente a adotar práticas ágeis, dificultando a implementação bem-sucedida do Scrum na organização.

3. Dificuldade em se adaptar: A agilidade exige a capacidade de se adaptar rapidamente a novas situações e requisitos em constante mudança. Um desenvolvedor sênior que está acostumado a seguir processos rígidos e definidos pode ter dificuldade em se adaptar às necessidades do Scrum e pode prejudicar a agilidade da equipe.

4. Falta de feedback construtivo: A cultura do Scrum incentiva a retroalimentação contínua entre os membros da equipe. Um desenvolvedor sênior que não está alinhado com essa cultura pode não fornecer feedback construtivo aos colegas, perdendo uma oportunidade valiosa de aprendizado e crescimento para toda a equipe.

5. Ausência de liderança ágil: Um desenvolvedor sênior geralmente é visto como uma referência técnica para a equipe. Se esse desenvolvedor não estiver alinhado com a cultura ágil, sua liderança pode prejudicar a adoção bem-sucedida do Scrum. É fundamental que os líderes na equipe tenham uma compreensão sólida dos valores e princípios ágeis para orientar e motivar a equipe adequadamente.

É importante ressaltar que esses problemas não estão relacionados apenas à posição de desenvolvedor sênior, mas sim à falta de alinhamento com a cultura ágil. Independentemente do nível de experiência, todos os membros da equipe devem abraçar os princípios e valores do Scrum para maximizar o sucesso do projeto, é verdade que o Scrum Master é responsável por saber o Scrum, porém isso não significa que os desenvolvedores não devam ter experiência com metodologias ágeis.

Para evitar esses perigos, é essencial investir em treinamento, comunicação clara e promover uma cultura de aprendizado e adaptação. Os desenvolvedores seniores também devem estar dispostos a se envolver e aprender com a equipe, adotando uma mentalidade colaborativa e ágil.

Conclusão​

Em conclusão, a metodologia ágil Scrum é altamente eficaz no desenvolvimento de software, promovendo a entrega rápida e adaptativa de valor. A ausência de hierarquia formal e a mentalidade colaborativa são características fundamentais do Scrum, permitindo autonomia, colaboração e adaptação.

O papel do Scrum Master é facilitar e promover a adoção efetiva do Scrum, enquanto o Code Review é uma prática colaborativa essencial para garantir a qualidade do código e do produto.

No entanto, a presença de uma liderança sem a cultura do Scrum ou agilidade pode representar desafios, como a falta de colaboração e resistência à mudança, não proporcionar uma cultura de revisão eficiente ou impedir a cultura de revisão, fazendo ser uma cultura hierarquica e selecionada para apenas algumas pessoas. Investir em treinamento, comunicação clara e uma cultura de aprendizado e adaptação é crucial para evitar esses problemas e alcançar o sucesso no Scrum.

Venho aqui compartilhar um conhecimento que tive através de minha pós graduação, este tema é altamente importante para desenvolvedores web e essencial para qualquer organização.

A acessibilidade na web é uma parte essencial do design e desenvolvimento web que garante que todas as pessoas possam usar e ter acesso às informações e funcionalidades na web. Um conjunto crucial de diretrizes que orienta essa prática é o WCAG, ou Web Content Accessibility Guidelines.

A acessibilidade é um conhecimento crucial para qualquer desenvolvedor web, pois não devemos apenas criar conteúdos onde o cliente deve operar, mas conteúdo acessível para todos

O que é o WCAG?​

WCAG é uma sigla que significa Web Content Accessibility Guidelines. São um conjunto de recomendações para tornar o conteúdo da web mais acessível, principalmente para pessoas com deficiências. Desenvolvido e mantido pelo W3C (World Wide Web Consortium), uma organização internacional que desenvolve padrões abertos para a web, o WCAG serve como um roteiro para a construção de experiências web inclusivas.

WCAG e Acessibilidade​

A acessibilidade da web é a prática de projetar e criar websites, ferramentas e tecnologias para que possam ser usados por todas as pessoas, independentemente de suas habilidades físicas, sensoriais ou cognitivas. Isso é importante não apenas como uma questão de inclusão e direitos civis, mas também porque a acessibilidade na web oferece benefícios como melhor SEO (Search Engine Optimization) e maior alcance de audiência.

As diretrizes do WCAG fornecem estratégias específicas e técnicas que ajudam os desenvolvedores a criar conteúdo que seja acessível para pessoas com deficiências. As diretrizes se concentram em quatro princípios principais, que são:

1. Perceptível: As informações e os componentes da interface do usuário devem ser apresentáveis aos usuários de maneiras que eles possam perceber. Isso inclui oferecer alternativas de texto para imagens, legendas para multimídia e criar um design e layout que permitam a compreensão eficaz do conteúdo.

2. Operável: Os componentes da interface do usuário e a navegação devem ser operáveis. Isso significa que os usuários devem ser capazes de interagir e navegar pelo conteúdo da web. Isso pode envolver tornar todas as funções disponíveis a partir de um teclado ou fornecer tempo suficiente para os usuários lerem e usarem o conteúdo.

3. Compreensível: As informações e a operação da interface do usuário devem ser compreensíveis. Isso significa que o conteúdo da web deve ser apresentado de uma maneira que os usuários possam entender.

4. Robusto: O conteúdo deve ser suficientemente robusto para ser interpretado de maneira confiável por uma ampla variedade de tecnologias assistivas. Além disso, os usuários devem ser capazes de acessar o conteúdo à medida que a tecnologia evolui.

A Legislação Brasileira de Acessibilidade na Web​

No Brasil, a Lei Brasileira de Inclusão da Pessoa com Deficiência (Estatuto da Pessoa com Deficiência), Lei Nº 13.146, estabelece normas gerais e critérios básicos para a promoção da acessibilidade das pessoas com deficiência ou com mobilidade reduzida.

No contexto digital, o Decreto Nº 5.296 de 2004 também é relevante. Esse decreto estabelece normas e critérios para a promoção da acessibilidade, incluindo a obrigação de que os sítios eletrônicos da administração pública devem ser projetados para oferecer acesso às informações contidas neles, independentemente das capacidades físico-motoras, perceptivas, sensoriais, intelectuais ou mentais de seus usuários.

O Modelo de Acessibilidade de Governo Eletrônico (e-MAG) é uma iniciativa que tem como objetivo orientar a adequação dos sítios e portais do governo à acessibilidade. O e-MAG está alinhado às recomendações internacionais, como o WCAG, mas considera as características culturais do Brasil.

Lembre-se que, apesar de haver leis específicas para a administração pública, a acessibilidade é um direito humano e as práticas de design acessível devem ser seguidas por todos os desenvolvedores e designers, independentemente de serem parte do setor público ou privado.

Avaliações de Acessibilidade​

As avaliações de acessibilidade geralmente caem em duas categorias: Avaliações automáticas e Avaliações manuais.

Avaliações automáticas​

Este tipo de avaliação é feita com ferramentas automatizadas de acessibilidade que podem analisar rapidamente um site ou aplicação para identificar problemas de acessibilidade comuns. Elas podem verificar coisas como se as imagens têm texto alternativo, se os cabeçalhos estão estruturados corretamente, se o contraste de cores é suficiente, etc. As ferramentas de avaliação automática são úteis para identificar problemas óbvios e fáceis de detectar, mas não conseguem capturar todos os aspectos da acessibilidade.

Avaliações manuais​

Este tipo de avaliação é realizada por humanos que manualmente verificam o site ou aplicação para problemas de acessibilidade. Isso pode incluir coisas como navegar pelo site apenas com o teclado, usar tecnologias assistivas (como leitores de tela) para interagir com o site, ou simplesmente verificar se o conteúdo faz sentido quando lido fora de ordem. As avaliações manuais são necessárias porque muitos aspectos da acessibilidade dependem do contexto e da interpretação, algo que as ferramentas automatizadas não são capazes de fornecer.

Qual avaliação devo utilizar?​

Idealmente, um site ou aplicação deve passar por ambos os tipos de avaliação para garantir a maior acessibilidade possível. Cada método tem suas próprias vantagens e limitações, e a combinação de ambos fornece a avaliação mais completa e precisa da acessibilidade de um site ou aplicação.

Abaixo segue as diretivas do WCAG para aplicar em seus sistemas, se seguir todos a risca você terá um sistema 100% acessível, note que as diretivas podem mudar de acordo com o ano, por isso é necessário verificar se você está usando a diretiva mais atualizada no momento.

Diretivas do WCAG

Conclusão​

Estes princípios orientam a construção de websites, aplicativos e outras tecnologias da web que sejam acessíveis a todas as pessoas, independentemente de suas habilidades. Ao seguir as diretrizes do WCAG, os desenvolvedores podem garantir que seus produtos sejam inclusivos e acessíveis.

Os padrões do WCAG são amplamente adotados globalmente e representam uma parte significativa da garantia de que a web seja inclusiva e acessível para todos. Independentemente de você ser um desenvolvedor experiente ou um novato.

Muitos profissionais e gestores de TI podem argumentar que projetos de migração tecnológica não são adequados para abordagens ágeis como o Scrum. Eles acreditam que esses projetos, que envolvem a transferência de dados, configurações e funcionalidades de um sistema antigo para um novo, necessitam de um caminho claramente definido com pouca margem para mudanças.

No entanto, essa visão não leva em conta a imprevisibilidade inerente a todos os projetos de tecnologia, incluindo migrações. Mesmo o projeto mais bem planejado pode enfrentar obstáculos inesperados, como problemas técnicos ou uma curva de aprendizado mais acentuada para os desenvolvedores.

Primeiramente, vale lembrar que a engenharia reversa, no contexto de migração tecnológica, geralmente envolve a compreensão de um sistema existente (frequentemente mais antigo ou obsoleto) para que possa ser recriado ou substituído por um sistema mais moderno ou eficiente. Isto implica em desmontar e analisar os componentes do sistema, entender como eles interagem e, em seguida, projetar um novo sistema com funcionalidade semelhante.

No entanto, só porque estamos recriando ou substituindo um sistema existente, não significa que não possa haver espaço para melhorias, otimizações ou novas funcionalidades, pois se trata de componentes e tecnologias diferentes. E é aqui que a presença de um Product Owner (PO) pode ser muito útil. O PO é responsável por entender as necessidades dos stakeholders, priorizar as funcionalidades e garantir que o produto final atenda às necessidades do negócio.

Por que considerar o Scrum para migração tecnológica?​

O Scrum, e as metodologias ágeis em geral, oferecem uma estrutura flexível que permite às equipes se adaptarem a mudanças e lidarem com imprevistos de maneira mais eficaz.

Diante dessa realidade, é válido questionar se as metodologias ágeis, como o Scrum, poderiam ser aplicadas em projetos de migração tecnológica. Aqui estão algumas razões para considerar essa abordagem:

1. Iterativo e Incremental: A natureza iterativa e incremental do Scrum permite uma detecção precoce e solução de problemas. Ao trabalhar em pequenas partes do projeto por vez, as equipes podem identificar desafios e corrigi-los antes que se tornem problemas maiores. Isto é particularmente útil na migração tecnológica, onde problemas inesperados são frequentes.

2. Colaboração e Comunicação: A abordagem ágil coloca um grande ênfase na comunicação constante e colaboração efetiva, seja por meio de reuniões diárias de Scrum ou sessões de planejamento de sprint. Esta cultura de colaboração pode ser vital em projetos de migração, onde a clareza de objetivos e responsabilidades é fundamental.

3. Flexibilidade: Projetos de migração podem ser marcados pela mudança. Seja uma alteração no escopo, problemas técnicos não previstos ou feedback do cliente, o Scrum permite uma resposta rápida e efetiva a essas mudanças.

4. Feedback Contínuo: A abordagem ágil preconiza a entrega contínua de valor, permitindo o feedback frequente de stakeholders e a oportunidade de ajustar o curso do projeto, se necessário. Em projetos de migração, esse feedback contínuo pode ser crucial para garantir que o novo sistema atenda às necessidades do negócio.

Conclusão​

Embora a migração tecnológica possa apresentar desafios únicos, a aplicação adaptativa das metodologias ágeis pode ser benéfica. A escolha da metodologia deve ser baseada nas necessidades e circunstâncias específicas do projeto, e não em prescrições rígidas.

Apesar das percepções iniciais, o Scrum e outras metodologias ágeis podem, de fato, ser aplicados com sucesso em projetos de migração tecnológica. Com a capacidade de se adaptar a mudanças e enfrentar desafios imprevistos, essas abordagens podem fornecer uma estrutura eficaz para navegar por esses complexos projetos de TI.

"Kanban: Successful Evolutionary Change for Your Technology Business" de David J. Anderson é um livro seminal no mundo da gestão de projetos ágeis. Ele apresenta o sistema Kanban, adaptado das fábricas da Toyota para o mundo do desenvolvimento de software, focando em melhorar a eficiência e a eficácia do fluxo de trabalho.

Principais métodos do Kanban​

O método Kanban se baseia em três princípios básicos:

1. Visualize o fluxo de trabalho: Isso é normalmente feito através de um quadro Kanban, onde cada tarefa é representada por um cartão que se move de uma coluna para outra, representando diferentes estágios do fluxo de trabalho.
2. Limite o trabalho em progresso (WIP): Isso significa que você deve limitar o número de tarefas que estão em andamento em qualquer estágio do fluxo de trabalho. Limitar o WIP ajuda a evitar o excesso de tarefas e garante que o trabalho flua suavemente através do sistema.
3. Gerencie o fluxo: Isso envolve monitorar o movimento das tarefas através do quadro Kanban e fazer ajustes conforme necessário para melhorar a eficiência.

Reuniões Standup​

Em um sistema Kanban, as reuniões standup têm um formato diferente. Em vez de cada membro da equipe responder a três perguntas típicas ("O que foi feito ontem?", "O que você fará hoje?", "Você está bloqueado ou precisa de alguma ajuda?"), o foco muda para o fluxo de trabalho.

O Fluxo de Trabalho​

O facilitador da reunião, geralmente o gerente do projeto ou um gerente de linha, "anda pelo quadro" visualizando o status dos tickets. A convenção é olhar o trabalho de trás para frente - da direita para a esquerda, na direção "do puxar".

Enfocando os Itens Bloqueados e Atrasados​

Em uma reunião standup do Kanban, a ênfase é dada para itens que estão bloqueados ou atrasados devido a defeitos. Se um item parece estar parado e não se movimentou por alguns dias, questões podem ser levantadas sobre ele.

Melhoria da Capacidade de Gerenciamento de Problemas​

Este formato permite que a equipe aprimore a capacidade de gerenciamento de problemas da organização. A equipe discutirá brevemente quem está trabalhando no problema e quando ele será resolvido.

Movendo-se para a frente, não para trás​

A ideia de que as tarefas devem ser continuamente movidas para a frente no processo, ao invés de serem movidas para trás. Isto está alinhado com o princípio de que o trabalho deve sempre estar avançando em direção à conclusão, além disso cada coluna tem um limite de tarefa para Work In Progess, você voltar uma tarefa para trás pode ocasionar vários problemas, como a terefa não poder retroceder por causa que o número máximo de tarefas já foi atingido, fazendo a tarefa ficar presa na parte de teste.

Por exemplo, se uma tarefa estiver em teste e um bug for descoberto, é sugerido que, em vez de mover a tarefa de volta para a coluna de desenvolvimento, uma nova tarefa deve ser criada para lidar com a correção do bug. Isso ajuda a manter a visibilidade e a rastreabilidade, e também enfatiza a ideia de que o trabalho deve ser concluído antes de ser movido para a próxima etapa.

Lidando com Atividades Desordenadas​

Em situações de alta inovação e experimentação, as atividades relacionadas a um trabalho de valor para o cliente podem não seguir uma ordem específica. O Kanban não deve forçar a execução de atividades em uma ordem determinada, mas sim refletir a maneira real de como o trabalho é feito.

Existem algumas estratégias para lidar com múltiplas atividades desordenadas:

1. Uma única coluna de atividades: Semelhante à abordagem para lidar com atividades concorrentes, todas as atividades são mantidas em uma única coluna e não se acompanha explicitamente no quadro qual delas é finalizada.

2. Modelando atividades como concorrentes: Esta abordagem envolve mover tickets verticalmente para cima e para baixo nas colunas conforme são puxados para cada atividade específica. Os tickets podem ser modificados para ter uma caixa pequena para cada atividade. Quando uma atividade é finalizada, a caixa pode ser marcada para sinalizar visualmente que o item está pronto para ser puxado para outra atividade na mesma coluna.

Se todas as caixas são preenchidas, o item está pronto para ser puxado para a próxima coluna no quadro ou pode ser movido para a coluna "done".

Lembrando que é possível que a etapa de desenvolvimento e de testes fiquem na mesma coluna, porém isso aumenta o número de tasks que ficariam na mesma coluna para determinada atividade.

Definição de Pronto​

A definição de pronto é outro conceito importante em Kanban. Isso se refere ao conjunto de critérios que uma tarefa deve atender antes de poder ser considerada completa e movida para a próxima etapa do fluxo de trabalho. A definição de pronto ajuda a garantir que o trabalho esteja realmente concluído antes de ser avançado, minimizando a necessidade de retrabalho.

Conclusão​

"Kanban: Successful Evolutionary Change for Your Technology Business" fornece uma visão detalhada e prática de como implementar e usar o Kanban no desenvolvimento de software. Os princípios e práticas que Anderson descreve ajudam a criar um fluxo de trabalho mais eficiente e eficaz, minimizando o retrabalho e melhorando a qualidade do produto final.

Agilidade, Scrum e Kanban: São apenas responsabilidades do Scrum Master (SM)?​

A agilidade, Scrum e Kanban não são apenas responsabilidades do Scrum Master. Embora o SM desempenhe um papel fundamental na promoção e aplicação desses conceitos e metodologias, é crucial que toda a equipe - incluindo os profissionais sêniores - entenda e se comprometa com eles.

Em um ambiente ágil, cada membro da equipe deve estar ciente do valor da colaboração, capacidade de resposta à mudança, entrega contínua de valor e melhoria contínua. Entender Scrum ou Kanban (ou qualquer outro framework ágil que a equipe esteja usando) significa entender como esses valores são colocados em prática.

Uma cultura de agilidade é suficiente para tornar uma empresa boa?​

Uma cultura de agilidade pode contribuir significativamente para a eficácia de uma empresa, mas não é a única coisa que importa. Outros fatores, como liderança eficaz, estratégia clara, boa comunicação, compreensão do mercado e do cliente, e a qualidade do produto ou serviço também são essenciais.

É suficiente ter conhecimento técnico, mas não ter conhecimento de agilidade?​

Ter um forte conhecimento técnico é certamente valioso, mas em um ambiente de trabalho moderno, especialmente em desenvolvimento de software, a compreensão das práticas ágeis é quase tão importante quanto as habilidades técnicas.

A agilidade ajuda as equipes a lidar com a incerteza, a se adaptar às mudanças e a entregar valor de maneira mais eficiente e eficaz. Portanto, mesmo que um profissional sênior seja tecnicamente habilidoso, a falta de conhecimento em agilidade pode limitar a sua capacidade de contribuir plenamente para a equipe e o projeto.

O que é Code Review?​

O Code Review é uma prática essencial em qualquer equipe de desenvolvimento, independentemente do nível de experiência dos membros. Consiste em um processo sistemático de verificação de se o código-fonte de um programa atende aos padrões de desenvolvimento predeterminados. O Code Review promove a qualidade do código, compartilha o conhecimento e ajuda a identificar e corrigir erros antes que eles se tornem problemas maiores.

Os profissionais sêniores devem ter uma cultura de Code Review?​

Definitivamente. O code review é uma prática essencial em qualquer equipe de desenvolvimento, independentemente do nível de experiência dos membros. Ela promove a qualidade do código, compartilha o conhecimento e ajuda a identificar e corrigir erros antes que eles se tornem problemas maiores.

Os profissionais sêniores, em particular, podem trazer uma riqueza de experiência e perspectiva para o processo de code review, ajudando a orientar os membros menos experientes da equipe e a manter altos padrões de qualidade.

O Code Review é limitado apenas aos profissionais sêniores?​

Não, o code review não deve ser limitado apenas aos profissionais sêniores. Todos os membros da equipe, independentemente de seu nível de experiência, devem estar envolvidos no processo de code review. Isso ajuda a garantir que todos entendam o código que está sendo produzido, promove a aprendizagem contínua e a troca de conhecimento, e ajuda a distribuir a propriedade do código por toda a equipe.

Peer Code Review: Uma modalidade essencial​

O Peer Code Review, também conhecido como revisão de código entre pares, é uma subcategoria de Code Review onde os membros da equipe revisam o código uns dos outros. Esta é uma prática particularmente eficaz para promover a aprendizagem entre a equipe e para assegurar que todos na equipe estejam cientes das diferentes partes do projeto.

Os profissionais sêniores, em particular, podem trazer uma riqueza de experiência e perspectiva para o processo de Peer Code Review, ajudando a orientar os membros menos experientes da equipe e a manter altos padrões de qualidade.

Conclusão: O Perigo da Falta de Conhecimento Ágil e Prática de Code Review em Profissionais Sêniores​

Para concluir, é importante ressaltar que o cenário moderno de desenvolvimento de software exige muito mais do que habilidades técnicas, mesmo para profissionais sêniores. A compreensão e a aplicação de metodologias ágeis e a participação ativa em práticas como code review são essenciais para o sucesso de qualquer projeto.

Profissionais sêniores sem essas habilidades ou que não estão dispostos a adotar essas práticas representam um risco significativo para suas equipes e projetos. Eles podem encontrar dificuldades para se adaptar às mudanças, para colaborar efetivamente com suas equipes e para contribuir para a entrega contínua de valor. Além disso, podem perder oportunidades de compartilhar conhecimento e de aprender com os colegas, o que pode limitar o crescimento e a eficácia da equipe como um todo.

Portanto, é crucial para profissionais sêniores manterem-se atualizados não apenas em relação às tecnologias e práticas técnicas, mas também em relação às metodologias e práticas de trabalho, como Scrum, Kanban e code review. Ao fazer isso, eles não apenas aumentam seu próprio valor como profissionais, mas também contribuem para a saúde, eficácia e sucesso de suas equipes e projetos.

Nesta seção, iremos revisar os conceitos fundamentais de bancos de dados, bem como as formas normais que são cruciais para um design eficiente de banco de dados.

A. Conceitos Básicos de Banco de Dados​

Bancos de dados são sistemas de organização de dados que permitem a recuperação, inserção, atualização e exclusão eficientes de dados. Eles são fundamentais para muitas aplicações modernas, incluindo sistemas de gerenciamento de informações, comércio eletrônico e muito mais.

Modelos de Dados​

Os modelos de dados definem a estrutura e o formato dos dados em um banco de dados. Eles incluem o modelo relacional, que organiza os dados em tabelas relacionadas, e os modelos de dados NoSQL, que podem incluir modelos de documentos, de chave-valor, de coluna larga e de grafos.

SQL e NoSQL​

SQL (Structured Query Language) é uma linguagem de programação usada para interagir com bancos de dados relacionais. NoSQL se refere a bancos de dados que não usam a estrutura de tabela tradicional encontrada em bancos de dados relacionais.

B. Formas Normais e Princípios de Design de Banco de Dados​

Quem meche com banco de daos precisa dominar a fazer consultas complexas, porém muitas vezes as formas normais são passadas despercebidas, um conceito básico e altamente importante. As formas normais são regras que guiam o design de bancos de dados para minimizar a duplicação de dados e evitar certos tipos de problemas de atualização.

Primeira Forma Normal (1NF)​

Um banco de dados está na primeira forma normal se cada coluna de cada tabela contém apenas valores atômicos (indivisíveis) e cada valor de uma coluna é do mesmo tipo.

Segunda Forma Normal (2NF)​

Um banco de dados está na segunda forma normal se estiver na primeira forma normal e cada coluna não-chave depende de toda a chave primária.

Terceira Forma Normal (3NF)​

Um banco de dados está na terceira forma normal se estiver na segunda forma normal e não houver dependências transitivas de colunas não-chave.

C. Praticando a Criação e Otimização de Consultas SQL​

Praticar a criação e otimização de consultas SQL é crucial para qualquer desenvolvedor que trabalhe com bancos de dados. Existem muitos recursos online, como o HackerRank, que oferecem problemas de prática de SQL que você pode usar para aperfeiçoar suas habilidades.

Nesta seção, vamos trabalhar com um exemplo de normalização de banco de dados da Primeira Forma Normal (1NF) para a Terceira Forma Normal (3NF).

Primeira Forma Normal (1NF)​

Vamos começar com uma tabela de pedidos de uma loja que vende produtos. A tabela está na Primeira Forma Normal (1NF), pois cada coluna contém apenas valores atômicos e cada valor de uma coluna é do mesmo tipo.

Em termos simplificados, a 1NF é quando "todas as tabelas estão juntas".

Segunda Forma Normal (2NF)​

Para normalizar a tabela para a Segunda Forma Normal (2NF), precisamos garantir que não haja nenhuma dependência parcial; todos os atributos não-chave devem depender completamente da chave primária. No caso da nossa tabela, o preço dos produtos não depende do OrderID, mas sim do Produto. Portanto, vamos dividir a tabela em duas: uma para pedidos e outra para produtos.

Em termos simplificados, a 2NF é quando "as tabelas são divididas de acordo com cada contexto".

Tabela Orders:

Tabela Products:

Terceira Forma Normal (3NF)​

Para normalizar a tabela para a Terceira Forma Normal (3NF), precisamos remover as dependências transitivas; todos os atributos não-chave devem depender apenas da chave primária. No nosso caso, o nome do cliente depende do CustomerID, que depende do OrderID. Isso é uma dependência transitiva. Portanto, vamos dividir a tabela de pedidos novamente, desta vez separando os clientes dos pedidos.

Tabela Orders:

Tabela Customers:

Tabela Products:

Agora, todas as tabelas estão na Terceira Forma Normal (3NF). Em cada tabela, cada coluna não-chave depende apenas da chave primária da tabela. As tabelas "Orders", "Customers" e "Products" não têm dependências transitivas nem dependências parciais, cumprindo assim as regras da 3NF.

A. Estruturas de Dados:​

Introdução às estruturas de dados​

• Definição e importância das estruturas de dados
• Classificação das estruturas de dados: linear vs não linear, homogênea vs heterogênea, estática vs dinâmica

Estruturas de Dados Lineares:​

• Arrays
• Listas Ligadas
• Pilhas
• Filas

Estruturas de Dados Não Lineares:​

• Árvores
  • Árvores Binárias
  • Árvores AVL
  • Árvores B
  • Árvores B+
  • Árvores de Segmento
  • Trie
• Grafos
• Tabelas Hash

B. Algoritmos:​

Introdução aos algoritmos​

• Definição e importância dos algoritmos
• Notação Big O, análise de complexidade de tempo e espaço

Algoritmos de Ordenação:​

• Bubble Sort
• Selection Sort
• Insertion Sort
• Quick Sort
• Merge Sort
• Outros (Heap Sort, Radix Sort, Bucket Sort, etc.)

Algoritmos de Busca:​

• Busca Linear
• Busca Binária
• Busca em Árvores (para diferentes tipos de árvores)
• Busca em Grafos: BFS (Busca em Largura) e DFS (Busca em Profundidade)

Resolução de Problemas:​

• Práticas de resolução de problemas com estruturas de dados e algoritmos
• Exercícios de codificação em plataformas como LeetCode, HackerRank ou Codewars

Analista de Sistemas​

Sobre​

Sou Felipe Jorge Sales da Silva, um Analista de Sistemas apaixonado por tecnologia e desenvolvimento web. Com mais de 8 anos de experiência em programação, sou formado em Análise e Desenvolvimento de Sistemas pelo IFSP e possuo uma pós-graduação em Software para Web pela UFSCar. Atualmente, trabalho como Desenvolvedor Front-end Angular no Santander Tecnologia Brasil, localizado em São Carlos, São Paulo.

Possuo um perfil sênior e amplo conhecimento em desenvolvimento full-stack, tendo liderado e conduzido projetos em diversas empresas. Trabalho com metodologias ágeis, como Scrum e Kanban, e possuo habilidades em code review, front-end, back-end e bancos de dados relacionais.

Destaco-me pela minha expertise em CSS, HTML semântico, SEO e pelo compromisso com a acessibilidade, desenvolvendo sistemas altamente performáticos, responsivos e adaptáveis para pessoas com deficiência visual. Acredito no trabalho em equipe, no respeito a todos os profissionais envolvidos e na aplicação de boas práticas em todos os aspectos do desenvolvimento.

Além da minha experiência profissional, sou empreendedor e já criei minha própria empresa, oferecendo serviços de criação de websites de qualidade e soluções inovadoras.

Experiência Profissional​

Santander Tecnologia Brasil
Mar 2021 - Atualmente (28 meses)
Trabalho como desenvolvedor Angular em projetos como Meus Limites Pix, Tela de Atendimento, Nova Home, Login, Cadastro, Campanhas Cashback e Cartões Internacionais. Além de fazer migrações de versões de Angular, criar novos componentes para o Desygn System e Disparo de tagueamento para Google Analytics, além de participar e ser reconhecido no programa "Code Girls" responsável por auxiliar e ensinar novos funcionários.

Monitora Soluções Tecnológicas
Mai 2018 - Mar 2021 (34 meses)
Desenvolvedor Full Stack com experiência em Java Spring, Adobe Flex, Oracle Database, Spring. Trabalhei na Vistajet, desenvolvendo funcionalidades como timelines de voos, contratos e sistemas financeiros. Realizei manutenção no banco de dados Oracle e criei tabelas, campos, procedures e functions. Também trabalhei no desenvolvimento de microserviços com Spring e MySQL, e na migração e manutenção de microserviços frontend com React. Sempre utilizando metodologia ágil (Scrum), além de boas práticas de programação como o Code Review por todo periodo de experiência.

Fui escolhido e me destaquei-me no projeto do Itaú, um projeto curto que precisava de alguém altamente experiente em frontend para criar um sistema rápido (menos de 2 meses), de um evento para o Itaú, criando todas as telas usando o framework Laravel (PHP), liderando a parte de frontend na criação de layouts de páginas e contéudo.

Agência Kife
Jan 2018 - Mai 2018 (5 meses)
Trabalhei na criação de layouts complexos, utilizando minha experiência em criação de componentes, lá fiz sistemas de blogs, incluindo a criação de painel de administrador, templates de Wordpress criados do zero, websites e hotsites, lojas e lojas e-commerce, além de trabalhar no novo site e blog da agência, trabalhando no SEO para alavancar a agência no ranking de mecanismos de busca. Fui responsável pelo treinamento de novos integrantes, sendo líder técnico, orientando, ensinando e decidindo as tecnologias utilizadas, participando de entrevistas e tomando decisões.

Octo Propaganda
Out 2017 - Dez 2017 (3 meses) A oferta de trabalho pela Agência Octo Propaganda foi uma parceria, que como parceiro fui responsável pelo desenvolvimentos de sistemas, sendo responsável pela criação de templates Wordpress customizados, criação de sites, hotsites e e-commerce, além disso eu fui responsável por fechar uma parceria da Xtech commerce com a Octo Propaganda, fazendo a Octo Propaganda se tornar um parceiro Xtech, fazendo a empresa encaminhar serviços para a agência.

Xtech Commerce
Out 2016 - Set 2017 (12 meses) Tudo começou com uma parceria com a Xtech Commerce, eu fechei uma parceria e abri minha própria MEI(Microempreendedor Individual), com isso trabalhei para uma empresa de E-Commerce do Rio de Janeiro. Começando com o desafio de criar o template Mobile deles para a plataforma. Apesar de desafiador foi um sucesso e fui responsável pelo novo template mobile da loja, depois disso fui responsável na criação de templates customizados para clientes contratados pela Xtecho, criando dois templates por semana, onde consegui estabilidade e experiência frontend de criação de templates por um periodo de um ano.

Agência Roadie e RDCommerce
Fev 2015 - Jul 2016 (18 meses) Na Agência Roadie, fui contratado por ser reconhecido pelos meus freelances que fazia, vendendo hotsites e sistemas web PHP. De maneira autodidata comecei com o desafio de fazer temas em Wordpress do zero, e aprendi a criar temas Wordpress customizados, hotsites e sistemas, criei aplicativos mobiles que disparavam notificações push, utilizando Java para front end e PHP para disparar as notificações push, além de sistemas utilizando o framework Laravel(PHP). Com isso me destaquei e treinei novos desenvolvedores. ALém disso fui um dos responsáveis pela criação do RDCommerce, uma plataforma de E-Commerce, utilizando a tecnologia do OpenCart criamos uma plataforma que cria e-commerce automatizado.vç[]

Monitoria em Banco de Dados IFSP
Jul 2014 - Dez 2014 (6 meses) Meu primeiro emprego remunerado, era estagiário responsável por dar monitoria em banco de dados, para conseguir isso eu fiz um desafio de uma prova e o aluno com maior nota seria escolhido como monitor, com isso eu ensinava para os alunos como criar banco de dados da maneira correta, utilizando a normalização de banco de dados e os preparava para as provas, ajudei na correção de provas e recebi feedbacks positivos nas notas, sendo que um dos alunos que participou da monitoria tirou nota máxima. Banco de dados tem um valor especial no meu coração onde me ajudou a me destacar e resolver tarefas complexas em Oracle na Vistajet Futuramente.

Experiência Total - 8 anos e 10 meses

Formação Acadêmica​

UFSCar - Universidade Federal de São Carlos​

Curso de Pós Graduação Lato Sensu em Computação - Desenvolvimento de Software para Web (2019)

• Academia Ágil: Atuação em times ágeis, implantação de frameworks ágeis em larga escala e desenvolvimento prático de um projeto ágil (Scrum, Kanban).
• Desenvolvimento de Software em Java: Uso de linguagem Java e seus frameworks e APIs mais utilizados no mercado.
• DevOps: Apresentação dos principais tópicos relacionados a DevOps.
• Teste Funcional e Estrutural em Aplicações Web e Aplicações Móveis.
• User eXperience [para todos] na Web: Princípios, conceitos e vertentes de User eXperience (UX).
• Desenvolvimento de Software do front e back-end: Uso de tecnologias como React e Angular.
• Metodologia de Pesquisa – Revisão Sistemática.
• Tópicos em Desenvolvimento de Software.

Instituto Federal de Educação, Ciência e Tecnologia de São Paulo - IFSP​

Análise e Desenvolvimento de Sistemas, Tecnologia em Tecnologia da Informação/Sistemas da Informação (2013-2016)

• Desenvolvimento de softwares de desktop, aplicações web, modelagem de banco de dados utilizando Mysql e Oracle, Casos de uso, Estrutura de Dados, Auditoria e Segurança de Sistemas.

Etec Paulino Botelho​

Técnico em Informática (2012)

• Desenvolvimento de softwares desktop e criação e arquitetura de base de dados.

Etec Paulino Botelho​

Informática Para Internet (2010-2011)

• Desenvolvimento de aplicações web utilizando HTML5, CSS, Javascript, PHP e Mysql.
• Criação de arquiteturas e modelos de banco de dados.