Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

agile

  • Le hudson de la Fondation Apache

    J'ai déjà parlé sur ce blog de Hudson, un serveur d'intégration continu, c'est à dire un logiciel qui permet de jouer des tâches conditionnels et déployer pas à pas les nouveaux développements d'un projets. Pour mémoire, voici les étapes de développement de logiciel :

    1. Concevoir l'idée, c'est non seulement avoir une idée mais surtout savoir comment on va la mettre en oeuvre.
    2. Planifier ses développements. L'utilisation de méthode Agile inspirée de SCRUM permet d'avoir une démarche itérative priorisant les actions les plus importantes en premier.
    3. Développer avec une méthode comme le développement piloté par les tests (TDD : tests driven developpement). Cela permet de s'assurer à tout moment de la non regression d'un développement en jouant des tests unitaires.
    4. Jouer les tests quotidiennement pour s'assurer que tout avance pour le mieux

    Hudson qui est un logiciel à plugins permet de greffer de nombreux modules d'en faire un tableau de pilotage depuis le developpement jusqu'au déployement voire à l'exploitation de ses produits avec pour obsession le respect qualité.

    J'ai découvert par hasard le Hudson de tout les produits de la fondation apache (ant, subversion, spamassassin, solr, ...). Cela donne une excellente idée de l'organisation de cet outil !

    Solr-Hudson.jpg
  • Je suis Steeve Jobs ... Agile (fin)

    apple-logo.jpgNote sérieuse avant de commencer : tous les personnages sont des caricatures, les situations poussés à l'extrême pour mettre en évidence les mauvais penchants du manager looser.

    Dans la première manche Steeve m'avait battu à plat de couture 1 ipad à 0. Mais le looser n'a pas dit son dernier mot.

    Le pouvoir de Steeve Jobs c'est d'avoir le talent de voir juste sur le futur des produits. Là, j'idéalise le bonhomme. Mais en tant qu'excellent communiquant, il offre de la poudre de perlimpinpin car tout était calculé ce qui passe pour être du meilleur effet n'est en fait que de la poudre aux yeux. Là j'écrase le boss.

    Pour suivre le Dieu Steeve et comme moi aussi j'ai du pouvoir, j'ai fais un communiqué de presse (ok, un Email) pour dire à mon équipe qu'un dossier super important pour les clients les attendait. Il y en avait plétor sur otrs, lequel je prends ?

    Dossier 1 : porte variable dynamique intégrant l'héritage booléen en cascade via des triggers mysql.
    Après mon mail plus personne ne voulait me parler. Il s'est passé 15 jours et rien. D'habitude quand j'envoie un email on a la politesse de me répondre, là rien on entendait les mouches volées. Je relance notre responsable mockup pour qu'il fasse des maquettes filaires.
    Le bougre me dit qu'il comprend rien à ça que je lui demande.
    - j'ai envoyé un mail il y a 15 jours c'est prioritaire. C'est pour une compétition contre Apple. Notre réputation est en jeu.
    - oui mais je ne comprend pas ce que tu veux faire et de toute façon j'ai un mois de boulot d'avance.
    - il fallait me le dire ! Passons. qu'est ce qu'on fait maintenant ?
    - à toi de me le dire.

    Leçon de ce dossier
    - prendre un dossier fédérateur : celui-là respire l'ennui. On a pas toujours le choix, mais si c'est le cas autant trouver un sujet sympa. Globalement dans le web, un projet grand public apporte plus d'adhésion qu'un projet grand compte. Le contact avec l'utilisateur final à qui on rend service est motivant.
    - dans l'urgence ou lorsque les plans sont bousculés reprendre ses esprits et revenir à vos basiques organisationnels. Il ne sert à rien de brasser du vent, ça épuise tout le monde. Faites un brife fonctionnel assurez vous que le ballon est bien entre les mains de vos collaborateurs.
    - la clef du succès pour aller vite et être agile, c'est la compétence individuelle mais aussi celle de l'équipe à se surpasser ensemble, c'est la compétence collective.

    Comme on est dans une note de blog, j'ai droit à un deuxième dossier.

    Dossier 2 : augmenter le taux de participation de 20 points par la mise en place de Facebook connect, twitter connect,... (revoilà mon pote Mark)
    Là je rencontre un succès plus vif car tout le monde à compris de quoi je parlais. L'objectif concret est motivant et fédérateur. Comme je suis futé, je n'ai pas pioché par hasard. Le responsable marketing m'a brieffé sur les tendances commerciales qui auraient le plus d'impact. J'ai listé dans le backlog produit les idées qui étaient les plus formalisées. On a fait la réunion de sprint pour caler les priorités et les détails du plan d'action. Bingo ! 1 mois plus tard les beta testeurs nous remontaient des améliorations. Pendant les tests on a paufiné le plan de com' et mis à jour la base de connaissance.

    Alors Steeve ? T'en pense quoi ?

    C'est ça que l'on est en train de mettre en place. Les kanbans, et autres outils Agiles d'organisation, c'est pour justement nous permettre de rester réactif même si l'équipe s'agrandi, même s'il y a des urgences, même si ...
    Nous avons encore quelques recrutements stratégiques à effectuer et promis après on s'y remet à fond de quoi faire briller les yeux des chefs de projets ;) sans douleur et sans toucher aux pauses wii !

  • La règle du ticket d'entrée dans des chantiers à forte valeur ajoutée

    Après avoir traité la stratégie face au chantier d'élimination du muda (gâchi), nous allons nous détailler la mise en place d'une organisation lean pour le développement de logiciel.

    Le cercle vertueux de développement logiciel

    Voici les actions que nous allons mener dans les mois qui viendront. Nos produits sont relativement jeunes et ont besoin de souplesses. Leurs contours initiaux éolluent en fonction des projet et des besoins clients. Lors des premiers cycles de développements, il faut prendre garde à ne pas trop marquer le produit par les volontés d'un unique client.

    cercle-produit.jpg

    Ce cercle vertueux est un cycle d'étude et développement que l'on peut retenir pour concilier la qualité, la rapidité d'exécution et la souplesse dans la gestion de la Road Map produit.

    Comment cela se passe ?

    Le backlog produit c'est la liste des fonctionnalités à développer. Quand on gère un produit web qui n'est pas encore mature, on vend au client un projet web. C'est les idées du client qui enrichissent fonctionnellement le produit. Une réunion mensuelle, réunion de planification, permet à la lumière des études du mois passé de sélectionner en fonction des priorités et de la charge, ce qui rejoindra le développement. Les éléments sélectionnés constituent la release ou backlog de sprint.

    Un cycle (sprint) dure un mois. Cela permet d'entamer des gros chantiers. Parallèlement, une livraison hébdomadaire des développements permet d'assurer des recettes sur les serveurs de préproduction plus courte et livrer des projets qui demande certaines fonctionnalités. Un cycle comprend une partie étude technique préléminaire au gros chantier du mois à venir et une partie développement. En cela, je m'écarte de la méthode SCRUM pure, nous ne sommes pas suffisamment nombreux. Je considère qu'une étude de faisabilité est souvent plus importante que le développement que c'est un travail apparentière.

    Pour les développeurs les plus juniors, j'ai mis en place des fiches de développements. Un chef de projets ou produits décrit fonctionnellement le besoin puis je détaille techniquement, en relation avec le responsable R&D, la meilleure manière technique d'arriver à la solution.

    Les bénéfices

    • Préparer le terrain par des études c'est s'assurer de ne pas avoir de surprise et de ne pas exploser le sprint.
    • L'autonomie dans les livraisons permet d'évaluer son rythme et de se mettre une pression "seine" en fonction des attentes des clients.
    • Avoir une idée des chantiers à 3 ou 6 mois (c'est beaucoup dans le web) permet d'anticiper (son plan RH, la sortie d'un nouveau produit, ...)
    • Les arbitrages fonctionnelles du produit sont fait par le chef des produits par le feedback permanent avec le développeur.

    Conclusion

    Les cycles permettent une remise en cause régulière de ce que l'on fait. Même si on jette à la poubelle un sprint car le besoin n'est plus là on a perdu qu'un mois. Le cahier des charges suit le besoin au plus près. Imaginez faire six mois de dévelloppement et arrive au constat que l'on est à côté de la plaque car le cahier des charges a été construit au début à partir d'arbitrages fonctionnelles judicieux à la hauteur des connaissances du démarage d'un projet.

  • Savoir se rendre indispensable...

    ..., c'est le meilleur moyen de ne pas l'être. Et réciproquement.

    Encore un article qui décape les idées reçues et qui va faire pleurer mon patron ;) ! N'ait peur, je suis juste de la génération Y.

    Ceux qui me connaissent savent que se rendre absolument incontournable dans son poste pour le conserver savent que c'est une réation qui ne me correspond absolument pas. Certains (voire tous) de mes employeurs en ont fait les frais. Pourquoi une telle surprise ?

    Question de génération

    Je lisais dernièrement un article de Management du mois d'août ("Le culot ça paie") sur la Génération Y, dont je fais parti. D'abord l'arrivée du web et réseaux sociaux facilite la mise à disposition d'un plus grand choix d'offres de job. Ensuite parce que la génération Y a la culture du zapping, du travail collaboratif, du travail en ligne. Crise ou pas crise, si le jeune y ne se sent pas à son aise, il claque la porte. Je vous invite à poursuivre sur Génération Y 2.0. Il faut ajouter qu'un job est un deal qui se fait à deux entre l'entreprise et le "talent" : pour le jeune Y, il faut se confronter au réel et tester pour apprendre.

    Question de choix de carrière

    Je lisais dans le même magazine un article sur les dirigeants de transition. Ce sont ces séniors qui vont diriger une entreprise pour une période de transition parce que la société est en redressement ou que le PDG est gravement malade, ... Ce sont des situations extrêmes qui nécessitent une adaptation et d'être à fond tout de suite et pendant 6 mois à 2 ans.

    J'aime bien cette approche de job transitoire, parce que c'est paradoxalement penser à long terme pour l'entreprise et pour soi. On pourra évolluer vers une autre mission (même au sein de la même entreprise) sans que l'entreprise prenne de risque. Le cycle d'un ingénieur est de changer de job tous les 2 ans, autant qu'un dirigeant de transition finalement. Cela laisse le temps d'apporter de l'enrichissement et une valeur ajouter. Encore faut-il avoir les mêmes exigences de travail bien fait que les dirigeants de transition ! Apporter du résultat tout de suite et construire un avenir serein.

    Question de valeur ajoutée

    Personnellement, je pense que si je n'apporte plus suffisamment de valeur ajoutée et que le projet arrive à maturité, je peux me retirer et laisser le soin de l'exploitation à des gens bien formés. Encore faut-il avoir préparé cela !

    Comment se rendre non indispensable dans son poste et donc indispensable pour l'entreprise ?

    1. Les méthodes Agile donnent pour rôle au chef de projet (ou scrum master, celui qui encadre l'équipe de développeur) un facilitateur et non pas un dirigeant qui impose ses solutions techniques. Il est là pour dénouer les problèmes, apporter une vision au projet (définir les objectifs de délais qualités, ...).
    2. Participer à la formation de ses collaborateurs et à la transmission des connaissances des séniors vers les juniors.
    3. Une vision longtermiste permettra de laisser son emprunte positive pendant longtemps après le départ. Entamer des chantiers structurer dès le départ permettra à l'équipe de vivre sur des acquis.
    4. Ne pas repousser au lendemain ce qui parait indispensable de faire de suite car cela apporte une valeur ajoutée importante.

    En fait, il n'y a rien d'exceptionnel à vouloir rester non indispensable. Ces exigences au quotidien correspondent au besoin des entreprises au jour le jour pour peu que l'individualisme ne soit pas le centre de vos motivations. L'entreprise a besoin de jouer collectif.

    Demain un exemple pour rester concrêt.

    Ajouté aujourd'hui à 10h02 :

     

  • De la définition de l'équipe projet...

    ... et des fonctions de chacun.

    En route vers l'industrialisation d'un projet web : l'environnement de réflexion et de management

    En tant que chef de projets des activités techniques dans des petites structures, j'ai souvent dû faire des maquettes avant de passer aux spécifications techniques lorsque le chef de produits était parti en rendez-vous commercial.

    C'est le bonheur des petites entreprises, mais à part que les logiciels de design, ce n'est pas mon fort cela montre :

    • la mise en place d'une organisation doit être adapté à la taille du projet
    • savoir dire "non, c'est pas dans mes cordes" ou "non, ça peut attendre le retour du chef de produit" n'est pas un aveux d'échec, c'est une alerte qui doit faire penser que le projet "part en sucette".
    • l'arbitrage qui est fait pour le chef de produit agissant pour le compte du client lors de la définition des maquettes peut apporter des erreurs.

    Je lisais récement une étude du standish group qui estime que seul 25% des projets sont des réussites. Au début, j'étais séptique, et puis en me plongeant dans mes souvenirs, le nombre de fonctionnalités sur des projets web qui sont finalement passés à la trappes faute de temps ou de pertinence, ... Derrière tout cela, il y a une question de rentabilité.