A metodologia Agile é um abordagem de desenvolvimento de software centrada nas necessidades do cliente. Seu foco é atender bem, usando como pilares fases curtas e dinâmicas de desenvolvimento e, principalmente, a flexibilidade para lidar com mudanças no projeto.
Não é de hoje que as demandas de desenvolvedores vêm aumentando, empresas de software buscam atender melhor as necessidades de seus clientes, implicando em alterações constantes no rumo de seus projetos.
Nesse contexto, a manutenção de modelos de desenvolvimento mais rígidos, como o tão disseminado Waterfall fica ameaçada por modelos inovadores e mais flexíveis.
De repente, palavras como “agile”, “scrum” e “kanban” se tornaram constantes no ambiente empresarial e o desenvolvedor se encontra muitas vezes perdido nas definições.
Desde o início, pela própria característica de startup, buscamos testar algumas dessas práticas na equipe de desenvolvimento da GeekHunter.
Você confere nossas opiniões, as principais diferenças e vantagens de cada uma neste artigo. Vamos? 🙂
O nascimento do Manifesto Ágil
Em fevereiro de 2001, Utah, EUA, nasceu a metodologia Agile.
Na época, os Lightweinght Methods — métodos leves — e o XP eram os métodos de desenvolvimento que mais cresciam.
Esse fato desencadeou um debate entre membros dos Extreme Programming sobre as contraposições dos Lightweinght Methods e XP.
Os mesmos membros do Extreme Programming entraram em alguns consensos, concluindo-se que os métodos leves não eram mais uma opção e que era preciso um novo formato. É o início do que conhecemos como Agile.
O Manifesto Ágil fez uma revolução, documentando e cravando na indústria de software os princípios e valores do ágil.
Metodologia Agile: foco no cliente e otimização de recursos
Desde o lançamento do Agile Manifesto em 2001 o desenvolvimento ágil vem ganhando mais e mais adeptos, seja em startups ou empresas tradicionais.
O mantra é simples: desenvolvimento incremental com foco no cliente facilita a coordenação e otimiza recursos.
O Agile bebe da filosofia de que um software que funciona vale mais para o seu sucesso do que uma pilha de documentos muito bem escritos.
Prever todas as necessidades logo no início de um projeto de grande porte não é uma tarefa fácil e qualquer alteração na etapa de desenvolvimento implica em um custo bem alto em modelos não incrementais.
Com isso em mente, faz todo o sentido encurtar o pipeline e realizar tarefas em paralelo, performando ciclos completos de planejamento, desenvolvimento e testes a cada funcionalidade (ou User Story).
Na prática, isso significa menos burocracia e a capacidade de mudar os planos sem muitos problemas.
Além da vantagem de lançar mais e mais cedo, também sentimos que atribuir prioridades acaba sendo mais simples, a equipe tem mais interação e fica mais motivada.
Independente do framework utilizado, os princípios do Agile incentivam os profissionais a criarem juntos um fluxo ideal para atualizações contínuas, com alta capacidade de se adaptar a mudanças de mercado.
Não se trata simplesmente de um método de desenvolvimento, mas sim de uma cultura operacional que torna o ambiente de trabalho mais rápido e mais eficaz.
Mas é importante ter em mente que Agile não é uma bala de prata para resolução de todos os problemas, e pode haver uma certa resistência durante a transição de um modelo incremental.
Nesse caso, guias online e diretrizes como o Agile in a Nutshell podem ajudar a decidir se vale a pena passar por esse processo.
Em resumo:
- Valoriza Indivíduos e interações perante processos e ferramentas;
- Documentação mais enxuta, aliada ao desenvolvimento em todas as etapas;
- Colaboração e integração com os usuários, requisitos incrementais;
- Capacidade de revisitar os planos e mudar de direção sem grandes transtornos;
Qual será a média do salário de programador? Se você não sabe, não tem problema: é só conferir o artigo!
Scrum: metodologia agile sob um novo olhar
Dentro do guarda-chuva do desenvolvimento ágil surgiram diversas soluções que implementam os conceitos de iterações contínuas nos projetos de software.
O Scrum não é em si uma metodologia de desenvolvimento, mas um framework no qual pessoas buscam dividir e priorizar o backlog em problemas menos complexos para entregar produtos com um alto valor agregado (com grande fit com o cliente) e em prazos reduzidos.
No final, cada empresa tem a liberdade de adaptar as diretrizes para a sua realidade, mas o processo define papéis profissionais bastante distintos: Product Owner, responsável por priorizar o desenvolvimento e garantir o entendimento das necessidades dos clientes;
Scrum Master, que age como um facilitador para a equipe para fazer melhorias no próprio processo.
A Equipe Scrum, geralmente de até 9 desenvolvedores que se auto-organizam para atender as expectativas do Product Owner da maneira mais otimizada, conforme as habilidades de cada um.
O trabalho do time de desenvolvimento passa por etapas:
- Adição dos padrões do projeto ao Product Backlog;
- Reuniões de planejamento para a seleção e divisão das atividades prioritárias em sprints;
- Utilização do Sprint Backlog para rastrear o progresso das tarefas, a aderência ao Daily Scrum e a realização de ajustes.
Ao final de cada Sprint, os profissionais terão um Product Increment (um conjunto de modificações que podem ser adicionadas imediatamente ao software).
Elas serão apresentadas ao Product Owner durante a Sprint Review. Nessa reunião, modificações são realizadas ou aprovadas.
No final do projeto, na Sprint Retrospective, todas as atividades são revisadas, sendo avaliados os pontos que necessitam de melhorias e os que podem ser replicados em projetos futuros.
A adoção completa do Scrum envolve a compreensão de seus princípios.
A equipe precisa internalizar os papéis e estar ciente das responsabilidades, não deixando passar nenhum meeting por falta de tempo. Uma vez passado o desconforto inicial, projetos complexos serão executados mais rapidamente e com um maior índice de sucesso.
A comunidade de Desenvolvimento Ágil Brasil tem as guidelines que você precisa para começar a gerenciar seus projetos seguindo o framework. Vale a pena conferir.
Kanban: A experiência do oriente
Muita gente não sabe, mas o Kanban é mais que uma prática para desenvolvimento de software.
O método ganhou bastante notoriedade por suas origens estarem ligadas à Toyota, uma das maiores fabricantes de automóveis do mundo.
Em TI, no entanto, costuma-se focar em um aspecto fundamental para organização e gerenciamento do processo incremental de desenvolvimento de software, o Kanban Board.
O “quadro” é bastante simples e funcional, em uma tabela organizam-se todas as etapas do desenvolvimento, dispostas em colunas, da concepção à etapa de testes e release.
São feitas distinções de atividades a fazer, em desenvolvimento, já entregues, bem como estipuladas prioridades, refletidas na disposição das linhas de determinada coluna (geralmente tarefas mais acima recebem maior prioridade).
O próprio time de desenvolvedores se encarrega de puxar para si os cards de atividades (User Stories) assim que possível, de acordo com o perfil e o prazo de cada feature, e como todos têm acesso compartilhado, fica mais fácil ter uma visão holística de quem está fazendo o quê e quais atividades ainda precisam ser atacadas.
Algumas ferramentas permitem fazer quadros online e tirar proveito das métricas para planejamento.
Na GeekHunter, é uma ferramenta que tem funcionado bastante e não apenas para a equipe de desenvolvimento, pois permite manter mesmo ideias ou feedbacks que frequentemente ficavam perdidos nas conversas e discussões, ainda que com baixas prioridades.
Métricas de TI: Como um gestor deve utilizá-las?
Metodologia Agile, Scrum ou Kanban, afinal?
O melhor de tudo é que é possível combinar o melhor de cada método e criar um sistema que funcione em harmonia com as necessidades dos desenvolvedores e dos gerentes de projeto. A nossa experiência tende a indicar métodos ágeis para equipes pequenas e de alto desempenho, especialmente em projetos mais propensos a mudanças.
No final, a metodologia em si ou políticas empresariais não terão nenhum impacto se não forem vivenciadas dia a dia pela equipe de profissionais, e é importante notar que todo processo de mudança passa por períodos de adaptação.
Melhor do que instalar do dia para a noite um novo paradigma é ir introduzindo mudanças aos poucos, em acordo mútuo e tendo como única finalidade melhorar o desempenho e a interação entre a equipe, nunca para “processualizar” ou seguir a moda.
O melhor método é sempre aquele que se adéqua às suas necessidades e resolve seus problemas.
E é claro, existem várias outras técnicas como Test Driven Development, Extreme Programming que também podem e devem ser utilizadas, mas merecem um post só pra elas.
E como a sua equipe se relaciona? Já testou modelos híbridos com bons resultados? Existe um método de trabalho que o motiva mais? É hora de testar!
Como um desenvolvedor pode se tornar um Gestor de TI
