Validation des commits par le product owner ?

[gordon]

Après discussion avec un ami développeur (nous avons tous deux peu d’expérience de missions en développement agile), nous avons pensé à une méthode pour faciliter la transparence d’un développeur (possiblement freelance) envers son client/product owner : ce dernier aurait accès, quotidiennement, à la liste des commits créés (leur nom uniquement). Il aurait alors la tâche de « valider » les commits pour indiquer « je constate que le projet a avancé », et il s’engagerait alors sur le paiement de cette journée de travail. Sans validation après deux jours, le projet se mettrait en pause.

Pour expliquer un peu plus précisément le contexte, il s’agirait d’opter pour cette méthode dans le cadre d’interactions entre des clients et des devs freelance junior, le tout en contrat par forfait. L’idée est donc de s’assurer que les choses avancent, et d’en avoir une preuve des deux côtés (le client voit pourquoi il paie, et ne peut pas refuser le paiement d’un jour travaillé).

Avez-vous des remarques à faire là-dessus ?

[ethan]

Mmh, dans cette approche, si je me met à la place du client, qu’est ce qui me prouve qu’une liste de commit correspond à une réelle avancée sur le projet? Après tout, le développeur pourrait très bien committer 3 fois un ajout d’espace dans un fichier. À moins que la phase de “validation” par le client lui donne accès à plus d’informations?

[gordon]

Je me dis que, s’il y a litige, il pourrait facilement être prouvé qu’un commit représente du travail ou pas.

On pourrait imaginer donner accès à plus d’infos au PO, comme le nombre de lignes en plus/moins dans un commit, ou bien le nombre de lignes modifiées, mais ces métriques, aux yeux d’un profane en développement, n’ont pas vraiment de sens.

[Toilal]

Je verrai mieux un système à base d’intégration continue, ou le client peut avoir accès à la version en cours de développement, même si elle n’est pas ou peu fonctionnelle. Là au moins, il peut voir les choses avancer, même si c’est compliqué en début de développement si l’application n’existe pas encore.

Les messages git sont trop techniques et élémentaires pour le client.

[benjamin_bnds]

Et pourquoi pas un outil d’échange/suivi plus “haut” niveau.
Un board Trello avec des cartes qui bougent, client et fournisseur ont accès.
Eventuellement certaines colonnes peuvent avoir comme titre les dates de release.

[gordon]

Existe-t-il un « Trello-like » libre et installable chez soi ?

[Jouj]

Bonjour,

La problématique n’est pas simple, mais l’idée est intéressante. Personnellement, je trouve la solution trello-like très bonne même si elle n’empêche pas de “tricher”…
D’après mon expérience, à chaque fin de sprint, il doit y avoir un livrable qui doit être validé par le client. Ce livrable doit suffire dans la majorité des cas à valider les user stories.
Un accès aux résultats des tests est un plus que certains clients pourraient apprécier. En revanche, un accès à la version en cours de développement est sûrement plus compliqué à mettre en place et peut poser de nombreux soucis qui feront perdre du temps à tout le monde. Pour moi, ce n’est pas une bonne solution.

[marcSauget]

Je donne un avis purement externe, ne travaillant pas avec un product-owner en direct.

Pour moi, le simple fait de vouloir faire valider les commits par le product-owner laisse présager d’un problème.
Si on regarde un peu la méthodologie Scrum (et les autres doivent être semblable), le product owner est différent du product master. Deux rôles différents car les enjeux ne sont pas les mêmes, les fréquences sur le projet non plus.
En voulant faire cela, pour moi, vous risquez de mélanger les rôles du donneur d’ordre (owner) du responsable du développement, résultat, vous risquez de mélanger les responsabilités et de vous retrouver un manque de liberté flagrant.
Théoriquement, vous livrez une fonctionnalités correspondant un besoin, le client est sensé valider le fait que ce que vous livrez réponde au besoin, pas trop le comment. En lui faisant valider les commits, il va entrer dans le comment … ce qui, à mon sens, doit rester de votre domaine de responsabilité.

En parallèle, je ne sais pas ce que vous utilisez comme gestionnaire de version, mais la pratique actuelle est au micro-commit, fonctionnalité par fonctionnalité, ou la fonctionnalité est différente de la fonctionnalité métier. Il est vraisemblable que votre client ne soit pas au fait de votre découpage technique de ce projet (et n’a peut être pas les connaissances techniques pour les comprendre) … Lui donner le rôle de valider l’ensemble de vos commits, va peut être lui faire valider un grand nombre de commit pas toujours compréhensible pour lui … Une bonne source d’ennui (ou au mieux de perte de temps en perspective).

Vous pourriez simplement réduire la durée de vos sprints pour qu’il puisse valider des fonctionnalités métiers régulièrement ?

[flou]

@gordon oui il existe un clone libre : https://github.com/libreboard/libreboard

[lkdjiin]

Je te déconseille vivement de faire ça !
Je vois 3 problèmes avec ton idée:

1. Un commit ne représente pas une valeur ajoutée pour le client. Ça ne mesure rien. C’est technique. C’est uniquement pour les devs. En d’autres termes c’est incompréhensible par un client.

2. Une erreur classique dans un contexte agile est de vouloir ajouter des proccess (et strict en plus) pour tout et pour rien. Et on fait cette erreur quelle que soit notre expérience. Imagine que ton client «valide» un commit aujourd’hui que tu doives supprimer demain ?

3. Pour s’assurer que les choses avancent, les outils nécessaires existent déjà : un board et un delivrable à chaque fin d’itération. Le board doit exister (quelle que soit sa forme) et être partagé avec le client pour que celui ci puisse ordonner les tâches à venir. Ce board est suffisant pour voir l’avancée quotidienne. Quand le client veut en voir plus, on peut aussi jouer sur la durée des itérations.

[lkdjiin]

Mauvaise idée, tu vas passer ton temps à expliquer à ton client pourquoi telle fonction n’est pas encore là, pourquoi telle autre ne fonctionne pas encore comme il faut, que oui, ce bug va être corrigé, etc. ;)

Sinon, ok, les messages de commit ne concernent pas le client.

[gordon]

Merci à tous pour ces retours, très utiles. Je vais plutôt m’orienter vers un reporting classique avec Libreboard, qui semble être un outil très intéressant.

[arnaud_oqube]

Bonjour,
Comme déjà dit par ailleurs, c’est probablement une mauvaise idée pour toutes les raisons citées. C’est aussi et surtout une mauvaise idée pour le client : comment savoir si un commit a du sens ou pas ? Il faut regarder à l’intérieur, comprendre le code, pourquoi ce code a changé… Du coup le client a l’obligation de se faire développeur ce qui n’est souvent ni possible (pas les compétences), ni souhaitables.

Mais pour moi la vrai mauvaise idée dans cette histoire c’est le contrat au forfait. D’ailleurs je perçois une contradiction entre le premier et le second paragraphe : tu veux que le client constate l’avancement et paye la journée de dev, mais tu fais un contrat au forfait… C’est étrange pour ne pas dire incohérent.

Puisque le mot-commencant-par-A a été cité, parlons en ! Un des quatre principes de base de l’Agilité c’est: “la collaboration avec le client plutôt que la contractualisation rigide”. L’idée, c’est de construire et travailler la confiance entre les parties : le client a confiance que les gens qui développent son logiciel sont des professionnels qui font leur travail correctement, avec toutes les limites qu’implique le fait de développer un logiciel (on fait des erreurs, on tombe sur des problèmes non prévus, on ne sait pas tout…) ; le développeur a confiance dans le fait que le client va payer son travail au juste prix et travailler avec lui pour résoudre son problème, avec toutes les limites que cela implique (les budgets ne sont pas extensibles, le client peut changer d’avis…).

Demander au client de valider un commit, objet technique s’il en est, va totalement à l’encontre de ce principe de confiance. Mais de manière générale, lui demander de valider quoi que ce soit est d’une certaine manière absurde et ouvre la porte à des arguties sans fin. Ce que propose l’agilité pour résoudre cette contradiction, c’est le principe : “un logiciel fonctionnel plutôt qu’une documentation exhaustive”. L’équipe livre en permanence un logiciel qui fonctionne, que le client peut utiliser, même imparfaitement, même partiellement, et ceci dès le début du développement. Être transparent sur le résultat permet d’éviter de discuter sur les moyens d’y parvenir.