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.

29 juillet 2008

CMMI et Agilité

Chez nous on est en train de débuter un programme autour du CMMI. Actuellement on est en train de voir à quel niveau nos équipes sont. Sur papier on est à au moins au niveau 3 car notre méthodologie actuelle (Centre Productivité P+) est full CMMI. Le problème n'est pas avec le niveau de maturité de la méthode mais plutôt avec celui de l'utilisation de la méthode. D'une équipe à une autre il y a effectivement de grandes variations dans la compréhension et la maitrise de la méthode.

Comme je me fais le promoteur de l'agilité dans notre entreprise, et que la tendance va être à la "certification" CMMI, je ressort la litérature existante sur le sujet. Généralement il n'y a pas d'incompatibilité entre les approches agiles et le CMMI, tout comme il n'y en avait pas avec le PMBOK. Souvent c'est une incompréhension des divers éléments en cause qui ammène une perception négative.

Ainsi à la base, le cadre du CMMI indique les pratiques qui doivent être mise en ouevre par les organisations et non comment les mettre en oeuvre. Or les approches agile décrivent pluôt comment mettre en oeuvre les pratiques. Donc pas d'incompatibilité fondamentale.

Il est possible cependant qu'une approche agile ne couvre pas tous les aspects (KPA) d'un niveau CMMI donné. C'est le cas de SCRUM qui se concentre plus sur la gestion de projet que sur les pratiques d'ingénieries logiciels prescrites par le CMMI et les bonnes pratiques en générale. C'est d'ailleur la raison pour laquel j'utilise rarement SCRUM seul.

Comme il faut s'y attendre il existe déjà le site http://www.agilecmmi.com/

Dans la littérature on trouve par exemple la façon dont MicroSoft a rendu sa méthologie agile au niveau 3. La présentation de 2005 (en PDF) montre comment a été conçu MSF for Agile.

Jeff Dalton, un évaluateur CMMI à un blog intéressant sur CMMI et l'agilité. Un autre blog intéressant est celui de Glen Alleman.

Le papier présenté en 2006 au SPICE discute de 3 études de cas de CMMI dans un contexte agile

L'excellente revue (militaire) CrossTalk discute dans un article de 2007 des processus d'ingénierie, de l'agilité et de la maturité. D'ailleur tout le numéro d'avril 2007 de CrossTalk est consacré à l'agilité et adresse la maturité. En février 2008 on trouve un excellent article de Capers Jones qui présente des données touchant les bénéfices du CMMI et de l'agilité et des approches hybrides.

Un article de Dr. Dobbs discute des approches agiles (valeurs de base) du TSP (Team Software Process) et du CMMI en général.

16:50 Publié dans Scrum | Lien permanent | Commentaires (0)

25 juillet 2008

Transformer les applications d'entreprise par le web 2.0

Avec tout le brouhaha autour du web 2.0 depuis quelques années, je me suis pencher sur la question de comment le web 2.0 pouvait nous aider à améliorer les applications que nous construisons pour nos entreprises. Il faut l'admettre, en effet, nos applications sont assez "classiques", pour ne pas dire franchement "platte". J'entends par là qu'elle font le travail, mais sans plus.

Parmi les dimensions importantes du web 2.0 on trouve l'aspect social, la contributiion des utilisateurs et l'effet réseau. Or sur ces plans, nos applications font généralement piètre figure, principalement parce qu'elle ne sont pas concues avec ce point de vue.

Par exemple, lorsque nous modélisons les besoins, on considère les cas d'utilisation de chacun des acteurs séparéments. L'acteur A consulte une information XYZ. On ne tient pas compte du fait que Jean consulte XYZ, Marie consulte ABC et Paul consulte MNOP et aussi XYZ. Or le simple fait d'exécuter le cas d'utilisation procure de l'information utile. Par exemple XYZ semble être populaire actuellement, et peut-être qu'il serait pertinent de dire à ceux qui consulte XYZ que MNOP pourrait être intéressant.

Ainsi il m'apparaît que certaines fonctionnalités pourraient être ajouter à nos applications, parfois sans grands efforts.

Voiçi quelques exemples:

- simplification de l'interface utilisateur. On veut souvent mettre toutes les possibilités d'interactions et d'informations sur des écrans qui finissent par être surchargés. Bien que cette caractéristique soit un effet de bord de la méthode de développement (en cascade, juste une chance pour émettre le besoin, alors on ne prend pas de chance, on l'ajoute!), il reste que les applications web 2.0 on souvent des interfaces épurées, simples et concentrées sur une fonction à la fois.

- informer l'utilisateur sur la "fraîcheur" de l'information. Beaucoup de système d'entreprise conservent les dates de création et de modifications des informations, mais peu exploitent cette information. Il est pourtant simple d'afficher une liste des dernières informations modifiées ou créées dans une format simple à lire comme "il y a 1 heure", ou "mis à jour il y 2 semaines". S'il vous plait n'affichez pas la date brut!

- évaluations. Une façon simple de permettre aux utilisateurs de contribuer du contenu est de leur permettre de voter sur un élément d'information. Par exemple, est-ce que l'information est importante? Utile? De qualité? L'évaluation peut être annonyme ou requérir une autentification selon les besoins. L'information ainsi contribuée permettra me mettre de l'avant les informations ayant une meilleure cote par exemple.

- commentaires. Une autre façon de permettre une contribution est d'offrir aux utilisateurs la possibilité d'ajouter un commentaire, lié à une information. Règle générale, lorsque nos systèmes ont un champ commentaire, ceux-çi sont retreint aux utilisateurs "officiels" du système. Pourquoi ne pas ouvrir l'ajout de commentaires à tous? On pourrait pousser plus loin et parler de "revue" de l'information.

- trace des visites. Une application a tout le loisir de garder une trace de ce que les utilisateurs font durant une session. Cette information peu servir a découvrir quels sont les fonctions, les champs et les informations les plus visitées et par conséquent les plus utiles dans le système, par exemple les informations les plus consultées. Ces traces permettent d'établir des patterns dans les données, par exemple "ceux ont consulté XYZ ont aussi consulté ABC". D'un coté cela permet de faciliter la navigation de l'utilisateur et de l'autre de lui faire découvrir des informations qu'il ne connaissait pas.

- touche personnelle. Il est souvent relativement simple d'identifier l'utilisateur, car la plupart des systèmes d'entreprise sont sécurisé et requiert une authentification. Tout les systèmes auxquels j'accède savent que je suis Jean Desbiens, mais peu s'en préoccupe. Sachant que je me reconnecte, pourquoi ne pas me présenter les informations que j'ai créés ou modifiés récemments, pourquoi ne pas se souvenir des recherches que j'ai effectuées. Pourquoi ne pas me montrer les informations que je partage avec mon groupe de travail? Beaucoup de choses peuvent être faites qui font que je me sente supporté personnellement par l'application plutôt que de façon anonyme.

- liste en format RSS. La plupart des applications web permettent de sauvegarder les listes affichées sous un format Excel ou CSV, pourquoi ne pas ajouter le format RSS? Ce n'est pas plus difficile et en plus ça peut facilement être consommé par d'autres applications! C'est probablement la façon la plus simple de permetttre à une tierce application de souscrire aux informations de l'application et de permettre les mashups.

- recherche en format RSS. Une fois les listes de l'applications disponibles en format RSS, pourquoi ne pas permettre d'interroger l'application dans le même format. Il s'agit simplement de permettre à la fonction de recherche de recevoir ses paramètres par un URL simple et de retourner un fichier RSS ou un autre microformat, ou carrément un XML.

- édition ouverte. Nos applications sont souvent très sécurisées, limitées a un groupe d'utilisateur restreint et la publication de l'information passe même parfois par un flux de travail (workflow) complexe d'approbation. Peut-être est-il temps de voir quel effet aurait une ouverture plus large aux utilisateurs, sur le modèle de wikipedia. A bas les approbations! Responsabilisons les utilisateurs! (Ca ne veux pas dire qu'on ne garde pas de trace des modifications ou qu'il n'y a pas un processus de modération).

- API, Application Programming Interface. La plupart de nos systèmes sont conçu principalement en fonction des besoins des utilisateurs (interactif) et des liens avec d'autres systèmes planifiés lors de l'élaboration des besoins. Ceci fait que les systèmes sont souvent fortement couplés et que ces interfaces sont très "privé". Un premier pas vers les architectures de services est de concevoir les systèmes comme une portion "présentation" et une portion "services" en gardant le couplage entre les deux au minimum. Et publiez cette interface de services ou API afin que d'autres puissent utiliser les informations de l'applications de nouvelles façons, qui apporterons de la valeur à l'entreprise.

Voilà quelques idées pour introduire un peu de web 2.0 dans vous applications.

29 mai 2008

Présentation de la mêlée quotidienne au Groupe Agile Montreal

Hier soir j'ai présenté la technique de la mêlée quotidienne (standup meeting ou daily crum) à une vingtaine de membres du Groupe Agile de Montreal

Ma présentation en format PowerPoint est basé sur un article sous forme de pattern que j'ai écrit. Vous pourrez aussi vous référer à l'article de Jason Yip, que je considère le meilleur article sur le standup meeting. Mike Coan a aussi un article sur les smells reliés au daily scrum.

Merci à tous les participants, vos commentaires ont rendu la présentation plus intéressante, j'en suis certain. J'ai d'ailleurs incorpore quelques modifications à la présentation.

03 mai 2008

Automatisation des tests WPF

www.thoughtworks.com a un nouveau framework de test, nommé White, qui permet d'automatiser les tests fonctionnels via l'interface des applications WPF (XBAP).

Nous allons y jeter un coup d'oeil car notre première recherche ne s'était pas avérée fructueuse (voir http://agile.blogspirit.com/archive/2007/10/05/tests-dans...). En espérant que ce nouveau framework sera intéressant. Ca devrait être le cas, car généralement thoughtworks produit des choses intéressantes. Je pense par exemple à Selenium pour les tests web.