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 " [...] continue lendo...
