Há anos, equipes de desenvolvimento de software buscam melhorar seu trabalho no dia a dia utilizando abordagens tradicionais da engenharia de software como o modelo cascata, espiral, etc. No geral, essas abordagens dividiam o desenvolvimento de software em várias etapas antes de um projeto ser entregue ao cliente. Nesses modelos, quanto maior o projeto, maiores os riscos de atraso, mudança de escopo, aumento de custo, alto índice de erros, etc.
Os profissionais de TI perceberam que nem sempre os clientes sabiam o que queriam (notava-se isso devido às frequentes mudanças de escopo após o projeto ser entregue), porém, quando recebiam o sistema, conseguiam entender melhor o problema e consequentemente vislumbrar uma melhor solução.
A entrega de software em pequenos lotes começava a fazer sentido, pois era uma forma do programador assumir que os problemas dos clientes seriam resolvidos com entregas frequentes e mais rápidas. Essa técnica gerava ótimos resultados e clientes satisfeitos – nasciam os métodos ágeis.
Em 2001, um grupo de programadores assinaram um manifesto que formalizou o movimento para desenvolvimento ágil de software. Com essa formalização, vários métodos passaram a ser mais conhecidos pela comunidade de TI como o Kanban, XP, Scrum, etc.
O manifesto contém 12 princípios que realçam principalmente: as pessoas e interações mais do que processos e ferramentas, software funcionando mais do que documentação abrangente, colaboração com o cliente mais do que negociação de contratos e respostas às mudanças mais do que seguir um plano.
Embora ainda haja programadores que não aceitem totalmente o uso de métodos ágeis em seu ambiente de trabalho (podemos notar pelos debates nacionais e internacionais em grupos no LinkedIn), não seria difícil negar a grande popularidade e benefícios que esses métodos trouxeram para várias empresas, principalmente aquelas ligadas ao desenvolvimento de software.
Entregar valor mais rápido à próxima etapa do processo e, como consequência, perceber a motivação e satisfação da equipe de programadores, é um dos grandes benefícios que esses métodos podem gerar ao negócio.
O problema
Na maioria das vezes, o uso desses métodos é uma iniciativa dos desenvolvedores, coordenadores e, no máximo, gerentes de TI que buscam melhorar seu trabalho no dia a dia sem o apoio da alta administração. Sem esse apoio, não há garantia de que o desenvolvimento terá integração com as demais áreas da empresa e, com isso, as pequenas entregas nem sempre chegarão rapidamente ao cliente.
Desenvolver um produto sem que a empresa toda (pós-vendas, suporte, helpdesk, infra, etc.) esteja alinhada com a maneira em que as entregas são feitas aos clientes pode
acarretar alguns problemas como: organizações que possuem vários tipos de clientes e, por alguma razão, realizam deployment semanais ou até quinzenais, ou seja, uma
feature no produto que leva apenas uma hora para ser feita, pode realmente ser entregue ao client ...
