Il existe un adage en informatique : consommez ce que vous avez préparé. L’idée est d’utiliser nous-même les logiciels que nous distribuons à nos clients pour en améliorer la qualité et l’utilisabilité. Après tout, il est beaucoup plus facile d’ignorer les irritants vécus par un client que ceux qui nous affligent tous les jours.
Archives du mot-clef Agile
Demander de l’aide c’est être fort
Nous avons tous régulièrement entendu cette maxime. On l’utilise pour inciter les gens à consulter un médecin ou à parler à un groupe de soutien. Cependant, on peut certainement l’appliquer à un domaine beaucoup plus large. En effet, il est rare que la réussite soit le fait d’une seule et unique personne. En informatique, il existe encore quelques exceptions principalement dans les applications pour appareils mobiles mais elles tendent à disparaître avec la complexification du développement. Pour réussir, il faut indiscutablement être une équipe.
Apprendre à viser juste
Le jeux de dards, le passe-temps le plus dangereux que l’on peut pratiquer en public dans un bar ou une taverne. Heureusement, il est presque disparu des lieux publics au Québec. Ce qui doit avoir évité des mésaventures à plusieurs personnes. Il existe quelques variantes des règles mais le jeu est tout de même assez simple. Il suffit de viser juste pour atteindre la cible de préférence près du centre. Ce n’est pas une chose très difficile à faire avec trois dards et les encouragements de quelques amis. La cible ne bouge pas, on n’est pas très loin et on peut contrôler la quantité d’alcool consommée. Pourtant, c’est quand même bougrement difficile et la cible semble être vraiment petite.
L’informatique industrielle ou le Kanban appliqué
D’accord le titre peut sembler contradictoire. Après tout, l’informatique est un domaine où la production à la chaîne n’est pas vraiment possible. La variabilité des tâches est diverse et les gens ne sont pas interchangeables. Mais est-ce qu’on ne pourrait pas retirer quelques avantages à optimiser la production logicielle en s’inspirant du travail en usine?
Le projet est en retard, il nous faut un plan
Avez-vous déjà remarqué que la première chose qu’on nous demande de faire lorsqu’un projet est en retard est de produire une liste? Bien sûr, cette liste est parfois habilement dissimulée par une autre appellation comme un plan d’action ou un état général de la situation. Mais dans tous les cas, le document produit reste toujours une liste des choses à faire pour compléter le projet.
L’objectif de cette liste est de créer une stratégie claire pour la complétion du projet. Le client va s’en servir comme étalon pour juger de l’avancement futur du projet. Elle lui donne une sensation de contrôle parce qu’il sait ce qu’on doit faire, la direction qu’on va suivre et combien de temps on va prendre. Elle n’existe que pour cet objectif bien particulier soit rassurer le client et lui démontrer qu’on a la volonté de compléter le projet.
Comment j’ai découvert la gestion de projet agile ou pourquoi je n’ai plus un mur de libre
Tout vient d’une constation bien simple que j’ai fait voici un an ou deux: J’ai de la difficulté à connaître l’avancement de mes projets et toutes mes prévisions ne marchent pas. Simple à régler? Pas vraiment…
L’informatique est un milieu particulier pour la gestion de projet. L’incertitude et la variabilité des tâches sont très élevées. En effet, il est possible d’atteindre le même objectif de plusieurs manières différentes. Chaque manière est plus ou moins complexe et implique un temps de réalisation différent dépendant du risque, de la description de la tâche, de l’expérience du programmeur, de son état mental, de l’alignement des planètes et du nombre de fois que son chat a marché sur le clavier. Au final, on se retrouve avec un projet composé de probablement 50 à 500 tâches qui peuvent prendre de 2 à 40 fois le temps prévu 90% du temps si on est chanceux.
Information générée par une source non certifiée 