Principais Pontos Palestra TOTVS

Metodologias

SCRUM KANBAN Alteraram para o método de divisão de trabalho no modelo spotify

Utilizam Scrum e Kanban mesclado em equipes

Scrum e Kanban

Kanban

Exige comprometimento opcional Usa lead time como métrica default para planejamento Deixa adicionar novos itens quando houver capacidade Sem diagramas É limitado diretamente pelo fluxo de trabalho Board é contínuo

Scrum

WIP é imitado diretamente pelo fluxo de trabalho

Daily

Tanto no Kanban quanto no Scrum No Scrum é dito o que foi feito no dia anterior com relação ao progresso da sprint No Kanban é com relação ao quadro, quem está realizando a atividade é quem fala da atividade

Planning

Encontrar o objetivo da Sprint Participam todos os membro da equipe

Reabastecimento:

Planning do Kanban

Menos de 3 itens no to-do é marcado o reabastecimento Participam todos os membros da equipe

Review

Entrega com relação ao ciclo completo Para o PO e líderes Finalização das Sprints 2 semanas

Retrospectiva

Ver os pontos a serem melhorados Ver bons pontos Dinâmicas para ter novas ideias

Método de Trabalho - Upstream

Backlog	Refinamento	Negócio	Refinamento	Negócio	Contínuo	Refinamento	Técnico	Refinamento	Técnico	Concluído
Backlog	Refinamento	Negócio	Refinamento	Negócio	Contínuo	Refinamento	Técnico	Refinamento	Técnico	Concluído

Método de Trabalho - Downstream

To Do	Desenvolvimento	Pronto Para Testar	Em Teste	Teste Concluído	Documentação	Pronto para Expedir	Concluído
To Do	Desenvolvimento	Pronto Para Testar	Em Teste	Teste Concluído	Documentação	Pronto para Expedir	Concluído

Plataforma FLUIG

Dividido em Squads Utiliza aplicação Fluig No-Code Liderança Liderança por Influência Não mudam no projeto

Importância do Design de produto

Descoberta Design de Experiência de usuário Prototipagem Teste de Usuário

Experiência de Usuário

Introdução do usuário trazer destaques e one boardings para as novas atividades deve ser tratado o engajamento para manter os usuários e n apenas números de downloads

Design

Design Thinking e Lean Inception → técnicas usadas se complementando

Estimativas

perguntas para todas as partes afetadas, para encontrar todas as melhoras possíveis integração e sinergia cada vez maior

Cronograma

Descobrir e Definir: Briefing Benchmarking Personas Matrizes CSD Entrevistas Jornadas de Usuário

Ideat e Decidir:

Como Nós Podemos Matriz de Priorização

Prototipar e Validar

Prototipação Testes de Usabilidade e Análise Protótipo de Alta Fidelidade Plataforma MIRO Para criação de design separadas por etapas e colunas (semelhante ao Figma)

S.A.R.A.

Situação Ação Resultados Aprendizado

Produto

dentro das comunidades do fluig é possível adicionar a comunidade os formulários existentes e anda criar novos formulários com No-Code, jogando os elementos em tela para montar e editar as configurações existentes na timeline aparecem todos os acontecimentos, é possível curtir, salvar etc ao preencher o formulário é possível avaliar o mesmo dentro do formulário é possível ver em registros do formulário os dados das respostas

Carreira Tech

Trilha em Y Gerencial ou Especialista todos tem a mesma base, depois de um ponto é direcionado sobre gradualmente com direção ao objetivo desejado cargos pensados para chegar onde deseja

O que é GIT:

Git é um sistema de controle de versionamento distribuído, ou seja, um sistema em que outras pessoas ou times, podem participar editando um mesmo documento ou código ao mesmo tempo, sendo gerido através de versões que são criadas no instante em que existe uma modificação. O Git serve tanto como um sistema de integração como um sistema de versionamento.

Para utilizar o GIT é importante que você baixe as dependências dele.

Para criar um novo repositório, você precisa, através do terminal, entrar em um diretório que deseja criar um repositório. Código: git init Com esse código irá criar um repositório no mesmo diretório e também um subdiretório chamado .git.

Código: git status

Através desse código você irá saber qual a versão que está no momento e também as possíveis modificações que você tem para atualizar.

Código: git add "nome_do_ arquivo.tipo"

Através desse código, os arquivos irão ser adicionados para o repositório com um status de “staged ”, que significa que o código estará em aguardo até próximo estado.

Para poder fazer as alterações no repositório é necessário que ele esteja em estágio de “staged”, para assim poder fazer um “commit“ e seguir com a atualização das alterações.

Código: git commit -m “ a mensagem que você quer colocar “

Esse código irá confirmar as alterações oficialmente no diretório. O -m serve para confirmar as modificações com alguma descrição ou aviso.

Código: git add ".tipo"*

Caso você queira deixar os arquivos em “staged” de todas as modificações que você fez no dia, pode utilizar o comando em que ele irá atualizar todos os arquivos do mesmo tipo de uma vez só.

Código: git commit -a

É utilizado caso queira fazer commits de todas as modificações que você já fez, porém sem precisar passar por um staged. Arquivos que foram adicionados e não foram acompanhados pelo git não irão contar nesse commit.

Código: git reset

Caso queira remover os arquivos que estão em “staged” e voltar para o passo anterior.

Código: git log

Para ver o histórico de modificações no repositório e em ordem cronológica.

Para tornar o git remoto é necessário você fazer uma conexão entre o seu repositório local e um repositório remoto.

Código: git remote add origin https://github.com/suaconta/project.git

Esse é um exemplo através do github. Com a criação de um repositório no github, é feita a conexão e que então irá criar uma branch principal com o nome de origin para esse repositório remoto.

Quando se é iniciado um repositório, você estará em uma “branch” ou ramificação principal, nomeada como master. Para controle de versionamento é utilizado o conceito de ramificações.

Para enviar os arquivos que estão em seu repositório local, é importante “empurrar” esses arquivos para o repositório remoto informando as ramificações que serão utilizadas no processo.

Código: git push -u origin master

Foi enviado os arquivos do repositório local na ramificação principal para o repositório remoto na ramificação principal.

Código: git pull origin master

Para atualizar seu repositório local com modificações que tenham acontecido no repositório remoto.

Código: git diff HEAD

A parte do git diff serve como uma análise de dados referentes aos repositórios, onde o HEAD serve como referência para a ramificação atual, comparando com uma última atualização recente

Código: git checkout "arquivo_arrependido.tipo".

Serve para retornar uma atualização do arquivo para uma atualização anterior. É utilizado para corrigir algum tipo de erro que possa ter acontecido ou arrependimento de atualizar.

Código: git branch nova_branch

Serve para criar uma nova ramificação do repositório.

Código: git checkout nome_branch

É utilizado para entrar em outras ramificações.

Código: git merge nome_branch

Irá fazer mesclar as modificações que você fez na branch citada na branch atual em que você está. Obs.: Tomar cuidado com esse código por favor.

Código: git -d nome_branch

Serve para deletar a ramificação atual, porém somente se tiver tido um pull e um merge para uma branch remota. Caso queira forçar o deletamento é necessário um -D ao invés de -d.

Quando acontece um conflito de um merge o git automaticamente “junta” os dois arquivos em um só informando que houve um problema na hora de mergear as 2 branchs.

Existem 3 tipos de resolução de conflito quando o mesmo acontece.

Aceitar as alterações da branch A. Aceitar as alterações da branch B. Aceitar ambas as alterações.

Os conflitos são muito variados e podem ter várias resoluções diferentes dependendo de onde a mesma está sendo aplicada.

Código: git cherry-pick

O cherry-pick é um comando para puxar um commit específico de uma branch. Esse comando foi criado como uma alternativa mais precisa para o git merge pois o mesmo puxaria todas as alterações de uma branch. Já o cherry-pick puxaria apenas a parte do código que funciona com certeza. Algumas vezes, o código criado por um desenvolvedor pode não funcionar 100%, justamente por ainda não ter passado por uma revisão e nesse caso, teria de ser feito o cherry-pick para que as alterações fossem mais precisas para outro desenvolvedor.

Membros da Equipe: Erik Tomelin, Gustavo Malkovski, Vinicius Ferri.

erik-tomelin / open_source Goto Github PK

open_source's Introduction