Como estabelecer um processo eficaz de gerenciamento de projetos em condições em que "certo" e "o que é melhor" não podem ser feitos, mas ainda precisam ser feitos? O artigo fornece uma visão geral do uso do JIRA para gerenciar um projeto de desenvolvimento de software no interesse de um grande cliente do governo. Ficarei feliz se as abordagens descritas ajudarem você a aumentar pessoalmente a eficácia de sua equipe e reduzir a tensão no projeto. Qualquer crítica é bem vinda.
FonteFilho de erros difíceis
A julgar pelo grande número de artigos modelo na Internet sobre como aplicar adequadamente os sistemas de gerenciamento de projetos no desenvolvimento de software, esse é um negócio simples e agradecido. No entanto, o uso real de sistemas de controle automatizado em projetos nos quais tive a chance de participar não foi tão "otimista" quanto se poderia esperar. Existem vários casos típicos que foram encontrados na prática.
As melhores opções se resumiram ao uso pela equipe do projeto de um dos muitos sistemas de rastreamento de bugs. A estrutura de tarefas e processos de negócios de um projeto geralmente se desenvolve “fora da caixa”. Esses sistemas foram utilizados principalmente por equipes de programadores e testadores. Essa organização de desenvolvimento pagou bem em pequenos projetos com clientes particulares, ou se as tarefas dos executores incluíssem apenas suporte de garantia para o produto de software (corrigindo erros detectados). No entanto, com o crescimento de novos requisitos, essa abordagem começou a cair. Isso se manifestou em um aumento no tempo gasto comparando os requisitos do cliente e as informações armazenadas no rastreador de bugs (e compilando manualmente relatórios integrados), além de dividir a equipe em dois campos (programadores “bons” e analistas “ruins”).
Outras situações se resumiram a inspirações “brilhantes” da liderança, quando, usando alavancas administrativas, as melhores metodologias de desenvolvimento de software foram “introduzidas” nas atividades das equipes de projeto. É verdade que esses líderes acreditavam que suas ações eram limitadas apenas ao processo de encontrar essa "bala de prata". Eles não se incomodaram com conceitos como "
sprint ", "
diagrama de combustão de tarefas " ou "
diagrama de fluxo cumulativo ". E mesmo que se incomodassem, os documentos de relatório que precisavam ser formados no estado do projeto (novamente manualmente) estavam vagamente conectados a essa melhor metodologia. As tentativas de apresentar aos clientes esses métodos levaram ao fato de que as condições do projeto não foram alteradas e, nos relatórios antigos, era necessário adicionalmente gerar novos relatórios adicionais (de acordo com o novo método). Tais contradições foram especialmente pronunciadas em projetos de contratos governamentais, cujas condições de organização conflitaram diretamente com a aplicação bem-sucedida do
Agile ,
RUP ou
PMBOK .
A apoteose da automação de gerenciamento foi o projeto para refinar o sistema de informações em nível federal no interesse de um grande cliente estadual. Como parte deste projeto, o próprio cliente usou o
HP Service Manager e o
JIRA . O HP Service Manager foi usado para coletar e analisar erros de software. Com a ajuda do JIRA, o cliente planejou as atividades de seus funcionários relacionadas à correção desses erros e ao desenvolvimento adicional do sistema. A lista de estados de tarefas nesses sistemas forneceu toda a variedade de opções possíveis para seu processamento. Os procedimentos detalhados para dar suporte a essas tarefas, formados pelo escritório de projetos do cliente (ou seja, pessoas que não são responsáveis pela manutenção e desenvolvimento), foram publicados na plataforma
Confluence . Os funcionários do contratado foram autorizados a ambos os sistemas, e eles foram incumbidos da responsabilidade de apoiar incidentes e requisitos (com diretrizes temporárias para tarefas de processamento e uma escala progressiva de multas). Além disso, uma cópia do JIRA foi implantada no local do contratante, com a ajuda da qual as atividades da equipe do projeto foram planejadas. A sincronização das atividades dos três sistemas foi realizada manualmente (para isso, eu tinha que manter uma "planilha" no Excel, na qual eram anotadas a relação das tarefas e seu estado atual). Além disso, os relatórios gerados pelo JIRA não se adequavam ao gerenciamento e, portanto, a equipe do projeto precisava fornecer relatórios horários de suas atividades, que eles também criavam manualmente no Excel. A situação não era incomum quando o chefe da equipe de desenvolvimento ou o chefe dos grupos de suporte “desligaram” no trabalho até tarde da noite, gerando relatórios resumidos sobre o estado do projeto com base nos resultados da equipe do projeto. Esse projeto foi concluído com sucesso no prazo e foi lembrado, exceto por uma baixa produtividade recorde, aumento do número de crises nervosas, esgotamento profissional rápido e, a julgar pelos bônus dos funcionários "sobreviventes", uma margem inesperadamente baixa. Após esses projetos, o pensamento nos assombra por um longo tempo: "Se criamos ferramentas que facilitam muito a vida dos clientes, por que, devido a essas ferramentas, pioramos nossas vidas de maneira tão sofisticada?"
Características do desenvolvimento nacional
Resumindo a experiência, podemos concluir que os maiores problemas com a automação do gerenciamento de desenvolvimento de software ocorreram em projetos para pedidos estaduais.
FonteAlém disso, tentativas repetidas de solucionar esses problemas de acordo com as melhores práticas de desenvolvimento de software levaram à conclusão: não são problemas, mas condições inevitáveis para a implementação do projeto para o cliente do estado. Uma análise de vários projetos nos permitiu identificar as seguintes características características generalizadas de tais condições:
- frequentemente os requisitos iniciais das especificações técnicas são formulados vagamente, o cliente investe nesses requisitos todos os novos significados à medida que o projeto se desenvolve (que está associado, entre outros, a uma mudança na atual estrutura regulatória que governa os processos de negócios automatizados);
- o intervalo de requisitos registrado nos termos de referência varia de "corrigir a inscrição" a "implementar um subsistema para monitoramento e análise de todos os processos", enquanto todos os requisitos devem ser implementados incondicionalmente (como regra, propostas para refinar a redação não são aceitas, você só pode influenciar alguns limites no método de implementação);
- Às vezes, o cliente, sem ter idéia de como resolver o problema, "empurra" esses problemas para o contratante, incluindo requisitos que são, para dizer o mínimo, "esotéricos" (algo como "... o subsistema deve fornecer uma previsão para a taxa de câmbio das principais moedas para curto, médio e longo prazo ... ");
- caso o contrato esteja relacionado ao aprimoramento do sistema existente, o cliente exige a introdução de componentes individuais antes da operação de teste, com a garantia da operação ininterrupta de todo o sistema (pode ser comparado com a conclusão de um motor de carro em movimento)
- o cliente é representado por várias unidades (organizações), cujos requisitos são frequentemente contraditórios;
- o orçamento e os prazos para o projeto permanecem inalterados, apesar da alteração e adição de requisitos;
- os clientes não buscam cooperação com os desenvolvedores (a cooperação é baseada no princípio de "faça primeiro e depois veremos"); os representantes dos clientes evitam a responsabilidade de tomar decisões sobre a especificação de requisitos, o momento da coordenação de questões problemáticas é ignorado; é inútil exigir coordenação antes do início do desenvolvimento, porque o fato de a equipe não cumprir os prazos não diz respeito ao cliente (ou seja, esses são nossos problemas como artistas);
- por um lado, o cliente exige a conformidade exata de todo o pacote de documentação com os requisitos formais do GOST; por outro, o desenvolvimento de instruções adicionais para o uso do produto na solução de problemas específicos.
Como regra, todos esses fatores provocam a indignação da equipe do projeto em relação a "clientes inadequados" e "má gestão do projeto". No entanto, dada a objetividade e repetibilidade das condições acima, as reclamações da equipe do projeto sobre a "complexidade" do cliente do estado são semelhantes às reclamações da equipe do navio sobre o frio e a escuridão da noite polar, depois que a companhia de navegação venceu uma grande licitação para transporte ao longo da
Rota do Mar do Norte .
Além das condições externas, as características comuns são compartilhadas pelas equipes de funcionários envolvidas no projeto de software.
- O núcleo da equipe do projeto pode consistir em 5 a 12 funcionários: gerente de projeto, analistas, testadores, redatores técnicos, programadores. Apesar de alguns funcionários, algumas vezes, desempenharem várias funções, como regra, essas equipes de projeto são caracterizadas por um baixo " fator de barramento ". Isso por si só também impõe restrições ao uso dos métodos Agile (por exemplo, é improvável que seja útil usar o agendamento de pôquer nessas condições).
- A equipe do projeto, juntamente com os processos de desenvolvimento de software, deve fornecer simultaneamente suporte de garantia (correção de erros de software) e suporte estendido (conclusão operacional de módulos de sistema individuais para alterações atuais nos processos de negócios do cliente).
- Como parte do desempenho de tarefas individuais, estão envolvidos funcionários de departamentos adjacentes da empresa, bem como subcontratados (empresas externas impostas pelo cliente), para os quais as tarefas do projeto geralmente são de prioridade secundária.
Vitória da esperança
O segundo casamento é a vitória da esperança sobre a experiência da vida.
Samuel Johnson
Há dois anos, fui convidado como analista líder de um projeto realizado pela
LANIT por ordem do governo. A equipe do projeto foi formada anteriormente, o projeto consistia em um refinamento substancial do sistema automatizado que existe há mais de uma década. Em geral, as condições do projeto foram as descritas acima. Naquela época, a equipe de desenvolvimento não usava nenhum dos sistemas de gerenciamento de projetos existentes em seu trabalho (embora quase todos os funcionários participassem de projetos nos quais esses sistemas eram usados e tinham uma opinião bastante cética sobre a necessidade de automação do gerenciamento). No entanto, a atual situação inicial ofereceu uma oportunidade para testar a automação do gerenciamento de projetos "do zero".
O JIRA foi escolhido como plataforma de automação. Uma combinação dos seguintes fatores contribuiu para essa escolha:
- a capacidade de registrar relacionamentos entre muitas e muitas tarefas;
- flexibilidade de configurações para a versão em caixa;
- salvando o histórico de todas as alterações no projeto;
- arquitetura parcialmente aberta, a possibilidade de aperfeiçoar suas próprias necessidades;
- a capacidade de interagir com sistemas externos que já foram usados pela equipe do projeto (SharePoint, Git, SVN etc.);
- a capacidade de usar em seu servidor (para projetos fechados);
- a presença na unidade de um funcionário com experiência significativa na administração desse sistema e que esteja interessado em unificar sua aplicação.
Historicamente, o JIRA versão 6.4 foi usado para uso no trabalho, no entanto, os elementos individuais das soluções implementadas nesta versão em nosso projeto apareceram parcialmente nas novas versões do JIRA prontas para uso (que indiretamente confirmaram a exatidão das decisões tomadas).
A automação do gerenciamento de projetos buscou inicialmente os seguintes objetivos:
- melhorar a qualidade do sono dos funcionários da equipe do projeto (como você sabe, uma pessoa descansada trabalha com muito mais eficiência);
- garantir uma distribuição transparente da responsabilidade pela implementação das tarefas do projeto;
- forneça "multithreading" da equipe do projeto, ou seja, paralelizar o trabalho sempre que possível;
- fornecer formação automática do estado atual das coisas em relação à implementação de cada um dos requisitos do cliente;
- fornecer monitoramento do estado atual do projeto, permitindo identificar problemas e riscos do projeto nos estágios iniciais;
- formar abordagens unificadas para a contabilidade, métodos para avaliar e comparar o status de vários projetos de desenvolvimento de software (semelhantes aos serviços do Google Analytics ou Yandex.Metrica , que permitem avaliar qualquer site pelos mesmos indicadores);
- aumentar a precisão da estimativa do tempo das tarefas, com base nas estatísticas coletadas.
Para evitar “automação para automação”, as seguintes considerações (limitações) também foram levadas em consideração ao projetar um modelo de contabilidade de dados no JIRA:
A automação do gerenciamento de projetos não deve incomodar a equipe do projeto. Considerando a experiência negativa anterior em automação de gerenciamento de projetos, um dos principais fatores de implementação foi a criação de tais condições que cada funcionário da equipe do projeto percebeu o JIRA não como uma carga extra no barco do projeto, mas como um sistema de navegação coletiva que notificará a equipe em tempo hábil de um perigo iminente e ajudará a atingir a meta projeto da maneira mais curta e segura. Além disso, o uso desse sistema de navegação deve facilitar a vida de todos os membros da equipe, e não apenas o gerenciamento de projetos. Para fazer isso, inicialmente o procedimento para trabalhar com o JIRA foi planejado levando em consideração a minimização da quantidade de dados registrados por programadores, testadores e redatores técnicos. Por outro lado, o objetivo era criar um ambiente de trabalho confortável no JIRA para todos os funcionários do projeto, o que os ajudaria a garantir um planejamento eficaz de seu dia de trabalho.
Garantia de continuidade. Um dos objetivos da automação do gerenciamento de projetos é garantir a continuidade para que qualquer funcionário qualificado possa "assumir" as funções de um membro da equipe aposentado sem um "período de teste" e com uma dor de cabeça mínima, para que "o esquadrão não perceba a perda de um lutador". A esse respeito, lembrei-me de um caso que um dos clientes me contou. Uma vez que ele ficou para o chefe, que, saindo de férias, lhe disse a senha do seu computador com uma réplica: "Bem, tudo está claro lá, você descobrirá se algo acontecer ...". Esse funcionário passou várias noites sem dormir compreendendo o conteúdo de várias pastas com os nomes “xxxxx1”, “xxxxx11” e “xxxxx111” (os nomes das pastas foram alterados por motivos de decência). A prevenção de tais situações requer o registro dos resultados do trabalho de todos os funcionários da equipe do projeto, incluindo o gerente do projeto, no JIRA.
Minimalismo O objetivo da automação do gerenciamento de projetos não era calcular, em um minuto, quanto um funcionário gastava tempo trabalhando na resolução das tarefas atribuídas a ele, mas garantir que as tarefas com uma determinada qualidade fossem resolvidas no tempo necessário. Portanto, ao implantar um projeto no JIRA, foi adotado o princípio de minimizar os dados registrados no sistema. I.e. o conjunto de parâmetros registrados no sistema de controle deveria ter sido minimamente necessário para a tomada de decisões informadas ("A
perfeição é alcançada não quando não há nada a acrescentar, mas quando não há nada a remover "). Entendeu-se que o modelo adotado de automação de gerenciamento de projetos deve funcionar em condições de alta incerteza e inconsistência (por exemplo, é possível saber a data do documento, mas não o número e vice-versa). Ao digitar as informações gravadas, usamos, sempre que possível,
a regra de Miller , que afirma que o número ideal de tipos (estados) deve estar entre "sete mais ou menos dois" (o que simplifica bastante o entendimento do trabalho do sistema pelos funcionários). Assim, por exemplo, ao projetar o ciclo de vida das tarefas (fluxo de trabalho), foi inicialmente assumido que o número de estados deveria obedecer a essa regra.
Consistência. A automação do gerenciamento de projetos deve contribuir para a coerência e coerência das ações de todos os funcionários da equipe do projeto (evitando a situação de "cisne, câncer e lúcio").
Em um dos projetos nos quais participei, uma equipe de analistas desenvolveu um modelo de atividade automatizada na notação
IDEF0 em um mês. Parecia que o próprio uso da metodologia criada pela Força Aérea dos EUA (!) Garantiu o sucesso dessa abordagem. No entanto, quando o chefe do departamento de programação estudou o relatório analítico de várias páginas, sua primeira pergunta foi: “Então, o que exatamente precisa ser feito?”. O modelo gerado acabou sendo inadequado para uso como uma descrição da declaração do problema para programadores. Os representantes do cliente admiraram várias vezes, percorrendo vários esquemas, mas também não encontraram a aplicação desse modelo para otimizar suas atividades. No final, esses esquemas adornavam a descrição dos processos tecnológicos, dando a este documento uma espessura e solidez sem precedentes, mas o efeito positivo da análise foi esgotado. Os resultados do mês de trabalho de vários analistas foram praticamente não reclamados pelo projeto.
Dada essa experiência, na automação do gerenciamento de projetos, deveria criar um único
transportador de tarefas que assegurasse uma conversão coordenada dos requisitos do cliente em um produto final de software da maneira mais curta possível e a um custo mínimo. Ao mesmo tempo, com base no monitoramento dos
parâmetros disponíveis deste transportador, era suposto identificar, medir e desenvolver as propriedades emergentes da equipe do projeto, através das quais era possível julgar o estado do projeto em todas as suas etapas.
Placa Kanban do avesso
Na minha opinião, o sucesso da automação de controle depende, em grande parte, da precisão com que o objeto de controle é modelado em um sistema automatizado.
Como era para automatizar o gerenciamento do processo de criação de software, foi realizada uma análise desse processo. Na minha opinião, o processo de criação de módulos de software separados sempre representa o ciclo de vida em cascata clássico. Primeiro, uma lista de requisitos para o produto criado é exibida. Os requisitos podem vir de diferentes fontes e ter vários graus de detalhes. Alguns dos requisitos estão interconectados, outra parte é relativamente independente. Para requisitos individuais, você pode formular imediatamente uma tarefa de desenvolvimento, enquanto outros requerem esclarecimentos e concretização. I.e.
sempre existem trabalhos relacionados à coleta, classificação e esclarecimento dos requisitos do cliente (embora a redação dos requisitos individuais possa ser ambígua até o final do projeto). Depois que os requisitos são tão específicos quanto possível, como regra, as chamadas definições de tarefas são formadas para grupos de requisitos interconectados, que detalham as especificidades da implementação desses requisitos e são o material de origem para os programadores começarem a trabalhar. Após a programação, os módulos criados são testados de forma autônoma, integrados ao sistema e testados novamente. De acordo com as atualizações de software concluídas, são feitas alterações apropriadas na documentação operacional e de design, após as quais são realizadas várias atividades,visa reconhecer a conclusão realizada pelas aspirações (requisitos) do cliente e a subsequente implementação da funcionalidade desenvolvida em operação comercial.FonteA principal diferença entre a vida real e o belo esquema em cascata é sua aleatoriedade (tudo acontece não em etapas e inconsistentemente). Na realidade, a transição de uma fase de desenvolvimento para outra não ocorre necessariamente somente após a conclusão completa e bem-sucedida da fase anterior. A cachoeira real tem seus próprios remansos de contradições, remansos e águas rasas de indiferença, pântanos de palavreado, corredeiras e redemoinhos de ambiguidade, corredeiras e pedras escorregadias de imaginação desenfreada, e frequentemente fontes e até gêiseres de novos requisitos. Não é possível refazer esse elemento dentro da estrutura do projeto, assim como é impossível para a equipe do navio refazer o rio ao longo do qual é necessário garantir a entrega da carga do cliente.Para transparência da distribuição de responsabilidades na automação do gerenciamento de projetos, foi implementado o princípio "1 tarefa - 1 executor". I.e.
obviamente, o processo de conclusão de uma tarefa não implicava sua transferência para outros artistas. Esse princípio tornou possível aplicar o mesmo processo de negócios a todos os tipos de tarefas, uma vez que o status do trabalho foi determinado principalmente do ponto de vista do executor dessa tarefa. O fluxo de trabalho padrão do JIRA foi ligeiramente modificado. A principal mudança foi a substituição do status "redescoberto" pelo status "pendente", ou seja, indica quando o trabalho em uma tarefa é suspenso por qualquer motivo. Para registrar tarefas redescobertas, o campo do usuário "Contador de redescoberta" foi usado. Ao mesmo tempo, os tipos de motivos para a transferência de tarefas estavam pendentes, aguardando uma solução:- coordenação com o cliente;
- solicitação de informações adicionais do cliente;
- aguardando a solução de tarefas / subtarefas relacionadas;
- é necessário esclarecer a declaração do problema.
Deve-se notar que a introdução do status “em espera” realmente implementou o “ botão de parada do transportador ” para os funcionários da equipe do projeto , o que, por sua vez, garantiu a identificação coletiva dos problemas nos estágios iniciais do projeto.
Como resultado da análise, foi implementado o seguinte modelo para registrar informações do projeto no JIRA. A abordagem padrão de compartilhamento de tarefas que o JIRA representou não foi usada no projeto. Seis tipos de tarefas foram criados, os quais, em essência, correspondiam aos principais estágios do desenvolvimento de software:- “Requisito” - tipo de tarefa para registrar os requisitos do cliente (semelhante em novas versões do JIRA - epic);
- «» – , ( ) ( ) ( JIRA – story);
- «» – ;
- «» – , ;
- «» – , ;
- "Implementação" é o tipo de tarefa para registrar os resultados do trabalho destinado a introduzir o software desenvolvido nas atividades do cliente (realização de testes, demonstrações, liberação de um release / patch / datafix, implantação de software nos servidores do cliente, treinamento de usuários etc.).
As subtarefas foram usadas para resolver problemas específicos (cujo tempo não excede duas horas) durante a execução da tarefa principal (por exemplo, para coordenar uma decisão de design com um programador ou gerente de projeto, realizar revisões de código, preparar análises de dados, etc.).De acordo com as regras estabelecidas no projeto, o registro de um requisito é uma base obrigatória para o planejamento de outras tarefas. Após o registro do requisito e seu esclarecimento com o cliente (se necessário), outros tipos de tarefas são formados, visando a implementá-lo. Em outras palavras, dentro da estrutura do modelo adotado, outras tarefas devem sempre estar associadas ao requisito no interesse pelo qual elas são cumpridas (usando o tipo de conexão “razão” -> “ação”). No interesse de implementar um requisito, várias tarefas de desenvolvimento podem ser criadas, por outro lado, uma tarefa (para análise, desenvolvimento, teste, documentação, implementação) pode ser criada no interesse de vários requisitos (em contraste com a abordagem padrão do JIRA, quando é assumidoque uma tarefa só pode ser associada a uma tarefa do tipo épico). Dentro da estrutura do modelo proposto, também é possível relacionar outras tarefas dependentes. Por um lado, essa abordagem garantiu a consistência das decisões tomadas, por outro, fornecia a possibilidade de uma reflexão bastante precisa do estado real das coisas no projeto. Nesse caso, são possíveis várias opções para organizar o trabalho, para entender a confusão que parece muito difícil.
- azul - a tarefa está incluída no plano de trabalho;
- azul - a tarefa está em andamento;
- rosa - a tarefa não tem executor;
- amarelo - a tarefa está pendente, requer uma solução;
- cinza - a tarefa está encerrada (você pode esquecê-la);
- laranja - os prazos para concluir a tarefa
O aparecimento de inscrições e marcas vermelhas no cartão de tarefas sinaliza a necessidade de ação imediata em relação à tarefa (por exemplo, a inscrição é exibida em vermelho se o prazo não tiver sido definido).Além das cores, à medida que o projeto se desenvolve, os cartões de tarefas no painel são cercados por tags adicionais que permitem avaliar rapidamente o status do trabalho no projeto.Etiquetas de prioridade:
- Normal;
- importante;
- crítico;
- bloqueio.Etiquetas sobre a estrutura de requisitos:
- desenvolvimento (requisitos dentro da estrutura de projetos que visam uma revisão substancial dos sistemas existentes);
- suporte estendido (requisitos para a conclusão operacional de módulos individuais do sistema de acordo com as mudanças atuais nos processos de negócios do cliente);
- suporte de garantia (erros de software detectados);
- atividades não relacionadas ao projeto (requisitos do gerente de projeto relacionados às atividades pré-projeto, refatoração , pré-venda , desenvolvimento de novas tecnologias, treinamento de pessoal etc.).Etiquetas do motivo da expectativa:
- solicitar informações adicionais ao cliente;
- coordenação com o cliente;
- aguardar a solução de tarefas / subtarefas relacionadas;
- é necessária uma clarificação da formulação.Tags especiais:
- o banco de dados foi finalizado na tarefa;
- o número de requisitos relacionados à tarefa (quanto mais requisitos relacionados, mais importante é a tarefa);
- o número de subtarefas não resolvidas;
- a tarefa é redescoberta.De fato, esse painel se tornou a principal ferramenta para receber diariamente uma resposta para a questão do gerenciamento de projetos: “O que é mais importante hoje?”, O que, por sua vez, nos permitiu responder em tempo hábil aos problemas. Da perspectiva do modelo proposto, para evitar problemas no projeto, é necessário garantir uma redução diária na quantidade de vermelho, laranja e amarelo no painel proposto. Por outro lado, um motivo de preocupação também foi a falta de tarefas relacionadas ao requisito (ou seja, a situação em que o requisito é planejado e não há trabalho para implementá-lo).O uso de filtros para o painel criado tornou possível no complexo refletir o estado das coisas de acordo com a lista selecionada de requisitos. Com sua ajuda, foi possível coordenar rapidamente as ações de toda a equipe do projeto, concentrando esforços nas áreas mais problemáticas, sem perder uma imagem holística do projeto.Cachoeira não pode ser ágil
No interesse de registrar os resultados do trabalho em todos os tipos de tarefas, dois repositórios foram implantados (para documentação do projeto e código do software). A adição (alteração) de materiais nesses repositórios foi refletida automaticamente nas tarefas relacionadas do JIRA e foi o principal tipo de relatório pelos artistas.A organização do trabalho usando a abordagem proposta para registrar tarefas no JIRA foi reduzida para o esquema a seguir.- JIRA ( ) . (, ) . (/), . , ( , ), , ( ) . ( ) . .
- , . , , , . () .
- , , . , , ( ), () , , , ( ).
- ( ) , , . . , . «» , ( ).
- Idealmente, as tarefas de teste devem ser formadas antes de registrar as tarefas de desenvolvimento (que especificam os objetivos dos programadores). Durante o teste, o testador responsável não apenas mantém um registro dos erros detectados, mas também corrige as imprecisões detectadas na tarefa de teste e no manual do usuário.
- De acordo com os requisitos para os quais uma lista completa de trabalho foi planejada, as tarefas de implementação são formadas (durante o registro, cuja prioridade e prazos para a implementação de requisitos são novamente especificados no JIRA).
- Após a entrega ao cliente, a solicitação pode ser transferida para o status “fechado” com a indicação obrigatória dos detalhes do documento de aceitação.
Note-se que a formação de tarefas de todos os tipos para a implementação de um único requisito não é um pré-requisito para o planejamento bem-sucedido. Por exemplo, um requisito simples como "corrigir um erro no nome de um campo" pode ser atribuído diretamente a um programador. Ao mesmo tempo, durante a implementação do projeto, observou-se que a maior parte dos comentários durante testes preliminares e operações de teste explicavam requisitos para os quais não foram tomadas decisões de design.
Dentro da estrutura da abordagem proposta, o planejamento do trabalho usando
o método Rolling Wave Planning se provou bem. Ao mesmo tempo, em parte devido ao painel descrito acima, foi possível evitar a fragmentação e inconsistência das obras planejadas. Nos estágios iniciais do registro, a seleção de acordo com os requisitos lembrava um
guarda-chuva vermelho , quando para a maioria dos requisitos as datas de disponibilidade e os executivos responsáveis não eram determinados e o trabalho era planejado apenas para uma pequena parte deles. No entanto, o painel de requisitos gradualmente se transformou em um tapete verde-azulado. As manchas vermelhas e alaranjadas que aparecem neste tapete nos forçaram a realizar ajustes diários nas tarefas pretendidas, o que ajudou a reduzir os riscos do projeto.
O modelo de organização de dados proposto mostrou boa escalabilidade. Inicialmente, apenas três funcionários da equipe do projeto (um analista e dois programadores) usaram o JIRA em seus trabalhos, enquanto os requisitos para subsistemas individuais foram registrados. No entanto, ao final do projeto, 100% dos requisitos de desenvolvimento e suporte estendido foram registrados e monitorados no JIRA com a participação de todos os funcionários da equipe do projeto.
Apesar de a idéia de automação do gerenciamento de projetos se basear em um modelo de desenvolvimento em cascata (cascata), constatou-se que, dentro da estrutura da abordagem proposta, se desejado, os elementos ágeis podem ser usados sem dor. E quem, em geral, disse que a cachoeira não é flexível? Por exemplo, para aplicar o
Scrum , dentro da estrutura do modelo proposto, basta garantir a regularidade dos eventos (tarefas) para a implementação do software e, portanto, todo o trabalho associado a esse evento será "forçado" a obedecer às regras de sprint definidas dessa maneira.
Além disso, o método proposto para registrar tarefas não limita o gerente de projetos na aplicação da abordagem Kanban e no uso de toda a variedade de
painéis do
Agile que o JIRA oferece "pronto para uso".
Para ser continuado
Qual é o resultado? O software desenvolvido foi colocado em operação comercial. Durante os testes preliminares, operação de teste e testes de aceitação, o cliente registrou muitos comentários sobre o produto de software implementado. No entanto, posteriormente, com base nos materiais que esclarecem os requisitos que foram armazenados no JIRA, o cliente foi forçado a reconhecer 25% dos comentários como novos requisitos que foram além do escopo do projeto (a complexidade planejada de atender a esses requisitos era proporcional à tarefa técnica concluída). Os problemas associados à implementação do contrato para ordens estaduais não desapareceram; no entanto, o monitoramento da conformidade com os requisitos usando o JIRA tornou possível identificar os riscos de interrupção no estágio de iniciação e responder rapidamente a eles. Isso, por sua vez, garantiu a dinâmica positiva do projeto em todas as suas etapas, apesar das peculiaridades do desenvolvimento nacional de software. Observou-se que, se os requisitos do cliente eram registrados no JIRA e as tarefas de análise, desenvolvimento e teste eram formadas, haveria muito menos discordâncias e disputas em relação a esses requisitos.
No estágio atual (estágio de manutenção), todos os requisitos são refletidos no JIRA. Todos os funcionários da equipe do projeto, de uma maneira ou de outra, usam o JIRA em seu trabalho. O custo dos programadores para registrar os resultados de seu trabalho no JIRA leva menos de 1% do seu tempo de trabalho. Para os analistas, ao contrário, o JIRA se tornou uma das principais ferramentas de trabalho. Encontrar um conjunto completo de informações para qualquer um dos requisitos do cliente é inferior a um minuto. Os documentos de relatório com base nos resultados do trabalho realizado são gerados automaticamente com base nos dados contidos no JIRA. Além disso, com base nesses dados, a documentação que acompanha as liberações é formada (uma lista de alterações e um programa de teste de liberação).
Dois anos de experiência na aplicação do JIRA sob as novas regras confirmaram antigas verdades:
- O JIRA não substitui o gerenciamento de projetos, mas ajuda a navegar rapidamente pelo fluxo de diversas tarefas;
- O JIRA ajudará você a focar seu projeto no lugar certo, na hora certa, mas não fará isso por você;
- O JIRA não resolverá os problemas do projeto para você, mas ajudará a identificá-los já nos estágios iniciais (ao mesmo tempo, identificará os problemas que você esperava ocultar);
- como qualquer sistema automatizado, o JIRA o ajudará a implementar rapidamente qualquer uma de suas decisões, independentemente de ser boa ou ruim;
- O JIRA não substitui a comunicação dos funcionários da equipe do projeto, mas ajudará a resolver disputas sem dor;
- O JIRA não salvará um funcionário da demissão, mas ajudará outro, que substituiu o aposentado, a entrar rapidamente no conhecimento;
- O JIRA ajudará a gerar documentos de relatório do projeto, mas apenas com base nas informações que você forneceu o registro.
E o mais importante - o JIRA não decidirá por você se você usará sua ajuda ou não.
Empregos LANIT para interessados