Skip to main content

4 posts tagged with "agilidade"

View All Tags

· 8 min read
Felipe Jorge Sales da Silva

No ambiente de desenvolvimento de software, a metodologia ágil Scrum tem se mostrado extremamente eficaz para promover a entrega de valor de forma rápida e adaptativa. Uma das principais características do Scrum é a ausência de hierarquia formal entre os membros da equipe de desenvolvimento. Neste artigo, discutiremos por que a hierarquia não funciona para o Scrum e por que é crucial adotar uma mentalidade colaborativa. Também abordaremos a importância do Code Review por toda a equipe e os perigos de um desenvolvedor sênior sem a cultura do Scrum ou agilidade.

Colocar sistemas hierarquicos promovem a divisão e dificulta a comunicação, a revisão de código deve ser algo compartilhado e não exclusivo, a rotação do code review não é em temporadas, mas constante, isto é, todos devem fazer revisão de todos.

Hierarquia versus Autonomia no Scrum

A hierarquia tradicional, com suas estruturas rígidas de poder e tomada de decisões centralizada, não se encaixa no contexto ágil do Scrum. No Scrum, a equipe de desenvolvimento é autogerenciada e responsável por tomar decisões técnicas e de implementação. A ausência de uma hierarquia formal permite que os membros da equipe sejam mais autônomos, colaborativos e adaptáveis às mudanças.

A mentalidade colaborativa é essencial no Scrum, pois todos os membros da equipe têm a responsabilidade de alcançar os objetivos do projeto. Através da colaboração, as habilidades e perspectivas de cada membro da equipe são aproveitadas de forma eficaz, levando a soluções inovadoras e de alta qualidade.

A hierarquia cria barreiras na comunicação e dificulta o fluxo de informações e ideias entre os membros da equipe. Isso pode levar a uma falta de transparência, perda de tempo e falta de engajamento por parte dos desenvolvedores. Além disso, a hierarquia pode inibir a autonomia e a criatividade, pois os membros da equipe podem se sentir restringidos por uma estrutura de comando e controle.

O Papel do Scrum Master no Scrum

Embora o Scrum preze pela ausência de hierarquia dentro do time de desenvolvimento, isso não significa que a liderança seja descartada totalmente. Pelo contrário, é essencial ter líderes fortes que garantam a efetividade do Scrum e facilitem o trabalho da equipe.

O Scrum Master como Líder Servo

O Scrum Master desempenha um papel de liderança no Scrum, atuando como um servo líder. Eles facilitam o processo e promovem a adoção efetiva do framework, orientando a equipe sobre as práticas ágeis, ajudando a remover obstáculos e promovendo uma cultura de colaboração e autogerenciamento.

No entanto, é importante ressaltar que o Scrum Master não é um gerente no sentido tradicional. Em vez de dar ordens ou impor autoridade hierárquica, o Scrum Master trabalha em estreita colaboração com a equipe, incentivando a transparência, a responsabilidade e a melhoria contínua.

A Liderança do Scrum Master

A liderança do Scrum Master é baseada na facilitação, na escuta ativa e no apoio aos membros da equipe. Eles atuam como facilitadores, garantindo que as cerimônias do Scrum sejam realizadas de forma eficaz, promovendo a colaboração entre os membros da equipe e removendo quaisquer obstáculos que possam atrapalhar o progresso do projeto.

Além disso, o Scrum Master desempenha um papel crucial na disseminação da mentalidade ágil e na cultura de melhoria contínua. Eles encorajam a equipe a refletir sobre seu trabalho, identificar áreas de melhoria e experimentar novas abordagens para alcançar resultados melhores.

O Sucesso do Scrum e o Papel da Equipe

Enquanto o Scrum Master oferece orientação e suporte, é importante destacar que o sucesso do Scrum depende da colaboração e do engajamento de toda a equipe. Cada membro tem a responsabilidade de se autogerenciar, tomar decisões e contribuir ativamente para o sucesso do projeto.

O Scrum Master trabalha em conjunto com a equipe para criar um ambiente propício à criatividade, inovação e colaboração. Eles ajudam a desenvolver a capacidade da equipe de tomar decisões informadas e assumir a responsabilidade pelo trabalho realizado.

O Scrum Master não apenas lidera, mas também capacita a equipe a se tornar autogerenciável e alcançar um desempenho excepcional. Eles promovem a comunicação efetiva, resolvem conflitos e incentivam a melhoria contínua.

Code Review: Uma Prática Colaborativa Essencial

Embora o Scrum seja um framework de gerenciamento de projetos ágeis e o code review seja uma prática de revisão de código, eles podem estar relacionados e se complementar dentro de um ambiente de desenvolvimento ágil.

No Scrum, o Code Review é uma prática fundamental para garantir a qualidade do código e promover a colaboração entre os desenvolvedores. Todos os membros da equipe devem participar do processo de revisão de código, independentemente de sua experiência ou posição na equipe.

Ao envolver toda a equipe no Code Review, várias vantagens são alcançadas. Em primeiro lugar, isso ajuda a disseminar o conhecimento técnico, permitindo que todos os desenvolvedores aprendam e cresçam. Além disso, promove a responsabilidade coletiva pela qualidade do código, identificando possíveis erros, melhorias e oportunidades de otimização.

Ao ter uma mentalidade colaborativa no Code Review, os desenvolvedores podem compartilhar conhecimentos, oferecer sugestões construtivas e aprender uns com os outros. Isso resulta em um código mais limpo, mais eficiente e mais resiliente, melhorando a produtividade e evitando problemas futuros.

Limitar o code review a posições hierárquicas pode ser um erro, pois isso pode criar uma falsa sensação de superioridade entre os desenvolvedores. No contexto do code review, é importante que todos os membros da equipe tenham a oportunidade de revisar e serem revisados, independentemente de sua posição na hierarquia.

Ao permitir que todos participem do processo de code review, cria-se um ambiente de colaboração e aprendizado mútuo. Todos os desenvolvedores têm conhecimentos e perspectivas diferentes, e permitir que todos tenham voz nas revisões de código pode levar a melhorias significativas na qualidade do código e no crescimento profissional da equipe.

O Perigo de um Desenvolvedor Sênior sem a Cultura do Scrum ou Agilidade

Um desenvolvedor sênior, com uma vasta experiência técnica, pode ser um recurso valioso para a equipe. No entanto, se esse desenvolvedor não estiver alinhado com a cultura do Scrum ou agilidade, pode representar um perigo para a organização. Aqui estão alguns motivos pelos quais um desenvolvedor sênior sem a cultura do Scrum ou agilidade pode ser problemático:

  1. Falta de colaboração: Um desenvolvedor sênior que não valoriza a mentalidade colaborativa do Scrum pode ser resistente a trabalhar em equipe e preferir tomar decisões de forma independente. Isso pode levar a lacunas de comunicação, falta de compartilhamento de conhecimento e redução da eficácia da equipe como um todo.

  2. Resistência à mudança: A agilidade requer uma mentalidade flexível e aberta a mudanças. Um desenvolvedor sênior preso a métodos de trabalho tradicionais pode ser resistente a adotar práticas ágeis, dificultando a implementação bem-sucedida do Scrum na organização.

  3. Dificuldade em se adaptar: A agilidade exige a capacidade de se adaptar rapidamente a novas situações e requisitos em constante mudança. Um desenvolvedor sênior que está acostumado a seguir processos rígidos e definidos pode ter dificuldade em se adaptar às necessidades do Scrum e pode prejudicar a agilidade da equipe.

  4. Falta de feedback construtivo: A cultura do Scrum incentiva a retroalimentação contínua entre os membros da equipe. Um desenvolvedor sênior que não está alinhado com essa cultura pode não fornecer feedback construtivo aos colegas, perdendo uma oportunidade valiosa de aprendizado e crescimento para toda a equipe.

  5. Ausência de liderança ágil: Um desenvolvedor sênior geralmente é visto como uma referência técnica para a equipe. Se esse desenvolvedor não estiver alinhado com a cultura ágil, sua liderança pode prejudicar a adoção bem-sucedida do Scrum. É fundamental que os líderes na equipe tenham uma compreensão sólida dos valores e princípios ágeis para orientar e motivar a equipe adequadamente.

É importante ressaltar que esses problemas não estão relacionados apenas à posição de desenvolvedor sênior, mas sim à falta de alinhamento com a cultura ágil. Independentemente do nível de experiência, todos os membros da equipe devem abraçar os princípios e valores do Scrum para maximizar o sucesso do projeto, é verdade que o Scrum Master é responsável por saber o Scrum, porém isso não significa que os desenvolvedores não devam ter experiência com metodologias ágeis.

Para evitar esses perigos, é essencial investir em treinamento, comunicação clara e promover uma cultura de aprendizado e adaptação. Os desenvolvedores seniores também devem estar dispostos a se envolver e aprender com a equipe, adotando uma mentalidade colaborativa e ágil.

Conclusão

Em conclusão, a metodologia ágil Scrum é altamente eficaz no desenvolvimento de software, promovendo a entrega rápida e adaptativa de valor. A ausência de hierarquia formal e a mentalidade colaborativa são características fundamentais do Scrum, permitindo autonomia, colaboração e adaptação.

O papel do Scrum Master é facilitar e promover a adoção efetiva do Scrum, enquanto o Code Review é uma prática colaborativa essencial para garantir a qualidade do código e do produto.

No entanto, a presença de uma liderança sem a cultura do Scrum ou agilidade pode representar desafios, como a falta de colaboração e resistência à mudança, não proporcionar uma cultura de revisão eficiente ou impedir a cultura de revisão, fazendo ser uma cultura hierarquica e selecionada para apenas algumas pessoas. Investir em treinamento, comunicação clara e uma cultura de aprendizado e adaptação é crucial para evitar esses problemas e alcançar o sucesso no Scrum.

· 3 min read
Felipe Jorge Sales da Silva

Muitos profissionais e gestores de TI podem argumentar que projetos de migração tecnológica não são adequados para abordagens ágeis como o Scrum. Eles acreditam que esses projetos, que envolvem a transferência de dados, configurações e funcionalidades de um sistema antigo para um novo, necessitam de um caminho claramente definido com pouca margem para mudanças.

No entanto, essa visão não leva em conta a imprevisibilidade inerente a todos os projetos de tecnologia, incluindo migrações. Mesmo o projeto mais bem planejado pode enfrentar obstáculos inesperados, como problemas técnicos ou uma curva de aprendizado mais acentuada para os desenvolvedores.

Primeiramente, vale lembrar que a engenharia reversa, no contexto de migração tecnológica, geralmente envolve a compreensão de um sistema existente (frequentemente mais antigo ou obsoleto) para que possa ser recriado ou substituído por um sistema mais moderno ou eficiente. Isto implica em desmontar e analisar os componentes do sistema, entender como eles interagem e, em seguida, projetar um novo sistema com funcionalidade semelhante.

No entanto, só porque estamos recriando ou substituindo um sistema existente, não significa que não possa haver espaço para melhorias, otimizações ou novas funcionalidades, pois se trata de componentes e tecnologias diferentes. E é aqui que a presença de um Product Owner (PO) pode ser muito útil. O PO é responsável por entender as necessidades dos stakeholders, priorizar as funcionalidades e garantir que o produto final atenda às necessidades do negócio.

Por que considerar o Scrum para migração tecnológica?

O Scrum, e as metodologias ágeis em geral, oferecem uma estrutura flexível que permite às equipes se adaptarem a mudanças e lidarem com imprevistos de maneira mais eficaz.

Diante dessa realidade, é válido questionar se as metodologias ágeis, como o Scrum, poderiam ser aplicadas em projetos de migração tecnológica. Aqui estão algumas razões para considerar essa abordagem:

  1. Iterativo e Incremental: A natureza iterativa e incremental do Scrum permite uma detecção precoce e solução de problemas. Ao trabalhar em pequenas partes do projeto por vez, as equipes podem identificar desafios e corrigi-los antes que se tornem problemas maiores. Isto é particularmente útil na migração tecnológica, onde problemas inesperados são frequentes.

  2. Colaboração e Comunicação: A abordagem ágil coloca um grande ênfase na comunicação constante e colaboração efetiva, seja por meio de reuniões diárias de Scrum ou sessões de planejamento de sprint. Esta cultura de colaboração pode ser vital em projetos de migração, onde a clareza de objetivos e responsabilidades é fundamental.

  3. Flexibilidade: Projetos de migração podem ser marcados pela mudança. Seja uma alteração no escopo, problemas técnicos não previstos ou feedback do cliente, o Scrum permite uma resposta rápida e efetiva a essas mudanças.

  4. Feedback Contínuo: A abordagem ágil preconiza a entrega contínua de valor, permitindo o feedback frequente de stakeholders e a oportunidade de ajustar o curso do projeto, se necessário. Em projetos de migração, esse feedback contínuo pode ser crucial para garantir que o novo sistema atenda às necessidades do negócio.

Conclusão

Embora a migração tecnológica possa apresentar desafios únicos, a aplicação adaptativa das metodologias ágeis pode ser benéfica. A escolha da metodologia deve ser baseada nas necessidades e circunstâncias específicas do projeto, e não em prescrições rígidas.

Apesar das percepções iniciais, o Scrum e outras metodologias ágeis podem, de fato, ser aplicados com sucesso em projetos de migração tecnológica. Com a capacidade de se adaptar a mudanças e enfrentar desafios imprevistos, essas abordagens podem fornecer uma estrutura eficaz para navegar por esses complexos projetos de TI.

· 5 min read
Felipe Jorge Sales da Silva

"Kanban: Successful Evolutionary Change for Your Technology Business" de David J. Anderson é um livro seminal no mundo da gestão de projetos ágeis. Ele apresenta o sistema Kanban, adaptado das fábricas da Toyota para o mundo do desenvolvimento de software, focando em melhorar a eficiência e a eficácia do fluxo de trabalho.

Principais métodos do Kanban

O método Kanban se baseia em três princípios básicos:

  1. Visualize o fluxo de trabalho: Isso é normalmente feito através de um quadro Kanban, onde cada tarefa é representada por um cartão que se move de uma coluna para outra, representando diferentes estágios do fluxo de trabalho.
  2. Limite o trabalho em progresso (WIP): Isso significa que você deve limitar o número de tarefas que estão em andamento em qualquer estágio do fluxo de trabalho. Limitar o WIP ajuda a evitar o excesso de tarefas e garante que o trabalho flua suavemente através do sistema.
  3. Gerencie o fluxo: Isso envolve monitorar o movimento das tarefas através do quadro Kanban e fazer ajustes conforme necessário para melhorar a eficiência.

Reuniões Standup

Em um sistema Kanban, as reuniões standup têm um formato diferente. Em vez de cada membro da equipe responder a três perguntas típicas ("O que foi feito ontem?", "O que você fará hoje?", "Você está bloqueado ou precisa de alguma ajuda?"), o foco muda para o fluxo de trabalho.

O Fluxo de Trabalho

O facilitador da reunião, geralmente o gerente do projeto ou um gerente de linha, "anda pelo quadro" visualizando o status dos tickets. A convenção é olhar o trabalho de trás para frente - da direita para a esquerda, na direção "do puxar".

Enfocando os Itens Bloqueados e Atrasados

Em uma reunião standup do Kanban, a ênfase é dada para itens que estão bloqueados ou atrasados devido a defeitos. Se um item parece estar parado e não se movimentou por alguns dias, questões podem ser levantadas sobre ele.

Melhoria da Capacidade de Gerenciamento de Problemas

Este formato permite que a equipe aprimore a capacidade de gerenciamento de problemas da organização. A equipe discutirá brevemente quem está trabalhando no problema e quando ele será resolvido.

Movendo-se para a frente, não para trás

A ideia de que as tarefas devem ser continuamente movidas para a frente no processo, ao invés de serem movidas para trás. Isto está alinhado com o princípio de que o trabalho deve sempre estar avançando em direção à conclusão, além disso cada coluna tem um limite de tarefa para Work In Progess, você voltar uma tarefa para trás pode ocasionar vários problemas, como a terefa não poder retroceder por causa que o número máximo de tarefas já foi atingido, fazendo a tarefa ficar presa na parte de teste.

Por exemplo, se uma tarefa estiver em teste e um bug for descoberto, é sugerido que, em vez de mover a tarefa de volta para a coluna de desenvolvimento, uma nova tarefa deve ser criada para lidar com a correção do bug. Isso ajuda a manter a visibilidade e a rastreabilidade, e também enfatiza a ideia de que o trabalho deve ser concluído antes de ser movido para a próxima etapa.

Lidando com Atividades Desordenadas

Em situações de alta inovação e experimentação, as atividades relacionadas a um trabalho de valor para o cliente podem não seguir uma ordem específica. O Kanban não deve forçar a execução de atividades em uma ordem determinada, mas sim refletir a maneira real de como o trabalho é feito.

Existem algumas estratégias para lidar com múltiplas atividades desordenadas:

  1. Uma única coluna de atividades: Semelhante à abordagem para lidar com atividades concorrentes, todas as atividades são mantidas em uma única coluna e não se acompanha explicitamente no quadro qual delas é finalizada.

  2. Modelando atividades como concorrentes: Esta abordagem envolve mover tickets verticalmente para cima e para baixo nas colunas conforme são puxados para cada atividade específica. Os tickets podem ser modificados para ter uma caixa pequena para cada atividade. Quando uma atividade é finalizada, a caixa pode ser marcada para sinalizar visualmente que o item está pronto para ser puxado para outra atividade na mesma coluna.

Se todas as caixas são preenchidas, o item está pronto para ser puxado para a próxima coluna no quadro ou pode ser movido para a coluna "done".

Lembrando que é possível que a etapa de desenvolvimento e de testes fiquem na mesma coluna, porém isso aumenta o número de tasks que ficariam na mesma coluna para determinada atividade.

Definição de Pronto

A definição de pronto é outro conceito importante em Kanban. Isso se refere ao conjunto de critérios que uma tarefa deve atender antes de poder ser considerada completa e movida para a próxima etapa do fluxo de trabalho. A definição de pronto ajuda a garantir que o trabalho esteja realmente concluído antes de ser avançado, minimizando a necessidade de retrabalho.

Conclusão

"Kanban: Successful Evolutionary Change for Your Technology Business" fornece uma visão detalhada e prática de como implementar e usar o Kanban no desenvolvimento de software. Os princípios e práticas que Anderson descreve ajudam a criar um fluxo de trabalho mais eficiente e eficaz, minimizando o retrabalho e melhorando a qualidade do produto final.

· 4 min read
Felipe Jorge Sales da Silva

Agilidade, Scrum e Kanban: São apenas responsabilidades do Scrum Master (SM)?

A agilidade, Scrum e Kanban não são apenas responsabilidades do Scrum Master. Embora o SM desempenhe um papel fundamental na promoção e aplicação desses conceitos e metodologias, é crucial que toda a equipe - incluindo os profissionais sêniores - entenda e se comprometa com eles.

Em um ambiente ágil, cada membro da equipe deve estar ciente do valor da colaboração, capacidade de resposta à mudança, entrega contínua de valor e melhoria contínua. Entender Scrum ou Kanban (ou qualquer outro framework ágil que a equipe esteja usando) significa entender como esses valores são colocados em prática.

Uma cultura de agilidade é suficiente para tornar uma empresa boa?

Uma cultura de agilidade pode contribuir significativamente para a eficácia de uma empresa, mas não é a única coisa que importa. Outros fatores, como liderança eficaz, estratégia clara, boa comunicação, compreensão do mercado e do cliente, e a qualidade do produto ou serviço também são essenciais.

É suficiente ter conhecimento técnico, mas não ter conhecimento de agilidade?

Ter um forte conhecimento técnico é certamente valioso, mas em um ambiente de trabalho moderno, especialmente em desenvolvimento de software, a compreensão das práticas ágeis é quase tão importante quanto as habilidades técnicas.

A agilidade ajuda as equipes a lidar com a incerteza, a se adaptar às mudanças e a entregar valor de maneira mais eficiente e eficaz. Portanto, mesmo que um profissional sênior seja tecnicamente habilidoso, a falta de conhecimento em agilidade pode limitar a sua capacidade de contribuir plenamente para a equipe e o projeto.

O que é Code Review?

O Code Review é uma prática essencial em qualquer equipe de desenvolvimento, independentemente do nível de experiência dos membros. Consiste em um processo sistemático de verificação de se o código-fonte de um programa atende aos padrões de desenvolvimento predeterminados. O Code Review promove a qualidade do código, compartilha o conhecimento e ajuda a identificar e corrigir erros antes que eles se tornem problemas maiores.

Os profissionais sêniores devem ter uma cultura de Code Review?

Definitivamente. O code review é uma prática essencial em qualquer equipe de desenvolvimento, independentemente do nível de experiência dos membros. Ela promove a qualidade do código, compartilha o conhecimento e ajuda a identificar e corrigir erros antes que eles se tornem problemas maiores.

Os profissionais sêniores, em particular, podem trazer uma riqueza de experiência e perspectiva para o processo de code review, ajudando a orientar os membros menos experientes da equipe e a manter altos padrões de qualidade.

O Code Review é limitado apenas aos profissionais sêniores?

Não, o code review não deve ser limitado apenas aos profissionais sêniores. Todos os membros da equipe, independentemente de seu nível de experiência, devem estar envolvidos no processo de code review. Isso ajuda a garantir que todos entendam o código que está sendo produzido, promove a aprendizagem contínua e a troca de conhecimento, e ajuda a distribuir a propriedade do código por toda a equipe.

Peer Code Review: Uma modalidade essencial

O Peer Code Review, também conhecido como revisão de código entre pares, é uma subcategoria de Code Review onde os membros da equipe revisam o código uns dos outros. Esta é uma prática particularmente eficaz para promover a aprendizagem entre a equipe e para assegurar que todos na equipe estejam cientes das diferentes partes do projeto.

Os profissionais sêniores, em particular, podem trazer uma riqueza de experiência e perspectiva para o processo de Peer Code Review, ajudando a orientar os membros menos experientes da equipe e a manter altos padrões de qualidade.

Conclusão: O Perigo da Falta de Conhecimento Ágil e Prática de Code Review em Profissionais Sêniores

Para concluir, é importante ressaltar que o cenário moderno de desenvolvimento de software exige muito mais do que habilidades técnicas, mesmo para profissionais sêniores. A compreensão e a aplicação de metodologias ágeis e a participação ativa em práticas como code review são essenciais para o sucesso de qualquer projeto.

Profissionais sêniores sem essas habilidades ou que não estão dispostos a adotar essas práticas representam um risco significativo para suas equipes e projetos. Eles podem encontrar dificuldades para se adaptar às mudanças, para colaborar efetivamente com suas equipes e para contribuir para a entrega contínua de valor. Além disso, podem perder oportunidades de compartilhar conhecimento e de aprender com os colegas, o que pode limitar o crescimento e a eficácia da equipe como um todo.

Portanto, é crucial para profissionais sêniores manterem-se atualizados não apenas em relação às tecnologias e práticas técnicas, mas também em relação às metodologias e práticas de trabalho, como Scrum, Kanban e code review. Ao fazer isso, eles não apenas aumentam seu próprio valor como profissionais, mas também contribuem para a saúde, eficácia e sucesso de suas equipes e projetos.