e todos os créditos serão postados no fi m do material. As partes “mão na massa” exigem a participação de todas as pessoas. Então, peço foco 100%, evitando multi-task (vamos manter o fl ow 😀). A aula será gravada e você poderá assisti-la depois. Todo o material será compartilhado com vocês, portanto não se preocupe em tirar prints - só se quiser!
• Esse workshop tem como objetivo explorarmos conhecimento sobre arquitetura de software e sua relação com as estruturas de times. • Além do conteúdo teórico, você vai poder experimentar uma ferramenta de mapeamento de domínios e, através de um caso hipotético, criar estruturas de times em volta desses domínios. Photo by Colin Carter on Unsplash
sensação de "ecstasy" e clareza; • você sabe exatamente o que você quer fazer de um momento para outro; • o senso de tempo desaparece; • você esquece de você mesmo; • você se sente parte de algo maior. Photo by Mulyadi on Unsplash
desenvolvendo software, essa sensação acontece quando estamos tão imersas ou imersos no código que esquecemos a hora e a realização ao ver a conclusão de uma entrega (por exemplo, um endpoint de uma API funcionando como deveria, ou um trecho de código executando algo de forma perfeita) gera um grande prazer e alegria. Ver as coisas funcionando depois que você fez aquele código é uma sensação realmente diferente.
• Objetivos em comum; • Objetivos pessoais alinhados; • Comunicação aberta; • Segurança; • Compromisso mútuo; • Senso de unidade; • Senso de progresso conjunto; • Con fi ança mútua;
• Troca de contexto e falta dele • Interrupções no fl uxo de trabalho • Distrações • Espera por clareza do trabalho • Barreiras de comunicação • Falta de conhecimento/skills • Reuniões desnecessárias • Dependências externas ou de outros times • Expectativas irreais ou não claras;
às estruturas de times que são: • Troca de contexto e a falta dele; • Barreiras de comunicação; • Espera pela clareza do trabalho; • Dependências externas ou de outros times;
quantidade de recursos de memória de trabalho usada. A teoria é que uma informação só pode ser armazenada na memória de longo prazo depois de primeiro ser recebida e processada pela memória de trabalho. Mas, essa memória é extremamente limitada tanto em capacidade como em duração
e tem limitações, nós podemos pensar em maneiras de reduzir a quantidade dessas informações necessárias para o trabalho ser feito, tornando melhor o uso da nossa capacidade cognitiva. PS: deixando claro aqui que não estamos falando de multi-tarefas e sim, multi-contextos.
super fi cial do contexto de negócio; • Demora pra ganhar contexto novamente sobre o domínio, diminuindo a produtividade; • Baixo conhecimento sobre a arquitetura ou o ecossistema que o domínio abrange; • Aumento do tempo para corrigir e identi fi car problemas; • Alta demora na recuperação de incidentes (MTTR - mean time to recovery); • Sobrecarga de assuntos, o que pode levar à fadiga mental e stress; • Di fi culdade ao lembrar de detalhes importantes das jornadas; • Fadiga na tomada de decisão - tende-se a tomar decisões mais pobres por conta da quantidade de assuntos pra lidar; • Tempo de onboarding mais alto para novas pessoas no time;
domínios sob sua responsabilidade. Alguns desa fi os eram constantes, como a priorização de iniciativas, de fi nição dos objetivos, o entendimento do capacity dos times e o stress que o time tinha ao ter que buscar informações de fl uxos que nem sabiam que tinham responsabilidade.
carga cognitiva. Se as pessoas do time precisam parar pra ganhar contexto do trabalho, buscar informações para ter clareza do trabalho a ser feito, por conta da falta de contexto e das dependências não explícitas ou não declaradas, di fi cilmente vão conseguir encontrar o estado de Flow.
principais quando desenhamos algum software: software developers e business experts Ambos os papéis devem falar a mesma linguagem, e essa linguagem deve ser onipresente - todos devem usar os mesmos termos e os significados das coisas precisam ser compartilhados. Isso até para nomes de classes, métodos, variáveis.
mapeamento de domínios. O EventStorming vale um curso todo sobre, mas sendo resumido aqui, ela se baseia em como atores, modelos e sistemas se relacionam. O nome Event não é à toa: a ideia é que o mapeamento seja feito em torno de eventos entre esses modelos e sistemas.
artefatos do EventStorming, o Domain Event. Através dos Domain Events nós conseguimos mapear os domínios que serão necessários para as definições de estruturas de times. Esse tipo de EventStorming é chamado de "Big Picture", pois não entra nas nuances dos processos, é apenas uma discussão dos eventos que acontecem, num nível alto de abstração.
para alcançar as metas digitais “As empresas esperam que grande parte de seu crescimento de curto prazo seja impulsionado pelo digital, mas o impacto continua elusivo. Além disso, faltam estruturas organizacionais e fi cazes, responsabilidade e métricas e incentivos signi fi cativos. À medida que os executivos se envolvem mais nos esforços digitais, eles devem trabalhar para garantir que suas estruturas e processos de negócios sejam con fi gurados para aproveitar ao máximo as oportunidades que os esforços digitais oferecem”
resultado) é desproporcionalmente grande - pelo menos dez vezes maior - comparado com seus pares, devido ao uso de novas técnicas organizacionais que alavancam as tecnologias aceleradas” “Com muita pouca inércia interna (isto é, número de colaboradores ativos ou estruturas organizacionais), elas demonstram uma extraordinária fl exibilidade, o que é uma qualidade fundamental no mundo volátil de hoje”
nido de forma mais ampla aqui do que apenas sistemas de informação) inevitavelmente produzirá um desenho cuja estrutura é uma cópia da estrutura de comunicação da organização. “As organizações há alguns anos entendem essa ligação entre a estrutura organizacional e o software que criam e vêm adotando novas estruturas para alcançar o resultado que desejam.” Thoughtworks
sobre estrutura de times e arquitetura de software, descrevem uma forma de classi fi car domínios por nível de complexidade, utilizando o Cyne fi n (um modelo pra classi fi car decisões e até dar sentido para certas situações). 1. Simples - a maioria do trabalho tem um caminho claro de ação; 2. Complicado - mudanças precisa ser analisadas e podem requerer algumas interações na solução até encontram um caminho; 3. Complexo - soluções requerem uma grande experimentação e descoberta; 4. Caótico - não há uma forma clara de como a solução ser resolvida;
do time já dominam o assunto, tem na palma da mão o contexto 2. Complicado - time ainda precisa estudar o ecossistema, entender como funciona a relação com outros componentes dos serviços. 3. Complexo - pessoas do time não têm total conhecimento dos fl uxos de negócio, nem das regras e políticas. Precisam fazer descoberta, muitas vezes abrindo vários projetos e precisando mapear as interconexões 4. Caótico - ninguém nunca lidou com aquele domínio de conhecimento, nem sabe como começar
a um time. Se o domínio for muito grande, ao invés de dividir responsabilidades de um domínio para vários times, tente dividir os domínios em sub-domínios, e associar cada sub-domínio a um time. Heurística 2: um único time deve ser capaz de acomodar de 2 a 3 domínios do tipo Simples. Como os domínios de tipo Simples são mais procedurais, o custo de troca de contexto entre domínios é mais tolerável. Se você manter 1 domínio Simples para 1 time, há o risco de desengajamento com o contexto do trabalho, que tende a ser mais de natureza rotineira. Heurística 3: um time responsável por 1 domínio Complexo, não deveria ter nenhum outro domínio sob sua responsabilidade. Resolver problemas complexos levam tempo e foco. A priorização sempre vai tender em resolver coisas do domínio Simples, por conta da facilidade do time em lidar com aquilo, do que mergulhar em resolver problemas que são complexos, porém importantes para o negócio. Heurística 4: evite que um time tenha que lidar com dois domínios Complicados. Isso pode parecer viável para um time grande, mas na prática, o time irá agira como se fossem dois, um pra cada domínio, e a carga cognitiva vai ser exigida como se todos precisasem saber de ambos. O ideal é dividir esse time em dois, pra que haja foco e autonomia em cada um dos domínios.
eduardojmatos
yanzm
kozy4324
sonic
hiranabe
oracle4engineer
junki
minorun365
sh_fk2
cheng_wei_chen
ry
wyamazak_devrel
line_developers_tw
marketingsoph
keathley
nwiizo
mza
addyosmani
matthewcrist
lauravandoore
tamaranovitovic
eileencodes
garrettdimon
greggifford
chriscoyier
