Dans la dernière vidéo de Scrum Life, il est dit :
Si on ne se pose pas la question ‹ est-ce qu’on a atteint l’objectif du sprint ? › c’est qu’on reste en mode ‹ dépiler un backlog › - https://youtu.be/lb9vaBbwC-g?t=220
Clairement je pense être dans ce cas… J’aimerais faire évoluer les choses.
Le problème est qu’avec la règle de ne pas mettre d’US lié fonctionnellement entre elles, on se retrouve vite bloquer si on veut avancer tout un pan de l’applicatif. Et donc on avance au max ce qu’on peut et puis on fait des petites US sur le reste de l’application puisqu’avec une équipe de 8 sur un sprint de 2 semaines, on peut difficilement tous travailler sur un seul pan de l’applciation.
Est-ce que je suis le seul à rencontrer ce problème ? Et sinon comment répondre à cette problématique et amener des objectifs de sprint ?
Si, c’est même très facile, ça s’appelle du mobbing/swarming/teaming
De manière plus pratique, une réduction de la durée du sprint peut être une solution, mais j’aurais envie de surtout poser la question suivante: pourquoi souhaitez vous faire des sprints exactement ?
La règle des US indépendantes c’est basé sur INVEST où l’US doit être indépendante et pas liée à une autre qui pourrait la bloquer durant une longue période pendant le sprint. Peut-être je l’ai mal interprété.
Pour le mobbing j’ai trouvé la définition suivante :
Le mobbing se manifeste comme un acharnement psychologique de l’ensemble de l’organisation sur un collaborateur.
Je ne pense pas que tu fasses référence à ça
Pour la question « Pourquoi veut-on faire des sprints ? », la réponse est diverse pour moi :
Oui, désolé, c’est bien le mob programming dont je parlais. D’ailleurs, c’est à cause de cet ambiguïté que le mouvement commence à préfèrer le terme de software teaming aujourd’hui
Indépendant ne veut pas forcément dire Autarcique.
I = l’item du backlog peut être réalisé complètement, sans qu’un n’autre ne doive l’être.
Donc les relations fonctionnelles sont autorisées.
Sur le terrain, j’ai plutôt découvert un problème de superposition que de dépendance.
2 Items qui dépendent du même socle.
Donc, il n’y a pas un item qui empêche l’autre, mais bien un qui entame le travail de l’autre.
Dans ce cas, le problème n’existe que sur l’estimation des 2 items parce qu’on va trouver que c’est une arnaque de comptabiliser le socle dans les 2 items.
Mais même, là, le problème n’est réel que si on utilise les estimations pour se justifier ou en croyant que c’est une science exacte.
Puisque l’important, c’est ton OBJECTIF DE SPRINT.
Les items sont la liste des choses à proposer à l’utilisateur pour atteindre cet objectif.
On se donne un sprint pour atteindre cet Objectif.
Si on est dans l’esprit, « on se donne un sprint pour réaliser tout ce qu’il y a à faire » on est en train de refaire du task list.
ça c’est si on considère que le découpage le plus efficient sur le sujet est un découpage fonctionnel dérivé d’US. Rien empêche que la tâche pour créer ce socle soit un SBI spécifique. Et là le soucis revient le management de dépendance et la gestion de ce genre de SBI en tout premier dans le sprint.
1 - On parle de dépendances externes. On ne supprime pas des dépendances externes, on s’en accommode au mieux et on prépare le terrain.
2 - L’architecture proposé dans ton article va à l’encontre de ce que je considère comme une bonne architecture (voir le paradigme Data Context Interactions et le Design By Contract).
3 - Est-ce que tu es d’accord avec la notion de « réduire le couplage au minimum, voir de le rendre inexistant si possible » ?
Pourtant elle se base sur les fondements de la Clean Architecture qui elle même a les propriétés de l’architecture hexagonale qui elle même utilise entre autre le D de SOLID : l’inversion de dépendance.
Comment inverser les dépenses si ce n’est en créant des contrats d’interface.
Exactement, cela commence par ne pas en créer.
Un couplage est quand deux composants sont dépendants entre eux. Ou bien quand l’architecture contient une dépendance cyclique.
Encore une fois, regarde le travail de Trygve et Coplien sur DCI. Relis les travaux séminaux d’Alan Kay. Ou même, vis à vis de SOLID, va voir le model CUPID de Dan North. Va voir ce qu’est le langage Eiffel et l’approche qu’elle prend vis à vis des assertions. Robert Martin n’est pas l’alpha et l’omega du développement logiciel.
Du coup on est fondamentalement pas d’accord sur l’importance des dépendances. Qu’est ce qui arrive dans un système où aucun éléments ne dépend l’un de l’autre ? Plus rien. On se retrouve avec des instances auto-centrées qui n’interagissent plus entre elles. Le business, les use-cases, les fonctionnalités se trouvent DANS ces interactions, DANS ces dépendances. Si demain ton corps n’avait plus de dépendances, tu deviendrais un sac d’atomes qui s’évaporerait dans l’air parce qu’il n’y aurait plus aucune cohésion dans le système.
Ce dont on parle avec l’inversion de dépendances par contre, c’est simplement une solution technique compliqué qu’on a trouvé pour manager la complexité accidentelle introduite par les langages orientés Class (Java en tête d’affiche) qui sont incapable de reproduire ce que Alan Kay envisageait à la base de l’Orienté Objet.
Merci Samuel, pour ce partage de ces ressources de veille.
Hier, j’ai regardé la conférence que tu as partagée sur la symétrie. Le contexte est important, l’application d’une pratique dépend du contexte d’utilisation.
L’objet de discussion est le couplage, pas les dépendances.
Concernant les dépendances d’architecture, elles doivent être acycliques, est dans le sens de la logique métier. De bas niveau vers haut niveau.
Par exemple, les use-cases, le cœur de l’application, ne doivent pas dépendre :
d’une base de données.
de l’interface utilisateur.
…
Quant aux dépendances lors de l’implémentation, elles sont supprimées dès lors que le use-case fournit un contrat d’interface.
Par exemple, l’implémentation du code pour accéder à la base de données ne dépendant pas du use-case.
Donc les dépendances existent de manière intrinsèque, mais ne concerne pas ce qui a le plus de valeur, la logique métier/les use-cases.
Pourquoi blâmer l’orienté-objet pour ce qu’il n’est pas censé résoudre, en l’occurrence modéliser le domaine de la vie réelle ?
En effet, l’orienté-objet ne peut pas modéliser tout le domaine de la vie réelle.
Un carré est un rectangle en géométrie.
Mais la class Carré ne peut pas étendre la class Rectangle en orienté-objet.
Elles ne partagent pas les mêmes propriétés.
L’inversion de dépendances a besoin du polymorphisme.
Ce principe est aussi applicable aux langages non orientés-objet.
Les langages orientés-object supportent polymorphisme
Les langages orientés-objet, quant à eux, permettent le polymorphisme, par conséquent l’implémentation de l’inversion de dépendances est plus simple.
Ceux non orientés-object peuvent aussi le faire
Ces langages peuvent aussi faire pointer la dépendance dans le mauvais sens. Ce n’est pas une caractéristique propre à l’orienté-objet.
L’inversion de dépendances est faisable aussi avec les langages non orientés-object. L’application est plus complexe dans ces langages, car il faut utiliser des pointeurs sur fonction pour faire du polymorphisme avec eux.
Je pense que la conférence de Coplien, a pour but de principalement éveiller les consciences pour ceux qui ont un mauvais usage des pratiques, ceux qui ne comprennent pas l’essence des pratiques, ceux qui font du cargo-culte.
Pour atteindre son objectif, il est bien obligé de trancher les idées qu’il partage.
La meilleure façon d’éveiller l’intérêt des individus est de briser directement leurs schémas existants.
— Citation tiret du livre « Ces idées qui collent : Pourquoi certaines idées survivent et d’autres meurent » écrit par Chip Heath, Dan Heath.
Encore merci pour ce partage, cela ne fait pas de mal une piqure de rappel.
Oui, c’est exact, dangereux comme le GOTO si c’est mal utilisé.
Il crache aussi sur les testes unitaires
Oui, une mauvaise pratique, essentiellement s’il y a un test unitaire pour chaque classe et fonction. Cela rend le code fragile. Cette erreur, je l’ai faite.
Son « bon » usage est couplé au TDD
Il permet décrire comment le cas d’usage se comporte.
Il fournit des exemples d’utilisation du cas d’usage.
Il fournit une preuve que le cas d’usage fonctionne comme il se doit, dans un domaine de définition donné.
Cela se rapproche plus à la science qu’à la mathématique. La science ne peut pas prouver qu’une théorie est vrai. Elle procède par des expérimentations pour trouver des cas où elle est fausse.
Il n’est pas question de test dans son sens strict, il n’est pas possible de prouver l’absence totale de bug.
Il permet de conserver le code propre et donc qu’il soit aussi facile de faire évoluer le comportement même après plusieurs itérations du code.
On y est presque mais c’est pas encore ça. Le fonctionnement du model DCI met l’accent sur les rôles. Ces roles sont définis dans des contextes qui sont des formalisation des use-cases exprimé dans un langage quasi transparent pour l’utilisateur final. Au runtime, quand un contexte est joué, les objets qu’on a identifié comme acteurs se voient attribué les rôles nécessaires au fonctionnement du dit use-case formant le contexte. Ces comportements sont défini non pas par héritage mais attaché au rôle, au runtime, à l’objet en question, et crée un réseau d’interactions entre les différents rôles. C’est ça, et avant tout ça l’essence de l’orienté objet d’Alan Kay. Pas de notions de polymorphisme, d’héritage, de class… Tout se trouve dans l’interaction entre les objets et le model mental de l’utilisateur.
@nicobiot Pourtant, ces notions apportées par le DCI sont très importantes, même pour des non-techniciens. Justement parce que le but est de rendre le pouvoir à l’utilisateur, en enlevant toutes les couches que les techniciens aiment bien utiliser pour se cacher.
