 Donc, j'ai une question pour vous. Je voudrais savoir qui n'est pas un English native speaker. Dis-moi. Ok. Pour ceux qui ne savent pas, je parle anglais maintenant. Donc la session sera en anglais. Je pense. C'est ok pour vous? Ok. Donc, on commence. Je suis Alexie Montville. Je suis Frédéric Le Pied, un VP Software Engineering à Tinovance. Je suis en train de travailler sur un agile. La mission de la compagnie est de construire l'infrastructure d'open cloud. Nous sommes maintenant 120. Nous étions 20 personnes, une année et un demi d'un an. Donc, nous sommes une grande compagnie. Nous avons décidé de construire la compagnie dans un agile. Donc, sans la bureaucratie et la hierarchy. Donc, nous allons parler plus de cela dans quelques minutes. Si vous voulez un tweet sur la session, nous serons très heureux. Si vous voulez continuer la conversation après la session, ce sera bien. Donc, on commence. Qu'est-ce que l'agile? Je pense que vous avez tous entendu de l'agile. Comme certains de vous, peut-être que vous avez essayé d'être agile. Je sais que c'est très difficile. Nous allons rapidement voir ce que l'agile est et ce que l'agile est. Nous utilisons l'agile à l'intérieur de la compagnie. Ce sont les valeurs de l'agile. Vous aurez beaucoup de valeurs quand vous parlez de l'agile. Et beaucoup de pratiques. Il y a des différences entre les valeurs et les pratiques. Certaines valeurs ici sont importantes pour moi. L'agile travaille sur un truc à l'heure. Donc, vous serez vraiment concentrés sur ça. Et vous serez le meilleur pour travailler sur ça. Respecte pour les gens, respecte pour les autres. Et l'élimination entre les gens, c'est vraiment important pour nous. Je ne vais pas passer le reste. Mais je vais dire, read the agile manifesto. Read the scrum values. Vous verrez beaucoup de ce que ça peut être inspiré pour vous. Peut-être qu'on peut demander qui fait le scrum. Peut-être. Oui. Nous allons rapidement sur ça. C'est le scrum framework. Nous allons tous faire ça. C'est vraiment important. Les pratiques à l'agile, les valeurs, les stand-up, devant un bord, qui montre votre avancement, votre progrès en développant quelque chose. Les pratiques à l'agile, les valeurs retrospectives. Vous devez prendre du temps pour réfléchir sur vos pratiques pour augmenter votre travail. La photo est de l'Akan Force. Vous pouvez regarder son travail. Il explique tout ce que l'agile fait avec Ligo. C'est vraiment grand. Les valeurs à l'agile, les pratiques à l'agile, les valeurs à l'agile, les programmations sur le même bord. La conversation, la conversation spontanée. La discussion sur le même bord. Et quelque chose comme ça. Quand nous travaillons avec Open Source, nous parlons des équipes distribuées, nous pouvons voir que toutes les pratiques, toutes les pratiques à l'agile sont en faveur des équipes collocées. Nous travaillons avec les équipes distribuées. Aujourd'hui, nous avons beaucoup de means pour travailler distribuées. En avance, nous sommes assez distribués. Vous pouvez voir ici l'extraction de la Wiki où on vous montre où tous nos collaborateurs sont locés. En Chine, en Indie, en France, en Montréal, en Canada et en États-Unis. Nous sommes assez spread. Quels sont les bénéfices de la distribuée ? Le meilleur intérêt de la distribuée est d'aider les talents où ils sont. C'est très important, parce que souvent, nous avons besoin de trouver un bon talent pour nous aider à contribuer et à développer nos softwares. Nous avons besoin d'aider les talents où ils sont. C'est très important. Ce qui est important, c'est d'aider les gens à travailler à l'hôpital. Nous avons beaucoup de temps sans travailler pour aller à l'hôpital. C'est très efficace pour les employés. Les équipes distribuées, c'est un équipe de collocéatrices. C'est un équipe de collocéatrices. Toutes les personnes sont remotely. Nous avons un mix entre les deux. C'est le meilleur, en fait, en théorie. Parce que vous voulez avoir ce type de communication à la vitesse de la communication. Nous allons voir comment nous comblerons. Il y a des difficultés. Vous avez vu que nous avons étendu plusieurs zones de temps. Nous avons besoin de trouver un overlap pour faire la rencontre. Pour exemple, nous avons besoin de décider, dans un équipe, quand est-ce que l'équipe se termine? C'est évidemment pas au début de la journée pour chaque personne dans le équipe. Nous avons des problèmes de facilitation d'activités. Quand vous commencez un rétrospectif, vous êtes en train de voir les aides-breakers pour établir le mindset de l'équipe pour avoir des activités, pour travailler ensemble, pour commencer la rencontre. Et quand vous êtes remotely, tout le monde est derrière cet ordinateur et vous dites, ok, quels aides-breakers je peux trouver et c'est assez difficile pour nous de trouver des activités. C'est assez difficile quand vous travaillez avec des gens et que vous essayez d'adapter l'agile sur cet ordinateur. Comme je l'ai dit, nous essayons d'avoir deux niveaux de communication, l'un sur les machines de café et l'autre avec les gens qui travaillent remotely. Ce que nous faisons, c'est que nous poussons les gens à travailler remotely, même si ils sont à l'office. Cette fois, ils sont utilisés à travailler remotely et qu'ils comprennent ce que ça veut dire, d'être seul à cet ordinateur. Et de cette façon, nous essayons d'avoir tous les ressources de la communication avec les aides-breakers. C'est-à-dire que nous voulons utiliser les tools électroniques pour communiquer. Chats, e-mails, Wikis, ce genre de tools. C'est très important pour Flavis. Une chose qui aide les gens à l'office va aussi travailler de temps en temps. Ils ne vont pas oublier à l'hôpital. Ils ne vont pas avoir la conversation avec la machine de café. Vous devez avoir de l'explicit et de l'explicit. Vous ne pouvez pas dire OK, je l'ai dit. Oui, où? Vous l'avez dit. Et vous l'avez écrit. Vous avez besoin de les tools? Oui. Nous forçons les gens à l'avion, de ne pas être en contact en permanence. Nous sommes tous tous dans le château par des équipes. Chaque équipe est dans le château et ils disent hi dans le matin. C'est comme si ils étaient autour de la machine de café. Ils discutent des choses qui n'ont rien à faire avec le travail et ils se socialisent dans les équipes. Certaines équipes préfèrent les voir. Certaines équipes sont bonnes avec l'audio. Mais tous les jours ils ont des contacts. C'est mieux pour la vidéo mais certains équipes ont décidé que c'est mieux pour l'audio. C'est principalement parce que c'est faire leur computer pour les e-mails. Nous essayons de poursuivre tout dans la week-end. De cette façon, nous pouvons avoir des newcomers qui sont conscients de ce qui a été décidé et ce qui a été travaillé sur les produits prévus. Et bien sûr, nous utilisons un secteur de software. C'est notre seul outil qui nous rend dans l'open stack. Nous avons notre code-review-système basé sur GARIT. Nous avons notre propre intégration continue et de bug-tracking. Tout est tracté et est disponible. Les gens sont conscients de ce qui se passe sur toutes les équipes. Nous utilisons un secteur de software qui est une solution pour nos clients d'internationalement. Nous pouvons dire que nous voulons notre propre champagne parce que nous sommes français. C'est important. C'est aussi une transition pour les sociologistes. Si nous voulons collaborer et travailler ensemble, nous devons connaitre tous les autres. Nous devons établir les liens entre nous. Nous devons établir les métaux. Évidemment, l'open stack est une opportunité d'établir les métaux. Ce n'est pas tout le temps. Nous sommes seulement 30 ans. Mais il y a beaucoup de gens à l'établir. Nous devons établir les métaux. Nous devons travailler ensemble en même endroit. Et puis ils peuvent travailler plus facilement quand les remords sont établis. C'est important que les équipes forment que nous rencontrent physiquement. Et puis, c'est plus facilement plus facilement. Nous avons de nouvelles offices dans Paris et Montréal. Nous pouvons organiser les métaux dans tous les offices. Nous organiserons les métaux régulièrement sur la technologie, les softwares, etc. ou d'autres choses qui sont professionnelles ou non pour établir les gens ensemble, d'aider à travailler ensemble. Nous connaissons tous les autres. C'était un événement où nous avons établi les nouvelles offices. Nous avons établi les stickers pour décorer tous les offices. Nous pouvons faire des personnes. Comment nous le faisons ? Oui. Je parle d'un team de développement, un team de développement de software. Quand nous sélectionnons de rejoindre notre équipe, les critères principaux aussi pour travailler remotely ou dans notre office, c'est un haut niveau d'autonomie. C'est très important pour nous parce que nous avons besoin d'être en charge de leur travail et d'acte et d'interact avec les communautés publics. Ils doivent être autonomes. C'est très important. C'est la chose importante. Et après la prochaine chose très importante c'est les techniques technologiques. L'entraînement d'entraînement est très difficile parce que le projet est très nouveau. C'est-à-dire que nous regardons les skills qui sont utiles pour développer l'entraînement d'entraînement. C'est-à-dire les lunettes, les storages, les opérations les langages, le Python ce genre de... Et puis, nous souhaitons les gens de travailler sur l'entraînement. Et aussi, c'est très important de pouvoir travailler sur l'entraînement c'est de avoir une bonne exposition pour la contribution de l'entraînement. Donc c'est facile pour les nouveaux commerces d'interact avec les communautés d'être capable de chatter dans le mailing list d'aller dans l'IRC avec les gars. C'est quelque chose que vous devez apprendre. Il peut être... Vous pouvez entraîner les gens pour acheter ce skill mais c'est mieux pour, dans notre opinion si nous avons un début. C'est aussi un mindset donc c'est facile de regarder pour cette espèce d'expertise. Est-ce que vous pouvez utiliser la mic ? Juste une question quand vous avez dit « seniors » Qu'est-ce que vous considérez « seniors » ? Qu'est-ce que vous considérez « seniors » ? « seniors » pour nous, c'est quelqu'un qui a une expérience priorite et contribuant à un grand projet d'entraînement et qui peut être autonomique mais qui n'a pas besoin d'aide d'autres pour faire leur travail. Donc il peut être un très jeune peuple en fait. Ce n'est pas juste un cas d'âge. C'est une autre question ? Oui. Sorry. Nous n'avons pas écouté. Comment vérifiez-vous au niveau de l'autonomie durant le processus de recrutement ? C'est une bonne question. Disant une question sur leur comportement quand ils mettent un problème sur ce qu'ils vont faire. Faisant cela. C'est généralement une ou deux questions pour comprendre ce qu'ils ont besoin. Si ils ont besoin vraiment de l'aide et qu'ils ne savent pas comment demander pour l'aide, c'est assez intéressant. Si ils savent comment demander pour l'aide, ok, vous savez que ce n'est pas un problème. Donc, oui. Normalement, quand ils ne sont pas seniors ils travaillent dans nos offices pas récemment. C'est très important parce que ça va se faire si on a des gens qui travaillent récemment dans les deux juniors. Donc, nous les prenons dans nos offices en Bangalore, Montréal ou Paris. Et après un mois ou six mois pour un an, ils peuvent y aller et travailler récemment. Ok. Ils peuvent commencer et vous pouvez aussi commencer si vous voulez, il y a un lien. Non. Donc maintenant, vous avez été récouru. C'est votre travail un jour dans la compagnie. Donc, maintenant, vous savez que vous avez besoin de穿er un tas pour rejoindre la compagnie. Non? Ok. En fait, le gars est en train de穿er un tas dans l'interview. Tais discrimination. Tais discrimination. Donc, pour le processus d'embordage ce que nous avons trouvé très important c'est de donner un corps. C'est quelqu'un de la équipe qui va aider le newcomer à trouver sa façon dans l'innovation. Donc, comme tous les gens sont très autonomistes ils travaillent seul sur leur côté. Donc, ce n'est pas facile quand vous arrive dans votre place. Donc, ce programme de bodice est très, très important. C'est important pour une bonne intégration pour trouver votre façon dans la communication de trouver les bonnes personnes. C'est très, très important. Et aussi, nous avons designé un programme pour 20 personnes pour travailler dans l'open stack. Donc, c'est très important pour avoir un bon réflexe parce que tous les projets d'open source sont différents. Et l'open stack est un grand projet. C'est l'un des plus grands projets d'open source. Donc, il a ses own rules pour contribuer. Donc, vous devez savoir comment faire vos reviews, quels tools vous utilisez pour préparer votre environnement, pour pouvoir débugger vos nouveaux développements ou vos fixations de bug. Dans la liste de mail, où vous pouvez demander pour aider ce genre de choses. Et le programme de tournage est designé pour aider les newcomers à faire leur première patch et leur première comité et l'avite acceptée. Donc, dès que la patch est acceptée, le programme de tournage est terminé pour les newcomers. Donc, c'est l'idée. Donc, ça peut être très vite pour les personnes qui sont déjà contribuées à l'open stack mais pour les personnes qui n'ont jamais contribué à l'open stack ou à un projet d'open source il peut prendre 2 ou 1 mois pour réussir à avoir un patch accepté. Et pour les personnes qui travaillent régulièrement, ils vont prendre 2 ou 4 weeks dans un de l'office pour rencontrer les gens, pour savoir les gens. Oui, c'est important d'avoir un lien physique au début de la nouvelle tournage. Parce qu'après nous, on va l'inforcer. Il y a aussi un grand effort pour le développement de talent. On a dit qu'on va essayer d'aider les personnes qui sont expérimentées à l'open stack ou à l'open source développement mais nous savons qu'on ne va pas recruter les stars rock dans l'open stack. Nous n'avons pas besoin de... Oui, nous n'avons pas besoin. Nous n'avons pas besoin de ça. Non, nous n'avons pas besoin d'un conflit. Donc, on va entraîner les gens pour devenir des plus grands contributaires au projet. Donc, il y a un effort à mettre le développement de talent dans les équipes et on va expérimenter les développeurs pour entraîner les autres développeurs dans l'équipe. Expérimenter dans un fil parfois c'est un gars de 20, 22, 23 ans. On va transmettre son connaissance. Ce n'est pas expérimenté dans un fil. On va travailler pour le transfert. Nous allons avoir des choses à dire sur ce sujet. Oui, l'entraînement interne. Donc, dans chaque équipe ils peuvent décider de transmettre leur connaissance. Ce n'est pas seulement un à un, mais d'avoir des entraînements pour les autres groupes des équipes. C'est un processus que nous essayons de mettre en place continuement. Parce qu'il faut apprendre un nouveau projet, un nouveau skill, un nouveau tool qu'on veut essayer. Et chaque sprint on va avoir un temps délicat pour l'entraînement interne. Ok. Nous parlons d'agile. Et évidemment l'agile est pas si grande parce que nous sommes deux, en Paris et en Montréal. Et nous avons construit une guilde composée d'une personne de team pour team pour partager la connaissance d'agile pour apprendre comment développer leurs skills d'agile pour comprendre ce qui est important dans certains comportements dans leurs équipes et donc ils soutiennent leurs équipes pour improvement leur pratique pour développer leur pratique. C'est déjà dit que nous avons travaillé ensemble. C'est important d'avoir cela. C'est très important. Nous avons fixé une façon de travailler dans l'open stack. Chaque six mois nous avons une nouvelle réelle. Nous base notre base à l'intérieur de nos teams sur ces réelles. La idée est d'avoir chaque 3 mois de notre projet en fait et d'avoir 2 semaines. C'est facile dans l'open stack parce que de ces réveils dans un projet d'open source il peut être très difficile parce que vous ne savez quand la réelle va arriver et cela fait notre réelle. La difficulté est d'avoir compris par le département de marketing parce que nous devons être alignés sur ce date et nous ne pouvons pas changer et nous ne pouvons pas décider quand la réelle arrive. C'est facile pour le développement mais pas pour le marketing. Ils vont s'adapter à la réalité. Open source ? Oui C'est ce que nous faisons. Donc basiquement on parle avec tous nos développements dans l'open source et nous poussons plus plus quand nous travaillons dans un projet d'open source pour nos customers on ne met pas un patch dans la production qui n'a pas été margeable. C'est très important pour nous. C'est aussi un château différent. Nous discutons avec nos customers parce qu'ils veulent leur feature ils veulent leur truc mais ils ne veulent pas le partager. Donc ce que nous faisons c'est que ils ne veulent pas d'avoir leur patch margeable dans le projet on charge 4 fois. Donc c'est un bon moyen de le faire. Et dans l'open stack en fait les customers comprennent cela très facile parce que le projet est très rapide. Si nous voulons maintenir un fork pour eux il sera très difficile très facile et c'est pourquoi nous le chargeons. Ce n'est pas parce que nous voulons charger 4 fois pour des raisons mais c'est parce que ça va coster 4 fois le prix. Donc l'open stack dans cet area nous aide à changer le mindset de nos customers. Certains ont déjà essayé de fork quelque chose et ont réalisé 6 mois plus tard que c'était vraiment une bonne idée. Donc ça nous aide. Et donc la question que j'ai entendu en utilisant un gel en faisant l'open stack c'est que vous ne savez quand c'est fait. Et dans un gel vous voulez savoir quand c'est fait. Comment on le fait. Bien sûr et bien c'est difficile dans le cas il peut prendre un long temps. Donc à la fin de l'open stack vous pouvez développer votre patch vous pouvez transmettre votre patch mais ce n'est pas déjà donc la définition que nous avons c'est que l'open stack est transmettue. Et donc nous devons suivre dans les prochains points que l'open stack sera accepté ou pas il sera un extra load pour l'open stack pour continuer à suivre les patchs. Donc deux choses qui ne sont pas vraiment un gel nous allons avoir plusieurs choses dans le progrès parce que nous avons plusieurs patchs et ils sont tous dans un different statut et donc nous ne devons pas concentrer sur une chose nous devons suivre le travail que vous avez fait avant dans un prévu sprint ce n'est pas si facile. Donc oui, les développeurs peuvent avoir environ 6 ou 10 patchs en parallèle en attendant pour un progrès. Oui. Comment le test fonctionne ? pouvez-vous utiliser le micro s'il vous plait ? Oui, s'il vous plait. Comment le test fonctionne dans ce cas ? 2 semaines. Oui, nous avons d'autres 2 semaines. Mais vous ne pouvez pas tester jusqu'à ce que votre merge arrive ou quand vous commencez le test ? Oui, l'idée est que la définition que nous avons faite est quand le patch s'est rendu. Ce n'est pas quand le patch s'est rendu. Donc après la suivante sprint nous continuons de suivre le statut des patchs et nous continuons de travailler sur eux si quelqu'un a demandé quelque chose. Donc, nous avons des temps d'essayer d'améliorer l'idée. Je pense que l'idée de faire le 4x pour un patch s'est rendu. Et avez-vous des métriques qui disaient qu'il est 4x plus expensif d'un point de développement ? Ou avez-vous trouvé un point de paix ? Non, c'était juste... On n'a pas des mesures et 4x c'est suffisant d'assurer qu'il change son mind. Donc, vous devez le demander, est-ce que c'est ça ? Nous souhaitons une solution basée sur l'open source et nous contribuons à l'open source. Et Oui, nous faisons un développement d'open stack mais au-delà d'open stack des frameworks technologiques. Donc, nous développons des solutions pour nos customers. La première c'est un service provider. C'est de pouvoir devenir un service provider interne service provider public service provider par ajouter sur l'open stack des CRM des systèmes de bilingue des e-commerce pour acheter vos instances, vos storages, etc. Et nous travaillons avec beaucoup de customers autour de le développement de software. Donc, nous construisons comme je l'ai dit le factory de software pour reproduire le développement d'open stack de l'open stack. Donc, toutes ces choses donnent des problèmes à nos producteurs parce que ce n'est pas seulement un software interne. Oui, oui. Oui. D'accord. Normalement, les stockholders sont des utilisateurs, d'exécutifs, de marketing, de recherche, etc. Mais quand nous travaillons avec un projet d'open source, il y a un nouveau stockholder qui est la communauté. Donc, nous avons discuté un peu les schedules, les schedules fixés. Donc, c'est une partie de ça. Mais aussi, nous devons aligner nos produits avec le projet de roadmap. Donc, c'est quelque chose que le producteur doit comprendre que quelque chose peut être difficile pour eux parce qu'ils doivent suivre un petit peu ce qui se passe dans le design submit et ce qui se passe dans la mailing list. Ils doivent suivre un petit peu de ces activités. Et c'est pas si common d'avoir un producteur qui a ces skills et qui veut suivre un projet d'open source. Et donc, nous essayons de faire un agile avec nos clients. Certains de nos clients sont essayés de faire un agile interne, donc c'est facile d'expliquer aux eux les bénéfices de faire ça. Certains ne sont pas si traînés avec ça et ils veulent leur grand projet. Ils veulent leur grand projet. Et ils n'ont pas vraiment qu'il sera fait. Ils disent OK, nous avons besoin de ça dans 6 mois. C'est très loin et ils ne sont pas si clés sur ce qu'ils veulent. Donc, nous essayons de travailler avec nos clients et la première chose nous... C'est pas exactement ça. C'est pas la première chose. Mais on peut essayer avec celui-là. Donc, c'était la solution pour nos clients. Oui. Donc, la idée est qu'on utilise beaucoup d'intégration continue. Nous faisons une intégration continue sur OpenStack sur un autre projet qui intégrerait dans nos systèmes de intégration continue. Et nous avons offert la solution de cette façon pour nos clients en customisant les déploiements et les solutions pour eux. Ah oui. Je me souviens que j'ai changé l'ordre. OK. Et puis si quelqu'un nous présente pour la présentation de notre VP notre produit VP d'hier il explique que à la fin le client décide si il a pu mettre dans la production ce qu'on a pour lui. Donc, j'ai une picture de la grande rède pour ceux qui ont voulu l'hier d'hier. Et ce que nous faisons aussi c'est la première chose qu'on a appelé le Discovery Workshop c'est deux jours deux jours où nous nous prenons dans le même salle des utilisateurs des clients des développeurs des personnes qui utilisent le cloud pour faire des développements des solutions pour les utilisateurs et des opérateurs des gens qui opéreraient le cloud opéreraient l'infrastructure et nous ferons tous ces gens dans le même salle pour deux jours et nous prenons leur projet. Et c'est très intéressant d'avoir tous ces gens dans le même salle et nous prenons aussi des gens dans nos interventions de l'opération de développement et de l'esprit productif. Et à la fin du workshop ils ont une vue une vue de leur projet priorisant le futur et nous pouvons définir la prochaine projet. Et ensuite nous pouvons commencer avec un processus d'intervention et délivrer différentes choses chaque deux semaines. Et les utilisateurs vont essayer les choses qu'on délivre chaque deux semaines. Donc ils vont apprendre comment utiliser leur cloud et parfois ils vont vraiment prioriser et changer la priorité du futur dans le projet. Et c'est ce que nous faisons des contributions à l'opération mais nous trouvons que c'est plus long pour ces choses que deux semaines. Donc c'est difficile. C'est ce que j'ai dit avant. Nous continuons de suivre les patchs pour les prochaines points. La définition est que nous avons accepté la lettre. Quand nous déploie une solution pour un customer d'exemple le secteur de software on a déjà une version de ça. On ne doit pas faire des développements pour une grande partie de la chose. C'est seulement un déploiement et c'est seulement un déploiement dans le projet mais nous avons plus de temps pour le déploier. Il ne faut pas avoir le premier print. Normalement nous parlons de le déploiement print et le déploiement print. En fait. Donc le meeting et le room avec les customers avant qu'ils déclenchent ce relire c'est que quand vous faites toutes les histoires vous crée les histoires. Vous pouvez bouger dans chaque sprint. En fait dans le workshop nous prioritons les casins et puis dans le design print le premier design print nous couvons les casins dans les histoires en fait. Ok mais ce workshop c'est quand vous décidez avec vos stakeholders exactement ce que il va une idée ce qui va arriver dans le relire. Exactement les casins et ce sont les uns qui sont les plus importants. Ok une autre question c'est ce que vous avez mentionné et je pense que vous avez parlé quelques minutes sur ce que vous considérez dans le sprint. Donc je pense que mon collègue a dit qu'il a mentionné deux semaines c'est très difficile. Donc vous avez juste tourné et puis les tests peuvent arriver après ces deux semaines. Est-ce correct ? Oui c'est correct mais seulement sur le soutien de développement sur le soutien de développement nous avons des produits qui sont testés qui sont très stabilisés donc si nous si nous sommes dans le scope de configuration de nos solutions actuelles nous n'avons pas besoin d'avoir ces patches acceptés à l'extrême parce que la solution est déjà capable de faire ce que le customer veut. Ok. C'est différent. C'est pourquoi dans le sprint de développement nous utilisons nos solutions et ces solutions sont prises pour être déploies donc nous n'avons pas besoin d'avoir des patches acceptés. Ok. Merci. Mais vous n'avez pas dit que vous êtes 100% upstream ? Oui. Alors qu'est-ce que quelque chose est réjecté ou qu'est-ce que c'est pas accepté ? Oui c'est une bonne question alors bien sûr. Donc quand on a dit que c'est la définition que nous avons faite on essaie d'avoir des ingénieurs et des contributaires dans toutes les zones d'open stack donc nous travaillons avec toutes les projets les projets de l'open stack donc nous pouvons discuter si c'est le bon approche avant de commencer à développer le patch donc nous avons plus de chances d'être acceptés à l'extrême donc on essaie de minimiser les problèmes de rejection mais ça peut arriver donc nous avons besoin de travailler encore et de commencer le cycle de l'open stack encore. Oui. Fais attention à cette question. Ça dépend pourquoi c'est réjecté. Oui. Si c'est réjecté parce que c'est un problème d'implementation ou c'est qu'on n'a pas le droit ou qu'on n'a pas la photo de notre contribution c'est probablement intéressant de challenger l'implementation et de essayer de l'adapter d'une autre façon si c'est le fonctionnement qui est le problème on va probablement penser sur ça et on va revenir dans le backlog c'est un autre problème je pense que nous sommes prêts comme vous pouvez le entendre et je ne sais pas comment c'est pour s'amener sur l'ombre ce que nous avons dit aujourd'hui c'était très fort pour ça agile c'est un moyen commun d'essayer de travailler pour notre équipe et ça nous aide à travailler avec notre équipe et ça nous aide à travailler avec le projet avec le projet donc c'est très important je voudrais assister au l'entraînement et la socialisation. L'entraînement est très important pour former les équipes et pour avoir une bonne socialisation. C'est important pour avoir un équipe de performance. Donc c'est très important pour mettre des énergies, des efforts, des investissements, du travail, de mettre les gens ensemble. C'est quelque chose que si vous avourez ça, vous aurez du travail, à mon avis. Et l'entraînement est une bonne opportunité parce qu'il y a le sommet de chaque six mois. Ça nous aide à nous rappeler que nous avons besoin d'être ensemble. Nous faisons une vraie opportunité. Nous sommes l'opensource, c'est notre DNA, c'est notre travail. Donc nous pensons que c'est une bonne façon de faire. Et la dernière chose, nous essayons de créer une nature, un agile et une culture d'opensource dans la compagnie. Et je pense que ça peut être intéressant pour les autres à essayer de adapter la façon dont les projets d'opensource travaillent dans leur compagnie, à penser que si tous les IT sont considérés comme les projets d'opensource, ça peut être intéressant de penser sur ça, comment ils peuvent travailler ensemble dans leurs compagnie. Et donc nous sommes prêts. C'est incroyable. Merci. Je ne sais pas si vous pouvez prendre des questions. Oui, peut-être que nous puissions prendre des questions. J'ai ça pour la première question, mais il y a déjà des questions, donc c'est pas très faible. Mais j'ai aussi des candies. Donc, si vous voulez une question, non ? Non ? Oui, oui, vas-y. Je vais garder le doigt. Vas-y, question. Oui, vous avez le doigt. Merci. Avec deux sprints, combien de temps avez-vous pris entre les sprints pour les plans de sprints et le respect ? Et est-ce que vous avez besoin d'un careur et de la nourriture de votre backlog pour garder ces deux sprints ? Ça dépend des équipements, mais certains équipements sont faits avec leur plan et leur réveil dans deux heures. Certains ont besoin de plus de temps. Et parfois, le fixe de l'échec d'une heure pour le retrospectif n'a pas suffisamment besoin de plus de temps. Donc, ça dépend. Mais c'est une ou deux heures pour chaque cérémonie. C'est aussi en anglais. Oui, nous sommes en temps, mais je peux encore les décider. Donc, si vous voulez, vous pouvez avoir, et il y a d'autres doigts sur notre boule d'eau. Donc, s'il vous plaît, vous pouvez le faire. Merci beaucoup.