Les méthodologies apportent un courant de changements. Mais, pour effectuer ce changement, il faut travailler plusieurs aspects.
Mais surtout s’assoir les gens de l'industrie concernée ensemble pour discuter ce qu'on peut améliorer ou non dans notre industrie.
C'est ainsi qu'a l'initiative, des gens que je respecte, MM Nicolas Roberge, Jonathan Parent, Luc Vaillancourt, Jean-Philippe Bonneau et le tout supporté par la Vetiq, on eu l’idée de lancer le premier WebCamp de Québec.
C’est une belle occasion d’échanger, de discuter, de voir comment on va les grands changements que l’industrie des TI doit faire, qu’il soit agile, web ou autrement.
La seule chose qui est sure avec les TI, c’est que ça évolue.. ! Et quand on veut voir, savoir et même participer à ce changement, il faut s’impliquer. C’est pourquoi, je serai présent, et je serais prêt à répondre aussi « présent » si les gens veulent m’entendre parler de ma vision des méthodologies agiles.
Participons aux changements, participons à ce WebCamp.. ! C’est une manière.. De s’impliquer aux changements.. ! Derrière le Web, derrière les technologies, il y a des gens qui réfléchissent!
En terminant, je vous invite aussi à laisser des commentaires sur ces billets, si voulez orienter ma possible présentation.
P.-S. Je vous invite à vous inscrire.. Rapidement, les places s’envolent.
mardi 9 juin 2009
lundi 1 juin 2009
Les méthodologies agiles, au gouvernement est-ce possible?
Les méthodologies agiles au gouvernement est ce possible, je réponds à cette question Oui, avec beaucoup de travail par contre.
L'informatique évoluée, les expertises changes, le manque de ressource, la spécialisation des ressources, et encore bien d'autre élément vos finir à faire changer l'approche que nos gouvernements.
Je ne sais pas s'ils iront vers les méthodologies agiles ou autres choses, mais le modèle, dois, et va changer, j'en suis sûr.
En me fiant à mon expérience, à ce que j'ai vu jusqu'ici, le gouvernement va prendre la tendance la plus forte. À titre d'exemple, la technologie qui a pris émergence pour faire du web dans les ministères de la région de Québec, c'est du .net de Microsoft.
En plus, une nouvelle génération (« Y » et ses suivantes) arrive à grands pas, ils ne veulent plus les anciennes méthodes. Mon ami Nicolas Roberge a bien décrit la problématique dans son billet : Le choc des générations dans les technologies de l’information».
On vit, le gouvernement vit un changement majeur dans la manière qu’il doit faire et l’informatique. Récemment, on pouvait apprendre que de grands chantiers avaient défoncé les temps et les budgets, pour le pas dire qu’ils avaient perdu le contrôle.
C’est peut-être en ne faisant plus ces grands chantiers qui sont presque impossibles à contrôler.
On ne peut pas manger un rhinocéros en une seule bouché, mais si on le découpe en petit morceau, c’est plus facile à manger.
C’est la même chose pour un projet informatique. Il faut le prendre en plus partie, c’est beaucoup plus facile à gérer, et ce, dans le contexte du manque de ressources et de changement technologies.
Mais, pour les méthodologies agiles soient abordés dans nos ministères, il y a plus d’un changement à faire. Je ne veux pas couvrir tous les éléments dans ce billet. Je vais essayer d’explorer chacune des problématiques dans les billets suivants.
L’agilité au gouvernement, c’est possible. Mais on va avoir besoin de bon cuisinier pour aider à manger notre rhinocéros. Moi, je suis partant pour trouver la bonne sauce et vous.. ?
Seul, je n’y arriverais pas .. Je vais faire mon petit bout de chemin, aider certain à le faire.. Mais, tous nous devront en faire un aussi.
Là, et seulement là, les méthodologies agiles pourront être adoptées aux gouvernements.
L'informatique évoluée, les expertises changes, le manque de ressource, la spécialisation des ressources, et encore bien d'autre élément vos finir à faire changer l'approche que nos gouvernements.
Je ne sais pas s'ils iront vers les méthodologies agiles ou autres choses, mais le modèle, dois, et va changer, j'en suis sûr.
En me fiant à mon expérience, à ce que j'ai vu jusqu'ici, le gouvernement va prendre la tendance la plus forte. À titre d'exemple, la technologie qui a pris émergence pour faire du web dans les ministères de la région de Québec, c'est du .net de Microsoft.
En plus, une nouvelle génération (« Y » et ses suivantes) arrive à grands pas, ils ne veulent plus les anciennes méthodes. Mon ami Nicolas Roberge a bien décrit la problématique dans son billet : Le choc des générations dans les technologies de l’information».
On vit, le gouvernement vit un changement majeur dans la manière qu’il doit faire et l’informatique. Récemment, on pouvait apprendre que de grands chantiers avaient défoncé les temps et les budgets, pour le pas dire qu’ils avaient perdu le contrôle.
C’est peut-être en ne faisant plus ces grands chantiers qui sont presque impossibles à contrôler.
On ne peut pas manger un rhinocéros en une seule bouché, mais si on le découpe en petit morceau, c’est plus facile à manger.
C’est la même chose pour un projet informatique. Il faut le prendre en plus partie, c’est beaucoup plus facile à gérer, et ce, dans le contexte du manque de ressources et de changement technologies.
Mais, pour les méthodologies agiles soient abordés dans nos ministères, il y a plus d’un changement à faire. Je ne veux pas couvrir tous les éléments dans ce billet. Je vais essayer d’explorer chacune des problématiques dans les billets suivants.
L’agilité au gouvernement, c’est possible. Mais on va avoir besoin de bon cuisinier pour aider à manger notre rhinocéros. Moi, je suis partant pour trouver la bonne sauce et vous.. ?
Seul, je n’y arriverais pas .. Je vais faire mon petit bout de chemin, aider certain à le faire.. Mais, tous nous devront en faire un aussi.
Là, et seulement là, les méthodologies agiles pourront être adoptées aux gouvernements.
mardi 12 mai 2009
Plan de travail, Les méthodoloties agiles et le gouvernement du québec
Mon ami Nicolas Roberge, m’a suggéré sur les méthodologies Agile et le gouvernement québécois.
Comme je crois, que je ne peux pas, qu'il est plus simple d'écrire une série de billets qu'un seul. Je vous propose donc un premier plan de travail.
1. Les méthodologies agile, au gouvernement est-ce possible ?
2. Les appels d'offres et les méthodologies agiles.
3. La motivation des ressources, une part importante du travail en méthodologies Agiles.
4. La gestion d'équipe mixte, consultant et fonctionnaire, est-ce possible ?
5. La gestion des demandes de changements dans le contexte gouvernemental.
6. La gestion de la livraison et de la facturation en contexte agile
7. Y-a-t-il une meilleure méthode, qui serait plus facile à adapter pour le gouvernement ?
Avez-vous d’autres suggestions et laissez-moi un commentaire.
Comme je crois, que je ne peux pas, qu'il est plus simple d'écrire une série de billets qu'un seul. Je vous propose donc un premier plan de travail.
1. Les méthodologies agile, au gouvernement est-ce possible ?
2. Les appels d'offres et les méthodologies agiles.
3. La motivation des ressources, une part importante du travail en méthodologies Agiles.
4. La gestion d'équipe mixte, consultant et fonctionnaire, est-ce possible ?
5. La gestion des demandes de changements dans le contexte gouvernemental.
6. La gestion de la livraison et de la facturation en contexte agile
7. Y-a-t-il une meilleure méthode, qui serait plus facile à adapter pour le gouvernement ?
Avez-vous d’autres suggestions et laissez-moi un commentaire.
Agile plus qu’un Buzzword et comment faire des affaires en agiles
On attendant parler partout des méthodologies agiles, comme étant le nouveau buzzword à la mode.
Et quand, quelque chose devient la saveur du mois, beaucoup de gens, très souvent avec les meilleures intensions du monde (et je le dis sans ironie), voie surgie des occasions d’affaires.
L’occasion d’offrir de nouveaux services à leurs clients. Car, beaucoup de gens, veulent se lancer à cette nouvelle approche, mais ne savent pas trop comment. Donc, le premier réflexe qu’ils ont, c’est engager un consultant.
Pour faire carrière en consultation, je sais que nous sommes vites à dire présent. Même si on n’a pas toujours la compétence. Ce billet n’est pas une critique sur le travail de consultant, étant moi-même consultant et propriétaire d’une petite firme de consultant, se serait me tirer dans le pied avec un fusil à lunette.
Mais, il faut avoir la sagesse de se former, et aussi d’intervenir dans notre spécialité et au besoin de faire partenariat. Je dirais même parfois, réinventer ou créer un nouveau modèle d’affaires.
Car, tant dans le contexte des méthodologies agiles, que d’autres secteurs de l’industrie, il est impossible de tout connaître.
A titre, d’exemple, j’effectue du conseil en méthodologies agiles depuis plusieurs années, depuis 2002, et je pratique régulièrement. Et, il m’arrive encore d’apprendre de nouvelles choses à ce sujet.
Je sais qu’il existe d’excellente formation théorique, par exemple la certification Scrum Master, certaines formations Lean et surement du côté Crystal Clear. Tout comme, il existe de nombreux livres aussi excellents, les uns que les autres.
Mais, dans beaucoup de choses, la pratique et l’expérience de terrain valent de l’or. En suivant la formation, Certification Scrum master, vous apprendrez à animer le « Scrum matinal ». Je l’espère, que votre formateur vous donnera des exemples, et surtout comment s’en sortir, quand le Scrum n’atteint pas son objectif.
Je me souviens de professeurs de base de données à l’université, qui disait vous allez comprendre aujourd’hui, ou dans 10 ans, la modélisation de données. J'avais compris à lors, la modélisation de données. Mais, ça m’a pris 10 ans (manière de parler) pour comprendre ce voulait dire son expression. Si tu as le cerveau, les habilités, un bon professeur, etc. Tu pourras apprendre facilement la théorie. Mais, il faut plus que la théorie pour la mettre en pratique.
15 Ans, plus tard, la différence maintenant en modélisation de données, je pense que je suis meilleur. Mais, surtout je peux trouver plus rapidement une solution aux cas nos théoriques.
C’est la même, vous pourriez lire, des tonnes de livres sur le « pair programming », seule l’expérience pourra vous dire qu’en mettant 2 individus ensemble, pourquoi ça fonctionne tout suite. Et en changeant, l’un des partenaires l’efficacité du pair sera réduite à zéro.
Quand on veut se lancer dans les méthodologies agiles. Il faut aller chercher les formations, lire les livres, les blogues comme celui-ci. Mais, ce qu’il ne faut jamais oublié. Que malgré parfois, un grand nombre d’années d’expériences en informatiques. Que lorsqu’on commence, dans une nouvelle technologie, comme les méthodologies agiles, nous redevenons des juniors pour un temps. Le temps, que l’expérience rentre. C’est d’une question de temps et d’effort.
Rappelons-nous, quand nous avons commencé, quand nous étions juniors, la plus grosse erreur qu’on a tous faite. C’était de ne demander de l’aide, que souvent trop tard. Et maintenant, que l’expérience de la vie, que l’expérience professionnelle a rentrée, oui, dans d’autres secteurs. Il serait sage de demander cette aide dès le départ.
Et pourquoi, en utilisant le bon vieux principe qui a fait sait preuve. Le bon vieux compagnonnage. Faire du compagnonnage, c’est d’être agile avec les méthodologies agiles.
Il y a de la place pour tout le monde, pour faire de la consultation en méthodologies agiles, Mais S.V.P. arrêtons d’improviser, arrêtons de vendre de l’air. Revenons aux 4 principes agiles, au manifeste, afin d’offrir une véritable offre agile.
Et quand, quelque chose devient la saveur du mois, beaucoup de gens, très souvent avec les meilleures intensions du monde (et je le dis sans ironie), voie surgie des occasions d’affaires.
L’occasion d’offrir de nouveaux services à leurs clients. Car, beaucoup de gens, veulent se lancer à cette nouvelle approche, mais ne savent pas trop comment. Donc, le premier réflexe qu’ils ont, c’est engager un consultant.
Pour faire carrière en consultation, je sais que nous sommes vites à dire présent. Même si on n’a pas toujours la compétence. Ce billet n’est pas une critique sur le travail de consultant, étant moi-même consultant et propriétaire d’une petite firme de consultant, se serait me tirer dans le pied avec un fusil à lunette.
Mais, il faut avoir la sagesse de se former, et aussi d’intervenir dans notre spécialité et au besoin de faire partenariat. Je dirais même parfois, réinventer ou créer un nouveau modèle d’affaires.
Car, tant dans le contexte des méthodologies agiles, que d’autres secteurs de l’industrie, il est impossible de tout connaître.
A titre, d’exemple, j’effectue du conseil en méthodologies agiles depuis plusieurs années, depuis 2002, et je pratique régulièrement. Et, il m’arrive encore d’apprendre de nouvelles choses à ce sujet.
Je sais qu’il existe d’excellente formation théorique, par exemple la certification Scrum Master, certaines formations Lean et surement du côté Crystal Clear. Tout comme, il existe de nombreux livres aussi excellents, les uns que les autres.
Mais, dans beaucoup de choses, la pratique et l’expérience de terrain valent de l’or. En suivant la formation, Certification Scrum master, vous apprendrez à animer le « Scrum matinal ». Je l’espère, que votre formateur vous donnera des exemples, et surtout comment s’en sortir, quand le Scrum n’atteint pas son objectif.
Je me souviens de professeurs de base de données à l’université, qui disait vous allez comprendre aujourd’hui, ou dans 10 ans, la modélisation de données. J'avais compris à lors, la modélisation de données. Mais, ça m’a pris 10 ans (manière de parler) pour comprendre ce voulait dire son expression. Si tu as le cerveau, les habilités, un bon professeur, etc. Tu pourras apprendre facilement la théorie. Mais, il faut plus que la théorie pour la mettre en pratique.
15 Ans, plus tard, la différence maintenant en modélisation de données, je pense que je suis meilleur. Mais, surtout je peux trouver plus rapidement une solution aux cas nos théoriques.
C’est la même, vous pourriez lire, des tonnes de livres sur le « pair programming », seule l’expérience pourra vous dire qu’en mettant 2 individus ensemble, pourquoi ça fonctionne tout suite. Et en changeant, l’un des partenaires l’efficacité du pair sera réduite à zéro.
Quand on veut se lancer dans les méthodologies agiles. Il faut aller chercher les formations, lire les livres, les blogues comme celui-ci. Mais, ce qu’il ne faut jamais oublié. Que malgré parfois, un grand nombre d’années d’expériences en informatiques. Que lorsqu’on commence, dans une nouvelle technologie, comme les méthodologies agiles, nous redevenons des juniors pour un temps. Le temps, que l’expérience rentre. C’est d’une question de temps et d’effort.
Rappelons-nous, quand nous avons commencé, quand nous étions juniors, la plus grosse erreur qu’on a tous faite. C’était de ne demander de l’aide, que souvent trop tard. Et maintenant, que l’expérience de la vie, que l’expérience professionnelle a rentrée, oui, dans d’autres secteurs. Il serait sage de demander cette aide dès le départ.
Et pourquoi, en utilisant le bon vieux principe qui a fait sait preuve. Le bon vieux compagnonnage. Faire du compagnonnage, c’est d’être agile avec les méthodologies agiles.
Il y a de la place pour tout le monde, pour faire de la consultation en méthodologies agiles, Mais S.V.P. arrêtons d’improviser, arrêtons de vendre de l’air. Revenons aux 4 principes agiles, au manifeste, afin d’offrir une véritable offre agile.
lundi 27 avril 2009
Macroscope versus Agiles, combat à finir
Pour beaucoup de gens, dont les puristes des 2 côtés, affirme haut et fort que ces 2 méthodologies s’opposent.
Mais, est-ce vraiment le cas ?
D’abord, posons un regard sur Macroscope de DMR.
Voici le texte d’introduction trouvé le site de DMR. http://tinyurl.com/Macrosope
« Grâce à ses méthodes, processus et outils, Macroscope aide les entreprises à planifier, à mettre en œuvre et à gérer leur transformation organisationnelle par des initiatives clés :
• planification stratégique
• architecture de l'entreprise et de ses technologies de l'information
• développement, déploiement et maintenance de systèmes d'information et d'autres solutions technologiques
• gestion de projet
• gestion de la valeur et de la réalisation des bénéfices
À la manière d'une feuille de route, Macroscope guide les acteurs dans la réalisation de leurs activités, et ce, à toutes les étapes d'un changement organisationnel. »
Regardons de l’autre côté le manifeste agile : http://tinyurl.com/AgileManifesto
• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide
Allez affirmer que Macroscope implémente les méthodologies agiles. Quand même, affirmer ceci serait une stupidité.
À la lumière de ces 2 courts textes, je crois que me permet par contre dire qu’il ne s’oppose pas. Macroscope est une méthodologie qui décrit et définit les processus qu’on devrait faire pour le changement organisationnel, y compris ceux qui touchent le développement d’applications. Pour se faire, il fournit une série de gabarits qui permet de documenter les processus de développement logiciels. Beaucoup d’excellents exemples de référence comme base pour les construire.
Vous pensez sans que j’aille citer le 2e principe, celui de la documentation exhaustive pour m’attaquer de front à Macroscope pour la tuer. Eh bien non, détromper vous trompez, c’est tout le contraire.
Oui, je m’en sers de ce principe. Mais, je ne me s’en pas partir en guerre rangée contre DMR et sa méthodologie. Je reconnais certaines applications de son approche de gestion et surtout quand les gens font de la sur documente ce n’est pas très agile.
Ce n’est pas une grande nouvelle. Mais, je pense qu’on devait réfléchir le problème différemment. Tout le monde qui me connaisse, et encore plus, ceux qui ont lu mes articles précédents savent que je prône la documentation, lorsque nécessaire bien sûr.
Il faut documenter ce qui doit être documenté. C’est ce que dit ce principe. Et de l’autre coté, Macroscope nous explique comment le faire cette documentation, comment documenter les différentes choses avec l’aide de ses gabarits
Donc, si nous voulons être agiles tout en utilisant Macroscope. C’est possible. Il suffit de gérer le projet en utilisant une approche agile. Et pourquoi pas SCRUM. SCRUM était une méthode du coté agile aussi structurée et structurante. Elle est très rassurante pour les clients.
Et utilisez Macroscope pour documenter les processus. Je travaille dans le marché de Québec, essentiellement gouvernementale et grosse compagnie d’assurances, pour savoir qu’elles sont habituées de lire ces documents.
Ce n’est pas un vrai passage à agile. Mais, une belle transition qui pourra aider à mieux faire l’informatique. Et surtout d’aider à démocratiser l’utilisation des méthodologies agiles dans notre belle région de Québec.
S.V.P. par contre, ARRÊTEZ de sur documenter et de faire du copier-coller de chose qui est déjà documentée. Combien de fois, j’ai vu qu’on a répété le texte, parfois écrit différemment, pour expliquer la même chose dans une même série de documents.
Il n’est pas nécessaire de réécrire un algorithme de validation générique dans tous les dossiers fonctionnels qui l’utilise. Documentez-la dans un seul document et fais-y référence, dans les autres.
Un document utilisant des références aurait du faire de 20-25 pages, mais parce qu’on n’avait pas recopié le texte. Il pourrait en contenir plus de 100 pages sinon. Qui aime lire des documents de 100 pages. Pas moi en tout cas.
Et en plus, pensons eu un peu à l’environnement.. ! Utilisons une documentation électronique, wiki, blogue et compagnie.
En utilisant, les bons côtés de chacune de ces méthodologies, nous serons agiles dans notre gestion de projets.
Et si vous croyez que cela ne peut pas fonctionner. Oui, j’en suis sur ça fonctionne. C’est d’ailleurs la technique, j’ai suggéré à une amie, une spécialiste Macroscope et ancienne membre de l’équipe de rédaction de Québec. Car, elle voulait passer à agile, mais sans pour autant délaisser ses bases.
A ce que je sais et selon que j’ai discuté avec elle, la dernière fois qu’on s’est vue. Elle l’a appliqué avec succès dans un de ses mandats dans un ministère.
Être agile, ce n’est pas tout changé, c’est aussi savoir manier l’ancien avec le nouveau. C’est de réfléchir le problème, pour trouver ou retrouver des solutions.
Et ceux, qui ne me croient pas .. Communiquer avec moi, on le fera ensemble, cette implémentation d’Agile et Macroscope dans votre organisation. generationagile@gmail.com
Mais, est-ce vraiment le cas ?
D’abord, posons un regard sur Macroscope de DMR.
Voici le texte d’introduction trouvé le site de DMR. http://tinyurl.com/Macrosope
« Grâce à ses méthodes, processus et outils, Macroscope aide les entreprises à planifier, à mettre en œuvre et à gérer leur transformation organisationnelle par des initiatives clés :
• planification stratégique
• architecture de l'entreprise et de ses technologies de l'information
• développement, déploiement et maintenance de systèmes d'information et d'autres solutions technologiques
• gestion de projet
• gestion de la valeur et de la réalisation des bénéfices
À la manière d'une feuille de route, Macroscope guide les acteurs dans la réalisation de leurs activités, et ce, à toutes les étapes d'un changement organisationnel. »
Regardons de l’autre côté le manifeste agile : http://tinyurl.com/AgileManifesto
• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide
Allez affirmer que Macroscope implémente les méthodologies agiles. Quand même, affirmer ceci serait une stupidité.
À la lumière de ces 2 courts textes, je crois que me permet par contre dire qu’il ne s’oppose pas. Macroscope est une méthodologie qui décrit et définit les processus qu’on devrait faire pour le changement organisationnel, y compris ceux qui touchent le développement d’applications. Pour se faire, il fournit une série de gabarits qui permet de documenter les processus de développement logiciels. Beaucoup d’excellents exemples de référence comme base pour les construire.
Vous pensez sans que j’aille citer le 2e principe, celui de la documentation exhaustive pour m’attaquer de front à Macroscope pour la tuer. Eh bien non, détromper vous trompez, c’est tout le contraire.
Oui, je m’en sers de ce principe. Mais, je ne me s’en pas partir en guerre rangée contre DMR et sa méthodologie. Je reconnais certaines applications de son approche de gestion et surtout quand les gens font de la sur documente ce n’est pas très agile.
Ce n’est pas une grande nouvelle. Mais, je pense qu’on devait réfléchir le problème différemment. Tout le monde qui me connaisse, et encore plus, ceux qui ont lu mes articles précédents savent que je prône la documentation, lorsque nécessaire bien sûr.
Il faut documenter ce qui doit être documenté. C’est ce que dit ce principe. Et de l’autre coté, Macroscope nous explique comment le faire cette documentation, comment documenter les différentes choses avec l’aide de ses gabarits
Donc, si nous voulons être agiles tout en utilisant Macroscope. C’est possible. Il suffit de gérer le projet en utilisant une approche agile. Et pourquoi pas SCRUM. SCRUM était une méthode du coté agile aussi structurée et structurante. Elle est très rassurante pour les clients.
Et utilisez Macroscope pour documenter les processus. Je travaille dans le marché de Québec, essentiellement gouvernementale et grosse compagnie d’assurances, pour savoir qu’elles sont habituées de lire ces documents.
Ce n’est pas un vrai passage à agile. Mais, une belle transition qui pourra aider à mieux faire l’informatique. Et surtout d’aider à démocratiser l’utilisation des méthodologies agiles dans notre belle région de Québec.
S.V.P. par contre, ARRÊTEZ de sur documenter et de faire du copier-coller de chose qui est déjà documentée. Combien de fois, j’ai vu qu’on a répété le texte, parfois écrit différemment, pour expliquer la même chose dans une même série de documents.
Il n’est pas nécessaire de réécrire un algorithme de validation générique dans tous les dossiers fonctionnels qui l’utilise. Documentez-la dans un seul document et fais-y référence, dans les autres.
Un document utilisant des références aurait du faire de 20-25 pages, mais parce qu’on n’avait pas recopié le texte. Il pourrait en contenir plus de 100 pages sinon. Qui aime lire des documents de 100 pages. Pas moi en tout cas.
Et en plus, pensons eu un peu à l’environnement.. ! Utilisons une documentation électronique, wiki, blogue et compagnie.
En utilisant, les bons côtés de chacune de ces méthodologies, nous serons agiles dans notre gestion de projets.
Et si vous croyez que cela ne peut pas fonctionner. Oui, j’en suis sur ça fonctionne. C’est d’ailleurs la technique, j’ai suggéré à une amie, une spécialiste Macroscope et ancienne membre de l’équipe de rédaction de Québec. Car, elle voulait passer à agile, mais sans pour autant délaisser ses bases.
A ce que je sais et selon que j’ai discuté avec elle, la dernière fois qu’on s’est vue. Elle l’a appliqué avec succès dans un de ses mandats dans un ministère.
Être agile, ce n’est pas tout changé, c’est aussi savoir manier l’ancien avec le nouveau. C’est de réfléchir le problème, pour trouver ou retrouver des solutions.
Et ceux, qui ne me croient pas .. Communiquer avec moi, on le fera ensemble, cette implémentation d’Agile et Macroscope dans votre organisation. generationagile@gmail.com
mercredi 22 avril 2009
123 Go je me lance en agile.. !
Un nouveau courant d’idées méthodologiques qui commence à émerger, c’est bien les méthodologies agiles. C’est bien beau, mais par où commencer! Voici notre réponse à cette question importante que nous allons essayer de vous donner des pistes des solutions durant cet article.
Nous aimerions bien vous proposer une recette magique. Une recette que vous pourriez, appliquer sans qui crainte de l’échec et qui va réussir à tous les coups. Mais, l’expérience de plusieurs années en informatique et en méthodologies de développement. Dont, avec les méthodologies agiles, nous a permis de comprendre qu’il faut faire attention avec ces soit disent « recette toute faite ».
Il faut repartir à la base des méthodologies agiles, les quatre principes :
• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide
Si une organisation, (une compagnie, une équipe de développement, etc.) décide de se tourner ou du moins regarde la possibilité de le faire. C’est qu’elle a identifié qu’elle a un problème quelque part. Et potentiellement, l’un qui touche c’est quatre grands principes.
Bravo, vous avez fait le premier pas. Car, en se lançant en agile, ou toutes autres nouvelles méthodes. Il faut gérer le changement. Il faut faire un constat.
Agile ne signifie qu’il faut tout changer dans votre organisation. Encore moins, que tout ce que vous faites déjà est en erreur. Agile chercher simplement à améliorer vos processus en apportant une nouvelle vision, une nouvelle approche dans la manière d’aborder un problème.
Lorsque nous implémentons agiles dans une organisation, il ne faut pas arriver avec un bulldozer qui détruira tout sur son passage. Il faut arriver avec de la minutie, du doigté, de la sagesse et surtout beaucoup de respect.
Nous disons toujours regardons ce que vous faites de biens, ce qui peut être amélioré, ce qui doit être changé et ce qui ne doit pas l’être.
Il y a une école de pensée dans les méthodologies agiles, qui veulent la mort des méthodes « wather falls » ou des approches mérisiennes (Mérise, P+, Macroscope). Nous pensons le contraire. Si certains éléments de ces méthodes en cascade fonctionnent chez vous. Continuez à les utiliser (ne changeons pas ce qui fonctionne.) Ajustons seulement la manière de les utiliser dans un contexte agile. Exemple, si vos clients sont confortable avec un dossier fonctionnel selon les la définition de P+. Continuer à les écrire sur cette base. L’adaptation agile qu’on peut faire, c’est de réduire son volume (le nombre de pages) et le média de production. Au lieu de l’écrire sur beau document imprimé sur 8 ½ - 11. Utiliser une version électronique qui contient des références web (pointeurs) vers des processus déjà documentés ou pourquoi pas un Wiki.
A l’inverse, si aucun de vos clients ne lit le plus petit dossier fonctionnel, à quoi sert donc à s’acharner des les produire. Utiliser peut-être un « cas d’utilisation UML » ou les « Story de Scrum ».
Il apporter des solutions aux problèmes, et surtout ne pas en créer de nouveau.
Après avoir fait le constat dans votre organisation, vous nous poserez sans doute les questions suivantes :
• Il doit exister une ou plusieurs méthodes structurées qui implémentent ces principes ?
• La quelle de ses méthodes, dois-je choisir ?
Il existe plusieurs méthodes, certaines plus structurées que d’autre.
• Scrum
• Extrême programming
• Lean
• RAD (Rapid Application Developpement)
• Et plusieurs autres.
Laquelle prendre dans cette liste, en prendre une ou toutes les prendre, me diriez-vous. Nous répondons toujours, la même chose. Un bon mélange de tout ça. Un petit soupçon de SCRUM pour sa structure et sa gestion d’équipe. La gestion des story pour documenter les processus d’affaires. Le « SCRUM matinal » pour assurer un bon suivi. Et le plus important, le cycle d’itération très court avec son fameux backlog.
Quelque graine d’extrême programming, avec son « pair programming » adapté à la bonne saveur de votre organisation. Peut-être pas 2 personnes assises devant l’écran. Mais, une redondance des expertises par exemple. Par l’approche, spécialiste et son assistant. Une personne possède une personne précise. Et en cas de son absence (ou non-disponibilité), le second peut intervenir à la place du principale.
Lean la gestion de la qualité des processus et des livrables. On veut livrer quelque chose, mais surtout quelque chose de qualité. Ainsi que son principe de juste d’attends.
N’oubliez pas, ce n’est pas une recette de cuisine. Une recette générique qu’on peut appliquer tous les organisations. Si on veut respecter les valeurs mêmes d’agrile, il faut trouver le moyen d’adapter cette recette, d’ajuster les saveurs pour réponse à notre besoin. Une méthode qui nous (nous et vous) à produire de meilleurs logiciels tant qualité du produit, en coût de développement qu’en temps de développement.
En conclusion, se lancer en agile, ce n’est pas une chose simple sans pour autant être complexe. Il faut prendre le temps de bien poser l’analyse. Ne pas avoir peur de se remettre en questions et surtout avec l’agilité de s’adapter en cours de routes.
Mais, surtout trouver une personne d’expériences (en méthodologie agile) avec la chimie passera .. ! et avec laquelle vous n’aurez pas peur de tout remettre en question. Y compris de ne rien changer .. !
Je sais, il semble que nous vous laissons sur votre faim, sans avoir bien répondu à la question. Et pourtant, oui nous y avons répondu .. ! Car, la seule solution à savoir comment on se lance en agile, c’est avec vous .. que seulement nous pouvons la trouver.. !
Agile c’est de pensée différemment, et parfois de donner des réponses qui ne semblent pas en être une.
Nous aimerions bien vous proposer une recette magique. Une recette que vous pourriez, appliquer sans qui crainte de l’échec et qui va réussir à tous les coups. Mais, l’expérience de plusieurs années en informatique et en méthodologies de développement. Dont, avec les méthodologies agiles, nous a permis de comprendre qu’il faut faire attention avec ces soit disent « recette toute faite ».
Il faut repartir à la base des méthodologies agiles, les quatre principes :
• Les individus et les interactions doivent primer sur les processus et les outils
• Le développement logiciel doit primer sur la documentation exhaustive
• La collaboration avec le client doit primer sur la négociation contractuelle
• L’ouverture au changement doit primer sur le suivi d’un plan rigide
Si une organisation, (une compagnie, une équipe de développement, etc.) décide de se tourner ou du moins regarde la possibilité de le faire. C’est qu’elle a identifié qu’elle a un problème quelque part. Et potentiellement, l’un qui touche c’est quatre grands principes.
Bravo, vous avez fait le premier pas. Car, en se lançant en agile, ou toutes autres nouvelles méthodes. Il faut gérer le changement. Il faut faire un constat.
Agile ne signifie qu’il faut tout changer dans votre organisation. Encore moins, que tout ce que vous faites déjà est en erreur. Agile chercher simplement à améliorer vos processus en apportant une nouvelle vision, une nouvelle approche dans la manière d’aborder un problème.
Lorsque nous implémentons agiles dans une organisation, il ne faut pas arriver avec un bulldozer qui détruira tout sur son passage. Il faut arriver avec de la minutie, du doigté, de la sagesse et surtout beaucoup de respect.
Nous disons toujours regardons ce que vous faites de biens, ce qui peut être amélioré, ce qui doit être changé et ce qui ne doit pas l’être.
Il y a une école de pensée dans les méthodologies agiles, qui veulent la mort des méthodes « wather falls » ou des approches mérisiennes (Mérise, P+, Macroscope). Nous pensons le contraire. Si certains éléments de ces méthodes en cascade fonctionnent chez vous. Continuez à les utiliser (ne changeons pas ce qui fonctionne.) Ajustons seulement la manière de les utiliser dans un contexte agile. Exemple, si vos clients sont confortable avec un dossier fonctionnel selon les la définition de P+. Continuer à les écrire sur cette base. L’adaptation agile qu’on peut faire, c’est de réduire son volume (le nombre de pages) et le média de production. Au lieu de l’écrire sur beau document imprimé sur 8 ½ - 11. Utiliser une version électronique qui contient des références web (pointeurs) vers des processus déjà documentés ou pourquoi pas un Wiki.
A l’inverse, si aucun de vos clients ne lit le plus petit dossier fonctionnel, à quoi sert donc à s’acharner des les produire. Utiliser peut-être un « cas d’utilisation UML » ou les « Story de Scrum ».
Il apporter des solutions aux problèmes, et surtout ne pas en créer de nouveau.
Après avoir fait le constat dans votre organisation, vous nous poserez sans doute les questions suivantes :
• Il doit exister une ou plusieurs méthodes structurées qui implémentent ces principes ?
• La quelle de ses méthodes, dois-je choisir ?
Il existe plusieurs méthodes, certaines plus structurées que d’autre.
• Scrum
• Extrême programming
• Lean
• RAD (Rapid Application Developpement)
• Et plusieurs autres.
Laquelle prendre dans cette liste, en prendre une ou toutes les prendre, me diriez-vous. Nous répondons toujours, la même chose. Un bon mélange de tout ça. Un petit soupçon de SCRUM pour sa structure et sa gestion d’équipe. La gestion des story pour documenter les processus d’affaires. Le « SCRUM matinal » pour assurer un bon suivi. Et le plus important, le cycle d’itération très court avec son fameux backlog.
Quelque graine d’extrême programming, avec son « pair programming » adapté à la bonne saveur de votre organisation. Peut-être pas 2 personnes assises devant l’écran. Mais, une redondance des expertises par exemple. Par l’approche, spécialiste et son assistant. Une personne possède une personne précise. Et en cas de son absence (ou non-disponibilité), le second peut intervenir à la place du principale.
Lean la gestion de la qualité des processus et des livrables. On veut livrer quelque chose, mais surtout quelque chose de qualité. Ainsi que son principe de juste d’attends.
N’oubliez pas, ce n’est pas une recette de cuisine. Une recette générique qu’on peut appliquer tous les organisations. Si on veut respecter les valeurs mêmes d’agrile, il faut trouver le moyen d’adapter cette recette, d’ajuster les saveurs pour réponse à notre besoin. Une méthode qui nous (nous et vous) à produire de meilleurs logiciels tant qualité du produit, en coût de développement qu’en temps de développement.
En conclusion, se lancer en agile, ce n’est pas une chose simple sans pour autant être complexe. Il faut prendre le temps de bien poser l’analyse. Ne pas avoir peur de se remettre en questions et surtout avec l’agilité de s’adapter en cours de routes.
Mais, surtout trouver une personne d’expériences (en méthodologie agile) avec la chimie passera .. ! et avec laquelle vous n’aurez pas peur de tout remettre en question. Y compris de ne rien changer .. !
Je sais, il semble que nous vous laissons sur votre faim, sans avoir bien répondu à la question. Et pourtant, oui nous y avons répondu .. ! Car, la seule solution à savoir comment on se lance en agile, c’est avec vous .. que seulement nous pouvons la trouver.. !
Agile c’est de pensée différemment, et parfois de donner des réponses qui ne semblent pas en être une.
jeudi 26 mars 2009
L’expérience et la compétence
Ces deux termes sont souvent confondus. Pour ma part, elles sont différentes sans pour autant s’opposer.
L’expérience s’acquière aux files des années, aucune formation, pilule magique peut données l’expérience. Comme disait mon défunt père, l’expérience s’acquiert : « au pic et la pioche » .
Quant à la compétence, elle peut s’acquérir par de la formation, par le travail, l’étude. Mais, à la base il faut avoir la structure d’esprit, de pensée, nécessaire pour arriver acquérir cette compétence.
Par exemple, j’ai un profond respect pour les programmeurs Cobol. J’ai eu de très bons professeurs, mais malgré cela je reste profondément incompétent dans ce langage. Par contre, fais-te moi parler d’architecture orientée objet et orientée Service, la je crois que je sais de quoi je parle.
Suis-je plus incompétent pour autant, non, c’est juste que mon cerveau est construit d’une certaine manière, qui m’aide dans mon travail. Et j’aurais beau travailler 10 ans, (j’espère que non) en Cobol, je resterai toujours un mauvais programmeur Cobol. Dieu merci, il y a des gens qui l’ont.
Combien de fois, j’ai entendu quelqu’un, et souvent des patrons pour justifier une promotion d’une personne. Il a acquis assez d’années expériences pour ce poste, sans pour autant regarder si la personne avait la compétence nécessaire pour ce poste.
Aux files des années, j’ai connu beaucoup de personnes qui avaient gravi les échelons par expérience sans pour autant en avoir les compétences. Un peu à l’image de principe de Peters.
À l’inverse, j’ai aussi connu beaucoup de gens, qui avaient toutes les compétences pour occuper un poste supérieur. Mais, qui n’avait pas toute « L’EXPÉRIENCE » pour l’obtenir.
Je ne veux pas dire qu’il faut donner à des gens sans expérience, des postes qui en demande. Mais, en plus de regarder l’expérience, qu’il faut regarder d’autre chose. Donc, les compétences, mais aussi l’intérêt. Je n’ai pas les compétences pour le Cobol, mais surtout aucun intérêt pour ce genre de langage.
Il faut donc, arrêter de voir l’informatique comme étant hiérarchique, mais étant compartimenté. Un bon programmeur ne fait pas automatiquement un bon architecte. C’est peut-être notre programmeur moyen qui sera notre meilleur architecte ou analyste. Je pense à coéquipier d’université, l’un pour des meilleurs programmeurs que j’ai connu. Ferais un mauvais architecte ou même pire, un analyste pitoyable. Car, il a de la difficulté à interagir et communiquer avec les autres. Mais, il écrit du code plus vite que sont ombre. Et surtout du code d’une très grande qualité.
Aujourd’hui, il doit cumuler près de 20 ans d’expérience, et aux dernières nouvelles que j’en ai eues, il est toujours programmeur. Et j’en suis sur, un programmeur redoutable. Il aurait l’expérience pour devenir Architecte ou Analyste. Mais, il n’a pas les compétences pour le devenir. Et je ne pense pas l’intérêt non plus.
Beaucoup trop, d’architecte, d’analyste ou chargé de projet qui pense, encore comme quand il était programmeur. Comme, j’ai connu beaucoup de monde, j’ai connu aussi un analyste fonctionnel, qui écrivait des dossiers fonctionnels, de vrai roman, excessivement facile à lire et comprendre. Par contre, il n’était incapable de le programmer ce dossier. A chacun son métier et les vaches seront bien gardé.
Avec les méthodologies agiles, nous offre un environnement assez sur les compétences et l’intérêt des individus plus tôt que par la reconnaissance de l’expérience. Un programmeur de 20 ans d’expérience, au lieu de lui donner un poste d’architecte dans laquelle, il n’aura pas l’expertise nécessaire. Lui donner la chance de continuer à faire ce qui fait de mieux, c'est-à-dire programmer, mais aussi transmettre toutes ces expériences (pas les années, mais la somme des projets et des lignes de codes) qu’il a fait aux autres.
Un bon programmeur, nous permet d’augmenter la qualité de notre logiciel. On veut un logiciel qui fonctionne, mais surtout un logiciel de qualité.
Mettons les bonnes aux bons endroits, tant d’un point de vue des compétences, de l’expérience que des intérêts. On est venu en informatique pour se faire du fun.. ! Pour avoir du Fun ! Donc, c’est en passant, en repassant ce modèle que nous pour arriver à cet objectif ultime, de livrer une application de qualité et surtout qui corresponds aux différents besoins de notre client.
Associons compétence, expérience et intérêt, et je crois sincèrement que nous de meilleurs ressources pour tous nos projets.
Si tout le monde change un seul individu, que cet individu en fait autant. La terre informatique se portera mieux !
L’expérience s’acquière aux files des années, aucune formation, pilule magique peut données l’expérience. Comme disait mon défunt père, l’expérience s’acquiert : « au pic et la pioche » .
Quant à la compétence, elle peut s’acquérir par de la formation, par le travail, l’étude. Mais, à la base il faut avoir la structure d’esprit, de pensée, nécessaire pour arriver acquérir cette compétence.
Par exemple, j’ai un profond respect pour les programmeurs Cobol. J’ai eu de très bons professeurs, mais malgré cela je reste profondément incompétent dans ce langage. Par contre, fais-te moi parler d’architecture orientée objet et orientée Service, la je crois que je sais de quoi je parle.
Suis-je plus incompétent pour autant, non, c’est juste que mon cerveau est construit d’une certaine manière, qui m’aide dans mon travail. Et j’aurais beau travailler 10 ans, (j’espère que non) en Cobol, je resterai toujours un mauvais programmeur Cobol. Dieu merci, il y a des gens qui l’ont.
Combien de fois, j’ai entendu quelqu’un, et souvent des patrons pour justifier une promotion d’une personne. Il a acquis assez d’années expériences pour ce poste, sans pour autant regarder si la personne avait la compétence nécessaire pour ce poste.
Aux files des années, j’ai connu beaucoup de personnes qui avaient gravi les échelons par expérience sans pour autant en avoir les compétences. Un peu à l’image de principe de Peters.
À l’inverse, j’ai aussi connu beaucoup de gens, qui avaient toutes les compétences pour occuper un poste supérieur. Mais, qui n’avait pas toute « L’EXPÉRIENCE » pour l’obtenir.
Je ne veux pas dire qu’il faut donner à des gens sans expérience, des postes qui en demande. Mais, en plus de regarder l’expérience, qu’il faut regarder d’autre chose. Donc, les compétences, mais aussi l’intérêt. Je n’ai pas les compétences pour le Cobol, mais surtout aucun intérêt pour ce genre de langage.
Il faut donc, arrêter de voir l’informatique comme étant hiérarchique, mais étant compartimenté. Un bon programmeur ne fait pas automatiquement un bon architecte. C’est peut-être notre programmeur moyen qui sera notre meilleur architecte ou analyste. Je pense à coéquipier d’université, l’un pour des meilleurs programmeurs que j’ai connu. Ferais un mauvais architecte ou même pire, un analyste pitoyable. Car, il a de la difficulté à interagir et communiquer avec les autres. Mais, il écrit du code plus vite que sont ombre. Et surtout du code d’une très grande qualité.
Aujourd’hui, il doit cumuler près de 20 ans d’expérience, et aux dernières nouvelles que j’en ai eues, il est toujours programmeur. Et j’en suis sur, un programmeur redoutable. Il aurait l’expérience pour devenir Architecte ou Analyste. Mais, il n’a pas les compétences pour le devenir. Et je ne pense pas l’intérêt non plus.
Beaucoup trop, d’architecte, d’analyste ou chargé de projet qui pense, encore comme quand il était programmeur. Comme, j’ai connu beaucoup de monde, j’ai connu aussi un analyste fonctionnel, qui écrivait des dossiers fonctionnels, de vrai roman, excessivement facile à lire et comprendre. Par contre, il n’était incapable de le programmer ce dossier. A chacun son métier et les vaches seront bien gardé.
Avec les méthodologies agiles, nous offre un environnement assez sur les compétences et l’intérêt des individus plus tôt que par la reconnaissance de l’expérience. Un programmeur de 20 ans d’expérience, au lieu de lui donner un poste d’architecte dans laquelle, il n’aura pas l’expertise nécessaire. Lui donner la chance de continuer à faire ce qui fait de mieux, c'est-à-dire programmer, mais aussi transmettre toutes ces expériences (pas les années, mais la somme des projets et des lignes de codes) qu’il a fait aux autres.
Un bon programmeur, nous permet d’augmenter la qualité de notre logiciel. On veut un logiciel qui fonctionne, mais surtout un logiciel de qualité.
Mettons les bonnes aux bons endroits, tant d’un point de vue des compétences, de l’expérience que des intérêts. On est venu en informatique pour se faire du fun.. ! Pour avoir du Fun ! Donc, c’est en passant, en repassant ce modèle que nous pour arriver à cet objectif ultime, de livrer une application de qualité et surtout qui corresponds aux différents besoins de notre client.
Associons compétence, expérience et intérêt, et je crois sincèrement que nous de meilleurs ressources pour tous nos projets.
Si tout le monde change un seul individu, que cet individu en fait autant. La terre informatique se portera mieux !
Inscription à :
Articles (Atom)
