Sécurité et Agilité en entreprise : contraintes et solutions

Mesures de Sécurité et Agilité entreprise ne font habituellement pas bon ménage. Aussi, il ne faut pas sous-estimer l’impact de la sécurité et de la conformité sur l’Agilité dans le contexte technologique actuel qui appelle de nombreuses entreprises à prendre de telles mesures afin d’assurer l’intégrité de leurs opérations et préserver la confidentialité de leurs données. 

Peu importe le nombre de développeurs dans votre organisation, il est possible de faire du développement logiciel en mode Agile. Des centaines d’écrits vantent les mérites de cette méthodologie de développement; à titre de rappel, en voici les points les plus importants :

  1.       Meilleure adéquation entre les livrables et les besoins ;
  2.       Minimiser le risque de dérapage en découpant le projet en « sprints » et ces derniers en « tâches » de courte durée ;
  3.       Meilleure communication entre les divers intervenants du projet ;
  4.       Emphase mise sur l’identification et la catégorisation des fonctionnalités qui auront le plus de valeur ajoutée pour l’organisation ;
  5.       Dans la trilogie « coût, temps, fonctionnalité », le défi consiste à développer le plus de fonctionnalités parmi les plus importantes dans le temps alloué, quitte à retirer des fonctionnalités, contrairement au mode Waterfall qui met l’emphase sur les fonctionnalités, toutes les fonctionnalités, quitte à dépasser dans le temps.

 

gestion par valeur vs gestion par plan

(suite…)

Les 4 plans de la Transformation Agile

On ne compte plus le nombre d’entreprises qui ont entamé leur Transformation Agile ces dernières années. Avec force raison car plus personne ne remettrait en question aujourd’hui les bénéfices de la Méthode Agile; il s’agit là d’une évidence qui fait l’unanimité dans tous les secteurs d’activités.

En effet, le lien direct entre Agilité et profitabilité fait en sorte que tous les gestionnaires veulent aujourd’hui en appliquer les principes à leur organisation mais il y a parfois loin de la coupe aux lèvres !

Ainsi, contrairement, à ce que l’on pourrait croire, n’est pas Agile qui veut !

Ce ne sont pas toutes les organisations qui sont prêtes à l’Agilité en entreprise considérant que cela implique de conférer plus d’autonomie aux unités d’affaires et aux équipes de travail, équipes de travail inter-fonctionnelles, cela va sans dire. Cela étant dit, ce ne sont donc pas nécessairement tous les dirigeants d’entreprise qui vont accueillir l’Agilité à bras ouverts.

Ainsi, plus que des processus, la méthode Agile appelle à une philosophie de travail qui englobe le personnel et la structure de l’organisation.

L’Agilité en Entreprise appelle à une transformation en profondeur de l’organisation. Cette transformation exhaustive touchera toutes les facettes de l’Organisation y incluant le Personnel, la Structure organisationnelle, la Stratégie et la Technologie. C’est là la voie d’une Transformation Agile réussie.

(suite…)

Pourquoi intégrer l’Agilité en entreprise ?

Qu’est-ce que la méthodologie Agile ?  Pourquoi intégrer l’Agilité à son entreprise et devenir une entreprise Agile, quels sont les bénéfices de l’Agilité pour l’entreprise ?

Fruit d’une recherche d’amélioration continue du processus de développement logiciel, la méthodologie Agile est apparue à l’avant-scène des TIC à la fin des années 90 en réaction aux excès des grands projets de développement logiciel en termes d’échéancier, de budget et de qualité des livrables.

Et cette recherche d’amélioration continue du développement logiciel s’appuie en fait sur la recherche de valeur ajoutée pour l’entreprise (portée du projet) et l’optimisation de la performance des équipes de développement logiciel dans un échéancier et des coûts fixes tel qu’illustré dans le diagramme ci-dessous :

gestion par valeur vs gestion par plan

(suite…)

croix

Le Développement logiciel sur mesure est mort. Vive le développement logiciel sur mesure.

Deux faits marquants jouent contre le développement logiciel sur mesure :

  • Le marché regorge de solutions logicielles exhaustives tels Oracle, SAP, IBM, Salesforce, etc.
  • Les histoires d’horreurs pleuvent du côté des grands projets de développement logiciel

Considérant ces faits, au fil des ans les entreprises ont choisi d’installer des solutions commerciales, CRM, ERP, logiciel comptable, système de gestion des prêts, etc., plutôt que d’opter pour un développement logiciel sur mesure.  Et dans plusieurs cas, elles ont remplacé une application « maison » dont la technologie était obsolète.

Évidemment, beaucoup de temps et d’efforts ont été investi pour adapter ces solutions commerciales à « votre » réalité pour en faire des solutions sur mesure répondant à vos besoins.  Si vous rencontrez une des deux situations ci-dessous, rassurez-vous, vous n’êtes pas la seule entreprise dans cette situation :

  • Vous possédez différents systèmes qui ne se « parlent » pas
  • Vous avez encore et toujours des besoins d’affaires précis qui ne sont pas comblés par les solutions commerciales

(suite…)

Bootcamp .Net à Montréal

Trouver de nouveaux développeurs a toujours été un grand défi pour les entreprises technologiques. Il n’y a pas beaucoup de développeurs qui cherchent un emploi au moment où votre entreprise cherche une nouvelle recrue. De plus, de ce petit nombre de développeurs, seulement certains ont des connaissances ou de l’expérience avec les technologies que vous utilisez dans vos projets. Beaucoup d’étudiants et de diplômés cherchent à se rendre rapidement sur le marché du travail et à commencer une nouvelle carrière. Les étudiants regardent du côté des bootcamps pour rapidement obtenir la formation nécessaire ainsi qu’un peu d’expérience. Il n’y a que quelques bootcamps à Montréal et ils dispensent un nombre limité de technologies. Vous serez déçu de constater qu’il n’existe pas de bootcamp pour les technologies .Net de Microsoft.

(suite…)

Meilleures pratiques de sauvegarde de documentation d’un projet TI

Il y a de bonnes et de meilleures pratiques de sauvegarde de documentation d’un projet TI; en TI comme en toute chose.

Dans les deux premiers billets de cette série sur la documentation d’un projet de développement TI, nous avons traité du « quoi » ou de ce qu’il faut documenter et du « comment » ou, si vous préférez, du format que l’on devrait utiliser.

Dans ce billet, nous ne traiterons pas du « pourquoi » mais bien du « où » sauvegarder la documentation d’un Projet TI.

Si vous pensez que ce billet sur la sauvegarde de documentation d’un projet TI est le parent pauvre des deux précédents, détrompez-vous.  Trop souvent la documentation d’un Projet TI n’est pas consultée parce qu’elle n’est pas facile d’accès et, pour les mêmes raisons, la documentation n’est souvent pas à jour.

(suite…)

Format de documentation d’un projet TI; meilleures pratiques

Quel est le format de documentation d’un projet TI le plus approprié ?  Et quelles sont les meilleures pratiques de documentation d’un projet TI en termes de format ?

La question peut paraître étrange car pour plusieurs, cette question ne se pose même pas. Mais en y regardant de plus près, elle mérite qu’on s’y attarde; comment doit-on documenter un projet TI et avec quel type de format ?

Pour mettre en lumière le défi du format de documentation d’un Projet TI, il faut tenir compte de trois facteurs :

  • Objet de la documentation
  • À qui elle s’adresse ?
  • Par qui est-elle produite ?

(suite…)

Meilleures pratiques de Documentation d’un Projet TI; l’objet de la documentation

Les meilleures pratiques de Documentation d’un Projet TI ne sont pas simples car l’objet de la documentation n’est pas toujours évident. D’abord, dans un projet TI, on peut retrouver un grand nombre de documentations différentes; le fameux manuel de l’usager, la documentation des requis destinée à l’exploitant du logiciel, la documentation d’architecture et de design destinée aux analystes, designers et développeurs et finalement, la documentation technique ou documentation logicielle destinée aux programmeurs en sont les principaux exemples.

Bref, la documentation d’un Projet de Développement logiciel, c’est comme les assurances, ça en prend mais il faut trouver le bon équilibre.

En ce qui nous concerne, nous parlerons de la documentation d’architecture et de conception et de la documentation technique d’un projet de développement TI. Ainsi, que doit-on documenter ?

Dans cette série de billets, nous allons aborder les points suivants :

  • Que doit-on documenter dans un projet TI ?
  • Comment doit-on documenter ?
  • Où doit-on rendre disponible ces documents aux différents lecteurs ?

(suite…)

La vision du Développement orienté-Service, par-delà l’Architecture orientée-Service

Nous voudrions dans ce billet, par-delà l’Architecture orientée-Service, revenir sur la vision du Développement orienté-Service car ce n’est pas rien, considérant que beaucoup soutiennent qu’en TI, il y a eu un avant et un après Architecture SOA !

La raison en est fort simple, avec l’architecture orientée-service, les services développés se sont retrouvés au cœur des systèmes d’information, en interface à la fois avec les applications fondamentales et les données.

Bien que cela ne soit pas évident au premier coup d’œil, beaucoup de développeurs y ont tout à coup gagné une marge de manœuvre, une liberté de conception, d’aucuns diront une créativité nouvelle.

(suite…)

Développement orienté Service, tous les bénéfices sans les risques !

Le Développement orienté Service offre tous les bénéfices du développement logiciel sur mesure mais sans les risques et sans les coûts d’un logiciel commercial; c’est ce que nous entendons aborder dans cette suite du billet précédent.

Nous expliquions dans le billet précédent qu’alors que le Développement logiciel sur mesure constitue un risque appréciable en termes de pérennité de services et de coûts de développement; le logiciel commercial, lui, entraîne souvent des coûts d’adaptation pré-installation faramineux et des frais récurrents de licence.

Ainsi, nous expliquions avoir pris une autre tangente depuis quelques années parce qu’elle nous apparaissait offrir le meilleur des deux mondes à la fois pour le client et pour le développeur; soit le Développement orienté service qui s’appuie sur trois principes :

(suite…)