CoopticNet : ReunioN20130312

======Code Source Cooptic du 12 mars 2013======

**Préambule** : à rajouter
ceci est plutôt un guide méthodo qu'un bilan de notre fonctionnement 
l'objectif c'est que cela re-serve pour d'autres projets

- **tableau de bord des tâches**
Page wiki où sont inscrites les différentes tâches à faire avec le nom de la personne en face. Un module de YesWiki permet d'avoir une barre d'avancement ce qui permet de savoir où on en est de la tâche (sous forme de pourcentage). Ce tableau de bord permet de suivre l'avancement des tâches et de faire le point en début de chaque réunion sur les tâches terminées et sur les blocages rencontrés. À la fin de chaque réunion, on complète avec les nouvelles tâches. Les tâches complétées sont archivées en bas de page quand une partie du projet est fini. Chaque personne responsable des tâche met à jour le degré d'avancement. Cet outil doit être utilisé après une phase d'explicitation et s'il correspond aux méthodes d'organisation des membres du groupe. La difficulté tient au fait que chaque participant a déjà son système de gestion de tâche et que cet outil se sur-ajoute aux outils existants. Il existe des outils semblables mais plus visuels comme le kanban. Cet outil est le reflet d'un système d'organisation spécifique qui doit explicité au début et être accepté par tous, sinon cela ne marche pas. Quelque soit l'outil utilisé, il est important d'avoir un endroit où chacun peut voir l'avancée du projet de manière globale. (www.kanbanpad.com)

- **scrum** (méthodologie)
 Scrum est une méthodologie de travail, de type "agile". Elle est souvent utilisée par des équipes de développement. Nous en avons extrait quelques grands principes que nous essayons d'appliquer lors des projets.
 - lister toutes les tâches à faire (sans ordre chronologique ni d'importance) puis leur attribuer 2 notes : une reflétant la difficulté / complexité de la tâche et l'autre l'avancée / la plus value pour le projet
 - commencer par traiter les tâches qui ont la plus grande plus-value pour le moins d'effort à fournir ... cela donne une grande satisfaction pour démarrer le projet collectivement
 - toutes les tâches étant listées on peut attribuer les premières à réaliser ... en fonction de l'avancement chacun peut aller piocher dans la liste des tâches à faire.
 - les priorités du projet peuvent être revues tout au long de l'avancée du projet ... il n'y a pas de cahier des charges fixe (qui ne peut pas être revu)
 - la méthode scrum permet de faire le lien entre les concepteurs / réalisateurs et les futurs utilisateurs
 - favoriser les tâches, qui même après un arrêt prématuré du projet, seront directement applicable et serviront le projet
 objectifs : 
 - la transparence : on sait ce qu'il y a faire, ce que chacun fait, où nous en sommes ...
 - l'adaptation = l'acceptation du changement : notion de cahier des charges mouvant
 - la régularité : on fait des points rapides mais réguliers et fréquents
 - la collaboration : on travaille ensemble (concepteurs et futurs utilisateurs)
 
  - **scrumblr.ca **(outils)
un simple tableau blanc avec des post-it !
il est possible d'organiser le tableau en colonnes ... par exemple pour suivre l'avancée des tâches (à faire / en cours / terminée)

- **agenda partagé : **
Création d'un calendrier au format ICS qui peut être lu aussi bien sur Thunderbird que sur Google Agenda. Deux calendriers ont été créés : un pour le montage du projet et l'autre pour la formation. Sur ces calendriers on retrouve les dates et les heures des séminaires, des regroupements, des réunions de COPIL et de sous-commissions. Tous les participants peuvent le modifier. L'intérêt est double :
- chacun a la même source d'information, notamment quand des dates changent
- cela permet d'avoir une trace de toutes les réunions qui ont eu lieu, notamment pour établir le bilan du projet.
Un mode d'emploi pour l'intégration du calendrier dans les outils de chacun est indispensable. De même, il est préférable, au lancement du projet, de prendre du temps lors de la première réunion physique, pour vérifier que tout le monde a réussi à l'intégrer. Il faut prendre un temps pour expliquer comment le lire et comment le modifier.
Il doit être précis et indiquer les heures exactes de début et de fin, notamment pour les regroupements et les séminaires, donc éviter les évènements notés pour la journée

- **Google document **
Permet de partager et de co-écrire des documents de type bureautique. Cet outil s'articule dans une trilogie : etherpad/dropbox/google document. Vérifier dès le démarrage du projet que tous les participants ont un compte Google et récupérer les adresses correspondantes. Il est intéressant de créer sur le wiki une page annuaire répertoriant les adresses mails, les adresses du comptes dropbox, les adresses du compte Google et les identifiants Skype de tous les participants. 
Créer un dossier partagé et y inscrire tous les participants avec les droits en écriture. Le titre est explicite (ex. coopticPartagé) pour permettre aux participants de faire la différences entre leurs propres dossiers Google Document. Automatiquement, tous les documents créés et rangés dans ce dossier ont les mêmes droit que le dossier, donc ils sont partagés automatiquement avec tous les participants, avec les droits d'écriture. Cela permet de retrouver tous les documents au même endroit, d'être sur d'avoir les bonnes adresses et de n'oublier personne. L'intérêt du dossier partagé par rapport au choix de créer des droits au coup par coup en utilisant la fonction" tous les utilisateurs disposant du lien" c'est de rassembler tous les documents au même endroit pour s'y reporter plutôt que de rechercher dans ses mails les différents liens.
Il faut prendre un temps en début de projet pour expliciter le fonctionnement technique à tous.
De même en début de projet, il faut se mettre d'accord sur l'utilisation de chacun des outils :
- etherpad : prise de note en réunion
- google document : co-écriture de document
- dropbox : document finalisé.
Google Document est notamment intéressant pour la création de tableaux : récupérer des contacts sous une forme structurée (qui permet le publipostage par exemple), qui fait quoi, etc... mais aussi pour la création de diaporama, qui peuvent ensuite être inclut dans le wiki en ligne.

- **Mail **(à regrouper avec liste de diffusion)
préciser sujet dans les mails et éviter de faire répondre si on change de sujet (à mettre dans liste de diffusion ?)

======Chronologie : mise en place du projet et son déroulement======

Code source du montage du projet (et non code source de la formation Cooptic)
 - Alternance présence/distance, synchrone/asynchrone :
En présence et synchrone : on lance pleins d'idées (brainstorming) + prise de décisions effective et collective
En asynchrone : appropriation (temps pour découvrir et comprendre le vocabulaire et le fonctionnement d'un projet européen (workpackage,...) + temps de travail par structure et au sein de chaque structure + le temps pour faire des propositions
--> aller retour synchrone/asynchrone permet de faire le lien avec les structures 
l'alternance présence / distance permet de ne pas avoir de temps mort (il se passe des choses - le projet avance - entre les séminaires)
La différence entre distance et présence c'est le type de travail que l'on fait qui est modifié par la modalité présence ou distance mais pas la continuité du travail effectué.
utilisation d'un wiki pour compléter / rédiger collectivement le dossier --> http://wikis.cdrflorac.fr/w/wiki047/ (synchrone/asynchrone)
utilisation de google doc
Les différents paragraphes du dossier européen sont divisés en autant de page wiki à compléter par les personnes concernées. À partir de cette matière brute, la réécriture globale du projet est confiée à une ou deux personnes, bien identifiées, afin de garantir la cohérence du projet. Dans ce cadre, Google Document est utilisé pour les tableaux (élaborer le budget ou la chronologie du projet (enchainement des workpackages)
 Alternance présence/distance et synchrone/asynchrone
 séminaire (présent synchrone) : calage, réorientation (séminaire = moment charnière)
 réunions mensuelles (à distance synchrone) : suivi, analyse des points de blocage
 le temps de travail dans sa structure (à distance  et asynchrone) individuel ou collectif 
 au cours du projet, besoin de spécialisation en groupe plus réduits en utilisant les même modalités (distance/présence, synchrone/asynchrone) et les mêmes outils
- importance du lancement du projet lors d'un séminaire en présentiel, assez en amont en prévoyant une partie appropriation des outils et des méthodes.
De façon plus générale
- tout le monde avait accès à tous les outils mais aussi leur gestion (possibilité de modification ...)
- confiance générale entre les partenaires

Qu'est-ce qu'on veut en faire ? pour qui ? comment on le présente ?