Wikipédia

Desenvolvimento ágil de software: diferenças entre revisões

Explorar interativamente o histórico
← Ver a alteração anteriorVer a alteração posterior →
Conteúdo apagado Conteúdo adicionado
VisualTexto wiki
Exgerth (discussão | contribs)
42 edições
m Melhora na definição de desenvolvimento ágil.
m ajustes usando script, +correções semiautomáticas (v0.53/3.1.39/0.4)
Linha 1:
{{fusão aqui|Feature Driven Development|data=junho de 2017}}
'''Desenvolvimento ágil de software''' (do inglês ''Agile software development'') ou '''Método ágil''' é uma expressão que define um conjunto de [[Metodologia (engenharia de software)|metodologias]] utilizadas no desenvolvimento de ''[[software]]''. As metodologias que fazem parte do conceito de [[desenvolvimento]] ágil, tal como qualquer [[Metodologia (engenharia de software)|metodologia]] de ''software'', providencia uma estrutura conceitual para reger projetos de [[engenharia de software]].
 
Existem inúmeros frameworks de processos para desenvolvimento de [[software]]. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projeto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, [[análise de requisitos]], projeto, codificação, [[teste de software|teste]] e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projeto.▼
== Introdução ==
▲Existem inúmeros frameworks de processos para desenvolvimento de [[software]]. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projeto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, [[análise de requisitos]], projeto, codificação, [[teste de software|teste]] e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projeto.
 
Métodos ágeis enfatizam comunicações em tempo real, preferencialmente cara a cara, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma [[sala]]. Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus ''clientes'' (clientes são as pessoas que definem o produto, eles podem ser os [[gerente]]s, [[analista de negócio|analistas de negócio]], ou realmente os [[cliente (comércio)|cliente]]s). Nesta sala devem também se encontrar os testadores, projectistas de iteração, [[redactores técnicos]] e gerentes.
Linha 51:
|páginas= 165-194
|isbn= 0-321-18612-5}}</ref> Métodos ágeis existem do lado adaptativo deste contínuo.
 
Métodos adaptativos buscam a adaptação rápida a mudanças da realidade. Quando uma necessidade de um projeto muda, uma equipe adaptativa mudará também. Um time adaptativo terá dificuldade em descrever o que irá acontecer no futuro. O que acontecerá em uma data futura é um item de difícil predição para um método adaptativo. Uma equipe adaptativa pode relatar quais tarefas se iniciarão na próxima semana. Quando perguntado acerca de uma implantação que ocorrerá daqui a seis meses, uma equipe adaptativa deve ser capaz somente de relatar a instrução de missão para a implantação, ou uma expectativa de valor versus custo.
 
Linha 61 ⟶ 62:
 
=== Comparação com o modelo em cascata ===
O desenvolvimento ágil tem pouco em comum com o [[modelo em cascata]]. Na visão de alguns este modelo é desacreditado, apesar de ser um modelo de uso comum. O modelo em cascata é uma das metodologias com maior ênfase no [[planejamento]], seguindo seus passos através da captura dos requisitos, análise, projeto, codificação e testes em uma seqüênciasequência pré-planejada e restrita. O progresso é geralmente medido em termos de entrega de artefatos—especificação de requisitos, documentos de projeto, [[plano de teste|planos de teste]], revisão do código, e outros. O modelo em cascata resulta em uma substancial integração e esforço de teste para alcançar o fim do ciclo de vida, um período que tipicamente se estende por vários meses ou anos. O tamanho e dificuldade deste esforço de integração e teste é uma das causas das falhas do projeto em cascata. Métodos ágeis, pelo contrário, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) num período de poucas semanas ou meses. Enfatiza a obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, e continuamente agregar novas funcionalidades através do [[ciclo de vida]] do projeto.
 
Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes, mais especificamente as equipes de [[Programação extrema]], trabalham com atividades simultaneamente.
Linha 71 ⟶ 72:
 
== Aplicabilidade dos métodos ágeis ==
Embora os métodos ágeis apresentem diferenças entre suas práticas, eles compartilham inúmeras características em comum, incluindo o desenvolvimento iterativo, e um foco na comunicação interativa e na redução do esforço empregado em artefatos intermediários. (Cohen et al., 2004)<ref name="cohen2004">Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In ''Advances in Computers'' (pp. 1-66). New York: Elsevier Science.</ref> A aplicabilidade dos métodos ágeis em geral pode ser examinada de múltiplas perspectivas. Da perspectiva do produto, métodos ágeis são mais adequados quando os requisitos estão emergindo e mudando rapidamente, embora não exista um consenso completo neste ponto (Cohen et al., 2004).<ref name="cohen2004"/> De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três dimensões chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas inúmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):<ref name="cohen2004"/>
 
* A cultura da organização deve apoiar a negociação.
Linha 83 ⟶ 84:
De forma a determinar a aplicabilidade de métodos ágeis específicos, uma análise mais sofisticada é necessária. O [[método dinâmico para o desenvolvimento de sistemas]], por exemplo, provê o denominado 'filtro de aplicabilidade' para este propósito. Também, a família de métodos Crystal provê uma caracterização de quando selecionar o método para um projeto. A seleção é baseada no tamanho do projeto, criticidade e prioridade. Contudo, outros métodos ágeis não fornecem um instrumento explícito para definir sua aplicabilidade a um projeto.
 
Alguns métodos ágeis, como DSDM ([[Dynamic Systems Development Method]]) e FDM ([[Feature Driven Development|Feature Driven Development)]]), afirmam se aplicar a qualquer projeto de desenvolvimento ágil, sem importar suas características (Abrahamsonn et al., 2003).<ref name= Abrahamsson2003>Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. ''Proceedings of ICSE'03'', 244-254</ref>
 
A comparação dos métodos ágeis irá revelar que eles suportam diferentes fases de um ciclo de vida do software em diferentes níveis. Estas características individuais dos métodos ágeis podem ser usadas como um critério de seleção de sua aplicabilidade.
Linha 102 ⟶ 103:
* Baixa criticidade
* Desenvolvedores senior
* Mudanças freqüentefrequente de requisitos
* Pequeno número de desenvolvedores
* Cultura que tem sucesso no caos.
Linha 134 ⟶ 135:
* [[Scrum (desenvolvimento de software)|Scrum]]
 
'''Albert Joseph ; Ercilia Chilaule ; Francelino Itc(I2cv)'''
* [[Feature Driven Development]] (FDD)
* [[Dynamic Systems Development Method]] (DSDM)
Linha 157 ⟶ 158:
 
== Futuras leituras ==
* Fowler, Martin. [http://www.martinfowler.com/articles/designDead.html ''Is Design Dead?'']. Appeared in ''Extreme Programming Explained'', G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
* Riehle, Dirk. [http://www.riehle.org/computer-science/research/2000/xp-2000.html ''A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other'']. Appeared in ''Extreme Programming Explained'', G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
* Tomek, Ivan. ''What I Learned Teaching XP''. [http://www.whysmalltalk.com/articles/tomek/teachingxp.htm http://www.whysmalltalk.com/articles/tomek/teachingxp.htm]
* M. Stephens, D. Rosenberg. ''Extreme Programming Refactored: The Case Against XP''. Apress L.P., Berkeley, California. 2003. (ISBN 1-59059-096-1)
* D. Rosenberg, M. Stephens. ''Agile Development with ICONIX Process''. Apress L.P., Berkeley, California. 2005. (ISBN 1-59059-464-9)
* Beck, et. al., ''Manifesto for Agile Software Development''. [http://www.agilemanifesto.org/]
* Larman, Craig and Basili, Victor R. [http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf ''Iterative and Incremental Development:A Brief History '' IEEE Computer, June 2003]
* Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. ''Proceedings of ICSE'03'', 244-254.
* Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. ''VTT Publications 478''.
Obtida de "https://pt.wikipedia.org/wiki/Desenvolvimento_ágil_de_software"