Soluções de design: jogando de acordo com suas regras

Não é segredo que quanto maior o projeto de software, mais o seu sucesso depende dos resultados do trabalho dos analistas, em particular, da escolha da estratégia correta de elaboração e pactuação das decisões de projeto. Porém, como você organiza o trabalho desses colaboradores criativos? E como tornar os resultados de suas atividades igualmente claros para os representantes do cliente e os programadores? Como avaliar o prazo possível e a importância desse trabalho para o projeto? Neste artigo, tentei formular minhas receitas para otimizar o gerenciamento do trabalho analítico em projetos de software para clientes governamentais. Qualquer crítica é apreciada.



Uma fonte

Quadro de invertigação

, .



.

Como no momento existem mais de duas dezenas de tipos de vagas de “analista” no mercado de trabalho de TI , imediatamente irei fazer uma reserva para falar sobre o trabalho analítico em projetos estaduais de criação de software customizado. Como mostra minha experiência, um analista de negócios que não entende os mecanismos de automação dos processos de negócios não pode preparar uma declaração adequada do problema. Assim como um analista de sistemas que não entende os objetivos de negócios da automação não pode ser adequado. Portanto, do meu ponto de vista, um analista trabalhando em projetos de software customizado deve combinar as competências de um analista de negócios, um analista de sistemas e um designer UX. Além disso, como regra, o analista líder em tal projeto deve desempenhar as funções de Dono do Produto.(se o cliente permitir). É sobre a organização das atividades desses "soldados universais" que será discutida mais adiante.



Ao criar software no interesse de organizações governamentais, a principal atividade dos analistas está relacionada com a resolução de problemas como:

• gerenciamento de requisitos;
• formação de declarações de problemas para programadores, planejamento de implementação e controle sobre a implementação dessas tarefas;
• preparação da documentação do projeto.

Os detalhes de gerenciamento dos requisitos de software customizado, o procedimento para seu refinamento inicial e a função principal do analista responsável por sua implementação foram discutidos em detalhes no artigo anterior .



No entanto, a especificidade dos desejos do cliente não é garantia de que ele gostará do resultado final. No decorrer dos meus projetos , o seguinte padrão foi "revelado": todos os comentários funcionais do cliente, registrados durante todos os tipos de testes (não devem ser confundidos com os erros identificados!), Relacionados aos requisitos para os quais a solução de design não foi proativamente acordada com o cliente. A este respeito, as estatísticas fornecidas por Natalya Rukol são indicativas.quando, ao analisar os resultados de um dos projetos, constatou-se que quase 70% dos "erros" revelados na fase de entrega foram causados ​​por uma falta de compreensão dos requisitos iniciais por parte dos desenvolvedores. 



Parece que após os requisitos para o produto de software terem sido esclarecidos, é necessário formar um pacote de documentação de design de acordo com GOST RD 50-34.698 , coordená-lo com o cliente e então desenvolver software em total conformidade com o projeto aprovado. É frequentemente sobre essa sequência de ações que se ouve dos excelentes alunos de ontem (os alunos da série C, como regra, não sabem da existência de tais documentos) e de muitos funcionários "experientes" que nunca foram pessoalmente responsáveis ​​pelo resultado final do desenvolvimento de software. 



Como sugere minha experiência, a formação da documentação do projeto é apenas a parte final do trabalho do analista. Como analogia, pode-se citar um trabalho de pesquisa, como resultado do qual um relatório deve ser gerado de acordo com GOST 7.32 ou uma dissertação deve ser escrita. No entanto, esses documentos são apenas uma forma de formalizar os resultados científicos obtidos. A realização de experimentos infrutíferos, o processamento estatístico do "ruído branco", a busca por grãos da informação necessária em toneladas de resíduos de papel pseudocientífico - todas essas partes integrantes do trabalho científico sempre permanecem nos bastidores. O mesmo acontece com a documentação do projeto. Por um lado, é parte integrante do produto de software... Por outro lado, contém apenas os resultados finais do trabalho analítico.  





Fonte



Na minha opinião, este aspecto é um dos vários motivos pelos quais , de acordo com os requisitos dos contratos governamentais para projetos de software, clientes "estúpidos" planejam concordar com a documentação do projeto na fase de testes preliminares, ou seja, no momento da conclusão real do desenvolvimento do software.



É por isso que, nos nossos projetos de software em JIRA, são formados dois tipos de tarefas distintas, que nos permitem separar o trabalho analítico diretamente da atividade de preparação da documentação do projeto. E o que é gratificante, não fui o único a chegar a tais conclusões... Então, o que exatamente os analistas devem fazer em um projeto de software depois de especificar os requisitos e antes de elaborar a documentação do projeto?

Soluções de design VS documentação de design?

Como é lindo no papel,

Como é fácil seguir as palavras.

Como é fácil torná-lo infalível.



B. Grebenshchikov

Apesar do fato de que a definição do conceito "solução de design" é dada em GOST 34.003-90 , no meu caso o significado deste conceito foi "descoberto" no curso de tentativas dolorosas e infrutíferas de concordar com os representantes do cliente de vários requisitos inter-relacionados, mas ambíguos, quando os clientes simplesmente ignoraram o proposto descrevemos o estabelecimento de objetivos ( TMP ), formado em estrita conformidade com RD 50-34.698-90. Depois de perceber que a decisão por parte do cliente não seria tomada até o início dos testes, a seguinte manobra foi realizada: nossa solução de design foi enviada ao cliente (ou seja, uma solução com a qual ele não era formalmente obrigado a concordar). 



Os atributos do ritual foram mantidos na solução de design, mas ajustes significativos foram feitos neste documento em comparação com o HMO hospedado. A solução de design foi complementada com um diagrama de um processo de negócio automatizado com uma breve descrição, layouts de interface de usuário, formulários de relatórios recebidos para impressão, propostas de distribuição de acesso, bem como um breve cenário para a entrega desta solução de design. Em termos de requisitos ambíguos e conflitantes, uma descrição inequívoca e detalhada foi feita. No entanto, o resto do texto foi minimizado de todas as maneiras possíveis. Algoritmos triviais não foram descritos de forma alguma, assim como campos de formulários de tela não foram descritos, a finalidade e as regras de validação eram claras a partir dos layouts de IU fornecidos.  



O coquetel resultante era ao mesmo tempo semelhante em forma a um documento elaborado de acordo com os requisitos de RD 50-34.698-90, mas na verdade não correspondia a nenhum dos formatos fornecidos neste GOST. Ao mesmo tempo, o que estava escrito nele foi entendido por um representante comum e despreparado do cliente. Os requisitos especificados neste documento eram perfeitamente claros tanto para o cliente quanto para o contratante. Os limites dos requisitos, o escopo necessário do trabalho planejado e como esses trabalhos deveriam ter sido concluídos foram determinados.



A carta de apresentação continha algo assim:



“Apresentamos uma variante da solução de design para atender aos requisitos listados. Informamos sobre o início dos trabalhos de implementação da opção apresentada. Se você discordar da solução de design proposta, informe-nos. "



No caso de uma discussão mais aprofundada dos requisitos, a ausência de uma resposta a tal carta foi interpretada como um acordo formal do cliente com a solução de design proposta. Caso o cliente tenha enviado objeções, neste caso foi informado que o trabalho de implementação desta solução de design foi suspenso e não poderia ser continuado até a sua aprovação. Nesse caso, como regra, a aprovação posterior foi muito mais rápida.



O que é engraçado, a princípio, nas cartas de resposta, se o cliente não mandasse os esclarecimentos necessários, usávamos a frase "o trabalho está suspenso". Depois de várias dessas cartas, um dos representantes do cliente começou um escândalo pelo fato de que “pelo contrato firmado não podemos suspender as obras e a falta de esclarecimento sobre os requisitos não é motivo para encerrar a obra”. No entanto, ele não tinha objeções ao texto de que “o trabalho não poderia ser continuado”. 



Como se descobriu mais tarde, apesar do fato de que a estrutura formada da solução de design não atendia aos requisitos do GOST, a abordagem proposta facilitou muito os movimentos corporais rituais para a formação e aprovação da documentação do design. O conteúdo da documentação de design, necessária para a entrega do projeto, foi formado pela cópia seletiva das seções relevantes das soluções de design. Ao mesmo tempo, em relação às seções da documentação que foram formadas com base em decisões de projeto "acordadas" preventivamente, nenhum comentário foi feito pelo cliente durante a aceitação.

 A descrição do elefante não está de acordo com GOST

A verdade é que os clientes não sabem o que querem. Normalmente eles não sabem quais questões precisam ser respondidas e quase nunca pensaram sobre o problema nos detalhes que deveriam ser indicados na especificação. 



Frederick Brooks

Na minha opinião, o principal critério para uma boa descrição da declaração do problema (solução de design) não é o cumprimento dos requisitos formais do GOST, mas uma descrição inequívoca das condições para a conclusão bem- sucedida do trabalho para atender aos requisitos do cliente. Deste ponto de vista, a descrição dos itens de teste para verificar os requisitos é, na verdade, uma parte integrante de qualquer solução de design.





Deve-se observar que, ao trabalhar com um cliente governamental, todas as ambigüidades e ambigüidades em suas decisões de projeto sempre serão interpretadas em favor do governo. Para evitar esses pontos cegos, por meio de tentativa e erro nos requisitos de registro, uma lista de verificação de avaliação da qualidade do projeto foi desenvolvida, listando as principais seções que deveriam ser refletidas na solução do projeto, conforme necessário . Portanto, qualquer solução de design deve ser verificada nas seguintes posições.

1. Lista de requisitos do cliente (que serão implementados como parte da solução de design).
2. Lista de definições e abreviações.
3. A lista de documentos normativos que regulam o processo automatizado.
4. (use case), :
   
   
   
   
   • ( , BPMN – , : , ) ;
   • ;
   • ( ) — ;
   • ( , ).
5. :
   
   
   
   
   • , ;
   • (UI) ( , , ); 
   • () .
6. :
   
   
   
   
   • API;
   • () «» ( );
   • () «» .
   
   
   , « » ( 2011 ., 1). - , ().
7. :
   
   
   
   
   • , () , ;
   • , () .
8. () , , . ( ) . ( ), , () , . «» .

Repito - esta não é uma estrutura fixa para uma solução de design, é uma lista formal de perguntas ( lista de verificação), cujas respostas devem, se necessário, refletir-se de uma forma ou de outra na solução de design. Como mostra a prática, se o desenvolvimento em relação a um dos elementos descritos acima não for esperado, será melhor se você indicar isso explicitamente na solução de design. Ou quase explicitamente (não assuste o cliente). O principal critério é uma interpretação inequívoca. É importante não exagerar, para que em vez de resolver o requisito declarado, a partir da sua aprovação, não nasçam cinco novos. Por exemplo, a frase "A referência de tipos de objeto deve conter apenas valores reais" e a frase "A referência de tipos não fornece o armazenamento do histórico de alterações" significam a mesma coisa, mas a segunda frase provavelmente levará ao fato de que você deve descrever e implementar mecanismos de controle de versão este mesmo manual.Ao formar decisões de design, é importante entender que seu objetivo é fixar as regras pelas quais você tem a garantia de entregar os requisitos associados a essas decisões.

, , , .

Muito (senão todo) do projeto depende de como os representantes do cliente imaginam o resultado final. Portanto, já nos estágios iniciais, projetar layouts de interface de usuário é a chave para o sucesso do projeto. Esclareça e especifique os requisitos do cliente em termos de uma descrição externa do produto de software que ele entende. O diálogo com os representantes do cliente, a partir da discussão de layouts de telas, mostrou-se muito mais efetivo do que o diálogo sobre a discussão dos formatos de dados de entrada e saída e seus algoritmos de transformação (as principais seções do IPR, criadas de acordo com o GOST).



Trabalhar dentro da estrutura de atribuições de design de todos os elementos da interface do usuário, além da transparência de compreensão dos limites de implementação, também fornece uma solução para uma série de problemas:

1. . , , UI, , .
   
   
   
   
   
   : . . ISBN: 978-5-91180-090-1
2. UX- . , , ( ).
3. «» . UI , , – , ( « » ).
4. , «» . UX- . , 80% . , . ( ) : « ?». , , ( ) , , . , « ». «» . , , « ».

Fonte



: Gostaria de dizer algumas palavras sobre os princípios do projeto de interfaces de usuário para sistemas de controle automatizados. Apesar do crescimento semelhante a uma avalanche no uso de dispositivos móveis, os computadores desktop e laptops permanecem fora da competição por sistemas de controle automatizados usados ​​em agências governamentais (bem como para resolver problemas de programação e administração de sistemas). Atualmente, uma variedade de ferramentas apareceu para interfaces de prototipagem . No entanto, explicar as especificidades do uso do Figma ou do Axure no interesse dos dispositivos móveis perde 10% das formas primitivas que permitem projetar 90% das interfaces de usuário.ACS .



Na minha experiência, para reduzir significativamente os problemas de desenvolvimento de software, você precisa seguir algumas regras simples ao projetar interfaces de usuário.



Em primeiro lugar, você precisa decidir sobre um esquema de navegação geral, no qual, como uma árvore de Ano Novo, você pode pendurar sem dor mais e mais novos elementos de interface. Nesse sentido, para sistemas de controle automatizados em minha prática, o esquema mais eficaz se mostrou, o qual é amplamente utilizado em vários IDEs . 



Não vou dar um exemplo de interface IntelliJ IDEA ou PhpStorm aqui, no entanto, tentarei dissecar os principais componentes de uma IU em partes componentes, do ponto de vista de um analista de um sistema de controle automatizado.



A interface construída de acordo com este esquema contém um painel vertical dobrável à esquerda, que fornece navegação em todo o sistema. A presença de um painel vertical com seções contendo menus hierárquicos realmente garante a implementação da regra dos “ três cliques ”.





Cada uma das opções de menu da barra de navegação principal fornece acesso a listas de formulários de objetos. Listas de objetos (catálogos) e formulários (cartões) exibindo esses objetos constituem a maior parte da interface do usuário. A unificação desses dois tipos de formulários dentro da estrutura do projeto e a formação de uma estrutura de navegação em sua base podem reduzir significativamente o número de solicitações do usuário associadas a deficiências na documentação do usuário.



No âmbito da descrição de qualquer forma de lista, o design deve determinar:

• lista de campos de atributos exibidos;
• requisitos para os modos de exibição de lista (exibição por padrão, agrupamento, classificação);
• requisitos para o formulário subordinado associado ao item da lista (cartão de visualização rápida (tabela));
• requisitos para o painel de filtros (seleção de registros de acordo com uma determinada lista de atributos);
• descrição das operações do grupo (ações simultâneas em vários itens da lista, por exemplo: comparação de itens da lista, alteração de atributos para vários itens da lista, alteração dos direitos de acesso para vários itens da lista);
• descrição dos formulários (painéis) dos relatórios estatísticos operacionais (monitoramento) com base nos resultados da seleção da lista;
• uma descrição dos requisitos de relatórios para impressão e um algoritmo para sua geração;
• requisitos para notificar usuários (sistemas externos) quando os objetos mudam.

Ao projetar formulários de lista, as seguintes regras funcionaram bem:

1. — , «» , .   (ribbon). 
2. , , :
   
   
   • — , CRUD: , , , ;
   • ( , );
   • ;
   • ( , , ).
   
   
   
3. ( .. ) . , . .

  :

•   ;
•   , (CRUD, , ..) ;
• /;
• lista de possíveis mensagens de informação;
• maneiras de ver o histórico de alterações do objeto.

Algumas palavras sobre o kit de ferramentas. Como resultado de tentativa e erro durante a implementação de vários projetos governamentais, as três abordagens a seguir para design de interface provaram ser as mais eficazes.

1. Caso, durante o desenvolvimento, sejam necessárias alterações nas interfaces existentes, você não deve reinventar a roda. Aqui o Paint.NET se mostrou o melhor de todos (com a ajuda do qual, aliás, foram preparadas as fotos para este artigo). Não faz sentido redesenhar os formulários novamente, é mais fácil alterar a imagem finalizada.
2. , — « »,   MS Visio . , , , , MS Visio, , , Windows. 
3. , -  , . , , . DHTMLX. XML-, , . (view), , . , , MS Visio. , , , « ».

Repetidamente, dando todos esses argumentos para desenvolvedores avançados, longe dos problemas do cliente, eu vi seu olhar se desvanecendo e ouvi sua avaliação especializada sobre a infelicidade e a sobrecarga da IU proposta. No entanto, ao longo do tempo, após analisar a experiência de vários projetos, percebi um padrão surpreendente: se um programador critica zelosamente o atraso e a complexidade das interfaces de usuário desenvolvidas, isso é um sinal certo de que o cliente aceitará tal interface com um estrondo.

Andaimes e cofragem

Normalmente as pessoas pensam muito. Mas o problema é que eles pensam sobre os problemas, não sobre as soluções para esses problemas.



David Allen

Durante a construção das casas, são utilizadas muitas estruturas auxiliares que, após a conclusão da construção, são totalmente desnecessárias. Estes são andaimes e cofragens . Notavelmente, mesmo os não profissionais não disputam a necessidade de adquirir e manter essas estruturas. No setor de TI, por outro lado, você costuma ver um analista "experiente" lutando para criar imediatamente a documentação do projeto que atenda a todos os requisitos.



No entanto, na minha opinião, sem o registro preventivo e a aprovação das soluções de design, a documentação de design criada é adequada apenas para o encerramento formal do contrato e no futuro prejudica a operação mais do que ajuda. No entanto, as soluções de design e protótipos descritos acima não são as únicas "estruturas auxiliares" no trabalho analítico.



Fonte



À primeira vista, parece que tudo depende da experiência do analista, sendo impossível regular o uso desses trabalhos auxiliares. Por exemplo, como levar em consideração e regular o trabalho de um analista que passou o dia inteiro visitando um cliente e no dia seguinte trouxe três gigabytes de todo tipo de documento? Ou que o analista passou uma semana estudando esses documentos? Isto é bom ou ruim? E você realmente não pode responder a essa pergunta se não souber os resultados que fazem sentido à luz da implementação do projeto.



Por isso, no âmbito do nosso projeto, foi realizada uma classificação do trabalho analítico realizado em termos dos resultados alcançados. Além da solução de design,A maioria dos projetos de software dos quais participei exigia que o analista desenvolvesse materiais analíticos dos seguintes tipos.

• Análise de documentos - um relatório baseado nos resultados da análise dos documentos regulamentares do cliente ou da documentação do projeto.
• Revisão analítica - relatório sobre os resultados da análise de soluções para o problema surgido (em regra, uma análise comparativa de novas tecnologias ou tendências de mercado).
• Levantamento de informações - relatório sobre os resultados de um estudo dos processos de negócios existentes do cliente (formação do modelo as is - " as is ").
• — ,   (use case).  legacy-.  
• — , ( ).  
• — , .

A segunda etapa em direção ao design previsível foi definir requisitos específicos para o trabalho analítico pretendido. Com base nesses requisitos, um modelo de descrição do problema JIRA foi definido para cada tipo de material analítico sendo desenvolvido.





A declaração da tarefa para o desenvolvimento de materiais analíticos envolve uma breve descrição dos resultados requeridos, e não uma descrição dos processos de análise. Assim, por exemplo, é recomendável evitar frases como "conduzir uma análise de domínio ..." ou "estudar o documento".

Um plano para o maestro 

Tudo deve ser declarado da forma mais simples possível, mas não da maneira mais simples.



Albert Einstein

Freqüentemente, quando se trata de análise de agendamento e trabalho de programação, há muita controvérsia sobre como estimar o tempo dos resultados neste caso. No entanto, a análise acima desta atividade criativa nos permite fazer a suposição de que ainda é possível dentro da estrutura de um projeto de software. O primeiro passo para isso é quebrar o trabalho de design do sistema em partes que podem ser verificadas com uma frequência de pelo menos uma vez por semana. É necessário se esforçar para garantir que os custos de mão de obra do analista para a formação de uma solução de design não excedam 5 dias úteis (em termos de volume, tal solução de design deve consistir em aproximadamente 20-30 páginas - de acordo com GOST R ISO / IEC 15910-2002) Conseqüentemente, de acordo com os mesmos padrões, um programador deve levar no máximo 3 horas para revisar a mesma solução de design. 



É importante entender que não é necessário fazer um projeto técnico a partir de uma solução de design . A solução de design deve abranger apenas um pequeno grupo de requisitos inter-relacionados, cujo resultado pode ser apresentado ao cliente.



Também é importante evitar cair na armadilha sobre a qual Mary e Tom Poppendieck alertam ao definir uma decisão de projeto.ou seja, não ficar refém do mito de que uma especificação detalhada criada com antecedência é garantia de redução de perdas. Como regra, ao chegar a um acordo sobre uma solução de design, o cliente tenta empinar tudo o que consegue lembrar neste documento. Portanto, ao concordar sobre isso, é importante garantir que o mínimo necessário que irá garantir a aprovação nos testes preliminares. Ao mesmo tempo, a chave do sucesso não é apenas uma combinação de qualidade, prazo e custo, mas também a satisfação dos participantes do projeto com seus resultados.



Regra geral, para obter os prazos de execução das tarefas de análise, basta uma peritagem do próprio contratante, mas em caso de litígio pode ser aplicada uma abordagem pragmática .... Para aumentar a objetividade da avaliação da intensidade do trabalho das tarefas de análise, pode ser utilizada uma calculadora online , que permite planear e estimar os custos do trabalho para a realização do trabalho analítico. Com essa ferramenta, é possível criar uma lista de obras planejadas, esclarecer sua redação, dependendo das especificidades do projeto. Para cada uma das obras previstas, é considerada a estimativa mínima, máxima e mais provável de custos de mão de obra. Como resultado do cálculo, a complexidade esperada da tarefa é formada e a reserva de tempo ótima é calculada, que deve ser deixada para o seguro. A descrição gerada da configuração do problema para análise pode ser copiada diretamente no campo de descrição do problema do JIRA.



Além dos atributos gerais descritos no artigo " JIRA: Limites do Projeto", Para cada problema do tipo" análise "no JIRA, o seguinte conjunto de atributos adicionais (personalizados) foi determinado empiricamente.





Levando em consideração o exposto, esclareçamos a seqüência de ações do analista previamente dada para implementar tarefas do tipo "análise" no interesse do desenvolvimento de software.



1. Se necessário, o analista responsável deve agendar tarefas no JIRA para conduzir pesquisas de informações com representantes do cliente (essas tarefas estão vinculadas aos requisitos relevantes).



É aconselhável, antes da reunião, numa primeira aproximação, fazer mock-ups da interface do usuário , que podem ser discutidos com o cliente. Ao realizar um levantamento de informações, é necessário discutir com o cliente o principal processo de negócio, do seu ponto de vista (user story - user story), formas alternativas pelas quais o cliente vê o resultado final. 



Freqüentemente, encontrei a opinião de que a base de uma pesquisa de informações é entrevistar um funcionário competente que falará em detalhes sobre os recursos do processo automatizado. No entanto, o que é bom para o desenvolvimento no interesse de um cliente comercial pode ter as consequências mais inesperadas para o governo. Encontrei repetidamente uma situação em que descobri que a descrição do processo, formada com base nas histórias de veteranos de cabelos grisalhos, contradiz os principais requisitos dos documentos regulamentares atuais. E isso não se explicava pelo fato de o analista ter entendido algo mal, mas pelo fato de o veterano "ter feito isso por toda a vida".



Portanto, antes de se reunir com especialistas no assunto, é necessário analisar os documentos normativos do ponto de vista da regulamentação do processo que se pretende automatizar. Ao mesmo tempo, é importante compreender que os documentos normativos também não são a verdade última, pois muitas vezes, numa análise imparcial, os documentos normativos contêm sempre ambiguidades e contradições (a exceção, em regra, são os documentos “escritos com sangue”). Aqui estão alguns dos desacordos mais comuns aos quais você deve prestar atenção:

• violação dos princípios básicos de classificação , por exemplo, quando sinais diferentes são misturados dentro do mesmo grupo (vermelho, verde, quente);
• construção de documentos de relatório com base em atributos que não são contabilizados;
• ;
• - ;
• — - , .

Resolver esses conflitos regulatórios é um dos principais problemas ao se reunir com os representantes do cliente. Para registar esta decisão, em resultado do levantamento de informações, deve ser elaborado um protocolo com indicação dos participantes, local e hora. O protocolo é apresentado ao cliente para esclarecimento (e-mail anexado à tarefa correspondente). Depois disso, a tarefa do levantamento de informações pode ser transferida para o status "concluído". Esta tarefa JIRA é transferida para o status "fechado" após receber a confirmação do cliente sobre a aprovação do protocolo.



2  Com base nos requisitos especificados e nos resultados de pesquisas de informações, uma solução de design é formada. O analista responsável deve coordenar isso com o gerente de projeto e programadores (para cada um deles, subtarefas apropriadas são criadas). Se a solução de design não passou na aprovação interna durante o dia de trabalho, a tarefa é transferida para o status "pendente" (um sinal para o gerente de projeto). Tendo passado na aprovação interna, a solução de design é enviada ao cliente para revisão (se necessário, aprovação). Todos os detalhes do envio são registrados nos comentários da tarefa. Enquanto a solução de design está do lado do cliente, a tarefa é transferida para o status "pendente".



3 -Se a solução do projeto for acordada (ou se ficar claro que a aprovação está sendo atrasada e os prazos estão se esgotando), então, com base nele, o analista responsável formula tarefas de desenvolvimento, teste e documentação. Neste caso, é necessário realizar uma avaliação preliminar dos custos laborais para a implementação da solução de design (como a soma dos custos laborais das tarefas de desenvolvimento associadas a esta solução de design). Com base nessa avaliação, é necessário esclarecer o momento de implementação dos requisitos relacionados.



4.  Após acordo com o cliente (uma carta confirmando este fato é salva no JIRA), a tarefa de preparar uma solução de design pode ser transferida para o status "concluído".

Continua 

Atualmente, o projeto de software para clientes governamentais é mais frequentemente organizado de acordo com os requisitos da série GOST 34. Ao mesmo tempo, defendendo a conformidade exata da documentação de design final com este GOST, a maioria dos representantes do cliente muitas vezes "esquece" que, além da documentação fornecida para testar o software desenvolvido, o cliente deve aprovar soluções de design no âmbito da aprovação do rascunho e dos projetos técnicos. E mesmo no caso em que o rascunho e os desenhos técnicos são acordados, não é incomum que o conteúdo seja ignorado por causa de prazos irrealistas em total conformidade com o formulário. Isso é especialmente verdadeiro para o projeto de sistemas que não estão diretamente relacionados à segurança de vidas. Então, em um dos projetos, um vice-chefe "ensinou vida"falando sobre como ele construiu um projeto técnico de 500 páginas usando a Wikipedia em uma noite. Como regra, pessoas completamente diferentes precisam separar os resultados de tais “decisões de design”.



Nessas condições difíceis, as abordagens descritas aqui permitem que você organize uma construção iterativa da funcionalidade do software enquanto mantém a consistência das soluções implementadas, o que corresponde aos princípios do desenvolvimento de software enxuto . Por outro lado, as configurações de destino das soluções de design descritas permitem compilar documentos em sua base que atendam aos requisitos "Procrusteanos" do cliente a um custo mínimo.



A divisão do trabalho analítico em ações elementares também permitiu coordenar as ações de vários funcionários com diferentes níveis de formação e, assim, formar naturalmente uma matriz de competências para analistas do nosso projeto no LANIT , que pretendo discutir no próximo artigo.



PSEste artigo é parte de uma série de artigos denominados " Regras para a preparação oportuna de softwares deliciosos ", que utilizo como um regulamento informal da equipe de projetos de software customizados no interesse de organizações governamentais. Esta série inclui os seguintes artigos:

- " JIRA como remédio para insônia e crises nervosas " - a ideia principal para organizar o trabalho de um projeto usando JIRA;

- " JIRA: limites do projeto " - disposições básicas para a unificação do projeto e requisitos gerais para todos os tipos de tarefas JIRA;

- “ JIRA: gestão de requisitos ” - as principais funcionalidades de registo, esclarecimento e controlo da implementação dos requisitos do cliente dentro do modelo proposto;

- "Soluções de design: jogar de acordo com suas regras ”- os principais aspectos da gestão analítica do trabalho e a formação de declarações de problemas para desenvolvedores;

No âmbito deste ciclo, está a ser preparado para publicação o seguinte:

- “ Matriz de competências do analista ” - critérios de avaliação do nível de maturidade dos analistas em projectos de software personalizado;

- " Onde os problemas se escondem no projeto " - os critérios (métricas) da avaliação operacional do estado atual do projeto de software.



O principal rótulo desta série de artigos é proporcionar melhoria evolutiva na qualidade dos projetos de software com base na melhoria da eficiência da gestão. Em outras palavras, para formar métodos de crescimento aplicados aos níveis do modelo CMMI .

Se você descobriu como usar o JIRA de forma mais eficiente em seu projeto de software - compartilhe suas idéias. Apenas ao descrever essas idéias, evite a frase "de alguma forma" e "de alguma forma". Convido a todos para discutir. Estou aguardando comentários / sugestões / dúvidas / desejos nos comentários.