Mentoria de carreira – tudo o que você precisa saber
Muito se fala sobre a mentoria de carreira como uma grande aliada na estratégia de desenvolvimento de pessoas nas organizações. Segundo pesquisas da Harvard Business Review, 75% de pessoas colaboradoras de empresas não estão satisfeitas com o programa de capacitação corporativo e apenas 12% conseguem realmente aplicar na rotina os aprendizados de cursos ou treinamentos disponibilizados pela empresa. Já uma pesquisa da Forbes apurou que mais de 71% das empresas da Fortune 500 possuem programas de mentoria focados em carreira. O estudo da Endeavor publicado na Forbes mostrou que 92% das pessoas empreendedoras acreditam que uma figura mentora impactaria no crescimento das suas empresas. Ou seja, dizer que mentoria é um assunto que está na moda seria um eufemismo, é uma preocupação de muitas empresas e profissionais, que não se limita somente à área de TI.Neste artigo, vamos aprofundar um pouco mais a respeito da mentoria de carreira e dos outros termos muitas vezes associados a esse tema. O que chamamos de mentoria? Pensando na definição enciclopédica, mentoria é o processo em que se estabelece uma relação entre uma pessoa mais experiente – pessoa mentora – com outra menos experiente – pessoa mentorada – com o foco na orientação para o crescimento pessoal e profissional. É o ato ou processo de ajudar e dar conselhos a uma pessoa mais jovem ou menos experiente, especialmente em um emprego ou na escola. Assim, essas pessoas podem crescer mais rápido com mais estudo, orientação e revisão intensiva. Apesar desse conceito já ser amplamente difundido, queremos deixar uma ressalva sobre mais ou menos experiente, mais velho ou mais jovem. Quando buscamos uma mentoria, por vezes temos interesse em amadurecer alguma habilidade específica ou aprofundar um conhecimento. Isso não quer dizer que apenas pessoas de “cargos acima” ou “mais velhas” poderiam nos oferecer tal troca, precisamos estar disponíveis a aprender com qualquer pessoa, com humildade e escuta empática. Com o mercado abordando cada vez mais o T-shaped skills (ou habilidades em T), temos colegas que escolheram se aprofundar naquilo que nós escolhemos ampliar e isso nos dá a oportunidade de encontrar mentorias em todas as nossas relações. Benefícios da mentoria de carreira As vantagens da mentoria são inúmeras. Além de ter um processo e um acompanhamento personalizado, a pessoa mentora facilita a tomada de decisões e orienta o desenvolvimento de planos, podendo compartilhar experiências em casos reais, estratégias e técnicas que foram aperfeiçoadas com o tempo através de acertos e erros. Por meio das novas experiências adquiridas, é possível perceber a pessoa aconselhada adquirindo e reforçando competências essenciais para o seu sucesso profissional, ou seja, isso acelera muito o processo de aprendizagem. Segundo pesquisa realizada por Silva (2008) em sua dissertação de mestrado, um grupo analisado afirmou que, a partir das experiências adquiridas no processo de mentoria, as pessoas se mostraram mais abertas a refletir sobre suas atitudes e a perceberem os pontos fracos. O processo ajuda a resgatar a satisfação, a vencer limitações e a ter responsabilidade pelas escolhas As relações de mentoria, especialmente as formais, organizadas por meio de um programa, geralmente são estabelecidas com um limite de tempo ou meta definida. Ter essa estrutura em vigor pode ser mais fácil para ambas as partes concordarem do que um compromisso em aberto. Por exemplo, uma pessoa aconselhada pode concordar em trabalhar com outra pessoa mentora por um ano ou até alcançar uma promoção específica desejada. Após atingir o prazo ou atingir a meta, os prazos podem ser renegociados. Podendo decidir continuar trabalhando, especialmente se o relacionamento tiver sido produtivo e útil para os dois lados. Tipos de mentoria Antes de tudo é preciso identificar qual modelo de mentoria melhor se adequa ao seu momento de vida, a Sociedade Brasileira de Desenvolvimento Comportamental traz uma lista de 15 tipos de mentoria, são elas: Inclusive, o modelos mais conhecidos e praticados são: Antes de começar Nós convidamos aqueles que buscam uma mentoria para validar alguns pontos antes de começar essa jornada: a) tenha clareza do que está buscando enquanto carreira e desenvolvimento, o que falta ou pode ser melhorado para sua entrega ser feita; b) tente ao máximo tangibilizar isso em características, habilidades e comportamentos para situações reais; c) por fim, busque aquela pessoa que realmente contribuirá para essa evolução. Receber mentoria não é um rótulo superficial, e nem deve ser buscado apenas para seguir o que é tendência. Um resultado positivo será alcançado quando o processo for vivido de forma genuína. O que é uma boa mentoria? Independentemente do tipo de mentoria escolhido, existe a figura da pessoa mentora, de acordo com Fandino et al. (2016), é ela que proporciona um ambiente onde novas ideias são exploradas, amadurecidas, colocadas em teste e inseridas na organização, contribuindo assim não só para o desenvolvimento da carreira profissional, como de toda a organização. Cada mentoria é única. No entanto, existem algumas características que todos os relacionamentos bem-sucedidos compartilham. 1. Respeito mútuo A relação entre partes é uma relação profissional de mão dupla, ambas investidas no sucesso de quem recebe os conselhos. A pessoa que aconselha não menospreza ou diminui a outra de forma alguma – afinal, também já esteve no mesmo lugar. Da mesma forma, a pessoa que recebe os conselhos respeita e escuta as opiniões com atenção. 2. Conexão pessoal As pessoas que compartilham semelhanças são mais propensas a ter um relacionamento de mentoria bem-sucedido. Podem ser suas crenças e valores, formação educacional, trajetória de carreira ou até mesmo lugar de origem. Um bom programa de mentoria irá emparelhar partes que têm algo em comum. 3. Comunicação e escuta A comunicação eficaz é essencial para um relacionamento bem-sucedido! A pessoa mentora deve ser capaz de fornecer feedback construtivo e usar a escuta ativa para julgar o que a pessoa mentorada precisa. Lembrando que quem recebe a mentoria deve receber feedbacks e também usar a escuta ativa para garantir que entende o que está sendo transmitido. 4. Expectativas realistas A dupla deve concordar com um conjunto de expectativas realistas para os resultados do relacionamento. Por exemplo,
API de data do Java: domine o uso de data no seu código
Lidar com datas ou qualquer operação que usa o tempo como unidade de medida é sempre um grande desafio. Dentro do mundo Java, isso não é diferente, no entanto, desde o Java 8 a nova API de data traz várias melhorias. Neste artigo vamos entender mais sobre essa complexidade para trabalhar com datas e como API de data do Java é útil. Afinal, por que a data é tão complexa? As APIs de datas são consideradas muito complexas, mas afinal qual o motivo dessa complexidade? Ao contrário das outras unidades de medida, as datas possuem complexidade física, cultural, política, histórica e também religiosa. A parte física para o tempo já é muito difícil. Albert Einstein em sua teoria da relatividade demonstra que é possível a dilatação do tempo. Desse modo, todas as viagens temporais do filme Interstellar são comprovadas, é possível entender mais sobre essas teorias no livro “The Science of Interstellar”. Além da complexidade natural, existem diversas intervenções políticas, como: Existem muitos impactos externos ao tempo e isso não ocorre com outras unidades de medida, por exemplo, não existe uma unidade de medida de distância modificada ao longo do ano, como um “metro de verão” ou uma unidade que deixe de existir por decreto. Entendendo os conceitos do tempo Já existe uma certa complexidade dentro da API de data, mas também pode-se observar outro problema em grande parte das pessoas que trabalham com desenvolvimento: não entendem o conceito de unidade de tempo. Conhecer esses conceitos já é complexo, sem entender dificulta mais ainda. Por exemplo, se alguém perguntar: “Que dia é hoje? Ou que horas são?” a resposta será depende, como os grandes problemas na história da computação ou de arquitetura de software. Afinal, para saber o dia ou as horas, depende de qual local estou me referindo, o agora pode mudar se estou me referindo a Lisboa ou a São Francisco. O objetivo aqui é falar sobre os conceitos mínimos para facilitar o dia a dia de devs: Resumindo… O UTC é o padrão utilizado atualmente para controlar o tempo de todo o mundo e a sua unidade de medida é o offset. Já o horário de verão, se resume em adiantar uma hora do relógio, ou seja, aumentar um no offset do seu horário e o time zone é responsável por conter o histórico dos horários de uma região. Conhecendo a API de data do Java Depois da contextualização do negócio e do conceito que está por trás do tempo, vamos falar sobre a não tão nova API de data do Java 8. Existem duas tentativas com tempo no mundo Java, no entanto, a minha recomendação é para os novos sistemas e funcionalidades não importarem nenhuma API que não esteja no pacote “java.time”. As entidades O primeiro passo é conhecer os tipos de entidades que a API de data traz suporte, esse artigo não cobrirá o detalhes de todos, mas você pode procurar uma leitura mais detalhada. Um ponto importante: a API traz representações que cobrem dia, mês, dia da semana, ano, timezone, offset, além da combinação de todas elas! A primeira interação com a API de data. Nesse memento, o que é feito a criação da cada tipo. Salientamos aqui as possibilidades que podem ser utilizadas com tipos ou entidades que representam tempo na API, ao invés de usar apenas um único, como era realizado anteriormente. Por exemplo, o YearMonth para trabalhar com a data de validade de um cartão de crédito ou Year para lidar com o ano de publicação de um livro. Essas variáveis, além de trazer uma melhor semântica para dentro do código, trazem clareza e simplificam como você realiza as validações. Isso é baseado no clássico e já mencionado “When Make a Type” do Martin Fowler. Exemplo da criação da variável Year que lançará uma exceção uma vez que é um ano inválido pela API. O teste foi criado utilizando JUnit 5 ou Jupiter. É possível também realizar combinações entre tipos para criar uma instância final, por exemplo, começamos com ano e vamos até à data. Criação de modo fluente com relação ao data de aniversário. Assim, como primeiro passo, sugiro que você explore e leia um pouco mais sobre os tipos que a API suporta. Essas APIs são muito mais eficientes para representar o tempo que tipos mais genéricos como int, long ou String, já que a API de data possui validações temporáveis. Operações com data Além de trazer mais semântica e validação para lidar com datas, a API também traz algumas operações bem interessantes que visam facilitar o seu dia, além de salvar o seu tempo. Desculpa o trocadilho tentador. As operações mais básicas são as de adicionar ou remover períodos, como mês ou dias, através dos métodos com os sufixos “plus” ou “minus” respectivamente. Utilizando operações básicas do LocalDate A interface TemporalAdjuster permite ajustes customizados e algumas operações mais complexas e a partir dela é possível criar várias operações customizáveis e reutilizáveis. Como convenção, essa classe utilitária traz diversos recursos, por exemplo, verificar a próxima segunda-feira a partir da data atual, me refiro a classe TemporalAdjusters. Exemplo de TemporalAdjustter de maneira simples utilizando a classe utilitária TemporalAdjusters para procurar a próxima segunda-feira. É possível também realizar comparações entre datas, nada muito recente comparado as API mais antigas, no entanto, é sempre importante salientar que isso existe. As operações básicas são bem úteis, porém, é possível ir além com o Period e também ChronoUnit. Com eles, você consegue ver a diferença entre um determinado período. Verificando os intervalos de diferença utilizando o Period e também o ChronoUnit. O último passo para comparação e verificação é o TemporalQuery, que tem o objetivo de extrair alguma informação do tempo. Exemplo do TemporalQuery que extrai uma informação booleana que verifica se é fim de semana ou não. O ponto de destaque de recursos de operações de data certamente é a possibilidade de trabalhar com os timezones. Exemplo de Offset utilizando o timezone de São Paulo. É possível realizar comparações de timezones diferentes,
Técnica INVEST – como quebrar User Stories de microsserviços
Há várias formas de quebrar User Stories, uma delas é com a técnica INVEST. A partir do entendimento da teoria de microsserviços e a experiência prévia que eu tinha de quebra de user stories utilizando a técnica INVEST comecei a testar alguns modelos para aplicar o conceito a este novo contexto. Neste artigo abordamos alguns exemplos sobre como podemos aplicar a técnica INVEST no dia a dia. Um pouco sobre a minha experiência de quebra de user stories utilizando a técnica INVEST Durante uma boa parte da minha carreira na área de engenharia e gestão de produtos trabalhei em contextos onde sempre havia uma jornada front-end para ser entregue para o usuário final. E durante todo este tempo toda técnica que aprendi para escrita de user story foi com foco no detalhamento dos requisitos das regras que deveriam estar contidas no front-end e nas regras aplicadas ao executar alguma ação. Iniciei na área de desenvolvimento em 2008 e durante este período trabalhei com Windows Form no VB6, front-end no ASP Clássico, telas do Delphi e a famosa tela preta das aplicações em Cobol. E é incrível ver como a tecnologia avança rápido e a maneira como trabalhamos muda radicalmente. Em 2018 comecei a trabalhar no papel de Project Manager e me deparei com cenários onde o escopo das squads eram exclusivos de back-end através de microsserviços. Acabando de sair de um projeto feito em Salesforce tive que mudar muito da maneira que eu atuava para definir os requisitos para me adaptar a este novo cenário. O ponto de partida foi dedicar uma boa parte do meu dia estudando, consumindo muitos tutoriais de blogs e YouTube para aprender mais sobre este cenário. Dentre as pesquisas: Recomendo fortemente que estudar temas relacionados a este contexto seja um hábito. Tenha curiosidade e procure reservar pelo menos 30 minutos do seu dia para adquirir novos conhecimentos. Acredito que o melhor caminho para acumular conhecimento é seguir as etapas: Afinal, o que é a técnica INVEST? Uma técnica que aprendi durante a minha carreira para quebra de história (user stories) é o INVEST que na minha visão é uma diretriz para tentar padronizar a quebra de histórias para alimentar a cadeia de valor da squad. De maneira bem resumida seria: Mas e aí? Como aplicar este conceito em um contexto de microsserviços? Como usar a técnica INVEST na prática Dentre os principais itens que entendo como importante termos como resultado no final de um Discovery destaco Product Backlog e o Diagrama de arquitetura. Vou explicar os dois a seguir: Product Backlog Através de técnicas como entrevistas, lean inception e outras é importante que seja mapeado o Product Backlog. Eu gosto de montar uma planilha com uma aba com os épicos e outra aba com histórias identificadas durante o processo. Exemplo fictício de mapeamento de epics: # Epic Description 1 Onboarding – Validação de Token Criar mecanismo responsável pela validação de token 2 Onboarding – Fraude Criar mecanismo responsável pela validação de fraudes 3 Onboarding – Biometria Criar mecanismo responsável pela validação de biometria 4 Onboarding – Credenciais Criar mecanismo responsável pela criação das credenciais de acesso 5 Onboarding – Atualização dos dados cadastrais Criar mecanismo responsável pela atualização dos dados cadastrais do cliente Exemplo fictício de mapeamento de user stories: # Epic User Story User Story (Description) Doubt 1 Onboarding – Validação de Token História A Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 2 Onboarding – Validação de Token História B Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 3 Onboarding – Validação de Token História C Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 4 Onboarding – Fraude História D Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 5 Onboarding – Fraude História E Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 6 Onboarding – Fraude História F Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 7 Onboarding – Biometria História G Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 8 Onboarding – Biometria História H Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 9 Onboarding – Biometria História I Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 10 Onboarding – Credenciais História J Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 11 Onboarding – Credenciais História L Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 12 Onboarding – Credenciais História M Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 13 Onboarding – Atualização dos dados cadastrais História N Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 14 Onboarding – Atualização dos dados cadastrais História O Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas 15 Onboarding – Atualização dos dados cadastrais História P Narrativa de negócio e critério de aceite em alto nível Para mapeamento de dúvidas e respostas Diagrama de arquitetura Em paralelo ao mapeamento do Product Backlog fazer uma proposta inicial do diagrama de arquitetura mapeando todos os microsserviços que pretendemos criar, banco de dados, filas, integrações com outros domínios, etc. Vale reforçar aqui que é uma proposta beta para nortear o início do projeto e que esta arquitetura será refinada com o decorrer dos próximos ciclos. Exemplo fictício de um diagrama de arquitetura: Começando a trabalhar com a técnica INVEST Dado o mapeamento inicial de escopo e a proposta de arquitetura alvo, agora é hora de refinar mais um pouco os temas mapeados realizando as quebras utilizando
O desejado mindset de produto
Por que alguns produtos digitais tem muito sucesso e suas empresas se destacam no mercado enquanto outros são facilmente esquecidos pelo público? Parece a pergunta de milhão de reais, mas a verdade é que há muitos fatores que explicam o sucesso de uns e o fracasso de outros. Uma dessas possíveis explicações é o mindset de produto. Quer descobrir o que é mindset de produto e 11 características que toda big tech bem sucedida no quesito têm em comum? Então continue lendo. Antes de avançar, o que é mindset de produto? Diferente do mindset de projeto, o mindset de produto foca na entrega de valor e propósito. É como se compararmos uma entrega feita no prazo com uma entrega feita para resolver uma dor diretamente ligada aos objetivos e propósitos do produto e de clientes. O mindset de produto endereça dores reais, em vez de focar cegamente em entregas. Da gestão de projetos ao mindset de produto Desde a década de 60 quando o gerenciamento de projetos foi fundado, o universo da tecnologia passou por transformações profundas na forma de criar e gerir produtos. Em 1969 foi criado o Project Management Institute (PMI) com o objetivo de formalizar todo o framework e as boas práticas de gestão de projetos. De lá pra cá muita coisa mudou, o aparecimento da gestão de produtos foi um game changer no mercado e nas empresas de tecnologia. Com o aparecimento de grandes idéias algumas empresas se destacaram, por exemplo, Apple, Google, Amazon, Meta para citar apenas algumas. Com isso, algumas perguntas começaram a pairar na mente das pessoas, por exemplo: A resposta para essas perguntas parece muitas vezes simples: elas têm mindset de produto. Mas o que é necessário para o atingimento deste mindset de produto? Não existe uma fórmula para atingir o mindset de produto. Porém, existem sintomas nas empresas que podem ser detectados e alterados. Afinal, a transformação é sempre muito difícil mesmo quando necessária. Muitas pessoas poderiam dizer que uma empresa com uma cultura voltada para produto resolveria o problema ou que a falta de cultura de produto poderia ser um. Porém, indo um pouco mais longe podemos dizer que a cultura não determina se o mindset de produto será vigente na empresa, mas sim o funcionamento e o empoderamento dela como um todo. Inclusive, aqui teríamos outros fatores que seriam pauta de discussão e até mesmo reflexão. O que dizem especialistas em Produto Segundo Marty Cagan em seu segundo livro Empowered empresas como Google, Amazon, Apple e Netflix podem ser consideradas fortes e produtizadas, com entregas e produtos consistentes que são amados por milhões de pessoas, mas têm diferentes culturas. A cultura na visão do autor não seria o diferencial, em sua visão, temos pontos anteriores, por exemplo: Já Eric Ries em seu livro The Lean Startup diz que sucesso não é entregar uma feature e sim aprender como resolver o problema do cliente. Considerando que para resolver o problema de clientes (pelo menos no caso de produtos digitais) é necessário muitas vezes entregar uma feature em produção, como chegamos a essa fórmula mágica do mindset de produto? Melissa Perri, autora de Escaping the build trap nos traz o seguinte pensamento: “O maior aprendizado que já tive em gestão de produtos é sempre focar no problema. Se você se ancorar no porquê, vai, na maioria das vezes, construir a coisa certa.” Poderíamos seguir aqui com outras personalidades de Produto, porém teríamos o mesmo consenso: empresas produtizadas focam em resolver problemas e na entrega de valor! 11 características de empresas com mindset de produto forte O ponto que temos aqui seria como atingirmos esse mindset de produto? Acredito muito que essas empresas produtizadas tem algo em comum sim, mas não seria exatamente a cultura. Empresas de produto podem ter culturas diferentes, porém todas elas têm características em comum: A seguir vamos ver cada uma dessas características em detalhes. Vamos nessa? A área de tecnologia Muitas empresas ainda enxergam a engenharia como uma área para servir o negócio. Líderes que repassam para seus times que os clientes de engenharia são as pessoas de negócio da empresa. Quando um porta voz é criado para a comunicação e repasse do negócio para os times de engenharia você está blindando seu time da realidade! Seu time de engenharia deve participar ativamente de discoveries, acompanhar métricas de negócio, ter ciência de quais ponteiros suas entregas irão mudar. Se você quer pessoas engajadas e apaixonadas pelo problema, inclua elas nas decisões. Aliás, a inclusão de engenharia nos processos e com o cliente irá revelar outras possibilidades antes não enxergadas! Estruturas flat e simples Em muitas empresas estruturas hierárquicas ainda são práticas vigentes e prejudicam, em muito, a fluidez da comunicação e o alinhamento. Na gestão de projetos temos uma fórmula para calcular o número de canais de comunicação possíveis: Número de possíveis canais de comunicação = n x (n-1)/2 Na prática, quanto mais pessoas envolvidas em uma estrutura, maior será o número de canais de comunicação possíveis. A ideia aqui é mantermos estruturas simples para que nossa comunicação e alinhamento sejam fluidas e sem distorções. Times de Produto ao invés de times de features A diferença principal entre um time de Produto e um time de features é o quanto de empoderamento o time tem para entregar resultado. Se um time não é empoderado ele não é comprometido com o problema e assim não pode ser responsável pelos resultados e sim somente pelas features encomendadas em produção. Como o próprio Marty Cagan cita várias vezes em seu primeiro livro Inspired: “Queremos um time de missionários e não mercenários…”. Visão de Produto Uma visão de produto (ou product vision no original) bem formulada, inspiradora e com propósito bem definido é ingrediente essencial para que as empresas possam tornar seus produtos relevantes, bem como focar no problema certo a ser resolvido. Estratégia de Produto Não basta termos uma visão muito bem formulada e inspiradora, temos que ter uma estratégia de produto bem definida e sólida. Neste ponto acredito
Architecture Decision Records (ADR): o que é e como fazemos na Zup
Com o passar do tempo e a evolução das tecnologias, construir software tornou-se mais rápido, porém mais complexo na mesma proporção. Por isso, ferramentas que organizam e principalmente documentam a tomada de decisão sobre arquitetura de software são mais do que bem-vindas. Neste artigo nós vamos te apresentar o que é Architecture Decision Records (ADR) e como adotamos esse documento na Zup. Mas vamos dar um passo para trás e voltar a falar sobre agilidade e complexidade no desenvolvimento de software. Isso se deve, principalmente, a dois fatores: a mudança do papel do software e a natureza do software. A seguir vamos ver eles em detalhes. A mudança do papel do software: software como meio para atingir um objetivo Nos primórdios do desenvolvimento de aplicações, o software surgiu com o propósito único e exclusivo de processar dados. Nessa época, o hardware era um um ponto de maior atenção, principalmente, devido o seu custo e consequentemente isso tornava o uso dessa tecnologia pouco acessível. Com a evolução econômica e tecnológica, o software deixou de só processar dados e começou a ter um papel estratégico; surgindo assim os sistemas de informações, onde esse processamento de dados passou a auxiliar em tarefas e tomadas de decisões nas empresas. O hardware já não era um fator determinante e isso tornou a tecnologia mais acessível. Em paralelo, às mudanças tecnológicas e econômicas continuaram a acontecer e o software passou a ser utilizado de forma massiva e não mais um privilégio para poucas pessoas; se tornando um fator de inovação e vantagem competitiva para quem o utilizava. Essa mudança de escopo e atuação transformou o impacto do software no negócio, e isso fez seu uso se tornar estratégico, e um meio para atingir o seu objetivo. Essa nova visão mudou a forma de fazer software. Surgiram assim as metodologias ágeis, com o propósito de acelerar e facilitar as entregas e as mudanças durante o desenvolvimento de um software. A necessidade era que o desenvolvimento funcionasse rápido e de forma consistente, para que as mudanças não afetassem negativamente o negócio. A natureza do software: inconstância e evolução Alinhado a toda essa mudança de papel, podemos afirmar que um software possui três características: complexidade, efemeridade e mutabilidade. Complexidade. O software não é somente código; envolve tecnologia, pessoas, processos e negócios. Efemeridade – Tecnologias vêm e vão diariamente. Uma funcionalidade ou um software inteiro pode se tornar inviável/obsoleto de uma hora para outra, seja por uma tecnologia depreciada, uma vulnerabilidade mapeada, entre outros. Mutabilidade – Devido às duas características citadas anteriormente, a mutabilidade se torna imprescindível para o software se manter funcionando. É preciso evoluir constantemente. Afinal, o que é arquitetura? Uma das discussões mais homéricas na área de engenharia de software, certamente é a definição do termo arquitetura. Resumindo sem polêmicas: Arquitetura é a organização, comunicação e estrutura de todos os softwares e serviços de uma área, além de nutrir a visão tecnológica. Modelo descentralizado para o sucesso! Ao longo do tempo, diversas metodologias surgiram e substituíram outras. Esse é o caso, por exemplo, do Management 3.0 que condena o fordismo ou modelo top-down e valoriza um modelo com mais participação através de seis pontos: A liderança precisa controlar o ambiente e não as pessoas. Isso quer dizer, fornecer todas as condições necessárias para que as atividades sejam realizadas da melhor maneira possível pelos indivíduos, e assim, maximizar os resultados. Esse modo de liderança não faz sentido apenas para gestão de pessoas, mas para a arquitetura de software também. Afinal, como garantir que toda a estrutura funcione com apenas uma única pessoa controlando? Naturalmente, não existe software ou uma única pessoa capaz de garantir uma boa governança. Afinal, não tem como fugir da Conway’s law. Em outras palavras, se a organização for confusa isso se refletirá no software. Logo uma arquitetura distribuída precisa considerar que o time seja bem distribuído e tenha autonomia. Substituindo o “faça!”, por “faz sentido?” Ao longo de anos, foi possível perceber as diversas tentativas de ter apenas uma pessoa como profissional de arquitetura ou um único setor responsável pela arquitetura. Mas, essas abordagens falharam miseravelmente, o que rendeu apenas boas piadas: Vale sempre salientar que o maior papel de profissionais de arquitetura, é escolher o trade-offs das decisões de arquitetura, ou seja, o contexto é a chave para qualquer decisão estratégica em nível tecnológico. Outro ponto é o livro “Skin in the game”, que fala que nós temos mais receio de tomar uma má decisão quando essa também nos impacta. Sem falar que o software vive em constante evolução e adaptação, e aprendemos isso com Manifesto Ágil, ou seja, uma boa decisão hoje, pode não ser uma boa decisão amanhã. A solução para isso, é uma eterna vigilância de todos os times como arquitetos de software. Ou seja, a responsabilidade da arquitetura não é de uma única pessoa externa, mas de todo o time, incluindo a sua manutenção. Erik Dörnenburg confirma e relata isso na sua apresentação: Arquitetura sem profissionais de arquitetura (em inglês). É preciso seguir um modelo descentralizado para solucionar esse problema. E hoje, é possível observar uma alta adesão e com resultados positivos, por exemplo, no livro Software Engineering at Google existe um sessão para condenar o mito de um único gênio. Se focarmos no outro extremo, certamente, teremos insucesso, afinal, se todo mundo pode tomar decisões, isso pode resultar em uma mistura de soluções com um alto grau de complexidade. Ruth Malan defende o papel de profissionais de arquitetura, porém, como facilitadores. Documentação, descentralização e inspiração: A melhor combinação para a escalabilidade da sua arquitetura Existem uma série de falácias e mitos na área de engenharia de software e tenho plena convicção de que o self-documenting code está nessa lista. Precisamos fazer um bom código, fluido e próximo da linguagem ubíqua, porém, isso não nos exime de documentar o nosso código. Em outras palavras, é necessário realizar as boas práticas de clean code como nomes significativos, tamanho dos métodos, menor curva ciclomática, aplicar o Domain-Driven Design (DDD), dentre
Infraestrutura como código: 8 práticas ruins de segurança em scripts para evitar
Se tem algo que merece a sua atenção é formas de aumentar a segurança de um processo, ainda mais algo tão estratégico como infraestrutura. Por isso, hoje eu gostaria de falar não só sobre o conceito de Infraestrutura como código (IaC), mas também de algumas práticas ruins de segurança que você pode evitar – e manter sua operação segura. Como chegamos na Infraestrutura como código (IaC) Ao longo do processo de desenvolvimento de software, times de infraestrutura precisam trabalhar para garantir que as soluções criadas sejam disponibilizadas em ambientes de produção atualizados e seguros. Para tal, estes times de infraestrutura realizam tarefas como: Durante algum bom tempo, times de infraestrutura criavam scripts em BASH/Perl/etc para automatizar essas tarefas. No entanto, com o crescimento e disponibilidade de sistemas de cloud, a execução desses scripts se tornou uma tarefa manual, ou seja, demorada, além de ser propensa a erros. Imagine ter que executar um script escrito em BASH em centenas (ou milhares) de instâncias da AWS? Precisaríamos ter que logar em cada instância, enviar o script para cada uma delas, alterar a permissão de execução do script, para só depois executá-lo. Infraestrutura como Código (IaC): o que é e sua relevância Antes de avançar, é importante trazer o conceito. Infraestrutura como código (do Inglês, Infrastructure as code, ou simplesmente IaC) é o processo de gerenciar e provisionar infraestrutura por meio de código, em vez de fazê-lo manualmente. Por isso, boas práticas de código, da escrita à segurança, são tão importantes. Scripts de infraestrutura como código surgiram em parte como forma de minimizar o esforço de criação e manutenção das tarefas de infraestrutura. Com scripts de IaC, a execução de um único script pode refletir em centenas (ou milhares) de instâncias de um servidor de nuvem. De acordo com um relatório de 2019 da RightScale, que conduziu um questionário online com 786 praticantes da indústria de software, 84% mencionaram que utilizam uma estratégia de multi-cloud, ou seja, utilizam de variados serviços de nuvem de diferentes fornecedores, como forma de otimizar os recursos e custos de infraestrutura. O uso de scripts de infraestrutura é comum em diversas empresas de tecnologia. Em um relatório de 2015, empresas como a Intercontinental Exchange (ICE) afirmam que utilizam scripts de infraestrutura para manter 75% do seu ambiente de desenvolvimento, composto por 20.000 servidores. Nesse mesmo relatório, foi observado que a utilização de scripts de infraestrutura tornou a ICE capaz de diminuir o tempo necessário para provisionar ambientes de desenvolvimento de 1 a 2 dias para 21 minutos. Ferramentas para Infraestrutura como Código Na atualidade, há um número significativo de ferramentas que possibilitam a criação de scripts de infraestrutura como código. Dentre as que se destacam estão, por exemplo: De acordo com o mesmo relatório de 2019, Ansible aparece como a ferramenta mais popular para implementação de scripts de IaC. Quando comparado ao mesmo relatório de 2018, Ansible subiu de 36% de adoção para 41% em 2019. No mesmo período, Terraform subiu de 20% de adoção para 31%. Essas ferramentas fornecem construções de linguagem de programação, como uma sintaxe bem definida e gerenciamento de dependências, de forma que times de infraestrutura (ou de desenvolvimento) possam descrever as tarefas de provisionamento em forma de scripts. Scripts de IaC como cidadãos de primeiro nível Os códigos desses scripts, por sua vez, são tratados como cidadãos de primeiro nível, ou seja, passam pelo mesmo controle de qualidade de um código escrito em uma linguagem de programação qualquer. Isso significa que scripts de infraestrutura devem ser mantidos, testados, revisados, depurados, etc. De forma análoga, scripts de infraestrutura como código, também podem apresentar bugs ou expor brechas de segurança. Uma vez que aplicações de software modernas precisam se comunicar com diferentes (micro-)serviços, uma senha hard-coded em um script de IaC pode ser a cereja do bolo para um usuário malicioso. Em um cenário em que multi-cloud passa a ser comum, a preocupação com a segurança dos serviços se torna ainda mais relevante. Mas como podemos fazer para que nossos scripts sejam menos vulneráveis a práticas ruins de segurança? Ou melhor, quais seriam essas práticas e como podemos identificá-las? 8 práticas ruins de segurança em scripts de Infraestrutura como Código A dupla de pesquisa, Akond Rahman e Laurie Williams, conduziu uma série de estudos empíricos (em parceria com outras pessoas ou não) sobre práticas ruins de segurança em scripts de IaC, por exemplo: Inclusive, aqui no blog da Zup a gente também já falou um pouco sobre estudos empíricos de Engenharia de Software. Nesses estudos, foram analisados mais de 50.000 scripts de infraestrutura como código, criados em mais de 800 repositórios de projetos de código fonte aberto, disponibilizados em plataformas como GitHub, OpenStack, Mozilla, dentre outros. Após um extensivo trabalho qualitativo de análise desses scripts, chegaram a um pequeno conjunto de oito práticas ruins de segurança em scripts de IaC que devem ser evitadas. Importante notar que estas práticas são chamadas de “más práticas”, em vez de “brechas de segurança”. Isso porque as más práticas indicam uma fraqueza de segurança nos scripts (que merecem atenção do time de desenvolvimento e infraestrutura), embora não necessariamente levem a brechas de segurança (que podem interromper a execução do programa). Vamos conhecer essas oito práticas ruins em detalhes a seguir, através de exemplos de scripts IaC escritos em Puppet. 1 – Admin by default Admin by default, ou administrador por padrão em português, acontece quando se fornece acesso de administrador para usuários comuns. Isso vai totalmente contra o princípio do menor privilégio, que sugere que times de desenvolvimento e infraestrutura desenhem sistemas de uma maneira que o menor acesso seja fornecido a uma entidade. 2 – Empty password Empty password, ou senha em branco em português, refere-se a deixar o campo de senha sem preenchimento. Isso indica a utilização de uma senha fraca (ou seja, que pode ser chutada). Uma senha em branco é diferente de não usar senhas (como no caso de autenticações baseadas em chaves públicas e privadas). Uma parte de um script IaC escrito em
KUTTL: faça testes de Kubernetes Operators
Fazer testes de Kubernetes Operators tem seus desafios, não é mesmo? Mas e se eu te dissesse que existe uma ferramenta de código que pode te ajudar muito nessa missão. Pois hoje eu vou te apresentar ao KUbernetes Test TooL, ou simplesmente KUTTL. Neste artigo vamos acompanhar o que é KUTTL, detalhes sobre a sua instalação e configuração, além de um exemplo de caso de teste utilizando essa ferramenta no macOs / Linux. O que é o KUTTL? KUbernetes Test TooL (KUTTL) é uma ferramenta open source de teste que facilita o teste de Kubernetes Operators. Para utilizá-la não é necessário conhecimento de nenhuma linguagem de programação específica, sendo todos os testes escritos em formato YAML de forma declarativa. As possibilidades de configuração de testes são inúmeras. É uma ferramenta de fácil utilização, possui documentação detalhada e foi criada pelo time de desenvolvimento do KUDO, o que passa confiança à ferramenta. Confira A documentação oficial do KUTTL é muito boa e vamos utilizá-la em alguns pontos desse tutorial. Inclusive, o site oficial da ferramenta também é bastante interessante. Agora vamos acompanhar como fazer as primeiras configurações do KUTTL. Pré-requisitos para instalar o KUTTL É necessário ter um cluster Kubernetes configurado ou ter o Kind instalado. Configure um cluster Kubernetes de versão 1.13 ou posterior no caso de necessitar rodar os testes em um cluster já configurado. Tenha instalado também o kubectl de versão 1.13 ou posterior. Instalação do krew O krew é um gerenciador de plugins do kubectl necessário para a instalação do KUTTL. Para instalá-lo rode o seguinte comando no seu terminal: Adicione a linha <export PATH=”${KREW_ROOT:-$HOME/.krew}/bin:$PATH”> no arquivo $HOME/.krew/bin para atualizar o PATH do krew e reinicie o terminal para aplicar as alterações. Instalação do KUTTL Para instalar o KUTTL rode o seguinte comando no seu terminal: Para facilitar asserções de teste instale também o plugin de assert. Para isso rode o seguinte comando: Configurações para os testes Agora que já vimos as principais informações para configurar o KUTTL é chegada a hora de fazer as configurações próprias para os testes. A seguir, além do passo a passo dos testes, eu vou abordar alguns conceitos importantes para esse tutorial. Configuração dos diretórios de teste Rode o seguinte comando para criar o diretório da suíte de testes: Cada pasta criada dentro do diretório “integration” irá representar um único teste. Configuração da suíte de teste Para informar as configurações da suíte de testes crie o arquivo kuttl-test.yaml na raiz do projeto. O arquivo deve conter basicamente o diretório de testes e o tipo relacionado ao escopo de testes: A criação desse arquivo é opcional. Caso não seja criado, os argumentos devem ser passados por meio de linha de comando na execução dos testes, por exemplo: Caso tenha criado o arquivo e utilize também argumentos na linha de comando, os argumentos irão sobrescrever as instruções do arquivo de configuração. Para mais informações sobre as possibilidades de configuração do KUTTL acesse a documentação de referência. Neste contexto vamos usar o arquivo de configuração como o criado acima, onde o KUTTL irá se encarregar de criar um cluster utilizando o kind e aplicar a imagem docker do operator a ser testado. O KUTTL criará também um namespace exclusivo para cada caso de teste, possibilitando rodá-los em paralelo e com isolamento entre eles, porém caso necessite, também é possível configurar um namespace específico para seus testes. Escrita de caso de teste Crie uma pasta com o nome do teste no diretório /tests/integration, nesse caso vamos nomear o teste de my-frist-test. O TestStep é um objeto que pode ser usado para especificar as configurações dos steps de teste. Os nomes de cada arquivo YAML deve conter em seu nome o prefixo com o index do step dentro da pasta do caso de teste, por exemplo: O índex serve para identificar a ordem em que os steps e asserts serão executados, onde os steps de mesmo índex são executados primeiro antes do assert de mesmo índex. Neste exemplo vamos criar o arquivo 00-pod.yaml do tipo Deployment com o conteúdo abaixo: Você pode consultar e personalizar as opções de configurações do TestStep na documentação de referência. O TestAssert é um objeto que é usado para especificar as configurações de um step de assert onde é possível comparar objetos específicos pelo nome ou qualquer objeto comparando um estado definido. O TestAssert deve ser criado na pasta de teste como um arquivo YAML, e assim como um step de teste deve seguir o mesmo padrão de nomenclatura do TestStep. Neste exemplo vamos criar o arquivo 00-assert.yaml com o seguinte conteúdo: Neste assert vamos comparar se o deployment criado no cluster contém o número de réplicas especificado no arquivo 00-pod.yaml. Assim como asserts também é possível criar steps de erros esperados, consulte a documentação de referência para saber mais. Execução dos testes Para executar o teste criado, basta executar o seguinte comando: Caso queira gerar o arquivo de report após a execução dos testes utilize o argumento –report <xml/json> O resultado dos testes no console será apresentado da seguinte forma: Encerrando… Espero que com esse artigo você tenha conseguido compreender as características e vantagens de usar o KUTTL. Com ele, seus testes de Kubernetes Operators nunca mais serão os mesmos. E você, já conhecia o KUTTL? Conta pra gente nos comentários se já usava ou se está pensando em adotar agora.
LocalStack: simule ambientes AWS localmente
A LocalStack é uma solução que tem tudo para apoiar muito a sua operação. Com ela é possível obter um ambiente cloud completo, na sua máquina, sem custo, disponível. Além disso, é possível monitorar tudo a partir de uma interface amigável. Quer descobrir tudo o que a LocalStack tem a oferecer e ainda acompanhar um tutorial de como começar a usar essa ferramenta? Então continue lendo! Afinal, o que é LocalStack e para que serve? A gente precisa desenvolver em um ambiente minimamente parecido (ideal que seja igual) com aquele onde a aplicação vai rodar. Quem desenvolve para o ambiente AWS, nem sempre tem disponível uma conta AWS ou, mesmo tendo acesso, em um ambiente corporativo muito seguro, não consegue manipular recursos com muita liberdade. A gente sabe que “experimentar é preciso”, mas ninguém quer correr riscos desnecessários. Para resolver esse dilema, existe uma iniciativa bacana, que recebe atenção de um bocado de gente batalhadora: a LocalStack. Você pode interagir com a LocalStack através de linha de comando, ou através de uma GUI mantida pelo time deles. Ainda tem a vantagem de poder checar o resultado dos comandos, confrontando com o que é apresentado na GUI. Segundo seu site, LocalStack provê um framework para teste e simulação, para o desenvolvimento de aplicações destinadas a rodar na nuvem, disponibilizando um ambiente de teste na máquina local, onde a aplicação está sendo desenvolvida. Este ambiente oferece a mesma funcionalidade e APIs do ambiente cloud da AWS. Sendo assim, serviços como execução de funções Lambda, armazenamento de dados em tabelas DynamoDB e outros estão ao seu alcance, sem que você precise, ao menos, ter uma conta na AWS. Vamos ver como é que se tira proveito desta fantástica ferramenta? Obtendo o compose para LocalStack Para começar, acesse o site oficial do LocalStack, conheça mais sobre ele e vá até o seu projeto no GitHub. Tem muita coisa legal aí, mas a gente pode ver isso depois. A dica, nesse momento, é aproveitar o conteúdo do Docker-compose.yml. Vamos a ele! Eu ia colocar uma figura aqui, do Github do LocalStack, mas você sabe que Github é dinâmico, vivo… As coisas se parecem de um jeito hoje e amanhã estão melhores! Então segue o link e dá uma olhadinha em tudo que tem em volta. Contribua com aquilo que descobrir “a mais”. Abra o link para o repositório LocalStack e você vai encontrar o arquivo que tanto procura: Usando o compose para LocalStack Devs que estejam atuando em um projeto com restrições de segurança, no qual são orientados a usar recursos de um repositório específico, podem definir uma imagem alternativa para o compose. O importante é assegurar que, seja qual for a fonte, ela é segura e fornece uma imagem com todos os recursos que se pretende usar. Dá uma olhada aí no que foi alterado: No trecho de código colocado aí em cima, a gente verifica algumas diferenças em relação ao compose baixado do Github. A primeira delas é a alteração da tag imagem, onde o valor exposto foi modificado para mostrar que é possível definir uma origem diferente da imagem, por motivo de preferência ou de política de segurança do seu contexto de trabalho. Também foram incluídas linhas, com pares de chave-valor, logo no início do bloco enviroment, para configurar opções de segurança. Estas informações poderiam ser definidas através dos profiles, mas não custa dar uma padronizada… Alterou? Salvou? Agora roda! ♪♫♪ Roda, roda, roda e avisa, um minuto de comercial! ♪♫♪. Isso é só pra lembrar do Chacrinha, o Velho Guerreiro, que muito antes da gente rodar aplicativos, já mandava “rodar” na televisão. Mas calma que você não vai usar a buzina do Chacrinha. Use o Bash do Docker e diga ao Docker-compose para dar um up no que está definido no seu arquivo docker-compose.yml. Não esqueça de abrir o Bash dentro da pasta onde está seu arquivo, sob pena de ter que fornecer o endereço completo do arquivo, o que pode ser bem maçante… Dando uma olhada no funcionamento da LocalStack Agora, se você, assim como eu, gosta muito de ter uma percepção mais concreta do que está acontecendo, a dica é usar o dashboard desenvolvido pela galera da LocalStack (este link pode não levar todo mundo ao mesmo ponto, leia adiante sobre isso). Você vai precisar fazer um cadastro no site e estar logado para usar esse dashboard. Nada do que a gente já não faça todos os dias: deixar nosso e-mail pra receber umas propagandazinhas… Depois de realizado o seu registro no site do LocalStack, e depois de efetuado o login, a url acima vai te levar ao dashboard, que oferecerá uma panorâmica da LocalStack da sua máquina. Se você ainda não fez o seu registro, ou, mesmo sendo registrado, nunca fez login, ou limpou o histórico de navegação, vai ser direcionado para a tela de login. Olha aí, que prático e que bonito o dashboard da galera rodando bonito! Além do indicador de funcionamento, muito útil para saber do status do nosso container, sempre se pode clicar nos links das filas, para dar uma olhada no seu conteúdo, o que, nesse momento, não vai acrescentar muita coisa ao nosso exercício. Interagindo com a LocalStack via GUI Você também deve ter observado que é possível, clicando nos sinais de “+”, criar novos elementos. No caso do SQS, a gente pode criar filas e mensagens, através do dashboard. Isso não tem a mesma emoção que a linha de comando, mas é uma boa ferramenta de certificação de que tudo vai bem. Ou não. Olha eu aí, criando preguiçosamente uma fila no meu SQS… Clique na bolinha azul, e tenha a vida facilitada, trocando a digitação de um comando por clique no botãozinho! Portas e credenciais – não tem mágica 1 – A única porta que a gente precisa acessar é a 4566. Isso pode soar estranho, já que tem um montão de serviços sendo oferecidos. Não se preocupe! O Container sabe qual serviço você quer acessar, porque nos comandos
Lançamento: Plano de Estudos de desenvolvimento iOS!
Na Zup, queremos mostrar ao mundo o potencial de criação de tecnologia do Brasil e isso só será possível com profissionais de alta qualidade. Atualmente, o desenvolvimento iOS é uma das áreas mais promissoras em tecnologia. Com uma demanda mais alta do que profissionais disponíveis, programar para os dispositivos da Apple pode ser um divisor de águas na carreira de qualquer pessoa. Por isso, lançamos hoje um Plano de Estudos de desenvolvimento iOS! Nesse plano listamos skills e conceitos importantes, além de cursos, leituras e exercícios para aprender e fixar esses conhecimentos. O quão confiantes estamos com a qualidade desse Plano de Estudos de desenvolvimento iOS? Bem, o zupper que criou esse plano não tinha nenhuma experiência em iOS e em seis meses de estudos conseguiu ser avaliado como Sênior em desenvolvimento iOS por outras empresas. Cenário do mercado para o desenvolvimento iOS Segundo um levantamento da GeekHunter, a demanda por devs mobile cresceu 600% em 2021. Além disso, a pesquisa da consultoria Bain & Company de 2020 traz dados interessantes sobre a distribuição de profissionais no desenvolvimento mobile: Já um levantamento da Michael Page também de 2020, aponta que 93% do mercado brasileiro de profissionais mobile se dedica ao Android. E vale lembrar que o mercado tem um claro déficit de profissionais de desenvolvimento. Segundo pesquisa da Associação das Empresas de Tecnologia da Informação e Comunicação e de Tecnologias Digitais (Brasscom), anualmente 46 mil profissionais de tecnologia se formam, porém a demanda estimada do mercado é de 70 mil vagas anuais. Em outras palavras, o cenário é de um déficit anual de 24 mil profissionais. Mas o que isso tudo quer dizer? 1 – Que o mercado está buscando cada vez mais pessoas com conhecimento em desenvolvimento mobile, mas a maioria se dedica ao Android. 2 – Está sobrando vagas para quem sabe desenvolver para iOS. Benefícios de aprender desenvolvimento iOS Além de uma menor competição dentro de um cenário de escassez, ainda há muitas outras vantagens em aprender desenvolvimento iOS. Vamos ver algumas a seguir: 1 – Remunerações – A média salarial para profissionais de desenvolvimento iOS variam um pouco de acordo com a fonte. Enquanto o Vagas.com informa R$ 4.700, o Glassdoor aponta R$ 5.900 de média (mar/22). 2 – Mais velocidade no desenvolvimento – Já percebeu que no Android há diversos aparelhos que usam esse sistema operacional? Bem, isso não acontece no iOS. Essa maior consistência faz com que algumas etapas (como testes, para citar apenas um exemplo) sejam concluídas mais rápido, reduzindo custos e aumentando a velocidade de desenvolvimento. Quer mais insights sobre o mercado de desenvolvimento? Então leia nosso artigo sobre a Stack Overflow Survey 2021. Por que um Plano de Estudos? Já deu para entender que o desenvolvimento iOS é uma área promissora, mas por que criar esse Plano de Estudo? Nosso objetivo era disseminar o conhecimento sobre desenvolvimento iOS dentro de casa, começando pelo time de engenharia de Zup Edu e depois produzir treinamentos para formar profissionais de desenvolvimento para os times da Zup. Porém, com o Plano de Estudos finalizado, percebemos o seu grande potencial e resolvemos disponibilizar para o público em geral também! Para construir nosso Plano de Estudos de desenvolvimento iOS, o Software Development Specialist na Zup, Rafael Rollo, montou e seguiu esse plano durante seis meses. Rollo já era um experiente programador, mas não tinha nenhuma experiência com desenvolvimento nativo sobre a plataforma da Apple. Portanto, se você nunca estudou nada sobre desenvolvimento de softwares pode ser interessante começar com um curso básico de lógica de programação antes de se debruçar neste Plano de Estudo de Desenvolvimento iOS. Conheça nosso Plano de Estudos de desenvolvimento iOS Com esse Plano de Estudos de desenvolvimento iOS propomos um formato de aprendizado assíncrono. Assim, você vai poder fazer cursos, leituras, exercícios e demais etapas no seu ritmo. Mais do que uma lista de skills e a correlação com cursos e exercícios para adquirir, nosso plano de estudos foi testado e aprovado. Uma dessas etapas contou com um desenvolvedor iOS Sênior fazendo sessões de mentoria para avaliar a fixação dos ensinamentos. Além disso, ao final do ciclo de aprendizado colocamos o Rafael à prova, fazendo processos seletivos em empresas de mercado que chegaram a avaliar ele como um desenvolvedor iOS Sênior. Estruturamos nosso Plano de Estudos de desenvolvimento iOS assim: E aí, vamos mergulhar no universo do desenvolvimento iOS? Então é só baixar o nosso Plano de Estudos. Conclusão Esperamos que tenha ficado claro as vantagens de aprender a desenvolver para iOS. Em cenário de escassez de mão de obra na tecnologia, o desenvolvimento para aplicativos iOS parece uma área ainda mais promissora. Além de baixar o nosso Plano de Estudos, sugerimos a leitura deste artigo sobre desenvolvimento iOS. Nele você vai ler, por exemplo: E claro, não esqueça de baixar o nosso Plano de Estudos. ? Ficou com alguma dúvida ou tem sugestões? É só deixar um comentário aqui no post.