Coleta de requisitos para um projeto de software - sem cortes

Desenvolvimento ... é como uma droga - eles escrevem um sistema, escrevem porque está correndo. E então, de repente acontece - "pensão alimentícia" precisa ser paga. E qualquer alteração no sistema leva a uma montanha de erros. Mas mesmo no início do século passado, o grande Kurt Godel previu isso e provou estritamente que, mesmo na aritmética, não temos inteligência para expressar todas as suas leis sem contradições. E na programação e mais ainda - vamos começar a nos levantar e ficar confusos. O que, em geral, é o que acontece: ou o laptop liga e reinicia à noite, e os aplicativos móveis cometem erros para que eles comecem a cair do bolso e se espalhar, repreendendo e chiando no chão.

E como você gosta das versões beta da moda de tudo e de tudo agora? Em breve os aviões começarão a aparecer nas versões alfa-beta, ao que parece.

Mas você pode programar sem erros para que a alma se regozije e não seja apenas agradável beber cerveja com o cliente, mas também seja seguro!


Nesta série de publicações sobre vários aspectos do desenvolvimento de software, tentarei criar um conjunto minimalista de valores e regras que, em primeiro lugar, são colocados na cabeça das pessoas comuns e, em segundo lugar, eles geralmente permitem ... vencer com o menor custo e tempo. Hoje, vamos falar francamente sobre a coleta de requisitos para um sistema de software.

Teatro, teatro em todos os lugares. Mas a indústria de desenvolvimento de software, sem dúvida, se beneficiará se todos os participantes do processo falarem a verdade primeiro, para si mesmos e, segundo, ninguém apoiará emoções e ministérios não sistemáticos em Cthulhu.

Você não precisa ir muito longe para obter exemplos - modelos abertos de desenvolvimento e seu sucesso (não necessariamente sem fins lucrativos) mostram de forma convincente:

• clareza, abertura, coragem
• discussão com a comunidade e o cliente
• identificação e resolução rápidas de problemas

bem como as comunicações mais justas baseadas na confiança e no respeito mútuo - levam uma solução de software, por exemplo, um site, ao sucesso.

O mundo está mudando ativamente. As comunicações horizontais ocorrem à velocidade da luz e, se não aprendermos a usar essa nova arma, definitivamente perderemos. Mas primeiro, dê uma olhada ao redor.

De onde vieram as "guerras sagradas" na programação?

Tudo é simples. Basta recordar o curso escolar de geometria. A compreensão científica do mundo em que vivemos é baseada em ... fé em "verdades imutáveis" = axiomas, por exemplo, que "linhas paralelas não se cruzam" ou no número de números primos em um intervalo (embora seja um teorema, mas o cachorro trabalha, mas ninguém entende o porquê).

É impossível provar o axioma, resta apenas acreditar que sempre funciona. Mas não podemos voar para o horizonte de eventos do Buraco Negro e verificar. E explique por que a interação entre os fótons também é transmitida muito mais rapidamente que a velocidade da luz.

Numerosas teorias científicas usam axiomas para a conclusão lógica dos teoremas, e assim por diante e nascem livros espessos com um certo período de garantia. Como resultado, e isso não é mais engraçado, o Grande Teorema de Fermat foi provado nos anos noventa de tal maneira que apenas um punhado daqueles com um excelente nível de educação especial pode entender a prova, capaz de escavar dezenas de páginas de um texto fino com fórmulas sob um microscópio :-) É por isso que continuam procure por evidências "reais", simples e bonitas.

Mesmo aparentemente o que poderia ser mais simples, aritmético, foram feitas repetidas tentativas para colocar os axiomas em ordem - mas as coisas ainda estão lá ...



Da mesma forma, as linguagens de programação e as tecnologias nas quais criamos sites, aplicativos móveis e sistemas de informação também representam um conjunto de axiomas ou pontos de referência, nos quais você também precisa “acreditar” e sobre o qual a base da tecnologia é construída, mas é impossível provar que elas são verdadeiras (embora às vezes ainda seja possível: tente escrever um site em C ++ e veja quanto tempo e dinheiro você perde).

Por exemplo, no mundo do Java / C # e em outras linguagens autoritativas e respeitáveis, modernas e fortemente tipadas com tipagem estática, você só precisa entender e "acreditar" que o mundo consiste em psicopatas, propensos a violência e perda de auto-identificação e, portanto, um "conjunto de axiomas" faz de tudo para proteger o desenvolvedor não apenas dos colegas, mas também de si mesmo (claro, estou brincando).

O resultado são sistemas de software criados por muito tempo, a partir de ferro e concreto, que são cobertos com centenas de autotestes e, como resultado, no momento em que a construção é concluída, os requisitos de negócios estão desatualizados há muito tempo, as armas nucleares são proibidas e um bunker com paredes de 100 metros vai desaparecer. imediatamente para o museu. Mas muitas vezes essa percepção do mundo - funciona bem, por exemplo, no desenvolvimento de sistemas estritamente especializados ou onde o custo do erro é muito alto (bancos, etc.).



No mundo das linguagens dinâmicas com digitação estrita / não estrita (PHP, JavaScript, Python, Ruby), o conjunto de axiomas é perfeito, da palavra “completamente”, outro:

• estamos cercados por pessoas inteligentes que escrevem certo e limpo imediatamente
• mania de perseguição (alterar o tipo de uma variável abaixo da lista, acesso a membros da classe oculta por outro desenvolvedor com uma intenção "maliciosa", é necessária uma refatoração profunda de código adiante, etc.) - uma doença que você precisa recuperar rapidamente
• o hardware está ficando mais barato, então você precisa compilar o programa apenas em partes e, se necessário,
• quanto mais código, mais erros, então o código deve ser lido imediatamente bem, ser claro, conciso e sexy

No mundo das linguagens funcionais, como Haskell / OCaml, você precisa acreditar que:

• qualquer tarefa pode ser expressa por função
• variáveis, ciclos e mutabilidade - leva a erros (na verdade é isso)
• programação - para os selecionados e inclinados ao pensamento analítico

Como resultado, em vez de simples scripts de muleta “feitos, verificados, decididos e esquecidos”, o verdadeiro trabalho científico começa no local de trabalho e a busca pela “função de Deus” é muito interessante para expressar o site ... com um conjunto de funções sem variáveis, uau!

Claro que exagerei, mas não há fumaça sem fogo. Embora em algumas tarefas essa abordagem funcione bem e ninguém tenha apresentado uma abordagem melhor.

“Cruzadas” no gerenciamento de projetos de software

No campo do gerenciamento de projetos, a situação é ainda mais coberta pela melancolia pseudo-científica. E a razão é bem conhecida: uma solução óbvia, deitada na superfície, simples e concisa para a testa:

• entender o que o cliente quer
• atrair especialistas e avaliar a quantidade de trabalho
• escrever código

na realidade, por algum motivo, ele não funciona :-)

Os participantes experientes das equipes do projeto estão bem cientes de que o cliente, muitas vezes brega, não sabe o que quer, porque está sobrecarregado de emoções e copia problemas de matemática na escola, o que acaba levando a uma "atrofia parcial da parte do cérebro" responsável pela expressão lógica consistente de sua pensamentos. Tendo opuses poéticos, desenhos de batom e notas de acordes de guitarra, em vez dos requisitos técnicos do site, especialistas, chorando para não rir da impotência, aumentam as estimativas da quantidade de trabalho em uma ordem de magnitude, introduzem um imposto por inadequação e assim por diante.

Sob essas condições de falta de lógica e desejo estritos, perdoe-me, usando minha cabeça para a finalidade a que se destina, como se aos trancos e barrancos, houvesse terríveis abusos não científicos no estilo de astrologia / numerologia / pranyozhenie e adivinhação em borra de café.

Os abusos geralmente são ativamente explorados por pessoas muito confiantes, capazes de convencer bem, que nunca mantiveram o "código" (sim, estou falando do Agile errado).

Eles dizem que em algumas equipes antes do sprint, mesmo os fãs mais fervorosos nos obrigam a engenheiros, desculpe-me, terapia com urina :-) No entanto, essas "práticas" são muitas vezes criadas por desenvolvedores muito experientes que, como nenhum outro, podem usá-las corretamente.

Aqui, eu realmente gosto da analogia com os nunchakus - parece uma arma simples, mas apenas alguns podem usá-la corretamente e a maioria se machuca, desculpe, você sabe o que é.

Outro mito é a permutabilidade

Às vezes, eles tentam nos convencer da intercambiabilidade dos engenheiros . É sabido que, para obter uma compreensão boa e profunda da tecnologia de software, você precisa ler muitos livros, ouvir uma dúzia de cursos , resolver várias centenas de problemas e participar de cinco projetos de software, dos quais pelo menos um chegou à linha de chegada. Em seguida - começa o experimento, que após 5 anos, pelo menos, faz do codificador - Especialista.

Normalmente, trabalhando constantemente em projetos, o desenvolvedor é fluente em uma ou duas linguagens de programação e tecnologias relacionadas. O sucesso e crescimento profissional de um engenheiro reside justamente em sua estreita especialização, porque além das próprias linguagens, é necessário aprofundar-se nas bibliotecas do sistema, que geralmente são muito numerosas e a documentação para elas é muito extensa.

O problema é que agora, por algum motivo, está na moda não ler livros - mas pesquisá-los no Google e escrevê-los, sem incluir o cérebro, enquanto se masturba mentalmente nas redes sociais e nas notificações de smartphones.

Encontrar um especialista de verdade que aprenda sistematicamente de baixo para cima, lenta mas seguramente, fechando as lacunas de seu próprio conhecimento - está se tornando cada vez mais difícil. Infelizmente, o mercado está cheio de "autodidatas" com ... "mãos mimadas".

O que fazer? Valores de sobrevivência recomendados

Em primeiro lugar, não há necessidade de se desesperar e é muito importante não se entregar às emoções. É necessário entender claramente que o desenvolvimento é, antes de tudo, matemática rigorosa (geralmente no nível da escola) e lógica com métricas, nas quais, usando terver e intuição, é necessário lidar com riscos prioritários e chefes "molhados" na infância.

Nós costumávamos jogar jogos online antes e funcionou bem - então vá em frente, apenas em vez de chefes você terá projetos de software e em vez de bugs - zerg!

Sempre é possível e necessário gerenciar sobriamente os riscos e, a partir da experiência, se feito "sistemática e cientificamente", um projeto de software decola a tempo ou fica claro rapidamente por que o míssil não inicia e qual / quem, especificamente, o problema.

Em vista do exposto, é recomendável que você comece a aderir aos seguintes valores da abordagem empírico-científico-empírica, que se cruzam estreitamente com o hino bem conhecido ao senso comum - " python zen " e " ágil manifesto ":

1. Procure a solução mais simples e clara
2. Quanto mais claro, mais correto
3. Tornou-se difícil - significa um batente em algum lugar e você precisa continuar pesquisando
4. Arrogância - de insegurança ou infância difícil
5. As habilidades do cérebro humano são limitadas, especialmente sob a influência de hormônios, e em alguns períodos até demais
6. Do álcool e do fumo - estamos entorpecendo intensamente
7. Tendemos a esquecer rapidamente até o que sabíamos bem e ainda mais recentemente
8. Busque a máxima transparência e abertura
9. Respeitar um ao outro
10. Incentive a subida mais rápida possível e a discussão de problemas no círculo mais amplo possível - ideal imediatamente em todos
11. Tire conclusões e não pise no rake 3,14 vezes seguidas :-)

Coleta de Requisitos

Tendo aprendido alguns segredos e características das tendências no desenvolvimento de software, seguiremos em frente com confiança - aprenderemos como montar corretamente os requisitos do sistema.

O cliente é capaz de pensar em princípio?

Nada engraçado - ainda é uma situação regular. E o cliente neste contexto é um conceito coletivo. Primeiro, tente avaliar o nível de pensamento lógico e a capacidade de concentrar os representantes dos clientes. Com quem você vai trabalhar e quem o ajudará? Possíveis opções:

1. Partido político. É necessário fazer, por exemplo, um projeto da web até a data, porque alguém quer / prometeu algo ... Os requisitos são vagos, ninguém sabe os detalhes e quem sabia - vai parar há muito tempo. O projeto foi serrado por uma equipe que saiu e era quase impossível entender o que eles viram. Nas paredes - cérebros secos de, possivelmente, o suicídio de um programador líder. O código é ruim e frágil, cheira a ponto de machucar seus olhos. Muitas vezes, em tal situação, eles tentam encontrar, com licença, o "sacrifício sagrado", que pode ser responsabilizado pelos próximos seis meses e ... começam a procurar um novo. Sentimento de medo, depressão e supressão da abertura do processo com uma mistura de sangue nos lábios. A probabilidade de criar uma solução de software dentro do prazo, embora pequena, ainda existe - se você fizer novamente em uma estrutura pronta com documentação pronta. Geralmente o único caminho e nenhum outro caminho.
2. Você se comunica com os representantes dos clientes e entende que é sinceramente difícil para as pessoas expressar seus próprios pensamentos de maneira consistente / formal, que são confundidos após a terceira frase, são repetidos e circulam em círculos. Após 15 minutos de diálogo, começam as queixas de dor de cabeça. Risos são ouvidos, a atmosfera da festa, a selfie, a vida foi bem-sucedida ... Mas os desejos, em geral, são compreensíveis e sinceros - você só precisa ajudá-los um pouco a formalizar estritamente. A probabilidade de decolar aqui é geralmente maior do que no parágrafo 1, mas, novamente, o uso da solução em caixa mais pronta com documentação pronta e cenários típicos geralmente ajuda.
3. O cliente entende bem o que quer e tenta expressar lógica e consistentemente seus próprios pensamentos e desejos. Nisto, ele é ajudado por um analista que não está confuso, expondo os pensamentos da gerência e passando-os como seus. A equipe do cliente também possui pelo menos um especialista em sua área de assunto (engraçado, mas ainda é uma situação bastante rara). Nesse caso, a probabilidade de ajudar e resolver o problema programaticamente é muito alta. Aqui você pode se envolver no projeto, na discussão conjunta do glossário, modelos de objetos, modelos de dados, fluxos de dados, cenários de teste de carga. Provavelmente, você pode coletar os requisitos em um tempo razoável.

Outro ponto importante aqui é construir relacionamentos tão confiáveis ​​quanto possível, mostrar sua abertura e desejo de ajudar o cliente a expressar claramente seus pensamentos. Muitas vezes, ajuda a algum tipo de treinamento, no qual os representantes dos clientes são explicados como trabalhar com as seguintes ferramentas de coleta de requisitos:

• Glossário Geral
• Um modelo de dados lógicos no qual são introduzidas relações estritas de multiplicidade entre elementos do glossário (um para um, um para muitos, muitos para muitos)
• Funções e cadeias de uso que mostram quem usa o sistema e como

Alarmes que indicarão problemas iminentes na coleta de requisitos:

• os representantes dos clientes traduzem as "flechas" entre si e não conseguem conectar as duas palavras, há muitas emoções - é recomendável escalar o problema o mais rápido possível e subir para um nível mais alto - caso contrário, você, como um "sacrifício sagrado", será apresentado como um presente para o culto à bagunça e aposentadoria / licença de maternidade. Trabalhar em tais condições no Agile é extremamente perigoso, é melhor escrever requisitos técnicos rigorosos e avançar em pequenas etapas
• os representantes dos clientes respondem no estilo de: ah, sua cabeça dói, mas você é esperto, um “programador”, então faça o que é certo. Aqui, você precisa procurar um especialista na área de assunto, responsável pelas respostas em nome do cliente e o mais rápido possível. Ou veja o parágrafo acima.
• eles preferem não falar sobre problemas (código ilegível, falta de documentação para os principais processos de negócios), porque dinheiro foi gasto, posições recebidas, bônus expressos e declarações de riscos podem levar a uma limpeza intensiva da equipe (no entanto, todos "entendem" e aqui os engenheiros rolam o barril) - é difícil dar conselhos aqui, agir de acordo com o clima

Nos casos clínicos acima, novamente, o desenvolvimento de uma solução de caixa / nuvem pronta com documentação pronta ajuda muito. Essa abordagem reduzirá os riscos de mudanças repentinas no curso em 180 graus por ordens de magnitude. Mas as garantias já são menores.

No caso de uma abordagem adequada por parte do cliente, um desejo de aprender e entender você, um desejo sincero de lançar um projeto no prazo e desenvolver ainda mais, o uso simultâneo de várias plataformas de tecnologia ajuda muito. O design não é mais assustador - você sente que o cliente compartilha a responsabilidade de coletar requisitos 100% com você e pode tentar fazê-lo bem. Você - segura um ao outro e juntos lutam com a complexidade:

• Site PHP com estrutura, solução in a box
• análise preditiva em Python
• um aplicativo móvel em uma única plataforma que funciona em qualquer lugar ou escrevemos para cada dispositivo

Não perca tempo!

Se durante 2-3 semanas, em casos extremos, um mês e meio, não passar a sensação de que você está participando da peça “converse com uma aparência inteligente e leve tempo e coloque tudo em alguém”, puxe o guindaste, ative o trem e grite alto para gritar: "vão para casa, filhos! desempenho acabou. "

Sério, marque uma consulta com a gerência do cliente e insista em incluir na equipe do projeto funcionários adequados que entendam em detalhes como o negócio funciona e que sejam capazes de responder a perguntas estritas dos engenheiros. Ou saia - às vezes, esse é o passo certo: salve o rosto e cresça como especialista.

Lista de verificação

Como resultado, podemos considerar o processo de coleta de requisitos bem-sucedido e faz sentido seguir em frente se, juntamente com o cliente, você puder preparar os seguintes artefatos dentro de algumas semanas:

1. Glossário listando 50-150 termos de domínio
2. Modelo de dados lógicos com relacionamentos de termos do glossário
3. Casos de uso com termos do glossário
4. Para algoritmos complexos - fluxogramas ou diagramas de atividades da UML
5. Interfaces de sistema de software que não contradizem logicamente os itens acima
6. Você decidiu um conjunto de axiomas que descrevem sua atitude em relação ao mundo = escolheu a tecnologia de software. Aqui, muitos, por causa do amor à criatividade, são atraídos pelo sadomasoquismo e pelo desejo de reinventar a roda - lute contra esse desejo. Decida: ou o mundo inteiro está cheio de truques sujos e psicopatas e cria um abrigo que pode suportar um ataque de OVNI, ou os desenvolvedores querem sinceramente ajudá-lo. A melhor tecnologia e um conjunto de axiomas: uma estrutura desenvolvida ou uma solução de caixa pronta - os riscos de não decolar diminuirão em ordens de magnitude (na experiência, 95% e acima dos projetos)
7. Você perdeu o sistema de software através do cliente, você mesmo, através do seu cérebro, e em nenhum lugar há pontos lamacentos ou lama emocional. Se houver lugares potencialmente estragados (e isso geralmente acontece sempre) - inclua-os no plano de gerenciamento de riscos e expresse-os em cada reunião do projeto. E espere que você seja enquadrado e não se esqueça de perguntar como você perdeu

Se os artefatos acima mencionados no período especificado não puderam ser coletados, e existem apenas documentos que cobrem o quinto ponto, como o “batom” da TK, os analistas não vão cooperar entre si, não são esperados especialistas na área do assunto do lado do cliente, os problemas são abafados e a atmosfera de limpeza das janelas reina e "Apenas boas notícias" - arrume suas coisas: muito provavelmente elas não o deixarão voar, a exploração da lua será adiada por um período indeterminado de tempo e você estará em uma performance teatral "demoraremos mais um pouco não será disperso. "

Para alcançar um sucesso real, é muito, muito importante amar verdadeiramente os sistemas de software, render-se ao máximo de coletar requisitos e projetar, desejar o início dos foguetes, beber cerveja com um cliente, confiar um no outro e repetir constantemente para si mesmos as palavras de Edsger Dijkstra : “simplicidade é a chave confiabilidade "!

Com a chegada de todos e sinceramente desejo a você boa sorte na implementação de projetos de software.