Para ser bem honesto, eu não queria escrever sobre os Mitos sobre Métodos Ágeis. Na verdade, eu apenas comecei a listar quais seriam os possíveis mitos e quando cheguei ao número 11 tomei um susto! Porque, afinal de contas como ainda podem existir tantos mitos?
Mitos sobre Métodos Ágeis, a motivação!
Já faz algum tempo que trabalho com projetos ágeis, e é normal alguma questão sempre voltar a tona, várias e várias vezes. Nessas horas, para desmistificar essas questões é preciso tempo e as vezes até muita paciência.
O fato é que, isso acabou me motivando a escrever sobre cada um desses mitos sobre métodos ágeis. E posso afirmar, eles não existem, mas ainda temos muitos mitomaníacos que querem, cada vez mais, acreditar neles.
Sem mais explicações e enrolações vamos ao nosso TOP 17 Mitos Sobre Métodos Ágeis:
01. Agilidade é novidade (ou coisa nova)
Novidade? Na verdade o manifesto ágil foi publicado em 2001, lá se vão mais de 15 anos. Mesmo sendo publicado em 2001, os Métodos Ágeis no Brasil, chegaram com mais força por volta de 2004 a 2007.
Se quisermos ir mais a fundo (como fui em minhas pesquisas), chegaremos ao conceito da Adocracia, que foi citado pela primeira vez por Warren Bennis em seu livro The Temporary Society em 1968, e definido por Alvin Toffler da seguinte forma:
A adocracia é um sistema temporário variável e adaptativo, organizado em torno de problemas a serem resolvidos por grupo de pessoas com habilidade e profissões diversas e complementares. Constitui-se em uma opção à tradicional Departamentalização.
Alguma semelhança? Sistema variável, adaptativo e organizado para resolver problemas? Isso é muito próximo aos conceitos que a agilidade prega.
Logo, podemos concluir que os conceitos ágeis já existiam e eram praticados a pelo menos 49 anos, ou seja, não é algo tão novo assim.
02. Métodos Ágeis significa não ter que criar documentação
Muitas pessoas acreditam que ao adotar os métodos ágeis, que não terão mais que produzir documentação. E isso é dificilmente é a verdade, você pode acabar sendo obrigado a criar o tanto de documentação, quando linhas de código.
Mas a prática é diferente de uma abordagem waterfall, onde é necessário criar toda a documentação antes de qualquer linha de código, já nos métodos ágeis a documentação vai surgir juntamente as entregas de software funcionando. Afinal de contas ela também é um entregável.
Para quebrar o mito de vez, documentar o que você faz é necessário. Mas, se deve documentar somente o que agregue valor ao produto entregue em cada ciclo de desenvolvimento, evitando o desperdício.
03. Ser ágil é não ter que se preocupar com o design
Não. Totalmente pelo contrário, se você adotou os métodos ágeis você também deve abraçar o design e seus princípios de experimentação, adaptação e evolução. Design deve estar envolvido em tudo, nas plannings e muito mais, como auxiliando a direcionar para o objetivo do produto e/ou projeto.
Devemos abraçar os princípios do design emergente que aparece mais claramente na refatoração de código, onde o desenvolvedor melhoram o design do seu código. Design é algo onipresente nos métodos ágeis e não apenas uma fase inicial de projeto.
04. Métodos Ágeis tem pouco planejamento
Se existe uma verdade é que, visitar o planejamento nos métodos ágeis é algo que acontece naturalmente a todo momento.
Nos métodos ágeis você tem o plano de todo o projeto, que deve ser visitado ao final de cada iteração refletindo nele os progressos realizados, ainda temos o planejamento da iteração, onde se tem um plano detalhado do que vai ser desenvolvido e temos o planejamento diário que acontece na Daily.
Assim podemos afirmar planejar é algo natural e constante no cotidiano de todos os envolvidos no projeto.
[epico_capture_sc id=”348″]
05. Tamanho e/ou padrão certo de User Story
Não existe o mesmo modelo de User Story para todos os times. Cada time tem o seu e ainda podendo variar dentro do que julgarem necessário.
Existe uma boa prática que diz que, uma boa User Story deve durar no máximo de 2 a 3 dias de desenvolvimento. Eu gosto dessa abordagem e acredito que ela ainda
deve conseguir ser independente, testável e entregável.
O tamanho da estoria vai variar de acordo com o conhecimento e experiência do time de desenvolvimento no projeto, podendo as vezes ser necessário se ter mais detalhes descritos e as vezes menos.
Claro, que o conhecimento e experiência também vão influenciar no tempo de desenvolvimento.
06. Tudo deve caber dentro do Sprint
Existe uma grande mentira que é: as estorias não devem ser quebradas.A consequência desse mito é de ter um Sprint Backlog inchado e que possivelmente o time não irá conseguir cumprir, por mais que assuma o compromisso da entrega.
Quebrar User Stories que são maiores que uma Sprint, não deveria traumático, mas também
não deve ser a regra, onde toda estoria é maior que seu ciclo de desenvolvimento.
Uma excelente prática é quebrar ordenadas por negócio as grandes estórias, garantido sempre um entregável funcionando.
Quando MENOR a estoria melhor para seu time, para seu fluxo produtivo e para suas entregas. Porém, as vezes irão surgir as exceções e nesses casos não tenha medo de quebrar e seja feliz.
07. Desenvolvedores fazem o que querem
Se você está fazendo isso então, a má noticia é que você está fazendo isso errado.
Desenvolvedores não fazem o que querem e sim seguem algo estipulado pelo cliente e/ou Product Owner. Logo, se seu time está fazendo o que quer ou o que acham melhor, você está com uma enorme chance de entregar algo que seu cliente não precisa.
Equipes ágeis são equipes bem disciplinadas e focadas no que o cliente e PO direcionam para atingir o maior valor de negócio possível.
08. Scrum e Kanban são inimigos!
Nãooooo! Por mais que ainda exista algumas afirmações como: “Ou você utiliza Scrum, ou utiliza Kanban”. Scrum e Kanban estão longe de serem inimigos, até mesmo por
compartilharem da mesma base de valores.
Obviamente, existem diferenças, um é mais flexível que o outro, mas no fundo eles podem se ajudar muito!
Por exemplo, um bom Kanban pode amplificar a transparência dentro do Scrum e promover a melhoria continua do seu fluxo produtivo.
Existem livros que definem ScrumBan como mais uma metodologia, como o do Corey Ladas.
09. Método Ágil não funciona com deadlines
Posso afirmar, Métodos Ágeis funcionam melhor COM deadlines.
Quando temos deadlines bem definidos, vai ser natural um empoderamento do time, que vai trazer maior motivação e engajamento. Outro ganho é a eliminação do desperdício, com deadline definido e conhecido, só será desenvolvido o necessário.
É o que chamo de fim da “floricultura“.
10. Agilidade não funciona em sistemas legados e caóticos!
Só por ser um legado e caótico é normal assumirmos que nada irá funcionar. O que vemos acontecer é esse mito se tornar verdade e estratégias serem traçadas com outras abordagens, mais engessadas e rígidas, justamente por ser um legado desconhecido.
Mas uma abordagem ágil vai fazer milagre nesse tipo de ambiente. Podemos até afirmar que, os Métodos Ágeis nasceram para controlar o caos, e quando empoderamos as pessoas e deixamos o conhecimento no legado imergir conforme a jornada é realizada, os resultados passam a ser incríveis.
Por experiência própria, já vivenciei mudanças que posso chamar de heroicas em sistemas legados que estavam fadados ao fracasso. Tudo em consequência a abordagem ágil, que vai fazer seu time ganhar muito conhecimento e realmente ser capaz de “domar” esse legado.
11. Vamos esperar o momento certo
“Gostamos da ideia de sermos ágeis, mas vamos esperar o projeto certo”
Não existe de um projeto “certo” para começar, você pode criar inúmeras desculpas ou até encontrar um bom motivo para não mudar. Minha opinião é que você deve fazer isso quando achar que é o momento e não quando encontrar o seu projeto perfeito para tal.
Normalmente, o melhor momento é quando se busca fazer mais e melhor do que está acostumado a fazer. Com certeza os Métodos Ágeis vão te dar muita flexibilidade e agilidade no tempo de resposta.
12. É necessário todos no mesmo local físico
Métodos Ágeis enfatiza o forte envolvimento de todos os envolvidos em um projeto. Como isso esse mito vem a tona e as começam a associar que as pessoas devem estar no mesmo local físico, para que se tenha sucesso no projeto.
Comunicação é historicamente um desafio em projetos e até com todos no mesmo lugar, não é assertiva. Mas esse problema é mais presente por um histórico de “cada um por si” do que pela habilidade de comunicação das pessoas.
E cada vez mais normal os times estarem espalhados e conectados através de hangout, skype e etc. Que é comunicação em tempo real, percebam que não importa mais onde ela ocorre e sim QUANDO.
13. Só funciona em projetos pequenos
Como os times ágeis normalmente são pequenos, o que se costuma a associar é que por esse motivo métodos ágeis só funcionam para projetos pequenos. O que é um mito que absurdo! O que existe de projetos ágeis com 100, 200 e até 500 pessoas é normal.
Na agilidade o lema em grandes projetos deve ser: Dividir para conquistar, organizar os times por funcionalidade ou temas de negócio e criar times focados na evolução da arquitetura irão diminuir a dependência e redundância.
Utilizar Scrum of Scrums, Nexus, SAFe ou qualquer outro processo de escala de agilidade vai ajudar a organizar muito bem as coisas.
[epico_capture_sc id=”348″]
14. Usando métodos ágeis, não sabemos quando vai estar pronto
O modelo tradicional temos todo o planejamento detalhado antes da primeira linha de código escrita. Embora seja comodo e até de certa maneira útil ter todo os detalhes conhecidos.
Qualquer mudança de plano no decorrer do desenvolvimento vai acabar custando muito mais caro.
A abordagem ágil é menos detalhada e se tem um planejamento macro, baseado ainda em incertezas que serão removidas por verdades absolutas ao longo do desenvolvimento. No modelo ágil, os detalhes do plano são refinados de acordo com o progresso realizado do projeto.
Logo, dessa abordagem fornece a todos os envolvidos um melhor entendimento do que se espera receber no curto prazo(como por exemplo uma entrega de uma ou duas sprints) e uma visão cada vez mais clara, porém ainda macro, do longo prazo.
15. Métodos Ágeis são menos estruturados e disciplinados do que Waterfall
Ser ágil é ser disciplinado e estruturado. Os frameworks mais utilizados são talvez os mais prescritivos.
As implementações de métodos ágeis mais bem sucedidas são aquelas orientas a processos e coordenadas mais do que o waterfall. Desde da gestão do escopo até a gestão do projeto.
Métodos Ágeis exigem muita disciplina, porque o escopo é gerenciado a todo momento, desde do começo até a entrega em produção. Onde as partes interessadas revisam o progresso em intervalos definidos e fornecendo feedback a cada passo da jornada.
16. Método Ágil = Scrum
Scrum é sem dúvida nenhuma o “processo” ágil mais difundido e utilizado no mundo, e isso pelo seus próprios méritos, em conseguir se encaixar muito bem em ambientes complexos.
Métodos Ágeis não se resumem somentoe ao Scrum, existem várias outras abordagens como Kanban, XP, Agile UP e etc.
O que deve se avaliar é qual o melhor para o seu contexto de trabalho e tentar adotar o que melhor se encaixa. Minha experiência diz que devemos começar com um processo “by the book” e ir adaptando e criando o seu próprio modelo hibrido de agilidade.
17. É a cura para todos os seus problemas
Agilidade traz um alinhamento das partes interessadas, te ajuda a identificar problemas mais cedo, reduz o tempo de entrada em produção, ou seja, são muitas vantagens em relação a outras abordagens.
Assim, algumas pessoas começam a acreditar que os métodos ágeis funcionam em qualquer situação, o que é falso. Existem muitos motivos para projetos falharem e talvez o principal dele é a execução errada do modelo de desenvolvimento.
Existem situações onde os métodos ágeis não irão funcionar, como por exemplo em projetos que não se conseguem quebrar as funcionalidades em pequenos itens de trabalho, ou em projetos não existe o envolvimento do cliente.
Avaliar o seu contexto é importante no momento de adotar alguma metodologia e entender a diferença entre problemas que você consegue resolver e o que é a sua realidade imutável.
Mitos sobre Métodos Ágeis existem para serem quebrados!
Eu nem imaginava que conseguiria ainda ouvir tantos mitos sobre os métodos ágeis, mas o lado positivo é que conseguimos “quebrar” cada um deles.
Você consegue enumerar mais algum mito? Deixe seu comentário falando qual o mito que você mais convive.
Já curtiu nossa página no Facebook? Curta agora, lá temos muito conteúdo que não temos aqui.
[epico_capture_sc id=”348″]
Fonte de pesquisa: https://www.agileconnection.com/article/top-twelve-myths-agile-development