Comment mener à bien un processus de développement (même si vous n’êtes pas technique)

Ne serait-ce pas génial… (Office Space, 1999)

Laurence Peter a formulé le principe selon lequel «les gestionnaires atteignent le niveau de leur incompétence» en 1969. En particulier, les leaders non techniques ont acquis une mauvaise réputation auprès des développeurs de logiciels.

Office Space décrit le responsable non technique de Bill Lumbergh, illustré ci-dessus. Dilbert fournit le classique "Boss Pointy-Haired".

Cet article s’adresse à tous ceux qui souhaitent orchestrer efficacement un processus de développement sans pour autant devenir la cible des blagues sur les refroidisseurs d’eau de votre équipe. Je partagerai ce que j’ai appris au fil des ans en gérant les processus de développement et de publication en tant que gestionnaire et architecte logiciel pour les universités UCLA et Stanford.

La plus grande leçon que j’ai apprise est que la clé de la réussite des versions de logiciels est absolument non technique.

C’est une question de processus.

Certains aspects d’un processus de développement bénéficient du savoir-faire technique, mais ce n’est pas nécessaire. La mise en production réussie de logiciels est beaucoup plus une question d'architecture de processus robuste que de conception ou de code.

Pour les besoins de cet article, nous supposerons que vous avez déjà accepté de commencer à construire quelque chose. Le pipeline d’approbation de produit est un processus différent. Aujourd’hui, nous nous concentrons sur l’obtention du produit convenu du concept à la production.

Quoi construire

Votre équipe doit établir une feuille de route claire pour son code. Les architectes et les fabricants utilisent des plans. Tu devrais aussi.

Devrais-je utiliser ces plans ou juste l'escalader? Hmm… (source)

Votre feuille de route devrait inclure un ensemble de schémas qui remplissent chacun un objectif différent. Ces schémas diffèrent selon les applications. Une maquette d'interface utilisateur, un diagramme d'architecture d'application et un modèle de processus métier sont courants. Des diagrammes de composants plus détaillés, tels que les diagrammes UML (Unified Modeling Language) et les modèles de flux, sont également utiles.

L’expertise technique vous permet d’utiliser ces schémas pour critiquer l’architecture de votre équipe et vous assurer qu’elle est sur la bonne voie. Même sans compétences techniques, ces schémas seront critiques.

Vous pouvez les utiliser pour mener des conversations productives sur l'achèvement du produit. Plus besoin de tirer un «% achevé» de nulle part ou de deviner la meilleure estimation de l'équipe de développement. Vous pouvez suivre le statut de chaque élément du diagramme pour déterminer si l'application est proche de son achèvement. Vous pouvez également projeter la vélocité future en fonction de la rapidité avec laquelle l’équipe a achevé les composants précédents.

Il n'y a pas de «bonne» quantité de documentation de pré-développement, mais il y en a une mauvaise: aucune. Déterminez avec votre équipe ce qui constitue une feuille de route acceptable avant de commencer à coder. Le premier point de contrôle de votre processus de développement consistera à examiner cette documentation et à s’assurer qu’ils respectent cet accord.

Quoi ne pas construire

Votre équipe ne peut pas tout construire. Ils ne devraient pas non plus. Vous devez vous assurer que vos développeurs ont un focus laser sur ce dont ils ont réellement besoin pour construire.

Pourquoi construisez-vous cette application en premier lieu? Définir la différenciation clé des produits existants. 80% du temps de votre équipe devrait être consacré à cette différenciation.

Les schémas que vous devriez maintenant avoir seront utiles ici. Votre application inclut-elle un composant de journalisation? Un processus d'inscription et de connexion? Il existe déjà d'excellents frameworks de logiciels libres et open-source (FOSS) dans la plupart des langues pour ces composants. Certains sont disponibles sous des licences extrêmement permissives.

Tesla illustre bien ce concept. Leur premier facteur de différenciation consistait à utiliser une batterie lithium-ion pour rendre les voitures électriques compétitives avec le gaz. Lithium-ion a atteint cet objectif en réduisant le poids de la batterie et en augmentant la portée.

Tesla a fini par construire des infrastructures complètes pour supporter ses voitures, comme cette station «Supercharger»… mais pas avant d'avoir perfectionné son produit initial différenciant (source)

Le premier prototype Tesla a simplement converti une voiture de sport électrique préexistante de batteries au plomb-acide en batteries au lithium. Leur première production était principalement une roadster Lotus Elise (une voiture de sport préexistante) équipée d'une batterie et d'un moteur Tesla.

La leçon pour votre équipe est d'utiliser ce qui existe déjà chaque fois que possible. Si vous pouvez utiliser ou adapter un progiciel FOSS, faites-le. Même si vous devez obtenir une licence pour du code payant ailleurs, cela vaut presque toujours la peine.

Installez rapidement tous les échafaudages afin de pouvoir tester votre «batterie lithium-ion». Ensuite, vous pourrez parcourir et remplacer tout ce qui aidera à différencier davantage votre produit sans vous soucier de retarder la préparation à la production.

Le deuxième point de contrôle de votre processus de développement consiste à examiner l'architecture planifiée avec votre équipe et à identifier la partie très limitée qu'ils ont l'intention de créer à partir de zéro.

Si cela ressemble à quelque chose qui existe déjà et que ce n’est pas l’objectif principal de votre produit, demandez à votre équipe de comprendre pourquoi elle pense qu’elle doit recommencer.

Ne vous contentez pas de le jeter par-dessus le mur

Trop souvent, les équipes de développement «jettent la version par-dessus le mur» quand leur travail est terminé et s'en vont. Les bogues post-publication sont à la charge de l'équipe de support. (la source)

Une fois que vous avez identifié les technologies prédéfinies que vous utiliserez, veillez à les passer en revue avec votre groupe de soutien à la production.

Les administrateurs de bases de données et de serveurs devront planifier l’installation et la prise en charge de toute nouvelle technologie. Il s'agit du troisième point de contrôle de votre processus de développement: l'état de préparation des opérations.

DevOps tient 90% de la sauce secrète appelée "DevOps". Si vous n'en avez jamais entendu parler, DevOps est l’idée que les équipes de développement logiciel et de production doivent s’unifier sous des objectifs communs.

Les avantages proposés incluent des versions beaucoup plus rapides, un code plus fiable et plus de temps consacré au développement grâce à l'automatisation. Ce sont tous d'excellents bienfaits, mais ils résultent d'un processus de communication fort. L'automatisation suit, non remplace, la collaboration.

Mise en oeuvre et test

Maintenant, votre équipe écrit le code. Collaborez avec votre équipe de mise en œuvre pour mettre au point un processus permettant de répartir le travail entre eux. Il n’existe pas d’approche universelle, et c’est là que les «compétences générales» du leadership l’emportent de manière dramatique sur les compétences techniques.

Certains développeurs voudront accaparer tout le travail "intéressant" et ignorer tout travail fastidieux. Ils peuvent croire qu’ils sont la personne la plus intelligente de la pièce et qu’ils doivent choisir leurs affectations. D’autres risquent de résister au changement et de ne faire que le même type de travail qu’avant.

Conduisez votre équipe dans une répartition équitable du travail. Invitez tout le monde à grandir convenablement, à partager et à collaborer.

Un autre aspect technique de la mise en œuvre est que le code doit inclure suffisamment de tests automatisés. Ce sont des tests définis par le code qu'un système de test peut exécuter.

Si le code va planter, ne voulez-vous pas que le CV de ces gars soit en ligne au lieu du vôtre? (domaine public: photo du gouvernement américain)

Des «scripts de test» manuels dans lesquels un humain interagit avec le code pour voir s'il fonctionne correctement sont insuffisants et reflètent une dette technique. Votre équipe technique doit au moins inclure des tests unitaires. Le développement piloté par les tests est une approche répandue pour garantir que le code critique est toujours testé.

Vous pouvez mener une conversation non technique avec votre équipe sur leur «couverture de test» (la partie du code testée). C’est assez simple: demandez-leur d’énumérer leurs hypothèses. Puis demandez où et comment ils testent ces hypothèses.

Le point de contrôle auquel le code est considéré comme complet par les développeurs est désigné dans mon magasin par dev-complete. Cela signifie que le processus de développement principal (dev) est terminé, mais du code supplémentaire peut être écrit pour résoudre les problèmes qui surviennent lors du processus de révision.

Dans un processus de développement agile, vous diviserez généralement le processus de mise en œuvre en plusieurs points de contrôle au lieu d'une échéance tout ou rien. Celles-ci sont généralement appelées itérations.

Reportez-vous à la feuille de route que vous avez définie à la première étape. Avant de démarrer de nouveaux composants, assurez-vous que ce que vous avez déjà commencé est au moins dev-complete. Cela vous donne une vue précise de la vitesse de développement et réduit les risques.

Lorsque vous terminez les itérations, vous pouvez envoyer le code dans un environnement pour «tests d'acceptation». Cela implique des utilisateurs pilotes ou tests (ou une équipe interne jouant ce rôle) qui interagissent avec le produit partiel. Ils testent pour s'assurer qu'il répond aux attentes de conception et fournissent des commentaires sur la façon dont cela pourrait être amélioré.

Les tests d'acceptation ne remplacent pas les tests unitaires mentionnés précédemment. Cela sert un but différent. Laisser votre équipe de développement s'appuyer sur les tests d'acceptation pour détecter les bogues fonctionnels de base est une recette pour un désastre.

Les commentaires des testeurs d'acceptation peuvent être intégrés à la prochaine itération. C’est une autre bonne raison de ne pas mordre une grosse partie du produit en une fois. Vous souhaitez laisser la possibilité de changer de cap une fois que les gens commencent à jouer avec le produit.

Une fois que vous avez accumulé suffisamment de code testé pour constituer une version de produit suffisante, vous êtes prêt à commencer le processus de gestion des versions.

A la recherche de bugs aux bons endroits

Le bogue doit être quelque part ici… (source)

Votre développeur ou votre équipe a atteint un point où il pense que le code est terminé. Les testeurs d’acceptation sont satisfaits du fonctionnement du produit. Le prochain point de contrôle du processus consiste à valider la conviction selon laquelle le code est prêt à devenir un produit. Commençons par revoir le code!

Vous n'êtes peut-être pas à l'aise ou ne possédez pas le savoir-faire technique nécessaire pour réviser vous-même le code de l'équipe. C'est bon! Tu n'es pas obligé. Votre processus doit.

Avec votre équipe, identifiez un processus de révision du code qui fonctionne pour eux. Si vous avez plusieurs développeurs, la révision de code par les pairs fonctionne très bien. Sinon, y a-t-il d'autres développeurs dans votre organisation en dehors de votre équipe? Travaillez au-delà des limites de l'équipe pour établir un programme de révision de code par les pairs.

S'il n'y a qu'un seul développeur, assoyez-vous avec eux et demandez-leur de vous guider dans le code. Utilisez vos schémas comme point de référence et demandez-leur de vous expliquer comment le code permet d’atteindre ses objectifs.

À la fin du processus de révision du code, le développeur et le (s) critique (s) doivent être à l'aise pour être tenus responsables du code.

La révision du code est également un bon moment pour examiner deux autres points critiques: la documentation et la sécurité.

J'ai déjà écrit sur une architecture de documentation durable - vérifiez si cela vous intéresse!

La révision de sécurité doit faire partie de toute révision de code. En général, cela implique de jeter un second regard sur le code afin de détecter les faiblesses qu'un attaquant pourrait exploiter pour révéler des données privées ou obtenir le contrôle du serveur. Cela doit être fait par un technicien.

Le projet de sécurité des applications Web ouvertes (OWASP) publie un guide complet gratuit pour la révision de la sécurité.

Votre développeur peut le faire s’il est le seul membre de l’équipe, même s’il utilise simplement un outil d’analyse automatique du code de sécurité. Il existe des outils gratuits pour vous aider dans ce processus, qui sont liés via le wiki OWASP.

Éjecter, éjecter, éjecter!

Le code a passé le processus de révision. Il est prêt à devenir un produit. Mais cela ne signifie pas qu’il est prêt pour la production.

Le dernier point de contrôle à effacer est l'état de préparation au déploiement. Votre code est-il dans un état où il est facile à déployer en production? Cela devrait impliquer le moins d'étapes manuelles que possible.

Cela signifie également que vous devez avoir un plan pour annuler le changement au cas où le code ne fonctionnerait pas comme prévu. C'est ce qu'on appelle un «plan de restauration».

Tous les codes de production ne restent pas en production… (source)

Si vous avez une équipe d’exploitation de logiciels distincte, c’est à cet endroit qu’elle revient. Ils doivent examiner la documentation relative au déploiement et à la restauration et vous indiquer si elle est suffisante.

Si vous n’avez pas ce personnel, vous pouvez effectuer cette étape vous-même. Assurez-vous qu'il existe des instructions claires et simples pour le déploiement du produit. Il devrait y avoir très peu d'étapes manuelles, car chaque étape manuelle introduit une possibilité d'erreur humaine.

Il devrait y avoir un plan clair et suffisant pour revenir à l’état de la situation précédent si le déploiement échoue. Cela peut être aussi simple que de restaurer une sauvegarde ou peut impliquer une communication client ou une conversion de données.

Que le plan soit suffisant dépend de la minutie avec laquelle votre équipe a testé le code et de l'étendue de la diffusion du produit. Prenez également en compte les risques associés au produit ou à cette version.

Une fois que vous avez passé ce point de contrôle, mettez ce code en production!

Post-release

Réussir ou échouer, il est important de revenir en arrière et de revoir le déroulement du processus.

Votre équipe a-t-elle estimé avec précision les efforts requis pour libérer un produit? Les tests ont-ils correctement modélisé le scénario de production? Passez en revue les points de contrôle de mise en œuvre et de test et examinez les performances de l'équipe.

Comment fonctionne le produit en production? C’est une bonne idée de rendre visite au personnel des opérations et d’obtenir ses commentaires. Cela crée en outre une relation de confiance entre les équipes de développement et d’exploitation et se traduira ultérieurement par d’autres avantages pour DevOps.

Où sont les lacunes restantes dans votre produit? S'ils sont dans du code tiers, il est maintenant temps de décider de personnaliser vos packages ou de les implémenter à nouveau. Sinon, vous avez maintenant des informations sur ce qu'il faut construire pour la prochaine version.

Surtout, tenez votre équipe et vous-même responsables des résultats de vos efforts.

La responsabilité facilite l'indépendance et favorise la croissance individuelle. Au fur et à mesure que votre équipe s'habitue à être tenue responsable de chaque étape de ce processus, elle ajuste ses performances en conséquence.

Conclusion

Il n’est pas nécessaire d’être un peu technique pour mener à bien un processus de publication de logiciel. Les compétences techniques peuvent aider, mais cela peut aussi devenir une béquille.

La clé de la réussite de la publication d'un logiciel est un processus bien documenté et bien compris permettant de faire passer un logiciel d'un pipeline à un autre, de l'idée au produit. Vous avez maintenant un point de départ pour rédiger votre propre processus de publication de logiciel.

Le plus important est que vous participiez avec votre équipe à remplir les blancs et à créer un processus reproductible qui fonctionne pour vous tous.

Il ne doit pas être parfait pour quiconque, mais il doit être compris par tout le monde.

Vous devez également vous assurer que la vitesse de votre produit à travers ces points de contrôle correspond à la demande du produit. Aucun de ces articles ne doit être un arrêt de la présentation de plusieurs jours. Ce pourrait être une simple liste de contrôle d'une page. Vous devez définir un processus adapté à votre environnement.

Comme avec tout processus, vous devriez également itérer. Tout comme pour le code, votre premier brouillon non testé n’est probablement pas parfait. Réglez le processus sur chaque exécution et vous obtiendrez un chemin de sortie logiciel souple et prévisible.

Et souviens-toi de te brosser les cheveux. Vous ne voulez pas que ça ait l'air… pointu.

Si vous avez aimé cet article et que vous aimeriez en lire davantage, faites-le-moi savoir! Si vous souhaitez en savoir plus sur les processus de développement d’applications d’entreprise, veuillez répondre ci-dessous. Je suis heureux de partager ce que j’ai appris sur le parcours de mon équipe!

Vous pouvez également apprécier mes autres articles sur le processus de développement logiciel:

  • Ce qui vous manque en sautant la liste de contrôle
  • Comment nous nous sommes réorganisés dans un atelier de développement plus professionnel lorsque nous avons perdu notre gourou du loup solitaire

Jonathan est directeur adjoint de l’architecture et des opérations au département des systèmes d’information sur la recherche de l’UCLA. Diplômé en physique de l'Université de Stanford, il travaille depuis plus de 10 ans dans les domaines de l'architecture des systèmes d'information, de l'amélioration des processus métiers et de la gestion organisationnelle.