Eh oui, nouvelle job = besoin de connaissance = nouveau bouquin :) Et comme amazone est mon amis, un petit tour à la boite postal s'imposait ce matin !
The First 90 Days
Michael Watkins
Harvard Business School Press
First, Break All The Rules
Marcus Buckingham & Curt Coffman
Simon & Schuster
Lean Software Development, An Agile Toolkit
Mary & Tom Poppendieck
Addison Wesley
J'ai emprunté Lean S/W Development dernièrement et j'ai particulièrement aimé le parallèle entre le monde manufacturier et le developpement logiciel. Ils démontrent bien que les racines Agiles repose sur le Toyota Way.
Ce matin, je viens de tomber ds First, Break All The Rules. Parlant de philosophie de management, axe sur la compréhension des gens et le team building, ce livre semble tout désigné pour moi, en ce moment :) Review plus consistant à suivre, je n'ai que 20 pages de lu !
samedi, octobre 20, 2007
Comment choisir un candidat ?
Dernièrement, avec les nouveaux postes créé au sein de mon équipe et plus encore, avec l'annonce de mon départ pour le coté obscure (je quitte la direction de l'équipe de support informatique au profit de la direction de l'équipe d'architecture réseau), j'ai eu beaucoup d'entrevues à faire passer et donc, de candidats à évaluer.
Bien sûr qu'une bonne liste de question pré-réfléchit aide, mais quelle réflexion dois-je avoir avant de donner le go/no-go ?
En fait, j'ai trouvé cette petite technique à 3 questions qui fait le travail pour le moment :)
1) Quel niveau de compétence le poste ouvert demande-t-il ?
2) Quel est le niveau de compétence du candidat vs les compétences demandés ?
3) Ai-je confiance et le temps à investir dans ce candidat pour l'amener au niveau voulu ?
Les 2 premières questions vont de soit, il faut le dire, par contre, la 3e demande un minimum d'introspection et une certaine honnêteté envers soi-même.
C'est facile d'engager un prospect et de critiquer par la suite, qu'il n'est pas au niveau voulu. Par contre, si on prend le temps de ce poser ces questions avant l'embauche, peut-être qu'à la même question, la "faute" reviendra plus au manager, qu'au nouvel employé ;-)
Bien sûr qu'une bonne liste de question pré-réfléchit aide, mais quelle réflexion dois-je avoir avant de donner le go/no-go ?
En fait, j'ai trouvé cette petite technique à 3 questions qui fait le travail pour le moment :)
1) Quel niveau de compétence le poste ouvert demande-t-il ?
2) Quel est le niveau de compétence du candidat vs les compétences demandés ?
3) Ai-je confiance et le temps à investir dans ce candidat pour l'amener au niveau voulu ?
Les 2 premières questions vont de soit, il faut le dire, par contre, la 3e demande un minimum d'introspection et une certaine honnêteté envers soi-même.
C'est facile d'engager un prospect et de critiquer par la suite, qu'il n'est pas au niveau voulu. Par contre, si on prend le temps de ce poser ces questions avant l'embauche, peut-être qu'à la même question, la "faute" reviendra plus au manager, qu'au nouvel employé ;-)
samedi, août 11, 2007
Un nouveau livre à ma collection !
J'ai lu dernièrement Agile Estimating & Planning de Mike Cohn. Excellent livre pour ceux qui s'intéresse plus à la gestion des projets agile qu'au développement de ceux-ci.
Excellent chapitre sur les raisons du planning, exemples d'erreurs communes et sur les ROI.
Ma note : 4/5
Lien vers Amazon.ca
Excellent chapitre sur les raisons du planning, exemples d'erreurs communes et sur les ROI.
Ma note : 4/5
Lien vers Amazon.ca
dimanche, janvier 29, 2006
Être un manager "Agile"
Quel beau concept, mais que de difficulté à l'application !
Équipe de support
Je dois quand même vous mettre en contexte : Je suis un chargé de projet d'une équipe de 5 personnes (jusque là, tout va bien...) qui a pour mission d'offrir le support à l'équipe de production de jeu (ouh, là ça se complique ! lol).
Un des principes de base de Scrum par exemple, est d'isoler l'équipe le plus possible, pour leur permettre de développer sans être dérangé. Évidement, mon équipe se doit de développer les outils interne pour l'équipe de prod, mais en même temps, elle doit offrir le support "1st line" pour tous les outils utilisé (interne ou off-the-shelf).
Expérience passé
Alors, comment gérer le tout ? Selon mon expérience sur des projets en gestion (base de donnée plus particuliairement), mes programmeurs me donnaient +/- 5 heures efficaces de développement par jour (j'entends ici toutes activités relié au développement - analyse, code, test, puisque nous parlons d'équipe multidisciplinaire). Le reste du temps étant partagé entre les réunions, la formation et le coaching des newbie (et quelque diner au resto qui s'étiraient... :-).
Donc, après une première année en charge du QA, qui inclus le support à la prod, mes chiffres sont moindre - 2 à 3 heures de tâche "planifier" vs 4-5 heure de "support", qui sont des tâches non-prévisibles. Et en mode "crunch" / fin de projet, le rendement de développement "planifié" pouvait tout simplement être réduit à néant !
Manager Agilement
Donc comment atteindre ses objectifs à long terme lorsqu'on ne peut même pas prédire le temps de développement d'une seul itération ? Premièrement, il faut contrôler l'information qui passe, non pas se faire dominer par elle !
Personnellement, j'adopte une stratégie "simpliste" quand à ma gestion de l'information. Une bonne gestion de mes emails avec les "flags" d'Outlook (merci Micro$oft !) et une planification avec un backlog - basé sur Scrum - développé en Excel. Ajouter à ça, un soupson de "sticky note" (réel et virtuel) en plus d'une bonne veille to-do list en papier que je traine partout !
Ensuite, tout passe par la priorisation des choses à faire et SURTOUT par une révision constante des priorités - que ce soit celles de l'équipe (backlog) ou personnelles (to-do list). Quand je parle de réviser souvent les priorité, je peux dire que je pouvais les revoir 3-4 fois / jours lors du crunch de pop3 (sur des journée de 14h environs, on parle au déjeuner (après la lecture de mes emails), au diner, au souper et finalement avant de quitter le soir).
Outil = Support
Il ne faut donc pas avoir à se "battre" avec un outil de gestion de tâche, d'où ma philosophie "simpliste" à ce sujet. Lorsque j'ai commencé à utiliser Scrum comme méthode de gestion, mon backlog était une simple feuille Excel, que je mettais à jour moi-même, sans aucune automatisation. J'ai laisser les besoin faire surface et d'itération en itération, j'ai développer un outils puissant mais simple, répondant parfaitemement à mes besoins.
Méthode Allégé
Aujourd'hui, je ne peux pas dire que j'applique Scrum comme tel, mais une méthode adapté à ma réalité, fortement inspiré de Scrum et autre principle Agile. Puisque l'équipe a adopté les itérations de 2 semaines, j'irai donc avec la famille, question de faciliter la communication et la validation!
Par contre, coté planif, puisque la donne change trop souvent, même au niveau du nombre d'heure de développement par itération, je ne mets pas trop l'emphase sur cette partie. Une rencontre de 2h environs suffit à la planification d'une itération. La définition des priorités est l'activité principale et en 2e lieu, vient l'estimation du temps pour accomplir ces tâches.
Ensuite, je m'efforce de valider le chemin parcouru, via les daily meeting et le backlog, et par la suite, je prend le temps de réviser les priorités à chaques fois que cela est nécéssaire.
Conclusion
Je trouve intéressant le fait que la clé de ma gestion est passé par la simplification d'une méthode qui, elle même, se veut la simplification d'une autre. Ce qui m'amène à dire que plus le chaos est important et hors de contrôle, plus le retour au source est la clé !
Prochain sujet a venir : La communication efficace passe par l'utilisation du bon média !
a++
Équipe de support
Je dois quand même vous mettre en contexte : Je suis un chargé de projet d'une équipe de 5 personnes (jusque là, tout va bien...) qui a pour mission d'offrir le support à l'équipe de production de jeu (ouh, là ça se complique ! lol).
Un des principes de base de Scrum par exemple, est d'isoler l'équipe le plus possible, pour leur permettre de développer sans être dérangé. Évidement, mon équipe se doit de développer les outils interne pour l'équipe de prod, mais en même temps, elle doit offrir le support "1st line" pour tous les outils utilisé (interne ou off-the-shelf).
Expérience passé
Alors, comment gérer le tout ? Selon mon expérience sur des projets en gestion (base de donnée plus particuliairement), mes programmeurs me donnaient +/- 5 heures efficaces de développement par jour (j'entends ici toutes activités relié au développement - analyse, code, test, puisque nous parlons d'équipe multidisciplinaire). Le reste du temps étant partagé entre les réunions, la formation et le coaching des newbie (et quelque diner au resto qui s'étiraient... :-).
Donc, après une première année en charge du QA, qui inclus le support à la prod, mes chiffres sont moindre - 2 à 3 heures de tâche "planifier" vs 4-5 heure de "support", qui sont des tâches non-prévisibles. Et en mode "crunch" / fin de projet, le rendement de développement "planifié" pouvait tout simplement être réduit à néant !
Manager Agilement
Donc comment atteindre ses objectifs à long terme lorsqu'on ne peut même pas prédire le temps de développement d'une seul itération ? Premièrement, il faut contrôler l'information qui passe, non pas se faire dominer par elle !
Personnellement, j'adopte une stratégie "simpliste" quand à ma gestion de l'information. Une bonne gestion de mes emails avec les "flags" d'Outlook (merci Micro$oft !) et une planification avec un backlog - basé sur Scrum - développé en Excel. Ajouter à ça, un soupson de "sticky note" (réel et virtuel) en plus d'une bonne veille to-do list en papier que je traine partout !
Ensuite, tout passe par la priorisation des choses à faire et SURTOUT par une révision constante des priorités - que ce soit celles de l'équipe (backlog) ou personnelles (to-do list). Quand je parle de réviser souvent les priorité, je peux dire que je pouvais les revoir 3-4 fois / jours lors du crunch de pop3 (sur des journée de 14h environs, on parle au déjeuner (après la lecture de mes emails), au diner, au souper et finalement avant de quitter le soir).
Outil = Support
Il ne faut donc pas avoir à se "battre" avec un outil de gestion de tâche, d'où ma philosophie "simpliste" à ce sujet. Lorsque j'ai commencé à utiliser Scrum comme méthode de gestion, mon backlog était une simple feuille Excel, que je mettais à jour moi-même, sans aucune automatisation. J'ai laisser les besoin faire surface et d'itération en itération, j'ai développer un outils puissant mais simple, répondant parfaitemement à mes besoins.
Méthode Allégé
Aujourd'hui, je ne peux pas dire que j'applique Scrum comme tel, mais une méthode adapté à ma réalité, fortement inspiré de Scrum et autre principle Agile. Puisque l'équipe a adopté les itérations de 2 semaines, j'irai donc avec la famille, question de faciliter la communication et la validation!
Par contre, coté planif, puisque la donne change trop souvent, même au niveau du nombre d'heure de développement par itération, je ne mets pas trop l'emphase sur cette partie. Une rencontre de 2h environs suffit à la planification d'une itération. La définition des priorités est l'activité principale et en 2e lieu, vient l'estimation du temps pour accomplir ces tâches.
Ensuite, je m'efforce de valider le chemin parcouru, via les daily meeting et le backlog, et par la suite, je prend le temps de réviser les priorités à chaques fois que cela est nécéssaire.
Conclusion
Je trouve intéressant le fait que la clé de ma gestion est passé par la simplification d'une méthode qui, elle même, se veut la simplification d'une autre. Ce qui m'amène à dire que plus le chaos est important et hors de contrôle, plus le retour au source est la clé !
Prochain sujet a venir : La communication efficace passe par l'utilisation du bon média !
a++
samedi, janvier 21, 2006
Nouveau Départ
Finalement, 2 ans plus tard, nous voici en 2006 !
J'ai changé d'emploi, je travail maintenant comme Lead Quality Assurance chez Ubisoft depuis mars 2005. J'ai été rejoindre Michel C, tel que prédit par ce dernier, lors de son départ de CAE !
2005 fût une année d'apprentissage, puisque le domaine du jeu m'était totallement inconnu ! Je me suis donc relevé les manches et j'ai contribué au développement de Prince of Persia : The Two Thrones à titre de 2e Lead QA officiel dans la compagnie.
Avec un baggage d'expérience qui s'est incroyablement accru durant la dernière année, tant au niveau de la gestion de projet que de la gestion de ressource humaine, j'entreprend l'année sur une nouvelle production dont je me doit de taire le nom, évidement, dû à l'état embryonaire du projet.
Je souhaite donc bonne lecture et bonne année à tout ceux qui oseront me lire ;-)
a++
Marco S.
J'ai changé d'emploi, je travail maintenant comme Lead Quality Assurance chez Ubisoft depuis mars 2005. J'ai été rejoindre Michel C, tel que prédit par ce dernier, lors de son départ de CAE !
2005 fût une année d'apprentissage, puisque le domaine du jeu m'était totallement inconnu ! Je me suis donc relevé les manches et j'ai contribué au développement de Prince of Persia : The Two Thrones à titre de 2e Lead QA officiel dans la compagnie.
Avec un baggage d'expérience qui s'est incroyablement accru durant la dernière année, tant au niveau de la gestion de projet que de la gestion de ressource humaine, j'entreprend l'année sur une nouvelle production dont je me doit de taire le nom, évidement, dû à l'état embryonaire du projet.
Je souhaite donc bonne lecture et bonne année à tout ceux qui oseront me lire ;-)
a++
Marco S.
dimanche, novembre 07, 2004
Software Development: Best Practices
TODO: À lire absolument
Article sur la façon d'estimer les projets
Software Development: Best Practices - Something’s Gotta Give
Article sur la façon d'estimer les projets
Software Development: Best Practices - Something’s Gotta Give
samedi, novembre 06, 2004
Agile Manifesto et autres jolies citations
À ne jamais, jamais oublier, le manifeste agile !
Autre citation
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Autre citation
- "I cannot say whether things will get better if we change; what I can say is they must change if they are to get better." - G. C. Lichtenberg
- "Those who succeed at Scrum are the individuals that will form the core of an organization. Scrum help identify these people." - Kent Beck, Agile Software Development with Scrum
- "Waterfall makes projects start well and finish badly. Iterative makes projects start badly but finish well." - Unknown
- "Freeing a team from uncertainty and interference is probably the greatest productivity gain that occurs in Scrum." - Unknown
- "Agility is more attitude than process and more environment than methodology" - Agile Developper
- "The best minute I spend, is the one I invest in people" - The One Minute Manager
- "How does a project get to be a year late?” ~ “One day at a time.” - Fred Brooks, The Mythical Man-Month.
- "Ce qui me préoccupe, ce sont les grandes et les petites choses. Entre les deux, je délègue". - Konosuka Matsushita, fondateur de Panasonic
- Q. "OK. What is it about you as a rally driver that makes you better than the next guy?"
A. "For any successful driver, it’s confidence. Self-belief. But that’s in anything in life. If you’re confident in what you’re doing and you really believe in yourself that you can pull it off, then generally you will." - Colin McRae RIP 1968-2007
Liste de site intéressant
La communauté agile
eZine
- Software Development Online J'ai découvert ça hier, un portail qui traite d'un peu tout ce qui attrait au software.
Tools
- scrum works Logiciel qui présente le sprint backlog version web server.
Other
- http://www.thinkgeek.com/ Un incontournable pour tout les geek de ce monde. Oui, je m'assume ;-)
marco qui lache pu de gosser sur son Blog ;-)
Certification Scrum Master
Ouais, plus que quelque semaine avant mon séminaire/formation de Scrum Master avec Ken Schwaber et M. Beauregard d'agile Montréal ;-)
J'ai vraiment hâte puisque le coté "application de Scrum" peut sembler façile vu les concept très GBS (gros bon sens ;-). Mais pourtant, même après 2 sprints complèts (le 3e termine dans 1 semaines et se doit d'être un constat d'échec lamentable, mais j'en reparle dans un prochain post ;-), il se trouve que la pratique "agile" est beaucoup plus complèxe qu'elle ne le semble.
Je suis entrain de lire le 2e livre de Schwaber : Agile Software Management with Scrum, Microsoft Press. J'ai à peine commencé, mais je vous assurer qu'il est beaucoup mieux organisé que le premier (Agile Software Development with Scrum) car ce n'est pas qu'un ramassi d'article mais un livre écrit d'un bout à l'autre !
Bon, voilà assez pour ce soir... Other things to do :) J'ai un "gros garage" à préparer, comme dirait Elvis Gratton !
marco qui pense encore à la job, meme le samedi soir à 20h30...
think smart, think agile !
J'ai vraiment hâte puisque le coté "application de Scrum" peut sembler façile vu les concept très GBS (gros bon sens ;-). Mais pourtant, même après 2 sprints complèts (le 3e termine dans 1 semaines et se doit d'être un constat d'échec lamentable, mais j'en reparle dans un prochain post ;-), il se trouve que la pratique "agile" est beaucoup plus complèxe qu'elle ne le semble.
Je suis entrain de lire le 2e livre de Schwaber : Agile Software Management with Scrum, Microsoft Press. J'ai à peine commencé, mais je vous assurer qu'il est beaucoup mieux organisé que le premier (Agile Software Development with Scrum) car ce n'est pas qu'un ramassi d'article mais un livre écrit d'un bout à l'autre !
Bon, voilà assez pour ce soir... Other things to do :) J'ai un "gros garage" à préparer, comme dirait Elvis Gratton !
marco qui pense encore à la job, meme le samedi soir à 20h30...
think smart, think agile !
Il faut toujours un premier post ;-)
Bienvenue sur agileNewbie !!!
Le voilà, mon premier post sur mon premier Blog ;-) J'vais en profiter pour me décrire un peu plus et pour vous inviter à commenter mes posts, car c'est l'idée derrière tous ça !
Comme je disais dans le "about me", je suis chef d'équipe chez CAE. Je travail en gestion, avec les produits d'Oracle, soit Forms 6i sur une base de donnée 9i. Nous avons changer notre façons de travailler depuis cet été pour former des équipes de travail plus versatiles et plus responsables.
Avec mon ex-collègue Michel C. (qui est maintenant rendu chez Ubisoft !), nous avons utilisé Scrum comme façons de gérer un 1er projet qui fût plus que fructueux. Depuis, les gens du management essais d'institutionnaliser cette méthodologie de dévelopement logiciel avec un certain succès, mais que d'embuche !
C'est ces histoires que j'essairais de partager avec vous via ce Blog et ce, vu de mon poste de nouveau Scrum Master ;-)
marco qui écoute harry potter d'une oreille distraite pour une 5 fois au moins :-/
Le voilà, mon premier post sur mon premier Blog ;-) J'vais en profiter pour me décrire un peu plus et pour vous inviter à commenter mes posts, car c'est l'idée derrière tous ça !
Comme je disais dans le "about me", je suis chef d'équipe chez CAE. Je travail en gestion, avec les produits d'Oracle, soit Forms 6i sur une base de donnée 9i. Nous avons changer notre façons de travailler depuis cet été pour former des équipes de travail plus versatiles et plus responsables.
Avec mon ex-collègue Michel C. (qui est maintenant rendu chez Ubisoft !), nous avons utilisé Scrum comme façons de gérer un 1er projet qui fût plus que fructueux. Depuis, les gens du management essais d'institutionnaliser cette méthodologie de dévelopement logiciel avec un certain succès, mais que d'embuche !
C'est ces histoires que j'essairais de partager avec vous via ce Blog et ce, vu de mon poste de nouveau Scrum Master ;-)
marco qui écoute harry potter d'une oreille distraite pour une 5 fois au moins :-/
S'abonner à :
Messages (Atom)