Pyxis

Cette semaine j’ai suivi une formation sur la gestion du temps « Mission Control » de la firme Aspectus. À force d’écouter la présentatrice, je faisais de plus en plus de liens avec SCRUM. Je vous explique. Un point sur lequel j’ai beaucoup accroché, c’est la proposition de voir, nos journées comme des accomplissements plutôt qu’une série de tâches! Nous travaillions tous les jours comme si nous étions des machines à « cruncher » des tâches! Dans SCRUM pour que l’équipe comprenne bien le pourquoi de faire quelques choses nous écrivons des histoires utilisateurs « user stories ». La façon de faire est de faire ressortir la valeur d’affaire livrée par la « stories ». Exemple : Afin de pouvoir m’inscrire à une formation, en tant que participant je veux avoir accès à un site web pour procéder à l’inscription. Dans notre calendrier de tous les jours nous inscrivons : Produire rapport de vente, rencontrer Bob, terminer Module X. Pourquoi ne pas faire comme les histoires utilisateurs et plutôt parler de l’accomplissement au lieu de la tâche. Nous pourrons ainsi partir le soir et être fiers de notre journée plutôt que de se dire que je n’ai pas été en mesure de faire telle et telle tâche! Voici un exemple : Aujourd’hui j’ai accompli le plan d’affaires, j’ai accompli la mise en place campus Pyxis, etc. Beaucoup plus intéressant non ? À l’avenir je vais essayer de mettre dans mon calendrier les accomplissements que je veux faire au lieu des tâches! Dans mon prochain blog je vous expliquerai autres liens que j’ai faits entre la formation et SCRUM!

Il y a des défis et des questions qui nous sont souvent posées. Peu importe si votre service se rapporte du côté “affaires” ou du côté “technologie” au sein de votre organisation, vous faites probablement face à certains de ces défis vous-mêmes et vous n’êtes pas sûr de ce qu’il faut faire. Si les afirmations qui suivent vous semblent familières, je vous invite à poursuivre votre lecture.

• Mon équipe manque constamment ses délais de livraison.
• L’équipe de projet dépasse constamment son budget d’opérations.
• Les livrables de mon équipe de projet ne rencontrent pas les besoins des utilisateurs.
• Les utilisateurs ne savent pas ce qu’ils veulent.
• Les besoins évoluent constamment et ceci impact notre plan projet.
• L’équipe de projet développe des composants logiciels qui ne semblent pas avoir de valeur pour l’entreprise et elle semble produire plus de papier que logiciel.
• Mon équipe développe des logiciels qui ne correspondent pas au besoin de mes utilisateurs.
• L’équipe de projet trouve habituellement des problèmes dans le processus de développement avec beaucoup de retard.
• L’équipe de projet n’a pas les compétences requises.
• L’équipe de projet est fatigué, personne ne s’amuse et nous avons perdu plusieurs bonnes ressources.
• J’ai besoin d’attendre longtemps avant que l’équipe de projet me fournisse l’information dont j’ai besoin.
• Nous savons que nous avons des problèmes mais nous ne savons pas par où commencer.
• Nous avons besoin d’externaliser ou d’impartir nos activités de développement logiciels afin de réduire nos coûts d’exploitation.
• L’équipe de projet livre du logiciel de mauvaise qualité.
• Nous avons commencé à utiliser Agile pour un petit projet et notre équipe de direction souhaite que toute l’organisation passe à l’agilité.

Les principes Agiles peuvent s’appliquer à votre projet d’entrepôt de données et d’intelligence d’affaires, mais il est essentiel de déterminer a priori quels problèmes vous tentez de résoudre afin d’appliquer la bonne solution. Nous vous présentons une liste de questions fréquemment demandées et vous offrons des solutions possibles pour chacune d’elles.

Défi: Mon équipe manque constamment ses délais de livraison.

Solution: L’utilisation de l’approche de gestion de projet Scrum pourrait vous aider à anticiper les retards et à adresser ceux-ci en temps opportun. De plus, l’utilisation fréquente de communication face-à-face plutôt que les communications par l’intermédiaire d’un plan de projet augmentera sensiblement la productivité de votre équipe, la performance de membres de l’équipe de projet et le respect des échéanciers tel que définis.

Défi: L’équipe de projet dépasse constamment son budget d’opérations.

Solution: La situation pourrait être pire que vous ne le pensez puisqu’une partie de votre budget peut-être dépensée inutilement en développant des fonctionalités qui ne seront pas utilisées. L’approche traditionnelle qui favorise une planification à long terme se traduit souvent par des écarts élevés entre le budget estimé et les coûts réels alors que l’utilisation d’une approche de livraison des logiciels par courtes itérations (jusqu’à 4 semaines) vous permettra de mieux contrôler vos coûts tout en vous assurant d’atteindre les résultats escomptés.

Défi: Les livrables de mon équipe de projet ne rencontrent pas les besoins des utilisateurs.

Solution: Cela pourrait cacher deux problèmes différents soit les exigences ne sont pas bien définies par les utilisateurs ou les exigences ne sont pas bien comprises par l’équipe de projet. Dans les deux cas, une étroite collaboration entre les utilisateurs et l’équipe de développement permettrait d’accroître sensiblement les chances de livrer le bon logiciel. De plus, la situation pourrait être renversée en mettant en œuvre les processus qui permettent de recevoir les demandes de changements au cours de la phase de développement et ainsi de s’adapter à l’évolution des besoins de l’entreprise.

Défi: Les utilisateurs ne savent pas ce qu’ils veulent.

Solution: Ce n’est pas forcément un problème avec vos utilisateurs. Avec l’utilisation d’une approche développement traditionnelle, les utilisateurs sont typiquement rencontrés au début du projet pour exprimer besoins et éventuellement ne voient les résultats que plusieurs mois ou années plus tard lorsque le logiciel final est livré. Avec une approche Agile, les utilisateurs sont invités à définir leurs besoins à court terme (pour les 4 prochaines semaines) au lieu de définir l’ensemble de leurs besoins pour le projet en entier ce qui permet à l’équipe de projet de mieux comprendre les besoins réels et de rencontrer les objectifs fixés.

Défi: Les besoins évoluent constamment et ceci impact notre plan projet.

Solution: En effet, si vous utilisez une méthode traditionnelle de développement de logiciels, il est difficile de vous adapter aux demandes de changements résultant de l’évolution de la dynamique de votre secteur d’activités. Avec une approche Agile, votre équipe ne sera pas seulement en mesure d’apprendre à faire face aux demandes de changements mais elle sera même receptive aux changements et sera en mesure de s’y adapter.

Défi: L’équipe de projet développe des composants logiciels qui ne semblent pas avoir de valeur pour l’entreprise et elle semble produire plus de papier que logiciel.

Solution: Pourquoi en est-ce ainsi? Le but de votre équipe de développement devrait être de livrer de la valeur à l’organisation, soit du logiciel. Si, une grande partie du temps, de l’effort et des énergies de votre équipe de développement sont consacrés à travailler sur des documents (plans de projet, exigences, architecture, modèles, etc.) au lieu de travailler sur la livraison de logiciels, vous avez probablement besoin de reconsidérer la démarche de développement logiciel que vous utilisez. L’utilisation d’une approche pragmatique et réaliste, comme agile pour votre processus de développement logiciel traitera les problèmes les plus graves généralement rencontrées par votre équipe de développement et accroîtra votre retour sur investissement.

Défi: Mon équipe développe des logiciels qui ne correspondent pas au besoin de mes utilisateurs.

Solution: Satisfaire les besoins de vos utilisateurs est essentiel pour une équipe de développement logiciel agile et l’application de pratiques bien définies aidera énormément. L’intégration des utilisateurs dans le cadre des activités de l’équipe de développement est une excellente façon pour les utilisateurs d’exprimer leurs besoins et ceux-ci seront beaucoup mieux compris et pris en compte.

Défi: L’équipe de projet trouve habituellement des problèmes dans le processus de développement avec beaucoup de retard.

Solution: Il est fréquemment reconnu que plus les problèmes sont trouvés tards dans le cycle de développement, plus ils deviennent coûteux à corriger. Sur la base de cette conclusion, la mise en œuvre d’une approche de développement Agile de logiciels forces l’équipe à présenter fréquemment les résultats de leur travail à leurs utilisateurs afin de démontrer la qualité du logiciel avant que les coûts continuent d’augmenter.

Défi: L’équipe de projet n’a pas les compétences requises.

Solution: Bien que ce soit possible, il est peu probable que vos ressources ne soient pas qualifiées pour votre projet. Votre équipe a peut-être besoin d’accompagnement autour de certaines pratiques de génie logiciel. Les membres de l’équipe pourront ainsi améliorer leurs compétences de développement et rencontrer vos exigences.

Défi: L’équipe de projet est fatiguée, personne ne s’amuse et nous avons perdu plusieurs bonnes ressources.

Solution: Il a souvent été démontré que des employés motivés fournissent de meilleurs résultats. Si vous souhaitez que votre projet et votre équipe réussissent, créer un environnement où les gens peuvent apprendre et sentent qu’ils contribuent à la réussite de l’organisation.

Défi: J’ai besoin d’attendre longtemps avant que l’équipe de projet me fournisse l’information dont j’ai besoin.

Solution: Vous utilisez probablement une approche traditionnelle en cascade où l’équipe de développement demande les exigences des utilisateurs, débute le développement et teste ensuite les requêtes et les rapports et une fois que l’équipe de développement se sent à l’aise avec les résultats, ceux-ci sont finalement présentés aux utilisateurs. En incluant les utilisateurs au sein de l’équipe de projet et en favorisant l’utilisation d’un cycle de développement incrémental, vous pouvez voir progresser rapidement vos demandes et pouver ainsi influencer la quantité de détails requis.

Défi: Nous savons que nous avons des problèmes mais nous ne savons pas par où commencer.

Solution: Un diagnostic vous permettrait d’identifier rapidement vos opportunités d’amélioration. De plus, il a été démontré qu’une approche flexible permet d’améliorer les communications au sein de l’équipe de développement et avec les utilisateurs permettant ainsi d’identifier clairement et rapidement les situations problématiques à régler.

Défi: Nous avons besoin d’externaliser ou d’impartir nos activités de développement logiciels afin de réduire nos coûts d’exploitation.

Pas nécessairement, une meilleure approche de développement logiciel peut vous aider à réduire vos coûts. Le Standish Group Study (Rapporté au XP2002 par Jim Johnson) a montré que jusqu’à 64% des fonctionnalités logicielles ne sont jamais utilisées. Ainsi, l’utilisation d’une approche agile pour développer vos logiciels réduira immédiatement vos coûts globaux de développement.

Défi: L’équipe de projet livre du logiciel de mauvaise qualité.

Solution: En plus de modifier votre façon de développer des logiciels, il serait avantageux d’utiliser de courts cycles de développement et la démonstration fréquente des résultats afin de gagner en visibilité sur le logiciel et régler les problèmes en temps opportun. Vous pourriez décider d’utiliser le développement généré par les essais (test-driven development ou TDD) ou la programmation en binôme pour de meilleurs résultats.

Défi: Nous avons commencé à utiliser Agile pour un petit projet et notre équipe de direction souhaite que toute l’organisation passe à l’agilité.

Solution: Merveilleux. Maintenant que vous avez pu constater les avantages de l’agilité dans votre organisation il serait pertinent que vous obteniez de l’accompagement et des conseils pour vous aider à déployer la nouvelle approche dans le reste de votre organisation. Nous pouvons vous aider.

I’ve long been convinced that the best way to choose between the different languages is to consider their respective communities, and this article definitely confirms my perception.

Relying on the technical merits of whatever platform is mostly religion. However, considering the surrounding community and environment totally makes sense. If you pick PHP as a language, no matter what you think of it from a technical point of view, you’re going to have to deal with (or even hire) PHP developers, who have been deeply affected by the hacker syndrome. If you pick the .NET platform, you’re going to work with religious people who do not consider anything which is not an official Microsoft BestPractice. If you pick the Java platform, you’re going to deal with framework-ill people who focus more on the infrastructure than the target application. and so on….
Everything is about choice!  So, just consider this when you start your next project, I feel like it’s as important as other technical considerations..

Vous pouvez maintenant suivre nos activités sur Twitter à l’adresse twitter.com/pyxistech. Vous y trouverez des événements où venir nous rencontrer, l’ajout de nouvelles dates de cours à notre calendrier de cours des annonces à propos de nos produits et autres tweets sur des sujets d’intérêt pour Pyxis.

Je suis en mandat avec une équipe de développement qui ne peut d’emblée adopter toutes les pratiques de Scrum. Le domaine d’affaire de l’application est si complexe qu’il est difficile pour le PO de présenter à l’équipe l’équivalent de quelques semaines de travail. Pour le moment, nous avons décidé de contourner le problème sans se priver des valeurs d’amélioration et de collaboration de l’Agilité en adoptant la méthode Kanban. Isabelle Therrien m’a référé un très bon article de Henrik Kniberg à propos du Kanban versus Scrum. C’est la meilleure vulgarisation de la méthode que j’ai lu à ce jour. Contrairement à d’autres articles, il explique bien le Kanban comme une méthode Agile à part entière, et pas seulement une adaptation de Scrum.

L’article explique notamment que: – Scrum est dirigé par l’engagement et les boîtes de temps alors que le Kanban est dirigé par un flux tendu et le périmètre. – Kanban permet la ré-introduction de spécialités impossibles à diffuser au sein d’une équipe pluri-disciplinaire – Kanban permet au PO de planifier les items à développer à l’unité alors que Scrum permet la planification d’items en lot

Attention! Kanban est moins restrictif que le Scrum. Il faut prendre garde de respecter l’esprit Agile.

Avez-vous des mises en garde ou des opinions à propos de Kanban?

Dans son article “Nous avons trop de temps et un surplus de budget pour compléter notre projet d’intelligence d’affaires“, Martin pose une question peu abordée dans la communauté Agile : Pourquoi choisir une approche Agile ? Quels sont les apports de cette approche pour votre organisation ?

Martin liste les avantages d’une démarche Agile et les pratiques qui adressent chacun des objectifs recherchés. Il aborde en particulier les projets en Intelligence d’Affaires (BI), mais les points qu’il apporte sont valables quelque soit le type de vos projets.

Un très bon article !

OpenDo est une initiative récente pour constituer un framework collaboratif et OpenSource dans le but de développer du logiciel critique certifié. L’initiative OpenDo bouleverse les approches traditionnelles en place.

Read more…

Si vous êtes d’accord avec le titre de ce message, vous n’avez pas besoin de lire la suite, votre project en intelligence d’affaires (BI) sera parmi les très rares (moins de 40%) qui ne se terminera pas par un abandon ou par un échec ou vous n’avez pas à vous soucier que votre projet va complètement vider votre budget avant de lentement et progressivement échouer.

Pour tous les autres, cet article présente les avantages de l’utilisation d’une approche Agile pour votre projet en intelligence d’affaires. Ce message fait suite à mon précédent article intitulé Personne n’est intéressé par l’agilité, où je me suis demandé pourquoi si peu d’articles explique les avantages réels derrière Agile.

Pourquoi les organisations devraient-elles utiliser une approche Agile pour leur projet en intelligence d’affaires?

Suite au récent lancement de notre pratique conseil en intelligence d’affaires agile, nous devons fréquemment répondre à cette question. En termes clairs, en utilisant une approche agile pour le développement de votre solution de BI vous augmenterez grandement votre retour sur investissement (ROI). Avant de lire plus loin, vous devez garder à l’esprit que Agile ne peut répondre à toutes vos pré-occupations liées au développement de logiciels, mais en utilisant une approche pragmatique et réaliste pour votre processus de développement logiciel, la mise en œuvre des principes Agile au sein de votre organisation adressera les problèmes les plus graves généralement rencontrés par un projet de développement de logiciel.

Le but de ce post n’est pas de décrire les principes agiles ni d’expliquer la pratique qui devrait être appliquée dans un contexte spécifique, mais d’expliquer en termes clairs les avantages qui découlent de ces pratiques.

Augmentation de la productivité

La performance de votre équipe de développement sera beaucoup plus élevée après l’implantation des méthodes agiles.

• Simplification et amélioration des communications;
• L’amélioration continue des performances par retrospection à la fin de chaque itération;
• Les progrès ne sont pas mesurés d’après la conformité au plan de projet mais par la livraison de composantes de qualité;
• La gestion de projet est partagée par tous les membres de l’équipe auto-gérée;
• Utilisation de pratiques innovatrices en génie logiciel améliore grandement la qualité;
• Augmentation de la capacité d’estimer les efforts et les délais;
• Productivité peut être évaluée et surveillée ce qui donne un rythme prévisible.

Rencontrer les échéanciers

Les échéanciers sont généralement très critiques et en tant que telle la mise en œuvre d’une approche Agile aide les équipe à rencontrer les échéanciers fixés.

• Réduit l’ensemble du projet en petits morceaux afin de maintenir de court cycle de livraison;
• Rendre les progrès de l’équipe visibles pour tout le monde avec l’utilisation de rapports définis;
• La démonstration du travail accompli à la fin de chaque itération;
• L’estimation et la planification est un processus partagé entre le client et l’équipe du projet;
• Livraison fréquente permet de réduire les frais associés à la mise en production;
• Les utilisateurs finaux sont impliqués dans la définition des échéanciers plutôt que de laisser l’activité à l’équipe de développement.

Augmentation de la qualité

La qualité n’est pas négociable et l’application de l’agilité est bénéfique à l’équipe du projet.

• L’équipe démontre le travail accoompli à la fin de chaque itération;
• La résolution des composants défectueux dès leur détection;
• Les tests ne sont pas seulement exécutés à la fin du projet lorsque le coût de réparation est beaucoup plus grand;
• Tests sont écrits avant le développement et doivent être exécutés de façon continue pendant toute la durée du projet au lieu d’attendre à la fin.

Rencontre des attentes

Beaucoup de projets sont livrés sans répondre aux attentes du client. L’utilisation d’une approche Agile aide à rencontrer les exigences.

• Le client fait partie de l’équipe de projet, il définit les priorités et évalue les résultats finaux;
• Obtenir une rétroaction continue tout au long du cycle de développement et pas seulement à la fin;
• Livraison des exigences initiales, mais s’il y a demande de changements, l’équipe créera des opportunités pour répondre à l’évolution des besoins;
• L’analyse et la conception se fait au début de chaque itération, et non pas seulement au début du projet;
• Le logiciel doit répondre aux besoins actuels et non seulement aux besoins qui ont été définis à l’origine du projet.

Livraison de valeur pour l’organisation

Tel que mentionné, les outils et les processus Agile se concentrent sur la livraison de valeur pour l’organisation.

• Les équipes de travail mettent l’accent sur les tâches à valeur ajoutée;
• Équipe livre la valeur la plus élevée en premier et évite de construire des composants qui ne seront jamais utilisés par le client;
• Focus sur les résultats (par opposition au processus ou au plan de projet);
• Boîtes de temps définies afin de veiller au respect des lignes de temps définies;
• Les coûts et les avantages peuvent être associés directement au logiciel livré;
• Réduit ou élimine les activités non-critiques;
• Soulever les obstacles au début du processus ce qui permet de réduire le coût de réparation.

Améliore le partage des connaissances

Comme Agile repose sur le concept de l’équipe, par opposition à l’individu, le partage des connaissances est un avantage direct.

• Empêche le fait qu’un seul individu soit le goulot d’étranglement du projet en mettant l’accent sur le partage de l’information et des tâches entre les membres de l’équipe.

Accroître la satisfaction des employés

Bien qu’elle ne soit pas souvent mentionnée, la satisfaction des employés est un avantage important de la mise en œuvre Agile.

• Relations entre l’équipe de projet et le client améliore la confiance et le partage des connaissances tout au long de la durée du projet;
• L’équipe d’auto-gérée et l’autonomie améliorent le moral des membres de l’équipe;
• Par l’inspection et l’adaptation de leurs processus de travail, les membres de l’équipe développent de nouvelles compétences;
• Compte tenu de la possibilité de jouer divers rôles, les individus augmentent leur satisfaction par le développement de nouvelles compétences.

Comme je l’ai mentionné dans mon précédent post, il y avait très peu d’articles qui expliquent les avantages (le pourquoi) de la mise en œuvre d’une approche Agile pour les projets de développement. J’espère que cet article vous aidera à promouvoir l’agilité dans votre organisation.

RESTful error handling gives a nice overview of the miscellaneous ways of handling errors in a RESTful web application. To me, the following criteria need to be met to provide decent REST error handling :

• Be simple to implement (or at least, be simple for simple cases)
• Be machine-parseable (so that intelligent REST clients can be built)
• Be human-readable (so you don’t have to fire up your HTTP sniffer to understand what went wront, when you’re developping a client)
• Follows HTTP semantics, so proxies, caching, etc continues to work correctly

None of the ideas suggested in the article match all of my criteria, so here is the solution I would suggest :

• ALWAYS return the most appropriate HTTP error code whenever an application error happens. Sure, it might not map perfectly, but choose the one that expresses the concept correctly. It is totally absurd to always use 200 error codes, even the SOAP guys have not made that mistake ! Also make sure to use a server-side REST framework that will automatically handle common errors for you (405 for unsupported methods, etc..)
• When the same HTTP error code maps to several application errors, add an ADDITIONAL X-Application-Error-Code : header that provides a simple string allowing to remove ambiguity (choose a simple all-ASCII exception name). This will allow creating simple clients that can easily parse exceptions without too much burden for simple cases
• Add a body that allows a human being (for instance, the developer of a REST client for your service) to instantly understand what went wrong. This can take the form of either a free-form response, or a fully-parseable (XML, JSON, whatever) response body that contains a message field.
• Only implement the fully-parseable response body when your application has matured. Do it smartly, avoid working weeks on your service before even displaying the first feature to your user

on the smallest possible conditions talks about abstracting conditions behind meaninful method names. Now, let’s say we want to go a step further, and want to reuse the same condition in different parts of the project….

I wish I would explain my super-great-idea about achieving this goal, but as usual, Martin Fowler & Eric Evans have thought about it before me, so here’s just the link to the wonderful pattern called Specification.  You could also buy the Domain Driven Design book, as Evans speaks about it in his book.