glossaire
Indicateurs clés de performance.
[TODO]
ou Minimum Viable Product
Stratégie de développement de produit utilisée pour de rapides et quantitatifs tests de mise sur le marché d'un produit. MVP peut également désigner le produit lui-même, le MVP1 étant le premier produit viable pouvant être mis sur le marché, puis MVP2 son évolution, etc.
Maquette graphique élémentaire qui permet d'imaginer le produit et faire des itération sur les écrans avant de lancer les développements. La version sans graphisme est le "wireframe", qui peut être fait sur papier et permet déjà de faire des itérations sur des hypothèses d'interface.
exemples d'outils : https://moqups.com
Synthétise le projet entrepreneurial d'une startup (1min max).
ou P.O. ou chef de produit
Le ou la PO coordonne les équipes tech, métier et les éventuels partenaires. Il est en charge de rédiger les stories ou issues et de les prioriser pour que les développeur(se)e puissent les mettre en oeuvre.
Le développement du produit est fixé par les KPI qui sont re-questionnées en continu.
Liste de tâches ( sous ensembles de fonctionnalités à développer), qui vont être priorisées et quantifiées en vue d’alimenter les sprints.
Un sprint dure ~2 semaines et permet de se concentrer sur une selection des tâches.
Au début d'un sprint une séance de "Sprint planning" (1h max) est organisée pour évaluer et prioriser les tâches à réaliser.
A la fin d'un sprint, il y a en général une démo (1h max) pour que toutes les nouveautés soient reviewées et partagées, et une rétro (1h max) pour progresser sur les pratiques si besoin.
Standup meeting. Point hebdomadaire et public, le mardi à 12h, où startup pitche sur son produit partage ses avancements, succès et difficultés.
Faire des tests à partir de "recettes" c'est à dire de scénarios de test. Permet de valider ou non des fonctionnalités.
Processus par lequel on rend un produit/service ludique (et potentiellement addictif)
Série d'instructions qui permettent à une machine d'executer des tâches répétitives
Exemple en JavaScript :
// définition d'une fonction
function hello(number) {
if (number === 42) {
alert("You win !");
}
}
// appel de la fonction
hello(1); // rien ne se passe
hello(42); // renvoie une alerte "You Win!"Dans une application, il y a plusieurs codes qui entrent en jeu :
- le code du backend qui gère la base de données et ses accès.
- le code du frontend qui gère l'interface graphique et ses interactions avec le backend.
Pour pouvoir mettre une application en ligne, les fichiers de celle-ci doivent être déposés sur un "serveur" connecté à internet.
Lorsque vous tapez hello.fabrique.social.gouv.fr votre ordinateur va interroger un annuaire via le système DNS pour savoir où est situé votre serveur (soit son adresse IP sous la forme 120.40.44.217). Le réseau internet et ses routeurs se chargent alors de transmettre physiquement et
à la vitesse de la lumière votre demande jusqu'à votre serveur qui va retourner ce que vous avez demandé, c.a.d votre page web sous forme de un ou plusieurs fichiers HTML, CSS, Javascript.
Nous hébergeons actuellement les applications sur Azure.
ou "ouverture des données"
L'OpenData permet de partager ce qui est l'or de tout système informatique : les données sous forme de "datasets" soit des fichiers CSV ou JSON, exploitables par une machine.
Utiliser de l'open-data c'est avoir accès à des données de référence brutes et de qualité.
Faire de l'open-data c'est publier et maintenir des datasets de qualité.
Développer en "open-source" c'est produire du code 100% public que n'importe qui peut réutiliser à sa guise. En publiant notre code et nos issues sur GitHub, tout l'historique d'un projet peut être consulté et réutilisé. A ce titre, nous nous devons d'adopter des standards de développement et de rédaction de haute-qualité.
Le code que nous produisons nous-même est composé au moins de 90% de briques open-sources existantes.
Voir la politique de contribution au logiciel libre de l'état
Le "logiciel libre" c'est le concept du partage de connaissances sans frontières qui a donné lieu en pratique au mouvement open-source.
ou "Application Programming Interface" soit des conventions techniques pour échanger des données entre systèmes.
En mettant en place une API on peut séparer le backend qui gère les données du frontend qui gère l'interface, ce qui permet d'avoir plusieurs frontends et de proposer notre service en tant que "plateforme".
Le backend est la partie non visible d'un service, il expose une API qui est utilisée par le frontend et/ou par d'autres services. Il gère également la persistance des données et leur accès (la base de données), l'authentification (login) et les autorisations (accès aux données).
C'est tout le cerveau de votre service.
Interface d’administration, qui permet d’administrer le site sans nécessité d’écrire des lignes de code. ex: gérer du contenu, articles, images, comptes...
La partie visible d'un service, soit l'interface graphique : Les textes, boutons, icônes, formulaires et autres tableaux qui composent votre application. Dans une application web, le frontend est composé de :
- HTML pour la structure de la page
- CSS pour le style de la page
- JavaScript pour les interactions
Si l'interface a besoin de récupérer des données, elle fait alors appel à l'API du backend via la méthode JavaScript fetch.
Un "système de gestion de versions" qui permet concrètement d'historiser tous les changements sur un ensemble de fichiers. Ce système est décentralisé ce qui permet de facilement travailler à plusieurs en parallèle.
Exemple d'historique GIT :
GitHub est la plateforme qui nous permet d'héberger l'historique GIT de nos projets : Code, Commits... mais aussi la documentation ou les issues.
Quelques notions :
- repo (repository) : un "dossier" qui stocke en général une application ou un site web.
- contributeur(ice) : personne qui a déjà modifié un ou plusieurs fichiers d'un repo
- commit : une ou plusieurs modifications dans le code, envoyées par un(e) contributeur;
- issue : ticket. pour signaler un bug ou demander une fonctionnalité (feature)
- milestone : un ensemble d'issues avec une date espérée de fin. généralement, une milestone = un sprint
- pull request : permet à un contributeur de soumettre des modifications (commits) à l'équipe
-
branche : chaque repo peut avoir plusieurs versions parallèles, les branches. La branche par défaut est nommée
master
Les issues permettent de définir les tâches techniques et les milestones de les programmer.
[Todo: reference good issue] [Todo: tag + issues conventions]
Techniquement, nous utilisons une convention de nommage pour les commits et la convention SemVer pour les numéros de version (releases).
NB : Nous ne stockons aucune donnée sensible sur GitHub
Un format de texte brut qui permet de rajouter une mise en forme minimale. Utile pour écrire des issues ou commentaires dans GitHub par exemple. Ce glossaire est édité en markdown.
voir guide pratique de la syntaxe et un exemple d'éditeur en ligne pour s'entrainer : https://pad.etalab.studio
Voir aussi : http://jargonf.org