Gestion et coordination des équipes pour le Drupal n'go

Les méthodes agiles ont sans doute beaucoup à apporter à la communauté.

Personnellement, je serai super curieux et heureux d'avoir la chance de voir comment on peut concrètement mettre en pratique ce type de méthode.

L'intérêt pédagogique de la mise en place d'une telle méthode me semble constituer en soi une motivation supplémentaire pour participer au Drupal NGO.

Le livre SCRUM and XP from the trenches librement téléchargeable à partir du lien indiqué plus haut est vraiment super intéressant.
Je vous le recommande à mon tour, ca se lit très facilement.

Ces 3 articles sur wikipedia sont également de très bonnes qualité :

http://fr.wikipedia.org/wiki/Manifeste_Agile
http://fr.wikipedia.org/wiki/Scrum
http://fr.wikipedia.org/wiki/Extreme_Programming

A quelles adaptations penses tu ?

Il est vrai que le contexte de drupal ngo est bien particulier :
-Une durée de réalisation fixe de deux jours
-Un nombre d'intervenants non connu à l'avance mais pouvant être de plusieurs dizaines de personnes.

Je serai justement intéressé d'en discuter avec toi sur ce post ou par gmail si tu veux.

Après une temps avec XP... on crois que le mieux adapté a 'notre structure, services et clients' est Crystal Clear.
Si vous avez besoin je peut vous filer qq doc interne (en espagnol, désolée) qu'on utilise pour évangéliser l'équipe.

De toute façon j'ai mise à votre dispo ces 3 éléments

1- Roles équipe http://www.gersbach.net/agile/roles_xp.png
2- Calendrier Iterations : http://www.gersbach.net/agile/calendario_iteracion.png
3- Methodology Map : http://www.gersbach.net/agile/MethodologyMap.jpg

Et je vous recommande vivement ce livre : http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-Developmen...
note : Alistair Cockburn [http://alistair.cockburn.us/] est un des pères du développement Agile

ps : Appliquer/Utiliser une méthodologie Agile n'est pas facile de tout et ça dépend de la taille de l'équipe et du client.
Bref, on peut discuter pendant des semaines...

a+

Martin GERSBACH
martin@gersbach.net | www.gersbach.net

Bonjour Martin, ne connaissant pas vraiment Crystal, je suis intéressée pour en apprendre d'avantage. Même si ca peut être compréhensible j'ai un peu du mal avec la doc en espagnol (oui, malgrè mon nom!). Aurais tu des liens qui me permettraient d'élargir mes connaissances? Merci.
Tu fais une comparaison avec XP mais pour moi XP n'est pas une méthodologie de gestion d'équipe mais d'organisation des développements pour augmenter la qualité du logiciel. Voici quelques pratiques XP: Conventions de codage, Pair programming, propriété collective du code, intégration continue, livraisons fréquentes, conception simple, TU, TDD etc. Scrum et XP sont complémentaires et semblent bien souvent utilisés ensembles.

Pour te répondre Julien et continuer dans la discussion, voici mes reflexions:

• Le pair programming (pratique XP) est un des aménagements qu'on peut facilement mettre en oeuvre et qui sera très certainement bénéfique pour tous les participants. Je parle en tout cas pour les développeurs, je ne sais pas si c'est appliquable aux graphisques mais finallement, pourquoi pas? Mettre en commun ses pratiques, idées et méthodes d'élaboration d'un graphisme ne peut être qu'une bonne chose.
• Je peux difficilement m'avancer sur les autres pratiques XP connaissant peu le monde du php/drupal et n'ayant jamais réalisé de projet avec cette techno (je viens du monde J2EE), je ne connais pas les outils permettant de produire un code de qualité et d'avoir une réactivité maximale quant à la correction de bugs. Peut être que vous pouvez me donner des éléments de réponse.

Concernant les adaptations scrum:

• Il va falloir fixer les jalons de manière précise et non négociable. Un sprint en scrum pour donner une idée c'est 3 semaines en moyenne (de ce que j'ai pu lire et entendre lors de conférences). Un scrum planning/review c'est 4 heures. En 2 jours ca ne va pas être franchement tenable ;)
  Dans ma reflexion j'ai:
  • 1 jour de développement = 2 heures
  • 1 sprint (habituellement 3 semaines) = 3 jours = 3 fois 2 heures
  • 1 standup meeting (habituellement 10 minutes par jour) = 10 minutes, difficillement compressible
  • 1 scrum review/planning (habituellement 4 heures) = 1 heure

  Ca reste une proposition à formaliser en calendrier ou schéma pour rendre les choses plus claires.

• Pour la composition des équipes, nous avions parlé à la réunion précédente d'équipes homogènes (les tech avec les tech et les graphistes avec les graphistes etc.) ce qui ne nous empêche pas de faire des sessions mixtes pour intégrer le design par exemple. Générallement, on parle d'équipe hétérogènes mais je ne vois pas d'arguments contraires pour le DNGO.
• Un des gros points noir que je vois c'est la coordination des équipes. Scrum prévoit une organisation qui s'appelle le "Scrum de scrums" qui permet aux scrummasters de chaque équipe de faire le point ensemble. Mais ca demande une certaine coordination de tous les "daily scrum" car le "product owner" est sensé participer à tous ces points. Dans le temps que nous devons y consacrer, ca risque d'être un peu sportif et il faut absolument définir les modalité de cette coordination.
• Pour moi la partie d'estimation (planning poker) qui est prévue pendant le scrum planning est à retirer car une perte de temps. L'estimation serait intéressante d'un point de vue indicateur mais aujourd'hui je ne suis pas sûre que ca apporte une réelle valeur ajoutée. A discuter. On voit de plus en plus apparaître des articles qui remettent en question cette pratique entre autre.
• Concernant l'utilisation du task board et des kanbans... (http://www.qualitystreet.fr/?2008/08/27/141-kanban-board-encore-plus-lea...) pour plus de facilité, on peut utiliser l'outil de track de bug pour créer nos taches et user stories. Cependant, le tableau a l'avantage d'être graphique pour tout le monde et super motivant. Ca demande peut être du temps supplémentaire mais je pense que ca vaut le coup de se donner la peine.
• Evidemment, une rapide formation pratique concernant l'organisation du week end devra être réalisée (avec concepts, dates etc.)

C'est à peu près tous les sujets que je souhaitais poser par ici. Je continue dans ma reflexion, à bientôt!

Salut claire,

M'intéressant aussi beaucoup à la gestion de projet Drupal en ce moment je suis vraiment ravi que tu partages avec nous tes connaissances.

Je suis d'ailleurs étonné par la quasi absence de partage de connaissance sur ce sujet au sein de la communauté jusqu'à présent.

Le premier constat que l'on peut faire est que les projets Drupal sont très variés.

Par exemple la taille d'un projet est un facteur important pour choisir des outils et une méthodologie de gestion de projet. Il serait vraiment intéressant de faire une enquête sur la communauté française et aussi internationale pour essayer d'évaluer la taille des projets menés.

A priori je dirai que Drupal est souvent utilisé pour des petits projets (Inférieur à 200 j/h ou 100 000 € de budget).
C'est même souvent un argument commercial : arriver à faire rentrer des projets ambitieux dans des fourchettes de couts intenables avec des technologies concurrentes. Certains showcases de la communauté montrent des sites web assez époustouflants en comparaison des moyens engagés pour les réaliser.

Mais il y a aussi une demande croissante pour réaliser des projets Drupal de taille plus importante.

Ce qui n'est pas sans soulever de nouveaux défis. Notamment en matière de gestion de projet.
Un projet à 1 million d'euros ne se gère pas tout à fait de la même façon qu'un projet à 30 000 euros dans lequel il faut sélectionner quelques modules, faire un beau thème et quelques développements custom.

Or il va y avoir de plus en plus de demande de projet drupal de taille importante. Car les possibilités de création de valeur des plateformes de social publishing sont considérables et Drupal semble être un outil extrêmement prometteur et extrêmement "agile" du fait notamment de la dynamique de sa communauté.

Si tu viens du monde J2EE, je pense que la taille moyenne des projets y est au contraire bien supérieur à 100 000 euros et 200 j/h.
L'expérience des équipes de développeur du monde J2EE est aussi souvent plus importante.

Mais encore une fois cela est en train d'évoluer.

Je propose que l'on forme carrément un groupe de travail "gestion de projet Drupal" pour continuer discuter de ces questions.

Le mieux serait qu'on se prévoit un petit rendez vous de visu et sinon par skype.

Qui serait intéressé ? Semaine prochaine vous avez des disponibilités ? mardi soir 19h par exemple ?

http://groups.drupal.org/projectManagement