Desenvolvimento ágil de software

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

No desenvolvimento de software , as práticas ágeis (às vezes escritas como Agile ) [1] incluem descoberta de requisitos e melhoria de soluções por meio do esforço colaborativo de equipes auto-organizadas e multifuncionais com seus clientes / usuários finais , [2] adaptáveis planejamento, desenvolvimento evolutivo, entrega antecipada, melhoria contínua e respostas flexíveis a mudanças nos requisitos, capacidade e compreensão dos problemas a serem resolvidos. [3] [4]

Popularizados no Manifesto de 2001 para o Desenvolvimento Ágil de Software , [5] esses valores e princípios foram derivados e sustentam uma ampla gama de estruturas de desenvolvimento de software , incluindo Scrum e Kanban . [6] [7]

Embora haja muitas evidências anedóticas de que a adoção de práticas e valores ágeis melhora a eficácia de profissionais, equipes e organizações de software, a evidência empírica é mista e difícil de encontrar. [8] [9]

História [ editar ]

Métodos de desenvolvimento de software iterativos e incrementais podem ser rastreados desde 1957, [10] com gerenciamento de projetos evolucionário [11] [12] e desenvolvimento de software adaptativo [13] surgindo no início dos anos 1970. [14]

Durante a década de 1990, vários métodos leves de desenvolvimento de software evoluíram em reação aos métodos pesados predominantes (geralmente chamados coletivamente de cascata ) que os críticos descreveram como excessivamente regulamentados, planejados e microgerenciados . Métodos leves incluíram: desenvolvimento rápido de aplicativos (RAD), de 1991; [15] [16] o processo unificado (UP) e o método de desenvolvimento dinâmico de sistemas (DSDM), ambos de 1994; Scrum , de 1995; Crystal Clear e Extreme Programming (XP), ambos de 1996; e desenvolvimento orientado a recursos, de 1997. Embora todos tenham se originado antes da publicação do Agile Manifesto , agora são chamados coletivamente de métodos ágeis de desenvolvimento de software. [7] Ao mesmo tempo, mudanças semelhantes estavam em andamento na fabricação [17] [18] e no pensamento gerencial [ carece de fontes ] .

Em 2001, dezessete desenvolvedores de software se reuniram em um resort em Snowbird , Utah , para discutir métodos leves de desenvolvimento. Eles foram: Kent Beck (Extreme Programming), Ward Cunningham (Extreme Programming), Dave Thomas (Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim Highsmith (Adaptive Software Development), Alistair Cockburn (Behavior-Driven Development) ), Robert C. Martin ( SOLID ), Mike Beedle (Scrum), Arie van Bennekum , Martin Fowler (OOAD e UML), James Grenning,Andrew Hunt , Ron Jeffries (Programação Extrema), Jon Kern , Brian Marick (Ruby, TDD) e Steve Mellor (OOA). Juntos, eles publicaram o Manifesto para o Desenvolvimento Ágil de Software . [5]

Em 2005, um grupo liderado por Cockburn e Highsmith escreveu um adendo de princípios de gerenciamento de projetos , a Declaração de Interdependência do PM, [19] para orientar o gerenciamento de projetos de software de acordo com métodos ágeis de desenvolvimento de software.

Em 2009, um grupo trabalhando com Martin escreveu uma extensão dos princípios de desenvolvimento de software , o Software Craftsmanship Manifesto , para orientar o desenvolvimento ágil de software de acordo com a conduta e o domínio profissional .

Em 2011, a Agile Alliance criou o Guide to Agile Practices (renomeado para Agile Glossary em 2016), [20] um compêndio de código aberto em evolução das definições de trabalho de práticas, termos e elementos ágeis, juntamente com interpretações e diretrizes de experiência de a comunidade mundial de praticantes ágeis.

O Manifesto para o Desenvolvimento Ágil de Software [ editar ]

Valores de desenvolvimento de software ágil [ editar ]

Com base em sua experiência combinada de desenvolver software e ajudar outros a fazer isso, os dezessete signatários do manifesto proclamaram que valorizam: [5]

  • Indivíduos e interações sobre processos e ferramentas
  • Software funcionando sobre documentação abrangente
  • Colaboração do cliente sobre a negociação do contrato
  • Responder à mudança ao invés de seguir um plano

Ou seja, enquanto os dois lados têm valor e os itens da direita devem ser considerados, os autores do manifesto optaram por inclinar a balança a favor dos itens da esquerda.

Como Scott Ambler elucidou: [21]

  • Ferramentas e processos são importantes, mas é mais importante ter pessoas competentes trabalhando juntas de forma eficaz.
  • Uma boa documentação é útil para ajudar as pessoas a entender como o software é construído e como usá-lo, mas o ponto principal do desenvolvimento é criar software, não documentação.
  • Um contrato é importante, mas não substitui o trabalho próximo com os clientes para descobrir o que eles precisam.
  • Um plano de projeto é importante, mas não deve ser rígido demais para acomodar mudanças na tecnologia ou no ambiente, as prioridades das partes interessadas e a compreensão das pessoas sobre o problema e sua solução.

Alguns dos autores formaram a Agile Alliance, uma organização sem fins lucrativos que promove o desenvolvimento de software de acordo com os valores e princípios do manifesto. Apresentando o manifesto em nome da Agile Alliance, Jim Highsmith disse:

O movimento ágil não é anti-metodologia, na verdade muitos de nós querem restaurar a credibilidade da palavra metodologia. Queremos restabelecer o equilíbrio. Abraçamos a modelagem, mas não para arquivar algum diagrama em um repositório corporativo empoeirado. Aceitamos a documentação, mas não centenas de páginas de tomos nunca mantidos e raramente usados. Planejamos, mas reconhecemos os limites do planejamento em um ambiente turbulento. Aqueles que classificariam os proponentes do XP ou SCRUM ou qualquer outra Metodologia Ágil como "hackers" ignoram tanto as metodologias quanto a definição original do termo hacker.

—  Jim Highsmith, History: The Agile Manifesto [22]

Princípios de desenvolvimento ágil de software [ editar ]

O Manifesto para o Desenvolvimento Ágil de Software é baseado em doze princípios: [23]

  1. Satisfação do cliente pela entrega antecipada e contínua de software valioso.
  2. Bem-vindo à mudança de requisitos, mesmo em desenvolvimento tardio.
  3. Entregar software funcionando com frequência (semanas em vez de meses)
  4. Cooperação estreita e diária entre empresários e desenvolvedores
  5. Os projetos são construídos em torno de indivíduos motivados, em quem se deve confiar
  6. A conversa cara a cara é a melhor forma de comunicação (co-location)
  7. Software funcionando é a principal medida de progresso
  8. Desenvolvimento sustentável, capaz de manter um ritmo constante
  9. Atenção contínua à excelência técnica e bom design
  10. Simplicidade - a arte de maximizar a quantidade de trabalho não feito - é essencial
  11. As melhores arquiteturas , requisitos e designs surgem de equipes auto-organizadas
  12. Regularmente, a equipe reflete sobre como se tornar mais eficaz e se ajusta de acordo

Visão geral [ editar ]

Programação em pares , uma técnica de desenvolvimento ágil usada pelo XP .

Iterativo, incremental e evolucionário [ editar ]

A maioria dos métodos de desenvolvimento ágil divide o trabalho de desenvolvimento de produtos em pequenos incrementos que minimizam a quantidade de planejamento e design iniciais. Iterações, ou sprints, são prazos curtos ( timeboxes ) que normalmente duram de uma a quatro semanas. Cada iteração envolve uma equipe multifuncional trabalhando em todas as funções: planejamento , análise , design , codificação , teste de unidade e teste de aceitação . No final da iteração, um produto funcional é demonstrado para as partes interessadas. Isso minimiza o risco geral e permite que o produto se adapte às mudanças rapidamente. [24]Uma iteração pode não adicionar funcionalidade suficiente para garantir um lançamento no mercado, mas o objetivo é ter um lançamento disponível (com o mínimo de bugs ) no final de cada iteração. [25] Por meio do desenvolvimento incremental, os produtos têm espaço para "falhar com frequência e cedo" ao longo de cada fase iterativa, em vez de drasticamente em uma data de lançamento final. [26] Várias iterações podem ser necessárias para lançar um produto ou novos recursos. Software funcionando é a principal medida de progresso. [23]

Uma das principais vantagens da metodologia Agile é a velocidade de entrada no mercado e a mitigação de riscos. Incrementos menores são normalmente lançados no mercado, reduzindo os riscos de tempo e custo de engenharia de um produto que não atende aos requisitos do usuário.

Comunicação eficiente e cara a cara [ editar ]

O princípio da co-localização é que os colegas de trabalho da mesma equipe devem estar situados juntos para melhor estabelecer a identidade como equipe e melhorar a comunicação. [27] Isso permite a interação face a face , idealmente na frente de um quadro branco, o que reduz o tempo de ciclo normalmente tomado quando perguntas e respostas são mediadas por telefone, chat persistente, wiki ou e-mail. [28]

Não importa qual método de desenvolvimento seja seguido, toda equipe deve incluir um representante do cliente ("Product Owner" em Scrum ). Essa pessoa é acordada pelas partes interessadas em agir em seu nome e assume um compromisso pessoal de estar disponível para os desenvolvedores responderem a perguntas durante a iteração. No final de cada iteração, as partes interessadas (parte interessada ou parte interessada do projeto ? [ esclarecimento necessário ] ) e o representante do cliente revisam o progresso e reavaliam as prioridades com o objetivo de otimizar o retorno do investimento(ROI) e garantindo o alinhamento com as necessidades do cliente e os objetivos da empresa. A importância da satisfação das partes interessadas, detalhada pela interação e revisão frequente ao final de cada fase, é o motivo pelo qual a metodologia é muitas vezes denotada como uma “ metodologia centrada no cliente ”. [29]

No desenvolvimento ágil de software, um radiador de informações é uma tela física (normalmente grande), quadro com notas adesivas ou similar, localizado de forma proeminente perto da equipe de desenvolvimento, onde os transeuntes podem vê-lo. Apresenta um resumo atualizado do status de desenvolvimento do produto. [30] [31] Um indicador de luz de construção também pode ser usado para informar uma equipe sobre o status atual do desenvolvimento de seus produtos.

Ciclo de feedback e ciclo de adaptação muito curto [ editar ]

Uma característica comum no desenvolvimento ágil de software é o stand-up diário (conhecido como scrum diário no framework Scrum). Em uma breve sessão (por exemplo, 15 minutos), os membros da equipe analisam coletivamente como estão progredindo em direção à meta e concordam se precisam adaptar sua abordagem. Para cumprir o limite de tempo acordado, as equipes geralmente usam perguntas codificadas simples (como o que concluíram no dia anterior, o que pretendem concluir naquele dia e se existem impedimentos ou riscos para o progresso) e atrasam discussões detalhadas e problemas resolução até depois do stand-up. [32]

Foco de qualidade [ editar ]

Ferramentas e técnicas específicas, como integração contínua , teste de unidade automatizado , programação em pares , desenvolvimento orientado a testes , padrões de design , desenvolvimento orientado a comportamento , design orientado a domínio , refatoração de código e outras técnicas são frequentemente usadas para melhorar a qualidade e aprimorar o desenvolvimento de produtos agilidade. [33] Isso se baseia em projetar e construir qualidade desde o início e ser capaz de demonstrar software para clientes em qualquer ponto, ou pelo menos no final de cada iteração. [34]

Filosofia [ editar ]

Comparado à engenharia de software tradicional, o desenvolvimento de software ágil visa principalmente sistemas complexos e desenvolvimento de produtos com características dinâmicas, não determinísticas e não lineares. Estimativas precisas, planos estáveis ​​e previsões geralmente são difíceis de obter nos estágios iniciais, e a confiança neles provavelmente será baixa. Os praticantes ágeis procurarão reduzir o salto de fé necessário antes que qualquer evidência de valor possa ser obtida. [35]Requisitos e design são considerados emergentes. Grandes especificações iniciais provavelmente causariam muito desperdício nesses casos, ou seja, não são economicamente sólidas. Esses argumentos básicos e experiências anteriores da indústria, aprendidas com anos de sucessos e fracassos, ajudaram a moldar o desenvolvimento ágil a favor do desenvolvimento adaptativo, iterativo e evolutivo. [36]

Adaptável vs. preditivo [ editar ]

Os métodos de desenvolvimento existem em um continuum de adaptativo a preditivo . [37] Os métodos ágeis de desenvolvimento de software estão no lado adaptativo desse continuum. Uma chave dos métodos de desenvolvimento adaptativos é uma abordagem de onda contínua para o planejamento do cronograma, que identifica os marcos, mas deixa flexibilidade no caminho para alcançá-los e também permite que os próprios marcos mudem. [38]

Os métodos adaptativos se concentram na adaptação rápida às realidades em mudança. Quando as necessidades de um projeto mudam, uma equipe adaptável também muda. Uma equipe adaptativa tem dificuldade em descrever exatamente o que acontecerá no futuro. Quanto mais distante uma data, mais vago é um método adaptativo sobre o que acontecerá nessa data. Uma equipe adaptável não pode relatar exatamente quais tarefas farão na próxima semana, mas apenas quais recursos planejam para o próximo mês. Quando perguntado sobre um lançamento daqui a seis meses, uma equipe de adaptação poderá relatar apenas a declaração de missão do lançamento ou uma declaração de valor esperado versus custo.

Os métodos preditivos , por outro lado, concentram-se em analisar e planejar o futuro em detalhes e atendem a riscos conhecidos. Nos extremos, uma equipe preditiva pode relatar exatamente quais recursos e tarefas são planejados para todo o processo de desenvolvimento. Os métodos preditivos dependem de uma análise de fase inicial eficaz e, se isso der muito errado, o projeto pode ter dificuldade em mudar de direção. As equipes preditivas geralmente instituem um conselho de controle de mudanças para garantir que considerem apenas as mudanças mais valiosas.

A análise de risco pode ser usada para escolher entre métodos adaptativos ( ágeis ou orientados a valor ) e preditivos ( orientados a planos ). [39] Barry Boehm e Richard Turner sugerem que cada lado do continuum tem seu próprio terreno , como segue: [40]

Bases de diferentes métodos de desenvolvimento
Métodos orientados a valor Métodos orientados a planos Métodos formais
Baixa criticidade Alta criticidade Criticidade extrema
Desenvolvedores sênior Desenvolvedores júnior (?) Desenvolvedores sênior
Os requisitos mudam com frequência Os requisitos não mudam com frequência Requisitos limitados, recursos limitados, consulte a lei de Wirth [ esclarecimento necessário ]
Pequeno número de desenvolvedores Grande número de desenvolvedores Requisitos que podem ser modelados
Cultura que responde à mudança Cultura que exige ordem Qualidade extrema

Ágil vs. cascata [ editar ]

Uma das diferenças entre os métodos ágeis de desenvolvimento de software e a cascata é a abordagem de qualidade e teste. No modelo em cascata , o trabalho passa pelas fases do ciclo de vida de desenvolvimento de software (SDLC)—com uma fase sendo concluída antes que a outra possa começar—portanto, a fase de teste é separada e segue uma fase de construção . No desenvolvimento ágil de software, no entanto, o teste é concluído na mesma iteração da programação. Outra maneira de olhar para isso é “Ágil: invente à medida que avança. Cachoeira: invente antes de começar, viva com as consequências”. [41]

Como o teste é feito em cada iteração – que desenvolve uma pequena parte do software – os usuários podem usar com frequência esses novos pedaços de software e validar o valor. Depois que os usuários conhecem o valor real do software atualizado, eles podem tomar melhores decisões sobre o futuro do software. Ter uma retrospectiva de valor e uma sessão de replanejamento de software em cada iteração — o Scrum normalmente tem iterações de apenas duas semanas — ajuda a equipe a adaptar continuamente seus planos para maximizar o valor que entrega. Isso segue um padrão semelhante ao ciclo plan-do-check-act (PDCA), pois o trabalho é planejado , feito , verificado (na revisão e retrospectiva), e quaisquer mudanças acordadas são executadassobre.

Essa abordagem iterativa suporta um produto em vez de uma mentalidade de projeto . Isso proporciona maior flexibilidade em todo o processo de desenvolvimento; enquanto nos projetos os requisitos são definidos e bloqueados desde o início, tornando difícil alterá-los posteriormente. O desenvolvimento iterativo de produtos permite que o software evolua em resposta às mudanças no ambiente de negócios ou nos requisitos do mercado.

Código vs. documentação [ editar ]

Em uma carta ao IEEE Computer , Steven Rakitin expressou cinismo sobre o desenvolvimento ágil de software, chamando-o de " mais uma tentativa de minar a disciplina da engenharia de software " e traduzindo " software funcionando em documentação abrangente " como " queremos gastar todo o nosso tempo codificando". Lembre-se, programadores de verdade não escrevem documentação ." [42]

Isso é contestado pelos proponentes do desenvolvimento ágil de software, que afirmam que os desenvolvedores devem escrever documentação se essa for a melhor maneira de atingir as metas relevantes, mas que geralmente há maneiras melhores de atingir essas metas do que escrever documentação estática. [43] Scott Ambler afirma que a documentação deve ser "apenas boa o suficiente" (JBGE), [44] que documentação demais ou abrangente normalmente causaria desperdício, e os desenvolvedores raramente confiam na documentação detalhada porque geralmente está fora de sincronia com o código, [ 43] 43] , enquanto pouca documentação também pode causar problemas de manutenção, comunicação, aprendizado e compartilhamento de conhecimento. Alistair Cockburn escreveu sobre o método Crystal Clear :

Crystal considera o desenvolvimento uma série de jogos cooperativos, e pretende que a documentação seja suficiente para ajudar o próximo a vencer no próximo jogo. Os produtos de trabalho do Crystal incluem casos de uso, lista de riscos, plano de iteração, modelos de domínio principal e notas de design para informar sobre as escolhas ... documentação suficiente para o próximo jogo. Eu sempre costumo caracterizar isso para minha equipe como: o que você gostaria de saber se você se juntasse à equipe amanhã.

—  Alistair Cockburn [45]

Métodos ágeis de desenvolvimento de software [ editar ]

Suporte ao ciclo de vida de desenvolvimento de software [46]

Os métodos ágeis de desenvolvimento de software suportam uma ampla gama de ciclos de vida de desenvolvimento de software . [46] Alguns métodos focam nas práticas (por exemplo, XP , programação pragmática , modelagem ágil), enquanto alguns focam no gerenciamento do fluxo de trabalho (por exemplo, Scrum, Kanban). Algumas atividades de suporte para especificação e desenvolvimento de requisitos (por exemplo, FDD ), enquanto outras buscam cobrir todo o ciclo de vida de desenvolvimento (por exemplo, DSDM , RUP ).

Estruturas de desenvolvimento de software ágil notáveis ​​incluem:

Estrutura Principais colaboradores
Desenvolvimento de software adaptável (ASD) Jim HighsmithSam Bayer
Modelagem ágil Scott AmblerRobert Cecil Martin
Processo unificado ágil (AUP) Scott Ambler
Entrega ágil disciplinada Scott Ambler
Método de desenvolvimento de sistemas dinâmicos (DSDM)
Programação extrema (XP) Kent BeckRobert Cecil Martin
Desenvolvimento orientado a recursos (FDD) Jeff De Luca
Desenvolvimento de software enxuto Mary Poppendieck, Tom Poppendieck
Inicialização enxuta Eric Ries
Kanban Taiichi Ohno
Desenvolvimento rápido de aplicativos (RAD) James Martin
Scrum Ken SchwaberJeff Sutherland
Scrumban
Estrutura ágil dimensionada - SAFe Scaled Agile, Inc.

Práticas ágeis de desenvolvimento de software [ editar ]

O desenvolvimento ágil de software é suportado por uma série de práticas concretas, abrangendo áreas como requisitos, design, modelagem, codificação, teste, planejamento, gerenciamento de risco, processo, qualidade, etc. Algumas práticas notáveis ​​de desenvolvimento ágil de software incluem: [47]

Prática Principais colaboradores
Desenvolvimento orientado a testes de aceitação (ATDD)
Modelagem ágil
Testes ágeis
Backlogs (Produto e Sprint) Ken Schwaber
Desenvolvimento orientado por comportamento (BDD) Dan North, Liz Keogh
Integração contínua (CI) Grady Booch
Equipe multifuncional
Stand-up diário / Daily Scrum James O Coplien
Design orientado por domínio (DDD) Eric Evans
Desenvolvimento iterativo e incremental (IID)
Programação em pares Kent Beck
Planejamento de pôquer James Grenning, Mike Cohn
Reestruturação Martin Fowler
Retrospectivo
Eventos Scrum (planejamento de sprint, revisão de sprint e retrospectiva)
Especificação por exemplo
Modelagem orientada por histórias Albert Zündorf
Desenvolvimento orientado a testes (TDD) Kent Beck
Timeboxing
História do usuário Alistair Cockburn
Rastreamento de velocidade

Adaptação do método [ editar ]

Na literatura, diferentes termos referem-se à noção de adaptação de método, incluindo 'adaptação de método', 'adaptação de fragmento de método' e 'engenharia de método situacional'. A adaptação de métodos é definida como:

Um processo ou capacidade em que os agentes humanos determinam uma abordagem de desenvolvimento de sistema para uma situação de projeto específica por meio de mudanças responsivas e interações dinâmicas entre contextos, intenções e fragmentos de métodos.

—  Mehmet Nafiz Aydin et al., Um Método de Desenvolvimento de Sistemas de Informação Ágil em uso [48]

A adequação à situação deve ser considerada como uma característica distintiva entre métodos ágeis e métodos de desenvolvimento de software mais orientados a planos, com métodos ágeis permitindo que as equipes de desenvolvimento de produtos adaptem as práticas de trabalho de acordo com as necessidades de produtos individuais. [49] [48] Potencialmente, a maioria dos métodos ágeis pode ser adequada para a adaptação de métodos, [46] como o DSDM adaptado em um contexto CMM . [50] e XP adaptados com a técnica Rule Description Practices (RDP). [51]Nem todos os proponentes ágeis concordam, no entanto, com Schwaber observando "foi assim que tivemos problemas em primeiro lugar, pensando que o problema não era ter uma metodologia perfeita. Os esforços [deveriam] se concentrar nas mudanças [necessárias] na empresa" . [52] Bas Vodde reforçou esse ponto de vista, sugerindo que, diferentemente das grandes metodologias tradicionais que exigem que você escolha elementos, o Scrum fornece o básico sobre o qual você adiciona elementos adicionais para localizar e contextualizar seu uso. [53] Praticantes raramente usam métodos de desenvolvimento de sistemas , ou métodos ágeis especificamente, pelo livro, muitas vezes optando por omitir ou adaptar algumas das práticas de um método para criar um método interno. [54]

Na prática, os métodos podem ser adaptados usando várias ferramentas. As linguagens genéricas de modelagem de processos, como a Unified Modeling Language, podem ser usadas para adaptar os métodos de desenvolvimento de software. No entanto, também existem ferramentas dedicadas à engenharia de métodos, como a Teoria da Essência da Engenharia de Software da SEMAT . [55]

Em larga escala, offshore e distribuído [ editar ]

O desenvolvimento ágil de software tem sido amplamente visto como altamente adequado para certos tipos de ambientes, incluindo pequenas equipes de especialistas trabalhando em projetos greenfield , [40] [56] : 157  e os desafios e limitações encontrados na adoção de métodos de desenvolvimento ágil de software em um grande organização com infraestrutura legada são bem documentados e compreendidos. [57]

Em resposta, uma variedade de estratégias e padrões evoluiu para superar desafios com esforços de desenvolvimento em larga escala (> 20 desenvolvedores) [58] [59] ou equipes de desenvolvimento distribuídas (não localizadas), [60] [61] entre outros desafios ; e agora existem várias estruturas reconhecidas que buscam mitigar ou evitar esses desafios.

Existem muitos pontos de vista conflitantes sobre se todos eles são eficazes ou se encaixam na definição de desenvolvimento ágil, e isso continua sendo uma área de pesquisa ativa e contínua. [58] [70]

Quando o desenvolvimento ágil de software é aplicado em um ambiente distribuído (com equipes dispersas em vários locais de negócios), geralmente é chamado de desenvolvimento ágil distribuído de software . O objetivo é aproveitar os benefícios exclusivos oferecidos por cada abordagem. O desenvolvimento distribuído permite que as organizações criem software configurando equipes estrategicamente em diferentes partes do globo, criando software virtualmente 24 horas por dia (mais comumente referido como modelo follow-the-sun). Por outro lado, o desenvolvimento ágil fornece maior transparência, feedback contínuo e mais flexibilidade ao responder às mudanças.

Domínios regulamentados [ editar ]

Os métodos ágeis de desenvolvimento de software foram inicialmente vistos como mais adequados para desenvolvimentos de produtos não críticos, portanto, excluídos do uso em domínios regulamentados, como dispositivos médicos , farmacêutico, financeiro, sistemas nucleares, automotivo e aviônico, etc. anos, houve várias iniciativas para a adaptação de métodos ágeis para esses domínios. [71] [72] [73] [74] [75]

Existem vários padrões que podem ser aplicados em domínios regulamentados, incluindo ISO 26262 , ISO 9000 , ISO 9001 e ISO/IEC 15504 . Uma série de preocupações-chave são de particular importância em domínios regulamentados: [76]

  • Garantia de qualidade (QA): Gestão de qualidade sistemática e inerente que sustenta um processo profissional controlado e confiabilidade e correção do produto.
  • Segurança e proteção: planejamento formal e gerenciamento de riscos para mitigar os riscos de segurança para os usuários e proteger os usuários com segurança contra uso indevido não intencional e mal-intencionado.
  • Rastreabilidade : Documentação que fornece evidência auditável de conformidade regulatória e facilita a rastreabilidade e a investigação de problemas.
  • Verificação e validação (V&V): Embutidos em todo o processo de desenvolvimento de software (por exemplo, especificação de requisitos do usuário, especificação funcional, especificação de projeto, revisão de código, testes de unidade, testes de integração, testes de sistema).

Experiência e adoção [ editar ]

Embora os métodos ágeis de desenvolvimento de software possam ser usados ​​com qualquer paradigma ou linguagem de programação na prática, eles foram originalmente associados a ambientes orientados a objetos, como Smalltalk, Lisp e, posteriormente, Java, C#. Os adotantes iniciais de métodos ágeis eram geralmente equipes de pequeno a médio porte trabalhando em sistemas sem precedentes com requisitos difíceis de finalizar e que provavelmente mudariam à medida que o sistema estava sendo desenvolvido. Esta seção descreve problemas comuns que as organizações encontram quando tentam adotar métodos ágeis de desenvolvimento de software, bem como várias técnicas para medir a qualidade e o desempenho de equipes ágeis. [77]

Medindo a agilidade [ editar ]

Avaliações internas [ editar ]

O índice de medição de Agilidade , entre outros, classifica os desenvolvimentos em relação a cinco dimensões do desenvolvimento de produtos (duração, risco, novidade, esforço e interação). [78] Outras técnicas são baseadas em metas mensuráveis [79] e um estudo sugere que a velocidade pode ser usada como uma métrica de agilidade. Há também autoavaliações ágeis para determinar se uma equipe está usando práticas de desenvolvimento de software ágil (teste Nokia, [80] teste Karlskrona, [81] teste de 42 pontos). [82]

Pesquisas públicas [ editar ]

Um dos primeiros estudos relatando ganhos em qualidade, produtividade e satisfação do negócio usando métodos ágeis de desenvolvimento de software foi uma pesquisa realizada pela Shine Technologies de novembro de 2002 a janeiro de 2003. [83]

Uma pesquisa semelhante, o State of Agile , é realizada todos os anos a partir de 2006 com milhares de participantes de toda a comunidade de desenvolvimento de software. Isso rastreia tendências sobre os benefícios percebidos de agilidade, lições aprendidas e boas práticas. Cada pesquisa relatou números crescentes dizendo que o desenvolvimento ágil de software os ajuda a entregar software mais rapidamente; melhora sua capacidade de gerenciar mudanças nas prioridades dos clientes; e aumenta sua produtividade. [84] As pesquisas também mostraram consistentemente melhores resultados com métodos ágeis de desenvolvimento de produtos em comparação com o gerenciamento de projetos clássico. [85] [86]Em suma, há relatos de que alguns acham que os métodos de desenvolvimento ágil ainda são muito jovens para permitir uma extensa pesquisa acadêmica sobre seu sucesso. [87]

Armadilhas comuns de desenvolvimento de software ágil [ editar ]

Organizações e equipes que implementam o desenvolvimento ágil de software geralmente enfrentam dificuldades na transição de métodos mais tradicionais, como desenvolvimento em cascata , como equipes que têm um processo ágil imposto a elas. [88] Estes são frequentemente denominados anti-padrões ágeis ou cheiros mais ágeis . Abaixo estão alguns exemplos comuns:

Falta de design geral do produto [ editar ]

Um objetivo do desenvolvimento ágil de software é focar mais na produção de software funcional e menos na documentação. Isso contrasta com os modelos em cascata, onde o processo geralmente é altamente controlado e pequenas alterações no sistema exigem uma revisão significativa da documentação de suporte. No entanto, isso não justifica ficar completamente sem nenhuma análise ou projeto. A falha em prestar atenção ao design pode fazer com que uma equipe prossiga rapidamente no início, mas depois tenha um retrabalho significativo necessário à medida que tentam expandir o sistema. Uma das principais características do desenvolvimento ágil de software é que ele é iterativo. Quando feito corretamente, o design surge à medida que o sistema é desenvolvido e as semelhanças e oportunidades de reutilização são descobertas. [89]

Adicionando histórias a uma iteração em andamento [ editar ]

No desenvolvimento ágil de software, as histórias (semelhantes às descrições dos casos de uso ) são normalmente usadas para definir os requisitos e uma iteração é um curto período de tempo durante o qual a equipe se compromete com objetivos específicos. [90] Adicionar histórias a uma iteração em andamento é prejudicial para um bom fluxo de trabalho. Eles devem ser adicionados ao backlog do produto e priorizados para uma iteração subsequente ou, em casos raros, a iteração pode ser cancelada. [91]

Isso não significa que uma história não pode se expandir. As equipes devem lidar com novas informações, que podem produzir tarefas adicionais para uma história. Se a nova informação impedir que a história seja concluída durante a iteração, ela deve ser transferida para uma iteração subsequente. No entanto, deve ser priorizado em relação a todas as histórias restantes, pois as novas informações podem ter alterado a prioridade original da história.

Falta de apoio do patrocinador [ editar ]

O desenvolvimento ágil de software é frequentemente implementado como um esforço de base nas organizações por equipes de desenvolvimento de software que tentam otimizar seus processos de desenvolvimento e garantir consistência no ciclo de vida de desenvolvimento de software. Por não ter apoio de patrocinadores, as equipes podem enfrentar dificuldades e resistências de parceiros de negócios, outras equipes de desenvolvimento e gestão. Além disso, eles podem sofrer sem financiamento e recursos adequados. [92] Isso aumenta a probabilidade de falha. [93]

Treinamento insuficiente [ editar ]

Uma pesquisa realizada pela VersionOne descobriu que os entrevistados citaram o treinamento insuficiente como a causa mais significativa para falhas nas implementações ágeis [94] As equipes caíram na armadilha de assumir que os processos reduzidos de desenvolvimento de software ágil em comparação com outras metodologias, como cascata, significam que não há regras para o desenvolvimento ágil de software. [ citação necessária ]

A função de proprietário do produto não foi preenchida corretamente [ editar ]

O proprietário do produto é responsável por representar o negócio na atividade de desenvolvimento e muitas vezes é o papel mais exigente. [95]

Um erro comum é ter a função de proprietário do produto preenchida por alguém da equipe de desenvolvimento. Isso exige que a equipe tome suas próprias decisões sobre priorização sem feedback real do negócio. Eles tentam resolver problemas de negócios internamente ou atrasam o trabalho à medida que chegam fora da equipe para obter orientação. Isso geralmente leva à distração e a um colapso na colaboração. [96]

As equipes não estão focadas [ editar ]

O desenvolvimento ágil de software exige que as equipes cumpram os compromissos do produto, o que significa que devem se concentrar no trabalho apenas para esse produto. No entanto, espera-se que os membros da equipe que parecem ter capacidade ociosa assumam outros trabalhos, o que dificulta que eles ajudem a concluir o trabalho com o qual sua equipe se comprometeu. [97]

Preparação/planejamento excessivo [ editar ]

As equipes podem cair na armadilha de gastar muito tempo preparando ou planejando. Essa é uma armadilha comum para equipes menos familiarizadas com o desenvolvimento ágil de software, onde as equipes se sentem obrigadas a ter um entendimento e especificação completos de todas as histórias. As equipes devem estar preparadas para avançar apenas com as histórias nas quais têm confiança e, durante a iteração, continuar a descobrir e preparar o trabalho para as iterações subsequentes (geralmente chamadas de refinamento ou preparação do backlog).

Resolução de problemas no standup diário [ editar ]

Uma reunião diária deve ser uma reunião focada e oportuna, onde todos os membros da equipe divulgam informações. Se a solução de problemas ocorrer, muitas vezes pode envolver apenas alguns membros da equipe e potencialmente não é o melhor uso do tempo de toda a equipe. Se durante a reunião diária a equipe começar a mergulhar na resolução de problemas, isso deve ser deixado de lado até que uma subequipe possa discutir, geralmente imediatamente após a conclusão da reunião. [98]

Atribuindo tarefas [ editar ]

Um dos benefícios pretendidos do desenvolvimento ágil de software é capacitar a equipe a fazer escolhas, pois estão mais próximas do problema. Além disso, eles devem fazer escolhas o mais próximo possível da implementação, para usar informações mais oportunas na decisão. Se os membros da equipe receberem tarefas atribuídas por outros ou muito cedo no processo, os benefícios da tomada de decisões localizada e oportuna podem ser perdidos. [99]

O trabalho atribuído também restringe os membros da equipe a determinadas funções (por exemplo, o membro da equipe A deve sempre fazer o trabalho do banco de dados), o que limita as oportunidades de treinamento cruzado. [99] Os próprios membros da equipe podem optar por assumir tarefas que aumentam suas habilidades e oferecem oportunidades de treinamento cruzado.

Scrum master como contribuidor [ editar ]

Na metodologia Scrum, que é uma metodologia popular que afirma ser consistente com os valores e princípios ágeis, um scrum master é a pessoa responsável por garantir que o processo scrum esteja ocorrendo e treinar a equipe scrum durante esse processo. Uma armadilha comum é um scrum master atuar como um contribuidor. Embora não seja proibido pela metodologia Scrum, o scrum master precisa garantir que ele tenha a capacidade de agir primeiro no papel de scrum master e não trabalhar em tarefas de desenvolvimento. O papel de um scrum master é facilitar o processo em vez de criar o produto. [100]

Ter o scrum master também multitarefa pode resultar em muitas trocas de contexto para ser produtivo. Além disso, como um scrum master é responsável por garantir que os bloqueios sejam removidos para que a equipe possa progredir, o benefício obtido pelo avanço das tarefas individuais pode não superar os bloqueios adiados devido à falta de capacidade. [101]

Falta de automação de teste [ editar ]

Devido à natureza iterativa do desenvolvimento ágil, muitas vezes são necessárias várias rodadas de testes. O teste automatizado ajuda a reduzir o impacto de testes repetidos de unidade, integração e regressão e libera desenvolvedores e testadores para se concentrarem em trabalhos de maior valor. [102]

A automação de teste também oferece suporte à refatoração contínua exigida pelo desenvolvimento de software iterativo. Permitir que um desenvolvedor execute testes rapidamente para confirmar que a refatoração não modificou a funcionalidade do aplicativo pode reduzir a carga de trabalho e aumentar a confiança de que os esforços de limpeza não introduziram novos defeitos.

Permitindo que a dívida técnica se acumule [ editar ]

Concentrar-se na entrega de novas funcionalidades pode resultar em aumento da dívida técnica . A equipe deve se permitir tempo para correção de defeitos e refatoração. A dívida técnica dificulta as habilidades de planejamento, aumentando a quantidade de trabalho não programado, pois os defeitos de produção distraem a equipe do progresso. [103]

À medida que o sistema evolui, é importante refatorar à medida que a entropia do sistema aumenta naturalmente. [104] Com o tempo, a falta de manutenção constante causa defeitos crescentes e custos de desenvolvimento. [103]

Tentando assumir muito em uma iteração [ editar ]

Um equívoco comum é que o desenvolvimento ágil de software permite mudanças contínuas, no entanto, um backlog de iteração é um acordo de qual trabalho pode ser concluído durante uma iteração. [105] Ter muito trabalho em andamento (WIP) resulta em ineficiências, como alternância de contexto e enfileiramento. [106] A equipe deve evitar se sentir pressionada a assumir trabalho adicional. [107]

Tempo fixo, recursos, escopo e qualidade [ editar ]

O desenvolvimento ágil de software corrige o tempo (duração da iteração), a qualidade e, idealmente, os recursos com antecedência (embora a manutenção de recursos fixos possa ser difícil se os desenvolvedores forem frequentemente afastados das tarefas para lidar com incidentes de produção), enquanto o escopo permanece variável. O cliente ou proprietário do produto geralmente pressiona por um escopo fixo para uma iteração. No entanto, as equipes devem relutar em se comprometer com o tempo, recursos e escopo bloqueados (comumente conhecido como triângulo de gerenciamento de projetos ). Esforços para adicionar escopo ao tempo e recursos fixos do desenvolvimento ágil de software podem resultar em diminuição da qualidade. [108]

Burnout do desenvolvedor [ editar ]

Devido ao ritmo focado e à natureza contínua das práticas ágeis, há um risco aumentado de esgotamento entre os membros da equipe de entrega. [109]

Gerenciamento ágil [ editar ]

O gerenciamento ágil de projetos é um processo de desenvolvimento iterativo, em que o feedback é coletado continuamente de usuários e partes interessadas para criar a experiência correta do usuário. Diferentes métodos podem ser usados ​​para realizar um processo ágil, incluindo scrum , programação extrema , lean e kanban . [110] O termo gestão ágil é aplicado a um método iterativo e incremental de gerenciar as atividades de projeto e construção de engenharia, tecnologia da informação e outras áreas de negócios que visam fornecer o desenvolvimento de novos produtos ou serviços de maneira altamente flexível e interativa, com base em os princípios expressos no Manifesto para o Desenvolvimento Ágil de Software .[111] Métricas de gerenciamento de projetos ágeis ajudam a reduzir a confusão, identificar pontos fracos e medir o desempenho da equipe ao longo do ciclo de desenvolvimento. A agilidade da cadeia de suprimentos é a capacidade de uma cadeia de suprimentos de lidar com a incerteza e a variabilidade na oferta e na demanda. Uma cadeia de suprimentos ágil pode aumentar e reduzir sua capacidade rapidamente, para que possa se adaptar a uma demanda de clientes em constante mudança. Finalmente, a agilidade estratégica é a capacidade de uma organização de mudar seu curso de ação à medida que seu ambiente está evoluindo. A chave para a agilidade estratégica é reconhecer as mudanças externas com antecedência suficiente e alocar recursos para se adaptar a esses ambientes em mudança. [112]

As técnicas Agile X também podem ser chamadas de gerenciamento de projetos extremos . É uma variante do ciclo de vida iterativo [113] onde as entregas são submetidas em etapas. A principal diferença entre desenvolvimento ágil e iterativo é que os métodos ágeis completam pequenas porções das entregas em cada ciclo de entrega (iteração), [114]enquanto os métodos iterativos evoluem todo o conjunto de entregas ao longo do tempo, completando-as perto do final do projeto. Ambos os métodos iterativos e ágeis foram desenvolvidos como uma reação a vários obstáculos que se desenvolveram em formas mais sequenciais de organização de projetos. Por exemplo, à medida que os projetos de tecnologia crescem em complexidade, os usuários finais tendem a ter dificuldade em definir os requisitos de longo prazo sem poder visualizar protótipos progressivos. Projetos que se desenvolvem em iterações podem coletar feedback constantemente para ajudar a refinar esses requisitos.

O gerenciamento ágil também oferece uma estrutura simples que promove a comunicação e a reflexão sobre o trabalho passado entre os membros da equipe . [115] As equipes que estavam usando o planejamento tradicional em cascata e adotaram o modo ágil de desenvolvimento normalmente passam por uma fase de transformação e geralmente recebem ajuda de coaches ágeis que ajudam a orientar as equipes por uma transformação mais suave. Normalmente, existem dois estilos de coaching ágil: coaching ágil baseado em push e pull-based . Aqui, um "sistema push" pode se referir a uma estimativa inicial de quais tarefas podem ser encaixadas em um sprint (trabalho push), por exemplo, típico com scrum; enquanto um "sistema puxado" pode se referir a um ambiente onde as tarefas são executadas apenas quando o trabalho está disponível, por exemplo, típico para kanban. [esclarecimento necessário ]As abordagens de gerenciamento ágil também foram empregadas e adaptadas aos setores empresarial e governamental. Por exemplo, dentro dogoverno federal dos Estados Unidos, aAgência dos Estados Unidos para o Desenvolvimento Internacional(USAID) está empregando umade gerenciamento de projetos colaborativosque se concentra na incorporaçãocolaboração, aprendizado e adaptação(CLA) para iterar e adaptar a programação. [116]

Os métodos ágeis são mencionados no Guia do Conhecimento em Gerenciamento de Projetos ( Guia PMBOK ) na definição do Ciclo de Vida do Projeto:

Ciclo de vida do projeto adaptativo , um ciclo de vida do projeto, também conhecido como métodos ágeis ou orientados a mudanças, que se destina a facilitar a mudança e requer um alto grau de envolvimento contínuo das partes interessadas . Os ciclos de vida adaptativos também são iterativos e incrementais, mas diferem porque as iterações são muito rápidas (geralmente 2-4 semanas de duração) e são fixas em tempo e recursos . [117]

Aplicações fora do desenvolvimento de software [ editar ]

Conferência Agile Brasil 2014

De acordo com Jean-Loup Richet (bolsista de pesquisa do ESSEC Institute for Strategic Innovation & Services) "essa abordagem pode ser aproveitada de forma eficaz para produtos que não são de software e para gerenciamento de projetos em geral, especialmente em áreas de inovação e incerteza". O resultado final é um produto ou projeto que melhor atende às necessidades atuais do cliente e é entregue com custos, desperdício e tempo mínimos, permitindo que as empresas obtenham ganhos de linha de fundo mais cedo do que por meio de abordagens tradicionais. [118]

Os métodos ágeis de desenvolvimento de software têm sido amplamente utilizados para o desenvolvimento de produtos de software e alguns deles usam certas características do software, como tecnologias de objetos . [119] No entanto, essas técnicas podem ser aplicadas ao desenvolvimento de produtos não-software, como computadores, dispositivos médicos, alimentos, roupas e música. [120] Métodos ágeis de desenvolvimento de software têm sido usados ​​em implantações e migrações de infraestrutura de TI sem desenvolvimento . Alguns dos princípios mais amplos do desenvolvimento ágil de software também encontraram aplicação na gestão geral [121] (por exemplo, estratégia, governança, risco, finanças) sob os termos agilidade de negóciosou gestão empresarial ágil.

Paradigmas de desenvolvimento de software ágil podem ser usados ​​em outras áreas da vida, como criar filhos. Seu sucesso no desenvolvimento infantil pode ser baseado em alguns princípios básicos de gestão; comunicação, adaptação e conscientização. Em uma TED Talk , Bruce Feiler compartilhou como ele aplicou os paradigmas ágeis básicos ao gerenciamento doméstico e à criação dos filhos. [122]

Críticas [ editar ]

As práticas ágeis têm sido citadas como potencialmente ineficientes em grandes organizações e certos tipos de desenvolvimento. [123] Muitas organizações acreditam que as metodologias de desenvolvimento ágil de software são muito extremas e adotam uma abordagem híbrida [124] que mistura elementos de desenvolvimento ágil de software e abordagens orientadas a planos. [125] Alguns métodos, como o método de desenvolvimento dinâmico de sistemas (DSDM) tentam isso de forma disciplinada, sem sacrificar princípios fundamentais.

A crescente adoção de práticas ágeis também tem sido criticada como sendo uma moda de gerenciamento que simplesmente descreve as boas práticas existentes sob um novo jargão, promove uma mentalidade de tamanho único para estratégias de desenvolvimento e enfatiza erroneamente o método sobre os resultados. [126]

Alistair Cockburn organizou uma celebração do 10º aniversário do Manifesto para o Desenvolvimento de Software Ágil em Snowbird, Utah em 12 de fevereiro de 2011, reunindo cerca de 30+ pessoas que estiveram envolvidas na reunião original e desde então. Uma lista de cerca de 20 elefantes na sala (tópicos/questões ágeis 'indiscutíveis') foi coletada, incluindo aspectos: as alianças, falhas e limitações das práticas e contexto de desenvolvimento ágil de software (causas possíveis: interesses comerciais, descontextualização, nenhuma maneira óbvia de progredir com base no fracasso, evidências objetivas limitadas, vieses cognitivos e falácias de raciocínio), política e cultura. [127] Como Philippe Kruchten escreveu:

O movimento ágil é, de certa forma, um pouco como um adolescente: muito autoconsciente, verificando constantemente sua aparência no espelho, aceitando poucas críticas, interessado apenas em estar com seus pares, rejeitando em bloco toda sabedoria do passado, apenas porque é do passado, adotando modismos e novos jargões, às vezes arrogante e arrogante. Mas não tenho dúvidas de que amadurecerá ainda mais, se tornará mais aberto ao mundo exterior, mais reflexivo e, portanto, mais eficaz.

—  Philippe Kruchten [127]

O "Manifesto" pode ter tido um impacto negativo na gestão e liderança do ensino superior, onde sugeriu aos gestores que os processos tradicionais e deliberativos mais lentos deveriam ser substituídos por outros mais 'ágeis'. O conceito raramente encontrou aceitação entre os professores universitários. [128]

Outra crítica é que, em muitos aspectos, o gerenciamento ágil e as práticas tradicionais de gerenciamento acabam se opondo. Uma crítica comum a essa prática é que o tempo gasto tentando aprender e implementar a prática é muito caro, apesar dos benefícios potenciais. A transição do gerenciamento tradicional para o gerenciamento ágil requer submissão total ao Agile e um firme compromisso de todos os membros da organização em acompanhar o processo. Questões como resultados desiguais em toda a organização, muita mudança para a capacidade dos funcionários de lidar ou falta de garantias no final da transformação são apenas alguns exemplos. [129]

Veja também [ editar ]

Referências [ editar ]

  1. ^ Reunião (2010). "Agile com "A" maiúsculo vs. ágil com "a" minúsculo" . Arquivado do original em 5 de janeiro de 2016 . Recuperado em 9 de setembro de 2015 .{{cite web}}: CS1 maint: unfit URL (link)
  2. ^ Collier, Ken W. (2011). Agile Analytics: Uma Abordagem Orientada a Valor para Business Intelligence e Data Warehousing . Pearson Educação. pág. 121 e segs. ISBN 9780321669544. O que é uma equipe auto-organizada?
  3. ^ Beck, Kent M.; Beedle, Mike; Bennekum, Arie van; Cockburn, Alistair; Cunningham, Ward; Fowler, Martin; Grenning, James; Highsmith, Jim; Hunt, Andy; Jeffries, Ron; Kern, Jon; Marick, Brian; Martin, RC; Mellor, Steve J.; Schwaber, Ken; Sutherland, Jeff; Thomas, Davi. "Manifesto para o Desenvolvimento de Software Ágil". S2CID 109006295 .  {{cite journal}}: Cite journal requires |journal= (help)
  4. ^ "O que é desenvolvimento de software ágil?" . Aliança Ágil. 8 de junho de 2013 . Recuperado em 4 de abril de 2015 .
  5. ^ a b c Kent Beck ; James Grenning; Robert C. Martin ; Mike Beedle; Jim Highsmith ; Steve Mellor ; Arie van Bennekum; André Hunt ; Ken Schwaber ; Alistair Cockburn ; Ron Jeffries ; Jeff Sutherland ; Ward Cunningham ; Jon Kern; Davi Thomas ; Martin Fowler ; Brian Marick (2001). "Manifesto para Desenvolvimento Ágil de Software" . Aliança Ágil . Recuperado em 14 de junho de 2010 .{{cite web}}: CS1 maint: url-status (link)
  6. ^ Qual é melhor – Kanban ou Scrum? , 4 de março de 2016
  7. ^ a b Larman, Craig (2004). Desenvolvimento ágil e iterativo: um guia do gerente . Addison-Wesley. pág. 27. ISBN 978-0-13-111155-4.
  8. ^ Dybå, Tore; Dingsøyr, Torgeir (1 de agosto de 2008). "Estudos empíricos de desenvolvimento ágil de software: uma revisão sistemática". Tecnologia da Informação e Software . 50 (9–10): 833–859. doi : 10.1016/j.infsof.2008.01.006 . ISSN 0950-5849 . 
  9. ^ Lee, Gwanhoo; Xia, Weidong (2010). "Toward Agile: Uma Análise Integrada de Dados de Campo Quantitativos e Qualitativos na Agilidade de Desenvolvimento de Software". MIS Trimestral . 34 (1): 87–114. doi : 10.2307/20721416 . JSTOR 20721416 . S2CID 26477249 .  
  10. Gerald M. Weinberg , como citado em Larman & Basili 2003 , pp .47–56 John von Neumann, então talvez ele tenha aprendido lá, ou assumido como totalmente natural. Eu me lembro de Herb Jacobs (principalmente, embora todos nós tenhamos participado) desenvolvendo uma grande simulação para a Motorola, onde a técnica usada era, até onde eu sei... enorme projeto era bastante estúpido, ou pelo menos ignorante das realidades. Acho que o que a descrição em cascata fez por nós foi nos fazer perceber que estávamos fazendo outra coisa, algo sem nome, exceto 'desenvolvimento de software'."
  11. ^ "Gerenciamento de Projeto Evolutivo (Página Original, arquivo externo)" . Gilb. Arquivado a partir do original em 27 de março de 2016 . Recuperado em 30 de abril de 2017 .
  12. ^ "Gerenciamento de Projeto Evolutivo (Nova página)" . Gilb . Recuperado em 30 de abril de 2017 .
  13. ^ Edmonds, EA (1974). "Um Processo para o Desenvolvimento de Software para Usuários Não Técnicos como um Sistema Adaptativo". Sistemas Gerais . 19 : 215-18.
  14. ^ Gilb, Tom (1 de abril de 1981). "Desenvolvimento evolutivo". ACM SIGSOFT Notas de Engenharia de Software . 6 (2): 17. doi : 10.1145/1010865.1010868 . S2CID 33902347 . 
  15. ^ Martin, James (1991). Desenvolvimento rápido de aplicativos . Macmillan. ISBN 978-0-02-376775-3.
  16. ^ Kerr, James M.; Hunter, Richard (1993). Por dentro do RAD: Como construir um sistema totalmente funcional em 90 dias ou menos . McGraw-Hill. pág. 3. ISBN 978-0-07-034223-1.
  17. ^ Instituto Iacocca (1991). "Estratégia Empresarial de Manufatura do Século XXI: Uma Visão Conduzida pela Indústria". Instituto Iacocca, Universidade Lehigh, Belém, PA.
  18. ^ Presley, A., J. Mills e D. Liles (1995). "Fabricação Aeroespacial Ágil". Nepcon East 1995, Boston.
  19. ^ Anderson, David (2005). "Declaração de Interdependência" . Arquivado a partir do original em 27 de janeiro de 2018 . Recuperado em 4 de outubro de 2018 .
  20. McDonald, Kent (1 de novembro de 2016). "Como você pode ajudar a Agile Alliance a ajudá-lo" . Blog da Aliança Ágil . Recuperado em 4 de julho de 2017 .
  21. ^ "Examinando o Manifesto Ágil" . Ambysoft Inc. Recuperado em 6 de abril de 2011 .
  22. ^ Jim Highsmith (2001). "História: O Manifesto Ágil" . ágilmanifesto.org.
  23. ^ a b Kent Beck ; James Grenning; Robert C. Martin ; Mike Beedle; Jim Highsmith ; Steve Mellor ; Arie van Bennekum; André Hunt ; Ken Schwaber ; Alistair Cockburn ; Ron Jeffries ; Jeff Sutherland ; Ward Cunningham ; Jon Kern; Davi Thomas ; Martin Fowler ; Brian Marick (2001). "Princípios por trás do Manifesto Ágil" . Aliança Ágil. Arquivado a partir do original em 14 de junho de 2010 . Recuperado em 6 de junho de 2010 .
  24. ^ Moran, A. (2014). Gestão Ágil de Riscos . Springer Verlag. ISBN 978-3319050072.
  25. ^ Beck, Kent (1999). "Abraçando Mudanças com Programação Extrema". Computador . 32 (10): 70–77. doi : 10.1109/2.796139 .
  26. ^ Mergel, Inês (julho de 2016). "Gestão ágil da inovação no governo: uma agenda de pesquisa" . Informações Governamentais Trimestral . 33 (3): 516-523. doi : 10.1016/j.giq.2016.07.004 .
  27. ^ Preuss, Deborah Hartmann (13 de outubro de 2006). "Estudo: Equipes Co-Localizadas vs. a Fazenda Cubículo" . InfoQ . Recuperado em 23 de outubro de 2018 .
  28. ^ Cockburn, Alistair (2007). "Desenvolvimento de Software Ágil: O Jogo Cooperativo" . www.pearson.com (2ª ed.). Profissional Addison-Wesley . Recuperado em 23 de outubro de 2018 .
  29. ^ Jain, Parita; Sharma, Arun; Ahuja, Laxmi (agosto de 2018). "O Impacto do Processo de Desenvolvimento de Software Ágil na Qualidade do Produto de Software" . 2018 7ª Conferência Internacional sobre Confiabilidade, Tecnologias Infocom e Otimização (Tendências e Direções Futuras) (ICRITO) . Noida, Índia: IEEE: 812-815. doi : 10.1109/ICRITO.2018.8748529 . ISBN 978-1-5386-4692-2. S2CID  195775457 .
  30. Cockburn, Alistair (19 de junho de 2008). "Radiador de informações" .
  31. ^ Ambler, Scott (12 de abril de 2002). Modelagem Ágil: Práticas Eficazes para a Programação EXtreme e o Processo Unificado . John Wiley & Filhos. págs. 12, 164, 363. ISBN 978-0-471-20282-0.
  32. ^ Vasiliauskas, Vidas (2014). "Desenvolvendo práticas ágeis de gerenciamento de tarefas e equipes de projetos" . Eylean. Arquivado a partir do original em 15 de setembro de 2014 . Recuperado em 15 de setembro de 2014 .
  33. ^ Jeffries, Ron; Anderson, Ana; Hendrickson, Chet (2001). Extreme Programming instalado . Addison-Weslsy. págs.  72–147 . ISBN 978-0201-70842-4.
  34. ^ Lisa Crispin; Janet Gregory (2009). Testes ágeis: um guia prático para testadores e equipes ágeis . Addison-Wesley.
  35. ^ Mitchell, Ian (2016). Desenvolvimento Ágil na Prática . Casa Tamar. pág. 11. ISBN 978-1-908552-49-5.
  36. ^ Larman, Craig (2004). Desenvolvimento ágil e iterativo: um guia do gerente . Addison-Wesley. pág. 27. ISBN 978-0-13-111155-4.
  37. ^ Boehm, B. ; R. Turner (2004). Equilibrando Agilidade e Disciplina: Um Guia para os Perplexos . Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6.Apêndice A, páginas 165–194
  38. ^ Larman, Craig (2004). "Capítulo 11: Dicas práticas" . Desenvolvimento ágil e iterativo: um guia do gerente . pág. 253. ISBN 9780131111554. Recuperado em 14 de outubro de 2013 .
  39. ^ Sliger, Michele; Broderick, Stacia (2008). A ponte para a agilidade do gerente de projeto de software . Addison-Wesley. pág. 46. ISBN 978-0-321-50275-9.
  40. ^ a b Boehm, B. ; R. Turner (2004). Equilibrando Agilidade e Disciplina: Um Guia para os Perplexos . Boston, MA: Addison-Wesley. págs. 55–57. ISBN 978-0-321-18612-6.
  41. ^ "Opinião de Paul Downey no Twitter" .
  42. ^ Rakitin, Steven R. (2001). "Manifesto Elicits Cinismo: Carta do leitor ao editor por Steven R. Rakitin". Computador IEEE . 34 (12): 4. doi : 10.1109/MC.2001.10095 . O artigo intitulado 'Desenvolvimento de software ágil: o negócio da inovação'... é mais uma tentativa de minar a disciplina de engenharia de software... Queremos gastar todo o nosso tempo codificando. Lembre-se, programadores reais não escrevem documentação.
  43. ^ a b Scott Ambler. "Documentação Agile/Lean: Estratégias para Desenvolvimento de Software Ágil" .
  44. ^ Scott Ambler. "Modelos e documentos apenas bons o suficiente: uma melhor prática ágil" .
  45. ^ Geoffrey Wiseman (18 de julho de 2007). "Os métodos ágeis exigem documentação?" . InfoQ.citando Cooper, Ian (6 de julho de 2007). "Sinais Staccato: Ágil e Documentação" . WordPress . com .
  46. ^ a b c Abrahamson P, Salo O, Ronkainen J, Warsta J (2002). Métodos ágeis de desenvolvimento de software: Revisão e análise (PDF) (Relatório técnico). VTT . 478.
  47. ^ "Guia de Práticas Ágeis" . a Aliança Ágil. Arquivado a partir do original em 9 de fevereiro de 2014.
  48. ^ a b Aydin, MN; Harmsen, F.; Slooten; Stagwee, RA (2004). "Um método de desenvolvimento de sistemas de informação ágil em uso". Turk J Elec Engin . 12 (2): 127–138.
  49. ^ Morris, David (2015). O paradoxo da transformação ágil: por que tentar muito ser ágil impede as organizações de se tornarem verdadeiramente ágeis . Nova Zelândia: Universidade de Auckland. doi : 10.13140/RG.2.2.32698.08640 .
  50. ^ Abrahamsson, P., Warsta, J., Siponen, MT, & Ronkainen, J. (2003). Novas Direções sobre Métodos Ágeis: Uma Análise Comparativa. Anais do ICSE'03 , 244-254
  51. ^ Mirakhorli, M.; Rad, AK; Shams, F.; Pazoki, M.; Mirakhorli, A. (2008). "Técnica RDP: uma prática para personalizar xp". Anais do workshop internacional de 2008 sobre Escrutinando práticas ágeis ou tiroteio no curral ágil (APOS '08) . ACM. págs. 23-32. doi : 10.1145/1370143.1370149 . ISBN 978-1-60558-021-0. S2CID  9528636 .
  52. ^ Schwaber, K (2006) Scrum é difícil e disruptivo.
  53. ^ Vodde, B (2016) A História de LeSS. Palestra de Encerramento. Scrum Austrália, Melbourne. abril de 2016.
  54. ^ Lagstedt, A., e Dahlberg, T. (2018). Compreendendo a Raridade da Seleção do Método ISD – Racionalidade Limitada e Estupidez Funcional. Anais do PACIS 2018. 154. https://aisel.aisnet.org/pacis2018/154 .
  55. Park, JS, McMahon, PE e Myburgh, B. (2016). Scrum Powered by Essence. ACM SIGSOFT Software Engineering Notes, 41(1), pp. 1–8.
  56. ^ Beck, K. (1999). Programação Extrema Explicada: Abrace a Mudança . Boston, MA: Addison-Wesley. ISBN 978-0-321-27865-4.
  57. ^ Evans, Ian. "Entrega Ágil na British Telecom" . Recuperado em 21 de fevereiro de 2011 .
  58. ^ a b W. Scott Ambler (2006) Supersize Me in Dr. Dobb's Journal, 15 de fevereiro de 2006.
  59. ^ Schaaf, RJ (2007). Conferência de Tecnologia de Software e Sistemas Agility XL 2007 Arquivado em 13 de março de 2016 na Wayback Machine , Tampa, FL
  60. ^ "Reunindo a distância" . Sdmagazine . com . Recuperado em 1 de fevereiro de 2011 .
  61. ^ Fowler, Martin. "Usando um Processo de Software Ágil com Desenvolvimento Offshore" . Martinfowler . com . Recuperado em 6 de junho de 2010 .
  62. ^ Leffingwell, Dean. "Scaled Agile Framework" . Estrutura ágil dimensionada .
  63. ^ Schwaber, Ken. "Guia do Nexus: O Guia Definitivo do Nexus: O exoesqueleto do desenvolvimento escalonado do Scrum" (PDF) . scrum.org . Recuperado em 14 de setembro de 2015 .
  64. ^ Sutherland, Jeff; Brown, Alex (23 de julho de 2014). "Scrum em escala: Parte 1" . Recuperado em 14 de setembro de 2015 .
  65. ^ Beedle, Mike. "Scrum Empresarial" . Recuperado em 25 de setembro de 2015 .
  66. ^ Ebbage, Michael. "Setchu – Ágil em Escala" . Recuperado em 30 de setembro de 2015 .
  67. ^ "Aliança XSCALE" . Aliança XSCALE . Recuperado em 15 de outubro de 2020 .
  68. ^ "Agilepath - Collaborate.Innovate.Succeed" . Agile-path. com. 18 de janeiro de 2019 . Recuperado em 26 de março de 2019 .
  69. ^ "Cópia arquivada" . Arquivado a partir do original em 28 de dezembro de 2018 . Recuperado em 18 de setembro de 2019 .{{cite web}}: CS1 maint: archived copy as title (link)
  70. ^ Workshop de Processos Ágeis II Gerenciando Múltiplos Projetos Ágeis Concorrentes. Washington: OOPSLA 2002
  71. ^ Cawley, Oisín; Wang, Xiaofeng; Richardson, Itaú (2010). Abrahamsson, Pekka; Oza, Nilay (eds.). Metodologias de Desenvolvimento de Software Lean/Agile em Ambientes Regulados – Estado da Arte . Software e Sistemas Empresariais Lean . Notas de Aula em Processamento de Informações Empresariais. Vol. 65. pp. 31–36. doi : 10.1007/978-3-642-16416-3_4 . HD : 10344/683 . ISBN 978-3-642-16415-6.
  72. ^ McHugh, Martin; McCaffery, Fergal; Coady, Garret (4 de novembro de 2014). Mitasiunas, Antanas; Rout, Terry; O'Connor, Rory V.; et ai. (ed.). Uma implementação ágil em uma organização de software de dispositivo médico . Melhoria de Processo de Software e Determinação de Capacidade . Comunicação em Ciência da Computação e Informação. Vol. 477. pp. 190–201. doi : 10.1007/978-3-319-13036-1_17 . ISBN 978-3-319-13035-4.
  73. ^ Wang, Yang; Ramadani, Jasmim; Wagner, Stefan (29 de novembro de 2017). Um estudo exploratório sobre a aplicação de um processo de desenvolvimento Scrum para sistemas críticos de segurança . Melhoria de Processo de Software Focada no Produto . Notas de aula em Ciência da Computação. Vol. 10611. pp. 324–340. arXiv : 1703.05375 . Bibcode : 2017arXiv170305375W . doi : 10.1007/978-3-319-69926-4_23 . ISBN 9783319699257. S2CID  4585465 .
  74. ^ "SafeScrum - SINTEF" . Sintef.no . Recuperado em 26 de março de 2019 .
  75. Thor Myklebust, Tor Stålhane, Geir Kjetil Hanssen, Tormod Wien e Børge Haugset: Scrum, documentação e o padrão de software IEC 61508-3:2010, http://www.sintef.no/globalassets/ec-61508-documentation-and -safescrum-psam12.pdf
  76. ^ Fitzgerald, B.; Stol, K.-J.; O'Sullivan, R.; O'Brien, D. (maio de 2013). Escalando métodos ágeis para ambientes regulamentados: um estudo de caso do setor . 2013 35ª Conferência Internacional de Engenharia de Software (ICSE) . págs. 863-872. doi : 10.1109/ICSE.2013.6606635 . HD : 10344/3055 . ISBN 978-1-4673-3076-3. S2CID  192403 .
  77. ^ Beck, Kent (2000). Programação Extrema Explicada . Addison-Wesley. pp.  1–24 . ISBN 978-0201616415.
  78. ^ Datta, Subhajit (2006). "Índice de medição de agilidade: uma métrica para a encruzilhada das metodologias de desenvolvimento de software". ACM-SE 44 Anais da 44ª Conferência Anual Regional Sudeste . pág. 271. doi : 10.1145/1185448.1185509 . ISBN 1595933158.
  79. ^ Pedro Lappo; Henrique CT André. "Avaliando Agilidade" (PDF) . Arquivado a partir do original (PDF) em 15 de setembro de 2009 . Recuperado em 6 de junho de 2010 .
  80. ^ Joe Little (2 de dezembro de 2007). "Teste Nokia, um teste específico para scrum" . Agileconsortium.blogspot.com . Recuperado em 6 de junho de 2010 .
  81. ^ Mark Seuffert; Mayberg, Suécia. "Teste Karlskrona, um teste genérico de adoção ágil" . Mayberg.se . Recuperado em 5 de abril de 2014 .
  82. ^ "Quão ágil você é? (Faça este teste de 42 pontos)" . allaboutagile. com/. Arquivado a partir do original em 5 de maio de 2014 . Recuperado em 3 de abril de 2014 .
  83. ^ "Resultados da pesquisa de metodologias ágeis" (PDF) . Shine Tecnologias. Janeiro de 2003. Arquivado a partir do original (PDF) em 21 de agosto de 2010 . Recuperado em 3 de junho de 2010 . 95% afirmaram que não houve efeito ou redução de custos ... 93% afirmaram que a produtividade foi melhor ou significativamente melhor ... 88% afirmaram que a qualidade foi melhor ou significativamente melhor ... 83% afirmaram que a satisfação do negócio foi melhor ou significativamente melhor
  84. ^ "Relatório 2013 State of Agile: Por que Agile?" . stateofagile. com. 27 de janeiro de 2014. Arquivado a partir do original em 28 de agosto de 2014 . Recuperado em 13 de agosto de 2014 .
  85. ^ Status Quo Agile , Segundo estudo sobre sucesso e formas de uso de métodos ágeis. Recuperado em 1 de julho de 2015
  86. Ambler, Scott (3 de agosto de 2006). "A pesquisa diz: Agile funciona na prática" . Dr. Dobb . Recuperado em 3 de junho de 2010 . Apenas 6% indicaram que sua produtividade foi reduzida ... Nenhuma mudança na produtividade foi relatada por 34% dos entrevistados e 60% relataram aumento de produtividade ... 66% [responderam] que a qualidade é maior ... 58% das organizações relatam satisfação melhorada, enquanto apenas 3% relatam satisfação reduzida.
  87. ^ "Respondendo à pergunta "Onde está a prova de que os métodos ágeis funcionam" . Agilemodeling. com. 19 de janeiro de 2007 . Recuperado em 2 de abril de 2010 .
  88. ^ Shore & Warden 2008 , p. 47
  89. ^ Beck, Kent (2000). Programação Extrema Explicada . Addison-Wesley. págs.  48–49 . ISBN 978-0201616415.
  90. ^ Rouse, Margaret. "Definição de Sprint (desenvolvimento de software)" . searchsoftwarequality.techtarget.com . Recuperado em 2 de outubro de 2015 .
  91. ^ Goldstein, Ilan (11 de outubro de 2011). "Problemas de sprint - quando sprints se transformam em rastreamentos" . www.axisagile.com.au . Recuperado em 8 de junho de 2014 .
  92. ^ "Funções do projeto e distribuição da responsabilidade" . Agile-only . com . Recuperado em 15 de junho de 2014 .
  93. ^ Bourne, Lynda. "O que um patrocinador de projeto realmente faz?" . blogs.pmi.org . Arquivado a partir do original em 7 de junho de 2014 . Recuperado em 8 de junho de 2014 .
  94. ^ "9th State of Agile Report" . Estágio do Agile Survey . Versão Um. Arquivado a partir do original em 12 de janeiro de 2015 . Recuperado em 8 de junho de 2014 .
  95. ^ Sims, Chris; Johnson, Hillary Louise (15 de fevereiro de 2011). Os Elementos do Scrum (Kindle ed.). Dymaxicon. pág. 73.
  96. ^ Rothman, Johanna Rothman (25 de agosto de 2011). "Quando você não tem proprietário do produto em tudo" . www.jrothman.com . Recuperado em 8 de junho de 2014 .
  97. Fox, Alyssa (8 de abril de 2014). "Trabalhando em várias equipes ágeis" . techwhirl . com/ . Recuperado em 14 de junho de 2014 .
  98. ^ "Reunião Scrum Diária" . www.mountaingoatsoftware.com . Recuperado em 14 de junho de 2014 .
  99. ^ a b Maio, Robert. "Planejamento de Sprint Eficaz" . www.agileexecutives.org . Arquivado a partir do original em 28 de junho de 2014 . Recuperado em 14 de junho de 2014 .
  100. ^ Berczuk, Steve. "Missão Possível: ScrumMaster e Colaborador Técnico" . www.agileconnection.com . Recuperado em 14 de junho de 2014 .
  101. ^ "Como implementar Agile Scrum" . Recuperado em 4 de janeiro de 2022 .
  102. ^ Namta, Rajneesh. "Reflexões sobre Automação de Testes em Agile" . www.infoq.com . Recuperado em 14 de junho de 2014 .
  103. ^ a b Band, Zvi (22 de março de 2014). "Dívida Técnica + Outubro Vermelho" . Recuperado em 8 de junho de 2014 .
  104. ^ Costa, James. "A Arte do Desenvolvimento Ágil: Refatoração" . www.jamesshore.com . Recuperado em 14 de junho de 2014 .
  105. ^ "Passo 4: Planejamento de Sprint (Tarefas)" . www.allaboutagile.com . Arquivado a partir do original em 29 de junho de 2014 . Recuperado em 14 de junho de 2014 .
  106. ^ George, Claire (3 de março de 2014). "Por que limitar seu trabalho em andamento é importante" . leankit . com . Recuperado em 14 de junho de 2014 .
  107. ^ "Reunião de Planejamento de Sprint" . www.mountaingoatsoftware.com . Recuperado em 14 de junho de 2014 .
  108. ^ McMillan, Keith. "Tempo, Recursos, Escopo... e Qualidade" . www.adeptechllc.com . Recuperado em 15 de junho de 2014 .
  109. ^ "Estudo atual sobre as limitações do Agile" . Procedia Ciência da Computação . 78 : 291-297. Janeiro de 2016. doi : 10.1016/j.procs.2016.02.056 .
  110. ^ "A Chamada de Compras para Agile, o que isso significa?" . 1 de novembro de 2019.
  111. ^ Moran, Alan (2015). Gerenciando Agile: Estratégia, Implementação, Organização e Pessoas . Springer. ISBN 978-3-319-16262-1.
  112. ^ "A Chamada de Compras para Agile, o que isso significa?" . 1 de novembro de 2019.
  113. ^ ExecutiveBrief, qual ciclo de vida é melhor para seu projeto? , PM Hut. Acesso em 23 de outubro de 2009.
  114. ^ "Gestão de Projetos Ágil" . VersãoUm . Recuperado em 1 de junho de 2015 .
  115. ^ "O que é gerenciamento ágil?" . Projeto Caminhos . Recuperado em 1 de junho de 2015 .
  116. ^ USAID. "Política Operacional do Ciclo do Programa ADS Capítulo 201" Arquivado em 23 de outubro de 2019 no Wayback Machine . Recuperado em 19 de abril de 2017
  117. ^ Project Management Institute , A Guide to the Project Management Body of Knowledge (Guia PMBOK), Quinta Edição
  118. ^ Richet, Jean-Loup (2013). Inovação Ágil . Casos e Pesquisa Aplicada, n°31. ESSEC-ISIS. ISBN 978-2-36456-091-8 
  119. ^ Smith, Preston G (2007). Desenvolvimento de Produto Flexível . Jossey Bass. pág. 25. ISBN 978-0-7879-9584-3.
  120. ^ Newton Lee (2014). "Entrando nas paradas da Billboard: produção musical como desenvolvimento ágil de software", Digital Da Vinci: Computers in Music. Springer Science+Business Media. ISBN 978-1-4939-0535-5.
  121. ^ Moran, Alan (2015). Gerenciando Agile: Estratégia, Implementação, Organização e Pessoas . Springer Verlag. ISBN 978-3-319-16262-1.
  122. ^ "Programação ágil - para sua família" .
  123. ^ Larman, Craig; Bas Vodde (13 de agosto de 2009). Dez Principais Impedimentos Organizacionais à Adoção Ágil em Grande Escala . Informe a TI.
  124. ^ "Introdução ao gerenciamento de projetos híbridos" . 20 de julho de 2016.
  125. ^ Barlow, Jordan B.; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011). "Visão Geral e Orientação sobre Desenvolvimento Ágil em Grandes Organizações" . Comunicações da Associação para Sistemas de Informação . 29 (1): 25–44. doi : 10.17705/1CAIS.02902 .
  126. ^ Kupersmith, Kupe. "Agil é uma moda" .
  127. ^ a b Kruchten, Philippe (20 de junho de 2011). "A Crise Adolescente do Agile?" . InfoQ.
  128. Richard Utz, "Against Adminspeak," Chronicle of Higher Education , 24 de junho de 2020.
  129. ^ Cohn, Mike (2015). Sucesso com Agile . Pearson. págs. 5–10. ISBN 978-0-321-57936-2.

Leitura adicional [ editar ]

Links externos [ editar ]