Que a construção de software não é um processo convencional até o mais novato desenvolvedor sabe, porém a complexidade dessa tarefa é elevada a um nível diferente quando se envolve dois ou mais desenvolvedores em um time. Surge a necessidade de um método que ajude ao time a desenvolver de maneira coordenada e sempre entregar resultados.
Nos primórdios do desenvolvimento, tínhamos o método Waterfall (em cascata), que era baseado no desenvolvimento fordista (sim, dos carros) de construção de produto. O método consistia em seguir um único ciclo de desenvolvimento, do começo ao fim do produto. Um escopo fechado de funcionalidades e ações que o software iria realizar sendo desenvolvidos em um longo espaço de tempo.
Na época, o desenvolvimento de software era equiparado a uma construção de engenharia, como uma construção civil ou mecânica. Porém a natureza do software é dinâmica, mutável e previsível a falha (se é possível falhar, irá falhar.Lei de Murphy), esse método de desenvolvimento em equipe foi péssimo em rendimento, falhando tanto em orçamento quanto em estimativa de tempo para a entrega.
Os níveis de falha foram agressivos, em 1994 uma empresa consultoria Standish Group deixou público um estudo que ficou comumente conhecido como CHAOS Report, no artigo mostrava dados de 20 anos de desenvolvimento pelo modelo waterfall mostrando claramente que havia falhas e modificações em grande parte dos projetos finalizados (quem imaginaria?)
Fato interessante: essa mesma consultoria continuou realizando o CHAOS Report nos anos consecutivos. Demonstrando o avanço de métodos de gerenciamento de software durante os anos.
Diante dessa merda generalizada, um grupo de dinossauros... digo, profissionais de TI experientes juntaram-se e levantaram a ideia de uma metodologia que mais se encaixaria com a atividade de construção de software. Nasce dessa lombra o Movimento ágil. Desse momento em diante, o rumo da fabricação de software mudou completamente. O manifesto que esses caras criaram nada mais é que um conjuntinho de ideias do que é a construção de um software real e como se deve seguir.
Pode parecer coisas obvieis hoje, mas há 23 anos atrás, projetos de software eram descartados pelo risco de sempre falharem e um dos motivos era tentar encaixar o software como um desenvolvimento padrão de qualquer engenharia.
A metodologia ágil é um conjunto genérico de dicas, tipo "beba mais água para melhorar a saúde", porém são características genéricas dos métodos mais famosos de desenvolvimento ágil. Extremming Programming, Scrum e Kanbam. Falarei um pouco mais nos próximos dias.
Bom, esse foi um resumo do meu estudo no desafio de 100 dias de código. Eu estudei pelo livro Engenharia de software moderna do Professor Marco Tulio Valente. É um ótimo livro introdutório para assuntos corriqueiros no dia-a-dia de desenvolvimento de software.
[1/100] dias de código
Top comments (3)
Uma coisa que me incomoda um pouco é que às vezes o ágil é colocado como superior ao cascata. E isso não é sempre verdade. Um problema bastante comum de ocorrer na metodologia ágil são os gestores usar isso como desculpa para não documentar o software, ou poderem mudar os requisites toda hora como se isso não fosse afetar o desempenho do time ou fosse exatamente o mesmo esforço que desenvolver assim do zero (já que os desenvolvedores devem abraçar as mudanças, serem amigos delas e não inimigos). Isso pode gerar um monte de software com bases toda remendada, funcionalidades abandonadas pela metade, ou que nem fazem sentido estarem no componente do sistema que estão depois de tudo que passou. Além de um possível time desmotivado por toda hora refazer as mesmas tarefas, sem visibilidade dos próximos passos, já que não se sabe onde o sistema deveria chegar.
Também existe o clássico: "usamos scrum, mas...", onde o time parece usar scrum, mas sempre tem algum ponto que não é seguido. Como isso se repete bastante, surge a pergunta se realmente é possível implementar scrum, e se sim, em que casos que é possível ou não.
Uma possível visão do ágil é que ele deveria ser na verdade várias cascatas em sequência, em vez de uma cascata só, porém em favor da "agilidade" se pula vários passos de definição, o que normalmente resulta em tarefas sem estar claro o que deveria ser feito ("depois documentamos [definimos] como deve funcionar, mas você já pode ir fazendo"). Esse comportamento pode levar a abstrações ou ideias que inicialmente faziam sentido, mas que com as mudanças que ocorreram, agora só atrapalham a manutenção e sustentação.
No final dizem que ágil é bom para os gestores, mas ruim para os desenvolvedores. O que tem sua parcela de verdade.
Também lembrei desse vídeo que discute um pouco o assunto:
O método é somente um guia de desenvolvimento, não uma religião. Cada produto deve ser definido e gerenciado a partir das suas peculiaridades. se o produto possui uma flexibilidade maior que aceite a não documentação, porque não? A ideia do movimento agile é melhorar o dia-a-dia dentro do desenvolvimento, não somente aplicar um método dentro das metodologias. Por exemplo um projeto pode transitar entre faixas de desenvolvimento e de manutenção onde na faixa de desenvolvimento, haja a necessidade de utilizar um XP ou Scrum e na faixa de manutenção fique de boas com um Kanbamzinho. Vai depender sempre das peculiaridades do projeto e principalmente do cliente. Enquanto a pesquisa, eu acho que se você tem um grupo de dados tendenciosos, o resultado da análise vai ser tendencioso. Não houve tratamento de dados, amostragem real e sempre é um modelo que a consultoria vende curso. Sou crítica do Scrum, Kanbam e XP, sou crítica de qualquer metodologia que não atenda a equipe mas não creio que o Waterfall seja a saída. Precisamos evoluir, pesquisar gerenciamento, adequar a realidade da década e não retroceder 20 e tantos anos em um modelo de construção de casas.
Concordo. Só destaco que, embora agile tenha sido pensado para melhorar o dia-a-dia, em certos casos ele pode piorar dependendo da maturidade das pessoas envolvidas (tanto desenvolvedores quanto gestores) e da natureza do projeto. Porém, sobre o cascata discordo, pois estou atuando em um projeto de escopo fechado (relativamente pequeno) e com prazo determinado (não muito longo) que foi terceirizado, então o cascata traz garantias tanto para o meu time, quanto para o cliente do que realmente será entregue e com uma visibilidade muito boa do andamento do projeto, e assim não temos surpresas de surgir um requisito que mude muito o que já foi feito, porém não tínhamos visibilidade disso já que foi deixado para sprints posteriores, por exemplo. Isso ainda servido como base para argumentação legal caso não haja comprimento de prazos ou argumentação de que o software não atende as necessidades ou está incompleto.
E como você comentou da pós, o contraditório pode ser interessante. Pelo menos no meu mestrado, ele era incentivado pelos professores.