Acho importante começar dando uma definição rápida sobre o que é agilidade quando aplicada no contexto de desenvolvimento de software.
A origem do termo ágil é mais ou menos uma resposta aos modelos convencionais de desenvolvimento de software existentes nos anos 90, sendo um dos mais conhecidos o chamado método cascata.
O modelo cascata resumidamente falando tem um fluxo linear bem burocrático com vários passos definidos em que ao cumprir cada passo o projeto sempre segue em frente. O problema desse método é que se demorava muito em cada etapa e o escopo era fechado demais para responder às mudanças necessárias para o avanço do projeto. Mas vou deixar pra falar mais desse método em outro post.
A principal razão para motivar mudanças no modelo de desenvolvimento era economizar recursos, e o recursos mais caro que existe é tempo. Tempo esse que passa para todos, das pessoas desenvolvedoras até as grandes negociações entre corporações e startups. O ponto é que: para economizar tempo era necessário flexibilizar o fluxo de trabalho e de certa forma priorizar os principais pontos no desenvolvimento de software. Vamos relembrar os pilares do Manifesto Ágil:
- Indivíduos e interações mais que processos e ferramentas
- Software em funcionamento mais que documentação abrangente
- Colaboração com o cliente mais que negociação de contratos
- Responder a mudanças mais que seguir um plano
A partir da origem dessa ideologia da agilidade, é possível que ambos os lados (desenvolvimento e cliente) consigam validar mais rapidamente o projeto em questão.
Para isso, era necessário ter uma forma de dividir o projeto em pequenas partes, priorizadas por ordem de maior valor para serem desenvolvidas primeiro.
Com isso, nasceram alguns frameworks como XP, Kanban e SCRUM que auxiliam nessa divisão, mas esses merecem ter um post para cada.
Acontece que a transformação ágil, se dá a partir do momento em que equipes de desenvolvimento encaram a ideia de mudar a forma de trabalho na tentativa de melhorar o dia a dia enquanto num projeto. Essa tarefa não é fácil por várias questões, tanto por seguimento da empresa, tipo de projeto, tipo de cliente, cultura do time/empresa, pontos delicados que merecem um outro post especial.
Importante salientar que essa mudança nunca, nunca em hipótese alguma, acontece da noite pro dia, é um processo lento que exige adaptação constante, assim como observação e colaboração de todas as pessoas envolvidas visando melhorias constantes no fluxo de trabalho até que se alcance uma boa estabilidade.
Em posts futuros pretendo trazer assuntos como maturidade de time, organização, frameworks, ícones do desenvolvimento e agilidade e outros.
Top comments (0)