Back to basis!
A categoria “Caderno Ágil” foi criada para que possamos discutir alguns conceitos ou princípios básicos das metodologias ágeis. Precisou de um help conceitual? Procure nos posts desta categoria! Você também pode sugerir temas para abordarmos! Participe! Espero que aprecie a leitura…
O Scrum é um framework de desenvolvimento de softwares iterativo e incremental, que define uma estratégia de desenvolvimento flexível, onde um time trabalha como uma unidade em direção a um objetivo comum.
Um processo é uma ação que expressa continuidade na realização de determinada atividade, um ato prolongado e contínuo, um seguimento. Ou seja, metodologias classificadas como um “modelo de processo” são aquelas que são (geralmente) extremamente prescritivas, definindo ações e documentações que devem ser seguidas à risca.
Diferentemente de outras metodologias de mercado, o Scrum é um framework e não um modelo. Um framework é “um conjunto de conceitos usado para resolver um problema de um domínio específico”. Isso significa dizer que o Scrum por si só não é executável: ele apenas reune um conjunto de práticas recomendadas para o desenvolvimento ágil de softwares.
Quer dizer que “ser ágil” é igual a “não ter processos“?
Definitivamente, não! Toda e qualquer unidade precisa de um mínimo de procedimentos para entregar algum valor a quem quer que seja. O Scrum deixa esta parte para o time de desenvolvimento, que discute e define qual a melhor dinâmica para aquele sistema em específico.
Totalmente voltado ao Manifesto Ágil, o Scrum sugere que os projetos sejam divididos em iterações menores, chamadas de Sprints, onde, ao final de cada uma delas, seja entregue um software perfeitamente funcional. Tudo isso de forma incremental, ou seja, novas características vão sendo adicionadas ao produto e características anteriormente implementadas podem ser revistas e até mesmo completamente redesenhadas.
A “lista de desejos” do cliente é armazenada no que se chama de Product Backlog e deverá ser priorizada (pelo cliente) com base no valor agregado ao negócio. É através desta priorização que o time de desenvolvimento garante que, ao final da iteração será entregue um software perfeitamente funcional. Em outras metodologias a priorização é feita pelo time de desenvolvimento, em cascata com relação à dependência de funções. Desta forma, tais metodologias só conseguem um software que agregue valor ao negócio do cliente quando uma grande iteração, com diversas funcionalidades satélites, é concluída. Em alguns projetos, somente quando o mesmo é inteiramente concluído.
Então o Scrum e as metodologias ágeis desenvolvem software em menos tempo, ou seja, “ser ágil” é “ser mais rápido”?
Sim e não, ao mesmo tempo! Se você olhar para o projeto inteiro, ser ágil não é ser rápido. Mas, se você considerar que o Scrum está aberto a adaptações e mudanças de planos, aliado ao fato de que cada iteração entrega software potencialmente funcional, o cliente pode iniciar a utilização do produto em menos tempo, diminuindo o tempo do retorno do investimento. Além disso, é possível “sentir” a receptividade do produto e pode direcionar os esforços para o que é mais importante para a estratégia de negócio. Inclusive terminando o projeto antes do tempo determinado, se as necessidades forem todas atendidas.
Mas qual é a mágica? Como conseguir entregar um software em funcionamento em iterações menores e alinhado com o valor agregado ao negócio? Simples! Com uma boa dose de colaboração por parte do cliente. Este é, talvez, um dos maiores desafios do Scrum, visto que, muitas vezes, o cliente tem uma dinâmica própria e completamente diferente do fornecedor de software. Ou seja, geralmente o cliente não tem tempo de se dedicar ao projeto! Entendendo e se comprometendo com este ponto, facilmente a dinâmica do time prova que este “investimento” traz um retorno extremamente satisfatório para o projeto.
No próximo “Caderno Ágil” vou começar a falar mais detalhadamente de cada uma das fases do Scrum.
Até lá!
Agile Momentum 