DEV Community: Ygor Perez de Oliveira

Como se tornar um desenvolvedor web 🌐

Ygor Perez de Oliveira — Sun, 20 Mar 2022 04:31:04 +0000

O eu que preciso para isso?

Neste artigo contem o caminho que você precisa seguir e como conseguir segui-lo, as informações passadas aqui podem ser utilizadas para qualquer área da sua vida.

Se tiver qualquer problema ou dúvida pesquise e pergunte para os outros, tem muitas comunidades e pessoas que vão te ajudar e assim podemos tentar resolver todos juntos e aprender com isso.

Dicas:

Foque no básico:

A fundação é a parte mais importante, não adianta tentar aprender a como construir um castelo sem antes saber o básico, como construir paredes e sustentar o edifício, por exemplo.

Um exemplo na programação é que não dá para aprender React sem saber Javascript e não da para usar o Javascript sem saber a lógica de programação (if, for, while e etc). Você pode até aprender dessa maneira, mas será uma jornada muito mais sofrida.

Se especialize:

É melhor se especializar em uma área do que saber bem pouquinho de cada, em um contexto profissional você saber um pouco de Javascript, Python, banco de dados e etc, não significa muito porque você não conseguirá contribuir muito em nenhum desses aspectos.

Você deve aprender o suficiente para poder fazer algo útil para alguém.

Após se especializar em algum tópico, talvez valha mais apena você ir se tornando generalista, saber sobre várias coisas, porque você conseguira contribuir no que você é bom e ir auxiliando no que você está aprendendo.

Sabemos um pouco sobre biologia, um pouco de matemática, um pouco de história, mas não o suficiente para aplicar em contexto profissional, por isso não conseguiríamos empregos nesses campos.

Crie metas:

Crie metas a curto e longo prazo, anote elas em um lugar com que você vê com frequência e foque apenas nas coisas que vão fazer elas serem atingidas, todos os outros objetivos você deixa de lado por um tempo. Escolha 5 objetivos que podem ser conquistado em um futuro próximo.

Depois toda semana você anota o que quer conquistar nesta semana, algo que te faça chegar mais perto de um dos seus 5 objetivos, então no final da semana se você conseguir ou não conquistar o objetivo você vai refletir o porque e como poderia ter melhorado.

Foque na jornada: https://medium.com/taking-note/why-the-journey-matters-more-than-your-goal-7aad1835093a aqui está muito bem explicado e com estudos de como você pode aumentar drasticamente as chances de atingir á sua meta.

Entenda por cima o que tem para ser aprendido, depois disso defina com clareza o que você quer aprender, por exemplo: “aprender a programar” isso está errado o mais certo é especificar bem como “aprender como criar um site que diz o IMC da pessoa”. A partir disso você pode ver o que necessário para isso e ir pesquisando e fazendo no código para aprender exemplo: como criar uma função em Javascript.

Após isso procure os melhores recursos para aprender o que é necessário, cursos, artigos e vídeos. Vá aprendendo o conteúdo e brincando com ele, vendo como ele funciona, testando outros jeitos de fazer, fuçando em tudo mesmo.

Caminhos:

É importante lembrar que você não precisa aprender tudo isto para poder ser chamado de desenvolvedor, é possível conseguir um emprego muito antes de aprender tudo.

Frontend:

https://roadmap.sh/frontend

Curso de Javascript

Backend:

https://roadmap.sh/backend

Curso de Javascript

Designer ux/ui:

https://github.com/togiberlin/ui-ux-designer-roadmap um pouco antigo, mas ainda assim vale a pena dar uma olhada

Curso de Figma

Se você quer um emprego:

Se você quer um emprego na área é preciso comprovar sua experiência e para isso é preciso ter projetos, então todos os projetos que você fizer coloque no seu Github (rede social de programadores), até mesmo os de tutoriais e documente tudo.

Não é obrigatório você fazer faculdade para conseguir um emprego, mas se optar por não fazer você precisará de um portfolio, também se aplica se você ainda não está na faculdade e também te da uma vantagem enorme mesmo se estiver.

Crie um perfil bom no LinkedIn, apreenda a fazer isso vendo vídeos e tenha um bom currículo, uma ótima ferramenta para isso é o https://resumeworded.com/ ele analisa seu currículo e perfil do LinkedIn, mas tem que estar em inglês. No LinkedIn da para ter 2 línguas no mesmo perfil e o currículo é relativamente fácil de traduzir então é bem viável e vale muito a pena.

Como aprender:

A coisa mais importante é primeiro acreditar que você pode aprender e ter o famoso “growth mindset”, a mentalidade de que coisas são aprendidas e não apenas talento e dom. Até em estudos pessoas que tinham essa mentalidade acabavam se alavancando mais em suas carreiras em comparação ao outro grupo.
Sempre que tiver uma dúvida pesquisa-la no google, isso fará com que você vá aprendendo durante o dia sem muito esforço. Se for uma dúvida de uma funcionalidade dentro de uma linguagem de programação você pode ir testando e pesquisando para descobrir como fazer algo.
Sempre programe/desenvolva junto dos tutoriais, só olhando você não aprenderá. Se rodear de pessoas que tem o hábito que você quer facilita muito também, por exemplo, eu sem o meu irmão me chamando para ir à academia eu faltaria muito mais.
Lembre-se que existe milhares de vídeos e cursos de graça no YouTube e em outras plataformas, a internet é seu melhor amigo.
Seja consistente, não é aquela uma vez que você estudou 12h em um dia que fará de você um desenvolvedor, mas sim as várias vezes que estuda 5m que seja. Por isso tenha um horário destinado a estudar todo dia.
Pare e pense o que você pode fazer para melhorar sempre, pegue feedback de outras pessoas e aplique na sua vida.

Como criar hábitos:

Cerque seu ambiente com coisas associadas ao que quer aprender para ter um contato maior com elas durante o dia assim estará se familiarizando mais com o ambiente e aprendendo passivamente.
Torne o certo fácil: suponha que você queira beber mais água então basta sempre ter uma garrafa de água cheia no seu campo de visão que você provavelmente beberá mais, já não que ir busca-la toda vez.
Torne o errado difícil: desta vez você quer passar menos tempo no TikTok, simples desinstale o aplicativo sempre que terminar de usa-lo e desabilite suas notificações, assim você tem menos contato com ele e tera de instala-lo sempre que for usar.
Diga aos outros o que está fazendo, se você bota na sua cabeça que você é um desenvolvedor muito mais fácil você desenvolver, afinal é só mais uma prática comum de um desenvolvedor.

Alguns hábitos interessantes:

Não precisa começar com todos de uma vez, se conseguir consquistar um desse a mais para o seu arsenal já sentira uma diferença incrivel.

Praticar exercício físico, importante lembrar que a mente faz parte do corpo, um corpo saudável possibilita uma mente mais saudável.
Meditação, passe um tempo consigo mesmo, diversos estudos mostram a capacidade de focar melhor e redução de ansiedade.
Journaling, escrever a coisa mais importante que aconteceu no dia, o que você aprendeu e 3 coisas pelas quais você é grato. É extremamente difícil se sentir triste ou estressado quando expressa gratidão.
Não comer alimentos processados e coisas que sabe que faz mal para a saúde, os problemas de saúde vão acumular com o tempo. Se você só alimenta seu corpo com lixo você não conseguira usar da capacidade máxima dele.
Conhecer pessoas novas, o ser humano é um ser sociável afinal e existem inúmeros benefícios por fazer isso, networking novos amigos, parceiros românticos e histórias. Isso também fara com que seja mais confiante e provavelmente você também será mais feliz e poder utilizar o tempo produtivo de maneira mais eficiente, já que estará mais motivado.
Se organizar, planejar onde você quer chegar, manter o ambiente organizado, saber o quanto gasta mensalmente e quanto ganha, investir e saber aonde gasta seu tempo.
Estudar, comece aprendendo tentando aplicar o conhecimento, já que existem 6 níveis de aprendizado conforme a taxonomia de bloom, lembrar, entender, aplicar, analisar/diferenciar, avaliar e criar. Não tem como você aplicar algo que você não entende e isso garante que você retenha a informação com mais qualidade e por mais tempo.

Links

Após concluir um desses cursos você tera o básico bem estabelecido e seria bom se aprofundar ainda mais em cada tema. Lembre-se que o mais importa é ser consistente, crie o hábito de ser um desenvolvedor, afinal o objetivo não é programar é ser um programador, então comece a ser um.

Cada ação que você toma é um voto para a pessoa que você quer ser.

O que é Scrum? E como ter sucesso 🚀

Ygor Perez de Oliveira — Sun, 20 Mar 2022 03:55:58 +0000

Metodologias ágeis:

É um grupo de métodos de maneiras de se gerenciar um projeto, o foco desse artigo será no scrum, o mais utilizado pelas empresas de software. Ele serve para lidar com projetos complexos onde muita coisa ainda é desconhecida.

Benefícios esperados:

Para a maioria das equipes ágeis, as histórias de usuários são o principal veículo de entrega incremental de software e oferecem os seguintes benefícios:

Mitigam os riscos de feedback atrasado, ainda mais se os incrementos forem pequenos e ou se o software for lançado para produção com frequência.
para o cliente ou proprietário do produto, a opção de mudar de ideia sobre os detalhes ou a prioridade de agendamento de qualquer história de usuário ainda não implementada para desenvolvedores, recebendo critérios de aceitação claros e precisos com feedback contínuo à medida que concluem o trabalho.
Promovendo uma clara separação de responsabilidades entre definir o “o quê” (província do cliente ou proprietário do produto) e o “como” (província da equipa técnica), potenciando as competências e criatividade de cada um.

Scrum:

Ele consiste em uma série de “rituais”, “artefatos” e princípios, onde se deve seguir para ter os melhores resultados. Funciona a base do empirismo, experiências, observações e fatos, mas para isso dar certo precisa ter os três pilares.

Os três pilares do Scrum:

Transparência:

Todo mundo envolvido deve saber o que está acontecendo com o produto. Para isso precisamos usar uma linguagem comum à todos, criar um glossário por exemplo, ter informações sobre o projeto disponiveis e seguir os rituais.

Inspeção:

É o ato de fazer uma observação, tanto sobre o produto, pessoas processos, ferramentas ou artefatos. Qualquer um pode fazer e é por isso que importante a transparência, o melhor exemplo é que no final de toda sprint temos a retrospectiva onde fazemos observações para decidir onde podemos mudar/adaptar.

Adaptação:

A adaptação é o conceito central do scrum, é onde se diferencia de outros métodos mais comuns em empresas não SaaS (software como um produto). É por isso que os dois ultímos pilares são tão importantes, sem eles não tem adaptação.

Artefatos:

São as informações mais importantes da scrum como: backlog do produto (parte das tarefas que devemos completar para o projeto estar completo), backlog da sprint (parte que estamos desenvolvendo), incrementos (funcionalidades novas), a definção de pronto e aceite, e o burndown chart (métrica de progresso).

Product backlog:

Todas os itens (histórias) que devem ser feitas para o projeto ou produto estar pronto, é composto de temas, épicos, e histórias de usuário. As vezes também é chamado de Portolio e tem épicos no lugar de temas, features como épicos e backlog items como hístorias.

Deve ser composto pelo product manager e o scrum master, os desenvolvedores deve ajudar subdividindo, estimando e dando descrições claras as tarefas.

Todas as tarefas e histórias devem conter uma descrição para que o time (equipe de desenvolvimento) possa entender o que deve ser feito. É papel do scrum master e do product manager garantir a compreensão de todos, a equipe deve perguntar o tempo todo absolutamente tudo que não souberem ao scrum master durante as reuniões e ao product owner sobre alguma parte da tarefa que não entendeu, caso ele tenha feito a tarefa.

Sprint backlog:

Se diferencia do product backlog porque nos realizamos apenas as tarefas decididas na planning que foram pegas do backlog, isso é o sprint backlog, também chamado de kanbann board ou agile board.

Histórias de usuário:

Uma história nada mais é que tarefas que devem ser implementadas para conseguir atingir os desejos dos stakeholders (interessados no produto). Exemplo de uma história: Eu como usuário do site quero poder me cadastrar para poder ter acesso a meus dados e com base nisso acesso a informações mais específicas. Segue essa estrutura, Eu como [ ] quero [ ] para [ ].

A sigla INVEST ajuda a lembrar um conjunto de critérios amplamente aceito, ou checklist, para avaliar a qualidade de uma história de usuário. Se a história não atender a um desses critérios, a equipe pode querer reformulá-la ou até mesmo considerar uma reescrita.

“Independente” (de todos os outros)
“Negociável” (não é um contrato específico para recursos)
“Valioso” (agrega um valor claro para os usuários)
“Estimável (para uma boa aproximação)
“Small” (caber dentro de uma iteração, sprint)
“Testável” (em princípio, mesmo que ainda não haja um teste para isso)

Denominação dos itens do kanban board:

Dentro de um Kaban board temos hístorias de usuários que devem ser dividas em tarefas, pelos próprios desenvolvedores mesmo, tarefas boas tem um objetivo claro e é possível completa-la em 1 dia de trabalho. É muito bom também deixar a meta da sprint logo no backlog para que time se mantenha focado.

Nota:

O nível de detalhe correspondente a uma história de usuário não é constante, evolui ao longo do tempo em função do “horizonte de planejamento”; por exemplo, uma história de usuário que está agendada para a próxima iteração deve ser melhor compreendida do que uma que não será implementada até a próxima versão.
Uma história de usuário não é um Caso de Uso; embora muitas vezes seja útil comparar e contrastar as duas noções, elas não são equivalentes e não admitem um mapeamento um-para-um.
Uma história de usuário em geral não corresponde a um componente técnico ou de interface do usuário: mesmo que às vezes possa ser um atalho útil para falar, por exemplo, “a história do diálogo de pesquisa”, telas, caixas de diálogo e botões não são histórias de usuário.
Pode se ter dentro de uma história fotos de design, links para referência e outras ferramentas que ajudem a completar ela, como por exemplo uma história técnica dentro dela para explicar tecnologias e etc.

Antes da reunião de Planejamento da Sprint, o Product Owner deve:

Verificar as prioridades das partes interessadas (stakeholders)

Se eles mudaram, o Product Owner deve estar ciente e levar isso em consideração ao definir o que precisa ser alcançado no próximo Sprint.
Refinar o Product Backlog

Uma prática também conhecida como backlog grooming. Ter um Backlog saudável e priorizado prepara o cenário para o Sprint Planning. Mesmo que ainda não seja um evento scrum oficialmente aceito, muitas organizações hoje o consideram um passo crítico que melhora a velocidade e a eficiência.
Verifique o Product Roadmap

Para que o Product Owner escolha os recursos mais apropriados para serem entregues.
Conheça a Capacidade, mas não a preencha

Fique atento ao cronograma de todos durante o sprint e deixe algum espaço livre para quaisquer imprevistos que possam surgir.
Certifique-se de que a definição de pronto esteja clara

Para que você forneça clareza e crie o caminho para entregar de maneira previsível.
Especifique os Critérios

de Aceitação ou, em outras palavras, defina as condições que um produto deve satisfazer para ser aceito pelo usuário final, cliente ou sistema. Isso definirá a instrução com um resultado claro de aprovação ou reprovação.
Peça ao Scrum Master para revisar o backlog da Sprint

É de uma forma ou de outra o principal conselheiro!

Backlog grooming:

O refinamento de pendências (anteriormente conhecido como preparação de pendências) é quando o PO e alguns, ou todo o restante da equipe, revisam os itens do backlog para garantir que contenha os itens apropriados, que eles sejam priorizados e que os itens estejam pronto para entrega. Essa atividade ocorre regularmente e pode ser uma reunião oficialmente agendada ou uma atividade contínua. Algumas das atividades que ocorrem durante esse refinamento do backlog incluem:

Removendo histórias de usuários que não parecem mais relevantes
Criar novas histórias de usuário em resposta às necessidades recém-descobertas
Reavaliar a prioridade relativa das histórias
Atribuir estimativas a histórias que ainda não receberam uma
Corrigir estimativas à luz de informações recém-descobertas
Dividiriteração, garantir que uma história seja pequena o suficiente para caber na iteração/sprint.

A intenção do refinamento do backlog é garantir que o backlog permaneça preenchido com itens relevantes, detalhados e estimados em um grau apropriado à sua prioridade e de acordo com o entendimento atual do projeto ou produto e seus objetivos.

Ao contrário de um “documento de requisitos” mais formal, o backlog é entendido como um corpo dinâmico de informações.

Por exemplo, nem todas as histórias de usuários precisam ter sido divididas em um nível refinado no início do projeto ou receber estimativas detalhadas; mas é importante que a qualquer momento um número “suficiente” de histórias esteja pronto para agendamento nas próximas iterações.

Um projeto Agile é, não menos do que qualquer outro, sujeito a “scope creep”, na forma de histórias de usuários que não geram valor substancial, mas foram consideradas “boas ideias na época” e inseridas no backlog para que não fossem esquecido.

Na ausência de esforços explícitos destinados a administrar essa inflação, essa inflação resultaria nas patologias muito conhecidas de excessos de cronograma e orçamento.

Gráfico burndown:

É um meio de quantificar o progresso de uma sprint, é mais uma das tarefas do Scrum master, pode ser medido em ponto de história ou horas.

Normalmente, o eixo y vertical no gráfico de burndown mede o número total de histórias a serem concluídas, enquanto o eixo x mede o tempo em uma sprint. Um declínio constante na inclinação representa o cenário ideal, ou seja, com histórias de usuários e tarefas no caminho certo para terminar a tempo e, assim, serem concluídas para chegar ao final do sprint.

É mais uma das tarefas do scrum master, deve ser atualizada toda sprint, seve para ter uma ideia de progressão e assim também podendo estimar melhor o tempo das tarefas.

Gráfico velocity:

De maneira semelhante à forma como o gráfico de burndown mede o trabalho concluído em cada sprint, o gráfico de velocidade mede o trabalho concluído ao longo de um projeto inteiro. Com esta ferramenta, o eixo y representa o número de pontos da história e o eixo x o número de sprints.

Embora o gráfico de velocidade seja geralmente pensado como uma ferramenta de gerenciamento que fornece uma visão geral de alto nível da eficácia e produtividade da equipe, ele também deve ser visto como de grande valor para o scrum master em sua rotina de trabalho diária e semanal.

Os benefícios para ele é que, principalmente com equipes scrum experientes, ele consegue usar a velocidade média como uma ferramenta de planejamento útil para projetos atuais e futuros. Ele ganha uma visão muito mais clara das capacidades da equipe que tem à sua disposição.

Definição de aceite/preparado (DOR):

O DOR, trata-se de uma listagem de requisitos que determinada história ou tarefa necessita para que possa estar apta a entrar no backlog da Sprint. Normalmente essa lista fica vinculada a tarefa e cada item é marcado com check se está atendido ou não. A história só deve ser movida para o backlog da Sprint se todos os itens levantados durante o refinamento estiverem marcados.

Exemplificando uma história, na qual necessitará consultar outra aplicação, podemos citar na lista do DOR alguns itens como:

Histórias de usuário devem ser escritas no padrão BDD
O(s) critério(s) de aceite estão claros
Serviço de Integração disponível para consulta
Design pronto
HTML pronto
Dados para teste

Não precisamos seguir essa definição, mas é importante que tenhamos a nossa própria e todos saibam o significado dela.

Definição de completo/feito (DOD):

Isso é quando se pode dizer que completou uma tarefa.

Se deve ter uma definição clara de feito em toda sprint. Deve se testar o incremento feito? Deve existir testes autônomos? Usuários devem testar? Precisa passar por feedback? Até onde vai à funcionalidade? (Isso deve estar bem explicado no backlog e o scrum master deve garantir que todos compreenderam as tarefas).

Exemplos:

Testes do programa feito
Código revisado por outro membro do time
Funcionalidades atende aos critérios de preparado

Rituais:

As vezes também é chamado de cerimonías, nada mais é do que os eventos do scrum que tem um tempo máximo, o refinamento do backlog (refinar as tarefas, backlog grooming) a fase de planejamento (planning), a curta reunião díaria (daily scrum, ou stand-up), review do que foi feito na sprint (sprint é o ciclo de desenvolvimento), retrospectiva (parte que vemos o que podemos fazer melhor na próxima sprint).

Sprint:

A sprint ou iteração é o ciclo de desenvolvimento com o objetivo de conquistar uma meta a partir de incrementos, o resultado deve ser um software utilizavel. Dura 14 dias.

A sprint deve continuar até o fim, mesmo se absolutamente tudo foi definido errado. Os erros devem ser discutidos na retrospectiva, retro. Se alguma tarefa da sprint não for terminada ela volta para o backlog.

Não se deve mudar o objetivo central da sprint e nem adicionar novas tarefas a ela, mas mudanças podem ser feitas e vão ser feitas, porque é intrínseco ao planejamento aparecer problemas inesperados, mudanças devem ser acordadas com o PO.

Daily:

Reunião de menos de 15 minutos realizada todos os dias de preferência no mesmo local e horário. O foco é ver se estamos progredindo para atingir a meta da sprint e resolver os problemas que impedem isso. Nas empresas normalmente é aqui que se mostra trabalho.

Perguntas comuns a serem feitas:

O que foi realizado desda última reunião?
O que é esperado atingir até a próxima reunião?
Quais são os seus impedimentos?

De forma alternativa às perguntas podemos fazer o “walk the board” onde passamos pelas tarefas do kanban board exemplo, eu estou responsável por essa história, já implementei uma das funcionalidades, é esperado que eu consiga terminar até hoje se eu conseguir resolver os problemas do banco de dados.

Nota:

Isso deve ser feito para ver como está o andamento do time e se alguém necessita de ajuda assim para como reconhecer o trabalho feito dos outros, é importante não se focar apenas em si mesmo. Sem conversa paralela, deve ser informal e no máximo 15 minutos.

Planning:

Essa faze serve para planejar o que devera ser feito na sprint, ou seja o sprint backlog, aqui se deve decidir o objetivo pelo PO, e estimar o tempo das tarefas trabalho dos devs já que eles que vão realizar o trabalho.

Estimando:

Essa é a primeira fase da planning, onde se deve atribuir quanto tempo ou pontos para uma tarefa.

Tipos de tempo:

Temos dois meios para quais podemos definir o tempo de uma tarefa, por pontos e por horas, por pontos seria um meio de comparação com as outras tarefas, normalmente os números utilizados são fibbonaci: 1, 2, 3, 5, 8, 13, 21, etc. A vantagem desse método é que humanos são ótimos em comparar coisas, mas péssimos em calcular prazos, porem fica mais difícil de explicar para outras pessoas fora da equipe a dificuldade de uma tarefa e nas primeiras sprints acaba sendo menos eficaz.

Como estimar bem:

É preferivel que o PO não participe da estimativa para não criar pressão sobre o time.

O time de desenvolvimento deve estimar o tempo de uma tarefa já que são eles que vão realiza-la, porém o scrum master deve auxilia-los no processo para garantir que estão pensando de forma realista e asseguralos de que é apenas uma estimativa, não é para ser perfeito.

Pegar duas história de tamanho médio (5 ou 8 pontos) para começar a estimativa é interessante. Escolher uma de fácil compreensão pelo time inteiro é bem importante. É bom lembrar que nem sempre o que é fácil para você será para mim.

planning poker:

Cada indivíduo precisa dar sua estimativa realista de qual pontuação terá, para que haja uma oportunidade de discutir as diferenças e depois fazer um acordo antes de se comprometer. A maioria dos analistas provavelmente concorda que isso na prática é simplesmente o caso de cada pessoa anotar sua pontuação prevista, 1, 2, 3, etc. em um cartão e depois revelá-la a seus colegas. No entanto, além desta sessão de planning poker, existem outras técnicas. É importante revelar ao mesmo tempo e não tentar persuadir os outros antes de revelarem suas pontuações.

Essa atividade é de suma importância porque vai definir o tempo do projeto e o PO necessita dessa estimativa para apresentar aos stakeholders e planejar o roadmap do produto.

O SM e PO não devem pressionar a equipe de desenvolvimento. Se for a primeira vez estimando ela será muito mais importante para as sprints posteriores do que a atual, já que da para ter um ideia melhor do tempo de uma tarefa.

Segunda estimativa:

A cada semana os pontos devem ser revisados e se possível dividir as tarefas e histórias em partes menores.

Para ter uma boa sprint se deve ter 3 critérios: objetivo, método e as métricas.

Objetivo:

Porque devemos realizar essa sprint? O que deve ser feito? Exemplo: observar os riscos, testar uma hipótese e efetuar funcionalidades. Importante para explicar o porque estamos fazendo essa sprint e motivar o time. Essa parte é papel do PO onde ele deve esclarecer todas as duvidas que a equipe de desenvolvimento tenha e explicar quais tarefas eles vão desenvolver.

Existe um acrônimo para criar metas efetivas: “SMART”

S – Specific (todos entendem o objetivo)
M – Mensurável (tem como saber se está pronto)
A – Alcançável (caiba no tempo de uma sprint)
R – Relevante (traz valor aos stakeholders)
T – Temporizado (tem tempo estimado)

Método:

Como realizaremos a tarefa? Deve se usar técnicas de validação? Por exemplo: teste de usabilidade, testes A/B (são experimentos realizados com o objetivo de comparar variáveis em estratégias de Marketing), protótipo e demo, para ter uma noção de como será o produto. Também pode ser decidido as tecnologias a serem utilizadas.

Métricas:

O que define que o objetivo foi alcançado? Por exemplo: pelo menos 5 usuários devem ser capaz completar os testes de forma bem sucedida em menos de 1 minuto.

Definindo o sprint backlog:

Está é a última faze da planning. Dependendo da complexidade do objetivo não será viavel completar em uma sprint, assim tendo que questionar o PO sobre os trade-offs e talvez mudar a definição de feito.

Definir quais histórias vão ser realizadas na sprint é muito importante que se tenha apenas tarefas que podem ser completadas no tamanho da sprint isso pode ser feito subdividindo as histórias em tarefas ou até mesmo as tarefas em tarefas menores.

É muito importante não pegar tarefas pensando: “Tudo bem se não completar essa.” Todas as tarefas do backlog da sprint deve ter o objetivo real de serem completadas e serem escolhidas de forma realista, o que pode ajudar com isso é: https://www.planningpoker.com/ para definir o tamanho das tarefas.

Limite WIP:

WIP significa trabalho em progresso e em algumas empresas tem um limite de tarefas que pode estar nessa sessão do kanban board.

Nota:

Não precisa de absolutamente tudo decidido na planning, a maior parte do como deve ser decidido pela equipe de desenvolvimento e não o SM e PO, ele deve apenas escutar e mentorear, nunca dar a palavra final. Também deve assegurar que não tem problema sair com algumas coisas não definidas e terá sempre adaptações.

Deve durar no máximo 4h.

Review:

É aqui que é mostrado o trabalho feito na sprint sendo convidado pessoas de fora para ver, stakeholders, pessoas que possam dar feedback, ou amigos. É importante não discutir o que deve ser melhorado aqui, já que existe a retrospectiva apenas para isso.

Deve durar no máximo 2h. Informal.

Retro:

Aqui é discutido o que deu errado e o que deu certo, o que será implementado na próxima sprint e o que deve ser abandonado em questão de métodos. O que intriga cada membro do time, o que cada um aprendeu. Quem mais te ajudou na última sprint, como você quer ajudar os outros.

É para ser uma refleção de como podemos melhorar para a próxima sprint ser melhor que a última.

Deve durar no máximo 2h.

Papeis:

Existem três trabalhos obrigatórios no scrum, o product owner (quem sabe como o produto deve ser, trabalho principal é o backlog), o scrum master (um coach onde papel é gerenciar o projeto e servir ao time de desenvolvimento), os devs (equipe de desenvolvimento, quem programa e dubla, adiciona informações dentro do produto se enquadra aqui, no tempo livre o SM pode se enquadrar também, mas não é o foco dele).

Outros papeis importantes, mas não essenciais são: Techlead (gerencia os desenvolvedores garantindo qualidade de código, minimizando o débito técnico e cuida dos processos de desenvolvimento, a parte do como, decide tecnologias e arquiteturas, também programa). QA (garantia de qualidade, testa os programas), devops (cuida da parte de infraestrutura, automatiza os processos de teste e garante que o servidor esteja funcionando) e o SME (experiente no assunto do tema, nosso caso um nútrologo ou nutricionista por exemplo).

Scrum master (SM):

Deve: organizar rituais (os métodos de scrum), resolver impedimentos, apaziguar as discussões, explicar como funciona o scrum, realizar métricas, ser um mentor, motivar o time, dando suporte a ele, priorizar o time às tarefas externas e entender os desejos do PO.

Não deve: ser a quem se reporta as tarefas feitas, quem toma as decisões e quem cobra o time.

Diarío do SM:

É muito importante o SM ter um díario onde ele anota observações e faz perguntas para tentar encontrar soluções para intervir ou decidir se pode continuar assim.

Intenvenção:

É uma ação tomada pelo SM, como conversar com o time sobre um tópico especifico que ele percebeu que não foi entendido corretamente ou apenas algo bom que eles estão fazendo e ele gostaria de saber mais. Para que a conversa seja boa é bom ser baseada em perguntas e não tenha culpado, todo o time tomou a decisão junto afinal.

Product owner (PO):

É quem deve garantir o maior aproveitamento do time, decidindo o objetivo, criando o roadmap e checando métricas. Também é quem conversa com os stakeholders (clarificando seus desejos e passando eles ao time), decide se algo está bom ou não, e constitui os desejos dos usuários no backlog.

Equipe de desenvolvimento:

Todos aqueles que realizam as tarefas do kanbann board. Seja um trabalho de design, implementar um software, dublar vídeos, ou redigir textos.

Sempre que tiver um impedimento ou precisar de ajuda pedir ao scrum master, tirar todas as dúvidas sobre metodologias scrum com ele e perguntar sobre o backlog para o PO se não entendeu alguma tarefa.

É quem decide como será realizada as tarefas do ponto de vista do desenvolvimento. Estima o tempo das tarefas.

Não pedir ajuda sem tentar fazer sozinho primeiro, mas não ficar batendo cabeça para sempre. Tem que saber o que irá dizer na daily. O google é seu melhor amigo.

Criar documentação dos produtos, revisar pull requests (solicitação para colocar o código no projeto, assim outro revisa seu código antes de coloca-lo) e fazer pair programming quando for mais eficaz (programar junto com outro dev).

Os valores do scrum:

Estes são os valores do scrum que devemos desenvolver com tempo para ter a maior produtividade.

Manifesto ágil:

Foi uma reunião feita entre os mais importantes gerentes de projetos, foi feita para decidir alguns elementos essenciais como:

Mais interação entre indivíduos do que processos e ferramentas.
Mais software em funcionamento do que documentação.
Colaboração entre o cliente acima de negociação e contrato.
Adaptabilidade é mais importante do que seguir um plano.

Apesar de todos esses serem impontantes os que estão a esquerda devem ser priorizados.

Outros principíos:

• Auto-organização da equipe (independencia do time)
• Composição da equipe (deve haver papeis bem delimitados)
• Feito significa feito (todos devem ter a mesma definição de feito)
• Product Owner Capacitado (tem que ter sua decisão respeitada)
• Scrum Master como Líder Servente (gerencia o time servindo os outros)
• Propriedade da equipe de se adaptar
• Entrega de valor (software útil para o usário final funcionando)

Incremento do produto:

Conforme descrito no Guia do Scrum, um Incremento é um trampolim concreto em direção ao Objetivo do Produto. Cada Incremento é aditivo a todos os Incrementos anteriores e verificado minuciosamente, garantindo que todos os Incrementos funcionem juntos. Para fornecer valor, o incremento deve ser utilizável.

Outros design patterns:

Design Patterns ou padrões de projetos são soluções generalistas para problemas recorrentes, uma especificação de como deve ser resolvido. Como a estrutura da história.

BDD:

Significa behavior driven development, é um meio de basear o desenvolvimento de histórias e códigos em comportamentos.

Exemplo:

Dado que estou na página de cadastro quando eu clicar no botão de cadastro e preencher a senha e email e confirmar a senha, então o sistema deve exibir uma mensagem no topo da tela: “Cadastro efetuado com sucesso” e redirecionar ele para a home. Segue essa estrutura, Dado que [ ] quando eu [ ] então [ ].

Como implementar na programação:

Foco em cenário;
Escreva a especificação para o cenário;
Escreva a especificação das unidades (naquele exemplo as unidade seriam o email e senha, já que se não preenchido corretamente mudaria o resultado);
Faça a especificação da unidade passar (atenda à todas as especificações, cenários e esteja de acordo com a definição de feito);
Refatore (reescreva o código de uma maneira melhor).

E quais os benefícios reais desta fusão Scrum e BDD?

Evita-se erros de compreensão e interpretação das histórias de usuário;
O que antes eram requisitos funcionais e requisitos não funcionais são transformados em comportamentos funcionais do software e critérios de aceitação;
Fornece uma forma de comunicação (vocabulários) comum a todos envolvidos, facilitando a compreensão por parte de todos;
A equipe fica ciente dos comportamentos que serão aceitos pelos usuários com antecedência;
A equipe entende como os comportamentos são relacionados, evitando confusão;
As reuniões de planejamento, revisão e diárias tornam-se mais eficazes.

Essa metodologia deve ser implementada no backlog e na programação, se não souber que resultado deve ter em outro caso da história por exemplo não preencher os campos da história pergunte ao PO.

TDD:

Você cria o teste do código antes do código em si, para fazer de maneira correta precisa seguir 5 etapas:

Escrever o teste antes da funcionalidade
Falhar no teste
Passar no teste
Refatorar o código, escrever tudo de novo de maneira otimizada.
Repete até estar de acordo com a métrica da tarefa (definição de feito)

Mais recursos:

Se quiser saber mais sobre scrum:

https://geekbot.com/blog/project-management-tools-that-every-scrum-master-should-use/

https://www.scrum.org/

é em inglês, leia e clique em todas as referências passadas para entender mais. Também recomendo o https://simpli-web.app.link/e/9588O7QB2nb, tem vários cursos gratuitos e com certificados, eles têm um de Agile Scrum Master que acabei fazendo e gostei bastante.

Mais sobre tdd, bdd, e ddd:

https://www.eduardopires.net.br/2012/06/ddd-tdd-bdd/

https://medium.com/cwi-software/domain-driven-design-do-início-ao-código-569b23cb3d47

Para saber mais sobre o trabalho do PO de modo interativo com um grupo:

https://medium.com/@sjoerdnijland/stakeholder-tycoon-4178eec63adf.

Onde fazer o backlog:

O mais usado é o jira, mas também tem o azure que é muito bom

https://azure.microsoft.com/en-us/services/devops/

https://start.atlassian.com/ jira

Uma alternativa ao Microsoft teams para organizar reuniões: https://www.gather.town/