Discussion :

[Invité]

Bonsoir,

Je jette une bouteille à la mer.

Actuellement travaillant sur un dossier ou je dois faire intervenir des notions "d'impact" , de "sprint" et "d’amélioration continue" , je recherche des exemples de ce qu'on appelle "impact".

Le dossier que je traite dans le fond touche à une problématique de flux de paiements entre une entreprises A et des fournisseurs. Il y a nécessité d'ajouter un code dans un classement existant, pour l'aiguillage des flux de paiements en question.

Un "impact" peut être budgétaire, organisationnel, structurelle ...

Auriez vous justement une liste, un schéma , une doc de ce qu'on appelle "un impact" ? Si possible une liste "d'impacts" le plus exhaustif possible, des "grandes familles types" en somme.

Quelque chose du même accabit qu'un indicateur smart, ou que le roue de Deming

Merci de m'aiguiller

[Pyramidev]

Bonjour,

Je n'ai pas de liste de catégories d'impact sous la main mais, en gros, dans une équipe auto-organisée dans laquelle les développeurs sont impliqués dans le besoin métier et interviennent dans les prises de décision, de meilleures décisions peuvent être prises, ce qui aboutit à un meilleur impact.

C'est le principal sujet abordé par l'article What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not publié par Gergely Orosz le 20/10/2020. Voici un extrait avec quelques exemples :

Here's a couple of conversations I've had at "SV-like" companies after asking an engineer if they can do X:

• "I did a bit of digging, and though we could do X, if we can reduce the scope by this feature that won't make a difference for the business impact, we could ship this without any code changes, just changing a few config files."
•"I am concerned if we could ship the project, and think we should put a pause on it. I checked what our competitors are doing, and one of them launched a similar feature, but reversed it, after they got investigated by the regulator. Have we checked with the legal team if we could ship this at all?"
• "I looked at our backlog, and project Y is really similar. If we combined project X and project Y, we could ship two things, with very little overhead."
• "We could either build this project on the legacy infrastructure now, but then we have migrate to the new infra that will be complete in a month. Can we delay the project by a month, until the new infra is ready, to avoid double work? If there's no strong business reason to launch in a month, I'd really suggest we do this"

In an environment that encourages problem solving and results over following directions, better decisions are made.

Remarque : pour les lecteurs du fil, je rappelle les liens avec l'agilité, le vrai Scrum et le Lean :
• Parmi les principes sous-jacents au manifeste agile, on peut lire Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
• Scrum est défini dans le guide Scrum qui insiste sur le fait que les équipes sont autoorganisées : Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
• Lean est défini dans le livre Lean Software Development: An Agile Toolkit qui est payant, mis à part le chapitre 3 Decide as Late as Possible qui est gratuitement accessible en ligne. Dans ce chapitre, à un moment, il y a une analogie avec les Marines pour parler des avantages de laisser des personnes en première ligne prendre des décisions pour s'adapter à la réalité du terrain avec les informations les plus à jour.

J'ai jugé ce rappel utile, car beaucoup d'entreprises disent être agiles et faire du Scrum. Mais, en général, elles ne s'appuient que sur une partie de l'agilité (typiquement le développement itératif pour avoir des feedbacks plus rapides) et ne font presque jamais du vrai Scrum.

[Invité]

Bonsoir,

Bonjour,

Je n'ai pas de liste de catégories d'impact sous la main mais, en gros, dans une équipe auto-organisée dans laquelle les développeurs sont impliqués dans le besoin métier et interviennent dans les prises de décision, de meilleures décisions peuvent être prises, ce qui aboutit à un meilleur impact.

C'est le principal sujet abordé par l'article What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not publié par Gergely Orosz le 20/10/2020. Voici un extrait avec quelques exemples :

Remarque : pour les lecteurs du fil, je rappelle les liens avec l'agilité, le vrai Scrum et le Lean :
• Parmi les principes sous-jacents au manifeste agile, on peut lire Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
• Scrum est défini dans le guide Scrum qui insiste sur le fait que les équipes sont autoorganisées : Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
• Lean est défini dans le livre Lean Software Development: An Agile Toolkit qui est payant, mis à part le chapitre 3 Decide as Late as Possible qui est gratuitement accessible en ligne. Dans ce chapitre, à un moment, il y a une analogie avec les Marines pour parler des avantages de laisser des personnes en première ligne prendre des décisions pour s'adapter à la réalité du terrain avec les informations les plus à jour.

J'ai jugé ce rappel utile, car beaucoup d'entreprises disent être agiles et faire du Scrum. Mais, en général, elles ne s'appuient que sur une partie de l'agilité (typiquement le développement itératif pour avoir des feedbacks plus rapides) et ne font presque jamais du vrai Scrum.

Merci pour ces liens. Je vais regarder cela avec attention