Cuisine intérieure Veeam: comment fonctionne le processus de R&D

Le soir. Une autre entrevue sur la R&D touche à sa fin et nos enquêteurs sont à l'écoute des questions inattendues d'un futur collègue. Mais pas de surprise: le ratio déduit par Wilfredo Pareto fonctionne également ici. Dans 80% des cas, nous entendons quatre questions - environ 20% du nombre total reçu. Comment votre processus est-il organisé? Que vais-je faire? Comment devenir senior / chef d'équipe en un an? Et la relocalisation en Europe?

Dans cet article, nous répondrons à la première question et parlerons du processus de développement dans Veeam - d'équipe en équipe, cette réponse change le moins.



Donc, le processus. Il s'agit d'une séquence répétable d'actions conduisant au succès tous les jours, ou du moins parfois. Vous avez appris à cuisiner du bortsch et chaque fois que cela s'avère tout aussi savoureux - un processus. Le stationnement n'est pas un coup - maîtrisé le processus. Le processus permet au cerveau de ne pas penser à chaque fois à une routine, la transformant en travail mécanique. Le cerveau est libéré pour la créativité.

Le processus de développement est une séquence d'actions qui transforment les désirs des utilisateurs en produits tangibles. Ces désirs sont formulés par des analystes et des chefs de produit, mis en œuvre par des développeurs, évalués de manière critique par des testeurs, décrits par des rédacteurs techniques.

Chez Veeam, nous fabriquons des produits massifs pour la sauvegarde et la réplication du centre de données - afin que rien ne soit perdu. Un produit en boîte classique sans client spécifique. À première vue, la chose est simple, mais il y a des nuances, alors nous le faisons pour la deuxième décennie.

Acteurs

Chaque version est le résultat de plusieurs groupes:

• Chefs de produit ou analystes . Ils priorisent leur travail, communiquent avec le monde extérieur - clients et partenaires. Le partenariat peut être technologique. Par exemple, un distributeur peut dire ce qui lui manque pour augmenter ses ventes, et un fabricant d'hyperviseur peut parler de plans pour l'avenir. Pour cette équipe, les «compétences orales», la capacité de saisir et de hiérarchiser les tendances dans un flux d'opinions houleuses sont importantes. Et ensuite défendre la position choisie, dire non, expliquer pourquoi quelque chose a été fait de cette façon, et non autrement. Cela n'a pas d'importance dans les communiqués de presse, lors de conférences ou en privé. Ces personnes éduquent le monde de la vente.
  
• Support technique Assistance téléphonique pour nos clients. Les indicateurs les plus importants d'une équipe sont le temps de réponse à un problème et son temps de résolution (SLA). Environ quelques milliers d'appels sont traités au cours du mois. L'équipe est multicouche, comprend à la fois des groupes d'interaction avec les clients et des groupes d'analyse des appels, développement de solutions de contournement, etc. Sur la base des informations reçues par le support, une liste d'améliorations et d'urgence est formulée - que ce soit pour l'implémentation dans un correctif privé, la prochaine mise à jour ou le report à une version majeure.
  
• Développeurs R&D . Les gens qui matérialisent les demandes en code.
  
• Testeurs, ou QA . Premiers testeurs, une gamme de test de réservoir et un support de vibration en même temps. Ils vérifient non seulement ce qui a déjà été mis en œuvre, mais ils se connectent également au travail au stade de la conception. En répétant les tâches des administrateurs dans une infrastructure proche du combat, il est plus facile de comprendre à quel point l'interface créée est pratique ou que les algorithmes sélectionnés sont productifs. Lorsque le support technique arrive à la conclusion qu'il y a un défaut dans le produit, QA reproduit les scénarios problématiques et surveille les correctifs.
  
• Équipe de rédacteurs techniques. Ils créent de la documentation pour l'utilisateur final, ainsi que des documents spécifiques tels que «Comment ça marche» et «Guide de déploiement». Ils obtiennent du matériel pour le travail des développeurs, des testeurs et des analystes.
  

Certaines équipes préfèrent les espaces ouverts, mais plus souvent - les armoires

Les équipes sont reliées via un système de comptabilité des exigences. Nous l'avons implémenté sur la base du Microsoft Team Foundation System, car nous l'avons utilisé historiquement comme système de stockage de version source. Le système stocke les exigences (exigences), les défauts (bogues) et les appels à l'assistance (problèmes), nécessitant la participation de l'AQ et des développeurs. Chaque problème implique des centaines de participants qui travaillent sur des milliers de tâches, d'exigences et de défauts. Le système aide à garder tout cela et, plus important encore, à répartir uniformément la charge, à prioriser les développeurs.

Cernes: cycles de développement

Le développement de notre produit est cyclique, chaque cycle se termine avec la sortie de la prochaine version - release. Voici ce qui se reflète dans les versions:

• Tendances du marché durables . Par exemple, la virtualisation et l'émergence d'infrastructures cloud. Changer les paradigmes du travail informatique prend des années - à l'heure actuelle, les utilisateurs passent de la suspicion et du déni («qu'est-ce que c'est que ça») à la reconnaissance de masse («oui, tout le monde le fait»). La virtualisation des centres de données a donné lieu à un moment donné à Veeam, car dans des conditions de virtualisation, les anciens produits pour les machines de sauvegarde étaient inefficaces.
  
• Prise en charge de nouvelles plateformes . Il était une fois, Veeam était destiné uniquement aux centres de données virtualisés basés sur la plate-forme VMWare. Compte tenu du nombre et de la taille croissants des clients, il est nécessaire de prendre en charge de nouvelles plateformes. En plus de VMWare, d'autres hyperviseurs (Hyper-V), serveurs physiques, plates-formes cloud (AWS, Azure), etc. sont apparus.
  
• Changements tactiques sur le marché . Les prochaines versions des systèmes d'exploitation et des hyperviseurs sont publiées. L'expérience est acquise en utilisant les versions précédentes de notre produit. Par exemple, c'est ainsi que nous avons obtenu une prise en charge au niveau de l'élément - récupération sélective à partir de serveurs d'applications populaires tels que Microsoft Exchange, Microsoft SQL Server, bases de données Oracle, etc.
  
• Défauts . Malgré tous nos efforts, la vie est non-non et elle présente des surprises. Bien sûr, nous essayons de les minimiser.
  

Chaque trimestre, nous recevons des mises à jour (mises à jour), environ une fois par an - des versions majeures (majeures). Ils sont bons en ce qu'ils minimisent les frais généraux liés à la création de fonctionnalités volumétriques liées à la prise en charge de nouvelles plates-formes et à l'évolution des paradigmes. Sur la base des particularités de la budgétisation, les services informatiques des clients sont les plus actifs à la fin de l'année, nous déployons donc également de grandes versions pour le moment.

Les mises à jour trimestrielles ont principalement deux objectifs: la prise en charge des nouvelles versions de serveurs protégés et le dépannage. Dans les mises à jour, nous collectons toutes les corrections des défauts découverts par les clients depuis la sortie de la version majeure. De plus, avec l'aide des mises à jour, nous répondons rapidement aux changements des plates-formes prises en charge. Aux termes du SLA, Veeam doit ajouter le support de la nouvelle version de l'hyperviseur dans un délai maximum de trois mois .
Et si le produit ne fonctionne pas pour un client particulier? Dans ce cas, nous émettons un correctif privé - en d'autres termes, une béquille. Ces correctifs sont publiés chaque semaine et ne sont pas toujours associés à des défauts du produit. Par exemple, les paramètres de sécurité du client peuvent ne pas être compatibles avec le produit. En émettant un correctif privé, nous analysons la fréquence du problème et décidons d'inclure ou non le correctif dans la prochaine mise à jour trimestrielle.

De l'aube au crépuscule: chronique de sortie

Chaque cycle de lancement commence par la planification - au niveau du produit dans son ensemble et au niveau d'une seule exigence. Dans le premier cas, la question des priorités métiers et de la répartition des besoins entre les équipes est résolue. Tout d'abord, les exigences ou les épopées les plus urgentes sont discutées. Dans le bon sens, pas plus de 60% du volume total de travail sur la sortie devrait être alloué à l'épopée, afin qu'il y ait un coussin de temps. La planification des produits est effectuée au niveau des chefs de département - produits, testeurs, développeurs.

Les développeurs et les testeurs sont divisés en équipes. Le nombre optimal de personnes dans une équipe est de cinq. Les équipes sont à la fois fonctionnelles et universelles. Dans ce dernier cas, l'équipe est autosuffisante, contient des développeurs ayant une expertise dans plusieurs domaines. Les commandes fonctionnelles sont plus étroitement ciblées - elles fonctionnent sur l'interface utilisateur, les composants du système, etc. Des personnes de différentes équipes fonctionnelles forment des équipes virtuelles qui commencent à mettre en œuvre les exigences. Au moins des représentants du groupe PM, des équipes de développement et de test se réunissent ici. Le chef d'équipe se voit attribuer le chef d'équipe de l'une des équipes fonctionnelles.

Le travail commence sur l'exigence. L'équipe virtuelle se réunit chaque semaine. Les participants parlent des succès de la semaine dernière et planifient le travail pour la prochaine.
Le chef d'équipe responsable de la modération anime les réunions et enregistre les résultats. Il résout également les problèmes qui ne peuvent pas être résolus au sein d'une équipe virtuelle. Par exemple, si vous devez déplacer des dates ou reporter une partie des tâches.

Au sein des équipes de développement fonctionnel ou de test, les points de contrôle sont plus rapprochés. En règle générale, un plan hebdomadaire est divisé en tâches ne dépassant pas deux à trois jours. Certaines équipes ont pris racine dans la pratique de la mêlée avec des volatiles quotidiens; quelque part, l'interaction point à point entre le chef d'équipe et l'équipe fonctionne plus efficacement.


Salle de réunion typique pour discuter de l'état actuel du projet

Tout développement est divisé en itérations hebdomadaires ou bimensuelles. Au cours des premières itérations, vous devez créer une fonctionnalité fonctionnant au minimum qui deviendra ultérieurement de la viande - par exemple, une interface utilisateur avancée, une API pour les clients, etc. Et surtout, la présence d'un squelette permet déjà aux testeurs d'obtenir une fonctionnalité.

Le cycle de publication comprend les versions alpha et bêta. Avec leur aide, nous montrons de nouvelles fonctionnalités au monde extérieur et collectons des commentaires à l'avance. Si nécessaire, les décisions sur l'architecture ou la fonctionnalité sont modifiées. Les scénarios sont amenés à l'état alpha et bêta non pas immédiatement, mais par lots. En règle générale, il y a environ deux versions bêta dans le cycle de publication.

Après la phase bêta, les équipes passent en mode de test de régression. À ce stade, le produit dans son ensemble fonctionne déjà, l'interface utilisateur et les scripts ont déjà durci et changent avec moins d'intensité. Une équipe de rédacteurs techniques entre en scène. Parallèlement, des équipes de support technique sont en cours de formation.

Les tests de régression sont effectués par cycles de deux semaines. Le temps de cycle est déterminé par le temps requis pour afficher tous les scénarios de produit. Plus le produit est grand, plus il y a de scénarios et, par conséquent, de cycles. Un bloc de code est déclaré avant la dernière boucle. Cela signifie que seules des modifications critiques seront apportées au produit - et seulement après de nombreuses révisions de code. De telles méthodes draconiennes sont nécessaires afin de ne pas introduire accidentellement de nouveaux défauts dans le produit.

Plus le moment de sortie est proche, plus les développeurs ont de temps libre et moins tout le monde. Les chefs de produit doivent préparer des communiqués de presse, coordonner le travail des services marketing. Les testeurs doivent rechercher des correctifs et effectuer des tests de régression finaux. Les rédacteurs techniques ajoutent de la documentation utilisateur. A ce moment favorable, les développeurs développent des activités de recherche pour les exigences de la prochaine version.

Et ici, c'est un moment passionnant, appelé RTM - Ready To Market. Cela signifie que le produit est déjà prêt à être distribué aux consommateurs. Dans deux semaines, il sera tourmenté par des journalistes, prestataires de services. Il sera montré lors des présentations. Deux semaines plus tard, le produit sera accessible à tous. En ce moment, des changements internes ont également lieu: de nouvelles branches de développement se préparent, du code est déposé. Et, bien sûr, l'infrastructure de construction de la prochaine version augmente. Après la sortie publique (GA), c'est un moment brûlant pour le support technique. Et le reste travaille déjà sur la prochaine version.

À propos des priorités

Et enfin, un peu de matériel. Comme vous le savez, dans la trinité du "rapide, de haute qualité, peu coûteux", vous pouvez choisir un maximum de deux options. La qualité, le timing et la fonctionnalité se battent constamment entre eux. Dans notre produit en boîte, la qualité passe avant tout. Hmm, mais quel est un domaine où la qualité n'a pas d'importance? Bien sûr que non. Toute la question est la définition de la qualité.
Pour nous, la qualité c'est:

• Préservation de la fiabilité et des performances dans les configurations de zoo . Un client possède un modeste centre de données de deux serveurs à l'époque de la bataille de Borodino, tandis que l'autre dispose d'une infrastructure haut de gamme dans un hangar à proximité avec Amazon. Le produit doit fonctionner correctement dans les deux cas.
  
• Facilité d'utilisation . L'utilisateur doit être au minimum contraint et certainement faire face sans aucune instruction. Mais une simplicité similaire est loin d'être toujours cachée derrière une simplicité externe - essayez de traverser de manière transparente avec un hérisson.
  
• Héritage Les investissements dans les entreprises sont à long terme et les directeurs financiers ne seront pas dépensés en informatique sans raison valable. Vous devez donc maintenir la compatibilité avec les versions précédentes et les produits associés. Souvent, lors de la reconstruction des centres de données, les serveurs de messagerie de l'ère 80 sont enfermés dans le mur. Et ils bourdonnent tous et ne pensent pas à mourir.
  

Avec un tel ensemble de priorités pour préserver la qualité, vous devez toujours combiner quelque chose, à la fois pour les développeurs et les testeurs. De petits changements dans le comportement des fonctions peuvent conduire à des tests d'intégration forcés de la part du lion du produit. Essayez d'ajouter la prise en charge des paramètres régionaux asiatiques au produit et comprenez de quoi il s'agit. Par conséquent, la question des priorités est une question de discussion conjointe des PM, des testeurs et des développeurs.

La deuxième priorité, presque indestructible, est le timing. Dans le cas des mises à jour, les dates de sortie sont fixées par le SLA, dans le cas des versions importantes - par le calendrier professionnel. Selon les statistiques, à chaque cycle de sortie, près de 50% du temps est consacré au développement, 50% à la mise à l'esprit du produit (phase de correction de bug).

Ce qui peut changer, c'est la fonctionnalité de la prochaine version. Une liste prioritaire d'exigences, ou backlog, aide ici. Théoriquement, tout est simple: choisissez la prochaine fonction prioritaire dans le backlog, regardez le temps restant. Lorsque l'heure est proche de la fin, arrêtez et libérez la prochaine version du produit. Le diable est caché dans les nuances:

• Incertitude des exigences . Par exemple, l'exigence «de prendre en charge la sauvegarde de machines physiques sous OS Linux» peut être encore affinée. Quels cœurs doivent être pris en charge? Quelles distributions? Quels systèmes de fichiers? Une seule et même exigence de haut niveau peut être mise en œuvre en un mois ou un an. La question est complète.
  
• Les équipes ont des spécialisations . Toutes les exigences ne peuvent être prises en charge par aucune équipe. Le développeur C # n'écrira pas de pilotes; le développeur de composants système ne fera pas toujours face au développement Web.
  
• Les exigences dépendent les unes des autres . Ce n'est pas toujours visible au niveau des scénarios utilisateur, mais il existe de telles relations à l'intérieur. Du point de vue du monde extérieur, la prise en charge de la sauvegarde à partir des systèmes de fichiers NTFS et ExtFS peut être une exigence avec des priorités différentes, mais à l'intérieur, vous devrez d'abord écrire un moteur commun.
  
• Les exigences sont divisées en différées et non reportables . Si le marché attend dans la prochaine version une fonction, et cela a été annoncé, il ne fonctionnera pas pour le reporter.
  
• Une partie des exigences implique la recherche . Sans les résultats de la recherche, il est impossible de planifier la complexité de la tâche (peut-être même pas du tout), et il peut être difficile de prévoir ces résultats.
  

C'est là que le développement agile entre en jeu. Pour nous, le développement agile signifie la nécessité d'un redéveloppement périodique. De nouvelles circonstances sont devenues connues - des plans modifiés. Ajout de nouvelles exigences de priorité au carnet de commandes - plans modifiés. Nous n'avons pas le temps avec des exigences non retardées - nous supprimons une partie des tâches ou modifions l'exigence. Dans la théorie du contrôle technique, cela s'appelle un système de rétroaction. Rappelez-vous comment fonctionne le pilote automatique.

Toute planification dans les conditions ci-dessus repose sur un jugement d'expert. Une évaluation experte du chef d'équipe est l'élément qui rend l'ensemble du processus ultérieur clair et structuré. Un autre nom pour l'évaluation d'expert est «la méthode du strabisme léniniste», comme Alexander Orlov de Stratoplan aime répéter. C'est à ce moment que vous prenez une décision basée sur l'expérience et l'intuition précédentes. Malgré d'éventuelles critiques, cela fonctionne. Il fonctionne comme tous nos processus décrits ci-dessus. Si vous avez encore des questions à leur sujet, nous vous invitons à commenter.

Et ensuite?

La technologie de processus actuelle est confortable et confortable comme les pantoufles maison. Le seul problème est que dans Veeam, un poinçon invisible vous conduit toujours: plus vite, plus, plus, plus.
Plus récemment, des bureaux pilotes ont été construits en Finlande et en République tchèque et cette année, nous préparons l'ouverture officielle du centre de R&D de Prague pour plusieurs centaines de personnes.


Le hall de notre bureau de Prague

Un bureau de développement est récemment apparu en Israël; les équipes au Canada et en Allemagne se développent.Le nombre de projets de développement communs avec HP, NetApp, Nutanix, EMC augmente.
La manufacture se transforme en un convoyeur géographiquement distribué, et en même temps, de nouveaux processus se cristallisent. Cependant, c'est un sujet pour un article séparé.
Restez connecté.