WONC DOVA

WONC - DOVA
BEN KHALFALLAH HÉLA
27 Octobre 2018

WONC - DOVA
INTRODUCTION
W O N C
Workﬂow : process et méthodologies.
Organisation : culture et
méthodologies, rôles, management
tools, wiki et blog interne, archives
des documents.
Nomenclature : documents et resources.
Communication : mail et chat.
D O V A
Développement : Architecture et Protocoles
de codage.
Outils : devops, tests, intégration
continue, déploiement continue.
Amélioration continue : rapports qualité,
statistiques, plans de correction et
d’amélioration.
Versioning : git, repository
management, versionning, branches,
commits & pull requests.

WONC - DOVA
WONC
WONC ORGANISER LE FLUX
DU TRAVAIL
ORGANISER
L’ENVIRONNEMENT DE
TRAVAIL
DÉFINIR UN
PROTOCOL DE
COMMUNICATION
+ +=

WONC - DOVA
DOVA
DOVA
DÉFINIR UN
PROTOCOL DE CODAGE
ORGANISER
L’ENVIRONNEMENT DE
CODAGE
MESURE &
AMÉLIORATION
CONTINUE
+ +=
Architecture & Charts Versionning et Process Tests & Qualité

WONC - DOVA
WONC - DOVA
WONC DOVA
Chambre de développement
Client

WONC
WORKFLOW
SPRINT DESIGN DÉVELOPPEMENT
RECETTE
INTERNE
RECETTE
CLIENT
Tant qu’il y a une nouvelle itération
Itération
MAINTENANCE ET TMA
MISE EN PRODUCTION
Fin
10 jours
RETROSPECTIVE
SPRINT
DÉVELOPPEMENT

SPRINT DESIGN
PRÉSENTATION DU BESOIN
ENRICHISSEMENT DU
BESOIN (BRAINSTORMING)
SKETCHING
(PAPIER OU TABLEAU)
PROTOTYPE
(AXURE OU JUSTINMIND)
USER FLOWS
(PAPIER OU TABLEAU)
VALIDATION
MODULES ET FONCTIONNALITÉS
CHIFFRAGE ET COTATION
CONCEPTION TECHNIQUE (MODULES
PRINCIPAUX)
THÈMES (ÉCRANS PRINCIPAUX)
(SKETCH, ILLUSTRATOR, PHOTOSHOP)
ICONOGRAPHIE (ICÔNES PRINCIPALES)
TYPOGRAPHIE
VALIDATION
DEV DESIGN
DEV, DESIGN & QUALITÉ1
2 2

SPRINT DESIGN
LIVRABLE CLIENT
LIVRABLE TECHNIQUE LIVRABLE UI/UX
RAO PRÉSENTATION UI/UX
TYPOGRAPHIE
3
DEV DESIGN
PROTOTYPE, SKETCHING & USER FLOWS
MODULES ET FONCTIONNALITÉS
PRINCIPAUX)

SPRINT DESIGN
DOCUMENTS MODULES ET FONCTIONNALITÉS
PRINCIPAUX)
TYPOGRAPHIE
RAO
PRÉSENTATION UI/UX
Excel
Excel
Word (docx)
Word (docx)
PDF
PDF
PDF
PDF
SKETCHING
(PAPIER OU TABLEAU)
PROTOTYPE
(AXURE OU JUSTINMIND)
USER FLOWS
(PAPIER OU TABLEAU)
DEV, DESIGN & QUALITÉ
DESIGN
DEV

SPRINT DESIGN
PLANIFICATION
J1 J2 J3 J4 J5
Présentation,
compréhension
et enrichissement
du besoin
Sketching
(écrans
principaux)
User Flows
(fonctionnalités
principales)
Validation
Prototype
(DEV)

SPRINT DESIGN
PLANIFICATION
J6 J7 J8 J9 J10
Validation
- Modules et
fonctionnalités
(DEV)
- Présentation
UI/UX (Design)
- Chiffrage et
cotation (DEV)
- Présentation
UI/UX (Design)
- RAO (DEV)
- Présentation
UI/UX
(Design)
- RAO (DEV)
- Présentation
UI/UX
(Design)
Attente de la validation client

SPRINT DESIGN
IMPORTANCE
▸ Carder l’attendu fonctionnel du projet.
▸ Réduire les risques d’incompréhension du besoin.
▸ Avoir une communication claire et organisée avec le client.
▸ J1-J2-J3 : la présence de tous les équipes concernées
(design, dev, qualité) par le projet est fortement
recommandé : une seule compréhension et un seul
chemin.

SPRINT DESIGN
SKETCHING : COMPRÉHENSION , ENRICHISSEMENT & SYNTHÉSE
TRANSFORMER LE BESOIN RÉEL EN UN PROBLÈME INFORMATIQUE

SPRINT DESIGN
SYNTHÈSE DES IDÉES & CONCEPTSCOLLABORATION, ÉCHANGE , PROPOSITIONS, IDÉES,...

SPRINT DESIGN
CADRAGE DU PÉRIMÈTRE DES FONCTIONNALITÉSEXPLICATIONS DES FONCTIONNALITÉS

SPRINT DESIGN
▸ Le sketching aide à penser différemment : la visualisation de l’idée va
amener à découvrir d’autres problèmes auxquels il faudra aussi des
solutions.
▸ Le sketching permet d’explorer des alternatives en prenant moins de
risque.
▸ Le sketching va encourager et favoriser la discussion collective et
l’échange entre les différents intervenants. Chacun se sent plus
impliqué et va apporter son expertise pour faire avancer les choses
dans le bon sens.
▸ Le sketching peut être fait sur des mockups (papier et stylo) et non
nécessairement sur un outil de design ou de sketching.

SPRINT DESIGN
USER FLOWS
▸ User storyboards permettent
d’identiﬁer :
Les scénarios de navigation (ﬂow).
Les uses cases de navigation.
Les animations possibles.
▸ User Flows peut être fait sur des
mockups (papier et stylo) et non
nécessairement en utilisant un
outil.
SKETCHING USER FLOWS
CONTENU DYNAMIQUE

SPRINT DESIGN
MODULES & FONCTIONNALITÉS

SPRINT DESIGN
TOTAL DEV : 13.5 J/H 13.5 J/H 13.5 J/H
Déﬁnition des ressources nécessaires et des deadlines primaires.

SPRINT DESIGN
CONCEPTION TECHNIQUE DES MODULES PRINCIPAUX
Conception UML des modules principaux

SPRINT DESIGN
RAO
▸ RAO est un document synthétisant toute l’étude technique faite.
▸ Il doit obligatoirement contenir ces chapitres :
Spéciﬁcation de besoin.
Solution technique :
1. Modules et fonctionnalités.
2. Conception technique.
3. Architecture de la solution.
4. Choix techniques.
Design (démarche, ergonomies et exigences).
Méthodologies et process.
Planiﬁcation et chiffrage.
Moyens de mise en oeuvre / Ressources nécessaires.

SPRINT DESIGN
PRÉSENTATION UI/UX

SPRINT DESIGN
ATTENTE DE LA VALIDATION CLIENT

LANCEMENT DE LA PRODUCTION
GO CLIENT
PRÉPARATION DU BACKLOG PRODUIT
PRÉPARATION DU SPRINT BACKLOG
LANCEMENT DE DÉVELOPPEMENT
En se basant sur les documents :
- Modules et fonctionnalités.
- Chiffrage et cotation.
PRIORISATION CLIENT : DÉFINITION DES
VERSIONS ET DES LOTS (SPRINTS) COMPOSANT ÉPIC
STORY TASK
Jira, Wrike

LANCEMENT DE LA PRODUCTION
Front Web, Front Mobile, BackendCOMPOSANT
ÉPIC
STORY
TASK
Modules (Authentiﬁcation)
Fonctionnalité (Login)
Tâches (UI, Branchement, Intégration)
VERSION

ITÉRATION - SPRINT DÉVELOPPEMENT
DÉVELOPPEMENT
RECETTE
INTERNE
RECETTE
CLIENT
Tant qu’il y a une nouvelle itération
Itération
RETROSPECTIVE
DCT
DESIGN (PAR SPRINT)
DÉVELOPPEMENT BACKEND
DÉVELOPPEMENT MOBILE (FONCTIONNEL)
DÉVELOPPEMENT FRONT WEB (FONCTIONNEL)
DÉVELOPPEMENT MOBILE
(INTÉGRATION DESIGN)
DÉVELOPPEMENT FRONT
WEB (INTÉGRATION DESIGN)
RECETTE
INTERNE
RECETTE
CLIENT
DCF
QUALITÉ & TEST : PRÉPARATION DES SCÉNARIOS DES TESTS FONCTIONNELS
SWAGGER
DEVOPS
RETRO

ITÉRATION - SPRINT DÉVELOPPEMENT
DCT
DESIGN (PAR SPRINT)
DÉVELOPPEMENT BACKEND
DÉVELOPPEMENT MOBILE (FONCTIONNEL)
DÉVELOPPEMENT FRONT WEB (FONCTIONNEL)
DÉVELOPPEMENT MOBILE
(INTÉGRATION DESIGN)
DÉVELOPPEMENT FRONT
WEB (INTÉGRATION DESIGN)
RECETTE
INTERNE
RECETTE
CLIENT
DCF
SWAGGER
DEVOPS
RETRO
2j 3j 2j 3j 3j 2j 0.5j
Sprint 15 jours
10 jours développement 5 jours recette

ITÉRATION
DCT : DOCUMENT DE CONCEPTION TECHNIQUE
▸ Pour chaque itération, l’équipe développement devra faire un document de conception
technique avant de commencer le développement.
▸ Ce document met en évidence :
La liste des écrans : code écran, nom écran, description.
Pour chaque écran les WebServices nécessaires : code écran, nom écran, titre WS, requête WS, commentaire.
La liste des WebServices : titre WS, requête WS, méthode WS, nom WS, description WS.
La description de chaque WS : méthode, header, entrées, sorties, commentaire.
▸ Le format de ce document : excel.
▸ Le DCT est le protocole de développement entre la partie Backend et la partie Frontend : la
partie Frontend pourra exploiter des mocks (SOAP-UI, JSON Web Server, fichiers, …) respectant
obligatoirement les spécifications décrites par le DCT (en attendant la fin de développement
Backend).
▸ Les équipes doivent absolument respecter ce protocole de développement.
▸ Toute modification dans le DCT devra être signalée aux différentes équipes.

ITÉRATION
LISTE DES ÉCRANS

ITÉRATION
CORRESPONDANCE ÉCRAN-WS

ITÉRATION
LISTE DES WS

ITÉRATION
DÉTAILS D’UN WS

ITÉRATION
SWAGGER
▸ Après le développement des Webservices nécessaires, l’équipe Backend devra
obligatoirement mettre Swagger à jour.
▸ Swagger est géré par version d’API.

ITÉRATION
DCF : DOCUMENT DE CONCEPTION FONCTIONNELLE DÉTAILLÉ
▸ Le document de conception fonctionnelle détaille :
l’arborescence de l’application.
les écrans : nomenclature et fonctionnalités incluses.
les règles de chargement et d’afﬁchage.
les règles de navigations.
les règles générales.

ITÉRATION
DESIGN PAR SPRINT
▸ L’équipe design devra fournir :
les spéciﬁcations nécessaires et exactes à suivre
absolument : marges, padding, dimensions, couleurs,
typographie.
les spéciﬁcations peuvent être sous formats d’un
document PDF ou en utilisant des outils comme sketch,
invision, zeplin …
les icônes nécessaires dans les différents formats
demandés.

ITÉRATION
DEVOPS, QUALITÉ ET TEST
DEVOPS
QUALITÉ & TEST
Mise en place des script
d’intégration continue et
déploiement continue.
Document excel : scénario, ok, ko, priorité,
screenshot, commentaire (scénario de
reproduction) .
Architecture cloud, Kubernetes, Google
Cloud, Azure, AWS, Codacy, CircleCI,
TeamCity, Jenkins, Bitbucket pipeline….
RECETTE
INTERNE

ITÉRATION
RECETTE INTERNE
RECETTE INTERNE
DCF
DCT
SCÉNARIOS DES
TESTS
FONCTIONNELS
SPEC DESIGN
Conformité aux
spéciﬁcations
fonctionnelles (DCF).
Conformité aux
spéciﬁcations design.
Tests d’intégrité :
comportement de
l’application en
changeant la réponse
des WS (cas extrêmes :
vide, nulle, changer le
format, …) (DCT).
Tests extraterrestres.

ITÉRATION
RECETTE INTERNE
Conformité aux
spéciﬁcations
fonctionnelles (DCF).
Conformité aux
spéciﬁcations design.
Tests d’intégrité :
comportement de
l’application en
changeant la réponse
des WS (cas extrêmes :
vide, nulle, changer le
format, …) (DCT).
Tests extraterrestres.
équipe design
équipe qualité & test

CULTURE & MÉTHODOLOGIES
AGILE
Kanban
Support phase
Scrum XP
Building phaseActors &
Ceremonies
Quality
Tools
ScrumBan
https://www.linkedin.com/pulse/process-methodologies-h%C3%A9la-ben-khalfallah/

RÔLES
https://www.linkedin.com/pulse/process-methodologies-h%C3%A9la-ben-khalfallah/

DESIGN
Il est fortement recommandé d’utiliser Sketch et Zeplin pour
éviter d’avoir plusieurs sources AI (Adobe Illustrator) ou
Photoshop. AI (Adobe Illustrator) sera utilisé pour les dessins
complexes.
Pour les animations : Principle
http://principleformac.com/

RÈGLE GÉNÉRALE
TypeDoc_NomProjet_Sprint_Version.extension
Sketching Sketching_News_V1.4.pdf
User Flows User_Flows_News_V1.2.pdf
Modules et fonctionnalités Modules_News_V1.3.xlsx
Chiffrage et cotation Chiffrage_News_V1.0.xlsx
RAO RAO_News_V1.0.docx
Présentation UI/UX Presentation_News_V1.1.pdf
Planiﬁcation et Versions (lots) Planing_News_V1.1.xlsx
DCF DCF_News_V1.0.docx
DCT DCT_News_Sprint_1_V1.1.xlsx
Spéciﬁcation design Spec_Design_News_Sprint_2_V1.1.pdf
Cahier de recette (scénario des tests) Recette_News_Sprint_2_V1.1.xlsx
Évaluation du sprint Evaluation_News_Sprint_2_V1.1.xlsx

ÉVALUATION DU SPRINT
Évaluation du projet en terme de nombre de bugs trouvés (classé selon le
degré : bloquant, mineur, simple ).
ÉQUIPE QUALITÉ & TEST

RÈGLE GÉNÉRALE
‣ Il ne faut pas utiliser : les accents, les espaces, les – et les
caractères spéciaux.
‣ Séparer les mots par des underscores.
TypeDoc_NomProjet_Sprint_Version.extension

ICÔNES ET IMAGES
‣ On adopte:
le préfix ic pour les icônes.
le préfix img pour les images (comme les images de help ou du
splashscreen).
‣ L’exportation des images iOS respecte les breakpoints : 1x, 2x et 3x.
(screen scale factor).
‣ L’exportation des images Android respecte les breakpoints : ldpi,
mdpi, xhdpi, xxhdpi,... (screen density).
‣ L’exportation WEB doit être en format svg.
‣ Le nom de l'image suffit pour connaitre l'emplacement et la
fonctionnalité.

ICÔNES ET IMAGES
ic_emplacement_fonctionalité_statut_langue (statut et langue sont optionnels)
img_emplacement_fonctionalité_langue (langue est optionnelle)
ic_tabbar_favoris_fr.png
ic_tabbar_favoris_fr@2x.png
ic_tabbar_favoris_fr@3x.png
ic_tabbar_favoris_selected_fr.png
ic_tabbar_favoris_unselected_fr.png
img_help_swipe_fr.png
img_help_swipe_fr@2x.png
img_help_swipe_fr@3x.png

ICÔNES ET IMAGES
‣ Il est très important de garder les mêmes noms et les
mêmes dimensions des images déjà exportées.
‣ Un nouveau nom implique un nouveau fichier => un
fichier non existant pour le compilateur => une image non
affichée => bug client.
‣ Un changement dans les dimensions => un changement
dans les mesures et les autolayouts => bug client.
‣ Le non-respect des conventions de nommages et des
dimensions est considéré comme un bug pour l’équipe
design.

FONTS
nomprojet_nomfont.ttf
nomprojet_nomfont.otf

MAIL
[nom projet][Pôle] : objet du mail
Pôle : Design, Mobile, Web, Backend, Qualité, Gestion.
[Générale][Pôle] : objet du mail
Pôle : Administration, RH, Design, Mobile, Web, Backend,
Qualité, Gestion.

DÉVELOPPEMENT
RÈGLES GÉNÉRALES
▸ Avant tout développement, les leads développeurs des équipes
doivent faire une charte de développement.
▸ La charte de développement est un protocole à suivre absolument.
▸ Elle met en évidence les best practices et les guidelines (UI/UX et
fonctionnels) concernant chaque plateforme de développement.
▸ À la ﬁn de chaque sprint, la charte devra être revue.
▸ Les tests unitaires sont obligatoires.
▸ Les checklists tels que de revue de code et d’avant commit, sont
recommandées.
http://helabenkhalfallah.e-monsite.com/blog/

DÉVELOPPEMENT
RÈGLES GÉNÉRALES
▸ Tous les projets front (mobile ou web) doivent
obligatoirement suivre l’architecture ASIS :
A S I S
APIS
SERVICES
INTERFACE (UI)
SETTINGS
APIs ou Core
La couche métier (Rest, Graphql,
Providers, ORM)
La couche UI : divisée en pages
et composants
Mise en forme

DÉVELOPPEMENT
PROCESS
DCT
CHECKLISTS
ARCHITECTURE
DÉVELOPPEMENT CONTRÔLE DE LA
QUALITÉ DES CODES
DÉPLOIEMENT
CHARTS

DÉVELOPPEMENT
PROCESS
BRANCH CREATE
CODACY
(JS PROJECTS)
CIRCLE CI
PULL REQUEST
MERGE & BRANCH
CLOSE
REVIEW
DEV UNIT TEST PRE-COMMIT COMMIT & PUSH
Linters
CIRCLE CI
You break it, You ﬁx it !
GIT IGNORE

DÉVELOPPEMENT
REVUE DU CODE SOURCE
REVUE QUOTIDIEN
REVUE DES PULL
REQUEST
Revue globale du projet chaque matin (2h)
Revue de chaque Pull Request
LEAD DÉVELOPPEUR
Le lead développeur est le maître du code. Il doit s’assurer du respect de la
qualité des codes sources avant les merges, des chartes de développement
et des architectures déﬁnies.

DÉVELOPPEMENT
QUALITÉ
UNIT TESTS LINT
CODACY
(JS PROJECTS)
CIRCLECI
CHARTE &
ARCHITECTURE
Obligatoire

LINTERS
L’utilisation des linters en local est obligatoire
Ne jamais commiter ou pusher un code avec des erreurs lint

ANALYSE STATIQUE DES PROJETS JS - CODACY
Après chaque nouvelle push, le développeur devra
voir le statut de sa modiﬁcation et corriger les erreurs
JS

INTÉGRATION CONTINUE - CIRCLECI
Après chaque nouvelle push, le développeur devra
voir le statut de sa modiﬁcation et corriger les erreurs

GESTION DES VERSIONS
SEMANTIC VERSIONING
▸ Given a version number MAJOR.MINOR.PATCH, increment
the (2.0.0) :
MAJOR releasing breaking changes
MINOR releasing new features.
PATCH releasing bug ﬁxes.
https://semver.org/

RÈGLES GIT : BRANCHES, COMMITS ET PULL REQUEST
Atomic commits : telling short stories with Git.
Branch Name : reason__details--tag
Commit Message :
git commit -m « short description of the atomic commit purpose »
Pull Request :
Title :
Reason details
Description :
- DONE : (what done)
- Remains : (what remains) => work in progress Pull Request.
http://sethrobertson.github.io/GitBestPractices/

Atomic commits : telling short stories with Git.
‣ For example, if we want to build a car :
We shouldn’t have a single commit : building car.
But we should have these steps (atomic commits) :
1. building the engine.
2. preparing wheel.
3. preparing carcass.
4. painting carcass.
5. assembling.

▸ Reason : You might branch because of the following reasons and use them in the name:
New feature / New page / New Component
Content Changes
Fix / Hot-fix / Patch
Enhancement / Optimisation
Refactor
Delete / Remove / Undo
Update / Upgrade
‣ Reason — label must be identical to the purpose of the branch.
‣ Try to have a single word in most cases and in extreme cases use - to separate multiple words.
‣ Examples:
Branch for a new page or feature : page__page-details or feature__feature-details.
For a Fix or a Patch : fix-123__fix-details or patch__patch-details .
For Deleting : delete__branch-details or remove__branch-details.

▸ Details : A two or three short-word descriptions about the branch.
▸ Try not to go beyond three words, as you may end up having long branch name.
▸ Use three words only if you don’t have the need of using tag name.
‣ Avoid long descriptive names for branches. They are branch names, not news
headlines. Make them as short and descriptive as possible. It is always possible
to cutdown the branch name to the specifics not to make it a long-named
branch.
‣ Examples:
Branch for a new page or feature : page__private-policy or feature__public-
api.
For a Fix or a Patch : fix-123__signup-routing or patch__file-uploader.
For Deleting : delete__duplicate-images or remove__analytics-tracking.

▸ Tag: It is optional.
▸ Use only one-word description for this.
‣ Examples:
Branch for a new page or feature : page__private-
policy--12345678 or feature__public-api—v2.
For a Fix or a Patch : ﬁx-123__signup-routing--recurring
or patch__ﬁle-uploader—pdf.
https://codeburst.io/let-the-branch-name-do-all-the-talking-in-git-e614ff85aa30

Run before push, check lint before commit
You should never push a breaking code
ATOMIC

AMÉLIORATION CONTINUE
ÉVALUATION GLOBALE DU
PROJET
ÉVALUATION DU SPRINT
RAPPORTS QUALITÉ
PLAN D’ACTIONS
équipe Qualité & Test
équipe Qualité & Test + équipe
gestion
Boucle Fermée

ANNEXES
▸ http://helabenkhalfallah.e-monsite.com/blog/mobile/design-pattern-
mobile-application.html
▸ https://www.linkedin.com/pulse/la-gestion-en-boucle-ferm%C3%A9e-
h%C3%A9la-ben-khalfallah/
▸ https://www.linkedin.com/pulse/process-methodologies-h%C3%A9la-
ben-khalfallah/
▸ https://www.linkedin.com/pulse/architecture-asis-ios-h%C3%A9la-ben-
khalfallah/
▸ https://www.linkedin.com/pulse/les-r%C3%A8gles-de-
d%C3%A9veloppement-angular-h%C3%A9la-ben-khalfallah/
▸ http://helabenkhalfallah.e-monsite.com/blog/mobile/les-re-gles-de-
codage-programmation-de-fensive.html

WONC DOVA

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (7)

Similaire à WONC DOVA

Similaire à WONC DOVA (20)

Plus de Héla Ben Khalfallah

Plus de Héla Ben Khalfallah (13)

WONC DOVA