en-uspt-br
Escrito em 2023-08-28 Modificado em 2023-08-28

Ciclo de Vida de Projetos - Framework Ágil

Atenção

A maior parte das coisas que escrevi está em formato livre e toda a tradução foi feita diretamente por mim. Claro, eu fiz minha pesquisa e deixei os links com as fontes no texto mas não leve o conteúdo tão a sério: eu não sou um cientista da computação muito menos um pesquisador. Em caso de dúvida, consulte as fontes. Obrigado e que o show continue!

Índice

> Rebobine Antes de Continuar

Em outro artigo eu contei sobre a Gerência de Projetos via Cascata e o quão estrita ela é: Você precisa seguir tudo à risca senão o projeto falha.

Caso não tenha lido, eu recomendo fortemente que o faça antes de continuar, uma vez que uso as ideias desse artigo para explicar minha visão do Framework Ágil.

Como foi demonstrado, a Cascata se importa mais com o resultado e o processo do que com o time. isso significa que ou o time se adapta ao projeto ou o time será alterado. isso pode até funcionar com consultores e outros provedores de serviço, Mas o que acontece quando o time é parte do próprio projeto?

Bom, as coisas podem ficar difíceis: pessoas podem ser demitidas, o projeto pode atrasar, pessoas ficam desmotivadas, etc.

Antes de sugerir melhorias, vamos primeiro listar os problemas da Cascata:

> Mas e Aí, O Que é Ser Ágil?

Ágil é um Framework que te permite aceitar as mudanças assim que chegarem.

Ágil é uma coleção de ferramentas comumente chamada de framework que permite a gestão de um projeto de forma que:

Isso que dizer que as coisas na direita tem seu valor mas devemos preferir as coisas na esquerda. Conhecedores vão identificar corretamente que eu copiei esses dados diretamente do Manifesto Ágil e eu admito mesmo, pois esse é O lugar para aprender sobre Ágil, mesmo que de uma forma mais orientada para Softwareenquanto eu prefiro uma forma mais genérica.

> Os Doze Mandamentos Princípios do Ágil

Mesmo que Ágil seja um Framework de práticas, existem doze princípios que devem sempre ser seguidos. Eles estão listados na forma que aparecem na página do Manifesto Ágil e eu também adicionei exemplos de como usa-los.

Lista de Princípios

>> Organize Suas Prioridades

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.

Ignore a palavra software por um momento e a troque pela palavra itens, para um uso mais genérico.

Esse princípio foca na ideia que não se precisa entregar o produto pronto uma única vez mas sim quebra-lo em diversas partes e entregar uma parte de cada vez.

Dessa forma permite-se que o cliente e o time recebam e processem feedback mais facilmente, uma vez que existe mais disponibilidade para discutir e validar o item entregue.

>> The Wind of Change (O Som da Mudança)

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.

Coisas mudam e sempre mudarão: esse é o princípio no qual a Teoria da Evolução e o Método Científico se baseiam.

É melhor aceitar as mudanças do que lutar contra elas. Imagine que você esteja planejando a construção da sua casa para uma família de 3 pessoase de repente você descobre que terá mais um bebê, você simplesmente abandona o projeto e começa tudo de novo ou você tentaria fazer algumas alterações para seguir com o novo estilo de vida?

É possível argumentar que dependeria de quanto o projeto já progrediu e é até um bom ponto mas eu discordo: Sempre existe espaço para a adaptação e isso leva a um melhor resultado final.

Indo diretamente ao ponto do princípio: Se você for qualquer tipo de empreendedor, você vai dar o seu melhor para lidar com as condições do mercado, mesmo que seja necessário reinventar seu negócio. Não seria isso uma aceitação da mudança?

>> Continue Entregando

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

O Primeiro Princípio deixa claro que devemos entregar itens de forma contínua mas quanto tempo entre as entregas as tornam contínuas?

A resposta dessa pergunta depende unicamente do time bem como do projeto em questão. Quando se fala de software existe uma preferência por ciclos de 2 semanas mas isso não é uma regra estrita.

Voltando ao artigo sobre Cascata e os exemplos de construção civil: se seu time é capaz de terminar a fundação de um andar em duas semanas, essa é sua cadência de entrega, pelo menos nessa fase do projeto.

>> Uma Mente, Muitos Corações

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Na Cascata uma vez que os requisitos são escritos e aprovados, nunca mais são revisados. No Ágil porém, eles são constantemente checados, validados and revisados quantas vezes forem possíveis.

isso garante que o time está trabalhando com o mesmo propósito, sempre alinhado.

>> O Time Faz Toda a Diferença

Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

para que se dê seu melhor, as pessoas precisam se sentir no seu melhor. Ninguém gosta de trabalhar num ambiente onde são apenas mais um, são alvo de piadas ou simplesmente deixadas de lado.

Ágil foca nas pessoas: Seu time é seu maior tesoure, cuide bem deles.

>> Evite E-Mails Que Podem Ser uma Conversa

O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.

Se você tem algo a dizer, diga. Não se comunique via meios que dependem da interpretação do destinatário: isso pode causar mal-entendimentos ou até perda do conteúdo no processo.

Para se manter com o time unido, as pessoas precisam estar abertas e livres. Caso tenha algo pessoal para conversar, sinta-se a vontade de organizar uma conversa privada: a melhor forma de confiar no time é ser aberto.

>> Estamos Chegando?

Software funcionando é a medida primária de progresso.

Não importa quanta burocracia seja feita ou quantas reuniões tiver: o que realmente conta como progresso é a solução do problema.

Será que a obra está em andamento? As pessoas estão construindo, as partes chegaram? É dessa forma que você valida o progresso na construção civil.

>> Mantenha o Ritmo

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

Acredito que esse é bem direto: Se você quer que o time faça o melhor trabalho, o ritmo deve ser constante.

Momentos de alta pressão ou muito lentos matam a produtividade porque o time pode ficar cansado ou distraído, resultando num time desmotivado.

>> Atenção nos Detalhes

Contínua atenção à excelência técnica e bom design aumenta a agilidade.

Assim que aceitamos mudanças, precisamos de um tempo para revisar nosso trabalho anterior. Precisamos cuidar muito bem do design e das técnicas usadas pelo time por podem precisar de pequenos ajustes.

Ajustes nas ferramentas, design e técnicas ao longo do tempo vão permitir que o time performe melhor.

>> Simplicidade é a Alma do Negócio

Simplicidade–a arte de maximizar a quantidade de trabalho não realizado–é essencial.

(Perdeu-se uma piada na tradução, onde falo de KISS, que significa Keep It Simple, Stupid. Em português, traduz-se como Mantenha Isso Simples, Idiota)

O projeto e os requisitos devem ser fáceis de entender e não deve-se complicar o trabalho do time sem necessidade. Se livrar de burocracias desnecessárias é ESSENCIAL para times ágeis obterem sucesso.

>> Melhora Pessoal é Real

As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

Assim como o time vai passando pelo processo ágil, o mesmo tende a se tornar auto-organizado. isso significa que o time é capaz de identificar e corrigir seus defeitos com o tempo, sejam eles técnicos ou organizacionais.

Tal habilidade também faz com que o time tome melhores e mais rápidas decisões, o que aumenta o valor entregue ao longo do tempo.

>> Olhar Para Trás É Fácil

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Para um time auto-organizável existir, o mesmo precisa refletir sobre decisões e eventos passados. Muito fácil de fazer, na verdade: normalmente isso é chamado de Retrospectiva.

Retrospectivas são eventos que devem ocorrer tão regularmente quanto as entregas, para que se possa iterar o último resultado alcançado.

A Retrospectiva deve focar em o que deu certo, o que não deu certo e como o time pode melhorar. Claro que isso não é uma regra e que o time é livre para se adaptar da forma que melhor funcione para o time em si.

> O Que Significa Ser Ágil?

Contrário ao que muitos acreditam, ser ágil não é a mesma coisa que ser rápido. Doido, não?

Pelo menos no contexto de gerência de projetos, ser ágil significa ser capaz de reagir a mudanças o mais rápido possível.

É um ótimo contraste com a Cascata, onde toda e qualquer mudança significaria o término do projeto.

As mudanças a serem tratadas de forma ágil não se limitam apenas a mudanças de projeto mas também a mudanças de time. Isso significa que ágil está pronto para aceitar que indivíduos entre e saiam do time tão bem quanto lida com mudanças de requisitos.

> O Quebra Cabeça do Framework

Como dito anteriormente, ágil é na verdade um framework, mas o que é isso?

Essencialmente, um framework é uma coleção de ferramentas, práticas e processo mas sem estrutura fixa.

Dessa forma é possível combinar essas ferramentas, práticas e processos da forma como preferir, desde que não vá contra os princípios.

isso permite obter uma forma totalmente customizada para o funcionamento do seu time e, por conta da natureza ágil, também permite a flexibilidade de mudar qualquer coisa, a qualquer momento.

Claro que isso também promove alguns desafios: dificilmente dois times trabalharão da mesma forma. Essa quantidade de customizações pode trazer um pouco de confusão na forma como times operam entre si, uma vez que cada um tem sua própria forma de funcionamento.

Ao mesmo tempo, isso é exatamente um dos fortes do ágil: Indivíduos e interações. Já que os times são ágeis, eles deveriam facilmente transformar essa dificuldade em algo útil para os dois times.

> Cadê os Entregáveis?

Na Cascata existem muitos artefatos ou entregáveis, praticamente um por fase. Como ágil lida com isso?

A resposta simples é que não lida. Não existem artefatos no ágil, pelo menos a princípio. Talvez seu time decida que alguns artefatos são necessários mas isso vai depender dos objetivos do projeto.

Ágil foca em entregar valor. Enquanto alguns artefatos podem ser importantes, eles não adicionam valor diretamente ao projeto ou podem até ser caros demais para manter atualizados.

As Regras de negócio são um ótimo exemplo de contraste entre Ágil e Cascata.

Na Cascata, não existe volta depois das Rules estarem definidas e documentadas em uma torre gigante de papel. Se por alguma força cósmica essas regras precisarem de qualquer mudança, a versão atual do documento deve ser destruída e a nova versão deve ser produzida. Não obstante, o time precisa interromper totalmente o trabalho no projeto enquanto essas alterações não se concluem para evitar a chance de retrabalho e correções.

No Ágil as mudanças são coisas constantes na vida, por isso uma atualização das regras não é apenas esperada, é bem-vinda. O time, usando suas ferramentas, práticas e processos vai executar uma forma de documentar e implementar essas mudanças tranquilamente, sem impactos adversos na forma de trabalho.

Em essência, tudo no ágil é decidido pelo time, incluindo o que é um entregável e com lidar com isso.

> O Time Dos Sonhos

Nesse ponto da leitura existe um senso de muita responsabilidade nas mãos do time, mas isso é algo positivo.

Afinal, o time é composto de todos com interesse no projeto, mesmo que não estejam diretamente trabalhando nos entregáveis.

No ágil existe menos foco no seu papel e sim em como fazer o time alcançar o sucesso o que significa que seu cargo não interfere na operação do time, apenas suas ações tem significado.

Imagine um time de futebol e como ele funciona. Existem 11 jogadores em diversas posições com apenas dois objetivos em todas as partidas: marcar gols no time adversário e fazer o melhor para impedir o time adversário de marcar pontos no seu time.

Para melhor organizar o time, o mesmo é disposto em mais ou menos 4 grupos: ataque, meio de campo, defesa e goleiro. Cada grupo respeita os dois objetivos principais mas os defendem de formas diferentes:

Ter papéis é importante para o time pois permite que todos saibam suas responsabilidades durante a partida. Ao mesmo tempo, o papel não limita o jogador a uma posição específica do campo. Não existem regras contra um jogador da defesa marcar um gol, nem uma regra contra um jogador atacante que executa um drible decisivo e impede um gol adversário.

também existem membros do time que não são parte direta da partida. isso inclui o treinador e assistentes, por exemplo. O trabalho deles é garantir que o time chegue na partida em sua melhor condição e até lidam com imprevistos como mudanças de estratégia e substituição de jogadores.

Tudo o que importa é que as pessoas no time tenham os mesmos objetivos. Nesse caso é a vitória da partida, não importa qual sua posição no campo.

> Framework Pré-Fabricado

Ágil é bem tranquilo com a forma como seu time está organizado e como o trabalho é dividido porque o importante é sempre seguir os princípios.

Mas isso significa que você precisa montar o workflow do seu time do zero toda vez?

Claro que não!

Mesmo que ágil seja um framework que não te força a seguir um método específico, existem algumas implementações, digamos, do framework que podem ser usadas diretamente.

As duas mais comuns para mim são: - SCRUM - Kanban

Existem muito mais formas de usar o framework ágil do que apenas essas duas, pense no ágil como uma peça de LEGO.

Esses dois exemplos seguem os princípios ágeis em suas respectivas formas mas eles NÃO são intercambiáveis. Escolha-os com sabedoria antes de começar porque ambos possuem formas distintas de lidar com trabalho e mudanças.

> Abrace a Agilidade

Ágil não significa que você irá entregar mais rápido ou terminar o projeto adiantado,então por que escolher algo que parece tão aleatório quando podemos seguir a estrutura que a Cascata providencia?

De forma simples, ágil permite uma melhor previsibilidade, melhor controle de qualidade e melhor entendimento do projeto.

A habilidade de aceitar mudanças e cuidar das pessoas permite que projetos ágeis se adaptem melhor a diferentes condições, sejam elas de mercado, climáticas e até políticas.

> Falso Ágil

Infelizmente nem tudo cheira a rosas. Por conta da sua natureza como framework, ágil permite que pessoas implementem sua própria versão.

Algumas implementações são muito boas como exemplificado anteriormente. Outras porém, se dizem ágil mas são na verdade cavaleiros do apocalipse.

Tenha certeza que realmente compreende e aceita os princípios ágeis antes de escolher ou criar sua versão ágil caso contrário seu projeto está fadado ao fracasso.

Alguns exemplos de métodos anti-ágil incluem mas não estão restritos a:

> O Fim da Corrida

Vamos concluir nossa aventura ágil. Espero que a essa altura você tenha um bom entendimento do que é ágil, como usa-lo e como torna-lo melhor.

Como toda ferramenta no universo, seu poder vem da forma como é usada e não da ferramenta em si. Não precisa excluir a Cascata da sua vida, talvez ela possa ser uma ferramenta poderosa em outros cenários mas eu pessoalmente acredito que devemos pensar sempre em ágil primeiro.

Como sempre: em caso de dúvidas ou comentários, mande um e-mail ou uma mensagem no Telegram, os links estão no topo da página.

Até logo.

análisecascataentregaestruturafeedbackferramentaframeworkiteraçãomanifestonavigationpessoasproblemaprojetoprojetoresultadostatementtimetrabalhoágil