JIRA: regras para a preparação oportuna de softwares deliciosos. TLDR 2: gerenciamento de requisitos
No início do artigo “ JIRA: as regras para a preparação oportuna de deliciosos softwares. TLDR 1: limites de possibilidades ”foi feita uma tentativa de unificar os requisitos gerais para o uso do JIRA no caso do gerenciamento de vários projetos para o desenvolvimento de software personalizado em um dos departamentos da nossa empresa . Desenvolvendo o tópico, este artigo será dedicado aos principais recursos de registro, esclarecimento e monitoramento da implementação dos requisitos do cliente no âmbito do modelo proposto anteriormente . Qualquer crítica é bem vinda.FonteQualquer produto acabado é determinado principalmente pela qualidade dos ingredientes originais, e o software não é exceção ( Garbage In - Garbage Out ). Se os ingredientes originais estiverem um pouco podres ou alguns deles simplesmente estiverem faltando, é improvável que você possa salvar a situação com a ajuda de um super-forno ou de uma panela maravilhosa. No caso do software, os componentes iniciais são as boas intenções (sonhos) do cliente em relação a um futuro brilhante (quando "os robôs estão trabalhando duro, a pessoa está feliz "). Um dos paradoxos dos contratos governamentais modernos é que o contratante geralmente tem uma influência fraca no processo de formação de requisitos, ou seja, processo de análise de requisitos reaisno projeto começa após a aprovação da lista desses requisitos. O fato de as recomendações da equipe do projeto em relação à redação dos requisitos não terem afetado o texto do contrato, o gerente do projeto normalmente descobre por um representante animado do departamento de contratos, que, com um senso de dívida completa, informa que a tão esperada proposta finalmente foi vencida e o acordo Continua pequeno. Ao mesmo tempo, por um lado, o cliente de todas as maneiras possíveis impede a alteração de requisitos no documento aprovado (um sonho é sagrado) e, por outro, ele pode facilmente interpretar de maneira diferente o mesmo requisito, dependendo da situação.Sob essas condições, é desejável garantir que todos os requisitos do cliente sejam armazenados em sua “cozinha digital” de forma que, no estágio de entrega do projeto, evite sérias frustrações de todas as partes interessadas no projeto.Para resolver esse problema, dentro da estrutura da abordagem proposta anteriormente , um tipo especial de tarefa é projetado - o “requisito”. Uma lista desses requisitos de tarefa é formada pelo chamado backlog do projeto. Nas versões mais recentes do JIRA, um análogo desse tipo de tarefa é o tipo de tarefa "épico". No entanto, como será visto mais adiante, o tipo de tarefa “requisito” em nosso projeto não está apenas consertando as formas conceituais de pensamento do cliente, mas tarefas caracterizando os resultados das atividades do gerente de projeto e analistas no gerenciamento de requisitos . Regras para requisitos de fatiagem
Se o cliente receber uma lista de requisitos para refinamento de software (por exemplo, termos de referência aprovados), todas as atividades de registro e manutenção da lista de requisitos no JIRA poderão ser reduzidas a dois cenários de fronteira.No primeiro caso, o gerente de projeto simplesmente encaminha a carta com os requisitos do cliente para os analistas com uma nota "Registre os requisitos relacionados à tangente no JIRA e garanta sua implementação". Depois disso, o gerente do projeto pode “martelar” o projeto até o início dos testes preliminares (a única coisa é garantir que todos os requisitos encontrem seus executores responsáveis no JIRA). Se sua equipe de projeto for composta por analistas sãos, programadores engenhosos, testadores de viciados em trabalho e escritores técnicos grafo-maníacos, o resultado dessa abordagem não será diferente da segunda opção mais problemática.No segundo caso, o trabalho de gerenciamento de requisitos é dividido em várias etapas.Início da fonte . Registro do documento de origem para desenvolvimento / modificação de software no JIRA. Os materiais recebidos são carregados no repositório com o número da tarefa correspondente indicada no comentário do commit.1. Com base no documento fonte registrado, está planejada uma reunião, cujo objetivo é determinar os limites de responsabilidade pelo cumprimento dos requisitos, identificando “pontos brancos” e requisitos “esotéricos”. O planejamento da reunião é realizado diretamente no JIRA (para isso, é registrada uma tarefa do tipo "implementação", a pessoa responsável pela tarefa é o gerente do projeto, os participantes são registrados como observadores, os itens da agenda são registrados na descrição). O tempo gasto em uma análise preliminar de requisitos é fixado de forma independente pelos analistas na forma de subtarefas para a reunião planejada. Se surgirem perguntas durante a análise, elas serão refletidas nos comentários na agenda da reunião.Durante a reunião, são tomadas decisões sobre a nomeação dos responsáveis pelas “manchas brancas”. Os riscos com relação aos requisitos "esotéricos" são avaliados e as formas de superá-los são propostas. A primeira versão, ainda que muito aproximada, do “roteiro” está sendo formada, segundo a qual o trabalho será organizado (levando em consideração as prioridades e o emprego atual da equipe do projeto).2. Depois que o analista é designado responsável pela implementação dos requisitos, ele registra cada requisito no JIRA como uma tarefa separada relacionada ao documento de origem (o link “complementa”). O status inicial da reivindicação é "classificação" .Uma das regras básicas - cada requisito do cliente deve ser registrado como uma tarefa separadano JIRA. Essa abordagem, por sua vez, possibilita avaliar o status do projeto do ponto de vista da implementação de cada um dos requisitos do cliente, e não do ponto de vista do número de tarefas executadas ou do investimento de mão de obra. A redação do requisito é registrada no campo "Descrição", palavra por palavra, como no documento do cliente.Além disso, o registro "atômico" de requisitos subsequentemente possibilita a geração automática de documentação de relatórios quando uma liberação ou atualização é emitida (protocolo de composição e teste funcional). 3. Dado o roteiro desenvolvido para cada um dos requisitos no estágio inicial de sua implementação, os seguintes problemas devem ser resolvidos pelo analista responsável:- esclarecimento do conteúdo semântico do requisito;
- clarificação dos limites da implementação.
No momento do esclarecimento, o requisito pode ser transferido para o status de "pendente" , indicando o motivo correspondente.Todos os materiais para esclarecimento (interpretação) dos requisitos são anexados à tarefa correspondente (carregada no repositório de documentação). Os materiais resultantes devem vir do cliente e devem permitir uma resposta clara às perguntas acima. É aconselhável que este seja um protocolo da reunião para esclarecer os requisitos, pelo menos um e-mail da correspondência.Após a eliminação de “manchas brancas”, o requisito pode ser transferido para o status de “atribuído” .4. No âmbito da implementação de uma área funcional (um caso de uso principal - caso de uso) o analista responsável deve formular tarefas do tipo "análise" relacionadas aos requisitos relevantes. 5. Se necessário, o analista responsável realiza uma pesquisa de informações do objeto de automação. 6. Após coletar os dados iniciais necessários para o design, o analista responsável forma a decisão do design. 7. Com base nos resultados da decisão de design, o analista deve formar / esclarecer a lista de componentes que estão sujeitos a desenvolvimento / modificação.8. A solução de design desenvolvida é uma condição necessária e suficiente para criar tarefas para o desenvolvimento, teste e documentação e prever a complexidade de sua implementação.Geralmente, é aí que está localizado o principal obstáculo entre gerentes e desenvolvedores. Um deAs abordagens usadas para reduzir a incerteza na solução desse problema são avaliar a tarefa proposta pelo desenvolvedor responsável, desde que a complexidade total da tarefa individual não deva exceder 16 horas. Alexei Kataev, em seu relatório, mostra de maneira convincente que se os custos de mão-de-obra para a implementação da tarefa excederem 12 horas, a confiabilidade da previsão da complexidade de uma tarefa dessas se tornará semelhante à confiabilidade da previsão dos ganhos em jogos de azar. Portanto, para garantir a qualidade necessária do planejamento, recomenda-se decompor as tarefas. Por outro lado, do ponto de vista da gerência, eu gostaria de obter um resultado significativo do ponto de vista do cliente durante a execução da tarefa de desenvolvimento, que nem sempre é possível em 16 horas de trabalho. No nosso caso, foi decidido que, se a complexidade da tarefa exceder 8 horas, o autor da tarefa deve dividi-la em estágios separados (o que nem sempre significa subtarefas). Além disso, listas formais de resultados específicos para cada um desses estágios foram determinadas. Além disso, calculadoras on-line foram criadas para aumentar a objetividade das previsões com base nessas listas, usando o método PERT .determinação da complexidade total para tarefas de diferentes tipos (uma descrição mais detalhada do trabalho com essas ferramentas deve ser fornecida durante a publicação dos seguintes artigos). Mas, ao mesmo tempo, foi estabelecida uma limitação de que a complexidade máxima projetada de uma única tarefa do JIRA não deve exceder 32 horas. No caso de o contratante não concordar com a complexidade projetada de sua tarefa, como argumento, ele deve enviar seu cálculo da complexidade, realizado usando as mesmas ferramentas. O árbitro na resolução de tais disputas entre o analista responsável pela implementação do requisito e os executores é o gerente do projeto (líder da equipe).9. Imediatamente após o registro das tarefas relacionadas ao requisito de desenvolvimento, teste e documentação, o gerente do projeto deve especificar a prioridade e o prazo para a implementação desse requisito (levando em consideração os custos totais de mão-de-obra das tarefas relacionadas, as prioridades e os prazos necessários para a implementação de outras tarefas do projeto). Dado esses esclarecimentos, por sua vez, o analista responsável pode ajustar o tempo das tarefas para desenvolvimento, teste e documentação.10. A implementação da solução de design é realizada dentro da estrutura de tarefas do tipo "desenvolvimento".Depois que a primeira tarefa relacionada ao requisito para desenvolvimento de software é colocada em funcionamento, o requisito deve ser transferido para o status "em trabalho" (isso pode ser feito usando o plug-in Automation for Jira ).11. Com base nos prazos de implementação especificados, é tomada uma decisão para incluir a implementação do requisito em uma ou outra versão do software. O cliente deve ser informado sobre quaisquer alterações na composição ou no prazo de entrega do release.12. Paralelamente ao processo de desenvolvimento, uma versão da documentação do usuário é formada com base na decisão de design.13. Após concluir as tarefas de desenvolvimento, o programador deve esclarecer a lista de componentes que foram desenvolvidos / modificados.14. A clarificação da documentação do usuário deve ser realizada como parte de um teste offline. O cumprimento de todos os requisitos relacionados ao requisito de desenvolvimento, documentação e teste é um sinal para traduzir esse requisito no status de "concluído" e sua inclusão no release.15. A revisão está incluída na versão do software de acordo com a decisão de entrega tomada pelo gerente do projeto.16. Antes da execução dos testes, é realizado um teste repetido de integração dos requisitos implementados incluídos no release.17. A confirmação da exatidão dos requisitos implementados pode ser realizada durante o teste do software (preliminar, operação de teste, aceitação). Os resultados do teste são registrados no JIRA como parte das tarefas do tipo "implementação".Depois que um documento é recebido do cliente sobre a implementação correta do requisito, ele pode ser transferido para o status “fechado” . Caso sejam recebidos comentários do cliente sobre o requisito, ele retornará ao status "atribuído"(no estágio número 8). Ao mesmo tempo, os próprios comentários podem ser corrigidos no JIRA como requisitos separados relacionados ao requisito principal, usando o tipo de comunicação "Relaciona" .Deixe-me lembrá-lo de que o esquema descrito não reflete o fluxo de trabalho de uma tarefa separada no JIRA, mas envolve a criação de um conjunto de tarefas inter-relacionadas de vários tipos (o que é refletido no esquema com as cores correspondentes). A sequência fornecida fornece uma visão geral do procedimento padrão para implementar novos requisitos do cliente. Ao mesmo tempo, esse esquema não exclui a possibilidade de desvios dele, por exemplo, no caso de prototipagem preliminar antes da decisão do projeto. No entanto, em nosso projeto, essas exceções devem ser acordadas com o gerente do projeto.Durante o teste ou operação comercial, os comentários dos clientes sobre o software criado serão inevitavelmente revelados. Essas observações podem ser divididas condicionalmente nos seguintes grupos:- novos requisitos;
- esclarecimentos sobre implementação;
- defeitos;
- erros.
Apesar do fato de que, de acordo com a abordagem proposta inicialmente , os comentários são registrados no JIRA, bem como os requisitos para aprimoramento de software (como tarefas do tipo "requisito"), o processo de sua eliminação merece uma consideração separada. Regras para colorir baratas
Quem não faz nada não está enganado.
Theodore Roosevelt
Não há software sem erros. Absolutamente. Mesmo se não houver erros no código, um usuário sofisticado os encontrará na documentação ou apenas os apresentará. De uma forma ou de outra, não vi projetos em que não houvesse incidentes de software. Análise de Manutenção de Software pelo Instituto Americano de Engenharia de Software ( SEI)), no início dos anos 90, mostrou que o coeficiente de correlação entre o número de erros detectados durante o teste de módulos individuais e o número de erros encontrados pelos usuários no produto final é de 0,91. Simplificando, se 10 erros foram detectados no estágio de teste, outros 9 aparecerão durante a operação de teste. A obtenção da qualidade exigida no desenvolvimento de software para estações espaciais é alcançada, em particular, devido à superioridade dez vezes maior da equipe de teste em relação à equipe de desenvolvimento, não incluindo o uso de técnicas avançadas, por exemplo, teste de unidade ou automação de teste de GUI. Na minha opinião, a confiabilidade desse software é alcançada devido ao mínimo envolvimento possível de usuários ativos em seu trabalho. Obviamente, é muito legal quando uma equipe profissional de controle de qualidade trabalha no projeto . No entanto, em muitos projetos de software, não é possível implementar todas essas recomendações por várias razões objetivas e subjetivas.Portanto, se o gerente de projeto não gerenciar o fluxo de incidentes recebidos, muito em breve esse encadeamento gerenciará esse gerente (se ele não "engasgar" nesse encadeamento). Por outro lado, como mostra a experiência, uma parte significativa dos comentários do cliente que foram inicialmente classificados por ele como erro de software não é um erro. A aparência de comentários desse tipo pode ser devido a razões como:- violação das condições técnicas de operação do software ("mãos tortas" dos administradores de sistema do cliente);
- restrições aos direitos de acesso do usuário (os direitos de acesso do usuário atribuídos não atendem às expectativas dele);
- a incompatibilidade das expectativas funcionais do usuário com os requisitos implementados (se nada ajudar, talvez você deva ler as instruções?);
- inconsistência na descrição da implementação do software (uma observação bastante rara, já que os usuários e administradores do cliente, em regra, não leem os manuais após o primeiro conhecimento do software).
Nesse sentido, durante a correspondência com o cliente em relação aos comentários sobre o software, é recomendável evitar palavras como “erro” ou “defeito”, pelo menos até que seja completamente inequivocamente estabelecido. Até este ponto, é recomendável usar as palavras "observação" ou "incidente".O processo unificado de execução de trabalho para eliminar incidentes pode ser representado como uma sequência das etapas a seguir.Início da fonte . Registre um aplicativo de resolução de incidentes no JIRA. Este estágio para diferentes projetos pode ser organizado à sua maneira. Você pode, por exemplo, registrar aplicativos recebidos do cliente manualmente no JIRA, ou pode usar uma caixa de correio especial, que o JIRA exibirá e configurará independentemente , com base nas cartas recebidas. Se você estiver desenvolvendo um aplicativo da web, poderá usar o coletor de tarefas JIRA para coletar comentários do usuário . No campo de como o comentário acabou sendo registrado no JIRA (no status de "rating" ), é necessário pré-processá-lo.1. Esclarecimento das condições do incidente. Como parte desta ação, é necessário coletar as informações mais completas sobre o comentário do software:- a sequência de ações durante as quais o incidente ocorre, uma combinação de dados de entrada;
- detalhes e autoridade do usuário do comentário;
- localização da estação de trabalho (servidor);
- capturas de tela de telas de usuário;
- protocolos de monitoramento;
- amostras de arquivos gerados incorretamente (relatórios).
Muitas vezes, uma parte significativa dos incidentes termina sua jornada de vida nesse estágio, pois durante a coleta de artefatos, verifica-se que o “erro” detectado é o comportamento padrão do sistema. Se o JIRA começar a acumular requisitos para resolver incidentes que foram resolvidos sem criar tarefas de desenvolvimento, vale a pena prestar muita atenção à facilidade de uso da interface com o usuário e à relevância do manual do usuário.2. Repartição do incidente em requisitos "atômicos". Freqüentemente, em uma carta, o representante do cliente pode refletir vários comentários. Portanto, se necessário, na segunda etapa, com base na carta registrada do cliente para o JIRA, tarefas de requisitos separadas são formadas. Além disso, cada uma dessas tarefas está associada ao requisito pai usando o relacionamento Cloners . Para cada uma dessas tarefas, os materiais coletados no estágio anterior são anexados (em parte). Além disso, todo o trabalho é organizado com cada requisito separadamente.3. Definição da estrutura contratual. Após especificar os defeitos identificados, é determinado o tipo de relacionamento contratual que o trabalho para eliminá-lo pode ser atribuído. Do ponto de vista de outras organizações de trabalho, esse estágio pode mudar fundamentalmente a prioridade de outras tarefas. Em muitos projetos, a operação de teste de novos componentes desenvolvidos como parte do desenvolvimento é realizada instalando esses componentes diretamente na versão atual após um breve teste autônomo. No entanto, o cliente correlaciona os erros que surgem nesses casos já com os contratos de suporte básico ou de garantia, que estipulam prazos estritos para a eliminação dos defeitos. Se, no âmbito do suporte básico, o período contratual para eliminar o defeito puder ser medido em horas, se o defeito for identificado em relação à nova funcionalidade,o período para eliminar o mesmo defeito é determinado até a data final da operação de teste (até vários meses). Se o gerente de projeto não prestar atenção a essa “pequena” nuance, a empresa executora terá todas as chances de começar a pagar uma penalidade por um software simples, mesmo antes de ser colocado em operação comercial.4. Controle de duplicatas. No caso de reinserir o aplicativo para a remoção de defeitos detectados anteriormente, esse requisito está associado à tarefa arquivada anteriormente através da conexão "Duplicar» ( Duplicar ). Com base nos resultados da análise preliminar do incidente, é necessário informar o cliente sobre seus resultados, pois a visão do cliente sobre o momento da eliminação do incidente pode se correlacionar fracamente com as obrigações contratuais.5. O incidente deve ser repetido no servidor de teste pela equipe de suporte antes de enviar a solicitação ao analista da equipe de desenvolvimento. O teste inicial pode ser registrado no JIRA na forma de uma subtarefa para o requisito relevante.6. Se o incidente não tiver sido resolvido no curso das etapas anteriores, o requisito será transferido para o status “atribuído” e transferido para o analista da equipe de desenvolvimento para identificar os motivos de sua ocorrência e formular tarefas para sua eliminação.7. Se necessário, o analista deve esclarecer o escopo contratual do requisito. Se for feito um comentário sobre a nova funcionalidade do software, o analista deverá associar esse defeito aos requisitos relevantes para desenvolvimento / desenvolvimento / suporte estendido (o link "Adicionar").8. A análise também deve determinar a lista de componentes que afetam este comentário. Além disso, se o comentário é realmente um bug de software, ele deve ser gerado.tipificação do defeito detectado.9. Após identificar as causas do defeito, o analista do grupo de desenvolvimento cria tarefas de desenvolvimento destinadas a eliminar o erro identificado. Se necessário, são formadas tarefas para testar e esclarecer a documentação. Como parte dessas tarefas, os custos planejados de mão-de-obra são determinados. Se a carga de trabalho de uma tarefa específica exceder 8 horas, é necessário fornecer uma justificativa da complexidade usando as ferramentas especificadas na seção anterior. Levando em consideração a prioridade e a carga de trabalho da equipe do projeto, são determinadas as datas planejadas para a implementação dessas tarefas. Depois que o primeiro requisito relacionado ao desenvolvimento do software é levado para o trabalho, o incidente deve ser transferido para o status de "em trabalho" .10. O aparecimento de tarefas relacionadas ao desenvolvimento, teste e documentação de um requisito é um sinal para o gerente de projeto tomar uma decisão sobre qual versão do software o defeito identificado será corrigido. Ao mesmo tempo, o gerente de projeto planeja um evento para a implementação do software, vinculando os requisitos correspondentes à tarefa do JIRA do tipo "implementação". 11. Se necessário, o gerente de projeto esclarece as datas planejadas para a implementação de tarefas relacionadas e informa o cliente sobre isso.12. A correção do defeito é realizada no âmbito de tarefas do tipo "desenvolvimento".13. Após a eliminação do defeito, o desenvolvedor, se necessário, deve esclarecer o tipo do defeito detectado e a composição dos componentes que foram finalizados.14. Se necessário, a documentação é especificada.15. Os especialistas do grupo de suporte realizam testes autônomos da funcionalidade corrigida (como parte da tarefa de teste formada pelo analista do grupo de desenvolvimento).Além disso, como no caso da implementação do novo requisito, a base para a transferência do incidente para o status de “concluído” é o cumprimento de todas as tarefas criadas em sua base (com exceção das tarefas do tipo “implementação”).16. Após a realização de testes offline, a correção está incluída na atualização e na versão atual.17. Após a prontidão de todas as melhorias planejadas para inclusão na liberação da entrega, são realizados testes de integração. A realização de testes de integração pode ser corrigida no JIRA na forma de uma subtarefa para a tarefa correspondente do tipo "implementação".18. As atualizações de software são transmitidas ao cliente da maneira estabelecida. No entanto, a transferência de tarefas dos requisitos relevantes para o status de "fechado" é possível somente depois de receber do cliente evidência documental da eliminação do incidente. FonteQualquer desenvolvedor sabe que os maiores erros são aqueles que não foram detectados em tempo hábil no estágio de formação / especificação de requisitos.Regras de congelamento de requisitos
Andar sobre a água e desenvolver software de acordo com a especificação é muito simples quando ambos estão congelados.
Edward V. Berard
Deve-se notar que o esclarecimento dos requisitos se provou de maneira mais eficaz, criando uma situação em que o cliente precisa dar uma resposta simples à carta de esclarecimento: “Eu concordo”. Para isso, é necessário formular várias respostas possíveis na carta . A arte de formar essas letras é que a própria opção escolhida pelo cliente é mais preferível para você como artista.
FontePor exemplo, o requisito "simples" de "fornecer a possibilidade de amostragem por região em todas as telas" no estágio de entrega pode causar muitos problemas, uma vez que não determina em qual tela a amostra deve ser fornecida, seja a amostragem por um valor de parâmetro ou por vários. como deve ser levada em consideração a historicidade das mudanças no nome das regiões. Se você apenas esclarecer esse requisito, é improvável que a resposta resolva os problemas indicados. Nesse caso, os esclarecimentos podem ser feitos usando uma carta com o seguinte conteúdo:. 4.5.6. : « 1, 2 3 «». , , ».
Uma cópia da carta é anexada à tarefa. A tarefa é transferida para o status "pendente" até que uma resposta do cliente seja recebida, que também é anexada posteriormente à tarefa. Essa redação é refletida no campo correspondente da tarefa JIRA (veja abaixo, “Esclarecimentos”). É com base nisso que as decisões de design, tarefas de desenvolvimento e tarefas de teste relacionadas são formadas.Idealmente, que muitas vezes é alcançável como um horizonte por razões objetivas e subjetivas, para transferir o requisito para um maior desenvolvimento, é necessário garantir um entendimento de seus limites por todos os membros da equipe do projeto. Portanto, assim que uma tarefa do tipo "requisito" é associada a tarefas de desenvolvimento, o gerente de projeto verifica se ele atende aos critérios de qualidade descritos abaixo ( Definição de Pronto) Se a redação básica do requisito não atender a esses critérios, o trabalho de aperfeiçoamento deve ser realizado sem falhas. O resultado do trabalho de refinamento deve ser uma redação atualizada do requisito ou uma decisão de projeto (SCF) acordada pelo cliente em relação a esse requisito. Ao contabilizar os custos de mão-de-obra em uma tarefa do tipo "requisito", apenas o tempo gasto diretamente em seu refinamento é registrado. Todos os outros custos de mão-de-obra são registrados em tarefas dos tipos correspondentes (ou suas subtarefas).Além dos atributos comuns descritos no artigo anterior , um conjunto de atributos adicionais foi definido para cada tarefa do tipo "requisito" no JIRA durante um processo longo e doloroso.* Atributo de preenchimento de recursos, comum a todos os tipos de tarefas.A alteração dos atributos específicos de uma tarefa do tipo "requisito" ao fazer a transição de estado para estado é descrita pela tabela a seguir, onde:
- uma alteração de atributo é possível;
- entrada de dados obrigatória.Continua
Muitos gerentes de projeto acreditam que, se os termos de referência foram aprovados pelo cliente, essa é a verdade última, que não está sujeita a alterações. Isso é parcialmente verdade - é improvável que a redação dos requisitos das especificações técnicas seja alterada até a conclusão do projeto. No entanto, já nos estágios iniciais do projeto (muito antes da aprovação do Programa e do procedimento de teste), ninguém se preocupa em esclarecer com o cliente os limites de cada requisito e fixar o procedimento proposto para sua verificação. Se esse trabalho não tiver sido realizado, provavelmente toda a "Lista de desejos" do cliente expressa durante a implementação, você decidirá dentro do orçamento e do cronograma do mesmo projeto.Não se esqueça das leis objetivas, que chamaram a atenção de Barry Boehm ( Barry W. Boehm ) no final dos anos 80 do século passado. Se o gerente do projeto não se preocupa em eliminar as incertezas e imprecisões dos requisitos nos estágios iniciais do projeto, então, na fase de conclusão do projeto, ele garante muitas “descobertas” desagradáveis.No entanto, a experiência mostrou que a maioria das ambiguidades não pode ser resolvida simplesmente esclarecendo os requisitos. Além disso, muitas vezes é impossível considerar os requisitos isoladamente, uma vez que os objetivos nos quais o software é criado podem ser alcançados somente com a implementação integrada dos desejos do cliente.Dentro da estrutura da abordagem descrita, propõe-se a coordenação de um conjunto de requisitos interconectados, bem como uma interpretação realista das fantasias dos clientes refletidas nos termos de referência aprovados, na solução de problemas do tipo "análise", cujos recursos serão apresentados no artigo "JIRA: regras para a preparação oportuna de software saboroso". TLDR 3: Soluções de Design. ” Source: https://habr.com/ru/post/undefined/
All Articles