Adaptive Software Development
Adaptive Software Development (ASD), em português: Desenvolvimento de Software Adaptativo ou Desenvolvimento adaptável de software é uma técnica para o desenvolvimento de softwares complexos, proposta por Jim Highsmith.
Imagem: Michael Kappel · BY-ND · Openverse
Jim Highsmith passou diversos anos trabalhando com metodologias predeterministas. Ele desenvolveu, instalou, ensinou e concluiu que tais metodologias são profundamente falhas: particularmente para empresas modernas. Seu livro mais recente foca na natureza adaptativa de novas metodologias, com uma ênfase particular em aplicar idéias originantes do mundo dos sistemas complexos adaptativos (comumente conhecidos como teoria do caos). A metodologia não provê práticas detalhadas como o XP faz, mas traz o fundamento do porquê o desenvolvimento adaptativo é importante, e as conseqüências nos níveis organizacionais e administrativos mais profundos.
Imagem: Michael Kappel · BY-ND · Openverse
ASD é caracterizado por seis propriedades:
Orientado a missões (Mission Driven)
Para cada iteração do ciclo de desenvolvimento justifica-se através de uma missão, que pode mudar ao longo do projeto.
Baseado em componentes (Component-Based)
Desenvolvimento orientado a componentes, desenvolvendo o software em pequenas partes.
Iterativo (Iterative)
Desenvolvimento de pequenos ciclos (iterações), com o objetivo de resultar em uma implementação satisfatória para cada missão definida por iteração. O ASD possui foco em refazer do que fazer corretamente já na primeira vez.
Prazos pré-fixados (Time Boxed)
Fixação de prazos para evitar ambigüidade em projetos, com prazos tangíveis forçando com que a equipe defina severamente decisões do projeto logo cedo
Orientado a riscos (Risk-Driven)
Todos itens que são considerados características de alto risco tem seu desenvolvimento priorizado.
Imagem: Michael Kappel · BY-ND · Openverse
Especular
O termo especular equivale a observar, indagar, pesquisar; em outras palavras, questionar as causas de algum assunto. No caso da metodologia ASD, utiliza-se como substituto do “planejar”. O planejamento é considerado muito amplo nessa metodologia, pois quando se planeja, busca-se o entendimento e definem-se estratégias para atendê-lo. Assim, antecipadamente, o ASD estimula a criação de um conjunto de regras e metas que muitas vezes precisam ser modificadas ao longo do desenvolvimento. Entende-se que, ao planejar, não temos ideia se tudo irá ocorrer conforme o previsto inicialmente. Portanto, o ASD utiliza o ato de especular como subterfúgio ao replanejar, ouvindo as necessidades do cliente ao longo do processo de desenvolvimento com o objetivo de evitar o retrabalho.
Colaborar
Quando o software a ser desenvolvido é considerado de alta complexidade, as previsões de como ele será́ implementado e de como vai se comportar no ambiente de utilização muitas vezes podem se mostrar inúteis devido ao fato de não conseguirmos controlá-las de antemão. Conforme apresentamos anteriormente, existem práticas de gestão que atuam em partes do processo de desenvolvimento desde que estas sejam previsíveis, mas para projetos que possuem elementos e variáveis desconhecidos, os métodos de gestão tradicionais não se aplicam, ou seja, não funcionam a contento. O PMBOK, por exemplo, é uma metodologia considerada tradicional, em que os processos precisam ser bem definidos, e alguns autores radicais consideram impossível trabalhar em conjunto com uma metodologia ágil.
Aprender
A metodologia ASD propõe que as partes interessadas participem efetivamente do desenvolvimento da solução a ser construída. Determina que todo artefato desenvolvido seja apresentado a todos para que valorizem o que foi produzido, ou seja, utilizam práticas de revisões junto com o cliente e testes com versões betas, a fim de obter resultados para novas análises e modificações. O aprendizado está no fato de que, com o andamento do projeto, o desenvolvedor passa a conhecer os desejos do cliente, adquirindo experiência e domínio do assunto e, consequentemente, da aplicação, além de conhecer antecipadamente os próximos passos a serem desenvolvidos. Os ciclos de revisões e testes devem ser curtos o suficiente para aprender apenas com pequenos erros, não oferecendo grandes riscos ao projeto.
Imagem: Remko van Dokkum · BY · Openverse
Este método não descreve cargos em detalhes : Participantes de uma sessão (workshop) do desenvolvimento de aplicações em conjunto (JAD).
