final .pdf



Nom original: final.pdf

Ce document au format PDF 1.3 a été généré par LaTeX with hyperref package / Mac OS X 10.12.6 Quartz PDFContext, et a été envoyé sur fichier-pdf.fr le 20/11/2017 à 09:14, depuis l'adresse IP 193.190.x.x. La présente page de téléchargement du fichier a été vue 614 fois.
Taille du document: 20.7 Mo (47 pages).
Confidentialité: fichier public


Aperçu du document


Faculté Polytechnique

Rapport de stage
Stage en entreprise - été 2017

AW Europe - VIT Software Engineering

B ORMANS T HOMAS

Sous la direction de Monsieur S AÏD MAHMOUDI
Remerciement à mon maître de stage Monsieur J ÜRGEN JANSSENS
Ainsi qu’à Monsieur F REDERIC B URGUET

i

Table des matières
1 Introduction

1

2 Méthodologie Agile
2.1 Qu’est ce que l’Agile ? . . . . . . . . . . . .
2.2 Méthode Scrum . . . . . . . . . . . . . . . .
2.3 Méthode Kanban . . . . . . . . . . . . . . .
2.4 Méthode hybride d’AW Europe - VIT . . .
2.5 Processus de développement d’AW Europe 2.5.1 Shared Strategic Vision . . . . . . .
2.5.2 Entrepreneurial Resources . . . . . .
2.5.3 Proactive Deal Flow . . . . . . . . .
2.5.4 Balanced Portfolio . . . . . . . . . .
2.5.5 Dynamic Execution . . . . . . . . .
2.6 Cycle en V . . . . . . . . . . . . . . . . . .
2.6.1 Cycle en V d’AW Europe . . . . . .
3 Outils Atlassian utilisés chez AW Europe
3.1 JIRA . . . . . . . . . . . . . . . . . . . . .
3.2 Confluence . . . . . . . . . . . . . . . . .
3.3 Tempo . . . . . . . . . . . . . . . . . . . .
3.4 Bitbucket . . . . . . . . . . . . . . . . . .

. . .
. . .
. . .
. . .
VIT
. . .
. . .
. . .
. . .
. . .
. . .
. . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

2
2
2
4
5
6
6
7
7
7
7
7
8

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

9
9
9
10
10

4 Analyse économique de l’entreprise
4.1 Enquête GRH . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 La motivation des employés . . . . . . . . . . . . . . . .
4.1.2 La hiérarchie du département VIT Software Engineering
4.1.3 Le processus de recrutement . . . . . . . . . . . . . . . .
4.1.4 L’organisation et la gouvernance des projets . . . . . . .
4.2 Positionnement sur le marché . . . . . . . . . . . . . . . . . . .
4.2.1 Principaux produits . . . . . . . . . . . . . . . . . . . .
4.2.2 Principaux concurrents . . . . . . . . . . . . . . . . . .
4.2.3 Pression marketing . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

11
11
11
12
13
14
15
15
16
17

5 Étude des KPIs
5.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 KPIs permettant la gestion de projets . . . . . . . . . . . . . . . . . . . . . .
5.2.1 KPIs liés au temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21
21
21
22

ii

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

5.3

5.2.2
5.2.3
5.2.4
KPIs
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3.7
5.3.8
5.3.9

KPIs liés au budget . . . .
KPIs liés à la qualité . . . .
KPIs liés à l’efficacité . . .
orientés sur la méthode Agile
Burndown Chart . . . . . .
Epic Burndown . . . . . . .
Release Burndown . . . . .
Control Chart . . . . . . . .
Cumulative Flow Diagram .
Velocity Chart . . . . . . .
Epic Report . . . . . . . . .
Sprint Report . . . . . . . .
Version Report . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

6 Mise en application
6.1 Dashboard JIRA . . . . . . . . . . . . . . . .
6.1.1 Dashboard pour l’équipe Manager . .
6.1.2 Dashboard pour l’équipe Développeur
6.2 Dashboard Speed Innovation . . . . . . . . .
6.2.1 Dashboard par projet . . . . . . . . .
6.3 Dashboard Business Development . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

23
23
23
24
24
25
25
25
26
27
28
28
28

.
.
.
.
.
.

29
29
30
31
32
33
35

7 Conclusion

36

A Annexes

37

iii

Chapitre 1

Introduction
Tout au long de nos études de génie civil, nous sommes amenés à découvrir de très nombreux aspects théoriques du métier, sans pour autant toujours pouvoir mettre en pratique
nos acquis dans le cadre universitaire.
Cependant, mettre en application cette théorie est essentiel à une bonne compréhension et
une maîtrise de celle-ci. C’est pourquoi nous avons l’occasion de réaliser un stage en entreprise
de 8 à 12 semaines avant de débuter notre dernière année de master.
J’ai donc eu l’opportunité de découvrir le monde du travail au sein de l’entreprise AW, une
grande entreprise internationale dans le domaine automobile en provenance du Japon. Les
principaux produits innovants de cette firme se basent sur le développement de boîtes à
vitesses automatiques (Automatic Transmissions) et le développement de systèmes de navigation (Vehicle Information Technology). AW Europe est reconnu et apprécié par la plupart
des constructeurs automobiles pour sa culture de la qualité privilégiant l’innovation et le partenariat avec ses clients.
Dans ce rapport, je vous décrirai l’expérience vécue et le travail réalisé au sein de cette
entreprise durant 8 semaines. Le sujet principal de mon stage était :
L’étude des KPIs 1 associés aux méthodes Agile pour le développement logiciel.
Pour cela, mon stage s’est divisé en trois parties bien distinctes :
— État de l’art des KPIs existants de manière globale, puis adaptés à la méthodologie
Agile.
— Définition les KPIs actionnables chez AW Europe dans la partie. VIT 2
— Mise en pratique et intégration des KPIs à partir des outils Atlassian ou autres.

1. Indices de performance
2. Vehicle Information Technology

1

Chapitre 2

Méthodologie Agile
2.1

Qu’est ce que l’Agile ?

La méthode Agile est une approche structurée et itérative de la gestion de projet et du
développement de produits. Cette méthode est très utilisée pour le développement de produits
logiciels. En effet, celle-ci se veut plus pratique que les méthodes traditionnelles en se basant
sur la réalisation de livraisons continues aux clients. Cela permet d’impliquer au maximum le
demandeur et de pouvoir être très réactif face à ses demandes. Les procédés de développement
appliquant l’Agile se basent sur un cycle de développement itératif, incrémental et adaptatif
respectant quatre valeurs fondamentales :





Les individus et leurs interactions importent plus que les processus et les outils.
Les logiciels opérationnels sont plus importants qu’une documentation exhaustive.
La collaboration avec les clients prime sur la négociation contractuelle.
L’adaptation au changement importe plus que le suivi d’un plan.

De ces valeurs découlent 12 principes généraux qui se basent principalement sur une relation
directe entre les développeurs et le client. Selon les méthodes Agiles, il est contre-productif
de devoir planifier et spécifier toutes les fonctionnalités du futur produit dans les moindres
détails. De cette façon, au lieu de se focaliser sur les objectifs lointains, il est plus intéressant
de procéder par étapes en fixant successivement les objectifs à court terme et commencer le
développement sans perdre de temps. Chaque fois qu’un objectif est ainsi atteint, on en fixe
un nouveau jusqu’à ce que le produit soit finalisé.

2.2

Méthode Scrum

Scrum est une méthode Agile dédiée à la gestion de projet. Une équipe utilisant cette
méthode est composée de trois rôles bien distincts, chacun ayant une importance cruciale au
bon fonctionnement de cette méthode.
Les rôles définis par Scrum sont les suivants :
— Le « Product Owner », qui porte la vision du produit à réaliser (représentant, généralement le client).
— Le « Scrum Master », garant de l’application de la méthodologie Scrum.
— L’équipe de développement qui réalise le produit.
2

L’équipe est généralement constituée de 8 à 10 membres, dont un Product Owner 1 . Celui-ci
joue le rôle de client au sein de l’équipe. Sa responsabilité principale est de définir un produit
qui apportera le maximum de valeur métier aux utilisateurs dans le temps et le budget impartis au projet.
Ensuite, il y a le Scrum Master, il a pour responsabilité, dans le cadre du développement d’un
produit, d’aider l’équipe à travailler de façon autonome et à s’améliorer constamment. Il est
le garant de l’application du processus, Scrum en l’occurrence.
Le reste de l’équipe, les développeurs, auront pour rôle de réaliser le produit souhaité par le
Product Owner.
Au point de vue du processus de développement, nous avons le "Product Backlog", celuici n’est autre qu’une simple liste ordonnée reprenant l’ensemble des tâches à réaliser (ou à
développer). Les éléments de cette liste sont classés par priorité selon 1 à 4 caractéristiques définies préalablement par le Product Owner : leur valeur métier, leur effort de réalisation, leur
risque et la connaissance technique ou métier apportée par leur mise en œuvre. Le Product
Backlog évoluera en fonction des feedback récoltés par le Product Owner auprès du client.
L’estimation du Product Backlog se fait en présence de toute l’équipe.
Des "Sprints" sont ensuite déterminés et définiront chaque itération. L’équipe se concentrera
donc sur un Sprint à la fois.
En théorie, à la fin de chaque Sprint, doit voir le jour une release du projet. Nous obtenons
ainsi un produit supposé fonctionnel à la fin de chaque Sprint, c’est-à-dire à chaque itération.
Pour que chaque membre de l’équipe ait une vue d’ensemble sur l’avancement du projet,
une réunion journalière est prévue chaque matin. Celle-ci doit être relativement courte car la
règle d’or de cette réunion est d’offrir un temps de parole d’une minute maximum à chacun
des membres. Le but étant de ne pas s’attarder sur les aspects et les problèmes techniques,
mais bien d’expliquer en quelques mots où le travail en est.
Pour cela, chaque membre doit répondre à trois brèves questions :
— Qu’ai-je fait depuis la dernière réunion ?
— Que vais-je faire aujourd’hui ?
— Quels éléments pourraient me freiner ?

Figure 2.1 – Méthode Scrum
1. Dans certaines entreprises, il se peut qu’il y ait plusieurs Product Owner au sein d’une équipe projet.

3

2.3

Méthode Kanban

Kanban est une autre méthode Agile dédiée à la gestion de projet. Celle-ci diffère sur
divers points par rapport à Scrum.
Premièrement, Kanban ne possède pas de rôles différents au sein de l’équipe. Cette méthode
se distingue aussi par sa gestion des approvisionnements. Alors que Scrum opte pour un système à flux poussés, la méthode Kanban impose un système à flux tirés.
Que cela veut-il dire ? Le processus est simple : nous avons, comme pour Scrum, une liste
ordonnée de tâches à réaliser. On appelle ces tâches des "étiquettes" et la liste la "Kanban
Queue".
Nous avons ensuite le "Kanban Board", qui n’est autre qu’un tableau reprenant les différentes étapes du développement du produit. Chaque étape se verra recevoir une limite de
tickets que l’on ne peut dépasser. Le système de flux tirés signifie que lorsqu’un ticket, en
dernière étape, est finalisé, celui-ci va être validé et va offrir sa place à un ticket de l’étape
précédente déjà achevé afin de le finaliser également dans l’étape suivante, et ainsi de suite.
Kanban permet donc de délivrer en continu un délivrable du produit.

Figure 2.2 – Méthode Kanban

4

2.4

Méthode hybride d’AW Europe - VIT

AW Europe utilise, comme de nombreuses entreprises, une méthode hybride de celles expliquées précédemment. En effet, les managers pratiquent une combinaison de la méthode
Scrum et Kanban, en reprenant différents aspects des méthodes et en les réajustant à la manière de travailler de l’équipe. La partie VIT d’AW Europe reprend les principes suivants en
provenance de la méthodologie Scrum :
— Les différents rôles de Scrum sont appliqués à l’équipe, nous y retrouvons au sein de
chaque projet un Product Owner, un Scrum Master ainsi que les développeurs.
— Un Product Backlog est utilisé pour lister les issues 2 à réaliser dans un projet. Ces
issues sont ensuite agencées dans des releases 3 mensuelles contenant différents Sprints
par l’ensemble de l’équipe lors des réunions appelées "Sprint Kick off" où l’on estime
et attribue également les tâches.
— Nous trouverons aussi dans leur organisation, la réunion quotidienne réalisée chaque
matin dans l’optique de mettre au courant tout le monde de l’avancée de chacun.
En ce qui concerne la méthode Kanban, c’est la philosophie du système à flux tirés qui est
reprise grâce au Kanban Board. Les issues en attente de rentrer dans le tableau Kanban sont
celles se trouvant dans le Sprint en cours. Nous pouvons donc imaginer le principe de cette
méthode comme une grande liste d’issues à réaliser se trouvant dans le product Backlog, pour
ensuite les réassembler par Sprints dans le but de définir leur ordre de réalisation. Chaque
Sprint sera exécuté un par un à travers un système à flux tirés. On peut donc considérer que
le Sprint en cours de réalisation est la Kanban Queue.
Des rétrospectives limitées à 1h sont également pratiquées toutes les 6 ou 7 semaines dans
le but de pouvoir déterminer des améliorations pour la prochaine itération du projet.
En fin d’itération, selon la méthodologie Agile, la version doit être fonctionnelle même si elle
n’est pas finalisée. Des démonstrations sont donc réalisées afin d’avoir un meilleur aperçu de
l’état actuel du projet.

Figure 2.3 – Méthode hybride AW Europe
2. Une issue est un problème, un bug ou une tâche ordinaire programmée pour un projet.
3. Chaque mois, une release est mise en place, celle-ci contient un à plusieurs Sprints, ce qui diffère peu
avec la théorie Scrum

5

2.5

Processus de développement d’AW Europe - VIT

Figure 2.4 – Processus d’AW Europe - VIT

2.5.1
-

-

-

Shared Strategic Vision

Chaque projet mené par AW doit suivre la vision stratégique de l’entreprise comme :
Répondre à une ou plusieurs technologies pour lesquelles l’entreprise veut se développer :
— ADAS : Automatic Driving
— Connected
— Big Data
— UX (User Experience)
Avoir une proposition de valeur, c’est-à-dire un retour pour l’entreprise. Par exemple :
— Permettre un retour sur l’investissement
— Permettre d’acquérir un nouveau client
— Permettre d’acquérir un nouveau marché
— Acquérir de nouvelles compétences/expériences
Étudier la compétitivité et l’attractivité du projet
Voir les projets à long terme
6

2.5.2

Entrepreneurial Resources

La société étant en possession de ressources, qu’elles soient humaines ou budgétaires, il
faut que le projet réponde à ces contraintes.
- Pour le budget :
— Obtenir des subsides externes.
— Créer une affectation budgétaire interne.
- Pour le personnel :
— Personnel disponible.
— Personnel suffisamment qualifié.

2.5.3

Proactive Deal Flow

Parmi une vague d’idées, le but de cette étape du processus est de sélectionner les idées
de projet attractives et réalisables satisfaisant les contraintes provenant des deux premières
étapes. Dans le cadre de mon stage, j’ai été amené à travailler sur le développement d’un
dashboard permettant le suivi hebdomadaire de différents projets ou idées en cours.

2.5.4

Balanced Portfolio

Gérer le portefeuille de projet en déterminant l’ordre des priorités pour chaque projet.
Ce qui veut dire que si, par exemple, un projet très important a besoin de ressources supplémentaires, il devient prioritaire sur les autres. Il se peut que l’on mette en standby ces projets
au profit de plus importants.

2.5.5

Dynamic Execution

C’est la partie du processus dans laquelle nous appliquons la méthodologie Agile pour
développer le projet.

2.6

Cycle en V

AW Europe utilise aussi le cycle en V comme modèle conceptuel pour le développement de
leurs projets. C’est un modèle conceptuel de gestion de projets imaginé à la suite du problème
de réactivité du modèle en cascade. Il permet, en cas d’anomalie, de limiter un retour aux
étapes précédentes. Les phases de la partie montante doivent renvoyer de l’information sur
les phases en vis-à-vis lorsque des défauts sont détectés, afin d’améliorer le logiciel.

7

Figure 2.5 – Schéma cycle en V

2.6.1

Cycle en V d’AW Europe

Figure 2.6 – Schéma cycle en V

Première partie Upstream : Pré-phase : déterminer les épics, users stories et Sprints.
L’évaluation de la charge de travail se fait lors des pokers, définition du backlog.
Deuxième partie Downstream : Attribution des tâches, implémentation des tests, partie
de développement, itérations des différents Sprints, phase de test.
Troisième partie Upstream : Vérification puis validation avec l’utilisateur avant la livraison du délivrable.

8

Chapitre 3

Outils Atlassian utilisés chez AW
Europe
3.1

JIRA

JIRA est un gestionnaire de suivi de bug, mais surtout un système de gestion de projets
développé par Atlassian. C’est un "issue tracker", que l’on pourrait traduire par un "gestionnaire de demandes". Cette définition offre une idée du potentiel d’un tel outil mais reste tout
de même assez flou car le terme anglais "issue" fait référence à quelque chose de beaucoup
plus générique. On considère une "issue"comme un objet, un sujet ou une situation susceptible
d’être traité par un ou plusieurs membres de l’équipe. Il peut donc s’agir de bug, d’anomalies, d’incidents, mais également d’une multitude de tâches anodines se trouvant au sein d’un
projet.
JIRA est donc un outil de planification et de suivi d’activités optimisé pour les méthodologies
Agile. Il est cependant très facilement adaptable aux méthodes vues précédemment. De très
nombreuses fonctionnalités sont mises à disposition permettant d’adapter JIRA à n’importe
quel type d’équipe ou de projet.

Figure 3.1 – Logo JIRA

3.2

Confluence

Confluence est une application web qui permet la création, la modification et l’illustration
collaboratives de pages. Cet outil est utilisé comme logiciel de travail collaboratif. En d’autres
termes, il s’agit d’un wiki semblable au célèbre Wikipédia, mais adapté au développement de
projets au sein d’équipe. C’est donc un logiciel de collaboration à la rédaction de contenus qui
révolutionne les méthodes de travail des équipes modernes. En effet, cela permet à une équipe
9

de rédiger directement ses rapports, recherches ou feedback au sein d’un même programme
dont chacun des membres de l’équipe a accès, peut les lire ou les modifier.
Confluence faisant partie des produits développés par Atlassian, il est très facile de lier JIRA
à Confluence pour communiquer des informations sur un projet de développement grâce aux
liens automatiques, à la création rapide de tickets et aux rapports.

Figure 3.2 – Logo Confluence

3.3

Tempo

Tempo est un template spécialement conçu pour JIRA. Il permet la planification d’équipes
et de projets. C’est un outil intéressant pour les manager, qui facilite la gestion d’équipes et
la répartition des tâches dans le temps. Une partie de Tempo, appelée Tempo Timesheets,
permet une gestion intuitive du temps dans JIRA.

Figure 3.3 – Logo Tempo

3.4

Bitbucket

Bitbucket est la version Git développée par Atlassian, c’est-à-dire qu’il s’agit d’un logiciel
de gestion de versions décentralisées. Il est utilisé principalement par les développeurs car,
en effet, il est quasi exclusivement utilisé pour gérer des codes sources vu que Bitbucket est
capable de suivre l’évolution d’un fichier texte ligne de codes par ligne de codes. Ce genre de
logiciel est fortement conseillé pour gérer un projet informatique, c’est pourquoi Atlassian a
développé sa version du programme, compatible et modulable à JIRA et Confluence.

Figure 3.4 – Logo Bitbucket

10

Chapitre 4

Analyse économique de l’entreprise
4.1

Enquête GRH

Dans cette partie, nous allons voir comment fonctionnent la gestion et la communication
des employés au sein d’AW Europe. Étant donné que cette firme est une très grande entreprise
comprenant différents départements, mon étude s’est basée principalement sur la section dans
laquelle mon stage a été réalisé, à savoir VIT Software Engineering.
Pour cela, différents sujets ont été analysés :
— La motivation des employés ;
— La hiérarchie du département VIT 1 Software Engineering ;
— Le processus de recrutement ;
— L’organisation et la gouvernance des projets.

4.1.1

La motivation des employés

AW Europe se distingue par l’attention qu’il porte à la qualité de ses processus et surtout de son personnel dont il en reconnaît son principal atout. Cette entreprise pratique une
politique basée sur l’équité et l’égalité des chances. Elle prône un environnement de travail
qualitatif, ouvert et diversifié, offrant les meilleures chances à chacun pour y développer ses
talents et sa performance, dans un environnement sûr qui privilégie le bien-être et l’épanouissement de ses travailleurs.
L’équipe est formée de personnes ayant toutes le même état d’esprit. Chacune aime résoudre des problèmes, complexes ou non. Elles aiment relever des défis, et partent dans l’optique de vouloir sans cesse apprendre de nouvelles choses. C’est une mentalité qui permet
à l’équipe d’avancer ensemble en acquérant toujours de nouvelles compétences dans chaque
domaine. Cela reflète donc bien la philosophie de «suprématie de la qualité» de l’entreprise
AW Europe pour le développement et la production de produits innovants apportant un haut
degré de satisfaction à ses clients.
L’envie et le besoin de créer de nouveaux produits innovants est donc la principale source
de motivation de chacun des employés d’AW Europe. Des activités externes sont organisées à
l’occasion, pour améliorer l’intégration et l’entente au sein des équipes. De plus, des organismes
internes existent et sont accessibles aux employés en cas de problèmes, tels que la prévention
de burn out, par exemple.
1. Vehicle Information Technology

11

4.1.2

La hiérarchie du département VIT Software Engineering

Figure 4.1 – Hiérarchie VIT Software Engineering

L’équipe est divisée en quatre parties :
— Product Definition
Celle-ci a pour but de définir les caractéristiques souhaitées du produit. Entre autres, ces
personnes se mettent à la place du client, en réfléchissant à ses attentes.
— Experts cast
C’est une partie de l’équipe qui s’occupe moins du développement, mais se focalise plus sur
l’algorithmique. Elle joue un rôle de data analyst.
— Development Squad
Il s’agit de l’équipe de développement. Il n’y a pas réellement de chef au sein de celle-ci,
mais il y a tout de même les Scrum Masters qui sont considérés comme leader, s’occupant
principalement d’assigner les différentes tâches d’un projet aux membres de l’équipe.
— System Squad
c’est la partie de l’équipe de développement travaillant sur les systèmes et les intégrations.

12

Joachim V.
Frederic B.
Jürgen J.
Richard V.
Giancarlo M.

Manager
Manager
Product Owner
Scrum Master
Scrum Master

Strategy
Tactics
Coordination
ADAS Leader
Connected leader

— Manager
Il s’occupe de la gestion des projets et des équipes, détermine le budget et s’occupe également
des ressources humaines et externes.
— Product Owner
c’est le membre de l’équipe de projet dont la responsabilité principale est de définir un produit
qui apportera le maximum de valeur métier au client dans le temps et le budget impartis au
projet.
— Scrum Master
Il a pour responsabilités d’aider l’équipe à travailler de façon autonome et à s’améliorer
constamment. Il est le garant de l’application du processus, Scrum en l’occurrence.

4.1.3

Le processus de recrutement

L’une des premières questions que l’on pose lors du premier entretien d’embauche permet
de savoir ce que le concerné connaît sur l’entreprise et ce qui le motive à vouloir travailler
pour celle-ci. Le but étant de vouloir recruter une personne ayant la même philosophie que
l’entreprise. Il est clair que recruter des futurs employés passionnés par le domaine de l’automobile favorise l’intégration de ceux-ci au sein de projets liant innovation, technologie et
automobile. C’est également une bonne source de motivation pour pouvoir fournir un bon
travail.
Le processus de recrutement est le suivant :
Lorsqu’un poste se libère, une publication de l’opportunité de carrière est diffusée dans les
canaux de diffusion interne afin de privilégier le personnel d’AW Europe au poste. S’il n’y
a pas de recrutement interne, une diffusion publique de l’annonce est réalisée afin d’ouvrir
les propositions à une personne externe à l’entreprise. Une prise de contact par téléphone
est réalisée par les recruteurs dans le but de vérifier l’adéquation du recruté aux critères de
base. Il s’ensuit un entretien avec les ressources humaines si le retour est positif. Si le premier
entretien RH 2 est en adéquation avec les valeurs de l’entreprise, le prétendant au poste est
présenté au service demandeur par les RH et obtient un entretien avec l’équipe.
La dernière étape avant la décision finale, celle-ci revenant au demandeur avec le soutien
des RH, est la validation de l’adéquation de la personnalité et de la motivation aux exigences
de la fonction.

2. Ressources Humaines

13

4.1.4

L’organisation et la gouvernance des projets

Dans le cadre de la méthodologie Agile Scrum, chaque matin une réunion de 10 à 15
minutes est réalisée au sein de l’équipe afin de pouvoir faire un bilan journalier sur l’avancement du projet. Chaque membre de l’équipe a son temps de parole et doit répondre à ces 3
questions :
— Qu’ai-je réalisé depuis hier ou depuis la dernière réunion ?
— Que vais-je faire aujourd’hui ?
— Quels sont les problèmes rencontrés ?
Chaque semaine, un appel en vidéo-conférence est réalisé avec la maison-mère au Japon, AW
Japon, afin de présenter les compte-rendus hebdomadaires des équipes de développement.
Cette réunion permet de prendre le temps de répondre aux différentes questions ou autres.
Pour en revenir aux principes de la méthode Agile, une démonstration du délivrable est
organisée toutes les deux semaines. Cette réunion est organisée par le Product Owner et/ou
le Scrum Master. Tous les membres de l’équipe de développement, d’évaluation et de business
ainsi que les managers y sont conviés.
Chaque mois, une rencontre avec le client est prévue afin de le tenir au courant des avancements et les progrès du/des projet(s). Ces entrevues peuvent être l’occasion de réaliser des
démonstrations au client, afin qu’il puisse tester le produit et donner son avis. Ces réunions
peuvent également servir à ouvrir les portes à de nouvelles collaborations.
Tous les trois mois a lieu le « Stage Gate Meeting », le but étant de montrer les avancements des projets aux personnes externes de l’équipe, les cadres supérieurs de l’entreprise.
Ces réunions ont pour but de déterminer le statut du projet, l’état d’avancement et la faisabilité de celui-ci en décidant s’il est intéressant pour l’entreprise de continuer le développement
du projet ou non.
En plus de ces réunions, les managers se rencontrent chaque vendredi afin de discuter des résolutions à prendre sur les différents problèmes rencontrés. Certains rapports hebdomadaires
sont également à rendre aux supérieurs du département afin qu’ils puissent, à leur tour, avoir
une vision globale de l’avancement des différents projets.
Des consignes ont été instaurées dans l’entreprise concernant les réunions afin que celles-ci
soient les plus efficaces possible. On les retrouve affichées dans chacune des salles de réunion.

14

Figure 4.3 – Règle de réunion AW VIT

Figure 4.2 – Règle de réunion AW

4.2
4.2.1

Positionnement sur le marché
Principaux produits

AW Europe possède deux lignes de production. La première gamme de produits provient
de la section "A/T" pour "Automatic Transmissions". Celle-ci se base principalement sur le
développement de boîtes de vitesses dans le domaine de l’automobile. La mission de cette
partie de l’entreprise consiste à faire d’AW Europe le premier fabricant spécialisé en transmissions automatiques sur le marché européen en assurant une place de premier de classe en
termes de qualité, de technologie et de livraison.
La seconde gamme de produits est développée par le département "VIT" pour "Vehicle
Information Technology". Cette section est basée sur la recherche et le développement de
prototypage en terme de système de navigation intégré dans les véhicules de nouvelles générations. Ils travaillent d’une part sur les systèmes de navigation embarquée, mais également
sur le développement d’applications de navigation pour Smartphone.
AW Europe ainsi que d’autres grandes entreprises dans le domaine de l’automobile font
partie du groupe international AISIN. Ce groupe développe aussi d’autres composants destinés aux voitures, que cela soit au niveau d’accessoires ou de composants mécaniques pour les
véhicules.
Cette entreprise assure aussi le reconditionnement de boîtes de vitesses automatiques.
L’objectif poursuivi consiste à réparer des produits endommagés provenant du marché en
restaurant un niveau de qualité et de fonctionnement identique à celui d’un produit neuf.
Cela a pour objectif :
1. D’améliorer de manière continue la satisfaction du client en termes de qualité, de coût
et de livraison ;
15

2. De diminuer l’impact sur l’environnement en allongeant la durée de vie du produit ;
3. De récupérer du terrain les pièces défaillantes dans le but d’identifier les causes racines
de dysfonctionnement et d’en informer Aisin AW rapidement afin que puissent être
prises les mesures adéquates au niveau de la conception, du processus de fabrication
et des fournisseurs de composants.

Figure 4.4 – Groupe AISIN

4.2.2

Principaux concurrents

AW Europe se place face à ses concurrents en adoptant différentes méthodes. La première
est la réalisation de "benchmarks", c’est-à-dire qu’ils achètent des véhicules dont le système
de navigation (et/ou la boîte à vitesses) provient de leurs concurrents dans le but de réaliser
différents essais. Les testeurs réalisent deux types de tests :
— Une équipe d’ingénieurs réalise des tests et étudie les aspects techniques de l’ensemble
des fonctionnalités du produit.
— Des équipes d’employés lambda travaillant pour AW Europe sont formées par section
d’âge et ont l’opportunité d’essayer ces véhicules librement durant quelques jours.
Une fois les essais réalisés par les différentes équipes, celles-ci se concertent afin de fournir
des feedbacks sur le produit et de réaliser un rapport. Cela permet d’avoir d’une part, un
rapport provenant des spécialistes et, d’autre part, un rapport provenant de personnes ordinaires pouvant être assimilées à la clientèle ciblée par ces véhicules.
Des benchmarks sont également réalisés par des firmes indépendantes spécialisées dans la
réalisation de rapports automobiles. AW Europe achète chaque année ces données mais en
comparant avec leurs benchmarks, l’entreprise remarque que ceux réalisés en interne sont de
meilleure qualité car les équipes savent exactement ce qui est à cibler.
En termes de part de marché, malgré de nombreux concurrents, AW Group détient approximativement 9 pourcent du marché international pour la partie VIT et 15 pourcent du
marché international pour la transmission automatique.
16

4.2.3

Pression marketing

Produit
Section A/T
Les produits créés dans cette section de l’entreprise sont à la pointe de l’innovation. AW Europe cherche à améliorer sans cesse les performances de ses boîtes à vitesses automatiques qui
ont pour but d’équiper les nouveaux modèles de véhicules de ses clients. Une voiture devant
être un moyen de transport sécurisé et suffisamment fiable que pour fonctionner plusieurs
années voire décennies, il est donc dans l’intérêt de l’entreprise que la qualité de ses produits
soit extrêmement haute. C’est pour cela, que de très nombreux essais sont effectués sur les
prototypes en cours de développement. Ceux-ci sont assemblés aux moteurs de la clientèle
et sont mis à rude épreuve dans des conditions extrêmes afin de vérifier leur résistance. AW
Europe est la seule entreprise européenne à posséder les installations nécessaires pour réaliser
de tels tests.
Afin de recevoir une satisfaction remarquable par ses clients, AW Europe porte une attention particulière au reconditionnement des boîtes à vitesses défaillantes.
Ayant à l’esprit les exigences des constructeurs automobiles européens, AW Europe lance
en 2002 avec succès, et en première mondiale, la boîte à 6 vitesses pour moteurs à traction
et à couple moyen. Poursuivant sur sa lancée, l’entreprise sera le premier fabricant de pièces
automobiles à développer dès 2004 un système hybride respectueux de l’environnement et
en 2006, à mettre sur le marché la première boîte à vitesses automatiques à 8 vitesses pour
moteur à propulsion à couple élevé.
Enfin, en 2008, un nouveau succès est remporté avec le lancement de la première boîte
à vitesses automatique à haute capacité de couple pour véhicules toutes roues motrices 8
vitesses. Elle sera bientôt suivie en exclusivité mondiale, en 2012, par la boîte 8 vitesses à
haute capacité de couple pour moteur à traction.

Figure 4.5 – Modèle 2002

Figure 4.6 – Modèle 2012

17

Section VIT
Cette section de l’entreprise est basée sur la recherche et le développement d’idées innovatrices dans le domaine de l’automobile. À l’heure d’aujourd’hui, l’avancée technologique est
telle que des prototypes de véhicules autonomes sont en train de voir le jour. AW Europe
travaille davantage sur cette technologie en développant différents projets parallèles dans le
but d’améliorer l’aide à la conduite d’un véhicule ordinaire et d’apporter des solutions pour
avancer dans le développement des voitures autonomes. Le degré d’innovation pour leurs produits est avant-coureur car leurs produits ont une avance de deux à cinq ans par rapport à ce
qui se trouve sur le marché actuel.
Leur travail étant principalement basé sur la recherche et le développement de prototypage,
ce ne sont donc pas des produits finis qui en ressortent dans la majorité des cas. Certains
projets portent sur de nouvelles fonctionnalités à rajouter sur les systèmes de navigation
actuels, tandis que d’autres concernent la création d’applications mobiles.

Figure 4.7 – Exemple produit pour AUDI

Figure 4.9 – Exemple produit pour VW

Figure 4.8 – Exemple produit pour VW

Figure 4.10 – Exemple produit pour Lexus

Prix de vente
AW Europe génère des bénéfices grâce à la vente de différents produits.
Une partie du chiffre d’affaires est obtenue grâce à la vente des "Map Updates", c’est-à-dire
que chaque année, de nouvelles maps de navigation sont créées contenant les dernières mises
à jour des routes et signaux routiers dans le monde. AW Europe collabore avec la maisonmère située au Japon pour réaliser ces cartes avant de les proposer aux différentes marques
automobiles partenaires.

18

L’entreprise réalise également des gains en vendant ces boîtiers comprenant leur système
de navigation. Les boîtiers sont assemblés sur le site de Baudour et la partie logicielle est
confectionnée et supervisée par les ingénieurs de la section VIT.
La vente des boîtes à vitesses assemblées sur le site de Baudour génère une grande partie
du chiffre d’affaires d’AW europe.
La partie "recherche et développement" ne génère aucun bénéfice, celle-ci est financée
principalement par la maison-mère.
Publicité
La capacité technologique d’AW Europe en termes de produits et de qualité est largement
reconnue, ce que démontre un portefeuille clientèle comptant 44 constructeurs automobiles
situés dans 13 pays à travers le monde.
La clientèle ciblée à partir des produits proposés par l’entreprise n’étant pas le grand
public, l’entreprise utilise différents moyens pour trouver de nouveaux clients. En effet le but
étant d’atteindre les grands constructeurs automobiles, AW Europe se présente à des foires
automobiles en présentant ses produits et en réalisant les démonstrations de ceux-ci. A titre
d’exemple, AW Europe se présente tous les deux ans au "Frankfurt Motor Show" qui est un
évènement très sollicité dans le milieu de l’automobile et qui intéresse tous les constructeurs
automobiles.
AW Europe développe également des projets destinés uniquement à pouvoir montrer ses
compétences à ses futurs clients. Au vu de leurs nombreuses relations au sein du groupe
AISIN, les membres travaillent pratiquement avec toutes les grandes marques automobiles.
C’est notamment le cas pour la partie A/T d’AW Europe collaborant avec plus de 44 marques
automobiles. En ce qui concerne la section VIT, ceux-ci collaborent avec 24 clients.
La principale force de vente et de publicité de l’entreprise réside donc dans son expérience
accrue dans son domaine, de ses produits de qualité ainsi que de ses engagements vis à vis de
ses clients. AW Europe a la ferme conviction qu’elle peut contribuer au succès de ses clients
grâce à sa préoccupation pour la qualité.
Place
En ce qui concerne la philosophie de distribution, les flux logistiques obéissent à la philosophie du système de production Toyota (TPS), qui se concrétise notamment dans les principes
suivants :
— Le flux tiré 3 (méthode Agile hybride) ;
— La minimisation des stocks ;
— La livraison en "juste-à-temps".
AW Europe est conscient de son impact sur l’environnement et a pour objectif de réduire
son empreinte environnementale de manière durable. C’est pour cette raison que l’entreprise
donne la priorité au transport multimodal (mer–rail–route–air) et à l’utilisation d’emballages
réutilisables.

3. Le besoin en aval tire le produit de l’étape en amont

19

En termes de distribution, la chaîne de production d’AW Europe assure trois activités principales :
1. La distribution de boîtes de vitesses automatiques à destination des usines automobiles.
2. La distribution de pièces détachées de boîtes de vitesses automatiques pour le service
après-vente à l’attention des centres de distribution des constructeurs automobiles.
3. L’approvisionnement et la gestion des composants intervenant dans les productions
locales. En complément, AW Europe assure l’approvisionnement en composants pour
les produits VIT.
L’entreprise se porte garante de la responsabilité du flux des approvisionnements depuis le
placement de la commande jusqu’à l’expédition et la facturation :
— Intégration et analyse des demandes des clients ;
— Création des plans de production et de distribution ;
— Calcul des besoins au moyen du système MRP ; 4
— Passage des commandes auprès des fournisseurs ;
— Suivi des commandes, préparations, livraisons et facturations.
AW Europe gère les opérations d’entreposage et de distribution de deux manières :
— Au moyen d’entrepôts indépendants situés à proximité de ses clients permettant de
fournir plus rapidement sa clientèle.
— Grâce à son entrepôt situé sur le site de Mons (Baudour) pour toutes les opérations
liées à la production locale et au service après-vente.

4. Material Requirement Planning

20

Chapitre 5

Étude des KPIs
5.1

Définition

Avant toutes choses, voici la définition d’un indicateur-clé de performance :
Un indicateur-clé de performance ou KPI (Key Performance Indicator) est un élément de
mesure utilisé comme estimation pour évaluer différents facteurs essentiels à la réussite lors
du développement d’un projet.

5.2

KPIs permettant la gestion de projets

Il est très important d’avoir un suivi des KPIs lors d’un projet. Cela permet de garder
une vision sur les différents objectifs de l’équipe. Avec des mesures de performance couvrant
les délais et les budgets, il est plus facile de superviser l’avancement du projet et de rester sur
le bon cheminement. Ces indicateurs de performance doivent satisfaire quatre points importants :
— L’opportunité
Permet de s’assurer que le projet est réalisé dans les temps.
— Le budget
Permet de s’assurer que le budget est correctement alloué.
— La qualité
Permet de savoir dans quelle mesure le projet a évolué et si ceux qui travaillent dessus ou
qui en bénéficient sont satisfaits .
— L’efficacité
Permet de savoir s’il est possible de gérer le projet de manière plus efficace .

21

Il existe de très nombreux KPIs mais en tant que gérant d’équipe, il est très important de
déterminer les indicateurs nécessaires pour le projet concerné. Plus la sélection de KPIs sera
judicieuse, plus la gestion du projet sera pertinente et efficace.
C’est donc pourquoi la première étape de ce stage était de réaliser un état de l’art des indicateurs existants. La suite étant de déterminer quels indicateurs pouvaient être pertinents pour
le processus de développement d’AW Europe. En voici un aperçu :

5.2.1

KPIs liés au temps

Cycle Time
Temps nécessaire pour compléter une tâche ou une activité.
Lead Time
Temps qui s’écoule entre le début et la fin d’un processus.
Time Spent
Temps consacré sur le projet par l’ensemble des membres de l’équipe ou par chaque membre
individuellement.
FTE 1 Days Vs. Calendar Days
Le temps que l’équipe consacre à un projet en jours civils, en heures et/ou en jours de travail
équivalents au temps plein.
La supervision de cette mesure du projet indique le nombre d’heures de travail prévues pour
les processus du projet par rapport au temps réel passé. Il est possible d’appliquer cette métrique à différentes périodes et comparer plusieurs phases de projet. Si le nombre réel d’heures
passées dépasse largement l’heure prévue, il est temps de réévaluer le temps prévu pour le
projet.
Schedule Performance Index
Cela permet d’indiquer si le projet est en avance ou en retard par rapport au calendrier prévu.
Pour cela, il faut diviser la valeur de l’avancement réalisé du projet avec la valeur planifiée.
Si le SPI est supérieur à un, cela signifie que le travail réalisé est plus conséquent que le travail
prévu. En d’autres termes, vous êtes en avance sur le calendrier.
Si le SPI est inférieur à un, cela signifie que le travail prévu n’a pas été réalisé complètement.
En d’autres termes, vous êtes en retard.
Si le SPI est égal à un, cela signifie que le travail est terminé au même rythme que prévu.
Vous êtes donc à l’heure.

1. Full time equivalent : Équivalent temps plein (Unité de mesure d’une charge de travail ou d’une capacité
de travail)

22

5.2.2

KPIs liés au budget

Budgeted cost of work scheduled (Planned value project)
Cela permet d’estimer la valeur prévue pour vos activités de projets en cours, à compter d’une
date de clôture. En comparant la valeur planifiée avec d’autres indicateurs, on peut voir si
l’on est en avance ou non sur le calendrier ou si l’on a déjà dépensé une grande partie du
budget prévu.
Budget Variance
La manière dont le budget actuel varie selon le budget projeté.
Schedule Variance
Il sert à déterminer si le projet en cours d’exécution est en avance ou en retard sur le budget
prévu. C’est calculé en soustrayant la valeur planifiée du projet de sa valeur gagnée.
Si la somme est négative, cela signifie que vous avez réussi à réaliser plus que prévu et que
vous avez un budget plus important à consacrer aux tâches restantes.
Si la somme est positive, cela signifie que vous avez utilisé plus de budget que ce qui était
prévu.
Line Items in Budget
Cela permet aux gestionnaires de suivre les dépenses individuelles et de fournir un moyen
plus détaillé de la manière dont le budget a été dépensé.

5.2.3

KPIs liés à la qualité

Customer Satisfaction/Loyalty
Cela sert à évaluer le taux de satisfaction du client. Cela peut être mesuré efficacement à
travers une enquête. C’est très important lorsque le projet est traité directement avec le client.
Number Of Errors
Cela sert à évaluer le nombre de fois où les choses doivent être refaites au cours du projet.
C’est le nombre de fois que vous devez revoir et retravailler une tâche. Ces erreurs affectent
les révisions budgétaires et celles du calendrier.
Customer Complaints
Cela peut également convenir dans le cas où un membre de votre groupe de projet se plaint
parce qu’un autre ne réalise pas les tâches demandées.

5.2.4

KPIs liés à l’efficacité

Number of project milestones completed on time with sign off
Un projet est subdivisé en différentes parties. Sont-elles terminées à temps ? De plus, les
étapes ont-elles été complétées et approuvées par le client ?
On peut déterminer deux indicateurs : le nombre de tâches en retard et le nombre de tâches
terminées.

23

Training/Research Needed For Project
Quelles sont les ressources/compétences nécessaires au début du projet qu’il fallait acquérir
pour commencer immédiatement à travailler sur le projet ?

5.3

KPIs orientés sur la méthode Agile

Les KPIs liés à la méthode Agile sont plus interactifs, dans le sens où les indices de
performance sont généralement repris et représentés à travers différents graphiques.

5.3.1

Burndown Chart

Cet outil permet de suivre le travail total restant et de projeter la probabilité d’atteindre
le but du Sprint. Cela aide l’équipe du projet à gérer ses avancements et à réagir en fonction
du rapport généré.
C’est donc une représentation graphique de l’évolution de la quantité de travail restante par
rapport au temps sur une période donnée. L’axe horizontal représente la ligne du temps du
projet, l’axe vertical représente la quantité de travail restante.
Il montre à l’équipe l’utilité de demander tous les jours l’état d’avancement des travaux,
car ces informations données sont immédiatement affichées et accessibles à toutes les parties
prenantes du projet, dont le propriétaire du produit. Il contribue donc à la mise sous-tension
et en énergie de l’équipe.

Figure 5.1 – Exemple de burndown chart

Avantages :
— Le Burndown Chart de Sprint est un indicateur visuel de la quantité de travail qui
reste théoriquement à faire pour terminer le sprint.
— Il pousse à estimer de nouveau quotidiennement le reste à faire.
Points d’attention :
— Le Burndown Chart de Sprint ne montre pas l’avancement du Sprint par rapport aux
objectifs qui lui ont été assignés (on ne voit pas si les stories sont terminées).
24

5.3.2

Epic Burndown

Ce rapport montre comment l’équipe progresse par rapport au travail d’une Epic en
utilisant le principe du Burndown Chart. Une Epic est une grande user story pouvant être
décomposée en plusieurs petites stories. Optimisée pour les équipes Scrum qui travaillent en
Sprint, elle rend le suivi beaucoup plus facile. Ce rapport peut être utilisé pour :
— Superviser la vitesse de travail de l’équipe à travers l’Epic.
— Voir l’impact qu’a le travail ajouté/supprimé pendant le Sprint sur les progrès globaux
de l’équipe.
— Permettre de prévoir combien de Sprint seront utiles pour finir le travail.

5.3.3

Release Burndown

Cela montre comment l’équipe progresse par rapport au travail pour une version. Ce
rapport peut être utilisé pour :
— Superviser la vitesse de travail de votre équipe à travers le backlog.
— Voir comment le travail ajouté/supprimé affecte la progression de l’équipe pendant un
Sprint.
— Permettre de prévoir combien de Sprint seront utiles pour finir le travail pour une
version.

5.3.4

Control Chart

Le tableau de contrôle indique le temps de cycle (Cycle Time) pour votre produit, version
ou sprint. Il détermine le temps passé par chaque problème dans un état particulier et est
ajouté à une période de temps spécifiée. La moyenne, la moyenne mobile et l’écart-type pour
ces données sont présents.

Figure 5.2 – Exemple de control Chart

25

Ce tableau peut être utilisé pour :
— Identifier les cartes ayant été bloquées ou ayant rencontré un délai de réalisation trop
important par rapport au Cycle Time moyen.
— Analyser les performances passées de votre équipe dans une rétrospective.
— Mesurer l’effet d’un changement de processus sur la productivité de votre équipe.
— Fournir aux intervenants externes la visibilité des performances de votre équipe.
— Kanban : utiliser les performances passées pour définir les objectifs de votre équipe.
Il est possible de réaliser deux graphiques : le premier avec le Cycle Time des cartes
terminées, et le second avec le Cycle Time des cartes en cours de réalisation. Ce dernier
permet ainsi une meilleure réactivité pour l’équipe et de traiter en urgence les cartes dépassant
l’écart-type. L’écart-type offre une indication du niveau de confiance des données.
Avantages :
— Il garantit le niveau de qualité des produits.
— Il prévient à temps et si le processus est corrigé dans les temps, le time scrap peut être
réduit.
— Il détermine la variabilité des processus et détecte des variations inhabituelles dans un
processus.
— Il indique si un processus est contrôlé ou hors de contrôle.

5.3.5

Cumulative Flow Diagram

C’est un graphique de zone permettant de montrer les différents états des éléments de
travail pour une application, version ou Sprint.

Figure 5.3 – Exemple de Cumulative Flow Diagram
26

La couche supérieure représente les cartes en entrée dans le système et la couche inférieure, les cartes ayant été traitées. Entre ces deux couches se trouvent les différentes étapes
du processus.
L’axe horizontal représente une ligne du temps, l’axe vertical représente le nombre de cartes
(problèmes). Chaque zone colorée du tableau équivaut à un état du flux de travail. Ce graphique peut être utile pour identifier les obstacles. Si on s’aperçoit qu’une zone s’élargit
verticalement au cours du temps, cela veut dire qu’il y a un obstacle dans cette zone. Il permet donc de suivre le temps de passage des cartes dans le système (Lead Time), ainsi que le
temps de réalisation (Cycle Time).
Avantages :
— Détection rapide de Bottleneck 2
Points d’attention :
— Il ne donne pas d’indication précise mais une vue globale des différents états des
éléments.

5.3.6

Velocity Chart

Il permet de donner une représentation du nombre de cartes réalisées par période (semaines, Sprints,...). Entre autres, il indique la quantité de travail livré, ce qui permet de
prédire la quantité de travail que l’équipe peut effectuer dans les Sprints à venir. Ce graphique est un outil très intéressant pouvant aider lors des réunions de planification de Sprint
pour décider de la quantité de travail possible.

Figure 5.4 – Exemple de Velocity Chart
2. Issue prenant beaucoup plus de temps que prévu pour être réalisée.

27

Avantages :
— Méthode extrêmement simple et puissante.
— Permet de prédire et de planifier les itérations futures.
— Il faut entre 3 à 6 itérations afin d’obtenir une vitesse de l’équipe très fiable.
Points d’attention :
— Si les longueurs des itérations changent, on ne peut pas mesurer la vitesse.

5.3.7

Epic Report

Ce rapport montre une liste d’issues complètes, incomplètes et non-estimées pour une
période. Il est très utile dans la planification du travail pour une période pouvant s’étendre
sur plusieurs Sprints.
Il permet de superviser les progrès accomplis durant une période et pour suivre la quantité
restante de travail incomplet ou non-estimé.

5.3.8

Sprint Report

Le Sprint Report permet de générer la liste des issues perçues dans chaque Sprint. Il est
très intéressant de travailler avec ce rapport lors des réunions rétrospectives. Les "Sprints"
étant uniquement utilisés dans la méthodologie Scrum (ou réadaptés pour l’utilisation d’une
méthode hybride), cet outil sera disponible que lors de l’application de celle-ci.

5.3.9

Version Report

Cela montre le progrès de l’équipe vers la fin d’une version. Il montre également la date
de sortie prévue en fonction de la vitesse de votre équipe depuis le début de la version et de
la quantité estimée de travail restant.

28

Chapitre 6

Mise en application
6.1

Dashboard JIRA

Une des nombreuses fonctionnalités proposée par JIRA est la possibilité de créer, copier
ou modifier des dashboards 1 . On peut facilement manier des outils existants et les adapter
avec des filtres 2 de recherche d’issues créés préalablement. Dans le cadre de la prise en main
de l’outil JIRA, deux dashboards ont été créés afin de répondre aux besoins d’une part, des
managers et d’autre part, des membres de l’équipe de développement.
Pour cela, il a fallu entrevoir les besoins des différents partis afin de pouvoir répondre au
mieux à leurs attentes.
L’avantage des dashboards JIRA sont nombreux. Tout d’abord, ceux-ci se mettent à jour
automatiquement à chaque actualisation de page en reprenant les modifications des issues
JIRA. Il est possible de rendre accessible à tout le monde ses dashboards mais aussi ses filtres
d’issues, c’est pourquoi il est donc facile de copier et modifier à sa guise un dashboard existant
d’où l’intérêt de réaliser des dashboards disponibles à tous les managers et développeurs d’une
équipe Agile.
Le seul inconvénient que l’on peut trouver, c’est que les dashboards reposent sur les
informations se trouvant sur JIRA provenant des membres de l’équipe. Ce qui veut dire que
si les informations sont mauvaises, les informations ressortant des dashboards risquent d’être
faussées également. Il faut donc pouvoir adapter une certaine rigueur au sein de l’équipe au
niveau de l’application de la méthode Agile imposée par les managers.

1. Outil informatique permettant de centraliser en un seul point un ensemble de données permettant de
piloter une activité.
2. Les filtres sont des requêtes permettant de sélectionner uniquement les issues souhaitées (Par exemple
le filtre : Afficher les issues pour un projet spécifique).

29

6.1.1

Dashboard pour l’équipe Manager

Quels étaient les besoins des managers de l’équipe ? Le rôle d’un manager est de pouvoir
superviser l’avancement de l’équipe de développement sur un ou plusieurs projets. L’objectif
de ce dashboard est donc de rendre ce contrôle beaucoup plus facile.
C’est pourquoi nous observons sur ce dashboard différentes informations :








L’aperçu de la vélocité de l’équipe projet ;
Le nombre de jours théoriques restants avant la fin du Sprint actuel ;
Le Burndown Chart du Sprint actuel ;
Les informations sur le Sprint actuel ;
Le Cumulative Flow Diagram représenté en Pie Chart ;
Le résumé des issues ouvertes dans le projet par ordre de priorité ;
Le nombre de tâches non résolues pour chacun des membres de l’équipe (triées par
priorité) ;
— Les informations relatives aux tests unitaires réalisés sur Bamboo. 3
Ce dashboard se base principalement sur un projet. Si un manager supervise plusieurs projets,
la meilleure solution est de dupliquer ce dashboard pour chacun des projets en modifiant
uniquement les filtres et en sélectionnant projet par projet. Il aura donc un dashboard par
projet, ce qui rend les informations plus structurées.

Figure 6.1 – Dashboard manager

3. Outil Atlassian permettant aux développeurs de réaliser des tests unitaires ou d’autres essais sur leurs
codes.

30

6.1.2

Dashboard pour l’équipe Développeur

En ce qui concerne les développeurs, leur dashboard servira principalement de moyen
d’aperçu rapide de ses propres issues, l’avancement de son travail ainsi que de visualisation
des tâches en cours de réalisation par l’équipe.
C’est pourquoi nous observons sur ce dashboard différentes informations :
— L’aperçu de la vélocité de l’équipe ;
— Le nombre de jours théorique restants avant la fin du Sprint ;
— Le Burndown Chart du Sprint ;
— Le fil d’actualité de l’équipe, où l’on voit les dernières modifications sur le projet ;
— Le résumé de ses issues personnelles ouvertes par ordre de priorité ;
— Le résumé des heures de travail enregistrées dans Tempo ;
— Les informations relatives aux tests unitaires réalisés sur Bamboo. 4
Ce dashboard est une idée proposée. Celui-ci n’est actuellement pas entièrement compatible
à la manière de travailler de l’équipe. L’outil Tempo est très récent et n’est pas encore utilisé
de manière optimale par les membres de l’équipe. Ce dashboard sert surtout de première
approche en terme de gestion de temps de travail associé à Tempo.

Figure 6.2 – Dashboard développeur

4. Outil Atlassian permettant aux développeurs de réaliser des tests unitaires ou d’autres essais sur leurs
codes.

31

6.2

Dashboard Speed Innovation

Dans le cadre des réunions hebdomadaires avec leurs supérieurs, les managers d’équipe
doivent rendre des comptes résumant l’avancement et les chiffres de leur département. Pour
cela, ils souhaitent utiliser des dashboards reprenant toutes ces informations à partir d’une
seule page. Pour ce dashboard, l’idée souhaitée est d’avoir un flux d’idées de projets qui
progresse par rapport au temps en se transformant en projet en cours de réalisation et pour
ensuite finir en produit.
Ce dashboard permet d’obtenir comme informations :
— La liste actualisée d’idées de projets retenus ;
— Un visuel sur l’avancement et l’état des projets ;
— Un visuel permettant de savoir le retard pris ou non pour chaque projet ;
— La relation actuelle avec chaque client ;
— L’avancée technologique de chaque projet en cours ;
— La valeur client des projets ;
— La profitabilité (bénéfice) pour l’entreprise.

Figure 6.3 – Dashboard Speed Innovation

32

6.2.1

Dashboard par projet

Le dashboard Speed Innovation apporte un maximum d’informations sur les avancées hebdomadaires de l’équipe, mais les détails pour chacun des projets n’y sont pas disponibles. C’est
pourquoi, en complément, il m’a été demandé de réaliser un dashboard supplémentaire pour
chaque projet en cours dans le but d’apporter plus d’informations concernant leur avancée.
À partir de différentes conversations avec les managers, mon rôle a été de mettre en place les
KPIs souhaités pour les différents projets. À travers ces discussions, j’ai trouvé intéressant
d’obtenir pour chaque projet les KPIs suivants :
Un Burndown Chart (par Sprint, Release ou Projet)
Cela permet d’avoir un aperçu sur le projet en cours et d’obtenir l’information suivante :
nombre de jours de travail en retard ou en avance.
Un Cumulative Flow Diagram
Il permet de détecter rapidement la présence ou non d’un bottleneck et de savoir dans quelle
étape du processus celui-ci se trouve.
Un Control Chart
Cela permet de contrôler le Cycle Time des tâches. Si une présence de bottleneck est détectée
dans le Cumulative Flow Diagram, on peut avoir plus de précision concernant les tâches qui
causent ce bottleneck. Le but étant de les lister pour pouvoir les régler.
Un Velocity Chart
Celui-ci permet de superviser la vitesse de production de l’équipe d’une semaine à l’autre. Si
jamais il y a une forte variation entre deux semaines, le but est de trouver une explication à
cela.
Un Pie Chart du workflow 5
Ce dernier permet de visualiser l’avancement du projet et de calculer son pourcentage d’avancement.
5. Flux de travail

33

Figure 6.4 – Dashboard Projet

34

6.3

Dashboard Business Development

J’ai également été amené à réaliser une remise à niveau de ce dashboard dont le but était
d’optimiser la place que prenaient toutes ces informations.
Nous avons, d’un côté, une ligne du temps reprenant pour chaque client l’avancée des coopérations en cours. De l’autre côté, nous avons un visuel sur les activités financières liées aux
projets. Nous avons ensuite un tableau reprenant les chiffres concernant les relations avec le
client.

Figure 6.5 – Dashboard Speed Innovation

35

Chapitre 7

Conclusion
Pour conclure ce rapport, je dirai que ce stage m’a fait gagner en maturité et en expérience.
Le fait de côtoyer des personnes compétentes dans un domaine totalement inconnu m’a poussé
à apprendre de nouvelles choses et à m’intéresser aux nouvelles technologies. Étant passionné
par ces dernières, mais également par l’automobile, ce fut avec joie et motivation que j’ai
réalisé ce stage et découvert le monde de ce métier.
Ce stage n’a pu être que bénéfique pour finaliser mon apprentissage car j’ai pu approfondir
mes connaissances théoriques apprises aux cours et les mettre en pratique dans des cas concrets
au sein d’une équipe d’ingénieurs.
J’ai pu découvrir deux rôles majeurs qui pourraient devenir une option de métier à l’avenir.
Tout d’abord, j’ai découvert le rôle de développeur en équipe Agile, leur manière de travailler
ainsi que leur esprit d’équipe. Le second rôle découvert est celui des managers d’équipe dont
le travail est de superviser l’avancement des projets et d’appliquer les méthode Agile mises
en place par l’entreprise.
J’ai eu l’occasion de découvrir les produits en provenance d’Atlassian ainsi que l’ensemble
de leurs fonctionnalités, car ils sont très prisés en entreprise. Certains employeurs doivent
proposer des formations à leurs nouveaux employés pour ces produits tandis que, pour ma
part, j’ai pu me former tout au long de mon stage.
Pour résumer, ce fut une expérience enrichissante qui me motive davantage à rentrer dans
le monde du travail en entreprise. Je tiens à remercier l’ensemble de mes professeurs qui ont
joué un rôle important dans mon apprentissage du métier, ainsi que mon maître de stage pour
son suivi, sa patience et son partage de connaissances tout au long de ces huits semaines de
stage.

36

Annexe A

Annexes

37

La motivation des employés
1. Pouvez-vous vous présenter brièvement ? (étude, passion, …)
2. Quelle est votre fonction au sein d’AW Europe ?
3. Est-ce que vous pensez jouer un rôle important au sein d’AW
Europe ?
4. Comment vous sentez-vous dans les locaux de l’entreprise ?
5. Comment trouvez-vous la communication dans l’entreprise ?
(Très bonne, bonne, mauvaise, très mauvaise)
6. Qu’est-ce qui vous motive à venir au travail chaque matin ?
7. Au niveau du relationnel, est-ce agréable et instructif de
travailler avec vos collègues dont les compétences ne sont pas
toujours identiques aux vôtres ?
8. Que fait AW Europe pour garder ses employés motivés ?

La hiérarchie du département VIT
9. Quels sont vos différents rôles ou tâches au sein de l’équipe VIT ?
10. Qui est votre supérieur ? Quelle influence a-t-il sur votre travail ?

Le processus de recrutement
11. Comment est établi le processus de recrutement ? Utilisez-vous
des outils particuliers ? Pouvez-vous décrire le processus ?
12. Quelles personnes interviennent lors d’un recrutement ?
13. Comment s’est déroulé votre entretien d’embauche pour votre
part ?
14. Est-ce qu’il y a des qualités ou un état d’esprit particulier à avoir
pour être engagé ?

L’organisation et la gouvernance des projets
15. Comment sont organisées les réunions en interne et avec vos
clients ?
16. De manière plus précise, comment sont supervisés les projets en
cours de l’équipe ?
17. Quelles sont les règles instaurées afin que les réunions se
déroulent correctement ?

2

NAVADAS P3
PHEV

New
customer
Concept
3/3

NAVADAS P2
Fuel

New
Project
1/1

Mobi
2 Learn
3 4

1

Exploration 6 weeks cycle

New
opportun
-ities
4/5

ECO

TME RFI

Driver
Coaching

Road
Frictions

TIC-TAC

1

5

valorization

Coyote
Data

2017.07.25

Launch
App

Opportunities

0 Month

Customer Value
AW(TC)-EUR

3/3

Time

2 Months

Opportunity development 3 months cycle

1 Month

HIGH
MID
LOW

ALPHA

On
Time

Refined
opportunity
Non OEM
Product
OEM
RFI / RFQ
3 Months

CAM/
VIT

PSA
RFQ

Must be
resched
ule or
cancel

ed

DEPT
.
Delay

Page 1

Output

Stopped

Customer
Speed Innovation - Dashboard

Product

2017.07.25

Last week: 5.14 | This week: 4.87 | Target: 6.00
EXPLANATION HERE
EXPLANATION HERE
EXPLANATION HERE
EXPLANATION HERE

Sprint speed of the Team

AW(TC)-EUR

MIB-1757 - Import inrix data into DynamoDb
MIB-1273 - HM Mob: what if no data
MIB-1810 - Map Matching
MIB-1751 - Ensure requirements AWJ are taken into …
MIB-1718 - Compare Heatmap results AEV with those …

Bottleneck(s) detected : IMPLEMENTING, VALIDATING
Issue delay :

Workflow - Bottleneck

4.

Remaining Work & Time Spent (Sprint)

3.

2.

Project delay 2 working days

Roadmap

Implementation of the next step

1.

NAV-ADAS Phase 1
Late

Project - Progress

Very
DEPTlate
.

Page 2

Deadline : 15/11/2017

ACTION : EXPLANATION HERE

On
Time

2017.07.25

AW(TC)-EUR

Dashboard JIRA - Developer

Page 3

DEPT.

2017.07.25

AW(TC)-EUR

Dashboard JIRA - Manager

Page 4

DEPT.


Aperçu du document final.pdf - page 1/47

 
final.pdf - page 3/47
final.pdf - page 4/47
final.pdf - page 5/47
final.pdf - page 6/47
 




Télécharger le fichier (PDF)


final.pdf (PDF, 20.7 Mo)

Télécharger
Formats alternatifs: ZIP Texte



Documents similaires


final
chapitre 3 mc
formation methodes agiles comprendre la demarche
catalogue de formation 2014
arteo conseil catalogue formations
arteo conseil catalogue formations

Sur le même sujet..




🚀  Page générée en 0.013s