Desenvolvimento Adaptive S / W - Guia Rápido

O que é Agile?

Em termos literários, a palavra “ágil” significa alguém que pode se mover com rapidez e facilidade ou alguém que pode pensar e agir com rapidez e clareza. Nos negócios, “ágil” é usado para descrever maneiras de planejar e fazer o trabalho, onde se entende que fazer mudanças conforme necessário é uma parte importante do trabalho. “Agilidade” de negócios significa que uma empresa está sempre em condições de levar em conta as mudanças do mercado.

No desenvolvimento de software, o termo “ágil” é adaptado para significar “a capacidade de responder às mudanças - mudanças de Requisitos, Tecnologia e Pessoas”.

Manifesto Ágil

O Manifesto Ágil foi publicado por uma equipe de desenvolvedores de software em 2001, destacando a importância da equipe de desenvolvimento, acomodando as mudanças de requisitos e o envolvimento do cliente.

O Manifesto Ágil é -

Estamos descobrindo melhores maneiras de desenvolver software, fazendo isso e ajudando outros a fazê-lo. Por meio deste trabalho, chegamos a valorizar -

Indivíduos e interações sobre processos e ferramentas.
software que trabalha sobre uma documentação completa.
Colaboração com o cliente na negociação do contrato.
Respondendo à mudança seguindo um plano.

Ou seja, embora haja valor nos itens à direita, valorizamos mais os itens à esquerda.

Características de Agilidade

A seguir estão as características de Agilidade -

Agilidade no Desenvolvimento Ágil de Software concentra-se na cultura de toda a equipe, com equipes multidisciplinares e multifuncionais, com autonomia e auto-organização.
Promove responsabilidade compartilhada e prestação de contas.
Facilita a comunicação eficaz e a colaboração contínua.
A abordagem de equipe inteira evita atrasos e tempos de espera.
Entregas frequentes e contínuas garantem um feedback rápido que, por sua vez, permite que a equipe se alinhe aos requisitos.
A colaboração facilita a combinação de diferentes perspectivas em tempo hábil na implementação, correções de defeitos e mudanças adequadas.
O progresso é constante, sustentável e previsível, enfatizando a transparência.

Metodologias ágeis

As primeiras implementações de métodos Agile incluem Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development e Dynamic Systems Development Method (DSDM). Essas são agora chamadas coletivamente de metodologias Agile, depois que o manifesto Agile foi publicado em 2001.

Neste tutorial, aprenderemos a Metodologia Ágil - Adaptive Software Development.

O que é Adaptive Software Development?

O Desenvolvimento Adaptativo de Software é um movimento em direção às práticas adaptativas, deixando as práticas determinísticas no contexto de sistemas e ambientes complexos. O Adaptive Software Development se concentra na colaboração e no aprendizado como uma técnica para construir sistemas complexos. Ele é desenvolvido a partir das melhores práticas de Desenvolvimento Rápido de Aplicativos (RAD) e Ciclos de Vida Evolucionários. O Adaptive Software Development foi então estendido para incluir abordagens adaptativas para o gerenciamento, com a especulação substituindo o Planning.

Jim Highsmith publicou um livro sobre Adaptive Software Development em 2000. Nas palavras de Highsmith -

“O Desenvolvimento de Software Adaptável é cíclico como o modelo evolucionário, com os nomes de fase especular, colaborar, aprender refletindo o reino imprevisível de sistemas cada vez mais complexos. O desenvolvimento adaptativo vai além de sua herança evolutiva de duas maneiras principais. Primeiro, ele substitui explicitamente o determinismo pela emergência. Em segundo lugar, vai além de uma mudança no Ciclo de Vida para uma mudança mais profunda no estilo de gestão. ”

Um modelo de Ciclo de Vida de Desenvolvimento de Software (SDLC) é uma estrutura que descreve as atividades realizadas em cada estágio de um projeto de desenvolvimento de software.

Em um Ciclo de Vida de Desenvolvimento de Software, as atividades são realizadas em cinco fases -

Requirements Gathering- Os requisitos para um software a ser desenvolvido são reunidos. Esses requisitos estarão em um idioma que seja compreendido pelo cliente / usuário. Terminologia específica de domínio é recomendada.
Analysis - Os requisitos coletados são analisados do ponto de vista da implementação e as especificações do software são escritas para cobrir tanto os requisitos funcionais quanto os não funcionais.
Design - Esta fase envolve chegar à arquitetura de software e especificações de implementação com base na tecnologia escolhida para o desenvolvimento.
Construction - Nesta fase, o código é desenvolvido, testado na unidade, integrado, testado na integração e o build é produzido.
Testing- O teste funcional do software construído é feito nesta fase. Isso também inclui o teste de requisitos não funcionais.

Existem duas abordagens para realizar essas atividades -

Prescriptive - Os modelos SDLC que fornecerão maneiras de realizar as atividades de uma maneira prescrita, conforme definido pela estrutura.
Adaptive- Os modelos SDLC que lhe darão agilidade na execução das atividades, com certas regras que precisam ser seguidas. Os métodos ágeis geralmente seguem essa abordagem, com cada um tendo suas regras. No entanto, seguir uma abordagem adaptativa ou ágil não significa que o software seja desenvolvido sem seguir qualquer disciplina. Isso levaria ao caos.

Você precisa entender que não podemos dizer que um modelo SDLC específico é bom ou ruim. Cada um deles tem seus próprios pontos fortes e fracos e, portanto, são adequados em determinados contextos.

Quando você escolhe um modelo SDLC para o seu projeto, você precisa entender -

Contexto da sua organização
Seu contexto de tecnologia
Composição de sua equipe
Seu contexto de cliente

Por exemplo, se o desenvolvimento de software for previsível, você pode usar uma abordagem prescritiva. Por outro lado, se o desenvolvimento de software é imprevisível, ou seja, os requisitos não são totalmente conhecidos, ou a equipe de desenvolvimento não tem exposição prévia ao domínio ou tecnologia atual, etc., a abordagem adaptativa é a melhor escolha.

Nas seções a seguir, você entenderá os modelos SDLC mais prevalentes que são desenvolvidos durante a execução de projetos de desenvolvimento de software em toda a indústria. Você também conhecerá os pontos fortes e fracos de cada um deles e em que contextos eles são adequados.

O modelo em cascata é um modelo SDLC clássico amplamente conhecido, compreendido e comumente usado. Foi introduzido por Royce em 1970 e ainda está sendo seguido como uma abordagem comum para o desenvolvimento de software em várias organizações em toda a indústria.

No modelo em cascata, cada fase do ciclo de vida pode começar somente após a conclusão da fase anterior do ciclo de vida. Portanto, é um modelo linear sem ciclos de feedback.

Modelo em cascata - pontos fortes

Os pontos fortes do modelo em cascata são -

Fácil de entender, fácil de usar.
Fornece estrutura para equipe de desenvolvimento inexperiente.
Marcos são bem compreendidos.
Define a estabilidade dos requisitos.
Ideal para controle de gestão (planejamento, monitoramento, relatórios).
Funciona bem quando a qualidade é mais importante do que custo ou cronograma.

Modelo em cascata - Fraquezas

Os pontos fracos ou as desvantagens do modelo em cascata são -

Idealizado - Não condiz bem com a realidade.
Irrealista - não pode esperar requisitos precisos no início do projeto.
Não reflete a natureza iterativa do desenvolvimento exploratório que é mais comum.
Difícil e caro de fazer alterações.
O software é entregue somente no final do projeto. Devido a isso -
- Atrasa a descoberta de defeitos graves.
- Possibilidade de entrega de requisitos obsoletos.
Sobrecarga de gerenciamento significativa, que pode ser cara para pequenas equipes e projetos.
Requer recursos experientes em todas as fases - analistas, designers, desenvolvedores, testadores.
O teste começa somente depois que o desenvolvimento é concluído e os testadores não estão envolvidos em nenhuma das fases anteriores.
A expertise das equipes multifuncionais não é compartilhada, pois cada fase é executada em silos.

Quando usar o modelo de cachoeira?

Você pode usar o modelo em cascata se -

Os requisitos são muito conhecidos.
A definição do produto é estável.
A tecnologia é bem compreendida.
Nova versão de um produto existente.
Portando um produto existente para uma nova plataforma.
Grande organização com equipes multifuncionais estruturadas.
Os canais de comunicação estão bem estabelecidos dentro da organização e também com o cliente.

Modelo de Prototipagem Evolutiva

No desenvolvimento de software usando o modelo de Prototipagem Evolutiva, os desenvolvedores constroem um protótipo durante a fase de requisitos. Os usuários finais avaliam o protótipo e dão feedback. O feedback pode ser correções para o protótipo ou funcionalidade adicional. Com base no feedback, os desenvolvedores refinam ainda mais o protótipo.

Assim, o produto evolui através do Protótipo → Feedback → Ciclos de Protótipo Refinado e daí o nome Prototipagem Evolutiva. Quando o usuário está satisfeito com a funcionalidade e funcionamento do produto, o código do protótipo é levado aos padrões exigidos para a entrega do produto final.

Modelo de Prototipagem Evolutiva - Pontos Fortes

Os pontos fortes ou as vantagens de um modelo de Prototipagem Evolutiva são -

Os clientes / usuários finais podem visualizar os requisitos do sistema à medida que são reunidos olhando para o protótipo.
Os desenvolvedores aprendem com os clientes e, portanto, sem ambigüidades em relação ao domínio ou ambiente de produção.
Permite design e desenvolvimento flexíveis.
A interação com o protótipo estimula a consciência da funcionalidade adicionalmente necessária.
Requisitos inesperados e mudanças de requisitos são facilmente acomodados.
Sinais constantes e visíveis de progresso são produzidos.
Entrega de um produto final preciso e sustentável.

Modelo de Prototipagem Evolutiva - Pontos Fracos

As fraquezas ou desvantagens do modelo de Prototipagem Evolutiva são as seguintes -

Tendência de abandonar o desenvolvimento estruturado no desenvolvimento de codificar e corrigir, embora não seja o que é prescrito pelo modelo.
Este modelo recebeu má reputação pelos métodos rápidos e sujos.
A manutenção geral pode possivelmente ser negligenciada.
O cliente pode eventualmente solicitar a entrega do protótipo como final, não dando aos desenvolvedores a oportunidade de executar a etapa final, ou seja, a padronização do produto final.
O projeto pode continuar para sempre (com aumento contínuo do escopo) e a gerência pode não apreciar isso.

Quando usar o modelo de prototipagem evolucionária?

Você pode usar o modelo de Prototipagem Evolutiva -

Quando os requisitos são instáveis ou precisam ser esclarecidos
Como o estágio de esclarecimento de requisitos de um modelo em cascata
Para desenvolver interfaces de usuário
Para demonstrações de curta duração
Para desenvolvimento novo ou original
Para implementar uma nova tecnologia

Em um modelo Iterativo Incremental, inicialmente, uma implementação parcial de um sistema total é construída de forma que ele esteja em um estado de entrega. Funcionalidade aumentada é adicionada. Defeitos, se houver, da entrega anterior são corrigidos e o produto de trabalho é entregue. O processo é repetido até que todo o desenvolvimento do produto seja concluído. As repetições desses processos são chamadas de iterações. No final de cada iteração, um incremento de produto é entregue.

Modelo Incremental Iterativo - Pontos Fortes

As vantagens ou pontos fortes do modelo Iterativo Incremental são -

Você pode desenvolver requisitos priorizados primeiro.
A entrega inicial do produto é mais rápida.
Os clientes obtêm funcionalidades importantes desde o início.
Reduz o custo de entrega inicial.
Cada lançamento é um incremento do produto, de modo que o cliente terá um produto funcionando à mão o tempo todo.
O cliente pode fornecer feedback para cada incremento de produto, evitando surpresas no final do desenvolvimento.
As mudanças de requisitos podem ser facilmente acomodadas.

Modelo Incremental Iterativo - Fraquezas

As desvantagens do modelo Iterativo Incremental são -

Requer um planejamento eficaz de iterações.
Requer um design eficiente para garantir a inclusão da funcionalidade necessária e provisão para alterações posteriores.
Requer a definição antecipada de um sistema completo e totalmente funcional para permitir a definição de incrementos.
São necessárias interfaces de módulo bem definidas, pois algumas são desenvolvidas muito antes de outras serem desenvolvidas.
O custo total do sistema completo não é menor.

Quando usar o modelo incremental iterativo?

O modelo incremental iterativo pode ser usado quando -

A maioria dos requisitos é conhecida desde o início, mas espera-se que evoluam com o tempo.
Os requisitos são priorizados.
É necessário que a funcionalidade básica seja entregue rapidamente.
Um projeto tem cronogramas de desenvolvimento longos.
Um projeto possui uma nova tecnologia.
O domínio é novo para a equipe.

O modelo de desenvolvimento rápido de aplicativos (RAD) tem as seguintes fases -

Requirements Planning phase - Na fase de planejamento de requisitos, um workshop deve ser conduzido para discutir os problemas de negócios de maneira estruturada.
User Description phase - Na fase de descrição do usuário, ferramentas automatizadas são usadas para capturar informações dos usuários.
Construction phase - Na fase de construção, ferramentas de produtividade, como geradores de código, geradores de tela, etc. são usados dentro de um time-box, com uma abordagem “Do until Done”.
Cut Over phase - Na fase de transição, são realizados a instalação do sistema, o teste de aceitação do usuário e o treinamento do usuário.

Modelo de desenvolvimento rápido de aplicativos - pontos fortes

As vantagens ou pontos fortes do modelo de desenvolvimento rápido de aplicativos são as seguintes -

O tempo de ciclo reduzido e a produtividade aprimorada com menos membros da equipe significariam custos mais baixos.
O envolvimento do cliente em todo o ciclo minimiza o risco de não atingir a satisfação do cliente e o valor do negócio.
O foco se move para o código em um modo o que você vê é o que você obtém (WYSIWYG). Isso traz clareza sobre o que está sendo construído é a coisa certa.
Usa conceitos de modelagem para capturar informações sobre negócios, dados e processos.

Modelo de desenvolvimento rápido de aplicativos - Pontos fracos

As desvantagens ou pontos fortes do modelo de desenvolvimento rápido de aplicativos são as seguintes -

O processo de desenvolvimento acelerado deve dar respostas rápidas ao usuário.
Risco de nunca conseguir o fechamento.
Difícil de usar com sistemas legados.
Desenvolvedores e clientes devem estar comprometidos com atividades rápidas em um período de tempo abreviado.

Quando usar o modelo de desenvolvimento rápido de aplicativos?

O modelo de desenvolvimento rápido de aplicativos pode ser usado quando -

O usuário pode estar envolvido em todo o ciclo de vida.
O projeto pode ser cronometrado.
A funcionalidade pode ser fornecida em incrementos.

Embora os pontos fortes do modelo de Desenvolvimento Rápido de Aplicativos sejam apreciados, ele é usado com moderação na indústria.

O modelo espiral adiciona análise de risco e prototipagem RAD ao modelo em cascata. Cada ciclo envolve a mesma sequência de etapas do modelo em cascata.

O modelo espiral tem quatro quadrantes. Vamos discuti-los em detalhes.

Quadrante 1 - Determine objetivos, alternativas e restrições

Objectives - Funcionalidade, desempenho, interface de hardware / software, fatores críticos de sucesso, etc.
Alternatives - Construir, reutilizar, comprar, subcontratar, etc.
Constraints - Custo, cronograma, interface, etc.

Quadrante 2 - Avalie alternativas, identifique e resolva riscos

Estude alternativas em relação aos objetivos e restrições que são determinados.
Identifique riscos como falta de experiência, novas tecnologias, cronogramas apertados, etc.
Resolva os riscos identificados avaliando seu impacto no projeto, identificando os planos de mitigação e contingência necessários e implementando-os. Os riscos sempre precisam ser monitorados.

Quadrante 3 - Desenvolva o produto de próximo nível

Atividades típicas incluem -

Crie um design
Revisão do design
Desenvolver código
Inspecione o código
Produto de teste

Quadrante 4 - Planeje a próxima fase

Atividades típicas incluem -

Desenvolver plano de projeto
Desenvolver plano de gerenciamento de configuração
Desenvolva um plano de teste
Desenvolva um plano de instalação

Modelo espiral - pontos fortes

As vantagens ou pontos fortes do método espiral são -

Fornece indicação precoce dos riscos, sem envolver muito custo.
Os usuários podem visualizar o sistema antecipadamente por causa das ferramentas de prototipagem rápida.
As funções críticas de alto risco são desenvolvidas primeiro.
O design não precisa ser perfeito.
Os usuários podem estar intimamente envolvidos em todas as etapas do ciclo de vida.
Feedback precoce e frequente dos usuários.
Custos cumulativos avaliados com frequência.

Modelo Espiral - Fraquezas

As desvantagens ou fraquezas do método espiral são -

Pode ser difícil definir objetivos, marcos verificáveis que indicam prontidão para prosseguir com a próxima iteração.
O tempo gasto em planejamento, redefinição de objetivos, análise de risco e prototipagem pode ser uma sobrecarga.
O tempo gasto para avaliar riscos pode ser muito grande para projetos pequenos ou de baixo risco.
O modelo espiral é complexo de entender para novos membros da equipe.
É necessária experiência em avaliação de risco.
A espiral pode continuar indefinidamente.
Os desenvolvedores devem ser reatribuídos durante as atividades da fase de não desenvolvimento.

Quando usar o modelo espiral?

O modelo espiral pode ser usado quando -

A criação de um protótipo é apropriada.
A avaliação de risco é importante.
Um projeto é de médio a alto risco.
Os usuários não têm certeza de suas necessidades.
Os requisitos são complexos.
A linha de produtos é nova.
Esperam-se mudanças significativas durante a exploração.
Compromisso de projeto de longo prazo imprudente devido a mudanças potenciais nos negócios.

Métodos Agile são baseados no manifesto Agile e são adaptativos por natureza. Métodos ágeis garantem -

Colaboração em equipe.
Colaboração do cliente.
Comunicação constante e contínua.
Resposta às mudanças.
Prontidão de um produto de trabalho.

Vários métodos Agile surgiram, promovendo o desenvolvimento iterativo e incremental com iterações time-boxed. Embora os métodos Ágeis sejam adaptativos, as regras do método específico não podem ser ignoradas e, portanto, requerem uma implementação disciplinada.

Métodos ágeis - Pontos fortes

As vantagens ou pontos fortes do método Agile são -

Lançamentos antecipados e frequentes.
Acomodação de mudanças de requisitos.
Comunicação diária entre o cliente e desenvolvedores.
Projetos construídos em torno de indivíduos motivados.
Equipes auto-organizadas.
Simplicidade, com foco no que é imediatamente necessário.
Sem construir para o futuro ou sobrecarregar o código.
Reflexão regular para ajustar o comportamento para melhorar a eficácia.

Métodos ágeis - Fraquezas

As desvantagens ou fraquezas do método espiral são -

A disponibilidade do cliente pode não ser possível.
As equipes devem ter experiência para seguir as regras do método.
O planejamento apropriado é necessário para decidir rapidamente sobre a funcionalidade que precisa ser entregue em uma iteração.
Espera-se que a equipe tenha habilidades de estimativa e de negociação.
A equipe deve ter habilidades de comunicação eficazes.
Novas equipes podem não ser capazes de se organizar.
Requer disciplina para desenvolver e entregar em iterações com limite de tempo.
O design precisa ser simples e passível de manutenção, exigindo, assim, habilidades eficazes de design.

Quando usar métodos Agile?

Os métodos Agile podem ser usados quando -

A aplicação é crítica em termos de tempo.
O escopo é limitado e menos formal (escalar métodos ágeis para projetos maiores está em andamento, com certas extensões para alguns dos métodos ágeis).
A organização emprega métodos disciplinados.

Os modelos SDLC anteriores são mais orientados para as práticas de estabilidade, previsibilidade e retornos decrescentes. O setor, como o de plataformas de Internet, tem se movido para aumentar os ambientes de retorno, abordagens imprevisíveis, não lineares e rápidas.

O Adaptive Software Development (ASD) evoluiu para resolver esses problemas. Ele enfoca a emergência como o fator mais importante do ponto de vista da administração, para aumentar a capacidade de gerenciar o desenvolvimento de produtos.

Nas palavras de Jim Highsmith, “A estrutura de desenvolvimento de software adaptável é baseada em anos de experiência com metodologias de desenvolvimento de software tradicionais, consultoria, prática e redação sobre técnicas de desenvolvimento rápido de aplicativos (RAD) e trabalho com empresas de software de alta tecnologia no gerenciamento do desenvolvimento de seus produtos práticas ”.

O modelo em cascata é caracterizado pela linearidade e previsibilidade, com feedback insuficiente. Pode ser visto como uma sequência dePlan → Build → Implement.

Os modelos de ciclo de vida evolucionário, como o modelo espiral, mudaram a abordagem determinística para a adaptativa, com Plan → Build → Revise Cycles.

No entanto, a mentalidade dos praticantes permaneceu Determinista, com previsibilidade de longo prazo se transformando em previsibilidade de curto prazo. As práticas dos modelos de Ciclo de Vida Evolucionário, como RAD, são menos determinísticas.

O Ciclo de Vida Adaptável

O modelo adaptativo é construído de um ponto de vista diferente. Embora cíclicos como o modelo evolucionário, os nomes da fase refletem a natureza imprevisível de sistemas cada vez mais complexos.

O Desenvolvimento Adaptativo vai além de sua herança evolutiva de duas maneiras principais -

Ele substitui explicitamente Determinismo por Emergência.
Vai além de uma mudança no ciclo de vida para uma mudança mais profunda no estilo de gestão.

As três fases do Adaptive Software Development Lifecycle são -

Speculate - Especular substitui a palavra determinística planejamento, planejamento de especificações de produto ou planejamento de tarefas de gerenciamento de projeto.
Collaborate - Colaborar representa o equilíbrio entre
- Gerenciando no sentido tradicional de gerenciamento de projetos, e
- Criar e manter o ambiente colaborativo necessário para o surgimento.

As Atividades Colaborativas constroem produtos, acompanhando o ritmo das mudanças no ambiente.

Learn - Aprender visa, tanto os desenvolvedores quanto os clientes, usar os resultados de cada ciclo de desenvolvimento para aprender a direção do próximo.

Neste capítulo, vamos entender os vários conceitos de Desenvolvimento de Software Adaptativo.

Teoria dos Sistemas Adaptativos Complexos (CAS)

Brian Arthur e seus colegas, no Instituto de Santa Fé, usaram a teoria dos Sistemas Adaptativos Complexos (CAS) para revolucionar a compreensão da Física, Biologia, Evolução e Economia.

Brian Arthur culminou em mais de duas décadas tentando convencer os economistas convencionais de que sua visão, dominada por suposições fundamentais de retornos decrescentes, equilíbrio e dinâmica determinística, não era mais suficiente para entender a realidade. O novo mundo apresenta retornos crescentes, instabilidade e incapacidade de determinar causa e efeito.

Os dois mundos diferem em comportamento, estilo e cultura. Eles pedem -

Diferentes técnicas de gestão
Estratégias Diferentes
Entendimento Diferente

Desenvolvimento de software complexo

Com o escopo dos Aplicativos de Software explodindo, até mesmo as organizações de desenvolvimento de software estão acumulando contradições semelhantes às mencionadas acima.

Um Mundo é representado pelo desenvolvimento Determinístico, derivado de práticas de gestão que estão enraizadas nos fundamentos de estabilidade e previsibilidade (o que nos termos de Arthur significa retornos decrescentes)
O Segundo Mundo é representado pelas indústrias que mudam de ambientes de retorno decrescente para crescente que são imprevisíveis, não lineares e rápidos.

Para abordar as questões desse segundo mundo, Jig Highsmith ofereceu um framework, Adaptive Software Development, que é diferente do Deterministic Software Development.

O Adaptive Software Development se concentra em abordar os sistemas complexos -

Desenvolvimento de Software Adaptativo para o ciclo de vida do desenvolvimento.
Técnicas de gerenciamento adaptativo que exigem uma mentalidade diferente daquela das práticas tradicionais de gerenciamento de projetos.

Neste tutorial, você pode entender essas duas implementações.

O Adaptive Software Development (ASD) é baseado em duas perspectivas -

Perspectiva conceitual baseada na teoria de Complex Adaptive Systems (CAS), conforme apresentada na primeira seção deste capítulo.
Perspectiva prática baseada em
- Anos de experiência com metodologias de desenvolvimento de software determinísticas.
- Consultar, praticar e escrever sobre técnicas de Desenvolvimento Rápido de Aplicativos (RAD); e trabalhar com empresas de software de alta tecnologia no gerenciamento do desenvolvimento de seus produtos.

Neste capítulo, você entenderá a perspectiva conceitual do Desenvolvimento de Software Adaptativo.

Conceitos de sistemas adaptativos complexos (CAS)

A teoria dos Sistemas Adaptativos Complexos (CAS) tem muitos conceitos. O Desenvolvimento de Software Adaptativo é baseado em dois desses conceitos -

Emergence
Complexity

Emergência

Em projetos complexos de desenvolvimento de produtos de software, os resultados são inerentemente imprevisíveis. No entanto, produtos de sucesso surgem desses ambientes o tempo todo.

Isso pode acontecer por Emergência, conforme ilustrado na teoria dos Sistemas Adaptativos Complexos (CAS). Isso pode ser entendido por um exemplo simples, comportamento de bando de pássaros.

Quando você observa um bando de pássaros, você percebe que -

Cada pássaro tenta
- Mantenha uma distância mínima de outros objetos no ambiente, incluindo outras aves.
- Combine velocidades com pássaros em sua vizinhança.
- Mova-se em direção ao centro de massa de pássaros percebido em sua vizinhança.
Não existem regras de comportamento para o grupo. As únicas regras são sobre o comportamento de pássaros individuais.
No entanto, existe um comportamento emergente, o bando de pássaros. Quando os pássaros errantes correm para alcançá-los, o bando se divide em torno dos obstáculos e se reforma do outro lado.

Isso mostra a exigência das mudanças mais difíceis do modelo mental no Desenvolvimento Adaptativo - das formas de gerenciar e organizar essa liberdade individual à noção de que uma nova ordem criativa emerge de forma imprevisível da auto-organização espontânea.

Além do desenvolvimento, a emergência é o conceito mais importante também do ponto de vista da gestão.

Complexidade

No contexto de Desenvolvimento de Software, Complexidade é sobre -

Os indivíduos de uma equipe, como desenvolvedores, clientes, fornecedores, concorrentes e acionistas, seus números e sua velocidade.
Tamanho e complexidade tecnológica.

Práticas de desenvolvimento de software adaptativo

O Adaptive Software Development oferece uma perspectiva diferente sobre as práticas de gerenciamento de software. Nas seções abaixo, você pode compreender as duas práticas importantes - Qualidade e RAD, ambas com ramificações para reunir requisitos.

Você pode encontrar os detalhes de todas as práticas no capítulo, Práticas de Desenvolvimento de Software Adaptativo neste tutorial.

Qualidade

Em um ambiente complexo, a prática milenar de "Faça certo da primeira vez" não funciona, pois você não pode prever o que é certo no início. Você precisa ter como objetivo produzir o valor certo. No entanto, em um ambiente complexo, as combinações e permutações de componentes de valor como escopo (recursos, desempenho, níveis de defeito), cronograma e recursos são tão vastas que nunca pode haver um valor ideal. Portanto, o foco é mudar para entregar o melhor valor no mercado competitivo.

Práticas RAD

As Práticas RAD geralmente envolvem uma combinação do seguinte -

Ciclo de Vida Evolucionário
Grupos de foco do cliente, sessões JAD, análises técnicas
Gerenciamento de projeto com limite de tempo
Engenharia Contínua de Software
Equipes dedicadas com salas de guerra

Os projetos RAD têm um sabor adaptativo inerente e emergente. Muitas organizações de TI são contra RAD. No entanto, a Microsoft e outros produziram softwares incrivelmente grandes e complexos usando técnicas comparáveis ao RAD porque levanta questões sobre sua visão de mundo fundamental.

As práticas RAD e o processo da Microsoft são exemplos de Desenvolvimento Adaptativo em ação. Dar a eles um rótulo (ou seja, Desenvolvimento Adaptativo) e perceber que há um corpo crescente de conhecimento científico (ou seja, teoria CAS) explica por que eles funcionam. Isso deve fornecer uma base para um uso mais extensivo dessas práticas.

O Adaptive Software Development evoluiu a partir das práticas RAD. Os aspectos de equipe também foram agregados a essas práticas. Empresas da Nova Zelândia ao Canadá, para uma ampla variedade de projetos e tipos de produtos, têm usado o desenvolvimento de software adaptativo.

Jim Highsmith publicou o Adaptive Software Development em 2000.

As práticas de Desenvolvimento de Software Adaptável fornecem capacidade de acomodar mudanças e são adaptáveis em ambientes turbulentos com produtos evoluindo com pouco planejamento e aprendizado.

Fases do ciclo de vida do ASD

O Desenvolvimento de Software Adaptativo é cíclico como o modelo Evolucionário, com os nomes das fases refletindo a imprevisibilidade nos sistemas complexos. As fases do ciclo de vida do desenvolvimento adaptativo são -

Speculate
Collaborate
Learn

Essas três fases refletem a natureza dinâmica do Desenvolvimento de Software Adaptativo. O Desenvolvimento Adaptativo substitui explicitamente Determinismo por Emergência. Vai além de uma mera mudança no ciclo de vida para uma mudança mais profunda no estilo de gerenciamento. O Adaptive Software Development tem um ciclo de vida dinâmico especular-colaborar-aprender.

O Adaptive Software Development Lifecycle concentra-se nos resultados, não nas tarefas, e os resultados são identificados como recursos do aplicativo.

Especular

O termo plano é muito determinístico e indica um grau razoavelmente alto de certeza sobre o resultado desejado. A meta implícita e explícita de conformidade com o plano restringe a capacidade do gerente de conduzir o projeto em direções inovadoras.

No Adaptive Software Development, o termo plano é substituído pelo termo especular. Ao especular, a equipe não abandona o planejamento, mas reconhece a realidade da incerteza em problemas complexos. Especular incentiva a exploração e experimentação. Iterações com ciclos curtos são encorajadas.

Colaborar

Aplicativos complexos não são construídos, eles evoluem. Aplicativos complexos requerem que um grande volume de informações seja coletado, analisado e aplicado ao problema. Ambientes turbulentos têm altas taxas de fluxo de informações. Conseqüentemente, aplicativos complexos requerem que um grande volume de informações seja coletado, analisado e aplicado ao problema. Isso resulta em diversos requisitos de conhecimento que só podem ser tratados pela colaboração da equipe.

Colaborar exigiria a capacidade de trabalhar em conjunto para produzir resultados, compartilhar conhecimentos ou tomar decisões.

No contexto do gerenciamento de projetos, a Colaboração retrata um equilíbrio entre o gerenciamento com técnicas tradicionais de gerenciamento e a criação e manutenção do ambiente colaborativo necessário para o surgimento.

Aprender

A parte Aprender do Ciclo de Vida é vital para o sucesso do projeto. A equipe deve aprimorar seus conhecimentos constantemente, usando práticas como -

Revisões Técnicas
Retrospectivas do Projeto
Grupos de foco do cliente

As revisões devem ser feitas após cada iteração. Tanto os desenvolvedores quanto os clientes examinam suas suposições e usam os resultados de cada ciclo de desenvolvimento para aprender a direção do próximo. A equipe aprende -

Sobre mudanças de produto
Mudanças mais fundamentais nas suposições básicas sobre como os produtos estão sendo desenvolvidos

As iterações precisam ser curtas, para que a equipe possa aprender com pequenos erros em vez de grandes.

Especule - colabore - Aprenda o ciclo como um todo

Como você observa no ciclo Especular-Colaborar-Aprender, fornecido acima, é óbvio que as três fases não são lineares e se sobrepõem.

Observamos o seguinte em uma estrutura adaptativa.

É difícil colaborar sem aprender ou aprender sem colaborar.
É difícil especular sem aprender ou aprender sem especular.
É difícil especular sem colaboração ou colaborar sem especular.

O Adaptive Software Development Lifecycle tem seis características básicas -

Missão focada
Baseado em recursos
Iterative
Time-boxed
Impulsionado pelo risco
Tolerante à mudança

Neste capítulo, você entenderá essas seis características do Desenvolvimento Adaptativo de Software.

Focado na missão

Para muitos projetos, a missão geral que orienta a equipe é bem articulada, embora os requisitos possam ser incertos no início do projeto. As declarações de missão atuam como guias que incentivam a exploração no início, mas têm um foco estreito ao longo do projeto. Uma missão fornece limites em vez de um destino fixo. As declarações de missão e as discussões que resultam nessas declarações fornecem direção e critérios para a tomada de decisões críticas de compensação de projetos.

Sem uma missão clara e uma prática de refinamento de missão constante, os ciclos de vida iterativos tornam-se ciclos de vida oscilantes, oscilando para frente e para trás sem nenhum progresso no desenvolvimento.

Baseado em recursos

O Adaptive Software Development Lifecycle é baseado em recursos de aplicativos e não em tarefas. Recursos são as funcionalidades desenvolvidas durante uma iteração com base nas prioridades do cliente.

Os recursos podem evoluir em várias iterações quando os clientes fornecem feedback.

Os recursos do aplicativo que fornecem resultados diretos ao cliente após a implementação são os principais. Um documento orientado para o cliente, como um manual do usuário, também é considerado um recurso. Os outros documentos, como o modelo de dados, mesmo se definidos como entregas, são sempre secundários.

Iterativo

O Adaptive Software Development Lifecycle é iterativo e se concentra em lançamentos frequentes para obter feedback, assimilar o aprendizado resultante e definir a direção certa para um desenvolvimento posterior.

Time-box

No Adaptive Software Development Lifecycle, as iterações são limitadas no tempo. No entanto, deve-se lembrar que time-boxing no Adaptive Software Development não se trata de prazos. Não deve ser usado para fazer a equipe trabalhar por longas horas desafiando um ambiente colaborativo ou para comprometer a qualidade dos resultados.

No Adaptive Software Development, o time-boxing é considerado uma direção para focar e forçar decisões de tradeoff difíceis como e quando necessário. Em um ambiente incerto, no qual as taxas de mudança são altas, é necessário que haja uma função de força periódica, como uma caixa de tempo, para terminar o trabalho.

Orientado pelo risco

No Adaptive Software Development, as iterações são conduzidas pela identificação e avaliação dos riscos críticos.

Tolerante à mudança

O Adaptive Software Development é tolerante a mudanças, vendo as mudanças como a capacidade de incorporar vantagem competitiva, mas não como um problema para o desenvolvimento.

As práticas de Desenvolvimento Adaptativo de Software são impulsionadas pela crença na adaptação contínua, com o ciclo de vida equipado para aceitar a mudança contínua como a norma.

O Adaptive Software Development Lifecycle é dedicado a -

Aprendizado contínuo
Mudança de orientação
Re-evaluation
Perscrutando um futuro incerto
Colaboração intensa entre desenvolvedores, gerenciamento e clientes

SDLC Adaptativo

O Adaptive Software Development combina RAD com as Melhores Práticas de Engenharia de Software, como -

Iniciação do projeto.
Planejamento de ciclo adaptativo.
Engenharia de componentes simultâneos.
Revisão de qualidade.
Controle de qualidade e lançamento final.

As práticas de Desenvolvimento de Software Adaptável podem ser ilustradas da seguinte forma -

Conforme ilustrado acima, as práticas de Desenvolvimento de Software Adaptável estão espalhadas pelas três fases da seguinte forma -

Especular - Iniciação e planejamento
- Iniciação do projeto
- Estabelecer prazo para todo o projeto
- Decida o número de iterações e atribua uma caixa de tempo para cada uma
- Desenvolva um tema ou objetivo para cada uma das iterações
- Atribuir recursos a cada iteração
Collaborate - Desenvolvimento simultâneo de recursos
- Colaboração para equipes distribuídas
- Colaboração para projetos menores
- Colaboração para projetos maiores
Learn - Avaliação de qualidade
- Qualidade do resultado da perspectiva do cliente
- Qualidade do resultado de uma perspectiva técnica
- O funcionamento da equipe de entrega e as práticas que os membros da equipe estão utilizando
- O status do projeto

Especular - Iniciação e Planejamento

No Desenvolvimento de Software Adaptável, a fase de especulação tem duas atividades -

Initiation
Planning

Speculate tem cinco práticas que podem ser executadas repetidamente durante a fase de iniciação e planejamento. Eles são -

Iniciação do projeto
Estabelecer prazo para todo o projeto
Decida o número de iterações e atribua uma caixa de tempo para cada uma
Desenvolva um tema ou objetivo para cada uma das iterações
Atribuir recursos a cada iteração

Iniciação do projeto

A Iniciação do Projeto envolve -

Definir a missão e os objetivos do projeto
Compreendendo as restrições
Estabelecendo a organização do projeto
Identificação e definição de requisitos
Fazendo estimativas iniciais de tamanho e escopo
Identificando os principais riscos do projeto

Os dados de início do projeto devem ser coletados em uma sessão JAD preliminar, considerando a velocidade como o aspecto principal. A iniciação pode ser concluída em um esforço concentrado de dois a cinco dias para projetos de pequeno a médio porte, ou de duas a três semanas para projetos maiores.

Durante as sessões JAD, os requisitos são reunidos em detalhes suficientes para identificar recursos e estabelecer uma visão geral do objeto, dados ou outro modelo de arquitetura.

Estabelecendo prazo para todo o projeto

O prazo para todo o projeto deve ser estabelecido, com base no escopo, requisitos do conjunto de recursos, estimativas e disponibilidade de recursos que resultam do trabalho de iniciação do projeto.

Como você sabe, especular não abandona as estimativas, mas significa apenas aceitar que as estimativas podem dar errado.

Iterações e caixa de tempo

Decida o número de iterações e os comprimentos de iteração individuais com base no escopo geral do projeto e no grau de incerteza.

Para uma aplicação de pequeno a médio porte -

As iterações geralmente variam de quatro a oito semanas.
Alguns projetos funcionam melhor com iterações de duas semanas.
Alguns projetos podem exigir mais de oito semanas.

Escolha o horário com base no que funciona para você. Depois de decidir sobre o número de iterações e a duração de cada uma delas, atribua uma programação para cada uma delas.

Desenvolva um tema ou objetivo

Os membros da equipe devem desenvolver um tema ou objetivo para cada iteração. Isso é algo semelhante ao objetivo do Sprint no Scrum. Cada iteração deve entregar um conjunto de recursos que podem demonstrar a funcionalidade do produto, tornando-o visível para o cliente para permitir revisão e feedback.

Dentro das iterações, os builds devem entregar recursos de trabalho em uma base preferencialmente diária, permitindo o processo de integração e tornando o produto visível para a equipe de desenvolvimento. O teste deve ser uma parte contínua e integrante do desenvolvimento de recursos. Não deve ser atrasado até o final do projeto.

Atribuir recursos

Os desenvolvedores e clientes devem, juntos, atribuir recursos a cada iteração. O critério mais importante para essa atribuição de recurso é que cada iteração deve entregar um conjunto visível de recursos com funcionalidade considerável para o cliente.

Durante a atribuição de recursos às iterações -

A equipe de desenvolvimento deve apresentar as estimativas de recursos, riscos e dependências e fornecê-los ao cliente.
Os clientes devem decidir sobre a priorização de recursos, usando as informações fornecidas pela equipe de desenvolvimento.

Portanto, o planejamento da iteração é baseado em recursos e feito em equipe com desenvolvedores e clientes. A experiência tem mostrado que esse tipo de planejamento fornece uma melhor compreensão do projeto do que um planejamento baseado em tarefas pelo gerente de projeto. Além disso, o planejamento baseado em recursos reflete a singularidade de cada projeto.

Colaborar ─ Desenvolvimento de recursos simultâneos

Durante a fase de Colaboração, o foco está no desenvolvimento. A fase de colaboração tem duas atividades -

A equipe de desenvolvimento colabora e entrega software funcional.
Os gerentes de projeto facilitam a colaboração e as atividades de desenvolvimento simultâneas.

Colaboração é um ato de criação compartilhada que abrange a equipe de desenvolvimento, os clientes e os gerentes. A criação compartilhada é promovida pela confiança e respeito.

As equipes devem colaborar em -

Problemas técnicos
Requisitos de negócio
Tomada de decisão rápida

A seguir estão as práticas relevantes para a fase de Colaboração no Desenvolvimento de Software Adaptável -

Colaboração para equipes distribuídas
Colaboração para projetos menores
Colaboração para projetos maiores

Colaboração para equipes distribuídas

Nos projetos envolvendo equipes distribuídas, deve-se considerar o seguinte:

Vários parceiros de aliança
Conhecimento de base ampla
A forma como as pessoas interagem
A maneira como eles gerenciam as interdependências

Colaboração para projetos menores

Nos projetos menores, quando os membros da equipe estão trabalhando em proximidade física, a colaboração com bate-papos informais no corredor e rabiscos no quadro branco deve ser incentivada, pois isso é considerado eficaz.

Colaboração para projetos maiores

Projetos maiores requerem práticas adicionais, ferramentas de colaboração e interação do gerente de projeto e devem ser organizados de acordo com o contexto.

Aprenda - Revisão de Qualidade

O Adaptive Software Development incentiva o conceito de 'Experimentar e Aprender'.

Aprender com os erros e experimentação requer que os membros da equipe compartilhem códigos e artefatos parcialmente concluídos no início, a fim de -

Encontre erros
Aprenda com eles
Reduza o retrabalho encontrando pequenos problemas antes que eles se tornem grandes

No final de cada iteração de desenvolvimento, existem quatro categorias gerais de coisas a aprender -

Qualidade do resultado da perspectiva do cliente
Qualidade do resultado de uma perspectiva técnica
O funcionamento da equipe de entrega e da equipe de práticas
O status do projeto

Qualidade do resultado da perspectiva do cliente

Nos projetos de Desenvolvimento de Software Adaptável, obter feedback dos clientes é a primeira prioridade. A prática recomendada para isso é um grupo de foco do cliente. Essas sessões são projetadas para explorar um modelo de trabalho do aplicativo e registrar as solicitações de mudança do cliente.

As sessões de grupo de foco do cliente são sessões facilitadas, semelhantes às sessões JAD, mas em vez de gerar requisitos ou definir planos de projeto, elas são projetadas para revisar o próprio aplicativo. Os clientes fornecem feedback sobre o software de trabalho resultante de uma iteração.

Qualidade do resultado de uma perspectiva técnica

Nos projetos de Desenvolvimento de Software Adaptativo, a revisão periódica dos artefatos técnicos deve ser considerada importante. As revisões de código devem ser feitas continuamente. As revisões de outros artefatos técnicos, como arquitetura técnica, podem ser conduzidas semanalmente ou no final de uma iteração.

Em projetos de Desenvolvimento de Software Adaptativo, a equipe deve monitorar seu próprio desempenho periodicamente. As retrospectivas incentivam as equipes a aprenderem sobre si mesmas e seu trabalho, juntas como uma equipe.

Retrospectivas de fim de iteração facilitam a autoavaliação periódica do desempenho da equipe, como -

Determine o que não está funcionando.
O que a equipe precisa fazer mais.
O que a equipe precisa fazer menos.

O Status do Projeto

A revisão do status do projeto ajuda no planejamento do trabalho futuro. Nos projetos de desenvolvimento de software adaptativo, determinar o status do projeto é uma abordagem baseada em recursos, o final de cada iteração marcado por recursos concluídos resultando em software funcional.

A revisão do status do projeto deve incluir:

Onde está o projeto?
Onde está o projeto versus os planos?
Onde deveria estar o projeto?

Como os planos dos projetos de Desenvolvimento de Software Adaptativo são especulativos, mais do que a questão 2 acima, a questão 3 é importante. Ou seja, a equipe do projeto e os clientes precisam se perguntar continuamente: "O que aprendemos até agora e isso muda nossa perspectiva sobre aonde precisamos ir?"

Um fluxograma do gerenciamento de software tradicional é mostrado abaixo.

O gerenciamento de software tradicional é caracterizado pelo termo comando-controle.

Muitas organizações estão mergulhadas em uma tradição de otimização, eficiência, previsibilidade, controle, rigor e melhoria de processos. No entanto, a economia emergente da era da informação requer adaptabilidade, velocidade, colaboração, improvisação, flexibilidade, inovação e flexibilidade.

Livros de revisão e gestão de negócios de Harvard surgiram com termos como capacitação, gestão participativa, organização de aprendizagem, gestão centrada no ser humano, etc., mas nada disso está sendo aplicado na gestão de organizações modernas.

No contexto do Desenvolvimento de Software Adaptável, a lacuna parece muito maior e há uma necessidade de considerar as técnicas de gerenciamento adaptativo que se mostraram bem-sucedidas em outros campos.

Gestão Adaptativa

A gestão adaptativa tem se mostrado bem-sucedida nos ambientes onde os gerentes de recursos trabalharam junto com as partes interessadas e cientistas como uma equipe, com os seguintes objetivos -

Para aprender como os sistemas gerenciados respondem às intervenções humanas.
Para melhorar as políticas e práticas de recursos no futuro.

O princípio por trás do gerenciamento adaptativo é que muitas atividades de gerenciamento de recursos são experimentos, pois seus resultados não podem ser previstos com segurança de antemão. Esses experimentos são então usados como oportunidades de aprendizagem para as melhorias no futuro.

O gerenciamento adaptativo tem como objetivo aumentar a capacidade de responder em tempo hábil diante de novas informações e em um cenário de objetivos e preferências variados das partes interessadas. Encoraja as partes interessadas a limitar as disputas e discuti-las de maneira ordenada, enquanto as incertezas ambientais são investigadas e melhor compreendidas.

A gestão adaptativa ajuda as partes interessadas, os gestores e outros tomadores de decisão a reconhecer os limites do conhecimento e a necessidade de agir sobre informações imperfeitas.

A gestão adaptativa ajuda a mudar as decisões tomadas, deixando claro que -

As decisões são provisórias.
A decisão da administração nem sempre precisa ser certa.
São esperadas modificações.

Existem dois tipos de abordagens de gestão adaptativa -

Gerenciamento Passivo Adaptativo.
Gerenciamento Adaptativo Ativo.

Gestão Passiva Adaptativa

A gestão adaptativa visa aprimorar o conhecimento científico e, assim, reduzir as incertezas.

No gerenciamento Passivo Adaptável, um único curso de ação preferido, com base nas informações e no entendimento existentes, é selecionado. Os resultados das ações de gestão são monitorados e as decisões subsequentes são ajustadas com base nos resultados.

Essa abordagem contribui para o aprendizado e gestão eficaz. No entanto, é limitado em sua capacidade de aprimorar as capacidades científicas e de gestão para condições que vão além do curso de ação selecionado.

Gestão Adaptativa Ativa

Uma abordagem de gerenciamento Active Adaptive analisa as informações antes que as ações de gerenciamento sejam tomadas.

Uma gama de modelos de sistemas alternativos e concorrentes de ecossistemas e respostas relacionadas (por exemplo, mudanças demográficas; usos recreativos), em vez de um único modelo, é então desenvolvida. As opções de gerenciamento são escolhidas com base nas avaliações desses modelos alternativos.

Gestão de Liderança-Colaboração

O gerenciamento adaptativo é o mais adequado para o desenvolvimento de software adaptativo. A abordagem requer gerentes de recursos, ou seja, gerentes que possam trabalhar com pessoas, permitir intervenções humanas e criar um ambiente amigável.

No desenvolvimento de software, os líderes geralmente assumem essas responsabilidades. Precisamos de líderes mais do que comandantes. Os líderes são colaboradores e trabalham lado a lado com a equipe. A Liderança Colaborativa é a prática mais procurada no desenvolvimento adaptativo.

Os líderes têm as seguintes qualidades -

Segure e defina a direção.
Influencie as pessoas envolvidas e forneça orientação.
Colabore, facilite e gerencie macro a equipe.
Forneça orientação.
Crie ambientes onde pessoas talentosas possam ser inovadoras, criativas e tomar decisões eficazes.
Entenda que ocasionalmente eles precisam comandar, mas esse não é seu estilo predominante.