Peut-être qu'après avoir lu cet article, vous vous surprendrez à penser que j'écris sur des choses banales que tout le monde connaît. Mais en 10 ans, je n'ai changé que 3 sociétés informatiques, dans deux desquelles ces pratiques «banales» n'étaient pas pleinement utilisées, le processus de développement logiciel en a grandement souffert. En plus de mon expérience personnelle, j'ai été inspiré pour écrire l'article par les histoires d'analystes que je connais qui travaillent dans le domaine informatique et presque tout le monde est confronté à des problèmes d'organisation et de communication qui doivent et peuvent être résolus.
Depuis 3 ans, je travaille en tant qu'analyste système dans le groupe d'entreprises InfoWatch et dans cet article, je souhaite partager avec vous les pratiques de travail avec les exigences que nous utilisons. La société développe des produits d'entreprise pour atténuer les risques liés à la sécurité des informations, protéger et analyser les données d'entreprise. Pour ces produits, des exigences élevées sont mises en avant en ce qui concerne leur fiabilité, leurs performances, leur tolérance aux pannes, ainsi que les exigences de certification. En raison des particularités du marché de la sécurité de l'information, nos solutions ne sont pas basées sur le cloud, mais sont installées sur site chez le client. Par conséquent, nous travaillons dans un mode de grande diffusion plusieurs fois par an. Pour atteindre l'objectif assigné et raccourcir le temps de sortie, nous travaillons selon les principes énoncés dans la méthodologie Agile.Pour commencer le développement, nous ne préparons pas de configuration système absolument détaillée, mais commençons par une description de haut niveau des aspects les plus importants de la nouvelle fonctionnalité. Autrement dit, nous prenons des décisions qui affectent surtout le volume et la complexité des améliorations et fournissons à l'équipe de développement les informations nécessaires pour commencer à travailler sur la conception de l'architecture et à écrire du code (pour les petites fonctionnalités). Puis, au cours du développement, nous détaillons progressivement les exigences et les amenons à un niveau de détail suffisant pour rédiger des cas de test détaillés. Cette approche vous permet de ne pas passer beaucoup de temps pour commencer le travail et de réduire les risques que les exigences devront être considérablement retravaillées si de nouvelles limitations techniques se manifestent.qui affectent surtout le volume et la complexité des améliorations et fournissent à l'équipe de développement les informations nécessaires pour commencer à travailler sur la conception de l'architecture et le codage (pour les petites fonctionnalités). Puis, au cours du développement, nous détaillons progressivement les exigences et les amenons à un niveau de détail suffisant pour rédiger des cas de test détaillés. Cette approche vous permet de ne pas passer beaucoup de temps pour commencer le travail et de réduire les risques que les exigences devront être considérablement retravaillées si de nouvelles limitations techniques se manifestent.qui affectent surtout le volume et la complexité des améliorations et fournissent à l'équipe de développement les informations nécessaires pour commencer à travailler sur la conception de l'architecture et le codage (pour les petites fonctionnalités). Puis, au cours du développement, nous détaillons progressivement les exigences et les amenons à un niveau de détail suffisant pour rédiger des cas de test détaillés. Cette approche vous permet de ne pas passer beaucoup de temps pour commencer le travail et de réduire les risques que les exigences devront être considérablement retravaillées si de nouvelles limitations techniques se manifestent.suffisant pour écrire des cas de test détaillés. Cette approche vous permet de ne pas passer beaucoup de temps pour commencer le travail et de réduire les risques que les exigences devront être considérablement retravaillées si de nouvelles limitations techniques se manifestent.suffisant pour écrire des cas de test détaillés. Cette approche vous permet de ne pas passer beaucoup de temps pour commencer le travail et de réduire les risques que les exigences devront être considérablement retravaillées si de nouvelles limitations techniques se manifestent.
Si votre processus de développement est similaire au nôtre ou si vous souhaitez passer à ce processus combiné, il est fort probable que les pratiques décrites ci-dessous vous conviennent. Mais même si vous avez un processus différent, il y a de fortes chances que les pratiques présentées vous soient utiles. Dans tous les cas, je vous suggère de vous familiariser avec eux, surtout si vous travaillez en tant qu'analyste système dans une entreprise informatique.
Les exigences relatives au produit en cours de développement constituent le principal domaine de responsabilité d'un analyste de systèmes. Les pratiques décrites ci-dessous visent à simplifier la gestion des exigences et, par conséquent, à simplifier le processus de développement de produits:
- documentation et gestion des versions;
- notification des changements;
- la revue;
- rassemblements / réunions / statuts;
- discussion / solution des questions ouvertes;
- enregistrement des discussions;
- validation de nouvelles fonctionnalités;
- présentation de nouvelles fonctionnalités.
Exigences en matière de documentation et de versionnage
C'est pratique lorsque la description du produit sous forme d'exigences fonctionnelles et non fonctionnelles est fixée dans un seul document, les exigences sont décomposées par domaines fonctionnels, interconnectées par regroupement, transitions via des liens, etc. Lorsque des modifications dans le cadre de la description des fonctionnalités ou à la suite de la correction de défauts sont reflétées dans la version correspondante des exigences.
Le versionnage des exigences est le même que pour le produit lui-même, ce qui vous permet de voir l'augmentation des fonctionnalités à chaque nouvelle version. Et obtenez également un accès rapide aux informations sur le fonctionnement de cette fonctionnalité dans les versions précédentes et les raisons pour lesquelles elle a été modifiée.
Dans certaines entreprises, il est nécessaire de passer beaucoup de temps pour obtenir de telles informations, car il est nécessaire de passer en revue toutes les tâches associées à une fonctionnalité particulière, de se plonger dans leur description et d'afficher les commentaires. À propos, un moyen plus rapide d'obtenir les informations dont vous avez besoin est de demander au développeur d'examiner les modifications du code, mais dans ce cas, cela prendra non seulement votre temps, mais aussi celui du développeur, ce qui coûtera à votre employeur. Suite. Décrire les exigences en un seul endroit vous permet non seulement de trouver les informations qui vous intéressent, mais aussi de comprendre immédiatement le contexte.
Nous utilisons Confluence, un outil pratique que vous pouvez modifier un peu vous-même. Un de mes collègues parle en détail de notre expérience avec Confluence dans son article " Comment nous utilisons Confluence pour développer les exigences des produits . " Il est intéressant de noter que de nombreuses sociétés informatiques disposent de cet outil, mais tout le monde ne l'utilise pas pour documenter les exigences des produits.
Notification des changements d'exigences
Il est recommandé d'informer toutes les parties prenantes des modifications apportées aux exigences, ce qui vous permet également de surveiller quand et pour quelle raison les exigences ont été modifiées. Si ci-dessus j'ai dit qu'il est important de refléter dans les exigences tous les changements résultant de la correction des défauts, alors nous parlons ici de notifier l'équipe de ces changements.
Il est important de comprendre que les exigences sont les données que les équipes de développement, les équipes de test et les rédacteurs techniques utilisent pour leur travail, et que toute modification des exigences doit être prise en charge dans la mise en œuvre, les cas de test et la documentation.
Le fait de ne pas informer les équipes impliquées sera probablement confronté aux problèmes suivants:
- la mise en œuvre peut ne pas répondre aux exigences;
- ;
- .
Jusqu'à récemment, notre équipe d'analystes informait toutes les personnes intéressées des modifications des exigences de la manière suivante: après avoir apporté des modifications aux exigences, elles laissaient un commentaire sur le problème, envoyaient une lettre contenant un lien vers le problème, un lien vers les exigences et une brève description des changements. À la fin de l'année dernière, nous avons automatisé ce processus: nous avons finalisé le suivi des problèmes (nous utilisons JIRA) et maintenant, après avoir apporté des modifications aux exigences, dans la tâche dans laquelle ces modifications ont été apportées, nous cliquons sur le bouton "Notifier les modifications ", sélectionnez les équipes intéressées et faites une brève Description des modifications:
Capture d'écran # 1 La
lettre qui est automatiquement générée après avoir cliqué sur le bouton" Envoyer une alerte "a la présentation suivante et contient toutes les informations nécessaires:
Capture d'écran 2
En plus de la lettre, un commentaire avec des informations similaires reste dans le problème.
Examen des nouvelles exigences
Il est obligatoire de passer en revue les nouvelles exigences par les responsables de toutes les équipes impliquées dans le développement de la fonctionnalité. Nous ne parlons pas de changements dans les défauts, mais de fonctionnalités complètement nouvelles, dont vous faites la description. Obtenir des commentaires est extrêmement utile, car les bonnes questions peuvent se poser qui aideront à révéler en détail les possibilités de la nouvelle fonctionnalité. Lorsque vous développez une pensée dans une direction pendant une longue période, identifiez un besoin, des problèmes, développez différents concepts et décrivez une solution dans le cadre du produit, l'œil peut devenir flou, et il peut sembler qu'il y a des choses évidentes qui font. ne doit pas être fixé dans les exigences. L'examen aide, y compris par le biais de questions de spécialistes qui se plongent dans le sujet à travers les informations qu'ils reçoivent dans les exigences, à comprendre quels points doivent être clarifiés ou divulgués.La révision aide également à affiner la clarté du libellé, à apporter des modifications afin qu'elles soient interprétées sans ambiguïté par tout le monde.
Pour ce faire, nous avons également amélioré le suivi des problèmes, ajouté un type distinct de tâche «Review», qui est lancé par l'analyste responsable de chaque fonctionnalité sur tous les chefs d'équipe. Les managers de manière indépendante ou déléguant à leurs subordonnés font la relecture des exigences, posent des questions ou apportent des éclaircissements par le biais de commentaires et s'accordent sur les modifications apportées.
Capture d'écran n ° 3
Rallyes / réunions / statuts
Les réunions quotidiennes de l'équipe travaillant sur la fonctionnalité sont un excellent événement pour les petites équipes, à condition qu'elles utilisent des sprints fréquents. Sinon, les réunions quotidiennes prendront tout le temps de l'équipe et ne seront d'aucune utilité. Cependant, vous ne devez pas abandonner complètement les réunions, il vous suffit de déterminer correctement la fréquence de leur tenue. Et puis vous pouvez garder le doigt sur le pouls, comprendre si l'équipe avance dans la bonne direction dans la mise en œuvre du concept conçu, ainsi qu'identifier dès les premiers stades les problèmes qui peuvent être résolus ou les limites qui doivent être convenues.
Naturellement, lors de l'élaboration des exigences, vous devez communiquer avec l'équipe, car vous pouvez apprendre beaucoup d'informations utiles. Les moments importants qui se produisent quelque part dans la «boîte noire» peuvent grandement influencer le concept des nouvelles fonctionnalités du produit, la communication avec les collègues permet d'attirer l'attention sur des moments qui sont intéressants pour leurs rôles. Par exemple, la communication avec les testeurs permet de prendre en compte des scénarios alternatifs qui sont prévus pour être testés dans les exigences, et il est important qu'ils soient initialement posés et pris en compte dans le développement, et non découverts lors de la phase de test. .
Discussion / solution des questions ouvertes
Je voudrais souligner la communication vocale en tant qu'élément distinct, car je considère qu'il est important d'avoir une communication en direct, car dans les nouvelles réalités, il n'y a aucun moyen de discuter des problèmes en face à face.
Les messagers sont plus souvent utilisés, ils sont bien adaptés à la correspondance personnelle, dans laquelle vous pouvez utiliser des sourires, des gifs, etc. pour exprimer vos émotions. Mais pour les activités professionnelles, ce n'est pas tout à fait acceptable, et par conséquent, un texte sec et sans visage reste c'est difficile à interpréter pour le destinataire, car la perception de ce texte dépend de l'humeur de la personne, de son attitude personnelle à votre égard, de son implication dans le dialogue et d'autres facteurs qui ne dépendent pas de vous.
Par conséquent, je préfère résoudre les problèmes dans la discussion «par la voix», c'est-à-dire appeler et discuter, convenir de quelque chose. L'appel vous aidera à savoir si vous avez bien compris le contexte, posez immédiatement des questions et obtenez des réponses. La voix transmet l'intonation, vous permet de placer les bons accents, de faire attention à ce qui est vraiment important. De plus, la communication vocale fait gagner du temps à tous les participants et vous permet de vous concentrer sur un sujet spécifique, car la communication vocale (et non le chat) nécessite la participation et la compréhension pour résoudre le problème.
Journalisation des discussions
Il est absolument habituel et obligatoire pour chacun d'enregistrer les discussions des décisions avec le client sous la forme d'un mandat, qui est déduit à plusieurs reprises «au point» et accepté par toutes les parties intéressées. Je tiens à attirer votre attention sur le fait qu'en plus de la documentation officielle en développement logiciel, la fixation écrite des accords peut être utile non seulement dans le cadre de la communication «client - développeur», mais aussi au sein de l'entreprise / équipe.
Nous pratiquons la journalisation de la communication de l'équipe lors de la discussion des concepts de solution et des fonctionnalités du système. Puisque lorsque l'on travaille sur une fonctionnalité, plusieurs solutions peuvent surgir, parmi lesquelles il faut en choisir une, naturellement, des questions se posent pour l'équipe, qui, en fait, sont discutées lors de réunions.
En règle générale, nous conservons le protocole dans un format question-réponse. Le protocole justifie également pourquoi une telle solution a été choisie, il est enregistré qui a pris ces décisions et qui les a coordonnées. Mais il est important de comprendre qu'il s'agit de notre document interne utilisé dans notre travail, qui n'est réglementé par rien ni par personne. Le procès-verbal enregistre une discussion sur un sujet spécifique et à une date précise, c'est-à-dire qu'elle est nécessaire pour comprendre pourquoi certaines décisions ont été prises ou rejetées, quelles questions en général se sont posées et lesquelles sont fermées, et lesquelles nécessitent des recherches pour obtenir une réponse. ... Ceci est important car en mode multitâche, il est difficile de garder toutes ces informations dans votre tête, de plus, tous les membres de l'équipe intéressés doivent être conscients de ces informations et y avoir accès. Aussi, après un long moment,vous pouvez relire ce protocole et y trouver des réponses aux questions, ou peut-être aurez-vous de nouvelles pensées basées sur les réponses. Ou vous vous assurerez à nouveau de l'exactitude de la solution choisie.
La validation signifie vérifier la fonctionnalité mise en œuvre pour la conformité avec les exigences de l'entreprise. Avant le début des tests fonctionnels, l'analyste responsable de la fonctionnalité procède à la validation: il vérifie si le scénario principal a été implémenté et si le comportement du système répond aux attentes. C'est une pratique importante qui doit être utilisée juste avant le transfert des fonctionnalités pour les tests, car si le script principal n'est pas exécuté, alors il est inutile de vérifier d'autres cas. Pour effectuer la validation, un scénario d'acceptation est écrit, contenant les étapes à effectuer et la réponse attendue du système afin de résoudre finalement le problème métier pour lequel la fonctionnalité a été développée. Dans le cadre de la validation, il est possible d'identifier, tout d'abord, la défaillance du scénario principal, les inconvénients de l'interface utilisateur, ainsi que les défauts fonctionnels flagrants.Si le scénario principal est exécuté, la fonctionnalité est considérée comme validée et peut être soumise à des tests. Le test est déjà plus détaillé, conformément aux cas de test, il vérifie la fonctionnalité implémentée.
Présentation de nouvelles fonctionnalités
Une autre pratique intéressante, à mon avis, est la présentation des fonctionnalités avant d'écrire des cas de test ou d'émettre une fonctionnalité pour les tests. La présentation s'adresse à des interprètes qui ne sont pas plongés dans le contexte comme le sont leurs dirigeants, car ils n'ont pas participé aux étapes d'élaboration de la solution. En règle générale, il s'agit d'une courte histoire sur les scénarios de base et alternatifs mis en œuvre pour résoudre les problèmes, les paramètres à définir dans le produit, les fonctionnalités technologiques de cette solution et les limites. En conséquence, une compréhension générale des nouvelles fonctions du produit est formée et un certain nombre de questions qui peuvent se poser pour une personne qui n'est pas immergée dans le contexte sont supprimées.
Après avoir testé la fonctionnalité, avant la sortie officielle de la version technique, nous effectuons une présentation et une démonstration de la nouvelle fonctionnalité pour les employés des départements qui implémentent le produit chez le client. Cela permet d'obtenir des commentaires, de désigner des caractéristiques et des limitations préliminaires, d'annoncer le développement ultérieur de la fonctionnalité. Il est important que chacun ait une compréhension commune de la nouvelle fonctionnalité et n'ait pas de fausses attentes.
Ci-dessus, j'ai décrit une petite liste de pratiques que mes collègues et moi utilisons dans notre travail. Je les trouve utiles, je les partage donc et je souhaite vous recommander de créer un processus pour travailler avec les exigences en utilisant ces pratiques. Dans les prochains articles, nous prévoyons de parler de la partie substantielle du travail avec les exigences - plus en détail sur les pratiques que nous utilisons pour identifier les besoins / problèmes des clients et formuler des solutions qui les couvriront pleinement.
Si vous avez des questions ou souhaitez partager votre expérience, n'hésitez pas à laisser vos commentaires.
Auteur: Venera Abbyasova AbbyasovaVenera
* Toutes les photos de l'article sont tirées du libre accès sur Internet.