DEV Community: Anderson Figueiredo

Retrospectiva - Team Building: Mapa Pessoal

Anderson Figueiredo — Fri, 28 Jan 2022 20:13:10 +0000

A construção de um time ágil é uma tarefa bem simples, escolham as pessoas com habilidades que se complementam, que tenham senso de trabalho em equipe e que se comuniquem bem e você terá sucesso.

No mundo perfeito a frase acima funciona bem, mas gosto de ser muito pé no chão quando se trata de pessoas e suas complexidades.

Pensando nos desafios da construção de confiança em times recém formados, rodei uma retrospectiva muito simples com um dos times que auxilio e gostaria de compartilhar aqui.

Mapa pessoal

Check-in

A importancia do check-in se dá pelo fato de ser um momento em que as pessoas possam se desvincular de problemas anteriores ao momento da retrospectiva e se alinhar ao novo objetivo. Entendendo o estado de espírito de todo mundo e garantido

Objetivo

A partir dessa interação, promover um ambiente confortável para que as pessoas se sintam seguras para compartilhar pontos de sua vida pessoal, de forma não invasiva.

Formato

Essa retrospectiva funciona bem em times presenciais e remotos.

Em ambos os ambientes, físico ou virtual, desenhe esse diagrama, sendo o centro o nome da pessoa e as ramificações, tópicos que você julga interessante para serem compartilhados como por exemplo: Hobby, Familia, Formação, Onde Nasci, Objetivos e Livro ou filme, a imagem a seguir demonstra um exemplo:

10 minutos para os participantes adicionarem itens relacionados às ramificações, não há limite de itens, no final é esperado algo como demonstrado na imagem abaixo:

Depois que finalizarem o preenchimento, cada pessoa pode apresentar o seu mapa pessoal em 10 minutos, se aprofundando em cada item.

A ideia dessa atividade é ser uma alternativa às apresentações padrão além de aproximar mais as pessoas do time.

#Notes: DevOps & Agile Culture

Anderson Figueiredo — Tue, 27 Jul 2021 03:11:17 +0000

Necessário tratar as equipes de operações e desenvolvimento como uma só, trabalhando próximas e com objetivos e metas compartilhadas.

O que é DevOps?

Cultura que utiliza práticas e ferramentas para aumentar a capacidade de desenvolver e entregar softwares, serviços e aplicativos com alta velocidade, mas, sem por em risco a estabilidade dos mesmos.

Características

Equipe multidisciplinar
- Os integrantes passam a trocar informações e cada vez mais entendendo sobre as necessidades um do outro
Focado em entrega com qualidade e estabilidade
Automação de processos

Benefícios

Aumento da velocidade de entrega
Escalabilidade
Velocidade
- Responsabilidade de ponta a ponta
- Realizar as entregas e melhorias de forma rápida
Colaboração contínua
- Acordo no fluxo de trabalho
- Reduzir processos ineficazes
Confiabilidade
Segurança

Práticas no DevOps

Pode funcionar bem quando ligada a metodologias ágeis
Adoção de microsserviços (com prós e contras)
Automação de infraestrutura
Monitoração e registro de logs

Fases do DevOps

Plan
- Estimar e dividir as atividades necessárias
Code
- Versionamento
- Documentação
Build
Tests
Release
Deploy
Operate
Monitor

DevSecOps

Shifting Security Left
- Discutir a segurança sempre no início de cada ciclo
- Segurança distribuída
- Prevenção e endereçamento de vulnerabilidades
- Disseminação da consciência de segurança
- Software seguro com mais qualidade
- Redução de custos ao identificar e resolver problemas de segurança

O que a gente não consegue medir, não conseguimos melhorar

#Notes: Clean Agile - Chap. 2

Anderson Figueiredo — Thu, 27 May 2021 03:07:26 +0000

O porquê da Metodologia Ágil

Acho justo dizer que qualquer sistema que exija que seus usuários pensem como programadores para inserir os dados no formato esperado é uma bela de uma porcaria.

Meus amigos e colegas de trabalho me dizem com uma certa frequência que eu fico procurando bugs nos sites e apps alheios, mas a verdade é que se algo não funciona como deveria (fica o load infinito ou o elemento que some do nada ou até mesmo aquele console.log() no console) fica difícil defender o projeto.
O ponto é, pra tentar descobrir minimamente o que está errado ou o erro apresentado, já precisa de um esforço grande.

Infelizmente, com o passar do tempo, as desordens no código podem se acumular. Se o código não estiver sempre limpo e ordenado, a equipe será pressionada e isso atrasará as coisas.

Em breve eu virei com as anotações do livro The DevOps Handbook que me fez refletir bastante sobre o "fazer certo" e o "fazer rápido".
Será que em alguma situação o modo empurrar com a barriga deu certo?

o código existente é um treinador ainda mais influente.

Aqui o tema era sobre a introdução do projeto a pessoas recém chegadas no time. Acredito que tendo um bom readme ou alguém experiente disponível para passar os padrões do projeto já ajuda bastante.

Mas, de onde a Equipe dos Feras tira os requisitos? Existe um documento de requisitos atualizados? Sim. É o código antigo. Ele é o único documento que descreve com precisão o que o sistema reprojetado deve fazer.

Ainda não tive a oportunidade de refatorar um projeto inteiro (não sei se me sobraria cabelo na cabeça caso o fizesse). Mas faz sentido usar as regras do sistema antigo para o desenvolvimento do novo.
Próximo a esse trecho, Uncle Bob fala sobre a evolução do sistema antigo em comparação com o novo, basicamente o sistema novo dificilmente vai conseguir acompanhar o antigo.

Redesigns grandes são muito caros e é raro serem implementados.

Você tem medo do código, e esse medo o obriga a assumir uma postura incompetente.

Sobre não se sentir confortável o suficiente para fazer uma refatoração que você sabe que é necessária.

Espero que todos os membros de uma equipe de software tenham certeza de que alguém consiga assumir a sua retaguarda caso eles tropecem e caiam.

Vai além do Truck Factor. A maturidade e boa relação do time ajuda tanto na qualidade do fluxo quanto do trabalho em si.

Na realidade, a melhor forma de aprender é ensinar. Portanto, quando pessoas novas se juntarem à equipe, ensine-as. Aprendam a ensinar uns aos outros. Mais uma vez, a prática ágil da Equipe como um Todo é compatível com essa expectativa.

Outro dia conversando com um colega de trabalho me veio o questionamento sobre como/quanto esse primeiro contato com os nossos projetos estariam sendo afetadas por conta do trabalho remoto. Para dar um melhor contexto, a cultura do time anteriormente já era essa, de fazer o onboarding no projeto, bem próximo ao time, para que dúvidas sejam esclarecidas o mais rápido possível. (Acho que esse assunto vale um post)

Os clientes têm o direito de agregar o máximo de valor possível em cada iteração.

Sobre os direitos do cliente (ou qualquer entidade relacionada com o produto/cronograma/orçamento).

A metodologia ágil não é um processo, não é modismo e não é somente um conjunto de regras. Pelo contrário, a agilidade é um conjunto de direitos, expectativas e disciplinas do tipo que alicerça a base de uma profissão ética.

Num vídeo ainda não publicado no meu canal do YouTube eu falo um pouquinho só sobre a metodologia ágil e suas cerimônias. Nele cito a impressão de que as cerimônias são obrigatórias e que todas as regras são escritas em pedra, tem uma diferença entre o fazer errado e o fazer adaptações, às vezes o problema é o desequilíbrio entre essas partes. Mas tendo em mente a importância do trabalho e o impacto que ele tem, acredito que boa parte dos problemas já são mitigados.

Tentei trazer mais links externos com referências para alguns termos, tem mais coisas desse tipo para serem agregadas aqui, mas deixo isso para a próxima revisão.

#Notes: Clean Agile - Chap. 1

Anderson Figueiredo — Tue, 25 May 2021 03:11:29 +0000

Anotações do capítulo: Introdução à Metodologia Ágil

A ideia de repetir um processo bem-sucedido é intuitiva e humana demais para ser considerada algum tipo de revolução.

É o que já aprendemos desde pequenos vendo coisas que dão certo.

O que relato a seguir é proveniente das minhas memórias; não tentei verificar nada com os envolvidos. Logo, você deve estar ciente de que minhas recordações têm muitas omissões e coisas inacreditáveis, ou, no mínimo, um tanto imprecisas. Mas não se assuste, pelo menos tentei ser um pouco divertido.

Tudo bem Uncle Bob, as vezes minha memória me confunde também.

Um bom gerente administra os coeficientes desses atributos, em vez de exigir que todos esses coeficientes sejam 100%. A metodologia ágil se esforça para atingir esse tipo de gerenciamento.

Sobre a capacidade de coordenação do gerente quando consegue realizar um projeto bom, rápido e barato e concluído quando necessário.

...os requisitos estão em constante movimento e nunca podem ser congelados. Isso ocorre porque os clientes não sabem realmente o que querem. Eles meio que sabem qual problema querem resolver.

O projeto chegar com o objetivo e utilidade imutáveis e seguir assim até a entrega seria um utopia? Esse trecho me faz lembrar bastante do último item do manifesto ágil: "Responder a mudanças mais que seguir um plano".

Não há como fingir que você implementou alguma coisa.

Imagina a situação em que alguém está revisando o seu código, questiona o motivo de ter usado tal método e você não consegue explicar ou diz algo sem sentido.

Esse processo de escrever histórias, estimá-las, planejá-las e projetá-las nunca para.

Tudo muda no decorrer do projeto, as funcionalidades, o foco do produto final, as necessidades de quem usa, as regras de negócio. Mas mais a frente ele cita que não é necessário desenvolver todas as histórias que foram criadas, mas entregar o necessário para o projeto. A priorização ajuda nesse ponto.

Por enquanto, quais são as possibilidades de a equipe concluir todas as histórias que planejou terminar? Praticamente zero, é claro. Isso ocorre porque o software não é um processo de estimativa confiável.

Colocamos a metodologia ágil em prática para matar a esperança antes que ela destrua o projeto.

Para não ficar vítima do achismo na expectativa de que vão conseguir cumprir o cronograma.

A esperança é a assassina de qualquer projeto. É o que faz uma equipe de software iludir os gerentes sobre seu verdadeiro progresso. Quando um gerente pergunta a uma equipe: “Como as coisas estão indo?”, é a esperança que responde: “Muito bem.” Gerenciar um projeto de software por meio da esperança não é nada bom. A metodologia ágil é uma forma de proporcionar uma bela dose precoce e contínua da realidade nua e crua no lugar da esperança.

O que eu disse?

A metodologia ágil é saber, o mais cedo possível, o quanto estamos ferrados.

Essa frase é boa.

Gerentes gerenciam os projetos de software, coletando os dados e tomando as melhores decisões possíveis com base neles. A agilidade gera dados. A agilidade gera muitos dados. Os gerentes utilizam esses dados para direcionar o projeto rumo ao melhor resultado possível.

Vai além da melhor visualização e acompanhamento do trabalho. Vai além da remoção de impedimentos e cerimônias.
Os gerentes deveriam (saber) coletar esses dados e (como) utilizar isso para estudar possíveis melhorias apresentar para o time e implementá-las.
É uma tarefa fácil?

A Lei de Brooks postula: Adicionar pessoas a um projeto de software atrasado resulta em um atraso ainda maior.

Ainda preciso ler mais sobre a Lei de Brooks.
Mas um antigo colega de trabalho que me guiou no início dos estudos sobre agilidade sempre reforçava que a entrada de uma nova pessoa impactava diretamente na produtividade por um tempo.

Grandes são as chances de eu retornar a essas anotações para atualizar algumas ideias ou trazer mais questionamentos.

Retrospectiva - Team Building: Party Time

Anderson Figueiredo — Sat, 08 May 2021 19:41:41 +0000

Já contei um pouco sobre os tipos de retrospectivas e a importância delas nesse post aqui, vale a pena conferir.

Agora mostro pra você uma das retrospectivas de #teambuilding que costumo fazer com vários times.

interações:

Quebra gelo
Party time

(Caso um membro ou toda a equipe esteja trabalhando remotamente, pode-se utilizar alguma ferramenta para facilitar o desenho, recomento o Miro ou Mural)

Quebra gelo - 10min

Dessa lista de perguntas, escolha uma para cada participante de forma aleatória.

Se você fosse um vegetal, o que seria?
Se você pudesse se tornar um personagem fictício, qual escolheria e por quê?
Se você pudesse morar em qualquer lugar e levar tudo e todos com você, para onde iria?
Se você pudesse/quisesse mudar seu nome, para qual seria?
Você é primavera, verão, outono ou inverno? Por quê?
Num apocalipse zumbi, o primeiro item a sua esquerda será sua única arma, qual é?
Se você criasse um slogan para a sua vida, qual seria?
O que eu amo e quero manter no meu trabalho, porque?

Party time - Trabalho em equipe - 50min

A ideia aqui é montar uma festa, com uma temática que facilite a interação dos membros do time.

Cada um fala uma coisa gostaria que tivesse numa festa (tentar fazer com que as pessoas digam coisas diferentes, mas pode ser qualquer coisa mesmo)

Dessa lista de itens, é necessário fazer um sorteio para que cada pessoa pegue um item diferente do que falou e tente desenhar.

Pra não virar bagunça, pode tentar desenhar um item por vez, mas as outras pessoas podem ajudar no processo também.

Conclusão

Para o fechamento, o(a) facilitador(a) pode perguntar o que as pessoas acharam e qual foi o ponto mais interessante da dinâmica.

Mesmo sendo uma interação um pouco incomum, é uma boa forma de contato inicial com novo membro ou até mesmo um novo time inteiro. As vezes é melhor oferecer uma dinâmica fácil e pode-se dizer, fora do contexto do processo comum da empresa, pois assim a conexão entre as pessoas fica mais leve.

Transformação Ágil

Anderson Figueiredo — Fri, 09 Apr 2021 23:24:15 +0000

Acho importante começar dando uma definição rápida sobre o que é agilidade quando aplicada no contexto de desenvolvimento de software.

A origem do termo ágil é mais ou menos uma resposta aos modelos convencionais de desenvolvimento de software existentes nos anos 90, sendo um dos mais conhecidos o chamado método cascata.

O modelo cascata resumidamente falando tem um fluxo linear bem burocrático com vários passos definidos em que ao cumprir cada passo o projeto sempre segue em frente. O problema desse método é que se demorava muito em cada etapa e o escopo era fechado demais para responder às mudanças necessárias para o avanço do projeto. Mas vou deixar pra falar mais desse método em outro post.

A principal razão para motivar mudanças no modelo de desenvolvimento era economizar recursos, e o recursos mais caro que existe é tempo. Tempo esse que passa para todos, das pessoas desenvolvedoras até as grandes negociações entre corporações e startups. O ponto é que: para economizar tempo era necessário flexibilizar o fluxo de trabalho e de certa forma priorizar os principais pontos no desenvolvimento de software. Vamos relembrar os pilares do Manifesto Ágil:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

A partir da origem dessa ideologia da agilidade, é possível que ambos os lados (desenvolvimento e cliente) consigam validar mais rapidamente o projeto em questão.

Para isso, era necessário ter uma forma de dividir o projeto em pequenas partes, priorizadas por ordem de maior valor para serem desenvolvidas primeiro.

Com isso, nasceram alguns frameworks como XP, Kanban e SCRUM que auxiliam nessa divisão, mas esses merecem ter um post para cada.

Acontece que a transformação ágil, se dá a partir do momento em que equipes de desenvolvimento encaram a ideia de mudar a forma de trabalho na tentativa de melhorar o dia a dia enquanto num projeto. Essa tarefa não é fácil por várias questões, tanto por seguimento da empresa, tipo de projeto, tipo de cliente, cultura do time/empresa, pontos delicados que merecem um outro post especial.

Importante salientar que essa mudança nunca, nunca em hipótese alguma, acontece da noite pro dia, é um processo lento que exige adaptação constante, assim como observação e colaboração de todas as pessoas envolvidas visando melhorias constantes no fluxo de trabalho até que se alcance uma boa estabilidade.

Em posts futuros pretendo trazer assuntos como maturidade de time, organização, frameworks, ícones do desenvolvimento e agilidade e outros.