Comment mettre en œuvre l'analyse des besoins ?

À quoi ressemble le processus de planification ?

L'analyse des besoins est incluse dans le processus de planification qui, à son tour, devrait être le suivant :

1. A projet qui décrit la vision finale de l'entreprise. produit à créer.
2. Un plan d'action général ou une idée qui définit ce qu'il faut faire pour atteindre nos objectifs.
3. Liste des tâches de base qui déterminent les étapes du travail sur le projet.
4. La planification du temps, dans laquelle nous définissons ce qui doit être livré et à quel moment.
5. Planification détaillée des tâches individuelles créées au cours de la troisième étape.

L'analyse des besoins couvre les trois premiers points du processus de planification.

Vision du projet

À ce stade, il convient de se poser quelques questions fondamentales :

1. Que voulons-nous faire ?

Certes, à ce stade, nous sommes déjà conscients de ce que nous recherchons et l'idée du projet a été présentée et réfléchie depuis longtemps, mais il vaut la peine d'y réfléchir de manière plus approfondie. Peut-être découvrirons-nous de nouvelles questions qui méritent d'être expliquées. Les questions suivantes peuvent être utiles à cet égard :

• Quel problème ce projet doit-il résoudre ?
• Qui sera son utilisateur final ?
• Sommes-nous en train de créer une interface pour les utilisateurs ? Sa création est-elle prévue dans le futur ? Le type d'interface que nous créons (bureau ou mobile) a-t-il été déterminé ? Sommes-nous intéressés par le RWD ?
• Existe-t-il des applications similaires ? Quels sont leurs avantages et leurs inconvénients ?
• Le projet a-t-il déjà fait l'objet d'une conception initiale ou d'une maquette ?
• Le projet dépendra-t-il d'applications externes ? Connaissent-elles ou ont-elles des limites ?
• Connaît-on les performances attendues et le niveau de sécurité ?

2. Quelles sont les exigences ?

Le moment est venu d'établir une liste des exigences fixées pour le projet. En plus des exigences fonctionnelles, nous spécifions celles qui ne sont pas liées aux fonctionnalités : convivialité, réactivité, rapidité, performance et sécurité.

Vérifions si chacune des exigences répond aux critères suivants :

• est complète - nous en avons une image complète,
• est correcte, sincère et attendue,
• est réalisable - réalisable et les autres exigences ne l'annulent pas,
• est nécessaire - il est nécessaire au fonctionnement du système ou exigé par le client,
• est sans ambiguïté - lisible et impossible à mal interpréter,
• est vérifiable - après la mise en œuvre, par l'observation et les essais, il est possible de déterminer si cette exigence a été respectée ou non.

3. Quel est l'objectif final ?

Il vaut la peine de créer une visualisation simple du fonctionnement du projet. Rien n'aide plus à comprendre l'idée du projet que de dessiner un flux de base ou d'écrire simplement sur le tableau en quelques points ce qui doit se passer à tour de rôle. Dans le cas d'une application dotée d'une interface utilisateur, l'idéal est de disposer des maquettes les plus simples.

4. Quelles sont les priorités ?

Tout comme pour la construction d'une maison, les projets informatiques doivent partir de zéro au début et s'orienter ensuite vers ce dont vous avez le plus besoin. Au départ, sur la base de la liste des besoins, il est donc nécessaire de spécifier une liste de toutes les fonctions possibles qu'un projet donné exécutera, puis de se mettre d'accord sur celles qui ont la plus haute priorité et qui doivent être réalisées dès que possible, et sur celles qui sont du type "nice-to-have" (agréable à avoir).

Le résultat de l'ensemble de la phase de visualisation du projet devrait être une image générale de la manière dont le projet devrait fonctionner, que ce soit par le biais de maquettes ou du flux d'activités dessiné. Nous devrions également recevoir une liste de toutes les fonctions possibles qu'un projet donné doit remplir et savoir quelle est la priorité de chacune d'entre elles.

La visualisation du projet est un moment clé de l'analyse des besoins. Elle permet de comprendre en profondeur l'essence du problème, et plus le matériel illustrant le problème est de qualité, plus les étapes suivantes de la planification seront efficaces.

Plan d'action

À ce stade, nous déterminons déjà comment nous imaginons le fonctionnement du projet dans son ensemble. Il est bon d'avoir quelques idées de mise en œuvre, de réfléchir et de discuter de chacune d'entre elles, et de mettre en évidence leurs faiblesses et leurs points forts. Il est également intéressant de détailler ici une idée choisie, voire toutes les idées.

Cette étape est également l'occasion de se pencher sur des questions purement technologiques, non seulement en ce qui concerne le langage ou le cadre dans lequel le projet sera rédigé, mais aussi en ce qui concerne les outils supplémentaires dont nous aurons besoin. AWS ou peut-être autre chose. Si nous hésitons entre certaines technologies ou si nous ne savons pas quoi utiliser, il vaut la peine de reporter une telle décision dans le temps et de la déléguer à une tâche de recherche. Bien sûr, nous ne pouvons le faire que si la planification ultérieure n'est pas bloquée par cette recherche. Dans le cas contraire, nous pouvons en toute sécurité les rattacher aux tâches de la sprint.

Principales tâches

Une fois le plan du projet établi, nous procédons à la définition des tâches principales, qui seront ensuite discutées en détail et décomposées en tâches plus petites par les responsables du développement. équipe lors de la planification d'un nouveau sprint. Il est important de décrire chaque tâche aussi précisément que possible.

Résumé

Comme indiqué précédemment, le processus d'analyse des besoins varie en fonction de la complexité du projet. Il y a des problèmes plus faciles et plus difficiles, et il y a aussi ceux qui ont déjà été résolus par quelqu'un et ceux qui sont complètement nouveaux et sur lesquels il faut s'arrêter plus longtemps. Quoi qu'il en soit, il y a quelques conseils importants à garder à l'esprit :

• La communication. Il s'agit de l'élément le plus important du cycle de vie de tout projet ; tout doit être clairement défini et expliqué.
• Comprendre rapidement le problème. C'est une bonne chose que la documentation du projet soit rédigée, mais n'oublions pas qu'elle doit être aussi concise que possible et ne pas faire un millier de pages. Chaque membre de l'équipe équipe de développement doit y avoir accès et doit pouvoir comprendre rapidement la vision du projet.
• La simplicité avant tout. Essayons de rendre nos projets aussi simples que possible, choisissons des solutions plus simples qui pourront être facilement développées à l'avenir, ou abandonnons-les lorsque le besoin s'en fera sentir.
• Vous n'en aurez pas besoin. Étant donné qu'en programmation, nous sommes guidés par le principe de YAGNI, ici, nous l'avons à l'arrière de la tête et nous n'accélérons pas trop.
• Les changements. Ne les craignons pas ; tôt ou tard, chaque projet en a besoin. En outre, ne nous faisons pas d'illusions en pensant que ce que nous planifions aujourd'hui fonctionnera toujours. En même temps, nous ne devons pas considérer les changements comme quelque chose de mauvais et d'indésirable. Les changements devraient être synonymes d'amélioration, et c'est ce que nous voulons : que le projet soit le meilleur.
• Le temps. Ne laissons pas la planification prendre trop de temps et s'éterniser. Si un problème nous bloque, cherchons des solutions à l'extérieur ou choisissons l'option la plus facile.

Il est toujours utile de se rappeler les aspects ci-dessus lors de l'analyse des besoins, afin que celle-ci se déroule sans heurts et constitue la base d'un projet bien planifié.

En savoir plus :

• Quelle est la meilleure approche de gestion de projet pour le développement de logiciels ?
• Les bonnes pratiques de Codest pour la création de logiciels. Notre approche du parcours client
• Un guide rapide pour créer et développer votre propre place de marché. Que faut-il savoir ?