h1

Conférence TED

mars 12, 2013

 

Publicités
h1

Pourquoi le Scrum Master devrait être le chef de projet?

janvier 2, 2013

Pour ma part, les rôles peuvent être attribués à une même personne ou non. Ce sont des rôles très différents mais aussi complémentaires.

Le chef de projet, recrute une équipe, la gère d’un point de vue hiérarchique ou non. Et a la responsabilité de la gestion du projet en terme de coût, planning et qualité.

Le Scrum Master a la responsabilité d’aider l’équipe à résoudre ses problèmes quotidien, d’isoler l’équipe des interruptions incessantes, d’être le point de contact des intervenants extérieur et de donner de la vision quant à l’état du sprint, du projet.

Le Scrum master est un facilitateur, mais pas forcément un manager.

Je pense qu’il n’y a pas de bonne ou mauvaise organisation mais avoir un scrum master issue de l’équipe de développement et qui tourne à chaque projet, peut être envisagé dans le cas ou les équipes veulent évoluer et apprendre, cela permet de responsabiliser chacun et de mieux impliquer les développeurs dans chaque projet.

Le chef de projet pourra de nouveau développer ou continuer à suivre l’état de son projet, à participer de manière plus opérationnelle, à faire du reporting managérial.

h1

Scrum Master! Scrum Master! et le Product owner dans tout cela!

janvier 2, 2013

Scrum se répand de plus en plus dans les équipes de développement.
Les scrum master sont formés en place, et sont la plupart du temps les anciens chef de projet.

Mais le Product Owner est oublié dans cette transformation. L’équipe de développement parle au développement avec le Scrum Master, c’est un bon moyen pour démarrer la mise en place des pratiques Scrum et de former l’équipe. Mais les équipes métier ou leurs représentants ne sont pas complètement intégrés et restent trop éloignés des développeurs.

« Utiliser les product owner dans les projets !! » sera mon cri du jour. Et pas un product owner pour 50 personnes mais pour les 8 à 10 personnes qui forment une équipe.

Ces organisations proviennent peut être du fait que le rôle et l’importance du PO sont mal compris. Après tout, quelles sont les activités d’un PO?
Un product owner a un rôle, au risque de me répéter, INDISPENSABLE pour une équipe Scrum. Voici ci-dessous une liste non exhaustive de ses attributions:

De manière générale:

  • Le PO est le pourvoyeur de la vision du produit fini pour ses équipes. Il identifie les thèmes, les épics et les users stories permettant de livrer un produit fini. Il priorise, fournit la valeur métier et accepte de faire des trade off, ajouter et retirer des user stories. Il élabore les critères d’acceptation qui permettront de finaliser les US, et travaille avec un testeur pour élaborer les tests fonctionnels qui seront automatisés. Il prépare une stratégie de test en collaboration avec le Scrum Master et le testeur.

Plus particulièrement:

  • Design de l’interface graphique: Travail en collaboration avec le marketing, un ergonome et un graphiste pour élaborer la nouvelle interface graphique, découpe cette nouvelle interface graphique en User Story pour implémentation.
  • Décrit les besoins métiers et organise ses story maps.
  • Travaille son backlog, l’affine en permanence et fournit les valeurs métiers de chacune des User story
  • Communique sa vision à l’équipe de développement, et dialogue avec elle dès que nécessaire
  • Participe à l’élaboration du planning de sprint, aux démonstrations et rétrospective de l’équipe.
  • Communique très régulièrement avec ses clients internes ou externes, améliore sa connaissance du métier et de ses clients.
  • Teste les versions intermédiaires
  • Accepte  ou rejette les user story développées, trace et suit la résolution des défauts identifiés

Alors ? Comment peut-on se passer de ce rôle au sein d’une équipe de développement aujourd’hui ? Moi, je ne sais plus faire sans.

h1

Les petits outils dont je ne peux plus me passer

janvier 2, 2013

StrokeIT: Mouse gesture – remplace les actions disponibles sur des boutons par des gestes de souris – iconiser, agrandir, fermer une fenêtre
Dirkey : permet de décrire ses raccourcis et d’accéder par un jeu de touches directement au répertoire qui nous interesse sans dérouler toute l’arborescence
– Google Drive et / ou Dropbox : partager, échanger des fichiers avec des collaborateurs ou des clients
– Clipperz: Coffre fort de mot de passe

h1

Agile product ownership in a nutshell

janvier 2, 2013

Je ne peux que me faire le relais de cette vidéo, elle explique tout ce qu’il faut aux néophytes et pour les autres c’est un excellent refesher!!

h1

Le métier n’a pas le temps !

janvier 2, 2013

Me voici dans le monde du conseil et les raisons pour lesquelles les clients font appel à nous sont systématiquement les mêmes. « Nous sommes de plus en plus soumis à des contraintes. Nos projets grossissent et se démultiplient avec un nombre croissant de plateformes à supporter…Nous n’y arrivons plus. Comment peut-on réduire nos coûts et nos délais avec l’agilité? »

Les premières choses que je cherche à comprendre chez ces clients sont leur organisation et l’empreinte des méthodes qualités qu’ils utilisent. Certains clients multiplient les méthodes qualités sans pour autant parvenir à de bons résultats.

La seconde chose que j’essaie de comprendre est la collaboration qui existent entre les différentes équipes. Et chez la plupart d’entre eux la collaboration entre le métier et les équipes de développement est quasiment inexistante… les équipes d’assemblage et d’intégration sont sous l’eau et les développeurs avancent sans intégration continue…

Effectivement il est temps de se poser les bonnes questions et de prendre du recul, et de commencer à tracer la route vers le succès, car le succès est possible.

D’ailleurs doit on parler d’agilité ou de pratiques agiles, ou tout simplement de pragmatisme.

Est-il normal que les personnes métiers n’interviennent pas en cours de développement et n’est pas de droit de regard?
Dans mes activités de développement, le métier est indispensable. C’est lui qui est porteur de la vision du produit fini, qui a la connaissance du client final, de ses attentes et de ses usages.
Quand je fais cette remarque, on me répond systématiquement:
Client: « Le métier n’a pas le temps. »
Moi: « Mais que fait le métier? »
Client: « Il prépare les spécifications de la prochaine version. »
Moi: « Mais vous avez déjà 2 versions en suspend, que vous ne parvenez pas à terminer. A quoi cela sert-il? »

Le vieux proverbe français s’est toujours vérifié: « A vouloir courrir après 2 lièvres à la fois, on risque d’en attraper aucun. »
1 – Concentrer vos forces vives sur les problèmes actuels et non futurs. Certains utilisent le concept de War room pour sortir des applications en retard et critiques. L’objectif est de réunir dans une même salle, le métier, les développeurs, les testeurs, intégrateurs… et de fixer les problèmes les uns après les autres. C’est un moyen efficace pour sortir des situations de crise.
2 – Le métier n’est vraiment pas disponible, utilisez alors un représentant ayant de bonnes connaissances métier. Il aura un rapport privilégié avec le métier et sera présent en permanence avec les équipes de développement.
3 – Instaurer des lieux, des moments de rencontre et d’échanges entre les développeurs et le métier. Les développeurs ont besoin de comprendre les aboutissants du produit pour faire du soft de qualité. Ne vous privez pas des idées des développeurs.
4 – Demander à voir régulièrement les productions réalisées en cours de développement, il est beaucoup plus facile de corriger une erreur tout de suite, quand le développeur se souvient encore du code, et qu’il a le nez dedans, plutôt que quand le développement est terminé.
Le développeur sera obligé de compiler et livrer son code de manière régulière et corrigera de lui-même les problèmes qu’il aura trouvé en le testant avant de vous le montrer. Et hop! une partie de bugs et défauts en moins.

A tous les amis agilistes, vous reconnaîtrez ici les notions d’équipe intégrée, de product owner, pluridisciplinaire, de démonstration, d’intégrations régulières et de démonstration. C’est déjà un très bon début pour qui veut progresser.

La réduction des coûts commence par la réalisation de logiciel correspondant aux besoins du client. Aller à l’essentiel est un bon moyen de réduire les délais, ce qui mécaniquement réduit les coûts des projets.
Intégrer et démontrer sont des activités indispensables pour obtenir du feedback régulier et obtenir des validations partielles sur les créations de l’équipe de développement.

h1

Bienvenue sur le blog de l’amélioration continue !

décembre 19, 2012

L’objectif de ce blog est de consolider et garder une trace de mes activités.

Je viens de changer de métier, et je reprends une vie plus dynamique dans les activités de recherche, amélioration et (re) découverte de l’univers infini du monde informatique en général et plus précisément de l’agilité.

L’agilité est le grand thème qui m’anime actuellement. Autour de ce thème de multiples notions très variées peuvent être abordées telles que l’Humain avec un grand H, comment réagissent les Hommes en mode auto organisé, sous la pression ou dans la décontraction, dans des secteurs concurrentiels, ou plus protégés…

Nous parlerons aussi des aspects méthodologiques des projets et organisationnels des entreprises.

Et enfin, les outils informatiques et les pratiques de développement permettant d’accroitre la productivité des équipes et de les aider à contrôler la qualité de leur livrable.

Et voilà! Nous parlons déjà de méthode, de qualité, de productivité (donc coûts / délais).

Les bons indicateurs de mesure pour tout projet.

Vous retrouverez tout au long de mes pages une partie de mon vécu et des conseils que je livrerais au fur et à mesure de mes réflexions.

Vous ne m’en voudrez pas si mes articles m’emmènent également dans des univers parallèles auquels je n’ai encore très certainement pas songé.

Tout ce que je souhaite c’est apporté aux lecteurs de ce blog un retour d’expérience sur mes activités projet et management ainsi que les liens utiles et les articles que j’aurais trouvé interessant.

Bonne lecture à tous.

Citation du jour: « Si la nécessité est la mère de l’invention, le mécontentement est le père du progrès. » – David Rockfeller