O livro “Pure Agile. Noções básicas de flexibilidade

Olá, habrozhiteli! Entregamos à gráfica mais uma novidade! Quase vinte anos se passaram desde que o Manifesto Ágil apareceu. O lendário Robert Martin (tio Bob) percebeu que era hora de tirar o pó dos princípios do Agile e novamente contar sobre a abordagem flexível não apenas para a nova geração de programadores, mas também para especialistas de outras indústrias. O autor dos livros “Código Limpo”, “Programador Ideal”, “Arquitetura Limpa”, que era amado pelo pessoal de TI, estava nas origens do Agile. O Pure Agile elimina o mal-entendido e a confusão que, ao longo dos anos de existência do Agile, tornaram mais difícil o uso do que o plano original. Em essência, o Agile é apenas uma pequena seleção de métodos e ferramentas que ajudam pequenas equipes de programadores a gerenciar pequenos projetos, ... mas levam a excelentes resultados,porque todo grande projeto consiste em um grande número de tijolos. Cinco décadas de trabalho com projetos de todos os tipos e tamanhos imagináveis ​​permitem ao tio Bob mostrar como o Agile deve realmente funcionar. Se você deseja entender os benefícios do Agile, não procure maneiras fáceis - você precisa usá-lo corretamente. O Pure Agile mostra como fazer isso para desenvolvedores, testadores, gerentes, gerentes de projeto e clientes.

Excerto. A primeira coisa a saber

Qual é a primeira coisa que você precisa saber sobre o projeto? Antes de descobrir o nome do projeto ou os requisitos para ele, antes de fazer qualquer movimento, você precisa obter mais informações. Claro, esses são os prazos. Depois que as datas são selecionadas, elas precisam ser corrigidas. Não faz sentido discutir os termos, porque eles são definidos em conexão com razões comerciais objetivas. Se setembro deve chegar, não é só isso. Talvez em setembro algum tipo de exposição ou reunião de acionistas esteja planejada, ou talvez os fundos simplesmente acabem. Seja qual for o motivo, ele tem alguns antecedentes importantes. E o motivo não mudará simplesmente porque, para alguns desenvolvedores, o volume de tarefas parece esmagador.

Ao mesmo tempo, os requisitos podem mudar em um fluxo contínuo que não pode ser corrigido.

E também há uma razão para isso: os clientes geralmente não sabem exatamente o que desejam. Eles parecem saber que problema precisam resolver, mas traduzir esse conhecimento em requisitos de projeto é sempre difícil. Portanto, há uma constante reavaliação e repensação de requisitos. Novos recursos são adicionados.

Alguns antigos desaparecem. A interface do usuário muda rapidamente - em semanas, se não dias.

É assim que o mundo do desenvolvimento de software se parece. Neste mundo, os prazos são fixos e os requisitos mudam constantemente. E de alguma forma, no contexto de tudo isso, os desenvolvedores precisam concluir o projeto com sucesso.

Coleção

O modelo em cascata nos profetizou uma maneira de contornar essa tarefa. Para explicar o quão sedutor e ineficaz foi ao mesmo tempo, citarei uma reunião como exemplo.

Foi o primeiro de maio. Big Boss chamou subordinados para a sala de conferências.

O chefe começou: “Temos um novo projeto. É necessário terminá-lo no dia primeiro de novembro. Ainda não temos requisitos. Eles serão anunciados para nós nas próximas semanas. Quanto tempo vai demorar para analisar o projeto? ”

Começamos a nos olhar interrogativamente. Todo mundo ficou em silêncio, com medo de falar demais. Ninguém tinha idéia do que responder. Alguém murmurou: "Portanto, não temos requisitos, por que devemos começar?"

“Imagine que eles são! Gritou o chefe. "Você sabe como tudo funciona." Vocês são especialistas! Eu não preciso de datas exatas. Eu só preciso preencher a programação de alguma forma. Lembre-se de que, se levar mais de dois meses, você poderá esquecer com confiança o projeto. ”

Alguém murmurou interrogativamente: "Dois meses?" O chefe considerou concordar com as condições: “Ótimo! Apenas o que eu estava pensando. Agora me diga quanto custa o design?

E, novamente, todo mundo congelou em confusão, a sala estava cheia de silêncio mortal. Nós contamos. E percebemos isso até o primeiro de novembro apenas seis meses. A conclusão se sugere. "Dois meses?" - você pergunta.

"Está certo! - o grande chefe sorriu radiante. - Como eu pensava. E ainda temos dois meses para implementação. Obrigado a todos, você é livre! "
Muitos leitores provavelmente se lembraram de que algo assim já lhes acontecia. Quem não teve isso, bem, você tem sorte!

Fase de análise

Então, suponha que saímos da sala de conferências e nos dispersássemos pelos escritórios. o que fazer a seguir? A fase de análise começa - isso significa que você precisa analisar alguma coisa. Mas o que exatamente chamamos de análise?

Se você ler livros sobre o tópico de análise no desenvolvimento de software, verá que cada autor fornece sua própria definição. Não há consenso sobre o que é análise. Pode ser a criação de uma decomposição estrutural de requisitos. Ou talvez - detecção e especificação de requisitos. Pode ser a criação de um modelo ou objeto de dados fundamental, e assim por diante ... A melhor definição de análise é esta: é isso que os analistas fazem.

Claro, existem coisas óbvias. Precisamos avaliar o tamanho do projeto, prever indicadores dos principais recursos técnicos, econômicos e humanos. Você precisa garantir que o horário de trabalho seja viável. Este é o menor que a empresa espera de nós. O que quer que seja chamado de análise, é exatamente o que faríamos nos próximos dois meses.

Essa é uma espécie de fase favorável do projeto. Todo mundo navega calmamente na Internet, realiza pequenas transações, se reúne com clientes e usuários, desenha belos gráficos, simplesmente coloca, se diverte.

Então, o primeiro de julho, um milagre acontece. A análise está completa.

Por que pensamos assim? Porque já é o primeiro de julho. Se, de acordo com o cronograma, a etapa de análise for concluída no dia primeiro de julho, essa etapa será concluída no dia primeiro de julho. Não estamos atrasados, está? Portanto, organizaremos uma pequena festa com balões e discursos de fogo, celebraremos a transição da etapa de análise para a etapa de design.

Fase de desenho

O que fazer agora? Claro, vamos projetar. Mas o que é design ?

Sabemos um pouco mais sobre a fase de design do software. Nesta fase, dividimos o projeto em módulos separados e projetamos as interfaces entre esses módulos. Nesta fase, também assumimos quantas equipes precisaremos e como essas equipes serão interconectadas. Em geral, o cronograma de trabalho precisa ser esclarecido, a fim de elaborar um plano de implementação plausível e viável.

É claro que, nesta fase, algo muda inesperadamente. Novos recursos são adicionados. As funções antigas desaparecem ou são ajustadas. E seria bom olhar para trás e analisar as mudanças novamente, mas tempo é dinheiro. Portanto, estamos tentando, de todas as maneiras possíveis, fazer alterações no design.

E então um novo milagre acontece. No dia primeiro de setembro, de repente concluímos o design. E porque? Sim, porque. O primeiro de setembro. De acordo com o cronograma de trabalho, já deveríamos ter terminado. Não há necessidade de hesitar.

Então mais uma festa. Balões e discursos. E avançamos para a próxima etapa - a implementação.

Seria ótimo iniciar esse esquema mais uma vez. Ah, se da mesma maneira seria possível concluir a fase de implementação! Mas não vai funcionar dessa maneira. Porque após a conclusão da implementação, é necessário concluir o projeto inteiro. A análise e o design não produzem frutos na forma binária. Eles não têm critérios inequívocos para completude.

Não há uma maneira objetiva de saber se eles são mantidos na realidade. Portanto, acabou por concluir essas etapas no prazo.

Fase de implementação

Mas a implementação apenas possui critérios distintos de integridade. Aqui não é mais possível brincar com precisão, dando o resultado imaginário como válido.
No estágio de implementação, a ambiguidade das tarefas está completamente ausente. Nós apenas escrevemos o código. E temos que escrever o código às pressas, destacando nossa língua, porque quatro meses foram simplesmente jogados no vento.

Enquanto isso, os requisitos do projeto continuam a mudar. Novos recursos são adicionados. As funções antigas desaparecem ou são ajustadas. Teríamos que voltar, conduzir uma nova análise e fazer alterações no design, mas ... restam apenas duas semanas. E em um ritmo acelerado, introduzimos todas essas alterações no código.

Ao examinarmos o código e compará-lo com o resultado do design, percebemos que devemos estar fora do lugar no estágio de design, porque o próprio código tem pouco em comum com o que foi originalmente representado nos gráficos maravilhosos. Mas não há tempo para pensar, porque o tempo está passando e as horas extras estão se tornando cada vez mais.

Por volta de 15 de outubro, alguém diz: "Ei, qual é a data hoje?" Quando levar? E aqui entendemos que faltam apenas duas semanas e até o dia primeiro de novembro nunca terminaremos. E de repente, pela primeira vez, nossos clientes descobrem que existem alguns problemas com o projeto.

Imagine a indignação deles. “E na fase de análise era impossível dizer sobre isso? Não foi então que você deveria ter estimado o tamanho do projeto e calculado cuidadosamente o cronograma de trabalho? E por que eles não disseram na fase de design? Não foi necessário dividir o projeto em módulos, distribuir o trabalho por toda a equipe e calcular os recursos humanos? Por que descobrimos tudo duas semanas antes do prazo final? ”

E eles estão certos, não estão?

Maratona de sobrevivência

E a maratona de sobrevivência começa. Os clientes estão com raiva. As partes interessadas chegaram ao extremo. A pressão está aumentando. Trabalhamos horas extras. Alguém sai do projeto. Apenas inferno!

E já em março, sofremos ao meio, com um resultado que apenas metade atende aos requisitos dos clientes. Todo mundo está chateado. Todo mundo desiste. E juramos a nós mesmos que da próxima vez isso não acontecerá. Da próxima vez, faremos tudo com sabedoria. Na próxima vez que a análise e o design forem realizados de boa fé.

Eu chamo de processo de inchaço fora de controle. Vamos trabalhar ainda melhor da próxima vez usando um método que não funciona.

»Você pode fazer uma pré-encomenda no site do editor.

Após o pagamento da versão impressa do livro, o pdf é enviado para o e-mailcom as primeiras 105 páginas do livro.