atome unique

La performance en développement logiciel, une question de métriques

L’évaluation de la performance d’une équipe de développement logiciel dans le cadre d’un projet de développement logiciel peut varier grandement selon le type de métriques utilisées aux fins de l’évaluation.

Cette requête de mesure de la performance au niveau des projets de développement revient constamment et constitue une source de préoccupation majeure chez les Gestionnaires; ce qui est tout à fait normal considérant le faible ratio de projets livrés dans les temps et les coûts.

(suite…)

gestion et performance

La perception de la performance en développement logiciel selon le style de gestion

La perception de la performance en développement logiciel varie selon le style de gestion; il faut le souligner, la mesure de la performance est vraiment une question de perception. L’évaluation de la performance d’une équipe de développement est en fait étroitement liée au style de gestion et aux priorités que celui-ci dicte; en développement logiciel comme dans toute autre activité d’ailleurs.

Tout gestionnaire souhaiterait avoir une évaluation objective de son équipe de développement et de son département TI dans le cadre d’un projet de développement logiciel. Le terme « objectif » est la clé de l’énigme ici. Existe-t-il une méthode objective d’évaluation de la performance d’un développeur, d’une équipe de développement, d’une entreprise de développement logiciel ? Existe-t-il un indicateur clé de performance en développement logiciel, qui dit la vérité ?

En fait, on ne compte plus les systèmes, méthodes et nomenclatures qui ont été développées depuis le début de l’ère industrielle afin d’évaluer la performance en développement logiciel comme ailleurs.

(suite…)

Développement logiciel Lean en 2017 ou Régime-Santé TI

Le Développement logiciel Lean est l’extension des principes Lean au Développement et à la Gestion de Produits et Services TI; plus particulièrement, on voudra éliminer tout travail qui n’apporte pas de valeur audit produit ou service TI.[1]

Lean Six Sigma est une méthodologie qui s’appuie sur un effort collaboratif d’équipe pour améliorer la performance en éradiquant de façon systématique le gaspillage (pertes )[1]et ce, sur huit plans : Transport, Inventaire, Mouvement, Attente, Surproduction, Sur-processus, Défectuosités et Talents (abréviation : ‘TIMWOODS’).

On ne saurait sous-estimer le rôle de plus en plus crucial de la fonction TI dans un contexte eBusiness et eCommerce où livrer de la qualité et de la valeur aux consommateurs est devenue la principale activité des entreprises. Les services et produits TI permettent souvent aux consommateurs de découvrir, commander et payer ainsi qu’aux employés et fournisseurs de communiquer, collaborer, gérer et exécuter / produire, etc.

(suite…)

La vraie nature du développement sur mesure en TI

Lorsqu’Analystik aborde un nouveau mandat de développement avec un client; l’objectif en est presque toujours d’automatiser un processus d’affaire et la méthodologie en est somme toute fort simple :

  • Analyse du processus existant
  • Étude des améliorations possibles au processus lui-même
  • Élaboration / schématisation d’une solution logicielle qui automatise le processus
  • Intégration aux technologies et processus connexes
  • Implantation

 

 

(suite…)

Analystik – 25 ans déjà et pourtant… toujours la même valeur

L’histoire d’Analystik ressemble sûrement à celle de milliers d’autres entreprises. Trois copains d’universités décident de partir en affaires avec l’insouciance de la jeunesse en tête et la passion au cœur.  Pour nous, c’était la passion de l’informatique et notre entreprise fut une firme de services-conseils TI, ce qui signifiait en fait « intégration et développement logiciel »; et bien sûr, nous étions convaincu de développer les meilleures applications au monde pour nos clients. Le passé n’est jamais garant de l’avenir mais…

Il y a tout de même des leçons à tirer du passage du temps; en ce sens, que si vous survivez, c’est que vous devez faire quelque chose de bien.  Et pour Analystik, la recette fut assez simple : nos valeurs.  Je sais, je sais, vous me direz : « Michel, ça fait très cliché »; et vous avez raison mais que dire, c’est tout simplement la vérité !

(suite…)

Projets TI : objectifs, portée, ressources, budgets, délais, livrables, etc.

L’augmentation de la productivité, la capitalisation sur l’avantage concurrentiel. Les réponses aux nouveaux besoins d’affaires passent souvent par les TI, ou peut-être devrais-je dire, un projet TIC, non ?

La traduction de ces modifications ou ajouts dans les systèmes de l’entreprise se fera à l’interne ou à l’externe. Mais, dans les deux cas, on rencontre encore bien souvent deux problèmes de base :

  • La portée des objectifs (et donc du projet) est mal définie et l’impact des modifications encourues est imprévisible
  • Le budget est mal attribué et parfois aussi, carrément irréaliste ou fortement sous-estimé

Ces deux facteurs sont responsables de la mauvaise tournure de la très grande majorité des projets informatiques. Ils dépassent les budgets et échéances ou encore n’atteignent pas leurs objectifs, quand ce n’est pas les deux; ces deux cas de figure sont le lot de 83% des projets informatiques selon les dernières études des références en la matière : Gartner, IDC, Forrester, etc.

 

Projets TIC… tac…

(suite…)

La Gestion des Attentes Client : réflexions d’un entrepreneur TI (14)

On ne compte plus le nombre de projets TI qui se sont soldés par un échec relatif : échec sur le plan des budgets et / ou des échéances, cela est assez commun au point où cela semble être presque perçu comme normal aujourd’hui, même si ça ne devrait pas être le cas.  Ce dont on parle moins souvent toutefois, c’est des échecs sur le plan des attentes du Client.

La raison en est fort simple; lorsqu‘il y a divergence sur ce plan entre le Client et le développeur TI, le processus de développement logiciel amène presque toujours les deux parties à conclure que des besoins nouveaux sont apparus en cours de projet ou que des besoins initiaux n’ont tout simplement pas été identifiés à l’origine du projet.

Ces deux hypothèses de travail couvrent une large partie des cas. Mais, pas tous, et la réalité est parfois toute autre et aussi toute simple !

(suite…)

Réflexions d’un entrepreneur TI (6) : variations du coût de développement d’une application

C’est la question à cent mille balles, comme disent nos amis Français : combien cela coûtera-t-il à développer cette application ?   Malheureusement, la réponse n’est jamais simple et jamais unique car il y a mille et un facteurs qui en feront varier le coût de développement… dont la méthodologie de travail et la notoriété de l’entreprise soumissionnaire ne sont pas les moindres !

Le client saisit-il bien toutes les subtilités et les implications sur le plan du développement logiciel de ses objectifs d’affaires ?  Veut-il une couche importante d’Intelligence d’Affaires ?  Quelle est la nature et l’état de son environnement TI actuel ?  Y a-t-il conflit en perspective ou incompatibilité entre l’application souhaitée et les systèmes / applications en place ?  Faudra-t-il développer d’autres applications ou mettre en place d’autres systèmes afin d’arrimer cette application ?   Dans quelle mesure, cette application est-elle critique à l’atteinte des objectifs d’affaires  de l’entreprise du client et si c’est le cas, devrons-nous remplacer certains systèmes en place ou en implanter d’autres ?  Devrons-nous optimiser certains processus des applications en place afin d’harmoniser l’interaction avec l’application développée ?  Quelle méthodologie le développeur utilisera-t-il ?  Quelle est l’architecture retenue ?

S’agit-il d’un billet sur la Gestion de Projets ?  Loin de là.  Et Dieu sait que la gestion de Projets a fait couler beaucoup d’encre en TI depuis une décennie et que cela mériterait toute une série de billets en soi… que nous ferons peut-être en 2010.  Mais pour les besoins de ce billet, nous prendrons pour acquis que tous les développeurs appliquent de bonne pratique en matière de Gestion de Projets.

(suite…)