ASD(Desenvolvimento adaptátivo de software)

Assuntos Gerais Agile
#1

Podem me chamar de burro, mas não entendi porrissssssima nenhuma dessa metodologia:

[quote=http://simplus.com.br/artigos/a-nova-metodologia/#N276]

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.

No coração do ASD (Adaptative Software Development) estão três fases não-lineares e sobrepostas: especulação, colaboração e aprendizado.

Highsmith vê o planejamento como um paradoxo em um ambiente adaptativo, uma vez que os produtos são naturalmente imprevisíveis. No planejamento tradicional, desvios dos planos são enganos e devem ser corrigidos. Em um ambiente adaptativo, entretanto, desvios nos guiam à solução correta.

Neste ambiente imprevisível você precisa de pessoas colaborando de forma rica pra lidar com a incerteza. A atenção da administração é menor a respeito de dizer às pessoas o que fazer, e maior a respeito de estimular a comunicação, para que as pessoas possam criar soluções criativas por conta própria.

Em ambientes predeterministas, o aprendizado normalmente é desestimulado. As coisas são planejadas de antemão e depois seguem o design estipulado.

Em um ambiente adaptativo, o aprendizado desafia todos os envolvidos no projeto - desenvolvedores e seus clientes - a examinar suas premissas e a utilizar os resultados de cada ciclo de desenvolvimento para adaptar o seguinte.
– [Highsmith]

Dessa forma, o aprendizado é uma característica contínua e importante, que assume que os planos e designs devem mudar à medida que o desenvolvimento avança.

O benefício principal, poderoso, indivisível, e predominante do ciclo de vida do Desenvolvimento Adaptativo é que ele nos força a confrontar nossos modelos mentais, que estão na raiz de nossas próprias ilusões. Ele nos força a estimar nossa habilidade de forma mais realista.
– [Highsmith]

Com esta ênfase, o trabalho de Highsmith foca diretamente em abordar as partes difíceis do desenvolvimento adaptativo, em particular em como lidar com a colaboração e o aprendizado dentro do projeto. Desta forma, seu livro ajuda a prover idéias para explorar essas áreas “soft”, o que faz que seja um bom complemento para as abordagens baseadas em práticas fundamentadas, tais como XP, FDD e Crystal.[/quote]

Alguém poderia explicar melhor que diabos é isso :?: :?: :?: :?:

#2

fabioEM
Não compreender uma coisa não te torna burro. Não precisa se avaliar tão negativamente só porque não entende algo.

Sobre o ASD, levando em conta somente esse texto (sem ler as publicações referentes à ele) e o que conheço dele (por causa da disciplina de Engenharia de Software, que teve um tópico - bastante curto - sobre isso), minha opinião é que o ASD não é uma metodologia completa (o que não quer dizer que seja melhor ou pior)): ele visa complementar outras metologias. Isso fica claro quando você lê esses trechos:

O ASD vai de encontro ao quarto item (se é que podemos numerá-los assim) do Agile Manifesto (http://agilemanifesto.org/iso/ptbr/): Responder a mudanças mais que seguir um plano. Ou seja, a ideia é que não somente o software a ser desenvolvido tenha algum grau de flexibilidade (o que pode set conseguido mesmo em projetos “predeterministas”), mas que o próprio processo de desenvolvimento seja flexível e permita grandes mudanças (de escopo, foco, da equipe, etc), já que, naturalmente, a mudança faz parte do ambiente. Os envolvidos devem estar cientes disso e aptos a adotar mudanças, quaisquer que sejam elas. Para isso, o ASD (teoricamente) provê algumas metodologias, resumidas na tríade especulação, colaboração e aprendizado.

Não sei se ajudou, mas fica aí minha visão.

Abraço.

#3

Bom eu não conheço esse autor, mas pelo que eu entendi, ele mostra os benefícios de uma abordagem adaptativa do desenvolvimento com relação a uma abordagem preditiva. Em uma abordagem preditiva, você levanta os requisitos do software, estima prazo e custo, monta um planejamento e o executa à risca. Em uma abordagem adaptativa, você mapeia a cadeia de valor do seu cliente e busca entregar as estórias de maior valor, a fim de obter feedback rápido.

O grande problema do desenvolvimento preditivo, é que não há espaço para o aprendizado. A sequencia de trabalho, assim como design, etc. é pré-determinada. Porém, se essa sequencia não se mostrar a mais adequada a mudança pode acarretar em custos que inviabilizem o projeto. Além do mais, como a divisão do trabalho também é pré-determinada, a tendência é que o conhecimento fique compartimentalizado.

O que o autor defende é que quando não se tenta pré-determinar a sequencia de todo o projeto, as incertezas e riscos ficam expostos. Isso evita pressuposições que impactam todo o projeto, e estimula o aprendizado e a comunicação na equipe. Dessa maneira, a organização do trabalho, os processos, etc. ficam mais flexíveis, de forma que é possível responder à mudanças de maneira mais adequada e com um impacto bem menor.

Ou seja, é o basicamente aquilo que encontramos no Scrum, XP, etc.

#4

[quote=TerraSkilll]fabioEM
Não compreender uma coisa não te torna burro. Não precisa se avaliar tão negativamente só porque não entende algo.

Sobre o ASD, levando em conta somente esse texto (sem ler as publicações referentes à ele) e o que conheço dele (por causa da disciplina de Engenharia de Software, que teve um tópico - bastante curto - sobre isso), minha opinião é que o ASD não é uma metodologia completa (o que não quer dizer que seja melhor ou pior)): ele visa complementar outras metologias. Isso fica claro quando você lê esses trechos:

O ASD vai de encontro ao quarto item (se é que podemos numerá-los assim) do Agile Manifesto (http://agilemanifesto.org/iso/ptbr/): Responder a mudanças mais que seguir um plano. Ou seja, a ideia é que não somente o software a ser desenvolvido tenha algum grau de flexibilidade (o que pode set conseguido mesmo em projetos “predeterministas”), mas que o próprio processo de desenvolvimento seja flexível e permita grandes mudanças (de escopo, foco, da equipe, etc), já que, naturalmente, a mudança faz parte do ambiente. Os envolvidos devem estar cientes disso e aptos a adotar mudanças, quaisquer que sejam elas. Para isso, o ASD (teoricamente) provê algumas metodologias, resumidas na tríade especulação, colaboração e aprendizado.

Não sei se ajudou, mas fica aí minha visão.

Abraço.[/quote]
Não entendo esse ponto e outros pontos:

[quote=TerraSkilll]A metodologia não provê práticas detalhadas[/quote] Beleza. se não provê práticas detalhadas, então como organizar uma equipe, quem faz o que? Quem é responsável pelo que? Isso não consigo entender, pois as outras XP, Scrum são mais claras.
Sem falar que esses processo também não entendi especulação, colaboração e aprendizado Prucurei no livro Pressman e não consegui compreender ainda.
Mas obrigado de ante mão pela resposta :wink: :wink:

#5

[quote=rmendes08] Em uma abordagem preditiva, você levanta os requisitos do software, estima prazo e custo, monta um planejamento e o executa à risca. Em uma abordagem adaptativa, você mapeia a cadeia de valor do seu cliente e busca entregar as estórias de maior valor, a fim de obter feedback rápido.
[/quote]
Pois é assim o XP também faz, me lembro pq trabalhei com essa metodologia. Um requisito complexo era analisado e se tentava intregrar logo para obter um retorno.

Não entendo como seria possível desenvolver um projeto sem usar uma sequência de passos pré-determinada; analise de requisitos, planejamento , projeto, codificação, teste, manutenção e entrega. Assim como a divisão de trabalho é pré-determinada, pois um analista de requisitos não deveria ficar codificando, assim como um gerente de projeto não deveria ficar fazendo o Layout da aplicação. Por essa razão que cada um tem seu papel. E, mais uma coisa como fazer com que o conhecimento não fique compartimentalizado?
Por exemplo, tenho 20 recursos e 2 projetos, um projeto trata de saúde e será feito com JSF Java, Hibernate e Mysql. Já outro projeto é para a área de imóveis e irá usar GWT,RestFull,Oracle, JDBC puro,Spring por exemplo. 10 pessoas para o projeto Saúde e 10 para o projeto Imóveis. De que forma posso fazer que o conhecimento seja passado para todos??
E como seria gerenciar usando esse sistema ASD?
Valeu pela resposta!! :lol:

#6

Nesse ponto tenho de ser sincero: sem ler a publicação do Highsmith, qualquer opinião que eu poste é mera especulação do que ele pode ter pretendido dizer. Mas creio que, dentro do que ele propõe, os elementos básicos ainda permaneçam. Um programador ainda programa, um DBA ainda faz a estruturação do banco. Se a metodologia não diz isso claramente, não quer dizer que isso tenha sido abolido. Está, de certa forma, implícito (novamente, é minha opinião).

[quote=fabioEM][quote=rmendes08] Em uma abordagem preditiva, você levanta os requisitos do software, estima prazo e custo, monta um planejamento e o executa à risca. Em uma abordagem adaptativa, você mapeia a cadeia de valor do seu cliente e busca entregar as estórias de maior valor, a fim de obter feedback rápido.
[/quote]
Pois é assim o XP também faz, me lembro pq trabalhei com essa metodologia. Um requisito complexo era analisado e se tentava intregrar logo para obter um retorno.
[/quote][/quote]
As metodologias tidas como ágeis têm princípios parecidos, por isso essa similaridade. A meu ver, são diferentes abordagens que visam um mesmo objetivo, que é um desenvolvimento de software mais rápido e conciso.

[quote=fabioEM][quote=rmendes08]
O grande problema do desenvolvimento preditivo, é que não há espaço para o aprendizado. A sequencia de trabalho, assim como design, etc. é pré-determinada. Porém, se essa sequencia não se mostrar a mais adequada a mudança pode acarretar em custos que inviabilizem o projeto. Além do mais, como a divisão do trabalho também é pré-determinada, a tendência é que o conhecimento fique compartimentalizado.
[/quote]
Não entendo como seria possível desenvolver um projeto sem usar uma sequência de passos pré-determinada; analise de requisitos, planejamento , projeto, codificação, teste, manutenção e entrega. Assim como a divisão de trabalho é pré-determinada, pois um analista de requisitos não deveria ficar codificando, assim como um gerente de projeto não deveria ficar fazendo o Layout da aplicação. Por essa razão que cada um tem seu papel. E, mais uma coisa como fazer com que o conhecimento não fique compartimentalizado?
Por exemplo, tenho 20 recursos e 2 projetos, um projeto trata de saúde e será feito com JSF Java, Hibernate e Mysql. Já outro projeto é para a área de imóveis e irá usar GWT,RestFull,Oracle, JDBC puro,Spring por exemplo. 10 pessoas para o projeto Saúde e 10 para o projeto Imóveis. De que forma posso fazer que o conhecimento seja passado para todos??
E como seria gerenciar usando esse sistema ASD?
Valeu pela resposta!! :lol:
[/quote]
Creio que está havendo uma pequena confusão: nenhuma metodologia (ágil ou não) diz que as tarefas não devem ser atribuídas a pessoas específicas. Também, no caso das metodologias ágeis (ASD, Scrum, XP), é errado dizer que não há planejamento. O que muda de uma metodologia ágil para uma “predeterminada” é que, no caso de uma predeterminada, por exemplo, o software é todo planejado de ponta a ponta antes de ser digitada qualquer linha de código (essa é uma visão simplista e grosseira, eu sei, mas serve para ilustrar). Já numa metodologia ágil, os ciclos de desenvolvimento tendem a ser mais curtos e a entrega das funcionalidades do projeto é feita em partes. Peguemos por exemplo um aplicativo de vendas: numa visão predeterminada, todo o software (incluindo cadastros, movimentos, relatórios, gráficos e tudo o mais) teria de ser planejado, projetado e codificado antes dos testes e da implantação. Num modelo ágil, o software pode ser entregue em partes (somente os cadastros no início, depois os movimentos e por fim os relatórios) e, a cada entrega, são avaliados os impactos e novas necessidades, que podem refletir em mudanças no projeto. Uma metodologia ágil incorpora as etapas de desenvolvimento comuns (analise de requisitos, planejamento , projeto, codificação, teste, manutenção e entrega), mas seus ciclos de entrega são mais curtos e com parte das funcionalidades de uma versão final do software. O caso específico do ASD é que ele foca na adaptabilidade da equipe à mudança, seja ela qual for. Outras metodologias tratam, por exemplo, da organização da equipe e da organização do projeto (como Scrum e XP).

Abraço.

#7

Pois é, esse conceito é muito subjetivo e genérico, afinal, mudanças sempre acontecem do decorrer de qualquer desenvolvimento de projeto. Não dar para ter uma ideia mais clara, fica nebuloso. O que gostaria de saber é como enfrenta essas mudanças :lol: :lol:
Se alguém souber ou puder indicar um livro…

#8

Pois é, esse conceito é muito subjetivo e genérico, afinal, mudanças sempre acontecem do decorrer de qualquer desenvolvimento de projeto. Não dar para ter uma ideia mais clara, fica nebuloso. O que gostaria de saber é como enfrenta essas mudanças :lol: :lol:
Se alguém souber ou puder indicar um livro…[/quote]

Oi, Fabio

A dificuldade em se entender os processos adaptativos esta na nossa intuicao, ou no que nos foi ensinado. Os processos adaptativos sao contra intuitivos porque nós crescemos ouvindo que tudo que fazemos tem que ser muito bem planejado, meticulosamente calculado e depois executado exatamente em cima daquilo que foi planejado. Nós vemos isso em filmes, em novelas, em propaganda, onde sempre quem planeja tudo muito bem é O CARA. E pior vemos isso em livros e faculdades tambem. Mas este tipo de abordagem so funciona quando temos algo absolutamente imutavel e com um numero pequeno de variaveis. Ou seja, algo que eu consigo prever de antemao. Quanto maior o nivel de incerteza em um projeto pior sera o resultado dos metodos preditivos.

Nos processos adaptativos, voce tem uma visao geral do que precisa ser feito, com essa visao geral voce comeca o seu projeto. A partir dai voce vai precisar criar formas de validar o que voce esta fazendo (lembre-se que voce esta trabalhando com um grande nivel de incerteza). Validar significa, por a prova, com alguem, ou algo que possa atestar que o que esta sendo feito esta de acordo com o resultado esperado. Quanto mais rapido este ciclo de desenvolvimento/validacao, mais rapidamente voce vai poder adaptar o seu processo as necessidades que surgirem.

Alguns livros:
Sobre metodologias especificamente:


http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches;jsessionid=B62544E9B01963C9255D1615620AFE38 (free)

Mas mais importante que as metodologias sao as razoes pra elas existirem. Estas sao obras indispensaveis, pare o que voce estiver fazendo e leia-as:
http://gettingreal.37signals.com/GR_por.php

#9

Pois é, esse conceito é muito subjetivo e genérico, afinal, mudanças sempre acontecem do decorrer de qualquer desenvolvimento de projeto. Não dar para ter uma ideia mais clara, fica nebuloso. O que gostaria de saber é como enfrenta essas mudanças :lol: :lol:
Se alguém souber ou puder indicar um livro…[/quote]

Oi, Fabio

A dificuldade em se entender os processos adaptativos esta na nossa intuicao, ou no que nos foi ensinado. Os processos adaptativos sao contra intuitivos porque nós crescemos ouvindo que tudo que fazemos tem que ser muito bem planejado, meticulosamente calculado e depois executado exatamente em cima daquilo que foi planejado. Nós vemos isso em filmes, em novelas, em propaganda, onde sempre quem planeja tudo muito bem é O CARA. E pior vemos isso em livros e faculdades tambem. Mas este tipo de abordagem so funciona quando temos algo absolutamente imutavel e com um numero pequeno de variaveis. Ou seja, algo que eu consigo prever de antemao. Quanto maior o nivel de incerteza em um projeto pior sera o resultado dos metodos preditivos.

Nos processos adaptativos, voce tem uma visao geral do que precisa ser feito, com essa visao geral voce comeca o seu projeto. A partir dai voce vai precisar criar formas de validar o que voce esta fazendo (lembre-se que voce esta trabalhando com um grande nivel de incerteza). Validar significa, por a prova, com alguem, ou algo que possa atestar que o que esta sendo feito esta de acordo com o resultado esperado. Quanto mais rapido este ciclo de desenvolvimento/validacao, mais rapidamente voce vai poder adaptar o seu processo as necessidades que surgirem.

Alguns livros:
Sobre metodologias especificamente:


http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches;jsessionid=B62544E9B01963C9255D1615620AFE38 (free)

Mas mais importante que as metodologias sao as razoes pra elas existirem. Estas sao obras indispensaveis, pare o que voce estiver fazendo e leia-as:
http://gettingreal.37signals.com/GR_por.php
http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783[/quote]

Parabéns! Material muito bom mesmo! Valeu vou estudar por eles :wink:

#10