Qu’est ce qu’un story point? Un story point sert à estimer l’effort nécessaire à une équipe pour implémenter une fonctionnalité (story pour les intimes).Cette estimation prend en compte : l’effort pour le développement la complexité du développement Le risque / l’inconnu Par abus de langage, on dit que le story point sert à estimer la …
J’ai pu cette année, après quelques années d’interruption, reprendre une de mes activités favorites : la croisière à la voile. Et cela s’est encore très bien passé. Merci à mes coéquipiers 1. Un programme défini en commun au début de la quinzaine puis respecté par la suite. Une adaptation journalière aux contraintes de la météo. Au …
Lors des étapes du 14 octobre à Vannes et du 28 octobre à Paris, des intervenants Neoxia auront l’occasion de donner des conférences sur des sujets aussi variés que les gaspillages dans les projets informatiques, le rythme parfois insoutenable dans l’Agile, ou encore les problèmes posés par la maintenance.
Sur son blog, David Brocard commente un phénomène observé dans des équipes agiles (Scrum par exemple) : une pression et un rythme insoutenable pèsent sur l’équipe. À mon sens, ceci est la conséquence d’un héritage des approches classiques, et d’un oubli de certains principes qui font l’Agilité. Voyons cela plus en détail.
La valeur. Voilà un terme qui s’utilise souvent à outrance. Dans le secteur informatique, on est en perpétuelle recherche de valeur. L’objectif permanent est de la maximiser.
J’ai mis un certain temps à comprendre ce que l’on entendait par le mot ‘valeur’. Je commence aujourd’hui à en cerner les contours. Et plus cette compréhension progresse, plus mon intérêt redouble.
L’une des premières prises de conscience est que la valeur est un concept qui s’utilise dans n’importe quel domaine, avec, souvent, le même sens caché. Marié depuis peu, j’ai pu en faire l’enrichissante expérience, à travers l’organisation de mon mariage. Alors qu’il ne nous restait plus qu’une semaine de préparation, nous nous sommes rendu compte que nous n’allions pas pouvoir finir tout ce que nous avions projeté de faire.
Dans un précédent billet Industrialiser n’est pas automatiser, nous présentions les standards comme moteur de l’industrialisation, et base de l’amélioration continue. Voyons maintenant comment une équipe peut mettre en pratique ces principes.
Comment élabore-elle ses standards ? Comment les met-elle en application ?
Reprenons l’exemple de l’éditeur de logiciel de e-commerce, et de son équipe de développement. Pour rappel, l’équipe livre, toutes les 2 semaines, des fonctionnalités en mettant en œuvre Scrum.
La lutte contre les facteurs de coût est éternelle. En matière de développement, elle consiste d’abord à réduire les temps de développement. Pour ce faire, on peut améliorer l’efficacité et la productivité du travail, ou bien encore, comme les temps de développement sont chiffrés à la journée, augmenter le temps de travail d’une journée, au risque d’aboutir à des charges irréalistes.
Une voie trop rarement empruntée consiste simplement à agir à la source, en évitant de demander des fonctionnalités, ou d’intégrer des exigences, dont on n’aura pas besoin. Une idée simple, et pourtant…
Sur TV4IT, Eric K’Dual évoque la démarche lean et son application à l’informatique.
Que promet la démarche lean ?
Quels sont ses grands pilliers ?
Comment le lean contribue à l’amélioration continue ?
Comment cette méthode s’applique-t-elle à l’informatique et notamment à la production ?
Quels sont ses liens avec les méthodes agiles ?
Eclairage avec Eric K’Dual, responsable de l’activité architecture de Neoxia.
Comme beaucoup, je pensais, il y a quelques mois encore, que l’industrialisation se résumait à une question d’automatisation. Au cours d’un échange passionné, on me fit remarquer qu’une procédure manuelle parfaitement réalisée pouvait être aussi efficace qu’un automate, et bien souvent moins coûteuse. Suite à cette discussion, je décidais de revoir mon approche, et de l’approfondir.
Dans le dernier billet, un bug grave avait été découvert sur une des solutions de e-commerce. À la sortie du débriefing, David et Mathieu échangent à la machine à café.
Ward Cunningham, le père du wiki, résume ainsi la notion de dette technique :
Laisser s’accumuler la dette technique pour répondre rapidement à un besoin fonctionnel est une pratique assez courante dans le développement logiciel.
Malheureusement, la dette qui s’accumule épuise les ressources projets, et démotive les équipes. Lorsque la dette s’est effectivement accumulée, le travail d’un architecte est alors d’investir pour rembourser la dette principale (à plus ou moins long terme), et pour éviter que le système ne s’écroule sous la dette, et sous les intérêts.
