Análise ágil. Mitos e Realidade

I Introdução

O estande deve ser movido! Não há estação, para que algumas pessoas não façam shandarah.
Agora confuso com o banheiro, depois com uma cabana na praia ...
(x / f Características da pesca nacional)

Final do ano, resumindo, preenchendo questionários e outros enfeites de Natal dos funcionários de TI. Pela enésima vez, olho para os questionários finais das empresas de TI, projetados para identificar tendências nas abordagens do desenvolvimento de produtos. E toda vez há uma sensação de algum truque quando você responde perguntas como: "Você ainda usa o método Waterfall (modelo em cascata) ou ainda (como toda a humanidade avançada) pratica o Agile (metodologias flexíveis)". Quando você começa a descobrir com o autor desta pesquisa e o que ele entende por Agile, suas explicações de alguma forma não se encaixam muito no esboço do manifesto (Manifesto Ágil). Ele realmente pensa em muitos princípios pela primeira vez e esses mesmos princípios o colocam diretamente parado. Mas, depois de um pouco de confusão, é usada artilharia pesada com substanciamento de concreto reforçado de nossa posição: "Não estamos trabalhando na cachoeira, portanto, ágil".

A tese da Metodologia Flexível em si é tão gutta-percha que parece que muitos tentam espremer nela qualquer coisa, ou melhor, o que é mais benéfico para eles. Gradualmente, tornou-se uma tela moderna, capaz de cobrir todo tipo de falhas e até negligências, no processo de fabricação de produtos de TI e, ao mesmo tempo, como se quisesse permanecer na crista da onda, em uma tendência. Como nós não somos assim - mas essa técnica.

Vamos juntos, mais uma vez "atacar a análise" no tópico de metodologias flexíveis, tentar classificar os principais artefatos e princípios nas prateleiras e separar o significado sagrado que foi originalmente estabelecido nesse conceito do que os populistas negligentes individuais o transformam. Também comparamos as abordagens do Agile com outros métodos para uma compreensão mais precisa da linha que os separa, ou vice-versa - combina-os. Ao mesmo tempo, vamos tentar descobrir onde o uso dos princípios Agile é mais apropriado e onde não é totalmente apropriado.

II Antecedentes do surgimento de técnicas de desenvolvimento de produtos de software

A história é como uma pasta de carne: é melhor não observar como é cozinhada.
Aldous Huxley

Por uma questão de objetividade, vamos mergulhar na história e sentir as circunstâncias que formaram o terreno em que vários princípios e métodos de desenvolvimento de produtos de software, incluindo os flexíveis, amadureceram.

1. Mitos e realidade sobre Cachoeira

Como já mencionado na introdução, a Antagonism (oferta de sacrifício) para o Agile (1) foi escolhida a técnica Waterfall, que em sua forma pura era relevante no século passado, na época dos cartões perfurados e drives de fita e foi introduzida pela primeira vez no mundo em um artigo de W.W. Royce ( WW Royce), publicado em 1970.

Essa comparação, sem dúvida, ajuda qualquer outra metodologia a parecer nova e inovadora em comparação com ela. Alguns palestrantes, para maior persuasão, imaginam que o modelo Waterfall não é um iterativo, mas um fluxo de trabalho monolítico único, uma fase sucessiva: análise de requisitos, design, implementação, teste, integração e suporte. Fiquei especialmente emocionado com a frase sobre métodos de desenvolvimento, que foi observada no artigo, até o período de Ajail: “Anteriormente, os produtos eram fabricados imediatamente como um todo. Para fazer isso, fomos ao longo da cadeia: idéia → termos de referência → design → programação → teste → lançamento. ” Com licença, mas Royce usou um modelo de desenvolvimento iterativo em sua abordagem. Simplificar a idéia de maneira cínica simplesmente não é mais ético, especialmente considerando que não havia vácuo entre o Waterfall e o Agile, mas uma cadeia evolutiva bastante longa.

Embora, para ser justo, devo admitir que a maior parte do que foi dito sobre Waterfall, em geral, não está longe da verdade. Se a equipe percebeu, em algum momento, que o resultado não atendeu às expectativas, então "finalizou" o produto que não estava certo ou jogou a maior parte do trabalho na cesta e iniciou o processo quase desde o início, criando um novo produto. Por que, apesar de algum absurdo pelos padrões atuais de tal abordagem, a técnica permanece há muito tempo um carro-chefe popular no mundo do desenvolvimento de software?

Para compreender esse fenômeno, mergulharemos na atmosfera dos então Centros de Computação (CC). Deixe-me lembrá-lo que, naqueles tempos distantes e distantes, o caminho entre o design dos desenvolvedores e a execução do computador era longo e espinhoso. Ele percorreu os dispositivos de preparação de dados já esquecidos, que executam perfuração mecânica de cartões perfurados e carinhosamente chamados de "barmales". Esta operação foi realizada não pelos próprios desenvolvedores, mas por pessoas especialmente treinadas. Tendo recebido o precioso pacote de caixas de papelão perfurado, na ordem de prioridade, levando em consideração a operacionalidade do computador, esses cartões perfurados foram colocados em um dispositivo especial (novamente, pessoas especialmente treinadas) que liam o código e somente depois disso, ele teve a chance de ser executado pelo processador. Mas se um dos cartões perfurados no baralho atolou durante a leitura, você deve repetir o procedimento para ler o baralho inteiro novamente. E Deus não permita, um erro foi manifestado no código, foi necessário recorrer à ajuda de "barmaley" novamente, interromper parte das cartas perfuradas e, sem confundi-las com os lugares no baralho, repetir todo o procedimento mais uma vez desde o início. Com esses encantos, o trabalho dos então programadores era pontilhado o tempo todo. Naturalmente, mudanças rápidas nos requisitos para o produto desenvolvido no decorrer de sua implementação, com essa abordagem, estavam fora de questão. Os requisitos de alta qualidade para o produto em desenvolvimento e o processo estritamente regulamentado de sua produção eram para todas as equipes.

2. E se não Cachoeira?

Mas o tempo passou e tudo mudou. Os computadores pessoais gradualmente se tornaram a cápsula para o mundo digital, deslocando enormes monstros barulhentos no quintal. O número de operações executadas pelos processadores por unidade de tempo aumentou em várias ordens de magnitude, e a velocidade da operação de entrada / saída de informações simplesmente pareceu ser "espaço". Os programadores obtiveram acesso direto e instantâneo à execução do código digitado no teclado - recursos de computação, sem sair do lugar. Agora ficou muito mais fácil fazer alterações no software, e já imaginar que alguém continua trabalhando de acordo com o método Waterfall em sua forma pura é simplesmente ridículo.

A seleção natural e a necessidade de adaptação forçaram as técnicas a sofrer mutações. Além disso, a maioria deles emprestou um modelo de desenvolvimento iterativo de seus antecessores. Simplesmente, os ciclos de execução foram significativamente reduzidos e aprimorados.

Mas então outro infortúnio surgiu. Até agora, oportunidades sem precedentes permitiram que a automação de seções individuais da produção continuasse com a automação de empresas inteiras e até mesmo varresse totalmente o setor. Com esses volumes de operações e quantidades de recursos envolvidos, não foi possível simplesmente simplificar os métodos de desenvolvimento de software. Pelo contrário, eles se tornaram ainda mais abrangentes e formalizados.

Uma das técnicas mais conhecidas que usam um modelo de desenvolvimento iterativo é o Rational Unified Process (RUP). Foi desenvolvido e implementado na segunda metade dos anos 90 na Rational Software.

O termo RUP oculta não apenas uma metodologia de desenvolvimento de software, mas também um conjunto de ferramentas que permitem gerenciar processos de desenvolvimento. Dentro da estrutura deste tópico, é especialmente interessante notar que a metodologia RUP (2) descreve um processo geral abstrato com base no qual uma organização ou uma equipe de projeto pode criar seu próprio processo de desenvolvimento de software exclusivo, focado em suas próprias necessidades. Como você diz que essa abordagem não é flexível?

Com análises e comparações adicionais, pode-se notar que alguns dos principais recursos do RUP também são parcialmente herdados da técnica Waterfall.

1. Abordagem cíclica à produção de software . O ciclo de vida do projeto RUP é dividido em 4 fases e 9 processos de trabalho.
2. Processo de desenvolvimento iterativo . O projeto RUP consiste em uma sequência de iterações com uma duração recomendada de 2 a 6 semanas.
3. Desenvolvimento obrigatório de requisitos . O RUP usa casos de uso ou casos de uso para descrever requisitos. Cada caso de uso é uma descrição do cenário de interação do usuário com o sistema que executa completamente uma tarefa específica do usuário.
4. Uma abordagem incremental que visa incrementalmente a funcionalidade do produto. A principal unidade de planejamento de iteração é o caso de uso, que permite fazer as alterações necessárias nos requisitos, decisões de design e implementação durante o projeto.

Damos especial atenção ao último ponto. Ele afirma que é a presença de requisitos detalhados elaborados de uma forma específica que apenas fornece a capacidade de efetivamente fazer alterações nas decisões de design e na implementação do produto durante o projeto. Inclusive nos estágios finais do projeto.

O RUP é frequentemente considerado por engano um processo pesado, com um alto nível de formalismo. Mas isso não é inteiramente verdade, pois o processo RUP pode (e deve) ser personalizado para as especificidades de uma organização e projeto em particular. Mesmo que a equipe adote um pequeno produto de software que precisará ser desenvolvido, dimensionado ou integrado com outros sistemas, o RUP permitirá que ele lide confortavelmente com todos os desafios que surgirem.

3. A derrubada das fundações

E depois mais. Tendo pulado o período do advento dos computadores pessoais em nosso mundo, passamos à aparência de todos os tipos de estúdios de ferramentas, ferramentas de visualização e modelagem, criadores de aplicativos automáticos etc. Em toda essa variedade de auxiliares, que, por exemplo, permitem arrastar e soltar um elemento no diagrama com o mouse e alterar automaticamente o código do aplicativo para o produto final, começaram a desvalorizar o próprio papel das técnicas de desenvolvimento de software. Com essas ferramentas avançadas, com falta de tempo ou recursos, você pode abandonar alguns fluxos de trabalho da metodologia e, ao mesmo tempo, não perder nada. Pelo menos a curto prazo. Essas liberdades e, como se viu, a impunidade, com o devido profissionalismo dos artistas, levaram as cabeças mais desesperadas à proclamação de uma nova tendência de TI - "Metodologias de desenvolvimento flexíveis".

Aqui neste ponto da linha vermelha, enfatizo mais uma vez uma tese muito importante, talvez a chave - “com o devido profissionalismo”! Ou seja, especialistas de alta classe que têm dezenas de projetos concluídos em larga escala atrás de suas cabeças, capazes de esboçar o diagrama de classes de um pequeno módulo em suas cabeças em 20 minutos, estimam imediatamente os processos que mudam de estado, sugerem dependências críticas etc. decidiu que, em alguns casos, pode prescindir da aprovação obrigatória dos regulamentos adotados. Ao mesmo tempo, o projeto ainda será levado ao resultado esperado com qualidade aceitável em um tempo significativamente menor. Isso é bom ou ruim? À primeira vista, é simplesmente maravilhoso. No segundo, nem tudo é tão simples. Analisaremos os prós e contras um pouco mais tarde.

Definitivamente ruim aqui é outro. Jovem e ousado, olhando de lado, faça a pergunta: "Mas o que foi possível?" Eles nunca viram requisitos de qualidade em seus olhos, não sabem ler diagramas, mas agora não precisam. Isso é tudo! os requisitos estão agora cancelados! Diagramas, processo de modelagem - lá no forno. Somente código, código e comunicação. Como um bônus - eles podem deixar seus comentários no código para as futuras gerações do mesmo insolente.

Com isso, a excursão histórica pode ser concluída e movida, por assim dizer, para mais perto do corpo ...

III Análise do fenômeno de metodologias flexíveis

Toda entidade deve ser analisada em termos de lógica antes de colocá-la na sua boca.
Woody Allen.

1. Definições de Metodologias Flexíveis

Como Adjayl existe há muitos anos, vamos aproveitar as informações disponíveis e começar revendo as definições e opiniões que estão no topo da rede. E já tendo se afastado deles, passaremos para o principal artefato - o Manifesto do desenvolvimento flexível de software.

A primeira coisa que foi encontrada em um mecanismo de pesquisa pelo termo Agile:

A metodologia de desenvolvimento flexível (desenvolvimento ágil de software, métodos ágeis) é uma série de abordagens ao desenvolvimento de software focadas no uso do desenvolvimento iterativo, na formação dinâmica de requisitos e na garantia de sua implementação como resultado da interação constante em grupos de trabalho auto-organizados, compostos por especialistas de vários perfis.

Os seguintes pontos importantes podem ser distinguidos desta definição:

1. Usando uma abordagem iterativa . Não há nada novo aqui, eu não ouvi falar sobre métodos de desenvolvimento de software que negam esse princípio;
2. A formação dos requisitos é realizada em etapas, no decorrer do desenvolvimento do produto . Essa é uma diferença fundamental de muitas outras técnicas. De certa forma, oferece uma vantagem; de certa forma, apresenta limitações fundamentais. Discutiremos mais tarde ambos;
3. Usando a constante interação estreita de todos os membros da equipe , incluindo o cliente. A maioria das outras metodologias, é claro, presta atenção ao trabalho em equipe, inclusive com os clientes, mas posicionar essa comunicação como um recurso adicional do projeto que oferece uma vantagem absoluta é mais exclusivo;
4. Equipe auto-organizada . Supõe-se que cada iteração termine com uma análise e uma mudança construtiva no processo, o que contribui para o desenvolvimento contínuo da equipe. Técnicas semelhantes são provavelmente emprestadas de técnicas anteriores. Por exemplo, ele pratica o RUP.

Em princípio, não conseguimos descobrir muito desta descrição, então vamos aos esclarecimentos:

A maioria das metodologias flexíveis visa minimizar os riscos, reduzindo o desenvolvimento a uma série de ciclos curtos chamados iterações, que geralmente duram de duas a três semanas. Cada iteração, por si só, parece um projeto de software em miniatura e inclui todas as tarefas necessárias para produzir um mini-aumento de funcionalidade: planejamento, análise de requisitos, design, programação, testes e documentação.

Mas já consideramos a mesma abordagem no bom e velho RUP. Ou seja, também não há nada fundamentalmente novo aqui.

A maioria das definições que encontrei também é abstrata e vaga, há muito pouca informação que permite que você pegue e comece a usar a flexibilidade imediatamente. Mas aqui se abre outro aspecto igualmente importante da abordagem, que traz clareza à superficialidade pela qual todo o tópico em questão se cruza. Aqui está um exemplo:

O Agile não inclui práticas, mas define os valores e princípios que orientam as equipes. Agile é uma família de processos de desenvolvimento, não a única abordagem para o desenvolvimento de software, e é definida pelo Agile Manifesto.

Agile é uma maneira de pensar com seu próprio sistema de valores. É semelhante à filosofia, religião ou cultura - o mesmo conjunto de atitudes em que uma pessoa acredita e que influencia seu comportamento.

Aparentemente, por essa mesma razão, existem inúmeras disputas em torno das metodologias flexíveis. Não há muito na idéia do que você realmente pode sentir. Aparentemente, por causa disso, você pode chamar algo de suas próprias (quase todas), metodologias flexíveis e não convencionais, e não ser pego no profissionalismo. Na minha opinião, isso é aceitável; se você quiser estar na tendência, nomeie sua abordagem para o desenvolvimento da moda o máximo possível, se apenas o processo de desenvolvimento e o produto final em si não sofrerem.

Lembro-me de um caso da minha prática, quando uma grande empresa de TI, antes de um novo projeto em larga escala, decidiu melhorar seus processos tecnológicos. Para isso (de acordo com as recomendações), foi convidado um especialista em metodologias flexíveis, em cujos ombros essa missão responsável foi confiada. Depois de ler uma palestra muito curta sobre o modo de pensar e o sistema de valores da Agil, ele começou a descobrir como as coisas realmente estão na produção de software na empresa. Encontrando falhas e inconsistências nos processos existentes, em conjunto com a equipe da empresa, selecionamos as formas e métodos mais adequados para resolvê-los. Felizmente, essas deficiências não eram segredo para ninguém, e várias razões os impediram de superá-las. Por exemplo: falta de tempo, contradições entre equipes subordinadas a diferentes setores verticais da administração, medo de assumir responsabilidades etc. Como todo esse evento foi patrocinado pela alta gerência da empresa, e o especialista convidado era um profissional de TI de primeira classe, as inovações desenvolvidas foram implementadas quase dentro do prazo e com um efeito positivo muito sensível. Isso é apenas o manifesto de metodologias flexíveis que eles não tinham nada a fazer. Como resultado, a maioria dos funcionários da empresa permaneceu confiante de que agora mudou completamente para o Agile, abandonou todo o resto. Tudo isso se assemelha muito a um conto de fadas sobre como um soldado cozinhava mingau de um machado, astuciosamente retirando os ingredientes que ele precisava dos proprietários e melhorando o sabor do prato. Isso é apenas o machado não é fervido.

Mas como estamos aqui para analisar imparcialmente o fenômeno Agile, continuaremos, portanto, nosso estudo. Vamos para a fonte original - o Manifesto de Ajail:

2. Vamos analisar as principais idéias do Manifesto Ágil

Ideias-chave:

1. Pessoas e interação são mais importantes que processos e ferramentas;
2. Um produto de trabalho é mais importante que a documentação abrangente;
3. A colaboração com o cliente é mais importante do que o acordo sobre os termos do contrato;
4. A disposição de mudar é mais importante do que seguir o plano original.

Vamos começar com uma mosca na pomada. Para mim, pessoalmente, todos os pontos são controversos. Vamos em ordem:

Ponto 1 . Na minha opinião, uma das principais razões para o surgimento do Ajail, como escrevi acima, foi o rápido desenvolvimento de sistemas de automação para processos de desenvolvimento de software, o que permitiu negligenciar os regulamentos. Ou seja, é apenas a exclusão do trabalho humano monótono por processos robóticos que nos permite produzir resultados mais confiáveis ​​e previsíveis, incluindo a manutenção de uma interação de alta qualidade dos próprios processos. Portanto, sobre “Pessoas - a coisa mais importante”, na minha opinião, esse é apenas um slogan que ajuda a divertir a vaidade humana dos membros mais sentimentais da equipe.

Mas, para ser sincero, observo que esses slogans, batendo palmas em retrospecto e outros sentimentos sobre os jovens funcionários, são bastante válidos e até (no início) aumentam o espírito de equipe. É importante que não haja vazio e decepção quando a compreensão do feriado se foi.

Ponto 2. O desenvolvimento é apenas um breve momento na vida de um sistema automatizado e, em seguida, começa a dura vida cotidiana de sua operação, modernização e expansão de oportunidades. Você já tentou manter um bom produto de software, completamente desprovido de documentação? O que está acontecendo nele e por que exatamente, e mais importante, como pode ser corrigido para que comece a funcionar de maneira um pouco diferente? E se ele interage com outro software, o que geralmente pode ser alterado nele e o que não pode ser tocado? Tudo isso se assemelha a caminhar em um campo minado.

E aqui adicionamos o princípio do desenvolvimento faseado. Sem documentação, porque ainda será necessário determinar em que estágio do desenvolvimento o produto geralmente está localizado.

Mas, por uma questão de objetividade, deve-se observar que, quando uma equipe entrega um produto acabado a um cliente, montado a partir de uma pilha de módulos, instalado em uma pilha de vários equipamentos e até mesmo sob uma carga "não-filho", então com um alto grau de probabilidade, pode ser necessário modificar ou alterar o código. Às vezes, as mudanças podem ser numerosas e profundas. E aqui definitivamente não é formalismo, é necessário salvar o rosto da equipe. Durante esse período, você pode adiar a documentação para tempos melhores e editar o código com urgência. Quero observar que é muito mais conveniente fazer isso quando houver documentação decente disponível, elaborada na fase de desenvolvimento, com uma descrição de como tudo funcionou no momento da introdução.

Ponto 3. Bem, para começar, o ponto não entende a própria oposição. Mas o acordo dos termos do contrato não é uma colaboração com o cliente? Se o cliente, como resultado do esclarecimento dos termos do contrato com a equipe de desenvolvimento, for capaz de entender a quantidade de trabalho, perceber aproximadamente o custo de sua implementação e, mais importante, imaginar o resultado que ele pode obter em alguns indicadores realmente tangíveis (funções comerciais automatizadas, modelos de layout etc.) .). Afinal, será mais fácil para ele tomar uma decisão: se ele precisa desse produto em particular, se está pronto para financiar sua produção etc. Isso não é uma colaboração?

Mas e a cooperação? Apenas conversas calorosas pela vida sem obrigações? Goste ou não, se o projeto for comercial, todas as partes precisam, antes de mais nada, alcançar seus objetivos no projeto. E os termos do contrato - basta fixar esses mesmos objetivos e maneiras de alcançá-los. No momento da elaboração e aprovação do contrato, ambas as partes começam a perceber que devem obter parceiros e o grau de responsabilidade em caso de falha no alcance do resultado acordado. O contrato, neste caso, é um motivador e um meio de resolver desacordos, para ambos. Afinal, os mais terríveis não são extremos, mas incertezas.

Sem contrato - sem responsabilidade, sem entendimento completo do que deve resultar da conclusão do projeto. Essa abordagem combina com você - boa sorte.

Ponto 4. Já dissemos acima que, se existem ferramentas modernas para projetar e desenvolver software, não há dificuldade específica para uma equipe de desenvolvedores profissionais fazer alterações na implementação de um produto em quase qualquer estágio. Esse é um processo normal, dependendo em maior medida da profundidade do entendimento da equipe, do produto que eles estão desenvolvendo. Portanto, neste caso, a questão não é tanto a disposição da equipe de fazer mudanças, mas quem pagará por todos esses excessos. É aqui que o contrato elaborado qualitativamente vem à tona, que determina quem e em que casos sofre perdas materiais com a reforma. Se os desenvolvedores refazem às suas próprias custas o que eles entenderam mal ou o cliente que não explicou corretamente o que ele precisava.

3. Discuta os princípios do Manifesto Ágil

Como queremos ter uma mente aberta sobre o tópico, vamos pelo menos brevemente tocar nos princípios que o Agile Manifesto explica:

• satisfação do cliente devido ao fornecimento precoce e ininterrupto de software valioso;
• bem-vindo mudanças nos requisitos, mesmo no final do desenvolvimento (isso pode aumentar a competitividade do produto resultante);
• entrega frequente de software de trabalho (todos os meses, semanas ou mais frequentemente);
• comunicação diária e próxima do cliente com os desenvolvedores durante todo o projeto;
• o projeto é realizado por indivíduos motivados, com as condições de trabalho, apoio e confiança necessários;
• O método recomendado de transmissão de informações é uma conversa pessoal (face a face);
• executar software é a melhor medida de progresso;
• , ;
• ;
• — ;
• , ;
• . .

A maioria dos itens acima não contradiz outros métodos e é muito aconselhável.

Mas nem sempre esses princípios podem realmente ser usados ​​na prática. Por exemplo, um cliente nem sempre consegue colaborar com uma equipe na discussão de soluções. Ele muitas vezes não tem tempo e, às vezes, nenhum desejo especial. Então você precisa de um profissional - um analista, capaz de falar de maneira concisa e discreta, tendo se baseado na confiança e usando todas as suas “coisinhas” psicológicas, para extrair informações úteis e já penteando-as de maneira suave e suave, transmitindo-as para a equipe de desenvolvimento da forma mais adequada para implementação. É interessante que se isso acontecer, o trabalho da equipe não seja mais considerado flexível?

Pelo mesmo motivo, nem sempre é possível organizar entregas frequentes. E esse processo pode ser seriamente afetado por vários módulos integráveis ​​desenvolvidos por equipes diferentes, que podem ser montados (módulos) ao mesmo tempo, no mesmo equipamento, é muito problemático. Sim, e equipamentos específicos, acontece que ele é entregue diretamente mais próximo da entrega. Isso também deve ser levado em consideração.

E há uma discórdia na declaração sobre "os melhores requisitos técnicos, design e arquitetura", apesar do fato de que os princípios do Agile, em princípio, não aceitam a documentação e todo esse jazz. Se você “ofender” uma abordagem formal da documentação, é improvável que seja a melhor (sabedoria popular).

Além disso, do meu ponto de vista, eleva uma queixa - elevar para o nível do melhor método de transmissão de informações - "conversa pessoal (cara a cara)". Na minha opinião, transmitir informações em um projeto é muito mais eficiente, por exemplo, usando um rastreador de tarefas ou um sistema wiki, sem, é claro, excluir a comunicação pessoal.

IV Aplicação de metodologias ágeis

Na inovação, você deve ser teimoso e flexível.
Se você não é teimoso, você se recusará a experimentar cedo demais.
Se você não for flexível, baterá a cabeça contra a parede e não verá outra solução para o problema que está tentando resolver.
Jeffrey Preston

Se tantas avaliações críticas surgiram durante a revisão, como tudo isso funciona?
O sucesso do Agile, aparentemente, contribui para a eficácia da metodologia em pequenos projetos e a comunalidade (simultaneidade) do uso de todos os itens acima.

1. Benefícios do uso do Agile

Através do uso de User Stories, a equipe de desenvolvimento é capaz de atingir o nível necessário de entendimento nas discussões com o cliente. Para o cliente, o limiar de entrada no tópico é reduzido, é mais fácil para ele operar com o conteúdo do projeto, estabelecendo prioridades, corrigindo imprecisões etc. Além disso, até mesmo os gerentes de projeto, produto e outros que têm muito conhecimento sobre as especificações de requisitos com base em histórias simples de usuários têm a oportunidade de manipular tarefas em um projeto com muito mais facilidade e entender as expectativas dos clientes.

Devido às freqüentes entregas de protótipos, é possível evitar grandes discrepâncias entre as expectativas do cliente e as opções oferecidas pelos executores das soluções. A cada novo lançamento, cada vez mais os aproximamos. Os rebaixamentos no tempo de execução e, consequentemente, as perdas financeiras também não são grandes e previsíveis, podem ser inseridos diretamente no plano do projeto.

Parece algo assim: O cliente espera receber algumas novas funcionalidades, cujos recursos ele próprio não representa totalmente. Existe uma “cooperação estreita”, como resultado do contratado oferecer uma solução piloto, que, em regra, não atende completamente às expectativas do cliente, das quais a equipe é informada. Este episódio incentiva uma nova "cooperação estreita", como resultado do qual o contratado faz ajustes no protótipo e apresenta novamente o produto ao cliente. E assim, em círculo, até que uma determinada funcionalidade conquiste completamente a mente do cliente, ou até que ela fique tão "cheia" de cooperação que não será confortável permanecer nela. Se a complexidade do produto e o número de funções automatizadas permitem executar de 3 a 6 ciclos para a felicidade completa e incondicional do cliente, por que não,esquema bastante viável.

A única coisa em que quero focar é um ponto fundamental que muitas vezes dispensa a devida atenção - a necessidade de consertar documentos (pelo menos depois do fato), cuja solução técnica foi alcançada como resultado de tentativa e erro. Isso é importante para o cliente, que posteriormente pode contratar uma nova equipe para finalizar ou dimensionar o produto, e para a própria equipe, que, em primeiro lugar, será capaz de replicar a solução ou suas partes e, em segundo lugar, se for recrutada para atualizar o produto, mais rápido e melhor para ingressar no processo.

2. Pequenos projetos - um ambiente confortável para o Agile

Para pequenos projetos, o uso de histórias de usuários, em vez de todos os requisitos do produto desenvolvido, permite simplificar e facilitar a comunicação com o cliente. Devido à interação freqüente com o cliente e à simplicidade da forma de comunicação, a equipe não lava, e o skate desenvolve requisitos aceitáveis ​​para a funcionalidade do produto. Na ausência de algoritmos complexos e integração com outros softwares, isso pode acontecer sem muita perda. Nível do domínio do problema - feche histórias do usuário e domínio da solução - comentários no código.

Usando uma equipe de profissionais, você não pode se preocupar em elaborar a arquitetura da solução e as especificações dos requisitos do produto. Certamente, algo como a equipe ou seus membros já decidiu e eles têm por trás os modelos e as melhores práticas apropriadas.

Se este produto é único e não está planejado desenvolvê-lo, isso é suficiente.

3. Como posso usar o Agile em projetos de tamanho médio

Usar o Agile em projetos de tamanho médio também pode ser muito eficaz.

Em projetos maiores, pode ser usada uma variedade de plataformas de automação, equipadas com modelos prontos, melhores práticas, ferramentas de auto-documentação, etc. Isso simplifica muito os processos formais, incluindo design, modelagem e documentação. As soluções apresentadas nesses casos geralmente são duplicadas, com um número limitado de melhorias e alterações.

O maior efeito pode ser obtido se decisões semelhantes anteriores forem documentadas. Com base nessa base, você pode dedicar mais tempo não ao design e modelagem, mas à seleção, juntamente com o cliente, do protótipo desejado. “Experimente, coloque e vá embora. Não pressione? ". É importante que novas soluções implementadas também sejam bem documentadas. Nesse caso, a equipe recebe um conjunto de blocos e instruções para montar vários modelos a partir deles, que podem ser oferecidos aos futuros clientes para escolher.

Nesse modelo de trabalho, é importante entender que o Agile não nega a importância do processo de documentação, simplesmente permite atrasar sua formação, priorizando a construção do próprio produto (se possível na situação atual). A documentação pode ser formada já após o recebimento de um produto sustentável, consolidando os resultados alcançados e, conforme observado acima, ajudando a não perder no futuro o fio de entendimento das regras do sistema.

4. Como usar efetivamente o Agile em grandes projetos de integração

Em projetos grandes e complexos, nos quais a documentação de alta qualidade é mantida, existe uma idéia arquitetônica do produto e do processo de sua produção, "partes" do produto podem ser terceirizadas para pequenas equipes. Essa transferência ocorre após um estudo detalhado da arquitetura geral e a preparação de requisitos de alto nível para novos subsistemas. E agora essas partes relativamente pequenas podem ser implementadas com bastante eficiência usando o Agile.

O mesmo esquema é aplicável a pequenas melhorias ou desenvolvimento gradual de um sistema complexo de grande porte, especialmente se você precisar realizar algum trabalho de pesquisa.

Outra opção para o uso do Agile em grandes projetos pode ser efetivamente aplicada em caso de entrega emergencial do produto ao cliente. Em vista da falta crítica de tempo e recursos para seu refinamento e correção, é precisamente a flexibilidade na abordagem que pode ajudar a evitar um fiasco. Em tais situações, na minha opinião, essa metodologia específica é ótima.

Nesta seção, vale mencionar os métodos existentes baseados no Agile, mas gravitando para resolver problemas de larga escala.

O Agile Unified Process (AUP) é uma versão simplificada do Unified Process (UP) desenvolvido por Scott Ambler. Essa metodologia de desenvolvimento de software combina elementos de metodologias flexíveis e um processo unificado. Em particular, a AUP envolve desenvolvimento por meio de testes (TDD), uso de modelagem flexível (modelagem ágil em inglês) e refatoração de banco de dados, gerenciamento flexível de mudanças.

O OpenUP é um método iterativamente incremental de desenvolvimento de software. Posicionado como uma versão leve e flexível do RUP. O OpenUP divide o ciclo de vida do projeto em quatro fases: a fase inicial, as fases de refinamento, design e transferência. O ciclo de vida do projeto garante que as partes interessadas e os membros da equipe recebam pontos de familiarização e tomada de decisão ao longo do projeto. Isso permite que você monitore efetivamente a situação e tome decisões oportunas sobre a aceitabilidade dos resultados. O plano do projeto define o ciclo de vida e o resultado final é a aplicação final.

5. Como não usar o Agile

Uma seção igualmente importante, talvez para a qual toda a análise foi contemplada.

1. O líder no meu anti-rating é a situação em que eles tentam usar o Agile, ou melhor, alguns de seus princípios, não para atingir objetivos específicos que possam ser alcançados, mas simplesmente #CRAFT. Por ser uma tendência, está nos lábios de todos. Por exemplo, alguém compartilhou críticas positivas na festa de TI, um pouco efêmeras e até arrogantes, mas houve um boato, uma comitiva apareceu. E agora eles já se autodenominam seguidores do Agile, sentem-se em comunicação com os demais - pertencentes a um determinado clube de elite. Tudo isso contribui para a aparente simplicidade da metodologia e os contornos nebulosos de suas fronteiras. As implementações nesse princípio ocorrem sem pensar e formalmente. As pessoas formal e sem princípios implementam princípios projetados para reduzir o formalismo.
   
   Por exemplo, um dos casos mais recentes. Em uma empresa, realizando Retrospectivas, eles foram proibidos pelos Timlids. Aqui está um chip. Inesperadamente. Primeiro pensamento: bem, talvez eles estejam certos para que não haja pressão das autoridades sobre a equipe ao discutir problemas, etc. Mas os Timlids estão ofendidos, estão perdidos e querem descobrir. Tentei convencer que eles dizem que poderia ser melhor, o principal é que você obtenha uma lista de desejos, com uma lista do que precisa ser alterado, do que precisa ser aprimorado etc. E aqui um segredo terrível foi revelado. E não há resultados e desejos para melhorar os processos como resultado dessas reuniões. Senhores IT_shniki, e por que então uma retrospectiva? Apenas se elogiem e aumentem o espírito de equipe? A, digamos, e B. disseram: Afinal, o principal objetivo desse processo de metodologia é que: "A equipe deve analisar sistematicamente maneiras possíveis de melhorar a eficiência e ajustar o estilo de seu trabalho".
2. A segunda situação em meu ranking é quando as equipes decidem economizar na preparação de requisitos em projetos com algoritmos comportamentais ou lógicos complexos. Ou seja, quando a história do usuário é apenas uma pequena dica do iceberg do problema, e sua parte principal não é visível e requer análise e design detalhados e detalhados para implementação. O que acontece com isso?
   
   Antes de iniciar o trabalho, nem o cliente nem os desenvolvedores compreendem aproximadamente a quantidade de trabalho que precisam executar. E de acordo: ou o cliente pagará, pagará e pagará, toda vez que lhe explicar que tudo ficou muito mais difícil e agora o trabalho ainda não se repete. E, afinal, será uma pena desistir e gradualmente começará a roer o entendimento severo de que esse produto "dourado" nunca será recompensado. Os desenvolvedores, tendo concordado em concluir o trabalho por um determinado período / tempo, terminam e refazem o produto (gratuitamente) às suas próprias custas até o cliente ficar sem imaginação, ou se compadecer das vítimas de uma abordagem flexível.
3. Um terceiro lugar honroso é considerado pela situação em que, em um grande projeto multifuncional (e de repente também em um projeto de integração), a equipe decide economizar na elaboração da arquitetura da solução e começa a implementar histórias de usuários individuais em breves iterações. Com um alto grau de probabilidade, acontecerá que, após 3-5 iterações, ao tentar criar um novo funcional, é necessário refazer todo o anterior, pois os princípios fundamentais nos quais esse funcional deveria ter sido baseado não foram levados em consideração. Pior ainda, se após a 10ª iteração for constatado que as tecnologias selecionadas não permitem satisfazer todas as necessidades do cliente e é necessário iniciar tudo de novo. Talvez mudando o comando.
4. A situação em que uma startup nítida e incrivelmente flexível está invadindo os espaços abertos de um segmento de mercado lento não caiu entre os três primeiros. Uma startup, também é uma startup, que não possui fundações, títulos, anexos e ao mesmo tempo estabilidade e estabilidade. Simplificando, quase não existe documentação, a equipe não é harmoniosa e geralmente muda. O mercado está literalmente destruindo a equipe, exigindo cada vez mais novas soluções no campo apostado, e todos os projetos subseqüentes estão simplesmente desmoronando diante de nossos olhos. Na maioria das vezes, isso é explicado pelo fato de a equipe não entender os processos de produção industrial de software , organização da entrega e suporte ao produto.

Resumir

Ao preparar este artigo, tentei ajudar as equipes interessadas na abordagem Agile a destacar e formalizar os desafios que eles deveriam enfrentar de uma maneira ou de outra, além de encontrar possíveis soluções para superá-los. Tentei considerar o tópico o mais tolerante possível, tanto para os apologistas pela introdução de uma ou mais metodologias desse grupo quanto para os oponentes que desejam desmascarar o halo da flexibilidade e se recusar a usá-lo.

Espero que a análise ajude as equipes que usam outras metodologias a tirar proveito da abordagem Agile, se necessário.