Agilité - Engagement et Kanban

Si l'agilité est appliquée correctement au cadre contractuel d'un projet, quel est le type d'engagement demandé au prestataire ?

• Un engagement de moyens

• Un engagement de résultats

• Aucun engagement

• Un engagement de résultats et de moyens

J'ai un engagement de moyens vis à vis de mon client, à quoi cela correspond ? (plusieurs réponses possibles)

• Un engagement sur la durée

• Un engagement sur les compétences

• Un engagement sur un livrable

• Un engagement sur l'efficacité d'un produit

Sur mon projet agile, j'ai un engagement de résultats, parmi les affirmations suivantes, lesquelles représentent un risque pour le projet ? (plusieurs réponses possibles)

• Le projet est agile donc mon client me demandera de prendre en charge des éléments qui ne sont pas prévus initialement dans le projet sans révision du budget

• L'engagement de résultat fait que tout changement de périmètre pourrait m'être reproché (contractuellement)

• Il n'y a aucun risque

• Chaque changement de périmètre demandé par mon client me demande un effort supplémentaire (chiffrage, négociation, contractualisation...)

Quels sont les avantages d'un engagement de moyens ?

• Les négociations client / prestataire sont centrées sur l'efficacité de la solution

• Les négociations client / prestataire sont centrées sur les éléments contractuels

• Il n'y a pas de négociation, les changements sont imposés à coups de 49.3

Mon projet fonctionne sur un engagement de moyens. Malheureusement un membre de l'équipe est en arrêt pendant l'intégralité du Sprint. Financièrement, comment cette situation sera-t-elle résolue ?

• Le client ne paiera que l'équivalent de ce qui est consommé par l'équipe

• Cela ne change rien, il faut terminer le projet, c'est au prestataire de faire l'effort pour rattraper le retard

• Cela ne change rien, le prix est fixé contractuellement pour la période couverte par le contrat, le client payera la totalité du prix.

• Cela ne change rien, le reste de l'équipe doit se mobiliser pour compenser les absences, le prix à payer sera le même pour le client.

Je suis sur un projet Agile, avec engagement de moyens, mon client ne comprend pas le retard pris par l'équipe sur le dernier Sprint, que doit-il se passer ? (Plusieurs réponses possibles)

• L'équipe de développement doit repousser la fin du Sprint pour pouvoir terminer le périmètre défini initialement

• L'équipe de développement doit chercher à comprendre les raisons du retard et essayer de s'améliorer

• Le Sprint se terminer normalement, le périmètre non terminé sera reconduit dans un sprint ultérieur

• L'équipe de développement doit expliquer les raisons du retard accumulé pour en faire comprendre les raisons au client

En Scrum, le Sprint Planning permet de définir le Sprint Goal (l'objectif du Sprint), l'équipe de développement doit-elle tout donner pour atteindre coute que coute le Sprint Goal ?

• Oui, c'est un objectif, et l'équipe s'est engagée sur le résultat

• Non, c'est un objectif mais les raisons de l'échec du Sprint Goal ne sont pas nécessairement imputables à l'équipe de développement

Qui est responsable en cas d'échec à atteindre le Sprint Goal au sein d'un Sprint ?

• Le Scrum Master

• Le Product Owner

• L'équipe de développement

• La Scrum Team

• L'équipe de développement et le Scrum Master

Je suis Product Owner (PO) mis à disposition du client par le prestataire pour intervenir auprès de l'équipe de développement sur un projet Agile, cette configuration est-elle la meilleure ? (Plusieurs réponses possibles)

• Non, étant prestataire, il est peu probable que le client me laisse le pouvoir de décision suffisant pour orienter l'évolution du produit

• Non, étant prestataire, il est peu probable que le client partage avec moi les données stratégiques de l'entreprise me permettant de prendre des décisions éclairées pour le produit

• Oui, étant prestataire, je connais déjà l'équipe de développement, ce sera plus simple de travailler avec eux

• Non, étant prestataire, cela va à l'encontre des principes de l'agilité qui demande à ce que le client soit intégré dans le projet au quotidien

Le Product Owner observe que la valeur produite lors des derniers Sprints est faible et qu'il n'a plus d'éléments ayant suffisamment de valeur dans son Product Backlog. Il décide d'arrêter le développement du produit, est-ce une bonne décision ?

• Oui, si la valeur n'est pas au rendez-vous, l'investissement n'est pas rentable

• Non, il devrait continuer le développement de son produit pour le terminer

• Non, arrêter le développement d'un projet est un aveu d'échec, il doit trouver des solutions pour poursuivre son développement