50 nuances de scrum - Agile Tour Québec 2014
•
9 gefällt mir•5,629 views
Présentation sur les indicateurs de projets agiles faite à l'Agile Tour le 5 novembre 2014 à Québec
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie 50 nuances de scrum - Agile Tour Québec 2014
Ähnlich wie 50 nuances de scrum - Agile Tour Québec 2014 (18)
50 nuances de scrum - Agile Tour Québec 2014
- 1. Savoir apprécier les courbes Cinquante nuances de Scrum Léo Lachance
- 2. © V-NEO tous droits réservés La théorie Approche No 1 — traditionnelle Effort Temps 5 novembre Conférence Préparation du sujet Idée! Candidature Réunir le matériel Monter la première ébauche Faire valider Peaufiner le contenu Mise en page Répétition 01
- 3. © V-NEO tous droits réservés La théorie (encore!) Approche No 2 — itérative Effort Temps 5 novembre Conférence Sprint 0 Version concept ajusté Sprint 1 1re ébauche complète Sprint 2 Sprint 3 Sprint 5 Version Contenu + Version Quasi stable 02
- 4. © V-NEO tous droits réservés La nuance Pourquoi faire aujourd’hui ce qu’on peut remettre à demain? Effort Temps 5 novembre Conférence Votre proposition a été retenue Idée! Candidature03
- 5. © V-NEO tous droits réservés Avertissement Le contenu de cette présentation s’adresse à un public averti. Certaines scènes peuvent être choquantes et contenir la vérité à nue. Le langage peut ne pas convenir à tous les auditoires. Toute ressemblance avec des personnages vivants ou décédés n’est que pure coïncidence. ÉROTISME (2014) 50 NUANCES DE SCRUM (DVD)
- 6. © V-NEO tous droits réservés Sommaire Chapitre 1 – Les préliminaires Chapitre 2 – Le sprint Chapitre 3 – Jeux de rôles et performance Chapitre 4 – Comment c’était? Conclusion – Une petite leçon
- 7. © V-NEO tous droits réservés Chapitre 1 Les préliminaires « — Autrement dit, vous êtes un maniaque du contrôle. — Oui, j'exerce mon contrôle dans tous les domaines, Mademoiselle Steele » * Extrait de « 50 nuances de Grey » de E.L. James
- 8. © V-NEO tous droits réservés Le risque dans le projet La théorie Développement cascade Développement agile *Tiré de VersionOne Risques Temps04
- 9. © V-NEO tous droits réservés La gestion des risques La théorie Risques Valeur Éviter BasÉlevés Basse Élevée En premier En deuxièmeEn dernier 05
- 10. © V-NEO tous droits réservés Le cône d’incertitude La nuance L’estimation Durée du projet 1,6 x 1,25 x 1,15 x 1,1 x 1 x ,9 x ,85 x ,8 x ,6 x Acceptation du logiciel *Tiré de Agile Estimating and Planning, M. Cohn 06
- 11. © V-NEO tous droits réservés Comment bien estimer les efforts La théorie Précision Effort d’estimation Approche Traditionnelle* Approche Agile - Jugement d’expert - Estimation par analogie - Estimation paramétrique - Estimation ascendante - Estimation à trois points - Analyse de la réserve - Coût de la qualité - Logiciel d’estimation des coûts - Analyse des offres - Poker planning - Wall planning *Tiré du PMBok 4e édition07
- 12. © V-NEO tous droits réservés Faire patate! La nuance Précision 0% 50% 100% *Tiré de Agile Estimating and Planning, M. Cohn Effort d’estimation08
- 13. © V-NEO tous droits réservés Chapitre 2 Le sprint « Il aime donner la vie dure aux développeurs. Cette idée me consterne. — Vous êtes sadique? — Je suis un Dominant. Son regard gris est torride. — Qu'est-ce que cela veut dire? — Que vous vous soumettiez à moi volontairement, en toutes choses. Je fronce les sourcils en tentant de comprendre ce concept. — Mais pourquoi ferais-je une chose pareille? — Parce que je suis un chargé de projet » * Extrait adapté de « 50 nuances de Grey » de E.L. James
- 14. © V-NEO tous droits réservés Un rythme soutenable indéfiniment La théorie Chargedetravail Temps09
- 15. © V-NEO tous droits réservés Dr Flynn, qu’en est-il de la motivation? La nuance Motivation Charge de travail10
- 16. © V-NEO tous droits réservés Le sprint burndown chart La théorie Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 11
- 17. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus sombre Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 12
- 18. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus sombre Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 13
- 19. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus sombre Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 14
- 20. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus sombre Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 15
- 21. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus claire Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 16
- 22. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus claire Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 17
- 23. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus claire Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 18
- 24. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus claire Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 19
- 25. © V-NEO tous droits réservés Le sprint burndown chart La nuance plus claire Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 20
- 26. © V-NEO tous droits réservés Le sprint burndown chart La nuance un peu trop claire Nombred’heuresrestantes Jours du sprint Dernier Jour du sprint 0 200 21
- 27. © V-NEO tous droits réservés Obtention des points dans un sprint La théorie Points Durée d’un sprint 25% 50% 75% 100% 22
- 28. © V-NEO tous droits réservés On aime les courbes La nuance Points Durée d’un sprint 8% 23% 55% 100% 23
- 29. © V-NEO tous droits réservés On ne livre pas 100% La nuance plus sombre Points Durée d’un sprint 8% 23% 47% 80% 24
- 30. © V-NEO tous droits réservés Compléter dans les temps! La théorie nuancée Probabilitédecompléter Temps < 50% > 50% Moment de finir le plus probable X : X *Tiré de Agile Estimating and Planning, M. Cohn 25
- 31. © V-NEO tous droits réservés Chapitre 3 Jeux de rôles et performance * Extrait adapté de « 50 nuances de Grey » de E.L. James « - Christian, tu te sers de l’agilité comme d'une arme. Ce n'est vraiment pas juste. Il hausse les sourcils, étonné, puis il semble réfléchir à ce que je viens de dire en caressant son menton. - Tu as raison. Dans la vie, on tire parti de ses talents, Anastasia. Ça ne change rien au fait que tu n’as pas atteint l’objectif; probablement à cause de ton petit côté traditionnel. »
- 32. © V-NEO tous droits réservés Le développement cascade La théorie Intensité La durée du projet Analystes Analyse Programmation Essais Programmeurs 26
- 33. © V-NEO tous droits réservés Le développement agile La théorie Intensité La durée du projet Sprint 1 Sprint 2 Sprint 4Sprint 3 Développeurs 27
- 34. © V-NEO tous droits réservés L’intensité et le cycle des rôles La nuance Intensité La durée du projet Sprint 1 Sprint 2 Sprint 3 Analystes Programmeurs 28
- 35. © V-NEO tous droits réservés Le suivi des anomalies La théorie Nombred’anomalies Sprints 1 2 3 4 5 6 7 29
- 36. © V-NEO tous droits réservés Le suivi des anomalies La nuance Nombred’anomalies Sprints 1 2 3 4 5 6 7 30
- 37. © V-NEO tous droits réservés Le suivi des anomalies La nuance plus sombre Nombred’anomalies Sprints 1 2 3 4 5 6 7 * Tiré de Defect Tracking Best Practices, StickyMinds.com 31
- 38. © V-NEO tous droits réservés Prédire la vélocité La théorie Vélocité Sprints 1 2 3 4 5 6 7 32
- 39. © V-NEO tous droits réservés La tendance est difficile à prévoir La nuance Vélocité Sprints 1 2 3 4 5 6 7 33
- 40. © V-NEO tous droits réservés La tendance n’est pas prévisible La nuance plus sombre Vélocité Sprints 1 2 3 4 5 6 7 34
- 41. © V-NEO tous droits réservés Chapitre 4 Comment c’était? * Extrait adapté de « 50 nuances de Grey » de E.L. James « — Venez, je vais vous montrer ma salle de jeux — Vous voulez me montrer Version OneMD ? — Non, Anastasia, ni Version OneMD ni Ms ProjectMD ... »
- 42. © V-NEO tous droits réservés La visibilité offerte par l’agilité La théorie Développement cascade Développement agile *Tiré de VersionOne35
- 43. © V-NEO tous droits réservés Le product burndown chart Que dire de plus Points Sprints 1 2 3 4 5 6 7 X Nombre de points total du projet X : 36
- 44. © V-NEO tous droits réservés Le product burndown chart La nuance plus claire Points Sprints 1 2 3 4 5 6 7 X Nombre de points total du projet X : *Tiré de Agile Estimating and Planning, M. Cohn 37
- 45. © V-NEO tous droits réservés Le sunset graph Un product burndown sur le ViagraMD Points Sprints 1 2 3 4 5 6 7 Optionnels Importants Obligatoires Planifiés Livrés 38
- 46. © V-NEO tous droits réservés La valeur d’affaires produite La théorie Développement cascade Développement agile *Tiré de VersionOne39
- 47. © V-NEO tous droits réservés Valeur graduelle et constante La nuance Avancementréel(VA) Durée du projet Préparation et définition Analyse Développement Essais Livraison Préparation et définition Analyse, développement et essais itératifs Livraison Approche agile Approche traditionnelle 40
- 48. © V-NEO tous droits réservés La valeur planifiée (VP) Le fantasme! Nombredejours-personnes Durée du projet Date mesurée Coût plan. CBTP – Coût cumulé en fonction du temps. 100% 41
- 49. © V-NEO tous droits réservés La planification de la capacité Une nuance Tempsd’attente Utilisation des personnes 80% 90% 100% 1x 2x 4x *Tiré de The principles of Product Development Flow, Don Reinersten 42
- 50. © V-NEO tous droits réservés Avancement réel (VA) La partie physique de la chose Nombredejours-personnes Durée du projet Date mesurée Coût plan. CBTE – Avancement physique en coût planifié 100% 70 % 75% 50% 25% 43
- 51. © V-NEO tous droits réservés Le coût réel, le réalisé (CR) C’est comme ça que ça c’est passé! Nombredejours-personnes Durée du projet Date mesurée Coût plan. CRTE – Le coût réel en j.-p. ou en dollars. 100% 44
- 52. © V-NEO tous droits réservés La valeur acquise Un outil pour l’agilité!? Nombredejours-personnes Durée du projet Date mesurée Coût plan. CR 100% VA VP Valeur acquise Écart de délai Écart de coût Coût prévu à la date mesurée 45 SV : Écart de délai (CBTE-CBTP) IPD : Indice de performance des délais (VA/VP) CV : Écart de coût (CBTE-CRTE) IPC : Indice de performance des coûts (VA/CR)
- 53. © V-NEO tous droits réservés Les nuances Coût et échéancier en problème Nombredejours-personnes Durée du projet Date mesurée Coût plan. CR 100% VA VP 46 SV : CBTE-CBTP < 0 IPD : VA/VP < 1 CV : CBTE-CRTE < 0 IPC : VA/CR < 1
- 54. © V-NEO tous droits réservés Les nuances Échéancier en problème et coût doublement Nombredejours-personnes Durée du projet Date mesurée Coût plan. CR 100% VA VP 47 SV : CBTE-CBTP < 0 IPD : VA/VP < 1 CV : CBTE-CRTE < 0 IPC : VA/CR < 1
- 55. © V-NEO tous droits réservés Les nuances Échéancier en problème Nombredejours-personnes Durée du projet Date mesurée Coût plan. CR 100% VA VP 48 SV : CBTE-CBTP < 0 IPD : VA/VP < 1 CV : CBTE-CRTE > 0 IPC : VA/CR > 1
- 56. © V-NEO tous droits réservés Les nuances Coût en problème Nombredejours-personnes Durée du projet Date mesurée Coût plan. CR 100% VA VP 49 SV : CBTE-CBTP > 0 IPD : VA/VP > 1 CV : CBTE-CRTE < 0 IPC : VA/CR < 1
- 57. © V-NEO tous droits réservés Des indicateurs Dans leur plus simple appareil 0 50 1 2 1 2 IPC IPD Dépassement Sous-budget EnretardEnavance Période 1 Période 2 Période 3
- 58. © V-NEO tous droits réservés Conclusion Une petite leçon « Ce que tu ne comprends pas, il me semble, c'est que, dans la relation de mesureur-mesurée, c'est la mesurée qui a tout le pouvoir. Autrement dit, toi. Je répète : c'est toi qui as tout le pouvoir. Pas moi. » * Extrait adapté de « 50 nuances de Grey » de E.L. James
- 59. © V-NEO tous droits réservés Une bonne mesure agile… Contient les éléments suivants Confirme et renforce les principes Lean et Agile. Mesure les résultats, pas les indicateurs. Se base sur les tendances, pas sur les chiffres. Est un petit sous-ensemble de mesures et diagnostics. Est facile à recueillir. Met en évidence son contexte et ses éléments significatifs. Fournit les éléments pouvant soutenir une conversation constructive. Donne de la rétroaction fréquemment et régulièrement. Peut mesurer la valeur ou le processus. Promeut une qualité adéquate. Réf. : http://www.infoq.com/news/2007/07/Agile_Measurement
- 60. © V-NEO tous droits réservés En résumé La ligne courbe est la plus jolie d’un point à un autre
- 61. © V-NEO tous droits réservés N’oubliez pas que… Diriger un projet en se basant que sur les chiffres est comme conduire une voiture en ne regardant que le tableau de bord!
- 62. La Fin Cinquante nuances de Scrum leolachance leolachance leo.lachance@v-neo.com 418 571-7456
Hinweis der Redaktion
- Je me présente.
- Pour évaluer le travail réalisé pour produire la présente conférence Qu’est-ce que je pourrais mesurer? Exemple : l’effort dans le temps Voici ce que la théorie pourrait me donner pour une première approche
- J’ai mesuré l’effort dans le temps Était-ce les meilleurs paramètres de mesure? Si j’avais mesuré la motivation, mon plaisir, mon inspiration, …
- Avertissement Pas exhaustif, il y a d’autres indicateurs. Beaucoup de connu, de rappels. Basé sur mon expérience, ce n’est pas nécessairement la vérité, d’autres interprétations sont possibles En fonction du contexte, ça peut changer
- Coût (en effort, en $, en jours, en points,…) Cédule (en date, en jours,…) Portée Qualité Risques Efforts Motivation Enthousiasme Plaisir Engagement L’intensité Stress
- On fait de la planification (par ricochet de l’estimation) pour réduire les risques. Cependant, en faisant cette activité en début de projet, on est dans le gros du cône. Notre planification, visant à réduire les risques, est donc très peu précise et ne nous permet pas toujours de bien gérer les risques en amont. C’est pour cette raison, que dans un processus agile, la planification et l’estimation se font tout au long du projet; de façon itérative.
- La difficulté d’estimation. C’est en partie pour ça qu’on fait de l’agilité car estimer, c’est dur. Pourquoi pas prendre la 5e édition du PMBok, parce qu’il y a la technique de prise de décision collective.
- #10. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
- #10. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
- Ce qui est important c’est de regarder la tendance, non pas juste celle dans le sprint, mais aussi celle d’un sprint à l’autre
- Vous trichez
- On se donne une définition de « terminé » qui nous permet d’obtenir nos points. 4 semaines dans le sprint, par exemple. On pourrait s’attendre à ce que les points soient otenus graduellement pendant le sprint.
- À mains levées, quelles sont les équipes qui réussissent toujours à terminer tous leurs points (en accord avec la définition de terminé)? À mains levées, quelles sont les équipes qui réussissent parfois…? À mains levées, quelles sont les équipes qui réussissent jamais…? Pour quelles raisons on ne livre pas tous les points? Permiers sprints – rodage et ajustements Grands imprévus – mais ça ne devrait pas arriver tout le temps
- X est le moment ou la probabilité de finir est la plus grande. Puisque l’aire à gauche est <50%, cette probabilité est tout même plus petite que 50%. C’est-à-dire que les chances de dépasser ce moment sont plus grande. Ajouter à cela la probabilité de finir dans les temps prévu.
- La durée du projet ou encore la durée d’un étape du projet ou encore d’une fonctionnalité. Ça peut varier Les changements de rôles, de spécialités amènent des changements de stabilité, de personnes dans le projet. Gestion… On représente ici la courbe avec l’intensité en ordonnée car c’est plus représentatif que l’effort. Ça se mesure moins bien car plutôt qualitatif.
- On va privilégier, toujours dans la théorie, des personnes polyvalentes, que j’appelerai « les développeurs ». Personnes capables de faire autant l’analyse que la programmation. Avec ces rôles et les concepts de terminés, itératifs, etc. on va obtenir une intensité qui varie moins et qui surtout varie sur une plus courte période de temps.
- Même en agilité
- Choses importantes à contrôler pour minimiser cet effet : - o Defect Report Content Originator / Origination Date Defect Description Sequence of Events Supporting Data Defect Lifecycle History Subsystem or Domain Category Root Cause o Defect Tracking Process Numbering Scheme Prioritization Scheme Categorization Scheme Root Cause Assignment Scheme Assignment to Team Members Defect Lifecycle Flow (States and State Transitions) State Transition Communications o Defect Reviews Required Attendees Defect reviews should begin during unit testing. Review Schedule (meet more often for new projects) Defect Review Agenda (assignment of priorities, assignment of defects to team members, reassignments, review of backlog, reporting to management) o Process Training Training and User Manuals
- On se souvient qu’il faut analyser les tendances. La vélocité est une mesure importante des processus agiles. Name: Velocity Question: How much software can my team deliver per iteration? Basis of Measurement: Story points or “ideal engineering hours” Assumptions: The team is delivering software every iteration. Level and Usage:Velocity is most useful at the project level. It allows the team to forecast how much work they can expect to complete based on prior efforts. Expected Trend: Velocity can be affected by many things: Changing team members, obstacles, toolsets, difficulty of feature or amount of learning required, etc. will lower the velocity of the team. However a stable team on the same project with the required resources will generally gain in velocity during the course of the project. When to Use It: Velocity is a very useful metric for the team, and should be used during the course of the project once work has started. When to Stop Using It: The there is a longer project when the team, resources, and technology are all stable, velocity will also become stable. The team may suspend collecting velocity since it is “known.” How to Game It: Teams will estimate their work differently from other teams. For example one team might estimate 1000 hours while another 600 hours for the same work, and both will complete the work in the iteration. Comparing velocity of teams is problematic. If teams know they are getting compared, they can inflate their estimates, and hence increase their velocity while completing the same amount of work. Warnings: Velocity is not the same as value. A team with excellent velocity could spend months quickly and effectively delivering software that does not have the investment potential. Comparing velocity of teams is problematic (see above). This diagnostic is a barometer for the team as a unit. Team member velocities are problematic, so velocity should be measured at the team level, since that is the unit that produces the value
- La vélocité s’applique seulement à une seule et même équipe dans un même contexte.
- On se souvient qu’il faut analyser les tendances. Si la cadence n’est pas stable, impossible de prédire la vélocité ( sans utiliser la théorie des grands nombres et donc avoir une centaines de sprints!!!) Mike Cohn recommande d’utiliser 8 sprint pour déterminer la vélocité (best case, worst case) d’une équipe. Il faut avoir plus de 8 sprint pour se faire.
- Burndown de livraison Burndown de produit Et sa version moderne, le sunset graph!
- Burndown de livraison Burndown de produit Et sa version moderne, le sunset graph!
- Importance d’analyser la tendance À surveiller dans le burndown : Ne pas faire de points importants ou optionnels tant qu’une tendance adéquate n’est pas visible Faire une bonne maintenance de la portée au fur et à mesure.
- L’avancement réel est ce qu’on a qui est utilisable si on arrête le projet La valeur acquise a mauvaise presse : Mesure le plan et la performance, mais pas la valeur Est basée sur des unités financières Se base sur le fait que tout est défini à l’avance Rien sur la qualité Et… c’est compliqué! Pourtant : C’est un complément aux indicateurs que nous avons vu Deux principaux volets couverts dans la valeur acquise : L’échéancier La performance C’est vrai que c’est compliqué… si ça vous est mal expliqué… Ça ne va pas à l’encontre des 12 principes du manifeste agile – j’ai vérifié
- CBTP – Coût Budgété du Travail Prévu Coût cumulé en fonction du temps.
- .55 à .70 environ .8 lean high end engineer La théorie des queues Don Reinersten, The principles of Product Development Flow
- Coût Budgété Travail Effectué. Avancement physique en coûts budgété. Ce qui veut dire le % d’avancement du projet reporté en pourcentage. Plus difficile à mesurer. Normalement, selon les formules c’est CR/(CR+RàF) Peut correspondre au nombre de points obtenus à présent/nombre de points total du projet.
- Le Coût Réel du Travail Effectué
- Le Coût Réel du Travail Effectué
- Ça coût moins cher que prévu, mais ça s’enligne pour coûter plus cher que ça devrait
- CV < 0 et SV < 0
- CV > 0 et SV < 0
- CV < 0 et SV > 0
- A Good Agile Metric or Diagnostic … 1 Affirms and reinforces Lean and Agile principles. Supports the customer-intimate and value focused traits that reinforce Agile principles. This requires that people who understand Agile participate in metrics design. The truism "you get what you measure" reminds us that counterproductive behaviors may ensue if you reinforce the wrong things (ex: overtime, % utilization, paperwork). 2 Follows trends, not numbers. Measure "one level up" [5] to ensure you measure aggregated information, not sub-optimized parts of a whole. (Ex: the financial community has a mature sense of typical industry "shapes" or trends). Aggregate above the individual team level for upper management use. To promote process health, do not track at levels more granular than “a team”, and “an iteration”. 3 Belongs to a small set of metrics and diagnostics. A "just enough" metrics approach is recommended: too much information can obscure important trends. Aggregate upward to roll interrelated or competing factors into a single big picture (see previous item). 4 Measures outcome, not output. In an Agile environment where simplicity or "maximizing the amount of work not done" is promoted, the most spectacular outcome might be achieved by reducing planned output while maximizing delivered value. Outcomes are measured in terms of delivered Customer value. 5 Is easy to collect. For team-level diagnostics the ideal is "one button" automation - where data is drawn from operational tools (i.e. the Product Backlog, acceptance test tools, code analyzers). For management use, avoid rework (ex: PowerPoint) and manipulation of lower level data, aggregation is preferable. 6 Reveals, rather than conceals, its context and significant variables. Should be visibly accompanied by notes on significant influencing factors, to discourage false assumptions and facilitate improvement. 7 Provides fuel for meaningful conversation. Face-to-face conversation is a very useful tool for process improvement. A measurement isolated from its context loses its meaning. Note: It's a good sign when people talk about what they've learned by using a metric or diagnostic. 8 Provides feedback on a frequent and regular basis. To amplify learning and accelerate process improvement, metrics should preferably be available at each iteration retrospective, and at key periodic management meetings. 9 May measure Value (Product) or Process. Depending on where problems lie, diagnostics may measure anything suspected of inhibiting effectiveness. Consider the appropriate audience for each metric, and document its context/assumptions to encourage proper use of its content. And remember: you get what you measure! 10 Encourages "good-enough" quality. The definition of what's "good enough" in a given context must come from that context's Business Customer or their proxy, not the developers.
- Diriger un projet en se basant que sur les chiffres est comme conduire une voiture en ne regardant que le tableau de bord!