Mot-clé - contrat

Fil des billets - Fil des commentaires

Arrêt sur retours d'expérience

La journée sur les méthodes agiles organisée par le CCT du Cnes a fait la part belle aux retours d'expérience. Les 200 personnes qui assistaient à ce séminaire, dont l'accroche était "Vraie rupture ou effet de mode ?", ont pu se rendre compte de la diversité des mises en œuvre.

Lire la suite...

Un retour d'expérience Scrum épatant

Jeudi, lors de l'Agile Tour à Toulouse, j'ai assisté au retour d'expérience d'un projet au forfait en Scrum entre l'INRA et Ekito. A chaque fois que je fais une présentation publique (et c'était encore le cas à Montpellier vendredi), j'ai droit à la question sur la compatibilité du forfait avec l'agilité ; la meilleure réponse est donnée par des expériences réussies. Et celle-là était la plus convaincante que j'ai observée.

Nicolas nous a raconté de façon magistrale la façon dont Scrum a été appliqué sur le projet. Les points-clé que j'ai relevés pour le succès de Scrum dans le cadre de ce projet au forfait :

  • un Product Owner, côté client, motivé, qui définit bien les priorités et qui est suffisamment disponible,
  • un ScrumMaster (c'était Nicolas) qui a bien compris Scrum et qui a su l'adapter au contexte,
  • un coach Scrum (c'était Jean-Marie Damas) très utile pour cadrer une première expérience,
  • un outil (c'était IceScrum) adapté à la distribution géographique [1] de l'équipe.

Pour ceux qui ont raté l'excellente présentation de Nicolas, son support "Forfait Scrum" est en ligne, avec les autres de la journée, sur le site de la SigmaT.

Notes

[1] entre l'INRA à Castanet et la rue de la bourse, il y a bien 12 kms

La vie en SSII

L'agilité devrait ramener un peu du plaisir de coder.

Lire la suite...

Gagnant-gagnant pour un contrat au forfait

Money for nothing, en version française.

Lire la suite...

Agilité et business model des SSII

Mon interview dans 01, sur le modèle historique du contrat au forfait face à l'essor des méthodes agiles

Lire la suite...

Les projets au forfait et l'éthique, en français

Les projets au forfait, c'est un sujet imprégné de culture d'entreprise. Il existe une croyance sur l'incompatibilité de l'agilité avec les contrats au forfait. Il faut des arguments et du temps pour la combattre. Les arguments sont connus, j'en ai déjà présentés plusieurs[1].

Mais c'est toujours nécessaire d'y revenir, en avançant de nouvelles thèses. Scott Ambler, qui avait fait un article l'an dernier sur le sujet, met cette fois-ci en avant l'éthique.
Je ne vous donne pas le lien dans Dr.Dobb's, car Java in the Alps a pris l'excellente initiative de traduire l'article en français : Les projets au forfait vont-ils à l’encontre de l’éthique ?

Notes

[1] comme ici ou . J'ai fait une présentation sur le sujet au SigmaT3 et Ekito en a fait une au SigmaT5, les 2 sont disponibles en téléchargement.

Conseil agile

Pour une méthode agile, du conseil agile.

Lire la suite...

Contrat au forfait et démarche agile

Une discussion récente avec un acheteur d'une grande administration m'a conforté dans l'idée que le contrat au forfait n'est pas un obstacle à l'introduction de l'agilité. Au contraire, l'agilité apparaît comme une voie à suivre pour éviter les difficultés rencontrées dans les contrats actuels.

Lire la suite...

La release à points

Une release est une série de sprints successifs. C'est une période de temps. Comment et quand déterminer la fin de la série et donc la fin de la release ?

Il y a la façon adaptative : la fin de la release n'est pas fixée, elle est envisagée à la fin de chaque sprint. On parle de release ajustable.

Il y a la façon prédictive : la date de fin de la release est décidée, c'est ce qu'on appelle une release à date fixée. Cela comporte des avantages.

Une release ajustable peut devenir à date fixée pendant son déroulement. A la fin d'un sprint, on décide avec le product owner que le produit est dans un état qui permet dé définir à quelle date on pourra finir la release.

On peut évoquer un troisième type de release, même s'il n'est pas agile, c'est la release à périmètre fixé (dans la pratique, le périmètre n'est jamais fixe). Le périmètre est défini par les éléments du backlog à faire.

A quoi sert de connaître le type de release ? Cela est déjà une information publiée, importante pour l'équipe et à l'extérieur. Cela permet également de faire une planification :

  • pour une release à périmètre fixé, l'objectif de la planification est de calculer la date de fin.
  • pour une release à date fixée, l'objectif de la planification est de calculer les fonctionnalités (stories) qui seront finies à cette date.

IceScrum permet déjà une planification automatique en associant des éléments du backlog sur les sprints en fonction de la vélocité estimée et du poids en points des éléments. Une nouvelle story d'IceScrum, développée actuellement, est d'améliorer cette planification en prenant en compte les types de release.

Est-ce par télépathie, car cette idée je viens de la présenter chez un client dans le cadre de réflexions sur les forfaits agiles ? Toujours est-il que le développeur de l'équipe en charge de cette story est parti, à son initiative, sur un autre type de release, la release à points (on pourrait dire release à taille fixée). Une release à taille fixée a un objectif défini en nombre de points à faire. A chaque sprint on mesure la vélocité et on diminue le nombre de points restant à faire. La release se termine quand on arrive à 0.

L'idée est intéressante pour les projets au forfait (et pourquoi pas de la TMA) : le contrat porterait sur un nombre de points et le client peut ajuster le contenu et les priorités. Mais cela nécessite d'avoir une équipe stable dont on connait la vélocité.

SigmaT3 : agilité et contrat au forfait

Le séminaire de vendredi sera l'occasion de débattre de ce sujet récurrent

Lire la suite...

- page 1 de 2