Journal de bord (JDB)
Définition : Journal de bord (JDB)
Le journal de bord est un enregistrement séquentiel de ce qui est réalisé, avec des notes permettant de garder la mémoire des réflexions associées.
Chaque entrée est datée et associée aux acteurs concernés.
Il consigne le temps de travail associé aux réalisations.
Il contient des références vers les livrables (documents publics, CR de réunion...).
Attention :
Le journal doit être rendu chaque semaine.
Attention : On ne raconte pas sa vie, on parle des livrables, on donne à voir
Chaque tâche doit produire des choses à voir et à lire ; chaque compte-rendu d'itération consiste à parler de livrables.
Exemple :
Conseil : Faciliter la tâche de la MOA
Le journal consigne la liste des livrables à consulter pour l'itération concernée (on est aussi précis que possible afin de faire gagner du temps à la MOA ; par exemple si on a créé une nouvelle page web on en donne l'URL directe, si on a modifié une page existante on précise à quel endroit).
Le journal intègre la fiche de temps consolidée depuis le début du projet (par exemple sous forme d'un lien vers un autre document en ligne)
Le journal peut intégrer une logique d'auto-évaluation.
Méthode : Auto-évaluation
Complément : Outils
Exercice
Initialisez un journal de bord sur la base du modèle suivant en utilisant une instance Etherpad ou Hedgedoc.
Ajouter une troisième itération de votre invention.
Timeboxing (boîtes de temps)
Définition : Timeboxing (gestion par boîtes de temps)
Principe du timeboxing : Les itérations ont une durée fixe, sont à court terme (< 1 mois), on évalue chaque itération à la fin et on réajuste le plan de travail en fonction des résultats.
Exemple :
Définition : Sprint (boîte de temps)
On appelle souvent sprint une itération correspondant à une timebox (boîte de temps).
Attention :
Il est important que les boîtes de temps aient une durée constante, que les réunions soient régulières, idéalement le même créneau à chaque période (c'est cette horlogerie qui permet au projet un pilotage régulier).
Fondamental :
Il est indispensable que les tâches soient découpée de telle façon que leur durée estimée de réalisation ne dépasse jamais une boîte de temps.
Exemple : Boîtes de temps d'une semaine
Tous les jeudis on livre à 18h.
On se réunit tous les vendredis à 14h.
Conseil :
Les livrables sont toujours antérieurs à la réunion et consultés avant celle-ci par le client.
On ne présente pas ce qui a été fait (c'est déjà connu), on entre directement dans l'étude critique des livrables.
On maintien le plan de travail (TODO-list, product backlog...) à jour.
Pads : Etherpad et Hedgedoc
Définition : Etherpad
Etherpad est un éditeur collaboratif simple à utiliser et très bien adapté à l'écriture collaborative synchrone, y compris avec des nombreux co-rédacteurs.
Exemple : Etherpad chez Picasoft
Définition : Hedgdoc
Hedgedoc (anciennement CodiMD) est un éditeur collaboratif plus avancé et plus fluide qu'Etherpad, qui repose sur l'écriture markdown.
Il propose aussi une gestion des droits et d'URL pour publier le pad sans autoriser de modification.
Il est parfaitement adapté à l'écriture collaborative asynchrone, un peu moins à l'écriture synchrone (ou alors avec deux ou trois co-rédacteurs, il manque l'écriture colorée d'Etherpad pour bien se repérer entre les différents contributeurs).
Exemple : Hedgedoc chez Picasoft
Méthode : Publier une page web avec Hedgedoc
Se connecter à Hedgedoc avec un compte (travailler en mode invité ne permet pas de gérer les droits sur le pad)
Créer un pad à une URL « sympa » en entrant directement la page correspondant à cette URL dans le navigateur (par exemple
https://md.picasoft.net/mon-url)Éditer sa page classiquement
Changer les droits sur la page en la passant du mode
au mode 
.Utiliser la fonction
pour disposer d'une page sans interface d'édition (par exemple https://md.picasoft.net/s/mon-url)Communiquer cette URL ou lier la page depuis une autre page HTML
