Desenvolvimento ágil de software
Origem: Wikipédia, a enciclopédia livre.
| Processo de Desenvolvimento de Software |
|---|
| Este artigo é parte da série Processo de desenvolvimento de software |
| Atividade e Passos |
| Requirimentos | Arquitetura | Especificação | Implementação | Teste | Implantação | Manutenção |
| Modelos |
| Ágil | Cleanroom | Interativo | RAD | RUP | Spiral | Waterfall | XP | Scrum |
| Disciplinas de Apoio |
| Gerenciamento de configuração | Documentação | Gerenciamento de Projeto |
Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.
Índice |
[editar] Introdução
Existem inúmeros métodos de desenvolvimento de software rápido, cada uma destas esta exposta pela The Agile Alliance. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de interação, os quais gastam tipicamente menos de uma semana a até quatro. Cada interaçã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, analise de requerimento, projeto, codificação, teste e documentação. Enquanto em uma interação não necessariamente adiciona bastante funciona para garantir uma implantação do produto, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada interação. Ao fim de cada interação, o time reavalia a prioridades do projeto.
Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo ágil devem estar agrupados em uma sala. Isto inclui todas as pessoas necessárias para terminar o software. No mínimo, isto inclui os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negocio, ou realmente os clientes). Nesta sala devem também se encontra os testadores, projetistas de interação, redatores técnicos e gerentes.
Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso. Combinado com a comunicação face-a-face, métodos ágeis produzem muito pouca documentação em relação a outros métodos. Disto se originam criticas de que os métodos ágeis sejam muito indisciplinados.
[editar] Princípios
Os princípios do desenvolvimento ágil valorizam:
- Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
- Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
- Softwares funcionais são a principal medida de progresso do projeto;
- Até mesmo mudanças tardias de escopo no projeto são bem-vidas.
- Cooperação constante entre entre pessoas que entendem do 'negócio' e desenvolvedores;
- Projetos surgem através de indivíduos motivados, e que deve exister uma relação de confiança.
- Design do software deve prezar pela excelência técnica;
- Simplicidade
- Rápida adaptação às mudanças
- indivíduos e interações ao invés de processos e ferramentas
- software funcional ao invés de documentação extensa
- colaboração com clientes ao invés de negociação de contratos
- responder a mudanças ao invés de seguir um plano
[editar] História
As definições modernas de desenvolvimento de software ágil evoluíram a partir da metade de 1990 como parte de uma reação contra métodos "pesados", caracterizados por uma pesada regulamentação, regimentação e micro gerenciamento usado o modelo em cascata para desenvolvimento. O processo originou-se da visão de que o modelo em cascata era burocrático, lento e contraditório a forma usual com que os engenheiros de software sempre realizaram trabalho com eficiência.
Uma visão que levou ao desenvolvimento de métodos ágeis e interativos era retorno a prática de desenvolvimento vistas nos primórdios da história do desenvolvimento de software [1].
Inicialmente, métodos ágeis eram conhecidos como métodos leves. Em 2001, membros proeminentes da comunidade se reuniram em Snowbird e adotaram o nome métodos ágeis. Mais tarde, algumas pessoas formaram A Agile Alliance[2], uma organização não lucrativa que promove o desenvolvimento ágil.
Os métodos ágeis iniciais—criado a prior em 2000— incluíam Scrum(1986), Crystal Clear, Programação extrema (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (1995).
[editar] Comparações com outros métodos
Metodos Ágeis são algumas vezes caracterizados como o oposto extremo de metodologias guiadas pelo planejamento ou disciplinadas. Uma distinção mais acurada é dizer que os métodos existem em um continuo do adaptativo até o preditivo. [1] Métodos ágeis existem do lado adaptativo deste continuo. Métodos adaptativos buscam a adaptação rápida à mudanças da realidade. Quando uma necessidade de um projeto muda, uma equipe adaptativa mudará também. Um time adaptativo ira ter dificuldade em descrever o que ira acontecer no futuro. O que irá acontecer em uma data futura é um item de difícil predição para um método adaptativo. Uma equipe adaptativa pode relatar quais tarefas quais tarefas iram se iniciar na próxima semana. Quando perguntado a cerca de uma implantação que ocorrera 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.
Métodos preditivos, em contraste, cocam o planejamento do futuro em detalhe. Uma equipe preditiva pode reportar exatamente quais aspectos e tarefas estão planejados para toda a linha do processo de desenvolvimento. Elas porem tem dificuldades de mudar de direção. O plano é tipicamente otimizado para o objetivo original e mudanças de direção podem causar a perda de todo o trabalho e determinar que seja feito tudo novamente. Equipes preditivas freqüentemente instituem um comitê de controle de mudança para assegurar que somente as mudanças mais importantes sejam consideradas.
Métodos ágeis têm muito em comum com técnicas de Desenvolvimento rápido de aplicação de 1980 como exposto por James Martin e outros.
[editar] Comparação como o desenvolvimento interativo
A maioria dos métodos ágeis compartilha a ênfase no desenvolvimento interativo para a construção de versões implantadas do software em curtos períodos de tempo. Métodos ágeis diferem dos métodos interativos porque seus períodos de tempo são medidos em semanas ao invés de messes é a realização é efetuada de uma maneira altamente colaborativa.
[editar] Comparação como 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 é o um das metodologias com mais ênfase no planejamento, seguindo seus passos através da captura dos requerimentos, analise, projeto, codificação e testes em uma seqüência pré-planejada e restrita. O progresso é geralmente medido em termos de entrega de artefatos—especificação de requerimentos, documentos de projeto, planos de teste, revisão do código, e outros. O modelo em cascata resulta em uma substancial integração e esforço d 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ça de integração é teste é uma das causas das falhas do projeto em cascata. Métodos ágeis, pelo contrario, produzem um desenvolvimento completo e teste de aspectos (mas um pequeno subconjunto do todo) a cada poucas semanas ou meses. Esta ênfase é na obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, e continuamente aumentar 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 interação. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.
[editar] Comparação como a "codificação cowboy"
A codificação cowboy é a ausência de método de definição: os membros da equipe fazem o que eles sentem que é correto. Os desenvolvedores ágeis freqüentemente reavaliam os planos, enfatiza a comunicação face a face e o uso relativamente esparso de documentos levando ocasionalmente as pessoas a confundirem isto com codificação cowboy. Equipes ágeis, contudo, seguem o processo definido (e freqüentemente de forma disciplinada e rigorosa).
Como em todas as metodologias, o conhecimento e a experiência dos usuários definem o grau de sucesso e/ou fracasso de cada atividade. Os controles mais rígidos e sistematizados aplicados em um processo implicam em altos níveis de responsabilidade para o usuários. A degradação de procedimento bem-intencionados pode levar as atividade a serem caracterizadas como codificação cowboy.
[editar] Aplicabilidade dos métodos ágeis
Embora os métodos ágeis defiram em suas praticas, eles compartilham inúmeras características em comum, incluindo o desenvolvimento interativo, e um foco na comunicação interativa e na redução do esforço empregado em artefatos intermediários. (Cohen et al., 2004) [2] 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 adequado quando os requerimentos estão emergindo e mudando rapidamente, embora não exista um consenso completo neste ponto (Cohen et al., 2004).[2] De uma pespectiva 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)[2]:
- A cultura da organização deve apoiar a negociação.
- As pessoas devem ser confiantes.
- Poucas pessoas, mas competentes.
- A organização deve promover as decisões que os desenvolvedores tomam.
- A Organização necessita tem um ambiente que facilite a rápida comunicação entre os membros.
O fator mais importante é provavelmente o tamanho do projeto (Cohen et al., 2004).[2] . Com o aumento do tamanho, a comunicação face a face se torna mais difícil. Portanto, métodos ágeis são mias adequados para projetos com pequenos times, com no máximo de 20 a 40 pessoas.
De forma a determinara aplicabilidades de métodos ágeis específicos, uma analise mais sofisticada é necessária. O método dinâmico para o desenvolvimento de sistemas, por exemplo, prove o denominado 'filtro de aplicabilidade' para este propósito. Também, a família de métodos Crystal prove 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 explicito para definir sua aplicabilidade a um projeto.
Alguns métodos ágeis, como DSDM e Desenvolvimento guiado por característica, afirmam se aplicar a qualquer projeto de desenvolvimento ágil, sem importar suas características (Abrahamsonn et al., 2003).[3]
A comparação dos métodos ágeis ira 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.
Desenvolvimentos ágeis vêm sendo amplamente documentados (ver Experiências realatadas, abaixo, como também em Beck[4], e Boehm & Turner[5] como funcionando bem para equipes pequenas (< 10 desenvolvedores). O desenvolvimento ágil pe particularmente adequados para equipes que tem que lidar com mudanças nos requerimentos rápida ou imprevisíveis.
A aplicabilidade do desenvolvimento ágil para os seguintes cenários é ainda uma questão aberta:
- esforços de desenvolvimento em larga escala (> 20 desenvolvedores), embora estratégias para maiores escalas tenham sido descritas .[6]
- esforços de desenvolvimenteo distribuído (equipes não co-alocadas). Estas estratégias tem sido descritas em Bridging the Distance[7] e Using an Agile Software Process with Offshore Development[8]
- esforços críticos de missão e vida.
- Companhias com uma cultura de comando e controle.
Barry Boehm e Richard Turner sugeriram que analise de risco pode ser usada para escolher entre métodos adaptativos ("ágeis") e preditivos ("dirigidos pelo planejamento"). [5] Os autores sugerem que cada lado deste continuo possui seu ambiente ideal"
ambiente ideal para o desenvolvimento ágil:
- Baixa criticidade
- Desenvolvedores senior
- Mudanças freqüente de requerimentos
- Pequeno número de desenvolvedores
- Cultura que tem sucesso no caos.
ambiente ideal para o desenvolvimento direcionado ao planejamento
- Alta criticidade
- Desenvolvedores Junior
- Baixa mudança nos requerimentos
- Grande número de desenvolvedores
- Cultura que procura a ordem.
[editar] Adaptabilidade dos metodos ágeis
Um método deve ser bastante flexível para permitir ajustes durante a execução do projeto. Há três problemas chaves relacionados ao tópico de adaptação dos métodos ágeis: a aplicabilidade dos métodos ágeis (no geral e no particular), e finalmente, o suporte ao gerenciamento de projeto.
[editar] Métodos ágeis e o gerenciamento de projeto
Os métodos ágeis diferem largamente no que diz respeito a forma de serem gerenciados. Algum métodos são suplementados com guias para direcionar o gerenciamento do projeto, mas estas não geralmente todas aplicáveis .[3].
PRINCE2 vem sendo tido como um sistema de gerenciamento de projeto complementar e adequado. .[9]
Uma das caracteristicas em comum dos processos ágeis é a capacidade de funcionar em ambientes muito exigentes que tem um grande numero de incertezas e flutuações (mudanças) que podem vir de varios fontes como: equipe em processo de formação ainda não trabalharam juntos em outros projetos, requisitos volateis, baixo conhecimento do dominio de negocio pela equipe, adoção de novas tecnologias, novas ferramentas, mudanças muito bruscas e rapidas no ambiente de negocios das empresas: novos concorrentes, novos produtos, novos modelos de negocio.
Sistemas de gerencia de projetos lineares e prescritivos, em este tipo de ambientes, falham a oferecer as caracteristicas necesarias para poder responder de forma ágil as mudanças requeridas e a sua adoção acaba incrementado desnecesariamente o risco, custo e prazo e abaixando a qualidade do produto gerado, assim como desgastando a equipe e todos os envolvidos no processo.
Uma abordagem para gestão de projetos ágeis, que tem em consideração planejamento não linear, porem muito mais exaustivo e focado em criação de valor para o cliente e em risco, que fornece um ambiente seguro se da atraves do uso de Scrum focado na gestão do projeto aliado a uma metodologia de desenvolvimento como XP, FDD, OpenUP, DSDM, Crystal ou outras.
[editar] Metodologias
- Programação extrema
- Scrum
- DSDM
- Adaptive Software Development
- Crystal
- Feature-Driven Development
- Pragmatic Programming
- Test Driven Development
[editar] Criticas
O método de desenvolvimento ágil é algumas vezes criticados como codificação cowboy. O inicio da Programação extrema soava como controverso e dogmático, tal como a programação por pares e o projeto continuo, tem sido alvo particular de críticos, tais como McBreen[10] e Boehm e Turner.[5] Contudo, muito destas criticas tem sido vista pelos defensores dos métodos ágeis como mal entendidos a respeito do desenvolvimento ágil.[11]
Em particular, a Programação extrema é revista e criticada por Matt Stephens' Extreme Programming Refactored.[12]
As criticas incluem
- falta de estrutura e documentação necessárias
- somente trabalhar com desenvolvedores de nível sênior.
- incorpora de forma insuficiente o projeto de software
- requer a adoção de muita mudança cultural.
- poder levar a maiores dificuldades nas negociações contratuais
[editar] Referências
- ↑ B. Boehm. Balancing Agility and Discipline: A Guide for the Perplexed. 2.ed. Boston,MA: Addison-Wesley, 2004. 165-194 p. ISBN 0321186125
- ↑ 2,0 2,1 2,2 2,3 Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (pp. 1-66). New York: Elsevier Science.
- ↑ 3,0 3,1 Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254
- ↑ ">K. Beck. Extreme Programming Explained: Embrace Change. Boston, MA: 157 p.
- ↑ 5,0 5,1 5,2 B. Boehm. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley, {{{Ano}}}. 55-57 p.
- ↑ Supersize Me
- ↑ Bridging the Distance
- ↑ Using an Agile Software Process with Offshore Development
- ↑ Agile Alliance at http://agilealliancebeta.org/article/file/904/file.pdf:
- ↑ P. McBreen. {{{Título}}}. Boston, MA: Addison-Wesley, 2003.
- ↑ sdmagazine
- ↑ Extreme Programming Refactored
[editar] Futuras leituras
- Fowler, Martin. Is Design Dead?. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
- Riehle, Dirk. 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
- 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. [3]
- Larman, Craig and Basili, Victor R. 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.
- Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138
- Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24
- Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (pp. 1-66). New York: Elsevier Science.
- Karlstrom, D., & Runeson P. (2005). Combining agile methods with stage-gate project management. IEEE Software, 22(3), 43-49
