Il semblerait que dans les petites équipes de développement (20+ personnes), il ne devrait pas y avoir de problèmes de désunion, de travail sur un code commun et de prise de décisions techniques. Mais nous savons tous que ce n'est pas le cas (sans parler des équipes comme la nôtre, où 80+ personnes). Il y a trois ans, pour les résoudre, nous avons commencé à organiser une conférence hebdomadaire interne des développeurs DevForum. Sous le chat, vous apprendrez comment cela nous aide, pourquoi d'autres formats (comme les réunions hebdomadaires ou Sprint Review) et les instructions pour le créer ne conviennent pas toujours.
Pendant trois ans, nous avons accumulé beaucoup de bons contenus. Par conséquent, il y aura une série d'articles écrits basés sur des discours à DevForum :
1. Chat Schrodinger sans boîte: le problème du consensus dans les systèmes distribués.
2. L'infrastructure comme code: première connaissance.
3. Infrastructure en tant que code: comment surmonter les problèmes avec XP.
4. Comment les serveurs s'accordent les uns avec les autres: algorithme de consensus distribué Raft.
5. Le cheval est mort - cri: transition de tslint à eslint.
6. Génération de contrats dactylographiés pour les modèles c #. (En cours ...)
...
Qu'est-ce que DevForum et quels problèmes résout-il?
DevForum est notre événement interne hebdomadaire pour les développeurs Dodo IS. Il fonctionne le jeudi depuis trois ans. Les développeurs se réunissent et consacrent une heure à communiquer entre eux.
Lors de cette réunion, nous discutons des questions techniques pertinentes pour toute l'équipe. Une heure de temps, deux rapports d'une demi-heure, le temps des questions et réponses.
Quels problèmes la conférence interne résout-elle?
Afin de progresser vers la réalisation d'un objectif commun, il est important pour nous de continuer à nous concentrer sur les questions importantes de l'entreprise. Pour la synchronisation globale de tous les Dodo, nous avons des réunions hebdomadaires le lundi. Tous les employés, partenaires / franchisés y sont présents, les enregistrements des réunions peuvent être consultés
dans le domaine public . Pour une synchronisation avec les entreprises et les partenaires, nous organisons une revue de
sprint bi-hebdomadaire. Pour une focalisation unique et une synchronisation régulière de l'équipe informatique, vous avez besoin de plus d'immersion dans la "viande" technique. C'est ce que nous faisons sur DevForum.
Voici une liste des problèmes et de leurs solutions:
- Partager les connaissances . Nous avons maintenant plus de 80 développeurs dans notre équipe. Chacun d'eux a sa propre formation, ses spécificités de travail, son propre niveau d'immersion. Nos équipes sont réparties par produit. Et il peut arriver que deux équipes indépendantes aient besoin de traverser les mêmes déserts. Quand ils ont la possibilité de partager leurs meilleures pratiques, réflexions, succès ou vice versa, cela s'améliore. Il y a une petite chance de ne pas marcher sur le râteau de quelqu'un.
De plus, notre équipe est en constante expansion, de nouvelles personnes viennent chercher un outil prêt à l'emploi pour une mise à niveau régulière et le partage des connaissances. - La formation . Ici, vous pouvez apprendre si vous ne pouvez pas le faire vous-même et enseigner si vous le pouvez. La formation est un point étroitement lié au partage des connaissances. Que cela nous plaise ou non, nous devons constamment améliorer notre niveau technique.
- Synchronisation technique des commandes (à ne pas confondre avec la synchronisation quotidienne des commandes) . Il est facile de se tenir au courant de tout lorsque vous n'êtes que trois personnes. Maintenant, nous sommes beaucoup plus. Parfois, nous rencontrons un tel problème: les équipes ont travaillé en parallèle sur un produit, mais ne savaient pas ce que chacun faisait. En conséquence, des conflits sont survenus, réécrivant le code de quelqu'un d'autre, etc. Lorsque certains le font, tandis que d'autres lancent, le processus de développement peut glisser. Chez DevForum, nous nous concentrons également sur la synchronisation technique des équipes et luttons avec la désunion.
- Outil de changement . Vous pouvez venir ici et changer le cours de l'histoire. Ici, vous devez dire par exemple.
Un exemple. Disons que nous avons Oleg. Il est assis dans l'infrastructure et fait le projet d'autonomie avec les gars. Lorsque le projet démarre à son plein potentiel, la vie de simples développeurs deviendra plus facile. Ils cesseront de tirer l'infrastructure et feront tout eux-mêmes. Vous faites tout vous-même, vous ne dépendez de personne, très bien.
Oleg est prêt à apporter des changements dans l'entreprise. Mais il sait qu'il ne suffit pas d'écrire sur les modifications apportées à Slack. Il faut dire en public, expliquer, répondre aux questions, écrire un article, mener une série d'actions, sinon rien ne changera. Oleg arrive sur DevForum et l'utilise comme outil de changement.
- Entraînement avant la représentation . Ici, vous pouvez vous entraîner avant une grande performance. Encore une fois, prenez Oleg comme exemple.
Un exemple . Oleg veut prendre la parole lors de grandes conférences. Il a besoin d'honneur, de célébrité et de milliers de vues sur Youtube.
Il vient vers nous et parle honnêtement de ses objectifs ambitieux. À son tour, nous lui fournissons une plate-forme pour une formation (pratiquement) indolore. Si nécessaire, nous aidons, demandons, guidons.
Le seuil d'entrée dans DevForum (contrairement à une mitap ou une conférence) est minimal. Oleg doit préparer un sujet, préparer des diapositives pendant une demi-heure et venir au bon moment. C'est un endroit idéal pour une répétition d'essai. Formation sur les chats, c'est-à-dire sur nous. Nous donnerons des commentaires et passerons en revue les diapositives, et vous pourrez vérifier les blagues sur nous.
Après DevForuma, le rapport peut déjà être lancé sur un mitap local. Et très probablement, ils le prendront.
Un peu rétro: comment est né DevForum
D'où vient ce format? Korotenechko. Il y a trois ans, notre entreprise a fait sa première tentative pour introduire régulièrement Sprint Review.
Cela ressemblait à ceci: tout le monde était réuni dans une pièce, absolument tout et se relayait pour se dire qui avait fait quoi au cours des dernières semaines. À cette époque, nous n'étions que 20, mais imaginez ce que c'est que d'écouter et de regarder le code pour le représentant commercial et le développeur pour regarder les bâtiments de la pizzeria. Nous avons très vite réalisé que les gens n'écoutent que les sujets qui les intéressent, et sur d'autres sujets ils sont douloureusement coincés dans le téléphone.
Nous sommes confrontés au fait qu'une démonstration profondément technique à ceux qui en sont loin est telle. Ils sont venus voir comment la caisse démarre, et nous leur parlons de l'expérience d'utilisation du framework Polly pour l'implémentation de retraits entre services. Nous avons rapidement réalisé qu'un tel format était de peu d'utilité pour les gens, et Sprint Review a refusé sous cette forme. À un moment donné, il a simplement été annulé et la réunion sur le calendrier est restée.
Un groupe d'initiative a pensé: c'est tellement cool de montrer des choses techniques à ceux qui sont dans le sujet. Il y a une réunion, il y a des gens, il y a un désir, il y a des sujets. Nous avons donc commencé à nous réunir une fois par semaine et continuons de le faire à ce jour.
Depuis trois ans, le format a subi quelques modifications.- Nous avons commencé à enregistrer nos performances. Le format lui-même existe depuis trois ans, nous avons des records en deux ans. Tous sont stockés en un seul endroit, si vous le souhaitez, vous pouvez les consulter.
- Nous avons quitté le format de la démonstration car nous sommes arrivés à la conclusion que la préparation et la démo elle-même prennent plus de temps que le format de la présentation.
- Nous sommes passés au format de présentation, qui est facile à préparer, en lui donnant littéralement 40 minutes de temps (bien qu'ici, bien sûr, cela dépend de la complexité du sujet et de l'orateur).
- Au début, chaque développeur a parlé à DevForum. À un moment donné, nous avons supposé que ce n'était pas chaque personne qui parlait, mais un représentant de l'équipe.
- Ensuite, nous sommes allés plus loin et avons cessé de harceler avec une proposition de parler aux équipes qui ont maintenant "rien ne se passe".
- Au départ, nous abordions quatre sujets par heure, mais nous sommes arrivés à la conclusion que, peu importe à quel point les rapports étaient intéressants, à la fin de l'heure, seule la bouillie restait dans ma tête. Alors maintenant, nous prenons un ou deux sujets sur DevForum, 25 minutes d'un rapport et 5 minutes pour des questions.
- Récemment, nous avons décidé d'élargir un peu la gamme des sujets et parfois d'inviter des intervenants externes.
Nous savons que notre DevForum n'est pas un format super unique, beaucoup de nos collègues ont essayé quelque chose de similaire. Mais, malheureusement, souvent de telles réunions régulières ne prennent pas racine, deviennent rapidement obsolètes et se fanent. Notre DevForum vit trois ans - c'est long pour analyser, collecter des expertises et partager avec vous l'expérience de la création et du maintien de ce format.
Comment organiser DevForum dans votre entreprise
Vous aurez besoin de 6 choses de base:
1. Comprendre les tâches et les formats de DevForum.
Plus de détailsPour comprendre s'il est nécessaire d'exécuter DevForum à la maison, vous pouvez consulter les tâches que ce format résout dans notre Dodo.
Ce sont les tâches de communication, de formation et de réalisation de soi des programmeurs. DevForum est un mécanisme flexible et peut à un moment ou à un autre travailler davantage pour atteindre différents objectifs.
Il existe deux formats vocaux vérifiés que nous avons développés en trois ans. Vous pouvez adopter:
Rapport : un développeur prépare et parle, tandis que d'autres posent des questions.
Un exemple . Une fois, le sujet était «Structural Logging», où ils ont parlé de Serilog, de son utilisation dans nos projets et de la façon dont il aide à mieux travailler avec les journaux dans Kibana. Il a également abordé le sujet de la journalisation structurelle via NLog et l'utilisation d'interfaces ILogging communes pour les projets .NET CORE.
Après la présentation, il y a eu une session de questions et tous les participants ont compris à quel point il était facile d'ajouter cette bibliothèque à un nouveau projet. Cela nous a pris 30 minutes. Pendant encore une demi-heure, nous avons discuté des niveaux de journalisation de ce jour tels que Debug, Info, Warn, Error etc., et en particulier, quels niveaux décrivent quelles situations dans le système. Lors de la séance de questions, le problème des erreurs de bruit dans les journaux, en particulier ceux liés aux retraits, a été soulevé. Depuis DevForum, tous les nouveaux projets de microservices utilisent exactement Serilog, et il est également apparu dans notre modèle de service.
Prise de décision : il y a un problème qui affecte en quelque sorte tout le monde. Les gens viennent avec des solutions possibles pour s'attarder sur une chose.
Un exemple . Nous avons réuni DevForum pour discuter de la définition du fait et nous voulions stabiliser la qualité du code fourni pour la production. Mais comment faire cela lorsque vous avez plusieurs commandes travaillant sur un code commun à la fois? La solution était de rendre commun à toutes les définitions des user stories réalisées. Le DOD proposé était un point controversé. Nous nous sommes réunis et avons discuté si nous en avions besoin ou non. Une décision générale a été prise. Pour l'implémenter, nous avons ajouté un élément à la liste de contrôle dans notre traqueur de tâches (Kaiten) et en avons fait un élément obligatoire lors de la fermeture des tâches. Certaines équipes ont ensuite renforcé le DoD en ajoutant leurs propres points importants pour elles.
2. Organisateurs puissants et chargés.
Plus de détailsIl faut également tenir compte de la présence de personnes constamment engagées dans l'événement - les organisateurs. Il est important qu'ils proviennent de développeurs ou de personnes qui comprennent la partie technique. Ils devront aider les participants à formuler des sujets, à rechercher de nouveaux orateurs et même parfois à maintenir une discussion en posant de bonnes questions.
Dans notre cas, nous avons 3 organisateurs des développeurs, ainsi qu'une équipe de marque informatique qui aide activement.
3. Consentement de la direction de votre service informatique.
Plus de détailsEn plus des objectifs et des organisateurs, un élément important du succès de l'événement est le manque d'opposition d'en haut. Ce processus est une initiative purement populaire, on peut dire que les passionnés le font. L'aide de la direction peut être bénéfique et l'opposition sera désastreuse. Pourtant, les gens se rassemblent pendant les heures de travail, utilisent les locaux et l'équipement de bureau. Cela, au minimum, ne devrait pas être interdit.
4. La disponibilité d'espace et d'équipement pour les réunions.
Plus de détailsL'espace peut être soit une salle de réunion au bureau, soit un lieu de réunion virtuel, un appel général dans Skype ou Google Meet.
Nous nous réunissons toujours dans une salle de réunion réservée «pour toujours à cette heure» dans le bureau, mais en même temps, nous diffusons tout en général Google meet, qui est également le même et ne change pas entre les réunions.
Notre négociation est vaste, pouvant accueillir 20 à 30 personnes. Il y a un projecteur et un système de sortie audio pour les appels à distance. Tout le monde sait que les jeudis de 16h00 à 17h00, le DevForum se tient dans cette salle de réunion.
En raison du fait que nous avons un développement partiellement distribué, nous sommes sûrs d'amener les travailleurs distants à un appel commun. Il permet également aux intervenants d'afficher leur écran depuis leur ordinateur, en se connectant à une réunion générale. Les orateurs peuvent être dans la salle de réunion générale ou dans tout autre endroit qui leur convient. Nous les entendrons tous et verrons également leur écran.
L'espace permanent désigné rend cette réunion plus fiable et prévisible pour les participants.
5. La présence d'un public d'auditeurs.
Plus de détailsPour rassembler les participants, nous avons un canal permanent dans le slack #devforum, où tous les développeurs sont sûrs. Nous avons même inclus cette chaîne dans la liste des chaînes requises dans la liste de contrôle du nouveau développeur. De plus, les mentors novices s'assurent qu'ils tombent dans le canal #devforum.
Il y a des annonces de réunions, des discussions après, le choix des sujets et des discussions sur les sujets.
Afin que les gens participent à la vie du forum, nous organisons des sondages, demandons aux intervenants de donner leur avis et publions également un enregistrement de la réunion le lendemain matin.
Il est également important que l'événement soit volontaire et facultatif. Oui, il a lieu pendant les heures de travail, mais si quelqu'un veut travailler ou a des choses plus importantes à faire à ce moment-là, il peut manquer.
Exemple de publication post-événement:
Un exemple de discussion après une réunion:
6. La présence d'orateurs et de sujets de discussion.
Plus de détailsIl s'agit de la partie la plus importante et la plus difficile de l'organisation. Ici, nous sommes confrontés à des problèmes, à la fois la recherche d'orateurs et la disponibilité des sujets.
Voici juste une courte liste d'activités que les organisateurs font pour impliquer les gens:
- Nous recherchons les sujets à l'avance, élaborons un plan de performance pour plus d'une semaine. Au début, nous avons recherché des sujets au début de la semaine, et jeudi nous avons dû parler.
- Nous allons dans les canaux de commande et demandons explicitement: y a-t-il des sujets pour DevForum?
- Nous menons des conversations personnelles avec les programmeurs, les encourageant à performer. Nous justifions la valeur pour le conférencier de participer: une compréhension plus approfondie du sujet, l'expérience de la parole, l'intérêt public, le matériel pour un futur article, une conférence.
- Nous jetons dans la chaîne des sujets de discussion que les gens seraient intéressés à écouter. Les développeurs avertis peuvent répondre et agir en tant que conférenciers.
- Nous répondons à des événements socialement importants, organisant indépendamment des discussions sur des sujets de développement problématiques.
- Nous regardons les conférences passées avec nos participants. Après avoir assisté à des conférences, il y a toujours quelque chose à dire.
- Suite aux résultats de conférences importantes pour nous, auxquelles ont assisté de nombreuses personnes de notre part, nous organisons une discussion au format "3 meilleurs reportages du dernier Highload ++".
- Nous invitons des intervenants externes.
Quelque chose d'autre d'important
Il peut sembler que tout est simple (ou vice versa, rien n'est clair), je vais donc énumérer quelques autres caractéristiques de l'organisation qui doivent être prises en compte et gardées à l'esprit.
Les organisateurs doivent travailler avec des conférenciers. Nous résolvons la peur de parler en nous aidant à préparer le discours. La paresse ou la désorganisation est stoppée par une demande de formuler le sujet à l'avance, même sous forme de projet, et avec la date exacte du discours.
Parfois, il n'y en a pas. Il y a des moments où tant de choses ont été trouvées, parfois quand il y en a peu. Dans ce cas, vous ne pouvez pas annuler catégoriquement l'événement. Nous devons essayer de trouver des sujets ou parler pour nous-mêmes. Les organisateurs sont également des développeurs, nous avons donc toujours quelque chose à dire. Vous pouvez recourir à des astuces, organiser des discussions plus libres.
Qualité vidéo et sonore. C'est un moment purement technique, mais il est important pour les gens que le son soit bon (vérifiez la connexion et Internet à l'avance), et la démonstration du code à l'écran est lisible. Même le sujet le plus intéressant, rempli de défauts techniques, peut aliéner les téléspectateurs.
Nous accumulons du matériel. Les réunions doivent être enregistrées. Nous avons une archive de vidéos, avec des présentations et des documents supplémentaires qui s'y rattachent. Il y a des listes de lecture sur YouTube. Nous mettons tous les enregistrements dans notre système de documentation, où il y a une recherche en texte intégral et vous pouvez trouver le sujet d'intérêt après et vous familiariser.
Dédié aux équipes de développement dans lesquelles il n'y a pas de gestionnaires dans lesquels vous travaillez sur un seul code, dans lesquelles les développeurs sont intéressés à savoir ce qui se passe, pour les personnes qui veulent se développer et aider les autres à se développer, ces équipes pour lesquelles la confiance est importante à l'intérieur.
De Dodo Pizza Engineering avec l'humanité