Talvez, depois de ler este artigo, você se pegue pensando que estou escrevendo sobre coisas comuns que todos sabem. Mas em 10 anos mudei apenas 3 empresas de TI, em duas das quais essas práticas "banais" não foram utilizadas na íntegra, o processo de desenvolvimento de software sofreu muito com isso. Além da minha experiência pessoal, me inspirei para escrever o artigo com as histórias de analistas que conheço que atuam na área de TI e quase todos se deparam com problemas organizacionais e de comunicação que precisam e podem ser resolvidos.
Nos últimos 3 anos tenho trabalhado como analista de sistemas no grupo de empresas InfoWatch e neste artigo quero compartilhar com vocês as práticas de trabalho com requisitos que utilizamos. A empresa desenvolve produtos corporativos para mitigar os riscos de segurança da informação, proteger e analisar dados corporativos. Para tais produtos, altos requisitos são apresentados em relação à sua confiabilidade, desempenho, tolerância a falhas, bem como requisitos para certificação. Pelas peculiaridades do mercado de segurança da informação, nossas soluções não são baseadas em nuvem, mas são instaladas no local do cliente. Portanto, trabalhamos em um modo de liberação grande várias vezes por ano. Para atingir a meta atribuída e reduzir o tempo de lançamento, trabalhamos de acordo com os princípios estabelecidos na metodologia ágil.Para iniciar o desenvolvimento, não preparamos requisitos de sistema absolutamente detalhados, mas começamos com uma descrição de alto nível dos aspectos mais importantes da nova funcionalidade. Ou seja, tomamos decisões que afetam acima de tudo o volume e a complexidade das melhorias e fornecemos à equipe de desenvolvimento as informações necessárias para começar a trabalhar no design da arquitetura e escrever o código (para pequenos recursos). Em seguida, no curso do desenvolvimento, detalhamos gradualmente os requisitos e os trazemos a um nível de detalhe suficiente para escrever casos de teste detalhados. Essa abordagem permite que você não perca muito tempo para iniciar o trabalho e reduz os riscos de que os requisitos tenham de ser significativamente retrabalhados se quaisquer novas limitações técnicas vierem à tona.que, acima de tudo, afetam o volume e a complexidade das melhorias e fornecem à equipe de desenvolvimento as informações necessárias para começar a trabalhar no design e na codificação da arquitetura (para pequenos recursos). Em seguida, no curso do desenvolvimento, detalhamos gradualmente os requisitos e os trazemos a um nível de detalhe suficiente para escrever casos de teste detalhados. Essa abordagem permite que você não perca muito tempo para iniciar o trabalho e reduz os riscos de que os requisitos tenham de ser significativamente retrabalhados se quaisquer novas limitações técnicas vierem à tona.que, acima de tudo, afetam o volume e a complexidade das melhorias e fornecem à equipe de desenvolvimento as informações necessárias para começar a trabalhar no design e na codificação da arquitetura (para pequenos recursos). Em seguida, no curso do desenvolvimento, detalhamos gradualmente os requisitos e os trazemos a um nível de detalhe suficiente para escrever casos de teste detalhados. Essa abordagem permite que você não perca muito tempo para iniciar o trabalho e reduz os riscos de que os requisitos tenham de ser significativamente retrabalhados se quaisquer novas limitações técnicas vierem à tona.suficiente para escrever casos de teste detalhados. Essa abordagem permite que você não perca muito tempo para iniciar o trabalho e reduz os riscos de que os requisitos tenham de ser significativamente retrabalhados se quaisquer novas limitações técnicas vierem à tona.suficiente para escrever casos de teste detalhados. Essa abordagem permite que você não perca muito tempo para iniciar o trabalho e reduz os riscos de que os requisitos tenham de ser significativamente retrabalhados se quaisquer novas limitações técnicas vierem à tona.
Se o seu processo de desenvolvimento é semelhante ao nosso, ou você deseja passar para esse processo combinado, provavelmente as práticas descritas abaixo são adequadas para você. Mas mesmo que você tenha um processo diferente, é provável que as práticas apresentadas sejam úteis para você. De qualquer forma, sugiro que você se familiarize com eles, principalmente se você trabalha como analista de sistemas em uma empresa de TI.
Requisitos para o produto que está sendo desenvolvido é a principal área de responsabilidade de um analista de sistemas. As práticas descritas abaixo visam simplificar o gerenciamento de requisitos e, como resultado, simplificar o processo de desenvolvimento de produto:
- documentação e controle de versão;
- notificação de mudanças;
- Reveja;
- comícios / reuniões / status;
- discussão / solução de questões abertas;
- registro de discussões;
- validação de nova funcionalidade;
- apresentação de novas funcionalidades.
Requisitos de documentação e controle de versão
É conveniente quando a descrição do produto na forma de requisitos funcionais e não funcionais é fixada em um documento, os requisitos são divididos por áreas funcionais, interligados por agrupamento, transições por meio de links, etc. Quando quaisquer alterações na estrutura da descrição de recursos ou como resultado da correção de defeitos são refletidas na versão correspondente dos requisitos.
A versão dos requisitos é a mesma do produto em si, o que permite que você veja o aumento da funcionalidade a cada nova versão. E também tenha acesso rápido a informações sobre como essa funcionalidade funcionava nas versões anteriores e por quais motivos foi alterada.
Em algumas empresas, é necessário gastar muito tempo para obter essas informações, pois é necessário revisar todas as tarefas que estão associadas a uma determinada funcionalidade, aprofundar-se em sua descrição e ver os comentários. A propósito, uma maneira mais rápida de obter as informações de que você precisa é pedir ao desenvolvedor para olhar as mudanças no código, mas neste caso levará não apenas o seu tempo, mas também o tempo do desenvolvedor, o que custará seu empregador mais. Descrever os requisitos em um lugar permite que você não apenas encontre as informações de interesse, mas também compreenda imediatamente o contexto.
Usamos o Confluence, que é uma ferramenta útil que você pode ajustar um pouco. Um colega meu fala sobre nossa experiência com o Confluence em detalhes em seu artigo “ Como usamos o Confluence para desenvolver os requisitos do produto . " Curiosamente, muitas empresas de TI possuem essa ferramenta, mas nem todos a usam para documentar os requisitos do produto.
Notificação de mudanças nos requisitos
É uma boa prática notificar todas as partes interessadas sobre as mudanças nos requisitos, o que também permite monitorar quando e por que motivo os requisitos foram alterados. Se acima eu disse que é importante refletir nos requisitos todas as mudanças em decorrência da correção de defeitos, então estamos falando em notificar a equipe sobre essas mudanças.
É importante entender que requisitos são os dados que equipes de desenvolvimento, equipes de teste e redatores técnicos usam para seu trabalho e que quaisquer mudanças nos requisitos devem ser suportadas na implementação, casos de teste e documentação.
A falha em notificar as equipes envolvidas provavelmente enfrentará os seguintes problemas:
- a implementação pode não atender aos requisitos;
- ;
- .
Até recentemente, nossa equipe de analistas notificava todos os interessados sobre as mudanças nos requisitos da seguinte forma: após fazerem as mudanças nos requisitos, eles deixavam um comentário sobre o problema, enviavam uma carta contendo um link para o problema, um link para os requisitos e uma breve descrição das mudanças. No final do ano passado, automatizamos esse processo: finalizamos o rastreador de problemas (usamos JIRA) e agora, após fazer alterações nos requisitos, na tarefa em que essas alterações foram feitas, clicamos no botão "Notificar sobre alterações Botão ", selecione as equipes interessadas e faça uma breve descrição das alterações:
Captura de tela # 1 A
carta que é gerada automaticamente ao clicar no botão" Enviar Alerta "tem a seguinte apresentação e contém todas as informações necessárias:
Captura de tela 2
Além da carta, um comentário com informações semelhantes permanece no problema.
Revisão de novos requisitos
É obrigatório revisar os novos requisitos pelos líderes de todas as equipes envolvidas no desenvolvimento do recurso. Não estamos falando sobre mudanças em defeitos, mas sobre funcionalidades completamente novas, cuja descrição você está fazendo. Obter feedback é extremamente útil, pois podem surgir as perguntas certas que ajudarão a revelar em detalhes as possibilidades da nova funcionalidade. Quando você desenvolve um pensamento em uma direção por muito tempo, identifica uma necessidade, problemas, desenvolve diferentes conceitos e descreve uma solução dentro da estrutura do produto, o olho pode ficar embaçado e pode parecer que há coisas óbvias que fazem não precisa ser fixado nos requisitos. A revisão ajuda, inclusive por meio de perguntas de especialistas que se aprofundam no tema por meio das informações que recebem nos requisitos, a entender quais pontos precisam ser esclarecidos ou divulgados.A revisão também ajuda a aprimorar a clareza do texto, a fazer alterações para que sejam interpretadas de forma inequívoca por todos.
Para fazer isso, também aprimoramos o rastreador de problemas, adicionando um tipo separado de tarefa "Revisão", que é iniciada pelo analista responsável para cada recurso em todos os líderes de equipe. Gestores de forma independente ou delegados a seus subordinados fazem a revisão dos requisitos, fazem perguntas ou esclarecimentos por meio de comentários e concordam com as alterações feitas.
Captura de tela # 3
Comícios / reuniões / status
As reuniões diárias da equipe que trabalha no recurso é um ótimo evento para equipes pequenas, desde que utilizem sprints frequentes. Caso contrário, as reuniões diárias ocuparão todo o tempo da equipa e não terão qualquer utilidade. No entanto, você não deve abandonar completamente as reuniões, basta determinar corretamente a frequência de sua realização. E então você pode manter o controle, entender se a equipe está caminhando na direção certa na implementação do conceito concebido, bem como identificar nos estágios iniciais problemas que podem ser resolvidos ou limitações que precisam ser acordadas.
Naturalmente, ao desenvolver requisitos, você precisa se comunicar com a equipe, pois você pode aprender muitas informações úteis. Momentos importantes que acontecem em algum lugar da “caixa preta” podem influenciar muito o conceito de novos recursos do produto, a comunicação com os colegas ajuda a chamar a atenção para momentos que são interessantes para suas funções. Por exemplo, a comunicação com os testadores torna possível levar em consideração cenários alternativos que estão planejados para serem testados nos requisitos, e é importante que eles sejam inicialmente estabelecidos e levados em consideração no desenvolvimento, e não descobertos durante a fase de teste .
Discussão / solução de questões abertas
Gostaria de destacar a comunicação por voz como um item à parte, pois considero importante a comunicação ao vivo, pois nas novas realidades não há como discutir os assuntos cara a cara.
Mensageiros são usados com mais frequência, eles são adequados para correspondência pessoal, na qual você pode usar sorrisos, gifs, etc. para expressar suas emoções. Mas para atividades de trabalho isso não é totalmente aceitável e, como resultado, permanece um texto seco e sem rosto isso é difícil para o destinatário interpretar, porque a percepção desse texto depende do humor da pessoa, de sua atitude pessoal para com você, do envolvimento no diálogo e de outros fatores que não dependem de você.
Portanto, prefiro resolver as questões na discussão "pela voz", ou seja, ligar e discutir, chegar a um acordo. A ligação irá ajudá-lo a descobrir se você entendeu o contexto corretamente, imediatamente faça perguntas e obtenha respostas. A voz transmite entonação, permite colocar os acentos certos, prestar atenção ao que é realmente importante. Além disso, a comunicação por voz economiza tempo para todos os participantes e permite que você se concentre em um tópico específico, uma vez que a comunicação por voz (e não por chat) requer participação e compreensão para resolver o problema.
Registro de discussão
É absolutamente habitual e obrigatório que todos registrem as discussões das decisões com o cliente na forma de um TOR, que é repetidamente deduzido "no ponto" e acordado por todas as partes interessadas. Quero chamar a atenção para o facto de que para além da documentação oficial no desenvolvimento de software, a fixação escrita de acordos pode ser útil não só no âmbito da comunicação "cliente - programador", mas também dentro da empresa / equipa.
Praticamos a comunicação da equipe de registro ao discutir os conceitos da solução e a funcionalidade do sistema. Pois ao trabalhar em um recurso podem surgir várias soluções, a partir das quais é necessário escolher uma, naturalmente surgem questões para a equipe, que, de fato, são discutidas em reuniões.
Como regra, mantemos o protocolo no formato de perguntas e respostas. O protocolo também justifica porque foi escolhida tal solução, fica registrado quem tomou essas decisões e quem as coordenou. Mas é importante entender que este é o nosso documento interno utilizado em nosso trabalho, que não é regulamentado por nada nem por ninguém. A ata registra uma discussão sobre um determinado assunto e em uma data determinada, ou seja, necessária para entender por que determinadas decisões foram tomadas ou rejeitadas, quais questões em geral surgiram e quais delas estão encerradas e quais requerem pesquisa para obter uma resposta. ... Isso é importante porque no modo multitarefa é difícil manter todas essas informações em sua cabeça, além disso, todos os membros da equipe interessados devem estar cientes e ter acesso a essas informações. Além disso, depois de muito tempo,você pode reler este protocolo e encontrar respostas para as perguntas nele, ou talvez você tenha novas idéias com base nas respostas. Ou, mais uma vez, você se certificará da correção da solução escolhida.
Validação significa verificar a funcionalidade implementada para conformidade com os requisitos de negócios. Antes do início do teste funcional, o analista responsável pelo recurso realiza a validação: ele verifica se o cenário principal foi implementado e se o comportamento do sistema atende às expectativas. Esta é uma prática importante que deve ser utilizada logo antes da transferência de funcionalidade para teste, pois se o script principal não for executado, não há sentido em verificar outros casos. Para realizar a validação, um cenário de aceitação é escrito, contendo as etapas que devem ser executadas e a resposta esperada do sistema para resolver o problema de negócio para o qual a funcionalidade foi desenvolvida. No âmbito da validação, é possível identificar, em primeiro lugar, a falha do cenário principal, os inconvenientes da interface do utilizador, bem como os graves defeitos funcionais.Se o cenário principal for executado, o recurso é considerado validado e pode ser enviado para teste. O teste já é mais detalhado, de acordo com os casos de teste, verifica a funcionalidade implementada.
Apresentação de nova funcionalidade
Outra prática legal, na minha opinião, é a apresentação da funcionalidade antes de escrever casos de teste ou emitir um recurso para teste. A apresentação é realizada para performers que não estão imersos no contexto como seus líderes estão, pois não participaram das etapas de elaboração da solução. Via de regra, este é um breve conto sobre quais cenários básicos e alternativos para a solução de problemas são implementados, quais configurações no produto devem ser feitas, quais são as características tecnológicas desta solução e quais são suas limitações. Como resultado, um entendimento geral das novas funções do produto é formado e uma série de questões que podem surgir para uma pessoa que não está imersa no contexto são removidas.
Após testar a funcionalidade, antes do lançamento oficial do release técnico, realizamos uma apresentação e demonstração da nova funcionalidade para os funcionários dos departamentos que estão implementando o produto no cliente. Isso torna possível obter feedback, designar recursos e limitações preliminares, anunciar o desenvolvimento futuro da funcionalidade. É importante que todos tenham um entendimento comum da nova funcionalidade e não tenham expectativas falsas.
Acima, descrevi uma pequena lista de práticas que meus colegas e eu usamos em nosso trabalho. Eu os considero úteis, então eu os compartilho e gostaria de recomendar que você construa um processo para trabalhar com requisitos usando essas práticas. Nos próximos artigos, planejamos falar sobre a parte substantiva do trabalho com requisitos - mais detalhadamente sobre quais práticas usamos para identificar as necessidades / problemas dos clientes e formular soluções que irão atendê-los totalmente.
Se você tiver dúvidas ou quiser compartilhar sua experiência, por favor, deixe seus comentários.
Autor: Venera Abbyasova AbbyasovaVenera
* Todas as fotos do artigo foram tiradas em acesso aberto na Internet.