La publication d'un produit est la partie la plus importante du travail de toute société de logiciels. Mais si vous avez peur de faire une sortie, alors peut-être que vous faites quelque chose de mal. Je vais vous dire comment j'organise habituellement la sortie. Cet article n'est pas destiné à être un guide exhaustif car tout est individuel dans l'industrie du développement logiciel.
Comment se préparer à la sortie?
Choisissez une personne responsable
Vous pouvez à tour de rôle, ou lancer des dés, ou tirer des allumettes - n'importe quelle façon est bonne. Il est important de faire tourner les gens et de former ceux qui ne savent pas comment faire une sortie. Par exemple, lorsque vous lancez des dés, vous pouvez entrer les règles que celui qui était en service la dernière fois a le droit de transférer, et s'il était en service deux fois de suite, alors automatiquement vous n'êtes pas en service. Le devoir ne doit pas être considéré comme une punition ou une conscription, et il doit y avoir des personnes qui peuvent assurer.
Personnaliser le calendrier
Fixez une date dans le calendrier d'entreprise et assurez-vous que toutes les parties prenantes sont au courant.
Faire un tableau sur wiki
Indiquez la version du tableau, la date et la personne responsable de la publication. Ceci est plus nécessaire pour maintenir les données historiques. Vous pouvez et devez immédiatement noter si la version a réussi et ce qui était exactement inclus dans la version.
Notes de version
C'est exactement ce qui était exactement inclus dans la version. Tout d'abord, ces données doivent être partagées avec les analystes: ils peuvent comparer tout changement de KPI avec ce qui est inclus dans la version. Sur la base de ces données, ils peuvent tirer des conclusions sur les fonctionnalités dont les utilisateurs ont besoin, les bonnes idées et celles qui ne le sont pas, et ce qui ira dans la prochaine itération.
Annonce interne
Il est important que les autres services sachent quand la libération a eu lieu, par exemple, pour faire des postes dans les services sociaux. réseaux sur une nouvelle version d'un produit (créer un guide d'information), surveiller les KPI (les mesures peuvent augmenter ou diminuer), etc.
Pendant la sortie
Créer un brunch de sortie
Le code à publier ne doit pas être modifié, sauf pour corriger les bogues critiques. Et dans le cas idéal, tout correctif doit passer par une demande de pool. De plus, tous les tests doivent être verts.
Envoyer une notification
Vous devez informer tout le monde par courrier ou dans le messager qu'un brunch de sortie a été créé et que les préparatifs sont en cours pour la sortie.
Créer une balise
Assurez-vous de créer une balise lorsque la version est finalisée et de resserrer les correctifs dans la branche de développement.
Faire la libération elle-même
Idéalement, vous devriez avoir des mécanismes qui contrôlent la libération: par exemple, ne libérez que 10% des utilisateurs ou uniquement des non-payeurs. Cela est nécessaire pour cela. pour réduire les dommages dus aux erreurs survenues au cours du processus de développement et qui n'ont pas été détectées lors des tests.
Libération d'un bouton
Mythique. Bien sûr, moins le facteur humain est impliqué dans la sortie, mieux c'est. Mais c'est normal, sinon tout peut être automatisé.
Si tout s'est mal passé comme prévu
Bien sûr, en cas d’erreur, vous ne pouvez pas vous blâmer, mais vous devez résoudre le problème ensemble et élaborer un plan pour éviter de tels incidents à l’avenir.
Après la libération
Pour surveiller
N'oubliez pas de surveiller les erreurs, la charge du serveur. Il convient également de prêter attention aux KPI: si vous avez publié une version et que votre DAU a chuté, alors peut-être que quelque chose ne fonctionne pas aussi bien qu'il le devrait, ou les outils de surveillance eux-mêmes sont cassés. Toute activité suspecte mérite d'être vérifiée.
Signaler un succès ou un échec
C'est beaucoup mieux s'ils apprennent le problème des développeurs, pas des utilisateurs. Et bien sûr, si vous avez résolu des problèmes, vous pouvez vous en vanter en toute sécurité.
Rétrospective
Cela, bien sûr, dépend en partie de la méthodologie de développement, mais si quelque chose s'est mal passé pendant le processus de publication, cela vaut la peine d'en discuter. Si quelque chose était bon, cela vaut également la peine d'être discuté. Idéalement, le conseil d'administration pour chaque point d'échec devrait être un point de réussite ou de gratitude envers un collègue. Cela aidera à ne pas transformer une rétrospective en lancinante et négative.
Commandez une pizza et célébrez
Lors de tels rassemblements, seuls les collègues deviennent amis et camarades. Et cela signifie que lors de la prochaine bataille, les amis ne vous laisseront pas tomber.
Commencez à vous préparer pour la prochaine version
J'aime vraiment l'idée de Release train, lorsque chaque sortie a lieu régulièrement à des dates clairement définies. Grâce à cela, le mécanisme de libération est débogué par l'équipe. Comme je l'ai écrit plus haut, il n'est pas nécessaire de le diffuser à 100% des utilisateurs: il peut être déployé auprès d'un petit groupe de personnes.
Comment les autres sociétés publient-elles?
Spotify
Spotify sortira souvent sur la base de la pratique de Release train. Comme l'indique le nom de cette pratique, la sortie est très similaire à un train: ceux qui n'ont pas eu le temps de terminer leur travail attendent la prochaine sortie. Les avantages de cette approche sont qu'une équipe défaillante ne retarde pas la livraison du produit et n'essaie pas de pousser les tâches inachevées. Et en conséquence, les devops n'ont pas leurs téléphones déchirés la nuit, et l'équipe de service ne semble pas au travail avec des sacs sous les yeux le matin. Bien sûr, cette approche ne fonctionnera pas pour une entreprise d'externalisation: le client ne paiera pas pour les travaux inachevés. Franchement: j'aime la culture de l'entreprise, je vous conseille de regarder une vidéo (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) sur son fonctionnement.
Réservation
Ces gars sont aussi très cool. Leurs versions sont basées sur des tests A / B. Supposons qu'il existe une version stable actuelle - la version A, et qu'il existe une version que le développeur vient de terminer - la version B. Si le KPI est meilleur dans la version B, cela vaut la peine d'augmenter le pourcentage d'utilisateurs pour cette version. Si la version B est pire, alors il y a deux options: la version B n'est tout simplement pas stable ou juste une fonctionnalité dont personne n'a besoin. Cette approche convient à une entreprise qui prend soin de son produit de travail, mais elle ne fera probablement pas de révolution. Si vous souhaitez en savoir plus sur le lean manufacturing, lisez le livre Lean Startup (http://theleanstartup.com/).