Contente
- Por que TI ágil?
- Como a metodologia ágil lida com os problemas do modelo em cascata?
- Como o Agile impactou o setor de TI?
- Sem erros, sem estresse - seu guia passo a passo para criar software que muda vidas sem destruir sua vida
- Razões pela qual a BT mudou para práticas ágeis
- Má gestão de requisitos
- Projeto de software ruim
- Restrições de desenvolvimento
- O que a BT fez para solucionar os problemas acima?
- Conclusão
Fonte: Darkovujic / Dreamstime.com
Leve embora:
Para muitos, o modelo em cascata de desenvolvimento de software é o padrão há décadas, mas agora está sendo substituído pela metodologia Agile, muito mais flexível.
A metodologia Agile para desenvolvimento de software pode impactar positivamente o setor de TI. Os resultados da adoção da metodologia Agile podem ser medidos de várias maneiras. O retorno mais rápido das solicitações de mudança de software, menos bugs, medição quantitativa do desempenho da equipe e gargalos são todos reflexos de uma implementação bem-sucedida do Agile. Para medir com sucesso o impacto do Agile, uma organização precisa comparar várias métricas relacionadas ao desenvolvimento pré-Agile e pós-Agile. O impacto real do Agile não pode ser medido apenas pelo aumento da receita ou pelo aumento do número de bugs corrigidos. Vários parâmetros internos precisam ser considerados para entender o impacto real. (Para saber mais sobre desenvolvimento Agile, consulte Agile Software Development 101.)
Por que TI ágil?
O setor de TI tem se inclinado para práticas ágeis, principalmente devido às restrições do modelo em cascata do desenvolvimento de software. Geralmente, observou-se que as empresas de TI não conseguem responder às demandas dos clientes ou às situações de mercado ou reduzir custos com o modelo em cascata de desenvolvimento de software. Mesmo se contrabalançarmos essa tendência avassaladora em relação à metodologia Agile e considerarmos parte da empolgação apenas um hype, há muito feedback empírico em relação ao modelo em cascata.
Simplificando, o modelo em cascata é um modelo de desenvolvimento de software em que o trabalho é realizado de maneira sequencial - uma fase após a outra. Existem cinco fases deste modelo: requisitos, design, implementação, verificação e manutenção. Normalmente, depois que uma fase é concluída, é difícil, se não impossível, fazer alterações em uma fase anterior. Portanto, a suposição é que os requisitos são praticamente fixos. A principal diferença com o modelo Agile está no pressuposto de que não haverá alteração nos requisitos. O Agile assume que as situações de negócios mudarão e os requisitos também. Portanto, o software é entregue em partes menores sobre ss, enquanto no modelo em cascata, a primeira entrega ou liberação é feita após um longo período de tempo. (Para obter mais informações sobre desenvolvimento, consulte Como o Apache Spark ajuda no rápido desenvolvimento de aplicativos.)
A crítica mais notável contra o modelo em cascata tem sido a suposição de que não haverá mudanças nos requisitos. A própria suposição é falha e irrealista. Por exemplo, em 2001, um estudo sobre 1.027 projetos de TI no Reino Unido mostrou que essa suposição era a maior razão para a falha de projetos de TI.
Em outro exemplo, Craig Larman, autor do livro "Desenvolvimento Ágil e Iterativo: Um Guia do Gerente", apontou como vários projetos executados pelo Departamento de Defesa (DoD) usando o modelo em cascata nos EUA falharam em alcançar seus objetivos. Nas décadas de 1980 e 1990, o DoD foi obrigado a usar o modelo em cascata para seus projetos de desenvolvimento de software, de acordo com os padrões publicados no DoD STD 2167. Estatísticas chocantes revelaram que 75% desses projetos de software nunca foram usados. Após esse relatório, uma força-tarefa foi lançada pelo Dr. Frederick Brooks, um conhecido especialista em engenharia de software. A força-tarefa publicou um relatório que comentava “O DoD STD 2167 também precisa de uma revisão radical para refletir as melhores práticas modernas. O desenvolvimento evolutivo é melhor tecnicamente, economiza tempo e dinheiro. ”
As quatro suposições a seguir do modelo em cascata falharam nos cenários do mundo real:
- Os requisitos fornecidos são razoavelmente bem definidos e, portanto, não sofrerão alterações significativas.
- Mesmo que os requisitos mudem durante a fase de desenvolvimento, eles serão pequenos o suficiente para serem acomodados dentro do ciclo de desenvolvimento.
- A integração do sistema, que ocorre após a entrega do software, seguirá o planejado.
- A inovação de software e o esforço necessário para inovar seguirão um cronograma planejado e previsível.
Como a metodologia ágil lida com os problemas do modelo em cascata?
A metodologia Agile é fundamentalmente diferente do modelo em cascata e isso é claro em suas suposições:
- Ninguém, nem mesmo o cliente, pode conhecer ou entender completamente os requisitos. Não há garantia de que os requisitos não sejam alterados.
- As alterações de requisitos podem não ser pequenas e gerenciáveis. De fato, eles virão em vários tamanhos e continuarão chegando. Portanto, o software será entregue em pequenos incrementos para acompanhar as alterações.
Como o Agile impactou o setor de TI?
O Agile está sendo adotado em muitos lugares, enquanto muitas empresas estão planejando adotá-lo. Embora o Agile tenha feito definitivamente mudanças fundamentais no setor de TI, fatos e números ainda são um pouco difíceis de obter. Mas o impacto do Agile pode ser entendido com o estudo de caso da British Telecom (BT) dado abaixo.
Sem erros, sem estresse - seu guia passo a passo para criar software que muda vidas sem destruir sua vida
Você não pode melhorar suas habilidades de programação quando ninguém se importa com a qualidade do software.
Razões pela qual a BT mudou para práticas ágeis
A BT começou a enfrentar vários problemas com suas práticas de desenvolvimento de software em 2004. A BT desenvolveu vários projetos de software, simples e complexos. Muitos projetos de software não conseguiram desenvolver resultados de qualidade dentro do prazo acordado. A BT descobriu que os problemas deviam suas raízes ao modelo em cascata. Portanto, reforçar o modelo em cascata não ajudaria. As principais causas dos problemas são apresentadas abaixo:
Má gestão de requisitos
- Muitos requisitos foram dados para serem cumpridos dentro de um tempo muito limitado.
- Muitos requisitos eram irrelevantes para as necessidades de negócios.
- Quase todos, se não todos os requisitos, receberam o status de alta prioridade.
- Os requisitos representavam as necessidades atuais dos negócios sem olhar para os cenários futuros. Isso deixou em aberto a possibilidade de futuras alterações de software.
Projeto de software ruim
- Dado o grande número de requisitos, os designers gastaram muito tempo apenas tentando descobrir o que os requisitos significavam. Pouco tempo foi deixado para o design real.
- Os analistas de requisitos passaram para outras tarefas, levando consigo conhecimentos não escritos e tácitos.
- Os dois fatores acima resultaram em design inadequado. Os designers ainda precisavam entregar de acordo com a linha do tempo original.
Restrições de desenvolvimento
A codificação foi apressada e de baixa qualidade devido ao design de software defeituoso. Os desenvolvedores perceberiam que um projeto de software ruim resultaria em código ruim, mas, no entanto, precisaria entregar dentro do prazo acordado. Muitos bugs seriam relatados durante a integração porque os testes de unidade e de regressão não foram executados.
Quando o software é implantado, o cliente observa que os requisitos já foram alterados e o cenário comercial também. O software também tem muitos problemas. Efetivamente, todo o esforço de desenvolvimento de software agora é considerado desperdício.
O que a BT fez para solucionar os problemas acima?
A BT percebeu que reforçar o modelo em cascata não era a resposta para os problemas. Precisava de uma nova abordagem. Então, decidiu implementar a abordagem Agile. Sob a nova abordagem, as seguintes coisas foram decididas:
- Em vez do ciclo de desenvolvimento de 12 meses, a BT agora entregaria partes de software viáveis em um ciclo de 90 dias. A idéia era focar em um ou dois problemas de negócios e ter como objetivo fornecer uma solução de software em 90 dias. O início deste ciclo foi marcado por uma intensa discussão entre diferentes partes interessadas, para que os requisitos fossem claramente identificados, analisados e priorizados.
- O objetivo era entregar valores comerciais claros e tangíveis. O cliente interno estava sob pressão para fornecer requisitos claros. Portanto, em vez de objetivos vagos, as histórias dos usuários foram fornecidas com critérios de aceitação claros.
- O software que seria entregue seria totalmente testado e documentado. O software passaria por testes frequentes de integração para identificar problemas com antecedência.
Com a abordagem ágil, a BT poderia se adaptar às mudanças de requisitos ou situações de negócios com mais facilidade. A qualidade do código melhorou e os bugs básicos de última hora foram resolvidos.
Conclusão
O Agile, por todas as suas vantagens e entusiasmo, ainda está em um estágio em que seu potencial não é totalmente realizado. Isso ocorre porque muitas organizações estão personalizando a abordagem na medida em que modificam seus princípios originais. Como resultado, o modelo em cascata está retornando em alguns casos. Embora a personalização continue, é importante manter os princípios básicos do Agiles. Muitas organizações afirmam ser totalmente ágeis, mas ainda têm um caminho a percorrer para se tornar uma empresa realmente ágil.