Méthodologies de développement de logiciels

Bonjour. Lors des deux derniers entretiens, on m'a posé des questions sur les méthodologies. Ce n’est pas la question la plus importante ou la plus difficile, mais ce serait bien d’avoir un aide-mémoire pour la réponse. Dans cet article je vais essayer de donner une idée de ce qu'est une méthodologie de développement et de comparer celles que j'ai personnellement rencontrées ou sur lesquelles on m'a interrogé. La méthodologie de développement logiciel est un processus de description de la manière dont un produit spécifique sera développé, c'est-à-dire l'un des moyens d'organiser le développement d'une équipe. Il existe de nombreux modèles différents d'un tel processus, chacun décrivant sa propre approche, et on ne peut pas dire que parmi eux il y en a un qui devrait être utilisé dans chaque projet, tout est purement situationnel. Je propose d'en examiner trois plus en détail.

Cascade

La cascade (cascade, cascade) est l'une des méthodologies les plus anciennes et implique la mise en œuvre strictement séquentielle de toutes les étapes, dont chacune doit être terminée avant le début de la suivante. C'est-à-dire que le passage à l'étape suivante signifie l'achèvement complet des travaux sur la précédente. L'image montre que nous analysons d'abord la tâche (documenter les tâches, discuter des difficultés), puis la conception a lieu (à ce stade, la structure du projet est formée), puis le codage et les tests. Il n'y a aucun remboursement pour les étapes suivantes. Il est recommandé d'utiliser un tel système dans les petits projets où les exigences sont connues à l'avance et où il est peu probable qu'elles changent. Avantages :

• Une documentation complète et cohérente à chaque étape ;
• Facilité d'utilisation;
• Exigences stables.
• Le budget et les délais sont prédéterminés

Défauts:

• Une grande quantité de documentation ;
• Ce n’est pas un système très flexible ;
• Le client ne peut pas visualiser la version démo du produit ;
• Il n’y a aucun moyen de revenir en arrière.

Mêlée

Scrum est un système de développement logiciel basé sur la division de l'ensemble du processus en itérations, où à la fin de chacune d'elles, l'équipe est prête à fournir une version de démonstration du produit. La photo montre que l'équipe passe par toutes les étapes de développement en parallèle, ce qui nous permet d'avoir une partie finie du projet à la fin de chaque itération. Je vais essayer d'expliquer brièvement avec des mots simples l'essence de la méthodologie, mais il y a beaucoup de termes ici. Je pense que le plus important est d’en comprendre l’essence, et les termes seront mémorisés avec l’expérience. Tout développement est divisé en sprints (souvent 2-3 semaines). Il existe un backlog (liste de tâches) pour toute la période de développement et pour chaque sprint séparément. Chaque tâche a son propre point d'histoire (niveau de difficulté). Chaque participant au processus a un rôle :

• Une équipe Scrum est une équipe travaillant sur un projet (développeurs, testeurs, designers).
• Un Scrum Master est une personne qui veille au respect des principes de Scrum.
• Propriétaire du produit – client.

Puisque dans ce système l'accent est mis sur la communication, il existe un grand nombre de rassemblements :

• Le stand-up est une courte réunion, organisée tous les jours, à laquelle tous les membres de l'équipe participent et chaque participant répond à 3 questions : qu'avez-vous fait ? Que fera-t-il ? Et quels sont les bloqueurs ?
• Planification – organisée au début du sprint et lors de cette réunion, les tâches à accomplir lors du prochain sprint sont déterminées.
• La rétrospective a lieu à la fin du sprint et son essence est de découvrir ce qui a été bien fait et ce qui pourrait être amélioré.

Avantages :

• Le client peut observer le résultat pendant le processus de développement.
• Contrôle quotidien du processus de développement.
• Capacité à faire des ajustements pendant le développement.
• Communications bien établies avec tous les membres de l’équipe.
• Petite quantité de documentation.

Défauts:

• Difficile d'estimer la main d'œuvre et les coûts nécessaires au développement
• Il est difficile de déterminer les principaux goulots d’étranglement avant le début du développement.
• La nécessité d'impliquer chacun dans le développement des autres membres de l'équipe.

Kanban

Kanban est un système basé sur la visualisation du processus d'exécution des tâches d'équipe. L'idée principale de ce système est de réduire le nombre de tâches en cours d'exécution (dans la colonne « en cours »). Dans Scrum, l'équipe se concentre sur la réussite des sprints ; dans Kanban, les tâches passent en premier. Idéal pour les projets en phase de support, où la fonctionnalité principale a déjà été développée et où des améliorations minimes et des corrections de bogues subsistent. Dans Kanban, les tâches sont soumises individuellement. La tâche, indépendamment des autres tâches, passe par toutes les étapes indiquées sur le tableau et dès qu'elle est terminée, elle peut être montrée au client. Un tableau Kanban se compose de colonnes, chacune représentant un processus de développement distinct. Certaines colonnes (par exemple, en cours) imposent des restrictions sur le nombre de tâches pouvant s'y trouver. Cela permet de trouver facilement et rapidement les zones problématiques dans la répartition des tâches. L'image montre un exemple d'une planche aussi simple. Le nombre de colonnes et les noms peuvent varier, mais je citerai les plus courants :

• À faire - une liste de tâches à effectuer
• En cours – tâches en cours d'exécution
• Révision du code – tâches qui ont été complétées et envoyées pour révision
• En test – tâches prêtes à être testées
• Terminé – tâches terminées.

Avantages :

• Facilité d'utilisation.
• Visualisation (aide à trouver les goulots d'étranglement, simplifie la compréhension)
• Forte implication de l'équipe dans le processus lui-même.
• Grande flexibilité dans le développement.

Défauts:

• Liste de tâches instable.
• Difficile à utiliser sur des projets à long terme.
• Pas de délais stricts.

En conclusion sur la méthodologie de développement logiciel

À mon avis, les personnes qui occupent des postes de direction ou aspirent à y accéder doivent avoir une compréhension approfondie des méthodologies de développement de logiciels, mais il est conseillé à chacun d'en comprendre au moins les bases. Ceci fait partie intégrante du processus de développement et n'est pas utilisé uniquement dans le domaine informatique. Merci d'avoir pris le temps de lire mon article, j'espère que vous l'avez trouvé utile. J'ai essayé de décrire uniquement les points clés aussi clairement et brièvement que possible, l'article n'est donc pas exhaustif. Je serai heureux d’entendre votre opinion à ce sujet et de répondre à vos questions. Tous mes vœux!