Adaptive Software Development

Adaptive Software Development (ASD)^[1], em português: Desenvolvimento de Software Adaptativo^[2] ou Desenvolvimento adaptável de software^[3] é uma técnica para o desenvolvimento de softwares complexos, proposta por Jim Highsmith.

O apoio filosófico do ASD concentra-se na colaboração humana e na auto-organização.

A auto-organização aparece quando agentes individuais independentes cooperam para criar resultados emergentes. Um resultado emergente é uma propriedade além da capacidade de qualquer agente individual.^[4]

Características

Características do ASD^[5]:

• Iterativo e incremental
• Sistemas grandes e complexos
• Arcabouço para evitar o caos
• Cliente sempre presente
• Desenvolvimento de aplicações em conjunto (Joint Application development – JAD)

Evolução histórica

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.

Propriedades

ASD é caracterizado por seis propriedades:^[3][5]

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

Tolerância a mudanças (Change-Tolerant)

Característico do método:

• As mudanças são freqüentes.
• É sempre melhor estar pronto a adaptá-las do que controlá-las.
• Constante avaliação de quais componentes podem mudar.

Orientado a riscos (Risk-Driven)

Todos itens que são considerados características de alto risco tem seu desenvolvimento priorizado.

Ciclo de vida^[6]

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.

A colaboração, neste contexto, traduz-se no ato de criação e manutenção de elementos de software capazes de atender as emergências por parte do cliente. O gerente de projeto, juntamente com os stakeholders, decide as prioridades, ou seja, aquilo que é previsível em curto prazo, fazendo com que sejam gerados benefícios aos usuários. É importante observar que a colaboração não visa “apagar incêndios” ou resolver problemas de processos da empresa. A colaboração pretende organizar o desenvolvimento, de forma a permitir que as funcionalidades sejam realizadas em ordem de utilização e suprindo as necessidades mais urgentes.

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.

Cargos e Responsabilidades

Este método não descreve cargos em detalhes ^[5]:

• Executivo responsável (Executive Sponsor)

Participantes de uma sessão (workshop) do desenvolvimento de aplicações em conjunto (JAD).

• Facilitador (Facilitator): Liderar e planejar as sessões.
• Escriba (Scribe): Efetuar anotações.
• Cliente (Customer): Sempre presente.
• Gerente de Projetos (Project Manager)
• Desenvolvedores (Developers)

Veja também

• Desenvolvimento ágil de software
• Modelo em cascata
• Modelo V

Referências

1. «"Site Oficial ASD"» (em inglês). Consultado em 26 de março de 2015 
2. «Guia de Projeto de Sistemas com Práticas de Métodos Ágeis e Terceirização do Desenvolvimento para o SISP». Brasília: Secretaria de Logística e Tecnologia da Informação. 2 de fevereiro de 2015. p. 6. 89 páginas. Consultado em 26 de março de 2015. Arquivado do original em 2 de abril de 2015 
3. César Sanz Gutierrez; Eduardo Yukio Miyake; Fábio Henrique Pereira Lima; Nick Lazur (2009). «Engenharia de Requisitos na Metodologia Ágil» (PDF). Orientadora: Dra. Judith Pavón. Universidade Anhembi Murumbi. 144 páginas. Consultado em 26 de março de 2015. Arquivado do original (pdf) em 2 de abril de 2015  !CS1 manut: Nomes múltiplos: lista de autores (link)
4. Pressman, Roger S (2010). Engenharia de Software. Uma Abordagem Profissional 7 ed. [S.l.]: McGraw-Hill Science/Engineering/Math. ISBN 9788563308337 
5. dos Santos, Rogério Guaraci; Giulian Dalton Luz. «Métodos Ágeis» (PDF)  A referência emprega parâmetros obsoletos |coautores= (ajuda)
6. De Carvalho Sbrocco, Jose Henrique Teixeira. Metodologias Ageis: ENGENHARIA DE SOFTWARE SOB MEDIDA. [S.l.]: ERICA 

• Portal das tecnologias de informação

Ligações externas

https://www.guj.com.br/t/asd-desenvolvimento-adaptativo-de-software/280382

https://prezi.com/z1dhhjferbxq/apresentacao-asd-engenharia-de-software/

https://prezi.com/mqey3hvnxtvd/desenvolvimento-de-software-adaptativo-asd/