JIRA: regras para a preparação oportuna de deliciosos softwares. TLDR 1: limites de oportunidade

No início do artigo “ JIRA como remédio para insônia e colapsos nervosos ”, foi proposta uma opção para usar o JIRA para gerenciar um projeto de desenvolvimento de software no interesse de um grande cliente estatal. No entanto, o manuseio descuidado dos equipamentos de automação de controle na "cozinha digital" pode não apenas estragar o produto, mas também levar a numerosos ferimentos. Em uma série de artigos "Regras para a preparação oportuna de software delicioso", propõe-se estudar em detalhes as regras para organizar o trabalho em um projeto de software usando um catalisador chamado JIRA. Qualquer crítica é bem vinda.

Fonte

Segredos Gerais

Inteligência é a capacidade de evitar o trabalho, mas para que seja feito.
Linus Tordvalds

Após a publicação do artigo “ JIRA como remédio para insônia e crises nervosas ”, vários executivos se interessaram em nossa experiência no uso do JIRA e decidiram introduzir um esquema de automação de gerenciamento semelhante em seus projetos. Portanto, como resultado da redação deste ensaio, deveria "simultaneamente pegar alguns coelhos":

- considerar sequencialmente cada tipo de tarefas do JIRA como um subprocesso do projeto, durante a apresentação:

• unificar as especificações desses subprocessos;
• padronizar regras de negócios para trabalho organizado;
• compilar mapas de "armadilhas" típicas e lugares que exigem "camas de palha" avançadas;
• determinar indicadores de desempenho mensuráveis ​​e realizáveis ​​para cada tipo de tarefa.

- formular uma declaração do problema para o administrador do JIRA, a fim de implantar novos projetos de acordo com a abordagem proposta;
- obter regulamentos informais, mas, no entanto, compreensíveis e transparentes sobre a distribuição de responsabilidades de todos os funcionários das equipes de projeto;
- formalizar as melhores receitas encontradas durante a solução de situações problemáticas (“life hacks” do gerente de projetos);
- identificar pontos fracos anteriormente não notados da abordagem proposta durante a discussão dos detalhes de sua implementação com os leitores da Habr.

Gostaria de observar imediatamente: algumas das técnicas descritas se comprovaram em uma das cozinhas digitais da LANIT para gerenciamento de projetos para o desenvolvimento e manutenção de software personalizado no interesse de um grande cliente do estado. No entanto, não é fato que essas recomendações sejam igualmente úteis em seu projeto. Por outro lado, estamos entrando em terra incógnita. Algumas das considerações expressas são planejadas apenas para implementação. Portanto, se você perceber pontos fracos na abordagem proposta ou se houver propostas construtivas de otimização, seja bem-vindo à discussão nos comentários.

Supõe-se que após a unificação ser realizada no interesse de diferentes líderes, a tecnologia de gerenciamento descrita será aplicada com sucesso a projetos de software de diferentes orientações e diferentes escalas. Por sua vez, o uso de um único espaço conceitual ao registrar tarefas do JIRA cria os pré-requisitos para a avaliação automatizada do estado atual das coisas na estrutura do portfólio de projetos . Além disso, supõe-se que uma abordagem unificada para registrar os resultados do trabalho no JIRA simplificará a mobilidade dos funcionários entre vários grupos de projetos, o que por sua vez também contribuirá para aumentar o sucesso dos projetos.

Limites do projeto

Qualquer tarefa difícil tem uma solução simples, fácil de entender e incorreta.
Arthur Bloch

Desde que o algoritmo de aplicativo JIRA proposto começou a se espalhar para outros projetos, foi necessário repensar a pergunta: "O que determina exatamente os limites de um projeto de software no JIRA?"

De acordo com os seguidores do PMBoK sem nuvens , a resposta a esta pergunta é elementar: "É claro que os limites do projeto são determinados pela carta (passaporte) do projeto ". Desse ponto de vista, para cada contrato com o cliente, um projeto separado deve ser formado no JIRA. Além disso, muitas vezes o desenvolvimento de um pacote de software pode incluir várias áreas de atividade, dentro das quais, como regra, vários contratos são concluídos:

• desenvolvimento - requisitos sob contratos para a criação de novos sistemas (subsistemas);
• desenvolvimento - requisitos no âmbito de contratos destinados a uma revisão substancial dos subsistemas existentes;
• suporte estendido - os requisitos de contratos para a conclusão operacional de módulos de sistema individuais para alterações atuais nos processos de negócios do cliente;
• suporte de garantia - eliminação de erros de software identificados durante o período de garantia;
• suporte básico - eliminação de erros de software identificados após o final do período de garantia.

Além disso, como parte da criação do software, a equipe do projeto deve resolver requisitos que não são definidos por nenhum dos contratos. Estes são os requisitos do gerente de projetos relacionados às atividades pré-projeto, refatoração, pré-venda, eliminação de erros identificados independentemente, treinamento da equipe etc.

No entanto, como a prática demonstrou, no desenvolvimento real de um produto de software de longo prazo, é difícil separar o trabalho de desenvolvimento e manutenção. A operação de teste ainda não terminou (o contrato de desenvolvimento não está fechado) e o cliente já está em pleno vigor para formular requisitos para suporte estendido a componentes do sistema que ainda não foram colocados em operação comercial. O cliente pode ser entendido, porque o mundo está mudando mais rápido do que o planejado nos contratos aprovados. Ao mesmo tempo, a identificação de novos defeitos de software continua. E o usuário que descobriu o defeito não se importa em que contrato esse erro deve ser corrigido. Do seu ponto de vista - simplesmente não deveria ter sido. Para atribuir o erro identificado a um ou outro contrato, leva tempo para analisá-lo e, se os projetos do JIRA são divididos com base nos contratos, surge um dilema : “E em qual projeto do JIRA esse defeito deve ser registrado?”. Além disso, é necessário organizar a transferência de tarefas de um projeto para outro, se um erro de classificação foi cometido. Se todos os defeitos identificados no software forem atribuídos a um projeto separado da equipe de suporte, os riscos de problemas surgem ao resolver problemas de pagamento pelo trabalho na fase do contrato de desenvolvimento ou ao analisar reclamações sobre não conformidade com o contrato no nível de fornecimento de serviço ( SLA ).

Por outro lado, os ciumentos chefes de departamento propõem que, dentro da estrutura do projeto, sejam criados projetos separados para a equipe de suporte, o departamento analítico e o departamento de desenvolvimento e teste. Todo mundo quer ser um mestre de pleno direito em sua diocese e não ser responsável pelos "cardumes" dos vizinhos. Além disso, a incrível flexibilidade do JIRA permite criar conexões entre as tarefas de diferentes projetos.

Fonte

Na minha opinião, as abordagens acima para registrar projetos no JIRA são semelhantes a tentar cozinhar uma sopa em vários potes diferentes localizados em cozinhas diferentes. O principal objetivo do projeto é a criação oportuna de um produto de software de uma determinada qualidade. Do ponto de vista do cliente, a qualidade do produto é determinada pelo conjunto de recursos funcionais desse produto, usando o qual o cliente pode garantir (ou seja, com segurança) resolver seus problemas de forma garantida (ou seja, confiável). E não importa para o cliente funcional final sob o qual as relações contratuais a funcionalidade necessária foi criada. Assim como não é importante que o piloto conheça a lista de subcontratados envolvidos na criação de sua aeronave.

Com isso em mente, a definição dos limites de um projeto JIRA deve garantir a harmonia entre as duas considerações a seguir.

1. É necessário que o projeto reflita todo o trabalho realizado durante a criação / modificação do produto de software (ou seu subsistema). O projeto deve ser considerado como um processo único para a criação de um produto de software (uma "aeronave"). Portanto, o princípio principal: um produto de software - um projeto JIRA. É importante não esquecer o que sua empresa produz - um "avião" ou um "motor para aviões". De qualquer forma, os criadores de software não devem ser alienados das consequências de suas decisões.
   
   Independentemente do tipo de relacionamento contratual com o cliente, o ponto de entrada para o processo de criação de um produto de software é qualquer requisito para sua modificação. O evento final é o recebimento da confirmação do cliente de que esse requisito foi implementado (ou declarado insolvente). Essa regra é a principal para avaliar a integridade do planejamento e a integridade das tarefas no projeto JIRA.
   
   É aconselhável que o projeto JIRA também encontre um local para trabalho auxiliar iniciado no interesse de atender aos requisitos do cliente. Durante o desenvolvimento do software, ocorrem muitos eventos que, em regra, permanecem “nos bastidores”: reuniões regulares para esclarecer prazos, implantar servidores de teste, preparar dados de teste, gerar instruções adicionais, etc. O JIRA pode ser de grande ajuda na detecção de buracos através dos quais o tempo de trabalho dos funcionários da equipe do projeto flui generosa e irrevogavelmente. Mas somente com a condição de que essas obras sejam registradas no projeto JIRA.
2. No caso de desenvolver sistemas de software realmente grandes, você não deve colocar tudo em um projeto JIRA, aumentando significativamente o risco de interrupção. Nesses casos, dentro de um projeto JIRA separado, é aconselhável agrupar por funções de software que fornecem suporte para um dos processos de negócios do cliente (como regra, essas funções são alocadas a subsistemas separados já no estágio do projeto conceitual).

Fonte: Sergey Arkhipenkov. Avaliação do projeto: charlatanismo ou xamanismo

Vale a pena pensar na formação de projetos individuais do JIRA para registrar os resultados do trabalho realizado regularmente na estrutura de vários produtos de software (por exemplo, contabilizando o tempo gasto pelos funcionários no estudo de novas tecnologias ou no trabalho relacionado a backups).

Uma das restrições em um projeto JIRA pode ser o número máximo de funcionários da equipe do projeto. A experiência pessoal sugere a seguinte conclusão: a composição máxima da equipe de desenvolvimento em um único projeto JIRA segue a regra de Miller (nas melhores tradições do Agile). O grupo de desenvolvimento aqui se refere a programadores e analistas que formulam as tarefas para eles. E, claro, o gerente de projetos. (Como você pode pensar! Isso é sagrado!) Além disso, se o orçamento do projeto permitir, os 80% restantes dos funcionários da equipe do projeto, que consistem em meninas amigáveis ​​da equipe de suporte, testadores mal-humorados, escritores técnicos chatos e um administrador de sistema divertido, podem ser incluídos de maneira segura e harmoniosa no projeto JIRA.

Como colocar tarefas nas prateleiras

No meu sótão, existem apenas as ferramentas de que preciso. Existem muitos deles, mas eles estão em perfeita ordem e sempre à mão.
Sherlock holmes

Em qualquer projeto, a navegação dos funcionários no fluxo de tarefas a serem resolvidas é um dos componentes importantes do sucesso. No entanto, à medida que o volume do projeto aumenta, fica cada vez mais difícil entender esse fluxo, que pode se tornar, por si só, um dos problemas do gerenciamento de um grande projeto. Portanto, a definição de um sistema de coordenadas único pelo qual todos os principais participantes possam navegar com facilidade é parte integrante da automação do gerenciamento de projetos.

A base desse sistema de coordenadas em nosso projeto foram as seguintes considerações: um produto de software, em regra, pode ser imaginado como uma caixa preta que se comunica com o mundo exterior de três maneiras principais:

• através da interface do usuário ;
• através de documentos formados para impressão em papel;
• via protocolos de troca eletrônica de dados ( API / EDI ).

É no espaço dessas três dimensões que os usuários finais veem o software. Por outro lado, a criação de software visa precisamente a formação e o processamento desses fluxos de dados.

Fonte

Além disso, os principais objetos de banco de dados e processos de negócios automatizados foram adotados como coordenadas adicionais dentro do projeto. Para navegar dentro desse espaço de coordenadas, foram formados classificadores apropriados, cujo suporte foi fornecido pelo gerente de projeto e analistas. Cada elemento do classificador consistia em um código e sua definição.

No decorrer dos meus projetos, para cada classificador, seus próprios recursos foram gradualmente revelados, o que deve ser levado em consideração se você decidir aplicar uma abordagem semelhante.

• No nosso caso, os códigos dos formulários impressos não repetiram a numeração dos formulários de acordo com os documentos do cliente. Além disso, os formulários individuais tinham várias opções de impressão. Assim, por exemplo, ao longo da existência de software, a forma de um dos relatórios mudou várias vezes com base em alterações nos documentos regulamentares (o nome e a essência do relatório não foram alterados). Ao mesmo tempo, para os dados antigos, era necessário manter a impressão deste relatório nos formulários antigos. As mesmas considerações se aplicam à classificação nos rascunhos de protocolos para intercâmbio eletrônico de dados.
• Na hierarquia de formulários, elementos individuais podem incluir painéis de navegação (menus), formulários de lista, cartões de objeto, guias, painéis de filtro, formulários de carregamento / descarregamento de dados, bem como formulários de operações complexas de grupo.
• É desejável “cultivar” as “árvores” dos processos tecnológicos para que eles tenham operações tecnológicas atômicas (indivisíveis), com base nas quais, por sua vez, é possível garantir o funcionamento do subsistema de distribuição de acesso (subsistema de segurança).
• Como todos os elementos de classificação com essa abordagem são exibidos nas telas do JIRA em um campo, é necessário fornecer pelo menos codificação primitiva, além dos nomes dos componentes, para distinguir o formulário "Registro de funcionário" do processo "Registro de funcionário".

Para quem não procura maneiras fáceis, as tarefas do JIRA podem ser marcadas com base no registro dos códigos correspondentes no campo "Componentes". Ao registrar tarefas de qualquer tipo no JIRA, no campo "Componentes", basta indicar a lista de códigos de objetos para os quais o trabalho planejado visa alterar / formar. Com base nos resultados da solução de cada problema, o executor responsável deve esclarecer a composição dos componentes (se necessário). Os próprios classificadores de componente são mantidos fora do JIRA.

Para os amantes do conforto a esse respeito, talvez o plugin Subcomponents for JIRA possa ajudar bastante .

Deve-se notar que o uso de classificadores corretamente compilados de componentes de software padroniza implicitamente a consciência coletiva e a linguagem de comunicação da equipe do projeto, resultando em um aumento no nível geral de entendimento. Por outro lado, essa abordagem é um dos métodos de coerção não violenta dos analistas para tarefas mais detalhadas, o que, por sua vez, aumenta a precisão de estimar o momento da implementação dos requisitos no projeto.

As regras de classificação adotadas para tarefas não apenas reduzem o tempo gasto na pesquisa, mas também fornecem a capacidade de automatizar:

• estimativas do insumo total planejado de mão-de-obra (ou custos reais de mão-de-obra) para obras destinadas à implementação de certos elementos de software,
• avaliação da distribuição real das prioridades - em alguma fase do projeto, seu gerente pode se surpreender ao descobrir que a maior parte do trabalho não é realizada em relação aos componentes prioritários,
• análise da qualidade do desenvolvimento da documentação ,
• avaliação da qualidade do gerenciamento de projetos em termos de planejamento. Por um lado, não faz sentido planejar tarefas nas quais os componentes não são formados (modificados) e, por outro lado, o planejamento de tarefas, durante o desenvolvimento do qual dezenas de objetos são alterados, indica que o problema não é cuidadosamente formulado.

Ao amarrar tarefas, não amarre as mãos

Ao descrever os princípios gerais de nosso modelo , foi dito sobre o uso de apenas um tipo de conexão "razão" -> "ação" (e, dentro da estrutura do projeto descrito, essa conexão era suficiente). No entanto, o desejo de usar os mesmos mecanismos do JIRA para automatizar o gerenciamento em vários projetos diferentes exigidos para expandir o número de tipos de relacionamentos usados ​​e unificar abordagens à sua aplicação.

Fonte

O JIRA "pronto para uso" oferece ao usuário vários tipos diferentes de conexões entre tarefas, e o uso descontrolado dessas conexões pode levar a conseqüências tristes. Para não confundir a nós mesmos e aos outros, concordamos com as seguintes regras básicas para ligação de tarefas do JIRA.

• O fechamento do mesmo tipo de link no loop é inaceitável (embora o JIRA permita isso).
• Um relacionamento adicional "Dependido" ("razão" => "ação") é usado apenas para conectar tarefas de diferentes tipos e somente na direção do "fluxo" do modelo clássico em cascata (cascata): requisito => análise => desenvolvimento => teste => documentação => implementação. A especificação dessas conexões na ordem inversa e a vinculação de tarefas do mesmo tipo são inaceitáveis. Se novos requisitos nasceram durante a implementação, quando esses requisitos forem registrados no JIRA, a conexão entre eles e a tarefa de implementação, durante a qual eles apareceram, não será formada.
• A conexão " Blocos " ("blocos" => "blocos") pode ser usada em qualquer um dos tipos de tarefas para criar sequências de fluxo de trabalho (por exemplo, para compor um script de execução de teste).
• O relacionamento " Clonadores " ("pai" => "filho") é usado apenas para a comunicação de tarefas do tipo "requisito". Associa o documento original do cliente contendo vários requisitos ("pai") a tarefas que contêm requisitos atômicos "descendentes".
• O relacionamento "Suplemento" ("Suplementos" => "suplementado") é usado apenas para relacionamentos na estrutura de tarefas do tipo "requisito". É usado para registrar a relação entre a tarefa do requisito principal e as tarefas nas quais os erros, comentários e esclarecimentos identificados durante o teste são registrados. De fato, usando esse tipo de comunicação, é fornecido o registro do histórico de alterações nos requisitos.
• O relacionamento "Duplicar" ("duplicado" => "duplicado") é usado apenas para a comunicação de tarefas do tipo "requisito". Ao especificar duplicatas, é necessário determinar o requisito básico, no âmbito do qual o trabalho será planejado na sua implementação. Em relação às duplicatas, as comunicações com tarefas de implementação não são criadas.

Fluxo de trabalho para todas as ocasiões

A razão para muitos problemas é que definimos quantas tarefas precisamos concluir, e não tantas quanto podemos concluir.
Maxim Dorofeev

, JIRA, . , JIRA (workflow). .

. «» . , JIRA . , .

, «» «», «» ( , ).






, .
*

, :

— ;

— ;

— .


« » «» . , . «». , . «» ( ).

BPM ( business process management ), . BPM «» , :

• - ( BPM CBOK );
• ( PM BOK );
• ( ITIL );
• ISO 9000 ;
• ( CMMI SEI );
• , , / 12207-2010 « . . ».

PMP ITIL . , , BPM , , . BPMS . - BPM ( , , Agile ). BPM « » ( , ). «» «» ( ). «»?

BPM . , , , BPM , .

Fonte

JIRA . , JIRA , , . BPM. , JIRA BPMS. Todas as sugestões adicionais para o uso do JIRA para automatizar o gerenciamento de projetos de software serão feitas com essa consideração importante em mente.

Uma das primeiras etapas na escada do CMMI é identificar, documentar e unificar os processos da organização. Portanto, como parte da série de artigos “JIRA: as regras para a preparação oportuna de software saboroso”, deve-se formular consistentemente especificações para todos os tipos de tarefas a serem resolvidas e tentar formular o aparato de critérios para sua avaliação abrangente do ponto de vista da abordagem do processo. O próximo artigo será dedicado aos recursos de registro de tarefas do tipo "requisito" e processos de negócios para sua implementação.