jeudi 26 mai 2011

Première demande de "pull" sous Github

A y est !! Enfin ! ....

Il y a presque 1 an, pour un développement WEB perso, j'avais récupéré une librairie Javascript sur Github. J'avais d'ailleurs eu quelques échanges sympa avec le nouveau "propriétaire" de la librairie (officiellement forké d'une version officiellement non maintenue par l'auteur initiale de la librairie).

Pour les besoins de mon appli, j'avais fait une petite modif pour ajouter une petite fonctionnalité sympa à la librairie. J'avais promis à l'auteur de soumettre ma modif, mais ... le temps a passé ... et je ne l'avais jamais fait ...

Maintenant, le projet est réouvert pour quelques temps, et j'en profite pour tenir ma promesse.

J'ai donc "forké" la librairie de référence sur mon compte Github en suivant cette page d'aide simple et claire : github:help : Fork A Repo.
Note : Pour faire des commits, voir plus bas ... ;-)
Ensuite, comme j'ai changé de machine et que je suis (pour l'instant ...) sous Wnidows, j'ai installé Git (msysgit) en suivant ce tutoriel pour débuter avec Git et GitHub sous Windows, simple et efficace, avec un petit rappel de ce qu'est un SCM décentralisé. On peut zapper la fin du tutoriel, les infos seront vus dans un autre tutoriel ...
Attention : chez moi, la génération de la clé dans une console "bash" ne fonctionnait pas, mais j'ai pu l'obtenir avec Git GUI.
Ensuite, pour compléter ma configuration de git et rentrer plus en détails dans les principes de fonctionnement et les commandes, je recommande ce tutoriel vraiment excellent : Gérez vos codes source avec Git !
Attention : pour la création du dépôt local et l'envoi de commits ("push"), se référer plutôt à l'aide Github citée plus haut.
Avec tout ça, j'ai réussit à faire un commit et à la pousser sur mon dépôt Github, donc sur mon fork du projet. Ensuite, en 1 clic dans l'interface de Github, j'ai fait une "Demande de pull" pour demander à l'auteur principal (de référence) d'intégrer mes modifs dans la branche principal de la librairie.

Reste plus qu'à attendre qu'il l'accepte ....

En tout cas, les principes mis en avant par Github sont vraiment très sympas pour les aspects collaborations, et l'apprentissage de git (j'y avais déjà touché) n'est finalement pas si compliqué que cela.

Et toi, lecteur de passage, que penses-tu de Git ? Es-tu plutôt SVN ?

lundi 23 mai 2011

Scrum Day France (Part 3)

"ScrumMasters, devenez le coach de votre équipe agile" par Véronique Messager

(Type : vidéo et diaporama mixés)

En introduction, Véronique évoque une révélation que j'ai eu moi aussi : la réponse que les méthodes agiles apportent lorsqu'on cherche (cherchait) une approche plus "humaine" dans la gestion de projet. J'ai pris conscience de cela au bout de pas mal de temps : l'approche et l'organisation qui m'étaient proposées pendant des années ne me convenaient pas, l'agilité a pointé ce qui manquait : l'aspect humain ...

Véronique rappel quelques points importants avec des variantes ou point de vue qui m'ont intéressé :
  • Le ScrumMaster protège l'équipe, de l'extérieur bien sûr, mais également des siens, des membres de l'équipe
  • Parmi les valeurs poussées par l'agilité, le droit à l'erreur, pas assez mis en avant
  • L'équipe s'engage sur les résultats, le ScrumMaster s'engage sur les moyens (moyens pour l'équipe de tenir ses engagements, notamment moyens techniques)
Comme souvent, la question : le ScrumMaster peut-il être un responsable hiérarchique ?

Véronique précise que c'est un débat, mais n'y répond pas. Personnellement, malgré mon pragmatisme, je suis assez formel : par expérience, il faut absolument éviter que le ScrumMaster soit un responsable hiérarchique. Pour obtenir la concrétisation de valeurs comme Transparence, Confiance, Ouverture, etc ..., pour obtenir l'affichage par les équipiers de leurs faiblesses pour qu'ils expriment leurs difficultés du moment lors de la mêlée quotidienne, il ne faut pas que le ScrumMaster soit hiérarchique !

Autre sujet abordé, pendant la présentation, mais également, pendant les Questions/Réponses : le ScrumMaster est-il un ancien chef de projet. Véronique dit qu'elle constate que c'est souvent le cas. Je pense que c'est possible, il n'y a rien qui s'y oppose, mais ça ne doit pas être systématique : un chef de projet peut très bien devenir (Proxy) Product Owner, notamment s'il a une bonne compétence métier et relationnel avec le client. L'important est que le ScrumMaster soit à l'écoute des équipiers et dans la communication, un chef de projet trop habitué à un rôle directif aura du mal avec cette approche très humaine, en "position basse" comme dit Véronique. J'y reviendrai dans un autre billet ...

Véronique a un point de vue intéressant sur le rôle de ScrumMaster : qu'il adopte une posture de "coach". Je pense que le rôle de "coach agile", comme je peux le faire en indépendant extérieur à l'entreprise, est une mission bien spécifique et différente de ScrumMaster. Mais en écoutant la suite de la présentation, je comprends ce que Véronique veut illustrer à l'auditoire pour lui faire sentir ce rôle de ScrumMaster :
  • Faire en sorte que chacun (individu ou l'équipe) trouve lui-même la solution à ses problèmes
  • Non pas intervenir sur une problématique mais plutôt sur la façon dont l'équipe appréhende et traite cette problématique
Véronique insiste ensuite sur ce que cet aspect humain implique pour le ScrumMaster :
  • Connaissance de soi et contrôle de soi-même
  • Connaissance (humaine et non privée) des autres
  • Relations entre les personnes
  • Prise en compte des émotions de chacun
Selon les situations et les contextes, une "charte" au sein de l'équipe peut-être intéressante comme cadre, notamment en cas de relations difficiles.

Obligé d'accélérer sur la fin de sa présentation, Véronique aborde rapidement des points souvent délaissés, voir inconnus, et pourtant très importants à intégrer pour le ScrumMaster (et finalement tous les acteurs) :
  • La notion de deuil qui accompagne souvent les changements nécessaires pour chacun (développeurs, managers, ...), la prise en compte du cycle de deuil, et l'accompagnement au changement nécessaire (coaching)
  • La notion de cycle de vie d'une équipe (Création, Turbulence, Harmonisation, Performance, Séparation) impliquant une équipe stable où les acteurs apprennent à travailler ensemble
Dernier point noté qui ouvre le rôle de ScrumMaster : ce dernier intervient à différents niveaux :
  • Individu : accompagnement au changement, adaptation individuelle à l'agilité de chacun
  • Équipe : permettre la meilleure transformation "de groupe" vers l'agilité
  • Organisation : dynamique globale nécessaire, évangélisation dans l'entreprise