Cette chose qu’on nomme Agile (et pourquoi c’est génial pour IBM i!)

Le changement est une bonne chose.

Nous nous améliorons seulement lorsque nous faisons quelque chose différemment. Pensez-y: ceux qui veulent perdre du poids essayent de changer ce qu’ils mangent et d’augmenter leur activité physique. Pourquoi? Parce que leurs habitudes quotidiennes et leur routine justifient leur poids actuel. Afin d’y voir un progrès, il faut sortir de sa zone de confort et essayer de changer un aspect de son quotidien. La même chose s’applique à un projet en TI.

Il y a quelque temps, j’ai commencé à introduire l’agilité dans mon travail chez Fresche. L’agilité était quelque chose qui m’avait été enseigné lors de mes études, et que je n’avais jamais mis en pratique dans ma carrière en informatique. Mon expérience en cycle de développement logiciel était strictement avec le modèle en cascade. Je dois admettre que les deux premières fois, je n’ai pas saisi l’agilité en tant que tel. Je me souviens d’un enseignant ou coach Agile qui m’avait dit: « Garde les choses simple ». Et ma réponse a été: « Mais je ne peux pas modifier les choses maintenant, nous l’avons déjà mis en place de cette façon ». C’était un projet long et compliqué. Inutile de dire que nous aurions dû faire certaines choses différemment. Toujours plus facile d’évaluer en rétrospective.

C’est une chose complexe.

Beaucoup de nos clients viennent du monde IBM i. Lorsque les entreprises veulent moderniser leurs applications, elles s’adressent à nous. Nous proposons une large gamme de solutions, dont la transformation de code. Peu importe leur système, tous nos clients ont un point en commun: ils utilisent un code plus ancien, tel que RPG, Cobol ou CA 2E, et souhaitent évoluer vers un langage de programmation moderne, tel que Java. Au final, chaque client et chaque environnement est différent, ce qui en fait un projet complexe.

Tant d’options et de façons

Revenons à aujourd’hui… modèle en cascade, chute d’eau, quoi? Je suis tombé en amour avec l’approche Agile et laissez-moi vous dire pourquoi. L’une des pratiques agile consiste à valoriser les personnes et les interactions par rapport aux processus. Ceci implique d’apporter des améliorations avant la fin du projet. Quel est l’intérêt d’une séance de leçons apprises lorsque le projet est déjà terminé et que vous l’avez livré à votre client? Pour que vous puissiez améliorer avec le prochain client? Qu’en est-il de votre client actuel? En mode agile, vos collaborateurs, les parties prenantes et, plus important encore, le client partagent rapidement leurs commentaires. Imaginez pouvoir apporter des améliorations immédiatement. Qu’est-ce que cela signifie pour nos clients IBM i? Plus de valeur tangible! Comment? Parce que nous avons pu faire les changements nécessaires. Être Agile est la réponse à nos environnements en constante évolution.

Rétroaction en continue

La rétroaction en continue est une partie essentielle dans un environnement Agile. Nous effectuons des rétrospectives d’équipe et des revues de produits pour recueillir ces commentaires. Comment allons-nous? Pouvons-nous faire mieux? Que pouvons-nous améliorer? Toutes les questions qui nous aident à offrir le plus de valeur à nos clients. Enfin, ce que nous faisons avec cette information est tout aussi important. Nous nous efforçons de changer une chose à la fois. Le résultat final? Un meilleur service et un meilleur produit pour nos clients.

This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.